Skip to content

Commit

Permalink
Propose resolution _groups_ for xarray support (see ome#48)
Browse files Browse the repository at this point in the history
In discussing with the xarray community, the one change to the NGFF
specification that needs to occur to prevent errors being raised
when opening a multiscale is for each resolution _array_ to live
in a separate _group_. This has already been tested by thewtex
in https://github.com/spatial-image/spatial-image-multiscale and
the current spec is permissive enough to allow it. The proposal
here would enforce the subdirectories moving forward.

The conflict in xarray stems from the fact that each of our
subresolutions have the same dimension names ("x", "y,", etc.)
but different sizes. This is not allowed in the xarray (nor NetCDF)
model. An added benefit of this change is that other arrays with
the same resolution levels and the same dimensions (e.g. labels!)
could be stored together:

```
    ├── resolution-N/.zgroup
    │   ├── image/.zarray
    │   └── labe/.zarray
```
  • Loading branch information
joshmoore committed Apr 21, 2022
1 parent caa7e8e commit 38ab95d
Showing 1 changed file with 15 additions and 11 deletions.
26 changes: 15 additions & 11 deletions latest/index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -141,19 +141,23 @@ For this example we assume an image with 5 dimensions and axes called `t,c,z,y,x
│ # "multiscales" and "omero" (see below). In addition, the group level attributes
│ # must also contain "_ARRAY_DIMENSIONS" if this group directly contains multi-scale arrays.
├── 0 # Each multiscale level is stored as a separate Zarr array,
│ ... # which is a folder containing chunk files which compose the array.
├── n # The name of the array is arbitrary with the ordering defined by
├── 0 # Each multiscale level is stored as a separate Zarr group
│ # which contains arrays of data at that particular resolution level.
│ ...
├── n # The name of the group is arbitrary with the ordering defined by
│ │ # by the "multiscales" metadata, but is often a sequence starting at 0.
│ │
│ ├── .zarray # All image arrays must be up to 5-dimensional
│ │ # with the axis of type time before type channel, before spatial axes.
│ │
│ └─ t # Chunks are stored with the nested directory layout.
│ └─ c # All but the last chunk element are stored as directories.
│ └─ z # The terminal chunk is a file. Together the directory and file names
│ └─ y # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
│ └─ x # will be `dimension_size / chunk_size`.
│ └── image # Within the group, there will typically be a single array named "image".
│ │ # Other arrays may be added in future versions.
│ │
│ ├── .zarray # All image arrays must be up to 5-dimensional
│ │ # with the axis of type time before type channel, before spatial axes.
│ │
│ └─ t # Chunks are stored with the nested directory layout.
│ └─ c # All but the last chunk element are stored as directories.
│ └─ z # The terminal chunk is a file. Together the directory and file names
│ └─ y # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
│ └─ x # will be `dimension_size / chunk_size`.
└── labels
Expand Down

0 comments on commit 38ab95d

Please sign in to comment.