How to average a 3D array into a 2D array in the fastest way?

[Wiebe@CARYA]

Could you post a vi with a 3d array as constant, or control with default value set? It will save us some time, and confusion about which array index is X, Y or Z...


It doesn't have to be a meaningfull picture, or full size picture.


For me in LV7.1, but others can use 8.2


Regards,


Wiebe.
"ccyang" <x@no.email> wrote in message news:1161798011721-432402@exchange.ni.com...
Thanks Kevin, your help is great. For my image, X means the number of rows, which is usually 512 or 256. Y means the number of columns, which is usually 5 to 10. Z means the number of images or frames per target, which may really varied from target to target. The numbers of X and Y will be determined before running the camera, and the number of Z will be determined by how big the target is. when the target comes, the camera will start to shoot the images automatically, and it will end automatically when the target leaves. Do you think the information is sufficient? Thanks a lot for your effort.

[wiebe@CARYA]

Hi,

This VI runs in about 0.11 - 0.15 sec. on my ancient 800 MHz PII. Should do much better on your PC (hopefully you'll have a 3 GHz dual core for this fancy graphics stuff).

The indices of all arrays can be rearanged, without speed penalty, to suit your needs.

Regards,

Wiebe.

[Wiebe@CARYA]

"Wiebe@CARYA" <wiNOebe.walsSPtra@carAMya.nl> wrote in message news:454069d2$1@PYROS.natinst.com...
Could you post a vi with a 3d array as constant, or control with default value set? It will save us some time, and confusion about which array index is X, Y or Z...


It doesn't have to be a meaningfull picture, or full size picture.


For me in LV7.1, but others can use 8.2


Regards,


Wiebe.
"ccyang" <x@no.email> wrote in message news:1161798011721-432402@exchange.ni.com...
Thanks Kevin, your help is great. For my image, X means the number of rows, which is usually 512 or 256. Y means the number of columns, which is usually 5 to 10. Z means the number of images or frames per target, which may really varied from target to target. The numbers of X and Y will be determined before running the camera, and the number of Z will be determined by how big the target is. when the target comes, the camera will start to shoot the images automatically, and it will end automatically when the target leaves. Do you think the information is sufficient? Thanks a lot for your effort.


Btw.


You haven't said anything about the data type of the 3D array. Is it U8 (grayscale)? Or 3 RGB U8's inside a U32? Or is it an U8 index to a RGB color table?


The "3D Array Average" VI I send in the parrallel message only works if the value is really a value. It doesn't work if the information has RGB information inside a U32, or if it is an indexed value. Still a few CPU cycles left to do conversion, so just let us know.


Regards,


Wiebe.

[ccyang]

Thanks a lot to Kevin! I spent many a little bit long time to understand your program, so I reply late. I think your code solve my problem. And thank you Weibe for your concern. My camera gives me F32 or I32 inputs, depends on the user's need. Thank you again, friends!

[Kevin_Price]

Well, giving credit where credit's due...

Wiebe is the one who posted his code, not me.  I'd been goofing with an example that used a queue to pass from a simulated image acq loop to a separate averaging loop, but didn't post.  Because of that extra stuff, it would probably add more confusion than clarity.

Note too that his example handles a 10x256x512 array.  I'm not sure how his arrangement of X,Y,Z corresponds to your imaging driver, but in terms of sheer size this would be like Z=256 frames to average.  (You had X,Y at 512, 10).  In my fiddling around, I was trying no more than Z=30 (1 second at typical U.S. frame rate).  I'm guessing that your Z is much smaller than what Wiebe benchmarked and that you'll be able to meet your speed requirements.

-Kevin P.

[ccyang]

Thank you very much Weibe, and thank you Kevin for reminding me of my typo. Both you give me a lot of help, I am coding my program and hope it works this time. The fundamental problem is that I am converting my MATLAB code to LabView one, and we all know how terrible it is to jump from one platform to another. When I get into another challenge, I will post it again, and wish I can hear both your kindly and essential advices again. Thank you.

[Matt_W1]

If speed is still an issue here's a faster/simpler version of what wiebe posted. It's about 3 times faster for me on Labview 8.2.

Message Edited by Matt W on 10-27-2006 03:16 PM

Message Edited by Matt W on 10-27-2006 03:16 PM

[ccyang]

Thanks a lot, matt. I think your idea is also very good. I am testing it. Thank you again for your suggestion.

[arvmenon]

Fellas,
Thank you very much for this awesome post.

Arvind.

[altenbach]

All other things being equal, I would go with the solution with the least amount of code. (=mine ;))

Here are three solutions (Wiebe (slightly modified), Matt, and mine) benchmarked. Mine uses the fewest amount of code and is comparable to Matt's solution. Simple code is easier to debug. 😄

Wiebe: Your benchmark is completely meaningless, because the entire calculation is folded into a constant and calculated at compile time exactly once and then never again. You need at least one of the dimensions as a control. Also, the indicator belongs outside the timing frame, because you don't want to possibly partially measure the updating of the indicator.