Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Point pair registration strange result #498

Closed
zihahage opened this issue Jan 18, 2017 · 3 comments
Closed

Point pair registration strange result #498

zihahage opened this issue Jan 18, 2017 · 3 comments
Labels

Comments

@zihahage
Copy link

zihahage commented Jan 18, 2017

Current Behavior

I know about the bug as described here #236.

But in CloudCompare 2.8, i think there is still a small bug.
Try

-1196.980 -714.234 -462.745
-1189.511 -1432.834 -466.560
1093.892 -1431.045 -469.854
1099.111 -711.013 -467.206

and

3039.947 117.745 -499.787
3040.068 837.800 -499.773
760.000 837.800 -499.787
759.928 117.900 -499.773
The two points with same index are equivalent.

It works well with any subset of 3 points but it gives strange result with the 4 points at once! Although the resultant alignment is correct, RMS displayed is very big, like 2395.55.

Expected Behavior

Steps to Reproduce (for bugs)

Context/Comments

Your Environment

  • OS & Version: win7 Enterprise 64 bit SP1
  • CC Version: 2.8
  • Graphics card:
@dgirardeau
Copy link
Member

I finally had some time to test this: even though the result 'seems' ok when using the 4 points, in fact one of the cloud is totally flipped (A0 is sent to R2, A1 is sent to R3, A2 to R0 and A3 to R1). This is why the RMS becomes huge.

This can indeed happen in some degenerate cases, with points aligned on a plane and with symmetries. This makes the registration maths fail...

We use Horn's algorithm, but I believe Arun's algorithm is more robust to this degenerate cases (see http://graphics.stanford.edu/~smr/ICP/comparison/eggert_comparison_mva97.pdf). Maybe we should switch to this method. However these cases really are degenerate and very particular.

@dgirardeau dgirardeau added the bug label Jan 24, 2017
@zihahage
Copy link
Author

zihahage commented Feb 4, 2017

After i read Horn's paper, i commented the two lines,
for (unsigned ip = 0; ip < n; ip++)
d[ip] = fabs(d[ip]);
which lie in line 263-264 in jacobi.h.

It works well and the result is correct, even with the two sets of 4 points listed in #236. But I am not sure if this change is correct.

@dgirardeau
Copy link
Member

Well, the negative eigenvalues are here because the case is degenerate... Therefore keeping their original sign may fix the issue but it may be by pure luck?

On the other hand, as this case is degenerate it won't work even if we use the absolute values instead of the negative ones...

For now I have made this automatic 'absolute' conversion optional. And it's only disabled for the case of the registration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants