Multi exposure settings consistency for HDR capture

An HDR frame set becomes difficult to trust when every frame carries a separately maintained configuration. One missed filter, automatic adjustment, or shared object reference can change more than the intended exposure. This procedure is for developers building repeatable multi-exposure acquisition. You will define shared parameters once, create independent frame plans, apply them through documented camera controls, and verify that captured images match their intended settings. Image fusion remains a separate task.

Define what must stay the same

Multi exposure settings consistency means that each frame differs only where the acquisition recipe explicitly permits it. Exposure duration is usually the first variable to bracket. Keep gain fixed initially because changing gain also changes noise behavior and complicates comparisons.

Divide the recipe into three groups before writing acquisition code:

Separate camera settings from host processing settings. A smoothing option in an image-processing pipeline is not necessarily a camera feature. Both belong in the recipe, but different components may apply them.

Also separate consistency from suitability. Identical processing can still obscure useful information. For radiometric comparison, prefer an acquisition path without automatic tone mapping or clipping introduced by processing. The HDR capture and fusion guide covers what happens after a reliable frame set exists.

Build independent plans, not repeated references

A collection containing the same settings object repeatedly is not a collection of independent configurations. Editing one entry may change every entry because they refer to the same underlying object.

The opposite mistake is assuming that every copy operation creates independent device settings. An SDK object can wrap native resources, handles, or nested objects. A general-purpose shallow or deep copy is not a supported cloning method unless the SDK documentation explicitly says it is.

Use this order of preference:

1. Use a documented SDK clone or copy operation with clearly stated ownership behavior.
2. Use a documented export-and-import operation if it preserves the required settings and produces independent instances.
3. Construct fresh SDK settings objects and populate them from a plain application-owned recipe.

The third approach is often straightforward because the recipe can contain only ordinary values. Keep live camera handles, SDK settings objects, and acquisition buffers outside it.

This Python example creates application-side plans, not camera SDK objects:

def make_frame_plan(exposure_us):
    return {
        "exposure_us": exposure_us,
        "automatic_exposure": False,
        "automatic_gain": False,
        "fixed_gain_db": 0.0,
        "processing": {
            "smoothing_enabled": False
        }
    }

frame_plans = [make_frame_plan(t) for t in (100, 400, 1600)]

assert frame_plans[0] is not frame_plans[1]
assert frame_plans[0]["processing"] is not frame_plans[1]["processing"]

All shared values appear in one construction function. Each call creates a fresh outer dictionary and a fresh nested processing dictionary. A camera-specific adapter must translate these application field names into documented device controls.

The gain field expresses an application convention, not a universal camera interface. Confirm the device's gain representation before converting it; the exposure and gain units guide explains why raw numbers cannot always be transferred directly.

Apply settings at a controlled acquisition boundary

Some features are writable during streaming; others require acquisition to stop. A successful write also does not necessarily mean the next received image used that value. Buffered images and device timing can separate configuration calls from exposure events.

Use a documented device sequencer or exposure table when available and suitable. Otherwise, use a controlled stop, configure, and capture workflow. Do not assume that either mechanism exists on a camera merely because it supports software exposure control.

Follow these steps for the initial implementation:

1. Establish a known acquisition state. Stop or pause acquisition where required, then handle queued images using the SDK's documented procedure.
2. Apply the shared recipe. Set image geometry, pixel format, trigger configuration, automatic-control state, and fixed gain in the documented order.
3. Read back dependent limits. Recheck exposure range, increments, and timing restrictions after changing features that can affect them.
4. Apply the frame-specific values. Populate a supported sequence table or configure the next exposure at the permitted boundary.
5. Read back the accepted configuration. Record requested and accepted values separately because devices may quantize or constrain requests.
6. Capture and associate images. Match each image to its recipe revision, set identifier, and intended frame position.
7. Validate before releasing the set. Mark incomplete or inconsistent sets invalid rather than passing partial data to fusion.

If settings must change during streaming, first review applying camera settings without stalling capture. That workflow requires explicit handling of feature access and frame boundaries.

One external trigger does not automatically mean that every planned exposure will be captured. Where that behavior is required, distinguish trigger handling from the exposure recipe using the multi-image capture per trigger guide.

Verify captured frames, not just configuration objects

Maintain three records: the requested plan, the accepted device configuration, and the captured frame's evidence. They answer different questions.

A settings readback establishes what the device reports when queried. It does not necessarily identify what was active during an earlier exposure. Prefer per-image exposure and gain metadata when the device provides it, together with frame counters, timestamps, and sequence position where available.

The closest companion procedure is verifying per-frame exposure and gain metadata. Use it to establish which fields genuinely describe the image rather than the camera's current state.

A practical acquisition manifest should record:

