Camera streaming callback not called: keep acquisition alive

An asynchronous start call can return successfully while the application closes the camera before its first image arrives. This is especially easy to miss when adapting a single-frame function for a GUI. For application developers integrating continuous acquisition, the first task is to check resource lifetime, not increase the frame rate. The checks below separate startup from frame delivery, keep acquisition resources alive, protect image ownership, and make shutdown predictable.

Separate streaming state from frame delivery

A streaming flag reports an acquisition state defined by the SDK. It does not necessarily prove that an exposure completed, an image crossed the interface, or your callback executed. Record these as separate events.

A synchronous capture function usually waits for its image before leaving the camera scope. An asynchronous function commonly schedules acquisition and returns immediately. If returning also exits the camera or SDK context, the connection may close before any callback arrives.

Start with this diagnostic order when single-frame capture works but asynchronous capture produces nothing:

Do not interpret an empty image queue as proof that the callback never ran. The callback might be rejecting every incomplete frame or failing before publishing an image.

Keep the session alive through the GUI event loop

The camera object, SDK session, callback registration, and acquisition buffers need valid owners throughout streaming. Storing a camera identifier is not equivalent to keeping an opened camera session alive.

Use an application-level acquisition controller rather than opening the camera inside a short button handler. The button requests a state change; the controller owns the resources until shutdown completes.

A conceptual lifetime arrangement looks like this:

Application lifetime
  Enter SDK session
    Open camera
      Register callback and prepare buffers
      Start acquisition
      Run GUI event loop
        Handle start, stop, and display requests
      Stop acquisition and finish outstanding callbacks
      Release camera-dependent resources
    Close camera
  Exit SDK session

This describes ownership, not a specific SDK API. Some integrations place acquisition in a worker thread instead. Follow the SDK's documented thread-affinity and event-dispatch requirements, including any restrictions on where resources may be opened or closed.

Do not add a blocking console prompt or an infinite sleep loop to a GUI button handler. That can keep the camera scope open while freezing the interface. A sleep also does not repair missing event dispatch when the SDK requires it.

The GUI-triggered acquisition workflow explains the separate issue of requesting images from interface controls. Here, the essential requirement is that the owning acquisition scope outlast those requests.

Prove where execution stops

Add timestamps and thread identifiers at these boundaries:

• SDK session entered and exited.
• Camera opened and closed.
• Callback registered and acquisition started.
• Callback entered, before checking frame status.
• Frame accepted, rejected, or returned to acquisition.
• Stop requested and stop completed.

Keep counters separate for callback entries, complete frames, incomplete frames, published images, and application-dropped images. Otherwise, a display counter can hide successful acquisition followed by a processing failure.

For an initial test, remove conversion, disk writing, image processing, and display work from the callback. Retain only bounded diagnostic work and the documented buffer-return action. This distinguishes acquisition failure from application workload.

Use a finite test deadline, not an indefinite wait. For example, a 2-second deadline is a diagnostic choice, not a universal camera timeout. Long exposures, external triggers, or slow startup may require a different deadline.

If callbacks arrive but the application later stalls, investigate callback workload and buffer queues rather than continuing to change resource scopes.

Transfer owned image data before returning buffers

Receiving a frame does not automatically give your application permanent ownership of its pixels. An array returned by an SDK may be a view into a reusable acquisition buffer.

If you save that view and then return the frame to acquisition, a later image can overwrite the same memory. Symptoms include changing images, mixed frames, intermittent corruption, and failures that disappear under a debugger.

For a straightforward preview path, use this ownership sequence:

1. Check the frame status before accessing image data.
2. Obtain or convert the image using the documented SDK operation.
3. Create an application-owned copy before returning any underlying acquisition buffer.
4. Publish that owned image to a bounded handoff queue.
5. Return the acquisition buffer according to the SDK contract, including its error-handling requirements.

Conversion is not proof of ownership. If conversion returns a separate image object, keep that object alive until copying finishes. If it returns a view, the original frame may still own the storage. Check dimensions, row stride, pixel format, and channel order rather than assuming the array is tightly packed.

Keep GUI widget updates on the GUI's permitted thread. The acquisition callback should hand off data through the framework's supported queue or notification mechanism.

The camera frame memory lifetime guide explains the ownership problem in more detail. The same underlying distinction matters in native code and array-based applications.

Budget copy volume and queue latency

Copying images simplifies ownership, but it requires memory and processing time. Estimate the payload before deciding how much work belongs in the callback.

For a tightly packed, uncompressed image:

