Machine Vision
mask bug in several IMAQ vision functions
Solved!
Some IMAQ Vision functions malfunction if you use the source image as the mask. I keep running into this bug in IMAQ Vision, some Vision functions exhibit this behavior, and some don't. It is not documented in the function descriptions. Even if it were, it would still be a bug. Example:
1. Create a U8 source image that contains some zeros and some nonzero values.
2. Wire the image into the source input and mask input of IMAQ Quantify and return the % value of the global report to see what percentage of pixels are nonzero.
The answer is wrong. If you copy the image into a separate image first, and wire the separate image into the mask input, you get the correct answer. See attached VI for edification
Cheers,
-root
Here's a picture of the block diagram of the VI I provided as an attachment in the original post.
The IMAQ Quantify VI returns, among other things, a global "area (pixels)" value and a global "%" value. The help documentation description of these values follows:
“Area (pixels) returns the analyzed surface area in pixels.
% returns the percentage of the analyzed surface in relation to the complete image.”
It turns out that the "analyzed surface area" is the image area corresponding to the pixels that are not masked in the mask image, Therefore these two particular values have nothing to do with the content of the source image. Here you can see that I have changed the source image to a picture of Abraham Lincoln.
With the mask wired up, I get a global “%” value of roughly 6.1 percent because that’s the percentage ratio of nonzero pixels in my mask to the total number of pixels in the source image. Here is a source image of all zeros. Note that you get the same global “%” value regardless of the source image.
The bug occurs when you use the source image as the mask. This function provides an efficient way to find the percentage of non zero pixels in an image, but it’s not so easy to try to figure out why the buggy vision function is always returning 100% unless you can pop over to the support forum and find a post about how to get around the bug.
Errr… oh dear, I used the naughty “b” word. I meant to say that NI should “document” the “feature” so that the user will understand the “intended behavior.” 😉
-root
I wasn't being serious when I said you guys should document the bug. I know it's cheaper to just document undesirable behavior, but seriously, you should consider fixing it instead.
Why would anyone actually want this VI to behave in this fashion? If I want the VI to analyze the whole image, I simply leave the mask input unwired, just like the Vision documentation tells me to. On the other hand, if I want to use the VI to just analyze nonzero pixels efficiently, I'm forced into making a totally unnecessary copy of the whole image, because there's a bug in the VI. Even if you guys need a temporary duplicate image in RAM to perform the operation, why would I want to have to remember to create a pointless duplicate myself outside of the VI, then immediately have to delete it on the other side of the VI to free up the memory again?
My recollection may be faulty, but like I mentioned in the original post, I recall running into this problem several times, and I think that this isn't the only Vision VI that I've seen go bananas when you try to use the source as the mask.
If anyone knows an efficient way to return the number of nonzero pixels in an image without duplicating the image in memory, please post the method here so I can mark it as a solution. I find that using IMAQ getpixelvalue in a double loop is extremely slow, even with a shift register as a counter.
P.S. Forgive me if I offend, but it seems like official national instruments responses always use fuzzy euphemisms for bugs like "undocumented behavior." I'm pretty sure that most forum users find this to be somewhat goofy. What's the deal with that?
