LabVIEW
Vision ROI Inconsistency?
First time really using the Vision Add-on, and not being an imaging processing guru I am a bit perplexed by how the Region of Interest (ROI) works.There may be a valid reason for why it works this way, but I am too dense to see it.
For simplicity, assume I have a rectangular ROI. The bounding rectangle is given by pixel coordinates, xLeft, yTop, xRight, and yBottom. All of this makes sense to me. The coordinates are pixels.
I am using the function Image to Array in the snippet below. (It is just a modified example) For the image to array function, you can include a bounding rectangle that will extract the pixel values.
When you extract the data, the data includes pixels starting from xLeft & yTop to xRight -1 & yBottom - 1. Is there a reason one boundary is included and the other boundary is excluded. For consistency, I would think both boundaries would be either included or excluded. (I know I can modify the rectangle to include boundaries or exclude, I just want to know the reason why it is defined like this. Maybe so the area of the rectangle is consistent with the boundaries, that is, length*width; that is my best guess, otherwise I really don't know.)
Cheers,
mcduff
@mcduff wrote:When you extract the data, the data includes pixels starting from xLeft & yTop to xRight -1 & yBottom - 1. Is there a reason one boundary is included and the other boundary is excluded. For consistency, I would think both boundaries would be either included or excluded. (I know I can modify the rectangle to include boundaries or exclude, I just want to know the reason why it is defined like this. Maybe so the area of the rectangle is consistent with the boundaries, that is, length*width; that is my best guess, otherwise I really don't know.)
Probably the same reason you have to use different VIs to draw something in a grayscale image or a color image...
If I had to guess a reason: it was made ~20 years ago, released, and except for a recompile ~10 year ago (for parallel execution) nobody bothered to improve it.
Good luck with it... 😁
Search LabVIEW like a graph! 
I would guess it has to do with calculating the final size of an image. For example, if Left is 40 pixels and Right is 80 pixels, including both borders would get you a 41 pixel wide final image. It makes a little more sense if you think of it as "Left" and "Left plus Width".
Also, imagine you need to split the image into three subsequent areas 20 pixels wide, so your first image is Left = 0, right = 19. Your next image should be L = 20, R = 39. If the boundaries were always included, you'd have duplicate pixels shared between adjacent ROI's.
It is not limited to the ROI coords, this is the general behavior of the LV drawing functions. For example:
It chaps my hide quite a few times. When I go to draw two rectangles (0,0,a,b) and (a,0,2a,b) the shared line is always double thickness until I make the adjustment.
Plus, let's draw the same rectangle using multiple line segments
If you let Picture to Pixmap.vi automatically determine the picture bounds, it clips the right and lower edges. If you manually specify the bounds, you get what I would expect. Sigh.
This mess has been around since the dawn of time and probably falls under the 'somebody out there is relying on this behavior' umbrella. I wouldn't hold my breath for a fix.
@BertMcMahan wrote:
I would guess it has to do with calculating the final size of an image. For example, if Left is 40 pixels and Right is 80 pixels, including both borders would get you a 41 pixel wide final image. It makes a little more sense if you think of it as "Left" and "Left plus Width".
Also, imagine you need to split the image into three subsequent areas 20 pixels wide, so your first image is Left = 0, right = 19. Your next image should be L = 20, R = 39. If the boundaries were always included, you'd have duplicate pixels shared between adjacent ROI's.
That's a valid point.
I've done quite a bit of OpenCV, and I had this a few times. And image with width X height of 100 X 100 doesn't fit a ROI of 0-100 X 0-100, you have to use 0-99 X 0-99.
Somehow, to me, discovering that feels like discovering the truth, while the other way around feels like uncovering a scam.
I guess I don't like software that's trying to be clever. Not even if the intend to protect me.
It saves the user from adding all those pesky decrement operators when using coordinates. You want a region of A by B pixels with top left coordinate X,Y? Then simply add A,B to X,Y and concatenate.
Working a lot with images I prefer it.
@RamonG wrote:
It saves the user from adding all those pesky decrement operators when using coordinates. You want a region of A by B pixels with top left coordinate X,Y? Then simply add A,B to X,Y and concatenate.
Working a lot with images I prefer it.
I agree that it's sometimes convenient. But sometimes it's not.
When that's the situation, I prefer the correct implementation.
Even then, sometimes it's hard to tell what 'correct' is... Often it depends on the situation, more often it's individual preference.
In this case, I don't see the rational behind the decision. But there might be one.
It won't change anyway 😁.
(Of course a Boolean input could be added to switch. That would be a compromise. Still we can debate what the default should be. But keeping the current behavior as default for compatibility seems 'safe'.)
@RamonG wrote:
Even then, sometimes it's hard to tell what 'correct' is... Often it depends on the situation, more often it's individual preference.
Correct is whatever the definition says, the expectation can of course be different.
In the case of the OP the definition says:
No, that just means the code correctly does as defined.
The definition itself can still be wrong (, or poorly chosen, or sometimes inconvenient).
If the code does as defined, it just means this isn't a bug. And, for the record, nobody said that.