• Recipe revision and acquisition-session identifier.
• Set identifier and intended frame position.
• Requested and accepted exposure and gain.
• Per-frame exposure and gain metadata, when supported.
• Image dimensions and pixel format.
• Device frame counter and timestamp, when available.
• Host receive time, recorded separately from device time.
• Completion status and any acquisition error.

Do not compare host and device timestamps as though they share a clock unless synchronization has been established. Use counters and documented sequence behavior where those provide a clearer association.

If per-frame settings metadata is unavailable, label that limitation explicitly. Controlled configuration boundaries, device readbacks, and image-response tests provide evidence, but they are not equivalent to direct per-image exposure reporting.

Work through a three-frame consistency test

Start with a stationary target, steady illumination, fixed optics, and disabled automatic controls. Select a region that stays above the noise floor and below saturation in every exposure being compared.

Consider an application recipe requesting exposures of 100, 400, and 1600 microseconds with unchanged gain. These are example requests, not operating claims for any listed camera.

The integration sum is not the complete acquisition-cycle duration. Readout, trigger handling, configuration changes, and image transfer can add time. Measure the actual set interval rather than calculating throughput from exposure duration alone.

For a linear image response, stable illumination, and unchanged gain, background-corrected signal should approximately follow exposure duration:

Use accepted exposures rather than requested ones if the camera adjusts values to supported increments. Do not expect the relationship to hold in saturated regions, near the noise floor, or after nonlinear processing.

For example, a background-corrected signal rising from 20 to 80 gives 80 / 20 = 4. That supports the expected relationship but does not independently prove correct frame ordering. Combine image response with metadata and counters.

Avoid treating a universal percentage tolerance as an acceptance standard. Establish variation from repeated captures under controlled conditions, then set a project-specific tolerance that accounts for noise and illumination stability.

A useful software test is to change a nested processing value in one disposable plan. Confirm that the other plans remain unchanged, then rebuild the intended recipe before acquisition.

Choose hardware around documented acquisition behavior

Begin camera selection with feature support, not resolution alone. Check manual exposure access, supported ranges and increments, trigger behavior, metadata availability, and any documented sequencing mechanism.

Use the area scan cameras category and camera finder to shortlist interfaces and imaging formats. Then verify the exact acquisition features needed by your recipe before ordering.

The LS-CMR-0053 is a GigE rolling-shutter camera. It is a candidate for an interface-based shortlist, not a promise of sequencer or per-frame metadata support.

The LS-CMR-0166 is a USB3 rolling-shutter camera. Its suitability likewise depends on documented controls and validation with the intended acquisition workflow.

Rolling-shutter operation deserves particular attention when the target or illumination changes during capture. Consistent settings do not remove row-dependent timing effects or motion between bracketed images.

If acquisition and processing will run on vision controllers, confirm SDK compatibility and support for the required camera interface. Keep recipe generation, device configuration, frame validation, and image fusion as separate software responsibilities. This makes failures easier to isolate without tying the design to one controller implementation.

Diagnose mismatches before changing the recipe

When a set fails validation, first identify which layer disagrees. Changing exposure values immediately can hide a software ownership or association error.

Startup deserves its own test. A saved recipe may be applied before another initialization step changes a related feature. The startup exposure-limit troubleshooting procedure explains how initialization order can create misleading configuration behavior.

The usual answer—hold everything fixed except exposure—is wrong when the inspection deliberately needs another variable. Different illumination directions, gain levels, or optical settings may be justified. Treat those as explicitly different acquisition states, with their own validation, rather than silently including them in an exposure-only bracket.

Run the acceptance checklist before deployment

Validate the complete workflow after reconnecting the camera and restarting the application, not only after an interactive setup session.

• Independent plans: changing one plan does not alter another, including nested values.
• Documented ownership: SDK objects are constructed or copied only through supported operations.
• Shared-state agreement: geometry, pixel format, gain, automatic controls, and processing match the recipe.
• Accepted settings recorded: quantization and dependent limits are visible in the manifest.
• Frame association verified: counters, metadata, and sequence behavior support each frame's identity.
• Incomplete sets rejected: a missing or duplicate image cannot silently enter fusion.
• Failure recovery tested: an interrupted set is discarded and the next set begins from a verified state.
• Restart behavior verified: reconnecting and restarting reproduce the intended acquisition state.
• Timing measured: actual set duration meets the inspection requirement with processing included.

As an initial engineering check, run 100 consecutive sets and inspect every manifest for missing frames, ordering errors, and settings mismatches. This is a useful starting test, not proof of long-term reliability; extend testing to the operating duration and conditions your application requires.

Start your shortlist in the camera configurator. For feature confirmation, send the exposure sequence, required metadata, trigger behavior, and timing target through application support before committing to hardware.