1 The idea
Solve error (reprojection error) is the distance in pixels between where a track really is and where the solved camera projects its 3D point. It’s measured in the plate’s own pixels, and a good-looking average can hide a bad track.
Read each track’s error on its button and click off the ones that pull the solve. Watch the average solve error, the worst frame, the number of tracks used and the slide of the CG cones on the rocks, then switch Plate resolution to see the same solve read as different numbers.
reprojection error = | tracked 2D − projected solved 3D | (px)2 Hands-on
Task: clean the solve until the CG cones on the rocks slide no more than 1 px (at the 640 px scale), with at least 8 tracks left.
Start with the bars that stand out, then check in the plate view what that track is sitting on, and how the worst frame and the cone slide respond.
3 Deep dive
What the number measures
After a solve, each track has its own 3D point. The solved camera projects that point back onto the image on every frame. The distance between that projection and where the track actually found the feature is the reprojection error for that track on that frame.
The single number a solver shows is usually an average or RMS over all tracks and frames. It’s a summary, and it doesn’t tell you where the problem is.
- 1Solved 3D point
- 2Camera projects it
- 3Compare with 2D track
- 4Distance in px
- 5Average over tracks and frames
Pixels depend on resolution
The same camera mistake covers more pixels on a wider plate, so the same solve reads bigger as the plate gets wider. An error number without a resolution means very little.
No single number fits every shot: the reading depends on the plate’s resolution, the solver and the shot itself. Compare only at the same resolution.
| Plate width | Same error reads |
|---|---|
| 640 | ×1 |
| 1920 | ×3 |
| 3840 | ×6 |
The average hides the bad track
Least squares weighs big misses heavily, so one bad track can pull the camera off and spike the error on its frames. Averaged with many good tracks, though, the overall number may still look fine.
Read the per-track errors and the per-frame error curve, looking for spikes or a steady climb. A slowly slipping track climbs; a track that jumps after an occlusion spikes.
Some solvers let you set a track’s weight to 0: it no longer drives the camera, but still reports its error as a check on that area.
Which tracks to cut
A camera solve assumes the world is still. Tracks on something that moves on its own, or that don’t stay on the same feature, disagree with all the others and pull the camera. Sky points have no fixed depth and can make the track slide; delete them even if the solver isn’t using them.
But don’t delete just to make the number pretty. Every frame still needs enough good tracks to solve. Cut too many and the solve runs short of data and gets worse in ways the number may not show.
| Track | Sign | What to do |
|---|---|---|
| On a moving thing (drone) | High error throughout | Mask it out or turn it off |
| Slipping off its feature | Error climbs slowly | Turn off or re-track |
| Jumps after occlusion | Spike on some frames | Cut the bad range or turn off |
| In the sky | No real depth | Delete |
The number isn’t the final test
The average reprojection error doesn’t measure how stable the shot looks. A solve with a low average can still swim if some frames jitter or some 3D points are solved in the wrong place. Check stability frame by frame, and put CG on the ground and watch it play.
Judge by the cone not sliding, not by a pretty number.
4 In real work
In Nuke
- Roto → into the CameraTracker (NukeX) mask input to keep moving things and sky out before tracking.
- After the solve, open the AutoTracks tab and read the per-frame error (Solve Error / per frame) for spikes.
- Lower Max Error and Max Track Error, press Delete Rejected and Delete Unsolved, then Update Solve, and repeat.
- Remove points that sit in the sky yourself, including the ones the solver has already left out (shown orange).
- Export the Camera → Scene with a checkerboard Card on the ground → ScanlineRender, Merge (over) onto the plate and play it to check for slide.
Common mistakes → the fix
- ✗ Quoting an error number without the plate resolution✓ Always give the resolution, and compare at the same width.
- ✗ Judging only the average and missing one bad frame or track✓ Read per-track errors and the per-frame curve, then watch CG on the ground.
- ✗ Deleting tracks until the number looks good✓ Remove only tracks with a reason, and keep enough good tracks on every frame.
- ✗ Keeping tracks on moving objects in a camera solve✓ Mask the moving thing out or turn those tracks off.
- ✗ Leaving sky points in because the solver isn’t using them✓ Delete them; sky points have no fixed depth.
Before you send the shot
- The reported error comes with the plate resolution.
- The per-frame error curve has no unexplained spikes.
- No tracks are left on moving things or in the sky.
- Every frame still has enough good tracks to solve.
- CG on the ground doesn’t slide when the whole shot plays.
5 Check yourself
A colleague’s solve reads 6 times the error of yours, but theirs is on a 3840-wide plate and yours on 640. What can you conclude?
🔒 Answer the question above and this card opens
1. The average error looks good, but the CG cone slides on just a few frames. What do you do first?
2. One track sits on a drone flying through the shot. What should you do with it in a camera solve?
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). A teaching solve computed in your browser: the 3D points are fixed at the scene’s true positions and only the camera (6 numbers per frame) is solved by least squares from the 2D tracks, which are the true positions plus seeded noise of 0.25 px and three deliberately bad tracks. A real solver also estimates the 3D points and the lens.