Right now we just pump everything to stdout. We should be able to control logging at runtime.

Hi,

There is an error when building the example, the error message is "ld: library not found for -lcpd-lib".

I have successfully built the CPD and run the "bin/cpd-test"; everything went quit smoothly. I also did "make install" as shown below (note the message is the second time running "make install"):

Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/local/lib/cpd/cmake/CpdConfig.cmake
-- Up-to-date: /usr/local/lib/cpd/cmake/CpdConfigVersion.cmake
-- Up-to-date: /usr/local/lib/cpd/cmake/CpdTargets.cmake
-- Up-to-date: /usr/local/lib/cpd/cmake/CpdTargets-noconfig.cmake
-- Up-to-date: /usr/local/include/cpd
-- Up-to-date: /usr/local/include/cpd/defaults.hpp
-- Up-to-date: /usr/local/include/cpd/nonrigid.hpp
-- Up-to-date: /usr/local/include/cpd/nonrigid_lowrank.hpp
-- Up-to-date: /usr/local/include/cpd/registration.hpp
-- Up-to-date: /usr/local/include/cpd/rigid.hpp
-- Up-to-date: /usr/local/include/cpd/version.hpp
-- Installing: /usr/local/lib/libcpd.0.2.2-60-gcd64321.dylib
-- Up-to-date: /usr/local/lib/libcpd.0.dylib
-- Up-to-date: /usr/local/lib/libcpd.dylib
-- Installing: /usr/local/bin/cpd

Then, I followed exactly the commands in the README.txt under "example" folder as

mkdir build
cd build
cmake ..
make

Then, the aforementioned error appeared. Any idea why this happened? Should the lib being linked be "libcpd"? I changed "cpd-lib" to "libcpd", but did not get any luck. Please kindly help me on this. Thanks!

Best,
Ben
PS. I am using Mac OS X 10.10.5 and CMake 3.3.1, for your reference.

We've got a report in Gitter that affine borks with 50k point datasets w/ about 32G of memory, which seems...worse than I'd expect. Though, re-reading the discussion, these are 100 dimension point sets, so maybe it's not that surprising. Check it out anyways, see if we can reproduce.

Per #32 the README is not clear on how to get things installed after the latest changes. Fixit.

Andriy's reference implementation came with a nonrigid_lowrank transformation, which used some tricks to speed up the very slow nonrigid registration. I think we could use https://github.com/m-reuter/arpackpp to do the eigenvalue calculations required, which is the only real hurdle (for now).

Currently, the user must Just Know if the CPD library they are linking against was build with ARMA_64BIT_WORD defined or not — otherwise, they will get some undefined symbol errors which are hard to track down. We should investigate if we can drop a breadcrumb in our cmake configuration installation that lets us deduce (or better yet, automatically deduce) the appropriate AMRA_64BIT_WORD setting.

Macros get all upper, so constants should be CamelCase.

As we got that A from Y = X*A,how we depose A to  S,R,T,satisify S*R*T=A

so far, Rigrid model was sloved,UnRigrid model was hard to knuw,that all.Thanks

hi ,
I have a strange problems , i followed the build instructions and i can run cpd executable succesfully , but when i want to use it in my own code i have some problems. I want to use it with ROS
it is installed to (/usr/local/lib succesfully ... )

find_package(CPD required) => cant find the CPD & CPD_Directories

if I set the .so lib (libcpd.so) in target_link_libraries it's OK ,
but I have just got the undefined reference for

