search

mhalber / Fine-To-Coarse-Registration

Implementation of the Fine-To-Coarse Registration algorithm:
http://scanregistration.cs.princeton.edu
MIT License
49 stars 17 forks source link

conf2fet spend long time #7

Closed WWWJL closed 4 years ago

WWWJL commented 4 years ago

Hi,

  1. I want to use the offline reconstruction to produce the high quality 3d mesh. firstly, I used the conf2fet to generate the .fcb file. In my ubuntu18.04 with 8 Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, it will take 30 minutes to process the 800 frames. used the parameters -load_every_kth_image 5 -min_feature_spacing m -0.05. So could you give your parameters to generate the .fcb file. Thank you!
  2. I use my online reconstruction method(for example bundlefusion/badslam) to generate the pairwise_matches.txt, Firstly, I want to know the pairwise_matches.txt information, Ti = m * Ti-1* and T is the camera to world(pw = T pc)? and I set the sift valid pairs the constant value 200; Secondly, if I understand the pairwise_matches.txt correctly, I run the fetregister, it get the worsely results than online method, it will get the Iteration 0 done in 6.092374 sec. Current error -nan** . Can you help me to solve this, Thankyou very much!

Best Wishes!

mhalber commented 4 years ago

Hi,

Thank you for your interest! As mentioned at the top of the README.md, this repo is no longer maintained. As such I can only offer very limited support. Regarding your questions:

  1. The conf2fet is by far the slowest part of the pipeline. We only needed to run it once for our test sets, and it was never optimized. It suffers from pretty aged memory model, with a lot of heap allocations, which means that a fix would probably mean a ground-up rewrite. It might happen someday, but I currently do not have cycles to do it. Your parameters are what we have used.
  2. My first intuition here is that the methods you mention might use a different coordinate system - did you attempt to verify with a viewer (fetregister needs to be build with USE_WINDOW=1) that the initial reconstruction looks reasonable? Aside from that, my feeling is that even if you solve this issue, you might not see much improvement over badslam or bundlefusion, which both already use some form of global pose correction, if I am not mistaken.

All the best!

WWWJL commented 4 years ago

Hi,

Thank you for your interest! As mentioned at the top of the README.md, this repo is no longer maintained. As such I can only offer very limited support. Regarding your questions:

1. The conf2fet is by far the slowest part of the pipeline. We only needed to run it once for our test sets, and it was never optimized. It suffers from pretty aged memory model, with a lot of heap allocations, which means that a fix would probably mean a ground-up rewrite. It might happen someday, but I currently do not have cycles to do it. Your parameters are what we have used.

2. My first intuition here is that the methods you mention might use a different coordinate system - did you attempt to verify with a viewer (fetregister needs to be build with USE_WINDOW=1) that the initial reconstruction looks reasonable? Aside from that, my feeling is that even if you solve this issue, you might not see much improvement over badslam or bundlefusion, which both already use some form of global pose correction, if I am not mistaken.

All the best!

Hi, Thank you for your reply!

  1. I found the conf2fet is slow because the normal calculation and segmentation( with a lot of heap allocations ); I found the https://github.com/ai4ce/peac plane segmentation algorithm can perform 35FPS, but it will have the non-clusters points, and the conf2fet original's segmentation will have not the non-clusters points except the invalid point, if i am understanded the conf2fet correctly.
  2. It is my fault, use a different coordinate system. I indeed not see much improvement over badslam or bundlefusion, but it still has a little improvement. So the Fine-to-Coarse Algorithm fails under what circumstances?

Best wisehs!

mhalber commented 4 years ago

Hi again,

  1. I don't believe there is nothing fundamental about the task of plane detection that disables implementation of fast algorithms. This however was not a priority for this project and it has never been optimized.
  2. As mentioned in the paper, Fine-to-Coarse algorithm focus was on incorporating priors about indoor environments (Manhattan World Assumption) into the pose estimation. As such if these priors are incorrect for your environment, then the algorithm will not produce correct results. We have found that rooms that have trapezoidal floor plan are particularly tricky for this algorithm.

It seems to me that you managed to resolve the coordinate system issue, so I will close this for now.