LabVIEW's 256-Color VI Icon Colormap?

[Justin Goeres]

I've been scrubbing over the color picker in the LabVIEW Icon Editor and have noticed something. When you use the color picker in the Icon Editor, even though your monitor displays a ton of colors, LabVIEW restricts what you can pick.

Along the "greys" bar at the top, there are actually only 11 unique RGB values you're allowed to get at. They are:

Grey RGBs

(0,0,0)

(17,17,17)

(51,51,51)

(68,68,68)

(102,102,102)

(119,119,119)

(153,153,153)

(170,170,170)

(204,204,204)

(221,221,221)

(255,255,255)

Likewise, in the "muted" & "saturated" areas (stealing my terminology from Christina), my manual scrubbing so far indicates that you're limited to any combination of the following hues:

Saturated & Muted RGBs

R: 0/51/102/153/204/255

G: 0/51/102/153/204/255

B: 0/51/102/153/204/255

If we calculate all the possible RGB colors we can select from these, we get 6³ = 216. Adding in the grey shades that weren't already duplicated in that calculation, we get a total color palette of 216 + 5 = 221 valid LabVIEW VI Icon colors.

This raises a question: Are these all the colors we can use in LabVIEW VI icons, or are there 34 more that I'm missing? The motivation for the question is that I'm trying to dither some images for use in LabVIEW icons using an external tool, and I want to do it right (LabVIEW's color substition is rather lacking).

EDIT: I generated a colormap of all 221 colors described above, as a PNG. Each color is a block (and black is duplicated a few times), but it's all in there. Just in case anyone besides me finds it useful:

1x1:

3x3:

[PJM_labview]

Justin,

I think you can use the attached VI to get access to the LV 8-bit color map. I think the colors are the same than the one used in VI icons, although I might be wrong.

Download File:post-121-1169663044.vi

PJM

[Justin Goeres]

I think you can use the attached VI to get access to the LV 8-bit color map. I think the colors are the same than the one used in VI icons, although I might be wrong.

Thanks! I checked the RGB values of your color map against what I'd generated. Your map matches what I'd found, but you indeed have extra colors (a total of 256). It appears from a quick comparison that the extra colors come from:

(1) A few extra shades of grey.

(2) The same few extra shades of each "pure" channel (e.g. RGB (136,0,0) -- a darkish red).

However, if you actually try to locate any of those colors in the Icon Editor color picker, you can't find them! Additionally, if you manually enter the RGB values into the color picker fields, the Icon Editor substitutes a different color to the one you picked! (It looks like it picks the closest one it can find.) This leads me to believe that your palette is the "correct" one, but that for some reason LabVIEW is restricting us to the smaller set of colors 221 colors I originally found.

I even checked this programmatically. I created a rectange of (136,0,0) and set a target VI's icon to that (via property node). When I open the VI's icon in the Icon Editor, however, the rectangle's color isn't (136,0,0), it's (153,0,0)!

It's all kind of weird.

EDIT: Here are the colors that you have in your map, but that you can't actually use in VI icons:

(Note that the last 5 elements of the last row are black and shouldn't really be there. They're just an artifact of reshaping the array so it's prettier. There are 35 extra colors total.)

[Grampa_of_Oliva_n_Eden]

Thanks! I checked the RGB values of your color map against what I'd generated. Your map matches what I'd found, but you indeed have extra colors (a total of 256). It appears from a quick comparison that the extra colors come from:

(1) A few extra shades of grey.

(2) The same few extra shades of each "pure" channel (e.g. RGB (136,0,0) -- a darkish red).

However, if you actually try to locate any of those colors in the Icon Editor color picker, you can't find them! Additionally, if you manually enter the RGB values into the color picker fields, the Icon Editor substitutes a different color to the one you picked! (It looks like it picks the closest one it can find.) This leads me to believe that your palette is the "correct" one, but that for some reason LabVIEW is restricting us to the smaller set of colors 221 colors I originally found.

I even checked this programmatically. I created a rectange of (136,0,0) and set a target VI's icon to that (via property node). When I open the VI's icon in the Icon Editor, however, the rectangle's color isn't (136,0,0), it's (153,0,0)!

It's all kind of weird.

EDIT: Here are the colors that you have in your map, but that you can't actually use in VI icons:

(Note that the last 5 elements of the last row are black and shouldn't really be there. They're just an artifact of resizing the array so it's prettier. There are 35 extra colors total.)

I do not have any more answers but another Q

The non-0 and 255 values are factors of 51.

THe 256 color values must also map to the 16 color version.

Like I said, more Q's an A's.

Ben

[Justin Goeres]

Ben,

I noticed similar things (and actually, 0 and 255 are multiples of 51 also ) when I decomposed PJM's and my colormaps into their RGB values.

Every valid channel value is some multiple of 17. This is slightly, but not entirely, surprising because 255 / 17 = 15 (which is hex 0xF). It's basically the equivalent of taking a 24-bit colorspace (8 bits per channel) and dropping the least 4 significant bits for each channel to get down to a 12-bit (4096) colorspace, then dropping a few more colors to get down to 8-bits-worth (255) in total.

I have a hunch that the 8-bit colorspace LabVIEW is using might be some kind of very standard one, but I don't know enough about this kind of thing to just come out and claim that . And then for icons they're just using a further subset of it.

FYI, the 16-color and B&W icon versions in the Icon Editor impose their own restrictions on the colors you can choose, as well. 16-color is (of course) a subset of the 256-color, and it's particularly humorous to use the color picker while editing a Black & White Icon (does anybody even do that anymore???).

[eaolson]

I have a hunch that the 8-bit colorspace LabVIEW is using might be some kind of very standard one, but I don't know enough about this kind of thing to just come out and claim that . And then for icons they're just using a further subset of it.

It looks like they're pretty much using the web-safe, 216 color pallete. There's a fantastic representation of it here.

Which makes me think: would it be possible to exchange the color picker in the icon editor with something more useful, much like how Mike Balla's Icon Editor can be dropped into the right location to use instead of the default one? There's not a lot of reason to have a color picker with millions of colors if it only lets you use a few of them.

[Justin Goeres]

It looks like they're pretty much using the web-safe, 216 color pallete. There's a fantastic representation of it here.

Aha! That's it, then (plus 5 colors??). Thanks!

Which makes me think: would it be possible to exchange the color picker in the icon editor with something more useful, much like how Mike Balla's Icon Editor can be dropped into the right location to use instead of the default one? There's not a lot of reason to have a color picker with millions of colors if it only lets you use a few of them.

It depends on where the limitation is being enforced. If it's actually the _editor_ that's doing the color substition, then maybe such a thing would be possible. But if the substitution is happening when LabVIEW itself stores the icon bitmap, then I think we'd probably always be at its mercy.

Perhaps someday NI will just give us support for glorious 24-bit (no, make it 32-bits with an alpha channel!) icons for our VIs.... :thumbup: .

[Ton Plomp]

Perhaps someday NI will just give us support for glorious 24-bit (no, make it 32-bits with an alpha channel!) icons for our VIs.... :thumbup: .

Now we allready have that alpha channel! (does anyone know the color code of transparent) is that just plain 0x00?

Ton

[martin@aerodynamics]

Now we allready have that alpha channel! (does anyone know the color code of transparent) is that just plain 0x00?

Ton

Transparent is: x1000000

[Justin Goeres]

Transparent is: x1000000

Yes, but that's outside the 8 bits of space in the color map for the icons. Icon transparency is done by masking the 8-bit icon with (the envelope of) the 1-bit icon if I recall correctly.

What I was talking about is full RGBa 32-bit color. That's 8 bits of alpha instead of just 1 like the "T" gives us now.

Not that there aren't a lot of other things I'd like to see fixed/added in LabVIEW before that, of couse!

EDIT: Before someone else points it out, if I'm not mistaken we do have full RGBa color on PNGs when we use them as decorations. I don't have time to test out exactly where else we might or might not have that, but that's at least one place.

[crelf]

...make it 32-bits with an alpha channel!) icons for our VIs

Now you're talkin' :thumbup:

[martin@aerodynamics]

Ok I left the 8 bit...

Anyway if you convert transparent to a 8 bit pixmap, then it's 0... (but that's also white...)

[robijn]

Do the special colours like "Text", "Thermometer fill", "Slide fill" etcetera maybe occupy the remaining space in the 256-colour palette ? As well as "transparent" maybe ?

Joris

[martin@aerodynamics]

I've been scrubbing over the color picker in the LabVIEW Icon Editor and have noticed something. When you use the color picker in the Icon Editor, even though your monitor displays a ton of colors, LabVIEW restricts what you can pick.

If we calculate all the possible RGB colors we can select from these, we get 6³ = 216. Adding in the grey shades that weren't already duplicated in that calculation, we get a total color palette of 216 + 5 = 221 valid LabVIEW VI Icon colors.

This raises a question: Are these all the colors we can use in LabVIEW VI icons, or are there 34 more that I'm missing? The motivation for the question is that I'm trying to dither some images for use in LabVIEW icons using an external tool, and I want to do it right (LabVIEW's color substition is rather lacking).

I made a test with all possible ICON colors (by programmatically generate and read ICONS)

=> there are "just" 221 colors

I will replace the color box of my Icon editor with a new customized colorbox which allows only to choose from the possible 221 colors...

[Rolf Kalbermatter]

It looks like they're pretty much using the web-safe, 216 color pallete. There's a fantastic representation of it here.

Which makes me think: would it be possible to exchange the color picker in the icon editor with something more useful, much like how Mike Balla's Icon Editor can be dropped into the right location to use instead of the default one? There's not a lot of reason to have a color picker with millions of colors if it only lets you use a few of them.

No not exactly. The 256 color palette LabVIEW uses actually comes from the Macintosh as a lot of other things that are in LabVIEW since version 3 :-).

That this color palette closely correlates witht the web standard does basically just show that Apple as so often had a bit of foresight when doing their user interface guidelines.

That or they had a secret time machine and just stole all the things that got later standards:-)

