Trigger call versus exposure time: understand capture timing

A capture routine can return quickly even when the camera has a long exposure configured. That observation does not, by itself, prove the exposure setting was ignored. Your timer might cover only command submission, or retrieval might return an image whose exposure began earlier.

For developers integrating camera acquisition, the useful question is which physical event each software operation represents. The checks below separate command latency, exposure duration and image availability, then show how to associate the measured timing with the correct frame.

Identify the interval your timer actually measures

Start by writing down the exact operations inside the timed region. A software trigger command, a blocking image retrieval and a logging request need not have equivalent timing semantics.

Use a monotonic host clock for elapsed-time measurements. Record separate times immediately before and after the trigger command, and immediately before and after image retrieval.

A command returning after 3 ms can be entirely compatible with an exposure lasting 1000 ms. The discrepancy requires investigation only if the application treats that return as proof that the image is complete.

If retrieval never completes, use the separate checks for one-shot capture timeouts. A timeout and an unexpectedly short successful retrieval are different symptoms.

Check existing frames and free-running acquisition first

The first possibility to test is that the returned image was not created by the request you timed. This can happen through an application queue, transport buffers or a continuously running acquisition path.

Inspect the adapter documentation before assuming that an operation named “trigger” sends a camera trigger. Some acquisition layers distinguish camera triggering from starting recording or selecting frames from a stream.

Run a controlled comparison:

1. Stop acquisition using the documented sequence.
2. Release outstanding image buffers and clear the application queue through supported APIs.
3. Configure the intended camera trigger mode before restarting acquisition.
4. Start acquisition without issuing a trigger, then check whether complete frames arrive.
5. Issue one software trigger and record the returned frame identifier and available metadata.

If images arrive before the software trigger, establish why. The camera might be free-running, another trigger source might be active, or the software layer might expose an existing stream.

A queue flush alone is not proof that the next image starts after the request. A free-running camera may already be exposing the next frame when the queue becomes empty.

Verify camera triggering and exposure readback

Next, confirm that the request reaches the intended camera function. A host-side recording trigger can work correctly while leaving sensor acquisition unchanged.

Check the runtime values for:

• The selected trigger function, such as frame start where supported.
• Trigger enable state and software trigger source.
• Acquisition mode and any frame-count setting.
• Timed exposure versus exposure controlled by an external signal.
• Automatic exposure state and the active exposure value.

Read settings after acquisition starts, not only immediately after configuration. Startup code, stored configurations or another control path may change them. The procedure for setting exposure through a GenICam API helps separate requested settings from accepted values.

Where available, record trigger readiness and rejected-trigger information. An ignored request can leave an older frame as the next retrievable image. Follow the checks for camera trigger-ready timeouts if readiness is uncertain.

An exposure request of 1000 ms may also be limited or adjusted by the camera's supported range and operating mode. Read back the accepted value and any documented increments. Do not infer the active exposure solely from the value stored in your application.

Measure exposure on the camera's clock

Camera metadata can provide stronger evidence than a host stopwatch, but only when its meaning is documented. A frame timestamp might identify a trigger, frame start, exposure start or another acquisition event.

Look for documented exposure-start and exposure-end events, or frame metadata that directly reports the exposure used. Availability and naming vary. Do not assume that an arbitrary image timestamp marks exposure completion.

When both exposure boundaries use the same camera clock, calculate the interval directly:

For a hypothetical camera clock, suppose exposure starts at 240000000 ticks and ends at 365000000 ticks. With a documented frequency of 125000000 ticks/s:

Those example values describe a timing calculation, not a specification for a listed product.

Match events to the returned image using documented frame identifiers or event relationships. Check counter wraparound, missing events and identifier resets after restarting acquisition. Arrival order alone can be misleading when event and image data travel through separate queues.

Do not subtract a raw camera timestamp from a host timestamp. Their origins and rates may differ. Use the approach in mapping camera timestamps to host time when you need to compare the two domains.

Use a timing output when metadata is insufficient

A documented exposure-active output can provide an independent electrical measurement. Observe it with a suitable oscilloscope or logic analyzer, following the camera's electrical specifications.

