Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Max continuous fps using imaq and LabVIEW

We are investigating the possibility of an application that would use a high speed camera like the Basler A504k, with a very small ROI and extremely high fps.  For example, the camera can do 10 k fps at small ROI.  We would use a low level ring for continuous acquisition in labview.  But in thinking about this system we are concerned  about fundamental limits for max fps in labview due to a) overhead associated each imaq extract buffer call and b) does labview have any practical limits (besides RAM) on the number of image buffers allowed? (we would probably need 10,000 images for a 1 second buffer at 10 kfps).  We would use Win 7 64 and a large amount of RAM, but for a continuous acquisition, eventually you will overflow the image buffers if you can't extract them as fast as they are going into RAM.  We also realize that a large RAID drive and special file writing techniques are required to save the images - we think we have a handle of that.

 

So my questions are:

1-what is the fastest frame extraction rate anyone has done with imaq and labview? (I saw a post of a user who extracted single lines from a line scan camera at 9 khz and I am thinking this is probably the max)

2-is there any way to extract or read many image buffers form the ring at one time to bypass the overhead with each call for a continuous acquisition

2-are there any practical limits on the number of image buffers in LV?

0 Kudos
Message 1 of 15
(6,469 Views)

Hi DrMike.

 

I don't have numbers for the max practical rate for extraction but at the moment I would guess that the driver is not tuned to support very high rates. There is some amount of overhead involved in extracting each image and this adds up.

 

Your second question addresses what I was going to suggest. With a bit of knowledge of how IMAQ's ring works, you can take advantage of the fact that extracting a buffer protects the image you extracted, but also _every image after it_. Thus, if 5 images are available (N through N+4), extracting N means that N+1 through N+4 are effectively extracted as well since the hardware will not write past N since it is extracted. You could then index directly into your image buffers to access the data for the other images. With this approach it is fairly easy to reduce the number of extractions by a large amount by say always extracting images in blocks of 10 or 100 or so.

 

There is no fixed limit to the number of image buffers in LabVIEW, espeically if you go to 64-bit. Because of how the hardware and driver work, there can be a lot of overhead in allocating and setup up the image rings for lots of very small images. One way to reduce this overhead is to ensure that the image widths are 32-byte aligned and have no borders when you allocate them. This allows the hardware to DMA images much more efficently. For normal image sizes the overhead is negligible, but for small images at fast rates it can be a big difference.

 

Eric

Message 2 of 15
(6,465 Views)

Eric,

 

Can you provide any more information regarding this method?  I am currently trying to run 2 cameras at 2400fps and I think trying to extract buffers one at a time is becoming a performance limitation.

 

How do you index the image buffers directly?

 

Thanks so much!

Josh

0 Kudos
Message 3 of 15
(6,149 Views)

If you are using IMAQ drivers (not IMAQdx), you allocate an array of buffers which are used for the ring acquisition.  If you keep this array, you can just read those images directly from the array without using the Extract function.  You have to be careful and make sure you are not more than half a buffer behind the currently acquiring image.  You also have to keep track of your array index and make sure you don't go past the end of your buffer.  You can keep track of the Last Acquired Buffer or Last Acquired Index using property nodes.

 

I would make sure your buffer is fairly large.  A few seconds would be nice, just in case you get behind for a second.  One second is probably fine if you are doing fast processing that catches up quickly if it gets behind.

 

Unfortunately, IMAQdx allocates its own buffers, and you can't access them directly without using the Extract function.

 

Bruce

Bruce Ammons
Ammons Engineering
0 Kudos
Message 4 of 15
(6,146 Views)

Bruce,

 

Thanks so much for the response.  I'm guessing on this, but you're referring to the array of IMAQ images(references) that you setup when you're configuring the buffer in the for loop? Like shown here?

http://www.ni.com/white-paper/4001/en

 

so you're saying we should setup about 5000 image buffers for 2 seconds of 2400 fps data.  Maybe acquire 100 frames directly from the array with every while loop iteration then keep myself synchronized using the property nodes...

 

I'm surprised there is much of a speed difference between the 2?

0 Kudos
Message 5 of 15
(6,145 Views)

To add to Bruce's comment, I would still recommend using the Extract function because otherwise it is extremely hard to guarantee that your image data is not modified while you are processing. Without Extract you would have to do some check after your processing to see which image the driver has last acquired and invalidate your results if it turns out that your buffer had been overridden.

 

Assuming your benchmarking yields that the Extract overhead is significant enough to be a problem at your high rate, my suggestion would be something like the following:

 

Have an outer loop that extracts N images at a time (where N is less than your number of images in your ring). Extract buffer X (where X starts at 0 and increases by N every iteration). If this suceeds, you will guarantee that any images after that buffer cannot be overritten by data more than one buffer ring newer. The driver will be able to acquire into buffers X to X+(ring_size-1). You would then process your N images using the buffer number modulus ring_size and index into your image array passed into the ring setup. On each inner loop iteration you would need to poll LastAcquiredBufferNumber to ensure that the image has been acquired. Finally, you would then Release the image and increment X by N and loop again.

 

Eric

0 Kudos
Message 6 of 15
(6,139 Views)

Eric,

 

Something like this?  Doh! Just noticed the for loop doesn't have N wired...Assume I wired "# of images to extract" to the N terminal

 

Extraction.png

0 Kudos
Message 7 of 15
(6,133 Views)

That looks pretty much likje what I envisioned... The only issues would be adding an additional loop (or modifying the inner loop) so that you wait until the image is available. Your code as-is would work, but if you get ahead of the acquisition you'll stop processing any data.

 

Interested to hear how well it works for you use case!

 

Eric

0 Kudos
Message 8 of 15
(6,130 Views)

Eric,

 

It's a dual 2400 fps camera setup.  Hoping to expand it to 4 cameras at 2400 fps 640x480 resolution.  I've got 6 SSDs right now to handle writing the data and hoping to expand to 12...

 

At high image resolution it works fine (1700x1700 @ 285 FPS)..I think it is because I'm not trying to call the extract function so much.

 

For more info about the project, code, and architecture check here.

http://forums.ni.com/t5/Machine-Vision/NI-1433-high-speed-stream-to-disk-with-ring-acquisition/m-p/2...

 

Thanks for all your help.  This looks like it should be significantly faster.

Josh

0 Kudos
Message 9 of 15
(6,128 Views)

I was thinking something like this:

 

Fast Image Processing.png

 

You have to assume your image processing is faster than the acquisition, or it will bog down anyway.  I still think the Extract adds unnecessary complexity - if you get to a situation where it makes a difference, you are already a full buffer behind and you will get a processing error.

 

The 5 msec delay is to make sure there are always a few images to process.  This could be adjusted for your frame rate.  It will probably improve your CPU efficiency by processing in a burst, then freeing up CPU time for other tasks.

 

Bruce

Bruce Ammons
Ammons Engineering
Message 10 of 15
(6,123 Views)