Stereo depth output resolution: why size settings seem ignored

A stereo processing size and a published depth image size can describe different stages of the same pipeline. You may reduce the stereo input dimensions successfully, yet receive an unchanged depth raster because a later registration stage uses another camera's output grid.

For engineers configuring depth acquisition, the useful question is not simply whether a width setting changed. It is which stage owns the image you consume. The checks below separate processing resolution, registration resolution and publication settings, then show how to verify a change without disturbing the geometry used downstream.

Separate the grids before changing settings

Think of the pipeline as several grids rather than one camera resolution. Depending on the implementation, those grids may share dimensions or differ substantially.

Changing an upstream grid does not guarantee a different downstream raster. A registration stage can project estimates calculated on a smaller stereo grid onto a larger target grid. The published image then contains more pixel locations, but those locations do not represent an equivalent increase in independently measured detail.

A color-camera optical frame identifier is a useful registration clue. It is not proof by itself: identifiers can be configured incorrectly, and coordinate frame names do not establish image dimensions.

If registration itself is uncertain, use the depth alignment verification checks. The task here is narrower: determine which setting actually controls the published raster.

Measure the image, not only its metadata

Start with the exact depth stream your application consumes. Inspect an actual image message rather than a viewer window or only a camera-information message.

Record these fields from a matched image and camera-information pair:

• Image width, height, encoding and row stride.
• Image timestamp and coordinate frame identifier.
• Camera-information width, height, timestamp and frame identifier.
• Intrinsic and projection matrices, plus any binning or region-of-interest fields.
• Stream endpoint and publishing process.

For an ordinary full-frame stream, the image and its calibration metadata should describe a consistent geometry. However, binning and region-of-interest conventions require the driver's documented interpretation. A dimension difference alone does not prove that metadata is stale.

A viewer may stretch a smaller image to fill its window. Conversely, camera information can advertise dimensions that do not describe the image you accidentally selected. Inspecting the message fields distinguishes these cases.

Capture the image and calibration information together. If timestamps or stream identities disagree, resolve that pairing before changing resolution settings. The depth and color timestamp checks explain why apparently related streams may still represent different captures.

Test registration as the first likely cause

When the observed depth dimensions match the color stream rather than the requested stereo size, inspect registration first. Look for the effective alignment target and any separate registered-output size setting.

Use a stationary scene and save the current configuration. If the driver documents an unregistered depth output, compare that stream with the registered output. Alternatively, temporarily disable registration through the documented setting, provided downstream consumers are stopped or prepared for the changed geometry.

Interpret the result carefully:

• If unregistered depth follows the requested dimensions but registered depth does not, a downstream output grid is likely controlling the registered size.
• If neither output changes, investigate configuration loading, supported modes and pipeline restart requirements.
• If both outputs change but camera information does not, investigate metadata pairing and publication behavior.

Do not assume every implementation requires registered depth to match the color image dimensions. Some expose independent output scaling; others provide only specific combinations.

Unexpectedly small output can also come from downstream reduction rather than registration. Use the depth decimation troubleshooting checks when a filter may be shrinking the raster after depth estimation.

Check effective settings and supported modes

A configuration file proves intent, not execution. The application may load another file, apply a launch-time override, or initialize its processing pipeline before your change takes effect.

Check the effective configuration reported by the running application. Confirm the relevant namespace or device instance, especially when several cameras use similar stream names.

Use this order:

1. Confirm which configuration file the running process loaded.
2. Check that the width and height settings belong to the intended processing stage.
3. Inspect reported parameter values and any startup warnings.
4. Determine whether the change is supported during acquisition or requires pipeline recreation.
5. Compare the requested size with documented sensor, processing and output modes.
6. Reinspect actual image messages after applying the supported change procedure.

Some implementations accept only fixed modes. Others may reject unsupported dimensions, retain the previous mode, or select a documented fallback. None of those behaviors should be assumed without checking the manufacturer's documentation and runtime feedback.

Obtain drivers, firmware and software documentation only from the manufacturer or its authorized distributors. If a documented mode is missing, record the installed versions and ask for support rather than trying unrelated packages.

Use a controlled change to identify the owning stage

Change one variable at a time. A simultaneous change to capture mode, processing size and registration target makes a successful outcome difficult to explain or reproduce.

A useful diagnostic sequence is:

