-
Notifications
You must be signed in to change notification settings - Fork 1
Description
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