You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RFC-2 for OME-NGFF has been adopted as part of the specification. This RFC bumps the NGFF version to 0.5, and uses Zarr v3 as the sole underlying storage format:
This RFC proposes to adopt version 3 of the Zarr format for OME-Zarr. Images that use the new version of OME-Zarr metadata MUST NOT use Zarr version 2 any more.
Zarr v3 is particularly beneficial for large bioimaging data since it supports sharding, allowing for fast parallel reads of slices across ND arrays without producing many (millions) of chunk files. Since managing chunk size to balance file count and read speed is a common trade-off iohub users have to make, iohub should implement OME-NGFF v0.5 and phase out writing (but keep supporting reading) of v0.4.
Currently, we cannot start the implementation because zarr-python, our primary Zarr backend, has not released a stable v3. However the v3 release should come soon.
RFC-2 for OME-NGFF has been adopted as part of the specification. This RFC bumps the NGFF version to 0.5, and uses Zarr v3 as the sole underlying storage format:
Zarr v3 is particularly beneficial for large bioimaging data since it supports sharding, allowing for fast parallel reads of slices across ND arrays without producing many (millions) of chunk files. Since managing chunk size to balance file count and read speed is a common trade-off iohub users have to make, iohub should implement OME-NGFF v0.5 and phase out writing (but keep supporting reading) of v0.4.
Currently, we cannot start the implementation because zarr-python, our primary Zarr backend, has not released a stable v3. However the v3 release should come soon.
cc @JoOkuma @ieivanov
The text was updated successfully, but these errors were encountered: