Embedded stereo vision system sizing for two cameras

A compact stereo installation can lose frames even when its processor appears lightly loaded. The bottleneck may sit in a shared interface, an expanding image queue, or repeated transfers through memory. Two cameras also need a common capture timeline; receiving their images together does not prove simultaneous exposure.

This guide helps you size acquisition and processing hardware before selecting parts. Start with image sampling, calculate the two-camera payload, then budget buffers, memory traffic and processing time. Keep these calculations separate from geometric calibration, which addresses a different part of the system.

Define the acquisition contract first

An embedded stereo vision system needs a written acquisition contract: what each camera delivers, when exposures occur, and when the result must arrive. Compact packaging alone does not establish processing capacity or timing performance.

Record these requirements before comparing hardware:

• Image width and height after any camera-side cropping.
• Transmitted pixel format and its actual bytes per pixel.
• Stereo pairs per second, rather than an ambiguous total frame rate.
• Maximum permissible exposure skew between the cameras.
• Maximum result age at the receiving machine controller.
• Whether every pair must be processed or old pairs may be discarded.

Choose image dimensions from the smallest useful feature, not from the largest available sensor. For an illustrative horizontal coverage of 160 mm and a sampling target of 0.2 mm per pixel:

This establishes sampling only. Stereo matching also needs suitable texture, disparity range and calibration accuracy. Use the camera resolution guide to separate pixel sampling from measurement capability.

Browse area scan cameras and the camera finder after defining these requirements. For ownership of acquisition sessions and pair assembly, the closest companion is the multi-camera acquisition architecture guide.

Calculate the two-camera payload

Use transmitted bytes per pixel, not sensor bit depth alone. Packed data and data held in a wider container create different payloads. Row padding, metadata and transport overhead can increase the total further.

For uncompressed images without padding:

Consider a hypothetical acquisition mode of 1280 × 1024 pixels, one byte per pixel, and 30 stereo pairs per second:

Here, MB means one million bytes. Each camera contributes approximately 39.3 MB/s. These are application calculations, not operating claims for any catalog product.

A Gigabit Ethernet link has a theoretical line rate equivalent to 125 MB/s. Usable image throughput is lower because the transport consumes bandwidth too. Independent camera links can remove a shared uplink bottleneck, but their traffic still converges inside the host.

Average throughput also hides bursts. Synchronized cameras may finish exposing together and begin transmitting together. Check switch uplinks, host interfaces and acquisition buffers under that simultaneous load, not only during staggered free-running tests.

Budget image buffers and working memory separately

Acquisition buffers absorb short scheduling delays. They do not increase the processing rate of an overloaded pipeline.

For the example above, retaining six frames from each camera requires:

That allocation covers raw images only. Add separate budgets for rectified images, disparity, confidence values, matching workspace, display images and application memory. Check whether the acquisition library owns additional buffers outside your application pool.

A disparity image using four bytes per pixel requires:

Some matching implementations allocate much larger intermediate structures. A full cost volume with 128 disparity candidates and two bytes per candidate would require:

Not every algorithm stores a full cost volume. This calculation shows why image-buffer size alone cannot establish the memory requirement. Obtain the chosen implementation's workspace requirement and measure its peak allocation.

Define who owns every buffer and when downstream processing releases it. The image buffer ownership guide explains why delayed release and retained references can resemble insufficient memory capacity.

Count memory traffic, not just installed memory

A host may have enough memory capacity but insufficient sustained bandwidth for repeated full-image passes. Acquisition writes, preprocessing, rectification, matching and display can all compete for the same memory subsystem.

Suppose one processing pass reads both raw images and writes an equally sized pair. Its minimum image traffic is:

This is a simplified lower-bound estimate. It excludes acquisition writes, lookup maps, matching workspace, cache effects and transfers to separate processing memory. Actual traffic depends on the implementation.

Reduce unnecessary format conversions and full-frame copies. Reuse allocated output buffers where the library permits it, and keep display generation outside the time-critical path. If you reduce resolution, check the effect on disparity precision before accepting the throughput improvement.

A zero-copy interface can remove a particular copy, but it does not make memory access free. The processor still reads image data, and buffer lifetime rules still apply.

Benchmark the complete processing graph with both camera streams active. A matching benchmark performed on an image already resident in processing memory does not measure acquisition-to-result performance.

Separate throughput from result latency

At 30 stereo pairs per second, a new pair arrives every 33.3 ms. A serial processing stage must sustain that interval over time, or its input queue will grow.

For example, a stage taking 45 ms per pair can process only:

A deeper queue postpones the overflow without correcting the imbalance. Parallel processing can increase throughput, but only when work, memory traffic and ordering can be managed appropriately.

Latency is a separate budget. Consider this illustrative sequence with no overlap between stages:

