04-16-2009 02:41 AM
Hi,
I can't seem to solve this somewhat basic programming logic problem: using a CCD I want to detect a color change in real time (at any FPS rate >10 FPS) and save the video with as many frames per second as the camera can give (71 FPS or as close to it as possible).
The camera is up to 71 FPS but my color detection takes too long to run one iteration of the while loop so I only get effectively 10-11 FPS in my AVI file. 10 FPS is acceptable for the detection response but ideally I would also save an AVI of the process at 71 FPS for historical record that can be further analyzed. I realize what I need is a way to quickly run the 'save to avi' on every available frame (71 FPS) and then in parallel sample 1 in every 7-8 frames for image detection processing (to get the 10 FPS the coding/CPU+RAM limits it to). I can't seem to write a program that can do the two in parallel without the color detection bogging down my save to AVI or without getting some sort of camera session invalid error.
Someone more clever and experienced please share some logic with me. My attempts with different while loops or conditional case structures just arent improving the FPS. I have attached the most basic version of my program; it achieves what I want but the FPS in this case are going to be equal in both the dection and avi.
Thank you in advance for your time and patience, I am just a student in over my head as usual....
-KR
04-16-2009 11:38 AM
Several times you talk about wanting to do things "in parallel" - LV LOVES to do things in parallel and automatically uses resources (like multiple core processors) to process things in an efficient way!
How do you do things in parallel - with parallel loops!
Easy solution for you - go to new and expand the folders in the "create new" window - find "design Patterns" and open "Producer/Consumer Design Pattern (Data)"
It may be somewhat of a bastardization but if you put your acquisition and AVI code in the producer loop you can create some logic to send an image to the consumer loop ever X images. You may want to COPY the image into a NEW reference (image references are not like data!) to avoid mucking up the image you are writing to the AVI.
Also if you feed too many images to the consumer loop they may get backed up in the queue! This is bad - study the tools in the synchronization>>queue operators palette to find ways to avoid this.
Have fun...
04-16-2009 02:57 PM
Jolt,
Thank you for your clear response. This is the sort of thing I was looking for but couldn't find. I had never heard of producer/consumer but it looks like this should work. I will spend today reworking the code and will post the results or problem. Fun... lol
Thanks again
-KR
04-16-2009 03:46 PM
I formatted the code to fit the producer consumer loops but I am not seeing any improvement in the frame rate / frames per second. The way I set it is that every 4th loop iteration of the 'save to avi', one frame gets passed to the detection. Unfortunately I am still only getting about 12-13 FPS and it doesn't get faster as I decrease the amount of frames passed to detection.
Because I didn't see any improvement I ran the 'save to avi file' sequence in its own VI. I found with out any color detection the resulting AVI is still only 12-13 FPS. This means the very simple program (attached) is running much too slow yet I don't see any other way of aquire images and making it into a movie; I am only using the basic IMAQ dx subVIs. Can anyone offer a solution or improvement? Is this data handling or memory related? I am on a fairly new PC...
Thanks in advance
-KR
04-16-2009 03:51 PM
KR,
How long are you wanting to acquire images for? You could always create a ring or sequence with the images (Basically a rotating buffer or buffer, both have examples in the NI example finder) which is much quicker than writing to AVI. Once you have an array of images, you can write them to AVI when speed does not matter. You would just write your known fps to the AVI create input.
Try this and let us know.