[features] "Allow setting both K and radius"

[feixyz10]

Currently setting both K and radius is not allowed, e.g. for normal estimation. Here is the source code: line 138 in feature.hpp

PCL_ERROR ("Both radius (%f) and K (%d) defined! ", search_radius_, k_);

I am wondering what is the consideration behind this kind of design.

In my opinion, it would be very useful if setting both is allowed.

[JStech]

You'd have to know which takes precedence. Whichever picks more points? Or less? Or just always use one over the other?

Do you have a specific use case in mind?

[feixyz10]

Setting both paramters means to find at most K nearest points within the sphere.

For example, I have a cloud with dense points in some regions and spare points in some other regions (this is quite common), and I want estimate normal for each point. Usually I prefer to use a larger K to get more smooth estimation. But for points in sparse regions, large K would bring faraway points into computation, which make normal estimation of these points in sparse regions quite inaccurate.

Allowing setting both, I think, can make a good tradeoff and solve the problem.

[mvieth]

Sounds like the max_nn parameter of radiusSearch is what you are looking for, but there is currently no way to use that in features.

In your use case, would it work for you to just set the radius? Then the computation would use many points in dense regions, and few points in sparse regions, and never points that are far away.

[feixyz10]

Just setting the radius, as @mvieth suggusted, is possibly a solution. But parameter tunning could be potentially a trouble, since flexibility is much lower than that of allowing two parameters to be set. And I guess that in many cases even no matter how you tune just one paramter you cannot get comparable performance when you can tune two.

So, would please let radiusSearch integrated into features?

[mvieth]

You are welcome to create a pull request to introduce such a feature. Alternatively, we can leave this issue open as a "feature request" for someone else who is interested in implementing this.

It should definitely be clear to the user what setting both parameters means. Like @JStech noted, this could have several possible interpretations:

1. Add a point to the result list if it is within the radius and among the k nearest points (intersection)
2. Add a point to the result list if it is within the radius or among the k nearest points (union)
3. Something else?

It should also be verified that when setting max_nn, the max_nn nearest points are in the result list, not just any max_nn points within the radius. I can't 100% guarantee that this is the case for all implementations right now.

[feixyz10]

Fine. I'll try. Thanks a lot.