Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shapes #73

Open
will-moore opened this issue Nov 4, 2021 · 5 comments
Open

Shapes #73

will-moore opened this issue Nov 4, 2021 · 5 comments

Comments

@will-moore
Copy link
Member

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: hms-dbmi/vizarr#127

Related to #33 (Mesh specification).

@glyg
Copy link
Contributor

glyg commented Nov 4, 2021

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

@will-moore
Copy link
Member Author

cc'ing @BioinfoTongLI from vizarr issue above.

@will-moore
Copy link
Member Author

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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants