Inaccurate frame rate using Guppy Pro?

[josborne]

Hello experts,

I have a simple vision system where I want to do a continuous grab and store the images to file.  I am using a Guppy Pro F032C 1394b camera.  And I am programming it using LV2011 64bit and the NIDAQmx and the Vision Development toolkit.  The system is working well, but I have discovered what I think is an inherent error in the frame rate.

I let the camera acquire images over long periods of time.  Many hours/days. And I believe I have discovered that instead of grabbing at 30.0 fps, it is actually grabbing at something like 29.9805 fps.  This equates to 0.033355 sec per frame instead of .033333 sec per frame. An error of approx 22 microseconds per frame.

This may seem quite accurate for some people.  But if we are recording over a 10 hour period, this error builds up to a time lag (error) of over 10 seconds.

Has anyone encountered this type of issue before?  Any tips?

[josborne]

Hmmm.  Just heard from the manufacturer.  They told me that frame-rate control is not actually done on-camera.  And that frame rates can fluctuate based on various factors.

Which makes me wonder?  If I am using IMAQdx and I tell my DCAM-compliant camera to record in video mode = "640 x 480 RGB 8 Packed 30.00 fps" ... how accurate is it?  Is the frame rate at least constant?

[josborne]

Here is a quick little VI that attempts to check the accuracy of the frame rate using IMAQdx.

It configures a DCAM camera to record in Mode 0 at 30 fps.  Then it calculates two different elapsed time values:

Elapsed camera time = NumberOfFrames / FrameRate

Elapsed system time = Tnow - Tstart 

Over time, these two elapsed times should be fairly constant.  But over time, I am seeing a drift.  This indicates that one of the clocks slower than the other (right?).

I also calculate the frame rate over a long period of time.  And it comes out to slightly lower than the expected 30 fps. 

Arg!  what is the accuracy of the frame rate?

[josborne]

I'm gonna let this run overnight and see what frame rate I measure.  But it certainly looks like my camera is not grabbing at the desired 30.0 fps.

[AnalogKid2DigitalMan]

josborne:

I vaugely recalled that analog broadcast standard of 30fps is not truely 30fps. Thus I googled 29.98 fps and got lots of hits. Looks like NTSC 30fps is actually closer to 29.97fps (30/1.001) for compatability. The same factor applies to broadcast signals  60Hz field rate (59.84 actual).

Not sure if this is the effect you are observing since it is for analog video broadcast but you may want to look into the video standards some more. Its odd that that number comes up very frequently.

Maybe Bruce A. has some insight.

-AK2DM

[josborne]

Thanks for the tip. 

I am also hopping Bruce A might have some advice.  He seems to be the machine vision expert on these boards.

[BruceAmmons]

I tend to agree with AK2DM.  Traditionally the actual frame rate is slightly lower than 30 fps, and I suspect the same timing has been maintained for compatibility.  The error is about 0.1%, which is pretty small.  I agree that it accumulates over time, though.

I think your program for measuring frame rates is a good one.  It will always converge to the actual frame rate eventually, as long as the frame rate remains constant.  If you let it run for several minutes or hours, I am sure the measurement is accurate, especially if it is repeatable.

Can you compensate for the slight difference in frame rates?  Are you trying to time stamp images?  Can you just add 1 image every 1000 images or so, kind of like correcting for leap year?  Does it work as long as you know the real frame rate?

Another possibility is running in mode 7 and adjusting the exposure time to get exactly 30 fps.  The camera manual can probably tell you what the formula for frame rate based on exposure time and other variables is.  Or, you could just try different settings until you get the right number.  You should be able to get a little closer, perhaps, although that would require high resolution adjustment of the exposure time.

Bruce

[josborne]

Thanks, Bruce. 

I let it run overnight, and the frame rate is convering to about 29.981 fps.  And the accumulated error/lag is about 45 seconds.

Looks like I now have a few good workaround options:

- Use format 7

- Use an external shutter trigger

- Compensate in the code (eg by adding a frame, or just by knowing that the real framerate is 29.98XX fps)

Now I just need to decide which solution will provide the most reliable results, without adding too much complexity to the system.

Btw:  the reason this is important to me is that we are using the video for what I call "patient surveillance".  The video will be synched with other signals (I use a start trigger to synch) such as EKG.  For example, if we see something strange in the EKG signal, we want to be able to look at that exact point in time on the video to see what happened to the patient.  And we will be recording for long periods of time, so a 30 second lag between EKG and video data would be unaccaptable.

[BlueCheese]

I think your best bet will be external synchronization via a trigger cable. The problem is that without a frame trigger, your frame rate is being controlled by an on-board oscillator on the camera which will drift independently from whatever oscillator is being used in you EKG measurements. In general these types of devices both use accurate clocks that don't drift very much, but over a large period of time you might still be quite a bit off. It would really depend on how long your length of time is and how many seconds of drift is acceptable to know if just using a fixed-rate mode on the camera would be acceptable.

Eric

[BlueCheese]

As some perspective on the clock drift, looking at the specs for one of our X-series DAQ devices (http://sine.ni.com/ds/app/doc/p/id/ds-100/lang/en), the onboard clock seems to have a drift of 50 ppm (parts-per-million). I believe that means that every 20,000 seconds (~5.5 days) it could drift off by 1 second. I would imagine the clock in a DAQ device that can be used to take frequency-dependent measurements probably has a more accurate clock than the ones used in most cameras, so I suspect you'd have even more drift there. So if being a second or two off in a few days is acceptable, then you can probably get away with triggering everything at the same time and having the camera run at a fixed-rate.

Eric