fix: propagate setIndices to correspondence estimation in registration

[AlrIsmail]

Description

This PR resolves issue #3109 where pcl::IterativeClosestPoint (and other registration algorithms inheriting from pcl::Registration) were ignoring indices set via setIndices().

The root cause was that while PCLBase stored the indices, the Registration class was not propagating them to the CorrespondenceEstimation object or the reciprocal search tree during the initialization phase (initCompute). This resulted in the algorithm always searching the full input cloud regardless of user-provided constraints.

Changes

• registration.hpp:
  • Updated initCompute() to propagate indices_ to the correspondence_estimation_ object.
  • Refactored initComputeReciprocal() to utilize PCLBase::initCompute() for consistent initialization and ensured the reciprocal search tree respects the input indices.
• test_registration.cpp:
  • Added a new deterministic regression test IterativeClosestPoint_setIndices that verifies the transformation result with setIndices is identical to physically cropping the point cloud.

Verification

• New Test: PCL.IterativeClosestPoint_setIndices passes successfully along with other existing tests.

[larshg]

Looks good to me - thanks 👍

[mvieth]

First of all, sorry for the delay. I have to say, I am not so sure this is a good idea. The Registration class has many subclasses implementing different methods, and it does not seem that they would all handle the given indices in a consistent manner.

Just as an example, here:

pcl/registration/include/pcl/registration/impl/registration.hpp

Line 202 in 821cf96

output[i] = (*input_)[(*indices_)[i]];

The given indices are used, but in several registration methods, e.g. in ICP:

pcl/registration/include/pcl/registration/impl/icp.hpp

Line 267 in 821cf96

transformCloud(*input_, output, final_transformation_);

The indices are ignored again. So while your new test ensures that the found transformations are identical, the point clouds returned by the two align calls would have different numbers of points (your new test does not test this).

Additionally, when a user calls for example

  reg_indices.setInputSource(source);
  reg_indices.setInputTarget(target);
  reg_indices.setIndices(indices);

Is it really clear that the indices should refer to source? They could just as well refer to target, or to both source and target (I am just thinking about what a user would expect/what the behaviour should be).

So overall, this pull request would likely "encourage" users to use setIndices but I am not sure if we should do that (because the meaning of setIndices might be ambiguous). And even if we wanted to, we would need far more tests to ensure that all registration classes work correctly and consistently.

Two things we could to with relatively low risk:

• Add a warning in registration.hpp if the user called setIndices (maybe indices_->size() != input_->size()) that the behaviour might not be as expected (just a warning, computation should continue)
• Add an overload setInputSource(cloud, indices) to Registration which basically just calls pcl::copyPointCloud(*cloud, *indices, *new_cloud); setInputSource(new_cloud);, as a convenience for users. Perhaps the same for setInputTarget. Ideally, the documentation should then make it clear that points are copied.