Can I make my RGB to HSL Converter faster?

[James.M]

Hello all,

I have an RGB to HSL converter, which I found somewhere here a while ago and have altered slightly for my uses. I am running this converter on each pixel of an IMAQ image in order to do a threshold on the image based on the hue and saturation values. The rest of the threshold code doesn't take very long, but there seems to be a bottleneck at this conversion.

I know there is an IMAQ threshold VI already, but LabVIEW's way of calculating the hue and threshold is different than the way my client wants it done (unfortunately).

My problem is that the converter takes about one microsecond to process. Multiply this by approximately 200,000 pixels and you get a 200ms processing time. This is unacceptable to my client and I can't seem to figure out a workaround. Below is a screenshot of the code as well as the VI itself. I would appreciate any feedback, or suggestions to speed up this process. I am trying to compete with LabVIEW's IMAQ Threshold VI, which only takes about 20ms for the whole image.

Thank you,

James

[rolfk · Accepted solution]

This sounds like a good canditate to setup the VI for inlining. That will allow LabVIEW to do some more optimization and also cut out on the small overhead of calling a VI. Go into your VI Properties and into the Execution settings, then check the "Inline SubVI into the calling VI".

If all else fails, the only other approach I see would be to implement it inside a C code, including the surrounding double for loop to avoid having to call a single function 200000 times. However compared to inlined subVIs I really doubt you could gain a lot by that unless you are a real C algorithme virtue.

[James.M]

ROLFK,

That solved the problem! This threshold method is still not as fast as LabVIEW's IMAQ Threshold (I did not expect it to be), but now it operates much much faster. It takes abot twice as long as the IMAQ Threshold, but this is acceptable I believe.

I've seen the inline and reentrant options before, but never looked in to them, or needed the speed, until now. I will be implementing these options in the other parts of my code that run often to speed them up.

Thank you,

James

[James.M]

Also, something I just learned recently is For Loop Iteration Parallelism. I used parallelism to run half of the loops simultaneously with the other half (on my duel-core laptop). This doubled the speed and on a quad-core processor it could quadruple the speed!

[GregSands]

Couple of quick thoughts from looking at your screen shot:

1. I don't think you're supposed to nest parallel loops.  In general, making the outside loop parallel is most efficient, as each loop does the most "work".
2. Be careful of the Hue Range, which wraps around from 360 to 0.  You might want to handle the Minimum being greater than the Maximum.
3. It won't make things much faster, but if you scaled your ranges to 0-1 rather than scaling each pixel's hue and saturation, you'd have many fewer multiplies.

[James.M]

Even though I'm first seeing this many months later, thank you for the tips! 

I do handle the minimum being greater than the maximum possibility right at the source with an XControl. The user isn't even allowed to enter in unacceptable values.

Your comment about the outer parallel loop being the important one is most likely correct, seems logical anyways.

I should have thought of scaling the ranges instead of the hue/sat values myself, thanks for pointing that out.