search

ome / ngff

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

Allow `.` as the dimension separator #135

Open jstriebel opened 2 years ago

jstriebel commented 2 years ago

Since v0.2, / is the only allowed dimension separator for OME NGFF chunk paths. To be compatible with Zarr arrays in general, it would be great to also allow . as the dimension separator, depending on the Zarr metadata if available.

This allows to add OME metadata to existing Zarr arrays, that already use the . dimension separator.

joshmoore commented 2 years ago

Thanks for capturing this, @jstriebel. I can't remember if I mentioned to you or to Norman but for everyone: the hard requirement on a single separator was required while the dimension_separator addition was being add to the Zarr v2 spec. At this point, I think it's fine to drop. If either of you want to drive that, please feel free. The major caveat will be that the implementations will need to be updated as well.

(There have also been requests to support Zip-based NGFFs which will touch the same code paths.)

normanrz commented 2 years ago

We are happy to drive this. Fwiw, I wouldn't interpret the current spec to have a strict / requirement, because it is not explicitly mentioned. Other parts of the Zarr spec are also not re-defined in the OME-NGFF spec, so, I would assume all features of zarr v2 are valid. Most implementations that support OME-NGFF already support ., because of their underlying zarr implementations.

joshmoore commented 2 years ago

Then we're looking at different implementations which is a good realization itself :smile:

 │   └─ t                  # Chunks are stored with the nested directory layout.
normanrz commented 2 years ago

I see. To me the directory listing seemed more like an example section than a normative section.