Spinal Path Editing

Spinal Path Editing

Since it can be tedious to repeatedly change coordinate system setups, SynthEyes can dynamically recompute portions of a solve as you change certain values.

Warning: this is a really advanced topic. It can be used quickly and easily, especially Align mode, but it can just as quickly reduce your solve to rubble. We’re not kidding, this thing is complicated!

First, what is “spinal editing” and why is it called that? Spinal editing is designed to work on an already-solved track, where you have an existing camera or object path to manipulate. The path is the spine that we edit. It is spinal because you can think of the trackers as being attached to it like ribs. If you manipulate the spine, the ribs move in response. You’ll be working on the spine to improve or reposition it. The perspective window's local-coordinate-system and path-relative handles can help make specific adjustments to the camera path.

After you have completed an initial solve producing a camera path, you can initiate spinal editing by launching the control panel with the Window/Spinal Editing menu item. This will open a small spinal control panel. You can also enable spinal editing with the Edit/Spinal aligning and Edit/Spinal solving menu items, though then you lose the feedback from the control panel.

There are two basic modes, controlled by the button at top left of the spinal control panel: Align and Solve.

Note that the recalculations done by spinal editing are launched only in response to a specific relatively small set of operations:

·         dragging the camera or object in a 3-D viewport or perspective view,

·         dragging the “seed point” (lock coordinates) of a properly-configured tracker in a 3-D viewport or perspective view,

·         changing the field of view spinner on the lens control panel or soft-lock panel.

·         changing the weight control on the spinal editing dialog.

In order for a tracker's seed point to be dragged and used for spinal alignment, it must be set to Lock Point mode.

Spinal Align Mode

In Align mode, your path is moved around as the coordinate system is repeatedly updated, but the shape of the path and the relationship to the trackers is not affected. The RMS error of the solve is unchanged. This can be a nice way to help get that specific coordinate system alignment you want; it allows a mixture of object and tracker constraints.

You can use a combination of locks on the camera and on trackers in the scene. As you drag the camera or tracker, the alignment will be repeatedly recalculated. Use the figure of merit value to keep track of whether you have an overconstrained setup: the value is normally very small, such as 0.000002. If it rises much above that, you don’t have a minimal set of constraints (typically it reaches 0.020–0.050). That is not a problem—unless you begin solving with the Constrain checkbox on.

Note that all camera and object locks are treated as hard locks by the alignment software.

Spinal Solve Mode

In Solve mode, you are changing the solve itself, generally by adding constraints on the camera path, then re-solving. The RMS error will always get worse! But it lets you interactively repair weak spots in your solve.

The spinal solve performs a Refine operation on your existing solution, meaning that it makes small changes to that solution. If the constraints you add after the initial solve, either directly or by dragging with the spinal solve mode, change the solution too much, then you will get a solution that is “the best solution near the old solution” rather than the best overall solution, which you would obtain by starting the solve from scratch (ie Automatic solving mode).

To maintain interactive response rates, the spinal solve panel allows you to terminate the refine operation early—and while dragging you’re just going to be changing things again anyway. When you stop dragging, SynthEyes will perform a last refine cycle to allow the refine to complete, although you can also keep it from taking too long. After you’ve been moving around for a bit, especially if your solves are not completing all the way, you can click the Finish button to launch a final normal Refine cycle (Finish is the same as the Go button on the solver panel).

Spinal editing might be used in especially subtle ways on long shots. Match-moving inherently produces local “rate of change” measurements, and small random errors (often amplified by small systematic effects such as lens distortion or off-center optic axis) accumulate to produce small twists in the geometry by the end of a long traveling shot. If you have GPS or survey data you can easily fix this using a few locks. But survey data is not always available.

These accumulating errors can be particularly problematic when a long shot loops back onto itself. Suppose a shot starts with a building site for a house, showing the ground where it will be. The shot flies past the house, loops around, then approaches from the side. However, the side view does not include the ground, but only some other details not visible from the front. The inserted house is now seen at an incorrect location, perhaps slanted a bit. The path needs to be bent into shape, and spinal path editing can help you achieve that.

Please keep in mind that the results of these manipulated solves are generally not the same result you would obtain if you started the solve again from scratch in Automatic solving mode. You might consider re-starting the solve periodically to make sure you’re not doing a whole lot of work on a marginal solution.

Using soft locks and spinal editing mode is a black art made available to those who wish to use it, for whatever results can be obtained with it. It is a tool that affects the solver in a certain way. There is no guarantee that it will do the specific thing that you want at this moment. If it does not do what you think it “should be doing,” it is not a bug.