Consider a hypothetical image measuring 1920 × 1200 pixels with 3 bytes per pixel:

• Image payload: 1920 × 1200 × 3 = 6,912,000 bytes, approximately 6.91 MB.
• Eight queued images: 6,912,000 × 8 = 55,296,000 bytes, approximately 55.3 MB.
• Copying 30 images per second: 6,912,000 × 30 = 207,360,000 bytes per second of image payload.

These estimates exclude row padding, temporary conversion images, acquisition buffers, and object overhead. Actual memory traffic also includes reads and writes, so copied payload is not a complete memory-bandwidth estimate.

At a consumer rate of 30 frames per second, an image with 6 frames ahead of it waits approximately 6 / 30 = 0.2 seconds before processing begins. A growing queue therefore creates stale display images even when acquisition remains healthy.

For a preview, a latest-image handoff may be preferable to preserving every frame. For inspection or recording, discarding frames may be unacceptable. Define the overflow policy explicitly, count every drop, and size the acquisition and processing pipeline for the required throughput.

Stop acquisition before closing its owners

Shutdown is part of the same lifetime problem. Closing the camera while callbacks or consumers still use SDK-backed memory can turn a clean preview into an intermittent crash.

Use an explicit state model such as stopped, starting, running, and stopping. Serialize lifecycle transitions through one owner so repeated button presses cannot race separate start and close operations.

A typical shutdown sequence is:

1. Mark the controller as stopping and reject new acquisition requests.
2. Stop generating application-controlled triggers, where applicable.
3. Invoke the SDK's documented acquisition-stop operation while the camera session remains valid.
4. Complete the documented callback-drain or synchronization procedure.
5. Release outstanding frame references and camera-dependent processing resources.
6. Close the camera, then release the SDK session.

The exact buffer-return behavior during stopping depends on the SDK. Do not implement a simple shared flag that skips all buffer returns unless the documentation explicitly requires that behavior. Equally, do not requeue into a camera that has already closed.

Avoid a blocking stop-and-join operation inside the callback it must wait for. This can deadlock. Request shutdown through the acquisition owner instead.

If processing uses device-backed resources, review GPU buffer lifetime after camera close. Application-owned CPU images and camera-dependent GPU allocations do not necessarily have the same teardown requirements.

When keeping the context open is not the answer

A correct lifetime arrangement cannot produce frames when the camera is waiting for an absent trigger. Confirm the selected acquisition mode, trigger source, and trigger conditions using documented settings.

For a permitted bench test, use the documented free-running configuration to separate callback delivery from trigger wiring and timing. Restore the intended configuration before validating the complete application. For delayed or missing triggered images, use the one-shot capture timeout checks.

Also inspect callback registration. Depending on the SDK or language binding, a registration handle or callback object may need an application-owned reference. Follow the documented ownership rules rather than assuming a local variable remains valid after startup returns.

Finally, check whether another application owns the camera, frames are incomplete, or transport diagnostics report errors. Change one variable at a time. A larger queue cannot repair a closed session, and a longer timeout cannot repair an unregistered callback.

Check hardware requirements without replacing the diagnosis

Do not replace a camera solely because a short-lived acquisition scope produces no callbacks. First establish callback delivery with the existing hardware and its supported SDK.

If the application also needs a hardware change, compare interface, shutter, resolution, and documented software support separately. The area scan cameras category and camera finder support that selection.

The LS-CMR-0053 uses GigE. The LS-CMR-0166 uses USB3. These are catalog examples of interface choices, not claims of compatibility with an existing application's SDK.

Before changing interfaces, confirm the required operating system, language binding, callback model, and buffer ownership contract. Similar image output does not make acquisition APIs interchangeable.

Verify the fix and prevent recurrence

Use this acceptance checklist before returning the application to normal operation:

• The camera and SDK remain open throughout the intended capture interval.
• Callback-entry and complete-frame counters advance independently of display updates.
• Every queued image has an explicit owner and release policy.
• Queue depth remains bounded, and overflow behavior is recorded.
• Repeated start and stop requests cannot create overlapping sessions.
• Normal window closure stops acquisition before destroying its owners.
• Error paths return or release buffers according to the SDK documentation.
• Restarting capture works without restarting the application.

Record time to first frame, callback rate, incomplete-frame count, queue depth, and stop duration. Repeat startup and shutdown enough times to expose timing-dependent failures rather than accepting a single successful run.

For hardware selection, continue with the camera configurator. For help reviewing an acquisition design, use application support with the lifecycle log, image format, queue policy, and SDK version.