| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
There are two main things.
First, remove the marker index caching. Thins makes it possible to
safely use function from a threaded environment.
Second, replace linear search with binary search, which speeds up
random lookup.
There is no measurable difference in the stabilization which had a
comment about caching nature of track lookup. The random lookup
complexity changed from O(N) to O(log N). In practice this also
unlikely to be measurable, but thread-safety worth it.
|
|
These properties are unused and serve no purpose.
Reviewed By: sergey, #motion_tracking
Differential Revision: https://developer.blender.org/D9803
|
|
Wrong comment was used for enumerator.
Also made it a real typed enumerator to ease use in the implementation
code.
Should be no functional changes.
|
|
|
|
Make unit more explicit.
Ideally would be "embedded" into the field name itself, but this will be
more involved change.
|
|
Some DNA headers already did this, most did not. Even though many of them would
be included in C++ files and thus compiled as C++. This would be confusing and
developers may think they have to add `extern "C"` too a whole lot of
(indirect) includes to be able to use a C header in C++.
However, this is a misconception.
`extern "C"` does not cause code to be compiled with C rather than C++! It only
causes the linker to not use C++ function name mangling. See
https://stackoverflow.com/a/1041880.
Because extern DNA headers don't have function declarations, using `extern "C"`
actually should not have any effect. On the other hand, adding it causes no
harm and avoids confusion. So let's just have it consistently in C header
files.
Differential Revision: https://developer.blender.org/D9578
Reviewed by: Bastien Montagne, Sybren Stüvel
|
|
Previously, only predefined and limited set of intrinsics combinations
could have been refined. This was caused by a bundle adjustment library
used in the early days of the solver.
Now it is possible to fully customize which intrinsics are to be refined
during camera solving. Internally solver supports per-parameter settings
but in the interface they are grouped as following:
* Focal length
* Optical center
* Radial distortion coefficients (which includes k1, k2, k3, k4)
* Tangential distortion coefficients (which includes p1, p2)
Differential Revision: https://developer.blender.org/D9294
|
|
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
|
|
Implemented Brown-Conrady lens distortion model with 4 radial and
2 tangential coefficients to improve compatibility with other software,
such as Agisoft Photoscan/Metashapes, 3DF Zephir, RealityCapture,
Bentley ContextCapture, Alisevision Meshroom(opensource).
Also older programs: Bundler, CPMVS.
In general terms, most photogrammetric software.
The new model is available under the distortion model menu in Lens
settings.
For tests and demos check the original patch.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9037
|
|
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
|
|
Neither Nuke nor Natron support OpenCV's radial distortion model
which makes it impossible to have any kind of interoperability.
The new model is available under the distortion model menu in Lens
settings.
Differential Revision: https://developer.blender.org/D7484
|
|
|
|
One of the corrections from last cleanup was wrong.
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
Avoids mixing these in with regular variables in code-completion.
Use char for pad members except for 'void *', to make size clearer.
Removed/shrink a few redundant padding vars which were >= 8 bytes.
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
|
|
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.
|
|
Done using:
source/tools/utils_maintenance/c_sort_blocks.py
|
|
Without this clang-format may wrap them onto a single line.
|
|
Prevents clang-format wrapping text before comments.
|
|
Needed for clang-format in some cases, see: T53211
|
|
Differential Revision: https://developer.blender.org/D3719
|
|
For now simply reshuffle option so they keep proper dependency flow.
Benefits:
- Has an ability to hide tracks lists to work with other sliders around.
Could be really handy to quickly get rid of lenghty lists.
- From a feedback seems to be fitting workflow better.
Things to doublecheck on:
- Feels a bit misordered: first you define whether one want to have
rotation stabilized, then have tracks, then scale options.
While this follows dependency flow (which is really good and which
we should not violate) it has weird feeling on whether things are
really where they have to be.
- Autoscale controls visibility of max-scale, can we just make it
active/inactive instead?
- Autoscale replaces slider with label. Can it be disabled slider
instead to reduce visual jumping (disabled slider prevents user
input)
Hopefully we'll still want to have collapsable box after re-iterating
over this points, so we don't waste bits in DNA.
|
|
bottom
|
|
See this page for motivation and description of concepts:
https://github.com/Ichthyostega/blender/wiki
See this video for UI explanation and demonstration of usage
http://vimeo.com/blenderHack/stabilizerdemo
This proposal attempts to improve usability of Blender's image stabilization
feature for real-world footage esp. with moving and panning camera. It builds
upon the feature tracking to get a measurement of 2D image movement.
- Use a weighted average of movement contributions (instead of a median).
- Allow for rotation compensation and zoom (image scale) compensation.
- Allow to pick a different set of tracks for translation and for
rotation/zoom.
- Treat translation / rotation / zoom contributions systematically in a
similar way.
- Improve handling of partial tracking data with gaps and varying
start / end points.
- Have a user definable anchor frame and interpolate / extrapolate data to
avoid jumping back to "neutral" position when no tracking data is available.
- Support for travelling and panning shots by including an //intended//
position/rotation/zoom ("target position"). The idea is for these parameters
to be //animated// by the user, in order to supply an smooth, intended
camera movement. This way, we can keep the image content roughly in frame
even when moving completely away from the initial view.
A known shortcoming is that the pivot point for rotation compensation is set to
the translation compensated image center. This can produce spurious rotation on
travelling shots, which needs to be compensated manually (by animating the
target rotation parameter). There are several possible ways to address that
problem, yet all of them are considered beyond the scope of this improvement
proposal for now.
Own modifications:
- Restrict line length, it's really handy for split-view editing
- In motion tracking we prefer fully human-readable comments, meaning we
don't use doxygen with it's weird markup and comments are supposed to
start with capital and end with a full stop,
- Add explicit comparison of pointer to NULL.
Reviewers: sergey
Subscribers: kusi, kdawg, forest-house, mardy, Samoth, plasmasolutions, willolis, sebastian_k, hype, enetheru, sunboy, jta, leon_cheung
Maniphest Tasks: T49036
Differential Revision: https://developer.blender.org/D583
|
|
|
|
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.
|
|
Useful for cases when you need to create bunch of witness tracks.
|
|
Based on the patch from Sebastian Koenig, discussed with Jonathan Williamson
https://developer.blender.org/T38172
Also removed redundant modes from clip editor.
Reviewers: brecht, carter2422
Reviewed By: carter2422
CC: sebastian_k, carter2422
Differential Revision: https://developer.blender.org/D293
|
|
Summary:
Now it's possible to assign an image to plane tracks
in clip editor. This image is only used for display
in clip editor and this image is being warped into
the plane track rectangle.
Main purpose of this is to get early feedback about
how good image warping matches the footage, before
clip goes to the compositor.
Pretty much straightforward change: just compute
homography from undeformed normalized frame corner
coordinates (unity square) to plane marker corners
and apply this matrix to opengl stack.
Still could improve behavior when perspective
plane transform is degenerate, but that's not so
much critical for now i'd say.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: sebastian_k
Differential Revision: http://developer.blender.org/D57
|
|
Added a weight slider to track which defines
how much particular track affects in a final
reconstruction. This weight is for sure
animateable.
Currently it affects on BA step only which in
most cases will work just fine.
The usecase of this slider is to have it set
to 1.0 most of the time where the track is
good, but blend it's weight down to 0 when
tracker looses the track. This will prevent
camera from jump.
Tutorial is to be done by Sebastian.
|
|
It was rather confusing from the user usage point
of view and didn't get so much improvement after
new bundle adjuster was added.
In the future we might want to switch resection
to PPnP algorithm, which could also might be a
nice alternative to fallback option.
|
|
|
|
- Do plane re-evaluation only when transform is actually done.
Before this re-evaluation happened on every mouse move.
- Added a flag "Auto Keyframe" for the plane track, which does:
* If Auto Keyframe is enabled, then every manual edit of the
plane will create a new keyframe at current frame and update
plane motion between current frame and previous/next keyframe.
This now also implies blending detected motion with neighbor
keyframes, so there's no jump happening.
No automatic update on manual point tracks edit will happen.
* If auto Keyframe is disabled, then no keyframes are adding
to the plane and every plane tweak will re-evaluate in on
the whole frame range.
In this case manual tweaks to point tracks and re-tracking
them implies plane re-evaluation.
|
|
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
|
|
Implements an automatic keyframe selection algorithm which uses
couple of approaches to find out best keyframes candidates:
- First, slightly modifier Pollefeys's criteria is used, which
limits correspondence ration from 80% to 100%. This allows to
reject keyframe candidate early without doing heavy math in
cases there're not much common features with first keyframe.
- Second step is based on Geometric Robust Information Criteria
(aka GRIC), which checks whether features motion between
candidate keyframes is better defined by homography or
fundamental matrices.
To be a good keyframe candidate, fundamental matrix need to
define motion better than homography (in this case F-GRIC will
be smaller than H-GRIC).
This two criteria are well described in this paper:
http://www.cs.ait.ac.th/~mdailey/papers/Tahir-KeyFrame.pdf
- Final step is based on estimating reconstruction error of
a full-scene solution using candidate keyframes. This part
is based on the following paper:
ftp://ftp.tnt.uni-hannover.de/pub/papers/2004/ECCV2004-TTHBAW.pdf
This step requires reconstruction using candidate keyframes
and obtaining covariance matrix of 3D points positions.
Reconstruction was done pretty much straightforward using
other simple pipeline routines, and for covariance estimation
pseudo-inverse of Hessian is used, which is in this case
(J^T * J)+, where + denotes pseudo-inverse.
Jacobian matrix is estimating using Ceres evaluate API.
This is also crucial to get rid of possible gauge ambiguity,
which is in our case made by zero-ing 7 (by gauge freedoms
number) eigen values in pseudo-inverse.
There're still room for improving and optimizing the code,
but we need some point to start with anyway :)
Thanks to Keir Mierle and Sameer Agarwal who assisted a lot
to make this feature working.
|
|
Also removed unneeded image buffer scaling, it was only needed
for "early output" if there was no rotation. That is no longer
supported since it used to pixelate result a lot and interpolation
is always used now.
Saves quite a few of memory and CPU cycles.
|
|
DNA headers when its not so obvious what their purpose is.
|
|
Highlight background depending on number of tracks existing on frame.
This is not so much mathematically accurate displaying where things
shall be improved, but it's nice feedback about which frames better
be reviewed.
Bad frames are tracks < 8, highlighted with red.
OK-ish frame are 8 <= tracks < 16, highlighted with yellow.
Could be some artifacts with color region start/end, this is a bit
unclear what exactly expected to be highlighted -- frames are
displayed as dots, but in fact they're quite noticeable segments.
---
svn merge -r54572:54573 ^/branches/soc-2011-tomato
|
|
|
|
also initialize bmesh-bevel settings struct to zero to avoid possible uninitialized memory later.
|
|
Helps a lot when debugging.
|
|
This fixes some "regressions" introduced in rev50781 which lead to much
worse solution in some cases. Now it's possible to bring old behavior back.
Perhaps it's more like temporal solution for time being smarter solution is
found. But finding such a solution isn't so fast, so let's bring manual
control over reprojection usage.
But anyway, imo it's now nice to have a structure which could be used to
pass different settings to the solver.
|
|
|
