Is there a way to create single "horseshoe" polygon around hole regions?

[rwtam121]

I'm wondering if it's possible for QuPath to automate a process that draws something like the below right image, breaking apart the lines of the left image.

I ask because when deploying my qupath coordinates to a server the server currently does not support hole generation. I also don't want to force a connection between the outer and inner polygons, leaving a line in between the two. So I was wondering if the "horseshoe" idea is possible...can we write code to break a small part of the inner and outer polygons and establish a connection between them, and do this across all inner polygons (if an outer polygon has multiple inner polygons?).

[Svidro]

I can think of easy enough ways to get the single horseshoe idea to work, but it sounds like you would want this to find multiple holes and interconnect them all, and the outside of the exterior polygon? At that point you need something like nearest neighbors to find the closest vertices of all of the inner polygons, and after that connect the inner polygons to the outer polygon using another nearest neighbors based on the entire interior structure...

And this could get really bad depending on how many vertices were on the outer polygon (open up a massive highway if two vertices are far enough apart due to smoothing or the edge of an image/slide). Maybe a safer way would be to create very thin (1 pixel wide) rectangles between single vertices and subtract annotations? Just kind of spitballing here. I do not have enough experience digging into AWT polygons to know the structure of the vertices.

[petebankhead]

It's an interesting idea and challenge, but I agree with @Svidro - it would be hard to solve in a really generic way. And then there are potential issues with having multiple holes within the same annotation, or multiple disconnected regions as well as holes...

Can you describe a bit more why this is necessary? For example,

• In which format do you plan to export the polygons?
• Do you need to visualize the polygons on the server, or just store them there?
• Do the polygons need to be used for measurements / analysis in software other than QuPath?

If only for storage, alternative approaches might be

• Store binary images representing the annotations instead
• Store zipped .qpdata files

If not need visualization too, you could potentially export separate exterior and hole polygons - and then flag which is which using a naming scheme or colors. The 'true' shapes might then be recreated with an import script in QuPath, if necessary.

[Svidro]

I wonder if there is some way to convert AWT objects into polygons? You could then classify by parent/child and export two sets of polygons... which you might be able to subtract on arrival or use one set for exclusion. Which I suppose fits in with the questions about final use.

[rwtam121]

Thanks for the responses. @Svidro , yeah @petebankhead provided code to split area AWT regions into polygons here: #99. It definitely works to isolate the parent/child polygons and is a step in the right direction; plotting area AWT creates all these interior regions which cannot be drawn without extraneous lines in my server, since it doesn't support hole generation.

@petebankhead , my workflow involves exporting the polygons into a text file and consolidating its coordinates into a JSON format. I am visualizing the polygons on the server (and also storing its respective JSON as well). If the server supported reading in a JSON format that accepted holes, it would look something like this (via geojson, which unfortunately our server does not support currently):

Without hole support, I'm currently visualizing the "hole" region by through the use of overlapping polygons in the server (those polygons created from the split AWT in QuPath). For instance, in the below image in the server, class 1 has the two overlapping polygons indicating that its larger polygon has a hole in it; class 2 is the region that fills that hole.

But that's inelegant for visualization, which is why I wanted to look into the horseshoe idea. The server renders polygons that connect to the exterior well, and if we can draw lines connecting to the outer region within QuPath that would help (even if it seems difficult and troublesome as you mentioned).

[petebankhead]

I guess since the split method gives you the arrays for the exterior polygons and for the holes, you could do an exhaustive search for the pair of vertices where one of the points on the exterior is closest to a point on the interior. Then insert the interior points into the exterior polygon's list of vertices and... see how that looks.

It sounds like you've been able to get all the data out of QuPath, and now it becomes a problem to solve elsewhere. Not sure how much influence you have on the server, but getting it to support GeoJSON/shapes with holes would sound more rewarding... albeit potentially difficult.

I can definitely envisage writing a generic GeoJSON exporter for QuPath ROIs; that sounds like something worthwhile (related to the recent discussion on shapefiles). This has been on my personal todo list for a while, but pretty low priority as I don't have a specific need for it at the minute - and nor do I know of anyone with such a need. It would definitely be higher priority it it helped interoperability with software for some genuinely useful purpose. But I'm not sure if it would help much in your case, unless you can get your server to support GeoJSON.