1. Save a baseline frame and its matching camera information.
2. Change only the documented stereo processing dimensions.
3. Recreate the pipeline if required, then record both unregistered and registered output dimensions.
4. Restore the baseline before testing a different supported registration-target size.
5. Test any independent published-output setting separately.

Make a small observation table containing requested processing size, effective processing size, target-image size and published-depth size. Include the software configuration and stream identity for each capture.

If published depth changes only when the registration target changes, that is strong evidence that the target grid owns the output dimensions in the tested mode. If a separate output-size control changes it independently, document that behavior instead.

Inspect intermediate images only where the driver exposes them through documented interfaces. You do not need an unsupported internal stream to complete the diagnosis; effective settings and controlled output comparisons may be sufficient.

Work through a resolution and bandwidth example

Suppose an application requests a processing grid of 640 × 360, while registered depth remains 1280 × 720. These are illustrative application dimensions, not specifications for any product listed below.

The larger raster has four times as many pixels:

Assume a tightly packed, single-channel depth image with 2 bytes per pixel at 15 frames per second:

That is approximately 6.91 MB/s versus 27.65 MB/s, using decimal megabytes. These figures exclude transport overhead, metadata and other streams. If rows contain padding, calculate image storage from row stride multiplied by height instead.

Reducing stereo processing dimensions might reduce computational work without reducing this published payload. Registration can still produce the larger raster.

Also, a smaller raster does not automatically change the numeric depth unit or measurement uncertainty. Those are separate properties, explained in the depth unit and precision settings guide.

Apply the fix at the stage that owns output size

Choose the correction according to the requirement, not merely the symptom.

You need smaller registered depth for color-based inspection. Use a documented registered-output size control, or a supported registration-target configuration. Verify that downstream image coordinates and calibration remain consistent.

You need native stereo geometry. Select documented unregistered depth and use its corresponding camera information. Transform points when another camera's coordinate frame is required.

You need less processing work. Adjust supported capture or stereo processing modes. Measure processing load or latency separately from published dimensions; image size alone does not demonstrate a computational improvement.

You need less downstream data. A documented output reduction stage may help. Validate its treatment of invalid depth values, edges and mixed foreground/background pixels. Ordinary image averaging can create depth values that do not correspond to a real surface.

If you resize depth yourself, update the associated calibration consistently with the exact scaling and cropping operation. Do not simply edit metadata dimensions to make them match. The calibration resolution mismatch guide explains when scaling calibration is appropriate and when another calibration is needed.

For requirements involving acquisition geometry rather than only output packaging, consult the capture-time depth resolution and field-of-view guide.

Revisit hardware only when a requirement remains unmet

An unchanged output raster is not, by itself, evidence that a camera needs replacing. First establish whether the installed pipeline provides the required output mode.

If a new acquisition system is necessary, write down the required measurement region, smallest relevant feature, working distance, update rate and output interface. Compare acquisition methods through the 3D sensors category and the camera finder, rather than selecting by pixel dimensions alone.

The catalog identifies MV-DLS300P-04 as a laser galvanometer stereo camera. It is an acquisition option to investigate, not a confirmed replacement for an existing software pipeline.

The catalog identifies MV-DPS200P-02 as a projected structured-light camera. Confirm supported output modes and integration requirements before considering a substitution.

The available catalog information does not establish compatibility with your current driver, registration behavior or requested output dimensions. Those points require product-specific documentation and application review.

Verify the correction before restoring production use

Complete this checklist after applying the chosen correction:

• Actual image: Confirm width, height, encoding and stride from a received frame.
• Calibration: Check that metadata describes the selected image geometry, including any documented cropping or binning.
• Coordinates: Confirm whether depth uses the stereo or registration-target coordinate frame.
• Scene check: Inspect foreground edges and verify that a known location maps to the intended physical feature.
• Persistence: Recreate the pipeline and confirm the setting survives through the intended configuration mechanism.
• Consumers: Check every process that assumes fixed dimensions or maps color pixels into depth.
• Performance: Measure payload, processing load and latency separately where each matters.

Keep the successful configuration with representative image and metadata samples. This makes later software changes easier to diagnose.

If the documented controls still cannot produce the required raster, use application support with the effective configuration, observed dimensions and matched metadata. For a new acquisition design, start with the camera configuration step after defining the required output geometry.