Using unordered_map and unordered_set C++ container types currently
requires careful testing or usage of boost, due to the various confusing
C++ version differences in include paths and namespaces.
Libmv defines tests for these cases in cmake and scons, such that ceres
can use any available implementation, or fall back too std::map/std::set
if none can be found.
This patch generalizes this buildfile code by providing a Blender macro.
* cmake: defines both the variables used by libmv at them moment as well
as 2 variables UNORDERED_MAP_INCLUDE_PREFIX and UNORDERED_MAP_NAMESPACE,
which can later be used in other C++ parts for convenience.
* scons: adds a tool script returning the include prefix and namespace.
Libmv checks these to define the appropriate definitions for ceres.
Differential Revision: https://developer.blender.org/D425
This is mainly a maintaince commit which syncs changes
between Blender and Libmv upstream also bringing new
GLog version.
This GLog version is presumably have better support of
MinGW from "the box".
This commit is also aimed to make further 3d part libs
update easier.
This is needed to minimize their reprojection error over the footage.
Without this extra step positions of such tracks were calculated by
algebraic intersection code only, which doesn't give best precision.
Avoid zero-sized problem when doing euclidean intersection
Zero-sized problem might occur when intersecting track with
constant zero weight. For such tracks we'll just use result
of algebraic intersection.
TODO: We probably need to have a separate BA step to adjust
positions of tracks with constant zero weight.
It doesn't make sense to use zero-weighted tracks as a correspondences
in keyframe selection.
Such tracks are not guaranteed to be tracked accurately because their
purpose is to add reference points in 3D space without affecting the
solution.
This gives much worse results on mango footage (see 04_2e)
so disabling for now for until proper prediction model is landed.
The thing is, currently blender sends input coordinates as the guess to
region tracker and in case of fast motion such an early out ruins the track.
First thing changed by this commit is making it so
Euclidean intersection takes track weight into account
when solving minimization problem. This behaves the
same exact way as it is for BA step.
Second thing is related on how average reprojection error
is being calculated. It didn't take track weight into
account which could confuse users. Now average reprojection
error will give the same result as intersection/BA uses
during minimization which gives much more predictable
behavior.
Differential Revision: https://developer.blender.org/D265
Using tracks with constant zero weight used to crash
keyframe selection since it was trying to use missing
parameter blocks for Jacobian evaluation,
Also fixed possible issues with wrong camera block being
marked as variable. This could technically happen when
having zero weighted tracks. Made it so all camera blocks
are marked as variable for now.
Switch the detector API to a single function which accepts
a float image and detector options. This makes usage of
feature detection more unified across different algorithms.
Options structure is pretty much straightforward and contains
detector to be used and all the detector-specific settings.
Also implemented Harris feature detection algorithm which
is not as fast as FAST one but is expected to detect more
robust feature points. It is also likely that less features
are detected, but better quality than quantity.
Blender will now use Harris detector by default, later we'll
remove FAST detector.
Mainly fixed some style warnings reported by cpplint.
Also changed how camera (un)distortion happens internally
by replacing number of channels as a template argument
with number as channels passing as function argument.
Makes code easier to follow by eliminating loads checks
how much channels are used and which argument to pass to
the template.
Summary:
This brings up much easier termination type usage,
which for us means we might use:
ceres::Summary::IsSolutionUsable()
instead of doing manual funky enum values check.
Reviewers: keir
Differential Revision: https://developer.blender.org/D153
Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
The issue was caused by the fact that in this version
of MSVC unordered_map class is defined in <unordered_map>
header file, but this file declares the class int std::tr1
namespace.
This confused existing assumption that if there's an
existing <unordered_map> file then class is declared
in std namespace.
Added an extra check to CMake which detects whether
it's std or std::tr1 which actually contains class
of unordered_map.
This might be changed/cleaned in the future, for
now committing to our repository to solve compilation
error on windows.
Details of the patch in upstream can be found there:
https://ceres-solver-review.googlesource.com/#/c/4371/
- A richer Problem API.
- DynamicNumericDiffCostFunction.
- Faster ITERATIVE_SCHUR solver.
- Faster SCHUR_JACOBI preconditioner.
- Faster Jacobian evaluation.
- Faster visibility based preconditioning using single linkage clustering.
Also re-wrote rules for unordered collections detection,
should work on all platforms and compilers now :)
- A bit more reasonable name for the estimation option
structure and estimation functions.
- Get rid of unclear function and parameter tolerance,
it wasn't clear at all in which units they are.
Now we've got expected_average_symmetric_distance as
an early output check and as soon as average symmetric
error goes below this threshold refining finishes.
This distance is measured in the same units as input
points are.
It is arguable whether we need callback for this or not,
but seems Ceres doesn't have some kind of absolute
threshold for function value and function_tolerance
behaves different from logic behind expected symmetric
error.
- Added option to normalize correspondences before
estimating the homography in order to increase estimation
stability. See
R. Hartley and A. Zisserman. Multiple View Geometry in Computer
Vision. Cambridge University Press, second edition, 2003.
https://www.cs.ubc.ca/grads/resources/thesis/May09/Dubrofsky_Elan.pdf
Before the refinement phase of tracking, a brute force SAD search
is run across the search area. This works well but is slow;
especially if the guess for the track's location is accurate.
This patch runs a refinement phase before running a brute force
search, hoping that the guessed position (in x2, y2) is close to
the best answer. If it is, then no brute search is done. If it is
not, then a normal brute force search followed by refinement is
done.
In some cases this may produce worse tracks than before; the
regressions will need investigation. The predictive motion model
(to be implemented) will reduce the probability of that happening.
Before this patch, if Ceres returned USER_SUCCESS indicating that
Ceres was only changing the tracked quad slightly between
iterations (indicating convergence), no final correlation check
was done. This leads to incorrectly returning that the tracking
was successful, when it actually failed.
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.
- Tweaked typedefs in stdint so they match
what we've got in BLI_sys_types (needed to
explicitly tell sign to MSVC).
Not so much harmful to be more explicit here,
but we really better to have single stdint
int blender.
- Tweaked allocations macros so MSVC is happy
with structures allocation.
Also made libmv-capi use guarded objetc allocation.
Run into some suspecious cases when it was not so
clear whether memory is being freed or not.
Now we'll know for sure whether there're leaks or not :)
Having this macros in a guardedalloc header helps
using them in other areas (for now it's OCIO and libmv,
but in the future it'll be more places).
Jittering was caused by homography not being estimated
accurate enough.
Before this, only algebraic estimation was used, which
is indeed not so much great, Now use algebraic estimation
followed with refinement step using Ceres minimizer.
The code was already there since keyframe selection patch,
made such estimation a generic function in multiview/ and
changed API for estimation in order to pass all additional
options via an options structure (the same way as it's
done fr Ceres).
This includes changes to both homography and fundamental
estimation.
TODO:
- Need to document Ceres functors better.
- Need to support homogeneous coordinates (currently
only euclidean coords are supported).