Replies: 16 comments
-
|
An alternative way would be to limit the color pallette in the Icon editor to the websafe colors. This would be less intrusive to the LabVIEW VI Format, until the VI Format supports 24bit Icons. I have cursed this feature multiple times because I was drawing some iconography for VIs using the TestStand green, which then was compressed into another green, that did not look anything like the amount of work I had put in for finding the right green. |
Beta Was this translation helpful? Give feedback.
-
|
It would also be useful to have a viewer that shows what the icon will look like when it is on a block diagram, including size (not zoomed in) |
Beta Was this translation helpful? Give feedback.
-
|
Besides this preview box? |
Beta Was this translation helpful? Give feedback.
-
|
Good catch. That's what I get for not double checking before making a post... |
Beta Was this translation helpful? Give feedback.
-
|
How is the icon stored in a VI file? Is it saved as an 8-bit, web-safe image? Or is it a different format (24 or 32-bit images)? If the icon is saved as an 8-bit image, then it makes sense for the editor to limit the color palette to compatible colors. If not, then it is recommended to see if the block diagram renderer handle the larger color palette. |
Beta Was this translation helpful? Give feedback.
-
@gregr-ni Can you please help us understand this? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
The 8-bit icon is stored as a resource, but the (24-bit) Icon Editor data is stored somewhere else in the VI. The palette includes the web-safe colors, but it also includes 4-bit ramps for greyscale, red, green, and blue. The exact palette is returned out of VI:VI Icon.Get as Image Data. Deducting duplicates, 6³ + 4*(2⁴ - 6) = 256.
Yes, those are two of the potential solutions I outlined in the OP. I think option 1 might be as simple as bouncing the 32x32 preview through VI:VI Icon.Set from Image Data and VI:VI Icon.Get as Image Data (against some dummy VI). |
Beta Was this translation helpful? Give feedback.
-
|
Here is a LAVAg post back from 2007 where Justin actually did some testing showing that the IE color picker only allows 221 colors. https://lavag.org/topic/4638-labviews-256-color-vi-icon-colormap/ |
Beta Was this translation helpful? Give feedback.
-
Rich addressed this, but to restate: The icon editor stores both 24-bit and 8-bit info in the VI but LV uses the 8-bit version for display. |
Beta Was this translation helpful? Give feedback.
-
|
Wrote a vi in LV 2023 that was able to reproduce the issue showing that the color picker changes a (0,0,136) color to a (0,0,153)
|
Beta Was this translation helpful? Give feedback.
-
|
Additional testing showed that 221 of the 256 colors are valid Vi icon colors.
|
Beta Was this translation helpful? Give feedback.
-
|
To address the saving of the 32 bit colors the ni IE bundles up all the VI icon data into a cluster.
It then send the flatten cluster to the lv_icon.lvlib:Write Icon Data to VI. which is locked.
The lv_icon.lvlib:Write Icon Data to Library.vi however is not locked and it uses the set tag function to store the flatten cluster in the VI/Library data so I assume the locked write icon data to VI does it the same way.
So the 32 bit colors are only used in the ni IE UI and not related to how the VI is shown on the block diagram. |
Beta Was this translation helpful? Give feedback.
-
|
We will split this issue into 2. We need to get further guidance on how 32 bit colors can be supported on the block diagram. |
Beta Was this translation helpful? Give feedback.
-
|
Will move to a discussion after talking about it on todays steerco meeting |
Beta Was this translation helpful? Give feedback.
-
|
Mark Balla's Next steps from our steerco meeting:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
You can go for a long time as an advanced LabVIEW user without realizing that while the LabVIEW Icon Editor is 24-bit, LabVIEW icons are 8-bit (the web-safe colors, to be precise, along with some extra grays). For instance, these gradients:
are crushed into:
And you have no feedback in the Icon Editor that this is about to happen, until you click OK. (Fortunately, the Icon Editor data model is also 24-bit, so you can open it back up to fix any issues that arise.)
The most annoying situation for this sort of thing is when you want to apply a slight tint to white, or perhaps some shade of gray. You're only going to be specifically doing that (and caring about the result) with an area fill. And that's precisely where any color differences will be most notable. Perhaps the worst-case scenario is in the light violets, with significantly more blue than red, in order to maximize the misalignment with the 6x6x6 color cube of the web-safe palette: #f7efff is crushed to white, while the only slightly-darker #f2e5ff goes off in a completely-different-yet-equally-unacceptable direction.
This can also lead to trouble when you want to apply some sort of overlay with a light alpha: at the high transparency settings you tend to want, only some of the pixels will actually be any different.
Ways to potentially solve this:
Beta Was this translation helpful? Give feedback.
All reactions