ome-zarr-rfc4-data

OME-Zarr RFC-4 — Orientation Sample Data

Sample datasets for RFC-4 (Axis Anatomical Orientation) of OME-Zarr (spec · ome/ngff#528). Validator and conformance suite: github.com/fideus-labs/ome-zarr-rfc4-validation.

RFC-4 adds one optional field to spatial axes (type: "space"):

{ "name": "x", "type": "space",
  "orientation": { "type": "anatomical", "value": "left-to-right" } }

value is one of 24 controlled-vocabulary directions naming the axis's lowest→highest coordinate direction. The field is optional per axis: an axis with no anatomical direction is left unannotated.

Overview

• 38 cases across 9 formats: OME-Zarr, DICOM, NIfTI, NRRD, MINC, Analyze, Bruker ParaVision, Varian FDF, whole-slide imaging (Aperio SVS).
• 30 real, 8 synthetic.
• 36 valid, 2 invalid (must-reject).
• All 24 vocabulary terms are present. palmar/dorsal appear only in the synthetic hand phantom; the other 22 appear in real data.
• All 24 terms appear as written OME-Zarr orientation metadata; for the source-format files the orientation is derived from the native header (DICOM IOP, NIfTI affine, NRRD space directions, MINC direction cosines).

Every case is indexed in manifest.csv: test_id, format, path, category, expect, rfc4_rules, orientation, data, source, license, notes.

Download

Clone this repo (git + git-lfs) or browse the file tree above. The data is also mirrored to a public Filebase S3 bucket, readable without credentials:

# a single file over plain HTTP
curl -O https://ome-zarr-rfc4.s3.filebase.io/manifest.csv

# the whole corpus via the anonymous S3 API (endpoint https://s3.filebase.io)
s5cmd --no-sign-request --endpoint-url=https://s3.filebase.io sync 's3://ome-zarr-rfc4/*' ./data/
# or with the AWS CLI
aws --no-sign-request --endpoint-url=https://s3.filebase.io s3 sync s3://ome-zarr-rfc4 ./data

An OME-Zarr can also be read straight from the mirror — e.g. ngff_zarr.from_ngff_zarr("https://ome-zarr-rfc4.s3.filebase.io/ome-zarr/heart_sunnybrook_apex_base.ome.zarr") (with the ngff-zarr[remote] extra).

Contents

One folder per format at the repo root.

manifest.csv              index of all 38 cases

ome-zarr/  18  OME-Zarr volumes with RFC-4 orientation written (16 valid + 2 invalid)
dicom/      4  synthetic HFDR/HFDL pair · axial CT · oblique CT
nifti/      5  avg152T1 LR/RL · Canon DTI oblique/axial · qform≠sform
nrrd/       1  MRHead.nrrd
minc/       3  ICBM152 T1 full · z-flip · xy-flip
analyze/    1  avg152T1.hdr/.img
bruker/     3  PV6.0 FLASH · rat PV5.1 · human PV5.1
fdf/        2  Varian test.fdf · synthetic HFS supine
wsi/        1  Aperio CMU-1-Small-Region.svs
screenshots/
  derived/  3-panel L/R/A/P/S/I orientation overlays (nibabel/ITK) — 33
  slicer/   3D Slicer captures — 13
  itksnap/  ITK-SNAP captures — 8
  niivue/   NiiVue captures — 14
  napari/   napari captures — 16

Test datasets

Orientation is listed per axis in lowest→highest coordinate order; — marks an axis left unannotated (no applicable RFC-4 term).

OME-Zarr — orientation written in the metadata

Invalid (must be rejected):

Source formats — orientation derived from the native header

Screenshots

Derived orientation overlays

Three-panel axial/coronal/sagittal views with L/R/A/P/S/I markers, rendered from the file's own header via nibabel/ITK. One per case, 35 total in screenshots/derived/.

A flip pair renders as mirrored markers — TC-49 above, and its exact axis-flip:

Viewers

The same files opened in four viewers.

3D Slicer — screenshots/slicer/, 13 captures (DICOM, NIfTI, NRRD, MINC, Analyze)

ITK-SNAP — screenshots/itksnap/, 8 captures

NiiVue — screenshots/niivue/, 14 captures

napari — screenshots/napari/, 16 captures (OME-Zarr, NRRD, WSI)

napari reads the OME-Zarr but does not apply the RFC-4 orientation field; its axis labels are the axis names, not anatomical directions.

Usage

git clone https://huggingface.co/fideus-labs/ome-zarr-rfc4-data
git clone https://github.com/fideus-labs/ome-zarr-rfc4-validation
cd ome-zarr-rfc4-validation
uv sync
uv run python validate_rfc4.py --data-dir ../ome-zarr-rfc4-data

validate_rfc4.py exits 0 when every case meets the expectation recorded in manifest.csv.

Conformance testing

conformance/run_conformance.py drives any tool's CLI against conformance/manifest.yaml and diffs its output. The tool must read one dataset and print this JSON to stdout:

{
  "input": "<path>",
  "format": "ome-zarr",
  "rfc4_valid": true,
  "axes": { "z": "inferior-to-superior", "y": "posterior-to-anterior", "x": "left-to-right" },
  "violations": [],
  "warnings": []
}

rfc4_valid is true/false for OME-Zarr, null for derived formats that carry no OME-Zarr schema. axes maps axis name → RFC-4 value, omitting unannotated axes. violations/warnings are code lists.

With ngff-zarr

ngff-zarr exposes this contract through a conformance subcommand (PR #605):

ngff-zarr conformance ome-zarr/brain_icbm_ras.ome.zarr

Drive the whole suite through it:

uv run python conformance/run_conformance.py \
    --data-dir ../ome-zarr-rfc4-data \
    --tool "ngff-zarr conformance {input}"

Exit code 0 means the tool matched the expected verdict on every case. The same driver runs the reference validator:

uv run python conformance/run_conformance.py \
    --data-dir ../ome-zarr-rfc4-data \
    --tool "python validate_rfc4.py --emit-canonical {input}"

Restrict to one format with --format ome-zarr; write a machine-readable report with --json report.json.

Violation and warning codes

Licensing & attribution

Redistributed here under CC BY 4.0 (umbrella). Per component: