LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Taking an Array of Pictures with a Set Framerate

I want to save all the frames that come from my camera to my disk and I wrote a VI to do it, but it seems the VI can't keep up with the camera. The camera has a framerate of 170 FPS when I use pixel binning and reduce the exposure time with NI MAX but the VI only picks up 10o frames for each second it is on at most. How do I get it to save all the frames or at least match the framerate of my camera. Thanks for your help.

0 Kudos
Message 1 of 2
(1,889 Views)

You are going to have to do a little Math (I'd help, but you haven't provided enough information).

  1. How big (in Bytes) is your Image?  To figure this out, multiply Pixel size (W x H) and consider the Pixel format -- RGB requires 4 bytes, GreyScale usually requires 1.  So 640 x 480 RGB = 1.228MB.  That's how much memory a single Image requires.
  2. What is your Frame Rate?  Multiply that by the Image Size to get an idea of Transfer Rates.  Note that for the small image in the previous step, a Frame Rate of 170 is about 209MB/s, about a third the speed of USB 3.0.
  3. Think about the "processing time" you have to "get rid of" a frame.  In your case, you have just under 6 ms, not a lot of time to open a file, write a few megabytes, and close the file.
  4. You used the default Grab Configuration, which allocates only 5 buffers for holding frames.  So when Frame 6 is being acquired, it will overwrite Frame 1 ...
  5. You need to take advantage of LabVIEW's Data Flow Paradigm, which allows you to build parallelism into your code.  You want two Loops running at the same time -- a Camera Loop that reads Frames into the Camera Driver, and an Image Loop that pulls Images out of the Driver and saves them to disk.  Depending on the answers to the above questions on Image Size and Frame Rate (not to mention the speed of your PC and its components), this may or may not be possible.
  6. TIFF files are among the largest of the Image files, which means more time spent doing Disk I/O.  On the other hand, because they are not compressed, they may "process" faster than other formats.  Only testing will tell.

Bob Schor

0 Kudos
Message 2 of 2
(1,873 Views)