Yes, but that's outside the 8 bits of space in the color map for the icons. Icon transparency is done by masking the 8-bit icon with (the envelope of) the 1-bit icon if I recall correctly.

Yes icons in itself have no transparency. The tranparency is done by a mask and this mask is in LabVIEW automatically computed from the BW icon. With a resource editor that understands LabVIEW's file format (in older LabVIEW versions you could simply use a Macinbtosh resource editor on the Mac version of LabVIEW) you could manipulate that mask to use something different than the automatically computed mask.

EDIT: Before someone else points it out, if I'm not mistaken we do have full RGBa color on PNGs when we use them as decorations. I don't have time to test out exactly where else we might or might not have that, but that's at least one place.

Any bitmap in LabVIEW can have 24 bits. And for importet bitmaps that are only imported to be placed on the front panel for instance, LabVIEW even allows transparency (GIF, PNG). Last time I looked (LabVIEW 7) the Picture Control itself did not support an Alpha channel (32bit bitmaps).

Rolf Kalbermatter

[martin@aerodynamics]

I will replace the color box of my Icon editor with a new customized colorbox which allows only to choose from the possible 221 colors...

Customized Color Box....

(will be implemented into my Icon editor soon...

Yes icons in itself have no transparency. The tranparency is done by a mask and this mask is in LabVIEW automatically computed from the BW icon. With a resource editor that understands LabVIEW's file format (in older LabVIEW versions you could simply use a Macinbtosh resource editor on the Mac version of LabVIEW) you could manipulate that mask to use something different than the automatically computed mask.

Actually the transparency is made by "overlaying" all 3 Icons (not just BW) ("256" Colors, 16 Colors, and BW)...

So if on the border of the overlayed Icon is white, then will this part showed as transparent....

In the default LabVIEW ICON Editor, it is not possible to make a complete transparent Vi.

But if you set the ICON programatically, you can make invisible Vi's...

(the invisible Vi's ar only shown in the Vi- Hirarchie, so you can wind up somebody )

[Rolf Kalbermatter]

Actually the transparency is made by "overlaying" all 3 Icons (not just BW) ("256" Colors, 16 Colors, and BW)...

Argh! I forgot about that. They changed that with I think LabVIEW 7. Before only the BW icon was used to compute the transparency mask.

Rolf Kalbermatter

[Ton Plomp]

In the default LabVIEW ICON Editor, it is not possible to make a complete transparent Vi.

If I remember we did that recently...

The only way to find them is using executed highlighting....

Ton

[Justin Goeres]

Any bitmap in LabVIEW can have 24 bits. And for importet bitmaps that are only imported to be placed on the front panel for instance, LabVIEW even allows transparency (GIF, PNG). Last time I looked (LabVIEW 7) the Picture Control itself did not support an Alpha channel (32bit bitmaps).

As a follow-up to this, here's an example of a 32-bit (RGBa) PNG image:

on a LabVIEW (8.2) front panel (1) as a decoration, and (2) loaded into a Picture Control.

As you can see, the decoration handles the alpha channel just fine. But the picture control appears to be thresholding it to a single transparency bit.

[martin@aerodynamics]

As a follow-up to this, here's an example of a 32-bit (RGBa) PNG image:

...But the picture control appears to be thresholding it to a single transparency bit.

This behaviour is described in the Vi description of the used vi ...

The Read png File.vi has an Input for Transparency...

So you can select the level of transparency- and that's just on/off ...

[Justin Goeres]

This behaviour is described in the Vi description of the used vi ...

And now you know about the rocky on-again/off-again relationship I have with documentation

[PJM_labview]

As a follow-up to this, here's an example of a 32-bit (RGBa) PNG image:

on a LabVIEW (8.2) front panel (1) as a decoration, and (2) loaded into a Picture Control.

As you can see, the decoration handles the alpha channel just fine. But the picture control appears to be thresholding it to a single transparency bit.

Fortunately, NI was nice enough to leave all the alpha infomation in the image data coming out of the read PNG, so it is possible to write your own draw flatten pixmap which can handle this. The end result is that it is possible to simulate alpha blending in a picture control (see attached screenshot).

Note: This will only allow to do alpha blending within the picture control. This does not provide alpha blending from the picture control with other objects on the front panel.

PJM

[Aristos Queue]

I've been scrubbing over the color picker in the LabVIEW Icon Editor and have noticed something. When you use the color picker in the Icon Editor, even though your monitor displays a ton of colors, LabVIEW restricts what you can pick.

I asked Greg about this...

The color picker was given the ability restrict colors to the 8 bit resolution. We toyed with decimating the colors to show which ones were discrete, but it just looked odd. Anyway, the color picker's 8 bit mode uses the LV 6x6x6+5 color cube which closely matches what HTML later adopted. This gives a decent distribution with the familiar color picking mechanisms.

This is not the limit of the icon's color table though. I think that we use the original Mac color table of 256 distributed colors. This color table is implicit to an icon and isn't saved in the icon, therefore can't be customized for a given icon.

The function that does the mapping is DColorToMIndex(). It uses the gH8BIT table that is loaded from the resources in lvinit. It was to limit us to a 5x5x5+4 table to cooperate better with other apps on XWindows.

It might be worthwhile to copy/paste the table into a post. This will let him give the image converter the LV table and the dither algorithm can minimize the errors.

Greg McKaskle

The aforementioned gH8BIT table isn't just a static table in the code. It's built on launch, so I can't just cut/paste it out. Maybe if I get ambitious.

[eaolson]

The color picker was given the ability restrict colors to the 8 bit resolution. We toyed with decimating the colors to show which ones were discrete, but it just looked odd.

I noticed the whole "Icons have a limited pallette" thing a few months ago, and found it incredibly frustrating. I selected my color, went back to the icon editor, started using it, and my icon just didn't look right. So I went back to the color picker, thinking I'd grabbed the wrong color, started using it again, and it still didn't look right. I finally managed to find something that looked acceptable, and gave up trying to figure out what was going on. The frustrating part was that the color picker dangles all those colors in front of you, but whisks them away when you get back to the editor, without mentioning that it had changed your selection. It's not mentioned in the documentation, either.

Why the 256ish color limit in the icons, anyway? Does it just harken back to archaic times when we had 8-bit monitors and, darn it, we were glad to have that?

[Rolf Kalbermatter]

I noticed the whole "Icons have a limited pallette" thing a few months ago, and found it incredibly frustrating. I selected my color, went back to the icon editor, started using it, and my icon just didn't look right. So I went back to the color picker, thinking I'd grabbed the wrong color, started using it again, and it still didn't look right. I finally managed to find something that looked acceptable, and gave up trying to figure out what was going on. The frustrating part was that the color picker dangles all those colors in front of you, but whisks them away when you get back to the editor, without mentioning that it had changed your selection. It's not mentioned in the documentation, either.

Why the 256ish color limit in the icons, anyway? Does it just harken back to archaic times when we had 8-bit monitors and, darn it, we were glad to have that?

Yes! The icon resource format used by LabVIEW originates from the original Macintosh OS icons. They have no explicite color table but instead use the application color table initialized by an application at startup and LabVIEW simply adopted that idea and ported it to all platforms. Changing that now would be a bit of a difficulty although I guess they could add a new million colors icon format to the internal resource table.

But that would be a lot of work since quite some low level routines would have to be updated and retested (where I think the LabVIEW developers would rather not use that resource format anymore if they could), the icon editor would have to be seriously overhauled, quite a bit of bitmap handling would have to be adapted to support that new icon format and last but not least the color picker tool itself would need to be taken care of too.

And I have some feeling that there are quite a lot of other projects on the todo list that have a higher priority and would require less work to do than this and with a lot less risk to break existing code.

I do think that the original color picker from older LabVIEW versions which had the actual colors in the 6*6*6 matrix was better for the icon format but they had to update it to support the color box which could take millions of colors.

Rolf Kalbermatter