ngff icon indicating copy to clipboard operation
ngff copied to clipboard

Shapes

Open will-moore opened this issue 2 years ago • 5 comments

Add support for Polygons, Polylines, Lines, Ellipses etc. See https://napari.org/tutorials/fundamentals/shapes.html for ways of representing nD shapes. Prompted by request for viewing Shapes in vizarr: https://github.com/hms-dbmi/vizarr/issues/127

Related to #33 (Mesh specification).

will-moore avatar Nov 04 '21 09:11 will-moore

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: https://github.com/ome/ngff/discussions/41 with respect to polygons

glyg avatar Nov 04 '21 10:11 glyg

cc'ing @BioinfoTongLI from vizarr issue above.

will-moore avatar Nov 04 '21 11:11 will-moore

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. 👍

will-moore avatar Nov 04 '21 15:11 will-moore

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

imagesc-bot avatar Apr 15 '22 07:04 imagesc-bot

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

imagesc-bot avatar May 16 '24 12:05 imagesc-bot