CloudCompare forum

Is there a way to region/poly select the overlap area for registration?

The cloud points are taken from different angles I have varying degrees of success with existing methods. I might just be doing it wrong. So any suggestions for workflow I'll take.

This is what I currently do.
-Load ptx A, pick 3 points, level (although my ground is not actually level)
-Load ptx B, pick 3 points, level (although my ground is not actually level)
So I have A and B, but they are not actually level to each other (each scan has ~5million points).
-I then try to "finely register already ..."
(btw as a new user, data and model are ambiguous terms. please consider renaming/adding "moving" and "staying" to description)
-I try to guess what my "final overlap" percentage is
(if you get this wrong it will sometimes compute overnight, perhaps a give up after x minutes is needed? So many times I have to kill cloudcompare in task manager and try again)
-Often this will give me a good angle adjustment so I can then move it up/down.
-Other times it will be very very wrong and I have to try "align by picking point pairs", but my point pairs are not uniformly scaled between scans and I just have to eye-ball it.

I have 27 scans with a total of ~108 million points, I need them to be aligned perfectly through computation and not by me by hand. Any suggestions would be greatly appreciated.


I am re-assembling an outdoor scan of various degrees of overlap.


Scan A


Scan B


Scan A and B


Overlap area between A and B. I wish there was a way to finely register two clouds but only considering points in this area.

Interesting ;)

First: the fact that the ICP process is taking ages when a partial overlap is defined should be fixed with the last version (2.6.2 - well at least I hope so. Don't hesitate to bug me if it's still slow).

Then, one very important thing: the ICP algorithm is not meant to be used on far-away scans. They have to be already roughly registered. So you should definitely use the 'Align by picking point pairs' tool (no need to be very accurate if you use the ICP tool afterwards). Or you can level all your scans, then work from above and rotate/translate them manually with the 'Rotate/Translate' tool (constraining the rotation around the Z axis typically). Once again, no need to be ultra-accurate. The idea is just to get the scans roughly registered.

And a trick that can help CC a lot when performing ICP on clouds with a small overlap (if you still get issues with the overlap with the 2.6.2 version): you can segment parts of your clouds (with the scissors tool for instance). Then you can register this subset the normal way. And eventually you can copy the resulting transformation matrix (displayed in the Console) and apply it on the original cloud with the 'Edit > Apply transformation tool'. Make sure to clone the cloud before segmenting it in this case (so as to keep a complete version in store). The issue with distances computation is that the farther the points are the (way) longer/harder it is to compute the distance (as the nearest point is somewhere in a sphere that keeps getting bigger and bigger). In the 2.6.2 version, when you specify an overlap we used approximate distances so as to discard as most points as possible (this is why it should be much faster). And if you roughly register your clouds first, it should also reduce the distances.

And last but not least, the registration tools of CC are meant to register two clouds/meshes before comparing them (this the 'Compare' in CloudCompare). Properly registering 27 scans together is a far more ambitious task. First the workflow might not be ultra efficient (you might have noticed that already ;). But what concerns me more is that when you 'serially' register the scans 2 by 2 over a long distance you will propagate the registration error of each step. And you generally end with a banana-shaped cloud. In this case it is better to use co-registration algorithms between multiple clouds and trying to minimize the error in a global way. And this is not possible with CC. You'll have to take great care about this and try to avoid using a too 'linear' path during your registration.

daniel wrote: But what concerns me more is that when you 'serially' register the scans 2 by 2 over a long distance you will propagate the registration error of each step.

This is so true!

And I can tell my scan operator wanted to go home, because there is less and less overlap as he worked around the track! :)

Thank you for your feedback I will give your suggestions a try.