David Brochart

Or maybe this could be handled by a special compressor, provided that we can request a given resolution from the Zarr store. Each chunk would then have all the resolutions...

Might be a duplicate of https://github.com/zarr-developers/zarr-specs/issues/23.

Yes the point is not to duplicate data, even a shrunk version of it, but to decompose the data into progressive layers of details, a kind of Fourier transform to...

Thinking about it, it might be possible to implement progressive encoding already, by adding a new dimension representing the resolution. When reading a zarr array, the decoding would be done...

> Perhaps @davidbrochart would be up for adding it to v2 as well based on [zarr-developers/zarr-python#715](https://github.com/zarr-developers/zarr-python/pull/715)? Sure, that should be easy.

Pyodide supports async, but not threads. I'm wondering how far we are from having Xarray and Dask to work in [JupyterLite](https://jupyterlite.rtfd.io). It would be nice for cloud-based data/processing, since the...

I'm very interested in zarr supporting tiles, but I'd also like not to duplicate data. In https://github.com/zarr-developers/zarr-specs/issues/80 I'm imagining an API where: ```python arr[z, y, x] # for a 2D...

Sure, sorry for the noise :smile:

So I guess zarr-lite implements what we call the [store API](https://github.com/zarr-developers/zarr-specs/blob/core-protocol-v3.0-dev/docs/protocol/core/v3.0.rst#abstract-store-interface) in Zarr v3, and especially the readable store API.

You're right, the store is not responsible for compression/decompression, it only deals with raw bytes. And no view either. So yes, zarr-lite is more than the store API.