What "Some data failed to reconstruct" means

When libmv finishes solving, Blender copies the result into the movie clip in reconstruct_retrieve_libmv_tracks() (tracking_solver.cc). It asks for a 3D position for every track and a camera for every frame from the first to the last tracked frame. Each track without a position and each frame without a camera is printed to the console, and the function reports that something is missing. The Solve Camera operator then shows this warning instead of the usual Average re-projection error message (tracking_ops_solve.cc).

The solve is not thrown away. Blender marks the reconstruction as valid and stores the average error before this step (tracking_solver.cc), so the header still shows Solve error, and every camera and bundle that did solve stays in the clip. Compare that with Failed to solve the motion: most likely there are no good keyframes, which means the whole solve failed, and with the 8 common tracks error, which stops the solve before it starts.

How to open the console and read it

  1. 1
    Open the console

    On Windows, use Window > Toggle System Console; the entry only exists on Windows (manual). On macOS and Linux, start Blender from a terminal and the messages print there.

  2. 2
    Solve again

    Click Solve Camera Motion once more, so the console shows fresh output for your current tracks.

  3. 3
    Read the track lines

    Unable to reconstruct position for track #12 'Track.012' names a track with no bundle. The number is the track's position in the list, counted from 0. Search for the name in quotes.

  4. 4
    Read the frame lines

    No camera for frame 214 names a frame the solver could not place a camera on. It is a clip frame number, which equals the scene frame when the clip's Start Frame is 1.

You may also see lines containing POINT BEHIND CAMERA. They come from libmv's triangulation (intersect.cc) and mean a track's 3D point landed behind one of the cameras, so it was rejected. For the full solver log, start Blender with the --debug-libmv command line argument. It is verbose, but it shows how many solved tracks each frame had and which frames could not be placed.

Why tracks fail to reconstruct

To give a track a bundle, libmv triangulates it from its markers on frames that already have a solved camera. It needs at least two such frames (pipeline.cc), and the resulting point must sit in front of every camera that sees it. Tracks fail when they cannot meet that:

  • Too short. A track with a marker on a single frame cannot be triangulated. Detect Features leaves these behind when you detect on a frame and never track the new markers.
  • Only on unsolved frames. A track that lives entirely at the start or end of the clip, where no camera could be solved, never sees two solved cameras.
  • No parallax. Sky, clouds, distant hills and features near the vanishing point barely shift as the camera moves. Their depth is almost undefined, and noise can push the point behind the camera.
  • Bad tracks. A track that jumps between features or slides along an edge triangulates to a nonsense position. Sometimes it fails, sometimes it gets a bundle with a high error, so check both.
Telephoto example frame where trees at different distances show very little relative movement
On a long lens, trees at different distances barely move relative to each other. Tracks with this little parallax carry almost no depth information, so they are the first to fail.

Why frames get no camera

libmv places a camera on a frame by resection, and it only tries when at least 5 tracks that already have bundles are visible on that frame (pipeline.cc). Frames that never reach five get no camera. The usual places are the start and end of the clip, where tracks have not started yet or have already died, whip pans, heavily motion blurred stretches and moments when something covers most of the frame.

The range the solver has to fill is not the scene frame range. It runs from the first to the last enabled marker of any track in the tracking object (tracking_solver.cc). One stray track that continues 100 frames past the others stretches that range, and every frame it covers alone becomes No camera for frame. After the solve, unsolved frames show as a thin red strip along the bottom of the Clip editor.

Is the solve still usable?

What failedEffect on the cameraWhat to do
A few tracksNone. Those tracks simply have no 3D pointUsually safe to delete them and move on
Many tracksFewer points hold the solve togetherCheck focal length, keyframes and a test object before trusting it
Frames at the start or endThe camera holds the nearest solved poseTrim those frames from the shot, or add tracks that cover them
Frames in the middleThe camera is blended between the solved frames on either sideNot usable for VFX on those frames. Add tracks and solve again
How the Camera Solver constraint behaves on frames without a solved camera, from tracking.cc.

Failed tracks also have no bundle, so you cannot use them for Floor, Set Origin or Set Scale. If Set Floor complains about bundles, this is often why.

Blender camera view with the footage as background, used to check that the solved camera matches the shot
Check a solve through the camera: the reconstructed points should stay glued to their features for the whole shot, including the frames the console listed.

How to clean up failed tracks

  1. 1
    Select them

    Choose Select > None, then Select > Select Grouped > Failed Tracks (Shift+G in the Clip editor). It selects every track of the active tracking object that has no bundle.

  2. 2
    Look before you delete

    Scrub through the shot. Tracks on sky, distant detail or moving things can go. A good ground track that was only too short is worth tracking further instead.

  3. 3
    Delete or extend

    Press X to delete the selection, or extend the useful tracks with Track Motion and keep them.

  4. 4
    Solve again

    Click Solve Camera Motion. If the console only lists tracks you have decided to keep, you can stop there.

How to fix frames with no camera

  • Add tracks where coverage drops. Go to the first failed frame, run Detect Features and track the new markers in both directions. In the Dope Sheet view, frames with fewer than eight tracks have a red background.
  • Stagger track lifetimes. If many tracks die on the same frame, the following frames lose their support at once. Start new tracks before the old ones end.
  • Remove stray tracks that run far beyond the rest of the shot.
  • Trim what cannot be solved. A whip pan or a burst of motion blur at the end of a shot is often better cut than solved.
  • Use Tripod for rotation-only shots, where a normal solve has no parallax to place cameras with. See camera vs planar vs tripod tracking.

MotionMaster 3D reports the same thing as a number. After a Heavy Tracking run, Reg in the Last Result box is the share of frames that got a camera, and 100% means every frame is solved. If a clip falls short, the docs recommend moving to a higher preset before changing individual parameters.