Dev:Ref/Release Notes/2.67/Motion Tracker
目次
Blender 2.67: Motion Tracker
Dopesheet View
The Dopesheet view had a minor interface improvement and is now highlighting the background depending on the number of tracks in a frame (r54750). This means that if for a frame (or sequence of frames) there're less than 8 tracks, the background will turn red; if there are from 8 to 16 tracks, the background will be yellow.
This is only a visual feedback, which doesn't mean that the camera motion won't reconstruct with less than 8 tracks. It only means that the user should pay attention to those frames and check if all possible good feature points are tracked there. Remember, if there are no good feature points in the frame and there are less than 16 tracks in the frame, it doesn't mean the solution won't be accurate. Rather, adding more tracks on crappy feature points will reduce the accuracy of solution.
Bundle Adjustment
Bundle adjustment (a step of camera motion solving which improves solution by minimizing reprojection error affecting on 3D markers and cameras position) was rewritten from scratch using Ceres non-linear least square minimizer library (r54859).
It is now considered more accurate, which for artists means reprojection error would be smaller than in previous versions.
This allowed implementing additional features, as:
- Refining radial distortion coefficients without affecting on focal length (r54881)
- Refining tripod camera motion (r54932)
Tripod Solver
Tripod solver was also rewritten from scratch, and also uses Ceres library now (r54932).
Because of using Ceres library and bundle adjustment step tripod solver became much more accurate for calibrated camera shots. For uncalibrated camera shots (when distortion coefficients or focal length are not exactly known), refining of camera intrinsics is now possible.
Please note, that this is special type of camera solver and it behaves different from regular solver. It means using more tracks doesn't imply more accurate solution. Having 5-10 tracks on frame is likely what shall be commonly used for this kind of solver.
Proxies
Proxies are now preparing frames in multiple threads, which makes it's faster on multi-core systems (r55302, r55311)
Please note, that it's only frame calculation which is threaded. Writing files on dist is still single-threaded and could not be multithreaded, so building proxies is still limited by HDD bandwidth.
Prefetching
Multithreaded frames prefetching was implemented for movie clip editor (r55448, r55459, r55773).
In fact, it's not real prefetching in it's movie players understanding. It is an operator which is invoking by P and which fills cache with frames. As many frames as fits into cache are load form the disk.
This allows to fill in the cache as fast as possible when you really need to track something, but this keeps CPU and HDD bandwidth idle if you've got clip editor opened but not actually interacting with it.
Smaller Features
- View All operator for motion tracking dopesheet (r55052)
- Added Alpha output socket to Movie Clip input node for compositor (r55402)
- Use checker backdrop for footage with alpha in Clip Editor (r55404)
- Cache is now freeing when switching movie clips, so the whole RAM is available for the clip you're currently working with (r55774)
- Jump to start/end of tracked segment works in Mask editing mode now (r55785)
- Switching between clips or changing proxy render size will free cache used by previous settings, leaving the whole memory for active setup (r55774)
- Use checker backdrop for footage with alpha channel in clip editor (r55404)
Fixes
- Fixed memory leak when opening multilayer EXR images, (r54934). This kind of images wouldn't actually work in clip editor, but at least it wouldn't eat computer's memory.
- Fixed subpixel precision in some trackers, (r55028)
- Refresh dopesheet when switching/deleting object, (r55079)
- 2D stabilization was broken for a while, which resulted in nearest interpolation used if there's no rotation, also stable image buffer used to be re-generated on every redraw. This behaves correct now. As an additional stable frame calculation is threaded now (r55901)
