Runtime camera exposure control without reloading the driver

Image capture can work even when your application has no GenICam node map for changing camera settings. Some acquisition drivers expose hardware controls through a separate, documented device-control interface. Editing an initialization file usually changes startup configuration, not the camera already running inside your application.

This procedure is for developers who already receive images and need to adjust exposure without rebuilding the acquisition connection. You will identify the supported control path, handle units and acquisition restrictions, and distinguish an accepted request from an exposure change visible in captured frames.

Choose the runtime control path first

Use the interface documented for the driver that currently owns the camera. Do not assume that a working image stream also exposes a GenICam feature tree, or that another camera API can safely share that connection.

A USB3 connection alone does not establish USB3 Vision support. Likewise, a driver can acquire images through a proprietary interface without exposing standard feature nodes. The relevant question is whether that driver documents runtime exposure access for your camera and software version.

For acquisition-state coordination across either interface style, use the guidance on applying camera settings while streaming. If you do have a node map, the GenICam exposure-setting procedure addresses that different access path.

Gather the interface contract before coding

Read the documentation for the installed driver version, its supported interfaces, and the camera's exposure behavior. Obtain documentation and software through the manufacturer or its authorized distributors.

Record these details before issuing a write:

• Exposure identifier: the documented property name, command identifier or enumeration member.
• Data representation: integer, floating-point value, structure or another specified payload.
• Units: seconds, milliseconds, microseconds, ticks or a documented conversion.
• Access state: readable, writable while streaming, or writable only while acquisition is stopped.
• Limits and increments: the current range and permitted step size, where available.
• Dependencies: automatic exposure, exposure mode, trigger mode, frame rate and image geometry.
• Completion semantics: whether success means accepted, applied, or queued for later application.
• Threading rules: permitted calling threads and synchronization requirements.

A numeric exposure identifier is not portable between unrelated drivers. Neither is a value that happens to produce a sensible image. The article on camera exposure and gain units explains why raw values need an explicit interpretation.

If the manual does not describe runtime exposure writes, seek confirmation before treating initialization-file fields as callable properties.

Change exposure through the documented interface

The following sequence describes application logic, not executable API calls. Map each operation to the exact functions, types and error handling supplied by your driver.

1. Use the existing device connection. Obtain its supported control interface through the documented mechanism. Check the return status before retaining a handle or interface reference. Avoid opening a second connection merely to change exposure.

2. Read the current control state. Check exposure mode, automatic exposure and the current exposure value. Record a known working setting for recovery. Where supported, query the current minimum, maximum and increment rather than assuming fixed limits.

3. Establish manual control. Disable automatic exposure through its documented control if a fixed exposure is required. Do not turn off unrelated automatic functions indiscriminately. Hold gain constant during verification so brightness changes remain interpretable.

4. Convert and validate the request. Translate your application's preferred units into the documented driver units. Check range, increment, numeric type and payload size. Reject invalid requests locally rather than relying on silent clamping.

5. Write in the permitted acquisition state. If streaming writes are supported, submit the change using the prescribed synchronization. Otherwise, coordinate acquisition stop, exposure write and acquisition restart. Stopping acquisition is not the same as unloading the driver.

6. Check status and read back. Record the write result and retrieve the exposure value where supported. If the driver returns a rounded or clamped value, show that applied value to the application instead of displaying only the request.

7. Associate the change with new frames. Account for queued images and any documented setting latency. Confirm the new condition through frame metadata, image measurements or both before declaring the transition complete.

Keep these operations outside an acquisition callback unless the documentation explicitly permits control calls there. A control operation that waits for the capture thread can deadlock when invoked from that same thread.

For interactive applications, use one settings owner and a bounded request queue. Coalesce slider changes so obsolete intermediate requests do not accumulate. A 100 Hz user-interface update rate does not imply that the camera needs 100 exposure writes each second.

If stopping acquisition is necessary, coordinate trigger generation and downstream inspection decisions. Do not silently associate a post-change image with a pre-change inspection request.

Work through units and timing with explicit arithmetic

