Is the algorithm on division of self overlapping polygons a good fit?

I just noticed that I never got an explicit answer to the question raised in Criteria for including new functionality into scikit-image : @skimage-core how do we feel about adding the function suggested in

to scikit-image and maintaining it? I’d like to get a (silent) consensus on this before we invest more work into this.

Based on our extended criteria in #6488:

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. :pray: Still, it’s a complex and large contribution that is not trivial to review.

1 Like

@jni support’s this:

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.


Hey Lars,
I have zero time these days — not even to have an opinion! :laughing: —, but I trust your decision. +1I’ll-vote-the-same-way-Lars-is-voting from me!

Hi @lagru,

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’ll try to dedicate it a few hours next week. :pray:

1 Like

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. :slightly_smiling_face:

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, …

1 Like

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.