Why does image saving slow the loop rate? How to set the exact interval between two frames?

[soljiang]

Hi,

I'm trying to use Hamamatsu camera to record sequence images.  The Hamamatsu camera I'm using is C4742-95-12ER.  It has maximum fps of 8Hz.   Becuase using labview driver cannot change the binning of the camera, I used the driver offered on Hamamatsu website and interface with IMAQ.  When I just show image on front panel and set Wait till next ms at 125ms, the real loop time period fluctuate about 125ms, which is consistent with the 8Hz.  However, when I switch the Start recording button on so that image file is saved as TIFF file into hard disk, the rate jumps way below the 125ms.  

Another question I have for my application is that, if I understand it correctly, the camera records the image and store it in the buffer before the labview calls the image.  Is there a way to know at what exact time the image is taken or is there a way to set the exactly interval between two frames (the interval between two sequential images are taken by the camera)?

Thank you very much.

Best,

Charles

[Andrey_Dmitriev]

The following recommendations for you:

At the first, remove all file IO operations from the acquisition loop.

Second, do not set Gain/Exposure Time at each iteration. Do it once before starting the acquisition loop.

Wait until next is also not necessary - remove it. tm_getnextframe.vi should wait until next valid frame will be received.

Then you should get real FPS rate (if PC fast enough to handle incoming image data, of course)

And is far as I remember, you should be able to change binning of the detector directly from IMAQ (but this option may depend from used interface and cable).

Andrey.

[soljiang]

If I remove File IO from the loop, how can I record the images files?  I want to save them into hard disk.

[Andrey_Dmitriev]

---

@soljiang wrote:

If I remove File IO from the loop, how can I record the images files?  I want to save them into hard disk.

---

Sure. But Do it step by step. First, try to get acquisition running stable at requested rate. And only when you will get desired FPS, then add functions for storing images on the hard drive - otherwise you will never found your bottleneck.

In general there are two ways. Storing images directly in acquisition loop - this is easiest way. In case if FPS dropped down, you can try to send images from acquisition loop (with Queue, for example), then store images in parallel in separate loop.

Andrey.

[ChristopheC]

There are a couple things you can try.

Configure your acquisition VI to wait for the next frame, and get rid of the Wait until next ms that just slows down your loop.

Writing to disk takes time, the more time, the bigger the images you're dealing with. You can benchmark the amount of time it takes to write your image, and verify if you can still meet the camera's frame rate.

Andrey has some good points, about trying to pipeline the image acquisition and the writing of the images.

This link might also help understand and configure your computer for more efficient streaming. The IMAQ Write File VI is not necessary the fastest way to write image to disk. The following document has an attachment that contains an API decicated to streaming images.

http://zone.ni.com/devzone/cda/tut/p/id/2909

If you still want to use standard image file VIs, you can try to specify a different, compressed format. PNG for example is compressed and lossless.

By playing with the compression factor and benchmarking, you should be able to find the value that gives you an optimized time between the time spent by the processor compressing the image data, vs the time spent writing the data to disk.

Hope this helps.

-Christophe

[soljiang]

Is there a way to determine at what exact time the image is taken from the camera?  I saw some thread telling how to use IMAQ to retrieve the image with a time stamp.  However, I don't think it works with the driver from Hamamatsu.  

[ChristopheC]

The easiest way is probably to use the profiler.

From the LabVIEW menu, choose Tools>>Profile>>Performance and Memory.

Run your VI, then press Start. You'll see how much time your acquisition VI takes.

[soljiang]

I'm pretty sure that it's the storage of the TIFF file by File IO that slows down the loop.  I've got a stupid question.  What's the meaning of the loop rate in this case?  When I don't store the image to TIFF, the real loop rate fluctuates between 124 and 126ms.  However, when I start write TIFF file into file IO, occasional the loop rate goes 125, 125....125, 380, 40, 125, ...125.  Is it the time that it retrieve the image from the buffer in camera that changes, or the image recorded by camera has a changed interval?  

For my application, I want the image that I store has a fairly constant interval.  If it just changes by 1ms, it's probably fine, but not has a 200ms change.  

I attached a picture showing the loop period of each loop, when I don't store the image (top) and when I store the image (bottom).  When I don't store the image, it stays pretty constant.  But after all, I really want to understand if this loop period actually reflects the interval between two frames, or it's just interval between when two frames are transferred from the buffer.  How many images are in the so called "buffer"?

[ChristopheC]

We are not in control of when the operating system decides to actually write the data to disk. The amount of time may vary depending on the size of the cache of your hard drive, and the write policy used, something that you're not in control when using the write functions of the Vision Development Module.

If you want something more deterministic, I recommend you use the streaming functions implemented in the API in the link that I mentioned in my previous answer. Using those, you'll get better determinism.

Another option is to use the IMAQ Write String function, that is converting an image to a string, and then use the standard LabVIEW File I/O primitive to write the data to disk (Write to Binary File and Flush File). You might get better determinism that using IMAQ Write.

Hope this helps.

Christophe

[Andrey_Dmitriev]

Here is the simple and straight forward benchmark (2048x2048 16 bit):

As you can see - the fastest ways - AIPD image format or RAW (IMAQ flattened to string) images

Andrey.