Two queued pair intervals add approximately 66.7 ms, making the result nearly 100 ms old. Real systems may overlap readout, transfer and processing, so measure the actual timeline rather than simply adding every nominal duration.

Log exposure timestamps, pair identifiers, processing completion times and queue age. Compare clocks only after establishing their relationship. Use the acquisition stall troubleshooting guide when delays appear only during sustained operation.

Check synchronization and interlaced-input limits

Stereo matching assumes corresponding image content represents sufficiently similar scene times. Host arrival timestamps cannot establish that condition because transfer and scheduling delays occur after exposure.

For lateral object motion, a simple image-displacement estimate is:

This estimate assumes small lateral movement at approximately constant distance. It shows how a modest timing error can create apparent image displacement before matching begins.

Verify hardware trigger support, exposure timing, electrical compatibility and timestamp meaning in the exact camera documentation. Global shutter avoids row-dependent exposure timing, but does not synchronize separate cameras by itself. Follow the dual-camera trigger diagnostic guide when pair timing is uncertain.

Legacy interlaced inputs require another check. A source delivering 50 fields per second supplies successive fields 20 ms apart. Combining adjacent fields produces a frame containing lines captured at different times. Motion can therefore create inconsistent edges even when the assembled frame looks acceptable during casual viewing.

Deinterlacing cannot recreate simultaneous scene information that was never captured. If legacy inputs must remain, verify field parity, field timestamps and synchronization between channels. Compare like-timed fields and measure the resulting spatial-resolution compromise. The analog scanline diagnostic guide covers acquisition-format checks.

After capture timing is sound, use the live stereo rectification guide for geometric alignment. Rectification does not repair temporal mismatch.

Choose cameras, interfaces and a controller independently

Use the budget to shortlist hardware, then verify the exact configuration. Interface type, shutter type and installed memory are screening criteria, not proof of a complete stereo solution.

The MV-CU020-90GC is a GigE camera with a global shutter. The MV-CH120-11UC is a USB3 camera with a global shutter. These are alternative acquisition starting points, not a recommendation to combine dissimilar cameras into a stereo pair.

For a new stereo installation, prefer matching camera models and compatible optics unless a specific requirement justifies otherwise. Confirm trigger operation, supported acquisition formats, required pair rate and software access before committing to a pair.

Vision controllers provide a compact host option. The MV-VC2140-128G40-1T is a catalog controller to evaluate against the processing budget. Its listing does not establish stereo-matching throughput, deterministic latency or compatibility with your chosen algorithm.

For host expansion, the frame grabbers category includes interface cards. The MV-GE2002P provides a GigE interface and is a candidate when evaluating camera connectivity.

Use the accessories finder to compare interface options. Check expansion-slot compatibility, driver support, aggregate host bandwidth and power requirements. Do not assume separate sockets mean completely independent internal bandwidth.

For a processor architecture different from your development machine, verify the acquisition library and dependencies before ordering. The binary compatibility guide explains why a suitable physical interface alone is insufficient.

Know when the usual sizing answer is wrong

Higher resolution is not always the correct response to weak stereo results. Poor texture, reflective surfaces, occlusion or exposure mismatch can limit correspondence even when pixels are plentiful. More pixels then increase bandwidth and processing demand without solving the underlying problem.

A faster host is also not the first remedy for unsynchronized capture. Check timing and image quality before attributing inconsistent disparity to processing capacity.

Conversely, reducing resolution can be unsuitable when small disparities already limit distance discrimination. Recalculate the optical geometry and test the required measurement range before accepting a smaller processing load.

Finally, a newest-pair-only queue is appropriate only when the application permits skipped observations. If every object must receive a result, dropping old pairs can hide missed inspections. Establish an explicit overload response instead: reject affected results, report the fault, or use the machine's approved process response.

Acceptance checklist and next step

Before ordering, confirm these items against documentation and representative benchmarks:

• Acquisition format: Record dimensions, packing, stride and metadata overhead so payload calculations match actual delivery.
• Pair timing: Measure exposure skew and reject unmatched images rather than pairing solely by arrival order.
• Transport path: Test simultaneous transfers through the intended ports, adapters and shared uplinks.
• Buffer ownership: Account for acquisition pools, processing outputs and algorithm workspace without double-counting shared memory.
• Sustained processing: Measure throughput, queue age and peak allocation with display and communications enabled.
• Worst-case scenes: Include motion, low texture, difficult reflections and the largest required disparity range.
• Long-duration behavior: Run through thermal stabilization and check for memory growth, lost pairs and increasing latency.
• Recovery: Verify documented reconnection behavior and discard incomplete pairs after an interruption.

Set numerical acceptance limits before testing. Passing means meeting payload, pair integrity and result-age requirements together, not merely producing a plausible depth image.

Start the camera configuration workflow with your acquisition contract. For a controller and interface review, contact the applications team with the payload calculation, timing budget and measured processing results.