Consider a hypothetical driver whose documentation specifies exposure in microseconds. The application requests milliseconds, so the conversion is:

These are application examples, not specifications for the catalog cameras below. If the interface instead uses ticks, apply its documented tick duration. Never assume that a raw count represents microseconds.

Quantization also matters. If the documented exposure increment were 10 us, a request of 12003 us would need an explicit rounding policy or rejection. Readback should reveal the permitted value that the camera or driver accepted.

Next, check timing feasibility. For a simplified acquisition sequence without overlapping exposure and readout:

This is a planning estimate, not a universal sensor timing model. Cameras may overlap operations, change frame rate, or impose different restrictions in triggered modes. Use documented limits and current readback to determine the actual allowed setting.

For an external trigger interval of 10 ms, a 12 ms exposure request deserves a timing review. Depending on the documented behavior, the camera may reject the setting, limit trigger acceptance, or require a different acquisition configuration.

Verify the applied setting, not just the return code

A successful function call may mean that a request entered a queue. A feature readback may also reflect driver state rather than metadata attached to a particular image. Use the strongest evidence the interface provides.

First, log the requested exposure, returned status and readable exposure value. Include timestamps and the current acquisition mode. If documented frame metadata contains exposure information, record it alongside the frame identifier.

Second, distinguish queued frames from newly exposed frames. At 50 fps, three queued frames represent approximately:

That estimate excludes command processing and transport delays. A fixed sleep does not reliably identify the first affected image under changing load. Prefer documented frame identifiers, setting events or acquisition sequencing where available. Discard images only through supported buffer-handling methods.

Third, test with stable illumination and a stationary target. Hold gain and image processing constant. Choose an image region that remains below saturation at both exposure settings.

For approximately linear image data, a dark-offset-corrected mean provides a useful cross-check:

A measured ratio near three supports the exposure change, but does not prove exact timing. Clipping, flicker, automatic gain and nonlinear processing can invalidate this comparison. Do not use display brightness alone as the acceptance test.

If the setting changes and then returns to an earlier value, investigate configuration writers rather than repeatedly retrying. The guide to exposure resets during acquisition covers that failure pattern.

Diagnose unsuccessful changes in a useful order

Start with the observed behavior and a controlled test. Repeated driver reloads can hide the distinction between unsupported access, incorrect values and delayed image delivery.

Test one dependency at a time. For example, first establish whether the feature is writable with acquisition stopped. Then test the same value during acquisition, if the documentation permits that attempt.

Do not treat every rejected write as a permissions problem. An out-of-range exposure or active automatic mode requires a different correction from an unsupported interface.

Where the application freezes while browsing controls, review feature-browser freezes during acquisition for related synchronization checks.

Check integration support before ordering hardware

The interface type of area scan cameras helps narrow hardware selection, but it does not establish compatibility with an existing runtime-control API. Use the camera finder for physical requirements, then verify the software control path separately.

The LS-CMR-0053 is a GigE catalog option. Confirm the intended acquisition software and exposure-control interface before selecting it.

The LS-CMR-0166 is a USB3 catalog option. Its interface listing alone does not establish compatibility with a particular driver or runtime-control method.

If your application runs on vision controllers, validate the deployed operating system, runtime and camera driver together. Moving acquisition to a controller does not add an exposure feature missing from the software interface.

Before ordering, check that you can:

• Identify the supported driver and runtime versions.
• Obtain the documented exposure-control interface.
• Read exposure units, limits and acquisition restrictions.
• Change exposure under the required trigger mode.
• Distinguish requested settings from settings applied to images.
• Recover from a rejected change without losing inspection synchronization.

Put the verified control path into production

Keep initialization files for documented startup configuration, and use runtime controls for supported live changes. After reconnecting or reopening a device, reacquire valid interface references and recheck dependent limits.

Record the last verified exposure separately from the last requested exposure. Define what the application should do when a write fails: retain the previous setting, pause inspection, or request an operator decision. Make that behavior explicit rather than leaving a misleading value on the screen.

For a hardware review, start with the camera configurator. For an existing installation, send the driver version, control documentation and required acquisition behavior through technical support before choosing a replacement.