vugie Posted December 10, 2008 Report Share Posted December 10, 2008 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 Quote Link to comment
shoneill Posted December 10, 2008 Report Share Posted December 10, 2008 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. Quote Link to comment
vugie Posted December 10, 2008 Author Report Share Posted December 10, 2008 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. Quote Link to comment
shoneill Posted December 10, 2008 Report Share Posted December 10, 2008 QUOTE (vugie @ Dec 9 2008, 03:25 PM) It is password-protected in my versionSplin 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 Quote Link to comment
Aristos Queue Posted December 10, 2008 Report Share Posted December 10, 2008 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. Quote Link to comment
shoneill Posted December 10, 2008 Report Share Posted December 10, 2008 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. Quote Link to comment
Aristos Queue Posted December 10, 2008 Report Share Posted December 10, 2008 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. Quote Link to comment
shoneill Posted December 11, 2008 Report Share Posted December 11, 2008 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.