How to disable update_scale when do rigid transformation

[szx0112]

The package looks great. One problem I am facing is that I need to disable the update_scale when runs cpd.registration_cpd(...). However, it seems that scale is not contained in the current parameter list.

Any comment is appreciated.

[neka-nat]

Hi @szx0112 ,

Thank you for reporting.
Since kargs contains update_scale, you can pass it as an argument.

tf_param, _, _ = cpd.registration_cpd(source, target,
                                      callbacks=cbs, update_scale=False)

If you assume rigid deformation without scale, I recommend filterreg.
It is the same accuracy with CPD and 100 times faster calculation speed.

[szx0112]

@neka-nat Got it. Thank you for the comments.

I tried the filterReg today, the default 'pt2pt' works great. I notice there is a point2plane option by changing the objective_function as 'pt2pl' and sigma2 as '0.01' when do registration_filterReg (same as in example).

However, it always shows 'Memory corruption' error. The point clouds are very small and downsampled before the processing.

Any suggestion? Thx.

[neka-nat]

Did you execute the following example?
https://github.com/neka-nat/probreg/blob/master/examples/filterreg_rigid_pt2pl.py
When using the pt2pl option, do you calculate the normal vector beforehand?

[szx0112]

Hi, @neka-nat Thanks for the suggestion. I forget to re-compute the normal after the point cloud down-sampling.

However, I found the point-to-plane registration results is not as good as point-to-point, it actually push the source point cloud away.

See pics below, the 1) is pt2pt and sigma2=None and the 2) is pt2pl with sigma2 = 0.01. I believe it may relate to the parameter tunning. Do we have any quick notes about the effects of each parameter?

pt2pt

pt2pl

Pls also notice the result of pt2pt registration, mismatch still exist between the source and target point clouds. My overall goal is to minimize such error. Any suggestions?

Thanks

[neka-nat]

Have you tried any other methods? (CPD, GMMReg, SVR, GMMTree)

[szx0112]

@neka-nat I have tried all the listed methods. For my cases, SVR and GMMReg shows comparable results as filterReg, they are better than CPD (larger fitness and small inlier error). GMMTree takes the longest to process, shows worst result, sometime it just push the source point cloud away.

However, I am still not able to generate good solution for the case mentioned above.

[neka-nat]

It may be difficult to increase the accuracy any further because the data is planar and has few features.
If the data has color information, you can also use ColoredIcp.
http://www.open3d.org/docs/release/tutorial/Advanced/colored_pointcloud_registration.html

[szx0112]

I have tried the colorICP, it shows less stable results as the probability-based method due to the noise of the point clouds.

The noise level of the point cloud is higher when the distance of target is far away from the sensor (RGBD camera in my case). Making the registration fail.

I believe it is necessary to further cleaning or filtering the point cloud before the registration.

Thanks for your help. I am going to close this issue.