Saving AVI w/ High Camera FPS and Resolution

[deskpilot]

I would question whether or not your actually saving all of your frames? I just glanced at your system and it is IEEE-1394. This bus only supports 100 MB/s transfer rate. The image has to be going onto the bus in raw form. At 640x480x160 fps, this would be 2 bytes per pixel. I'm not sure that my 3 bytes per number is correct, but unless you are taking black and white, I don't see how it could be 2 per? Do you have some way of knowing if you are actually capturing all of the images?

[JimAllen]

I am saving B&W only.

I get all the frames because I save the buffer number with the images.

I've about given up here, wasted a lot of time on this already, I'll try and open a ticket with NI and see if they can help but that's about it for me.

Thanks for the help.

Wonder what happened to Stephen, I completely took over his thread 🙂

[deskpilot]

Not sure about the OP, I was hoping he would pop back in. I've been trying to gather as much information as I can for when I get to turn my camera project back on and try to improve it. Doesn't seem like many people are doing medium to high rate acquisition with NI stuff so whatever tidbits I can get are helpful.

Good luck.

[smcclana]

As for my project, we've changed the configuration to a camera with a manageable array size, and the application can now record all the data to AVI without requiring compression.

I wouldn't totally disregard writing to AVI and going right to a binary format for your data collection.  I would suggest checking out the AVI Compressor Comparison example  and run it on your system.  There might be an average write time which is more optimized for your computer.  As a previous poster had mentioned, you're shifting the load to the processor, but there could be one compression filter which gives you enough marginal gain that you'd be able to record all the data you're receiving.  The advantage to writing straight to AVI instead of writing to binary is that you don't need to reconvert it using some binary to AVI utility.  Bear in mind that writing to AVI can be slow at the start, so regardless of it being a highspeed data transfer application or not, your Q will allow you to record all the data without dropping frames.

Best of luck,

Stephen McClanahan

[deskpilot]

Now that some of what I've learned and forgotten has come back to me I realize my previous statements may have been too blanketed. I see now that in some circumstances you would want to compress. In our case we were able to attach a hard drive with a write speed of 320 MB/s, and had the option of upgrading to 600+ MB/s, but would not have been able to reach this speed. We were limited by the GigE cameras, and then the limit of the PCIEx1 card which is close behind. The initial project was supposed to be processing 1000 images a second, but we neveer got there.

So I guess you really have to look at where your bottleneck is before you can decide the best method of saving. The example you linked to leaves out one piece of information, which is time to compress per image, but that should be easy to benchmark.

Glad you got yours figured out Stephen, and hopefully if Cosworth learns anything to help him he will come back and share.

[banana jacks]

I need to record B&W video of image size 640x480 at 300fps. I'm running LV 2009 with the IMAQdx driver(s) to run my GigE camera. Is there a single VI that will record the images at the camera's full frame rate and save to AVI?

It seems like maybe I'm needing a combination of File I/O and image grabbing VI's, but I'm not sure how to put them together. Surely someone's done this before?

So far, I've gotten LV to recognize the camera. I used Low_Level_Grab.vi to confirm that I can capture images at ~300fps. The problem is video capture.

[OliviaC]

Hi banana jacks,

Within the Example Finder you should be able to find an example called Grab and Save to AVI.vi. This is found in Hardware Input and Output»IMAQ»File Input and Output»Grab and Save to AVI.vi. Although this example uses the IMAQ VIs, just replace them with the IMAQdx equivalent VIs and it should work with your GigE camera.

Message Edited by O54E on 05-13-2010 11:01 AM

[banana jacks]

It worked, just like you said. Kudos, Olivia. -BJ

[Dixie]

What i missed in the discussion is how to get to the raw image data: i have a similar problem in that I need to store about 600 MB/s to disk for the high speed line scan camera (full camera link configuration) that i use. For me the only way seems to be to use the win32 dll interface for unbuffered writes. Although the lv vi's allow unbuffered writes there does not seem to be a way to give them a pointer and a number of bytes to write like you can do with the win32 functions. I am using imaq images, but you can't pass in the imaq image reference to the binary write vi, because it contains no data: it's just a reference. Using the imageToArray vi is no good either since that copies the whole image to a new array instead of just rerepresenting the existing data. That's a huge waste of speed. For now I'm stuck with the win32 functions and passing the image data pointer manually. This works and is fast enough (when writing to a fast RAID array at least), but it is a pain to do since a tiny mistake will lead to horrible LV crashes and fpsane.cpp errors. Does anybody have any suggestions to make this easier? Dixie