An adjustable exposure setting is useful only when your application can discover it, write it, and apply it to the intended frames. Start with the controls exposed by your active acquisition interface rather than copying a property name from another camera. This procedure helps you distinguish missing software access from a temporarily locked setting, configure manual exposure before acquisition, and verify both image appearance and capture timing.
Establish which device and interface you are configuring
First identify the camera, acquisition interface, selected device, and software version. Confirm that your application has opened the intended physical camera, especially when several devices have similar descriptions. Record the serial identifier in your configuration log without publishing it in shared screenshots.
A camera configuration utility and your acquisition application may expose different controls. A successful adjustment in the utility confirms that the camera supports that operation through that connection. It does not prove that another interface exposes an equivalent property.
With area scan cameras, the host application commonly manages acquisition and device settings. With smart cameras, exposure may belong to an inspection job configured on the device. An interface that receives inspection output might not expose the camera's imaging controls.
Before making changes, gather:
- The camera documentation and the supported acquisition-interface documentation.
- A stationary, repeatable scene with constant illumination.
- A way to display or save individual frames without automatic display scaling.
- A log of requested settings, reported settings, frame identifiers, and available device timestamps.
Close other configuration applications during the initial test. Concurrent clients can complicate access permissions or change settings without your application requesting them.
Discover the feature and its access state
-
Enumerate the device-specific controls after opening the camera. Inspect the feature browser, property collection, or documented capability-query mechanism provided by the acquisition interface. Do not assume that a generic image-input object contains every camera setting.
-
Find the control that actually changes exposure duration. GenICam-based devices may expose names such as
ExposureTimeandExposureAuto. Other interfaces can use different names, aliases, or adapter-specific properties. Search descriptions as well as names, and distinguish exposure duration from gain, brightness targets, and trigger delay. -
Inspect access conditions and allowed values. Record whether the feature is implemented, currently available, readable, and writable. Then inspect its units, numeric type, minimum, maximum, and increment if one is reported. Query these details after selecting the intended acquisition configuration.
An absent property and a read-only property require different investigations. A feature can become unavailable because a controlling mode is disabled, or become read-only while acquisition is active. Neither condition proves that the camera lacks exposure adjustment.
For a deeper examination of feature names and controlling nodes, use GenICam exposure feature discovery for missing attributes. If the software reports that a node does not exist, diagnosing GenICam feature access errors helps separate an incorrect name from an unsupported acquisition path.
Set manual exposure before acquisition
-
Stop acquisition before the first configuration attempt. This removes a common source of write restrictions and makes the startup sequence easier to reproduce. Some cameras permit live changes, but support and frame-boundary behavior must come from their documentation.
-
Select the documented exposure mode and disable automatic exposure when appropriate. If the device offers multiple exposure modes, choose the mode in which the numeric duration control applies. An external pulse-width-controlled mode may determine exposure from the incoming signal instead. Use only enumeration values reported by the interface.
-
Write an allowed duration, read it back, and then start acquisition. Use the reported units and increment. If the interface rounds or clamps a request, record the accepted value rather than treating the requested value as the applied value.
A practical startup sequence is: open the device, load the intended job or preset, select acquisition modes, disable automatic exposure, query the current range, write exposure, verify readback, and start capture. Loading a preset after the write can replace your setting.
The manual exposure initialization-order procedure covers this sequencing problem in more detail. If a mode-setting operation fails, check the enumeration values reported by the camera rather than substituting a value taken from another device.
Do not change gain, illumination, and exposure simultaneously during this test. Keep gain and lighting constant so that any brightness change has a clear interpretation.
Choose a value that fits units and timing
Exposure values are not portable unless their units and representation are known. One interface may report a physical duration, while another exposes an integer code or a scaled value. Never infer the unit from the magnitude alone.
For a duration explicitly documented in microseconds, the conversion is:
That arithmetic applies only when the control uses physical time units. A logarithmic code, lookup-table index, or undocumented raw value cannot be converted by dividing by a convenient constant. The article on camera exposure and gain units explains why raw values need their own interpretation.
Next compare exposure with the required frame period:
At a target of 50 frames per second, a 4 millisecond exposure is shorter than the nominal 20 millisecond frame period. That makes it a plausible starting value, not proof that the camera can deliver the requested cadence. Readout, trigger handling, transfer capacity, and acquisition mode still matter.
Do not automatically add exposure time and readout time to predict the period. Some sensors overlap those operations; others impose different restrictions. Conversely, a conventional acquisition cannot provide independent 30 millisecond exposures at 20 millisecond intervals on the same pixels. The camera may reject that combination or reduce the frame rate.
For triggered acquisition, distinguish the trigger command from the actual exposure interval. The trigger-call versus exposure-time explanation describes why host-call timing alone cannot verify sensor timing.
Verify the images and the acquisition timing
-
Compare two permitted exposure settings under fixed conditions. For example, test 2 milliseconds and 4 milliseconds if both values are supported. Keep gain, aperture, lighting, scene position, and image-processing settings unchanged.
-
Measure a stable, unsaturated image region. With linear raw image data and negligible offset, doubling exposure should approximately double the signal above the black level. Saturation, gamma processing, automatic gain, flickering illumination, or changing display scaling can invalidate that comparison.
-
Check frame identity and timing before accepting the configuration. Buffered images may predate the write. Use frame identifiers, device timestamps, or per-frame exposure metadata when available to determine which images belong to the new configuration.
If metadata is unavailable, follow the documented restart or buffer-handling procedure and test a clearly identified sequence. Do not assume that the first returned image was captured after the most recent setting change.
For the timing example above, measure device timestamp differences over a useful sample rather than timing individual host callbacks. Across 100 frame intervals, a nominal period of 20 milliseconds spans approximately 2 seconds. Host scheduling can make delivery uneven even when sensor acquisition is regular.
A dark startup image deserves separate investigation. First-frame exposure settling and light timing explains why startup behavior may differ from steady acquisition.
If the reported setting later changes, log the value before and after loading jobs, reconnecting, and starting acquisition. Use exposure resets during acquisition to investigate configuration reloads and competing control paths.
Diagnose missing or ineffective controls
Work through the likely causes in order: the wrong device or property collection, a controlling mode, an acquisition-state restriction, and finally an interface capability gap. This avoids changing drivers before checking simpler explanations.
| Observation | Likely explanation | Useful test | Corrective action |
|---|---|---|---|
| Exposure works in a configuration utility but is absent in the application | The application uses a different property layer or acquisition path | Enumerate device-specific controls through the active interface | Use the documented interface that exposes the required feature |
| Exposure is visible but read-only | Acquisition or a controlling mode restricts writes | Stop capture and inspect dependent settings | Apply the documented configuration order |
| A numeric write is rejected | The request violates the current range, type, or increment | Query constraints immediately before writing | Submit a supported value in the correct representation |
| Readback differs from the request | The device rounded, limited, or replaced the value | Compare the accepted value and active modes | Use the accepted setting or change the documented constraint |
| Brightness stays constant | Automatic control, stale frames, saturation, or display processing masks the change | Inspect fresh raw frames with other controls fixed | Remove the masking condition and repeat the comparison |
| Brightness changes but cadence falls | Exposure or another timing limit restricts acquisition | Compare device timestamp intervals | Shorten exposure or revise the timing requirement |
Do not install an unrelated interface merely because it exposes a familiar property name on another camera. Confirm device support, operating-system compatibility, and feature access in the current manufacturer's documentation.
If production requires adjustments during capture, first establish a working stopped-acquisition sequence. Then follow applying camera settings while streaming to evaluate live-write behavior without assuming it matches startup configuration.
Check camera candidates without assuming software support
When choosing hardware, use the camera finder to narrow interface and imaging requirements. Then verify exposure access through the exact software connection you intend to deploy. A catalog interface specification does not establish support for a particular application property.
The LS-CMR-0053 is a GigE area scan camera. Treat it as a candidate for interface compatibility checks, not evidence that your application exposes a particular exposure control.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 12 MP
The LS-CMR-0166 uses a USB3 interface. Its interface alone does not establish feature names, writable states, or exposure limits.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
Before ordering either candidate, request confirmation of the supported acquisition interface, exposure representation, trigger behavior, and startup configuration procedure. For an on-device inspection workflow, establish whether exposure belongs to the device job or a remotely accessible setting.
Save a repeatable startup checklist
Once the test works, turn it into an explicit configuration sequence rather than relying on settings left behind by a setup utility.
- Confirm the device identity and intended acquisition interface.
- Load the required job or preset before applying application-specific changes.
- Select the documented exposure mode and automatic-control state.
- Query the current range, increment, units, and write permission.
- Write the exposure and record the accepted readback.
- Start acquisition and identify frames captured after configuration.
- Check image brightness, saturation, and device timestamp spacing.
- Repeat the sequence after a reconnect or power cycle if persistence matters.
A fixed manual duration is not always the right operating choice. Automatic exposure can suit genuinely variable scenes, provided its limits and response are compatible with motion and timing requirements. Pulse-width-controlled exposure also needs a different verification method because the incoming signal determines duration.
Bring your interface choice, required frame period, exposure test log, and example images to applications support. If you are selecting a new acquisition system, start with the camera configurator and verify software feature access before finalizing the hardware.
Questions
Why can I adjust exposure in a setup utility but not in my application?
The two applications may communicate through different drivers or property layers. Check which device-specific controls your acquisition connection exposes and whether that connection supports configuration as well as image transfer. Use the manufacturer's supported integration path rather than assuming every camera setting appears in every application.
Should exposure be configured before or after starting acquisition?
Begin with acquisition stopped because that gives you a simpler configuration and verification sequence. Live adjustment is appropriate only when the camera and interface document it. Also establish how the application identifies the first frame affected by a change, particularly when images are buffered.
Does exposure readback prove that a particular image used that setting?
Readback confirms the reported configuration, but it may not describe an image already waiting in a buffer. Per-frame exposure metadata offers stronger evidence when supported. Otherwise, combine a controlled image comparison with documented restart or buffer handling and a clearly identified capture sequence.
Can I assume every camera provides an ExposureTime control?
No. Feature names depend on the device and acquisition interface, and some cameras determine duration through another exposure mode. Discover the available controls and consult their descriptions. Even a familiar name still requires checks for units, allowed values, access permissions, and automatic-control dependencies.

