---
tags: NGFF, community-call
---
# OME-NGFF community call: 2024-04-03
Please paste this into the Zoom chat as new people join:
:::warning
Welcome to the community call. Live notes for the session are available in https://hackmd.io/So61knrQR0iLftd2LGAVjA Where possible, help to structure the notes for later publication rather than commenting in Zoom's chat. Thanks!
:::

## Code of conduct
The OME community is open to everybody and built upon mutual respect. Please take the time to review the code of conduct below.

https://github.com/ome/.github/blob/master/CODE_OF_CONDUCT.md

## Preliminary agenda (not for notes)

- Quick round table `<5m` (Josh)
- `min(30s, 300s/attendees)` per person
- State of NGFF `5m` (Josh)
- Zarr v3
- RFC
- Transforms (additional `5m` in session 2)
- Prepared toughts on labels & collections `15m` (Norman)
- [Slides](https://docs.google.com/presentation/d/1ANsNdCchmwWR1grhg5-hSrWH5nyPz2QSFYToF56PVc4/edit?usp=sharing)
- Open discussion on labels & collections `20m`
- Wrapping up `10m`
- Take homes, Todos, and Task Forces
- Next meeting
- Any other business

----

<details><summary>Earlier session</summary>

## OME-NGFF community call (09:00 CET; 03 Apr 2024)

### "User registration" Session 1

| Name | Institute | Twitter Handle | Mastodon Handle | GitHub Handle |
|------------ |--- |---------------------- |---------------- |--------------- |
| Bugra Özdemir | Euro-BioImaging Bio-Hub | | | bugraoezdemir |
| Christian Tischer | EMBL |
| Davis Bennett | Independent software developer | | | d-v-b |
| Guillaume Gay | France BioImaging | _ | [[e-mail]](https://[e-mail]) | glyg
| Joel Lüthi | BioVisionCenter, Zurich | @[e-mail] | jluethi | jluethi|
| Josh Moore | German BioImaging, e.V. | notjustmoore | | joshmoore |
| Koji Kyoda | RIKEN BDR | kkyoda | | |
| Matthew Hartley | EMBL-EBI | BioImageA | | matthewh-ebi |
| Norman Rzepka | scalable minds | normanrz | [[e-mail]](https://mastodon.social/@normanrz) | normanrz |
| Sébastien Besson | Glencoe Software | | | sbesson |
| Tim-Oliver Buchholz | FMI | tibuch | | tibuch |
| Duncan Davidson | | | | |
| Jean-Marie Burel | | | | |

**Registration now closed; please see below**

### Session 1 Notes

* Introduction (Josh) 09:01 CEST
- shorter preparation time for the meeting so (a) keeping it shorter and (b) keeping the intro shorter. We can discuss a longer meeting in the future.
- **Process:** reviews are now in for RFC-1. Josh's focus will be on getting these processed.
- **Spec versions:** transforms are slotted for the next version but there is current an issue with F- vs. C-ordering. This is a sufficiently hard problem that it will likely get its own RFC so we can approach a consensus.
- **Zarr updates**: there are now several v3 implementations that can read and write the spec, including sharding. The reference implementation is still zarr-python which is being actively developed on the "v3" branch. There will be presentations at SciPy in July so the summer is the current initial release target.

* Presentation (Norman) 09:11 CEST
- See slides
- JMB: e.g., annotation on which channel will go in the attributes section? Good question. Haven't thought about it.
- JMB: part of "attributes"? NR: debatable. Not defined by the spec. It's free-form. To standardize across viewers, then would want a spec.
- CT: plate collection is in the same document? Yes. Hierarchical collection all in one file. CT: How do I see the hierarchy? Example just needs indentation.
- TOB: stuck on "collecting with compatible axes" does this allow projection images? DVB: there was some push back on having any restriction on the axes. e.g., not sure how to fit histogram in whatsoever
- SB: next step question, slide 11 has an overview. one proposal or multiple? NR: was thinking multiple RFCs. (Josh: smaller changes need not be RFCs)
- MH: ditto to the previous. additionally: slide 25 - nothing in the keys other than the name for detecting what's what. NR: the valueType on the collection should help, but that's still up for discussion. there's a split of responsibilities and therefore redundancy which might not be ideal.
- CT: comment/a similar idea would be that the pixels as actual measurements could have for example the number of photons, then that could even be the unit, and if not present just "intensity". DVB: not convinced that measurements of counts is continuous, but it's a discrete quantity that I've measured. NR: don't want it to be too convoluted. e.g., what happens to a viewer that knows nothing about nanoseconds or photon counts? CT: is that already a rendering concept then? NR: that is specified at the collection level.
- Josh: thoughts/questions
- multi-multiscales requirement likely boils down to re-using arrays
- discovery of collection JSONs
- group versus extra file ("inlining"?)
- performance of HCS metadata
- larger feedback: [RO-Crate](https://w3id.org/ro/crate/)
- NR: general feedback?
- :+1:: Tim-Oliver, Tischi, Joel, ...
- SB: Glencoe perspective - labels have worked in OMERO.plus but happy to relax restrictions. Don't own the data so can't add metadata. (Managing via third party system. Aggregating outside the Zarr hierarchy.) Josh: the thing you're managing outside the Zarr hierarchy could now be another Zarr hierarchy. DVB: opening a collection is actually better for users. Move away from opening a single image. Rather a scene. That defines how you look at your data. We choose contract settings, etc. based on multiple images.
- JL: fractal framework was starting to define a new way of collecting all images. so now zarr's can collect what has happened to them which can be very powerful.

</details>

## OME-NGFF community call (17:00 CET; 03 Apr 2024)

### "User registration" Session 2

| Name | Institute | Twitter Handle | GitHub Handle |
|------------ |---------------------- |---------------- |--------------- |
| Copy | and | paste | me |
| Josh Moore | German BioImaging, e.V. | notjustmoore | joshmoore |
| Kola Babalola | EMBL-EBI | | |
| Jason Swedlow | University of Dundee/OME| jrswedlow | jrswedlow |
| Erin Diel | Glencoe Software | dielwithit | erindiel | |
| Ken Ho | Francis Crick Institute | DrKenHo | DrKenHo-crick|
| Joel Lüthi | BioVisionCenter, Zurich | jluethi | jluethi|
| Damir Sudar |Quantitative Imaging Systems LLC | | dsudar |
| Davis Bennett | Independent software developer | | | d-v-b |
| Caterina Strambio-De-Castillia|UMass Chan Medical School|StrambioLab | |strambc|
| Eric Perlman | Yikes LLC | | perlman |
| Marc Bruce | Glencoe Software | | mabruce |
| Melissa Linkert | Glencoe Software | | | melissalinkert |
| Matt McCormick| Kitware | thewtex | thewtex | |
| Norman Rzepka | scalable minds | normanrz | normanrz |
| Sébastien Besson | Glencoe Software | | | sbesson |
| Dan Toloudis | Allen Institute for Cell Science | [e-mail] | toloudis | | toloudis |
| Wouter-Michiel Vierdag | EMBL | WVierdag | melonora |
| Fernando Cervantes | The Jackson Laboratory | | fercer |
| Anthony Asmar | National Institute of Standards and Technology | | | |

### Session 2 Notes

* Please see the introduction section above (Josh)
* Presentation (Norman)
- ... please feel free to add notes or questions here ...
- KB: how does one identify, e.g., a segmentation?
- ML: is this breaking with everything that exists? NR: goal would be to have a unified way of representing all the different collections. whether or not it's breaking is probably a question for the process. you won't need to move data around, just add/rewrite JSON files. (i.e. fairly cheap operation). ML: concern is that the users with 100s of TBs of data would have issues (tough sell). looking to shield end-users.
- NR: that's probably a even larger issue since it will touch any large RFC (Zarr V3, etc.)
- MM: generally like everything here. Does the Zarr v3 defined root cause any issues? NR: the defined root didn't make it into the final spec. there's practically a root (where the file ending is)
- WV: Regarding rendering metadata, would you also include multiple views as in multiple crops of the same image for example each one having their own metadata + optional description? (e.g. pathologist quickly flipping through view configurations)
- NR: haven't really thought about it yet. trying to define the base groupings first, but they should have metadata like you're suggesting.
- KH: Am I correct that these labels are mainly collections of processed images, like segmented images and prediction maps? Does it include ROIs and assuming that hand drawn annotations in this context are saved as masks, i.e. image array and not as polygons, and lines?
- JM: geometries aren't yet being proposed.
- DT: separate collection JSON (doesn't need to be a zarr) is a great way to bring things together.
- from chat: We are building into our viewer the ability to simply concatenate image channels with parameters like &url1=….&url2=…, and a standard collection spec is exactly how we’d prefer to do this. Allowing Independent absolute zarr urls, plus a top-level transform override, completely solves it for us. One note: our multiresolution levels are not a 1-1 match because we segment at an upsampled resolution.
- NR: excellent use-case. Frequent issue in webknossos. That brings us back to the transforms discussion.
- JL: Same here, we often have labels at different resolutions than images
- DB: we also segment at a different resolution
- CT: doesn't the scale solve this? DT: yes. The tool needs to be able to find that.
- last comments
- EP: addresses many of the issues that I've run into with OME-Zarr. wish we had it a year ago.
- DB: optimistic because it is a description of usage that people do. i.e., formalizing what people are doing.
- DB: biggish question: does this need to be part of NGFF? JM: agreed, probably not.

* Wrapping up
- Another, longer community meeting.
- Pro votes: CS, ...