ngff
ngff copied to clipboard
ome
Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.
related to #64 and https://github.com/kevinyamauchi/ome-ngff-tables-prototype , as discussed this morning with @kevinyamauchi this is a description of adata slots and how they are used in https://github.com/theislab/squidpy and other spatial analysis...
Over the past few weeks we assembled a draft for a "rendering settings" specification (current spec: https://ngff.openmicroscopy.org/latest/#omero-md ); taking into account how OMERO stores rendering information, how other image formats...
There are a few clarifications that could improve the spec (without changing any content). This could be done for a version 0.4.1 or just rolled into 0.5. - [ ]...
I am working on converting data with segmentations to ngff using the "image-label"s. There are a couple of questions about the description in https://ngff.openmicroscopy.org/latest/#label-md: 1. Are "colors" and/or "properties" mandatory...
At various locations in the current specification, a path is stored to another group or array within the same fileset: * The datasets of multiscales link to the individual arrays...
(Following on discussion from https://github.com/ome/ngff/pull/85) As schematized by @constantinpape [here](https://github.com/ome/ngff/pull/85#issuecomment-1044233185), the current (0.4) version of the spec results in a hierarchy like this: ``` image-group/ .zgroup
- [x] MUST DO - [x] Finalize axes & transformations #85 - [x] Update the example data (e.g. in https://github.com/ome/ome-ngff-prototypes) for changes in #85 - [x] Finalize support in ome-zarr-py/ome-zarr-napari,...
All the metadata JSON could be stored separately and included in order to be tested by one or more implementations.
I am a bit confused by the different versions of the spec that are stored in this repository: We have the specs for the individual versions, right now `0.1` and...
see: https://github.com/tischi/i2k-2020-s3-zarr-workshop/issues/9#issuecomment-732369669 The current spec allows for each resolution level to be a different dtype. This should be restricted with a clause that they "MUST be the same".