libpointmatcher
libpointmatcher copied to clipboard
Deprecated use of Voxel in Gestalt filter
As the use of voxel should be deprecated, this filter should use an Octree (for 3D points) or a Quadtree (for 2D points) instead of voxels.
Plus by construction of the octree, the algorithm could be simplified since we have the information of the k-NN in the node. For instance, if we want k points to compute covariance, we just need to build the octree/quadtree with this number of point as criterion (plus, the cells containing less than k points could be ignored, acting like a filter for very sparse space partition).
@MathLabu in the second paragraph of your comment above, were you actually suggesting to use the octree for finding neighbors, instead of running K-NN?
For that sake, would you build the octree, and then to query the neighbors of a point, just navigate the octree nodes recursively until reaching the area around that point?
I don't exactly remember what I meant at this time :sweat_smile: But I think my comment only applies to the Gestalt filter, so not really suggesting to use the octree instead of a knn for finding neighbors in general.
In this filter, around here, a search for nearest-neighbors is done.
I guess what I meant was to use the octree as spatial representation instead of the voxel (because of memory issue), and try to adapt the algorithm to leverage the octree for the computation, by applying the a visitor that would perform the actual computation at each leaf (for instance, computing covariance for leaf having at least k points)!
@MathLabu I think your idea is quite solid, and applicable to other filters that depend on local patches around points, such as computation of surface normals, features, statistical outlier rejection, region growing, etc.
I hope in the future we have the chance to test this.