search

ome / ngff

Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.
https://ngff.openmicroscopy.org
Other
117 stars 38 forks source link

Shapes #73

Open will-moore opened 3 years ago

will-moore commented 3 years ago

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

glyg commented 3 years ago

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

will-moore commented 3 years ago

cc'ing @BioinfoTongLI from vizarr issue above.

will-moore commented 3 years ago

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

imagesc-bot commented 2 years ago

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 commented 5 months ago

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