Bug in FPFHEstimation ?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in FPFHEstimation ?

Maxime Latulippe
Hi all,

There seems to be numerical approximation errors in the FPFHEstimation class. I realized, using a multiscale feature persistence analysis, that the number of persistent FPFHs retained changes depending on the position/orientation of the point cloud.

For example, using the bunny dataset, I get 2323 persistent FPFHs on the original data and 2390 on the data translated by 0.1 on the x axis. By saving the descriptors to a file, we can see that the FPFH values change slightly from one cloud to the other. Even if those variations are very small, they should not exist since the FPFH descriptor is pose invariant.

I will get my hands dirty and try to find where this problem comes from. Can anyone check this also and confirm the errors? I attached the code that reproduces the error.

test.cpp

Maxime Latulippe
Master student, Laval University (Quebec)
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPFHEstimation ?

Radu B Rusu
Administrator
Maxime,

As far as I'm aware of, the feature persistence should not influence the FPFH calculation unless we have a bug. I'm a
bit busy for the next few days, so I'd appreciate any additional tests/information you can find. The values are computed
from the relative point values and normal orientations, so unless those values change relative to each other, the values
should be the same.

The first test that I would do is check to see how the surface normals change with respect to each other, whether they
are flipped correctly towards the viewpoint / oriented consistently, etc.

Cheers,
Radu.

On 06/05/2012 06:43 AM, Maxime Latulippe wrote:

> Hi all,
>
> There seems to be numerical approximation errors in the FPFHEstimation
> class. I realized, using a multiscale feature persistence analysis, that the
> number of persistent FPFHs retained changes depending on the
> position/orientation of the point cloud.
>
> For example, using the bunny dataset, I get 2323 persistent FPFHs on the
> original data and 2390 on the data translated by 0.1 on the x axis. By
> saving the descriptors to a file, we can see that the FPFH values change
> slightly from one cloud to the other. Even if those variations are very
> small, they should not exist since the FPFH descriptor is pose invariant.
>
> I will get my hands dirty and try to find where this problem comes from. Can
> anyone check this also and confirm the errors? I attached the code that
> reproduces the error.
>
> http://www.pcl-users.org/file/n4018958/test.cpp test.cpp
>
> Maxime Latulippe
> Master student, Laval University (Quebec)
>
> --
> View this message in context: http://www.pcl-users.org/Bug-in-FPFHEstimation-tp4018958.html
> Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPFHEstimation ?

Maxime Latulippe
Hi Radu,

Thank you for your response. The problem was the orientation of the normals. By translating the point cloud, the normals were flipped towards the same viewpoint than the original point cloud, which is not correct. So there were differences in the normal orientations between the two point clouds. I added these lines of code and now it works well:

Eigen::Vector4f centroid;
pcl::compute3DCentroid(*cloud,centroid);
ne.setViewPoint(centroid[0], centroid[1], centroid[2]);

There is still a very small difference in the number of persistent FPFHs (about 1%). I guess this is probably due to the float representation of the point coordinates. Translating the points by 0.1 must imply small numerical errors...

Maxime
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPFHEstimation ?

Radu B Rusu
Administrator
Maxime,

Thanks for your fast reply. Glad to hear things are working out now.

Regarding the precision, I'm wondering if switching to doubles internally would help. The calculations will be slower,
but if you're looking for that extra precision, it might help.

Don't hesitate to ping us if you have any other problems.

Cheers,
Radu.

On 06/07/2012 12:58 PM, Maxime Latulippe wrote:

> Hi Radu,
>
> Thank you for your response. The problem was the orientation of the normals.
> By translating the point cloud, the normals were flipped towards the same
> viewpoint than the original point cloud, which is not correct. So there were
> differences in the normal orientations between the two point clouds. I added
> these lines of code and now it works well:
>
> Eigen::Vector4f centroid;
> pcl::compute3DCentroid(*cloud,centroid);
> ne.setViewPoint(centroid[0], centroid[1], centroid[2]);
>
> There is still a very small difference in the number of persistent FPFHs
> (about 1%). I guess this is probably due to the float representation of the
> point coordinates. Translating the points by 0.1 must imply small numerical
> errors...
>
> Maxime
>
> --
> View this message in context: http://www.pcl-users.org/Bug-in-FPFHEstimation-tp4018958p4019110.html
> Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPFHEstimation ?

blackibiza
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPFHEstimation ?

Radu B Rusu
Administrator
Can you please check first if that helps in a local copy on your machine?

Cheers,
Radu.

On 06/07/2012 11:10 PM, blackibiza wrote:

> perhaps an overloaded function which takes as parameter the flag
> "high_precision" = true/false for calling the execution of the function with
> the floats or the one with doubles would be a good deal, no?
>
> --
> View this message in context: http://www.pcl-users.org/Bug-in-FPFHEstimation-tp4018958p4019126.html
> Sent from the Point Cloud Library (PCL) Users mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email] / http://pointclouds.org
> http://pointclouds.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pointclouds.org
http://pointclouds.org/mailman/listinfo/pcl-users