open ngff file with lower resolution pyramid
satra opened this issue · 4 comments
i'm trying the viewer on this file to see if it will do zoom based resolution fetch, but it opens at the highest resolution.
napari --plugin napari-ome-zarr 'https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/'
i'm on a 16" macbook pro. wondering if it's because of the resolution of display, and if there is a way to force it to a different pyramid level by default.
Hey @satra. Good question! Unless something has changed (and that's certainly possible; napari goes fast) the plugin interface implemented here doesn't allow us to specify.
@jni, @sofroniewn, @tlambert03, @DragaDoncila, etc. might be able to tell us more.
Since I have napari-ome-zarr installed from the code (pip install -e .) I just tried returning a pyramid without the first 2 resolutions:
$ git diff
diff --git a/napari_ome_zarr/_reader.py b/napari_ome_zarr/_reader.py
index 1107f2b..f785f23 100644
--- a/napari_ome_zarr/_reader.py
+++ b/napari_ome_zarr/_reader.py
@@ -170,7 +170,7 @@ def transform(nodes: Iterator[Node]) -> Optional[ReaderFunction]:
if properties is not None:
metadata["properties"] = properties
- rv: LayerData = (data, metadata, layer_type)
+ rv: LayerData = (data[2:], metadata, layer_type)
LOGGER.debug(f"Transformed: {rv}")
results.append(rv)
And that allowed me to at-least view that image on low bandwidth (whereas trying without that hack failed).
I guess part of the issue was that the highest resolution has 3D chunks of 128 x 128 x 128 so that it's loading a lot more data than you'd otherwise need for a 2D slice.
$ napari --plugin napari-ome-zarr -vvv 'https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/'
...
10:01:27 INFO - shape ('t', 'c', 'z', 'y', 'x') = (1, 1, 900, 1100, 1800)
10:01:27 INFO - chunks = ['1', '1', '128 (+ 4)', '128 (+ 76)', '128 (+ 8)']
10:01:27 INFO - dtype = uint16
10:01:27 DEBUG https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/1/.zarray
10:01:28 INFO resolution: 1
10:01:28 INFO - shape ('t', 'c', 'z', 'y', 'x') = (1, 1, 450, 550, 900)
10:01:28 INFO - chunks = ['1', '1', '128 (+ 66)', '128 (+ 38)', '128 (+ 4)']
10:01:28 INFO - dtype = uint16
10:01:28 DEBUG https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/2/.zarray
10:01:28 INFO resolution: 2
10:01:28 INFO - shape ('t', 'c', 'z', 'y', 'x') = (1, 1, 225, 275, 450)
10:01:28 INFO - chunks = ['1', '1', '128 (+ 97)', '128 (+ 19)', '128 (+ 66)']
10:01:28 INFO - dtype = uint16
10:01:28 DEBUG https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/3/.zarray
10:01:28 INFO resolution: 3
10:01:28 INFO - shape ('t', 'c', 'z', 'y', 'x') = (1, 1, 113, 138, 225)
10:01:28 INFO - chunks = ['1', '1', '64 (+ 49)', '64 (+ 10)', '64 (+ 33)']
10:01:28 INFO - dtype = uint16
10:01:28 DEBUG https://dandiarchive.s3.amazonaws.com/zarr/7723d02f-1f71-4553-a7b0-47bda1ae8b42/4/.zarray
10:01:28 INFO resolution: 4
10:01:28 INFO - shape ('t', 'c', 'z', 'y', 'x') = (1, 1, 57, 69, 113)
10:01:28 INFO - chunks = ['1', '1', '32 (+ 25)', '32 (+ 5)', '32 (+ 17)']
10:01:28 INFO - dtype = uint16
But I guess that also meant that once I'd loaded the lower resolutions, I got nice smooth Z-sliding without having to load more chunks:
thanks @joshmoore and @will-moore - indeed these are at 128^3, which has it's challenges. i was simply testing how much view-based rendering napari provides, and after it loaded i was able to squeeze the viewport to have it access a lower resolution pyramid. so indeed it is tied to rich pixel density of my display. perhaps that can be parameterized in a way to balance pyramid resolution and FOV.
i'll close this for now. feel free to re-open if it's useful for tracking a pending feature.