No imagecodecs registered in zarr-python.

[sharkinsspatial]

With our conversion to using the ArrayV3Metadata for our internal ManifestArray representation we also needed to adopt Zarr v3 style codec pipelines rather than the pure numcodecs list we used previously.

IIUC Because the Zarr v3 spec only contains a small number of native codecs zarr-python uses an entrypoint system to register a suite of numcodecs so they can be discovered via the zarr-python registry and used as a Zarr v3 style codec (from this PR zarr-developers/numcodecs#524).

When we converted to ArrayV3Metadata we did not have any test coverage that was exercising the zarr-python codec registry lookup for an imagecodec. @maxrjones is working on the TiffVirtualBackend that requires the use of imagecodecs and was hitting a failure related to this. I've made a simplified reproduction of the issue with this test bb13a2c which fails when using the fixture parameterized with compressor that needs to be represented by an imagecodec like imagecodecs_lz4h5 rather than a numcodec.

I'm don't have a great grasp of how the entrypoint system works for zarr-python and what the next steps are. Are we able to perform entrypoint registration for codecs from within our own pyproject.toml or does this need to be done upstream in zarr-python? To complicate matters it appears that there are also some underlying compatibility issues with imagecodecs and Zarr v3 style codec conversion zarr-developers/zarr-python#2735

[TomNicholas]

I'm don't have a great grasp of how the entrypoint system works for zarr-python and what the next steps are. Are we able to perform entrypoint registration for codecs from within our own pyproject.toml or does this need to be done upstream in zarr-python?

Is the problem that there are codecs which have no way to be registered? Or that zarr-python doesn't register those codecs by default? I thought the whole point of the codec entrypoint system was that anyone could register any codecs they needed...

[maxrjones]

I'm don't have a great grasp of how the entrypoint system works for zarr-python and what the next steps are. Are we able to perform entrypoint registration for codecs from within our own pyproject.toml or does this need to be done upstream in zarr-python?

Is the problem that there are codecs which have no way to be registered? Or that zarr-python doesn't register those codecs by default? I thought the whole point of the codec entrypoint system was that anyone could register any codecs they needed...

From my perspective, the problem is that I don't know how to use imagecodecs with Zarr Python 3 + Zarr spec 3. I would need that understanding that in order to construct array metadata for virtual stores that use imagecodecs.

Based on zarr-developers/numcodecs#524, I think something like https://github.com/maxrjones/virtual-tiff/pull/4 might be necessary to use imagecodecs with Zarr Python 3 + Zarr format 3 but honestly I'm mostly guessing. Some guidance would be greatly appreciated.

[maxrjones]

I think I'm starting to understand the problems more, here is a summary of the issues:

1. No library registers imagecodecs via the Zarr Python entry point system (e.g., https://github.com/maxrjones/virtual-tiff/blob/82be31265089b81e027e6b788022296053b95a5d/pyproject.toml#L93-L95)
2. There are currently no imagecodecs wrappers that implement the additional methods required for adding codecs for Zarr Python 3 (e.g., compute_encoded_size is expected but not included in the numcodecs wrapper for imagecodecs)
3. The existing Zarr-Python 2 numcodec wrappers for imagecodecs subclass numcodecs.abc.Codec rather than zarr.abc.codec.ArrayArrayCodec, zarr.abc.codec.ArrayBytesCodec or zarr.abc.codec.BytesBytesCodec as expected for Zarr-Python 3
4. imagecodecs bytes to bytes codecs expect unsigned bytes so Use unsigned bytes to back Buffer zarr-python#2738 is required for most imagecodecs to work even after 1-3 are addressed

I also expect we'd discover more issues to be resolved after these.

All of these are problems for using imagecodecs with Zarr Python 3 + Zarr format 3 independent of VirtualiZarr. But they are a prerequisite for any broadly useful TIFF reader, and probably many other file formats.

[sharkinsspatial]

@TomNicholas @maxrjones and I discussed this in more detail yesterday (he is out for the rest of this week) and I think the next steps based on this are

1. @maxrjones has a solid foundation for Zarr v3 imagecodec wrappers in https://github.com/maxrjones/virtual-tiff/pull/4. We'll continue to prototype and expand the wrappers for all the supported imagecodecs in this repo.
2. Based on the work in https://github.com/maxrjones/virtual-tiff/pull/4 we'll make a PR to imagecodecs with these wrappers and see if Use unsigned bytes to back Buffer zarr-python#2738 can get merged.
3. Use entrypoint registration from within Virtualizarr to register the imagecodecs as @maxrjones has demonstrated in https://github.com/maxrjones/virtual-tiff/pull/4
4. Expand test coverage to include HDF fixtures with compression that requires an imagecodec to represent.