---
tags: NGFF,zarr,hackathon
---

# OME-Zarr Hackathon

## Participants
* John Bogovic
* Constantin Pape
* Josh Moore
* Vladimír Ulman
* Christian Tischer
* Sébastien Besson
* Matt McCormick
* Dženan Zukić
* Johannes Roos
* Ko Sugawara
* Tobias Pietzsch

## John's spec proposal (1700, Tuesday)

* https://github.com/bogovicj/ngff/wiki/Transforms-notes,-examples,-proposals
* https://github.com/saalfeldlab/n5-ij/wiki/OME-Zarr-hackathon-2022

Spaces will get names, e.g. "FAFB". A space just uses the "axes" already defined in the spec

Mapping from space to space using transformations

Example use-cases:
https://github.com/ome/ngff/issues/84

Q: Seb
Are "axes", "coordinateTransformations", "multiscales" separate because the idea is to have "axes" and transformations re-usable?

A: John, Constantin: Yes!
Example application: one image mapped to different spaces, e.g.
different registrations

Q: Seb

Are units MUST or SHOULD.

A: Constantin
Currently it is SHOULD, i.e. there should be some sort of warning if an unknown unit is encountered. Would rather not change it for 0.4, we could make this more restrictive later.

Q: Tobi

This raises a point about "How does software interpret the spec", would be good to include this in the examples

A: John

(Long answer), agrees that adding this to the use-cases is a good starting point

John: which transformations do we want to support
- affine and simpler (rigid, euler etc.)
- displacement field
- cartesian to polar? Some ultrasound images use polar coordinates. (Dženan)
- transform of a single axis (Constantin) (could also be massaged into a displacement field, but may not be the most natural way to represent this)
- timing metadata out of OME and into NGFF (Josh)
- are light wavelengths for channels part of the tranforms (John)
- fine to introduce new type (e.g. angle or spectrum), but try to do this incrementally (Constantin)
- call "setup" / "component" / "configuration" or similar?
- time-lapse FLIM data w/ 2 time indexes - Seb
- viewer should have two sliders?
- RGB: transforms on color spaces?
- discrete vs continuous
- discrete means: no interpolation, cannot "mix"
- continuous: interpolation
- discrete transformations, is this something we want?
- example: 2 or 3 channels with different wavelength, we want to flip them; this would be a discrete transformation that just flips channels
- or shuffling slices, 90 degree rotations, axis permutations
- John & Stephan's initial thoughts: integer indexable -> integer indexable
- Should we have different transform classes?
- discrete -> discrete
- discrete -> continuous
- continuous -> continuous
- one can't "iterate" over a continuous thing (but can integrate ;))
- how does xarray do it
- give an array that map the array to eg the time point (Constantin)
- John: what about the native state
- can be implicit ?!
- Saalfeld: pixel space is the space without name (and it's too late in the day for me to fully understand this)
- Alternative: every dataset space gets a default name derived from the dataset metadata. Becomes weird if their are multiple containers, that might have the same internal names.
- Josh: from linked metadata world, something without a name is a b-node (blank node)
- but how do you find it? you go do thet path, then find the thing that's unnamed
- https://www.w3.org/2005/rules/wg/wiki/bNode_Semantics
- https://en.wikipedia.org/wiki/Blank_node
- native resolution (Seb)
- the space closest to the dataset.
- Orientations (Constantin + Matt)
- medical imaging community / neuro imaging commuinity
- the datasets / organisms have "canonical" orientations
- left to right (sagittal)
- top to bottom (axial, or transverse)
- front to back (coronal)
- the tools that are made to this would use the information
- John: related: quaternions in nifti
- problem: there are multiple ways in nifti and we should just keep one
- Dženan: preferred way: rotation matrix
- Matt: series of rotations / rigid rotation
- Vlado: is added constraint / complexity of rigid-only really worth it
- Tobi: constraining is useful in bdv for example (+1 from Matt)
- Tobi: storing as affine in impl is nice and will probably happen, but just "mark" it as rigid
- Tobi: do we restrict the number of ways that we store? {"type":"rigid", "affine" : []}
- potential restrictions:
- "integer transformations": axis permutation / flipping / slicing???
- translation only
- rotation only (?)
- translation + rotation
- translation + rotation + isotropic scaling
- What should the spec expect of implementations?
- Example: raw space to some physical space to some template space
- how to deal with concatenation of the transformations
- Constantin: even more general, Fiji viewer or others will not be able to support all the transformations
- how do we keep track of which viewer/tool supports what?
- Tischi: e.g. many viewer can deal with the native pixel space and some scaling, but not the more complex ones.
- For these having the "simple" native space, like it currently is with the transforms in datasets
- Vlado: can this be solved by named spaces?

John: channels
are usually discrete and should probably stay like this.
What about wavelengths in microscopy.

## Current v0.4 state