zarr-vectors stores three-dimensional spatial geometry — point clouds, streamlines, graphs, skeletons, and meshes — in spatially indexed Zarr v3 stores. Spatial queries touch only the chunks they need, whether the store sits on a local filesystem or a cloud object store (S3, GCS). Resolution pyramids are encoded natively so viewers like Neuroglancer can stream data progressively at any scale.
The library implements Zarr Vectors, originally specified by Forest Collman at the Allen Institute for Brain Sciences, extended with separated chunk/bin sizes, per-level sparsity, and OME-Zarr-compatible multiscale metadata.
Two module surfaces carry a compatibility promise, split by what the caller is
doing. zarr_vectors.api is for using data — opening a store, selecting
a region or a set of objects, reading it back, editing it — and is re-exported
from the top-level package, so zarr_vectors.open(...) and
zarr_vectors.api.open(...) are the same function. zarr_vectors.building
is for making stores: ingest converters, pyramid builders, exporters,
repair tools. Everything else — core, encoding, spatial, lazy,
ops, sharding, multiresolution and rechunk — is internal and
changes without notice. zarr_vectors.stability() answers for any dotted
name at runtime, so nothing here has to be taken on trust.
Overview of Zarr Vectors. a — Complex and detailed derivative datasets now exceed GPU and system memory. b — Summary of the Zarr Vectors concept, showing input data types, construction, and uses.¶
Where to start¶
Write and query your first vector store in a few lines of Python. |
|
The mental model: chunks, supervoxel bins, fragments, the object model
and the resolution pyramid — and how |
|
The data surface: |
|
The builder surface, for code that writes stores rather than reads them: arrays, fragments, shards and manifests. |
|
Which modules are supported, which are internal, and how to ask at runtime. |
|
Full technical specification for Zarr Vectors. |