Set exposure every frame: latency and the one-frame delay

You set a new exposure, grab the next frame, and the image is lit exactly as before. The write succeeded — the frame you grabbed was already exposed. Every per-frame control loop meets this once, and the fix is timing, not a different call: know when the value takes effect, wait the right number of frame periods, and confirm on each image which exposure produced it. The rules below give you the latch point, the two-frame-period wait with its arithmetic at 30, 60 and 120 fps, per-frame verification through chunk data, the reason per-frame writes can fail after seconds, and the point at which a sequencer or trigger replaces the writes.

Why doesn't the next frame show my new exposure?

Because a sensor latches its exposure time when a frame starts: the frame your grab call returns next was integrated before your write was processed, so at 30 fps it was exposed up to 33 ms before your new value ever reached the camera.

Two delays stack. Phase comes first: the register write lands partway through the frame that is integrating, and the sensor picks up the new value at the next frame boundary, between zero and one period later. Transport comes second: that affected frame must still be read out, transferred, unpacked and queued behind any frames already in flight. Neither delay is a fault; it is how clocked sensors and pipelines behave, on every area scan camera, rolling or global shutter, and the same latch governs gain and strobe width.

Set exposure every frame and your loop therefore always runs one step behind the camera: the image in your hand answers the write from one or two iterations ago.

How long must I wait before the new exposure arrives?

Wait two frame periods before you judge the result: the affected frame arrives one to two periods after the write completes, which is 33 to 67 ms at 30 fps, 17 to 33 ms at 60 fps and 8 to 17 ms at 120 fps.

The worst case is one period of phase plus one period of integration and transport, and that is what a pipeline holding a single frame in flight delivers. A decoder, a grab queue several frames deep or a live viewer holding its own copy adds roughly a period each. When your numbers look one frame too slow, look for those buffers first — the hidden frame buffering walkthrough shows where they hide.

Two periods is the contract for any per-frame change on the same register path, including when you change camera gain at runtime. Nothing your code does inside that window can pull the frame forward, so spend the window preparing the next write rather than polling for the old one.

How fast can I alternate two exposures, and what caps each value?

One switch per frame is the ceiling, and each exposure must fit inside one frame period: at 30 fps each state lasts 33.3 ms, the pair repeats every 66.7 ms, and the longest single exposure is that 33.3 ms minus readout time.

Worked example: the LS-CMR-0166 is a 12 MP USB3 camera rated at 30 fps and 4000 × 3000. The frame period is 1000 / 30 = 33.3 ms. Alternate 2 ms for a bright label and 15 ms for a dark cap and the pair repeats every 2 × 33.3 = 66.7 ms, which is 15 complete cycles per second. Both values fit: after the 15 ms frame, 33.3 − 15 = 18.3 ms remain for readout and transfer. Score each frame only once the write plus two periods — 67 ms — have passed.

Its rolling shutter changes motion artifacts, not the timing: exposure is still fixed per frame when capture starts. As a working rule, hold the longest exposure near or below 80 percent of the frame period; the remaining fraction covers readout and transfer on a full-frame readout.

A camera that carries the numbers in this example:

Push exposure towards the cap and the camera slows down rather than breaking: the delivered frame rate falls as exposure grows, the effect described in frame rate drops as exposure grows.

How do I check which exposure a frame actually used?

Read the exposure the camera reports on the frame itself, not the value you sent: with chunk data enabled, each image carries the applied exposure time, so the two-frame wait becomes a check instead of a guess.

Turn on the camera's chunk-mode switch in its feature tree, and each delivered buffer carries the applied exposure time and a capture timestamp alongside the pixels; the pattern is described in chunk data on camera frames. Key your processing on that reported value: thresholds tuned for the 2 ms state are wrong for the 15 ms state, and the stamp tells you which one you are holding. A camera that cannot report the applied value can still be characterized once — log the intended value with each frame timestamp, flash a test target, measure the offset, and from then on treat the two-period wait as the contract.

Why do exposure writes start failing after a few seconds?

Per-frame control writes can exhaust a capture stack built for occasional changes, and the run that worked for seconds then dies with a device-invalidated error such as MF_E_VIDEO_RECORDING_DEVICE_INVALIDATED; the fix is fewer writes, not faster ones.

One write per frame at 30 fps is 30 control requests a second, forever, and stacks built around viewing apps assume a handful of changes per session; some retire the device when the writes keep coming. Cut the traffic instead of chasing the error. Write only when the target value differs from the last value written. Rate-limit what remains to a few writes per second and let the two-period wait absorb the lag. Query the exposure range and its units first, because the same number means microseconds on one camera and something else on another. And fix the start-up order: set manual exposure before streaming and turn auto gain off first, or the camera rewrites the register under you.

When is a camera-side sequence better than writing exposure per frame?

Whenever the pattern repeats — the same two or three exposures on every part or every cycle — program the camera's sequencer or fire it from a hardware trigger and stop writing exposure from the host: nothing crosses the driver at frame rate, so there is nothing to invalidate.

Industrial area scan cameras commonly provide a sequencer: a short table of exposure and gain sets that advances one row per frame or per trigger, applied at the frame boundary with no host round trip. Row counts and feature names differ by model, so read the sequencer group in the feature tree of the camera you are buying. A sequencer removes every failure mode above at once: no control traffic at frame rate, no phase to lose, no driver stack to exhaust.

Closed-loop exposure is the exception: when the value must react to the previous image, host writes are the only tool, and the two-period wait plus the per-frame read-back are what keep the loop stable. For a fixed two-state lighting scheme, alternating two exposures per trigger moves the alternation onto the trigger edge instead of into software.

A camera that suits trigger-driven sequences:

The MV-CU020-90GC is a 2.5 MP global-shutter GigE camera; global shutter keeps a moving part undistorted from frame to frame, which is what you want once a trigger, not the wall clock, decides when each exposure state fires.

What must be in place before per-frame exposure runs in production?

Four checks: auto modes off, a two-frame-period wait after every write, the applied exposure read back per frame, and a write issued only when the value changes — miss one and the loop drifts, fights the camera, or trips the driver stack.

• Auto exposure and auto gain off at start-up, before streaming, so manual writes stand.
• Two-frame-period wait after every write: 67 ms at 30 fps before any judgment of the result.
• Applied exposure read back per frame from chunk data, with processing keyed to that value.
• Change-only writes, capped at a few per second, so no stack ever sees one write per frame.
• Fixed patterns moved into the camera's sequencer or onto a hardware trigger.

On a multi-camera cell, run that loop on a vision controller beside the cameras rather than across the office network: control writes and image timestamps then share one host clock, and a network hop turns the two-period wait into a moving target. To pick the hardware, the area scan camera finder filters by interface, shutter and resolution, and the camera configurator pairs camera, lens and light in one pass.

For the rest of the stream-and-trigger fixes, the systems topic page collects the related guides, or contact us with your frame rate and exposure pattern and we will check the wait and the sequencing choice against your camera.