OME-NGFF community call: 2022-10-05

--- tags: NGFF, community-call --- # OME-NGFF community call: 2022-10-05 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/TyfrLiCqRteL0Xfc8HRiOA 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 # Summary * Transforms * People are super excited * v0.5 will introduce coordinate systems * Transformations now must have specified input and output coordinate systems * New transformations will be added * Broad support for relaxing 5D image constraint to nD * Support for relaxing image axis ordering (tczyx) to SHOULD from MUST * Tables * Broad support for adopting AnnData as table model * Initial table specification will be for tables that annotate label images * Initial table specification will not add coordinate systems to tables * xarray compatibility * Proposal to restructure multiscale images and labels to be natively compatible with xarray * Add a group "between" multiscales group and arrays. * now "0/image/.zarray" * was "0/.zarray" * Discussed whether multiple arrays should be allowed to be stored in the same group (a "yes" choice would constrain coordinate systems). * Some concerns raised about potentially creating too many ways to create a valid file. * Next steps * No significant additional spec work is needed; after a few changes it will be time for community review! :tada: * Final review and comments on the spec PRs * Transforms: https://github.com/ome/ngff/pull/138 * Tables: https://github.com/ome/ngff/pull/64 * Add section to clarify features supported in the java, javascript, and python implementations * Base specification with core (required) features * Extended specification levels with features that some clients can choose to not implement. # Links * [Previous meeting notes](https://hackmd.io/Ndb5IHRmQn2PCCNBLkG-fQ) * [Forum post](https://forum.image.sc/t/ome-ngff-community-call-transforms-and-tables/71792) * Tables * [today's slides](https://docs.google.com/presentation/d/1K3ZvxNsaRpXTr1rxVb3uQppV3-bADO44tLBIVvWEM44/edit?usp=sharing) * [image.sc thread](https://forum.image.sc/t/proposal-for-ome-ngff-table-specification/68908/1) * [pull request](https://github.com/ome/ngff/pull/64) * [tidy data](https://tidyr.tidyverse.org/articles/tidy-data.html) * [data APIs dataframe spec RFC](https://data-apis.org/blog/dataframe_protocol_rfc/) * Transformations * [pull request](https://github.com/ome/ngff/pull/138) * [today's slides](https://docs.google.com/presentation/d/1SicK2bGOGGoAw7Kttc0IsfZ9cM4z0-_IPGuHUz1ezQ4/) * [user stories](https://github.com/ome/ngff/issues/84) * [coordinate systems and transformations](https://github.com/ome/ngff/issues/94) * [transformation types](https://github.com/ome/ngff/issues/101) # OME-NGFF community call (17:00 CET; 05 Oct 2022) ## "User registration" Session 1 | Name | Institute | Twitter Handle | GitHub Handle | |------------ |---------------------- |---------------- |--------------- | | Copy | and | paste | me | | Josh Moore | University of Dundee | notjustmoore | joshmoore | | Kevin Yamauchi | ETH Zurich | ky396 | kevinyamauchi | | Norman Rzepka | scalable minds | normanrz | normanrz | | Matthew Hartley| EMBL-EBI | BioImageA | matthewh-ebi | | Will Moore | University of Dundee/OME | will-j-moore | will-moore | | Stephan Saalfeld | HHMI Janelia | herrsaalfeld | axtimwalde | | Isaac Virshup | Helmholtz Munich | ivirshup | ivirshup | | Matt McCormick | Kitware | thewtex | thewtex | | Ken Ho | Crick | drkenho | DrKenHo-crick | | Jeremy Muhlich | Harvard Medical School | jmuhlich | jmuhlich | | Robert Young | Harvard Medical School | | RobJY | |Caterina Strambio-De-Castillia | UMass Medical School | StrambioLab | strambc | | Grzegorz Bokota | university of Warsaw | Czaki_PL | Czaki | | Eric Perlman | | perlman | | Damir Sudar | Quantitative Imaging Systems | | dsudar | | Joel Lüthi | Friedrich Miescher Institute | joel_luethi | jluethi | | Davis Bennett | HHMI/Janelia | davis.v.bennett | d-v-b | | John Bogovic | HHMI/Janelia | BogovicJohn | bogovicj | | Gabor Kovacs | Allen Institute | | kgabor | | Luca Marconato | EMBL | LucaMarconato2 | LucaMarconato | | Merrick Strotton | UCB | @mostlymerrick | mezwick ## Transformations Presentation - John Bogovic presented [slides](https://docs.google.com/presentation/d/1SicK2bGOGGoAw7Kttc0IsfZ9cM4z0-_IPGuHUz1ezQ4/) - on coordinate systems and transforms - Coordinate systems are a set of axes - Transform map one coordinate system to another - all zarr arrays implicitly define an "array coordinate system" that matches xarray defaults, but they can also be explicitly defined - new transformations added (see slides) - proposal to allow iamges to be N-dimensional (currently restricted to 5D) - proposal to relax requirement of axis ordering to a suggestion. ## Transformations Discussion - xarray compatibility by allowing multiple images per multiresolution group - Norman Rzepka (:+1:) will there be metadata multiple images are stored in a multiscale group for bookkeeping? - Josh Moore: So far no, but there is room for discussion - Isaac Virshup (:-1:): concerns that there is overlap with the coordinate systems since one can specify that two images are overlapping by saying they are in the same coordinate system. - Joel Lüthi: concerns about compatibilty with HCS - Davis (:-1:): is the problem that xarray doesn't have a good representation of multiscale? If so, should we instead make the change in xarray? - josh: even the basic representation is problematic for them - saalfeld: thumbs up davis - Matt (:+1:): testing data tree representation (multiscale spatial image) - https://github.com/spatial-image/spatial-image-multiscale/ - response from xarray was "why do something different?" if netcdf + xarray are compatible - should try to be compatible with them if we want them to use napari + webknossos + friends (means adopting their data model) - Kevin: also the impression from SciPy - Davis: they always have coordinates listed explicitly - because a single dataset has multiple arrays (materialize zarr arrays for coordinates) - no one in microscopy wants to do that: used to expressing the transformation as affine or something similarly small that fits in metadata - move conversation back to issue/PR - should we expand support from 5D images to nD? - John Bogovic: in favor - Kevin Yamauchi: in favor - Stephan Saalfeld: in favor - Josh Moore: open to it, but wants to note that doing so will require updating all implementations. - Stephan Saalfeld: coordinate or displacement fields are always n+1 which doesn't work in 5D (+1 from JBogovic) - should we change dimension order to a suggestion? - No objections - Gabor Kovacs: the introduction of the axis mapping transformation already breaks predictable dimension order anyway. This may apply to the 5D-nD question, too. - John Bogovic will make an issue and investigate changing - Norman Rzepka: clarifying, changing MUST to SHOULD? - John Bogovic: yes that is the plan - URL + path - are paths relative? or combine them both? - Saalfeld: make a well defined schema and combine them both (like neuroglancer) - Normal Rzepka: likes the idea of well defined schema, but unsure if it is scope creep - Josh: not sure if it works for all of the locations in the current spec - Further discussion on github - Saalfeld: small extension to neuroglancer's schema: `<STORAGE_FORMAT>://<TRANSPORT_PROTOCOLL>://<CONTAINER_URL>?<GROUP_OR_DATASET_PATH>` - FYI: CZI working on improving metadata support in napari - We'd love to get your perspective on metadata use for viewing and analyzing images, to improve support and display of metadata in napari. Learn more and sign up here: https://bit.ly/3Cwb7cv - If you're also interested in plugin metrics and would like to try a napari hub prototype, go here: https://bit.ly/3e8kEhs ## Tables Presentation - [Documentation for anndata](anndata.readthedocs.io) - Kevin Yamauchi presented [slides](https://docs.google.com/presentation/d/1K3ZvxNsaRpXTr1rxVb3uQppV3-bADO44tLBIVvWEM44/edit?usp=sharing) on tables - Readers also available in R, JS, Rust, Julia - Saalfeld: rows & columns are 1D or ND? 1D. so X is 2D but you can have multiple layers of them. - Not trying to interoperate with the coordinate spec _yet_ - compatible with HCS (investigation by Joel Lüthi) ## Tables Discussion - Tischi: how does this work re: chunking? by row? column? - Kevin: user specified. recommendations are in the spec (e.g. row chunking should be the same for rows & X) - Isaac: do whatever you want - Norman: how do strings / variable length datatypes work - zarr supports this - using their structure - looking at https://awkward-array.readthedocs.io/en/latest/ - Gábor: hierarchies of tables - at top level, will there be metadata of how deep the hierarchy - validation that everything is present - Josh: should guide the client, file listing is hard / impossible for some stores - Joel - if tables are used for ROIs or broader things, do the requirements need to be as hard as they are now? - how are paths defined? relative? absolute? URI (as above)? - Isaac: another vote for doing things uniformly - Saalfeld: agreed. And for example classic URL has a lot of this. - Isaac: worry with Zarr v2, we don't know what the root is. - Josh: might be able to add on in V2 at the NGFF level - add coordinate systems in the future? - Example: centroid or moment of inertia - Grzegorz: vote for this. also **bounding boxes** - Damir: also for superresolution. - fitted points and whatever data goes with it. - John: pain point is that the structure with a skeleton doesn't contain its system - always asking people who produce them what coordinate system - Luca: want columns in anndata with a coordinate space. looking for the most ergonomic thing - low ramification is to keep separate tables for spatial information and for annotation - spatial could inherit all the attributes of an image - separate tables would have annotations which you could map to objects containing spatial information - very tempting beside your features to have an extra "x" and "y" column - additionally, with multiple samples you could end up mixing coordinate spaces - don't have a great way to keep simplificty and ergonomics - AOB # OME-NGFF community call (00:01 CET; 06 Oct 2022) ## "User registration" Session 2 | Name | Institute | Twitter Handle | GitHub Handle | |------------ |---------------------- |---------------- |--------------- | | Copy | and | paste | me | | Josh Moore | University of Dundee | notjustmoore | joshmoore | | Dženan Zukić | Kitware Inc. || dzenanz | | John Bogovic | HHMI/Janelia | BogovicJohn | bogovicj | | Andy Sweet | CZI | | andy-sweet | | Jordao Bragantini | CZB | jobragantini | jookuma | | Luca Marconato | EMBL | LucaMarconato2 | LucaMarconato | | Kevin Yamauchi | ETH Zurich | ky396 | kevinyamauchi | | Judith Lacoste | Canada BioImaging | JLacoste2 | JSDLacoste| | Alice Kang | Canada BioImaging | ## Tables Presentation - Kevin Yamauchi presented [slides](https://docs.google.com/presentation/d/1K3ZvxNsaRpXTr1rxVb3uQppV3-bADO44tLBIVvWEM44) ## Tables Discussion - Juan: adding attributes on the edges of a graph? - Isaac: looking at other sparse representations (Josh missed this on notes if someone wants to add something) - What is the best way to store paths? - [a new issue](https://github.com/ome/ngff/issues/144) - Juan: relative and absolute from the root are good choices (relative to filesystem bad) - Juan: remove multiple indirection - John: use case want to annotate data on the internet that I can't control. how to reference? - Juan: flag to indicate that a path is relative? - each path as an object? ... - Andy: consider a path to the intensity image measured using the labels? - Kevin: there is not, but it is something worth adding - Can we deal with tidy-data? If so, how? (Andy) - https://cran.r-project.org/web/packages/tidyr/vignettes/tidy-data.html#:~:text=Tidy%20data%20is%20a%20standard,Every%20column%20is%20a%20variable - Chi-Li: how is zarr's performance compared to libs for sparse matrix / specific for table forms - Josh: zarr is not really competing with those libs - Chi-Li: using TileDb - Andy: re: AnnData. There is a 'write to zarr' in the api, can we use it? - Kevin: yes, bus doesn't help for languages other than python - Isaac: Vitessce already supports reading from anndata - Andy: https://data-apis.org/ was looking into table interchange format - Isaac: having support for sparse in core python - Draft proposal: https://data-apis.org/dataframe-protocol/latest/purpose_and_scope.html - Juan: consider building a (limited) view into the AnnData that matches the dataframe - Kandarp + Chi-Li: working on napari + metadata - We'd love to get your perspective on metadata use for viewing and analyzing images, to improve support and display of metadata in napari. Learn more and sign up here: https://bit.ly/3Cwb7cv - If you're also interested in plugin metrics and would like to try a napari hub prototype, go here: https://bit.ly/3e8kEhs - Juan: prefer specifying region with path rather than index when a table annotates multiple label images to avoid multiple levels of indirection - on xarray - moving to support the more complicated transforms? Josh: no. - Isaac: at a hackathon xarray agreed that anything that supports the Index interface - Isaac: tables also break netcdf compatibility - Juan: feels like units should be on the transformations and not on the spaces. A space defines the "type" of dimension (space, time, voltage, etc) but it's up to users to decide what units they view them in. - Juan: some useful "space" units are missing in the allowed list, specifically lat/lon, northing/easting. - Juan: other types of dimensions: voltage, current, ... Anything expressible in [pint](https://pint.readthedocs.io/en/stable/index.html) - Dženan : vote to remove mapIndex - Jordao was curious about what happens when there are multiple transforms between spaces - John: it is allowed, but not recommended - Dženan: maybe just take the "first" one?