resolution levels not a factor of 2

[will-moore]

When using OMERO to provide a OME-Zarr interface via https://github.com/will-moore/omero-web-zarr
the size of each pyramid resolution is determined by the pyramid in the original file.

For svs images, the resolution levels are often not a factor of 2. e.g. sample image
https://downloads.openmicroscopy.org/images/SVS/77917.svs

Sizes of resolutions (X, Y) are:

96999, 45667
24249, 11416
6062, 2854
3031, 1427
1024, 482

The OME-Zarr spec doesn't specify any down-sampling info, so this should be valid, and I believe this is handled correctly in napari, although there are other async issues and tiles being re-loaded on every zoom that prevent me from testing this properly.

It seems that vizarr assumes that each resolution is a factor of 2 smaller than the previous, so that in the image above, we get tiles incorrectly overlaid when moving from one resolution to the next:

Initial view is very-much smaller than expected (appears in the top-left of the screen):

I don't know if this can be handled in Vizarr, or if it needs to be handled at a lower level in deck.gl etc?

[manzt]

Thanks for opening the issue. This is something I've also run into using vizarr with napari-lazy-openslide.

To my knowledge, this is an assumption that deck.gl makes about image pyramids, so I'm not sure what it would take to support. In napari, each resolution is represented as a separate ndarray with it's own shape. To this end, napari can inspect the available resolutions and determine how to fetch slices of data.

Viv extends deck.gl's TileLayer, which fetches tiles based on tileSize and maxZoom alone. It has no knowledge of what resolutions are available, and implicitly also makes the assumption that tileSize is consistent across resolutions (which is not necessarily true for OME-Zarr either).

It is my impression that to add this support, we'd either need to implement our own TileLayer or (preferably) improve the existing deck.gl TileLayer. Fundamentally, the challenge I see is that there is no standard in-memory representation for ndarrays in JavaScript (akin to the numpy-like interface). This means that deck.gl's TileLayer is designed around tile source formats, making requests directly for individual tiles, rather than interfaces that represent multi{scale,dimensional} data.

A primary motivation in moving our loaders to loaders.gl is the hope that we can work with the deck.gl community to unify these interfaces (e.g. PixelSource). cc: @kylebarron

visgl/loaders.gl#1469

visgl/loaders.gl#1462

[will-moore]

I just tried another example where the factor between resolutions wasn't 2:
Take an image with a single high-resolution dataset, and generate a "thumbnail" sized resolution, e.g. a factor of 16 smaller.
These images behave just fine in vizarr.

The previously created example is still behaving strangely, https://hms-dbmi.github.io/vizarr/?source=https://minio-dev.openmicroscopy.org/idr/v0.4/idr0082/9846318.zarr/ so I'm not sure what the issue is with that sample...