Camera restarts between captures: keep the stream alive

Back-to-back captures refuse to repeat. The first frame looks right, the next has shifted brightness or color, and the period you asked for quietly becomes three seconds. The camera is rarely at fault. The capture path is opening and closing the device for every shot, and each open restarts sensor initialization plus the auto exposure, gain and white balance loops from zero. This guide shows how to confirm it from a timestamp log, how to keep one acquisition stream alive instead, and which fixed settings make every frame identical.

What a reopen per capture looks like

The pattern is distinctive. A review display holds the last frame for a fraction of a second, the stream restarts, and the image needs one to two seconds to settle before the next capture is trustworthy. Cycle time sits at a floor no matter what you change: lowering the resolution or the image quality does not shorten the period. That flatness is the tell. Data volume scales with resolution; a fixed start-up overhead does not. When quality and dimension settings move nothing, the cost is the open, not the transfer.

A second fingerprint shows up in pixel values rather than timing. Brightness or color takes a step between shots, because every open restarts auto exposure and auto white balance, and those loops converge over several frames. The scene never changed; the control loop did.

Likely causes in order of probability

1. The capture path re-opens the device for every frame. Stacks that expose a dedicated still mode initialize the sensor fresh for each still. Test: timestamp the capture call and the arrival of the first pixel. A reopen prints a flat delay of roughly a second on every shot.
2. Auto exposure, gain or white balance is still enabled. Test: fix all three and compare ten consecutive frames on an open stream. Steps that vanish were the loops.
3. A review or preview layer re-arms the camera to show the last frame between shots. Test: capture with the viewer disabled.
4. The connection itself resets between shots. Test: the driver log shows disconnect or re-enumeration events that nothing else explains.

Cycle budget for a 1-second capture period

This is the case that forces the fix: one capture per second while a pattern settles — laser speckle, a dispensed bead, a curing surface, anything watched continuously.

Inputs, with units and source:

• Target period: 1.0 s per capture — the cycle the task needs.
• t_open = 1.0 s — the order of magnitude a still-path open costs before the first usable frame; your timestamp log prints the exact value for your stack.
• t_settle = 2.0 s — typical re-stabilization after a restart, a mix of auto-loop convergence and the pattern settling; measure it from stream restart to the first frame your algorithm accepts.
• t_frame = 0.033 s — one frame of a 30 fps stream, the rate a 12 MP USB3 camera sustains at full resolution.

The rule in words: the shortest reliable period equals open time, plus settle time, plus one frame period.

A reopen path therefore reaches about 20 captures per minute (60 s ÷ 3.03 s = 19.8), three times slower than target. With the stream kept alive, the open and settle terms vanish:

The grab then occupies 3.3% of the period (0.033 s ÷ 1.0 s), and 30 fps supports up to 30 captures per second.

Decision: below a period of about 3 s, a reopen per capture cannot meet the target — keep the stream alive. Above about 3 s the reopen path fits the clock but resets the image every shot, so the live stream wins on repeatability at any period. Fixing exposure, gain and white balance manually removes most of t_settle as well, because there is no control loop left to converge; what remains is the scene's own physics, and no camera setting can freeze that.

Fix one: open once and keep the stream alive

Industrial GigE Vision and USB3 Vision cameras have no still mode to escape. The device streams until you stop it, so open it once at start-up and leave it open, then choose how each cycle gets its frame:

• Free-run: the camera delivers continuously and each cycle takes the latest frame. Simplest, and enough when the scene is static between captures.
• Software trigger on the open session: the trigger-to-image wait is one to two frame periods, not a re-initialization. The software trigger timeout failure modes are worth reading before relying on one-shot calls.
• Hardware trigger: wire the machine event into the camera's opto-isolated input. Latency drops from frame periods to microseconds, and several cameras can share one trigger source for synchronized frames.

The one-session pattern applies to integration code too: keeping a camera open and ready between MQTT-triggered grabs shows it end to end.