Verify voltage compatibility, output topology, required pull-ups and loading before connecting equipment. Do not assume an output is directly compatible with the measuring instrument.

Measure the documented exposure signal's pulse width. A pulse of approximately 1000 ms, paired with a much shorter software-command interval, supports the explanation that the command returned asynchronously.

However, check what the output actually represents. An acquisition-active signal can include more than exposure. An event labelled exposure-active may have model-specific behavior for rolling shutters, overlapping acquisitions or multiple exposures.

With a rolling shutter, different rows expose at different times. A frame-level interval may span more than one row's integration duration. Use the documented signal definition before equating its width with the exposure setting.

For hardware-triggered tests, observing both the physical trigger and exposure output can reveal trigger-to-exposure delay. A software trigger has no equivalent physical input edge, so a nearby host-generated marker is only an approximate reference unless its timing uncertainty is characterized.

Interpret a shorter retrieval time with a worked example

Consider a hypothetical free-running acquisition with a 1000 ms exposure. The following times use one common reference for explanation; they are not raw timestamps from unrelated clocks.

The actual exposure duration is:

Both measurements are valid. They describe different intervals because the image was already exposing when the application request occurred.

A queued image can produce an even shorter retrieval interval because its exposure and delivery may have finished before the request.

By contrast, if a fresh, full image genuinely results from a new trigger issued inside the timed interval, that image cannot finish its required exposure before the exposure duration has elapsed. An apparent contradiction means you must revisit frame association, timestamp semantics, exposure readback or timer placement.

Separate exposure timing from host delivery behavior

Once exposure duration is verified, investigate the path between the camera and your application. Log frame identifiers, camera timestamps, host receipt times, queue depth and buffer status where supported.

Perform two diagnostic runs: one with the processing and display paths disabled, and one with the normal workload. Keep the camera configuration unchanged. A growing difference between camera event time and application receipt time points toward transport, buffering or scheduling rather than a changed exposure.

A latest-image queue policy may intentionally discard older images. An oldest-image policy may preserve every frame while accumulating latency. Neither policy proves that the image corresponds to the most recent request.

For asynchronous processing, use explicit frame association rather than whichever callback finishes first. The guide to matching asynchronous results with frame timestamps covers that downstream problem.

Prevent recurrence by logging acquisition configuration at startup and recording frame identity alongside every timing measurement. Keep camera exposure duration, trigger-command latency and host delivery latency as separate fields.

Check compatibility before changing hardware

Replacing a camera or interface card is not the first remedy for a timing interpretation error. Start with the supported software stack and documented acquisition behavior. The guide to camera acquisition software compatibility explains the integration choices.

When reviewing area scan cameras, use the camera finder for transport and sensor selection. Separately verify software triggering, exposure limits, timestamp meanings, event availability and timing outputs in the manufacturer's documentation.

The LS-CMR-0053 is a GigE camera with a rolling shutter. Its listed interface does not establish which exposure events or trigger functions are available.

For a GigE host connection, the LS-FGB-0004 is a PoE Gigabit Ethernet card. Adding an interface card does not change what an application-level trigger means.

Browse frame grabbers and the accessory finder only after identifying the required interface and host integration. Confirm adapter, driver and event support independently of connector compatibility.

Acceptance checklist and next step

Before accepting the measurement, check that:

• The timed region has clearly identified start and end operations.
• The trigger command addresses sensor acquisition rather than recording alone.
• The accepted exposure value is read back during the actual acquisition state.
• Queue handling is documented, with no assumption that flushing stops an exposure already underway.
• Each returned image is associated with its exposure evidence.
• Timestamp units, frequency, wraparound and clock domains are accounted for.
• Electrical timing signals are interpreted according to their documented definitions.
• Tests are repeated after acquisition restart and under the normal processing workload.

The usual stopwatch comparison is useful when it brackets a verified new exposure and delivery of that same image. It is the wrong test when it measures only submission or retrieves an existing frame.

For a new setup, begin with the camera configuration step. For an existing station, send the acquisition sequence, accepted settings and frame timing log through application support before replacing hardware.