spatialdataR for Fractal (OME-Zarr) output

[csoneson]

Hello - as discussed at CSAMA this week, I'm exploring the possbility to use spatialdataR for microscopy OME-Zarr files processed (for example) by Fractal. My testing is based on the file here: https://zenodo.org/records/10519143 which we are also using in the ez-zarr vignette.

When attempting to read the file, I ran into two issues, related to:

• the location of the version information
• the fact that the image is 4D (czyx)

The first issue could be solved by checking for the version in different locations (specifically x$omero$version or x$multiscales[[1]]$version) in

spatialdataR/R/sdAttrs.R

Line 130 in 175f1d8

v <- x$spatialdata_attrs$version

The second issue I currently solved by removing the z-dimension in .readArray() if it's present and of length 1 (and failing otherwise), but here I think the solution will depend on whether you'd like to be able to also handle 3D images in a more sophisticated way.

With these fixes, I could read the file. Now trying to plot it with SpatialData.plot() fails because CTname(img) returns an empty vector.

Happy to discuss further.

[Artur-man]

SpatialData attributes are slightly different than OME-ZARR attributes. Can you also try using https://github.com/Huber-group-EMBL/rome and see if you get a similar error. We are working on establishing generic dependencies so OME-ZARR and spatialData objects can be used in multiple packages.

[csoneson]

This works:

library(rome)
x <- ome_read("20200812-CardiomyocyteDifferentiation14-Cycle1_mip.zarr/B/03/0/")
plot(x, 1)

[Artur-man]

Super, I think Fractal might have its own framework, so I am not sure if we can directly read as a SpatialData object.

CC @LucaMarconato

[HelenaLC]

I have seen omero version, spatialdata version, another I don't recall? – This has 0 impact on anything except accessing multiscales. @Artur-man do you know which one we should check? I believe Charlotte's issue we can fix; it is just checking the right place to distinguish Zarr v2 and v3; nothing spatialdata-related (I think).

[Artur-man]

omero fields, including version, are optional (so you go with the one under multiscales), but I do not think omero's across sd and ngff are the same at all: https://ngff.openmicroscopy.org/specifications/0.4/index.html#omero-metadata-transitional

[Artur-man]

I also do not see a version specification in the link referring to the omero:
https://docs.openmicroscopy.org/omero/5.6.1/developers/Web/WebGateway.html#imgdata

This is really confusing, omero version in the image might be identical to the NGFF version.

@csoneson also ... the spatialdata_attr version is the raster format version specific to SpatialData:
https://github.com/scverse/spatialdata/blob/cc87549c8cb95dfa083c78ddf1c5ab704b0703c6/src/spatialdata/_io/format.py#L309-L313

[LucaMarconato]

Fractal uses the standard OME-Zarr way of representing images and a custom way to store tables (since tables are not part of the specs), but which is similar to how spatialdata store tables.

For the tables we would need to implement a converter or a in-memory adapter; it should be easy.

For the image part, we are working towards aligning SpatialData with OME-Zarr 0.6 (the dev version has been released only recently, before it was still in "draft mode"). Until then we will have some discrepancies.