This avoids need to do special trickery detecting whether the principal
point is to be changed when reloading movie clip. This also allows to
transfer the optical center from high-res footage to possibly its lower
resolution proxy without manual adjustment.
On a user level the difference is that the principal point is exposed in
the normalized coordinates: frame center has coordinate of (0, 0), left
bottom corner of a frame has coordinate of (-1, -1) and the right top
corner has coordinate of (1, 1).
Another user-visible change is that there is no more operator for setting
the principal point to center: use backspace on the center sliders will
reset values to 0 which corresponds to the center.
The code implements versioning in both directions, so it should be
possible to open file in older Blender versions without loosing
configuration.
For the Python API there are two ways to access the property:
- `tracking.camera.principal_point` which is measured in the normalized
space.
- `tracking.camera.principal_point_pixels` to access the pixel-space
principal point.
Both properties are not animatable, so there will by no conflict coming.
Differential Revision: https://developer.blender.org/D16573
Historically tracks and reconstruction for motion tracking camera
object were stored in the motion tracking structure. This is because
the data structures pre-dates object tracking support, and it was
never changed to preserve compatibility.
Now the compatibility code supports more tricks and allows to change
the ownership without breaking any compatibility. This is what this
change does: it moves tracks from motion tracking structure to the
motion tracking camera object, and does it in a way that no
compatibility is broken.
One of the side-effects of this change is that the active track is
now stored on motion tracking object level, which allows to change
active motion tracking object without loosing active track. Other
than that there are no expected user-level changes.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
The issue was caused by a prediction algorithm detecting tracking the
wrong way. Solved by passing tracking direction explicitly, so that
prediction will always happen correctly regardless of the state of the
Tracks context.
This change solves a bottleneck which was caused by attempt to cache
postprocessed search areas used for tracking. It was a single cache
used by all threads, which required to have some synchronization
mechanism. This synchronization turned out to be making all threads
to idle while one thread is accessing the cache. The access was not
cheap, so the multi-threading did not provide expected speedup.
Current solution is to remove the cache of search areas. This avoids
any threading synchronization overhead because there is no need for
it anymore. The downside is that for certain configurations tracking
became slower when comparing to master branch. There is no expected
slowdown compared to 2.91 release.
The slowdown is mainly experienced when using big search area and
keyframe matching strategy. Other cases should still be within a
ballpark of performance of single-threaded code prior to this change.
The reason why is it so is because while this change makes it so the
image accessors needs to process images multiple times the complexity
of this process is almost the same as all the overhead for the cache
lookup and maintenance.
Here are Some numbers gained on different configurations.
CPU: Intel Xeom CPU E5-2699 v4
OS: Linux
Footage: Old_Factory MVI_4005.mov from the first part of Track Match
Blend training which can be found on the Blender Cloud.
Tracking 443 markers across 250 frames. The unit is seconds.
File: F9433209
2.91: 401.520874
before: 358.650055
after: 14.966302
Tracking single marker across 250 frames. The unit is seconds.
File: F9433211
2.91 before after
Big keyframe 1.307203 1.005324 1.227300
Big previous frame 1.144055 0.881139 0.944044
Small keyframe 0.434015 0.197760 0.224982
Small previous frame 0.463207 0.218058 0.234172
All at once 2.338268 1.481220 1.518060
Previously image accessor was sharing array pointer for tracks access.
Now it is possible to pass a temporary array valid only during the
initialization process.
Should be no functional changes.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
This feature got lost with new auto-track API,
Added it back by extending frame accessor class. This isn't really
a frame thing, but we don't have other type of accessor here.
Surely, we can use old-style API here and pass mask via region
tracker options for this particular case, but then it becomes much
less obvious how real auto-tracker will access this mask with old
style API.
So seems we do need an accessor for such data, just matter of
finding better place than frame accessor.
The title actually tells it all, this commit switches Blender to use the new
autotrack API from Libmv.
From the user point of view it means that prediction model is now used when
tracking which gives really nice results.
All the other changes are not really visible for users, those are just frame
accessors, caches and so for the new API.
This commit makes it so CameraIntrinsics is no longer hardcoded
to use the traditional polynomial radial distortion model. Currently
the distortion code has generic logic which is shared between
different distortion models, but had no other models until now.
This moves everything specific to the polynomial radial distortion
to a subclass PolynomialDistortionCameraIntrinsics(), and adds a
new division distortion model suitable for cameras such as the
GoPro which have much stronger distortion due to their fisheye lens.
This also cleans up the internal API of CameraIntrinsics to make
it easier to understand and reduces old C-style code.
New distortion model is available in the Lens panel of MCE.
- Polynomial is the old well-known model
- Division is the new one which s intended to deal better with huge
distortion.
Coefficients of this model works independent from each other
and for division model one probably want to have positive values
to have a barrel distortion.
File tracking.c became rather huge and annoying to
maintain and it really contains several independent
areas of motrack pipeline.
Now we've got:
* tracking.c: general-purpose functions which are used
by blender, clip editor, RNA and so.
* tracking_detect.c: feature detection functions
(blender-side, logic is still in libmv).
* tracking_plane_tracker.c: blender-side 2D tracking logic.
* tracking_plane_tracker.c: plane track tracker.
* tracking_solver.c: functions for camera solving.
* tracking_stabilize.c: 2D stabilization functions.
* tracking_util.c: utility functions for all those files
and which shouldn't be public.