error: undefined reference to `cpd::NonrigidLowrank::NonrigidLowrank(float, int, float, bool, float, float, float, unsigned int)'

so , I cant compile and use CPD in my ROS package . Any Suggestion ?!

The first few iterations can be a bit wonky, since we don't assume the points are anywhere close to each other. We could probably do a bit better in certain circumstances by keeping the points home.

Needs to add the git hash as a string.

Hi,

I am having trouble installing the cpd package. I am attempting to install on a Mac running OS X 10.11.1. I followed the following steps:
Using brew:
installed armadillo
installed flags

then downloaded fgt using git
installed following the instructions:
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_BUILD_TYPE=Release
$ make

no errors.

downloaded cpd using git

executed:
$mkdir cpd/build && cd cpd/build
then
$cmake .. -DBUILD_CLI=ON

this is where things failed with the following error:

-- cpd version EAD-HASH-NOTFOUND
-- cpd options:
ARMA_64BIT_WORD: ON
ARMA_NO_DEBUG: OFF
BUILD_DEBUG_OUTPUT: OFF
CMake Error at CMakeLists.txt:66 (find_package):
By not providing "FindFgt.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Fgt", but
CMake did not find one.

Could not find a package configuration file provided by "Fgt" (requested
version 0.2.0) with any of the following names:

FgtConfig.cmake
fgt-config.cmake

Add the installation prefix of "Fgt" to CMAKE_PREFIX_PATH or set "Fgt_DIR"
to a directory containing one of the above files. If "Fgt" provides a
separate development package or SDK, be sure it has been installed.

-- Configuring incomplete, errors occurred!

Then, I modified the CMakeLists.txt file in the cpd/build directory to add the line:

set(Fgt_DIR "/Users/dnicolella-mbp/Documents/CoherentPointDrift/C_plus/fgt/build")

Now I get the following error:

-- cpd version 0.2.2-63-g02aea6b
-- cpd options:
ARMA_64BIT_WORD: ON
ARMA_NO_DEBUG: OFF
BUILD_DEBUG_OUTPUT: OFF
CMake Error at /Users/dnicolella-mbp/Documents/CoherentPointDrift/fgt/build/FgtConfig.cmake:23 (include):
include could not find load file:

/Users/dnicolella-mbp/Documents/CoherentPointDrift/fgt/build/FgtTargets.cmake

Call Stack (most recent call first):
CMakeLists.txt:66 (find_package)

-- Found PythonInterp: //anaconda/bin/python (found version "2.7.10")
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Configuring incomplete, errors occurred!

It seems that I am missing something here - I don't think I want to be adding machine specific paths to the cmake files.

Any help in solving this issue would be greatly appreciated.

(I am not a programmer, so I may be missing something obvious, and for that I apologize in advance).

Best Regards,
Dan Nicolella

Trying to compile with brew's El Capitan

[ 45%] Built target gtest_main
Scanning dependencies of target Test
[ 48%] Building CXX object test/CMakeFiles/Test.dir/affinity_eigenvectors_test.cpp.o
In file included from /Users/hobu/dev/git/cpd/test/affinity_eigenvectors_test.cpp:21:
In file included from /Users/hobu/dev/git/cpd/src/affinity_eigenvectors.hpp:22:
In file included from /usr/local/Cellar/armadillo/6.100.0/include/armadillo:517:
/usr/local/Cellar/armadillo/6.100.0/include/armadillo_bits/Mat_meat.hpp:7785:102: error: base class 'arma::Mat<double>' is uninitialized when used here
      to access 'arma::Mat<double>::mem_local' [-Werror,-Wuninitialized]
  : Mat<eT>( arma_fixed_indicator(), fixed_n_rows, fixed_n_cols, 0, ((use_extra) ? mem_local_extra : mem_local) )
                                                                                                     ^
/Users/hobu/dev/git/cpd/test/fixtures.hpp:31:7: note: in instantiation of member function 'arma::Mat<double>::fixed<36, 3>::fixed' requested here
class RegistrationTest : public ::testing::Test {
      ^
In file included from /Users/hobu/dev/git/cpd/test/affinity_eigenvectors_test.cpp:21:
In file included from /Users/hobu/dev/git/cpd/src/affinity_eigenvectors.hpp:22:
In file included from /usr/local/Cellar/armadillo/6.100.0/include/armadillo:517:
/usr/local/Cellar/armadillo/6.100.0/include/armadillo_bits/Mat_meat.hpp:7785:102: error: base class 'arma::Mat<double>' is uninitialized when used here
      to access 'arma::Mat<double>::mem_local' [-Werror,-Wuninitialized]
  : Mat<eT>( arma_fixed_indicator(), fixed_n_rows, fixed_n_cols, 0, ((use_extra) ? mem_local_extra : mem_local) )
                                                                                                     ^
/Users/hobu/dev/git/cpd/test/fixtures.hpp:31:7: note: in instantiation of member function 'arma::Mat<double>::fixed<3, 3>::fixed' requested here
class RegistrationTest : public ::testing::Test {
      ^
2 errors generated.

On my local laptop, CPD breaks with armadillo 6. I'm not sure why yet, so we should blacklist armadillo 6 for now until the problem is fixed.

Alternatively, fix our code to work with armadillo 6.

PDAL's Docker-based dependencies only has cmake 3.0, and since we want to be usable in PDAL, we should downgrade our cmake version requirement.

Right now we scale based on statistics, e.g. one standard deviation from the mean gets scaled to ±1. There should be an option that scales to min/max, since cropped areas don't tail off gaussian-style but instead end abruptly.

Darnit, its hard, but do it.

Hi Pete, nice implementation of the CPD algorithm. Just what I was looking for right now.
[Although I'd prefer non-GPL'd code as I intend to use it in a newer version of IRTK which will be released under BSD].

Trying to build the library, I was wondering where to find the FGT code ? You have documented all really well in the README, but this detail seems to be missing.

At this point, I don't see any reason that we need to add yet another dependency to cpd if we don't have to. gflags was used mostly because lazy on my part. This would also help #1.

Call it a tutorial, if you will.

Hi Pete,

First of all thank you for your wonderful effort. I was impressed by Andriy's work and wanted to implement it in C++ but luckily I found your work. I have tried to use your code in order to obtain affine transformation between two point sets. However, I found one problem, after obtaining the Rotation matrix from the C++ implementation (which is quite similar to Matlab's version of Rotation Matrix), I am not able to obtain the translation vector. The C++ implementation gives a 4x4 matrix which should contain the translation vector in the last column (first three values), however I only get zeros there. While on Matlab, I am successfully able to extract the translation vector. Perhaps it may be due to a bug in affine.cpp lines 63 to 76. I am not sure about it, therefore need your advice. I am sharing my results from C++ as well as Matlab implementations as under:

C++:
0.412826___0.672476___0.0161503___0
-0.810932___0.499356___-0.0364218___0
0.0255316___-0.0201581___1.08613___0
0_____________-0____________0____0

MATLAB:

0.4145___0.6700___0.0225___-0.0068
-0.8070___0.4973___-0.0322___0.0282
0.0506___-0.0382___1.0859___-0.3342
0_________0__________0_______1

Thanks.

This'll speed things up, but is danger-esqe 💀. Still, should be an option to really pound out some work.

In preparation for tagging v0.1, we should formalize our style conventions, check code coverage, and other general niceties.

Right now our unit tests cover some very basic and simplistic cases, and are mostly good for testing compliance with the Matlab implementation's behavior. However, as we start using CPD in production, it'd be nice to have some longer and/or harder registration tests available in our test suite. These tests would not need to be run as part of the standard test run, and might not even be run on Travis, but could be run locally after some sort of bigger change set to guard against more regressions.

I tried briefly on 2014-11-20 to build and run the command-line app on Travis, but gflags was throwing funky errors during the build process. Crypic stuff about pthread_rwlock_wrlock. It didn't seem like a rabbit hole worth the trouble, so I removed cli from the test steps.

In Rigid we use the set_ prefix, but in Nonrigid we don't. Add the set_ prefix to the Nonrigid.

Hi,
I found an error in rigid registration. For example,

cpd::Rigid reg;
cpd::Registration::ResultPtr result = reg.run(X,Y);
result->transformation.print();

This code prints wrong translation values that are too small than expected.
(at (0,3) and (1,3) of the homogeneous transformation matrix.)
I guess that these value are not "denormalized" after 'execute" unlike Y matrix in 'result'.
Is it correct? all just my wrong usage? Please check it.
(Any way, this library is wonderful. I love it.)

FGT is built with armadillo paths, etc, so we should just inherit those paths and such from the FGT target rather than having to set them again for CPD. This will also (hopefully) help prevent Armadillo version conflicts.

Howard said it shouldn't be necessary, so I should look into why I was having issues in the first place and how to dodge those problems.

using cmake 3.0.2 i get:

CMake Warning (dev) at src/CMakeLists.txt:19 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target "Library" links to target "Fgt::Library" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

i use -DCMAKE_PREFIX_PATH=/home/arthurb/local/share and the config files are there:

$ ls /home/arthurb/local/share/Fgt/CMake/
FgtConfig.cmake  FgtConfigVersion.cmake  FgtTargets.cmake  FgtTargets-noconfig.cmake

it successfully finds armadillo in the same locations.

any ideas? i'm not hugely familiar with cmake. thanks.

Right now our debug output is very haphazard, poorly formatted, and kind of ad-hoc. While this is to be expected for DEBUG output, since we pipe some of this information to log files, we might want to make things look slightly prettier.

Ideas include:

• prefix each new line with some sort of CPD-specific text (e.g. CPD debug:)
• use banners to highlight more important debug information, such as the configuration parameters

Right now they aren't documented, so functions don't show up in Doxygen.

figtree is turning into a bit of a problematic dependancy. Not only is the codebase a bit of a spaghetti pile, but it may be overkill for the problems that we're building cpd to solve. Specifically, since we're going to be using cpd primarily for three-dimensional spatial data, we don't need a solution that scales well at higher dimensions (yet).

Down the road we might want to support higher dimensions (for instance, using cpd with smoothed intensity values?) but I think performant and maintainable code for three dimensions should be the priority for now.

I've been reading through the IFGT user manual for the original IFGT code (from 2006!) and it seems like something I might be able to drop in to cpd itself (maybe with FLANN to do the K-center clustering?). I also should scan around some more to see if anyone's done a newer IFGT.

I just wanted to let you know that I have taken your use of the gflags library as an example for two new options added to the gflags-config.cmake file. The recommended use is documented here. It will be part of the gflags 2.2.0 release version.

Right now all of our headers are public (in our include/ folder). We should pull back stuff like debug.hpp and find_P.hpp, while keeping headers that might be useful to the general public.

As a bonus level, consider removing the cpd::registration namespace. It's all about the registration, baby, and the extra typing is a bit of a pain.

Looks for gflags_static, which we don't accept. I'm not sure if this a bad thing, as I have a vague memory of some sorts of gflags being too old, but that's rare for Homebrew so it very would could be an issue on our end. Check it out.

The command-line executable, when installed on Ubuntu, doesn't link against libcpd.so correctly.

cc @effi425xiao

Calling libraries may want to inject behavior into each CPD run, e.g. visualize each iteration or log configuration parameters. The callback could be configured like any other registration parameter.

As an additional improvement, we could store a container of callbacks that would be called in an unspecified order.

Figtree's a bit of a strange dependency, and one that shouldn't move too much. Since we depend on a custom fork on the main repo, maybe it makes sense to vendor the library (in vendor/). We could still provide a cmake option (USE_VENDORED_FIGTREE, default TRUE) to enable a external figtree (in the case of active figtree development).

Andriy's reference implementation came with an affine transformation, which we could add for completeness.

We've got newer armadillo versions available, so we should update the dependency.

I know that we use compile definitions — see if the armadillo library gives us any clues on whether it was compiled with 64bit words.

Edit: if we can learn 64bit word status from the library, drop support for armadillo nowrap.

Can we? But really, can we?

Add logic to nonrigid(_lowrank) to break down a large dataset into roughly equally sized chips, later stitching the results of those chip runs back together. This should provide roughly equal results to running the algorithm on the whole dataset, since the nonrigid should allow bending past certain scales.

PDAL has a internal chipper that does about what we want. However, it would be nice to not add big dependency like that. We could extract the chipper for our own purposes, or use some other point-count splitting algorithm.

http://uncrustify.sourceforge.net/

Pace some recommendations I found on the web web.

I think that Travis's install scripts would be better contained in a makefile instead of a bunch of shell scripts. Advantages:

• the targets could be more easily reused in (or, to flip it around, imported from) other makefiles used for installation of dependencies in a non-CI environment
• if one step in the makefile fails the whole thing will fail automatically — no clumsy && chaining

I'm not sure exactly on the naming/file structure yet, but I think I want to avoid creating a Makefile in the root of the project, as that might incorrectly lead someone to think that it's an autotools project instead of a cmake one. Maybe dependencies/Makefile, with install-armadillo, etc targets that pool into top level install-apt, install-homebrew, etc.

Right now CPD tends to break down when the domain of X and Y are >> the domain of Z. Explore optional Z exaggeration pre-scaling to see if we can help alleviate some of these problems.

I think that this is a prerequisite for #23.

Its simple and fits with my development scheme.

I think it might be nice for osx folks to provide a homebrew install formula.