03-01-2010 12:43 PM
I am trying to measure the brightness of each "cell" of a grid in the fastest way possible. It appears that the Quantify function will do the trick, but I am running into some problems with how region boundaries are defined.
For example, suppose I defined two rectangualr regions:
RoiA - 100, 100, 100, 100 (left, top, width, heigth)
RoiB - 200, 100, 100, 100
The Quantify function interprets these as overlapping ROIs, and the QuantifyReport contains data for only one region having an area of 20,000 pixels. If RoiB were to use 201 as the left dimension, the QuantifyReport would contain data for two regions, each 10,000 pixels.
So, what is the boundary of the region? If the left dimension of the RoiA sits on top of pixel column 100, then the last pixel column is 199. I should be able to start a new ROI at Column 200 and the regions should not overlap. However, RoiA and RoiB do overlap, at least based on how the Quantify function works.
Any ideas?
03-01-2010 11:36 PM
actually the rectangle is defined as left,top,right,bottom in the roi descriptor. One simple thing you can do is to manually define the roi in vision assistant and generate the labview code ffrom it directly.
Also did you try histogram of the image for your application?
03-02-2010 11:48 AM
You're mistaken. Per the documentation for the NI VIsion .NET class library:
03-12-2010 10:33 AM
If I ask real nice, would somebody please answer my original question?
Pretty please? :manhappy:
03-15-2010 12:43 PM
Hi Steve,
Your original assumption is incorrect, which is what is causing issues. An ROI that starts at pixel 100 and goes for 100 pixels would end at pixel 200. You can confirm this by playing around in LabVIEW. This is why they are overlapping.
04-10-2010 12:28 PM
Thanks for the response. Didn't get around to checking sooner.
If I understand what you are saying, the ROI defined with the start on column 100 (left, and thinking only in terms of the width in order to simplify the discussion) and extending 10 pixels (Width) actually ends on column 110. This is actually 11 pixel columns, if the boundaries of the ROI sit on top of pixel columns: 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110 = 11 columns. If the ROI boundary sits between pixel columns, i.e., starting at "100.5" and ending at "110.5", you have the specified 10 pixels columns: 101, 102, 103, 104, 105, 106, 107, 108, 109, 110 = 10 columns.
Another possibility is that the left boundary sits on the start column and the right boundary sits next to the last column.
Still not sure I understand how this works. Where is the ROI boundary?
Thanks!
04-13-2010 10:47 AM
04-16-2010 08:59 AM
Thanks, Tejinder.
Another question: If I have a ROI starting at 100, 10 pixels wide going from 100 to 109, and another starting at 110 and going to 119, why does the Label function treat these as a single ROI and not two distict ROI's?
04-19-2010 02:51 PM
Which VI you are talking about? Do you mean the IMAQ Label VI?
If so, that particular VI doesn't have anything to do with ROI. It applies a unique grayscale value to all pixels composing the same group of pixels (a particle).
If this is not exactly what you were talking about, let me know.