-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consolidate Plate to preview image #141
Comments
I think it's awesome that the ome-zarr-py library and its napari plugin gives access to the whole pyramid. While it takes a bit to initially load a plate, the browsing of a plate afterwards is super cool, getting relevant resolutions loaded whenever I zoom in. It takes 45s for initial loading to finish (though that varies a lot with connection speed), but then it's a super-interactive plate to browse afterwards! Now, if we can use something like a "preview" image for a plate that makes the initial loading a few seconds instead of 45s in my example (or longer in examples with e.g. 384 wells), that's a super interesting thought! But I wouldn't want to give up the pyramidal loading for it. My 2 main concerns would be:
=> is your proposal that we only load preview & full-res, or could we still dynamically load the pyramid levels?
PS: sorry for the long delay in response time. Conference & covid interfered with my usual rhythm. |
One additional thought that just came up: If a lot of time is spent on the In that way, only a single (larger) |
Currently, when viewing an NGFF Plate in vizarr or napari, the pyramid is created by using 1 down-sampled tile from the first Image of every Well.
In vizarr (hms-dbmi/vizarr#119) we check the
.zattrs
for every Well to find the path/to/first/Image for each.The
multiscales
of the first Image in the plate is used to find what the lowest resolution is, then we load that same resolution for all Wells.This makes it quite slow to load a Plate, since we have to load for each Well:
.zattrs
,.zarray
& chunks (1 per channel).E.g. for a 384-Well plate, this is at least 1920 requests for the lowest resolution.
https://hms-dbmi.github.io/vizarr/?source=https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.1/plates/5966.zarr
A similar strategy of checking the
path/to/first/Image
for every Well is also in an open PR for ome-zarr-py (for viewing in napari): ome/ome-zarr-py#207In the case of vizarr, we only load the smallest (lowest resolution) level of the pyramid, and don't load higher resolutions when we zoom in.
I wonder whether we could specify a "preview" image of a Plate that clients could use to view a Plate as a NGFF Image. This would enable the viewing of the down-sampled Plate as simply as we currently view a single Image: load only the
.zarray
and the chunks of optimum size. Instead of 1 chunk per Well, we would stitch Wells together.The lowest resolution of the Plate could be loaded from the full resolution Images as it is now.
This plate "preview" would also allow vizarr to view multi-resolution levels of the plate (but not the full resolution).
I could imagine an
ome_zarr
command like$ ome_zarr consolidate_plate path/to/plate.zarr
to generate a plate preview Image from an existing NGFF plate. This could take into account a differentpath/to/first/Image
for each Well.The top-level
.zattrs
"plate":{}
object could specify the existence of a `"plate_preview": "path/to/multiscales_image.zarr".cc @jluethi @sbesson
The text was updated successfully, but these errors were encountered: