1 The idea
A 3D camera solve finds depth by triangulation: it sees the same point from two camera positions and finds where the two rays cross. If the camera doesn’t translate, there is no parallax and no depth.
Move the “Use frame 1 and frame” slider to frame k to use more of the camera move, and watch the near rock’s depth band narrow in the top view, while the hill depth ± readout stays large. Then set Camera move to Rotation only (nodal) and notice that the band never narrows.
σ_Z ≈ Z² · σ_px / (f_px · B)2 Hands-on
Task: using the real move, get the near rock’s depth uncertainty down to 2% or less (for a 0.5 px track error).
Watch the baseline readout and the near rock’s uncertainty as you move k. Rotation only (nodal) won’t get you there.
3 Deep dive
Triangulation: two rays crossing
A tracked point in one frame only gives a direction: a ray from the camera through that pixel. The real point could be anywhere along it. A second frame, taken after the camera has moved, gives a second ray; where the two cross is the 3D position.
If the camera barely moved, the two rays are nearly parallel, and a fraction of a pixel of track error slides the crossing a long way along the ray. That is the shaded band in the top view.
- 1Track point in frame 1
- 2Same point in frame k
- 3A ray from each camera
- 4Crossing = depth
Baseline and distance
For two views, depth uncertainty is about σZ ≈ Z² · σpx / (f_px · B), where Z is distance, σpx the track error, f_px the focal length in pixels and B the baseline. Precision grows with the baseline and falls with distance squared.
In this figure, over about 0.94 m of camera travel, the near rock (about 7.4 m away) moves about 65 px on the plate and the hill (about 150 m) about 20 px. Near points give depth; far points mostly pin rotation.
| What changes | Depth uncertainty |
|---|---|
| Baseline B ×2 | Halves |
| Distance Z ×2 | About ×4 |
| Track error ×2 | ×2 |
| f_px ×2 (longer lens or more pixels) | Halves |
Rotation only: every point on a sphere
On a tripod pan the camera only turns about its own centre, so every ray starts from one spot and nothing shows parallax: there is no depth to recover. The solve can still find the rotation, but each point is known only as a direction, at any distance. The upside is that a 2D track holds anywhere in such a frame, and if no feature survives the whole pan, a 3D solve set to rotation only covers it.
A rotation-only fit is only right when the move really is nodal; if the camera also travels, it slides more than a full solve. Very far scenery is the exception: it shifts so little that it moves almost as one flat layer even when the camera travels.
Before choosing nodal, compare something near with something far: if they shift against each other, the camera isn’t nodal.
When the data is weak
With few features and almost no depth, different solvers can return wildly different focal lengths: the data can’t tell. Then lock the focal length from the camera report, solve with the camera motion the shot really has (rotation only just when the move is close to nodal), and flag the lens as an assumption.
Keep plenty of tracks alive on every frame, never just a handful, and spread them in depth. Delete sky features: clouds drift and edges against the sky are not fixed points, so they pull the solve.
4 In real work
In Nuke
- CameraTracker (NukeX): set Camera Motion to match the shot: Free Camera for a real move, Rotation Only for a nodal pan.
- Feed a Roto into the CameraTracker mask input to cut out anything that moves.
- Track, then delete sky features by hand, including unused ones.
- Solve, then check that near features (ground, rocks) are in the solve, not only far hills.
- Export a Camera; from a nodal solve, use it for far background or sky and don’t read distances from it.
Common mistakes → the fix
- ✗ Expecting a tripod-pan solve to give the depth of things✓ Treat it as a rotation-only solve and don’t read distances from it.
- ✗ Solving only on far features such as hills and sky✓ Add tracks on the near ground and rocks; rotation is fine, but depth and translation need near points.
- ✗ Leaving sky features in✓ Delete them all; clouds drift and sky edges aren’t fixed points, so they pull the solve.
- ✗ Using a rotation-only fit on a camera that also translates✓ Use the full (free-move) solve.
- ✗ Trusting one solver’s focal when solvers disagree wildly✓ Assume the lens from the camera report, solve rotation only, and flag it as an assumption.
Before you send the shot
- Checked that the camera really translates before using depth from the solve.
- Tracks are spread near and far.
- Sky features deleted and moving things masked.
- No frame drops to just a handful of tracked points.
- Nodal solve used only for a move that really is nodal.
- If the lens is assumed, it’s flagged.
5 Check yourself
In rotation-only mode, why does the near rock’s depth band never narrow, however far you slide k?
🔒 Answer the question above and this card opens
1. Same baseline, but the point is twice as far away. How does its depth uncertainty change?
2. All your tracks are on the far hills. Which part of the solve is weakest?
Where the numbers come from: A 48-frame handheld shot (640×360) rendered in Blender (Cycles) through our desert set, with a green screen on a pole and a drone flying across. Frame 1 is the still plate’s camera. Every true position comes from the scene’s own 3D (truth.json, dist.f32). Camera positions and point depths are the scene’s own truth. The depth band uses the two-view formula with an assumed 0.5 px tracking error, a teaching value not measured on a tracker; the top view is a teaching diagram.