Save Sequence Images with a given timing

[Emanuele_S]

Dear Diane,

I read again the post you suggested as it seems that the frame rate is indicated by means of a VI which updates based on foftware based clock, therefore it doesn't seem to be reliable.

I've tried to check the frame rate with the simple method of recording ten seconds and see how many images I've go saved: it seems that if I set 5fps I always get 50 images, which is the required number. The discrepancy occurs when I increase it to 10fps or more: in this case I guess the time needed to enqueue the image is anyway longer than 0.1s and so I don't get the required number of images...

It seems strange to me that I cannot increase the frame rate, but it seems so... probably my computer is too old, the CPU is an Intel Core 2 @ 2.13 GHz and I have not more than 3.4Gb RAM...

Please let me know what you think about it.

Thank you again

Emanuele

[DianeS]

Hi Emanuele,

Is your camera capable of frame rates greater than 5Hz?

Just try "LL Sequence".  I'm not saying it's going to be your final solution.  All we are trying to do here is see if you can acquire images at a rate greater than 10Hz.

I've attached a modified version of "LL Sequence" for you to try.  With the default values I've saved, it should acquire 100 images in a 10 second period.  Use your function generator to provide a 10Hz trigger signal to your camera.

Note that this code won't save any images to file, etc.  We're only going to focus on getting your frame rate correct.

Since just jumping to a final solution to your problem isn't working, we're going to have to do things in steps and solve problems one by one.  That's really the right way to do things anyway.  Solve your first problem.  Move on to your next problem.  Etc.

Give this a try and let me know how many images you are able to acquire.  Then we'll worry about the rest of the things you want to do.

Diane

[Emanuele_S]

Dear Diane,

my camera can record up to 32 fps (frames per second), it's not an excellent camera, but should acquire at 10fps.

I've run your program. I guess that you set up the timeout with the purpose of cheking whether the program is able to finish correctly the acqusition in 10 seconds, right?

Sometimes I don' get any error message, whereas sometimes I get the following error message

Error -1074397150 occurred at IMAQ Get Buffer.vi

I guess that there's something wrong...

Please let me know if this is what you expected.

Thank you again

Emanuele

[DianeS]

Hi Emanuele,

I looked up that error code and discovered the following:

If you are getting a timeout error at IMAQ Get Buffer, then that implies that you're not able to acquire 100 images in 10 seconds.  Did I know you were going to get this error?  No.  Does it tell us something?  Yes.

You mention that sometimes you get the error and sometimes you don't.  When you do NOT see the error, do you acquire all 100 images?

What happens if you make the timeout period a little (say, 100msec) longer?  Are you able to consistently acquire all 100 images in that case?

Diane

[Emanuele_S]

Dear Diane,

I guess you live in the US and for you it's still daytime, but in Europe it's night and I'm about to go to bed.

I'll try to work on the program and on what you suggested tomorrow as soon as I get to my office,

I'll immediately check what you told me, but could you please just give me some suggestions on how to proceed in the case I find the timeout error again (as it will probably happen)? How can I modify the program to get rid of it?

Thank you and good evening for you.

Emanuele

[DianeS]

Make the timeout longer.  Since you don't get an error some of the time, I'm guessing it's because I set the timeout too tight.  We don't synchronize the software acquisition with the trigger signal, so probably some of the time you just get lucky and start your software acquisition at the same time as you trigger your camera...and sometimes you don't.  Making the timeout longer should allow capture of all of the images.

Let me know how it goes.

When you do NOT see the timeout, how many images do you acquire?

[Emanuele_S]

Dear Diane,

making the timeout longer avoids having the error message: I set the timeout 10100ms and it always works.

Tthis means, as you also said, that the fact that sometimes the program returned the error message when I set the timoeut precisely 10000ms was due to the fact that the first rise of the square wave trigger signal takes up to 100ms to appear for the first time, making the acquistion time slighlty longer. Probably there is a small tolerance, which is anyway smaller than 100ms.

I start to think that the fact that the producer consumer loop acquires at a slower rate (if I set a rate higher than 5fps) is due to the fact that while the program acquires images, it is also Bayer-decoding and saving images, because the producer loop and the consumer loop are anyway run at the same time by the computer: so the computational resources to Bayer-decode the image and  to write it to the hard disk are too high, and from time to time the program skips a frame...

As you suggested, the best solution would be to build a sequence-like program, as it works and always acquires 100 images in 10 secs. The only thing that I would like to do is to start-stop the acqusition manually and not to have a limted number of images established a priori, just like I can do in the Grab program. I guess the program saves the images to the RAM, so I will have anyway a limitation, but to limit the problem I might also look into reducing the AOI (area of interest) of the camera, in this way each image should occupy less space in the RAM and then in the hard disk.

Please let me know what you think about it.

Emanuele

[Emanuele_S]

Dear Diane,

I've thought that one possibility is to build a code that enqueues elements and then dequeues them in series rather than in parallel: I don't know if this is possible to be done with the same functions used in producer-consumer code. I based on the HL Grab program (sequence always asks a number of images at the beginning, so I don't think it's what I want)

To give you an idea, I've built a VI that puts the two loops in series. As it is, it doesn't work, so it will have to be modified, but I've posted it in order for you to see it.

Please let me know how you think that I can make it working and if you think it is a good idea or suggest better alternative solutions.

Thank you

Emanuele

[DianeS]

Hi Emanuele,

You are wrong about the producer-consumer loop architecture being your problem.  The whole idea of the producer-consumer architecture is that you can acquire images at one rate and process / save them at a different rate.  Your problem is due to the fact that "LL Grab" is not the right approach for you, for reasons I've described earlier in this thread.  I'll state them again, briefly, here.

When you use "LL Grab", you configure a single buffer, which gets overwritten with each acquisition.  Since you're not controlling when you view the buffer, you're more-or-less grabbing images at random.  If your acquisition loop iterates slower than 100msec, which is likely, you will sometimes overwrite a buffer before you've had a chance to enqueue it to your consumer loop.

When you use "LL Sequence", you configure a buffer for each image.  None of those buffers are overwritten.  Thus, when you finish acquiring all of your images, they're all there.

Basically what I wanted to find out was, can you acquire images at 10Hz?  The answer is yes, you can.  Now we can move forward.

Next, I want you to look at "LL Ring".  "LL Ring" is nice because it essentially uses a circular buffer.  You can choose to either extract an image, or overwrite it.  So you configure a number of buffers -- say, 100 -- then start your acquisition.  Extract the images you want and queue them to the consumer loop.  Overwrite the images you don't want.

This allows you to reuse buffers, so you don't have to know in advance how many you're going to need.  It also allows you to acquire images and extract them until you press a "stop" button.

I've attached a modified example of how you would incorporate "LL Ring" with a producer-consumer architecture, to give you an idea of an approach you can take.  Please make sure you understand how this VI works.  (note that it's not executable -- you'll have to modify it in order to get it to run)  Read the help files for all of the subVIs and understand what they are doing and why.  Do not just use this VI without understanding it.

Let me know how it goes.

[DianeS]

Hi Emanuele,

No, your most recent VI won't work.  I'm not being successful in explaining concepts to you, but I will try one more time:

LL Grab only configures a single buffer.  That buffer is overwritten with each image acquisition.

What does that mean?

It means that, by using LL Grab, you are using software timing.  It doesn't matter how you trigger your camera.  You are overwriting the buffer every single time your camera recieves a trigger, regardless of whether your software has grabbed it or not.  That's why you keep skipping images at higher frame rates.  That's why it works at slower rates and not at higher rates.  You are simply grabbing images at random.  If the software happens to be able to keep up, great.  If not, too bad.  This is the problem you're having.  It has nothing to do with the image processing time in the consumer loop.  Nothing at all.

By configuring multiple buffers, you can acquire images using hardware timing.  That's why you are able to acquire images at 10Hz when you use LL Sequence.  Each image goes into its own buffer, and no buffers are overwritten.

Using LL Ring will allow you to acquire images using hardware timing, because you can re-use your buffers while still running a continuous acquisition.  Here is how it works, in a nutshell:  You configure multiple buffers.  (Please search "circular buffer" so that you understand how a circular buffer works.)  Your software grabs an image.  After you've grabbed the image, that buffer is reused for another image.  That prevents you from running out of buffers.  It also means you don't have to know in advance how many buffers you'll need.

Trying to implement a producer-consumer in series is completely pointless and defeats the purpose of the producer-consumer.  If you want to do things in series (acquire images and then post-process them), you don't need a queue.  Look again at the example I posted in message #21.  Do you see a queue in that VI?  And how do you expect the "dequeue element" in your consumer loop to work when you've already released the queue reference?  Have you looked at the help files for the queue VIs?  Do you understand that releasing a queue reference means you can't use it anymore?

You're very much on the wrong track with your most recent VI.  Please forgive my frustration, I'm sure you are frustrated too!  It seems I'm not able to explain these concepts well enough for you to understand them.  I feel like I'm just repeating myself to no purpose.

I'm not sure I can help you further.  I'm convinced that using LL Grab is the wrong approach for you, but you don't seem open to any other approach.  I'm not sure where to go next.