CloudCompare forum

Hi,

I have noticed that the algorithm used in Faro's SCENE software seems to do a much better job at registering point clouds. In my case, 2 indoor point clouds of the same room from the same location.

Inputs for Cloud to Cloud registration in SCENE include: 1) Subsampling distance 2) Maximum number of iterations 3) Maximum search distance

For ICP in CloudCompare the inputs are 1) Number of iterations 2) Final Overlap 3) max thread count OR 1) RMS difference 2) Final Overlap 3) max thread count.

I have found that for a combination of attempted settings, ICP in CloudCompare does a poor job of registering .fls files with very high overlap compared with SCENE. What are the differences in the algorithms, and is there any way to replicate the SCENE algorithm in CloudCompare? I would prefer to only use CloudCompare, as I will be bringing in scans to be registered from a Microsoft Kinect, which I am not sure SCENE can handle. But I need faith in CloudCompare's ICP algorithm first.

I have also found that when I set RMS difference to 1.0e-5 (the default), when ICP is done, an RMS greater than this is typically reported. I thought that this input was the threshold maximum allowable RMS, and that the algorithm won't terminate until it is reached. Am I mistaken?

Thank you,

Evan

How close are the files when you are starting ICP? CC needs a reasonably close initial alignment before ICP. ICP can easily get stuck in local minimums.
I don't know for sure but my guess would be that scene probably has internally a multistage algorithm and having an earlier stage get a solid rough alignment prior to an ICP stage.

Yes, definitely. the bare ICP algorithm is only meant to be used with already roughly registered clouds. It's a registration refinement algorithm.

And the 'RMS difference' is the difference of RMS between 2 iterations... not the absolute RMS (which can probably never reach such low values ;).

See https://www.cloudcompare.org/doc/wiki/i ... ?title=ICP

Thanks for the responses as usual.

The point clouds are very close I would say. Some areas are dead on aligned, while other areas there is maybe 2 cm of displacement, indicating sensitivity to rotations. I guess there are a lot of local minima very near to the global minimum.

Thanks for clearing up RMS "difference." I should read more carefully next time.

Then are you setting the "final overlap" parameter correctly? That's generally the other reason why the registration is stuck (because non overlapping points are shifting the result towards them)

Another thing you may want to take a look at is the spatial distribution of the points you're using for registration.

If you're working with raw undecimated tripod lidar scans then you have many more points per unit area on surfaces that are close to the scanner than you have on points that are far away. This effectively biases your alignment towards surfaces that are close to the scanner, which may not be desirable. You may get better results by subsampling your point clouds first so that the point density is a little more uniform.

I think this is what Scene does as part of their C2C alignment, however using a single point density doesn't account for the fact that point density and precision do naturally vary as a function of distance from the scanner. Before running C2C we actually decimate our point clouds so that data within binned distances from the scanner have the same density. For example, all the data from 0-10 m has one density, data from 10-30m has another lower density, data from 30-70m yet another.

Hi Daniel. "Final Overlap" shouldn't be an issue because I am scanning the same room. The only difference between scans is a target that I move around. If I register two of my .fls files in SCENE, the reported overlap is ~93% with ~0.4mm mean point error. Since I am trying to assess the accuracy of a few different sensors, it is really important for me to get my registrations down to sub-millimeter error, since I will be reporting on accuracies on the order of 3-10 mm. I am currently troubleshooting another issue though involving noise in one of my sensors... The noise appears to give a flat wall some 17 mm of "depth." I am thinking about using RANSAC to fit a plane to the noisy wall and ceiling and then use those planes to register against the non-noisy and clean FARO scans.

Hi Jed. Thanks for that information! That makes a lot of sense and clears up one of the inputs to the C2C algorithm in SCENE. In fact I was not subsampling so I may give that a try.