Established methods: Honestly, I don’t think it qualifies yet as “established, well documented in the literature and widely used by the imaging community”. There is a paper Redirecting from 2014. Google Scholar finds 4 citations (1 preprint, 1 same author).
Personally, I feel that this method may still be useful to include in scikit-image and also kind I am a little invested because fercer and others already put in some work. Still, it’s a complex and large contribution that is not trivial to review.
I just want to lend my support to including this. In general working with polygons in Python is a pain and it’s hard to find good implementations, so I’m glad if we can fill that hole.
As you know, I’m also a little invested in this contribution (not as much as I should!) and I view it favourably. I think it’s valuable for users to expand their possibilities of working with polygons, but I admit the PR is requiring significant review work…
I think, on its own, it is a useful and unique (in Py ecosystem) functionality, even though quite niche.
In skimage, we use polygons primarily to represent the objects in an image and typically merely convert them to the segmentation masks. So, with our current functionality it is quite unlikely to end up with a polygon that would need a handling with the proposed function, unless it is coming from an external processing routine. Accordingly, I would say that the addition is a borderline accept/reject, with ties slightly towards accept.
Sorry if my opinion does not help to reduce the uncertainty.
That’s a very good point. If functions in scikit-image were to return such polygons I’d view this as an argument in favor. Otherwise, it’s not necessarily a point against it though.
Maybe we should ask were it’s most likely that this function will be discovered, expected and useful. E.g. is this more likely for scikit-image or for Shapely? I can also find SymPy, Planar, …
I think we will want to support polygons going forward. imho in the context of skimage2 we should check how to best maximise compatibility with other libraries such as Shapely, but we should have our own first-class support because it is needed in many image analysis tasks, and Shapely is too big a dependency for us (I think).
But, we have a long-running Rectangle PR for a reason:
which is that dealing with shapes is useful and natural in many analysis contexts, and unannotated NumPy arrays or tuples simply don’t provide enough information for downstream use.
Still, it’s a complex and large contribution that is not trivial to review.
—, but I trust your decision. +