regarding the discussion about shapes in #33, there is the question of the desired standard to do that, basically either WKT or GeoJSON. It seems to me that GeoJSON would be better suited? But neither provide geometry primitives like rectangles circles or ellipses, and both are 2D.

Also it is not clear to me if ROIs specification should be a subclass of shape or the other way around (as you can also specify ROIs with e.g. a list of pixels?

See also: #41 with respect to polygons

cc'ing @BioinfoTongLI from vizarr issue above.

I prefer GeoJSON over WKT, simply because it's JSON!

But I expect we'd have to abuse the GeoJSON standard a bit to do all the things we want.

"GeoJSON supports the following geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection".

So we're missing Ellipse and possibly Rectangle.
Also, going beyond 3D is discouraged:

https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.1
"Implementations SHOULD NOT extend positions beyond three elements
because the semantics of extra elements are unspecified and
ambiguous. Historically, some implementations have used a fourth
element to carry a linear referencing measure (sometimes denoted as
"M") or a numerical timestamp, but in most situations a parser will
not be able to properly interpret these values. The interpretation
and meaning of additional elements is beyond the scope of this
specification, and additional elements MAY be ignored by parsers."

But otherwise, I guess we can use a lot of what's there without having to re-invent a new format. 👍

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/interchange-formats-for-rois-a-k-a-graphical-annotations/65798/2

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/roi-annotations-and-tracking-information-in-ome-zarr/65975/7