Color to RGB speed issue

[vugie]

I just realized that LV "Color to RGB" function from graphics palette in unexpectably slow. I recognized with simple test that it is about 700 times slower than using Split Number function three times to get color components. There is no such issue with "RGB to Color" function.

VI with test case attached

LV 8.2.1

[shoneill]

QUOTE (vugie @ Dec 9 2008, 12:38 PM)

I just realized that LV "Color to RGB" function from graphics palette in unexpectably slow. I recognized with simple test that it is about 700 times slower than using Split Number function three times to get color components. There is no such issue with "RGB to Color" function.

VI with test case attached

LV 8.2.1

I set the VI parameters for this to "Subroutine" ages ago. That seems to speed things up a bit. Any disabling debugging and so on and so forth.

You can also cast a U32 to a cluster containing 4 U8 instead of using the sub-VI. It's actually faster if I remember correctly.

To speed things up you can also cast an array of U32 to an array of clusters with 4 U8 each and then process the data of the U8 cluster array individually.

Shane.

[vugie]

QUOTE (shoneill)

I set the VI parameters for this to "Subroutine" ages ago.

It is password-protected in my version

QUOTE (shoneill)

You can also cast a U32 to a cluster containing 4 U8 instead of using the sub-VI. It's actually faster if I remember correctly.

Splin Number based method is fastest I found. I'm going to enclose it in subroutine VI and use it further and I suggest to do so to everyone who perform extensive pixel manipulation.

[shoneill]

QUOTE (vugie @ Dec 9 2008, 03:25 PM)

It is password-protected in my version

Splin Number based method is fastest I found. I'm going to enclose it in subroutine VI and use it further and I suggest to do so to everyone who perform extensive pixel manipulation.

In LV 8.2.1 the VI isn't protected.....

May be faster for a single value, how about an array of U32 values?

Shane

[Aristos Queue]

QUOTE (vugie @ Dec 9 2008, 05:38 AM)

I just realized that LV "Color to RGB" function from graphics palette in unexpectably slow. I recognized with simple test that it is about 700 times slower than using Split Number function three times to get color components. There is no such issue with "RGB to Color" function.

System colors aren't handled by just splitting the number. The 32 bit number uses 24 bits to encode colors. The other 8 bits can encode system colors -- colors that resolve to whatever your operating system settings say they should be.

[shoneill]

QUOTE (Aristos Queue @ Dec 9 2008, 04:51 PM)

System colors aren't handled by just splitting the number. The 32 bit number uses 24 bits to encode colors. The other 8 bits can encode system colors -- colors that resolve to whatever your operating system settings say they should be.

Hmm. Interesting. I knew the 24-bit part, but this extra info on the remaining 8 bits sounds quite interesting. Is there more info on this?

Shane.

[Aristos Queue]

QUOTE (shoneill @ Dec 9 2008, 01:21 PM)

Hmm. Interesting. I knew the 24-bit part, but this extra info on the remaining 8 bits sounds quite interesting. Is there more info on this?

That's everything I know on the topic, and I don't even guarantee that it is fully correct among the various versions of LabVIEW. I know I've seen a version of that VI that had to worry about that case. Whether that was for a LV way in the past or far in the future or currently shipping, I do not know.

[shoneill]

QUOTE (Aristos Queue @ Dec 9 2008, 09:08 PM)

That's everything I know on the topic, and I don't even guarantee that it is fully correct among the various versions of LabVIEW. I know I've seen a version of that VI that had to worry about that case. Whether that was for a LV way in the past or far in the future or currently shipping, I do not know.

It must be fascinating living outside our normal time-space continuum.... :worship:

Shane.