I’m not aware of anything – QuPath should contain the necessary logic, but it moves through its own intermediate representation so I suspect you’d want to skip that for something more direct.
I expect conversion to an ImageJ ROI should be relatively ok, since the GeoJSON specification is nicely-written.
The relevant bits in the QuPath code:
Note that, at the end, for complicated stuff it creates a java.awt.Shape
and generates a ShapeRoi
from this… leaving a lot of the most difficult logic up to Java AWT. To help, I used the ShapeWriter
from JTS: (source here).
Conversion from ImageJ to GeoJSON is likely much more awkward.
The relevant bits of the QuPath code:
By far the most awkward / error-prone part is handling multipolygons – particularly as they can contain holes, and (most evil of all) positive regions nested within holes. Earlier QuPath pre-release versions continually failed with some obscure shapes, but I think the logic is pretty robust now.
The most general way I can think of achieving a conversion is:
- Handle the ‘easy’ cases (lines, points, rectangles… ellipses aren’t really supported)
- Convert any complicated areas (including ImageJ polygons, since they may have self-intersections – forbidden in geojson) into a
ShapeRoi
and then:
- Get a
java.awt.Shape
from the ShapeRoi
- Generate an
java.awt.geom.Area
object (since this has some guarantees)
- Use the
PathIterator
from the Area
to generate polygons… see here for info on how I did it in the end
I fould JTS useful/indispensable in this, but you should avoid its unreliable ShapeReader
– which only works in the easy cases.