ARGB to RGB, array processing performance

[Jester_v01]

I'm trying to use a 2D picture control to display rapidly changing data - I need a decent frame rate.  I'm using the Cairo graphics library to generate the bitmap I want to display and then using a dll call to LabVIEW:MoveBlock to get it to display.  The bitmap is fairly large (720x1366) but Cairo and the MoveBlock seem pretty efficient and their performance is fine.

The problem is that I need to convert the frame (a 1D array of U32, representing ARGB) to an array of U8 representing R then G then B. This is then converted to a string and sent to the 2D picture control to display.

I'm using this VI to do the conversion.

The ARGB and RGB arrays are preallocated.  However, the performance still sucks.  At the moment I'm getting about 16 frames a second and this section of my main loop is taking four times longer than everything else put together.  All I'm trying to do is strip out the alpha channel!  I've tried using masking and bitshifts rather than the split number blocks - no benefit.  I've tried pulling back the original frame as an array of U8 (A then R then G then B) and then using the decimate array and interleave array blocks to filter out the A bytes.  It was slower.

Any ideas?

Luke

[Jester_v01]

I managed to achieve a very marginal improvement by keeping a copy of the last frame's ARGB array and only converting the changed pixels, but it was pretty marginal because I still had to run the whole array to compare them.

Is there a way of getting out the indexes of different array elements for two arrays without running round a for loop - ie a block to do it?

Luke

[Jester_v01]

Further profiling reveals that the 2D picture control has got pretty lousey performance too...  Are there any smarter ways to a take an ARGB U32 array and just dump it on the screen?

[Andy.G]

Hey Jester,

Perhaps you could try and improve the performance of that loop, since that is what seems to be causing the issue. I would suggest enabling parallelism in that loop; you are able to programmatically demine the number of logical processors in your system using a LabVIEW function. This will then allow you to automatically share the iteration cycles of that loop between the processors to improve performance. To allow parallelism within a for loop right click the loop edge and select “Configure Iteration Parallelism...” this will the show a box within the loop with a “P” as seen in image. The function to determine the number of processors is called “CPU Information”.

[Jester_v01]

I'll try that - thanks!

[Jester_v01]

Nope - won't parallelise(?) because of the shift register.....  Any more ideas?  Can I rewrite the loop without the shift register? 

[Andy.G]

Hey Jester,

would it be possible to split the ARGB data across three different loops and only pulling R or G or B in seperate loops, also you could try to pre allocate the size of the shift registers using the array size function, this should improve performance.

[Jester_v01]

The array going into the shift register is already preallocated to the right size (number of pixels * 3).  The ARGB array is sized to the number of pixels.  I've tried various splitting solutions, but it seems the cost of resizing the array into a linear array so I can convert it into a string to send it to the picture control is too great. 

Here's the code in context:  The ARGB array is grabbed using MoveBlock, processed to just get the RGB values and then formatted to be sent to the picture control.  The picture control is updated after the frame blank is detected, which just about gives flicker free updating.  The slow bits seem to be processing the ARGB array and passing the array to the picture control.  I've tried grabbing the ARGB as an array of A, R, G and B (ie bytes) but this doesn't yield any speed up.  I've also tried not processing it at all and telling the picture control to expect a color depth of 32 rather than 24, and, whilst this works (not documented... Grr NI Grr)  it isn't any faster and gets the colours wrong...

All I want to do is put an ARGB array on the screen quickly... how hard can it be??

[RavensFan]

What is the speed if you typecast the U32 array to a U8, decimate it into 4 parts, interleave the 3 parts of interest.

[Darin.K]

---

@Ravens Fan wrote:

What is the speed if you typecast the U32 array to a U8, decimate it into 4 parts, interleave the 3 parts of interest.

---

I thought the same, then re-read this in the original post:

I've tried pulling back the original frame as an array of U8 (A then R then G then B) and then using the decimate array and interleave array blocks to filter out the A bytes.  It was slower.