Zarr Visualization Roadmap (+ BOF CNG 2025)

[abarciauskas-bgse]

On May 2, 2025, at the CNG 2025, we held a birds of a feather session on Zarr Visualization approaches.

As an opening prompt, attendees were asked to share what their interests and experience is with Zarr visualization approaches. Attendees were familiar with or using @carbonplan/maps, have built in-house Zarr visualization platforms with pyramiding and caching, and were interested in using the GPU for visualization and 3 and 4-D mapping. In general, attendees agreed that visualizing Zarr should be "as-easy" as visualizing COGs, with interoperability for platforms such as QGIS, so Zarr datasets can be accessible to all levels of user.

Summary of discussion

• Adopting COG-Style Overviews for Zarr: Broad agreement that Zarr should support overview levels (like COGs) to enhance visualization; ideally, chunks should align with CRS-based resolutions.
• Zarr and Visualization Tools: A GDAL Zarr driver could improve integration with tools like QGIS, but virtualization systems like Icechunk may not be supported even if GDAL reads Zarr.
• 3D Visualization: Tools like Neuroglancer and Nepari demonstrate potential for 3D visualization using Zarr, suggesting broader use cases beyond 2D rasters.
• Standards Evolution: Need to define a Web-Optimized Zarr (WOZ) spec, potentially building on ndpyramid and GeoZarr. Discussion centers on CRS encoding approaches (CF vs COG-like) and multi-dimensional aggregation.
• Client-Side Rendering Benefits: Rendering directly in-browser (e.g., via GPU) allows flexible, fast interaction without server overhead—highlighted by Kyle’s GPU-based demo using deck.gl raster layers.

Roadmap for Zarr Visualization

I wrote up a roadmap that I felt represented the discussion about order of operations. I am open to feedback or modifications!

1. Web-Optimized Zarr Spec drafted, tested and accepted by community

• Revisit ndpyramid, reconcile ndpyramid and WOZ and CRS with GeoZarr.

The spec should include:

• How CRS should be specified
• How TMS multiscales will be stored and the associated metadata specification
• Definition of support for varied tile matrix sets

2. Build server-side tools on top of that spec

There is no need for a server vs client-side debate as both are necessary for different use cases: Server-side can plug-in to existing tools via WMS and WMTS. Client-side enables power, serverless direct data interactions.

• Build a purpose built Zarr IO library for reading chunks and generating tiles. We don't need to overhead of xarray.
• Improve server-side APIs using the purpose-built Zarr IO library

3. Build client-side tools on top of that spec

4. Zarr in-browser readers

   1. Do we need to pick one, zarrita.js or zarr-js? See open questions.

5. Icechunk in-browser readers

   • Develop a typescript reader for icechunk, which could be extracted from neuroclancer
   • build WASM binding for Icechunk. It will take a lot of work (well some say a week, some say a year) but is possible. Will require re-writing some of Icechunk.

• GL layers for Zarr (can be more than one)
  1. numeric-data-layer is in progress at Development Seed (Hanbyul, Kyle). Currently using deck.gl but may use zarr-gl (Mapbox GL and Maplibre).

Open questions

• Do we need more than one gl implementation?
• What is the strategy for addressing transforms? Are they supported or only Zarr that follows the WOZ spec?
• zarr-gl uses zarr.js, whereas preference for zarrita was expressed, which should be adopted by the community?

[TomAugspurger]

Thanks for sharing this writeup Aimee!

Build a purpose built Zarr IO library for reading chunks and generating tiles. We don't need to overhead of xarray.

Just to confirm, is the idea for this library to translate something like morecantile Tiles or lat / lon coordinates to the appropriate chunks to index into a Zarr array? We'd still use zarr-python for the actual data reading?

[d-v-b]

Build a purpose built Zarr IO library for reading chunks and generating tiles. We don't need to overhead of xarray.

I suspect the IO layer of neuroglancer is the most performant web-based zarr IO implementation available. @jbms, do you have any estimate for how complex it would be to factor neuroglancers chunked IO into a separate package?

[jbms]

I think this was a question about server-side --- for which there are already many implementations --- e.g. zarr-python, tensorstore, zarrs.

Regarding multi-resolution --- that is certainly pretty critical. Even though it is oriented around microscopy data, you could use OME-zarr already to represent the multi-resolution levels, and perhaps just substitute suitable geo units in place of the ones currently supported by OME-zarr.

For web client side application usage, Neuroglancer's I/O layer is not easily used separately. But also there is only a very small amount of code specific to zarr --- mostly it is just a matter of integrating zarr as a format into neuroglancer's I/O, caching, and multi-resolution volume interfaces. Adding support for geo transforms and other geo data types to Neuroglancer is something that I considered --- that would be an alternative approach to building a new viewer or adapting existing viewers to support 3-d or n-d data.

Re icechunk: Currently neuroglancer supports the old msgpack-based icechunk format. I haven't yet updated it to support the new flatbuffers format and I imagine it may change significantly at least one more time in the near future, and once support for this or a later version is added I probably won't bother to keep supporting the old versions until it becomes stable. Depending on how urgently you want to actually use it, you might instead just wait to support it until it becomes more stable.

[TomAugspurger]

I think this was a question about server-side --- for which there are already many implementations --- e.g. zarr-python, tensorstore, zarrs.

That was my understanding too. My hope is that any of those can achieve about equivalent performance for reading chunks.

[jbms]

One thing that existing implementations don't support is efficiently transcoding between different encodings of chunks, where there may be a more optimized path than fully decoding to raw uncompressed format and then re-encoding to the target format.

For example, you might have a zarr array using some to-be-implemented jpeg codec for chunks, and want to transcode to some geo-oriented tile format that also supports jpeg encoding. With the existing libraries I'm aware of, you would have to fully decode the original jpeg chunks and then re-encode into the new jpeg tiles, which is both inefficient and lossy compared to just not decoding the jpeg at all, and merely copying the jpeg data into a new container format.