Any tips for fine registration ICP problem

[sbemis]

Hi -

I have a point cloud built in Agisoft that I'm attempting to align with a portion of an airborne lidar point cloud. The procedure I'm trying to follow is:
1) clip out a swath of the agisoft point cloud for the area that I specifically wish to register to the lidar
2) run fine registration ICP with the agisoft swath as the data and the lidar as the model/reference (this has aligned very well in test runs)
3) run fine registration ICP of the full agisoft point cloud (data) to the swath extracted from the same point cloud (model/reference).

Unfortunately, the output from my step 3 typically results in a substantial rotation and reduction in scale for the full cloud. I've tinkered with some of the parameters, decreasing the overlap to 3% or 5%, allowing it to adjust scale or not, ignoring points far away, etc., but nothing has provided a similar small shift/correction as step 2 did for the swath point cloud. I even tried to trick it into not rotating by constraining the rotation to the y axis, but the output matrix for those tests were just the identity matrix.

I've even run the cloud-cloud distance for the full point cloud to the swath, and it shows very small displacements between the two clouds.

One possible problem I can think of is that I'm running this on unclassified - so considering that agisoft is more than likely treating trees different than lidar, so perhaps the scattered trees are creating problems - but then again, I'm trying to match a point cloud to a swath of the exact same point cloud!

I'd post an image but CloudCompare is cranking away on a process and it's time for me to hit the sack. I can provide more details if that would be helpful - but basically if there's any ideas how to help force the cloud to register to a swath of itself accurately, I'd love to hear it.

Thanks,
Sean

[daniel]

Indeed, screenshots would help a lot.

If the full agisoft cloud is much wider than the lidar cloud (or at least the overlap is very partial) then don't hesitate to decrease the overlap a lot more (50% or even less). This percentage should represent the number of points of the registered/data cloud that are actually in front of the other cloud at the end of the process.

Otherwise the other options shouldn't matter that much.

And by the way, if you use the 2.6.2 version, be sure to download the 'real' last version (there was a hiccup the day of the release - the version that was available on Tuesday and Friday was bugged :D).

[sbemis]

This first screenshot shows the swath of points cropped from the agisoft model after registration to the lidar point cloud - as well as the registration info/matrix.

agisoft_swath_and_lidar.PNG (44.56 KiB) Viewed 6640 times

This second screenshot shows the coverage of the agisoft swath relative to the full dataset. I finally did the division and found that the swath covers 1.4% of the full model (based upon # of points) and so set the overlap to 1%. And again, the swath is derived from the full dataset and no projections, etc. have been changed between the two, so they should be lined up pretty well already - with the only difference being the small adjustments made in the alignment to the lidar point cloud.

agisoft_swath_and_full_agisoft_prior_to_registration.jpg (96.17 KiB) Viewed 6640 times

And this is the typical result after fine registration with the corresponding transformation matrix.

agisoft_swath_and_full_agisoft_after_registration.PNG (33.6 KiB) Viewed 6640 times

I haven't upgraded to the latest version, so I'll do that and keep testing.

Thanks,
sean

[daniel]

Are you really trying to register the big red cloud with the very thin yellow one?

If yes then part of the issue here is that CC will ignore a coverage below 10% (you can see this in the report dialog). And the fact that you can input such a small coverage is definitely an error! Anyway this is because it was normally unlikely to happen (using such a small overlap is generally not a good idea ... apart if your cloud are already well registered... which is your case).

For this reasons, but also for the sake of efficiency, you should definitely do the registration the other way around. Then:

• copy the resulting matrix (select it in the Console and use the 'CTRL+V' shortcut)
• select the red cloud
• paste the matrix in the 'Apply transformation' tool and check the 'inverse' option

This will make the red cloud go to the right position (and you can delete and reload the yellow one).

P.S.: and in the case you are in fact trying to make the yellow cloud move relatively to the red one, then the overlap is 100%.

[sbemis]

Yes, registering red to yellow. In essence, I'm trying this as an alternative to the align points picking registration process for the agisoft dataset relative to the lidar. And I'm interested in registering only a portion of the agisoft point cloud in order to track displacement across the scene relative to a fixed region.

Your suggestion makes sense, but also in the meantime, a simple alternative method occurred to me --- take the transformation matrix from registering the narrow swath to the lidar and applying it to the full dataset! In either case I need to be concerned about registration/scaling errors propagating across the scene, but at least in this case there's one less processing step to add to the errors.

Thanks!
sean

[Ingsayyad]

@ daniel Does it help to have cloud with normals for better results. How can fix rotation, i.e.,no rotation about X, Y,Z.

[daniel]

Nope, normals are not used.