OME-NGFF 0.4 specification

--- tags: NGFF --- In a former [blog post](https://www.openmicroscopy.org/2021/12/16/ome-ngff.html), we reported several 2021 updates on OME-NGFF including an academic paper, new specifications and samples. # OME-NGFF 0.4 specification The latest release of the OME-NGFF specification included changes to the axes and high-content screening specifications. ## Axes Axes introduced in the 0.3 release allow to define the dimensionality of the imaging volume, currently between 2 and 5 dimensions. Following several discussions and the community call of 2021-??-??, a [draft proposal](https://github.com/ome/ngff/pull/57) led by EMBL is currently under review to: define format axe types (initially spatial, time, channel) and units remove all assumptions based on axe names (x,y,z,c,t) and use the axe types defined above add support for axe transformations, initially scale, translate This extension is important for extending the specification into a wide variety of imaging domains, e.g., tomography. Several implementations (MoBIe, ome-zarr-py) have been updated to read and write OME-NGFF with 0.4 axes and preliminary samples are currently available at … ## HCS A [specification proposal](https://github.com/ome/ngff/pull/24) by Glencoe Software is under review to amend the high-content screening specification. The proposed changes are critical for supporting sparse plates which are very frequent in the HCS domain. Python (ome-zarr-py) and Java (bioformats2raw) implementations have been updated to produce the new plate layout and OME-NGFF samples are also # OME-NGFF 0.4 implementations & samples - MoBIE - ome-zarr-py/napari-ome-zarr/ - ZarrReader? - bioformat2raw # Investigations Over the past few months, the OME team in Dundee has started exploring a number of new specifications and concepts. ## Collections Refer to [issue](https://github.com/ome/ngff/issues/31) Several members of the community have contributed to the discussion on this issue, started by Draga Doncila. Having reached a consensus on the key parts of a Collections specification, the discussion has moved on to more technical aspects such as validation and JSON-ld. A PR is to update the spec in in progress. ## Validation As the number of NGFF specifications grows, manually checking the validity of datasets can become cumbersome, especially doing so across multiple programming languages. In a first attempt at mitigating this complexity, the OME team in Dundee has evaluated providing a schema syntax for NGFF specifications. Such a declarative representation provides a simple way to validate at least the JSON metadata provided in NGFF datasets and more formally defines the expectations of datasets. For the current specifications (v0.1 through v0.3), [JSON Schema](https://json-schema.org/) files were added to the specification repository in [NGFF#69](https://github.com/ome/ngff/pull/69). These schema files can be used from most major programming languages for validation. For example, support has been added to ome-zarr-py in [ome-zarr-py#142](https://github.com/ome/ome-zarr-py/pull/142). Moving forward, however, we will likely move beyond JSON Schema in order to support extensible subclassing of core NGFF types. For the v0.3 specification, [SHACL](https://www.w3.org/TR/shacl/) shape expressions were also evaluated for validating [JSON-LD](https://json-ld.org/) metadata. These are available in the repository for review. As more advanced specifications (like [collections](https://github.com/ome/ngff/pull/67)) need JSON-LD support, we will evaluate adding or migrating to another validation framework. ## Rendering Initial rendering settings were introduced in version 0.1 under the ``omero`` specification - See https://ngff.openmicroscopy.org/0.1/#omero-md. The settings were only covering a subset of the rendering settings used by the OMERO viewers and we were not taking into account settings required by other viewers e.g. BDV, napari. Over the past few weeks, the OME team has looked at a rendering settings specification to cover the needs of several viewers. An internal consensus has been reached, and the first version of the proposal will be presented to the community