Attending: Sanket Verma (SV), Davis Bennett (DB), Ward Fisher (WF), Eric Perlman (EP), Norman Rzepka (NR), Josh Moore (JM), John Kirkham (JK), Dennis Heimbigner (DH), Jeremy Maitin-Shepard (JMS)


SV initiated the meeting by sharing important updates and discussing the best way to take and keep notes for the community meetings. After this, NR had some questions on ZEP0001 implementation. The meeting ended with the SV discussing various voting tools and DB on storing the sampling grid in the bio-imaging domain.


  • ZEP0001 is finally accepted! 🎉
    • Implementors can start working on their implementations
    • Will be moving the ZEP0001 under the new Accepted section
    • Will move it under Final section once we have atleast one complete reference implementation
  • Ongoing updates to https://zarr.dev/ – opinions & PRs welcome.

Meeting Minutes:

  • Community meeting notes
  • NR: Quetions for ZEP0001
    • Q1. What constitutes a reference implementation?
      • SV: Does zarrita have all the sections? Believe so.
      • SV: Documentation or something to share with the community? Needs work.
        • More a technical proof-of-concept (and generate reference data)
        • Tests can be read by other implementors
        • Didn’t add optimizations.
    • Q2. How do we get implementations to implement? (esp. zarr-python)
      • SV: deciding on physical vs. in-person. (and/or ZarrCon?) Suggestions?
      • NR: any necessary prework? (also: remote is fine)
    • DB: backwards compatibility?
      • JM: personally would opt for trying to not impact end users, but if a new API emerges, that could be used directly.
      • …performance…
      • JK: not absolute performance, but targeted things that could be fixed
  • SV: Voting for ZEP1
  • Meetings
  • DB: Where does your samples come from e.g. in bio-imaging?
    • In bio-imaging the specification of sampling grid is stored as a transformation - essentially matrix
    • What if we normalise the storing of grid as array of data? (which is NetCDF way)
    • From Zarr side - would need a codec that supports partial read and have metadata as a matrix
    • Because specification of the matrix gets awful and you get metadata describing spatial transformations - whether it could really be data
    • JMS: You can store the array but your software also need to know how to work with that newly stored array data