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

Possible issue with initICP in RGBDOdometry.cpp #83

Closed
kzampog opened this issue Apr 6, 2017 · 4 comments
Closed

Possible issue with initICP in RGBDOdometry.cpp #83

kzampog opened this issue Apr 6, 2017 · 4 comments

Comments

@kzampog
Copy link

kzampog commented Apr 6, 2017

Hi,

Thanks for releasing this code!

I was looking at the code in RGBDOdometry.cpp and noticed that calls in lines 162-163 have the same arguments:

    resizeVMap(vmaps_curr_[i - 1], vmaps_curr_[i]);
    resizeNMap(vmaps_curr_[i - 1], vmaps_curr_[i]);

while it seems like they should read:

    resizeVMap(vmaps_curr_[i - 1], vmaps_curr_[i]);
    resizeNMap(nmaps_curr_[i - 1], nmaps_curr_[i]);

Of course, I may be missing something. This particular variant of initICP() is used in line 487 of ElasticFusion.cpp.

Also, I was wondering if you were planning to release RGBDOdometry as a separate package (in the spirit of ICPCUDA which it seems to build upon).

Thank you!

Best,
Kostas

@mp3guy mp3guy closed this as completed in 31c874a Apr 7, 2017
@mp3guy
Copy link
Owner

mp3guy commented Apr 7, 2017

Nice, great find! That's a pretty significant bug that was probably making the geometric term go to crap below the first pyramid level. I'd imagine the photometric term was doing all of the heavy lifting below that.

I was planning to but never got the time, hopefully in the future.

@kzampog
Copy link
Author

kzampog commented Apr 25, 2017

Hi again!

I have another question about RGBDOdometry. The version of initICP that directly takes a depth map does not seem to update the vmaps_tmp variable which is later used by initRGB, so the new depth map (nextDepth[0]) generated in line 212 seems to be based on the 'model' geometry.

I'm not sure if this is intended, but it seems from the code that the two initICP variants behave differently regarding this.

Thanks again!

Best,
Kostas

@mp3guy
Copy link
Owner

mp3guy commented Apr 26, 2017

Hmm, interesting find. It's a very long time since I wrote this code, but if I test what looks like a fix, performance on all benchmarks is significantly worse. So as you observed it's non-obvious as to what's going on here, but the way it is now is the way it works. It may be the case that something is poorly named. Long on my to do list is a big refactor and clean up of the tracking code (including visualising residuals etc...), but finding the time for that is difficult.

@kzampog
Copy link
Author

kzampog commented Apr 26, 2017

Cool, thanks a lot! I'll keep you updated if I happen to gain any insight on this.

LouisGallagher pushed a commit to LouisGallagher/ElasticFusion that referenced this issue May 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants