result point-cloud identical to result point cloud

[paulen1]

I have two point clouds of the same object from slightly different angles. Both are saved in non-binary ply format. I tried registration with various methods using Fast-Robust-ICP. Unfortunately the resulting .ply seems to be identical to the target point cloud given at the beginning. I can not make out any visual diffrences when looking at the point clouds and they both have the exact same number of vertices. I did not give any kind of orientation. Was that the issue maybe? Or is there any other setting i should have configured?

Thank you and best regards, Paul

[yaoyx689]

Hi, from your description, I don't know what the problem is. Could you please provide the source and target models you tested? Let me try it.

[paulen1]

ps5neu.zip Thank you very much for the quick reply. I've attached the source files now.

[yaoyx689]

You are welcome.

fricp_reg_results.zip

The result of my test with the source code is in the fricp_reg_results/demean folder, where 51to52* is the result of using ps51neu.ply as source and ps52neu.ply as target, and the running command is:

./FRICP ps5neu/ps52neu.ply ps5neu/ps51neu.ply ps5neu/51to52 3

Is this result the same as your test result?

But it seems that registration results are incorrect, the reason is that the overlap rate of the two models is low, and there is an initialization to align their centers of gravity in the code, which will cause the initial position difference for registration to be too large.

After I removed the center of gravity alignment operation, the results are displayed in the fricp_reg_results/no_demean folder. It seems that the matching is successful, but because of its low overlap, I can't be sure whether this is the alignment you want.

If the results in fricp_reg_results/no_demean are successful, you can replace the contents (lines 63-67 in main.cpp)

   VectorN source_mean, target_mean;
    source_mean = vertices_source.rowwise().sum() / double(vertices_source.cols());
    target_mean = vertices_target.rowwise().sum() / double(vertices_target.cols());
    vertices_source.colwise() -= source_mean;
    vertices_target.colwise() -= target_mean;

with

VectorN source_mean(0,0,0), target_mean(0,0,0);

and run again. This modification can be applied to any example with a good initial alignment.

[paulen1]

Thank you for the reply. I've checked the results and could not make out a big improvment. With the results in the demean folder, I can, apart from orientation, still not visually make out a difference comparing 51to52_m3reg_pc.ply to ps52neu.ply (one of the input point clouds) and the number of vertices also match again (both have 23134). With the results in the no_demean folder it behaves similarly. Except that now 52to41_m3reg_pc.ply matches ps52neu.ply in terms of number of vertices. Visually it looks identical, only the position seems to be slightly different. I have attached screenshots of these two point clouds in meshlab below.

I understand that the small overlap in the given sample makes registration difficult, but even with other examples that include a much larger overlap, the result always seems to match one of the input point clouds.

Do you have any other idea what could be causing this issue?

Thanks and best regards, Paul

[yaoyx689]

1. Sorry, the two files (51to52 & 52to51) in the demean folder are reversed, you can ignore them.

2. It is worth emphasizing that our method is to calculate the transformation R (rotation) and t (translation) so that R x source + t matches the target, and the output result is R x source +t. Therefore, the number and shape of the output result are exactly the same as the source, and the positions match the target.

3. The result is not much different from the source, but the purpose of registration is to match the result with the target. As shown in the figure below, the result can indeed partially match the target. I think the result (no_demean/51to52_m3reg_pc.ply) and the target (ps52neu.ply) have already partially matched well, which is obviously better than the original source and target. One of the perspectives is shown here, and the other perspectives you can see are also locally matched.

[paulen1]

Thank you again for your reply. I believe I now know what I misunderstood. I thought the resulting point cloud was supposed to be a combination of the two input point clouds. I assume it is actually supposed to be the source point cloud, but rotated and moved so that both the source and the target point cloud fit together. The "melting" of the result and target point clouds had happend in other repos i looked at automatically, which probably caused this misunderstanding on my side.

Thank you a lot for your visualizations and support, Paul