Segmentation module has inconsistent API

[catskul]

EuclideanClusterExtraction::extract requires std::vector<PointIndices> while PCLBase::setIndices requires PointIndices::Ptr.

The result is that if you want to get one to the other a

std::vector<pcl::PointIndices> clusters;
ec.extract( clusters );

extractor.setIndices( 
    boost::shared_ptr<pcl::PointIndices>( 
        new pcl::PointIndices( clusters[0] ) ) );

I suspect this pattern exists in other parts of pcl.

Code that fits the pattern should probably be adjusted to use vector<PointIndices::Ptr> instead if not shared_ptr<vector<PointIndices::Ptr> >

Likewise PCLBase should add an overload for PointIndices and make a copy

[taketwo]

I agree that there is an inconsistency. In fact, there is an even larger problem in my opinion. Currently the segmentation module is a random collection of algorithms with no common interface (unlike e.g. filters module, where there is a base class Filter). Some of them have segment() function to do the main job, others call it extract(). The parameters of these functions are often different.

Thus, if we want to fix the inconsistency you mentioned, I would shoot for a common "consistent" interface for all of the segmentation module.

[greenbrettmichael]

@taketwo have there been any further discussions on creating a segment interface in the last few years?

[taketwo]

Sorry, but I don't recall any.

[greenbrettmichael]

Would this be accepted as a welcome change for post 1.9 or does there need to be some exchange of design/UML prior?

[taketwo]

You are certainly welcome to work on consolidating the interfaces. It would be nice to hear your proposal/plan (up to a reasonable degree of detail) and have a discussion to make sure everyone is happy with it. I don't think we necessarily need UML diagrams, if words/tables/code snippets work better for you, let's use that.

[greenbrettmichael]

I have not forgotten about this. I looked into performing this task and found classes in segmentation that would be difficult to abstract (the example that comes to mind is lccp_segmentation, which instead of providing indices, instructs you to relabel a cloud).
I believe that going through these classes thoroughly to create a proposal interface(s) would take me about 20 hours, then applying the agreed changes would range 5-30 guessing that some changes would be needed to a couple of classes. In that vein I have to put this issue off until after Dec 15, so I can grab a couple of lower hanging fruits and things that I notice as problematic while working with PCL.

[stale]

Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.

[kunaltyagi]

Technically, the effort required is "unknown", but I assume it'd be high