This is the right thing to do since the CMake files contain target
specific information - share is only for target-independent files.
Without this patch, the CMake files will collide on distributions
that allow to install for multiple targets in parallel (e. g. on
Exherbo).
Change-Id: Iac17af63b9f9b25d0ca400c77c2b2e0e8a51196f
This is needed for multiarch layouts where the prefix is /usr/${host}
but where arch-independent files are installed to /usr/share.
Change-Id: Icec01f8ea927594b4edb26997d6384e478415999
Computing the covariance matrix for a number of parameter blocks
previously required adding all parameter blocks to the computation and
subsequently assembling the matrix by concatenating all the blocks.
This patch adds the computation of the covariance matrix for a vector
of parameter blocks. All covariance block pairs are added automatically
and the resulting covariance matrix is assembled in the order the
parameter blocks appear.
Change-Id: I3b70c63f16862adc23a1d7fb7a21dde4e68abe9a
NIST recommends greater than 4 digits rather than greater than
or equal to 4 digits to declare that the solve was successful.
Change-Id: I5c65e6e791508b95b692c23dafd3833d73cd0487
Print information about the fill-in when using Eigen to perform
Simplicial sparse Cholesky factorization.
Change-Id: I09013b7f4ed2f6c55ae8ce8922447e23d63580a8
When detecting duplicates, it is more efficient to use std::adjacent_find
than it is to use std::unique.
Change-Id: Ib6b4671c10848bb7dd10aa7a1baeffc8c9c825b5
I169b637a1e2a106956b536c41d6a514a266e7cc0 marked Jets (in C++11) as
aligned to 16 bytes, and enabled Eigen vectorization. However, to
implement this, we added Eigen includes to port.h.
Turns out this broke some other tricks Ceres uses (redefining Eigen
constants for better performance), so we don't want to do that. Move
most of the implementation to jet.h where it is safe.
Change-Id: I47c6fc4180db1ff674bc660723dd5a2b84254e0d
We currently don't align the infinitesimal part of a Jet to a 16-byte
boundary (and thus force Eigen to avoid using SSE ops)--as a member of a
larger struct, we couldn't guarantee Jets would be allocated on
appropriately-aligned boundaries. However, C++11 adds better support
for requesting alignment: we can use it to guarantee the members will be
properly aligned, and tell Eigen to vectorize.
There is a significant gotcha here: the standard gives wide latitude to
implementations as to which alignments they choose to support. If we
ask for 16 and the system only supports 8, we may have misaligned
Jets. So we test (using alignof(std::max_align_t)) that the current
system supports 16-byte aligned values; if not, we fall back to the
current solution.
Two other small notes:
- This is obviously gated on C++11 support, and
thus we put the logic in port.h and export some useful #defines.
- GCC 4.8.x has a
bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019) that has
max_align_t in the wrong namespace. This will not be a problem with a
modern GCC, but add a small workaround since many systems still ship 4.8.
This results (on a x86 workstation) in a 60% speedup in Jacobian
evaluation on bin/simple_bundle_adjuster problem-16-22106-pre.txt.
Change-Id: I169b637a1e2a106956b536c41d6a514a266e7cc0
Parameter blocks that are not associated with any residual block
lead to structurally zero columns in the Jacobian. The covariance
computation algorithm was only paying attention to structural
sparsity caused by constant parameter blocks but not free parameter
blocks.
This patch fixes this, by iterating over the residual blocks in
the problem and collecting all the parameter blocks in use.
The tests for ComputeCovarianceSparsity are also extended to include
the case where there are constant and free parameter blocks.
Thanks to Wannes Van Loock for reporting this.
Change-Id: Ic298a6e93c53f2f95fb69105397a87200738a2b0
Accumulate the number of steps of the line search algorithm
and report it as part of Summary::FullReport.
Change-Id: I1de12784009a3e08f2a2c2aff5085d57a3c73828
- Previously we had the Ceres version defined in two places, one in
include/ceres/version.h, and one in the main CMakeLists.
- Now the main CMakeLists reads the Ceres version directly from
version.h, as does the make_release script, so that we have a single
place (version.h) in which the current Ceres version is defined.
Change-Id: Ie80aa7d38f5b576d3ed4d6109dd699f565c91027
This commit fixes a bug related to the computation of covariance blocks
in the tangent space for constant parameter blocks, causing out of
bounds memory access.
Change-Id: Iaeee7992405fcaaae6086612798e96f2e10ebc5c
1. Add answers to a number of FAQs.
2. Add a note to the documentation for NumericDiffCostFunction that
NumericDiffOptions needs to be documented and mentioned.
3. Update the docs for Solver::Options::numeric_derivative_relative_step_size
to indicate that this setting only applies to the gradient checker.
4. Remove deprecated constructors from NumericDiffCostFunction and
DynamicNumericDiffCostFunction.
Change-Id: If8fc011b2a5996dbc2c51268aa477550ed014a1c
- Gives an option to specify a lower deployment target version than the
current SDK for backward compatibility.
Change-Id: Ieb84ba7f42cdf925510f84b8e0cd01b5e9fc051b
- On GCC 4.9+ although GCC supports LTO, it requires use of the
non-default gcc-ar & gcc-ranlib. Whilst we can ensure Ceres is
compiled with these, doing so with GCC 4.9 causes multiple definition
linker errors of static ints inside Eigen when compiling the tests
and examples when they are not also built with LTO.
- On OS X (Xcode 6 & 7) after the latest update to gtest, if LTO
is used when compiling the tests (& examples), two tests fail
due to typeinfo::operator== (things are fine if only Ceres itself is
compiled with LTO).
- This patch disables LTO for all compilers. It should be revisited when
the performance is more stable across our supported compilers.
Change-Id: I17b52957faefbdeff0aa40846dc9b342db1b02e3
- If Ceres is built as a shared library, and LTO is enabled for Ceres
and the tests, then type_info::operator==() incorrectly returns false
in gtests' CheckedDowncastToActualType() in the following tests:
-- levenberg_marquardt_strategy_test.
-- gradient_checking_cost_function_test.
on at least Xcode 6 & 7 as reported here:
https://github.com/google/googletest/issues/595.
- This does not appear to be a gtest issue, but is perhaps an LLVM bug
or an RTTI shared library issue. Either way, disabling the use of
LTO when compiling the test application resolves the issue.
- Allow LTO to be enabled for GCC, if it is supported.
- Add CMake function to allow easy appending to target properties s/t
Ceres library-specific compile flags can be iteratively constructed.
Change-Id: I923e6aae4f7cefa098cf32b2f8fc19389e7918c9
1. Fix a typo in the Trust Region algorithm.
2. Add ARL in the list of users.
3. Update the version history.
Change-Id: Ic286e8ef1a71af07f3890b7592dd3aed9c5f87ce
- The newer style, which are more specific and match the SDK names
are not available on Xcode < 7.0.
Change-Id: I2f07a0365183d2781157cdb05fd49b30ae001ac5
- Substantial cleanup of iOS.cmake to use xcrun & xcodebuild to
determine the SDK & tool paths.
- Use libtool -static to link libraries instead of ar + ranlib, which
is not compatible with Xcode 7+, this change should be backwards
compatible to at least Xcode 6.
- Force locations of unordered_map & shared_ptr on iOS to work around
check_cxx_source_compiles() running in a forked CMake instance without
access to the variables (IOS_PLATFORM) defined by the user.
- Minor CMake style updates.
Change-Id: I5f83a60607db34d461ebe85f9dce861f53d98277
- Changing the inlining threshold for Clang as described has a minimal
effect on user performance.
- The problem that originally prompted the belief that it did was
due to an erroneous CXX flag configuration (in user code).
Change-Id: I03017241c0f87b8dcefb8c984ec3b192afd97fc2
1. Move common test infrastructure into test_util.
2. system_test now only contains powells function.
3. Add bundle_adjustment_test.
Instead of a single function which computes everything,
there is now a test for each solver configuration which
uses the reference solution computed by the fixture.
Change-Id: I16a9a9a83a845a7aaf28762bcecf1a8ff5aee805
- Increasing the inline threshold results in very variable performance
improvements, and could potentially confuse users if they are trying
to set the inline threshold themselves.
- As such, we no longer export our inline threshold configuration for
Clang, but instead document how to change it in the FAQs.
Change-Id: I88e2e0001e4586ba2718535845ed1e4b1a5b72bc
The test for CompressedRowSparseMatrix::AppendRows tries to add
a matrix of size zero, which results in an invalid pointer deferencing
even though that pointer is never written to.
Change-Id: I97dba37082bd5dad242ae1af0447a9178cd92027
The outer product computation logic in SparseNormalCholeskySolver
does not work well with dynamic sparsity. The overhead of computing
the sparsity pattern of the normal equations is only amortized if
the sparsity is constant. If the sparsity can change from call to call
SparseNormalCholeskySolver will actually be more expensive.
For Eigen and for CXSparse we now explicitly compute the normal
equations using their respective matrix-matrix product routines and solve.
Change-Id: Ifbd8ed78987cdf71640e66ed69500442526a23d4
- When compiled with Clang, Ceres and all of the examples are compiled
with an increased inlining-threshold, as the default value can result
in poor Eigen performance.
- Previously, client code using Ceres would typically not use an
increased inlining-threshold (unless the user has specifically added
it themselves). However, increasing the inlining threshold can result
in significant performance improvements in auto-diffed CostFunctions.
- This patch adds the inlining-threshold flags to the interface flags
for the Ceres CMake target s/t any client code using Ceres (via
CMake), and compiled with Clang, will now be compiled with the same
increased inlining threshold as used by Ceres itself.
Change-Id: I31e8f1abfda140d22e85bb48aa57f028a68a415e
This method numerically computes function derivatives in different
scales, extrapolating between intermediate results to conserve function
evaluations. Adaptive differentiation is essential to produce accurate
results for functions with noisy derivatives.
Full changelist:
-Created a new type of NumericDiffMethod (RIDDERS).
-Implemented EvaluateRiddersJacobianColumn in NumericDiff.
-Created unit tests with f(x) = x^2 + [random noise] and
f(x) = exp(x).
Change-Id: I2d6e924d7ff686650272f29a8c981351e6f72091
- Previously, when Ceres was built as a static library we did not
compile position independent code. This means that the resulting
static library could not be linked against shared libraries, but
could be used by executables.
- To enable the use of a static Ceres library by other shared libraries
as reported in [1], the static library must be generated from
position independent code (except on Windows, where PIC does not
apply).
[1] https://github.com/Itseez/opencv_contrib/pull/290#issuecomment-130389471
Change-Id: I99388f1784ece688f91b162d009578c5c97ddaf6
The logic for determing static/dynamic f-block size in
DetectStructure was broken in a corner case, where the very first
row block which was used to initialize the f_block_size contained
more than one f blocks of varying sizes. The way the if block
was structured, no iteration was performed on the remaining
f-blocks and the loop failed to detect that the f-block size
was actually changing.
If in the remaining row blocks, there were no row blocks
with varying f-block sizes, the function will erroneously
return a static f-block size.
Thanks to Johannes Schonberger for providing a reproduction for this
rather tricky corner case.
Change-Id: Ib442a041d8b7efd29f9653be6a11a69d0eccd1ec
The schur eliminator treats rows with e blocks and row with
no e blocks separately. The template specialization logic only
applies to the rows with e blocks.
So, in cases where the rows with e-blocks have a fixed size f-block
but the rows without e-blocks have f-blocks of varying sizes,
DetectStructure will return a static f-block size, but we need to be
careful that we do not blindly use that static f-block size everywhere.
This patch fixes a bug where such care was not being taken, where
it was assumed that the static f-block size could be assumed for all
f-block sizes.
A new test is added, which triggers an exception in debug mode. In
release mode this error does not present itself, due to a peculiarity
of the way Eigen works.
Thanks to Werner Trobin for reporting this bug.
Change-Id: I8ae7aabf8eed8c3f9cf74b6c74d632ba44f82581
Niels Ole Salscheider