Apply camera settings while streaming without stalling capture

You have a camera streaming on the line and you need to adjust exposure, gain or the region of interest while it keeps delivering images, for example from a GUI an operator uses to tune a new part. The trap is doing this by re-applying a whole saved configuration file on every change: that can stop and restart acquisition inside the camera, and repeated reloads leave the stream slow or stalled. This guide shows the writes that are safe on a live stream, how to sequence them, and how to verify each change without stopping capture. It applies to GenICam-compliant GigE and USB3 area scan cameras such as the MV-CU020-90GC or the LS-CMR-0166.

Why a full configuration reload stalls the stream

A saved settings file is not one value, it is dozens of feature writes applied in sequence: pixel format, packet size, ROI, exposure, gain, trigger configuration and more. Several of those features cannot change while acquisition is running, so the apply path stops acquisition, rewrites everything, and restarts it. Done once at startup, that is exactly what you want.

Done in your main loop, three things go wrong:

1. Each reload drops frames for the stop-restart window, often tens to hundreds of milliseconds.
2. Repeated partial teardown can leave packet size and buffer negotiation in a mixed state, so delivered frame rate drops and stays low.
3. Every intermediate state is a valid-looking configuration, so a trigger event arriving mid-load can be serviced with the wrong exposure or ROI.

If your camera has become very slow after repeated reloads, stop the stream, restore a known-good configuration once, and restart. Then switch to per-feature writes as below.

Which settings tolerate a live write

Group camera features by what a write does to the acquisition pipeline:

Before writing anything on a live stream, read the feature's access mode. Many GenICam nodes report read-write only when acquisition is stopped; a write attempt then raises an access error. If you hit one of those errors, see our guide on GenICam node not existing: diagnose feature access errors for how to read the node's availability and write the value in the right state.

The safe sequence for a live change

Use this order for every adjustment you make during capture:

1. Check the feature is writable now (read its access mode, not just that the node exists).
2. Write the single value through the GenICam feature, one feature per operation.
3. Read the value back and compare, because cameras round exposure and gain to internal steps.
4. Confirm the effect in the data: mean pixel level for exposure and gain, image dimensions for an ROI change.

Step 3 matters more than people expect. If you ask for a 5 000 µs exposure and the camera rounds to 4 950 µs, your downstream exposure calculations will drift unless you store the read-back value. We cover the raw units cameras actually report in Camera exposure and gain units: interpreting raw values.

Step 4 is your acceptance test. Doubling exposure time should roughly double mean pixel level in an unsaturated scene; if it does not, the write landed on a feature that is not the one gating the image, or auto exposure is fighting you. The verification workflow in Per-frame exposure and gain: verifying camera metadata extends directly to live writes.

Two rules that prevent most stalls

One feature at a time, from one writer. If your GUI thread, the acquisition thread and a watchdog all write camera features, writes interleave and land in inconsistent order. Funnel all camera writes through one function guarded by a lock, and have the GUI request changes rather than write directly.

Let auto functions do continuous adaptation. If the goal is a picture that stays correct as lighting drifts, do not write exposure from your loop every frame. Enable auto exposure with a defined upper limit and ROI; the camera adapts in silicon with no pipeline disturbance. Misconfigured auto functions cause their own problems, which we diagnose in Auto exposure ROI instability from detection feedback and Auto exposure upper limit not applied: check startup settings.

A worked example: raising exposure from a GUI

An operator reports the image is too dark on a part that just changed. The stream is running on a camera similar to the MV-CU020-90GC, a 2.5 MP GigE model with a global shutter:

1. Read ExposureTime access mode: writable, acquisition running. Read current value: 2 000 µs.
2. Compute the target. Mean pixel level is 60 out of 255 and you want about 120, so roughly double the exposure: 2 000 × 120 / 60 = 4 000 µs. Watch for motion blur: at a belt speed of 300 mm/s and a scale of 0.2 mm/pixel, a 4 ms exposure smears 300 × 0.004 / 0.2 = 6 pixels, which may be too much. In that case raise gain instead, accepting more noise.
3. Write 4 000 to ExposureTime.
4. Read back: 3 990 µs. Store 3 990 in your configuration state.
5. Grab 5 frames, compute mean level, confirm it sits near 120.

Total disruption: zero dropped frames. The whole operation is one write plus two reads.

Changing ROI on a live stream

ROI (Width, Height, OffsetX, OffsetY) is the second most common live change and has its own sequencing rule: write the offsets before shrinking and after growing, so the window never extends beyond the sensor.

1. To shrink: write OffsetX/OffsetY first, then Width/Height.
2. To grow: write Width/Height first, then OffsetX/OffsetY.
3. Expect the delivered image size to change 1-2 frames after the write; size your buffer handling for that transition, or consumers will reject one odd-sized frame.

Decimation and binning are usually writable live too, but they change the image scale, so any calibration or pixel-to-mm factor downstream must be reloaded in the same operation.

When even the right approach fails

If single-feature writes still stall the stream:

• Check the camera is not in a configuration-lock mode, where a ConfigurationRunning flag blocks writes after a config load.
• Check firmware age: early firmware revisions of some models had live-write bugs fixed later; updating via the manufacturer's documented procedure is the legitimate fix.
• Check your transport headroom. A GigE link near its bandwidth limit amplifies any hiccup into visible frame loss; the fix is inter-packet delay and packet size tuning at startup, described in our guide on exposure resets during acquisition: find the cause, which also covers settings that get overwritten mid-run.
• If nothing helps, plan the change as a stop-change-start cycle at a controlled moment, between parts rather than during a capture. A deliberate 100 ms gap per shift is far better than an unpredictable stream.

Checks before you build a GUI on live writes

• [ ] Every feature your GUI writes reports writable with acquisition running.
• [ ] All writes go through one locked function; no direct writes from the UI thread.
• [ ] Each write is followed by a read-back, and the read-back value is stored, not the requested one.
• [ ] ROI growth and shrink use the offset/size write order.
• [ ] Buffer handling tolerates one frame of changed image dimensions after an ROI write.
• [ ] Auto exposure and gain with limits handle continuous drift; manual writes handle part changes only.
• [ ] A known-good configuration is loaded exactly once at startup, never in the loop.

Choosing the hardware for a tunable set-up

If you are still specifying the camera, prefer models whose firmware and SDK clearly report feature access modes, and give yourself interface headroom so writes never contend with the stream. GigE suits long cable runs and multi-camera cells; USB3 suits single-camera bench work where its higher per-link bandwidth absorbs ROI changes easily. For a deeper grounding in balancing the settings themselves, see Industrial camera image quality settings: exposure, gain, balance. Browse the area scan cameras range, narrow it with the camera finder, or start at the camera step of the system configurator to match camera, lens and lighting in one pass.

For bench tuning where you change ROI and format often, a USB3 camera with bandwidth headroom is forgiving. A 12 MP model such as the LS-CMR-0166 delivers its full 4000 × 3000 resolution at 30 fps over USB3, so smaller ROIs during tuning pose no transport problem.

Once the set-up is final, lock it down: load the configuration once at startup and verify it stuck. The pattern in Reset camera settings programmatically before capture gives you a clean baseline every boot, and Camera startup frame rate: verify saved settings and readback shows how to confirm the running frame rate matches what you configured. If you would rather have the whole chain checked before ordering, our expert support reviews camera, lens and lighting choices with every order.