Return image data from a capture service reliably

A capture service can return color or depth images directly, without creating temporary files. The architectural question is whether that response should carry a complete frame, identify a frame available elsewhere, or leave image delivery to a continuous stream. For inspection applications, the right choice depends on payload size, request frequency, freshness requirements, and buffer ownership. You can make either approach reliable by defining those contracts before implementing the transport.

Choose what a successful response means

Return image bytes directly when captures are occasional, consumers need an explicit response, and transfer time fits the application deadline. Prefer a stream when acquisition is continuous or several consumers need overlapping access to the same frames.

The main distinction is not synchronous versus asynchronous calling. It is how acquisition, delivery, and processing share resources.

A frame identifier is useful only when the consumer can retrieve that exact frame. A reference to the latest available image is not equivalent: another acquisition may replace it before retrieval.

For acquisition shared among several clients, the multi-camera acquisition session architecture explanation provides the broader session-management context. Here, the narrower goal is defining exactly what crosses the request-response boundary.

Separate acquisition from the response handler

Give camera acquisition a clear owner rather than allowing every service request to open, configure, and close the device. A persistent acquisition component can receive frames, attach metadata, and expose completed frame objects to service handlers or stream publishers.

This does not require continuous exposure. The owner can maintain a session while requesting acquisitions only when supported and appropriate.

Define the requested freshness explicitly:

• Latest completed frame: return a cached frame, subject to an age limit.
• Next available frame: wait for a frame satisfying a documented acquisition-time condition.
• Request-associated capture: associate the request with a specific acquisition using supported camera and software mechanisms.

These are different promises. An image received after a request may still have been exposed before that request, especially when acquisition or transport queues already contain frames.

Use a request identifier and a frame identifier as separate fields. Several requests may legitimately reference the same cached frame, while one request may require a color-and-depth pair.

The camera module acquisition without saving files guide covers the underlying file-free acquisition path. Keep that path independent of how your service serializes its response.

Calculate the payload before selecting the transport

Estimate uncompressed image size using the actual row stride, not only the nominal pixel dimensions. Padding can make each row longer than its visible pixels require.

Consider a hypothetical response containing these tightly packed images:

• Color: 1920 × 1080 pixels, with three 8-bit channels.
• Depth: 640 × 480 pixels, with one unsigned 16-bit channel.

The arithmetic is:

Across a hypothetical 1 Gbit/s link, the ideal transfer time for that pair is approximately 54.7 ms. This is a lower bound that excludes protocol overhead, competing traffic, acquisition, serialization, and processing.

A small request message therefore says little about the cost of its response. Check middleware message limits and transport behavior using the full payload, not a placeholder image.

These calculations describe byte transport, so a camera-resolution calculator would not estimate this bottleneck. Resolution selection and response delivery are separate decisions.

Understand what asynchronous calling actually changes

An asynchronous client call can leave the application thread free while waiting. It does not remove acquisition time, response serialization, memory allocation, or network transfer.

The server can still block its own progress if a service callback waits for work that requires the same execution thread. For example, a handler waiting for an image callback cannot finish if that callback has no opportunity to run.

Use an execution arrangement that allows acquisition callbacks to progress independently. Keep expensive image processing away from the acquisition callback, and avoid holding the camera-state lock while serializing a large response.

A practical division of responsibilities is:

1. The request handler validates parameters and checks capacity.
2. The acquisition owner supplies an eligible frame or reports failure.
3. A response worker packages stable image data and metadata.
4. The client processes the completed response outside its event-handling thread.

Bound concurrency at the service boundary. If all workers are occupied, an explicit busy response is preferable to an indefinitely growing request queue.

Also separate client timeout from server cancellation. A client that stops waiting does not necessarily stop acquisition or release server resources. Define cancellation behavior and whether completed frames remain retrievable.

If requests fail before any valid image arrives, consult the one-shot capture timeout troubleshooting guide. Request-response architecture cannot compensate for an acquisition sequence that never produces a frame.

Return interpretable color and depth data

Image bytes alone are not a complete response. Include enough information to reconstruct the array and interpret its measurements:

• Width, height, row stride, channel layout, and numeric encoding.
• Byte order for multi-byte values.
• Frame identifier and acquisition timestamp, with the timestamp's meaning documented.
• Clock domain and synchronization status when comparing different sources.
• Depth scale, invalid-value convention, and applicable coordinate frame.
• Calibration identifier and whether images are raw, rectified, or registered.

