{"course":{"slug":"motion-and-audio","title":"Motion, Sound and Music","url":"https://addaly.com/learn/motion-and-audio","level":"intermediate","track":"create"},"lesson":{"slug":"camera-solve-and-parallax","title":"Solving for a camera, and when you cannot","url":"https://addaly.com/learn/motion-and-audio/camera-solve-and-parallax","position":35,"of":72,"minutes":11,"answer":"A camera solve triangulates depth from parallax, so a purely rotating camera carries no depth information at all and can only be solved as a nodal pan; and reprojection error in pixels.","keyIdea":"A camera solve triangulates depth from parallax, so a purely rotating camera carries no depth information at all and can only be solved as a nodal pan; and reprojection error in pixels, not the look of the point cloud, is the number that says whether the solve will hold."},"body":{"format":"markdown","text":"## From flat tracks to a camera in space\n\nA 2D track tells you where a feature moved on the screen. A **camera solve** (also called matchmoving or a 3D track) works out where the camera was in three dimensions on every frame, and where a cloud of tracked points sits in the world. Once you have that, you can put a 3D object into the shot and it will stay put as the camera moves, with correct perspective.\n\nThe solver is doing structure from motion: it has many features, each seen from many camera positions, and it searches for the set of 3D point positions and camera poses that best explains all the 2D observations at once. The measure of \"best\" is **reprojection error**: project each solved 3D point back through each solved camera and measure how far it lands from where the feature actually was, in pixels.\n\nThat number is the one thing to look at. Under about 0.5 pixels on a 1080p plate is a solve you can build on. Between 1 and 2 is marginal and will slide. Above 3, something is wrong and no amount of adding more tracks will fix it.\n\n## The limitation that surprises everybody\n\n**A camera that only rotates cannot be solved for 3D.**\n\nIf the camera is on a tripod and pans, every feature in the frame moves in a way that depends only on the rotation. A near object and a distant mountain shift by the same amount on the sensor. There is no parallax, so there is no depth information, so the solver has nothing to triangulate with. It is not a software limitation: the information does not exist in the footage.\n\nThis is why solvers offer a separate **nodal** or **tripod** mode: it solves rotation only, gives you no point cloud and no translation, and is entirely adequate for adding a distant element like a sky replacement or a far-off building. What it cannot do is let you place an object on the floor in front of the camera, because there is no floor in the solution.\n\nThe practical consequence on set: **if you want a 3D solve, move the camera sideways.** Even a metre of lateral movement over a shot turns an unsolvable pan into a solvable one. A handheld shot usually solves well for precisely this reason: the operator's sway supplies parallax for free.\n\n## What the solver needs from you\n\n**Enough tracks, spread through depth.** Twenty to forty good tracks is typical. They must not all be on one plane: tracks that all sit on a flat wall give an ambiguous solution, because a plane seen from different angles has multiple consistent interpretations. Get near objects and far objects in the set.\n\n**Tracks that last.** A solve is stronger when features persist across many frames, because each one is then constraining many camera positions. A shot where every track lives for eight frames is a weak solve even if there are two hundred of them.\n\n**The focal length, if you have it.** Solving for the focal length as well as the geometry is possible and less accurate. If you know the lens was 35mm on a Super 35 sensor, tell the solver and it has one fewer unknown. Most modern cameras and phones record the focal length in metadata; `exiftool` will read it out of the file, free.\n\n**Lens distortion handled.** A real lens bends straight lines, most visibly at wide angles. The solver assumes a pinhole camera. If you feed it distorted footage, the error shows up as a solve that fits the centre of frame and drifts at the edges. The standard workflow is: estimate the distortion, undistort the plate, solve and composite on the undistorted image, then redistort the finished comp so it matches the original lens. Blender, Fusion and Nuke all have this loop, and skipping it is a common cause of an insert that looks glued on near the frame edge.\n\n## Setting the scene up afterwards\n\nA solve gives you a camera and a point cloud in arbitrary units, with an arbitrary origin and orientation. It does not know which way is up or how big anything is. Before you can place an object you have to constrain it:\n\n- Pick three or more points you know lie on the ground and define them as the floor plane.\n- Pick two points a known distance apart and set the scale: the gap between two paving slabs, a person's height, a door.\n- Set an origin so your scene's coordinates are meaningful.\n\nSkipping this is why a first solve produces a cube that drifts through the floor at forty-five degrees.\n\n## Checking the solve honestly\n\nDo not judge it by looking at the error number alone. Put a simple 3D object in the scene (a grid on the floor, a cube on a surface, a sphere at a tracked point) and play the shot at full speed. A solve with acceptable numbers can still slide if the distortion was not handled or the scene orientation is slightly off, and playback shows it in a second.\n\nThen check the individual track errors and delete the worst offenders. A single bad track with a large error can distort the whole solution, and removing three bad tracks is usually worth more than adding thirty good ones.\n\n## The free path\n\n**Blender** has a complete matchmoving pipeline: 2D tracking, lens distortion estimation, a camera solver with per-track error readout, scene orientation tools, and then the 3D scene and compositor in the same application. It is used on real productions and costs nothing. This is a case where the free tool is a first-class option rather than a compromise. **COLMAP** and **Meshroom** are open-source structure-from-motion packages aimed at photogrammetry that can also produce camera solutions. PFTrack, 3DEqualizer and SynthEyes are the paid specialists.\n\n## The limitation\n\nA solve describes a rigid world seen by a moving camera. Anything in the scene that moves independently is a contaminant, and the solver has no way to know which tracks are on the moving car and which are on the road. You remove them by hand, and on a busy shot that is most of the work.\n\nRolling shutter is the other reliable spoiler. Most CMOS cameras expose the frame line by line over several milliseconds, so during fast movement the top and bottom of the frame are from different moments and straight verticals lean. A solver assuming a global shutter fits an average that is wrong everywhere. Some tools compensate; the compensation is a model, not a measurement, and heavy rolling shutter remains a reason a shot cannot be solved to a usable error."},"check":{"question":"A shot filmed from a locked-off tripod, panning left to right, will not solve for a 3D camera. Adding more tracks and running the solver again does not help. Why?","options":[{"text":"The tracks are all moving in the same direction at the same rate, so the solver cannot distinguish camera rotation from a uniform translation of the whole scene.","correct":false,"tempting":"Names an ambiguity between two motions, when the actual problem is that depth cannot be recovered from rotation at all."},{"text":"Under pure rotation, near and distant features shift identically on the sensor, so there is no parallax to triangulate depth from and the information is absent from the footage.","correct":true},{"text":"Tripod shots are usually shot at a longer focal length, and the solver cannot estimate a long focal length reliably without being given it in advance.","correct":false,"tempting":"Focal length estimation is genuinely harder on long lenses, but supplying it does not make a nodal pan solvable."},{"text":"The solver needs tracks that persist across many frames to constrain each camera position, and a pan continuously moves features out of frame, so no track survives long enough to contribute to more than a handful of camera poses in the solution.","correct":false,"tempting":"Track lifetime does weaken a solve, but a slow pan with long-lived tracks still cannot be solved in 3D."}]},"prev":{"slug":"tracking","title":"What a tracker can and cannot see","url":"https://addaly.com/learn/motion-and-audio/tracking"},"next":{"slug":"matching-the-plate","title":"Black level, grain, focus, and the order to do them in","url":"https://addaly.com/learn/motion-and-audio/matching-the-plate"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Solving for a camera, and when you cannot', in Motion, Sound and Music. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/motion-and-audio/camera-solve-and-parallax (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Solving for a camera, and when you cannot","courseTitle":"Motion, Sound and Music","module":{"index":4,"slug":"putting-two-images-together","title":"Putting two images together"},"answer":null,"keyIdea":"A camera solve triangulates depth from parallax, so a purely rotating camera carries no depth information at all and can only be solved as a nodal pan; and reprojection error in pixels, not the look of the point cloud, is the number that says whether the solve will hold.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"from-flat-tracks-to-a-camera-in-space","runs":[{"text":"From flat tracks to a camera in space"}]},{"t":"p","runs":[{"text":"A 2D track tells you where a feature moved on the screen. A "},{"text":"camera solve","b":true},{"text":" (also called matchmoving or a 3D track) works out where the camera was in three dimensions on every frame, and where a cloud of tracked points sits in the world. Once you have that, you can put a 3D object into the shot and it will stay put as the camera moves, with correct perspective."}]},{"t":"p","runs":[{"text":"The solver is doing structure from motion: it has many features, each seen from many camera positions, and it searches for the set of 3D point positions and camera poses that best explains all the 2D observations at once. The measure of “best” is "},{"text":"reprojection error","b":true},{"text":": project each solved 3D point back through each solved camera and measure how far it lands from where the feature actually was, in pixels."}]},{"t":"p","runs":[{"text":"That number is the one thing to look at. Under about 0.5 pixels on a 1080p plate is a solve you can build on. Between 1 and 2 is marginal and will slide. Above 3, something is wrong and no amount of adding more tracks will fix it."}]},{"t":"h2","id":"the-limitation-that-surprises-everybody","runs":[{"text":"The limitation that surprises everybody"}],"role":"limit"},{"t":"p","runs":[{"text":"A camera that only rotates cannot be solved for 3D.","b":true}]},{"t":"p","runs":[{"text":"If the camera is on a tripod and pans, every feature in the frame moves in a way that depends only on the rotation. A near object and a distant mountain shift by the same amount on the sensor. There is no parallax, so there is no depth information, so the solver has nothing to triangulate with. It is not a software limitation: the information does not exist in the footage."}]},{"t":"p","runs":[{"text":"This is why solvers offer a separate "},{"text":"nodal","b":true},{"text":" or "},{"text":"tripod","b":true},{"text":" mode: it solves rotation only, gives you no point cloud and no translation, and is entirely adequate for adding a distant element like a sky replacement or a far-off building. What it cannot do is let you place an object on the floor in front of the camera, because there is no floor in the solution."}]},{"t":"p","runs":[{"text":"The practical consequence on set: "},{"text":"if you want a 3D solve, move the camera sideways.","b":true},{"text":" Even a metre of lateral movement over a shot turns an unsolvable pan into a solvable one. A handheld shot usually solves well for precisely this reason: the operator’s sway supplies parallax for free."}]},{"t":"h2","id":"what-the-solver-needs-from-you","runs":[{"text":"What the solver needs from you"}]},{"t":"p","runs":[{"text":"Enough tracks, spread through depth.","b":true},{"text":" Twenty to forty good tracks is typical. They must not all be on one plane: tracks that all sit on a flat wall give an ambiguous solution, because a plane seen from different angles has multiple consistent interpretations. Get near objects and far objects in the set."}]},{"t":"p","runs":[{"text":"Tracks that last.","b":true},{"text":" A solve is stronger when features persist across many frames, because each one is then constraining many camera positions. A shot where every track lives for eight frames is a weak solve even if there are two hundred of them."}]},{"t":"p","runs":[{"text":"The focal length, if you have it.","b":true},{"text":" Solving for the focal length as well as the geometry is possible and less accurate. If you know the lens was 35mm on a Super 35 sensor, tell the solver and it has one fewer unknown. Most modern cameras and phones record the focal length in metadata; "},{"text":"exiftool","code":true},{"text":" will read it out of the file, free."}]},{"t":"p","runs":[{"text":"Lens distortion handled.","b":true},{"text":" A real lens bends straight lines, most visibly at wide angles. The solver assumes a pinhole camera. If you feed it distorted footage, the error shows up as a solve that fits the centre of frame and drifts at the edges. The standard workflow is: estimate the distortion, undistort the plate, solve and composite on the undistorted image, then redistort the finished comp so it matches the original lens. Blender, Fusion and Nuke all have this loop, and skipping it is a common cause of an insert that looks glued on near the frame edge."}]},{"t":"h2","id":"setting-the-scene-up-afterwards","runs":[{"text":"Setting the scene up afterwards"}]},{"t":"p","runs":[{"text":"A solve gives you a camera and a point cloud in arbitrary units, with an arbitrary origin and orientation. It does not know which way is up or how big anything is. Before you can place an object you have to constrain it:"}]},{"t":"ul","items":[[{"text":"Pick three or more points you know lie on the ground and define them as the floor plane."}],[{"text":"Pick two points a known distance apart and set the scale: the gap between two paving slabs, a person’s height, a door."}],[{"text":"Set an origin so your scene’s coordinates are meaningful."}]]},{"t":"p","runs":[{"text":"Skipping this is why a first solve produces a cube that drifts through the floor at forty-five degrees."}]},{"t":"h2","id":"checking-the-solve-honestly","runs":[{"text":"Checking the solve honestly"}]},{"t":"p","runs":[{"text":"Do not judge it by looking at the error number alone. Put a simple 3D object in the scene (a grid on the floor, a cube on a surface, a sphere at a tracked point) and play the shot at full speed. A solve with acceptable numbers can still slide if the distortion was not handled or the scene orientation is slightly off, and playback shows it in a second."}]},{"t":"p","runs":[{"text":"Then check the individual track errors and delete the worst offenders. A single bad track with a large error can distort the whole solution, and removing three bad tracks is usually worth more than adding thirty good ones."}]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"Blender","b":true},{"text":" has a complete matchmoving pipeline: 2D tracking, lens distortion estimation, a camera solver with per-track error readout, scene orientation tools, and then the 3D scene and compositor in the same application. It is used on real productions and costs nothing. This is a case where the free tool is a first-class option rather than a compromise. "},{"text":"COLMAP","b":true},{"text":" and "},{"text":"Meshroom","b":true},{"text":" are open-source structure-from-motion packages aimed at photogrammetry that can also produce camera solutions. PFTrack, 3DEqualizer and SynthEyes are the paid specialists."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"A solve describes a rigid world seen by a moving camera. Anything in the scene that moves independently is a contaminant, and the solver has no way to know which tracks are on the moving car and which are on the road. You remove them by hand, and on a busy shot that is most of the work."}]},{"t":"p","runs":[{"text":"Rolling shutter is the other reliable spoiler. Most CMOS cameras expose the frame line by line over several milliseconds, so during fast movement the top and bottom of the frame are from different moments and straight verticals lean. A solver assuming a global shutter fits an average that is wrong everywhere. Some tools compensate; the compensation is a model, not a measurement, and heavy rolling shutter remains a reason a shot cannot be solved to a usable error."}]}],"check":{"question":[{"text":"A shot filmed from a locked-off tripod, panning left to right, will not solve for a 3D camera. Adding more tracks and running the solver again does not help. Why?"}],"options":[{"text":[{"text":"The tracks are all moving in the same direction at the same rate, so the solver cannot distinguish camera rotation from a uniform translation of the whole scene."}],"correct":false,"tempting":[{"text":"Names an ambiguity between two motions, when the actual problem is that depth cannot be recovered from rotation at all."}]},{"text":[{"text":"Under pure rotation, near and distant features shift identically on the sensor, so there is no parallax to triangulate depth from and the information is absent from the footage."}],"correct":true,"tempting":null},{"text":[{"text":"Tripod shots are usually shot at a longer focal length, and the solver cannot estimate a long focal length reliably without being given it in advance."}],"correct":false,"tempting":[{"text":"Focal length estimation is genuinely harder on long lenses, but supplying it does not make a nodal pan solvable."}]},{"text":[{"text":"The solver needs tracks that persist across many frames to constrain each camera position, and a pan continuously moves features out of frame, so no track survives long enough to contribute to more than a handful of camera poses in the solution."}],"correct":false,"tempting":[{"text":"Track lifetime does weaken a solve, but a slow pan with long-lived tracks still cannot be solved in 3D."}]}],"order":[0,3,2,1],"why":null},"prev":{"slug":"tracking","title":"What a tracker can and cannot see","minutes":10},"next":{"slug":"matching-the-plate","title":"Black level, grain, focus, and the order to do them in","minutes":11}}}