You finish a stereo calibration on a two-camera rig and the tool reports a negative baseline. Open the depth view and the point cloud covers only part of the scene, with torn pixels where the pair should overlap. The cause is almost always mundane: the camera feeding the left channel is physically on the right, so the solver fitted a mirrored rig. This page is for engineers building or re-commissioning a stereo pair from two area scan cameras. It explains what the sign means, why depth stays anchored to the left image even when the pair is flipped, how to find and fix the swap in minutes, and what calibration coverage a long baseline such as 1.7 m can realistically deliver.
What a negative baseline is telling you
The baseline is the translation between the two camera centers, and calibration tools store it as the second camera's position relative to the reference camera — the left one of the pair. A solver expects the second camera to sit to the right of the reference, so the x-component of the translation comes out positive on a healthy rig. A negative value says the fitted second camera sits to the left of the reference. Nobody moved your cameras: the roles were swapped at capture time, and the solver did the only consistent thing — it fitted a mirrored rig.
The magnitude is the tell, and it gives you the decision rule. Measure the spacing between lens centers with a tape. If the absolute value of the calibrated translation is close to that measurement and the sign is negative, the pair is role-swapped: swap it back and recalibrate. If the magnitude is far off too, the fit itself is weak, usually from poor board coverage or too few poses; that path is covered in stereo calibration board coverage: fix the stall at the end. For what frame the translation is expressed in when you merge it with other poses, see which reference frame a camera pose guess means.
Why depth stays anchored to the left image
Every stereo depth stack reports depth on the reference image's pixel grid. The call in your SDK that returns depth or a point cloud hands you values aligned with the left image, deprojected with the left camera's intrinsics. Two consequences follow when the pair is flipped.
The view never stitches. A depth viewer shows the shared scene as the left camera sees it; objects only the right camera catches never appear, because depth does not exist outside the two cameras' overlap — depth coverage is always smaller than a single image, as set out in why the depth image field of view is smaller.
Distances can stay plausible while the image corrupts. The solver still converged, only on a mirrored rig, so the fitted magnitude can match your tape measure even though the roles are reversed. Rectification built on a negative translation pairs pixels that do not correspond, which tears depth toward the frame edges while ranges in the shared center come out roughly right. Plausible numbers in the middle are not evidence of a healthy rig; they are evidence of geometry with the wrong sign. Horizontal-line artifacts after rectification point at camera order first — the checklist is in stereo rectification horizontal lines: fix camera order and baseline.
Can you anchor depth to the right image instead? Some SDKs expose a reference-image or measure-frame setting; if yours has one, that is the supported route. If not, keep the left image as the anchor: run 2D steps on the left image and deproject with the left intrinsics. Which intrinsics apply to which stream is worked through in aligned depth streams: data layout and which camera to deproject with.
Find which camera is which in one minute
Work down the causes in this order; the first explains most cases.
- Channels swapped at capture. Enumeration order is not physical position: power-up sequence, hub topology or a re-plugged cable reorders device indices, and the capture tool binds index zero to the left slot by habit rather than geometry.
- Roles carried over from another rig. A configuration that names cameras by serial can leave both channels pointing at the wrong bodies after hardware changes.
- The rig was re-mounted. A camera swapped for service changes the geometry the calibration stored.
- A mirrored mount on purpose. Rare, but if the second camera genuinely sits left of the reference, the negative sign is honest and the fix is to re-declare which camera is the reference.
Two tests settle which body is which:
- Lens-cap test. Cap one camera and watch the capture tool: the feed that goes dark identifies the body holding that channel. If the capped camera sits on the right of the rig while the software calls it left, the pair is flipped.
- Edge test. Hold a target at the far right of the scene. It lands near the right edge of the physically left camera's frame and nearer the center in the right camera's frame. Whichever channel shows it most extreme holds the physically left camera.
Bind channels by serial number, never by index. If one feed never appears at all, run the slot checks in one camera in a stereo pair shows no live image before touching calibration.
Fix the swap and recalibrate
- Run the lens-cap test and note which physical camera holds which channel.
- Swap the two camera connections, or reassign the channels by serial number in the capture configuration, so the physically left camera feeds the left input.
- Repeat the cap test inside the capture tool to confirm the new mapping took.
- Recalibrate. Expect the translation's x-component to come out positive, with a magnitude within a few percent of the tape-measured spacing.
- Verify depth against a target at a tape-measured distance — the procedure is in depth map to real distance calibration — and inspect the cloud edges; leftover tearing has its own diagnostics in warped sparse point clouds and corner noise in stereo point clouds.
- Store the two serial numbers, the measured baseline and the date with the calibration file, so the next engineer inherits a labeled rig.
Worked example: a 1.7 m baseline that calibrates at 60% coverage
Inputs, for a long-baseline rig: spacing between lens centers B = 1.70 m, measured with a tape; first-pass calibration coverage of about 60%, as the calibration tool reported.
Rule, as an estimate: coverage is limited by the geometric overlap of the two footprints at the board's distance, and every centimeter of baseline removes a centimeter of shared width.
Here W is the width each camera sees at the board's distance, in the same units as B.
Arithmetic: 0.60 = 1 − 1.70 m / W gives W = 1.70 m / 0.40 = 4.25 m. Each camera's footprint at the board was about 4.25 m wide — a wide field of view, or a board placed far out.
Decision: overlap hits zero when B equals W, so keep B at or below half the view width for 50% overlap or better. On this rig, 80% coverage needs W = 1.70 m / 0.20 = 8.5 m, an impractical board distance, or B = 0.20 × 4.25 m = 0.85 m, half the baseline. If coverage is the priority, cut the baseline roughly in half; if the 1.7 m spacing is the priority, accept the lower coverage and fill the shared view with board poses. The reason to keep a long baseline at all is precision:
with f and d in pixels and Z coming out in the units of B. Doubling B halves the depth error that disparity noise causes at a given range, which is why long-baseline rigs are built despite the coverage cost; the trade at distance is worked through in long range stereo depth accuracy and wide baseline stereo camera selection.
One boundary on the estimate: the tool's coverage figure counts valid matches as well as geometry, so treat these numbers as a planning guide. And note what this case does not show — the 60% was not caused by the flip. A swapped pair changes the sign; coverage is geometry. Fixing the roles will not raise it.
Prevention: a two-minute checklist after any rig change
- Label L and R at the connectors, on tape or tags, so the rig reads correctly without software.
- Bind channels by serial number in the capture configuration, never by enumeration order.
- Repeat the lens-cap test after any re-cabling, hub swap or camera service.
- Check the translation's sign and magnitude straight after calibration, before saving anything.
- Store the measured baseline, both serial numbers and the date with the calibration file.
- Recalibrate after any bracket, mount or lens change; a calibration is valid only for the geometry it was captured on.
Each item costs a minute and prevents the failure this page describes: a rig that calibrates successfully and still produces mirrored depth.
When a ready-made 3D sensor beats owning the calibration
Your own stereo calibration makes sense for one-off rigs, research brackets and baseline lengths no catalog sensor covers. In a production cell, purpose-built 3D sensors compute the stereo geometry inside one housing and stream depth, so the baseline's sign is never yours to debug. Examples of the type:
- Type
- Stereo / structured light
- Type
- Stereo / structured light
If you are building the pair yourself, matched global-shutter bodies are the requirement that matters. A matched pair of MV-CU020-90GC cameras — 2.5 MP, 1/1.7" global-shutter C-mount GigE units — holds rectification stable across the rig's life.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
Shortlist bodies on the area scan cameras page or the camera finder, then step through the camera configurator to match sensors, trigger and mounts to your baseline. For a second opinion on a stubborn rig, the contact page reaches the applications team, and more stereo fixes sit on the 3D topic page.
Questions
Does a negative baseline always mean the cameras are swapped?
Not always — but almost always when the magnitude matches your tape-measured spacing, because the geometry fit is real and only the roles are reversed. First check what your tool prints: some report the baseline as a positive distance alongside the translation vector; judge the sign from the vector's x-component. A genuinely mirrored mount — second camera physically left of the reference — is the honest exception.
Why do distances still look right in the middle of the scene after a flip?
The solver still converged on a consistent stereo solution, only mirrored. Depth is reported on the left image's pixel grid, so wherever the rectified pair still overlaps, plausible numbers come out. Regions the mis-rectified pair cannot match return empty or torn values, which is the corruption you see toward the edges. Plausible middle distances are not proof of health.
Can I align depth to the right image instead?
Calibration is stored relative to the reference camera, so depth natively lives on the left grid and deprojects with the left intrinsics. Some SDKs expose a reference-image or measure-frame setting; use it if you truly need right anchoring. Otherwise keep every 2D step on the left image and treat the left camera's parameters as the only ones that apply to the depth.
My baseline magnitude is wrong as well as the sign. What does that mean?
A magnitude far from your measured spacing points to a poor fit, not just a swap: too little board coverage, too few poses, or motion during capture. Fix the roles first, then recollect with the board filling the shared view from several distances and angles. Coverage and pose spread drive the translation estimate, so they decide the magnitude.