Do not assume every depth image contains millimeters. An integer depth value requires a documented scale. Floating-point depth also requires a unit and an invalid-value convention.

Color channel order matters too. Two arrays with identical dimensions and byte counts can produce different colors if the consumer interprets their channels differently.

For paired color and depth, specify whether the response guarantees temporal pairing, geometric alignment, both, or neither. Similar timestamps do not establish geometric alignment, and alignment does not prove simultaneous exposure.

The raw versus rectified registration explanation addresses the geometric distinction. For processing that finishes out of order, use the association principles in matching asynchronous frames with timestamps.

Compression is a separate contract. Lossy color compression changes pixel values, which may affect inspection thresholds. For depth, use a representation that preserves the required numeric values and metadata. Validate the decoded array rather than judging a display preview.

Bound memory, queues, and buffer lifetimes

A service must own, retain, or copy image storage until response serialization no longer needs it. Returning a view into a camera buffer is unsafe if acquisition can overwrite that buffer first.

The correct approach depends on the SDK and middleware. Reference-counted ownership, an application buffer pool, or an explicit copy can all be valid. Do not assume that a zero-copy option applies across every process or network boundary.

Using the earlier hypothetical payload, eight retained frame pairs occupy:

That excludes serialization buffers, processing copies, and middleware queues. Two queued pairs alone require about 13.7 MB before those additional allocations.

Choose overflow behavior according to the task:

• For a live preview, dropping older frames usually preserves freshness.
• For inspection records, silent frame dropping can break traceability.
• For request-associated capture, reject excess work or report a missed deadline explicitly.

Define a maximum frame age separately from a maximum queue length. A queue containing only one frame can still hold an unacceptable image if acquisition has stopped.

Return distinct statuses for busy, acquisition timeout, unavailable stream, expired frame, and invalid request. These conditions need different recovery actions.

Select hardware without assuming a service interface

Choose the acquisition device for the measurement first. Use area scan cameras for intensity images when the task does not require a measured depth surface. Use 3D sensors when depth or surface geometry is part of the inspection.

The LS-CMR-0166 is a USB3 area scan camera with a rolling shutter. It is an example to evaluate for an intensity-image acquisition path, not evidence of a built-in image-return service.

The MV-DPS200P-02 is a projected structured-light 3D camera. Its catalog identification does not establish a particular response schema, color stream, synchronization mode, or middleware integration.

For either candidate, verify the manufacturer's documented acquisition API, buffer ownership rules, supported image encodings, and stream combinations before choosing an integration design.

Use the camera finder to narrow hardware options. Build the service contract around verified acquisition capabilities rather than assuming that an interface or sensor category provides the application protocol you need.

Verify the contract under failure and load

Test more than the successful single-client case. A service that returns one image correctly can still fail when consumers overlap or acquisition stalls.

Use this acceptance checklist:

• Array integrity: reconstruct the received image using its declared stride and encoding; compare it with the source buffer.
• Freshness: record acquisition time and response arrival time; reject frames older than the application's limit.
• Association: confirm that each response identifier refers to the intended frame or documented frame pair.
• Load: increase request frequency until the configured capacity limit is reached; check that rejection is predictable.
• Slow consumers: delay processing and confirm that queues remain bounded.
• Cancellation: abandon a request and verify when its resources are released.
• Disconnects: interrupt acquisition and confirm that stale cached frames are not reported as new captures.
• Recovery: reconnect the device and verify configuration, metadata, and frame identifiers before resuming inspection.

Record median and upper-percentile latency rather than only an average. For example, a stable average can conceal occasional long delays that exceed an inspection deadline.

Recognize when a direct response is the wrong choice

A full-image response becomes less attractive when clients repeatedly request the same frames, transfers dominate processing time, or requests accumulate faster than acquisition can satisfy them. A continuous stream with bounded subscriber queues may then be simpler and more efficient.

Conversely, a stream is not automatically better for occasional diagnostic capture. It adds subscription lifecycle and frame-selection work that a small, well-defined request-response interface may avoid.

The practical decision is to keep direct responses when their measured size, latency, and ownership behavior satisfy the contract. Otherwise, separate the control request from frame delivery and make their association explicit.

Before ordering hardware or committing to middleware, document the required image formats, request rate, maximum frame age, and timeout behavior. Start with the camera configuration step, or send those requirements through application support to discuss the acquisition path.