Frame rate issue with GigE camera software

[Radman]

Hello all,

Looking for some help with optimizing my GigE camera software for controlling a B1921 Imperx camera (1952x1112). The goal of this software is to control camera functions in real-time (i.e. exposure, digital gain, frame rate, etc) and save images on command.  After reading several prior posts on similar subjects, I wrote my code using a producer/consumer structure and saved the images in binary format. The images are saved when the boolean control (save frames) is triggered making both the queue block (producer loop) and save block (consumer loop) true.  The images are dequeued from the queue and saved into a binary file. Once the file is opened successive frames are appended to the original binary file keeping all of the images in a single file. 

I have notice that the software starts to lose frames when the frame rate exceeds 20 frames/sec (frames are saved onto a SSD).  The max frame rate of the camera is 39 fps. I did check the jumbo packets size and the highest I can set it to is 9 kb. My test is to image a clock and count how many frames are collected in a given time.  For example, if I run the camera at 10 frames/sec for 30 seconds, I should have 300 frames. Are there other computer/camera settings I need to modify to save at higher frame rates?  Am I missing something in my code that might make saving images more efficient? 

Attached is the code for your review. Any help is really appreciated!

[SamiF]

Few suggestions :

- are you sure you need to read/write attributes at every iteration ?

- I am not sure your use of the queue is really efficient : a queue should enable you to send messages or in case data between 2 parallel loops and to take advantage of buffering of this data. The problem is that you enqueue always the same image reference. This means that if at some stage your recording loop is late making the queue contain 2 items : they will both contain the same image which is the latest acquired one. Actually it would be better then to have just one acquisition/recording loop, with the 100 buffers you configured with "IMAQdx Configure Acquisition" helping losing no data. There are other ways to keep 2 loops and make proper queue use, but start with a single loop it will probably be enough in your case

- You use the IMAQdx Get Image vi which basically copies the content of an image buffer to an image you provide in input. Then you use Image to Array which is not optimized. I strongly suggest you try either "IMAQdx Get Image Data.vi" or "IMAQ Image to EDVR.vi" to have a more straightforward access to raw data and avoid copies and format change.

I hope this helps,

Sami

[AmitShachaf]

I would like to comment on your using of binary file to save images.

It is not a very efficient way to save images.

You will be much better off saving the image using the IMAQ functions. 

Image format like Tiff or PNG that I would recommend are using lossless compression in the file format.

When you are saving binary data your data is not compressed.

What I do in my code is Technic that I call MegaImageFile.

I allocate memory for a large file of 100 images in my case. For you probably 10 images is better. 

Then I fill the large image with 10 images and save it to file with 

I get from every recording a series of very large images. But I am using PNG format. 

Then when you are reading the file I am separating it back to single images. 

It is more efficient way since you are using compression.  

[Radman]

Thanks for taking the time to look at my code....I will address both of your comments:

Sami:  I originally wrote this as a single loop and after reading some comments made by others I made it a dual loop since I thought that the consumer loop would be better at processing and saving the data.  I liked the function that "IMAQx get image data" since its a more direct way to get raw data and should be computationally more efficient? Unfortunately I saw no speed improvement with going to a single loop and using this function.

Amit:  when I first started working on this I had a single loop and was saving the files in a tiff format.  The issue with IMAG tiff converter is that the files can't be saved in a single file and the tiff vi has to create, open, and close the file every time a new frame is saved. A slow process when trying to save large format images.  This is what drive me to use a producer/consumer loop but utlimately saving the raw data in binary seemed to be more efficient and gave me the best saved frame rates.

[AmitShachaf]

Hi Radman,

If you stitch all the images into single large image file in memory and write this large file to disk. 

Then you are opening and closing this file only once. 

It is more programming then using the binary file like you are doing. But performance is better. 

I was also using dual loop in my application. 

I was able to save images size 640x50 16Bit  at 700 FPS into regular HD.

I think it is compares to the speed you need.

Thanks - Amit

[Radman]

This is an interesting idea....so I gather you would have the first loop generate frames and have the second loop acquire all of the frames and stich them together? After the frames are stiched than write them to a tiff file or some other format?