drop ome-zarr dependency

[will-moore]

Investigating a lighter-weight alternative to ome-zarr-py.
Uses zarrv3.

This includes the functionality from un-merged Plate Labels Fix (ome/ome-zarr-py#207 with #54).

Also includes the handling of bioformats2raw, similar to behaviour from un-merged ome/ome-zarr-py#174

Pros:

• Mapping from OME-Zarr metadata to napari data happens in one step, instead of being split between ome-zarr-py and napari-ome-zarr.
• This allows us to more easily support additional complexity as in the RFC-5 spec.

Cons:

• Some small duplication of logic between napari-ome-zarr and ome-zarr-py

The PR handles bioformats2raw, channels metadata, labels, plates and plates with labels. Testing with:

$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.5/idr0062A/6001240_labels.zarr

$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.5/idr0066/ExpD_chicken_embryo_MIP.ome.zarr

$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846152.zarr

# bioformats2raw.layout (single image)
$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846151.zarr

# bioformats2raw.layout (3 images in series)
$ napari --plugin napari-ome-zarr https://storage.googleapis.com/jax-public-ngff/public/397.zarr

# v0.5 plate (see screenshot)
$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.5/idr0090/190129.zarr

# Plate with labels (NB: need to scroll to first Z-plane to see labels) (screenshot below)
$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0001A/2551.zarr

# Nine images in bioformats2raw layout, translated into a 3 x 3 grid (screenshot below)
$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.5/idr0033A/BR00109990_C2.zarr

# labels colors, and properties (screenshot below, comparing with biongff-viewer) - mouseover labels to see properties
$ napari --plugin napari-ome-zarr https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0079A/idr0079_images.zarr/2

TODO:

• handle labels colors
• coordinateTransformations
• pre v0.4 (missing/minimal axes etc)

[will-moore]

As discussed with @joshmoore this morning, I looked into whether https://github.com/BioImageTools/ome-zarr-models-py could perform some of the graph traversal logic in this PR, e.g. multiscales -> labels or bioformats2raw -> multiscales (not yet done in this PR). But I don't see any of that functionality in ome-zarr-models.py?
cc @dstansby

[dstansby]

graph traversal logic in this PR

I had a quick look at the diff, but didn't quite understand what the required logic is. Could you explain a bit more? (or maybe add some short docstrings to the new classes/methods?)

We are generally 👍 on adding helpful functionality to ome-zarr-models-py, and I'm going to be sprinting to a first release tomorrow actually, so now is a good time to request stuff 😄

[will-moore]

@dstansby By "graph traversal" logic, I mean, if I start with multiscales group e.g. group = zarr.open("https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr") I then want to get the labels (if they exist). Here this is implemented in the children() method, where we know to look in a child "labels" group and check attrs for "labels": ["labels1.zarr", "labels2.zarr"] then return objects for those child labels so that the arrays (and metadata) can be added to the layers that are passed to napari.

I don't see that ome-zarr-models-py includes that kind of logic for traversing the graph between these objects?

[dstansby]

You can get the list of labels paths from Image.attributes.labels. But the labels part of the spec just says these point to "labels objects", which I don't think are more specifically defined anywhere else?

If the OME-Zarr spec was more prescriptive about what these "labels objects" were (are they meant to be groups with image-label metadata ??) then we could certainly do more, but I don't think the spec allows us to make those assumptions unfortunately.

[dstansby]

I am only now reading version 0.5 of OME-zarr, and see that the labels section is much improved over 0.4 😄 . It's definitely within scope of ome-zarr-models-py to provide logic for getting from an Image dataset to the labels dataset if it's in the metadata. Tracking issue at ome-zarr-models/ome-zarr-models-py#92

[will-moore]

Currently in the tutorial at https://github.com/BioImageTools/ome-zarr-models-py/blob/main/docs/tutorial.py
If I add:

print(ome_zarr_image.attributes.labels)

I get None (even though that image does have labels).
I don't see any population of the labels in https://github.com/BioImageTools/ome-zarr-models-py/blob/7659a114a2428fe9d8acbd06aa7bc1c9d32624bb/src/ome_zarr_models/v04/image.py#L85 ?

[dstansby]

even though that image does have labels

There's a labels group, but looking at that dataset in the validator the top level group is missing the labels metadata, which is why .labels is giving None.

[dstansby]

To be precise, if you look at the image group in the validator, it should have a "labels" key at the same level as the "multiscales" and "omero" keys. If that was there, the paths under the "labels" key would be in the .labels attribute in ome-zarr-models-py

[dstansby]

Oh hold on, am I just reading the spec wrong? Does:

The special group "labels" found under an image Zarr

Really mean:

The special Zarr group "labels" found inside an image Zarr group

?

If so then we should definitely implement that in ome-zarr-models-py!

[will-moore]

Yes, image.zarr/labels/ group.
This is shown a bit more clearly in the layout at https://ngff.openmicroscopy.org/0.4/index.html#image-layout

[dstansby]

Gotcha, I always thought the "labels" group was an arbitrary name and the example was just an example 🤦 - thanks for explaining, and I'll let you know once I've implemented this in ome-zarr-models-py 😄

[will-moore]

Thanks, ome-zarr-models/ome-zarr-models-py#96 looks good

[will-moore]

One issue I'm having with supporting bioformats2raw.layout here is how to load the /OME/METADATA.ome.xml (which could be local or remote etc).

E.g. https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846151.zarr/OME/METADATA.ome.xml

I'm trying something like:

from zarr.core.buffer import default_buffer_prototype
url = "https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846151.zarr"
group = zarr.open(url)
xml_data = await group.store.get("OME/METADATA.ome.xml", prototype=default_buffer_prototype())

but I want to avoid using async await if I can.

In https://github.com/ome/ome-zarr-py/pull/174/files it looks like this only handles local OME.xml files with root = ET.parse(filename)

[joshmoore]

In ome/ome-zarr-py#174 (files) it looks like this only handles local OME.xml files with root = ET.parse(filename)

Then that would have been a bug. I assume a method like get_json() (get_text or get_contents) would have been needed to slurp the XML.

[will-moore]

Seems this works for getting XML, but need to check if there's a better way that doesn't use testing classes...

import zarr
from zarr.core.buffer import default_buffer_prototype
from zarr.testing.stateful import SyncStoreWrapper
url = "https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846151.zarr"
group = zarr.open(url)
store = group.store
wrapper = SyncStoreWrapper(store)
xml_data = wrapper.get("OME/METADATA.ome.xml", prototype=default_buffer_prototype())
print("xml_data", xml_data.to_bytes())

[joshmoore]

Better to just use the SyncMixing for now: https://github.com/zarr-developers/zarr-python/blob/4455726a0dbdeebb00d146b3b7a4bfa4e63374b5/src/zarr/core/sync.py#L181

[will-moore]

Thanks, this is working...

from zarr.core.sync import SyncMixin
from zarr.core.buffer import default_buffer_prototype   
url = "https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0048A/9846151.zarr"
group = zarr.open(url)
store = group.store
mx = SyncMixin()
xml_data = mx._sync(store.get("OME/METADATA.ome.xml", prototype=default_buffer_prototype()))
print("xml_data", xml_data.to_bytes())

[will-moore]

If we wanted to use ome-zarr-models-py to handle some of the graph traversal (e.g. labels), this would now look like this:

import zarr

from ome_zarr_models.v04.image import Image
from ome_zarr_models.v04.labels import Labels, LabelsAttrs



group = zarr.open_group(
    "https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr", mode="r"
)
image = Image.from_zarr(group)
print("image.labels", image.labels)
assert image.labels == Labels(
    zarr_version=2, attributes=LabelsAttrs(labels=["0"]), members={}
)

for label in image.labels.attributes.labels:
    print("label", label)
    label_group = group[f"labels/{label}"]
    print("label_group", label_group)
    label_image = Image.from_zarr(label_group)
    print("label_image", label_image)

    first_dataset_path = label_image.attributes.multiscales[0].datasets[0].path
    zarr_arr = label_group[first_dataset_path]
    print("zarr_arr", zarr_arr)

See ome-zarr-models/ome-zarr-models-py#96

[will-moore]

@joshmoore I'll stop working on this for now, as I think there's enough here to evaluate this approach.
I think this is a viable option to provide OME-Zarr support to napari without using ome-zarr-py, but would appreciate feedback & discussion

[dstansby]

To chip in from ome-zarr-models-py, this is exactly the use case we'd love to support, so if there's anything else we can add to make this easier please let us know!

[will-moore]

@jluethi - This PR fixes the Plate Labels support for napari if you'd like to give it a try (as an alternative approach to #54)?

[will-moore]

@jluethi - Apologies: just tested the Plate with Labels above and some minor bug since the previous screenshot - looking to fix now...

[will-moore]

OK @jluethi - PlateLabels fixed now, at least for the test data I have.

[jluethi]

Oh, that's exciting! Thanks for the tag Will, will try to test this next week!

[jburel]

No header?

[will-moore]

No, I don't see any other files in this repo having a header, same for ome-zarr-py.

[jo-mueller]

Hi @will-moore , just went through this in a superficial manner. What's implemented here is exactly the kind of API that I (personally) think is missing over at ome-zarr-py, i.e. exposing the data from ome.zarr files through some sort of object-oriented logic. In this case it makes it easy for napari to grab the data to be viewed from Multiscales.data, but I would really love to be able to do the same from code, too!

Do you think it would be possible to move this upstream into ome-zarr-py? This would also allow ome-zarr-py to expose some of the cool tools of ome-zarr-models-py through its own API and keep naparei-ome-zarr really lightweight.

Edit: typo

[will-moore]

@jo-mueller Those Spec classes already exist in ome-zarr-py - see https://github.com/ome/ome-zarr-py/blob/7627a54b624247ec45415bc34457ae6d8ef5990c/ome_zarr/reader.py#L158 but we haven't documented their use as part of the API. They are a fair bit more complex at ome-zarr-py (e.g. use a ZarrLocation class to do the zarr access) and I struggle to understand them each time I need to work on them, fix bugs etc. So part of my motivation for implementing a simpler version of them here was to understand them better.

What we do with them at ome-zarr-py can be discussed next week

[jo-mueller]

@will-moore thanks for the pointer, definitely helpful to get on the same page until then.

I think what's confusing (at least to me) about the Spec and Node instances, is that they are object-oriented classes for metadata that are also owning an attribute that allows to access the data. I.e., Multiscales(Spec) allows to give you access to multiscale_object.node.zarr, if I see it correctly.

I guess my idea (for ome-zarr-py) but also for the changes here would be:

• Introduce the Spec and derived classes from this PR in ome-zarr-py and replace the implementations there. Especially the data, children and metadata attributes are useful.
• Replace the functionality inside def metadata -> Dict with ome-zarr-models-py. I figure the latter (correct me if I'm wrong @dstansby) allows to simply ingest a nested directory of ome-zarr metadata into corresponding metadata objects and spit out a dict object via metadata.model_dump() if required.
  This will save a lot of type checking, validation, etc. The only things you'd really have to check here would be the version field to invoke the correct metadata model from ome-zarr-models-py.

I'd have some other ideas particularly for the Plate structure (maybe a getter à la __get__(self, row, col) would be cool?) but the bigger decision to make here is probably the relationship between ome-zarr-py and napari-ome-zarr.

[will-moore]

Thanks @jo-mueller - All good points to discuss next week...

[will-moore]

@jo-mueller I guess we need to revive this discussion...

This PR fixes a bunch of issues and I'm adding all the RFC5 / v0.6 stuff on top of it, so it would be nice to get merged.
I don't know if it's worth holding off until ome-zarr-py is in a state where it can support everything we need here.

Maybe discuss at next week's Tuesday call?

[jo-mueller]

Hey @will-moore thanks for the ping. Totally agree! Personally I was hoping to

• use the Image class I was developing over at ome-zarr-py
• make stronger use of either yaozarrs or ome-zarr-models-py to outsource the model handling (if we find ourselves in conflict with development decisions there I guess we can always overload 🙊)

I'm relatively confident that I can get the development at ome/ome-zarr-py#515 into a presentable state by then 🤞

[joshmoore]

(I assume the title of this PR can be updated now? 😄 )