[Done] Improvement on the connected component and octree
Posted: Fri May 03, 2013 12:57 pm
Hi Daniel,
this requests comes from our use of the connected component feature and the way the octree structure can be used for some data analysis.
Our first problem is that when we use the connected component (to segment individual plants, trees, boulders etc....) we cannot use a fixed minimum distance between connected points as it is fixed by the octree level, which is itself imposed by the max size of the cloud. A possibility is to trim all the point clouds at the same time to the same extent, but this is really annoying.
1. One solution would be to impose a true minimum distance so that you're independent of the octree level, and can use the same parameters for differents scenes or epochs. This gives the possibility to fine tune your segmentation distance (rather than to depend on the 10 available octree sizes).
If this is too complicated, another solution (less ideal) could be to be able to impose the size of the octree at level 0 which would be larger than the scene size (i.e. 1000 m), and potentially unlock more octree levels to get down to a few cm (I guess the 64bit version could handle this). This way if we want our minimum distance to be systematically ~12 cm, we choose an octree level 0 of size 1000 m and impose an octree level 13 for the connected component calculation.
I think more generally, that it could be interesting to be able to impose the octree size. For instance, we're working on estimating the volume of plants, and for this a first order estimate can be obtained by summing up the volume of octree cells covering the plant at a given octree size (obviously fine enough). We want this octree size to be always the same whatever the size of the plant in order to compare things on the same basis. So here is my second request :
2. could you for a given cloud and for a given octree size output the volume(or the number of cells) corresponding to the octree cells ?
I don't realize how significant these change are but I'm sure that for people working on vegetation (and I know there are many out there), this would be extremely useful.
this requests comes from our use of the connected component feature and the way the octree structure can be used for some data analysis.
Our first problem is that when we use the connected component (to segment individual plants, trees, boulders etc....) we cannot use a fixed minimum distance between connected points as it is fixed by the octree level, which is itself imposed by the max size of the cloud. A possibility is to trim all the point clouds at the same time to the same extent, but this is really annoying.
1. One solution would be to impose a true minimum distance so that you're independent of the octree level, and can use the same parameters for differents scenes or epochs. This gives the possibility to fine tune your segmentation distance (rather than to depend on the 10 available octree sizes).
If this is too complicated, another solution (less ideal) could be to be able to impose the size of the octree at level 0 which would be larger than the scene size (i.e. 1000 m), and potentially unlock more octree levels to get down to a few cm (I guess the 64bit version could handle this). This way if we want our minimum distance to be systematically ~12 cm, we choose an octree level 0 of size 1000 m and impose an octree level 13 for the connected component calculation.
I think more generally, that it could be interesting to be able to impose the octree size. For instance, we're working on estimating the volume of plants, and for this a first order estimate can be obtained by summing up the volume of octree cells covering the plant at a given octree size (obviously fine enough). We want this octree size to be always the same whatever the size of the plant in order to compare things on the same basis. So here is my second request :
2. could you for a given cloud and for a given octree size output the volume(or the number of cells) corresponding to the octree cells ?
I don't realize how significant these change are but I'm sure that for people working on vegetation (and I know there are many out there), this would be extremely useful.