How can I skip files in an imaqdx sequence

[dadmir42]

I would like to start an imaq image sequence but skip approximately 100 images before beginning storage of the images into a buffer.  In addition, I may want to stop aquiring and begin again without ending the sequence.  The reason I need to do this is for precise timing of image capture.  The camera that the sequence collects images from sends an external trigger to a device which then begins a timed operation.  If I had unlimited buffer space, I would not need to skip images, but I can't switch over to a 64-bit system at this time.

It seems to me that the best option would be to only save the images that I need.  The imaq version of sequence had a "skip" input that allowed specified images to be skipped, thus saving buffer space.  The imaq dx version does not have this.  Is there a work-around?  Perhaps there is an imaqdx sequence sub-VI that has a "skip" input like the imaq version of sequence or something similar?

[Bob_Schor]

There is a very "thin" connection between taking frames I"images") with a video camera using IMAQdx and saving those images to a file.  There is nothing to stop you from taking, say, frames at 30 fps and just looking at them (without saving anything).  When you decide you want to start saving, put the images into a Queue (to get them out of the "capture images" loop) and start writing them to disk (in a file format of your choice -- I've used .avi).

Note that you can similarly stop writing to your file whenever you think you have enough image data.

If you are clever about this, you can even do something like "create a video starting 5 seconds before and ending 5 secondsafter an external trigger".

Bob Schor

[dadmir42]

Thanks Bob, I think I understand what you are saying.  The problem I have been having is that at 30 fps I cannot write every frame to disk without missing frames.  My method thus far has been to create as many buffers as possible and then running a labview "Sequence" to fill the buffers.  When the buffers are full, I write them to the hard drive.  For the camera I am using, I am limited to about 380 buffers.  At 30 fps I run out of buffers after about 12 seconds.  What I would like to do is capture those 12 seconds of frames after the camera is on for 30 or more seconds. 

I think that what I am hearing from you is not to use the "sequence" command, but to do a "grab" instead.  The "grab" command will write over and over to the same set of buffers, and when I get to the frames that I need to capture, I can let the "grab" command continue until the buffers are filled with new images and then stop the process.  Saving the images to files after the process stops.

Or possibly, as an alternative, I can create just a few "grab" buffers and transfer from the "grab" buffers to a much larger second set of buffers on the fly.  Since RAM to RAM transfer is very fast, it should not interfere with aquisition of new frames.  This would allow me to grab, say, two separate six second sequences.  When the second set of buffers is full and collection is complete, I can stop acquisition and dump the secondary buffers to files.

Is this the gist of what you are saying?

Dave Admiraal

[Bob_Schor]

Using a Producer-Consumer pattern, you should have no trouble at all keeping up with streaming 30 fps to disk.  The basic idea of this pattern is that you have one process, the Producer, running in a loop that that makes "data" (in this case images) at some rate.  As they are made, they are put on a Queue, typically of some finite length (for efficiency), for export.  There is another process, the Consumer, also running in a loop and trying to empty the Queue.  The beauty of a Queue is that the Consumer will simply wait patiently for something to process, then process everything until the Queue is empty, when it waits again.

If you are not familiar with the Producer-Consumer pattern, there is an example, called Queue Basics, in LabVIEW (Help, Find Examples).  The Producer is the Top Left Loop, the Consumer is the Top Right Loop.

You should be able to set the camera up to produced images (in Grab mode) at 30 frames/sec.  Allocate "extra" buffers (experiment -- you may only need a few) to hold the images.

Here is the Producer loop:

1. Allocate a Queue to hold Image buffers from the camera.  I'd suggest that 10 elements should be enough (gives you 0.33 seconds for processing).
2. Set up the camera (Grab, 30 FPS, allocate buffers).
3. Start the Camera.
4. Bring into your Producer Loop the Image Queue and the Camera I/O Reference.  Within the loop, ask the Camera for the Next Buffer, and put it on the Queue.  Wire a Stop control to the Stop button to stop taking images.
5. On exiting the loop, stop the Camera.  Check if the Queue is empty (either using the Queue Status, or simply wait a second), then Release the Queue. 

[In this simple example, I'm assuming you are only taking a single video, hence when you push the Stop button, above, everything gets ready to shut down.  It is easy to modify this code to allow you to start and stop, saving multiple videos].

Here is the Consumer loop:

1   Open a file to hold the video.  Use the appropriate palette for the type of file you are writing (for example, I know there are VIs to handle .avi files).

2.  Bring the File reference into your Producer loop.  Also, bring a branch of your Queue into the loop.

3.  Dequeue an image.  It's not a bad idea to put a time-out (say, 100 msec) on the Dequeue, and to follow the Dequeue with a Case statement, where the True (Timed Out?) case does nothing, and the False case handles your image.

4.  Write the image to your already-opened file.

5.  When dealing with parallel (e.g. Producer-Consumer) loops, it's always a "trick" to get them to both stop at the same time.  You've already coded a Stop of the Producer, which stops the Camera, and then Releases the Queue.  Well, if the Queue is released while the Consumer is waiting on a Dequeue, an error will be generated (possibly 1122, I'm not sure).  You can wire the Error line to the Stop condition, since when the Queue has vanished, there's nothing to Consume, so you can safely exit the Consumer.  [It is Good Practice to find out the number of the "Waiting on non-existant Queue" error and to use this as the Exit condition, since you might have other errors that you'd want to handle differently, such as "No more Disk Space"].

Bottom line -- unless there is something very peculiar about your setup, you should have absolutely no trouble recording 30 fps video with LabVIEW.

BS

[dadmir42]

Thanks Bob -

Based on some of the ideas you passed along, I was able to get the program to work the way I need it to by doing a continuous grab on an array of images and then stopping the grab after the required number of images had passed, cycling through the array until the process was triggered to stop with a counter.  Using the grab function instead of the sequence function was the key.

My bitmaps are about 1 MB each and I'm pulling them in at 30 frames per second.  I don't really want to store them as an .avi, because I wish to process them individually and I need them to be uncompressed.  That means I have to write each bitmap to a hard drive at about 30 MBytes per second.  The better hard drive write speeds are about 100 to 200 MBytes per second, so if I use the queueing process you suggest, I might be safe.  The key is probably the hard drive latency since each bitmap has to be saved individually.  Latency is probably about 4 or 5 msec - multiplied by 30 is about 120 to 150 msec, which means that I probably still should be okay.  I think using a queue may work, and I will probably try this in the future for a different data set that requires the collection of far more images than I need for the current project.  The nice thing about the data I will be collecting for the next project is that I may only have to grab a pair of images every second or so, in which case the queuing method will work terrific.

Thanks so much for your help with this.

Cheers,

Dave Admiraal