| Age | Commit message (Collapse) | Author |
|---|
|
This change transitions libmv/osd tests to our
blender_add_test_executable macro that explicitly
takes the include directories as a parameter.
This is in preparation for future clean-up of
global include directories.
Differential Revision: https://developer.blender.org/D12012
Reviewed By: sergey
|
|
Correct X/Y mismatch in RetrackRegionTracker.
NOTE: This isn't used at the moment.
Reviewed By: sergey
Ref D11895
|
|
Docs: https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
Differential Revision: https://developer.blender.org/D11460
|
|
|
|
|
|
Got ignored in the initial commit of clang-format support to the Libmv.
|
|
The root of the issue was caused by the PredictMarkerPosition()
always returning false when tracking backwards. This was making
it so tracker always had to run brute initialization, which is
an expensive operation.
From own timing here:
- Tracking forward takes 0.667637 seconds
- Tracking backward used to take 2.591856 seconds
- Tracking backward now takes 0.827724 seconds
This is a very nice speedup, although the tracking backwards is
still somewhat slower. Will be investigated further as part of
a regular development.
|
|
|
|
Forgot to update regression test to the changed API.
|
|
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.
|
|
Mode to an own utility function and guard missing enumerator values
with a LOG(FATAL).
|
|
|
|
Is based on Google style which was used in the Libmv project before,
but is now consistently applied for the sources of the library itself
and to C-API. With some time C-API will likely be removed, and it
makes it easier to make it follow Libmv style, hence the diversion
from Blender's style.
There are quite some exceptions (clang-format off) in the code around
Eigen matrix initialization. It is rather annoying, and there could be
some neat way to make initialization readable without such exception.
Could be some places where loss of readability in matrix initialization
got lost as the change is quite big. If this has happened it is easier
to address readability once actually working on the code.
This change allowed to spot some missing header guards, so that's nice.
Doing it in bundled version, as the upstream library needs to have some
of the recent development ported over from bundle to upstream.
There should be no functional changes.
|
|
Before this change messages of ERROR and above were printed.
This change makes it so LOG(INFO), LOG(WARNING), LOG(ERROR)
and LOG(FATAL) will be printed to the console by default
(without --debug-libmv and --debug-cycles).
On a user level nothing is changed because neither INFO nor
WARNING severity are used in our codebase. For developers this
change allows to use LOG(INFO) to print relevant for debugging
information. Bering able to see WARNING messages is also nice,
since those are not related to debugging, but are about some
detected "bad" state.
After this change the LOG(INFO) is really treated as a printf.
Why not to use printf to begin with? Because it is often more
annoying to print non-scalar types. Why not to use cout? Just
a convenience, so that all type of logging is handled in the
same way. When one is familiar with Glog used in the area, it
is easy to use same utilities during development. Also, it is
easy to change LOG(INFO) to VLOG(2) when development is done
and one wants to keep the log print but make it only appear
when using special verbosity flags.
The initial reason why default severity was set to maximum
possible value is because of misuse of VLOG with verbosity
level 0, which is the same as LOG(INFO). This is also why
back in the days --debug-libmv was introduced.
Now there is some redundancy between --debug-libmv, --debug-cyles
and --verbose, but changes in their meaning will cause user
level side effects.
Differential Revision: https://developer.blender.org/D10513
|
|
Usage of LOG(INFO) actually went against own guidelines in the
logging.h: the INFO is for messages which are to be printed
regardless of debug/verbosity settings.
|
|
|
|
Log to verbosity level 1 rather than INFO severity.
Avoids a lot of overhead coming from construction of the INFO stream
and improves performance and threadability of code which uses logging.
This makes tracking of 250 frames of a track of default settings to
drop down from 0.6sec to 0.4sec.
|
|
Unused and was not entirely happy with such short abbreviations.
|
|
Allows to use mutex, scoped_lock, and conditional_variable from within
the libmv namespace.
Implementation is coming from C++11. Other configurations are easy to
implement, but currently C++11 is the way to go.
|
|
Allows to easily access build platform information, such as bitness,
compiler, supported C++ version and so on.
|
|
Bundler wouldn't be able to pull changes form upstream until all the
changes are upstreamed, but is better to have information consistent.
|
|
Ceres is an external library, so consider it a system header which
makes it so all strict flags are properly ignored for them.
|
|
|
|
|
|
Reviewed By: sergey, ankitm
Differential Revision: https://developer.blender.org/D9377
|
|
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
|
|
Was using doing an implicit cast of floating point value to boolean.
Was not noticed before because the boolean value was never never used.
|
|
Use the newly introduced packed intrinsics, which allows to remove
code which was initializing parameters block based on distortion
model type.
Now such initialization is done by a particular implementation of
a distortion model.
Differential Revision: https://developer.blender.org/D9192
|
|
This is a common class which can be used in all sort of minimization
problems which needs camera intrinsics as a parameter block.
Currently unused, but will replace a lot of hard-coded logic in the
bundle adjustment code.
|
|
|
|
There is no point in testing std::vector capacity as it can differ
between std implementations.
|
|
Corrects 34 miscellaneous misspelled words.
Differential Revision: https://developer.blender.org/D9248
Reviewed by Campbell Barton
|
|
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
|
|
There would be eigen alignment issues with the custom libmv vector
class when compiling with AVX optimizations. This would lead to
segfaults.
Simply use the std::vector base class as suggested by the old TODO in
the class header.
Reviewed By: Sergey
Differential Revision: http://developer.blender.org/D8968
|
|
That was a suboptimal decision from back in the days, which ended up
being problematic. It is no longer used, so remove it from API making
it so new code does not depend on this weak concept.
|
|
The order got broken when Brown distortion model has been added.
Made it so the indexing of parameters is strictly defined in the
parameter block, matching how parameters are used in the cost
function.
There is some duplication going on accessing parameters. This can
be refactored in the future, by either moving common parts packing
and cost function to an utility function in bundle.cc.
Alternatively, can introduce a public PackedIntrinsics class which
will contain a continuous block of parameters, and each of the
camera models will have API to be initialized from packed form and
to create this packed form.
The benefit of this approach over alternative solutions previously
made in the master branch or suggested in D9116 is that the specific
implementation of BA does not dictate the way how public classes need
to be organized. It is API which needs to define how implementation
goes, not the other way around.
Thanks Bastien and Ivan for the investigation!
|
|
This reverts commit 7e836bde11ce6521953c9f246cacd442a3ef6c0e.
Reverting the incomplete workaround, due to the following reasoning:
- There should be no dependency between CameraIntrinsics and the bundler
code. This violates intended abstraction of the intrinsics class.
- The fix was not complete, or wrong. Even in the world where there is
a requirement to the parameters storage size this should have applied
to all distortion models, including Divisions, Nuke.
Proper fix will be committed next.
|
|
The leak was happening when problem did not have any parameters blocks
defined. This happens, for example, if there are no 3D points at all,
or when all markers are set to 0 weight.
Was noticeable in libmv_modal_solver_test when building with LSAN
enabled.
|
|
Is a local function, not affecting API.
|
|
Current libmv_modal_solver_test fails since rB3a7d62cd1f5e.
It appears that the issue is caused by the insertion of the new OFFSET_K4 parameter,
as, if camera intrinsics are not required to implement/use all of those deform
parameters, they absolutely have to keep order (values) matching those defined
in bundle.cc, otherwise `PackIntrinisicsIntoArray` and `UnpackIntrinsicsFromArray`
will mangle them around.
|
|
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
|
|
Copy the appropriate parameter
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9014
|
|
This commit introduces a new way to build unit tests. It is now possible
for each module to generate its own test library. The tests in these
libraries are then bundled into a single executable.
The test executable can be run with `ctest`. Even though the tests
reside in a single executable, they are still exposed as individual
tests to `ctest`, and thus can be selected via its `-R` argument.
Not yet ported tests still build & run as before.
The following rules apply:
- Test code should reside in the same directory as the code under test.
- Tests that target functionality in `somefile.{c,cc}` should reside in
`somefile_test.cc`.
- The namespace for tests is the `tests` sub-namespace of the code under
test. For example, tests for `blender::bke` should be in
`blender::bke:tests`.
- The test files should be listed in the module's `CMakeLists.txt` in a
`blender_add_test_lib()` call. See the `blenkernel` module for an
example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7649
|
|
The unit being "pixels".
Before this change the solve errors were unitless in the UI.
With this change in place, the UI is now clear on that the unit of the
reprojection errors is pixels (px).
Differential Revision: https://developer.blender.org/D8000
|
|
|
|
Using latest master because of various compilation error fixes.
Brings a lot of recent development. From most interesting parts:
- New threading model.
- Tiny solver.
- Compatibility with C++17.
|
|
Don't use linear array with frame as an index since it has the
following disadvantages:
- Requires every application to take care of frame remapping, which
could be way more annoying than it sounds.
- Inefficient from memory point of view when solving part of a footage
which is closer to the end of frame range.
Using map technically is slower from performance point of view, but
could not feel any difference as the actual computation is way more
complex than access of camera on individual frames.
Solves crash aspect of T72009
|
|
|
|
|
|
|
