Skip to content

Commit 38ab95d

Browse files
committed
Propose resolution _groups_ for xarray support (see ome#48)
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 ```
1 parent caa7e8e commit 38ab95d

File tree

1 file changed

+15
-11
lines changed

1 file changed

+15
-11
lines changed

latest/index.bs

Lines changed: 15 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -141,19 +141,23 @@ For this example we assume an image with 5 dimensions and axes called `t,c,z,y,x
141141
│ # "multiscales" and "omero" (see below). In addition, the group level attributes
142142
│ # must also contain "_ARRAY_DIMENSIONS" if this group directly contains multi-scale arrays.
143143
144-
├── 0 # Each multiscale level is stored as a separate Zarr array,
145-
│ ... # which is a folder containing chunk files which compose the array.
146-
├── n # The name of the array is arbitrary with the ordering defined by
144+
├── 0 # Each multiscale level is stored as a separate Zarr group
145+
│ # which contains arrays of data at that particular resolution level.
146+
│ ...
147+
├── n # The name of the group is arbitrary with the ordering defined by
147148
│ │ # by the "multiscales" metadata, but is often a sequence starting at 0.
148149
│ │
149-
│ ├── .zarray # All image arrays must be up to 5-dimensional
150-
│ │ # with the axis of type time before type channel, before spatial axes.
151-
│ │
152-
│ └─ t # Chunks are stored with the nested directory layout.
153-
│ └─ c # All but the last chunk element are stored as directories.
154-
│ └─ z # The terminal chunk is a file. Together the directory and file names
155-
│ └─ y # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
156-
│ └─ x # will be `dimension_size / chunk_size`.
150+
│ └── image # Within the group, there will typically be a single array named "image".
151+
│ │ # Other arrays may be added in future versions.
152+
│ │
153+
│ ├── .zarray # All image arrays must be up to 5-dimensional
154+
│ │ # with the axis of type time before type channel, before spatial axes.
155+
│ │
156+
│ └─ t # Chunks are stored with the nested directory layout.
157+
│ └─ c # All but the last chunk element are stored as directories.
158+
│ └─ z # The terminal chunk is a file. Together the directory and file names
159+
│ └─ y # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
160+
│ └─ x # will be `dimension_size / chunk_size`.
157161
158162
└── labels
159163

0 commit comments

Comments
 (0)