high speed image array

[achille]

Hi,

I have a linescan camera with frame rate of 1.5 KHz. In the MAX I have set the number of lines returned in each image to equals 20. That means that the time for capturing the 20 lines equals to 13ms (20/1500=0.013 sec).

I want the image that i am capturing every 13msec to join it with previous images. For doing this I am using the array functions. What exactly I do is:

1. Initialize at the beginning of the program an array of size 1200x1280 with zeroes values.

2. In order to keep the size of the image constant (1200x1280) at the beginning of each loop I am deleting the first 20 rows so as later to add at the end of the array the latest image        of 20 lines I have captured.

3. Use the image to array function to have the array of the latest image captured.

4. Use the insert to array function to insert the 20 lines array to the total array of 1200x1280 size.

5. Use the array to image function to transform the newly updated 1200x1280 array to an image.

The problem is that the time I need to do all this is much more than the 13 msec of the acquisition which results in overwriting buffers and finally missing images.

As I have understand the time I need to transform the 20 lines image into array and then to transform the total array to an image is much more than the 13msec between consecutive images acquisition.

Can somebody please help me? How can achieve to capture images every 13msec and at the same  time make the process described above?

I have read all the threads but I didn't manage to solve my problem.

I have attached a small code of how I was trying to do it. I am using LabView 8.2.1.

Please any comments or help is deeply appreciated.

Thank in advance 

Achille 

[achille]

I am trying to attach the code but I always receive "Unexpected error" when press post message......

This happens only when I attach file to the message... 

[OliviaC]

Hi achille,

Have you tried to increase your buffer? What is the current rate of acquisition that you can acheive? Another thing to consider is that it take time to update the front panel, especially if there is an image display. Is it an option for you to see your image outside of the timed loop?

[achille]

Dear Olivia,

Thank you for your message. I will try today to increase the number of buffers. Although I am not sure if it is going to work and I will try to explain why. Maybe I am wrong, I wish to be wrong because this project is really critical to me.

As I have written above I have to capture every 13 msec a block of 20 lines from the linescan camera. Since the time for transforming the image to array and join it with the previous acquired image is always higher than 13 msec that means to me that I will never have an equilibrium between the two jobs, acquisition and the process described above.

The program will always need more and more buffer and since the time of operation of the program is not determined, one can not predetermine the necessary number of buffers.

A second thing is concerning the display window inside the loop. The program will be used for real time inspection. Which means that I need to have a real time display of the products being scanned from the camera together with the results of the process. Otherwise I will not be able to control it.

Concerning the current situation with the camera scanning at 1500 Hz a normal acquisition last a few seconds and then I am loosing frames because there always overwritten from newer data.

Once I was present in a small exhibition and there was a guy working with the same kind of camera and the same rates of acquisition. He was using a coreco frame grabber and had a small program written in c which made the live acquisition and similar process to the one described in my first message without having any time problems and having simultaneously real time display of the image. Unfortunately I don't know his name and i can't be in touch with him for asking things. But since he did it with the coreco I don't see why is it something that can not work with labview and the pxi-1422.

I am looking forward for any help of you because as I pointed above this really a very critical project to me.

Thank you in advance for your time and any possible help.

Achille 

[BruceAmmons]

I assume your image to array conversions are taking the majority of the time.

You can do the same task without converting to an array.  Use IMAQ Image to Image.  You will need two full size buffers for this.  After each capture, copy buffer A to B using a 20 line Y offset.  Then copy the new image into the top of B with 0 Y offset.  The next time around, you copy B to A.  This will probably be much faster.

Second option would be to maintain the array in a shift register instead of converting it every time in the loop.  This will save some time since you would only have to do one array to image conversion.

Bruce

[Andrey_Dmitriev]

Agree with Bruce. Also you can do this with IMAQ Shift / IMAQ Image to Image.

Try to separate Acquisition / Processing loops with Producer/Consumer pattern (don't forget that IMAQ images transferred by references, not by values).

 If "scrolled" image is not required then you can visualize only every Nth image:

 Something like that:

Andrey.

Message Edited by Andrey Dmitriev on 04-27-2009 04:43 PM

[BruceAmmons]

Shift is a much better option, like Andrey suggests.  I had forgotten that function existed.  Now I am wondering how I did it when I had an application very similar to this one...

Bruce

[achille]

Dears Bruce and Andrey,

Thank you very much for the replies to my post. You both show me alternative options that I didn't know.

Unfortunately the problem still exist because I can't avoid transforming image to array. This is because I am using 2 subroutines for image processing which I wrote specifically for my application and are based on arrays manipulation. So the image to array function and reverse is still there and is really time consuming....

Any idea? 

[OliviaC]

Hi achille,

Did you try what Andrey suggested? The idea behind the producer/consumer loops is that one loop acquires the images while the other loop does the processing (which is image to array conversion in this case). This sort of set up allows you to acquire images faster because it doesn't have to wait for the processing of the previous peice of data to finish before acquire the next image. The latest acquired images are added to the end of a queue in the producer loop and in the consumer loop (which is always slower than the producer loop), these images will be pulled out of the queue to be converted. This way you do not lose any images and you can acquire at a faster rate.