Skip to content

Support ngio>0.2.2 #31

@jluethi

Description

@jluethi

The rechunk_zarr task has an issue with ngio > 0.2.2. We optionally derive labels and formerly used the old _derive_label function. It became public in ngio 0.2.3.

But the issue now is that while the label is derived, no metadata about it is added to the image, thus it can't be found there later (e.g. a .zattrs is missing). Not sure whether this is due to the change in derive_label or some other fixes in ngio.

The goal: Improve the part where we derive the label to also handle updating the .zattrs correctly.

Specifically, we did this so far:

ngio.images.label.derive_label(
                name=label,
                store=f"{rechunked_zarr_url}/labels/{label}",
                ref_image=old_label,
                chunks=new_chunksize,
                overwrite=overwrite,
            )

            if rebuild_pyramids:
                new_label = new_ome_zarr_container.get_label(name=label)

@lorenzocerrone How do I add the derived label correctly to my new image at rechunked_zarr_url?

Testing things with:

            new_ome_zarr_container = ngio.open_ome_zarr_container(
                rechunked_zarr_url
            )
            print(new_ome_zarr_container.list_labels())
            print(rechunked_zarr_url)

We can see that new_ome_zarr_container does not list any labels, while on disk it does have the label folder. Running the same test with ngio 0.2.2, the list of labels was also empty, but the get_label was robust to that. I'd say it's fine to require this metadata to be correct in the labels group, let's just find a good way we also populate it correctly in the derive_label flow of rechunk_zarr

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions