Depth unit and precision settings on 3D cameras: what they change

You set a depth precision parameter to 0.1 mm, launch your node, and the depth topic still reports 0.400 m, 0.399 m: whole millimetres, exactly as before. This is one of the most common integration questions with stereo and structured-light 3D cameras, and the answer is usually not a broken camera. It is a mismatch between what the parameter promises, what the driver passes through, and what the message format can express. This article explains how depth values are encoded, what a depth unit and precision setting does and does not change, and how to verify the true scale of your stream.

What a depth value actually is

A depth image is not a list of distances. It is a 2D array of integer counts, one count per pixel, and a separate convention (the depth unit) says how to convert counts to physical distance. Most depth cameras ship with a default of 1 mm per count. A pixel reading of 400 in a 16-bit unsigned image therefore means 400 mm, which a downstream driver converts to 0.400 m before publishing. The three decimal places you see are the unit conversion, not measurement resolution.

For a stereo camera the underlying measurement is disparity, and depth follows the triangulation relation:

where z is depth, f is focal length in pixels, B is the baseline, and d is the disparity measured in pixels. Disparity itself is quantised: the matching algorithm finds disparity in whole or sub-pixel steps, and each step maps to a depth step that grows with the square of distance. That quantisation, not the depth unit, sets how fine your measurement can be.

What the depth unit and precision setting changes

A depth unit or precision parameter changes only the scale factor between the raw counts and the reported distance. Set it to 0.1 mm and a reading of 3997 counts means 399.7 mm. The camera captures the same images, runs the same stereo matching, and has the same depth noise. You get more decimal places in the output, which is useful in two cases:

• Your algorithm works on differences smaller than 1 mm at close range, for example thickness checks, and you want to avoid rounding in the transport format.
• You pipeline depth into a controller or logger that expects a fixed unit and you need the counts to match that unit.

Everything else stays the same. If your depth noise at 400 mm is ±1 mm, 0.1 mm units simply report 399.7, 400.1, 400.6 instead of 400, 400, 401.

Why the setting sometimes appears to do nothing

When a precision parameter is ignored, the cause is almost always in the software path between you and the sensor:

1. The wrapper never passes it through. Some driver wrappers accept the argument, log it, but never call the SDK call that applies it to the device. The stream then keeps the hardware default.
2. The format cannot express it. If the depth frame is converted to a 16-bit integer message interpreted in millimetres, 0.1 mm counts are truncated back to millimetres on the way out. The setting was applied upstream; the conversion throws it away.
3. Older firmware or SDK. The unit control may exist in the SDK but only be honoured on certain device families or firmware revisions.
4. A view tool applied it, the driver did not. If a vendor viewer shows 0.1 mm steps but your runtime does not, the viewer used its own SDK session. The driver session is a separate connection and needs the setting itself.

The reliable test is to read raw pixel values from the depth image, not a converted floating-point topic. Point the camera at a flat target, move it a known small distance (for example 5 mm with a dial indicator or a calibrated stage), and see whether raw counts change by about 5 (1 mm units) or about 50 (0.1 mm units).

The range trade-off nobody mentions

Finer units are not free. A 16-bit unsigned depth image holds 0 to 65,535:

At 0.1 mm units, anything beyond about 6.5 m either saturates or wraps, depending on the implementation. Before changing the unit, confirm your full working distance fits the numeric range. For a fixed-mount inspection cell at 300 to 800 mm, 0.1 mm units are safe. For a mobile robot or a bin-picking cell viewing a 3 m bin, they are not.

Worked example: does 0.1 mm buy you anything?

Take a stereo camera with an 848 × 480 depth stream, a 50 mm baseline, and a focal length of about 430 pixels. A pixel of disparity uncertainty Δd gives a depth uncertainty of roughly:

At z = 0.5 m with sub-pixel matching at Δd = 0.1 pixel:

Δz ≈ 0.25 × 0.1 / (430 × 0.05) ≈ 0.0012 m, about 1.2 mm.

So at half a metre the measurement itself is uncertain by roughly a millimetre or more. Reporting to 0.1 mm adds digits without adding information. The same camera at 100 mm has Δz of about 0.05 mm, and there 0.1 mm units are at least in the right ballpark, though still finer than the noise. If your task needs sub-millimetre certainty at several hundred millimetres, a different sensor class is the honest answer rather than a finer unit: a 3D laser profiler measures a profile directly and its accuracy is specified, not inferred from stereo matching.

How to verify the scale of your stream

Work through this in order; it takes ten minutes and removes all guesswork:

1. Read the driver's startup log for the parameter it reports applying. If the log is silent on the unit, assume the default.
2. Subscribe to the raw depth image, not the converted distance topic, and print pixel values as unsigned integers.
3. Place a target at a known distance and note the raw count. 400 counts at 400 mm means 1 mm units; 4000 counts means 0.1 mm.
4. Move the target 10 mm and confirm the count changes by 10 or 100 respectively. This also confirms the sign and linearity.
5. If the unit is wrong, apply the setting in the layer that actually opens the device, and re-check steps 2 to 4.

If the sensor is a time-of-flight or structured-light device rather than stereo, the same logic applies: the unit is a scaling convention, and the raw count test tells you the truth. For measuring a single fixed point rather than a full frame, the approach in center pixel depth measurement: read a fixed image point shows how to extract and interpret one pixel's value repeatably.

When the usual answer is wrong

Changing the depth unit is the right fix only when the measurement is already good enough and you are losing precision in transport or rounding. It is the wrong fix when:

• The depth map is noisy. Temporal and spatial filters, stable exposure, and better ambient-light control do far more than finer units. The techniques in stereo depth lighting optimization for dark surfaces address the actual signal quality.
• You need resolution you cannot reach. Depth resolution and coverage interact; before changing anything, read depth image field of view: why stereo coverage is smaller so you know what the frame can and cannot resolve.
• Your real problem is quantisation in the pixel-to-3D conversion. If your code converts depth to point clouds, the scaling belongs there, and camera intrinsic parameter conversion for depth and texture images covers the parameter side.
• You need repeatable gauging. Then a profiler or a dedicated measuring setup beats any stereo unit setting.

For recurring depth-stream problems in the field, the checks in stereo depth stream disconnect: diagnose startup crashes and the jitter-focused external article on troubleshooting stereo camera depth jitter and IMU drift cover the integration issues that mimic unit problems.

Choosing a unit: a short checklist

• Default 1 mm is right for most robotics, logistics and bin-picking ranges; do not change it without a reason.
• Use 0.1 mm only when your working distance stays under about 6.5 m and your task responds to sub-millimetre differences.
• Confirm the transport format keeps the finer counts end to end; a 16-bit millimetre field discards them.
• Verify with the raw-count step test before trusting the output.
• Compare the change against your measured depth noise; if noise is larger than the step, revert.

If you are selecting hardware rather than configuring it, start from the 3D sensors category or the camera finder, and the system configurator will walk the camera, lens and lighting choices with you. For depth-specific capture parameters, the article on changing 3D camera depth resolution and field of view at capture time is the closest companion to this one.

Key points to take away

A depth unit or precision setting is a scaling convention, not a resolution improvement. Verify the raw counts, respect the 16-bit range when you shrink the unit, and match your expectations to the depth noise formula rather than to the number of decimal places on the topic. If the numbers still do not add up, the problem is almost always in the driver's pass-through or the message conversion, and the ten-minute test above will find it.