Get Image Subset incorrectly handles mask

[rwunderl]

This is more of an answer than a question, and it has already been filed as a bug (CAR 510218). I just hope it helps someone else who may be having this problem. I found it in LabVIEW 2012 SP1, but it has been verified up to 2014.

In the vi.lib function Get Image Subset.vi, the mask array is improperly indexed. The image width is wired to the row index, and the image height is wired to the column index. This is the reverse of what it needs to be. When reversed, the VI works [better].

Steps to Reproduce:
Mask an image using Create Mask.vi.

Take a subset of the masked image using Get Image Subset.vi.

Display the image subset using Draw Flattened Pixmap.vi.

The picture will have a mask that is incorrect.

See the attached bug test VI.

After further consideration, the bug is actually a little bit more complicated than the fix shown in the attached bug test VI. The mask is not exactly what LabVIEW explains it to be in the Help documentation. It is not just as simple as U8s with a bit per pixel, as described. It's actually a bit per pixel in byte pairs (U16) with each row of the image being an even number of bytes (hench U16). This is then padded with True values at the end of each row, if the image is not a multiple of 16 pixels wide. Therefore, when interpreting the mask array, you must consider that each row of the image is an even number of bytes (multiples of 16 bits) before you cast it to a 2D Boolean array.

The easiest way to calculate how many bytes per row is to take the number of mask bytes (the array size of mask) and divide by the number of rows in the image (image data Rectangle.bottom-Rectangle.top). This should always result in an even integer if the mask is valid. Then you have to multiply by 8 to get the number of bits per row before casting to a Boolean array and reshaping it to 2D. The fact that the mask is in multiples of 2 bytes doesn't really matter in Get Image Subset.vi, except that it does not check for a valid mask size like, say, Draw Flattened Pixmap.vi does before performing an operation.

See the attached Get Image Subset.vi for the final fix that I have implemented on my machine.

I hope this helps some folks out there. Not sure how I was the first to report this issue, but I suppose most people use the IMAQ functions instead...

[dadreamer]

This is still an issue as of LV 2020. I can't check on 2021 right now, but I'll add if there are any changes. NI used to write about CAR 510218 in the known issues, e.g. LabVIEW 2019 and 2019 SP1 Known Issues, and proposed such a workaround:

---

NI wrote:
Workaround: Swap the Dimension Size inputs of the Reshape Array in the Case Structure at the bottom of Get Image Subset.vi.

---

Which is not entirely correct as the mask size doesn't have to equal to the image size. In LV 2020's Known Issues and Bug Fixes no longer any tracks of CAR 510218. Get Image Subset VI is left as it is.

I assume, it wouldn't be so difficult to replace the original VI with your fixed version. But something went another way.

[rwunderl]

---

@dadreamer wrote:

This is still an issue as of LV 2020. ... In LV 2020's Known Issues and Bug Fixes no longer any tracks of CAR 510218.

---

Thank you for pointing this out. I also looked for the status of this some months ago, and I did not find it carried forward as a known issue.

---

@dadreamer wrote:

I assume, it wouldn't be so difficult to replace the original VI with your fixed version. But something went another way.

---

I also don't know how this was not a slam-dunk bug fix for LabVIEW 2016. Why would they leave such an obvious error in the code when a fix was already made? I put the above example together to convince NI to quickly fix the issue, and I still recall the tech support person commenting on how amazing it was that someone was actually able to fully explain the issue let alone propose a working solution. But as you say, nothing ever came of it.

Here are code snippets of the original VI and the proposed solution for anyone who's interested:

Get Image Subset.vi - Original

And the fix:

Get Image Subset.vi - Modified

---

@dadreamer wrote:

... the mask size doesn't have to equal to the image size.

---

I never considered the case where the mask size is not the same as the image size. When would this ever be the case? I presumed you would always be creating a mask using the original image. How else would you know how to reshape the mask array if not from the Rectangle value (which is shared between the image and the mask elements of the image data cluster)?

[dadreamer]

---

@rwunderl wrote:

I never considered the case where the mask size is not the same as the image size. When would this ever be the case? I presumed you would always be creating a mask using the original image. How else would you know how to reshape the mask array if not from the Rectangle value (which is shared between the image and the mask elements of the image data cluster)?

---

Yes, you are right. I meant the cases, where the mask size differs from the image size due to the alignment reasons. I personally stumbled upon these, when using my custom-made 32-bit PNG with alpha channel. I have read the file with Read PNG File VI and noticed that the mask array was already filled and its size didn't equal to both the image array size and the Rectangle dimensions. Of course, the common Get Image Subset VI did not work for me as I expected, and that fix, proposed by NI, did not help too. I started googling this issue and finally found this thread (thanks!). Your VI is working fine for me.

By the way, I saw another way of reshaping the mask array (AFAICR it's posted somewhere on these forums).

And this is to convert it back.

Seems like the (Un)flatten Pixmap VIs are able to deal with the padding elements automatically.

[rwunderl]

---

@dadreamer wrote:

---

By the way, I saw another way of reshaping the mask array (AFAICR it's posted somewhere on these forums).

And this is to convert it back.

Seems like the (Un)flatten Pixmap VIs are able to deal with the padding elements automatically.

---

Wow. The guts of those functions are quite disgusting. But from the outside, it seems like a pleasantly simple hack/solution to resizing the 1-bit mask "image" while taking into account the 16-bitness of the mask array. Thanks for pointing out this possibility. It would certainly be useful for reducing code if you needed to manipulate the mask elsewhere (beyond this Get Image Subset situation).

P.S., I filed a service request inquiring about the status of CAR 510218. It appears in LabVIEW 2019 and 2019 SP1 Known Issues, but it has been taken off of the list of "most severe and common issues" for 2020 and beyond. I hadn't noticed before that they do have a spreadsheet with all of the known issues linked to at the bottom. I now see it is still on the list. Only 44 of the 203 bugs made the headlines...

[RolfO]

Just add my solution also since i solved the problem in my own way before searching for a solution.

[billko]

---

@RolfO wrote:

Just add my solution also since i solved the problem in my own way before searching for a solution.

---

What you've added is a picture of your solution.  It would probably be more helpful if you made a real snippet or made it into a VI.