Disparity map to depth conversion: bands are not fixed mm

A disparity map is not a depth map in millimetres, and the difference bites the moment you try to draw color rings at fixed depth steps — every 100 mm, say — on top of a live stereo view. Equal disparities sit at unequal depths, so rings that look right at 1.2 m drift apart as the part moves away. This guide gives you the conversion formula, worked numbers you can re-run with your own calibration, the pixel mapping back to the rectified image, and the decision between coloring in a shader, thresholding on precomputed edges, or choosing a sensor that outputs depth directly. Stereo 3D camera integrators in inspection and robot guidance can apply every step from the SDK's calibration parameters alone.

Why is a fixed disparity band not a fixed depth band?

Because Z = f·B/d is a hyperbola: at a 1000 px focal length and 120 mm baseline, a 10 px band around d = 100 px covers about 120 mm of depth, while the same band around d = 50 px covers about 485 mm.

Disparity is the pixel shift between the same surface point in the two rectified views. The shift doubles when the distance halves and fades toward zero as the surface recedes, and that inverse curve is the whole story here.

A color cycle keyed to raw disparity therefore measures the scene in disparity steps, not millimetres: ring pairs stay at fixed pixel positions while the depth scale they represent stretches with distance. The map gains its millimetres only when every value passes through the conversion in the next section, and the unit questions behind stereo disparity scale and calibration for depth estimates start exactly there.

What formula converts disparity to depth?

Depth comes from the pinhole stereo relation Z = f·B/d: rectified focal length in pixels times baseline in millimetres, divided by disparity in pixels, gives depth in millimetres along the optical axis.

f is the fx value of the rectified camera's intrinsics, not the lens's millimetre rating; B is the horizontal separation of the two camera centres, in the unit you want out of Z; d is the matched pixel shift. The relation falls out of similar triangles on one matched point pair — depth from a matched stereo point pair: disparity to 3D coordinates works the derivation step by step.

Calibration packs f, B and the principal points into one reprojection matrix Q. Applying it per pixel is exactly what produces the point map: converters such as OpenCV's reprojectImageTo3D do it image-wide, and one SDK names its point-map command ComputePointMap(). Z points along the optical axis, so straight-line range to an off-centre pixel is a different quantity — depth value vs true distance: convert a pixel's Z to camera distance gives that conversion.

How much depth error does one disparity pixel cost?

One pixel of disparity uncertainty costs Z²/(f·B) of depth: 12 mm at Z = 1200 mm and 48 mm at Z = 2400 mm for the 1000 px, 120 mm example, so depth precision degrades with the square of distance.

The arithmetic: 1200² / (1000 × 120) = 12 mm, and 2400² / (1000 × 120) = 48 mm. Doubling the stand-off quadruples the quantization.

Subpixel matching softens the steps: at 0.25 px effective resolution the same camera resolves 3 mm at 1.2 m and 12 mm at 2.4 m. Three consequences follow. Far band edges draw ragged, because one disparity pixel crosses half a 100 mm band at 2.4 m. Measured heights pick up a quantization bias that stereo depth height overestimation from disparity quantization quantifies. And matching noise swells into depth noise by the same square law, which is why far disparity maps turn speckled — the troubleshooting checklist for noisy DNN stereo disparity depth walks the checks on the matching side.

How do you draw depth bands every 100 mm on a disparity map?

Convert first, color second: turn every disparity into Z with the reprojection parameters, or precompute the disparity thresholds for each band edge and threshold the raw map — there is no fixed disparity count that equals 100 mm.

Bands in depth become bands in disparity by inverting the same relation:

For the example camera, f = 1000 px and B = 120 mm, the true 100 mm bands shrink to fewer and fewer disparities as Z grows:

Two implementations, and the choice is easy. Threshold the raw disparity map against edges like the table's: no per-pixel arithmetic at all, just remember disparity falls as depth rises, so the comparisons run backwards. Or convert every pixel to Z first and color on Z: more work, but it gives smooth gradients and survives any later change of band width. What remains wrong is coloring unconverted disparities in uniform steps for a measurement overlay — the rings are honest in pixels only.

If converted Z disagrees with a tape measure, the coloring is not the fault — the camera needs metric calibration, and depth map to real distance calibration for XYZ point clouds walks that fix.

Which rectified-image pixel does each disparity pixel belong to?

The disparity map is a shifted crop of the rectified image: map pixel (x, y) lands on rectified pixel (x + ox, y + oy), with the offset read from the camera's parameters — one SDK calls it DisparityMapOffset and reports the same offset for the point map.

The offset exists because rectification and the disparity search window leave a valid region smaller than the full image. Software handles it two ways: some SDKs crop the map and publish the offset as a camera parameter, others keep the full size and mark the outer pixels invalid. Either way, read the value at run time instead of assuming zero. The overlay recipe is then mechanical: compute the color from Z at map pixel (x, y), write it into the rectified image at (x + ox, y + oy).

Border pixels have no valid disparity at all; why stereo depth images have an invalid band at the edges explains that band. If the overlay still slides after a correct offset, stereo disparity map troubleshooting after rectification lists the rectification-side causes.

Do you need the full point map just to color by depth?

No: the conversion is one multiply and one divide per pixel, so color in a pass over the smaller disparity map — applying Z = f·B/d inline, the way viewer render passes do — and build the full point map only when you need actual XYZ coordinates.

The data sizes explain the saving: a 16-bit disparity map costs about 2 bytes per pixel, while an XYZ point map of 32-bit floats costs 12 — six times the memory and the transfer, for a color index you could have computed in place. Thresholding against a table like the one above skips the arithmetic entirely.

Build the real point map when something downstream needs coordinates anyway: robot guidance, volume checks, CAD comparison. Then color on Z directly, because the point map is already in millimetres and shares the same pixel offset onto the rectified image.

Which 3D cameras skip disparity conversion entirely?

Time-of-flight, projected structured-light and laser profiler sensors deliver depth natively — their depth and point maps are already in millimetres, so band coloring is a direct threshold on Z and the conversion step disappears.

The choice sits upstream of the software. Passive stereo buys high-resolution texture and low latency but leaves the conversion on your side; native-depth sensors trade some texture detail to delete the whole question. The three camera types below cover the common integration cases, each returning 3D data directly instead of a raw disparity map:

For profile-by-profile measurement on a conveyor, a 3D laser profile sensor outputs height maps in millimetres, so the conversion never reaches your code:

Whichever family you pick, placement decides accuracy before any coloring does — the 3D camera working distance and positioning guide covers that geometry. To compare native-depth options, start at the 3D sensors category, narrow down in the camera finder, or step through the system configurator; more depth-integration guides sit on the 3D topic page.