Optimizing Camera fps to Save Images into Folder (revamped project)

[JohnnyDoe771]

Hello,

It has been some time since my initial internship but I am re-vamping this project. There were some issues left unresolved and I see that there is also still interest in this project by some other LV community members. Here is the original thread link: https://forums.ni.com/t5/LabVIEW/How-to-Optimize-Camera-Speed-fps/m-p/4052322#M1162346

Goal 1:

Currently, the code has an issue with the Queue wiring (see attached VI for current code) and this is one problem. I have a more complex version that in theory analyses the images but is not attached due to other reasons and I cant currently share that VI. For this, I only wish to capture and save images as fast as possible, and to save all of the images being captured.

The producer loop should generate the images and send them to the consumer loop. The consumer loop is meant to only save the images into a file that is predetermined. Each file gets re-created based one the "experiment number", which is really just each time it's ran for now. 

The images are still saving at "lower" speeds around 35 fps, when the camera is able to operate much much faster at default settings. 

To combat this, we created a queue function to try to save images even after the camera runs. Which worked for a moment but had issues with saving the same image over and over again. Now, there is an issue of queue wiring that I can't seem to find the problem with. Note: Goal is to run at 196 fps (or as close to as possible). One idea is to reduce the resolution slightly, but how to do this in LabVIEW but still be able to see 10um objects?

Any advice on optimizing the code and allowing the program to save all of the captured images without saving one image continuously, would help a lot!

Goal 2: is to have the original images be sent to a consumer loop that analyzes each image. My current set up to do this sends a duplicate image to the consumer loop. In my code, both "IMAQ Copy VI" and "IMAQ Write File 2 VI" have a duplicate image output that could work for this. The question is, which one may be better to use to improve the processing speed of the program?

I am using a more advanced computer and camera version than previously discussed, so optimization should (in theory) be a bit easier on computer processing capabilities. I also now have an actual PC interface card from Basler to help with this.

Thank you for any help on this, I look forward to seeing what you all think! This is also mentioned in the orginal thread (see link above) but I decided to make a new thread since it has been awhile.

Thank you!

-James

[JohnnyDoe771]

Hello,

It has been some time since my initial internship but I am re-vamping this project. There were some issues left unresolved and I see that there is also still interest in this project by some other LV community members.

Currently, the code has an issue with the Queue wiring (see attached VI for current code). I have a more complex version that in theory analyses the images (previous goal) but is not attached due to other reasons and I cant currently share that VI. 

The producer loop should generate the images and send them to the consumer loop. The consumer loop is meant to only save the images into a file that is predetermined. Each file gets re-created based one the "experiment number", which is really just each time it's ran for now. 

The are still saving at "lower" speeds around 35 fps, when the camera is able to operate much much faster at default settings. 

To combat this, we created a queue function to try to save images even after the camera runs. Which worked for a moment but had issues with saving the same image over and over again. Now, there is an issue of queue wiring that I can't seem to find the problem with. Note: Goal is to run at 196 fps (or as close to as possible).

Any advice on optimizing the code and allowing the program to save all of the captured images without saving one image continuously, would help a lot!

This summarizes goal 1.

Goal 2 is to have the original images be sent to a consumer loop that analyzes each image. My current set up to do this sends a duplicate image to the consumer loop. "IMAQ Copy VI" and "IMAQ Write File 2 VI" both have a duplicate image output that could work for this. The question is, which one may be better to use to improve the processing speed of the program?

I am using a more advanced computer and camera version than previously discussed, so optimization should (in theory) be a bit easier on computer processing capabilities.

Thank you for any help on this, I look forward to seeing what you all think! I may have to make this a separate thread though...

[Kevin_Price]

I'm not very familiar with most IMAQ stuff, so here are some more general comments:

1. Tidy up.  Wait, let me emphasize that more.  TIDY UP!!!    Bugs hide in messy code that's hard to follow.
2. It's risky to ignore error outs.  Error ins should usually be wired as well.
3. Your consumer is a greedy loop, burning CPU with no relief.  Bring your dequeue function *outside* the case structure instead of querying queue status.  (Or, send both image ref and buffer # through the stream channel by bundling them into a cluster, then moving the stream reader function outside the case structure.)
4. Though I don't know IMAQ, it seems odd to configure a bunch of buffers but then also wait for the *next* one on every Grab call.   The reason to bother with buffers is to let you retrieve the *previous* images that built up since your last iteration.

-Kevin P

[JohnnyDoe771]

Good morning Kevin,

Thank you for your reply and general help solutions! 

Changes:

• Tidied up the code and made it a bit more comprehensive, new code attached. Some spots are a lot tougher to make pretty but I tried...
• I got rid of the case structure in the consumer loop since its meant to save as the producer sends it info (all its doing is saving the images to a folder). Might be a mistake but we'll see. I couldn't justify keeping it and had a lot of open-ended wires that flagged.
• I didn't adjust "errors in" but added the "error outs" that were missing. So now its a compiled error list sent to the user when an error occurs.
• I did adjust the queue as you suggested and no errors are flagging anymore. That also fixed the bug in the consumer loop! 
• I adjusted the buffers slightly. As you mention, I definitely want to be able to use buffers so images aren't "lost" when I end the producer loop but want the consumer to keep saving the remaining images.

I was unsure how to fix the greedy loop you mentioned. I really liked the cartoon styled link you provided with it. What does an error in do??

Now, I need to test how this affects speed. (I'll post an updated average fps and image save data when I run it a few times)

I'm 100% open to any more advices/advances. Thank you!

[JohnnyDoe771]

Kevin's advice actually helped quite a bit for the queue. Currently, I am looking at speed but need to do an extra test to see if the same image is being constantly copied again.

Fps data update:

• Average fps is at 36 currently.
• The consumer is saving at exactly the same rate as the camera, which is great and shows the two are communicating (the buffered number matches the images saved).

So the code is simplified a bit but still running "slow". The camera is capable of running at 136 fps at default settings; 2464 x 512 resolution.

Questions from this:

• The camera is being completely accessed through LabVIEW, is there a way to alter the camera's AOI controls inside of LabVIEW? i.e. set a user control in the interface that would allow change to the camera resolution. I am sorting through the vision and motion tools and am having trouble finding one. If I find a working one, I'll update the code in this forum but if you guys reply before that, that would help a lot.
• What may be causing the program to run at 36 fps if the camera defaults are up to 136 fps? The PC does have a USB 3.0 PCI-Express card that is meant to keep up with this camera.

Thank you!

[JohnnyDoe771]

This is how to do it with the Measurement & Automation Explorer. https://www.youtube.com/watch?v=oTWHhMENsCg

However, is it possible to set a program on the interface so the user can more accessibly adjust the resolution?

[Bob_Schor]

To the tune of "Anything You Can Do, I Can Do Better" (thanks to Irving Berlin):

   Anything MAX can do, you can do also.  Though MAX is easier, you can do it, too.

To which you reply -- "No, I can't", and I say "Yes, you can", and it goes on for a while.

Look at how you set things in MAX.  You are basically setting Properties for the Camera to set its FPS and other parameters.  There's a way to do exactly the same thing with IMAQdx, but it is a bit complex, sufficiently so that I can't recall the process (though I did some IMAQdx work a few years ago).  But a hint will come from the names that MAX gives to the Properties (for example, looking at the integrated Web Cam on my Laptop, I see an Acquisition Mode that includes an FPS specification).

Bob Schor