Potential problem with OURCVFHEstimation::computeRFAndShapeDistribution

[translunar]

Well, actually two problems.

Firstly, the output point cloud doesn't have dimensions set. I have a patch for this, but wanted to make sure it was correct, first. It drove me crazy! I was getting out a point cloud of size 2, but width and height were both 0. Presumably this should have width of 2 and height of 1, yes?

Secondly, this function may map one cluster onto more than one CVFH in the case of multiple equally-easy axis disambiguations. Maybe that's how it's supposed to be, but it causes a problem in the 3d rec framework — basically, the OURCVFHEstimator in the rec framework expects that CVFH signatures will map one-to-one onto centroids. Unfortunately, in cases where the axes can't be disambiguated, you can end up with more CVFH signatures than centroids, which is not handled in the rec framework code.

I'm not quite sure how to address this without changing the API. If there is more than one centroid, and the no-disambiguation situation occurs, there's no way to determine the correct mapping between them other than to recalculate the SGURFs for most or all of the centroids.

Presumably this never happens to most people because most people change the axis ratio — but it seems that this is not actually a solution, just a way of reducing the occurrence of this particular problem.

Am I misunderstanding something? I'll keep looking at the code to see if I can find a workaround.

[taketwo]

Presumably this should have width of 2 and height of 1, yes?

Yes, height=1 is the convention for unorganized clouds, which is the case here.

Sorry, cannot comment on the other items.