image acquisition at high fps

[Franzi Ki]

Hi everyone,

I want to take images with my Basler acA1300-200um camera at 50 to 100 fps and save them numerated. My problem is that I cannot reach the fps if I am taking and saving the images simultaneously (in one loop).

I have read about that topic and one proposed solution is the producer/consumer scheme, which has no improvement for my VI. Does anyone know, how I can decouple the acquisition from the saving or how I can store the images temporarily in the RAM?

 

Thanks

[infinitenothing]

9 hours ago, Franzi Ki said:

Hi everyone,

I want to take images with my Basler acA1300-200um camera at 50 to 100 fps and save them numerated. My problem is that I cannot reach the fps if I am taking and saving the images simultaneously (in one loop).

I have read about that topic and one proposed solution is the producer/consumer scheme, which has no improvement for my VI. Does anyone know, how I can decouple the acquisition from the saving or how I can store the images temporarily in the RAM?

 

Thanks

Here's an example of using producer consumer. If you have a solid state hard drive or a RAID disk, something like this should work. You'll notice there's two places we're storing images in memory. The "number of buffers" and the "max queue size". In this example, we'd primarily increase the max queue size to store more in "RAM". IMAQdx already decouples acquisition for you so another option (not shown) is to increase the "number of buffers".  While you were saving the image (where the enqueue is now), IMAQdx would be filling the next buffer in parallel. The only caveat is that IMAQdx uses a lossy buffer so you would have to monitor buffer number out to make sure you don't miss any frames.

[smithd]

There are some examples for imaq with worker threads, I'd take a look at those.

I don't think that producer consumer will particularly help since imaq basically gives you that for free if you enable buffering in the driver. What could help is if you had N workers which would give you the ability to use all CPU cores for processing, which could allow you to write your images as PNGs (reducing image size) if your disk is the bottleneck.

I would suggest using a disk benchmark like (http://crystalmark.info/software/CrystalDiskMark/index-e.html) to see how fast you can write to disk, then determine how big your images are and how many bits, and that will tell you if your disk is the bottleneck (or if it will be, even if it isn't right now).

Also you mentioned buffering in ram. If this is a finite acquisition then I'd definitely look into that. Maintain a set of N imaq references and use a new reference for each incoming frame. However at 100 fps thats a lot of memory.

[Franzi Ki]

7 hours ago, smithd said:

There are some examples for imaq with worker threads, I'd take a look at those.

I don't think that producer consumer will particularly help since imaq basically gives you that for free if you enable buffering in the driver. What could help is if you had N workers which would give you the ability to use all CPU cores for processing, which could allow you to write your images as PNGs (reducing image size) if your disk is the bottleneck.

I would suggest using a disk benchmark like (http://crystalmark.info/software/CrystalDiskMark/index-e.html) to see how fast you can write to disk, then determine how big your images are and how many bits, and that will tell you if your disk is the bottleneck (or if it will be, even if it isn't right now).

Also you mentioned buffering in ram. If this is a finite acquisition then I'd definitely look into that. Maintain a set of N imaq references and use a new reference for each incoming frame. However at 100 fps thats a lot of memory.

I had a look on how fast I can write to disk and this could be a bottleneck, if I want to reach the 100 fps, but at the moment, the Frame rate is limited to 9 - 10 fps. So this could not be the problem, now. I am already writing my images as PNGs.

What do you mean with "N workers"?  and how could it look like, if I create for each frame an new reference, I cannot imagine this.

Thanks for your help!

 

19 hours ago, infinitenothing said:

Here's an example of using producer consumer. If you have a solid state hard drive or a RAID disk, something like this should work. You'll notice there's two places we're storing images in memory. The "number of buffers" and the "max queue size". In this example, we'd primarily increase the max queue size to store more in "RAM". IMAQdx already decouples acquisition for you so another option (not shown) is to increase the "number of buffers".  While you were saving the image (where the enqueue is now), IMAQdx would be filling the next buffer in parallel. The only caveat is that IMAQdx uses a lossy buffer so you would have to monitor buffer number out to make sure you don't miss any frames.

 

Unfortunately, this example did not help me, the increasing of the max queue size did not show any effect on my frame rate.

But thanks for your help!

[smithd]

PNG conversion takes a long, long time so you should use the imaq image to string functions to see if the png conversion is taking a while with your particular images. I found that the quality setting didnt help performance much but you can try it (pngs here are lossless so its quality of compression).

if your drive is a spinning disk you must not write each image to its own file, you must pack the images into a single file and unpack later. Overhead for making files on a rust drive is killer, probably cut my throughput by a factor of 8. I made an in memory zip creator for this purpose but unfortunately i cannot share it. You can do much the same by creating png strings and writing them to a binary file. For an ssd this isnt an issue.

The worker thread is same as producer consumer but with N (1/cpu here) consumers to each producer. You can do this with 'start asynchronous call', a parallel for loop, or just dropping down several copies of the same function.

[infinitenothing]

4 hours ago, Franzi Ki said:

Unfortunately, this example did not help me, the increasing of the max queue size did not show any effect on my frame rate.

But thanks for your help!

How did your program exit? Did the enqueue timeout? If not, the rate is probably limited by the camera. If so, your rate is limited by your disk. Are you using a laptop? You can get an SSD for <$300.

How big did you increase the queue size. If you use 64 bit labview and have tons of memory, you should be able to store all those images to memory.

Actually, how are you benchmarking your frame rate? I would benchmark it in the top loop and output the delta t to a chart so you can see if it goes fast while you are using memory.

[Franzi Ki]

19 hours ago, smithd said:

PNG conversion takes a long, long time so you should use the imaq image to string functions to see if the png conversion is taking a while with your particular images. I found that the quality setting didnt help performance much but you can try it (pngs here are lossless so its quality of compression).

if your drive is a spinning disk you must not write each image to its own file, you must pack the images into a single file and unpack later. Overhead for making files on a rust drive is killer, probably cut my throughput by a factor of 8. I made an in memory zip creator for this purpose but unfortunately i cannot share it. You can do much the same by creating png strings and writing them to a binary file. For an ssd this isnt an issue.

The worker thread is same as producer consumer but with N (1/cpu here) consumers to each producer. You can do this with 'start asynchronous call', a parallel for loop, or just dropping down several copies of the same function.

Thanks, I will have a look on this.

17 hours ago, infinitenothing said:

How did your program exit? Did the enqueue timeout? If not, the rate is probably limited by the camera. If so, your rate is limited by your disk. Are you using a laptop? You can get an SSD for <$300.

How big did you increase the queue size. If you use 64 bit labview and have tons of memory, you should be able to store all those images to memory.

Actually, how are you benchmarking your frame rate? I would benchmark it in the top loop and output the delta t to a chart so you can see if it goes fast while you are using memory.

I increased the queue size more and more, but I checked the VI again and found a small mistake and afterwards I reached the 100 fps... It helps to save it as an array, now I have to check, how I will continue with this data type. But many thanks!!!

I already benchmark the frame rate in top loop trough the delta t.