LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Flattened pixmap mask description wrong for small images -- Bug?

I've been working with images loaded from disk lately, and it seems to me the description for the mask element of the flattened pixmap cluster is incorrect when the image size is small. The online help reads:
mask is an array of bytes in which each bit describes mask information for a pixel. The first byte describes the first eight pixels, the second byte describes the next eight pixels, and so on. If a bit is zero, LabVIEW draws the corresponding pixel as transparent. If the array is empty, LabVIEW draws all pixels without transparency. If the array does not contain a bit for each pixel in the image, LabVIEW draws any pixels missing from the array without transparency.
So there should be one bit in the mask for each pixel. Here is what I'm getting:

image size   # pixels    mask length, bytes (bits)
1x1               1            2   (16)
1x2               2            2   (16)
2x2               4            4   (32)
4x4              16            8   (64)
8x8              64           16  (128)
9x9              81           18  (144)
32x32          1024          128 (1024)
33x33          1089          198 (1584)


It looks like there are two issues here. One, the mask array works on rows of pixels. If the row does not end on a byte, the byte is padded on the right with zeros until the end, then the next row starts. E.g., for the 9x9 image, pixel #9 is byte 2, bit 8; byte 2 is padded with zeros; pixels 10-18 start with byte 3.

Two, for some reason small images (i think 8 pixels per row or less, but I'm not sure) have every other byte a zero. For example, here is the mask for my 4x4 test image, with every pixel opaque:
   11110000 00000000 11110000 00000000 11110000 00000000 11110000 00000000
According to thel help text, the mask array should be 2 bytes long, with every bit a 1.

It seems to me that the first issue is likely intentional, and the help text just isn't entirely clear. The second issue, I'm not sure about. Maybe it was just assumed that pictures would be large and small pictures wouldn't be used?
0 Kudos
Message 1 of 6
(3,676 Views)
There are some allignment bytes added to each line of the mask, to force each line to be an even number of bytes. This is indeed called "padding" and it's quite usual in image formats.


The help is just a desciptive text, not a specification. So it's no bug, it's just how it is...


I'm not sure what the first and the second issue is... Each row is 16 bit padded, that is the only issue.


Regards,


Wiebe.
Message 2 of 6
(3,656 Views)

Wiebe is correct that every line of the image gets an even number of bytes in it mask.

The help was misleading, I agree. I have reported this confusion as a bug in the documentation (I do not remeber to CAR#) so it can be explained better.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 6
(3,650 Views)
All,
I believe this issue was reported to R&D with a CAR number of 460D5900. Just to let you know...
 
 
Chris C
Message 4 of 6
(3,637 Views)

wiebe@CARYA wrote:
I'm not sure what the first and the second issue is... Each row is 16 bit padded, that is the only issue.


Oh geez, since mask is an array of U8s, it never ocurred to me it would be padded out to 16 bytes. I just kept seeing them as "extra" bytes. I wonder why the array wasn't made as an array of U16s, then? Anyway, thanks for pointing that out.

0 Kudos
Message 5 of 6
(3,619 Views)

This was reported to R&D  (460D5900) for further investigation. Thanks again for the feedback!

 

Chris C

0 Kudos
Message 6 of 6
(3,581 Views)