[ppf_registration] Incorrect calculation of Point Pair Feature

[magres]

Describe the bug

The classes PPFRegistration and pcl::PPFEstimation use the function pcl::computePairFeatures while feature estimation and aligning , but it issues wrong angle data.

Context

For example with this snippet

PointNormalT p1(10, 10, 10, 0, 0, 10);
PointNormalT p2(50, 10, 10, 0, 10, 0);
float f1, f2, f3, f4;
pcl::computePairFeatures(
p1.getVector4fMap(),
p1.getNormalVector4fMap(),
p2.getVector4fMap(),
p2.getNormalVector4fMap(),
f1, f2, f3, f4);

Expected behavior

f1=pi/2, f2=pi/2, f3=pi/2 is expected.

Current Behavior

f1=0, f2=10, f3=0 is issued.

Your Environment (please complete the following information):

• OS: Windows 10
• Compiler: MSVC 19
• PCL Version 1.11

Possible Solution

Fix the calculation.

[magres]

pcl::computePPFPairFeature make it worse: f1=f2=f3=0

PointNormalT p1(10, 10, 10, 0, 0, 10);
PointNormalT p2(50, 10, 10, 0, 10, 0);
float f1, f2, f3, f4;
pcl::computePPFPairFeature(
p1.getVector4fMap(),
p1.getNormalVector4fMap(),
p2.getVector4fMap(),
p2.getNormalVector4fMap(),
f1, f2, f3, f4);

[mvieth]

This bug seems to be Windows and/or VS19 specific. Can you set pcl::console::setVerbosityLevel(pcl::console::L_VERBOSE);, run the two code snippets again, and see whether there are new messages?

[magres]

whether there are new messages?

There's no extra messages. The problem seems to lie in the sources: computePairFeature and computePPFPairFeature have nothing to do with point pair features got to do.

[mvieth]

What is the value of f4 in both cases?

[magres]

What is the value of f4 in both cases?

f4 is ok, 40 in my case.

[mvieth]

Some further results:
The bug does not seem Windows/VS19 specific after all. The returned features do not seem to be angles, but dot products (so missing acos, and if you consider that acos(0)=pi/2, it makes more sense). I am not yet sure if just the documentation is bad/wrong, or the returned features should really be angles.
Side note: the normals should be normalized, so ..., 0, 0, 1) and ..., 0, 1, 0).
I will try to investigate this further.

[mvieth]

The PPF Estimation and Registration actually use the computePairFeatures (PFH) function instead of the computePPFPairFeature function. Not sure why, maybe because it produces better results? The computePPFPairFeature gives the values you expect (pi/2), but as a dot product (0) instead of an actual angle. The documentation should really reflect this.
Does that answer your questions? We can leave this issue open so that someone improves the documentation in a pull request (or you can do that if you like).

[magres]

Pull request #4702