From 4c29921686c8aa2964881826ed51e5ee900d4405 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 10:44:08 -0300 Subject: [PATCH 01/43] remove leftover reference to bikeshed --- README.md | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/README.md b/README.md index 4821dff2..cf8f3600 100644 --- a/README.md +++ b/README.md @@ -14,16 +14,9 @@ See also [CONTRIBUTING.md](./contributing/index.md) Specifications have been moved to [ome/ngff-spec](https://github.com/ome/ngff-spec). -### Editing specifications - -Specifications are written in markdown, or technically -[bikeshed](https://github.com/tabatkins/bikeshed) -- a markdown document, with -special extensions understood by the bikeshed tool. The bikeshed tool is run -during the Sphinx build step (see conf.py). - # RFCs -Requests for comments (RFCs) are used to discuss and capture high-level decisions within the NGFF community. +Requests for comments (RFCs) are used to discuss and capture high-level decisions within the NGFF community. RFCs are contained under the `rfc` directory at the moment but may be moved out into a separate repo in the future. @@ -37,5 +30,3 @@ RFCs are contained under the `rfc` directory at the moment but may be moved out - - From 87eb2e615a845a30af8de9ea0f047a7e7416b087 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 11:54:39 -0300 Subject: [PATCH 02/43] fix broken links in a-z --- help-desk/index.md | 58 ++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 48 insertions(+), 10 deletions(-) diff --git a/help-desk/index.md b/help-desk/index.md index cadbd2ac..bec2a33a 100644 --- a/help-desk/index.md +++ b/help-desk/index.md @@ -1,8 +1,8 @@ # Help Desk -* [Glossary](#glossary) -* [FAQs](#faqs) -* [Where to seek for help](#where-to-seek-for-help) +- [Glossary](#glossary) +- [FAQs](#faqs) +- [Where to seek for help](#where-to-seek-for-help) ## Glossary @@ -29,11 +29,23 @@ Jump to: [Back to top](#glossary) +### D + +[Back to top](#glossary) + +### E + +[Back to top](#glossary) + +### F + +[Back to top](#glossary) + ### G [Back to top](#glossary) -### H +### H **HCS** - Dedicated layout of OME-Zarr files representing the used wells and plates for High Content Screening (HCS). The layout allows a user to efficiently address and analyze specific data from specific wells. @@ -41,12 +53,24 @@ Jump to: [Back to top](#glossary) +### I + +[Back to top](#glossary) + ### J **JSON file** - A simple standardized human-readable data format for sharing data using nested key-value pairs. [Back to top](#glossary) +### K + +[Back to top](#glossary) + +### L + +[Back to top](#glossary) + ### M **Multiscale** - Multiscale means storing the same image at multiple resolutions (full size, half size, quarter size, etc.). This makes it easy for tools to zoom and navigate very large images quickly—just like how map apps load lower-resolution versions first, then sharpen the view as you zoom in. @@ -54,6 +78,7 @@ Jump to: [Back to top](#glossary) ### N + **NGFF** - Next Generation File Format (NGFF) is a community for solving problems related to producing open-source software for microscopy data. [Back to top](#glossary) @@ -76,6 +101,10 @@ Jump to: [Back to top](#glossary) +### Q + +[Back to top](#glossary) + ### R **RFC** - Request For Comments (RFC) is a process for proposing a change to the standardized specification for OME-Zarr files. @@ -84,7 +113,7 @@ Jump to: ### S -**Shard/ing** - Like [Chunks](#c), sharding is a way of breaking up pixel data for more efficient access. Shards are groups of chunks with headers in front of them for describing the chunks inside. +**Shard/ing** - Like [Chunks](#c), sharding is a way of breaking up pixel data for more efficient access. Shards are groups of chunks in a single object with headers describing the chunks inside. [Back to top](#glossary) @@ -96,6 +125,9 @@ Jump to: ### U +[Back to top](#glossary) + +### V [Back to top](#glossary) @@ -105,6 +137,14 @@ Jump to: [Back to top](#glossary) +### X + +[Back to top](#glossary) + +### Y + +[Back to top](#glossary) + ### Z **Zarr** -- A file format, see the [main page](#../) for more information about what a Zarr is and the benefits of using Zarr. @@ -172,15 +212,13 @@ That is often the case. OME-Zarr include multiresolution data (i.e. pyramids), w Not yet fully. Some workarounds are possible (1D arrays, mesh formats), but this is an active area of development. - - ## Where to look for help + If you have questions or need help with OME-Zarr, you can reach out through the following channels: -| Where | Description | When to use | +| Where | Description | When to use | |-------|-------------| --------------| -| [Image.sc Forum](https://forum.image.sc) | A community forum for image analysis and bioimaging. | To know when to use the tags [ngff](https://forum.image.sc/tag/ngff), [ome-ngff](https://forum.image.sc/tag/ome-ngff), and [ome-zarr](https://forum.image.sc/tag/ome-zarr) in the forum please read [Landing Page](https://ngff.openmicroscopy.org/index.html), Glossary and FAQs in this page. | +| [Image.sc Forum](https://forum.image.sc) | A community forum for image analysis and bioimaging. | To know when to use the tags [ngff](https://forum.image.sc/tag/ngff), [ome-ngff](https://forum.image.sc/tag/ome-ngff), and [ome-zarr](https://forum.image.sc/tag/ome-zarr) in the forum please read [Landing Page](https://ngff.openmicroscopy.org/index.html), Glossary and FAQs in this page. | | [ome/ngff GitHub Issues](https://github.com/ome/ngff/issues) | The official repository for OME-NGFF specifications and related discussions. | For reporting bugs, suggesting features, or discussing technical aspects of the OME-NGFF specifications. | | Office Hours | Regularly scheduled virtual meetings where you can ask questions and get help from the NGFF community | Office hours rotate between APAC/AU/EU- and AMER/AU/EU-friendly times. Join them when you want to chat about OME-Zarr. Read more in the [Community](../community/index.md) page. | | OME-Zarr libraries GitHub Issues| Various repositories for OME-Zarr libraries. | For issues specific to a particular OME-Zarr library, use the respective GitHub repository's issue. | | In person events | Conferences, workshops, and meetups where you can connect with the NGFF community. | To network, learn, and discuss OME-Zarr in person. Check the [Community](../community/index.md) page for upcoming events. | - From 2e0f2e1697b27f5d4061dcdf9d4123c17e471765 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 11:55:27 -0300 Subject: [PATCH 03/43] fix internal link for 0.5 (soon to change) --- specifications/index.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/specifications/index.md b/specifications/index.md index e84b8ad8..2ff0644e 100644 --- a/specifications/index.md +++ b/specifications/index.md @@ -1,9 +1,8 @@ -Specifications -============== +# Specifications OME-Zarr files have standardized metadata (that is the OME portion of "OME-Zarr") - each new version of OME-Zarr files has its own specification. Those specifications are listed below. -The current released version of the OME-Zarr specification is [0.5](0.5/ngff_spec/index.md). +The current released version of the OME-Zarr specification is [0.5](0.5/index.md). ```{toctree} :maxdepth: 1 @@ -17,4 +16,4 @@ dev/index.md 0.1/index.md dev/version_history -``` \ No newline at end of file +``` From 70d2f4f78ac4c6cdbdf5e11cab8abf874def7717 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 11:55:46 -0300 Subject: [PATCH 04/43] Fix boldface errors --- index.md | 62 ++++++++++++++++++++++++++++---------------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/index.md b/index.md index b6300c6a..d7f2ccd1 100644 --- a/index.md +++ b/index.md @@ -15,12 +15,12 @@ In summary, OME-Zarr allows you to store, share and stream large images. You can An OME-Zarr is a file format optimized for storing, viewing, & sharing large images. There are two parts to an OME-Zarr: -* **The "Zarr" part describes how the pixel data for the images are laid out** -* **The "OME" part, which stands for [Open Microscopy Environment](https://www.openmicroscopy.org/), describes metadata about the pixel data. This includes metadata such as: - * spatial relationships - * high content screening data - * well data - * [and more](./specifications/index)! +- **The "Zarr" part describes how the pixel data for the images are laid out**. [Zarr](https://zarr.dev) is a next-generation data format used for scientific datasets in multiple domains. +- **The "OME" part describes metadata about the pixel data.** OME stands for [Open Microscopy Environment](https://www.openmicroscopy.org/). This includes metadata such as: + - spatial relationships + - high content screening data + - well data + - [and more](./specifications/index)! ## Why would I use OME-Zarr? @@ -28,14 +28,14 @@ In general, OME-Zarr is growing as a default [FAIR](https://en.wikipedia.org/wik OME-Zarr files have two major benefits: -* **Standardization:** "OME-Zarr" is a "Zarr" with embedded standardized metadata in the Open Microscopy Environment (OME) format. - * **_Sharing_**: It eases cross-organization file sharing, aiding organizational collaboration and data sharing. Repositories like the [Image Data Resource](https://idr.openmicroscopy.org/) and [BioImage Archive](https://www.ebi.ac.uk/bioimage-archive/) are currently migrating to having OME-Zarr as a standard format for _all_ their data. - * **_Interoperability_**: Standardized metadata enables the ability to "mix and match" tools from different organizations, benefiting from the strengths of multiple tools as needed. +- **Standardization:** "OME-Zarr" is a "Zarr" with embedded standardized metadata in the Open Microscopy Environment (OME) format. + - **_Sharing_**: It eases cross-organization file sharing, aiding organizational collaboration and data sharing. Repositories like the [Image Data Resource](https://idr.openmicroscopy.org/) and [BioImage Archive](https://www.ebi.ac.uk/bioimage-archive/) are currently migrating to having OME-Zarr as a standard format for _all_ their data. + - **_Interoperability_**: Standardized metadata enables the ability to "mix and match" tools from different organizations, benefiting from the strengths of multiple tools as needed. -* **Parallel access**: Chunking is inherent to "Zarr" files. This means "Zarr" files are stored in independently-accessible blocks. - * **_Storage_**: Microscopy images can be quite large and can therefore reach Cloud system storage limits for individual files; the chunked nature of a Zarr can alleviate this issue. Some storage systems may also duplicate byte-equivalent files, so a chunked file like Zarr may save storage space. - * **_Viewing_**: Viewers can target specific chunks to load based upon the current view, reducing lag, & enabling massive images to be viewed within browsers. - * **_Cost_**: When viewing or reading data, the total cost of accessing a Zarr file on the cloud may be less than a more monolithic file format due to the more efficient data access patterns. Ex. A viewer can just access the chunks of the image it needs to display rather than the entire image. +- **Parallel access**: Chunking is inherent to "Zarr" files. This means "Zarr" files are stored in independently-accessible blocks. + - **_Storage_**: Microscopy images can be quite large and can therefore reach Cloud system storage limits for individual files; the chunked nature of a Zarr can alleviate this issue. Some storage systems may also duplicate byte-equivalent files, so a chunked file like Zarr may save storage space. + - **_Viewing_**: Viewers can target specific chunks to load based upon the current view, reducing lag, & enabling massive images to be viewed within browsers. + - **_Cost_**: When viewing or reading data, the total cost of accessing a Zarr file on the cloud may be less than a more monolithic file format due to the more efficient data access patterns. Ex. A viewer can just access the chunks of the image it needs to display rather than the entire image. Of note, both benefits contribute to **_AI-readiness_**: the standardized metadata & access patterns provide a common layer for machine-learning workflows, reducing the friction for developers to build and test models. @@ -45,33 +45,33 @@ The [tools](./tools/index), [data](./data/index), and [ecosystem](./ecosystem/in While the format matures, it may be frustrating to use OME-Zarr in some cases, for example: -* If you are working with small images, not planning to share them and your current tools already work well, then using OME-Zarr may not be necessary. Planned expansions to the specification (such as single-file Zarrs) will make it more convenient in these scenarios. +- If you are working with small images, not planning to share them and your current tools already work well, then using OME-Zarr may not be necessary. Planned expansions to the specification (such as single-file Zarrs) will make it more convenient in these scenarios. -* If you need specific conditions for which OME-Zarr support is not mature, you may need to use a different file format. - * Particularly, if your original file is lossy compressed, you will see a large increase in file size (about an order of magnitude) as the images are decompressed into OME-Zarr, since transferring lossy compressed tiles is not yet supported. This currently impacts most whole slide image (WSI) formats such as SVS, CZI, and NDPI, which are lossy JPEG compressed by default. +- If you need specific conditions for which OME-Zarr support is not mature, you may need to use a different file format. + - Particularly, if your original file is lossy compressed, you will see a large increase in file size (about an order of magnitude) as the images are decompressed into OME-Zarr, since transferring lossy compressed tiles is not yet supported. This currently impacts most whole slide image (WSI) formats such as SVS, CZI, and NDPI, which are lossy JPEG compressed by default. ## Who is using OME-Zarr? These are _some_ of the organizations (and their dataset pages) that are using OME-Zarr for their data. -* [Allen Institute](https://bff.allencell.org/datasets) -* biohub -* [Broad Institute](https://broadinstitute.github.io/cellpainting-gallery/overview.html) -* [EMBL - Image Data Resource (IDR)](https://idr.openmicroscopy.org/) -* [Howard Hughes Medical Institute, Janelia (HHMI)](https://openorganelle.janelia.org/) -* [Jackson Laboratory (JAX)](https://images.jax.org/) -* ... [and more](./data/index) +- [Allen Institute](https://bff.allencell.org/datasets) +- biohub +- [Broad Institute](https://broadinstitute.github.io/cellpainting-gallery/overview.html) +- [EMBL - Image Data Resource (IDR)](https://idr.openmicroscopy.org/) +- [Howard Hughes Medical Institute, Janelia (HHMI)](https://openorganelle.janelia.org/) +- [Jackson Laboratory (JAX)](https://images.jax.org/) +- ... [and more](./data/index) ## How do I use OME-Zarr? -* Already have a Zarr? - * Check out the [tools section](./tools/index)! -* Want to create a Zarr? - * Check out the [tools section](./tools/index)! -* Want to see or download a Zarr? - * Check out the [data section](./data/index)! -* Want to cite OME-Zarr/NGFF in your work? - * Check out the [publications section](./publications/index)! +- Already have a Zarr? + - Check out the [tools section](./tools/index)! +- Want to create a Zarr? + - Check out the [tools section](./tools/index)! +- Want to see or download a Zarr? + - Check out the [data section](./data/index)! +- Want to cite OME-Zarr/NGFF in your work? + - Check out the [publications section](./publications/index)! ## Have other questions? From 4edff7a4c6fb373de470321697e0041ba74190c5 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 11:58:32 -0300 Subject: [PATCH 05/43] change links to use https --- boilerplate/header.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boilerplate/header.include b/boilerplate/header.include index 79b2fd56..7bd9e500 100644 --- a/boilerplate/header.include +++ b/boilerplate/header.include @@ -10,7 +10,7 @@
- OME logo (6 circles in a hexagon) + OME logo (6 circles in a hexagon)

[TITLE]

[LONGSTATUS], From d327d106a157e4ea1be05c6b35d0f952c10dfd23 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 08:47:28 -0300 Subject: [PATCH 06/43] fix anchors and refs in rfc1 --- contributing/specification/index.md | 2 +- resources/data/index.md | 2 +- rfc/1/index.md | 7 +++++-- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/contributing/specification/index.md b/contributing/specification/index.md index ca262d33..07c01557 100644 --- a/contributing/specification/index.md +++ b/contributing/specification/index.md @@ -6,7 +6,7 @@ request for comment (RFC) documents. In the future we will flesh out this page with a guide to RFCs, but in the meantime the RFC process is outlined in the -[Implementation section of RFC 1](../rfc/1/index.md#implementation). +[Implementation section of RFC 1](rfc1-implementation). ## Comment on a Request For Comment (RFC) diff --git a/resources/data/index.md b/resources/data/index.md index aef32357..3a51d379 100644 --- a/resources/data/index.md +++ b/resources/data/index.md @@ -16,7 +16,7 @@ Resources curating OME-Zarr sample data, for demonstration and testing purposes. | BIA Samples | [BIA Samples logo](https://uk1s3.embassy.ebi.ac.uk/bia-integrator-data/pages/omengff.html) | Sample OME-Zarr datasets from the BioImage Archive for testing | | Sanger Institute Samples | [Sanger Institute Samples logo](https://www.sanger.ac.uk/project/ome-zarr/) | Datasets from the Sanger Institute that have been converted to OME-Zarr to test and encourage the file format | | SSBD samples | [SSBD samples logo](https://ssbd.riken.jp/ssbd-ome-ngff-samples) | Sample OME-Zarr datasets from the Systems Science of Biological Dynamics database (SSBD) for testing and demonstration purposes | -| OME 2024 NGFF challenge | [OME 2024 NGFF challenge logo](https://ome.github.io/) | Close to 500 TB of data in the OME-Zarr 0.5 format | +| OME 2024 NGFF challenge | [OME 2024 NGFF challenge logo](https://ome.github.io/) | Close to 500 TB of data in the OME-Zarr 0.5 format | ## Data portals diff --git a/rfc/1/index.md b/rfc/1/index.md index ee7fba5f..20818232 100644 --- a/rfc/1/index.md +++ b/rfc/1/index.md @@ -238,6 +238,7 @@ right direction. **Reviewers** should strive to provide feedback which informs * **Commenters** are other members of the community who, though not contacted as **Reviewers**, have provided feedback that they would like added to the official record of the RFC. +(rfc1-implementation)= ## Implementation The RFC process can be represented as a state diagram with the various stakeholders responsible for forward motion. @@ -322,7 +323,8 @@ to the **Editors**, either via a public PR adding the review in markdown to the RFC's subdirectory or by emailing the **Editors** directly. (This latter course should only be used when necessary.) -(rfc-recommendations)= Possible recommendations from **Reviewers** in ascending order of support are: +(rfc-recommendations)= +Possible recommendations from **Reviewers** in ascending order of support are: * “Reject” suggests that a **Reviewer** considers there to be no merit to an RFC. This should be a last recourse. Instead, suggestions in a “Major @@ -367,7 +369,8 @@ contact **Reviewers** to see if their recommendations have changed. > 🕑 Authors responses to Reviewers should be returned to the Editors in less than two weeks. -(anchor-rebuttal-r6)= This brings a critical, and possibly iterative, decision point (R6). If all **Reviewers** `approve` and there are no further changes needed, the RFC can progress to S1 as soon as there are two in-progress implementations. If the **Reviewers** do _not_ approve, then the **Editors** will make one of three decisions (R7): +(anchor-rebuttal-r6)= +This brings a critical, and possibly iterative, decision point (R6). If all **Reviewers** `approve` and there are no further changes needed, the RFC can progress to S1 as soon as there are two in-progress implementations. If the **Reviewers** do _not_ approve, then the **Editors** will make one of three decisions (R7): * The **Editors** MAY provide **Authors** a list of necessary changes. These will be based on the **Reviewers** suggestions but possibly modified, e.g., to remove contradictions. * The **Editors** MAY decide that the RFC is to be closed (R9). This is the decision that SHOULD be chosen if there is a unanimous `Reject` recommendation. The **Authors** MAY then decide to re-draft a new RFC (D2). From b310e48e1b85cfeccdd9c70cf3da30aa739dcbe9 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:24:01 -0300 Subject: [PATCH 07/43] fix internal links and anchors --- contributing/specification/index.md | 4 +- help-desk/index.md | 5 ++- index.md | 13 +++--- resources/data/index.md | 1 + resources/ecosystem/index.md | 3 +- resources/rfc-status-codes/index.md | 17 +++---- resources/tools/index.md | 3 +- rfc/1/index.md | 2 + rfc/1/templates/review_template.md | 1 + rfc/3/comments/3/index.md | 2 + rfc/3/versions/2026-07-17/index.md | 69 +++++++++++++---------------- 11 files changed, 60 insertions(+), 60 deletions(-) diff --git a/contributing/specification/index.md b/contributing/specification/index.md index 07c01557..7090703d 100644 --- a/contributing/specification/index.md +++ b/contributing/specification/index.md @@ -13,7 +13,7 @@ meantime the RFC process is outlined in the If you want to leave a suggestion or comment on an RFC that is under review, please leave a comment in a new page under the "comments/" directory for the relevant RFC. A template is also available for formatting your comment: -[template](../rfc/1/templates/review_template). +[template](rfc1-review-template). ## How to change the specification @@ -143,7 +143,7 @@ Other useful admonitions and directives (e.g., `hint`, `note`) can be found [her ## Building *only* the spec document -The spec document under the [ngff-spec](github.com/ome/ngff-spec) repository can be built as a standalone document to make writing and rendering a smoother experience. +The spec document under the [ngff-spec](https://github.com/ome/ngff-spec) repository can be built as a standalone document to make writing and rendering a smoother experience. To build the spec document, you first need to install the necessary dependencies: After cloning the ngff-spec repo, navigate into the repository on your machine and install the dependencies using pip: diff --git a/help-desk/index.md b/help-desk/index.md index bec2a33a..c3567770 100644 --- a/help-desk/index.md +++ b/help-desk/index.md @@ -91,7 +91,7 @@ Jump to: **OME-NGFF** - OME-NGFF refers to the resulting efforts of the OME & NGFF communities. -**OME-Zarr** - An OME-Zarr is a standardized file format for microscopy images. More details on the [main page](#../). +**OME-Zarr** - An OME-Zarr is a standardized file format for microscopy images. More details on the [main page](#main-page). [Back to top](#glossary) @@ -147,7 +147,7 @@ Jump to: ### Z -**Zarr** -- A file format, see the [main page](#../) for more information about what a Zarr is and the benefits of using Zarr. +**Zarr** -- A file format, see the [main page](#main-page) for more information about what a Zarr is and the benefits of using Zarr. **Zarr Group** - A Zarr group is like a folder inside a dataset. It can hold arrays, metadata, or other groups, helping organize complex data into a clear hierarchy. Think of it as a way to keep all related images and information neatly together. @@ -212,6 +212,7 @@ That is often the case. OME-Zarr include multiresolution data (i.e. pyramids), w Not yet fully. Some workarounds are possible (1D arrays, mesh formats), but this is an active area of development. +(where-to-seek-for-help)= ## Where to look for help If you have questions or need help with OME-Zarr, you can reach out through the following channels: diff --git a/index.md b/index.md index d7f2ccd1..c54d30c9 100644 --- a/index.md +++ b/index.md @@ -1,3 +1,4 @@ +(main-page)= # Next-Generation File Formats (NGFF) + OME-Zarr Welcome to the Next-Generation File Formats (NGFF) main page! This site is dedicated to providing resources for the NGFF community and those that are interested in getting started with OME-Zarr. @@ -39,7 +40,7 @@ OME-Zarr files have two major benefits: Of note, both benefits contribute to **_AI-readiness_**: the standardized metadata & access patterns provide a common layer for machine-learning workflows, reducing the friction for developers to build and test models. -The [tools](./tools/index), [data](./data/index), and [ecosystem](./ecosystem/index) may provide a better sense of the range of scientific use cases that may benefit from OME-Zarr. The [publications](./publications/index) page provides a list of publications that have used OME-Zarr in their work. +The [tools](#resources-tools), [data](#resources-data), and [ecosystem](#resources-ecosystem) may provide a better sense of the range of scientific use cases that may benefit from OME-Zarr. The [publications](#resources-publications) page provides a list of publications that have used OME-Zarr in their work. ## When would I not use OME-Zarr? @@ -60,18 +61,18 @@ These are _some_ of the organizations (and their dataset pages) that are using O - [EMBL - Image Data Resource (IDR)](https://idr.openmicroscopy.org/) - [Howard Hughes Medical Institute, Janelia (HHMI)](https://openorganelle.janelia.org/) - [Jackson Laboratory (JAX)](https://images.jax.org/) -- ... [and more](./data/index) +- ... [and more](#resources-data) ## How do I use OME-Zarr? - Already have a Zarr? - - Check out the [tools section](./tools/index)! + - Check out the [tools section](#resources-tools)! - Want to create a Zarr? - - Check out the [tools section](./tools/index)! + - Check out the [tools section](#resources-tools)! - Want to see or download a Zarr? - - Check out the [data section](./data/index)! + - Check out the [data section](#resources-data)! - Want to cite OME-Zarr/NGFF in your work? - - Check out the [publications section](./publications/index)! + - Check out the [publications section](#resources-publications)! ## Have other questions? diff --git a/resources/data/index.md b/resources/data/index.md index 3a51d379..e1c875dc 100644 --- a/resources/data/index.md +++ b/resources/data/index.md @@ -1,3 +1,4 @@ +(resources-data)= # Data Resources Looking for test data? [IDR Samples](https://idr.github.io/ome-ngff-samples/) aims at covering the different corners of the specification. diff --git a/resources/ecosystem/index.md b/resources/ecosystem/index.md index 4b9dbf4f..10c92ea1 100644 --- a/resources/ecosystem/index.md +++ b/resources/ecosystem/index.md @@ -1,8 +1,9 @@ +(resources-ecosystem)= # Ecosystem Workflows and data formats that adopt OME-Zarr and build upon it for extended capabilities and interoperabilitieswith additional systems. -It extends the [tools](../tools/index.md) section by including projects that are not necessarily tools for viewing, writing, reading, converting, validating or processing OME-Zarr data, but that are still part of a ecosystem of projects with first-class, dedicated support for OME-Zarr. +It extends the [tools](#resources-tools) section by including projects that are not necessarily tools for viewing, writing, reading, converting, validating or processing OME-Zarr data, but that are still part of a ecosystem of projects with first-class, dedicated support for OME-Zarr. It fits microscope acquisition software, analysis pipelines, standards and extensions, gallery-like displays, integrative workflows, and the like. diff --git a/resources/rfc-status-codes/index.md b/resources/rfc-status-codes/index.md index 651c74b4..22c26a43 100644 --- a/resources/rfc-status-codes/index.md +++ b/resources/rfc-status-codes/index.md @@ -1,18 +1,13 @@ -RFC status codes -============ - - -[RFC 1](../../rfc/1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. +# RFC status codes +[RFC 1](#rfc-1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. ![State diagram of the RFC process](../../rfc/1/diagram.png) -This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. +This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. The status codes indicating ends of an RFC process are outlined in **bold**. -Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. - - +Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. | Phase | Code | Description | Wait time | Action by | | ----- | ------ | --------------------------------------------------------------------------------------------------- | --------------- | ----------------- | @@ -26,7 +21,7 @@ Wait times provide a sense on how fast the process is expected to move to the ne | RFC | R2 | REVIEWERS submit REVIEWS with recommendations as new PRs. | NA | REVIEWER + EDITOR | | RFC | R3 | EDITORS merge REVIEWS and send to AUTHOR for RESPONSE | NA | AUTHOR + EDITOR | | RFC | R4 | AUTHORS prepare RESPONSE and changes to RFC | NA | AUTHOR | -| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | +| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | | RFC | R6 | REVIEWERS approve? | NA | REVIEWER | | RFC | R7 | If no, EDITORS approve? | NA | EDITOR | | RFC | R8 | If changes necessary, AUTHORS prepare changes to RFC and/or RESPONSE. If they are major, back to R1 | NA | AUTHOR | @@ -35,4 +30,4 @@ Wait times provide a sense on how fast the process is expected to move to the ne | SPEC | S1 | RFC accepted! AUTHORS or EDITORS update the SPEC | NA | AUTHOR + EDITOR | | SPEC | S2 | Clarifications needed? | If yes, 4 weeks | EDITOR | | SPEC | S3 | Update implementations | NA | EDITOR | -| SPEC | **S4** | SPEC adopted | NA | EDITOR | \ No newline at end of file +| SPEC | **S4** | SPEC adopted | NA | EDITOR | diff --git a/resources/tools/index.md b/resources/tools/index.md index 82e84b32..89642e6e 100644 --- a/resources/tools/index.md +++ b/resources/tools/index.md @@ -1,3 +1,4 @@ +(resources-tools)= # Tools A list of tools and libraries with OME-Zarr support. These are developed by various members of the NGFF community. If you think your tool/library should be listed here, please [open a pull request](https://github.com/ome/ngff). @@ -109,7 +110,7 @@ Want to validate a Zarr? Use one of these. | Name | Link | Description | | -------- | ------- | ------- | -| ome-ngff-validator | [OME NGFF Validator logo](https://ome.github.io/ome-ngff-validator/) | Web page for validating OME-Zarr files. | +| ome-ngff-validator | [OME NGFF Validator logo](https://ome.github.io/ome-ngff-validator/) | Web page for validating OME-Zarr files. | | ome-zarr-models | [![image](https://github.githubassets.com/favicons/favicon.svg)](https://github.com/ome-zarr-models/ome-zarr-models-py) | Python package and command line interface that can validate OME-Zarr files | | yaozarrs | [![image](https://github.githubassets.com/favicons/favicon.svg)](https://github.com/imaging-formats/yaozarrs) | Bottom-up python library with models and CLI for creating & validating OME-Zarr groups and documents with optional extras for array-backend-agnostic I/O | diff --git a/rfc/1/index.md b/rfc/1/index.md index 20818232..a4a931b6 100644 --- a/rfc/1/index.md +++ b/rfc/1/index.md @@ -1,6 +1,8 @@ RFC-1: RFC Process ================== +(rfcs:rfc1)= + Definition of the NGFF “Request for Comment” (RFC) process ```{toctree} diff --git a/rfc/1/templates/review_template.md b/rfc/1/templates/review_template.md index 10597d42..f1d37f7c 100644 --- a/rfc/1/templates/review_template.md +++ b/rfc/1/templates/review_template.md @@ -1,3 +1,4 @@ +(rfc1-review-template)= # Review Template Replace the title above of this file with “RFC-NUM: Review NUM” diff --git a/rfc/3/comments/3/index.md b/rfc/3/comments/3/index.md index 289e8be4..02e3e405 100644 --- a/rfc/3/comments/3/index.md +++ b/rfc/3/comments/3/index.md @@ -1,5 +1,7 @@ # RFC-3: Comment 3 +(rfcs:rfc3:comment3)= + | **Role** | Name | GitHub Handle | Institution | |----------|------|---------------|-------------| | **Author** | [Cornelia Wetzker](https://orcid.org/0000-0002-8367-5163) | [cwetzker](https://github.com/cwetzker) | TU Dresden | diff --git a/rfc/3/versions/2026-07-17/index.md b/rfc/3/versions/2026-07-17/index.md index 954d514f..78178c27 100644 --- a/rfc/3/versions/2026-07-17/index.md +++ b/rfc/3/versions/2026-07-17/index.md @@ -86,19 +86,19 @@ This RFC is currently in RFC state `R1` (send for review). - [btbest](https://github.com/btbest) - - 2026-02-02 - - [Comment](./comments/1/index) + - [Comment](#rfcs:rfc3:comment1) * - Commenter - Chris Barnes - [clbarnes](https://github.com/clbarnes) - German BioImaging - 2026-02-05 - - [Comment](./comments/2/index) + - [Comment](#rfcs:rfc3:comment2) * - Commenter - Cornelia Wetzker - [cwetzker](https://github.com/cwetzker) - Technische Universität Dresden - 2026-03-19 - - [Comment](./comments/3/index) + - [Comment](#rfcs:rfc3:comment3) ``` ## Overview @@ -109,7 +109,7 @@ conversion of proprietary datasets, usage by microscope vendors[^1], and usage by novel microscopy modalities[^2]. This RFC removes these restrictions, opening NGFF to many more users within its -target domain (and beyond). Because it *only* removes restrictions, existing +target domain (and beyond). Because it _only_ removes restrictions, existing valid OME-Zarr datasets will remain valid after implementation of this proposal. @@ -144,7 +144,6 @@ and, > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. - and, > - Every Zarr array referred to by a `path` MUST have the same number of @@ -158,9 +157,9 @@ hamper the adoption of OME-Zarr as an acquisition-time format due to performance concerns: many acquisitions happen in TZCYX order (all channels are acquired together for each z-slice), which violates the "axes must be ordered by type" requirement. In such cases, scientists must first acquire their data -and *then* transpose it — an expensive proposition for large datasets. (Note: +and _then_ transpose it — an expensive proposition for large datasets. (Note: Admittedly, Zarr transpose codecs, as well as the mapAxis transformation from -RFC-5, already offer solutions to this problem. However, the *simplest* +RFC-5, already offer solutions to this problem. However, the _simplest_ solution of flexible array ordering with default codecs and only scale and translation transforms is only open after this RFC.) @@ -195,7 +194,7 @@ fluorophore decay lifetime can be used to get more information about the sample, for example by separating fluorophores not only according to their emission spectra but also their lifetime. The decay measurement constitutes an additional time axis called `u` or `µ` and can result in a 6-dimensional -dataset with axes `CTUZYX`. (See [comment 3](./comments/3/index), and [this +dataset with axes `CTUZYX`. (See [comment 3](#rfcs:rfc3:comment3), and [this paper][flim-paper].) FLIM data currently cannot be represented in OME-Zarr, causing users to use @@ -219,7 +218,7 @@ important part of data quality checks. Currently, this kind of microscopy data cannot be stored in OME-Zarr. Within the same workflow, the crystal orientation is usually encoded as three -*Euler angles* or four *quaternion* components stored at each pixel position. +_Euler angles_ or four _quaternion_ components stored at each pixel position. Although it's possible to use the "custom" axis for this purpose, a dedicated axis with a clear naming convention is more ergonomic for scientists. @@ -241,17 +240,17 @@ to save these intermediate image products for later reprocessing. ### Overlapping labels -OME-Zarr can represent not only raw images, but also *label images*, or +OME-Zarr can represent not only raw images, but also _label images_, or segmentations. Traditionally, segmentations assigned a single integer value to each pixel in the source image. However, newer segmentation methods produce -*coarse-to-fine* segmentations, with semantic meaning. For images spanning many +_coarse-to-fine_ segmentations, with semantic meaning. For images spanning many scales, as produced by modern microscopes, we may want to segment tissues, cells within those tissues, and organelles within those cells. These three levels of segmentations can be stacked along a new "coarseness" axis. -Similarly, new segmentation methods can produce *overlapping binary masks*. Due -to the overlap, they *cannot* be stored as traditional integer masks (one value -per pixel), but are typically instead stored as *n* boolean masks. For this +Similarly, new segmentation methods can produce _overlapping binary masks_. Due +to the overlap, they _cannot_ be stored as traditional integer masks (one value +per pixel), but are typically instead stored as _n_ boolean masks. For this mask, an extra "instance" axis is needed in addition to the [TCZ]YX axes of a source image. @@ -261,7 +260,7 @@ Downstream computational products are necessary for the analysis of microscopy data, and these should ideally be stored in formats compatible with the tooling used to work with the raw data. The format aims to be flexible enough to accommodate these products, such as segmentations (the `label-image` section), -or the outputs of registrations (see [rfc-5](../5/index)). +or the outputs of registrations (see [rfc-5](#rfcs:rfc5:version3)). Some outputs may naturally contain arbitrary dimensions, for example, a grid search of the parameter space for a denoising algorithm may contain an @@ -290,7 +289,8 @@ After this specification change, tools may encounter OME-Zarr files that don't match the earlier expectations of containing a subset of the TCZYX axes. This proposal is agnostic as to what to do in those situations, and indeed the appropriate action depends on the tool, but some suggestions include: -- fail with an informative error message. (i.e. *partial* implementations are + +- fail with an informative error message. (i.e. _partial_ implementations are OK, especially if well-documented.) - prompt the user about which axes to treat as spatial. - arbitrarily choose which axes to treat as spatial. @@ -304,36 +304,31 @@ document, taking as base the current development version: > - The length of `axes` must be between 2 and 5 and MUST be equal to the > dimensionality of the Zarr arrays storing the image data (see > `datasets:path`). -> > - `axes` MUST contain 2 or 3 entries of `type:space` -> > - `axes` MAY contain one additional entry of `type:time` -> > - `axes` MAY contain one additional entry of `type:channel` or a null / > custom type. -> > - `axes` entries MUST be ordered by `type` where the `time` axis must come > first (if present), followed by the `channel` or custom axis (if present) > and the axes of type `space`. -> > - If there are three spatial axes where two correspond to the image plane > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. -2. The following lines are *added* to "multiscales metadata": +2. The following lines are _added_ to "multiscales metadata": > 0. The length of the axis names MUST match the number of axes of the array. -> 1. *If* a dataset contains exactly 2 spatial dimensions, those dimensions +> 1. _If_ a dataset contains exactly 2 spatial dimensions, those dimensions > SHOULD be named `y` and `x`, except where rule 4 applies. -> 2. *If* a dataset contains exactly 3 spatial dimensions, those dimensions +> 2. _If_ a dataset contains exactly 3 spatial dimensions, those dimensions > SHOULD be named 'z', 'y', and 'x', except where rule 4 applies. -> 3. *If* a dataset contains exactly 1 time dimension, it should be named `t`. +> 3. _If_ a dataset contains exactly 1 time dimension, it should be named `t`. > 4. When image data axes map straightforwardly to axes with common names in > the relevant field of practice, those axes SHOULD be named according to > such conventions. For example, spatial frequency axes resulting from a > Fourier transformation of `z', 'y', and 'x' SHOULD be named 'w', 'v', and -> `u`, respectively. Similarly, a temporal frequency axis resulting from -> a Fourier transformation of the `t` axis SHOULD be named `w` or `ω`. +`u`, respectively. Similarly, a temporal frequency axis resulting from +a Fourier transformation of the `t`axis SHOULD be named`w`or`ω`. > 5. Axis names MUST NOT be repeated within a dataset, and SHOULD NOT be > different only by upper/lower-case. For example, the same dataset SHOULD > NOT have both an `X` and an `x` axis. @@ -370,7 +365,7 @@ the RFC. Developers of visualization libraries and software are concerned that this PR may result in a "wild west" of OME-Zarr datasets that have little in common, -making it difficult for tools to decide *which* axes to display. More details +making it difficult for tools to decide _which_ axes to display. More details about these concerns are developed below in the "Drawbacks" section. ## Backwards Compatibility @@ -426,21 +421,21 @@ have assuaged most implementation concerns][recap comment]. ## Performance The current OME-Zarr specification ensures arrays are stored in order TCZYX. -With C-order array data, this ensures efficient access for *some* but not *all* +With C-order array data, this ensures efficient access for _some_ but not _all_ access patterns. By removing restrictions on axis orderings, a new class of "mistake" is possible, as someone could save an array in order XYTCZ, which would combine poorly with C-order arrays to view XY planes. However, it is -arguable that Zarr chunking is in fact more important here — XYTCZ *could* be +arguable that Zarr chunking is in fact more important here — XYTCZ _could_ be a perfectly cromulent axis ordering for XY planes if the Zarr chunk size was (1024, 1024, 1, 1, 1). Moreover, imposing a fixed axis ordering can incur performance penalties at -*write* time (where performance is often critical) if the data is not already +_write_ time (where performance is often critical) if the data is not already in the expected order. Therefore, this proposal argues that any performance implications are better addressed through good documentation and good defaults. Indeed, more flexible -dimension ordering could *improve* performance in some scenarios, such as +dimension ordering could _improve_ performance in some scenarios, such as "pixel drilling", that is, extracting the value of a single x/y position over time. @@ -475,7 +470,6 @@ an informative error message (e.g. "The given dataset contains an unknown axis This RFC is placed in the public domain. - [nat methods paper]: https://www.nature.com/articles/s41592-021-01326-w [ome-model]: https://github.com/ome/ngff/pull/239/files#r1609781780 [ngff 0.4]: https://ngff.openmicroscopy.org/specifications/0.4/index.html @@ -502,11 +496,12 @@ This RFC is placed in the public domain. [zulip-rfc-3-thread]: https://imagesc.zulipchat.com/#narrow/channel/328251-NGFF/topic/RFC-3.3A.20remove.20dimension.20restrictions/near/568178521 [^1]: https://github.com/ome/ngff/pull/239#issuecomment-2122809286 + [^2]: https://github.com/ome/ngff/pull/239#issuecomment-2149119404 ## Changelog -| Date | Description | Link | -| ---------- | ---------------------------- | ---------------------------------------------------------------------------- | -| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | -| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | +| Date | Description | Link | +| ---------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | +| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | +| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | From da508020d90c099e6fac5e82fcb54ce8ce5c97b4 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:24:12 -0300 Subject: [PATCH 08/43] fix link to rfc1 --- resources/rfc-status-codes/index.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/resources/rfc-status-codes/index.md b/resources/rfc-status-codes/index.md index 22c26a43..7f487f04 100644 --- a/resources/rfc-status-codes/index.md +++ b/resources/rfc-status-codes/index.md @@ -1,13 +1,18 @@ -# RFC status codes +RFC status codes +============ + + +[RFC 1](#rfcs:rfc1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. -[RFC 1](#rfc-1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. ![State diagram of the RFC process](../../rfc/1/diagram.png) -This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. +This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. The status codes indicating ends of an RFC process are outlined in **bold**. -Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. +Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. + + | Phase | Code | Description | Wait time | Action by | | ----- | ------ | --------------------------------------------------------------------------------------------------- | --------------- | ----------------- | @@ -21,7 +26,7 @@ Wait times provide a sense on how fast the process is expected to move to the ne | RFC | R2 | REVIEWERS submit REVIEWS with recommendations as new PRs. | NA | REVIEWER + EDITOR | | RFC | R3 | EDITORS merge REVIEWS and send to AUTHOR for RESPONSE | NA | AUTHOR + EDITOR | | RFC | R4 | AUTHORS prepare RESPONSE and changes to RFC | NA | AUTHOR | -| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | +| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | | RFC | R6 | REVIEWERS approve? | NA | REVIEWER | | RFC | R7 | If no, EDITORS approve? | NA | EDITOR | | RFC | R8 | If changes necessary, AUTHORS prepare changes to RFC and/or RESPONSE. If they are major, back to R1 | NA | AUTHOR | @@ -30,4 +35,4 @@ Wait times provide a sense on how fast the process is expected to move to the ne | SPEC | S1 | RFC accepted! AUTHORS or EDITORS update the SPEC | NA | AUTHOR + EDITOR | | SPEC | S2 | Clarifications needed? | If yes, 4 weeks | EDITOR | | SPEC | S3 | Update implementations | NA | EDITOR | -| SPEC | **S4** | SPEC adopted | NA | EDITOR | +| SPEC | **S4** | SPEC adopted | NA | EDITOR | \ No newline at end of file From a3d8cc73bf9a1682ae60fd6b295ef4f28450e706 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:25:19 -0300 Subject: [PATCH 09/43] Add html-proofer linking thanks @elichad; closes #535 --- .github/workflows/html-proofer.yml | 48 ++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 .github/workflows/html-proofer.yml diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml new file mode 100644 index 00000000..a60ceaad --- /dev/null +++ b/.github/workflows/html-proofer.yml @@ -0,0 +1,48 @@ +name: "Build and Lint Site" + +on: + push: + branches: ["main"] + pull_request: + branches: ["main"] + +jobs: + build-site: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + fetch-depth: 1 + + # dependencies + - uses: ruby/setup-ruby@v1 + with: + ruby-version: "3.3" + - uses: actions/setup-node@v4 + with: + node-version: "19" + - name: Install dependencies + working-directory: ./docs + run: | + pip install + gem install bundler + bundle config path vendor/bundle + bundle install + + - name: Build the site + working-directory: ./docs + run: bundle exec jekyll build --future --strict_front_matter + + - name: Validate all links, enforce alt text + working-directory: ./docs + run: | + bundle exec htmlproofer --ignore-files "/.*\/specifications\/(0\.[0-9]+|dev)\/.*/,/.*webpack-macros\.html/,/.*\/rfc\/4\/markdown\/.*/,/.*\/rfc\/5\/.*/,/.*\/rfc\/1\/.*/,/.*\/0\.[0-9]+(\.html|\/.*)/,/.*\/ro-crate-preview\.html/,/.*\/examples\/.*\/index\.html/" --disable-external true --enforce-https false --swap-urls '^/ro-crate/:/' ./_site + - name: Ensure no unexpected encoded HTML in output + working-directory: ./docs + run: | + ! fgrep -R 'lt;blockquote' _site + + - name: Ensure no unexpected jekyll in output + working-directory: ./docs + run: | + ! fgrep -R 'site.pages' _site From 62f9f6d7eb6d983c00ef3f8aec753b54a04224f5 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:31:09 -0300 Subject: [PATCH 10/43] adapt html-proofer action to this context --- .github/workflows/html-proofer.yml | 54 +++++++++++++++++++----------- 1 file changed, 34 insertions(+), 20 deletions(-) diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml index a60ceaad..8bedcf03 100644 --- a/.github/workflows/html-proofer.yml +++ b/.github/workflows/html-proofer.yml @@ -1,10 +1,29 @@ name: "Build and Lint Site" on: - push: - branches: ["main"] + workflow_dispatch: pull_request: branches: ["main"] + paths: + - "specifications/**" + - "rfc/**" + - "resources/**" + - "community/**" + - "contributing/**" + - "help-desk/**" + - "_html_extra/**" + - "_static/**" + - "_ext/**" + - "images/**" + - "**/*.md" + - "conf.py" + - "requirements.txt" + - "readthedocs.yml" + - ".github/workflows/build-lint.yml" + +concurrency: + group: build-lint-${{ github.ref }} + cancel-in-progress: true jobs: build-site: @@ -13,36 +32,31 @@ jobs: - uses: actions/checkout@v4 with: fetch-depth: 1 + submodules: recursive # dependencies - uses: ruby/setup-ruby@v1 with: ruby-version: "3.3" + - uses: actions/setup-python@v5 + with: + python-version: "3.13" - uses: actions/setup-node@v4 with: - node-version: "19" + node-version: "22" + - name: Install dependencies - working-directory: ./docs run: | - pip install - gem install bundler - bundle config path vendor/bundle - bundle install + pip install -r requirements.txt + pip install specifications/dev + gem install html-proofer - name: Build the site - working-directory: ./docs - run: bundle exec jekyll build --future --strict_front_matter + run: sphinx-build -b html . _build/html - name: Validate all links, enforce alt text - working-directory: ./docs - run: | - bundle exec htmlproofer --ignore-files "/.*\/specifications\/(0\.[0-9]+|dev)\/.*/,/.*webpack-macros\.html/,/.*\/rfc\/4\/markdown\/.*/,/.*\/rfc\/5\/.*/,/.*\/rfc\/1\/.*/,/.*\/0\.[0-9]+(\.html|\/.*)/,/.*\/ro-crate-preview\.html/,/.*\/examples\/.*\/index\.html/" --disable-external true --enforce-https false --swap-urls '^/ro-crate/:/' ./_site - - name: Ensure no unexpected encoded HTML in output - working-directory: ./docs - run: | - ! fgrep -R 'lt;blockquote' _site + run: htmlproofer --ignore-files "/.*\/specifications\/(0\.[0-9]+|dev)\/.*/,/.*webpack-macros\.html/,/.*\/rfc\/4\/markdown\/.*/,/.*\/rfc\/5\/.*/,/.*\/rfc\/1\/.*/,/.*\/0\.[0-9]+(\.html|\/.*)/" --disable-external ./_build/html - - name: Ensure no unexpected jekyll in output - working-directory: ./docs + - name: Ensure no unexpected encoded HTML in output run: | - ! fgrep -R 'site.pages' _site + ! fgrep -R 'lt;blockquote' _build/html \ No newline at end of file From 2f464c95b6526f88da5ccf9c38136454ef024ca8 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 31 Jul 2026 09:55:13 -0300 Subject: [PATCH 11/43] Add scaffold for topic hub session --- resources/topic-hub/index.md | 7 +++++++ resources/topic-hub/spatial-omics/index.md | 15 +++++++++++++++ resources/topic-hub/wsi/index.md | 19 +++++++++++++++++++ 3 files changed, 41 insertions(+) create mode 100644 resources/topic-hub/index.md create mode 100644 resources/topic-hub/spatial-omics/index.md create mode 100644 resources/topic-hub/wsi/index.md diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md new file mode 100644 index 00000000..0c9b6f66 --- /dev/null +++ b/resources/topic-hub/index.md @@ -0,0 +1,7 @@ +(topic-hub)= + +# Topic Hub + +The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. + +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Light Sheet Microscopy", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md new file mode 100644 index 00000000..fc7f54c4 --- /dev/null +++ b/resources/topic-hub/spatial-omics/index.md @@ -0,0 +1,15 @@ +# Spatial Omics + +The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. + +They all ultimately build upon the OME-NGFF specification, and have the core compatible with the OME-Zarr ecosystem.. + +# Spatial proteomics + +- Meyer-Bender, M., Vöhringer, H., Schniederjohann, C. et al. Spatialproteomics: an interoperable toolbox for analyzing highly multiplexed fluorescence image data. Nat Methods (2026). https://doi.org/10.1038/s41592-026-03155-1 + +An xarray/zarr Python toolkit for multiplexed immunofluorescence, using SpatialData for the underlying data representation, in connection with the [scverse ecosystem](https://scverse.org/). + +- Alexander Coulton, Nicholas McGranahan, Odon: an ultra-fast viewer for spatial proteomics, Bioinformatics, Volume 42, Issue 7, July 2026, btag514, https://doi.org/10.1093/bioinformatics/btag514 + +A viewer for spatial proteomics data built directly for OME-Zarr datasets, with secondary support for SpatialData. diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md new file mode 100644 index 00000000..26dbaa2e --- /dev/null +++ b/resources/topic-hub/wsi/index.md @@ -0,0 +1,19 @@ +# Whole Slide Imaging + +Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. + +- [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html#) + +Storage backed by [SpatialData](https://spatialdata.scverse.org/). + +# Tools + +- [raw2features](https://github.com/CraigMyles/raw2features) + +Utility for generating embeddings from whole slide images saved in OME-Zarr format. + +## See Also + +- [Bringing Open Data to Whole Slide Imaging (Besson et al, 2019.)](https://pmc.ncbi.nlm.nih.gov/articles/PMC6774793/) +- [DICOM WSI](https://dicom.nema.org/dicom/dicomwsi/) +- [WSI on Wikipedia](https://en.wikipedia.org/wiki/Whole_slide_imaging) From 55af941d803596b8228c2fc85130618c83e5d487 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 31 Jul 2026 10:25:34 -0300 Subject: [PATCH 12/43] Add more resources --- resources/topic-hub/dynamics/index.md | 11 +++++++++++ resources/topic-hub/index.md | 2 +- resources/topic-hub/volume-em/index.md | 7 +++++++ resources/topic-hub/wsi/index.md | 18 +++++++++++++----- 4 files changed, 32 insertions(+), 6 deletions(-) create mode 100644 resources/topic-hub/dynamics/index.md create mode 100644 resources/topic-hub/volume-em/index.md diff --git a/resources/topic-hub/dynamics/index.md b/resources/topic-hub/dynamics/index.md new file mode 100644 index 00000000..18713983 --- /dev/null +++ b/resources/topic-hub/dynamics/index.md @@ -0,0 +1,11 @@ +# Dynamics + +OME-Zarr aids large-scale analysis of big data for dynamic processes, e.g. in 5D settings (volumetric, multi-channel time-lapses). + +Here are some resources related to dynamic (i.e. over time) imaging data that take benefit of OME-Zarr and the NGFF. + +## Biohub + +- [Dynamic Cell Atlas](https://chanzuckerberg.github.io/dynamic-cell-atlas-specs/index.html) - A specification for storing dynamic cell atlas data internal to Biohub, building upon OME-Zarr. + +- [Zebrahub – Multimodal Zebrafish Developmental Atlas Reveals the State-Transition Dynamics of Late-Vertebrate Pluripotent Axial Progenitors](https://www.biorxiv.org/content/10.1101/2023.03.06.531398v2) – Data at [Zebrahub Lightsheet Imaging Atlas](https://zebrahub.sf.czbiohub.org/imaging) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index 0c9b6f66..bff64627 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -4,4 +4,4 @@ The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. -It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Light Sheet Microscopy", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md new file mode 100644 index 00000000..de5e3d65 --- /dev/null +++ b/resources/topic-hub/volume-em/index.md @@ -0,0 +1,7 @@ +# Volume EM + +- [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) + +- [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data + +- [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 26dbaa2e..43f25f4a 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -2,17 +2,25 @@ Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. +- [QuPath](https://qupath.github.io/) Open source software for digital pathology image analysis, with support for OME-Zarr. + +## Lazyslide & WSIData + - [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html#) -Storage backed by [SpatialData](https://spatialdata.scverse.org/). +Storage backed by [SpatialData](https://spatialdata.scverse.org/), so OME-NGFF at the core. + +- [LazySlide: Accessible and interoperable whole slide image analysis](https://lazyslide.rtfd.io/) uses WSIData at its core. + +## Other tools -# Tools +- [fastslide](https://github.com/NKI-AI/fastslide) C++20 library for reading whole slide images, including support for OME-Zarr. -- [raw2features](https://github.com/CraigMyles/raw2features) +- [raw2features](https://github.com/CraigMyles/raw2features) Utility for generating embeddings from whole slide images saved in OME-Zarr format. -Utility for generating embeddings from whole slide images saved in OME-Zarr format. +- [kfb2zarr](https://github.com/camlloyd/kfb2zarr) Rust converter for KFBio whole slide images (.kfb, .kfbf) to OME-Zarr -## See Also +## See also - [Bringing Open Data to Whole Slide Imaging (Besson et al, 2019.)](https://pmc.ncbi.nlm.nih.gov/articles/PMC6774793/) - [DICOM WSI](https://dicom.nema.org/dicom/dicomwsi/) From 40dd894661b9068b95b632df8f1f6de120732971 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Mon, 3 Aug 2026 16:00:30 -0300 Subject: [PATCH 13/43] Add Tomography section and index --- resources/topic-hub/dynamics/index.md | 2 ++ resources/topic-hub/index.md | 8 +++++- resources/topic-hub/spatial-omics/index.md | 2 ++ resources/topic-hub/tomography/index.md | 29 ++++++++++++++++++++++ resources/topic-hub/volume-em/index.md | 20 +++++++++++++++ resources/topic-hub/wsi/index.md | 2 ++ 6 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 resources/topic-hub/tomography/index.md diff --git a/resources/topic-hub/dynamics/index.md b/resources/topic-hub/dynamics/index.md index 18713983..5bd86537 100644 --- a/resources/topic-hub/dynamics/index.md +++ b/resources/topic-hub/dynamics/index.md @@ -1,3 +1,5 @@ +(topic-dynamics)= + # Dynamics OME-Zarr aids large-scale analysis of big data for dynamic processes, e.g. in 5D settings (volumetric, multi-channel time-lapses). diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index bff64627..fbeb4c79 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -4,4 +4,10 @@ The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. -It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style: + +- [Volume EM](#topic-volume-em) +- [Whole Slide Imaging](#topic-wsi) +- [Spatial Omics](#topic-spatial-omics) +- [Dynamics](#topic-dynamics) +- [Tomography](#topic-tomography) diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md index fc7f54c4..240ecd6f 100644 --- a/resources/topic-hub/spatial-omics/index.md +++ b/resources/topic-hub/spatial-omics/index.md @@ -1,3 +1,5 @@ +(topic-spatial-omics)= + # Spatial Omics The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. diff --git a/resources/topic-hub/tomography/index.md b/resources/topic-hub/tomography/index.md new file mode 100644 index 00000000..4cf6c10a --- /dev/null +++ b/resources/topic-hub/tomography/index.md @@ -0,0 +1,29 @@ +(topic-tomography)= + +# Tomography (CT) + +While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray tomography, electron tomography, and other non-microscopy imaging modalities. + +The value of the specification includes the metadata for mapping voxels to physical space, and the ability to store large datasets in a chunked and compressed format, with multiscale support, that is suitable for cloud storage and analysis. + +# Example + + + +# Datasets + +- [Herculaneum Scrolls](https://scrollprize.org/) - Scrolls carbonized by Mount Vesuvius eruptions imaged via X-ray micro-CT, made available in OME-Zarr format. ([data](https://registry.opendata.aws/vesuvius-challenge-herculaneum-scrolls/), [source](https://github.com/ScrollPrize/open-data)). Multimillion-dollar awards for teams that "unroll" the scrolls – all starting with processing OME-Zarr data. + +- [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) + +- [VoDaSuRe](https://augusthoeg.github.io/VoDaSuRe/) - A large-scale dataset covering volumetric super-resolution data with micro-CT ([arXiv](https://arxiv.org/abs/2603.23153); [dataset](https://huggingface.co/datasets/AugustHoeg/VoDaSuRe)) + +# Tools + +Tools that work on 3D volumetric data (like CT-scans) are sometimes developed for 3D microscopy, but natively work for visualizing other 3D data, such as tomography images: + +- [VolE](https://vole.allencell.org/) - Allen Institute for Cell Science's viewer for large-scale volumetric datasets, with native support for OME-Zarr. + +- [WebKnossos](https://webknossos.org/) - A web-based platform for visualizing, annotating, and sharing large-scale volumetric datasets. + +- [Neuroglancer](https://github.com/google/neuroglancer) - Google's WebGL-based viewer for volumetric data, with first class support for OME-Zarr. diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index de5e3d65..ef9bc530 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -1,7 +1,27 @@ +(topic-volume-em)= + # Volume EM +Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging large volumes of biological samples at high resolution. The OME-NGFF specification caters for this kind of big data nicely, and there are a number of resources that build upon OME-Zarr to provide additional support for vEM data. + +## Tools + +- [WebKnossos](https://webknossos.org/) - A web-based platform for visualizing, annotating, and sharing large-scale volumetric datasets. It has native support for OME-Zarr and is [widely used in the vEM community](https://home.webknossos.org/use-cases/volume-em). + +- [VolE](https://vole.allencell.org/) - Allen Institute for Cell Science's viewer for large-scale volumetric datasets, with native support for OME-Zarr. + +- [Neuroglancer](https://github.com/google/neuroglancer) - Google's WebGL-based viewer for volumetric data, with first class support for OME-Zarr. + +- [SyGlass](https://www.syglass.io/science) - A proprietary virtual reality platform for visualizing and analyzing large-scale volumetric datasets, with support for OME-Zarr. + +## Other + +- [WebKnossos Zarr Gallary](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. + - [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) - [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data - [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) + +- [Cryo-ET](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 43f25f4a..61c65e35 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -1,3 +1,5 @@ +(topic-wsi)= + # Whole Slide Imaging Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. From d566d6bf00b1e52fd8c68fde48b674fc2fbd309a Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Mon, 3 Aug 2026 16:11:16 -0300 Subject: [PATCH 14/43] fix: Fix typo --- resources/topic-hub/volume-em/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index ef9bc530..58c7611c 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -16,7 +16,7 @@ Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging la ## Other -- [WebKnossos Zarr Gallary](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. +- [WebKnossos Zarr Gallery](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. - [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) From 5ad42cf00dcbbbec06714cb9540bfbc97d4acfe9 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 4 Aug 2026 16:09:30 -0300 Subject: [PATCH 15/43] docs: add CryoET to topic-hub Thank you @uermel --- resources/topic-hub/cryo-et/index.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 resources/topic-hub/cryo-et/index.md diff --git a/resources/topic-hub/cryo-et/index.md b/resources/topic-hub/cryo-et/index.md new file mode 100644 index 00000000..c5e150d4 --- /dev/null +++ b/resources/topic-hub/cryo-et/index.md @@ -0,0 +1,21 @@ +# Cryo-ET + +Cryogenic electron tomography (cryo-ET) sits between single particle cryo-EM and volume EM. Cryo-ET involves the collection of tilt series of images from vitrified samples, which are then computationally reconstructed into 3D volumes. + +Here are some resources in the intersection of cryo-ET and OME-Zarr. + +## Tools + +- [ChimeraX OME-Zarr](https://github.com/uermel/chimerax-ome-zarr) - A plugin for [ChimeraX](https://www.cgl.ucsf.edu/chimerax/) to read and visualize OME-Zarr datasets designed for cryo-ET data. + +- [copick](https://copick.github.io/copick/) - CryoET annotation framework built upon OME-Zarr data. [[paper](https://onlinelibrary.wiley.com/doi/10.1002/pro.70578)] + +- [zarr-particle-tools](https://github.com/czimaginginstitute/zarr-particle-tools) - CryoET data analysis package (subtomogram averaging) based on OME-Zarr + +## Data + +- [Cryo-ET Data Portal](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). [[paper](https://www.nature.com/articles/s41592-024-02477-2)] + +## Other + +- [Cryo-ET Object Identification Kaggle Challenge](https://www.kaggle.com/competitions/czii-cryo-et-object-identification) - Kaggle competition for cryo-ET object identification, with OME-Zarr datasets. From 4e78a4f22603b66e20bd3d8801e959c9092c9f5c Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 4 Aug 2026 16:10:45 -0300 Subject: [PATCH 16/43] docs: add cryo-et to the index --- resources/topic-hub/cryo-et/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/resources/topic-hub/cryo-et/index.md b/resources/topic-hub/cryo-et/index.md index c5e150d4..29eb362c 100644 --- a/resources/topic-hub/cryo-et/index.md +++ b/resources/topic-hub/cryo-et/index.md @@ -1,3 +1,5 @@ +(#topic-cryo-et)= + # Cryo-ET Cryogenic electron tomography (cryo-ET) sits between single particle cryo-EM and volume EM. Cryo-ET involves the collection of tilt series of images from vitrified samples, which are then computationally reconstructed into 3D volumes. From 205d3780293ece2651b2b0813348fc9785a26e34 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 10:24:10 -0300 Subject: [PATCH 17/43] Add CryoET to index, remove it from vEM Thanks @uermel! --- resources/topic-hub/index.md | 1 + resources/topic-hub/volume-em/index.md | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index fbeb4c79..42e66b50 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -7,6 +7,7 @@ The Topic Hub is a collection of resources particular to the intersection of NGF It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style: - [Volume EM](#topic-volume-em) +- [CryoET](#topic-cryoet) - [Whole Slide Imaging](#topic-wsi) - [Spatial Omics](#topic-spatial-omics) - [Dynamics](#topic-dynamics) diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index 58c7611c..bbb28148 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -23,5 +23,3 @@ Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging la - [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data - [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) - -- [Cryo-ET](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). From 788ed28024c3f2ab6ffb3300b934d82e7f6f8452 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 10:41:05 -0300 Subject: [PATCH 18/43] Add spora suite to the topic-hub (spatial proteomics) closes #579 --- resources/topic-hub/spatial-omics/index.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md index 240ecd6f..19bde65f 100644 --- a/resources/topic-hub/spatial-omics/index.md +++ b/resources/topic-hub/spatial-omics/index.md @@ -2,12 +2,24 @@ # Spatial Omics -The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. - -They all ultimately build upon the OME-NGFF specification, and have the core compatible with the OME-Zarr ecosystem.. +The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build either on OME-Zarr directly or upon SpatialData. # Spatial proteomics +## spora ecosystem + +A suite of resources for spatial proteomics that use OME-Zarr at multiple levels. Includes: + +* [A spora data formats specification](https://spora.epfl.ch/docs-data.html) used to harmonize datasets. + +In short, it stores structured tabular data as `.parquet`, all whole-slide images as `.ome.zarr`, and segmentation masks as `.npz`. + +* [spora[data]](https://spora.epfl.ch/datasets.html) a resource containing multiple harmonized spatial proteomics datasets +* [spora [io]](https://github.com/bunnelab/spora-io) a Python library for accessing spora datasets +* Wenckstern, J., Jain, E., von Querfurth, B. et al. The Virtual Tissues foundation model resolves spatial proteomics across scales. Nature (2026). https://doi.org/10.1038/s41586-026-10884-y ([github repo](https://github.com/bunnelab/virtues#datasets)) + +## other + - Meyer-Bender, M., Vöhringer, H., Schniederjohann, C. et al. Spatialproteomics: an interoperable toolbox for analyzing highly multiplexed fluorescence image data. Nat Methods (2026). https://doi.org/10.1038/s41592-026-03155-1 An xarray/zarr Python toolkit for multiplexed immunofluorescence, using SpatialData for the underlying data representation, in connection with the [scverse ecosystem](https://scverse.org/). From d061e48f911325504a41b2ca42d186ff6cc878ea Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:05:50 -0300 Subject: [PATCH 19/43] add HCS page --- resources/topic-hub/hcs/index.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 resources/topic-hub/hcs/index.md diff --git a/resources/topic-hub/hcs/index.md b/resources/topic-hub/hcs/index.md new file mode 100644 index 00000000..1a55aee8 --- /dev/null +++ b/resources/topic-hub/hcs/index.md @@ -0,0 +1,9 @@ +(topic-hcs)= + +# High Content Screening + +High Content Screening (HCS) workflows record images for multiple conditions at the same time, often in multi-well plates. The OME-TIFF specification provided first-class support for HCS, and the OME-Zarr addressed HCS needs early on. With a [dedicated specification for plates and wells](https://ngff.openmicroscopy.org/0.5/#hcs-layout). + +- The [Fractal analytics framework](https://fractal-analytics-platform.github.io/) for large scale processing with OME-Zarr has multiple [workflows to analyse HCS data](https://fractal-analytics-platform.github.io/fractal_tasks/) ([preprint](https://www.biorxiv.org/content/10.64898/2026.03.05.709921v1.full)). + +- Massei, R., Busch, W., Serrano-Solano, B. et al. High-content screening (HCS) workflows for FAIR image data management with OMERO. Sci Rep 15, 16236 (2025). https://doi.org/10.1038/s41598-025-00720-0 From 96398b6a06138aab4de26a5d0d10f8814c74855d Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:06:15 -0300 Subject: [PATCH 20/43] fix typos and details in pages for ct-scan and wsi --- resources/topic-hub/tomography/index.md | 6 ++++-- resources/topic-hub/wsi/index.md | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/resources/topic-hub/tomography/index.md b/resources/topic-hub/tomography/index.md index 4cf6c10a..dbc63f7a 100644 --- a/resources/topic-hub/tomography/index.md +++ b/resources/topic-hub/tomography/index.md @@ -1,8 +1,8 @@ (topic-tomography)= -# Tomography (CT) +# Computed Tomography (CT) -While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray tomography, electron tomography, and other non-microscopy imaging modalities. +While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray computed tomography (CT-scan). The value of the specification includes the metadata for mapping voxels to physical space, and the ability to store large datasets in a chunked and compressed format, with multiscale support, that is suitable for cloud storage and analysis. @@ -12,6 +12,8 @@ The value of the specification includes the metadata for mapping voxels to physi # Datasets +- [The Human Organ Atlas](https://human-organ-atlas.esrf.fr/) - Human organs scanned with Hierarchical Phase-Contrast Tomography (HiP-CT) made available in the OME-Zarr format ([paper](https://www.science.org/doi/10.1126/sciadv.adz2240)). + - [Herculaneum Scrolls](https://scrollprize.org/) - Scrolls carbonized by Mount Vesuvius eruptions imaged via X-ray micro-CT, made available in OME-Zarr format. ([data](https://registry.opendata.aws/vesuvius-challenge-herculaneum-scrolls/), [source](https://github.com/ScrollPrize/open-data)). Multimillion-dollar awards for teams that "unroll" the scrolls – all starting with processing OME-Zarr data. - [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 61c65e35..b6f70c58 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -2,9 +2,9 @@ # Whole Slide Imaging -Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. +Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. Many of the examples come from the digital pathology community, but OME-Zarr may be used for other whole slide imaging applications. -- [QuPath](https://qupath.github.io/) Open source software for digital pathology image analysis, with support for OME-Zarr. +- [QuPath](https://qupath.github.io/) - Open source software for digital pathology image analysis, with support for OME-Zarr. ## Lazyslide & WSIData From b41fbf43789a0aad76fe1e207380cec1870f16b2 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:07:22 -0300 Subject: [PATCH 21/43] Add HCS to the topic hub index --- resources/topic-hub/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index 42e66b50..b7db23d7 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -8,6 +8,7 @@ It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and - [Volume EM](#topic-volume-em) - [CryoET](#topic-cryoet) +- [High-Content Screening](#topic-hcs) - [Whole Slide Imaging](#topic-wsi) - [Spatial Omics](#topic-spatial-omics) - [Dynamics](#topic-dynamics) From c2cf2235dc382449d322851a13d014572332d25c Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 28 Jul 2026 11:54:39 -0300 Subject: [PATCH 22/43] fix broken links in a-z --- help-desk/index.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/help-desk/index.md b/help-desk/index.md index c3567770..af1e3225 100644 --- a/help-desk/index.md +++ b/help-desk/index.md @@ -212,7 +212,10 @@ That is often the case. OME-Zarr include multiresolution data (i.e. pyramids), w Not yet fully. Some workarounds are possible (1D arrays, mesh formats), but this is an active area of development. +<<<<<<< HEAD (where-to-seek-for-help)= +======= +>>>>>>> 87eb2e6 (fix broken links in a-z) ## Where to look for help If you have questions or need help with OME-Zarr, you can reach out through the following channels: From ad7e388989cc9fc3008200d800db86d4b5f3e8ce Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:24:01 -0300 Subject: [PATCH 23/43] fix internal links and anchors --- resources/rfc-status-codes/index.md | 17 +++------ rfc/3/versions/2026-07-17/index.md | 59 +++++++++++++---------------- 2 files changed, 33 insertions(+), 43 deletions(-) diff --git a/resources/rfc-status-codes/index.md b/resources/rfc-status-codes/index.md index 7f487f04..22c26a43 100644 --- a/resources/rfc-status-codes/index.md +++ b/resources/rfc-status-codes/index.md @@ -1,18 +1,13 @@ -RFC status codes -============ - - -[RFC 1](#rfcs:rfc1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. +# RFC status codes +[RFC 1](#rfc-1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. ![State diagram of the RFC process](../../rfc/1/diagram.png) -This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. +This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. The status codes indicating ends of an RFC process are outlined in **bold**. -Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. - - +Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. | Phase | Code | Description | Wait time | Action by | | ----- | ------ | --------------------------------------------------------------------------------------------------- | --------------- | ----------------- | @@ -26,7 +21,7 @@ Wait times provide a sense on how fast the process is expected to move to the ne | RFC | R2 | REVIEWERS submit REVIEWS with recommendations as new PRs. | NA | REVIEWER + EDITOR | | RFC | R3 | EDITORS merge REVIEWS and send to AUTHOR for RESPONSE | NA | AUTHOR + EDITOR | | RFC | R4 | AUTHORS prepare RESPONSE and changes to RFC | NA | AUTHOR | -| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | +| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | | RFC | R6 | REVIEWERS approve? | NA | REVIEWER | | RFC | R7 | If no, EDITORS approve? | NA | EDITOR | | RFC | R8 | If changes necessary, AUTHORS prepare changes to RFC and/or RESPONSE. If they are major, back to R1 | NA | AUTHOR | @@ -35,4 +30,4 @@ Wait times provide a sense on how fast the process is expected to move to the ne | SPEC | S1 | RFC accepted! AUTHORS or EDITORS update the SPEC | NA | AUTHOR + EDITOR | | SPEC | S2 | Clarifications needed? | If yes, 4 weeks | EDITOR | | SPEC | S3 | Update implementations | NA | EDITOR | -| SPEC | **S4** | SPEC adopted | NA | EDITOR | \ No newline at end of file +| SPEC | **S4** | SPEC adopted | NA | EDITOR | diff --git a/rfc/3/versions/2026-07-17/index.md b/rfc/3/versions/2026-07-17/index.md index 074f3043..78178c27 100644 --- a/rfc/3/versions/2026-07-17/index.md +++ b/rfc/3/versions/2026-07-17/index.md @@ -109,7 +109,7 @@ conversion of proprietary datasets, usage by microscope vendors[^1], and usage by novel microscopy modalities[^2]. This RFC removes these restrictions, opening NGFF to many more users within its -target domain (and beyond). Because it *only* removes restrictions, existing +target domain (and beyond). Because it _only_ removes restrictions, existing valid OME-Zarr datasets will remain valid after implementation of this proposal. @@ -144,7 +144,6 @@ and, > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. - and, > - Every Zarr array referred to by a `path` MUST have the same number of @@ -158,9 +157,9 @@ hamper the adoption of OME-Zarr as an acquisition-time format due to performance concerns: many acquisitions happen in TZCYX order (all channels are acquired together for each z-slice), which violates the "axes must be ordered by type" requirement. In such cases, scientists must first acquire their data -and *then* transpose it — an expensive proposition for large datasets. (Note: +and _then_ transpose it — an expensive proposition for large datasets. (Note: Admittedly, Zarr transpose codecs, as well as the mapAxis transformation from -RFC-5, already offer solutions to this problem. However, the *simplest* +RFC-5, already offer solutions to this problem. However, the _simplest_ solution of flexible array ordering with default codecs and only scale and translation transforms is only open after this RFC.) @@ -219,7 +218,7 @@ important part of data quality checks. Currently, this kind of microscopy data cannot be stored in OME-Zarr. Within the same workflow, the crystal orientation is usually encoded as three -*Euler angles* or four *quaternion* components stored at each pixel position. +_Euler angles_ or four _quaternion_ components stored at each pixel position. Although it's possible to use the "custom" axis for this purpose, a dedicated axis with a clear naming convention is more ergonomic for scientists. @@ -241,17 +240,17 @@ to save these intermediate image products for later reprocessing. ### Overlapping labels -OME-Zarr can represent not only raw images, but also *label images*, or +OME-Zarr can represent not only raw images, but also _label images_, or segmentations. Traditionally, segmentations assigned a single integer value to each pixel in the source image. However, newer segmentation methods produce -*coarse-to-fine* segmentations, with semantic meaning. For images spanning many +_coarse-to-fine_ segmentations, with semantic meaning. For images spanning many scales, as produced by modern microscopes, we may want to segment tissues, cells within those tissues, and organelles within those cells. These three levels of segmentations can be stacked along a new "coarseness" axis. -Similarly, new segmentation methods can produce *overlapping binary masks*. Due -to the overlap, they *cannot* be stored as traditional integer masks (one value -per pixel), but are typically instead stored as *n* boolean masks. For this +Similarly, new segmentation methods can produce _overlapping binary masks_. Due +to the overlap, they _cannot_ be stored as traditional integer masks (one value +per pixel), but are typically instead stored as _n_ boolean masks. For this mask, an extra "instance" axis is needed in addition to the [TCZ]YX axes of a source image. @@ -290,7 +289,8 @@ After this specification change, tools may encounter OME-Zarr files that don't match the earlier expectations of containing a subset of the TCZYX axes. This proposal is agnostic as to what to do in those situations, and indeed the appropriate action depends on the tool, but some suggestions include: -- fail with an informative error message. (i.e. *partial* implementations are + +- fail with an informative error message. (i.e. _partial_ implementations are OK, especially if well-documented.) - prompt the user about which axes to treat as spatial. - arbitrarily choose which axes to treat as spatial. @@ -304,36 +304,31 @@ document, taking as base the current development version: > - The length of `axes` must be between 2 and 5 and MUST be equal to the > dimensionality of the Zarr arrays storing the image data (see > `datasets:path`). -> > - `axes` MUST contain 2 or 3 entries of `type:space` -> > - `axes` MAY contain one additional entry of `type:time` -> > - `axes` MAY contain one additional entry of `type:channel` or a null / > custom type. -> > - `axes` entries MUST be ordered by `type` where the `time` axis must come > first (if present), followed by the `channel` or custom axis (if present) > and the axes of type `space`. -> > - If there are three spatial axes where two correspond to the image plane > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. -2. The following lines are *added* to "multiscales metadata": +2. The following lines are _added_ to "multiscales metadata": > 0. The length of the axis names MUST match the number of axes of the array. -> 1. *If* a dataset contains exactly 2 spatial dimensions, those dimensions +> 1. _If_ a dataset contains exactly 2 spatial dimensions, those dimensions > SHOULD be named `y` and `x`, except where rule 4 applies. -> 2. *If* a dataset contains exactly 3 spatial dimensions, those dimensions +> 2. _If_ a dataset contains exactly 3 spatial dimensions, those dimensions > SHOULD be named 'z', 'y', and 'x', except where rule 4 applies. -> 3. *If* a dataset contains exactly 1 time dimension, it should be named `t`. +> 3. _If_ a dataset contains exactly 1 time dimension, it should be named `t`. > 4. When image data axes map straightforwardly to axes with common names in > the relevant field of practice, those axes SHOULD be named according to > such conventions. For example, spatial frequency axes resulting from a > Fourier transformation of `z', 'y', and 'x' SHOULD be named 'w', 'v', and -> `u`, respectively. Similarly, a temporal frequency axis resulting from -> a Fourier transformation of the `t` axis SHOULD be named `w` or `ω`. +`u`, respectively. Similarly, a temporal frequency axis resulting from +a Fourier transformation of the `t`axis SHOULD be named`w`or`ω`. > 5. Axis names MUST NOT be repeated within a dataset, and SHOULD NOT be > different only by upper/lower-case. For example, the same dataset SHOULD > NOT have both an `X` and an `x` axis. @@ -370,7 +365,7 @@ the RFC. Developers of visualization libraries and software are concerned that this PR may result in a "wild west" of OME-Zarr datasets that have little in common, -making it difficult for tools to decide *which* axes to display. More details +making it difficult for tools to decide _which_ axes to display. More details about these concerns are developed below in the "Drawbacks" section. ## Backwards Compatibility @@ -426,21 +421,21 @@ have assuaged most implementation concerns][recap comment]. ## Performance The current OME-Zarr specification ensures arrays are stored in order TCZYX. -With C-order array data, this ensures efficient access for *some* but not *all* +With C-order array data, this ensures efficient access for _some_ but not _all_ access patterns. By removing restrictions on axis orderings, a new class of "mistake" is possible, as someone could save an array in order XYTCZ, which would combine poorly with C-order arrays to view XY planes. However, it is -arguable that Zarr chunking is in fact more important here — XYTCZ *could* be +arguable that Zarr chunking is in fact more important here — XYTCZ _could_ be a perfectly cromulent axis ordering for XY planes if the Zarr chunk size was (1024, 1024, 1, 1, 1). Moreover, imposing a fixed axis ordering can incur performance penalties at -*write* time (where performance is often critical) if the data is not already +_write_ time (where performance is often critical) if the data is not already in the expected order. Therefore, this proposal argues that any performance implications are better addressed through good documentation and good defaults. Indeed, more flexible -dimension ordering could *improve* performance in some scenarios, such as +dimension ordering could _improve_ performance in some scenarios, such as "pixel drilling", that is, extracting the value of a single x/y position over time. @@ -475,7 +470,6 @@ an informative error message (e.g. "The given dataset contains an unknown axis This RFC is placed in the public domain. - [nat methods paper]: https://www.nature.com/articles/s41592-021-01326-w [ome-model]: https://github.com/ome/ngff/pull/239/files#r1609781780 [ngff 0.4]: https://ngff.openmicroscopy.org/specifications/0.4/index.html @@ -502,11 +496,12 @@ This RFC is placed in the public domain. [zulip-rfc-3-thread]: https://imagesc.zulipchat.com/#narrow/channel/328251-NGFF/topic/RFC-3.3A.20remove.20dimension.20restrictions/near/568178521 [^1]: https://github.com/ome/ngff/pull/239#issuecomment-2122809286 + [^2]: https://github.com/ome/ngff/pull/239#issuecomment-2149119404 ## Changelog -| Date | Description | Link | -| ---------- | ---------------------------- | ---------------------------------------------------------------------------- | -| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | -| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | +| Date | Description | Link | +| ---------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | +| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | +| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | From bb7fcfd0903007e8dc2e5fccfe5094e55ca7a404 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:24:12 -0300 Subject: [PATCH 24/43] fix link to rfc1 --- resources/rfc-status-codes/index.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/resources/rfc-status-codes/index.md b/resources/rfc-status-codes/index.md index 22c26a43..7f487f04 100644 --- a/resources/rfc-status-codes/index.md +++ b/resources/rfc-status-codes/index.md @@ -1,13 +1,18 @@ -# RFC status codes +RFC status codes +============ + + +[RFC 1](#rfcs:rfc1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. -[RFC 1](#rfc-1) defined a Request for Comments process for the NGFF community, which is used to drive changes. The text listed a set of codes used to define how a change progresses from an idea to actual adoption. ![State diagram of the RFC process](../../rfc/1/diagram.png) -This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. +This resource is a (non-normative) table describing the different codes used in that specification that outline the states of the RFCs. It is _not_ a full description of the RFC process. The status codes indicating ends of an RFC process are outlined in **bold**. -Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. +Wait times provide a sense on how fast the process is expected to move to the next phase. The actual time may vary in practice, given factors such as the time of the year and current capacity. + + | Phase | Code | Description | Wait time | Action by | | ----- | ------ | --------------------------------------------------------------------------------------------------- | --------------- | ----------------- | @@ -21,7 +26,7 @@ Wait times provide a sense on how fast the process is expected to move to the ne | RFC | R2 | REVIEWERS submit REVIEWS with recommendations as new PRs. | NA | REVIEWER + EDITOR | | RFC | R3 | EDITORS merge REVIEWS and send to AUTHOR for RESPONSE | NA | AUTHOR + EDITOR | | RFC | R4 | AUTHORS prepare RESPONSE and changes to RFC | NA | AUTHOR | -| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | +| RFC | R5 | EDITORS merge RESPONSE and changes to RFC, contacts REVIEWERS | 2 weeks | REVIEWER + EDITOR | | RFC | R6 | REVIEWERS approve? | NA | REVIEWER | | RFC | R7 | If no, EDITORS approve? | NA | EDITOR | | RFC | R8 | If changes necessary, AUTHORS prepare changes to RFC and/or RESPONSE. If they are major, back to R1 | NA | AUTHOR | @@ -30,4 +35,4 @@ Wait times provide a sense on how fast the process is expected to move to the ne | SPEC | S1 | RFC accepted! AUTHORS or EDITORS update the SPEC | NA | AUTHOR + EDITOR | | SPEC | S2 | Clarifications needed? | If yes, 4 weeks | EDITOR | | SPEC | S3 | Update implementations | NA | EDITOR | -| SPEC | **S4** | SPEC adopted | NA | EDITOR | +| SPEC | **S4** | SPEC adopted | NA | EDITOR | \ No newline at end of file From 2a3da8b7d42a3962981a92c0f25ba069eed12681 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:25:19 -0300 Subject: [PATCH 25/43] Add html-proofer linking thanks @elichad; closes #535 --- .github/workflows/html-proofer.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml index 8bedcf03..779f2f17 100644 --- a/.github/workflows/html-proofer.yml +++ b/.github/workflows/html-proofer.yml @@ -59,4 +59,4 @@ jobs: - name: Ensure no unexpected encoded HTML in output run: | - ! fgrep -R 'lt;blockquote' _build/html \ No newline at end of file + ! fgrep -R 'lt;blockquote' _build/html From f5250b1c34b67d4640407ac1dd9ad71ccbf0b747 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Wed, 29 Jul 2026 09:31:09 -0300 Subject: [PATCH 26/43] adapt html-proofer action to this context --- .github/workflows/html-proofer.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml index 779f2f17..0bc69355 100644 --- a/.github/workflows/html-proofer.yml +++ b/.github/workflows/html-proofer.yml @@ -59,4 +59,8 @@ jobs: - name: Ensure no unexpected encoded HTML in output run: | +<<<<<<< HEAD ! fgrep -R 'lt;blockquote' _build/html +======= + ! fgrep -R 'lt;blockquote' _build/html +>>>>>>> 62f9f6d (adapt html-proofer action to this context) From 8f6065042ad90e7cab12845c4bbba405dcc1c34b Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 31 Jul 2026 09:55:13 -0300 Subject: [PATCH 27/43] Add scaffold for topic hub session --- resources/topic-hub/index.md | 7 +++++++ resources/topic-hub/spatial-omics/index.md | 15 +++++++++++++++ resources/topic-hub/wsi/index.md | 19 +++++++++++++++++++ 3 files changed, 41 insertions(+) create mode 100644 resources/topic-hub/index.md create mode 100644 resources/topic-hub/spatial-omics/index.md create mode 100644 resources/topic-hub/wsi/index.md diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md new file mode 100644 index 00000000..0c9b6f66 --- /dev/null +++ b/resources/topic-hub/index.md @@ -0,0 +1,7 @@ +(topic-hub)= + +# Topic Hub + +The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. + +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Light Sheet Microscopy", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md new file mode 100644 index 00000000..fc7f54c4 --- /dev/null +++ b/resources/topic-hub/spatial-omics/index.md @@ -0,0 +1,15 @@ +# Spatial Omics + +The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. + +They all ultimately build upon the OME-NGFF specification, and have the core compatible with the OME-Zarr ecosystem.. + +# Spatial proteomics + +- Meyer-Bender, M., Vöhringer, H., Schniederjohann, C. et al. Spatialproteomics: an interoperable toolbox for analyzing highly multiplexed fluorescence image data. Nat Methods (2026). https://doi.org/10.1038/s41592-026-03155-1 + +An xarray/zarr Python toolkit for multiplexed immunofluorescence, using SpatialData for the underlying data representation, in connection with the [scverse ecosystem](https://scverse.org/). + +- Alexander Coulton, Nicholas McGranahan, Odon: an ultra-fast viewer for spatial proteomics, Bioinformatics, Volume 42, Issue 7, July 2026, btag514, https://doi.org/10.1093/bioinformatics/btag514 + +A viewer for spatial proteomics data built directly for OME-Zarr datasets, with secondary support for SpatialData. diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md new file mode 100644 index 00000000..26dbaa2e --- /dev/null +++ b/resources/topic-hub/wsi/index.md @@ -0,0 +1,19 @@ +# Whole Slide Imaging + +Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. + +- [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html#) + +Storage backed by [SpatialData](https://spatialdata.scverse.org/). + +# Tools + +- [raw2features](https://github.com/CraigMyles/raw2features) + +Utility for generating embeddings from whole slide images saved in OME-Zarr format. + +## See Also + +- [Bringing Open Data to Whole Slide Imaging (Besson et al, 2019.)](https://pmc.ncbi.nlm.nih.gov/articles/PMC6774793/) +- [DICOM WSI](https://dicom.nema.org/dicom/dicomwsi/) +- [WSI on Wikipedia](https://en.wikipedia.org/wiki/Whole_slide_imaging) From c9cb193e9e844da383e91d4a476394befa6075de Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 31 Jul 2026 10:25:34 -0300 Subject: [PATCH 28/43] Add more resources --- resources/topic-hub/dynamics/index.md | 11 +++++++++++ resources/topic-hub/index.md | 2 +- resources/topic-hub/volume-em/index.md | 7 +++++++ resources/topic-hub/wsi/index.md | 18 +++++++++++++----- 4 files changed, 32 insertions(+), 6 deletions(-) create mode 100644 resources/topic-hub/dynamics/index.md create mode 100644 resources/topic-hub/volume-em/index.md diff --git a/resources/topic-hub/dynamics/index.md b/resources/topic-hub/dynamics/index.md new file mode 100644 index 00000000..18713983 --- /dev/null +++ b/resources/topic-hub/dynamics/index.md @@ -0,0 +1,11 @@ +# Dynamics + +OME-Zarr aids large-scale analysis of big data for dynamic processes, e.g. in 5D settings (volumetric, multi-channel time-lapses). + +Here are some resources related to dynamic (i.e. over time) imaging data that take benefit of OME-Zarr and the NGFF. + +## Biohub + +- [Dynamic Cell Atlas](https://chanzuckerberg.github.io/dynamic-cell-atlas-specs/index.html) - A specification for storing dynamic cell atlas data internal to Biohub, building upon OME-Zarr. + +- [Zebrahub – Multimodal Zebrafish Developmental Atlas Reveals the State-Transition Dynamics of Late-Vertebrate Pluripotent Axial Progenitors](https://www.biorxiv.org/content/10.1101/2023.03.06.531398v2) – Data at [Zebrahub Lightsheet Imaging Atlas](https://zebrahub.sf.czbiohub.org/imaging) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index 0c9b6f66..bff64627 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -4,4 +4,4 @@ The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. -It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Light Sheet Microscopy", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md new file mode 100644 index 00000000..de5e3d65 --- /dev/null +++ b/resources/topic-hub/volume-em/index.md @@ -0,0 +1,7 @@ +# Volume EM + +- [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) + +- [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data + +- [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 26dbaa2e..43f25f4a 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -2,17 +2,25 @@ Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. +- [QuPath](https://qupath.github.io/) Open source software for digital pathology image analysis, with support for OME-Zarr. + +## Lazyslide & WSIData + - [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html#) -Storage backed by [SpatialData](https://spatialdata.scverse.org/). +Storage backed by [SpatialData](https://spatialdata.scverse.org/), so OME-NGFF at the core. + +- [LazySlide: Accessible and interoperable whole slide image analysis](https://lazyslide.rtfd.io/) uses WSIData at its core. + +## Other tools -# Tools +- [fastslide](https://github.com/NKI-AI/fastslide) C++20 library for reading whole slide images, including support for OME-Zarr. -- [raw2features](https://github.com/CraigMyles/raw2features) +- [raw2features](https://github.com/CraigMyles/raw2features) Utility for generating embeddings from whole slide images saved in OME-Zarr format. -Utility for generating embeddings from whole slide images saved in OME-Zarr format. +- [kfb2zarr](https://github.com/camlloyd/kfb2zarr) Rust converter for KFBio whole slide images (.kfb, .kfbf) to OME-Zarr -## See Also +## See also - [Bringing Open Data to Whole Slide Imaging (Besson et al, 2019.)](https://pmc.ncbi.nlm.nih.gov/articles/PMC6774793/) - [DICOM WSI](https://dicom.nema.org/dicom/dicomwsi/) From 4ab3f2c6f04e140f3f2c1aea1fed867cf1c04b74 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Mon, 3 Aug 2026 16:00:30 -0300 Subject: [PATCH 29/43] Add Tomography section and index --- resources/topic-hub/dynamics/index.md | 2 ++ resources/topic-hub/index.md | 8 +++++- resources/topic-hub/spatial-omics/index.md | 2 ++ resources/topic-hub/tomography/index.md | 29 ++++++++++++++++++++++ resources/topic-hub/volume-em/index.md | 20 +++++++++++++++ resources/topic-hub/wsi/index.md | 2 ++ 6 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 resources/topic-hub/tomography/index.md diff --git a/resources/topic-hub/dynamics/index.md b/resources/topic-hub/dynamics/index.md index 18713983..5bd86537 100644 --- a/resources/topic-hub/dynamics/index.md +++ b/resources/topic-hub/dynamics/index.md @@ -1,3 +1,5 @@ +(topic-dynamics)= + # Dynamics OME-Zarr aids large-scale analysis of big data for dynamic processes, e.g. in 5D settings (volumetric, multi-channel time-lapses). diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index bff64627..fbeb4c79 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -4,4 +4,10 @@ The Topic Hub is a collection of resources particular to the intersection of NGFF and particular topical communities. -It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style. +It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style: + +- [Volume EM](#topic-volume-em) +- [Whole Slide Imaging](#topic-wsi) +- [Spatial Omics](#topic-spatial-omics) +- [Dynamics](#topic-dynamics) +- [Tomography](#topic-tomography) diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md index fc7f54c4..240ecd6f 100644 --- a/resources/topic-hub/spatial-omics/index.md +++ b/resources/topic-hub/spatial-omics/index.md @@ -1,3 +1,5 @@ +(topic-spatial-omics)= + # Spatial Omics The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. diff --git a/resources/topic-hub/tomography/index.md b/resources/topic-hub/tomography/index.md new file mode 100644 index 00000000..4cf6c10a --- /dev/null +++ b/resources/topic-hub/tomography/index.md @@ -0,0 +1,29 @@ +(topic-tomography)= + +# Tomography (CT) + +While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray tomography, electron tomography, and other non-microscopy imaging modalities. + +The value of the specification includes the metadata for mapping voxels to physical space, and the ability to store large datasets in a chunked and compressed format, with multiscale support, that is suitable for cloud storage and analysis. + +# Example + + + +# Datasets + +- [Herculaneum Scrolls](https://scrollprize.org/) - Scrolls carbonized by Mount Vesuvius eruptions imaged via X-ray micro-CT, made available in OME-Zarr format. ([data](https://registry.opendata.aws/vesuvius-challenge-herculaneum-scrolls/), [source](https://github.com/ScrollPrize/open-data)). Multimillion-dollar awards for teams that "unroll" the scrolls – all starting with processing OME-Zarr data. + +- [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) + +- [VoDaSuRe](https://augusthoeg.github.io/VoDaSuRe/) - A large-scale dataset covering volumetric super-resolution data with micro-CT ([arXiv](https://arxiv.org/abs/2603.23153); [dataset](https://huggingface.co/datasets/AugustHoeg/VoDaSuRe)) + +# Tools + +Tools that work on 3D volumetric data (like CT-scans) are sometimes developed for 3D microscopy, but natively work for visualizing other 3D data, such as tomography images: + +- [VolE](https://vole.allencell.org/) - Allen Institute for Cell Science's viewer for large-scale volumetric datasets, with native support for OME-Zarr. + +- [WebKnossos](https://webknossos.org/) - A web-based platform for visualizing, annotating, and sharing large-scale volumetric datasets. + +- [Neuroglancer](https://github.com/google/neuroglancer) - Google's WebGL-based viewer for volumetric data, with first class support for OME-Zarr. diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index de5e3d65..ef9bc530 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -1,7 +1,27 @@ +(topic-volume-em)= + # Volume EM +Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging large volumes of biological samples at high resolution. The OME-NGFF specification caters for this kind of big data nicely, and there are a number of resources that build upon OME-Zarr to provide additional support for vEM data. + +## Tools + +- [WebKnossos](https://webknossos.org/) - A web-based platform for visualizing, annotating, and sharing large-scale volumetric datasets. It has native support for OME-Zarr and is [widely used in the vEM community](https://home.webknossos.org/use-cases/volume-em). + +- [VolE](https://vole.allencell.org/) - Allen Institute for Cell Science's viewer for large-scale volumetric datasets, with native support for OME-Zarr. + +- [Neuroglancer](https://github.com/google/neuroglancer) - Google's WebGL-based viewer for volumetric data, with first class support for OME-Zarr. + +- [SyGlass](https://www.syglass.io/science) - A proprietary virtual reality platform for visualizing and analyzing large-scale volumetric datasets, with support for OME-Zarr. + +## Other + +- [WebKnossos Zarr Gallary](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. + - [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) - [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data - [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) + +- [Cryo-ET](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 43f25f4a..61c65e35 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -1,3 +1,5 @@ +(topic-wsi)= + # Whole Slide Imaging Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. From efc5025c46f6401f55d7cabb95c4e40316757161 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Mon, 3 Aug 2026 16:11:16 -0300 Subject: [PATCH 30/43] fix: Fix typo --- resources/topic-hub/volume-em/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index ef9bc530..58c7611c 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -16,7 +16,7 @@ Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging la ## Other -- [WebKnossos Zarr Gallary](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. +- [WebKnossos Zarr Gallery](https://zarr.webknossos.org/)- A gallery of OME-Zarr datasets, mostly vEM, hosted by WebKnossos. - [CCP Volume EM OME-NGFF Hackathon, at EMBL-EBI, Hinxton, UK, March 2026](https://focalplane.biologists.com/2025/12/11/ccp-volume-em-ome-ngff-hackathon-2026/) From 2d8fa4fde29a3caa4d84fc35c2962e96146ed583 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 4 Aug 2026 16:09:30 -0300 Subject: [PATCH 31/43] docs: add CryoET to topic-hub Thank you @uermel --- resources/topic-hub/cryo-et/index.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 resources/topic-hub/cryo-et/index.md diff --git a/resources/topic-hub/cryo-et/index.md b/resources/topic-hub/cryo-et/index.md new file mode 100644 index 00000000..c5e150d4 --- /dev/null +++ b/resources/topic-hub/cryo-et/index.md @@ -0,0 +1,21 @@ +# Cryo-ET + +Cryogenic electron tomography (cryo-ET) sits between single particle cryo-EM and volume EM. Cryo-ET involves the collection of tilt series of images from vitrified samples, which are then computationally reconstructed into 3D volumes. + +Here are some resources in the intersection of cryo-ET and OME-Zarr. + +## Tools + +- [ChimeraX OME-Zarr](https://github.com/uermel/chimerax-ome-zarr) - A plugin for [ChimeraX](https://www.cgl.ucsf.edu/chimerax/) to read and visualize OME-Zarr datasets designed for cryo-ET data. + +- [copick](https://copick.github.io/copick/) - CryoET annotation framework built upon OME-Zarr data. [[paper](https://onlinelibrary.wiley.com/doi/10.1002/pro.70578)] + +- [zarr-particle-tools](https://github.com/czimaginginstitute/zarr-particle-tools) - CryoET data analysis package (subtomogram averaging) based on OME-Zarr + +## Data + +- [Cryo-ET Data Portal](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). [[paper](https://www.nature.com/articles/s41592-024-02477-2)] + +## Other + +- [Cryo-ET Object Identification Kaggle Challenge](https://www.kaggle.com/competitions/czii-cryo-et-object-identification) - Kaggle competition for cryo-ET object identification, with OME-Zarr datasets. From 6c0827f65f4ffe0e62596293ab1c02ea10fa0bf0 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Tue, 4 Aug 2026 16:10:45 -0300 Subject: [PATCH 32/43] docs: add cryo-et to the index --- resources/topic-hub/cryo-et/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/resources/topic-hub/cryo-et/index.md b/resources/topic-hub/cryo-et/index.md index c5e150d4..29eb362c 100644 --- a/resources/topic-hub/cryo-et/index.md +++ b/resources/topic-hub/cryo-et/index.md @@ -1,3 +1,5 @@ +(#topic-cryo-et)= + # Cryo-ET Cryogenic electron tomography (cryo-ET) sits between single particle cryo-EM and volume EM. Cryo-ET involves the collection of tilt series of images from vitrified samples, which are then computationally reconstructed into 3D volumes. From 36c405e757c57910e8530138891f6d8b0d9758cc Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 10:24:10 -0300 Subject: [PATCH 33/43] Add CryoET to index, remove it from vEM Thanks @uermel! --- resources/topic-hub/index.md | 1 + resources/topic-hub/volume-em/index.md | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index fbeb4c79..42e66b50 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -7,6 +7,7 @@ The Topic Hub is a collection of resources particular to the intersection of NGF It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style: - [Volume EM](#topic-volume-em) +- [CryoET](#topic-cryoet) - [Whole Slide Imaging](#topic-wsi) - [Spatial Omics](#topic-spatial-omics) - [Dynamics](#topic-dynamics) diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index 58c7611c..bbb28148 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -23,5 +23,3 @@ Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging la - [Chapter 14 - Toward scalable reuse of vEM data: OME-Zarr to the rescue](https://www.sciencedirect.com/science/chapter/bookseries/abs/pii/S0091679X23000262) - (paywalled) book chapter describing the value of OME-Zarr for volume EM data - [Webinar for CCP volumeEM: 'OME-Zarr: A Next Generation File Format for FAIR Bioimaging Data' with Chris Barnes](https://www.ccp-volumeem.ac.uk/showandtell/may-2026) - -- [Cryo-ET](https://cryoetdataportal.czscience.com/) - Cryo-ET data portal, with datasets shared as OME-Zarr (arguably EM and volumetric, but usually not considered 'volume EM' in the sense of serial sectioning or block-face imaging). From 28d53bf5a842f12352c1d62ce03344e87b3ba86c Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 10:41:05 -0300 Subject: [PATCH 34/43] Add spora suite to the topic-hub (spatial proteomics) closes #579 --- resources/topic-hub/spatial-omics/index.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md index 240ecd6f..19bde65f 100644 --- a/resources/topic-hub/spatial-omics/index.md +++ b/resources/topic-hub/spatial-omics/index.md @@ -2,12 +2,24 @@ # Spatial Omics -The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build upon SpatialData to further refine the representation of data. - -They all ultimately build upon the OME-NGFF specification, and have the core compatible with the OME-Zarr ecosystem.. +The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build either on OME-Zarr directly or upon SpatialData. # Spatial proteomics +## spora ecosystem + +A suite of resources for spatial proteomics that use OME-Zarr at multiple levels. Includes: + +* [A spora data formats specification](https://spora.epfl.ch/docs-data.html) used to harmonize datasets. + +In short, it stores structured tabular data as `.parquet`, all whole-slide images as `.ome.zarr`, and segmentation masks as `.npz`. + +* [spora[data]](https://spora.epfl.ch/datasets.html) a resource containing multiple harmonized spatial proteomics datasets +* [spora [io]](https://github.com/bunnelab/spora-io) a Python library for accessing spora datasets +* Wenckstern, J., Jain, E., von Querfurth, B. et al. The Virtual Tissues foundation model resolves spatial proteomics across scales. Nature (2026). https://doi.org/10.1038/s41586-026-10884-y ([github repo](https://github.com/bunnelab/virtues#datasets)) + +## other + - Meyer-Bender, M., Vöhringer, H., Schniederjohann, C. et al. Spatialproteomics: an interoperable toolbox for analyzing highly multiplexed fluorescence image data. Nat Methods (2026). https://doi.org/10.1038/s41592-026-03155-1 An xarray/zarr Python toolkit for multiplexed immunofluorescence, using SpatialData for the underlying data representation, in connection with the [scverse ecosystem](https://scverse.org/). From 859486d4f59960710e09fd49eda430d4569b8679 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:05:50 -0300 Subject: [PATCH 35/43] add HCS page --- resources/topic-hub/hcs/index.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 resources/topic-hub/hcs/index.md diff --git a/resources/topic-hub/hcs/index.md b/resources/topic-hub/hcs/index.md new file mode 100644 index 00000000..1a55aee8 --- /dev/null +++ b/resources/topic-hub/hcs/index.md @@ -0,0 +1,9 @@ +(topic-hcs)= + +# High Content Screening + +High Content Screening (HCS) workflows record images for multiple conditions at the same time, often in multi-well plates. The OME-TIFF specification provided first-class support for HCS, and the OME-Zarr addressed HCS needs early on. With a [dedicated specification for plates and wells](https://ngff.openmicroscopy.org/0.5/#hcs-layout). + +- The [Fractal analytics framework](https://fractal-analytics-platform.github.io/) for large scale processing with OME-Zarr has multiple [workflows to analyse HCS data](https://fractal-analytics-platform.github.io/fractal_tasks/) ([preprint](https://www.biorxiv.org/content/10.64898/2026.03.05.709921v1.full)). + +- Massei, R., Busch, W., Serrano-Solano, B. et al. High-content screening (HCS) workflows for FAIR image data management with OMERO. Sci Rep 15, 16236 (2025). https://doi.org/10.1038/s41598-025-00720-0 From a24f65459ff326fbd110c099ba930fa09b936919 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:06:15 -0300 Subject: [PATCH 36/43] fix typos and details in pages for ct-scan and wsi --- resources/topic-hub/tomography/index.md | 6 ++++-- resources/topic-hub/wsi/index.md | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/resources/topic-hub/tomography/index.md b/resources/topic-hub/tomography/index.md index 4cf6c10a..dbc63f7a 100644 --- a/resources/topic-hub/tomography/index.md +++ b/resources/topic-hub/tomography/index.md @@ -1,8 +1,8 @@ (topic-tomography)= -# Tomography (CT) +# Computed Tomography (CT) -While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray tomography, electron tomography, and other non-microscopy imaging modalities. +While the OME community comes from the bioimaging and microscopy world, the OME-NGFF specification is also applicable to other imaging modalities. There are several kinds of tomography that can benefit from the OME-NGFF specification, including x-ray computed tomography (CT-scan). The value of the specification includes the metadata for mapping voxels to physical space, and the ability to store large datasets in a chunked and compressed format, with multiscale support, that is suitable for cloud storage and analysis. @@ -12,6 +12,8 @@ The value of the specification includes the metadata for mapping voxels to physi # Datasets +- [The Human Organ Atlas](https://human-organ-atlas.esrf.fr/) - Human organs scanned with Hierarchical Phase-Contrast Tomography (HiP-CT) made available in the OME-Zarr format ([paper](https://www.science.org/doi/10.1126/sciadv.adz2240)). + - [Herculaneum Scrolls](https://scrollprize.org/) - Scrolls carbonized by Mount Vesuvius eruptions imaged via X-ray micro-CT, made available in OME-Zarr format. ([data](https://registry.opendata.aws/vesuvius-challenge-herculaneum-scrolls/), [source](https://github.com/ScrollPrize/open-data)). Multimillion-dollar awards for teams that "unroll" the scrolls – all starting with processing OME-Zarr data. - [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index 61c65e35..b6f70c58 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -2,9 +2,9 @@ # Whole Slide Imaging -Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. +Resources related to Whole Slide Imaging (WSI) and its use in the context of the NGFF. Many of the examples come from the digital pathology community, but OME-Zarr may be used for other whole slide imaging applications. -- [QuPath](https://qupath.github.io/) Open source software for digital pathology image analysis, with support for OME-Zarr. +- [QuPath](https://qupath.github.io/) - Open source software for digital pathology image analysis, with support for OME-Zarr. ## Lazyslide & WSIData From 2cc001b144e9575b904f86bb424e09a3122d2e47 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:07:22 -0300 Subject: [PATCH 37/43] Add HCS to the topic hub index --- resources/topic-hub/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index 42e66b50..b7db23d7 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -8,6 +8,7 @@ It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and - [Volume EM](#topic-volume-em) - [CryoET](#topic-cryoet) +- [High-Content Screening](#topic-hcs) - [Whole Slide Imaging](#topic-wsi) - [Spatial Omics](#topic-spatial-omics) - [Dynamics](#topic-dynamics) From 521ce3a8bf06645486a6d6625f29231bf24bacef Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:28:10 -0300 Subject: [PATCH 38/43] remove duplication in html-proofer --- .github/workflows/html-proofer.yml | 62 ------------------------------ 1 file changed, 62 deletions(-) diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml index 024b44a1..779f2f17 100644 --- a/.github/workflows/html-proofer.yml +++ b/.github/workflows/html-proofer.yml @@ -1,67 +1,5 @@ name: "Build and Lint Site" -on: - workflow_dispatch: - pull_request: - branches: ["main"] - paths: - - "specifications/**" - - "rfc/**" - - "resources/**" - - "community/**" - - "contributing/**" - - "help-desk/**" - - "_html_extra/**" - - "_static/**" - - "_ext/**" - - "images/**" - - "**/*.md" - - "conf.py" - - "requirements.txt" - - "readthedocs.yml" - - ".github/workflows/build-lint.yml" - -concurrency: - group: build-lint-${{ github.ref }} - cancel-in-progress: true - -jobs: - build-site: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - fetch-depth: 1 - submodules: recursive - - # dependencies - - uses: ruby/setup-ruby@v1 - with: - ruby-version: "3.3" - - uses: actions/setup-python@v5 - with: - python-version: "3.13" - - uses: actions/setup-node@v4 - with: - node-version: "22" - - - name: Install dependencies - run: | - pip install -r requirements.txt - pip install specifications/dev - gem install html-proofer - - - name: Build the site - run: sphinx-build -b html . _build/html - - - name: Validate all links, enforce alt text - run: htmlproofer --ignore-files "/.*\/specifications\/(0\.[0-9]+|dev)\/.*/,/.*webpack-macros\.html/,/.*\/rfc\/4\/markdown\/.*/,/.*\/rfc\/5\/.*/,/.*\/rfc\/1\/.*/,/.*\/0\.[0-9]+(\.html|\/.*)/" --disable-external ./_build/html - - - name: Ensure no unexpected encoded HTML in output - run: | - ! fgrep -R 'lt;blockquote' _build/html -name: "Build and Lint Site" - on: workflow_dispatch: pull_request: From db6e4f0c50482d94765cb3158f0687d5fa5bc14e Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:32:21 -0300 Subject: [PATCH 39/43] return to main rfc/3 version --- rfc/3/versions/2026-07-17/index.md | 59 ++++++++++++++++-------------- 1 file changed, 32 insertions(+), 27 deletions(-) diff --git a/rfc/3/versions/2026-07-17/index.md b/rfc/3/versions/2026-07-17/index.md index 78178c27..074f3043 100644 --- a/rfc/3/versions/2026-07-17/index.md +++ b/rfc/3/versions/2026-07-17/index.md @@ -109,7 +109,7 @@ conversion of proprietary datasets, usage by microscope vendors[^1], and usage by novel microscopy modalities[^2]. This RFC removes these restrictions, opening NGFF to many more users within its -target domain (and beyond). Because it _only_ removes restrictions, existing +target domain (and beyond). Because it *only* removes restrictions, existing valid OME-Zarr datasets will remain valid after implementation of this proposal. @@ -144,6 +144,7 @@ and, > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. + and, > - Every Zarr array referred to by a `path` MUST have the same number of @@ -157,9 +158,9 @@ hamper the adoption of OME-Zarr as an acquisition-time format due to performance concerns: many acquisitions happen in TZCYX order (all channels are acquired together for each z-slice), which violates the "axes must be ordered by type" requirement. In such cases, scientists must first acquire their data -and _then_ transpose it — an expensive proposition for large datasets. (Note: +and *then* transpose it — an expensive proposition for large datasets. (Note: Admittedly, Zarr transpose codecs, as well as the mapAxis transformation from -RFC-5, already offer solutions to this problem. However, the _simplest_ +RFC-5, already offer solutions to this problem. However, the *simplest* solution of flexible array ordering with default codecs and only scale and translation transforms is only open after this RFC.) @@ -218,7 +219,7 @@ important part of data quality checks. Currently, this kind of microscopy data cannot be stored in OME-Zarr. Within the same workflow, the crystal orientation is usually encoded as three -_Euler angles_ or four _quaternion_ components stored at each pixel position. +*Euler angles* or four *quaternion* components stored at each pixel position. Although it's possible to use the "custom" axis for this purpose, a dedicated axis with a clear naming convention is more ergonomic for scientists. @@ -240,17 +241,17 @@ to save these intermediate image products for later reprocessing. ### Overlapping labels -OME-Zarr can represent not only raw images, but also _label images_, or +OME-Zarr can represent not only raw images, but also *label images*, or segmentations. Traditionally, segmentations assigned a single integer value to each pixel in the source image. However, newer segmentation methods produce -_coarse-to-fine_ segmentations, with semantic meaning. For images spanning many +*coarse-to-fine* segmentations, with semantic meaning. For images spanning many scales, as produced by modern microscopes, we may want to segment tissues, cells within those tissues, and organelles within those cells. These three levels of segmentations can be stacked along a new "coarseness" axis. -Similarly, new segmentation methods can produce _overlapping binary masks_. Due -to the overlap, they _cannot_ be stored as traditional integer masks (one value -per pixel), but are typically instead stored as _n_ boolean masks. For this +Similarly, new segmentation methods can produce *overlapping binary masks*. Due +to the overlap, they *cannot* be stored as traditional integer masks (one value +per pixel), but are typically instead stored as *n* boolean masks. For this mask, an extra "instance" axis is needed in addition to the [TCZ]YX axes of a source image. @@ -289,8 +290,7 @@ After this specification change, tools may encounter OME-Zarr files that don't match the earlier expectations of containing a subset of the TCZYX axes. This proposal is agnostic as to what to do in those situations, and indeed the appropriate action depends on the tool, but some suggestions include: - -- fail with an informative error message. (i.e. _partial_ implementations are +- fail with an informative error message. (i.e. *partial* implementations are OK, especially if well-documented.) - prompt the user about which axes to treat as spatial. - arbitrarily choose which axes to treat as spatial. @@ -304,31 +304,36 @@ document, taking as base the current development version: > - The length of `axes` must be between 2 and 5 and MUST be equal to the > dimensionality of the Zarr arrays storing the image data (see > `datasets:path`). +> > - `axes` MUST contain 2 or 3 entries of `type:space` +> > - `axes` MAY contain one additional entry of `type:time` +> > - `axes` MAY contain one additional entry of `type:channel` or a null / > custom type. +> > - `axes` entries MUST be ordered by `type` where the `time` axis must come > first (if present), followed by the `channel` or custom axis (if present) > and the axes of type `space`. +> > - If there are three spatial axes where two correspond to the image plane > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. -2. The following lines are _added_ to "multiscales metadata": +2. The following lines are *added* to "multiscales metadata": > 0. The length of the axis names MUST match the number of axes of the array. -> 1. _If_ a dataset contains exactly 2 spatial dimensions, those dimensions +> 1. *If* a dataset contains exactly 2 spatial dimensions, those dimensions > SHOULD be named `y` and `x`, except where rule 4 applies. -> 2. _If_ a dataset contains exactly 3 spatial dimensions, those dimensions +> 2. *If* a dataset contains exactly 3 spatial dimensions, those dimensions > SHOULD be named 'z', 'y', and 'x', except where rule 4 applies. -> 3. _If_ a dataset contains exactly 1 time dimension, it should be named `t`. +> 3. *If* a dataset contains exactly 1 time dimension, it should be named `t`. > 4. When image data axes map straightforwardly to axes with common names in > the relevant field of practice, those axes SHOULD be named according to > such conventions. For example, spatial frequency axes resulting from a > Fourier transformation of `z', 'y', and 'x' SHOULD be named 'w', 'v', and -`u`, respectively. Similarly, a temporal frequency axis resulting from -a Fourier transformation of the `t`axis SHOULD be named`w`or`ω`. +> `u`, respectively. Similarly, a temporal frequency axis resulting from +> a Fourier transformation of the `t` axis SHOULD be named `w` or `ω`. > 5. Axis names MUST NOT be repeated within a dataset, and SHOULD NOT be > different only by upper/lower-case. For example, the same dataset SHOULD > NOT have both an `X` and an `x` axis. @@ -365,7 +370,7 @@ the RFC. Developers of visualization libraries and software are concerned that this PR may result in a "wild west" of OME-Zarr datasets that have little in common, -making it difficult for tools to decide _which_ axes to display. More details +making it difficult for tools to decide *which* axes to display. More details about these concerns are developed below in the "Drawbacks" section. ## Backwards Compatibility @@ -421,21 +426,21 @@ have assuaged most implementation concerns][recap comment]. ## Performance The current OME-Zarr specification ensures arrays are stored in order TCZYX. -With C-order array data, this ensures efficient access for _some_ but not _all_ +With C-order array data, this ensures efficient access for *some* but not *all* access patterns. By removing restrictions on axis orderings, a new class of "mistake" is possible, as someone could save an array in order XYTCZ, which would combine poorly with C-order arrays to view XY planes. However, it is -arguable that Zarr chunking is in fact more important here — XYTCZ _could_ be +arguable that Zarr chunking is in fact more important here — XYTCZ *could* be a perfectly cromulent axis ordering for XY planes if the Zarr chunk size was (1024, 1024, 1, 1, 1). Moreover, imposing a fixed axis ordering can incur performance penalties at -_write_ time (where performance is often critical) if the data is not already +*write* time (where performance is often critical) if the data is not already in the expected order. Therefore, this proposal argues that any performance implications are better addressed through good documentation and good defaults. Indeed, more flexible -dimension ordering could _improve_ performance in some scenarios, such as +dimension ordering could *improve* performance in some scenarios, such as "pixel drilling", that is, extracting the value of a single x/y position over time. @@ -470,6 +475,7 @@ an informative error message (e.g. "The given dataset contains an unknown axis This RFC is placed in the public domain. + [nat methods paper]: https://www.nature.com/articles/s41592-021-01326-w [ome-model]: https://github.com/ome/ngff/pull/239/files#r1609781780 [ngff 0.4]: https://ngff.openmicroscopy.org/specifications/0.4/index.html @@ -496,12 +502,11 @@ This RFC is placed in the public domain. [zulip-rfc-3-thread]: https://imagesc.zulipchat.com/#narrow/channel/328251-NGFF/topic/RFC-3.3A.20remove.20dimension.20restrictions/near/568178521 [^1]: https://github.com/ome/ngff/pull/239#issuecomment-2122809286 - [^2]: https://github.com/ome/ngff/pull/239#issuecomment-2149119404 ## Changelog -| Date | Description | Link | -| ---------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | -| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | -| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | +| Date | Description | Link | +| ---------- | ---------------------------- | ---------------------------------------------------------------------------- | +| 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | +| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | From e91415bad6163e10d7ec9be3d94398a6d4838896 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:45:05 -0300 Subject: [PATCH 40/43] fix typos via statistical review Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- resources/topic-hub/cryo-et/index.md | 2 +- resources/topic-hub/hcs/index.md | 2 +- resources/topic-hub/index.md | 2 +- resources/topic-hub/spatial-omics/index.md | 5 ++--- resources/topic-hub/tomography/index.md | 6 +++--- resources/topic-hub/volume-em/index.md | 2 +- resources/topic-hub/wsi/index.md | 2 +- 7 files changed, 10 insertions(+), 11 deletions(-) diff --git a/resources/topic-hub/cryo-et/index.md b/resources/topic-hub/cryo-et/index.md index 29eb362c..b04e3a1c 100644 --- a/resources/topic-hub/cryo-et/index.md +++ b/resources/topic-hub/cryo-et/index.md @@ -1,4 +1,4 @@ -(#topic-cryo-et)= +(topic-cryo-et)= # Cryo-ET diff --git a/resources/topic-hub/hcs/index.md b/resources/topic-hub/hcs/index.md index 1a55aee8..6c67f132 100644 --- a/resources/topic-hub/hcs/index.md +++ b/resources/topic-hub/hcs/index.md @@ -2,7 +2,7 @@ # High Content Screening -High Content Screening (HCS) workflows record images for multiple conditions at the same time, often in multi-well plates. The OME-TIFF specification provided first-class support for HCS, and the OME-Zarr addressed HCS needs early on. With a [dedicated specification for plates and wells](https://ngff.openmicroscopy.org/0.5/#hcs-layout). +High Content Screening (HCS) workflows record images for multiple conditions at the same time, often in multi-well plates. The OME-TIFF specification provided first-class support for HCS, and the OME-Zarr addressed HCS needs early on, with a [dedicated specification for plates and wells](https://ngff.openmicroscopy.org/0.5/#hcs-layout). - The [Fractal analytics framework](https://fractal-analytics-platform.github.io/) for large scale processing with OME-Zarr has multiple [workflows to analyse HCS data](https://fractal-analytics-platform.github.io/fractal_tasks/) ([preprint](https://www.biorxiv.org/content/10.64898/2026.03.05.709921v1.full)). diff --git a/resources/topic-hub/index.md b/resources/topic-hub/index.md index b7db23d7..8b0241d1 100644 --- a/resources/topic-hub/index.md +++ b/resources/topic-hub/index.md @@ -7,7 +7,7 @@ The Topic Hub is a collection of resources particular to the intersection of NGF It includes topics like "Whole Slide Imaging", "Volume EM", "Spatial Omics", and "Dynamics", for which a collection of links is provided, in a sort of [web directory](https://en.wikipedia.org/wiki/Web_directory) style: - [Volume EM](#topic-volume-em) -- [CryoET](#topic-cryoet) +- [Cryo-ET](#topic-cryo-et) - [High-Content Screening](#topic-hcs) - [Whole Slide Imaging](#topic-wsi) - [Spatial Omics](#topic-spatial-omics) diff --git a/resources/topic-hub/spatial-omics/index.md b/resources/topic-hub/spatial-omics/index.md index 19bde65f..fde4ffdb 100644 --- a/resources/topic-hub/spatial-omics/index.md +++ b/resources/topic-hub/spatial-omics/index.md @@ -4,10 +4,9 @@ The SpatialData format builds upon OME-Zarr to provide a standard for storing spatial omics data. There are a number of resources that build either on OME-Zarr directly or upon SpatialData. -# Spatial proteomics - -## spora ecosystem +## Spatial proteomics +### spora ecosystem A suite of resources for spatial proteomics that use OME-Zarr at multiple levels. Includes: * [A spora data formats specification](https://spora.epfl.ch/docs-data.html) used to harmonize datasets. diff --git a/resources/topic-hub/tomography/index.md b/resources/topic-hub/tomography/index.md index dbc63f7a..6682ada4 100644 --- a/resources/topic-hub/tomography/index.md +++ b/resources/topic-hub/tomography/index.md @@ -6,17 +6,17 @@ While the OME community comes from the bioimaging and microscopy world, the OME- The value of the specification includes the metadata for mapping voxels to physical space, and the ability to store large datasets in a chunked and compressed format, with multiscale support, that is suitable for cloud storage and analysis. -# Example +## Example -# Datasets +## Datasets - [The Human Organ Atlas](https://human-organ-atlas.esrf.fr/) - Human organs scanned with Hierarchical Phase-Contrast Tomography (HiP-CT) made available in the OME-Zarr format ([paper](https://www.science.org/doi/10.1126/sciadv.adz2240)). - [Herculaneum Scrolls](https://scrollprize.org/) - Scrolls carbonized by Mount Vesuvius eruptions imaged via X-ray micro-CT, made available in OME-Zarr format. ([data](https://registry.opendata.aws/vesuvius-challenge-herculaneum-scrolls/), [source](https://github.com/ScrollPrize/open-data)). Multimillion-dollar awards for teams that "unroll" the scrolls – all starting with processing OME-Zarr data. -- [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) +- [Open SciVis](https://registry.opendata.aws/ome-zarr-open-scivis/) - A collection of volumetric datasets in OME-Zarr format, including several CT scans. ([source](https://github.com/InsightSoftwareConsortium/OMEZarrOpenSciVisDatasets)) - [VoDaSuRe](https://augusthoeg.github.io/VoDaSuRe/) - A large-scale dataset covering volumetric super-resolution data with micro-CT ([arXiv](https://arxiv.org/abs/2603.23153); [dataset](https://huggingface.co/datasets/AugustHoeg/VoDaSuRe)) diff --git a/resources/topic-hub/volume-em/index.md b/resources/topic-hub/volume-em/index.md index bbb28148..4ce215c1 100644 --- a/resources/topic-hub/volume-em/index.md +++ b/resources/topic-hub/volume-em/index.md @@ -2,7 +2,7 @@ # Volume EM -Volume Electron Microscopy (vEM) includes a numbers of techniques for imaging large volumes of biological samples at high resolution. The OME-NGFF specification caters for this kind of big data nicely, and there are a number of resources that build upon OME-Zarr to provide additional support for vEM data. +Volume Electron Microscopy (vEM) includes a number of techniques for imaging large volumes of biological samples at high resolution. The OME-NGFF specification caters for this kind of big data nicely, and there are a number of resources that build upon OME-Zarr to provide additional support for vEM data. ## Tools diff --git a/resources/topic-hub/wsi/index.md b/resources/topic-hub/wsi/index.md index b6f70c58..873c3945 100644 --- a/resources/topic-hub/wsi/index.md +++ b/resources/topic-hub/wsi/index.md @@ -8,7 +8,7 @@ Resources related to Whole Slide Imaging (WSI) and its use in the context of the ## Lazyslide & WSIData -- [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html#) +- [wsidata: Efficient data structures and IO for whole slide image analysis](https://wsidata.readthedocs.io/en/latest/index.html) Storage backed by [SpatialData](https://spatialdata.scverse.org/), so OME-NGFF at the core. From 2ce8b000301f603381f62db56cbb7f7323fadb50 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Thu, 20 Aug 2026 11:45:58 -0300 Subject: [PATCH 41/43] restore html-proofer to main --- .github/workflows/html-proofer.yml | 2 +- specifications/dev | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/html-proofer.yml b/.github/workflows/html-proofer.yml index 779f2f17..8bedcf03 100644 --- a/.github/workflows/html-proofer.yml +++ b/.github/workflows/html-proofer.yml @@ -59,4 +59,4 @@ jobs: - name: Ensure no unexpected encoded HTML in output run: | - ! fgrep -R 'lt;blockquote' _build/html + ! fgrep -R 'lt;blockquote' _build/html \ No newline at end of file diff --git a/specifications/dev b/specifications/dev index ad84ca01..fd8e71b8 160000 --- a/specifications/dev +++ b/specifications/dev @@ -1 +1 @@ -Subproject commit ad84ca013b64dd2ba6bc12af5d13ba3158fefabf +Subproject commit fd8e71b814d9cee247ffec0b8b6998d9b41ff73f From 48d4bd686c36094344a8d3cc676acc0382d7dcb8 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 21 Aug 2026 05:29:30 -0300 Subject: [PATCH 42/43] revert submodule changes --- specifications/dev | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specifications/dev b/specifications/dev index fd8e71b8..ad84ca01 160000 --- a/specifications/dev +++ b/specifications/dev @@ -1 +1 @@ -Subproject commit fd8e71b814d9cee247ffec0b8b6998d9b41ff73f +Subproject commit ad84ca013b64dd2ba6bc12af5d13ba3158fefabf From f6a3aab9a4ba4c2fe903dd98ac5b684ca7a55577 Mon Sep 17 00:00:00 2001 From: Tiago Lubiana Date: Fri, 21 Aug 2026 05:31:28 -0300 Subject: [PATCH 43/43] restore help desk --- help-desk/index.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/help-desk/index.md b/help-desk/index.md index d847c064..c3567770 100644 --- a/help-desk/index.md +++ b/help-desk/index.md @@ -1,8 +1,5 @@ # Help Desk -- [Glossary](#glossary) -- [FAQs](#faqs) -- [Where to seek for help](#where-to-seek-for-help) - [Glossary](#glossary) - [FAQs](#faqs) - [Where to seek for help](#where-to-seek-for-help)