Add an example application of homography matrix estimation
from a 2D euclidean correspondences which is done in two
steps:
- Coarse algebraic estimation
- Fine refinement using Ceres minimizer
Nothing terribly exciting apart from an example of how to
use user callbacks.
User callback is used here to stop minimizer when average
of symmetric geometric distance becomes good enough.
This might be arguable whether it's the best way to go
(in some cases you would want to stop minimizer when
maximal symmetric distance is lower than a threshold) but
for a callback usage example it's good enough to stick
to current logic.
Change-Id: I60c8559cb10b001a0eb64ab71920c08bd68455b8
Do not propagate 3d party libs through
IMPORTED_LINK_INTERFACE_LIBRARIES_[DEBUG/RELEASE] mechanism
when building shared libraries. SuiteSparse, lapack & co
are considered private. Glog still gets propagated since
it is part of the public interface. See documentation of
TARGET_LINK_LIBRARIES().
Change-Id: If0563b0c705b102876f5190e9a86694d10f79283
- Previously we were replicating the same two lines to update a cache
variable whilst preserving its help string.
- This commit adds a function which wraps up this common operation into
a single line.
Change-Id: Ic78a5adf5d59262bbbcec1e353ded7620391e862
- Previously we overwrote the default (empty) config.h in the source
tree with a configured config.h, generated using the current compile
options.
- This was undesirable as it could lead to inadvertant commits of the
generated config.h.
- This patch moves the default config.h to <src>/config/ceres/internal,
separate from the other headers, thus if Ceres is compiled without
CMake this directory will now also have to be included. This
directory is _not_ added to the CMake include directories for Ceres
(thus the default config.h is never used when compiling with CMake).
- When using CMake, the generated config.h is now placed in
<build>/config/ceres/internal, which is in turn added to the include
directories for Ceres when it is compiled, and the resulting config.h
is copied to ceres/internal when installed.
Change-Id: Ib1ba45e66e383ade2ebb08603af9165c1df616f2
- Previously we passed all compile options to Ceres via add_definitions
in CMake. This was fine for private definitions (used only by Ceres)
but required additional work for public definitions to ensure they
were correctly propagated to clients via CMake using
target_compile_definitions() (>= 2.8.11) or add_definitions().
- A drawback to these approaches is that they did not work for chained
dependencies on Ceres, as in if in the users project B <- A <- Ceres,
then although the required Ceres public compile definitions would
be used when compiling A, they would not be propagated to B.
- This patch replaces the addition of compile definitions via
add_definitions() with an autogenerated config.h header which
is installed with Ceres and defines all of the enabled Ceres compile
options.
- This removes the need for the user to propagate any compile
definitions in their projects, and additionally allows post-install
inspect of the options with which Ceres was compiled.
Change-Id: Idbdb6abdad0eb31e7540370e301afe87a07f2260
Problems that do not use bounds do not have to pay the
price of storing bounds constraints.
Also replace the raw pointer access to the upper and
lower bounds arrays with accessors which hides the
lazy initialization from the user.
Change-Id: I0325a35de9c29f853559f891e32e7c777686e537
- Previously all Ceres compile definitions were private to Ceres, that
is they were not exported to users via the CMake export mechanism.
- Now that we use compile definitions in public (installed) Ceres
headers, we need to export the Ceres compile definitions.
- If we did not do this, then the client's code 'see's' a different
version of the Ceres headers to those which were in fact compiled,
or in the case of shared_ptr, may not find the required header.
- This patch makes use of the new, in CMake 2.8.11, function:
target_compile_definitions() to export all of the Ceres compile
definitions using CMake's export functionality.
- For CMake versions < 2.8.11, we have to use the blunter instrument of
calling add_definitions() in CeresConfig.cmake (invoked by a call to
find_package(Ceres)). This is messy because it ends up adding the
Ceres compile definitions to any target declared in the user's code
after the call to find_package(Ceres). Although this should do no
harm as all of our defines are prefaced with CERES_, so any
unintentional name clashes are unlikely.
Change-Id: I5dea80949190eaf4fb08ea4ac568ce28c32dd4e0
Solver::Summary::message was not being updated when the solver
terminated because of a user's iteration callback indicating
success or failure.
Thanks to Sergey Sharybin for reporting this.
Change-Id: I27e6e5eed086920ddf765461b0159417ac79d7b3
1. Update version history.
2. Minor changes to the tutorial to reflect the bounds constrained
problem.
3. Added static factory methods to the SnavelyReprojectionError.
4. Removed relative gradient tolerance from types.h as it is
not true anymore.
Change-Id: I8de386e5278a008c84ef2d3290d2c4351417a9f1
This compiler defines shared_ptr in std::tr1 namespace, but
for this <tr1/memory> is to be included. Further, this compiler
also does have <memory> header which confused previous shared
pointer check.
Simplified logic around defines now, so currently we've got:
- CERES_TR1_MEMORY_HEADER defined if <tr1/memory> is to be
used for shared_ptr, otherwise <memory> is to be used.
- CERES_TR1_SHARED_PTR defined if shared_ptr is defined in
std::tr1 namespace, otherwise it's defined in std namespace.
All the shared_ptr checks are now moved to own file FindSharedPtr
which simplifies main CMakeLists.
Change-Id: I558a74793baaa0bd088801910a356be4ef17c31b
As pointed out by Jim Roseborough, this is the Marsaglia Polar
method and not the Box-Muller method.
Change-Id: Id5332bcd4b4c23a3885cc296729b44eaa5edd0a8
The standard sparse normal Cholesky solver assumes a fixed
sparsity pattern which is useful for a large number of problems
presented to Ceres. However, some problems are symbolically dense
but numerically sparse i.e. each residual is a function of a
large number of parameters but at any given state the residual
only depends on a sparse subset of them. For these class of
problems it is faster to re-analyse the sparsity pattern of the
jacobian at each iteration of the non-linear optimisation instead
of including all of the zero entries in the step computation.
The proposed solution adds the dynamic_sparsity option which can
be used with SPARSE_NORMAL_CHOLESKY. A
DynamicCompressedRowSparseMatrix type (which extends
CompressedRowSparseMatrix) has been introduced which allows
dynamic addition and removal of elements. A Finalize method is
provided which then consolidates the matrix so that it can be
used in place of a regular CompressedRowSparseMatrix. An
associated jacobian writer has also been provided.
Changes that were required to make this extension were adding the
SetMaxNumNonZeros method to CompressedRowSparseMatrix and adding
a JacobianFinalizer template parameter to the ProgramEvaluator.
Change-Id: Ia5a8a9523fdae8d5b027bc35e70b4611ec2a8d01
Fix variable names in port.h and fix fpclassify when
using gnustl. This was tested by switching to gnustl
in the JNI build.
Thanks to Carlos Hernandez for suggesting the gnustl fixes.
Change-Id: I690b73caf495ccc79061f45288e416da1604cc72
By default shared_ptr is now assumed to be
in the standard <memory> header and in the
std namespace.
Previously the way the ifdefs were structured if the appropriate
variable was not defined, it would default to <t1/memory>.
The new defaults are more future proof.
Change-Id: If457806191196be2b6425b8289ea7a3488a27445
Solver::Options::linear_solver_ordering and
Solver::Options::inner_iteration_ordering
were bare pointers even though Solver::Options took ownership of these
objects.
This lead to buggy user code and the inability to copy Solver::Options
objects around.
With this change, these naked pointers have been replaced by a
shared_ptr object which will managed the lifetime of these objects. This
also leads to simplification of the lifetime handling of these objects
inside the solver.
The Android.mk and Application.mk files have also been updated
to use a newer NDK revision which ships with LLVM's libc++.
Change-Id: I25161fb3ddf737be0b3e5dfd8e7a0039b22548cd
The existing introduction was a bit redundant and also
was not really an introduction. Also updated the build
instructions to reflect the new reality on Mac OSX.
Also updated the beginning of the tutorial to be a bit
gentler and updated the history to be more consistent
Change-Id: Ife38c1949252cf9f4c6301856957f2d38365f313
This reworks the Ceres Sphinx documentation such that it can
function as the main Ceres website, now hosted at
ceres-solver.org. This also changes to the theme sphinx_rtd_theme
used by Read The Docs; this theme has strong mobile support and is
well enough designed.
Change-Id: I63232d985859a6dac94ff58f08bf81eb2b9e7f99
and SchurEliminator.
Also update the comment inside generate_partitioned_matrix_view_specializations.py
Change-Id: I99a7ab4256091b1da48553da3076e5996a5757ed
- Breaking change: Problem::Options::enable_fast_parameter_block_removal
is now Problem::Options::enable_fast_removal, as it now controls
the behaviour for both parameter and residual blocks.
- Previously we did not check that the specified residual block to
remove in RemoveResidualBlock actually represented a valid residual
for the problem.
- This meant that Ceres would die unexpectedly if the user passed an
uninitialised residual_block, or more likely attempted to remove a
residual block that had already been removed automatically after
the user removed a parameter block upon on which it was dependent.
- RemoveResidualBlock now verifies the validity of the given
residual_block to remove. Either by checking against a hash set of
all residuals maintained in ProblemImpl iff enable_fast_removal
is enabled. Or by a full scan of the residual blocks if not.
Change-Id: I9ab178e2f68a74135f0a8e20905b16405c77a62b
Keir Mierle