resolution levels not a factor of 2 about vizarr HOT 1 OPEN

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

from vizarr.