Measuring camera latency glass to glass the right way

A 50 ms number obtained by filming a tablet against a monitor tells you almost nothing about your camera. It lumps exposure, sensor readout, USB transfer, host buffering, your image viewer and the monitor's own frame queue into one figure, and most of those terms belong to the test bench, not the machine. This guide shows you how to split glass-to-glass latency into its parts, measure each one properly, and cut the terms that actually matter for a time-sensitive application. It applies to any USB3 or GigE area scan camera driven through a GenICam-style SDK.

What glass-to-glass latency is made of

Every frame travels the same pipeline, and the total is simply the sum of the stages:

Typical magnitudes for a mid-range USB3 camera on a Linux host:

The screen-comparison method measures the whole column. The number you actually care about for colour measurement is everything up to your processing. Isolate those stages and the 50 ms figure usually collapses.

Why the screen comparison misleads

Filming a pre-recorded clip on a tablet and comparing the flash against your PC's viewer adds three unknowns: the tablet's refresh delay, the monitor's frame queue, and the viewer's buffering. A 60 Hz monitor holds a finished frame for up to 16 ms before showing it, and simple viewers queue one to three frames ahead, which alone explains most of a 50 ms reading. If you want a display-related sanity check, that is fine, but never use it to tune the camera. A related pitfall is assuming the frame rate equals the latency; those are different quantities, as covered in camera not reaching max frame rate: find the bottleneck.

What you need

• A camera with controllable exposure and a GenICam-feature interface, for example the LS-CMR-0166 12 MP USB3 area scan camera or an industrial USB3 model such as the MV-CS200-10UM.
• A short, shielded USB3 cable; long or unshielded cables force retry-heavy transfers that show up as jitter, a failure mode detailed in USB3 Vision transfer errors: diagnose bandwidth and buffers.
• One GPIO line and an LED (for the hardware ground-truth test).
• A host that timestamps frames on arrival — a vision controller rather than a desktop, if the machine will run one; see the vision controllers range.

Step 1: stop measuring the display

Point your timing at the image callback, not the screen. Register an OnImage-style callback and timestamp each frame with a monotonic clock the moment it arrives in your process. Compute the mean and worst-case delta between consecutive arrivals first; if that delta already exceeds your budget, the problem is throughput, not latency, and the fixes in RGB camera frame rate limits: pixel format and exposure apply before anything else.

Step 2: lock the exposure

Auto exposure is a latency source people forget: it changes the exposure period frame to frame, so your latency wanders with scene brightness. Set a fixed exposure. The rule is simple — every millisecond of exposure is a millisecond of latency, because integration must finish before readout starts:

At 10 ms exposure you have already spent a fifth of a 50 ms budget before a single pixel leaves the sensor. Brighten the lighting and cut exposure to 1-2 ms rather than raising gain, which costs noise. Fixed versus automatic exposure behaviour is covered in automatic iris, exposure and gain control in machine vision.

Step 3: use the callback, not polling

Polling a grab call in a loop adds scheduler delay and buffer churn. The lowest-latency path in almost every SDK is the frame-arrival callback: the driver hands you the buffer the moment it is complete, and you copy or process it immediately. Keep the callback short — enqueue and return — and do colour conversion on a worker thread. If frames sit in a queue before you see them, queued depth times frame period is pure added latency; the same reasoning drives camera acquisition high CPU usage: replace busy waiting.

Step 4: measure the camera-only latency with an LED

For a ground-truth number, wire an LED to a GPIO output and let it flash at a known instant, or flash it while the camera watches. Compare the host timestamp of the first frame containing the flash against the flash command timestamp. That difference is exposure plus readout plus transfer — the camera-side latency you cannot remove. Repeat 100 times and record the mean and the 99th percentile; the tail matters more than the mean for time-sensitive decisions.

1. Set fixed exposure and frame rate; disable auto exposure and auto gain.
2. Register the arrival callback and log monotonic timestamps for every frame.
3. Toggle the LED from a GPIO line and log that timestamp too.
4. Find the first frame showing the LED on; subtract the two timestamps.
5. Repeat across 100 toggles and report mean, median and worst case.

If the GPIO route is impractical, a photodiode on the scene and a scope will do the same job electrically.

Step 5: interpret the numbers

Suppose the LED test reports 12 ms mean with 2 ms exposure and 8 ms worst-case jitter. Your camera-side floor is about 10 ms; everything above that on the host is yours to cut. Now re-add only what the application needs: if you measure colour spaces on arrival, add your conversion time — a few milliseconds — and you are done. No viewer is involved, and the display line in the table disappears from the budget.

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

When 50 ms is actually fine

If the application only logs colour measurements and reacts on a timescale of seconds, glass-to-glass latency through a viewer is irrelevant; determinism matters more than raw speed. Conversely, if a robot or actuator closes a loop on the measurement, budget the whole chain — including the decision hand-off described in vision picking request timing: overlap processing and motion — not just the camera. And if a PLC times the sequence, network transfer variability becomes part of the loop, as in machine vision network congestion: diagnose transfer faults.

Checklist before you trust the number

• Fixed exposure set, auto exposure and auto gain off.
• Timestamps taken in the arrival callback, on a monotonic clock.
• LED or photodiode ground truth measured, not inferred from a screen.
• 100 or more samples with mean and worst case reported.
• Display removed from the measurement path.

If the measurement is for a camera that must also survive a shutdown-restart cycle without losing settings, verify timing after reboot using the checks in camera startup frame rate: verify saved settings and readback. For help choosing hardware for a latency-critical cell, start at the system configurator or contact us.