Save Sequence Images with a given timing

[DianeS]

Hi Emanuele,

If you can set up your frame acquisition rate using your Camera Configuration tool, why don't you just grab all of your images and post-process them?  You'll know the images were taken at your specified frame rate, so the rate at which you post-process them really doesn't matter.  You don't need to process your images while you're acquiring them.  You can acquire them all and then process them once they're acquired.

I'm going to put together a picture for you.  THIS IS NOT TESTED CODE.  It is intended only to give you an idea of an approach you might take.

Diane

P.S.  I found lots of information when I searched the forum yesterday.  Maybe you didn't use the right keywords?

[Emanuele_S]

Dear Diane,

maybe I don't where to search, but I haven't yet understood the difference between Labview terms grab, ring and sequence (to me they all should do the same thing...)... maybe it's because I'm not a native english speaker... Does the grab function preserve my exact frame rate whereas multuiple snap does not? I don't understand... sorry for that

[DianeS]

Your English is excellent, in my opinion!

You set up your camera to acquire at your frame rate, using your camera configuration software.  Then you configure your acquisition.  Then you run your acquisition.  It will acquire frames at whatever rate you've specified when you configured the camera.  (at least, that's the idea)  When your acquisition is done, your buffer will contain all the images you acquired.

To help you understand, open the front panel of the IMAQ Sequence VI.  (Drop the VI on your block diagram, double-click to open it, then look at the block diagram.)  You will find that it looks a lot like the VI I just posted for you.  (Which is nice, since I scribbled up the VI without looking at IMAQ Sequence first!)

A lot of the higher-level VIs on the palette are written using the lower-level VIs.

Look at what I showed you, then look at your code.  Then look at the help files for every function you see on the block diagram.  There's a good reason that I put the "IMAQ Status" VI in the code...you need some way of knowing when the acquisition is finished.  In your code, you aren't waiting for the acquisition to finish before you start trying to grab buffers.

It might also be a problem that you only configured 1 buffer.  I'm guessing here, but it seems reasonable.

Is that at all helpful?

[Emanuele_S]

Dear Diane,

I hope you're alright.

After trying for some days and reading the posts you suggested, I modified the program and decided to go for an external trigger, as it looked that the internal trigger was not so reilable (or at least many people in the forum say so). Now I've set up the camera in so as to be activated by an external trigger signal, still generated by Labview, which I can control (basically the frame rate is given by the period of the trigger signal). However if I campute the frame rate, I still have discrepancy between the frame rate I set and the one I compute. I just would like to know whether you think this is the right way to compute the frame rate during the acqusition. Of course I attach the code. I have the same problem both when I use an external trigger and when I use an internal trigger. So I think I've made some concptual mistakes in the program. The program is based on an example of Labview, precisely LL Grab.

Please let me know what you think.

Emanuele

[DianeS]

Hi Emanuele,

Of course you're still having problems.  To be specific, I see two big problems with your code:

The USB 6009 cannot generate hardware-timed output.  Probably the DAQ assistant is generating an error since you have the board configured to produce an output that it is incapable of producing -- put an error indicator on the "error out" terminal of the DAQ assistant and see.  Given that you have specified a configuration that the board is not capable of performing, I doubt you're generating a trigger signal at all.  Even if you are generating a signal, it's going to be completely random since you have no timing in that loop.

In order to provide a hardware-timed trigger, which will generate your triggers at a reliable rate, you will need a DAQ board which is capable of hardware-timed output.  If you don't have one, you could consider using a function generator or something similar to provide a trigger, if you have a function generator available. 

So...you can't generate a reliable trigger signal with the 6009, because it can only generate software-timed output.  This is stated clearly on the board's specification sheet. 

On to your image acquisition code:

I don't think "LL Grab" is the right example for you to use.  I think that "LL Sequence" is much closer to what you want to achieve.  If you want all of your acquired images so you can select which ones to process, then you will need to put each one in its own buffer.  I think we went through this in my last post.  Also look at "LL Ring".

Read the descriptions of the examples.   The "LL Grab" description states the following:

"A grab is appropriate for high-speed applications where you want to process only one image at a time."

To quote from the example description for "LL Sequence": 

"A sequence is appropriate for applications that process multiple images. " 

And the description of "LL Ring" says:

"A ring initiates a continuous high-speed acquisition to multiple buffers and is appropriate for high-speed applications that perform processing on every image. Multiple buffers are useful when processing times vary depending on other applications and processing results."

Which example sounds the most like what you want to do?

Diane

[Emanuele_S]

Dear Diane,

my DAQ card is a PCI 6221. I don't know if it is suitable to generate signals with a fixed frequency.I think I can get also an external signal generator, even if it is incredible how large the number my components is, even in 2012!

