1. Base class for preprocessors.
2. A preprocessor for problems that will be solved using
the trust region minimizer.
3. Added sanity tests to the program reordering options
for Schur type linear solvers.
4. Tests for the TrustRegionPreprocessor.
Change-Id: I88cd926f0053bbbf2bd6b11e03ec55b8bf473cf1
This is a intermediate change to clean things up
in preparation for a broader refactoring of the SolverImpl.
Essentially we are replacing raw pointers in Minimizer::Options
with shared_ptr objects. For now this only makes things a bit
more complicated looking inside solver_impl.cc, but going
forward this will lead to considerable simplifications in
tracking ownership of various pointers.
Change-Id: I21db8fc6763c29b0d15e834d7c968a0f514042a0
Ensure that when a new problem object is constructed for validing
gradients, the parameter blocks have their data pointers point to
the user's parameter blocks.
We used to do this inside solver_impl.cc, but doing this at
construction is the right thing to do.
Change-Id: I3bfdc89bb0027c8d67cde937e8f2fa385d89c30c
The instrumentation revealed that EIGEN_SPARSE can be upto
an order of magnitude slower than CX_SPARSE on some bundle
adjustment problems.
The problem comes down to the quality of AMD ordering that
CXSparse/Eigen implements. It does particularly badly
on the Schur complement. In the CXSparse implementation
we got around this by considering the block sparsity structure
and computing the AMD ordering on it and lifting it to the
full matrix.
This is currently not possible with the release version of
Eigen, as the support for using preordered/natural orderings
is in the master branch but has not been released yet.
Change-Id: I25588d3e723e50606f327db5759f174f58439e29
Simplifying some of the template handling, and remove the use
of SelfAdjointView as it is not needed. The solver itself takes
an argument for where the data is actually stored.
The performance of SparseNormalCholesky with EIGEN_SPARSE
seems to be on par with CX_SPARSE.
Change-Id: I69e22a144b447c052b6cbe59ef1aa33eae2dd9e3
SPARSE_NORMAL_CHOLESKY and SPARSE_SCHUR can now be used
with EIGEN_SPARSE as the backend.
The performance is not as good as CXSparse. This needs to be
investigated. Is it because the quality of AMD ordering that
we are computing is not as good as the one for CXSparse? This
could be because we are working with the scalar matrix instead
of the block matrix.
Also, the upper/lower triangular story is not completely clear.
Both of these issues will be benchmarked and tackled in the
near future.
Also included in this change is a bunch of cleanup to the
SparseNormalCholeskySolver and SparseSchurComplementSolver
classes around the use of the of defines used to conditionally
compile out parts of the code.
The system_test has been updated to test EIGEN_SPARSE also.
Change-Id: I46a57e9c4c97782696879e0b15cfc7a93fe5496a
The loss functions that ship with ceres can sometimes
generate a zero first derivative if the residual is too
large.
In such cases Corrector fails with an ugly undebuggable
crash. This CL is the first in a series of fixes to
take care of this.
We clamp the values of rho' from below by
numeric_limits<double>::min().
Also included here is some minor cleanup where the constants
are treated as doubles rather than integers.
Thanks to Pierre Moulon for reporting this problem.
Change-Id: I3aaf375303ecc2659bbf6fb56a812e7dc3a41106
- Warning type generated is unused-but-set-variable, not unused-variable
and the corresponding "local variable is initialized but not
referenced" MSVC warning.
Change-Id: I716fd6a87cc91533bc862b2ef932601c8857818d
- Eigen 3.2.0 emits an unused variable warning from Ordering.h
#included by Eigen/SparseQR which prevents Ceres compilation due
to -Werror.
- As Eigen 3.2.0 is still in widespread use, we explicitly disable
the warning only around the inclusion of Eigen/SparseQR.
Change-Id: I48ce905ef6a22bc1b06f9e5bed328bd315f407f0
Sparse Cholesky factorization is not rank revealing. Therefore
this algorithm cannot reliably tell when the Jacobian matrix is
rank deficient or so poorly conditioned that the covariance matrix
cannot be estimated.
Making things worse, this algorithm works on the normal equations,
which makes the conditioning problem much worse.
This change, deletes the SPARSE_CHOLESKY algorithm in the covariance
estimation code. Also to make the naming consistent, it renames
SPARSE_QR -> SUITE_SPARSE_QR
so that it parallels EIGEN_SPARSE_QR.
Also, since we now have EIGEN_SPARSE_QR, we can default to using
it when SuiteSparse is not available instead of DENSE_SVD, which
generally speaking should only be used by folks who are dealing
with small rank deficient jacobians.
Change-Id: I8b134c7e8a2e86ca374371f185b19f1c3e74349c
Alessandro Gentilini pointed out that the install instructions
don't actually install the library.
Also included are some other minor changes to dependency
description.
Change-Id: I50872114bca7a9774ef66f55ba78ed9b7adad93f
For smaller problems Eigen is faster than SuiteSparseQR. This has been
tested with Eigen 3.2.1. Below are detailed timings. Problem 1 is the
smallest and problem 3 is the largest. The timings below are:
mean +- standard deviation.
Problem 1:
Eigen 0.0009218 +- 0.0002755
SuiteSparse 0.001406 +- 0.001610
Problem 2:
Eigen 0.002338 +- 0.001005
SuiteSparse 0.001910 +- 0.0004513
Problem 3:
Eigen 0.005455 +- 0.001759
SuiteSparse 0.002411 +- 0.0004974
Detailed problem descriptions:
Problem 1 size:
Original Reduced
Parameter blocks 533 54
Parameters 368 104
Effective parameters 1201 94
Residual blocks 233 77
Residual 1194 258
Problem 2 size:
Original Reduced
Parameter blocks 573 84
Parameters 1458 184
Effective parameters 1281 164
Residual blocks 263 107
Residual 1314 378
Problem 3 size:
Original Reduced
Parameter blocks 613 114
Parameters 1548 264
Effective parameters 1361 234
Residual blocks 293 137
Residual 1434 498
Change-Id: I884a67e2f728fe2992812148d82ccf5f27864fd7
- Without explicitly specifying the flags for release compilation in
the iOS toolchain file, no additional flags are passed and so the
libraries were not being built with full optimisations, even though
the CMAKE_BUILD_TYPE was 'Release'.
Change-Id: I742bab7589906b556640776d481491a8cc2303d4
The version parsing code was hard coding the fact that the
desired version is of the form
r + NUMERIC_MAJOR_VERSION + ALPHABETIC_MINOR_VERSION
r10 release of the NDK does not have a minor version an it breaks
the logic.
The fix is to make the version extraction be more robust to the
optional presence of the minor version.
Change-Id: Iace13ae7cad8cbd93ed635ecf7f1dce3a3ae15d5
- Explain the various ways to fix the problem of multiple definitions
of ERROR from glog / miniglog vs windows.h.
- Add note about use of CMAKE_LIBRARY_PATH to aid FindBLAS & FindLAPACK.
- Fix minor style typo in code-block for sample Ceres output.
Change-Id: I21742614f4c5a8fe1ac8f66811b7777a72bcc503
- Previously if miniglog was being used (on a non-Android system), we
compiled it into a separate library, against which Ceres then linked.
- This was unsatisfactory as it required miniglog being built as a
static library when building Ceres as a Windows DLL, because miniglog
did not use the dllexport/dllimport statements, whilst for other
platforms when building Ceres as a shared library, miniglog needed to
be compiled as a shared library.
- We now compile miniglog into Ceres on all platforms, not just on
Android.
- miniglog now uses the CERES_EXPORT macro to support Windows DLLs.
This means that miniglog now depends on Ceres' internal/port.h (and
thus internal/config.h) which define the CERES_EXPORT macro and
control its behaviour respectively.
- miniglog now also uses localtime_s, not localtime on Windows.
Change-Id: Ia55b9af8b4e6decf067eab92f0a5c2d14358a1e9
Move all the program reordering programs into their own file.
Also split the reordering routines for SPARSE_NORMAL_CHOLESKY
into individual library dependent routines.
Also get rid of RemovedFixedBlocksFromProgram.
Change-Id: Ie969f529e6d20dded9da021b9df1a040e08287c1
The script assert_ndk_version.sh used to require that the user
either define ANDROID_NDK_ROOT or ndk-build be in the path
so that ANDROID_NDK_ROOT can be inferred.
But since we are always calling this script from within an
Android.mk file, ndk-build already defines a variable called
NDK_ROOT, which we can pass to the script, thereby simplifying it
and making it more robust.
Change-Id: I31d66529a36a93e760e0dd0f17cfe61428fbac55
Create the glog include directories and library directories
only if we've already checked that the user is using
glog (and not miniglog).
Otherwise, @GLOG_INCLUDE_DIR@ and @GLOG_LIBRARY@ will be
empty and the generated files will cause Cmake errors.
Change-Id: Ia0ce9cf98f7d56c83b2285f72f45b8e0d5dc34c4
- Ceres now requires Android NDK version >= r9d to compile, Jørgen's
script allows a clean way to verify this condition is met before
trying to compile for Android.
- Note that this is a modified version of the original script, which
adds support for versions >= 10, and fixes extraction of the version
number now that the architecture is also included.
Change-Id: Icd7ffd25407bcf29af007e30b5da5d18eb799adf
CreateReducedProgram is a safer API, reduces the possibility of
memory leaks and produces valid programs.
Change-Id: I094d53d207fced970a4d9ea0b66cdb09ce5f0657
A number of typos in solver.cc which were hidden behind ifdefs
and were only revealed when building under android.
Change-Id: I89cbe8056da071479d2d1a251a8919b0be1f1cd4
Program::RemoveFixedBocks will happily drop all fixed parameter
and residual blocks. So if it is called on the one and only copy
of a program, like it was being called in the tests, this will
result in a memory leak because we would have lost track of the
fixed parameter and residual blocks.
This is not a problem in actual usage since CreateReducedProgram
will first create a copy of the program and then remove the fixed
blocks from it. But in the tests, we were creating a ProblemImpl
and then calling RemovedFixedBlocks on the underlying program
object causing a memory leak.
The fix to make a copy in the tests and then work on that. I
have also added a warning in program.h
Change-Id: I03a5f7a7f5453aec848451a5c0ace4b065f71e9b
Inner iterations require specific constraints on parameter
block orderings. The creation and validation routines for
these orderings are not static methods in CoordinateDescentMinimizer.
Change-Id: Ifc89491c9a8672e08523191b74b53058cbfa1db3
Move functions that determine alternatives to Schur type linear
solver and preconditioners into the LinearSolver and Preconditioner
interfaces.
Change-Id: Iae900afb7db17cdbeb7753497005a48c3144e2d7
Sameer Agarwal