Color to RGB and RGB to color - bug?

[Yamaeda]

Trying to optimize a image modifying part of a program i tried to parallellize an image modifying loop. It's hard to find a more fitting task for parallellisation, right?

To my surprise i gained 0 speed, and checking Color to RGB is showed to not be reentrant! Easy enough to fix, but i'd call that a bug since it shouldn't have been shipped like that.

Since the program after modifying some colors reassembles the image it also uses RGB to color, but that one is password locked, so it's stuck on non reentrant. 😞

LV2017

/Y

[GerdW]

Hi Yamaeda,

what about working with arrays of R, G and B - and use DecimateArray/InterleaveArray instead?

[IanSh]

I agree these VI's should be able to be re-entrant. I wonder why the color to RGB is password protected. Surely it is just the reverse of RGB to color. I assume you are able to just make your own color to RGB function with 3 split numbers to overcome your parallel problem.

[Yamaeda]

---

@GerdW wrote:

Hi Yamaeda,

what about working with arrays of R, G and B - and use DecimateArray/InterleaveArray instead?

---

Yes that's a workaround, just like i can write a FFT on my own, but i expect the built in functions to be good enough. 🙂

/Y

[GerdW]

Hi Yamaeda,

i expect the built in functions to be good enough.

Sure - but just for scalar values.

When working with images we often try to handle arrays - and those two RGB functions aren't polymorphic to support arrays…

On this password protected function: in older LV versions the function uses a CLFN to call a ResolveColor function in LabVIEW. And it used the UI thread to do so…

[Ben]

---

@GerdW wrote:

Hi Yamaeda,

i expect the built in functions to be good enough.

Sure - but just for scalar values.

When working with images we often try to handle arrays - and those two RGB functions aren't polymorphic to support arrays…

On this password protected function: in older LV versions the function uses a CLFN to call a ResolveColor function in LabVIEW. And it used the UI thread to do so…

---

...

and if you check the help...

"

Resolves any color input, including system colors, into its respective red, green, and blue components.

"

... we find a hint why it is not just a matter of splitting the number and what maybe a call to the OS.

If you are not dealing with System colors, just use split number cascaded since it is polymorphic and will adapt to arrays.

Ben

[paul_cardinale · Accepted solution]

Use this instead:

[JÞB]

/Y

Look at the conversion on trim whitespace.  I suspect that similar arguments may apply.  NI does make an effort to write bullet proof code that is cross platform and localized.  That can make a "roll-your-own" solution much faster in the cases you will use it.  

I've often considered writing a "95 percent" TK.  But, the documentation to claim where the functions fail is prohibitive.