Embedded camera stacks that split a still path from a video path need a one-line change instead. A capture_continuous loop runs on the still port by default; point it at the video port (use_video_port=True) or hold the module in burst mode (burst_mode=True) so consecutive stills skip the re-initialization. The video-port route is much faster. Compare one frame from each route before committing, because still paths sometimes add resolution or noise reduction that the video path skips.

Fix two: take the control loops out

An open stream removes the restart; manual settings remove the wobble. Set exposure time, analog gain and the white-balance channel gains to fixed values chosen under production lighting, then confirm from per-frame metadata that every frame reports the same numbers. Gain and exposure units differ between camera families, so convert once with the exposure and gain unit reference and the image quality settings guide.

Fixed settings assume fixed light. Under drifting ambient light a locked exposure tracks nothing, and brightness walks through the day. The auto-mode drift checklist lists what to turn off, and controlling ambient light at the station covers what to shield.

Verify with data rather than eyes: read the per-frame exposure and gain metadata and alarm when a frame deviates from the setpoints.

Startup frames and scene settle

Two transients survive both fixes. The frames right after an open are not production frames: any loop still enabled converges over its first frames, and the sensor needs a few frames to stabilize, so discard the first 10 to 20 of every session. Second, the scene's own settling is not a camera property. A pattern that keeps moving for 2 s after the process step keeps moving however the camera is opened. Trigger the capture off the machine event that ends the motion, or delay the grab until the pattern is static. The camera can stop restarting itself; it cannot freeze the part.

Cameras that make continuous capture the default

Any industrial camera can stay open. For a 1-second-or-faster cycle, specify three traits: a global shutter so each frame catches one instant, GigE or USB3 for sustained streaming without drops, and trigger support on the open session.

The MV-CU020-90GC pairs a global shutter with 2.5 MP on GigE, a fit for fixed-position checks streamed continuously. Where the inspection needs pixels over speed, the LS-CMR-0166 streams 30 fps at 4000 × 3000 over USB3. For embedded and space-limited builds, board-level cameras follow the same rules: the LS-BCM-0003 captures 120 fps at 3.1 MP over USB3 with a global shutter.

At 120 fps the frame period is 8.3 ms, so the grab consumes less than 1% of a one-second cycle (8.3 ms ÷ 1000 ms = 0.83%).

If the same stream also feeds an operator display, the HMI side has its own keep-it-open quirks; the MJPEG stream configuration troubleshooting reference covers the common ones. Area scan cameras and smart cameras both support the pattern, and a smart camera runs the job on-device, which removes the PC-side capture loop entirely.

When the stream alone is not enough

Three situations need more. Multi-camera synchronization: software triggers issued from one host jitter by a frame period or more, so distribute a hardware trigger and the cameras expose within microseconds of each other. Fast motion: a rolling shutter distorts a moving scene, which is why the global-shutter requirement above is not cosmetic. Bursts faster than the link: a 20-frame sequence at 120 fps over a link that sustains 60 floods it, and the camera's buffer carries the overflow — the burst capture and buffer guide shows how to size it.

Prevention checklist

Work through this before the system ships.

• Open once per session. Search the code for open or close calls inside the capture loop; none belong there.
• Timestamp every grab twice: host call time and the camera's frame counter. Alarm on a counter reset.
• Fix exposure, gain and white balance, log the per-frame values, and alarm on any deviation.
• Discard the first 10 to 20 frames after every open.
• Disable review or preview displays in production code.
• Budget the cycle as frame period plus processing plus margin, with the numbers taken from your log rather than the data sheet's maximum frame rate.
• Control the light: locked illumination, shaded ambient, and a strobe where LED on-time matters.

Two minutes with a timestamp log catches a reopen before it costs a week of wondering why the images drift. To size a camera against your cycle target, start with the camera finder or the camera configurator; if the timing still will not hold, send the log through the contact page and we will read it with you.