-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Feaure matching API #5964
Feaure matching API #5964
Conversation
Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes. |
54b1821
to
dfab86f
Compare
dfab86f
to
71489d9
Compare
5d25e5e
to
f04364b
Compare
753114b
to
a8e173b
Compare
Thank you for providing this pull request! If I understand correctly, this will enable users to get correspondences from a set of features using the |
Yes, see |
/// of the aforementioned correspondence set where source[i] and target[j] are | ||
/// mutually the nearest neighbor. If the subset size is smaller than | ||
/// mutual_consistency_ratio * N, return the unfiltered set. | ||
core::Tensor CorrespondencesFromFeatures(const core::Tensor &source_features, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Future PR is OK] Lowe ratio test as an alternative to mutual filter. This has a parameter to allow control over which matches are acceptable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable, will do in a future PR
|
||
dst_fpfh_import = o3d.pipelines.registration.Feature() | ||
dst_fpfh_import.data = dst_fpfh_np | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make this clearer, can we have a function that computes FPFH features and stores in an npy file. Then another function that reads from that file and uses the new API? A --save-features
argument can control this behavior. This can be useful even just with FPFH if we are doing multiway registration [implementation not needed here].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intend to extend this example with support to this functionality. However, there are inconsistencies between tensor point cloud downsample (nearest corner per voxel) and the legacy (mean per voxel). I will make another PR regarding t point cloud, and revisit this example.
@@ -90,6 +90,60 @@ core::Tensor ComputeFPFHFeature(const geometry::PointCloud &input, | |||
return fpfh; | |||
} | |||
|
|||
core::Tensor CorrespondencesFromFeatures(const core::Tensor &source_features, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these are CUDA tensors, should we copy them to the CPU first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is no need, as tensor nns backend is able to query properly (and fast). The conversion only has to be done for calling ransac.
very great work! very appreciate for this. |
* expose correspondences from features api for external feature usages and debugging * Improve FPFH feature matching time
correspondences from features
api for global registration from external point-wise 3D features (e.g. FCGF).In theory a tensor RANSAC API could be included as well, but there are various problems. Problem analysis step by step.
Total registration time (s) (100K iterations)
Average run time breakdown (model selection/estimation/check happens every iteration; model validation only happens 250 times per 100K iterations)
Problem:
ComputeTransformation
;SelectByIndex
) are only suitable for large inputs. The tensor overhead is overwhelmingly large for small data.Potential solutions:
wei/ransac-tensor
Type
Motivation and Context
Checklist:
python util/check_style.py --apply
to apply Open3D code styleto my code.
updated accordingly.
results (e.g. screenshots or numbers) here.
Description
This change is