Hi,
I am just looking at ome-zarr-py. From the discussion in the issues I can see that there are ways to specify class annotations for labels in label images (added by @DragaDoncila).
Is there also a standard (or even support) for saving ROI data, such as polygons or rectangle annotations (maybe also with a name and a class label)? How would that work on multiscale images?
Hi @VolkerH,
not as yet. At one of the last community calls (end of October), this certainly came up. As in ROI format : format .roi of imageJ, the current running suggestion was to integrate WKT/WKB as a first step, though there were ideas for more advanced formats, like the meshes discussion in Mesh data in ome-zarr - #5 by kephale. I imagine this is one of the topics where someone motivated will need to push forward with a proposal so that we can all hammer on the actual implementations.
~Josh
We’re quite interested in pushing this forward. Will follow up within a week.
~Kyle
Hi all,
I’m also game for working on this!
For meshes, I think translating the PLY specification to zarr is the easiest thing to do, with the following organization:
mesh.zarr/
├── .attrs
├── edge
│ ├── 0
│ └── .array
├── face
│ ├── 4
│ ├── 5
│ ├── 6
│ ├── 7
│ └── .attrs
└── vert
├── 0
└── .array
i.e the topmost .attrs contains the PLY header, and we sort faces by their number of sides, and have one group per polygon number of sides.
For ROI, PLY can store polygons (and is extensible), but is less common than WKT as a ROI format…
Last but not least, the mechanism for a common reference frame discussed there is also important here.
Still interested as well, although I have very little bandwidth currently.
I like PLY as base because it seem quite flexible in the number of dimension of vertices (a volume tracked in time could be a 4D ROI?), in the variety of faces and additional attributes one can add. It should fit most use case I can think of (triangulated mesh in 3D, epithelium in 3D+t, neuronal arbor (=tree in 3D), etc…)
Agreed. I haven’t run into any cases where working from PLY would be a limitation. I need to check into the common reference frame discussion. We’re storing scenegraphs that have hierarchies of reference frames, so I would make sure that the reference frames can be nested.
There was a question of specifying transforms I think from one ref. frame to the other?
For multiscale ROIs / polygons we might be interested in looking at the mapbox vector-tiles specification as I’ve heard it handles multiscale quite nicely. I’ve not used it myself, but I think and it is widely used in the mapping/ geospatial community. Could give good ideas towards an ome-zarr implementation.
Whatever is decided here for either shapes or meshes, we can then work to make sure that napari can easily visualize the format if people choose.
Yes, looking at what the geospatial community has certainly sounds like a great idea.
I was just thinking of the opposite direction. Saving annotations made in napari into a zarr file.
Reading this, I realise there is a case where PLY is in default:
The PLY format is NOT intended to be a general scene description language, a shading language or a catch-all modeling format. This means that it includes no transformation matrices, object instantiation, modeling hierarchies, or object sub-parts. It does not include parametric patches, quadric surfaces, constructive solid geometry operations, triangle strips, polygons with holes, or texture descriptions (not to be confused with texture coordinates, which it does support!).
(quote from PLY’s specification)
I think this is bad for ROIs, there are often holes in them (e.g when selecting the cytoplasm). So no one size fits all 