I used grab because you suggested useing it in one of your previous answers, but maybe sequence is what better suits my purposes. don't you think?

Please let me know.

I'll keep on working on it anyway.

Emanuele

[DianeS]

Hi Emanuele,

Interesting.  When I opened your DAQ assistant in the code you posted and looked at your configuration, the board was listed as a USB-6009.  I believe that a 6221 will generate hardware-timed analog output, but you'll have to check the spec sheet for that device.  There are lots of good DAQ examples in the Example Finder to help you with square wave generation.  I think that card will also do hardware-timed digital output -- again, you'll have to check -- which would be a very good way for you to generate a trigger signal.

As for your image acquisition...

I have re-read this entire thread and nowhere did I suggest you use "LL Grab" as a starting point.  You posted some code in message #1 of this thread which was obviously based on "LL Grab", so you obviously started with that example, on your own, without any suggestions from me.  "LL Grab" was your original approach...not mine.   

After trying for some time to help you work with your original code, I came to the conclusion that you were on the wrong track.  I've been trying to steer you away from it since message #21 of this thread, where I posted an example of a different approach you might take.   The next time you posted code -- message #24 -- it was clear that you were still using your original approach, which was based on "LL Grab".  In other words, you'd pretty much ignored my advice from message #21 (and from message #23, where I suggested you look at "IMAQ Sequence").  I again suggested in message #25 that you look at one of the sequenced examples .

It's your code, you get to write it any way you want, and you're free to ignore any advice you're given.  All of that is ok.  It's frustrating for someone who's trying to help you, but in the end it's your choice and we all come into it knowing that.

But don't say you chose your original approach, based on "LL Grab", because I suggested it.  That is not true.

[Emanuele_S]

Of course I take my responsibility for what I've done! It's my decision, I don't blame you for that, you took my answer too seriously, I just wrote it to tell you why I chose grab, non to blame you.

In any case grab is indicated "where you want to process only one image at a time", it made sense for my original program, as I had to use the bayer decoding process within the loop, meaning that it had to be applied to each image at a time. Now that I've changed it to a version of the program tha only takes an image and enqueues it, perhaps sequence can be better.

In any case the problem seems to lie in the code, because I've tried an external trigger with an external analog function generator, and I don't achieve the same frame rate as I set: also the number of images in 10 seconds doesn't look to be that required,. The program  always indicates a slighly smaller value: for example if I set 10Hz, the programs return 7-8, if I set 5Hz, the program returns 3-4... I really don' understand why.

Do you think that the frame rate is calculated correctly in my code?

It looks very hard to force a frame rate, although it may seem a very simple requirement to implement....

[DianeS]

Thank you, Emanuele.  You are right and I appreciate your response.  I did get upset and I apologize for that. 

I do think "Sequence" would be better.  I think it makes sense to acquire all of your images (I will try to use the word "acquire" in future so we don't run into a possible language barrier -- I'm sure that was part of our misunderstanding), and then process them after you're done acquiring. 

So you'd use "LL Sequence" (let's start there) to acquire 10 seconds' worth of images, each image in its own buffer.

Then, you can pick out the images you want, and apply your Bayer decoding process to those images, then save them.

I think that's a pretty good approach -- what do you think?

I do find it very peculiar that you aren't able to achieve your frame rate, even using an external trigger.  The function generator should be pretty accurate!  Do you know what kind of trigger signal your camera expects?  It must be somewhere in the camera's manual.  For instance, does the trigger signal have to be "high" for a minimum length of time in order to be considered a valid trigger by the camera?

(If my question about trigger signal format isn't clear, let me know and I'll try to ask it more clearly.)

Here is what I suggest for now:  Keep using your function generator for your trigger signal.  Try to run "LL Sequence" without any modifications -- i.e. don't add your Bayer code quite yet, just run the example -- and see what it does.  Let's try to track down this frame rate problem first, then we can add the other stuff you need to do.

Does that sound all right?

[Emanuele_S]

Dear Diane thank you.

I can try LL sequence, but what I would like to do is to acquire images for an undetermined period of time, because I don't know a priori how long my acqusition has to be. In particular I have to calibrate a flat plate whose surface is coloured with a liquid crystal coating. In order to do that I have to create a temperature transient so that the liquid crystal coating changes colour: when all the colour spectrum is spanned, then can stop my acquisition, but I don't know how long it takes and I might also want to go backwards to double check my calibration so it might take much longer. Probably if I have to acquire images for a predetermined time, I could also use the NI Vision Assistant, which is very similar to the DAQ assistant.

Before trying new solutions, please let me know if the way to estimate the frame rate in my program is correct. Otherwise I'd rely on a wrong estimation and I couldn't be sure of what I get.

Thank you again fpor your time.

Emanuele