Picture to Pixmap (8-bit input) not returning colors array

[lanmat]

I'm trying to open an image, interactively add text and a few test patterns to the image and resave it. Everything's hunky-dory except the "Picture to Pixmap" vi (v7.0) is returning a faulty image array and not returning a colors array. Here's a screen shot of the test program if you wish to see for yourself (again, LV 7.0)

[Ankita]

Hi,

You will need to use Unbundle By Name function to access the colors array. This array is part of the Image Data cluster returned by the Picture to Pixmap function. For more information please refer to Context help for Picture to Pixmap function.

Hope this helps.

Ankita

[lanmat]

Right. Those variables are included in the image data cluster on the front panel. The problem isn't accessing the colors array, but the fact that it's empty in the 'image data out' (in example above), when it's populated and correct in the 'image data in' indicator.

[Johnner]

This definitely looks like a bug to me (still there in 7.1.1), but maybe it's one that a LabVIEW developer can issue a fairly immediate fix for and post here. Perhaps someone just forgot to connect a few of the outputs in a case structure on that password-protected diagram.

To be sure we've clearly described the problem, let me resummarize it: Picture to Pixmap.vi always returns an empty "colors" array inside its "image data" output cluster, regardless what value is used as the "depth" input. This is OK behavior when the depth is 32 and there is no color table, but incorrect when the depth is anything less. With 8, for example, you expect to get a 256-element color table.

You can work around it, because I think the output color array is fixed for each color depth. It's always going to be the standard LabVIEW color palette for the image depth selected. To get the standard palette for a particular depth, you can invoke the "Get Image" method on any panel object (right-click, select Create >> Invoke Node) and look at its image data output, where the colors array is populated (see screenshot). In the worst case of no fix from NI, you could embed the shipping VI in a wrapper that updates the output cluster with the correct array.

--John

[zou]

Please be aware that the 8 bit image got this way isn't the same as the original one since the color table changed.
The difference can be dramatic. Try "Soap Bubbles.bmp" or "Coffee Bean.bmp" which located in Windows system dir.

George Zou
http://gtoolbox.yeah.net

[lanmat]

I agree.

As Johnner said above, 24-bit images obviously don't have a problem since each array element has all three 8-bit RGB values. However, I will add my opinion that there isn't quite a work around. If you take a look at the colors table of the incoming image for, say, an 8-bit image, there are indeed 256 elements in the color table. But the color table is customized to the image--for example an 8-bit grayscale image which returns a color array of 256 steps from black to white--and not the same color table recieved from the 'Get Image' invoke node (which is constant no matter what the image is inside).

So past the problem of the Picture2Pixmap.vi not returning a colors array, I'm thinking that even if it did, it would simply be the default color table that 'Get Image' returns. 'Get Image' isn't tailoring the 256 colors it outputs to the image like a normal image processing program (photoshop et al), reducing the colors down to the 256 closest colors represented. In 8-bit mode, the default color array only returns 11 gray values. Obviously that's not going to work for a grayscale image where 256 values are desired.

If you get a picture and save it as 24-bit, 8-bit color, 8-bit grayscale, 4-bit color, 4-bit grayscale, and 1-bit images, I've included a little test vi that will show the problem (hopefully) very clearly. Just open an 8-bit image, set the depth to 8 on the vi, and you'll see the test bitmap it saves is all funky since there's no color table included in the 'image data out' and the image in the 'Picture out' control has significantly fewer colors (picture out interprets the data with the default color table) in it than the 'Picture in' even though both images written to them were 8-bit to start with.

So...summary: Looking past the missing color table problem, unless a more typical graphics processing algorithm is included (to match the closest 2^1;4;8 colors) in reducing a picture control's default 24-bit information to 8, 4, and 1 bit information, even if they fix Picture2Pixmap.vi to return the color table the 'Get Image' invoke node returns, it's still not going to preserve a non 24-bit image.

[lanmat]

Just to clarify, if you take the image array from Picture2Pixmap.vi and the colors table from 'Get Image', you do get a recognizable image (proving the vi assumes it's working with the default color tables) with drastically reduced colors because of the non-tailored default 8;4;1-bit color tables.

[lanmat]

Alright.

Upon realizing NI staff might not put forth the amount of effort it would take to create real 4 & 8-bit color tables based on a given image, I decided to take at least a part of the matter into my own hands. I don't have the expertise to create a fully functional bit depth converter from any one bit depth to another due to the complexity of color matching from something with a high bit depth to something with a low bit depth(as in the case of a picture to an 8-bit bitmap).

However, I do know how to adequately match color to grayscale so I whipped up a little vi that will take image data (as output from Picture2Pixmap.vi and similar vi's) at any bit depth and convert to an 8-bit grayscale image. And since the majority of the images our group deals with are grayscale, there's no problem. I still think it wouldn't be very hard for people with software development connections to get hands on a simple full-fledged color matching bit depth converter algorithm. But in the meantime, here's one that will give you grayscale.

To use it as a go between between Picture2Pixmap.vi, make sure the bit depth is set to 24 so as to not lose any of the color (luminance) information, then apply this vi.

[lanmat]

Oops...grabbed the vi from the wrong place. Darn networked computers. 😉

[AristosQueue (NI)]

This issue came up before. I got some changes made to the documentation of this function. In the next version of LV, the help for the colors output will read as follows:

"colors is an array of RGB color values that correspond to the values in image. The value of image depth determines how LabVIEW interprets the value of this output. If image depth is 24, LabVIEW ignores this output. If image depth is 8, the array can have 256 elements. If image depth is 4, the array can have 16 elements. If image depth is 1, the array can have 2 elements. If the array is empty for any depth other than 24 bits per pixel, the image is using the default LabVIEW color palette."

Note that sentence at the end. The "default LabVIEW color palette" is an operating system dependent thing. In Windows, it is set in the Desktop properties.

I have asked internally that this get fixed and that we always output a table of colors, even when it is the default table.

Now, there is a workaround. But it is kinda weird. Attached is the VI that does it...