From d2b1a2066a13fee0c424fe4604a546d9c052d509 Mon Sep 17 00:00:00 2001
From: Constantin Pape <c.pape@gmx.net>
Date: Fri, 28 Jan 2022 14:11:45 +0000
Subject: [PATCH] chore(rebuild): Merge pull request #57 from
 constantinpape/axes-spec

Extend the axes fields in multiscales metadata

SHA: 90de9f1c440bf7dccaac34fcfceb5785fc09ada5
Reason: push, by @sbesson

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
---
 0.1/index.html    |  351 +++++--
 0.2/index.html    | 2453 +++++++++++++++++++++++++++++++++++++++++++++
 0.3/index.html    |  987 ++++++++++++++++++
 latest/index.html |  537 ++++++++--
 4 files changed, 4163 insertions(+), 165 deletions(-)
 create mode 100644 0.2/index.html
 create mode 100644 0.3/index.html

diff --git a/0.1/index.html b/0.1/index.html
index c69e6add..b0686c71 100644
--- a/0.1/index.html
+++ b/0.1/index.html
@@ -12,7 +12,7 @@
  *   - .toc for the Table of Contents (<ol class="toc">)
  *     + <span class="secno"> for the section numbers
  *   - #toc for the Table of Contents (<nav id="toc">)
- *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
+ *   - ul.index for Indices (<a href="#ref">term</a><span>, in § N.M</span>)
  *   - table.index for Index Tables (e.g. for properties or elements)
  *
  * Structural Markup
@@ -368,8 +368,8 @@
 /** Subheadings ***************************************************************/
 
 	h1 + h2,
-	#subtitle {
-		/* #subtitle is a subtitle in an H2 under the H1 */
+	#profile-and-date {
+		/* #profile-and-date is a subtitle in an H2 under the H1 */
 		margin-top: 0;
 	}
 	h2 + h3,
@@ -583,34 +583,27 @@
 	a[href] {
 		color: #034575;
 		color: var(--a-normal-text);
-		text-decoration: none;
-		border-bottom: 1px solid #707070;
-		border-bottom: 1px solid var(--a-normal-underline);
-		/* Need a bit of extending for it to look okay */
-		padding: 0 1px 0;
-		margin: 0 -1px 0;
+		text-decoration: underline #707070;
+		text-decoration: underline var(--a-normal-underline);
+		text-decoration-skip-ink: none;
 	}
 	a:visited {
 		color: #034575;
 		color: var(--a-visited-text);
-		border-bottom-color: #bbb;
-		border-bottom-color: var(--a-visited-underline);
+		text-decoration-color: #bbb;
+		text-decoration-color: var(--a-visited-underline);
 	}
 
-	/* Use distinguishing colors when user is interacting with the link */
+	/* Indicate interaction with the link */
 	a[href]:focus,
 	a[href]:hover {
-		background: #f8f8f8;
-		background: rgba(75%, 75%, 75%, .25);
-		background: var(--a-hover-bg);
-		border-bottom-width: 3px;
-		margin-bottom: -2px;
+		text-decoration-thickness: 2px;
 	}
 	a[href]:active {
 		color: #c00;
 		color: var(--a-active-text);
-		border-color: #c00;
-		border-color: var(--a-active-underline);
+		text-decoration-color: #c00;
+		text-decoration-color: var(--a-active-underline);
 	}
 
 	/* Backout above styling for W3C logo */
@@ -1116,9 +1109,12 @@
 
 	.toc a {
 		/* More spacing; use padding to make it part of the click target. */
-		padding-top: 0.1rem;
+		padding: 0.1rem 1px 0;
 		/* Larger, more consistently-sized click target */
 		display: block;
+		/* Switch to using border-bottom for underlines */
+		text-decoration: none;
+		border-bottom: 1px solid;
 		/* Reverse color scheme */
 		color: black;
 		color: var(--toclink-text);
@@ -1131,6 +1127,13 @@
 		border-color: #054572;
 		border-color: var(--toclink-visited-underline);
 	}
+	.toc a:focus,
+	.toc a:hover {
+		background: rgba(75%, 75%, 75%, .25);
+		background: var(--a-hover-bg);
+		border-bottom-width: 3px;
+		margin-bottom: -2px;
+	}
 	.toc a:not(:focus):not(:hover) {
 		/* Allow colors to cascade through from link styling */
 		border-bottom-color: transparent;
@@ -1266,7 +1269,7 @@
 	ul.index ul,
 	ul.index dl { font-size: smaller; }
 	@media not print {
-		ul.index li span:not(.dfn-paneled) {
+		ul.index li a + span {
 			white-space: nowrap;
 			color: transparent; }
 		ul.index li a:hover + span,
@@ -1484,9 +1487,9 @@
 		}
 	}
 </style>
-  <meta content="Bikeshed version ef9d3c0a, updated Fri Nov 13 17:14:48 2020 -0800" name="generator">
+  <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/0.1/" rel="canonical">
-  <meta content="c6d7d84f77959846ecdc9b65eecfa87bb6dc1f86" name="document-revision">
+  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -1593,9 +1596,9 @@
     --ins-bg: transparent;
 
     --a-normal-text: #034575;
-    --a-normal-underline: #707070;
+    --a-normal-underline: #bbb;
     --a-visited-text: var(--a-normal-text);
-    --a-visited-underline: #bbb;
+    --a-visited-underline: #707070;
     --a-hover-bg: rgba(75%, 75%, 75%, .25);
     --a-active-text: #c00;
     --a-active-underline: #c00;
@@ -1687,6 +1690,16 @@
 figcaption:not(.no-marker)::before {
     content: "Figure " counter(figure) " ";
 }</style>
+<style>/* style-issues */
+
+a[href].issue-return {
+    float: right;
+    float: inline-end;
+    color: var(--issueheading-text);
+    font-weight: bold;
+    text-decoration: none;
+}
+</style>
 <style>/* style-md-lists */
 
 /* This is a weird hack for me not yet following the commonmark spec
@@ -1812,7 +1825,7 @@
   <div class="head">
     <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2020-11-20">20 November 2020</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -1820,12 +1833,13 @@ <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="cont
      <dt>Issue Tracking:
      <dd><a href="https://forum.image.sc/tag/ome-ngff">Forums</a>
      <dd><a href="https://github.com/ome/ngff/issues/">GitHub</a>
-     <dt class="editor">Editor:
+     <dt class="editor">Editors:
      <dd class="editor p-author h-card vcard"><span class="p-name fn">Josh Moore</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+     <dd class="editor p-author h-card vcard"><span class="p-name fn">Sébastien Besson</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
     </dl>
    </div>
    <div data-fill-with="warning"></div>
-   <p class="copyright" data-fill-with="copyright">Copyright © 2020 <a href="https://www.openmicroscopy.org/"><abbr title="Open Microscopy Environment">OME</abbr></a><sup>®</sup> (<a href="https://dundee.ac.uk/"><abbr title="University of Dundee">U. Dundee</abbr></a>).
+   <p class="copyright" data-fill-with="copyright">Copyright © 2022 <a href="https://www.openmicroscopy.org/"><abbr title="Open Microscopy Environment">OME</abbr></a><sup>®</sup> (<a href="https://dundee.ac.uk/"><abbr title="University of Dundee">U. Dundee</abbr></a>).
 OME trademark rules apply. </p>
    <hr title="Separator for header">
   </div>
@@ -1839,9 +1853,9 @@ <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="cont
   <h2 class="no-num no-toc no-ref heading settled" id="sotd"><span class="content">Status of this document</span></h2>
   <div data-fill-with="status">
    <p></p>
-   <p>The current released version of this specification is 0.1. Migration scripts
+   <p>This is the 0.1 release of this specification. Migration scripts
 
-will be provided between numbered versions. Data written with the latest changes
+will be provided between numbered versions. Data written with the latest version
 (an "editor’s draft") will not necessarily be supported.</p>
   </div>
   <div data-fill-with="at-risk"></div>
@@ -1854,7 +1868,12 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
       <li><a href="#why-ngff"><span class="secno">1.1</span> <span class="content">Why "<span><abbr title="Next-generation file-format">NGFF</abbr></span>"?</span></a>
       <li><a href="#ome-ngff"><span class="secno">1.2</span> <span class="content">OME-NGFF</span></a>
      </ol>
-    <li><a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+    <li>
+     <a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+     <ol class="toc">
+      <li><a href="#image-layout"><span class="secno">2.1</span> <span class="content">Images</span></a>
+      <li><a href="#hcs-layout"><span class="secno">2.2</span> <span class="content">High-content screening</span></a>
+     </ol>
     <li>
      <a href="#metadata"><span class="secno">3</span> <span class="content">Metadata</span></a>
      <ol class="toc">
@@ -1862,9 +1881,12 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
       <li><a href="#omero-md"><span class="secno">3.2</span> <span class="content">"omero" metadata</span></a>
       <li><a href="#labels-md"><span class="secno">3.3</span> <span class="content">"labels" metadata</span></a>
       <li><a href="#label-md"><span class="secno">3.4</span> <span class="content">"image-label" metadata</span></a>
+      <li><a href="#plate-md"><span class="secno">3.5</span> <span class="content">"plate" metadata</span></a>
+      <li><a href="#well-md"><span class="secno">3.6</span> <span class="content">"well" metadata</span></a>
      </ol>
-    <li><a href="#citing"><span class="secno">4</span> <span class="content">Citing</span></a>
-    <li><a href="#history"><span class="secno">5</span> <span class="content">Version History</span></a>
+    <li><a href="#implementations"><span class="secno">4</span> <span class="content">Implementations</span></a>
+    <li><a href="#citing"><span class="secno">5</span> <span class="content">Citing</span></a>
+    <li><a href="#history"><span class="secno">6</span> <span class="content">Version History</span></a>
     <li>
      <a href="#w3c-conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
      <ol class="toc">
@@ -1940,6 +1962,9 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
 is represented here as it would appear locally but could equally
 be stored on a web server to be accessed via HTTP or in object storage
 like S3 or GCS.</p>
+   <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secno">2.1. </span><span class="content">Images</span><a class="self-link" href="#image-layout"></a></h3>
+   <p>The following layout describes the expected Zarr hierarchy for images with
+multiple levels of resolutions and optionally associated labels.</p>
 <pre>.                             # Root folder, potentially in S3,
 │                             # with a flat list of images by image ID.
 │
@@ -1982,6 +2007,46 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
                 ├── 0         # Each multiscale level is stored as a separate Zarr array, as above, but only integer values
                 │   ...       # are supported.
                 └── n
+</pre>
+   <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno">2.2. </span><span class="content">High-content screening</span><a class="self-link" href="#hcs-layout"></a></h3>
+   <p>The following specification defines the hierarchy for a high-content screening
+dataset. Three groups must be defined above the images:</p>
+   <ul>
+    <li data-md>
+     <p>the group above the images defines the well and MUST implement the <a href="#well-md">well specification</a>. All images contained in a well are fields
+of view of the same well</p>
+    <li data-md>
+     <p>the group above the well defines a row of wells</p>
+    <li data-md>
+     <p>the group above the well row defines an entire plate i.e. a two-dimensional
+collection of wells organized in rows and columns. It MUST implement the <a href="#plate-md">plate specification</a></p>
+   </ul>
+<pre>.                             # Root folder, potentially in S3,
+│
+└── 5966.zarr                 # One plate (id=5966) converted to Zarr
+    ├── .zgroup
+    ├── .zattrs               # Implements "plate" specification
+    ├── A                     # First row of the plate
+    │   ├── .zgroup
+    │   │
+    │   ├── 1                 # First column of row A
+    │   │   ├── .zgroup
+    │   │   ├── .zattrs       # Implements "well" specification
+    │   │   │
+    │   │   ├── 0             # First field of view of well A1
+    │   │   │   │
+    │   │   │   ├── .zgroup
+    │   │   │   ├── .zattrs   # Implements "multiscales", "omero"
+    │   │   │   ├── 0
+    │   │   │   │   ...       # Resolution levels
+    │   │   │   ├── n
+    │   │   │   └── labels    # Labels (optional)
+    │   │   ├── ...           # Fields of view
+    │   │   └── m
+    │   ├── ...               # Columns
+    │   └── 12
+    ├── ...                   # Rows
+    └── H
 </pre>
    <h2 class="heading settled" data-level="3" id="metadata"><span class="secno">3. </span><span class="content">Metadata</span><a class="self-link" href="#metadata"></a></h2>
    <p>The various <code>.zattrs</code> files throughout the above array hierarchy may contain metadata
@@ -2007,10 +2072,10 @@ <h3 class="heading settled" data-level="3.1" id="multiscale-md"><span class="sec
    <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3.2. </span><span class="content">"omero" metadata</span><a class="self-link" href="#omero-md"></a></h3>
    <p>Information specific to the channels of an image and how to render it
 can be found under the "omero" key in the group-level metadata:</p>
-<pre class="language-json highlight"><c- u>"id"</c->: <c- mi>1</c->,                              # ID in OMERO
-<c- u>"name"</c->: <c- u>"example.tif"</c->,                # Name as shown in the UI
-<c- u>"version"</c->: <c- u>"0.1"</c->,                     # Current version
-<c- u>"channels"</c->: <c- p>[</c->                         # Array matching the c dimension size
+<pre class="language-json highlight"><c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->                              # ID i<c- kc>n</c-> OMERO
+<c- f>"name"</c-><c- p>:</c-> <c- u>"example.tif"</c-><c- p>,</c->                # Name as show<c- kc>n</c-> i<c- kc>n</c-> <c- kc>t</c->he UI
+<c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c-><c- p>,</c->                     # Curre<c- kc>nt</c-> versio<c- kc>n</c->
+<c- f>"channels"</c-><c- p>:</c-> <c- p>[</c->                         # Array ma<c- kc>t</c->chi<c- kc>n</c->g <c- kc>t</c->he c dime<c- kc>ns</c->io<c- kc>n</c-> size
     <c- p>{</c->
         <c- f>"active"</c-><c- p>:</c-> <c- kc>true</c-><c- p>,</c->
         <c- f>"coefficient"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
@@ -2025,10 +2090,10 @@ <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3
             <c- f>"start"</c-><c- p>:</c-> <c- mi>0</c->
         <c- p>}</c->
     <c- p>}</c->
-<c- p>]</c->,
-<c- u>"rdefs"</c->: <c- p>{</c->
-    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # First timepoint to show the user
-    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # First Z section to show the user
+<c- p>],</c->
+<c- f>"rdefs"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # Firs<c- kc>t</c-> <c- kc>t</c->imepoi<c- kc>nt</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # Firs<c- kc>t</c-> Z sec<c- kc>t</c->io<c- kc>n</c-> <c- kc>t</c->o show <c- kc>t</c->he user
     <c- f>"model"</c-><c- p>:</c-> <c- u>"color"</c->                  # <c- u>"color"</c-> or <c- u>"greyscale"</c->
 <c- p>}</c->
 </pre>
@@ -2059,7 +2124,7 @@ <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3
 image the label is associated with. If included it MAY include a key <code>image</code> whose value is the relative path to a Zarr image group. The default value is
 "../../" since most labels are stored under a subgroup named "labels/" (see
 above).</p>
-<pre class="language-json highlight"><c- u>"image-label"</c->:
+<pre class="language-json highlight"><c- f>"image-label"</c-><c- p>:</c->
   <c- p>{</c->
     <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c-><c- p>,</c->
     <c- f>"colors"</c-><c- p>:</c-> <c- p>[</c->
@@ -2073,17 +2138,175 @@ <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3
       <c- p>},</c->
       ...
       <c- p>]</c->
-    <c- p>}</c->,
-    <c- u>"source"</c->: <c- p>{</c->
+    <c- p>},</c->
+    <c- f>"source"</c-><c- p>:</c-> <c- p>{</c->
       <c- f>"image"</c-><c- p>:</c-> <c- u>"../../"</c->
     <c- p>}</c->
-]
+<c- p>]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.5" id="plate-md"><span class="secno">3.5. </span><span class="content">"plate" metadata</span><a class="self-link" href="#plate-md"></a></h3>
+   <p>For high-content screening datasets, the plate layout can be found under the
+custom attributes of the plate group under the <code>plate</code> key.</p>
+   <dl>
+    <dt><strong>acquisitions</strong>
+    <dd>An optional list of JSON objects defining the acquisitions for a given
+      plate. Each acquisition object MUST contain an <code>id</code> key providing an
+      unique identifier within the context of the plate to which fields of
+      view can refer to. It SHOULD contain  a <code>name</code> key identifying the name
+      of the acquisition. It SHOULD contain a <code>maximumfieldcount</code> key
+      indicating the maximum number of fields of view for the acquisition. It
+      MAY contain a <code>description</code> key providing a description for the
+      acquisition. It MAY contain a <code>startime</code> and/or <code>endtime</code> key specifying
+      the start and/or end timestamp of the acquisition using an epoch
+      string.
+    <dt><strong>columns</strong>
+    <dd>A list of JSON objects defining the columns of the plate. Each column
+      object defines the properties of the column at the index of the object
+      in the list. If not empty, it MUST contain a <code>name</code> key specifying the
+      column name.
+    <dt><strong>field_count</strong>
+    <dd>An integer defining the maximum number of fields per view across all
+      wells.
+    <dt><strong>name</strong>
+    <dd>A string defining the name of the plate.
+    <dt><strong>rows</strong>
+    <dd>A list of JSON objects defining the rows of the plate. Each row object
+      defines the properties of the row at the index of the object in the
+      list. If not empty, it MUST contain a <code>name</code> key specifying the row
+      name.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+    <dt><strong>wells</strong>
+    <dd>A list of JSON objects defining the wells of the plate. Each well object 
+      MUST contain a <code>path</code> key identifying the path to the well subgroup.
+   </dl>
+   <p>For example the following JSON object defines a plate with two acquisition and
+6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion.</p>
+<pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_01(2012-07-31_10-41-12)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343731272000</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_02(201207-31_11-56-41)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343735801000</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"columns"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"field_count"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+    <c- f>"name"</c-><c- p>:</c-> <c- u>"test"</c-><c- p>,</c->
+    <c- f>"rows"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"A"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"B"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c-><c- p>,</c->
+    <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/3"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/3"</c->
+        <c- p>}</c->
+    <c- p>]</c->
+  <c- p>}</c->
+</pre>
+   <h3 class="heading settled" data-level="3.6" id="well-md"><span class="secno">3.6. </span><span class="content">"well" metadata</span><a class="self-link" href="#well-md"></a></h3>
+   <p>For high-content screening datasets, the metadata about all fields of views
+under a given  well can be found under the "well" key in the attributes of the
+well group.</p>
+   <dl>
+    <dt><strong>images</strong>
+    <dd>A list of JSON objects defining the fields of views for a given well.
+      Each object MUST contain a <code>path</code> key identifying the path to the
+      field of view. If multiple acquisitions were performed in the plate, it  
+      SHOULD contain an <code>acquisition</code> key identifying the id of the 
+      acquisition which must match one of acquisition JSON objects defined in
+      the plate metadata.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+   </dl>
+   <p>For example the following JSON object defines a well with four fields of
+views. The first two fields of view were part of the first acquisition while
+the last two fields of view were part of the second acquisition.</p>
+<pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c->
+  <c- p>}</c->
 </pre>
-   <h2 class="heading settled" data-level="4" id="citing"><span class="secno">4. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
+   <h2 class="heading settled" data-level="4" id="implementations"><span class="secno">4. </span><span class="content">Implementations</span><a class="self-link" href="#implementations"></a></h2>
+   <p>Projects which support reading and/or writing OME-NGFF data include:</p>
+   <dl>
+    <dt><strong><a href="https://github.com/ome/omero-ms-zarr">omero-ms-zarr</a></strong>
+    <dd>A microservice for OMERO.server that converts images stored in OMERO to OME Zarr files on the fly, served via a web API.
+    <dt><strong><a href="https://github.com/IDR/idr-zarr-tools">idr-zarr-tools</a></strong>
+    <dd>A full workflow demonstrating the conversion of IDR images to OME Zarr images on S3.
+    <dt><strong><a href="https://github.com/ome/omero-cli-zarr">OMERO CLI Zarr plugin</a></strong>
+    <dd>An OMERO CLI plugin that converts images stored in OMERO.server into a local Zarr file.
+    <dt><strong><a href="https://github.com/ome/ome-zarr-py">ome-zarr-py</a></strong>
+    <dd>A napari plugin for reading ome-zarr files.
+    <dt><strong><a href="https://github.com/glencoesoftware/bioformats2raw">bioformats2raw</a></strong>
+    <dd>A performant, Bio-Formats image file format converter.
+    <dt><strong><a href="https://github.com/hms-dbmi/vizarr/">vizarr</a></strong>
+    <dd>A minimal, purely client-side program for viewing Zarr-based images with Viv &amp; ImJoy.
+   </dl>
+   <p><img alt="Diagram of related projects" src="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/images/zarr-ome-diagram.png"></p>
+   <p>All implementations prevent an equivalent representation of a dataset which can be downloaded or uploaded freely. An interactive
+version of this diagram is available from the <a href="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/">OME2020 Workshop</a>.
+Mouseover the blackboxes representing the implementations above to get a quick tip on how to use them.</p>
+   <p class="note" role="note"><span>Note:</span> If you would like to see your project listed, please open an issue or PR on the <a href="https://github.com/ome/ngff">ome/ngff</a> repository.</p>
+   <h2 class="heading settled" data-level="5" id="citing"><span class="secno">5. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
    <p><a href="https://ngff.openmicroscopy.org/0.1">Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a> J. Moore, <em>et al</em>. Editors. Open Microscopy Environment Consortium, 20 November 2020.
 This edition of the specification is <a href="https://ngff.openmicroscopy.org/0.1/]">https://ngff.openmicroscopy.org/0.1/</a>.
 The latest edition is available at <a href="https://ngff.openmicroscopy.org/latest/">https://ngff.openmicroscopy.org/latest/</a>. <a href="https://doi.org/10.5281/zenodo.4282107">(doi:10.5281/zenodo.4282107)</a></p>
-   <h2 class="heading settled" data-level="5" id="history"><span class="secno">5. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
+   <h2 class="heading settled" data-level="6" id="history"><span class="secno">6. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
    <table>
     <thead>
      <tr>
@@ -2092,21 +2315,13 @@ <h2 class="heading settled" data-level="5" id="history"><span class="secno">5. <
       <td>Description
     <tbody>
      <tr>
-      <td>0.1.3-dev4
-      <td>2020-09-14
-      <td>Add the image-label object 
-     <tr>
-      <td>0.1.3-dev3
-      <td>2020-09-01
-      <td>Convert labels to multiscales 
+      <td>0.1.4
+      <td>2020-11-26
+      <td>Add HCS specification 
      <tr>
-      <td>0.1.3-dev2
-      <td>2020-08-18
-      <td>Rename masks as labels 
-     <tr>
-      <td>0.1.3-dev1
-      <td>2020-07-07
-      <td>Add mask metadata 
+      <td>0.1.3
+      <td>2020-09-14
+      <td>Add labels specification 
      <tr>
       <td>0.1.2 
       <td>2020-05-07
@@ -2162,25 +2377,25 @@ <h3 class="no-ref no-num heading settled" id="w3c-conformant-algorithms"><span c
     and are not intended to be performant.
     Implementers are encouraged to optimize. </p>
   </div>
-<script src="https://www.w3.org/scripts/TR/2016/fixup.js"></script>
+<script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script>
   <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
   <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
   <ul class="index">
-   <li><a href="#hdf5">HDF5</a><span>, in §1.1</span>
-   <li><a href="#ngff">NGFF</a><span>, in §1.1</span>
+   <li><a href="#hdf5">HDF5</a><span>, in § 1.1</span>
+   <li><a href="#ngff">NGFF</a><span>, in § 1.1</span>
   </ul>
   <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
   <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
   <dl>
    <dt id="biblio-rfc2119">[RFC2119]
-   <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>. March 1997. Best Current Practice. URL: <a href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
+   <dd>S. Bradner. <a href="https://datatracker.ietf.org/doc/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a>
   </dl>
   <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
   <dl>
    <dt id="biblio-n5">[N5]
-   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62">N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
+   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62"><cite>N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</cite></a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
    <dt id="biblio-ome-zarr-py">[OME-ZARR-PY]
-   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931">ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
+   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931"><cite>ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
    <dt id="biblio-zarr">[ZARR]
-   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231">Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
+   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231"><cite>Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
   </dl>
\ No newline at end of file
diff --git a/0.2/index.html b/0.2/index.html
new file mode 100644
index 00000000..9272eaf6
--- /dev/null
+++ b/0.2/index.html
@@ -0,0 +1,2453 @@
+<!doctype html><html lang="en">
+ <head>
+  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
+  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
+  <title>Next-generation file formats (NGFF)</title>
+<style data-fill-with="stylesheet">/******************************************************************************
+ *                   Style sheet for the W3C specifications                   *
+ *
+ * Special classes handled by this style sheet include:
+ *
+ * Indices
+ *   - .toc for the Table of Contents (<ol class="toc">)
+ *     + <span class="secno"> for the section numbers
+ *   - #toc for the Table of Contents (<nav id="toc">)
+ *   - ul.index for Indices (<a href="#ref">term</a><span>, in § N.M</span>)
+ *   - table.index for Index Tables (e.g. for properties or elements)
+ *
+ * Structural Markup
+ *   - table.data for general data tables
+ *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
+ *     -> use <table class='complex data'> for extra-complex tables
+ *     -> use <td class='long'> for paragraph-length cell content
+ *     -> use <td class='pre'> when manual line breaks/indentation would help readability
+ *   - dl.switch for switch statements
+ *   - ol.algorithm for algorithms (helps to visualize nesting)
+ *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
+ *     -> .sidefigure for right-floated figures
+ *   - ins/del
+ *     -> ins/del.c### for candidate and proposed changes (amendments)
+ *
+ * Code
+ *   - pre and code
+ *
+ * Special Sections
+ *   - .note       for informative notes             (div, p, span, aside, details)
+ *   - .example    for informative examples          (div, p, pre, span)
+ *   - .issue      for issues                        (div, p, span)
+ *   - .advisement for loud normative statements     (div, p, strong)
+ *   - .annoying-warning for spec obsoletion notices (div, aside, details)
+ *   - .correction for "candidate corrections"       (div, aside, details, section)
+ *   - .addition   for "candidate additions"         (div, aside, details, section)
+ *   - .correction.proposed for "proposed corrections" (div, aside, details, section)
+ *   - .addition.proposed   for "proposed additions"   (div, aside, details, section)
+ *
+ * Definition Boxes
+ *   - pre.def   for WebIDL definitions
+ *   - table.def for tables that define other entities (e.g. CSS properties)
+ *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
+ *
+ * Numbering
+ *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
+ *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
+ *   - ::before styled for CSS-generated issue/example/figure numbers:
+ *     -> Documents wishing to use this only need to add
+ *        figcaption::before,
+ *        .caption::before { content: "Figure "  counter(figure) " ";  }
+ *        .example::before { content: "Example " counter(example) " "; }
+ *        .issue::before   { content: "Issue "   counter(issue) " ";   }
+ *
+ * Header Stuff (ignore, just don't conflict with these classes)
+ *   - .head for the header
+ *   - .copyright for the copyright
+ *
+ * Outdated warning for old specs
+ *
+ * Miscellaneous
+ *   - .overlarge for things that should be as wide as possible, even if
+ *     that overflows the body text area. This can be used on an item or
+ *     on its container, depending on the effect desired.
+ *     Note that this styling basically doesn't help at all when printing,
+ *     since A4 paper isn't much wider than the max-width here.
+ *     It's better to design things to fit into a narrower measure if possible.
+ *
+ *   - js-added ToC jump links (see fixup.js)
+ *
+ ******************************************************************************/
+
+/* color variables included separately for reliability */
+
+/******************************************************************************/
+/*                                    Body                                    */
+/******************************************************************************/
+
+	html {
+	}
+
+	body {
+		counter-reset: example figure issue;
+
+		/* Layout */
+		max-width: 50em;			  /* limit line length to 50em for readability   */
+		margin: 0 auto;				/* center text within page                    */
+		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
+		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag    */
+
+		/* Typography */
+		line-height: 1.5;
+		font-family: sans-serif;
+		widows: 2;
+		orphans: 2;
+		word-wrap: break-word;
+		overflow-wrap: break-word;
+		hyphens: auto;
+
+		color: black;
+		color: var(--text);
+		background: white top left fixed no-repeat;
+		background: var(--bg) top left fixed no-repeat;
+		background-size: 25px auto;
+	}
+
+
+/******************************************************************************/
+/*                         Front Matter & Navigation                          */
+/******************************************************************************/
+
+/** Header ********************************************************************/
+
+	div.head { margin-bottom: 1em; }
+	div.head hr { border-style: solid; }
+
+	div.head h1 {
+		font-weight: bold;
+		margin: 0 0 .1em;
+		font-size: 220%;
+	}
+
+	div.head h2 { margin-bottom: 1.5em;}
+
+/** W3C Logo ******************************************************************/
+
+	.head .logo {
+		float: right;
+		margin: 0.4rem 0 0.2rem .4rem;
+	}
+
+	.head img[src*="logos/W3C"] {
+		display: block;
+		border: solid #1a5e9a;
+		border: solid var(--logo-bg);
+		border-width: .65rem .7rem .6rem;
+		border-radius: .4rem;
+		background: #1a5e9a;
+		background: var(--logo-bg);
+		color: white;
+		color: var(--logo-text);
+		font-weight: bold;
+	}
+
+	.head a:hover > img[src*="logos/W3C"],
+	.head a:focus > img[src*="logos/W3C"] {
+		opacity: .8;
+	}
+
+	.head a:active > img[src*="logos/W3C"] {
+		background: #c00;
+		background: var(--logo-active-bg);
+		border-color: #c00;
+		border-color: var(--logo-active-bg);
+	}
+
+	/* see also additional rules in Link Styling section */
+
+/** Copyright *****************************************************************/
+
+	p.copyright,
+	p.copyright small { font-size: small; }
+
+/** Back to Top / ToC Toggle **************************************************/
+
+	@media print {
+		#toc-nav {
+			display: none;
+		}
+	}
+	@media not print {
+		#toc-nav {
+			position: fixed;
+			z-index: 3;
+			bottom: 0; left: 0;
+			margin: 0;
+			min-width: 1.33em;
+			border-top-right-radius: 2rem;
+			box-shadow: 0 0 2px;
+			font-size: 1.5em;
+		}
+		#toc-nav > a {
+			display: block;
+			white-space: nowrap;
+
+			height: 1.33em;
+			padding: .1em 0.3em;
+			margin: 0;
+
+			box-shadow: 0 0 2px;
+			border: none;
+			border-top-right-radius: 1.33em;
+
+			color: #707070;
+			color: var(--tocnav-normal-text);
+			background: white;
+			background: var(--tocnav-normal-bg);
+		}
+		#toc-nav > a:hover,
+		#toc-nav > a:focus {
+			color: black;
+			color: var(--tocnav-hover-text);
+			background: #f8f8f8;
+			background: var(--tocnav-hover-bg);
+		}
+		#toc-nav > a:active {
+			color: #c00;
+			color: var(--tocnav-active-text);
+			background: white;
+			background: var(--tocnav-active-bg);
+		}
+
+		#toc-nav > #toc-jump {
+			padding-bottom: 2em;
+			margin-bottom: -1.9em;
+		}
+
+		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
+		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
+			padding-bottom: 1.5rem;
+		}
+
+		#toc-nav:not(:hover) > a:not(:focus) > span + span {
+			/* Ideally this uses :focus-within on #toc-nav */
+			display: none;
+		}
+		#toc-nav > a > span + span {
+			padding-right: 0.2em;
+		}
+	}
+
+/** ToC Sidebar ***************************************************************/
+
+	/* Floating sidebar */
+	@media screen {
+		body.toc-sidebar #toc {
+			position: fixed;
+			top: 0; bottom: 0;
+			left: 0;
+			width: 23.5em;
+			max-width: 80%;
+			max-width: calc(100% - 2em - 26px);
+			overflow: auto;
+			padding: 0 1em;
+			padding-left: 42px;
+			padding-left: calc(1em + 26px);
+			color: black;
+			color: var(--tocsidebar-text);
+			background: inherit;
+			background-color: #f7f8f9;
+			background-color: var(--tocsidebar-bg);
+			z-index: 1;
+			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
+			box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset;
+		}
+		body.toc-sidebar #toc h2 {
+			margin-top: .8rem;
+			font-variant: small-caps;
+			font-variant: all-small-caps;
+			text-transform: lowercase;
+			font-weight: bold;
+			color: gray;
+			color: hsla(203,20%,40%,.7);
+			color: var(--tocsidebar-heading-text);
+		}
+		body.toc-sidebar #toc-jump:not(:focus) {
+			width: 0;
+			height: 0;
+			padding: 0;
+			position: absolute;
+			overflow: hidden;
+		}
+	}
+	/* Hide main scroller when only the ToC is visible anyway */
+	@media screen and (max-width: 28em) {
+		body.toc-sidebar {
+			overflow: hidden;
+		}
+	}
+
+	/* Sidebar with its own space */
+	@media screen and (min-width: 78em) {
+		body:not(.toc-inline) #toc {
+			position: fixed;
+			top: 0; bottom: 0;
+			left: 0;
+			width: 23.5em;
+			overflow: auto;
+			padding: 0 1em;
+			padding-left: 42px;
+			padding-left: calc(1em + 26px);
+			color: black;
+			color: var(--tocsidebar-text);
+			background: inherit;
+			background-color: #f7f8f9;
+			background-color: var(--tocsidebar-bg);
+			z-index: 1;
+			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
+			box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset;
+		}
+		body:not(.toc-inline) #toc h2 {
+			margin-top: .8rem;
+			font-variant: small-caps;
+			font-variant: all-small-caps;
+			text-transform: lowercase;
+			font-weight: bold;
+			color: gray;
+			color: hsla(203,20%,40%,.7);
+			color: var(--tocsidebar-heading-text);
+		}
+
+		body:not(.toc-inline) {
+			padding-left: 29em;
+		}
+		/* See also Overflow section at the bottom */
+
+		body:not(.toc-inline) #toc-jump:not(:focus) {
+			width: 0;
+			height: 0;
+			padding: 0;
+			position: absolute;
+			overflow: hidden;
+		}
+	}
+	@media screen and (min-width: 90em) {
+		body:not(.toc-inline) {
+			margin: 0 4em;
+		}
+	}
+
+/******************************************************************************/
+/*                                Sectioning                                  */
+/******************************************************************************/
+
+/** Headings ******************************************************************/
+
+	h1, h2, h3, h4, h5, h6, dt {
+		page-break-after: avoid;
+		page-break-inside: avoid;
+		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
+		font-family: inherit;	/* Inherit the font family. */
+		line-height: 1.2;		/* Keep wrapped headings compact */
+		hyphens: manual;		/* Hyphenated headings look weird */
+	}
+
+	h2, h3, h4, h5, h6 {
+		margin-top: 3rem;
+	}
+
+	h1, h2, h3 {
+		color: #005A9C;
+		color: var(--heading-text);
+	}
+
+	h1 { font-size: 170%; }
+	h2 { font-size: 140%; }
+	h3 { font-size: 120%; }
+	h4 { font-weight: bold; }
+	h5 { font-style: italic; }
+	h6 { font-variant: small-caps; }
+	dt { font-weight: bold; }
+
+/** Subheadings ***************************************************************/
+
+	h1 + h2,
+	#profile-and-date {
+		/* #profile-and-date is a subtitle in an H2 under the H1 */
+		margin-top: 0;
+	}
+	h2 + h3,
+	h3 + h4,
+	h4 + h5,
+	h5 + h6 {
+		margin-top: 1.2em; /* = 1 x line-height */
+	}
+
+/** Section divider ***********************************************************/
+
+	:not(.head) > :not(.head) + hr {
+		font-size: 1.5em;
+		text-align: center;
+		margin: 1em auto;
+		height: auto;
+		color: black;
+		color: var(--hr-text);
+		border: transparent solid 0;
+		background: transparent;
+	}
+	:not(.head) > hr::before {
+		content: "\2727\2003\2003\2727\2003\2003\2727";
+	}
+
+/******************************************************************************/
+/*                            Paragraphs and Lists                            */
+/******************************************************************************/
+
+	p {
+		margin: 1em 0;
+	}
+
+	dd > p:first-child,
+	li > p:first-child {
+		margin-top: 0;
+	}
+
+	ul, ol {
+		margin-left: 0;
+		padding-left: 2em;
+	}
+
+	li {
+		margin: 0.25em 0 0.5em;
+		padding: 0;
+	}
+
+	dl dd {
+		margin: 0 0 .5em 2em;
+	}
+
+	.head dd + dd { /* compact for header */
+		margin-top: -.5em;
+	}
+
+	/* Style for algorithms */
+	ol.algorithm ol:not(.algorithm),
+	.algorithm > ol ol:not(.algorithm) {
+	border-left: 0.5em solid #DEF;
+	border-left: 0.5em solid var(--algo-border);
+	}
+
+	/* Put nice boxes around each algorithm. */
+	[data-algorithm]:not(.heading) {
+	 padding: .5em;
+	 border: thin solid #ddd;
+	 border: thin solid var(--algo-border);
+	 border-radius: .5em;
+	 margin: .5em calc(-0.5em - 1px);
+	}
+	[data-algorithm]:not(.heading) > :first-child {
+	 margin-top: 0;
+	}
+	[data-algorithm]:not(.heading) > :last-child {
+	 margin-bottom: 0;
+	}
+
+	/* Style for switch/case <dl>s */
+	dl.switch > dd > ol.only,
+	dl.switch > dd > .only > ol {
+	margin-left: 0;
+	}
+	dl.switch > dd > ol.algorithm,
+	dl.switch > dd > .algorithm > ol {
+	margin-left: -2em;
+	}
+	dl.switch {
+	padding-left: 2em;
+	}
+	dl.switch > dt {
+	text-indent: -1.5em;
+	margin-top: 1em;
+	}
+	dl.switch > dt + dt {
+	margin-top: 0;
+	}
+	dl.switch > dt::before {
+	content: '\21AA';
+	padding: 0 0.5em 0 0;
+	display: inline-block;
+	width: 1em;
+	text-align: right;
+	line-height: 0.5em;
+	}
+
+/** Terminology Markup ********************************************************/
+
+
+/******************************************************************************/
+/*                                 Inline Markup                              */
+/******************************************************************************/
+
+/** Terminology Markup ********************************************************/
+	dfn   { /* Defining instance */
+		font-weight: bolder;
+	}
+	a > i { /* Instance of term */
+		font-style: normal;
+	}
+	dt dfn code, code.idl {
+		font-size: inherit;
+	}
+	dfn var {
+		font-style: normal;
+	}
+
+/** Change Marking ************************************************************/
+
+	del {
+		color: #aa0000;
+		color: var(--del-text);
+		background: transparent;
+		background: var(--del-bg);
+		text-decoration: line-through;
+	}
+	ins {
+		color: #006100;
+		color: var(--ins-text);
+		background: transparent;
+		background: var(--ins-bg);
+		text-decoration: underline;
+	}
+
+	/* for amendments (candidate/proposed changes) */
+
+	.amendment ins, .correction ins, .addition ins,
+	ins[class^=c] {
+		text-decoration-style: dotted;
+	}
+	.amendment del, .correction del, .addition del,
+	del[class^=c] {
+		text-decoration-style: dotted;
+	}
+	.amendment.proposed ins, .correction.proposed ins, .addition.proposed ins,
+	ins[class^=c].proposed {
+		text-decoration-style: double;
+	}
+	.amendment.proposed del, .correction.proposed del, .addition.proposed del,
+	del[class^=c].proposed {
+		text-decoration-style: double;
+	}
+
+/** Miscellaneous improvements to inline formatting ***************************/
+
+	sup {
+		vertical-align: super;
+		font-size: 80%
+	}
+
+/******************************************************************************/
+/*                                    Code                                    */
+/******************************************************************************/
+
+/** General monospace/pre rules ***********************************************/
+
+	pre, code, samp {
+		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
+		font-size: .9em;
+		hyphens: none;
+		text-transform: none;
+		text-align: left;
+		text-align: start;
+		font-variant: normal;
+		orphans: 3;
+		widows: 3;
+		page-break-before: avoid;
+	}
+	pre code,
+	code code {
+		font-size: 100%;
+	}
+
+	pre {
+		margin-top: 1em;
+		margin-bottom: 1em;
+		overflow: auto;
+	}
+
+/** Inline Code fragments *****************************************************/
+
+	/* Do something nice. */
+
+/******************************************************************************/
+/*                                    Links                                   */
+/******************************************************************************/
+
+/** General Hyperlinks ********************************************************/
+
+	/* We hyperlink a lot, so make it less intrusive */
+	a[href] {
+		color: #034575;
+		color: var(--a-normal-text);
+		text-decoration: underline #707070;
+		text-decoration: underline var(--a-normal-underline);
+		text-decoration-skip-ink: none;
+	}
+	a:visited {
+		color: #034575;
+		color: var(--a-visited-text);
+		text-decoration-color: #bbb;
+		text-decoration-color: var(--a-visited-underline);
+	}
+
+	/* Indicate interaction with the link */
+	a[href]:focus,
+	a[href]:hover {
+		text-decoration-thickness: 2px;
+	}
+	a[href]:active {
+		color: #c00;
+		color: var(--a-active-text);
+		text-decoration-color: #c00;
+		text-decoration-color: var(--a-active-underline);
+	}
+
+	/* Backout above styling for W3C logo */
+	.head .logo,
+	.head .logo a {
+		border: none;
+		text-decoration: none;
+		background: transparent;
+	}
+
+/******************************************************************************/
+/*                                    Images                                  */
+/******************************************************************************/
+
+	img {
+		border-style: none;
+	}
+
+	img, svg {
+		/* Intentionally not color-scheme aware. */
+		background: white;
+	}
+
+	/* For autogen numbers, add
+	  .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
+	*/
+
+	figure, .figure, .sidefigure {
+		page-break-inside: avoid;
+		text-align: center;
+		margin: 2.5em 0;
+	}
+	.figure img,	.sidefigure img,	figure img,
+	.figure object, .sidefigure object, figure object {
+		max-width: 100%;
+		margin: auto;
+		height: auto;
+	}
+	.figure pre, .sidefigure pre, figure pre {
+		text-align: left;
+		display: table;
+		margin: 1em auto;
+	}
+	.figure table, figure table {
+		margin: auto;
+	}
+	@media screen and (min-width: 20em) {
+		.sidefigure {
+			float: right;
+			width: 50%;
+			margin: 0 0 0.5em 0.5em;
+		}
+	}
+	.caption, figcaption, caption {
+		font-style: italic;
+		font-size: 90%;
+	}
+	.caption::before, figcaption::before, figcaption > .marker {
+		font-weight: bold;
+	}
+	.caption, figcaption {
+		counter-increment: figure;
+	}
+
+	/* DL list is indented 2em, but figure inside it is not */
+	dd > .figure, dd > figure { margin-left: -2em; }
+
+/******************************************************************************/
+/*                             Colored Boxes                                  */
+/******************************************************************************/
+
+	.issue, .note, .example, .assertion, .advisement, blockquote,
+	.amendment, .correction, .addition {
+		margin: 1em auto;
+		padding: .5em;
+		border: .5em;
+		border-left-style: solid;
+		page-break-inside: avoid;
+	}
+	span.issue, span.note {
+		padding: .1em .5em .15em;
+		border-right-style: solid;
+	}
+
+	blockquote > :first-child,
+	.note  > p:first-child,
+	.issue > p:first-child,
+	.amendment > p:first-child,
+	.correction > p:first-child,
+	.addition > p:first-child {
+		margin-top: 0;
+	}
+	blockquote > :last-child,
+	.note  > p:last-child,
+	.issue > p:last-child,
+	.amendment > p:last-child,
+	.correction > p:last-child,
+	.addition > p:last-child {
+		margin-bottom: 0;
+	}
+
+
+	.issue::before, .issue > .marker,
+	.example::before, .example > .marker,
+	.note::before, .note > .marker,
+	details.note > summary > .marker,
+	.amendment::before, .amendment > .marker,
+	details.amendment > summary > .marker,
+	.addition::before, .addition > .marker,
+	addition.amendment > summary > .marker,
+	.correction::before, .correction > .marker,
+	correction.amendment > summary > .marker
+	{
+		text-transform: uppercase;
+		padding-right: 1em;
+	}
+
+	.example::before, .example > .marker {
+		display: block;
+		padding-right: 0em;
+	}
+
+/** Blockquotes ***************************************************************/
+
+	blockquote {
+		border-color: silver;
+		border-color: var(--blockquote-border);
+		background: transparent;
+		background: var(--blockquote-bg);
+		color: currentcolor;
+		color: var(--blockquote-text);
+	}
+
+/** Open issue ****************************************************************/
+
+	.issue {
+		border-color: #e05252;
+		border-color: var(--issue-border);
+		background: #fbe9e9;
+		background: var(--issue-bg);
+		color: black;
+		color: var(--issue-text);
+		counter-increment: issue;
+		overflow: auto;
+	}
+	.issue::before, .issue > .marker {
+		color: #831616;
+		color: var(--issueheading-text);
+	}
+	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
+	  or use class="marker" to mark up the issue number in source. */
+
+/** Example *******************************************************************/
+
+	.example {
+		border-color: #e0cb52;
+		border-color: var(--example-border);
+		background: #fcfaee;
+		background: var(--example-bg);
+		color: black;
+		color: var(--example-text);
+		counter-increment: example;
+		overflow: auto;
+		clear: both;
+	}
+	.example::before, .example > .marker {
+		color: #574b0f;
+		color: var(--exampleheading-text);
+	}
+	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
+	  or use class="marker" to mark up the example number in source. */
+
+/** Non-normative Note ********************************************************/
+
+	.note {
+		border-color: #52e052;
+		border-color: var(--note-border);
+		background: #e9fbe9;
+		background: var(--note-bg);
+		color: black;
+		color: var(--note-text);
+		overflow: auto;
+	}
+
+	.note::before, .note > .marker,
+	details.note > summary {
+		color: hsl(120, 70%, 30%);
+		color: var(--noteheading-text);
+	}
+	/* Add .note::before { content: "Note "; } for autogen label,
+	  or use class="marker" to mark up the label in source. */
+
+	details.note[open] > summary {
+		border-bottom: 1px silver solid;
+		border-bottom: 1px var(--notesummary-underline) solid;
+	}
+
+/** Assertion Box *************************************************************/
+	/*  for assertions in algorithms */
+
+	.assertion {
+		border-color: #AAA;
+		border-color: var(--assertion-border);
+		background: #EEE;
+		background: var(--assertion-bg);
+		color: black;
+		color: var(--assertion-text);
+	}
+
+/** Advisement Box ************************************************************/
+	/*  for attention-grabbing normative statements */
+
+	.advisement {
+		border-color: orange;
+		border-color: var(--advisement-border);
+		border-style: none solid;
+		background: #fec;
+		background: var(--advisement-bg);
+		color: black;
+		color: var(--advisement-text);
+	}
+	strong.advisement {
+		display: block;
+		text-align: center;
+	}
+	.advisement::before, .advisement > .marker {
+		color: #b35f00;
+		color: var(--advisementheading-text);
+	}
+
+/** Amendment Box *************************************************************/
+
+	.amendment, .correction, .addition {
+		border-color: #330099;
+		border-color: var(--amendment-border);
+		background: #F5F0FF;
+		background: var(--amendment-bg);
+		color: black;
+		color: var(--amendment-text);
+	}
+	.amendment.proposed, .correction.proposed, .addition.proposed {
+		border-style: solid;
+		border-block-width: 0.25em;
+	}
+	.amendment::before, .amendment > .marker,
+	details.amendment > summary::before, details.amendment > summary > .marker,
+	.correction::before, .correction > .marker,
+	details.correction > summary::before, details.correction > summary > .marker,
+	.addition::before, .addition > .marker,
+	details.addition > summary::before, details.addition > summary > .marker {
+		color: #220066;
+		color: var(--amendmentheading-text);
+	}
+	.amendment.proposed::before, .amendment.proposed > .marker,
+	details.amendment.proposed > summary::before, details.amendment.proposed > summary > .marker,
+	.correction.proposed::before, .correction.proposed > .marker,
+	details.correction.proposed > summary::before, details.correction.proposed > summary > .marker,
+	.addition.proposed::before, .addition.proposed > .marker,
+	details.addition.proposed > summary::before, details.addition.proposed > summary > .marker {
+		font-weight: bold;
+	}
+
+/** Spec Obsoletion Notice ****************************************************/
+	/* obnoxious obsoletion notice for older/abandoned specs. */
+
+	details {
+		display: block;
+	}
+	summary {
+		font-weight: bolder;
+	}
+
+	.annoying-warning:not(details),
+	details.annoying-warning:not([open]) > summary,
+	details.annoying-warning[open] {
+		background: hsla(40,100%,50%,0.95);
+		background: var(--warning-bg);
+		color: black;
+		color: var(--warning-text);
+		padding: .75em 1em;
+		border: red;
+		border: var(--warning-border);
+		border-style: solid none;
+		box-shadow: 0 2px 8px black;
+		text-align: center;
+	}
+	.annoying-warning :last-child {
+		margin-bottom: 0;
+	}
+
+@media not print {
+	details.annoying-warning[open] {
+		position: fixed;
+		left: 0;
+		right: 0;
+		bottom: 2em;
+		z-index: 1000;
+	}
+}
+
+	details.annoying-warning:not([open]) > summary {
+		text-align: center;
+	}
+
+/** Entity Definition Boxes ***************************************************/
+
+	.def {
+		padding: .5em 1em;
+		background: #def;
+		background: var(--def-bg);
+		margin: 1.2em 0;
+		border-left: 0.5em solid #8ccbf2;
+		border-left: 0.5em solid var(--def-border);
+		color: black;
+		color: var(--def-text);
+	}
+
+/******************************************************************************/
+/*                                    Tables                                  */
+/******************************************************************************/
+
+	th, td {
+		text-align: left;
+		text-align: start;
+	}
+
+/** Property/Descriptor Definition Tables *************************************/
+
+	table.def {
+		/* inherits .def box styling, see above */
+		width: 100%;
+		border-spacing: 0;
+	}
+
+	table.def td,
+	table.def th {
+		padding: 0.5em;
+		vertical-align: baseline;
+		border-bottom: 1px solid #bbd7e9;
+		border-bottom: 1px solid var(--defrow-border);
+	}
+
+	table.def > tbody > tr:last-child th,
+	table.def > tbody > tr:last-child td {
+		border-bottom: 0;
+	}
+
+	table.def th {
+		font-style: italic;
+		font-weight: normal;
+		padding-left: 1em;
+		width: 3em;
+	}
+
+	/* For when values are extra-complex and need formatting for readability */
+	table td.pre {
+		white-space: pre-wrap;
+	}
+
+	/* A footnote at the bottom of a def table */
+	table.def td.footnote {
+		padding-top: 0.6em;
+	}
+	table.def td.footnote::before {
+		content: " ";
+		display: block;
+		height: 0.6em;
+		width: 4em;
+		border-top: thin solid;
+	}
+
+/** Data tables (and properly marked-up index tables) *************************/
+	/*
+		<table class="data"> highlights structural relationships in a table
+		when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)
+
+		Use class="complex data" for particularly complicated tables --
+		(This will draw more lines: busier, but clearer.)
+
+		Use class="long" on table cells with paragraph-like contents
+		(This will adjust text alignment accordingly.)
+		Alternately use class="longlastcol" on tables, to have the last column assume "long".
+	*/
+
+	table {
+		word-wrap: normal;
+		overflow-wrap: normal;
+		hyphens: manual;
+	}
+
+	table.data,
+	table.index {
+		margin: 1em auto;
+		border-collapse: collapse;
+		border: hidden;
+		width: 100%;
+	}
+	table.data caption,
+	table.index caption {
+		max-width: 50em;
+		margin: 0 auto 1em;
+	}
+
+	table.data td,  table.data th,
+	table.index td, table.index th {
+		padding: 0.5em 1em;
+		border-width: 1px;
+		border-color: silver;
+		border-color: var(--datacell-border);
+		border-top-style: solid;
+	}
+
+	table.data thead td:empty {
+		padding: 0;
+		border: 0;
+	}
+
+	table.data  thead,
+	table.index thead,
+	table.data  tbody,
+	table.index tbody {
+		border-bottom: 2px solid;
+	}
+
+	table.data colgroup,
+	table.index colgroup {
+		border-left: 2px solid;
+	}
+
+	table.data  tbody th:first-child,
+	table.index tbody th:first-child  {
+		border-right: 2px solid;
+		border-top: 1px solid silver;
+		border-top: 1px solid var(--datacell-border);
+		padding-right: 1em;
+	}
+
+	table.data th[colspan],
+	table.data td[colspan] {
+		text-align: center;
+	}
+
+	table.complex.data th,
+	table.complex.data td {
+		border: 1px solid silver;
+		border: 1px solid var(--datacell-border);
+		text-align: center;
+	}
+
+	table.data.longlastcol td:last-child,
+	table.data td.long {
+		vertical-align: baseline;
+		text-align: left;
+	}
+
+	table.data img {
+		vertical-align: middle;
+	}
+
+
+/*
+Alternate table alignment rules
+
+	table.data,
+	table.index {
+		text-align: center;
+	}
+
+	table.data  thead th[scope="row"],
+	table.index thead th[scope="row"] {
+		text-align: right;
+	}
+
+	table.data  tbody th:first-child,
+	table.index tbody th:first-child  {
+		text-align: right;
+	}
+
+Possible extra rowspan handling
+
+	table.data  tbody th[rowspan]:not([rowspan='1']),
+	table.index tbody th[rowspan]:not([rowspan='1']),
+	table.data  tbody td[rowspan]:not([rowspan='1']),
+	table.index tbody td[rowspan]:not([rowspan='1']) {
+		border-left: 1px solid silver;
+	}
+
+	table.data  tbody th[rowspan]:first-child,
+	table.index tbody th[rowspan]:first-child,
+	table.data  tbody td[rowspan]:first-child,
+	table.index tbody td[rowspan]:first-child{
+		border-left: 0;
+		border-right: 1px solid silver;
+	}
+*/
+
+/******************************************************************************/
+/*                                  Indices                                   */
+/******************************************************************************/
+
+
+/** Table of Contents *********************************************************/
+
+	.toc a {
+		/* More spacing; use padding to make it part of the click target. */
+		padding: 0.1rem 1px 0;
+		/* Larger, more consistently-sized click target */
+		display: block;
+		/* Switch to using border-bottom for underlines */
+		text-decoration: none;
+		border-bottom: 1px solid;
+		/* Reverse color scheme */
+		color: black;
+		color: var(--toclink-text);
+		border-color: #3980b5;
+		border-color: var(--toclink-underline);
+	}
+	.toc a:visited {
+		color: black;
+		color: var(--toclink-visited-text);
+		border-color: #054572;
+		border-color: var(--toclink-visited-underline);
+	}
+	.toc a:focus,
+	.toc a:hover {
+		background: rgba(75%, 75%, 75%, .25);
+		background: var(--a-hover-bg);
+		border-bottom-width: 3px;
+		margin-bottom: -2px;
+	}
+	.toc a:not(:focus):not(:hover) {
+		/* Allow colors to cascade through from link styling */
+		border-bottom-color: transparent;
+	}
+
+	.toc, .toc ol, .toc ul, .toc li {
+		list-style: none; /* Numbers must be inlined into source */
+		/* because generated content isn't search/selectable and markers can't do multilevel yet */
+		margin:  0;
+		padding: 0;
+	}
+	.toc {
+		line-height: 1.1em;
+	}
+
+	/* ToC not indented until third level, but font style & margins show hierarchy */
+	.toc > li			{ font-weight: bold;   }
+	.toc > li li		 { font-weight: normal; }
+	.toc > li li li	  { font-size:   95%;	}
+	.toc > li li li li	{ font-size:   90%;	}
+	.toc > li li li li li { font-size:   85%;	}
+
+	/* @supports not (display:grid) { */
+		.toc > li			{ margin: 1.5rem 0;	}
+		.toc > li li		 { margin: 0.3rem 0;	}
+		.toc > li li li	  { margin-left: 2rem;   }
+
+		/* Section numbers in a column of their own */
+		.toc .secno {
+			float: left;
+			width: 4rem;
+			white-space: nowrap;
+		}
+		.toc > li li li li .secno { font-size: 85%; }
+		.toc > li li li li li .secno { font-size: 100%; }
+
+		.toc li {
+			clear: both;
+		}
+
+		:not(li) > .toc			 { margin-left:  5rem; }
+		.toc .secno				 { margin-left: -5rem; }
+		.toc > li li li .secno	  { margin-left: -7rem; }
+		.toc > li li li li .secno	{ margin-left: -9rem; }
+		.toc > li li li li li .secno { margin-left: -11rem; }
+
+		/* Tighten up indentation in narrow ToCs */
+		@media (max-width: 30em) {
+			:not(li) > .toc			 { margin-left:  4rem; }
+			.toc .secno				 { margin-left: -4rem; }
+			.toc > li li li			 { margin-left:  1rem; }
+			.toc > li li li .secno	  { margin-left: -5rem; }
+			.toc > li li li li .secno	{ margin-left: -6rem; }
+			.toc > li li li li li .secno { margin-left: -7rem; }
+		}
+		/* Loosen it on wide screens */
+		@media screen and (min-width: 78em) {
+			body:not(.toc-inline) :not(li) > .toc			 { margin-left:  4rem; }
+			body:not(.toc-inline) .toc .secno				 { margin-left: -4rem; }
+			body:not(.toc-inline) .toc > li li li			 { margin-left:  1rem; }
+			body:not(.toc-inline) .toc > li li li .secno	  { margin-left: -5rem; }
+			body:not(.toc-inline) .toc > li li li li .secno	{ margin-left: -6rem; }
+			body:not(.toc-inline) .toc > li li li li li .secno { margin-left: -7rem; }
+	}
+	/* } */
+
+	@supports (display:grid) and (display:contents) {
+		/* Use #toc over .toc to override non-@supports rules. */
+		#toc {
+			display: grid;
+			align-content: start;
+			grid-template-columns: auto 1fr;
+			grid-column-gap: 1rem;
+			column-gap: 1rem;
+			grid-row-gap: .6rem;
+			row-gap: .6rem;
+		}
+		#toc h2 {
+			grid-column: 1 / -1;
+			margin-bottom: 0;
+		}
+		#toc ol,
+		#toc li,
+		#toc a {
+			display: contents;
+			/* Switch <a> to subgrid when supported */
+		}
+		#toc span {
+			margin: 0;
+		}
+		#toc > .toc > li > a > span {
+			/* The spans of the top-level list,
+			  comprising the first items of each top-level section. */
+			margin-top: 1.1rem;
+		}
+		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
+			grid-column: 1;
+			width: auto;
+			margin-left: 0;
+		}
+		#toc .content {
+			grid-column: 2;
+			width: auto;
+			margin-right: 1rem;
+		}
+		#toc .content:hover,
+		#toc .content:focus {
+			background: rgba(75%, 75%, 75%, .25);
+			background: var(--a-hover-bg);
+			border-bottom: 3px solid #054572;
+			border-bottom: 3px solid var(--toclink-underline);
+			margin-bottom: -3px;
+		}
+		#toc li li li .content {
+			margin-left: 1rem;
+		}
+		#toc li li li li .content {
+			margin-left: 2rem;
+		}
+	}
+
+
+/** Index *********************************************************************/
+
+	/* Index Lists: Layout */
+	ul.index	  { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
+	ul.index li	{ margin-left: 0; list-style: none; break-inside: avoid; }
+	ul.index li li { margin-left: 1em; }
+	ul.index dl	{ margin-top: 0; }
+	ul.index dt	{ margin: .2em 0 .2em 20px;}
+	ul.index dd	{ margin: .2em 0 .2em 40px;}
+	/* Index Lists: Typography */
+	ul.index ul,
+	ul.index dl { font-size: smaller; }
+	@media not print {
+		ul.index li a + span {
+			white-space: nowrap;
+			color: transparent; }
+		ul.index li a:hover + span,
+		ul.index li a:focus + span {
+			color: #707070;
+			color: var(--indexinfo-text);
+		}
+	}
+
+/** Index Tables *****************************************************/
+	/* See also the data table styling section, which this effectively subclasses */
+
+	table.index {
+		font-size: small;
+		border-collapse: collapse;
+		border-spacing: 0;
+		text-align: left;
+		margin: 1em 0;
+	}
+
+	table.index td,
+	table.index th {
+		padding: 0.4em;
+	}
+
+	table.index tr:hover td:not([rowspan]),
+	table.index tr:hover th:not([rowspan]) {
+		color: black;
+		color: var(--indextable-hover-text);
+		background: #f7f8f9;
+		background: var(--indextable-hover-bg);
+	}
+
+	/* The link in the first column in the property table (formerly a TD) */
+	table.index th:first-child a {
+		font-weight: bold;
+	}
+
+/** Outdated warning **********************************************************/
+
+.outdated-spec {
+	color: black;
+	color: var(--outdatedspec-text);
+	background-color: rgba(0,0,0,0.5);
+	background-color: var(--outdatedspec-bg);
+}
+
+.outdated-warning {
+	position: fixed;
+	bottom: 50%;
+	left: 0;
+	right: 0;
+	margin: 0 auto;
+	width: 50%;
+	background: maroon;
+	background: var(--outdated-bg);
+	color: white;
+	color: var(--outdated-text);
+	border-radius: 1em;
+	box-shadow: 0 0 1em red;
+	box-shadow: 0 0 1em var(--outdated-shadow);
+	padding: 2em;
+	text-align: center;
+	z-index: 2;
+}
+
+.outdated-warning a {
+	color: currentcolor;
+	background: transparent;
+}
+
+.edited-rec-warning {
+	background: darkorange;
+	background: var(--editedrec-bg);
+	box-shadow: 0 0 1em;
+}
+
+.outdated-warning button {
+	color: var(--outdated-text);
+	border-radius: 1em;
+	box-shadow: 0 0 1em red;
+	box-shadow: 0 0 1em var(--outdated-shadow);
+	padding: 2em;
+	text-align: center;
+	z-index: 2;
+}
+
+.outdated-warning a {
+	color: currentcolor;
+	background: transparent;
+}
+
+.edited-rec-warning {
+	background: darkorange;
+	background: var(--editedrec-bg);
+	box-shadow: 0 0 1em;
+}
+
+.outdated-warning button {
+	position: absolute;
+	top: 0;
+	right:0;
+	margin: 0;
+	border: 0;
+	padding: 0.25em 0.5em;
+	background: transparent;
+	color: white;
+	color: var(--outdated-text);
+	font:1em sans-serif;
+	text-align:center;
+}
+
+.outdated-warning span {
+	display: block;
+}
+
+.outdated-collapsed {
+	bottom: 0;
+	border-radius: 0;
+	width: 100%;
+	padding: 0;
+}
+
+/******************************************************************************/
+/*                                    Print                                   */
+/******************************************************************************/
+
+	@media print {
+		/* Pages have their own margins. */
+		html {
+			margin: 0;
+		}
+		/* Serif for print. */
+		body {
+			font-family: serif;
+		}
+
+		.outdated-warning {
+			position: absolute;
+			border-style: solid;
+			border-color: red;
+		}
+
+		.outdated-warning input {
+			display: none;
+		}
+	}
+	@page {
+		margin: 1.5cm 1.1cm;
+	}
+
+
+
+/******************************************************************************/
+/*                             Overflow Control                               */
+/******************************************************************************/
+
+	.figure .caption, .sidefigure .caption, figcaption {
+		/* in case figure is overlarge, limit caption to 50em */
+		max-width: 50rem;
+		margin-left: auto;
+		margin-right: auto;
+	}
+	.overlarge {
+		/* Magic to create good item positioning:
+		  "content column" is 50ems wide at max; less on smaller screens.
+		  Extra space (after ToC + content) is empty on the right.
+
+		  1. When item < content column, centers item in column.
+		  2. When content < item < available, left-aligns.
+		  3. When item > available, fills available + scroll bar.
+		*/
+		display: grid;
+		grid-template-columns: minmax(0, 50em);
+	}
+	.overlarge > table {
+		/* limit preferred width of table */
+		max-width: 50em;
+		margin-left: auto;
+		margin-right: auto;
+	}
+
+	@media (min-width: 55em) {
+		.overlarge {
+			margin-right: calc(13px + 26.5rem - 50vw);
+			max-width: none;
+		}
+	}
+	@media screen and (min-width: 78em) {
+		body:not(.toc-inline) .overlarge {
+			/* 30.5em body padding 50em content area */
+			margin-right: calc(40em - 50vw) !important;
+		}
+	}
+	@media screen and (min-width: 90em) {
+		body:not(.toc-inline) .overlarge {
+			/* 4em html margin 30.5em body padding 50em content area */
+			margin-right: calc(84.5em - 100vw) !important;
+		}
+	}
+
+	@media not print {
+		.overlarge {
+			overflow-x: auto;
+			/* See Lea Verou's explanation background-attachment:
+			* http://lea.verou.me/2012/04/background-attachment-local/
+			*
+			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
+						top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
+						top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
+						top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
+						white;
+			background-repeat: no-repeat;
+			*/
+		}
+	}
+</style>
+  <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
+  <link href="https://ngff.openmicroscopy.org/0.2/" rel="canonical">
+  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+<style>/* style-autolinks */
+
+.css.css, .property.property, .descriptor.descriptor {
+    color: var(--a-normal-text);
+    font-size: inherit;
+    font-family: inherit;
+}
+.css::before, .property::before, .descriptor::before {
+    content: "‘";
+}
+.css::after, .property::after, .descriptor::after {
+    content: "’";
+}
+.property, .descriptor {
+    /* Don't wrap property and descriptor names */
+    white-space: nowrap;
+}
+.type { /* CSS value <type> */
+    font-style: italic;
+}
+pre .property::before, pre .property::after {
+    content: "";
+}
+[data-link-type="property"]::before,
+[data-link-type="propdesc"]::before,
+[data-link-type="descriptor"]::before,
+[data-link-type="value"]::before,
+[data-link-type="function"]::before,
+[data-link-type="at-rule"]::before,
+[data-link-type="selector"]::before,
+[data-link-type="maybe"]::before {
+    content: "‘";
+}
+[data-link-type="property"]::after,
+[data-link-type="propdesc"]::after,
+[data-link-type="descriptor"]::after,
+[data-link-type="value"]::after,
+[data-link-type="function"]::after,
+[data-link-type="at-rule"]::after,
+[data-link-type="selector"]::after,
+[data-link-type="maybe"]::after {
+    content: "’";
+}
+
+[data-link-type].production::before,
+[data-link-type].production::after,
+.prod [data-link-type]::before,
+.prod [data-link-type]::after {
+    content: "";
+}
+
+[data-link-type=element],
+[data-link-type=element-attr] {
+    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
+    font-size: .9em;
+}
+[data-link-type=element]::before { content: "<" }
+[data-link-type=element]::after  { content: ">" }
+
+[data-link-type=biblio] {
+    white-space: pre;
+}</style>
+<style>/* style-colors */
+
+/* Any --*-text not paired with a --*-bg is assumed to have a transparent bg */
+:root {
+    color-scheme: light dark;
+
+    --text: black;
+    --bg: white;
+
+    --unofficial-watermark: url(https://www.w3.org/StyleSheets/TR/2016/logos/UD-watermark);
+
+    --logo-bg: #1a5e9a;
+    --logo-active-bg: #c00;
+    --logo-text: white;
+
+    --tocnav-normal-text: #707070;
+    --tocnav-normal-bg: var(--bg);
+    --tocnav-hover-text: var(--tocnav-normal-text);
+    --tocnav-hover-bg: #f8f8f8;
+    --tocnav-active-text: #c00;
+    --tocnav-active-bg: var(--tocnav-normal-bg);
+
+    --tocsidebar-text: var(--text);
+    --tocsidebar-bg: #f7f8f9;
+    --tocsidebar-shadow: rgba(0,0,0,.1);
+    --tocsidebar-heading-text: hsla(203,20%,40%,.7);
+
+    --toclink-text: var(--text);
+    --toclink-underline: #3980b5;
+    --toclink-visited-text: var(--toclink-text);
+    --toclink-visited-underline: #054572;
+
+    --heading-text: #005a9c;
+
+    --hr-text: var(--text);
+
+    --algo-border: #def;
+
+    --del-text: red;
+    --del-bg: transparent;
+    --ins-text: #080;
+    --ins-bg: transparent;
+
+    --a-normal-text: #034575;
+    --a-normal-underline: #bbb;
+    --a-visited-text: var(--a-normal-text);
+    --a-visited-underline: #707070;
+    --a-hover-bg: rgba(75%, 75%, 75%, .25);
+    --a-active-text: #c00;
+    --a-active-underline: #c00;
+
+    --blockquote-border: silver;
+    --blockquote-bg: transparent;
+    --blockquote-text: currentcolor;
+
+    --issue-border: #e05252;
+    --issue-bg: #fbe9e9;
+    --issue-text: var(--text);
+    --issueheading-text: #831616;
+
+    --example-border: #e0cb52;
+    --example-bg: #fcfaee;
+    --example-text: var(--text);
+    --exampleheading-text: #574b0f;
+
+    --note-border: #52e052;
+    --note-bg: #e9fbe9;
+    --note-text: var(--text);
+    --noteheading-text: hsl(120, 70%, 30%);
+    --notesummary-underline: silver;
+
+    --assertion-border: #aaa;
+    --assertion-bg: #eee;
+    --assertion-text: black;
+
+    --advisement-border: orange;
+    --advisement-bg: #fec;
+    --advisement-text: var(--text);
+    --advisementheading-text: #b35f00;
+
+    --warning-border: red;
+    --warning-bg: hsla(40,100%,50%,0.95);
+    --warning-text: var(--text);
+
+    --amendment-border: #330099;
+    --amendment-bg: #F5F0FF;
+    --amendment-text: var(--text);
+    --amendmentheading-text: #220066;
+
+    --def-border: #8ccbf2;
+    --def-bg: #def;
+    --def-text: var(--text);
+    --defrow-border: #bbd7e9;
+
+    --datacell-border: silver;
+
+    --indexinfo-text: #707070;
+
+    --indextable-hover-text: black;
+    --indextable-hover-bg: #f7f8f9;
+
+    --outdatedspec-bg: rgba(0, 0, 0, .5);
+    --outdatedspec-text: black;
+    --outdated-bg: maroon;
+    --outdated-text: white;
+    --outdated-shadow: red;
+
+    --editedrec-bg: darkorange;
+}</style>
+<style>/* style-counters */
+
+body {
+    counter-reset: example figure issue;
+}
+.issue {
+    counter-increment: issue;
+}
+.issue:not(.no-marker)::before {
+    content: "Issue " counter(issue);
+}
+
+.example {
+    counter-increment: example;
+}
+.example:not(.no-marker)::before {
+    content: "Example " counter(example);
+}
+.invalid.example:not(.no-marker)::before,
+.illegal.example:not(.no-marker)::before {
+    content: "Invalid Example" counter(example);
+}
+
+figcaption {
+    counter-increment: figure;
+}
+figcaption:not(.no-marker)::before {
+    content: "Figure " counter(figure) " ";
+}</style>
+<style>/* style-issues */
+
+a[href].issue-return {
+    float: right;
+    float: inline-end;
+    color: var(--issueheading-text);
+    font-weight: bold;
+    text-decoration: none;
+}
+</style>
+<style>/* style-md-lists */
+
+/* This is a weird hack for me not yet following the commonmark spec
+   regarding paragraph and lists. */
+[data-md] > :first-child {
+    margin-top: 0;
+}
+[data-md] > :last-child {
+    margin-bottom: 0;
+}</style>
+<style>/* style-selflinks */
+
+:root {
+    --selflink-text: white;
+    --selflink-bg: gray;
+    --selflink-hover-text: black;
+}
+.heading, .issue, .note, .example, li, dt {
+    position: relative;
+}
+a.self-link {
+    position: absolute;
+    top: 0;
+    left: calc(-1 * (3.5rem - 26px));
+    width: calc(3.5rem - 26px);
+    height: 2em;
+    text-align: center;
+    border: none;
+    transition: opacity .2s;
+    opacity: .5;
+}
+a.self-link:hover {
+    opacity: 1;
+}
+.heading > a.self-link {
+    font-size: 83%;
+}
+li > a.self-link {
+    left: calc(-1 * (3.5rem - 26px) - 2em);
+}
+dfn > a.self-link {
+    top: auto;
+    left: auto;
+    opacity: 0;
+    width: 1.5em;
+    height: 1.5em;
+    background: var(--selflink-bg);
+    color: var(--selflink-text);
+    font-style: normal;
+    transition: opacity .2s, background-color .2s, color .2s;
+}
+dfn:hover > a.self-link {
+    opacity: 1;
+}
+dfn > a.self-link:hover {
+    color: var(--selflink-hover-text);
+}
+
+a.self-link::before            { content: "¶"; }
+.heading > a.self-link::before { content: "§"; }
+dfn > a.self-link::before      { content: "#"; }
+</style>
+<style>/* style-syntax-highlighting */
+
+code.highlight { padding: .1em; border-radius: .3em; }
+pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
+
+.highlight:not(.idl) { background: rgba(0, 0, 0, .03); }
+c-[a] { color: #990055 } /* Keyword.Declaration */
+c-[b] { color: #990055 } /* Keyword.Type */
+c-[c] { color: #708090 } /* Comment */
+c-[d] { color: #708090 } /* Comment.Multiline */
+c-[e] { color: #0077aa } /* Name.Attribute */
+c-[f] { color: #669900 } /* Name.Tag */
+c-[g] { color: #222222 } /* Name.Variable */
+c-[k] { color: #990055 } /* Keyword */
+c-[l] { color: #000000 } /* Literal */
+c-[m] { color: #000000 } /* Literal.Number */
+c-[n] { color: #0077aa } /* Name */
+c-[o] { color: #999999 } /* Operator */
+c-[p] { color: #999999 } /* Punctuation */
+c-[s] { color: #a67f59 } /* Literal.String */
+c-[t] { color: #a67f59 } /* Literal.String.Single */
+c-[u] { color: #a67f59 } /* Literal.String.Double */
+c-[cp] { color: #708090 } /* Comment.Preproc */
+c-[c1] { color: #708090 } /* Comment.Single */
+c-[cs] { color: #708090 } /* Comment.Special */
+c-[kc] { color: #990055 } /* Keyword.Constant */
+c-[kn] { color: #990055 } /* Keyword.Namespace */
+c-[kp] { color: #990055 } /* Keyword.Pseudo */
+c-[kr] { color: #990055 } /* Keyword.Reserved */
+c-[ld] { color: #000000 } /* Literal.Date */
+c-[nc] { color: #0077aa } /* Name.Class */
+c-[no] { color: #0077aa } /* Name.Constant */
+c-[nd] { color: #0077aa } /* Name.Decorator */
+c-[ni] { color: #0077aa } /* Name.Entity */
+c-[ne] { color: #0077aa } /* Name.Exception */
+c-[nf] { color: #0077aa } /* Name.Function */
+c-[nl] { color: #0077aa } /* Name.Label */
+c-[nn] { color: #0077aa } /* Name.Namespace */
+c-[py] { color: #0077aa } /* Name.Property */
+c-[ow] { color: #999999 } /* Operator.Word */
+c-[mb] { color: #000000 } /* Literal.Number.Bin */
+c-[mf] { color: #000000 } /* Literal.Number.Float */
+c-[mh] { color: #000000 } /* Literal.Number.Hex */
+c-[mi] { color: #000000 } /* Literal.Number.Integer */
+c-[mo] { color: #000000 } /* Literal.Number.Oct */
+c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
+c-[sc] { color: #a67f59 } /* Literal.String.Char */
+c-[sd] { color: #a67f59 } /* Literal.String.Doc */
+c-[se] { color: #a67f59 } /* Literal.String.Escape */
+c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
+c-[si] { color: #a67f59 } /* Literal.String.Interpol */
+c-[sx] { color: #a67f59 } /* Literal.String.Other */
+c-[sr] { color: #a67f59 } /* Literal.String.Regex */
+c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
+c-[vc] { color: #0077aa } /* Name.Variable.Class */
+c-[vg] { color: #0077aa } /* Name.Variable.Global */
+c-[vi] { color: #0077aa } /* Name.Variable.Instance */
+c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
+</style>
+ <body class="h-entry">
+  <div class="head">
+    <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
+   <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Final Community Group Report, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
+   <div data-fill-with="spec-metadata">
+    <dl>
+     <dt>This version:
+     <dd><a class="u-url" href="https://ngff.openmicroscopy.org/0.2/">https://ngff.openmicroscopy.org/0.2/</a>
+     <dt>Issue Tracking:
+     <dd><a href="https://forum.image.sc/tag/ome-ngff">Forums</a>
+     <dd><a href="https://github.com/ome/ngff/issues/">GitHub</a>
+     <dt class="editor">Editors:
+     <dd class="editor p-author h-card vcard"><span class="p-name fn">Josh Moore</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+     <dd class="editor p-author h-card vcard"><span class="p-name fn">Sébastien Besson</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+    </dl>
+   </div>
+   <div data-fill-with="warning"></div>
+   <p class="copyright" data-fill-with="copyright">Copyright © 2022 <a href="https://www.openmicroscopy.org/"><abbr title="Open Microscopy Environment">OME</abbr></a><sup>®</sup> (<a href="https://dundee.ac.uk/"><abbr title="University of Dundee">U. Dundee</abbr></a>).
+OME trademark rules apply. </p>
+   <hr title="Separator for header">
+  </div>
+  <div class="p-summary" data-fill-with="abstract">
+   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
+   <p>This document contains next-generation file format (NGFF)
+
+specifications for storing bioimaging data in the cloud.
+All specifications are submitted to the https://image.sc community for review.</p>
+  </div>
+  <h2 class="no-num no-toc no-ref heading settled" id="sotd"><span class="content">Status of this document</span></h2>
+  <div data-fill-with="status">
+   <p></p>
+   <p>This is the 0.2 release of this specification. Migration scripts
+
+will be provided between numbered versions. Data written with the latest version
+(an "editor’s draft") will not necessarily be supported.</p>
+  </div>
+  <div data-fill-with="at-risk"></div>
+  <nav data-fill-with="table-of-contents" id="toc">
+   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
+   <ol class="toc" role="directory">
+    <li>
+     <a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
+     <ol class="toc">
+      <li><a href="#why-ngff"><span class="secno">1.1</span> <span class="content">Why "<span><abbr title="Next-generation file-format">NGFF</abbr></span>"?</span></a>
+      <li><a href="#ome-ngff"><span class="secno">1.2</span> <span class="content">OME-NGFF</span></a>
+     </ol>
+    <li>
+     <a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+     <ol class="toc">
+      <li><a href="#image-layout"><span class="secno">2.1</span> <span class="content">Images</span></a>
+      <li><a href="#hcs-layout"><span class="secno">2.2</span> <span class="content">High-content screening</span></a>
+     </ol>
+    <li>
+     <a href="#metadata"><span class="secno">3</span> <span class="content">Metadata</span></a>
+     <ol class="toc">
+      <li><a href="#multiscale-md"><span class="secno">3.1</span> <span class="content">"multiscales" metadata</span></a>
+      <li><a href="#omero-md"><span class="secno">3.2</span> <span class="content">"omero" metadata</span></a>
+      <li><a href="#labels-md"><span class="secno">3.3</span> <span class="content">"labels" metadata</span></a>
+      <li><a href="#label-md"><span class="secno">3.4</span> <span class="content">"image-label" metadata</span></a>
+      <li><a href="#plate-md"><span class="secno">3.5</span> <span class="content">"plate" metadata</span></a>
+      <li><a href="#well-md"><span class="secno">3.6</span> <span class="content">"well" metadata</span></a>
+     </ol>
+    <li><a href="#implementations"><span class="secno">4</span> <span class="content">Implementations</span></a>
+    <li><a href="#citing"><span class="secno">5</span> <span class="content">Citing</span></a>
+    <li><a href="#history"><span class="secno">6</span> <span class="content">Version History</span></a>
+    <li>
+     <a href="#w3c-conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
+     <ol class="toc">
+      <li><a href="#w3c-conventions"><span class="secno"></span> <span class="content">Document conventions</span></a>
+      <li><a href="#w3c-conformant-algorithms"><span class="secno"></span> <span class="content">Conformant Algorithms</span></a>
+     </ol>
+    <li>
+     <a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
+     <ol class="toc">
+      <li><a href="#index-defined-here"><span class="secno"></span> <span class="content">Terms defined by this specification</span></a>
+     </ol>
+    <li>
+     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
+     <ol class="toc">
+      <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
+      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
+     </ol>
+   </ol>
+  </nav>
+  <main>
+   <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
+   <p>Bioimaging science is at a crossroads. Currently, the drive to acquire more,
+larger, preciser spatial measurements is unfortunately at odds with our ability
+to structure and share those measurements with others. During a global pandemic
+more than ever, we believe fervently that global, collaborative discovery as
+opposed to the post-publication, "data-on-request" mode of operation is the
+path forward. Bioimaging data should be shareable via open and commercial cloud
+resources without the need to download entire datasets.</p>
+   <p>At the moment, that is not the norm. The plethora of data formats produced by
+imaging systems are ill-suited to remote sharing. Individual scientists
+typically lack the infrastructure they need to host these data themselves. When
+they acquire images from elsewhere, time-consuming translations and data
+cleaning are needed to interpret findings. Those same costs are multiplied when
+gathering data into online repositories where curator time can be the limiting
+factor before publication is possible. Without a common effort, each lab or
+resource is left building the tools they need and maintaining that
+infrastructure often without dedicated funding.</p>
+   <p>This document defines a specification for bioimaging data to make it possible
+to enable the conversion of proprietary formats into a common, cloud-ready one.
+Such next-generation file formats layout data so that individual portions, or
+"chunks", of large data are reference-able eliminating the need to download
+entire datasets.</p>
+   <h3 class="heading settled" data-level="1.1" id="why-ngff"><span class="secno">1.1. </span><span class="content">Why "<dfn data-dfn-type="dfn" data-export id="ngff"><abbr title="Next-generation file-format">NGFF</abbr><a class="self-link" href="#ngff"></a></dfn>"?</span><a class="self-link" href="#why-ngff"></a></h3>
+   <p>A short description of what is needed for an imaging format is "a hierarchy
+of n-dimensional (dense) arrays with metadata". This combination of features
+is certainly provided by <dfn data-dfn-type="dfn" data-export id="hdf5"><abbr title="Hierarchical Data Format 5">HDF5</abbr><a class="self-link" href="#hdf5"></a></dfn> from the <a href="https://www.hdfgroup.org">HDF Group</a>, which a number of
+bioimaging formats do use. HDF5 and other larger binary structures, however,
+are ill-suited for storage in the cloud where accessing individual chunks
+of data by name rather than seeking through a large file is at the heart of
+parallelization.</p>
+   <p>As a result, a number of formats have been developed more recently which provide
+the basic data structure of an HDF5 file, but do so in a more cloud-friendly way.
+In the <a href="https://pydata.org/">PyData</a> community, the Zarr <a data-link-type="biblio" href="#biblio-zarr">[zarr]</a> format was developed
+for easily storing collections of <a href="https://numpy.org/">NumPy</a> arrays. In the <a href="https://imagej.net/">ImageJ</a> community, N5 <a data-link-type="biblio" href="#biblio-n5">[n5]</a> was developed to work around
+the limitations of HDF5 ("N5" was originally short for "Not-HDF5").
+Both of these formats permit storing individual chunks of data either locally in
+separate files or in cloud-based object stores as separate keys.</p>
+   <p>A <a href="https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html">current effort</a> is underway to unify the two similar specifications to provide a single binary
+specification. The editor’s draft will soon be entering a <a href="https://github.com/zarr-developers/zarr-specs/issues/101">request for comments (RFC)</a> phase with the goal of having a first version early in 2021. As that
+process comes to an end, this document will be updated.</p>
+   <h3 class="heading settled" data-level="1.2" id="ome-ngff"><span class="secno">1.2. </span><span class="content">OME-NGFF</span><a class="self-link" href="#ome-ngff"></a></h3>
+   <p>The conventions and specifications defined in this document are designed to
+enable next-generation file formats to represent the same bioimaging data
+that can be represented in <a href="http://www.openmicroscopy.org/ome-files/">OME-TIFF</a> and beyond. However, the conventions will also be usable by HDF5 and other sufficiently advanced
+binary containers. Eventually, we hope, the moniker "next-generation" will no longer be
+applicable, and this will simply be the most efficient, common, and useful representation
+of bioimaging data, whether during acquisition or sharing in the cloud.</p>
+   <p class="note" role="note"><span>Note:</span> The following text makes use of OME-Zarr <a data-link-type="biblio" href="#biblio-ome-zarr-py">[ome-zarr-py]</a>, the current prototype implementation,
+for all examples.</p>
+   <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. </span><span class="content">On-disk (or in-cloud) layout</span><a class="self-link" href="#on-disk"></a></h2>
+   <p>An overview of the layout of an OME-Zarr fileset should make
+understanding the following metadata sections easier. The hierarchy
+is represented here as it would appear locally but could equally
+be stored on a web server to be accessed via HTTP or in object storage
+like S3 or GCS.</p>
+   <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secno">2.1. </span><span class="content">Images</span><a class="self-link" href="#image-layout"></a></h3>
+   <p>The following layout describes the expected Zarr hierarchy for images with
+multiple levels of resolutions and optionally associated labels.</p>
+<pre>.                             # Root folder, potentially in S3,
+│                             # with a flat list of images by image ID.
+│
+├── 123.zarr                  # One image (id=123) converted to Zarr.
+│
+└── 456.zarr                  # Another image (id=456) converted to Zarr.
+    │
+    ├── .zgroup               # Each image is a Zarr group, or a folder, of other groups and arrays.
+    ├── .zattrs               # Group level attributes are stored in the .zattrs file and include
+    │                         #  "multiscales" and "omero" below)
+    │
+    ├── 0                     # Each multiscale level is stored as a separate Zarr array,
+    │   ...                   # which is a folder containing chunk files which compose the array.
+    ├── n                     # The name of the array is arbitrary with the ordering defined by
+    │   │                     # by the "multiscales" metadata, but is often a sequence starting at 0.
+    │   │
+    │   ├── .zarray           # All image arrays are 5-dimensional
+    │   │                     # with dimension order (t, c, z, y, x).
+    │   │
+    │   └─ t                  # Chunks are stored with the nested directory layout.
+    │      └─ c               # All but the last chunk element are stored as directories.
+    │         └─ z            # The terminal chunk is a file. Together the directory and file names
+    │            └─ y         # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
+    │               └─ x      # will be &lt;code data-opaque bs-autolink-syntax='`dimension_size / chunk_size`'>dimension_size / chunk_size&lt;/code>.
+    │
+    └── labels
+        │
+        ├── .zgroup           # The labels group is a container which holds a list of labels to make the objects easily discoverable
+        │
+        ├── .zattrs           # All labels will be listed in &lt;code data-opaque bs-autolink-syntax='`.zattrs`'>.zattrs&lt;/code> e.g. &lt;code data-opaque bs-autolink-syntax='`{ &amp;quot;labels&amp;quot;: [ &amp;quot;original/0&amp;quot; ] }`'>{ "labels": [ "original/0" ] }&lt;/code>
+        │                     # Each dimension of the label &lt;code data-opaque bs-autolink-syntax='`(t, c, z, y, x)`'>(t, c, z, y, x)&lt;/code> should be either the same as the
+        │                     # corresponding dimension of the image, or &lt;code data-opaque bs-autolink-syntax='`1`'>1&lt;/code> if that dimension of the label
+        │                     # is irrelevant.
+        │
+        └── original          # Intermediate folders are permitted but not necessary and currently contain no extra metadata.
+            │
+            └── 0             # Multiscale, labeled image. The name is unimportant but is registered in the "labels" group above.
+                ├── .zgroup   # Zarr Group which is both a multiscaled image as well as a labeled image.
+                ├── .zattrs   # Metadata of the related image and as well as display information under the "image-label" key.
+                │
+                ├── 0         # Each multiscale level is stored as a separate Zarr array, as above, but only integer values
+                │   ...       # are supported.
+                └── n
+</pre>
+   <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno">2.2. </span><span class="content">High-content screening</span><a class="self-link" href="#hcs-layout"></a></h3>
+   <p>The following specification defines the hierarchy for a high-content screening
+dataset. Three groups must be defined above the images:</p>
+   <ul>
+    <li data-md>
+     <p>the group above the images defines the well and MUST implement the <a href="#well-md">well specification</a>. All images contained in a well are fields
+of view of the same well</p>
+    <li data-md>
+     <p>the group above the well defines a row of wells</p>
+    <li data-md>
+     <p>the group above the well row defines an entire plate i.e. a two-dimensional
+collection of wells organized in rows and columns. It MUST implement the <a href="#plate-md">plate specification</a></p>
+   </ul>
+<pre>.                             # Root folder, potentially in S3,
+│
+└── 5966.zarr                 # One plate (id=5966) converted to Zarr
+    ├── .zgroup
+    ├── .zattrs               # Implements "plate" specification
+    ├── A                     # First row of the plate
+    │   ├── .zgroup
+    │   │
+    │   ├── 1                 # First column of row A
+    │   │   ├── .zgroup
+    │   │   ├── .zattrs       # Implements "well" specification
+    │   │   │
+    │   │   ├── 0             # First field of view of well A1
+    │   │   │   │
+    │   │   │   ├── .zgroup
+    │   │   │   ├── .zattrs   # Implements "multiscales", "omero"
+    │   │   │   ├── 0
+    │   │   │   │   ...       # Resolution levels
+    │   │   │   ├── n
+    │   │   │   └── labels    # Labels (optional)
+    │   │   ├── ...           # Fields of view
+    │   │   └── m
+    │   ├── ...               # Columns
+    │   └── 12
+    ├── ...                   # Rows
+    └── H
+</pre>
+   <h2 class="heading settled" data-level="3" id="metadata"><span class="secno">3. </span><span class="content">Metadata</span><a class="self-link" href="#metadata"></a></h2>
+   <p>The various <code>.zattrs</code> files throughout the above array hierarchy may contain metadata
+keys as specified below for discovering certain types of data, especially images.</p>
+   <h3 class="heading settled" data-level="3.1" id="multiscale-md"><span class="secno">3.1. </span><span class="content">"multiscales" metadata</span><a class="self-link" href="#multiscale-md"></a></h3>
+   <p>Metadata about the multiple resolution representations of the image can be
+found under the "multiscales" key in the group-level metadata.</p>
+   <p>"multiscales" contains a list of dictionaries where each entry describes a multiscale image.</p>
+   <p>Each dictionary contained in the list MUST contain the field "datasets", which is a list of dictionaries describing
+the arrays storing the individual resolution levels.
+Each dictionary in "datasets" MUST contain the field "path", whose value contains the path to the array for this resolution relative
+to the current zarr group. The "path"s MUST be ordered from largest (i.e. highest resolution) to smallest.</p>
+   <p>It SHOULD contain the field "name".</p>
+   <p>It SHOULD contain the field "version", which indicates the version of the
+multiscale metadata of this image (current version is 0.2).</p>
+   <p>It SHOULD contain the field "type", which gives the type of downscaling method used to generate the multiscale image pyramid.</p>
+   <p>It SHOULD contain the field "metadata", which contains a dictionary with additional information about the downscaling method.</p>
+<pre class="language-json highlight"><c- p>{</c->
+    <c- f>"multiscales"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"version"</c-><c- p>:</c-> <c- u>"0.2"</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"example"</c-><c- p>,</c->
+            <c- f>"datasets"</c-><c- p>:</c-> <c- p>[</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c-><c- p>},</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c-><c- p>},</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c-><c- p>}</c->
+            <c- p>],</c->
+            <c- f>"type"</c-><c- p>:</c-> <c- u>"gaussian"</c-><c- p>,</c->
+            <c- f>"metadata"</c-><c- p>:</c-> <c- p>{</c->                                       # <c- kc>t</c->he <c- kc>f</c->ields i<c- kc>n</c-> me<c- kc>ta</c->da<c- kc>ta</c-> depe<c- kc>n</c->d o<c- kc>n</c-> <c- kc>t</c->he dow<c- kc>ns</c->cali<c- kc>n</c->g impleme<c- kc>ntat</c->io<c- kc>n</c->
+                <c- f>"method"</c-><c- p>:</c-> <c- u>"skimage.transform.pyramid_gaussian"</c-><c- p>,</c-> # here<c- p>,</c-> <c- kc>t</c->he param<c- kc>ters</c-> passed <c- kc>t</c->o <c- kc>t</c->he skimage <c- kc>fun</c->c<c- kc>t</c->io<c- kc>n</c-> are give<c- kc>n</c->
+                <c- f>"version"</c-><c- p>:</c-> <c- u>"0.16.1"</c-><c- p>,</c->
+                <c- f>"args"</c-><c- p>:</c-> <c- u>"[true]"</c-><c- p>,</c->
+                <c- f>"kwargs"</c-><c- p>:</c-> <c- p>{</c-><c- f>"multichannel"</c-><c- p>:</c-> <c- kc>true</c-><c- p>}</c->
+            <c- p>}</c->
+        <c- p>}</c->
+    <c- p>]</c->
+<c- p>}</c->
+</pre>
+   <p>If only one multiscale is provided, use it. Otherwise, the user can choose by
+name, using the first multiscale as a fallback:</p>
+<pre class="language-python highlight"><c- n>datasets</c-> <c- o>=</c-> <c- p>[]</c->
+<c- k>for</c-> <c- n>named</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>:</c->
+    <c- k>if</c-> <c- n>named</c-><c- p>[</c-><c- u>"name"</c-><c- p>]</c-> <c- o>==</c-> <c- u>"3D"</c-><c- p>:</c->
+        <c- n>datasets</c-> <c- o>=</c-> <c- p>[</c-><c- n>x</c-><c- p>[</c-><c- u>"path"</c-><c- p>]</c-> <c- k>for</c-> <c- n>x</c-> <c- ow>in</c-> <c- n>named</c-><c- p>[</c-><c- u>"datasets"</c-><c- p>]]</c->
+        <c- k>break</c->
+<c- k>if</c-> <c- ow>not</c-> <c- n>datasets</c-><c- p>:</c->
+    <c- c1># Use the first by default. Or perhaps choose based on chunk size.</c->
+    <c- n>datasets</c-> <c- o>=</c-> <c- p>[</c-><c- n>x</c-><c- p>[</c-><c- u>"path"</c-><c- p>]</c-> <c- k>for</c-> <c- n>x</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>[</c-><c- mi>0</c-><c- p>][</c-><c- u>"datasets"</c-><c- p>]]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3.2. </span><span class="content">"omero" metadata</span><a class="self-link" href="#omero-md"></a></h3>
+   <p>Information specific to the channels of an image and how to render it
+can be found under the "omero" key in the group-level metadata:</p>
+<pre class="language-json highlight"><c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->                              # ID i<c- kc>n</c-> OMERO
+<c- f>"name"</c-><c- p>:</c-> <c- u>"example.tif"</c-><c- p>,</c->                # Name as show<c- kc>n</c-> i<c- kc>n</c-> <c- kc>t</c->he UI
+<c- f>"version"</c-><c- p>:</c-> <c- u>"0.2"</c-><c- p>,</c->                     # Curre<c- kc>nt</c-> versio<c- kc>n</c->
+<c- f>"channels"</c-><c- p>:</c-> <c- p>[</c->                         # Array ma<c- kc>t</c->chi<c- kc>n</c->g <c- kc>t</c->he c dime<c- kc>ns</c->io<c- kc>n</c-> size
+    <c- p>{</c->
+        <c- f>"active"</c-><c- p>:</c-> <c- kc>true</c-><c- p>,</c->
+        <c- f>"coefficient"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"color"</c-><c- p>:</c-> <c- u>"0000FF"</c-><c- p>,</c->
+        <c- f>"family"</c-><c- p>:</c-> <c- u>"linear"</c-><c- p>,</c->
+        <c- f>"inverted"</c-><c- p>:</c-> <c- kc>false</c-><c- p>,</c->
+        <c- f>"label"</c-><c- p>:</c-> <c- u>"LaminB1"</c-><c- p>,</c->
+        <c- f>"window"</c-><c- p>:</c-> <c- p>{</c->
+            <c- f>"end"</c-><c- p>:</c-> <c- mi>1500</c-><c- p>,</c->
+            <c- f>"max"</c-><c- p>:</c-> <c- mi>65535</c-><c- p>,</c->
+            <c- f>"min"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"start"</c-><c- p>:</c-> <c- mi>0</c->
+        <c- p>}</c->
+    <c- p>}</c->
+<c- p>],</c->
+<c- f>"rdefs"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # Firs<c- kc>t</c-> <c- kc>t</c->imepoi<c- kc>nt</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # Firs<c- kc>t</c-> Z sec<c- kc>t</c->io<c- kc>n</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"model"</c-><c- p>:</c-> <c- u>"color"</c->                  # <c- u>"color"</c-> or <c- u>"greyscale"</c->
+<c- p>}</c->
+</pre>
+   <p>See https://docs.openmicroscopy.org/omero/5.6.1/developers/Web/WebGateway.html#imgdata
+for more information.</p>
+   <h3 class="heading settled" data-level="3.3" id="labels-md"><span class="secno">3.3. </span><span class="content">"labels" metadata</span><a class="self-link" href="#labels-md"></a></h3>
+   <p>The special group "labels" found under an image Zarr contains the key <code>labels</code> containing
+the paths to label objects which can be found underneath the group:</p>
+<pre class="language-json highlight"><c- p>{</c->
+  <c- f>"labels"</c-><c- p>:</c-> <c- p>[</c->
+    <c- u>"orphaned/0"</c->
+  <c- p>]</c->
+<c- p>}</c->
+</pre>
+   <p>Unlisted groups MAY be labels.</p>
+   <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3.4. </span><span class="content">"image-label" metadata</span><a class="self-link" href="#label-md"></a></h3>
+   <p>Groups containing the <code>image-label</code> dictionary represent an image segmentation
+in which each unique pixel value represents a separate segmented object. <code>image-label</code> groups MUST also contain <code>multiscales</code> metadata and the two
+"datasets" series MUST have the same number of entries.</p>
+   <p>The <code>colors</code> key defines a list of JSON objects describing the unique label
+values. Each entry in the list MUST contain the key "label-value" with the
+pixel value for that label. Additionally, the "rgba" key MAY be present, the
+value for which is an RGBA unsigned-int 4-tuple: <code>[uint8, uint8, uint8, uint8]</code> All <code>label-value</code>s must be unique. Clients who choose to not throw an error
+should ignore all except the _last_ entry.</p>
+   <p>Some implementations may represent overlapping labels by using a specially assigned
+value, for example the highest integer available in the pixel range.</p>
+   <p>The <code>properties</code> key defines a list of JSON objects which also describes the unique
+label values. Each entry in the list MUST contain the key "label-value" with the 
+pixel value for that label. Additionally, an arbitrary number of key-value pairs 
+MAY be present for each label value denoting associated metadata. Not all label 
+values must share the same key-value pairs within the properties list.</p>
+   <p>The <code>source</code> key is an optional dictionary which contains information on the
+image the label is associated with. If included it MAY include a key <code>image</code> whose value is the relative path to a Zarr image group. The default value is
+"../../" since most labels are stored under a subgroup named "labels/" (see
+above).</p>
+<pre class="language-json highlight"><c- f>"image-label"</c-><c- p>:</c->
+  <c- p>{</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.2"</c-><c- p>,</c->
+    <c- f>"colors"</c-><c- p>:</c-> <c- p>[</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"rgba"</c-><c- p>:</c-> <c- p>[</c-><c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>0</c-><c- p>]</c->
+      <c- p>},</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+        <c- f>"rgba"</c-><c- p>:</c-> <c- p>[</c-><c- mi>0</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>128</c-><c- p>]</c->
+      <c- p>},</c->
+      ...
+      <c- p>],</c->
+    <c- f>"properties"</c-><c- p>:</c-> <c- p>[</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1200</c-><c- p>,</c->
+        <c- f>"class"</c-><c- p>:</c-> <c- u>"foo"</c->
+
+      <c- p>},</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1650</c->
+      <c- p>},</c->
+      ...
+      <c- p>]</c->
+  <c- p>},</c->
+  <c- f>"source"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"image"</c-><c- p>:</c-> <c- u>"../../"</c->
+  <c- p>}</c->
+<c- p>]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.5" id="plate-md"><span class="secno">3.5. </span><span class="content">"plate" metadata</span><a class="self-link" href="#plate-md"></a></h3>
+   <p>For high-content screening datasets, the plate layout can be found under the
+custom attributes of the plate group under the <code>plate</code> key.</p>
+   <dl>
+    <dt><strong>acquisitions</strong>
+    <dd>An optional list of JSON objects defining the acquisitions for a given
+      plate. Each acquisition object MUST contain an <code>id</code> key providing an
+      unique identifier within the context of the plate to which fields of
+      view can refer to. It SHOULD contain  a <code>name</code> key identifying the name
+      of the acquisition. It SHOULD contain a <code>maximumfieldcount</code> key
+      indicating the maximum number of fields of view for the acquisition. It
+      MAY contain a <code>description</code> key providing a description for the
+      acquisition. It MAY contain a <code>startime</code> and/or <code>endtime</code> key specifying
+      the start and/or end timestamp of the acquisition using an epoch
+      string.
+    <dt><strong>columns</strong>
+    <dd>A list of JSON objects defining the columns of the plate. Each column
+      object defines the properties of the column at the index of the object
+      in the list. If not empty, it MUST contain a <code>name</code> key specifying the
+      column name.
+    <dt><strong>field_count</strong>
+    <dd>An integer defining the maximum number of fields per view across all
+      wells.
+    <dt><strong>name</strong>
+    <dd>A string defining the name of the plate.
+    <dt><strong>rows</strong>
+    <dd>A list of JSON objects defining the rows of the plate. Each row object
+      defines the properties of the row at the index of the object in the
+      list. If not empty, it MUST contain a <code>name</code> key specifying the row
+      name.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+    <dt><strong>wells</strong>
+    <dd>A list of JSON objects defining the wells of the plate. Each well object 
+      MUST contain a <code>path</code> key identifying the path to the well subgroup.
+   </dl>
+   <p>For example the following JSON object defines a plate with two acquisition and
+6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion.</p>
+<pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_01(2012-07-31_10-41-12)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343731272000</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_02(201207-31_11-56-41)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343735801000</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"columns"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"field_count"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+    <c- f>"name"</c-><c- p>:</c-> <c- u>"test"</c-><c- p>,</c->
+    <c- f>"rows"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"A"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"B"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.2"</c-><c- p>,</c->
+    <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/3"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/3"</c->
+        <c- p>}</c->
+    <c- p>]</c->
+  <c- p>}</c->
+</pre>
+   <h3 class="heading settled" data-level="3.6" id="well-md"><span class="secno">3.6. </span><span class="content">"well" metadata</span><a class="self-link" href="#well-md"></a></h3>
+   <p>For high-content screening datasets, the metadata about all fields of views
+under a given  well can be found under the "well" key in the attributes of the
+well group.</p>
+   <dl>
+    <dt><strong>images</strong>
+    <dd>A list of JSON objects defining the fields of views for a given well.
+      Each object MUST contain a <code>path</code> key identifying the path to the
+      field of view. If multiple acquisitions were performed in the plate, it  
+      SHOULD contain an <code>acquisition</code> key identifying the id of the 
+      acquisition which must match one of acquisition JSON objects defined in
+      the plate metadata.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+   </dl>
+   <p>For example the following JSON object defines a well with four fields of
+views. The first two fields of view were part of the first acquisition while
+the last two fields of view were part of the second acquisition.</p>
+<pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.2"</c->
+  <c- p>}</c->
+</pre>
+   <h2 class="heading settled" data-level="4" id="implementations"><span class="secno">4. </span><span class="content">Implementations</span><a class="self-link" href="#implementations"></a></h2>
+   <p>Projects which support reading and/or writing OME-NGFF data include:</p>
+   <dl>
+    <dt><strong><a href="https://github.com/mobie/bigdataviewer-ome-zarr">bigdataviewer-ome-zarr</a></strong>
+    <dd>Fiji-plugin for reading OME-Zarr.
+    <dt><strong><a href="https://github.com/glencoesoftware/bioformats2raw">bioformats2raw</a></strong>
+    <dd>A performant, Bio-Formats image file format converter.
+    <dt><strong><a href="https://github.com/ome/omero-ms-zarr">omero-ms-zarr</a></strong>
+    <dd>A microservice for OMERO.server that converts images stored in OMERO to OME-Zarr files on the fly, served via a web API.
+    <dt><strong><a href="https://github.com/IDR/idr-zarr-tools">idr-zarr-tools</a></strong>
+    <dd>A full workflow demonstrating the conversion of IDR images to OME-Zarr images on S3.
+    <dt><strong><a href="https://github.com/ome/omero-cli-zarr">OMERO CLI Zarr plugin</a></strong>
+    <dd>An OMERO CLI plugin that converts images stored in OMERO.server into a local Zarr file.
+    <dt><strong><a href="https://github.com/ome/ome-zarr-py">ome-zarr-py</a></strong>
+    <dd>A napari plugin for reading ome-zarr files.
+    <dt><strong><a href="https://github.com/hms-dbmi/vizarr/">vizarr</a></strong>
+    <dd>A minimal, purely client-side program for viewing Zarr-based images with Viv &amp; ImJoy.
+   </dl>
+   <p><img alt="Diagram of related projects" src="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/images/zarr-ome-diagram.png"></p>
+   <p>All implementations prevent an equivalent representation of a dataset which can be downloaded or uploaded freely. An interactive
+version of this diagram is available from the <a href="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/">OME2020 Workshop</a>.
+Mouseover the blackboxes representing the implementations above to get a quick tip on how to use them.</p>
+   <p class="note" role="note"><span>Note:</span> If you would like to see your project listed, please open an issue or PR on the <a href="https://github.com/ome/ngff">ome/ngff</a> repository.</p>
+   <h2 class="heading settled" data-level="5" id="citing"><span class="secno">5. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
+   <p><a href="https://ngff.openmicroscopy.org/0.2">Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a> J. Moore, <em>et al</em>. Editors. Open Microscopy Environment Consortium, 29 March, 2021.
+This edition of the specification is <a href="https://ngff.openmicroscopy.org/0.2/]">https://ngff.openmicroscopy.org/0.2/</a>.
+The latest edition is available at <a href="https://ngff.openmicroscopy.org/latest/">https://ngff.openmicroscopy.org/latest/</a>. <a href="https://doi.org/10.5281/zenodo.4282107">(doi:10.5281/zenodo.4282107)</a></p>
+   <h2 class="heading settled" data-level="6" id="history"><span class="secno">6. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
+   <table>
+    <thead>
+     <tr>
+      <td>Revision
+      <td>Date
+      <td>Description
+    <tbody>
+     <tr>
+      <td>0.2.0
+      <td>2021-03-29
+      <td>Change chunk dimension separator to "/" 
+     <tr>
+      <td>0.1.4
+      <td>2020-11-26
+      <td>Add HCS specification 
+     <tr>
+      <td>0.1.3
+      <td>2020-09-14
+      <td>Add labels specification 
+     <tr>
+      <td>0.1.2 
+      <td>2020-05-07
+      <td>Add description of "omero" metadata 
+     <tr>
+      <td>0.1.1 
+      <td>2020-05-06
+      <td>Add info on the ordering of resolutions 
+     <tr>
+      <td>0.1.0 
+      <td>2020-04-20
+      <td>First version for internal demo 
+   </table>
+  </main>
+  <div data-fill-with="conformance">
+   <h2 class="no-ref no-num heading settled" id="w3c-conformance"><span class="content">Conformance</span><a class="self-link" href="#w3c-conformance"></a></h2>
+   <h3 class="no-ref no-num heading settled" id="w3c-conventions"><span class="content">Document conventions</span><a class="self-link" href="#w3c-conventions"></a></h3>
+   <p>Conformance requirements are expressed
+    with a combination of descriptive assertions
+    and RFC 2119 terminology.
+    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
+    in the normative parts of this document
+    are to be interpreted as described in RFC 2119.
+    However, for readability,
+    these words do not appear in all uppercase letters in this specification. </p>
+   <p>All of the text of this specification is normative
+    except sections explicitly marked as non-normative, examples, and notes. <a data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a> </p>
+   <p>Examples in this specification are introduced with the words “for example”
+    or are set apart from the normative text
+    with <code>class="example"</code>,
+    like this: </p>
+   <div class="example" id="w3c-example">
+    <a class="self-link" href="#w3c-example"></a> 
+    <p>This is an example of an informative example. </p>
+   </div>
+   <p>Informative notes begin with the word “Note”
+    and are set apart from the normative text
+    with <code>class="note"</code>,
+    like this: </p>
+   <p class="note" role="note">Note, this is an informative note. </p>
+   <h3 class="no-ref no-num heading settled" id="w3c-conformant-algorithms"><span class="content">Conformant Algorithms</span><a class="self-link" href="#w3c-conformant-algorithms"></a></h3>
+   <p>Requirements phrased in the imperative as part of algorithms
+    (such as "strip any leading space characters"
+    or "return false and abort these steps")
+    are to be interpreted with the meaning of the key word
+    ("must", "should", "may", etc)
+    used in introducing the algorithm. </p>
+   <p>Conformance requirements phrased as algorithms or specific steps
+    can be implemented in any manner,
+    so long as the end result is equivalent.
+    In particular, the algorithms defined in this specification
+    are intended to be easy to understand
+    and are not intended to be performant.
+    Implementers are encouraged to optimize. </p>
+  </div>
+<script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script>
+  <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
+  <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
+  <ul class="index">
+   <li><a href="#hdf5">HDF5</a><span>, in § 1.1</span>
+   <li><a href="#ngff">NGFF</a><span>, in § 1.1</span>
+  </ul>
+  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
+  <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
+  <dl>
+   <dt id="biblio-rfc2119">[RFC2119]
+   <dd>S. Bradner. <a href="https://datatracker.ietf.org/doc/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a>
+  </dl>
+  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
+  <dl>
+   <dt id="biblio-n5">[N5]
+   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62"><cite>N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</cite></a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
+   <dt id="biblio-ome-zarr-py">[OME-ZARR-PY]
+   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931"><cite>ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
+   <dt id="biblio-zarr">[ZARR]
+   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231"><cite>Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
+  </dl>
\ No newline at end of file
diff --git a/0.3/index.html b/0.3/index.html
new file mode 100644
index 00000000..ffb85fc2
--- /dev/null
+++ b/0.3/index.html
@@ -0,0 +1,987 @@
+<!doctype html><html lang="en">
+ <head>
+  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
+  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
+  <title>Next-generation file formats (NGFF)</title>
+  <meta content="w3c/CG-FINAL" name="w3c-status">
+  <link href="https://www.w3.org/StyleSheets/TR/2021/cg-final" rel="stylesheet">
+  <link href="https://www.w3.org/2008/site/images/favicon.ico" rel="icon">
+  <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
+  <link href="https://ngff.openmicroscopy.org/0.3/" rel="canonical">
+  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
+<style>/* style-autolinks */
+
+.css.css, .property.property, .descriptor.descriptor {
+    color: var(--a-normal-text);
+    font-size: inherit;
+    font-family: inherit;
+}
+.css::before, .property::before, .descriptor::before {
+    content: "‘";
+}
+.css::after, .property::after, .descriptor::after {
+    content: "’";
+}
+.property, .descriptor {
+    /* Don't wrap property and descriptor names */
+    white-space: nowrap;
+}
+.type { /* CSS value <type> */
+    font-style: italic;
+}
+pre .property::before, pre .property::after {
+    content: "";
+}
+[data-link-type="property"]::before,
+[data-link-type="propdesc"]::before,
+[data-link-type="descriptor"]::before,
+[data-link-type="value"]::before,
+[data-link-type="function"]::before,
+[data-link-type="at-rule"]::before,
+[data-link-type="selector"]::before,
+[data-link-type="maybe"]::before {
+    content: "‘";
+}
+[data-link-type="property"]::after,
+[data-link-type="propdesc"]::after,
+[data-link-type="descriptor"]::after,
+[data-link-type="value"]::after,
+[data-link-type="function"]::after,
+[data-link-type="at-rule"]::after,
+[data-link-type="selector"]::after,
+[data-link-type="maybe"]::after {
+    content: "’";
+}
+
+[data-link-type].production::before,
+[data-link-type].production::after,
+.prod [data-link-type]::before,
+.prod [data-link-type]::after {
+    content: "";
+}
+
+[data-link-type=element],
+[data-link-type=element-attr] {
+    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
+    font-size: .9em;
+}
+[data-link-type=element]::before { content: "<" }
+[data-link-type=element]::after  { content: ">" }
+
+[data-link-type=biblio] {
+    white-space: pre;
+}</style>
+<style>/* style-colors */
+
+/* Any --*-text not paired with a --*-bg is assumed to have a transparent bg */
+:root {
+    color-scheme: light dark;
+
+    --text: black;
+    --bg: white;
+
+    --unofficial-watermark: url(https://www.w3.org/StyleSheets/TR/2016/logos/UD-watermark);
+
+    --logo-bg: #1a5e9a;
+    --logo-active-bg: #c00;
+    --logo-text: white;
+
+    --tocnav-normal-text: #707070;
+    --tocnav-normal-bg: var(--bg);
+    --tocnav-hover-text: var(--tocnav-normal-text);
+    --tocnav-hover-bg: #f8f8f8;
+    --tocnav-active-text: #c00;
+    --tocnav-active-bg: var(--tocnav-normal-bg);
+
+    --tocsidebar-text: var(--text);
+    --tocsidebar-bg: #f7f8f9;
+    --tocsidebar-shadow: rgba(0,0,0,.1);
+    --tocsidebar-heading-text: hsla(203,20%,40%,.7);
+
+    --toclink-text: var(--text);
+    --toclink-underline: #3980b5;
+    --toclink-visited-text: var(--toclink-text);
+    --toclink-visited-underline: #054572;
+
+    --heading-text: #005a9c;
+
+    --hr-text: var(--text);
+
+    --algo-border: #def;
+
+    --del-text: red;
+    --del-bg: transparent;
+    --ins-text: #080;
+    --ins-bg: transparent;
+
+    --a-normal-text: #034575;
+    --a-normal-underline: #bbb;
+    --a-visited-text: var(--a-normal-text);
+    --a-visited-underline: #707070;
+    --a-hover-bg: rgba(75%, 75%, 75%, .25);
+    --a-active-text: #c00;
+    --a-active-underline: #c00;
+
+    --blockquote-border: silver;
+    --blockquote-bg: transparent;
+    --blockquote-text: currentcolor;
+
+    --issue-border: #e05252;
+    --issue-bg: #fbe9e9;
+    --issue-text: var(--text);
+    --issueheading-text: #831616;
+
+    --example-border: #e0cb52;
+    --example-bg: #fcfaee;
+    --example-text: var(--text);
+    --exampleheading-text: #574b0f;
+
+    --note-border: #52e052;
+    --note-bg: #e9fbe9;
+    --note-text: var(--text);
+    --noteheading-text: hsl(120, 70%, 30%);
+    --notesummary-underline: silver;
+
+    --assertion-border: #aaa;
+    --assertion-bg: #eee;
+    --assertion-text: black;
+
+    --advisement-border: orange;
+    --advisement-bg: #fec;
+    --advisement-text: var(--text);
+    --advisementheading-text: #b35f00;
+
+    --warning-border: red;
+    --warning-bg: hsla(40,100%,50%,0.95);
+    --warning-text: var(--text);
+
+    --amendment-border: #330099;
+    --amendment-bg: #F5F0FF;
+    --amendment-text: var(--text);
+    --amendmentheading-text: #220066;
+
+    --def-border: #8ccbf2;
+    --def-bg: #def;
+    --def-text: var(--text);
+    --defrow-border: #bbd7e9;
+
+    --datacell-border: silver;
+
+    --indexinfo-text: #707070;
+
+    --indextable-hover-text: black;
+    --indextable-hover-bg: #f7f8f9;
+
+    --outdatedspec-bg: rgba(0, 0, 0, .5);
+    --outdatedspec-text: black;
+    --outdated-bg: maroon;
+    --outdated-text: white;
+    --outdated-shadow: red;
+
+    --editedrec-bg: darkorange;
+}</style>
+<style>/* style-counters */
+
+body {
+    counter-reset: example figure issue;
+}
+.issue {
+    counter-increment: issue;
+}
+.issue:not(.no-marker)::before {
+    content: "Issue " counter(issue);
+}
+
+.example {
+    counter-increment: example;
+}
+.example:not(.no-marker)::before {
+    content: "Example " counter(example);
+}
+.invalid.example:not(.no-marker)::before,
+.illegal.example:not(.no-marker)::before {
+    content: "Invalid Example" counter(example);
+}
+
+figcaption {
+    counter-increment: figure;
+}
+figcaption:not(.no-marker)::before {
+    content: "Figure " counter(figure) " ";
+}</style>
+<style>/* style-issues */
+
+a[href].issue-return {
+    float: right;
+    float: inline-end;
+    color: var(--issueheading-text);
+    font-weight: bold;
+    text-decoration: none;
+}
+</style>
+<style>/* style-md-lists */
+
+/* This is a weird hack for me not yet following the commonmark spec
+   regarding paragraph and lists. */
+[data-md] > :first-child {
+    margin-top: 0;
+}
+[data-md] > :last-child {
+    margin-bottom: 0;
+}</style>
+<style>/* style-selflinks */
+
+:root {
+    --selflink-text: white;
+    --selflink-bg: gray;
+    --selflink-hover-text: black;
+}
+.heading, .issue, .note, .example, li, dt {
+    position: relative;
+}
+a.self-link {
+    position: absolute;
+    top: 0;
+    left: calc(-1 * (3.5rem - 26px));
+    width: calc(3.5rem - 26px);
+    height: 2em;
+    text-align: center;
+    border: none;
+    transition: opacity .2s;
+    opacity: .5;
+}
+a.self-link:hover {
+    opacity: 1;
+}
+.heading > a.self-link {
+    font-size: 83%;
+}
+li > a.self-link {
+    left: calc(-1 * (3.5rem - 26px) - 2em);
+}
+dfn > a.self-link {
+    top: auto;
+    left: auto;
+    opacity: 0;
+    width: 1.5em;
+    height: 1.5em;
+    background: var(--selflink-bg);
+    color: var(--selflink-text);
+    font-style: normal;
+    transition: opacity .2s, background-color .2s, color .2s;
+}
+dfn:hover > a.self-link {
+    opacity: 1;
+}
+dfn > a.self-link:hover {
+    color: var(--selflink-hover-text);
+}
+
+a.self-link::before            { content: "¶"; }
+.heading > a.self-link::before { content: "§"; }
+dfn > a.self-link::before      { content: "#"; }
+</style>
+<style>/* style-syntax-highlighting */
+
+code.highlight { padding: .1em; border-radius: .3em; }
+pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
+
+.highlight:not(.idl) { background: rgba(0, 0, 0, .03); }
+c-[a] { color: #990055 } /* Keyword.Declaration */
+c-[b] { color: #990055 } /* Keyword.Type */
+c-[c] { color: #708090 } /* Comment */
+c-[d] { color: #708090 } /* Comment.Multiline */
+c-[e] { color: #0077aa } /* Name.Attribute */
+c-[f] { color: #669900 } /* Name.Tag */
+c-[g] { color: #222222 } /* Name.Variable */
+c-[k] { color: #990055 } /* Keyword */
+c-[l] { color: #000000 } /* Literal */
+c-[m] { color: #000000 } /* Literal.Number */
+c-[n] { color: #0077aa } /* Name */
+c-[o] { color: #999999 } /* Operator */
+c-[p] { color: #999999 } /* Punctuation */
+c-[s] { color: #a67f59 } /* Literal.String */
+c-[t] { color: #a67f59 } /* Literal.String.Single */
+c-[u] { color: #a67f59 } /* Literal.String.Double */
+c-[cp] { color: #708090 } /* Comment.Preproc */
+c-[c1] { color: #708090 } /* Comment.Single */
+c-[cs] { color: #708090 } /* Comment.Special */
+c-[kc] { color: #990055 } /* Keyword.Constant */
+c-[kn] { color: #990055 } /* Keyword.Namespace */
+c-[kp] { color: #990055 } /* Keyword.Pseudo */
+c-[kr] { color: #990055 } /* Keyword.Reserved */
+c-[ld] { color: #000000 } /* Literal.Date */
+c-[nc] { color: #0077aa } /* Name.Class */
+c-[no] { color: #0077aa } /* Name.Constant */
+c-[nd] { color: #0077aa } /* Name.Decorator */
+c-[ni] { color: #0077aa } /* Name.Entity */
+c-[ne] { color: #0077aa } /* Name.Exception */
+c-[nf] { color: #0077aa } /* Name.Function */
+c-[nl] { color: #0077aa } /* Name.Label */
+c-[nn] { color: #0077aa } /* Name.Namespace */
+c-[py] { color: #0077aa } /* Name.Property */
+c-[ow] { color: #999999 } /* Operator.Word */
+c-[mb] { color: #000000 } /* Literal.Number.Bin */
+c-[mf] { color: #000000 } /* Literal.Number.Float */
+c-[mh] { color: #000000 } /* Literal.Number.Hex */
+c-[mi] { color: #000000 } /* Literal.Number.Integer */
+c-[mo] { color: #000000 } /* Literal.Number.Oct */
+c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
+c-[sc] { color: #a67f59 } /* Literal.String.Char */
+c-[sd] { color: #a67f59 } /* Literal.String.Doc */
+c-[se] { color: #a67f59 } /* Literal.String.Escape */
+c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
+c-[si] { color: #a67f59 } /* Literal.String.Interpol */
+c-[sx] { color: #a67f59 } /* Literal.String.Other */
+c-[sr] { color: #a67f59 } /* Literal.String.Regex */
+c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
+c-[vc] { color: #0077aa } /* Name.Variable.Class */
+c-[vg] { color: #0077aa } /* Name.Variable.Global */
+c-[vi] { color: #0077aa } /* Name.Variable.Instance */
+c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
+</style>
+ <body class="h-entry">
+  <div class="head">
+   <p data-fill-with="logo"><a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a> </p>
+   <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
+   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-FINAL">Final Community Group Report</a>, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></p>
+   <details open>
+    <summary>More details about this document</summary>
+    <div data-fill-with="spec-metadata">
+     <dl>
+      <dt>This version:
+      <dd><a class="u-url" href="https://ngff.openmicroscopy.org/0.3/">https://ngff.openmicroscopy.org/0.3/</a>
+      <dt>Issue Tracking:
+      <dd><a href="https://forum.image.sc/tag/ome-ngff">Forums</a>
+      <dd><a href="https://github.com/ome/ngff/issues/">GitHub</a>
+      <dt class="editor">Editors:
+      <dd class="editor p-author h-card vcard"><span class="p-name fn">Josh Moore</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+      <dd class="editor p-author h-card vcard"><span class="p-name fn">Sébastien Besson</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+      <dd class="editor p-author h-card vcard"><span class="p-name fn">Constantin Pape</span> (<a class="p-org org" href="https://www.embl.org/sites/heidelberg/">European Molecular Biology Laboratory (EMBL)</a>)
+     </dl>
+    </div>
+   </details>
+   <div data-fill-with="warning"></div>
+   <p class="copyright" data-fill-with="copyright"><a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2022 <a href="https://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="https://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="https://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="https://www.keio.ac.jp/">Keio</a>, <a href="https://ev.buaa.edu.cn/">Beihang</a>). W3C <a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document" rel="license">permissive document license</a> rules apply. </p>
+   <hr title="Separator for header">
+  </div>
+  <div class="p-summary" data-fill-with="abstract">
+   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
+   <p>This document contains next-generation file format (NGFF)
+
+specifications for storing bioimaging data in the cloud.
+All specifications are submitted to the https://image.sc community for review.</p>
+  </div>
+  <h2 class="no-num no-toc no-ref heading settled" id="sotd"><span class="content">Status of this document</span></h2>
+  <div data-fill-with="status">
+   <p></p>
+   <p>This is the 0.3 release of this specification. Migration scripts
+
+will be provided between numbered versions. Data written with the latest version
+(an "editor’s draft") will not necessarily be supported.</p>
+  </div>
+  <div data-fill-with="at-risk"></div>
+  <nav data-fill-with="table-of-contents" id="toc">
+   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
+   <ol class="toc" role="directory">
+    <li>
+     <a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
+     <ol class="toc">
+      <li><a href="#why-ngff"><span class="secno">1.1</span> <span class="content">Why "<span><abbr title="Next-generation file-format">NGFF</abbr></span>"?</span></a>
+      <li><a href="#ome-ngff"><span class="secno">1.2</span> <span class="content">OME-NGFF</span></a>
+     </ol>
+    <li>
+     <a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+     <ol class="toc">
+      <li><a href="#image-layout"><span class="secno">2.1</span> <span class="content">Images</span></a>
+      <li><a href="#hcs-layout"><span class="secno">2.2</span> <span class="content">High-content screening</span></a>
+     </ol>
+    <li>
+     <a href="#metadata"><span class="secno">3</span> <span class="content">Metadata</span></a>
+     <ol class="toc">
+      <li><a href="#multiscale-md"><span class="secno">3.1</span> <span class="content">"multiscales" metadata</span></a>
+      <li><a href="#omero-md"><span class="secno">3.2</span> <span class="content">"omero" metadata</span></a>
+      <li><a href="#labels-md"><span class="secno">3.3</span> <span class="content">"labels" metadata</span></a>
+      <li><a href="#label-md"><span class="secno">3.4</span> <span class="content">"image-label" metadata</span></a>
+      <li><a href="#plate-md"><span class="secno">3.5</span> <span class="content">"plate" metadata</span></a>
+      <li><a href="#well-md"><span class="secno">3.6</span> <span class="content">"well" metadata</span></a>
+     </ol>
+    <li><a href="#implementations"><span class="secno">4</span> <span class="content">Implementations</span></a>
+    <li><a href="#citing"><span class="secno">5</span> <span class="content">Citing</span></a>
+    <li><a href="#history"><span class="secno">6</span> <span class="content">Version History</span></a>
+    <li>
+     <a href="#w3c-conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
+     <ol class="toc">
+      <li><a href="#w3c-conventions"><span class="secno"></span> <span class="content">Document conventions</span></a>
+      <li><a href="#w3c-conformant-algorithms"><span class="secno"></span> <span class="content">Conformant Algorithms</span></a>
+     </ol>
+    <li>
+     <a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
+     <ol class="toc">
+      <li><a href="#index-defined-here"><span class="secno"></span> <span class="content">Terms defined by this specification</span></a>
+     </ol>
+    <li>
+     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
+     <ol class="toc">
+      <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
+      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
+     </ol>
+   </ol>
+  </nav>
+  <main>
+   <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
+   <p>Bioimaging science is at a crossroads. Currently, the drive to acquire more,
+larger, preciser spatial measurements is unfortunately at odds with our ability
+to structure and share those measurements with others. During a global pandemic
+more than ever, we believe fervently that global, collaborative discovery as
+opposed to the post-publication, "data-on-request" mode of operation is the
+path forward. Bioimaging data should be shareable via open and commercial cloud
+resources without the need to download entire datasets.</p>
+   <p>At the moment, that is not the norm. The plethora of data formats produced by
+imaging systems are ill-suited to remote sharing. Individual scientists
+typically lack the infrastructure they need to host these data themselves. When
+they acquire images from elsewhere, time-consuming translations and data
+cleaning are needed to interpret findings. Those same costs are multiplied when
+gathering data into online repositories where curator time can be the limiting
+factor before publication is possible. Without a common effort, each lab or
+resource is left building the tools they need and maintaining that
+infrastructure often without dedicated funding.</p>
+   <p>This document defines a specification for bioimaging data to make it possible
+to enable the conversion of proprietary formats into a common, cloud-ready one.
+Such next-generation file formats layout data so that individual portions, or
+"chunks", of large data are reference-able eliminating the need to download
+entire datasets.</p>
+   <h3 class="heading settled" data-level="1.1" id="why-ngff"><span class="secno">1.1. </span><span class="content">Why "<dfn data-dfn-type="dfn" data-export id="ngff"><abbr title="Next-generation file-format">NGFF</abbr><a class="self-link" href="#ngff"></a></dfn>"?</span><a class="self-link" href="#why-ngff"></a></h3>
+   <p>A short description of what is needed for an imaging format is "a hierarchy
+of n-dimensional (dense) arrays with metadata". This combination of features
+is certainly provided by <dfn data-dfn-type="dfn" data-export id="hdf5"><abbr title="Hierarchical Data Format 5">HDF5</abbr><a class="self-link" href="#hdf5"></a></dfn> from the <a href="https://www.hdfgroup.org">HDF Group</a>, which a number of
+bioimaging formats do use. HDF5 and other larger binary structures, however,
+are ill-suited for storage in the cloud where accessing individual chunks
+of data by name rather than seeking through a large file is at the heart of
+parallelization.</p>
+   <p>As a result, a number of formats have been developed more recently which provide
+the basic data structure of an HDF5 file, but do so in a more cloud-friendly way.
+In the <a href="https://pydata.org/">PyData</a> community, the Zarr <a data-link-type="biblio" href="#biblio-zarr">[zarr]</a> format was developed
+for easily storing collections of <a href="https://numpy.org/">NumPy</a> arrays. In the <a href="https://imagej.net/">ImageJ</a> community, N5 <a data-link-type="biblio" href="#biblio-n5">[n5]</a> was developed to work around
+the limitations of HDF5 ("N5" was originally short for "Not-HDF5").
+Both of these formats permit storing individual chunks of data either locally in
+separate files or in cloud-based object stores as separate keys.</p>
+   <p>A <a href="https://zarr-specs.readthedocs.io/en/core-protocol-v3.0-dev/protocol/core/v3.0.html">current effort</a> is underway to unify the two similar specifications to provide a single binary
+specification. The editor’s draft will soon be entering a <a href="https://github.com/zarr-developers/zarr-specs/issues/101">request for comments (RFC)</a> phase with the goal of having a first version early in 2021. As that
+process comes to an end, this document will be updated.</p>
+   <h3 class="heading settled" data-level="1.2" id="ome-ngff"><span class="secno">1.2. </span><span class="content">OME-NGFF</span><a class="self-link" href="#ome-ngff"></a></h3>
+   <p>The conventions and specifications defined in this document are designed to
+enable next-generation file formats to represent the same bioimaging data
+that can be represented in <a href="http://www.openmicroscopy.org/ome-files/">OME-TIFF</a> and beyond. However, the conventions will also be usable by HDF5 and other sufficiently advanced
+binary containers. Eventually, we hope, the moniker "next-generation" will no longer be
+applicable, and this will simply be the most efficient, common, and useful representation
+of bioimaging data, whether during acquisition or sharing in the cloud.</p>
+   <p class="note" role="note"><span>Note:</span> The following text makes use of OME-Zarr <a data-link-type="biblio" href="#biblio-ome-zarr-py">[ome-zarr-py]</a>, the current prototype implementation,
+for all examples.</p>
+   <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. </span><span class="content">On-disk (or in-cloud) layout</span><a class="self-link" href="#on-disk"></a></h2>
+   <p>An overview of the layout of an OME-Zarr fileset should make
+understanding the following metadata sections easier. The hierarchy
+is represented here as it would appear locally but could equally
+be stored on a web server to be accessed via HTTP or in object storage
+like S3 or GCS.</p>
+   <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secno">2.1. </span><span class="content">Images</span><a class="self-link" href="#image-layout"></a></h3>
+   <p>The following layout describes the expected Zarr hierarchy for images with
+multiple levels of resolutions and optionally associated labels.</p>
+<pre>.                             # Root folder, potentially in S3,
+│                             # with a flat list of images by image ID.
+│
+├── 123.zarr                  # One image (id=123) converted to Zarr.
+│
+└── 456.zarr                  # Another image (id=456) converted to Zarr.
+    │
+    ├── .zgroup               # Each image is a Zarr group, or a folder, of other groups and arrays.
+    ├── .zattrs               # Group level attributes are stored in the .zattrs file and include
+    │                         # "multiscales" and "omero" (see below). In addition, the group level attributes
+    │                         # must also contain "_ARRAY_DIMENSIONS" if this group directly contains multi-scale arrays.
+    │
+    ├── 0                     # Each multiscale level is stored as a separate Zarr array,
+    │   ...                   # which is a folder containing chunk files which compose the array.
+    ├── n                     # The name of the array is arbitrary with the ordering defined by
+    │   │                     # by the "multiscales" metadata, but is often a sequence starting at 0.
+    │   │
+    │   ├── .zarray           # All image arrays must be up to 5-dimensional
+    │   │                     # with dimension order (t, c, z, y, x).
+    │   │
+    │   └─ t                  # Chunks are stored with the nested directory layout.
+    │      └─ c               # All but the last chunk element are stored as directories.
+    │         └─ z            # The terminal chunk is a file. Together the directory and file names
+    │            └─ y         # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
+    │               └─ x      # will be &lt;code data-opaque bs-autolink-syntax='`dimension_size / chunk_size`'>dimension_size / chunk_size&lt;/code>.
+    │
+    └── labels
+        │
+        ├── .zgroup           # The labels group is a container which holds a list of labels to make the objects easily discoverable
+        │
+        ├── .zattrs           # All labels will be listed in &lt;code data-opaque bs-autolink-syntax='`.zattrs`'>.zattrs&lt;/code> e.g. &lt;code data-opaque bs-autolink-syntax='`{ &amp;quot;labels&amp;quot;: [ &amp;quot;original/0&amp;quot; ] }`'>{ "labels": [ "original/0" ] }&lt;/code>
+        │                     # Each dimension of the label &lt;code data-opaque bs-autolink-syntax='`(t, c, z, y, x)`'>(t, c, z, y, x)&lt;/code> should be either the same as the
+        │                     # corresponding dimension of the image, or &lt;code data-opaque bs-autolink-syntax='`1`'>1&lt;/code> if that dimension of the label
+        │                     # is irrelevant.
+        │
+        └── original          # Intermediate folders are permitted but not necessary and currently contain no extra metadata.
+            │
+            └── 0             # Multiscale, labeled image. The name is unimportant but is registered in the "labels" group above.
+                ├── .zgroup   # Zarr Group which is both a multiscaled image as well as a labeled image.
+                ├── .zattrs   # Metadata of the related image and as well as display information under the "image-label" key.
+                │
+                ├── 0         # Each multiscale level is stored as a separate Zarr array, as above, but only integer values
+                │   ...       # are supported.
+                └── n
+</pre>
+   <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno">2.2. </span><span class="content">High-content screening</span><a class="self-link" href="#hcs-layout"></a></h3>
+   <p>The following specification defines the hierarchy for a high-content screening
+dataset. Three groups must be defined above the images:</p>
+   <ul>
+    <li data-md>
+     <p>the group above the images defines the well and MUST implement the <a href="#well-md">well specification</a>. All images contained in a well are fields
+of view of the same well</p>
+    <li data-md>
+     <p>the group above the well defines a row of wells</p>
+    <li data-md>
+     <p>the group above the well row defines an entire plate i.e. a two-dimensional
+collection of wells organized in rows and columns. It MUST implement the <a href="#plate-md">plate specification</a></p>
+   </ul>
+<pre>.                             # Root folder, potentially in S3,
+│
+└── 5966.zarr                 # One plate (id=5966) converted to Zarr
+    ├── .zgroup
+    ├── .zattrs               # Implements "plate" specification
+    ├── A                     # First row of the plate
+    │   ├── .zgroup
+    │   │
+    │   ├── 1                 # First column of row A
+    │   │   ├── .zgroup
+    │   │   ├── .zattrs       # Implements "well" specification
+    │   │   │
+    │   │   ├── 0             # First field of view of well A1
+    │   │   │   │
+    │   │   │   ├── .zgroup
+    │   │   │   ├── .zattrs   # Implements "multiscales", "omero"
+    │   │   │   ├── 0
+    │   │   │   │   ...       # Resolution levels
+    │   │   │   ├── n
+    │   │   │   └── labels    # Labels (optional)
+    │   │   ├── ...           # Fields of view
+    │   │   └── m
+    │   ├── ...               # Columns
+    │   └── 12
+    ├── ...                   # Rows
+    └── H
+</pre>
+   <h2 class="heading settled" data-level="3" id="metadata"><span class="secno">3. </span><span class="content">Metadata</span><a class="self-link" href="#metadata"></a></h2>
+   <p>The various <code>.zattrs</code> files throughout the above array hierarchy may contain metadata
+keys as specified below for discovering certain types of data, especially images.</p>
+   <h3 class="heading settled" data-level="3.1" id="multiscale-md"><span class="secno">3.1. </span><span class="content">"multiscales" metadata</span><a class="self-link" href="#multiscale-md"></a></h3>
+   <p>Metadata about the multiple resolution representations of the image can be
+found under the "multiscales" key in the group-level metadata.</p>
+   <p>"multiscales" contains a list of dictionaries where each entry describes a multiscale image.</p>
+   <p>Each dictionary contained in the list MUST contain the field "datasets", which is a list of dictionaries describing
+the arrays storing the individual resolution levels.
+Each dictionary in "datasets" MUST contain the field "path", whose value contains the path to the array for this resolution relative
+to the current zarr group. The "path"s MUST be ordered from largest (i.e. highest resolution) to smallest.</p>
+   <p>It MUST contain the field "axes", which is a list of dimension names of the axes.
+The values MUST be unique and one of <code>{"t", "c", "z", "y", "x"}</code>.
+The number of values MUST be the same as the number of dimensions of the arrays corresponding to this image.
+In addition, the "axes" values MUST be repeated in the field "_ARRAY_DIMENSIONS" of all scale groups
+(i.e. groups containing arrays with the multiscale data).
+This ensures compatibility with the <a href="http://xarray.pydata.org/en/stable/internals/zarr-encoding-spec.html#zarr-encoding">xarray zarr encoding</a>.</p>
+   <p>It SHOULD contain the field "name".</p>
+   <p>It SHOULD contain the field "version", which indicates the version of the
+multiscale metadata of this image (current version is 0.3).</p>
+   <p>It SHOULD contain the field "type", which gives the type of downscaling method used to generate the multiscale image pyramid.</p>
+   <p>It SHOULD contain the field "metadata", which contains a dictionary with additional information about the downscaling method.</p>
+<pre class="language-json highlight"><c- p>{</c->
+    <c- f>"multiscales"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"example"</c-><c- p>,</c->
+            <c- f>"datasets"</c-><c- p>:</c-> <c- p>[</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c-><c- p>},</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c-><c- p>},</c->
+                <c- p>{</c-><c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c-><c- p>}</c->
+            <c- p>],</c->
+            <c- f>"axes"</c-><c- p>:</c-> <c- p>[</c->
+                <c- u>"t"</c-><c- p>,</c-> <c- u>"c"</c-><c- p>,</c-> <c- u>"z"</c-><c- p>,</c-> <c- u>"y"</c-><c- p>,</c-> <c- u>"x"</c->
+            <c- p>],</c->
+            <c- f>"type"</c-><c- p>:</c-> <c- u>"gaussian"</c-><c- p>,</c->
+            <c- f>"metadata"</c-><c- p>:</c-> <c- p>{</c->                                       # <c- kc>t</c->he <c- kc>f</c->ields i<c- kc>n</c-> me<c- kc>ta</c->da<c- kc>ta</c-> depe<c- kc>n</c->d o<c- kc>n</c-> <c- kc>t</c->he dow<c- kc>ns</c->cali<c- kc>n</c->g impleme<c- kc>ntat</c->io<c- kc>n</c->
+                <c- f>"method"</c-><c- p>:</c-> <c- u>"skimage.transform.pyramid_gaussian"</c-><c- p>,</c-> # here<c- p>,</c-> <c- kc>t</c->he param<c- kc>ters</c-> passed <c- kc>t</c->o <c- kc>t</c->he skimage <c- kc>fun</c->c<c- kc>t</c->io<c- kc>n</c-> are give<c- kc>n</c->
+                <c- f>"version"</c-><c- p>:</c-> <c- u>"0.16.1"</c-><c- p>,</c->
+                <c- f>"args"</c-><c- p>:</c-> <c- u>"[true]"</c-><c- p>,</c->
+                <c- f>"kwargs"</c-><c- p>:</c-> <c- p>{</c-><c- f>"multichannel"</c-><c- p>:</c-> <c- kc>true</c-><c- p>}</c->
+            <c- p>}</c->
+        <c- p>}</c->
+    <c- p>]</c->
+<c- p>}</c->
+</pre>
+   <p>If only one multiscale is provided, use it. Otherwise, the user can choose by
+name, using the first multiscale as a fallback:</p>
+<pre class="language-python highlight"><c- n>datasets</c-> <c- o>=</c-> <c- p>[]</c->
+<c- k>for</c-> <c- n>named</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>:</c->
+    <c- k>if</c-> <c- n>named</c-><c- p>[</c-><c- u>"name"</c-><c- p>]</c-> <c- o>==</c-> <c- u>"3D"</c-><c- p>:</c->
+        <c- n>datasets</c-> <c- o>=</c-> <c- p>[</c-><c- n>x</c-><c- p>[</c-><c- u>"path"</c-><c- p>]</c-> <c- k>for</c-> <c- n>x</c-> <c- ow>in</c-> <c- n>named</c-><c- p>[</c-><c- u>"datasets"</c-><c- p>]]</c->
+        <c- k>break</c->
+<c- k>if</c-> <c- ow>not</c-> <c- n>datasets</c-><c- p>:</c->
+    <c- c1># Use the first by default. Or perhaps choose based on chunk size.</c->
+    <c- n>datasets</c-> <c- o>=</c-> <c- p>[</c-><c- n>x</c-><c- p>[</c-><c- u>"path"</c-><c- p>]</c-> <c- k>for</c-> <c- n>x</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>[</c-><c- mi>0</c-><c- p>][</c-><c- u>"datasets"</c-><c- p>]]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3.2. </span><span class="content">"omero" metadata</span><a class="self-link" href="#omero-md"></a></h3>
+   <p>Information specific to the channels of an image and how to render it
+can be found under the "omero" key in the group-level metadata:</p>
+<pre class="language-json highlight"><c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->                              # ID i<c- kc>n</c-> OMERO
+<c- f>"name"</c-><c- p>:</c-> <c- u>"example.tif"</c-><c- p>,</c->                # Name as show<c- kc>n</c-> i<c- kc>n</c-> <c- kc>t</c->he UI
+<c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->                     # Curre<c- kc>nt</c-> versio<c- kc>n</c->
+<c- f>"channels"</c-><c- p>:</c-> <c- p>[</c->                         # Array ma<c- kc>t</c->chi<c- kc>n</c->g <c- kc>t</c->he c dime<c- kc>ns</c->io<c- kc>n</c-> size
+    <c- p>{</c->
+        <c- f>"active"</c-><c- p>:</c-> <c- kc>true</c-><c- p>,</c->
+        <c- f>"coefficient"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"color"</c-><c- p>:</c-> <c- u>"0000FF"</c-><c- p>,</c->
+        <c- f>"family"</c-><c- p>:</c-> <c- u>"linear"</c-><c- p>,</c->
+        <c- f>"inverted"</c-><c- p>:</c-> <c- kc>false</c-><c- p>,</c->
+        <c- f>"label"</c-><c- p>:</c-> <c- u>"LaminB1"</c-><c- p>,</c->
+        <c- f>"window"</c-><c- p>:</c-> <c- p>{</c->
+            <c- f>"end"</c-><c- p>:</c-> <c- mi>1500</c-><c- p>,</c->
+            <c- f>"max"</c-><c- p>:</c-> <c- mi>65535</c-><c- p>,</c->
+            <c- f>"min"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->
+            <c- f>"start"</c-><c- p>:</c-> <c- mi>0</c->
+        <c- p>}</c->
+    <c- p>}</c->
+<c- p>],</c->
+<c- f>"rdefs"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # Firs<c- kc>t</c-> <c- kc>t</c->imepoi<c- kc>nt</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # Firs<c- kc>t</c-> Z sec<c- kc>t</c->io<c- kc>n</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"model"</c-><c- p>:</c-> <c- u>"color"</c->                  # <c- u>"color"</c-> or <c- u>"greyscale"</c->
+<c- p>}</c->
+</pre>
+   <p>See https://docs.openmicroscopy.org/omero/5.6.1/developers/Web/WebGateway.html#imgdata
+for more information.</p>
+   <h3 class="heading settled" data-level="3.3" id="labels-md"><span class="secno">3.3. </span><span class="content">"labels" metadata</span><a class="self-link" href="#labels-md"></a></h3>
+   <p>The special group "labels" found under an image Zarr contains the key <code>labels</code> containing
+the paths to label objects which can be found underneath the group:</p>
+<pre class="language-json highlight"><c- p>{</c->
+  <c- f>"labels"</c-><c- p>:</c-> <c- p>[</c->
+    <c- u>"orphaned/0"</c->
+  <c- p>]</c->
+<c- p>}</c->
+</pre>
+   <p>Unlisted groups MAY be labels.</p>
+   <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3.4. </span><span class="content">"image-label" metadata</span><a class="self-link" href="#label-md"></a></h3>
+   <p>Groups containing the <code>image-label</code> dictionary represent an image segmentation
+in which each unique pixel value represents a separate segmented object. <code>image-label</code> groups MUST also contain <code>multiscales</code> metadata and the two
+"datasets" series MUST have the same number of entries.</p>
+   <p>The <code>colors</code> key defines a list of JSON objects describing the unique label
+values. Each entry in the list MUST contain the key "label-value" with the
+pixel value for that label. Additionally, the "rgba" key MAY be present, the
+value for which is an RGBA unsigned-int 4-tuple: <code>[uint8, uint8, uint8, uint8]</code> All <code>label-value</code>s must be unique. Clients who choose to not throw an error
+should ignore all except the _last_ entry.</p>
+   <p>Some implementations may represent overlapping labels by using a specially assigned
+value, for example the highest integer available in the pixel range.</p>
+   <p>The <code>properties</code> key defines a list of JSON objects which also describes the unique
+label values. Each entry in the list MUST contain the key "label-value" with the 
+pixel value for that label. Additionally, an arbitrary number of key-value pairs 
+MAY be present for each label value denoting associated metadata. Not all label 
+values must share the same key-value pairs within the properties list.</p>
+   <p>The <code>source</code> key is an optional dictionary which contains information on the
+image the label is associated with. If included it MAY include a key <code>image</code> whose value is the relative path to a Zarr image group. The default value is
+"../../" since most labels are stored under a subgroup named "labels/" (see
+above).</p>
+<pre class="language-json highlight"><c- f>"image-label"</c-><c- p>:</c->
+  <c- p>{</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
+    <c- f>"colors"</c-><c- p>:</c-> <c- p>[</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"rgba"</c-><c- p>:</c-> <c- p>[</c-><c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>0</c-><c- p>]</c->
+      <c- p>},</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+        <c- f>"rgba"</c-><c- p>:</c-> <c- p>[</c-><c- mi>0</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>128</c-><c- p>]</c->
+      <c- p>},</c->
+      ...
+      <c- p>],</c->
+    <c- f>"properties"</c-><c- p>:</c-> <c- p>[</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1200</c-><c- p>,</c->
+        <c- f>"class"</c-><c- p>:</c-> <c- u>"foo"</c->
+
+      <c- p>},</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1650</c->
+      <c- p>},</c->
+      ...
+      <c- p>]</c->
+  <c- p>},</c->
+  <c- f>"source"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"image"</c-><c- p>:</c-> <c- u>"../../"</c->
+  <c- p>}</c->
+<c- p>]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.5" id="plate-md"><span class="secno">3.5. </span><span class="content">"plate" metadata</span><a class="self-link" href="#plate-md"></a></h3>
+   <p>For high-content screening datasets, the plate layout can be found under the
+custom attributes of the plate group under the <code>plate</code> key.</p>
+   <dl>
+    <dt><strong>acquisitions</strong>
+    <dd>An optional list of JSON objects defining the acquisitions for a given
+      plate. Each acquisition object MUST contain an <code>id</code> key providing an
+      unique identifier within the context of the plate to which fields of
+      view can refer to. It SHOULD contain  a <code>name</code> key identifying the name
+      of the acquisition. It SHOULD contain a <code>maximumfieldcount</code> key
+      indicating the maximum number of fields of view for the acquisition. It
+      MAY contain a <code>description</code> key providing a description for the
+      acquisition. It MAY contain a <code>startime</code> and/or <code>endtime</code> key specifying
+      the start and/or end timestamp of the acquisition using an epoch
+      string.
+    <dt><strong>columns</strong>
+    <dd>A list of JSON objects defining the columns of the plate. Each column
+      object defines the properties of the column at the index of the object
+      in the list. If not empty, it MUST contain a <code>name</code> key specifying the
+      column name.
+    <dt><strong>field_count</strong>
+    <dd>An integer defining the maximum number of fields per view across all
+      wells.
+    <dt><strong>name</strong>
+    <dd>A string defining the name of the plate.
+    <dt><strong>rows</strong>
+    <dd>A list of JSON objects defining the rows of the plate. Each row object
+      defines the properties of the row at the index of the object in the
+      list. If not empty, it MUST contain a <code>name</code> key specifying the row
+      name.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+    <dt><strong>wells</strong>
+    <dd>A list of JSON objects defining the wells of the plate. Each well object 
+      MUST contain a <code>path</code> key identifying the path to the well subgroup.
+   </dl>
+   <p>For example the following JSON object defines a plate with two acquisition and
+6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion.</p>
+<pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_01(2012-07-31_10-41-12)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343731272000</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_02(201207-31_11-56-41)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343735801000</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"columns"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"field_count"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+    <c- f>"name"</c-><c- p>:</c-> <c- u>"test"</c-><c- p>,</c->
+    <c- f>"rows"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"A"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"B"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
+    <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/3"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/3"</c->
+        <c- p>}</c->
+    <c- p>]</c->
+  <c- p>}</c->
+</pre>
+   <h3 class="heading settled" data-level="3.6" id="well-md"><span class="secno">3.6. </span><span class="content">"well" metadata</span><a class="self-link" href="#well-md"></a></h3>
+   <p>For high-content screening datasets, the metadata about all fields of views
+under a given  well can be found under the "well" key in the attributes of the
+well group.</p>
+   <dl>
+    <dt><strong>images</strong>
+    <dd>A list of JSON objects defining the fields of views for a given well.
+      Each object MUST contain a <code>path</code> key identifying the path to the
+      field of view. If multiple acquisitions were performed in the plate, it  
+      SHOULD contain an <code>acquisition</code> key identifying the id of the 
+      acquisition which must match one of acquisition JSON objects defined in
+      the plate metadata.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+   </dl>
+   <p>For example the following JSON object defines a well with four fields of
+views. The first two fields of view were part of the first acquisition while
+the last two fields of view were part of the second acquisition.</p>
+<pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c->
+  <c- p>}</c->
+</pre>
+   <h2 class="heading settled" data-level="4" id="implementations"><span class="secno">4. </span><span class="content">Implementations</span><a class="self-link" href="#implementations"></a></h2>
+   <p>Projects which support reading and/or writing OME-NGFF data include:</p>
+   <dl>
+    <dt><strong><a href="https://github.com/ome/omero-ms-zarr">omero-ms-zarr</a></strong>
+    <dd>A microservice for OMERO.server that converts images stored in OMERO to OME Zarr files on the fly, served via a web API.
+    <dt><strong><a href="https://github.com/IDR/idr-zarr-tools">idr-zarr-tools</a></strong>
+    <dd>A full workflow demonstrating the conversion of IDR images to OME Zarr images on S3.
+    <dt><strong><a href="https://github.com/ome/omero-cli-zarr">OMERO CLI Zarr plugin</a></strong>
+    <dd>An OMERO CLI plugin that converts images stored in OMERO.server into a local Zarr file.
+    <dt><strong><a href="https://github.com/ome/ome-zarr-py">ome-zarr-py</a></strong>
+    <dd>A napari plugin for reading ome-zarr files.
+    <dt><strong><a href="https://github.com/glencoesoftware/bioformats2raw">bioformats2raw</a></strong>
+    <dd>A performant, Bio-Formats image file format converter.
+    <dt><strong><a href="https://github.com/hms-dbmi/vizarr/">vizarr</a></strong>
+    <dd>A minimal, purely client-side program for viewing Zarr-based images with Viv &amp; ImJoy.
+   </dl>
+   <p><img alt="Diagram of related projects" src="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/images/zarr-ome-diagram.png"></p>
+   <p>All implementations prevent an equivalent representation of a dataset which can be downloaded or uploaded freely. An interactive
+version of this diagram is available from the <a href="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/">OME2020 Workshop</a>.
+Mouseover the blackboxes representing the implementations above to get a quick tip on how to use them.</p>
+   <p class="note" role="note"><span>Note:</span> If you would like to see your project listed, please open an issue or PR on the <a href="https://github.com/ome/ngff">ome/ngff</a> repository.</p>
+   <h2 class="heading settled" data-level="5" id="citing"><span class="secno">5. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
+   <p><a href="https://ngff.openmicroscopy.org/0.3">Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a> J. Moore, <em>et al</em>. Editors. Open Microscopy Environment Consortium, 20 November 2020.
+This edition of the specification is <a href="https://ngff.openmicroscopy.org/0.3/]">https://ngff.openmicroscopy.org/0.3/</a>.
+The latest edition is available at <a href="https://ngff.openmicroscopy.org/latest/">https://ngff.openmicroscopy.org/latest/</a>. <a href="https://doi.org/10.5281/zenodo.4282107">(doi:10.5281/zenodo.4282107)</a></p>
+   <h2 class="heading settled" data-level="6" id="history"><span class="secno">6. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
+   <table>
+    <thead>
+     <tr>
+      <td>Revision
+      <td>Date
+      <td>Description
+    <tbody>
+     <tr>
+      <td>0.3.0
+      <td>2021-08-24
+      <td>Add axes field to multiscale metadata 
+     <tr>
+      <td>0.2.0
+      <td>2021-03-29
+      <td>Change chunk dimension separator to "/" 
+     <tr>
+      <td>0.1.4
+      <td>2020-11-26
+      <td>Add HCS specification 
+     <tr>
+      <td>0.1.3
+      <td>2020-09-14
+      <td>Add labels specification 
+     <tr>
+      <td>0.1.2 
+      <td>2020-05-07
+      <td>Add description of "omero" metadata 
+     <tr>
+      <td>0.1.1 
+      <td>2020-05-06
+      <td>Add info on the ordering of resolutions 
+     <tr>
+      <td>0.1.0 
+      <td>2020-04-20
+      <td>First version for internal demo 
+   </table>
+  </main>
+  <div data-fill-with="conformance">
+   <h2 class="no-ref no-num heading settled" id="w3c-conformance"><span class="content">Conformance</span><a class="self-link" href="#w3c-conformance"></a></h2>
+   <h3 class="no-ref no-num heading settled" id="w3c-conventions"><span class="content">Document conventions</span><a class="self-link" href="#w3c-conventions"></a></h3>
+   <p>Conformance requirements are expressed
+    with a combination of descriptive assertions
+    and RFC 2119 terminology.
+    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
+    in the normative parts of this document
+    are to be interpreted as described in RFC 2119.
+    However, for readability,
+    these words do not appear in all uppercase letters in this specification. </p>
+   <p>All of the text of this specification is normative
+    except sections explicitly marked as non-normative, examples, and notes. <a data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a> </p>
+   <p>Examples in this specification are introduced with the words “for example”
+    or are set apart from the normative text
+    with <code>class="example"</code>,
+    like this: </p>
+   <div class="example" id="w3c-example">
+    <a class="self-link" href="#w3c-example"></a> 
+    <p>This is an example of an informative example. </p>
+   </div>
+   <p>Informative notes begin with the word “Note”
+    and are set apart from the normative text
+    with <code>class="note"</code>,
+    like this: </p>
+   <p class="note" role="note">Note, this is an informative note. </p>
+   <h3 class="no-ref no-num heading settled" id="w3c-conformant-algorithms"><span class="content">Conformant Algorithms</span><a class="self-link" href="#w3c-conformant-algorithms"></a></h3>
+   <p>Requirements phrased in the imperative as part of algorithms
+    (such as "strip any leading space characters"
+    or "return false and abort these steps")
+    are to be interpreted with the meaning of the key word
+    ("must", "should", "may", etc)
+    used in introducing the algorithm. </p>
+   <p>Conformance requirements phrased as algorithms or specific steps
+    can be implemented in any manner,
+    so long as the end result is equivalent.
+    In particular, the algorithms defined in this specification
+    are intended to be easy to understand
+    and are not intended to be performant.
+    Implementers are encouraged to optimize. </p>
+  </div>
+<script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script>
+  <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
+  <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
+  <ul class="index">
+   <li><a href="#hdf5">HDF5</a><span>, in § 1.1</span>
+   <li><a href="#ngff">NGFF</a><span>, in § 1.1</span>
+  </ul>
+  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
+  <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
+  <dl>
+   <dt id="biblio-rfc2119">[RFC2119]
+   <dd>S. Bradner. <a href="https://datatracker.ietf.org/doc/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a>
+  </dl>
+  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
+  <dl>
+   <dt id="biblio-n5">[N5]
+   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62"><cite>N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</cite></a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
+   <dt id="biblio-ome-zarr-py">[OME-ZARR-PY]
+   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931"><cite>ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
+   <dt id="biblio-zarr">[ZARR]
+   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231"><cite>Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
+  </dl>
\ No newline at end of file
diff --git a/latest/index.html b/latest/index.html
index 7f6dcfe5..4262a7c6 100644
--- a/latest/index.html
+++ b/latest/index.html
@@ -12,7 +12,7 @@
  *   - .toc for the Table of Contents (<ol class="toc">)
  *     + <span class="secno"> for the section numbers
  *   - #toc for the Table of Contents (<nav id="toc">)
- *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
+ *   - ul.index for Indices (<a href="#ref">term</a><span>, in § N.M</span>)
  *   - table.index for Index Tables (e.g. for properties or elements)
  *
  * Structural Markup
@@ -368,8 +368,8 @@
 /** Subheadings ***************************************************************/
 
 	h1 + h2,
-	#subtitle {
-		/* #subtitle is a subtitle in an H2 under the H1 */
+	#profile-and-date {
+		/* #profile-and-date is a subtitle in an H2 under the H1 */
 		margin-top: 0;
 	}
 	h2 + h3,
@@ -583,34 +583,27 @@
 	a[href] {
 		color: #034575;
 		color: var(--a-normal-text);
-		text-decoration: none;
-		border-bottom: 1px solid #707070;
-		border-bottom: 1px solid var(--a-normal-underline);
-		/* Need a bit of extending for it to look okay */
-		padding: 0 1px 0;
-		margin: 0 -1px 0;
+		text-decoration: underline #707070;
+		text-decoration: underline var(--a-normal-underline);
+		text-decoration-skip-ink: none;
 	}
 	a:visited {
 		color: #034575;
 		color: var(--a-visited-text);
-		border-bottom-color: #bbb;
-		border-bottom-color: var(--a-visited-underline);
+		text-decoration-color: #bbb;
+		text-decoration-color: var(--a-visited-underline);
 	}
 
-	/* Use distinguishing colors when user is interacting with the link */
+	/* Indicate interaction with the link */
 	a[href]:focus,
 	a[href]:hover {
-		background: #f8f8f8;
-		background: rgba(75%, 75%, 75%, .25);
-		background: var(--a-hover-bg);
-		border-bottom-width: 3px;
-		margin-bottom: -2px;
+		text-decoration-thickness: 2px;
 	}
 	a[href]:active {
 		color: #c00;
 		color: var(--a-active-text);
-		border-color: #c00;
-		border-color: var(--a-active-underline);
+		text-decoration-color: #c00;
+		text-decoration-color: var(--a-active-underline);
 	}
 
 	/* Backout above styling for W3C logo */
@@ -1116,9 +1109,12 @@
 
 	.toc a {
 		/* More spacing; use padding to make it part of the click target. */
-		padding-top: 0.1rem;
+		padding: 0.1rem 1px 0;
 		/* Larger, more consistently-sized click target */
 		display: block;
+		/* Switch to using border-bottom for underlines */
+		text-decoration: none;
+		border-bottom: 1px solid;
 		/* Reverse color scheme */
 		color: black;
 		color: var(--toclink-text);
@@ -1131,6 +1127,13 @@
 		border-color: #054572;
 		border-color: var(--toclink-visited-underline);
 	}
+	.toc a:focus,
+	.toc a:hover {
+		background: rgba(75%, 75%, 75%, .25);
+		background: var(--a-hover-bg);
+		border-bottom-width: 3px;
+		margin-bottom: -2px;
+	}
 	.toc a:not(:focus):not(:hover) {
 		/* Allow colors to cascade through from link styling */
 		border-bottom-color: transparent;
@@ -1266,7 +1269,7 @@
 	ul.index ul,
 	ul.index dl { font-size: smaller; }
 	@media not print {
-		ul.index li span:not(.dfn-paneled) {
+		ul.index li a + span {
 			white-space: nowrap;
 			color: transparent; }
 		ul.index li a:hover + span,
@@ -1484,9 +1487,9 @@
 		}
 	}
 </style>
-  <meta content="Bikeshed version ef9d3c0a, updated Fri Nov 13 17:14:48 2020 -0800" name="generator">
+  <meta content="Bikeshed version 2e3c4c68b, updated Fri Jan 14 14:49:00 2022 -0800" name="generator">
   <link href="https://ngff.openmicroscopy.org/latest/" rel="canonical">
-  <meta content="c6d7d84f77959846ecdc9b65eecfa87bb6dc1f86" name="document-revision">
+  <meta content="90de9f1c440bf7dccaac34fcfceb5785fc09ada5" name="document-revision">
 <style>/* style-autolinks */
 
 .css.css, .property.property, .descriptor.descriptor {
@@ -1593,9 +1596,9 @@
     --ins-bg: transparent;
 
     --a-normal-text: #034575;
-    --a-normal-underline: #707070;
+    --a-normal-underline: #bbb;
     --a-visited-text: var(--a-normal-text);
-    --a-visited-underline: #bbb;
+    --a-visited-underline: #707070;
     --a-hover-bg: rgba(75%, 75%, 75%, .25);
     --a-active-text: #c00;
     --a-active-underline: #c00;
@@ -1687,6 +1690,16 @@
 figcaption:not(.no-marker)::before {
     content: "Figure " counter(figure) " ";
 }</style>
+<style>/* style-issues */
+
+a[href].issue-return {
+    float: right;
+    float: inline-end;
+    color: var(--issueheading-text);
+    font-weight: bold;
+    text-decoration: none;
+}
+</style>
 <style>/* style-md-lists */
 
 /* This is a weird hack for me not yet following the commonmark spec
@@ -1812,7 +1825,7 @@
   <div class="head">
     <img alt="OME logo (6 circles in a hexagon)" src="http://www.openmicroscopy.org/img/logos/ome-logomark.svg" style="float:right;width:42px;height:42px;"> 
    <h1 class="p-name no-ref" id="title">Next-generation file formats (NGFF)</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2020-11-20">20 November 2020</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2022-01-28">28 January 2022</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -1820,12 +1833,14 @@ <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="cont
      <dt>Issue Tracking:
      <dd><a href="https://forum.image.sc/tag/ome-ngff">Forums</a>
      <dd><a href="https://github.com/ome/ngff/issues/">GitHub</a>
-     <dt class="editor">Editor:
+     <dt class="editor">Editors:
      <dd class="editor p-author h-card vcard"><span class="p-name fn">Josh Moore</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+     <dd class="editor p-author h-card vcard"><span class="p-name fn">Sébastien Besson</span> (<a class="p-org org" href="https://www.openmicroscopy.org">Open Microscopy Environment (OME)</a>)
+     <dd class="editor p-author h-card vcard"><span class="p-name fn">Constantin Pape</span> (<a class="p-org org" href="https://www.embl.org/sites/heidelberg/">European Molecular Biology Laboratory (EMBL)</a>)
     </dl>
    </div>
    <div data-fill-with="warning"></div>
-   <p class="copyright" data-fill-with="copyright">Copyright © 2020 <a href="https://www.openmicroscopy.org/"><abbr title="Open Microscopy Environment">OME</abbr></a><sup>®</sup> (<a href="https://dundee.ac.uk/"><abbr title="University of Dundee">U. Dundee</abbr></a>).
+   <p class="copyright" data-fill-with="copyright">Copyright © 2022 <a href="https://www.openmicroscopy.org/"><abbr title="Open Microscopy Environment">OME</abbr></a><sup>®</sup> (<a href="https://dundee.ac.uk/"><abbr title="University of Dundee">U. Dundee</abbr></a>).
 OME trademark rules apply. </p>
    <hr title="Separator for header">
   </div>
@@ -1839,9 +1854,8 @@ <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="cont
   <h2 class="no-num no-toc no-ref heading settled" id="sotd"><span class="content">Status of this document</span></h2>
   <div data-fill-with="status">
    <p></p>
-   <p>The current released version of this specification is 0.1. Migration scripts
-
-will be provided between numbered versions. Data written with the latest changes
+   <p>The current released version of this specification is <a href="../0.3/index.html">0.3</a>. Migration scripts
+will be provided between numbered versions. Data written with these latest changes
 (an "editor’s draft") will not necessarily be supported.</p>
   </div>
   <div data-fill-with="at-risk"></div>
@@ -1854,17 +1868,28 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
       <li><a href="#why-ngff"><span class="secno">1.1</span> <span class="content">Why "<span><abbr title="Next-generation file-format">NGFF</abbr></span>"?</span></a>
       <li><a href="#ome-ngff"><span class="secno">1.2</span> <span class="content">OME-NGFF</span></a>
      </ol>
-    <li><a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+    <li>
+     <a href="#on-disk"><span class="secno">2</span> <span class="content">On-disk (or in-cloud) layout</span></a>
+     <ol class="toc">
+      <li><a href="#image-layout"><span class="secno">2.1</span> <span class="content">Images</span></a>
+      <li><a href="#hcs-layout"><span class="secno">2.2</span> <span class="content">High-content screening</span></a>
+     </ol>
     <li>
      <a href="#metadata"><span class="secno">3</span> <span class="content">Metadata</span></a>
      <ol class="toc">
-      <li><a href="#multiscale-md"><span class="secno">3.1</span> <span class="content">"multiscales" metadata</span></a>
-      <li><a href="#omero-md"><span class="secno">3.2</span> <span class="content">"omero" metadata</span></a>
-      <li><a href="#labels-md"><span class="secno">3.3</span> <span class="content">"labels" metadata</span></a>
-      <li><a href="#label-md"><span class="secno">3.4</span> <span class="content">"image-label" metadata</span></a>
+      <li><a href="#axes-md"><span class="secno">3.1</span> <span class="content">"axes" metadata</span></a>
+      <li><a href="#trafo-md"><span class="secno">3.2</span> <span class="content">"transformations" metadata</span></a>
+      <li><a href="#multiscale-md"><span class="secno">3.3</span> <span class="content">"multiscales" metadata</span></a>
+      <li><a href="#omero-md"><span class="secno">3.4</span> <span class="content">"omero" metadata</span></a>
+      <li><a href="#labels-md"><span class="secno">3.5</span> <span class="content">"labels" metadata</span></a>
+      <li><a href="#label-md"><span class="secno">3.6</span> <span class="content">"image-label" metadata</span></a>
+      <li><a href="#plate-md"><span class="secno">3.7</span> <span class="content">"plate" metadata</span></a>
+      <li><a href="#well-md"><span class="secno">3.8</span> <span class="content">"well" metadata</span></a>
      </ol>
-    <li><a href="#citing"><span class="secno">4</span> <span class="content">Citing</span></a>
-    <li><a href="#history"><span class="secno">5</span> <span class="content">Version History</span></a>
+    <li><a href="#naming-style"><span class="secno">4</span> <span class="content">Specification naming style</span></a>
+    <li><a href="#implementations"><span class="secno">5</span> <span class="content">Implementations</span></a>
+    <li><a href="#citing"><span class="secno">6</span> <span class="content">Citing</span></a>
+    <li><a href="#history"><span class="secno">7</span> <span class="content">Version History</span></a>
     <li>
      <a href="#w3c-conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
      <ol class="toc">
@@ -1940,6 +1965,11 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
 is represented here as it would appear locally but could equally
 be stored on a web server to be accessed via HTTP or in object storage
 like S3 or GCS.</p>
+   <h3 class="heading settled" data-level="2.1" id="image-layout"><span class="secno">2.1. </span><span class="content">Images</span><a class="self-link" href="#image-layout"></a></h3>
+   <p>The following layout describes the expected Zarr hierarchy for images with
+multiple levels of resolutions and optionally associated labels.
+Note that the number of dimensions is variable between 2 and 5 and that axis names are arbitrary, see <a href="#multiscale-md">§ 3.3 "multiscales" metadata</a> for details.
+For this example we assume an image with 5 dimensions and axes called <code>t,c,z,y,x</code>.</p>
 <pre>.                             # Root folder, potentially in S3,
 │                             # with a flat list of images by image ID.
 │
@@ -1949,28 +1979,30 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
     │
     ├── .zgroup               # Each image is a Zarr group, or a folder, of other groups and arrays.
     ├── .zattrs               # Group level attributes are stored in the .zattrs file and include
-    │                         #  "multiscales" and "omero" below)
+    │                         # "multiscales" and "omero" (see below). In addition, the group level attributes
+    │                         # must also contain "_ARRAY_DIMENSIONS" if this group directly contains multi-scale arrays.
     │
     ├── 0                     # Each multiscale level is stored as a separate Zarr array,
     │   ...                   # which is a folder containing chunk files which compose the array.
     ├── n                     # The name of the array is arbitrary with the ordering defined by
     │   │                     # by the "multiscales" metadata, but is often a sequence starting at 0.
     │   │
-    │   ├── .zarray           # All image arrays are 5-dimensional
-    │   │                     # with dimension order (t, c, z, y, x).
+    │   ├── .zarray           # All image arrays must be up to 5-dimensional
+    │   │                     # with the axis of type time before type channel, before spatial axes.
     │   │
-    │   ├── 0.0.0.0.0         # Chunks are stored with the flat directory layout.
-    │   │   ...               # Each dotted component of the chunk file represents
-    │   └── t.c.z.y.x         # a "chunk coordinate", where the maximum coordinate
-    │                         # will be &lt;code data-opaque bs-autolink-syntax='`dimension_size / chunk_size`'>dimension_size / chunk_size&lt;/code>.
+    │   └─ t                  # Chunks are stored with the nested directory layout.
+    │      └─ c               # All but the last chunk element are stored as directories.
+    │         └─ z            # The terminal chunk is a file. Together the directory and file names
+    │            └─ y         # provide the "chunk coordinate" (t, c, z, y, x), where the maximum coordinate
+    │               └─ x      # will be <code>dimension_size / chunk_size</code>.
     │
     └── labels
         │
         ├── .zgroup           # The labels group is a container which holds a list of labels to make the objects easily discoverable
         │
-        ├── .zattrs           # All labels will be listed in &lt;code data-opaque bs-autolink-syntax='`.zattrs`'>.zattrs&lt;/code> e.g. &lt;code data-opaque bs-autolink-syntax='`{ &amp;quot;labels&amp;quot;: [ &amp;quot;original/0&amp;quot; ] }`'>{ "labels": [ "original/0" ] }&lt;/code>
-        │                     # Each dimension of the label &lt;code data-opaque bs-autolink-syntax='`(t, c, z, y, x)`'>(t, c, z, y, x)&lt;/code> should be either the same as the
-        │                     # corresponding dimension of the image, or &lt;code data-opaque bs-autolink-syntax='`1`'>1&lt;/code> if that dimension of the label
+        ├── .zattrs           # All labels will be listed in <code>.zattrs</code> e.g. <code>{ "labels": [ "original/0" ] }</code>
+        │                     # Each dimension of the label <code>(t, c, z, y, x)</code> should be either the same as the
+        │                     # corresponding dimension of the image, or <code>1</code> if that dimension of the label
         │                     # is irrelevant.
         │
         └── original          # Intermediate folders are permitted but not necessary and currently contain no extra metadata.
@@ -1982,16 +2014,147 @@ <h2 class="heading settled" data-level="2" id="on-disk"><span class="secno">2. <
                 ├── 0         # Each multiscale level is stored as a separate Zarr array, as above, but only integer values
                 │   ...       # are supported.
                 └── n
+</pre>
+   <h3 class="heading settled" data-level="2.2" id="hcs-layout"><span class="secno">2.2. </span><span class="content">High-content screening</span><a class="self-link" href="#hcs-layout"></a></h3>
+   <p>The following specification defines the hierarchy for a high-content screening
+dataset. Three groups must be defined above the images:</p>
+   <ul>
+    <li data-md>
+     <p>the group above the images defines the well and MUST implement the <a href="#well-md">well specification</a>. All images contained in a well are fields
+of view of the same well</p>
+    <li data-md>
+     <p>the group above the well defines a row of wells</p>
+    <li data-md>
+     <p>the group above the well row defines an entire plate i.e. a two-dimensional
+collection of wells organized in rows and columns. It MUST implement the <a href="#plate-md">plate specification</a></p>
+   </ul>
+<pre>.                             # Root folder, potentially in S3,
+│
+└── 5966.zarr                 # One plate (id=5966) converted to Zarr
+    ├── .zgroup
+    ├── .zattrs               # Implements "plate" specification
+    ├── A                     # First row of the plate
+    │   ├── .zgroup
+    │   │
+    │   ├── 1                 # First column of row A
+    │   │   ├── .zgroup
+    │   │   ├── .zattrs       # Implements "well" specification
+    │   │   │
+    │   │   ├── 0             # First field of view of well A1
+    │   │   │   │
+    │   │   │   ├── .zgroup
+    │   │   │   ├── .zattrs   # Implements "multiscales", "omero"
+    │   │   │   ├── 0
+    │   │   │   │   ...       # Resolution levels
+    │   │   │   ├── n
+    │   │   │   └── labels    # Labels (optional)
+    │   │   ├── ...           # Fields of view
+    │   │   └── m
+    │   ├── ...               # Columns
+    │   └── 12
+    ├── ...                   # Rows
+    └── H
 </pre>
    <h2 class="heading settled" data-level="3" id="metadata"><span class="secno">3. </span><span class="content">Metadata</span><a class="self-link" href="#metadata"></a></h2>
    <p>The various <code>.zattrs</code> files throughout the above array hierarchy may contain metadata
 keys as specified below for discovering certain types of data, especially images.</p>
-   <h3 class="heading settled" data-level="3.1" id="multiscale-md"><span class="secno">3.1. </span><span class="content">"multiscales" metadata</span><a class="self-link" href="#multiscale-md"></a></h3>
-   <p>Metadata about the multiple resolution representations of the image can be
-found under the "multiscales" key in the group-level metadata.
-The specification for the multiscale (i.e. "resolution") metadata is provided
-in <a href="https://github.com/zarr-developers/zarr-specs/issues/50">zarr-specs#50</a>.
-If only one multiscale is provided, use it. Otherwise, the user can choose by
+   <h3 class="heading settled" data-level="3.1" id="axes-md"><span class="secno">3.1. </span><span class="content">"axes" metadata</span><a class="self-link" href="#axes-md"></a></h3>
+   <p>"axes" describes the dimensions of a physical coordinate space. It is a list of dictionaries, where each dictionary describes a dimension (axis) and:</p>
+   <ul>
+    <li data-md>
+     <p>MUST contain the field "name" that gives the name for this dimension. The values MUST be unique across all "name" fields.</p>
+    <li data-md>
+     <p>SHOULD contain the field "type". It SHOULD be one of "space", "time" or "channel", but MAY take other values for custom axis types that are not part of this specification yet.</p>
+    <li data-md>
+     <p>SHOULD contain the field "unit" to specify the physical unit of this dimension. The value SHOULD be one of the following strings, which are valid units according to UDUNITS-2.</p>
+     <ul>
+      <li data-md>
+       <p>Units for "space" axes: <a class="property css" data-link-type="property">angstrom</a>, <a class="property css" data-link-type="property">attometer</a>, <a class="property css" data-link-type="property">centimeter</a>, <a class="property css" data-link-type="property">decimeter</a>, <a class="property css" data-link-type="property">exameter</a>, <a class="property css" data-link-type="property">femtometer</a>, <a class="property css" data-link-type="property">foot</a>, <a class="property css" data-link-type="property">gigameter</a>, <a class="property css" data-link-type="property">hectometer</a>, <a class="property css" data-link-type="property">inch</a>, <a class="property css" data-link-type="property">kilometer</a>, <a class="property css" data-link-type="property">megameter</a>, <a class="property css" data-link-type="property">meter</a>, <a class="property css" data-link-type="property">micrometer</a>, <a class="property css" data-link-type="property">mile</a>, <a class="property css" data-link-type="property">millimeter</a>, <a class="property css" data-link-type="property">nanometer</a>, <a class="property css" data-link-type="property">parsec</a>, <a class="property css" data-link-type="property">petameter</a>, <a class="property css" data-link-type="property">picometer</a>, <a class="property css" data-link-type="property">terameter</a>, <a class="property css" data-link-type="property">yard</a>, <a class="property css" data-link-type="property">yoctometer</a>, <a class="property css" data-link-type="property">yottameter</a>, <a class="property css" data-link-type="property">zeptometer</a>, <a class="property css" data-link-type="property">zettameter</a></p>
+      <li data-md>
+       <p>Units for "time" axes: <a class="property css" data-link-type="property">attosecond</a>, <a class="property css" data-link-type="property">centisecond</a>, <a class="property css" data-link-type="property">day</a>, <a class="property css" data-link-type="property">decisecond</a>, <a class="property css" data-link-type="property">exasecond</a>, <a class="property css" data-link-type="property">femtosecond</a>, <a class="property css" data-link-type="property">gigasecond</a>, <a class="property css" data-link-type="property">hectosecond</a>, <a class="property css" data-link-type="property">hour</a>, <a class="property css" data-link-type="property">kilosecond</a>, <a class="property css" data-link-type="property">megasecond</a>, <a class="property css" data-link-type="property">microsecond</a>, <a class="property css" data-link-type="property">millisecond</a>, <a class="property css" data-link-type="property">minute</a>, <a class="property css" data-link-type="property">nanosecond</a>, <a class="property css" data-link-type="property">petasecond</a>, <a class="property css" data-link-type="property">picosecond</a>, <a class="property css" data-link-type="property">second</a>, <a class="property css" data-link-type="property">terasecond</a>, <a class="property css" data-link-type="property">yoctosecond</a>, <a class="property css" data-link-type="property">yottasecond</a>, <a class="property css" data-link-type="property">zeptosecond</a>, <a class="property css" data-link-type="property">zettasecond</a></p>
+     </ul>
+   </ul>
+   <p>If part of <a href="#multiscale-md">§ 3.3 "multiscales" metadata</a>, the length of "axes" MUST be equal to the number of dimensions of the arrays that contain the image data.</p>
+   <h3 class="heading settled" data-level="3.2" id="trafo-md"><span class="secno">3.2. </span><span class="content">"transformations" metadata</span><a class="self-link" href="#trafo-md"></a></h3>
+   <p>"transformations" describes a series of transformations, e.g. to map discrete data space of an array to the corresponding physical space.
+It is a list of dictionaries. Each entry describes a single transformation and MUST contain the field "type".
+The value of "type" MUST be one of the elements of the <code>type</code> column in the table below.
+Additional fields for the entry depend on "type" and are defined by the column <code>fields</code>.</p>
+   <p>| type          | fields | description |
+| ------------- | ------ |------------ |
+| <code>identity</code> |        | identity transformation, is the default transformation and is typically not explicitly defined |
+| <code>translation</code> | one of: <code>"translation":List[float]</code>, <code>"path":str</code> | translation vector, stored either as a list of floats (<code>"translation"</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. |
+| <code>scale</code> | one of: <code>"scale":List[float]</code>, <code>"path":str</code> | scale vector, stored either as a list of floats (<code>scale</code>) or as binary data at a location in this container (<code>path</code>). The length of vector defines number of dimensions. |</p>
+   <p>In addition, the field "axisIndices" MAY be given to specify the subset of axes that the transformation is applied to, leaving other axes unchanged. If not given, the transformation is applied to all axes. The length of "axisIndices" MUST be equal to the dimensionality of the transformation. If "axisIndices" are not given, the dimensionality of the transformation MUST be equal to the number of dimensions of the space that the transformation is applied to.
+If given, "axisIndices" MUST be given in increasing order. It uses zero-based indexing.</p>
+   <p>The transformations in the list are applied sequentally and in order.</p>
+   <h3 class="heading settled" data-level="3.3" id="multiscale-md"><span class="secno">3.3. </span><span class="content">"multiscales" metadata</span><a class="self-link" href="#multiscale-md"></a></h3>
+   <p>Metadata about an image can be found under the "multiscales" key in the group-level metadata. Here, image refers to 2 to 5 dimensional data representing image or volumetric data with optional time or channel axes. It is stored in a multiple resolution representation.</p>
+   <p>"multiscales" contains a list of dictionaries where each entry describes a multiscale image.</p>
+   <p>Each "multiscales" dictionary MUST contain the field "axes", see <a href="#axes-md">§ 3.1 "axes" metadata</a>.
+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").
+The "axes" MUST contain 2 or 3 entries of "type:space" and MAY contain one additional entry of "type:time" and MAY contain one additional entry of "type:channel" or a null / custom type.
+The order of the entries MUST correspond to the order of dimensions of the zarr arrays. In addition, the 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".
+The values of the "name" fields must be given as a list in the field "_ARRAY_DIMENSIONS" in the attributes (.zattr) of the zarr arrays.
+This ensures compatibility with the <a href="http://xarray.pydata.org/en/stable/internals/zarr-encoding-spec.html#zarr-encoding">xarray zarr encoding</a>.
+E.g. for "axes: [{"name": "z"}, {"name": "y"}, {"name": x}]", the zarr arrays must contain "{"_ARRAY_DIMENSIONS": ["z", "y", "x"]}" in their attributes.</p>
+   <p>Each "multiscales" dictionary MUST contain the field "datasets", which is a list of dictionaries describing the arrays storing the individual resolution levels.
+Each dictionary in "datasets" MUST contain the field "path", whose value contains the path to the array for this resolution relative
+to the current zarr group. The "path"s MUST be ordered from largest (i.e. highest resolution) to smallest.</p>
+   <p>Each "datasets" dictionary MUST have the same number of dimensions and MUST NOT have more than 5 dimensions. The number of dimensions and order MUST correspond to number and order of "axes".
+Each dictionary MAY contain the field "transformations", which contains a list of transformations that map the data coordinates to the physical coordinates (as specified by "axes") for this resolution level.
+The transformations are defined according to <a href="#trafo-md">§ 3.2 "transformations" metadata</a>. In addition, the transformation types MUST only be <code>identity</code>, <code>translation</code> or <code>scale</code>.
+They MUST contain at most one <code>scale</code> transformation per axis that specifies the pixel size in physical units.
+It also MUST contain at most one <code>translation</code> per axis that specifies the offset from the origin in physical units.
+If both <code>scale</code> and <code>translation</code> are given <code>translation</code> must be listed after <code>scale</code> to ensure that it is given in physical coordinates. If "transformations" is not given, the identity transformation is assumed.
+The requirements (only <code>scale</code> and <code>translation</code>, restrictions on order) are in place to provide a simple mapping from data coordinates to physical coordinates while
+being compatible with the general transformation spec.</p>
+   <p>Each "multiscales" dictionary MAY contain the field "transformations", describing transformations that are applied to each resolution level.
+The transformations MUST follow the same rules about allowed types, order, etc. as in "datasets:transformations".
+These transformations are applied after the per resolution level transformations specified in "datasets". They can for example be used to specify the <code>scale</code> for a dimension that is the same for all resolutions.</p>
+   <p>Each "multiscales" dictionary SHOULD contain the field "name". It SHOULD contain the field "version", which indicates the version of the multiscale metadata of this image (current version is 0.4).</p>
+   <p>Each "multiscales" dictionary SHOULD contain the field "type", which gives the type of downscaling method used to generate the multiscale image pyramid.
+It SHOULD contain the field "metadata", which contains a dictionary with additional information about the downscaling method.</p>
+<pre>{
+    "multiscales": [
+        {
+            "version": "0.4",
+            "name": "example",
+            "axes": [
+                {"name": "t", "type": "time", "unit": "millisecond"},
+                {"name": "c", "type": "channel"},
+                {"name": "z", "type": "space", "unit": "micrometer"},
+                {"name": "y", "type": "space", "unit": "micrometer"},
+                {"name": "x", "type": "space", "unit": "micrometer"}
+            ],
+            "datasets": [
+                {
+                    "path": "0",
+                    "transformations": [{"type": "scale", "scale": [0.5, 0.5, 0.5], "axisIndices": [2, 3, 4]}]  # the voxel size for the first scale level (0.5 micrometer)
+                }
+                {
+                    "path": "1",
+                    "transformations": [{"type": "scale", "scale": [1.0, 1.0, 1.0], "axisIndices": [2, 3, 4]}]  # the voxel size for the second scale level (downscaled by a factor of 2 -> 1 micrometer)
+                },
+                {
+                    "path": "2",
+                    "transformations": [{"type": "scale", "scale": [2.0, 2.0, 2.0], "axisIndices": [2, 3, 4]}]  # the voxel size for the second scale level (downscaled by a factor of 4 -> 2 micrometer)
+                }
+            ],
+            "transformations": [{"type": "scale", "scale": [0.1], "axisIndices": [0]],  # the time unit (0.1 milliseconds), which is the same for each scale level
+            "type": "gaussian",
+            "metadata": {                                       # the fields in metadata depend on the downscaling implementation
+                "method": "skimage.transform.pyramid_gaussian", # here, the paramters passed to the skimage function are given
+                "version": "0.16.1",
+                "args": "[true]",
+                "kwargs": {"multichannel": true}
+            }
+        }
+    ]
+}
+</pre>
+   <p>If only one multiscale is provided, use it. Otherwise, the user can choose by
 name, using the first multiscale as a fallback:</p>
 <pre class="language-python highlight"><c- n>datasets</c-> <c- o>=</c-> <c- p>[]</c->
 <c- k>for</c-> <c- n>named</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>:</c->
@@ -2002,15 +2165,13 @@ <h3 class="heading settled" data-level="3.1" id="multiscale-md"><span class="sec
     <c- c1># Use the first by default. Or perhaps choose based on chunk size.</c->
     <c- n>datasets</c-> <c- o>=</c-> <c- p>[</c-><c- n>x</c-><c- p>[</c-><c- u>"path"</c-><c- p>]</c-> <c- k>for</c-> <c- n>x</c-> <c- ow>in</c-> <c- n>multiscales</c-><c- p>[</c-><c- mi>0</c-><c- p>][</c-><c- u>"datasets"</c-><c- p>]]</c->
 </pre>
-   <p>The subresolutions in each multiscale are ordered from highest-resolution
-to lowest.</p>
-   <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3.2. </span><span class="content">"omero" metadata</span><a class="self-link" href="#omero-md"></a></h3>
+   <h3 class="heading settled" data-level="3.4" id="omero-md"><span class="secno">3.4. </span><span class="content">"omero" metadata</span><a class="self-link" href="#omero-md"></a></h3>
    <p>Information specific to the channels of an image and how to render it
 can be found under the "omero" key in the group-level metadata:</p>
-<pre class="language-json highlight"><c- u>"id"</c->: <c- mi>1</c->,                              # ID in OMERO
-<c- u>"name"</c->: <c- u>"example.tif"</c->,                # Name as shown in the UI
-<c- u>"version"</c->: <c- u>"0.1"</c->,                     # Current version
-<c- u>"channels"</c->: <c- p>[</c->                         # Array matching the c dimension size
+<pre class="language-json highlight"><c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->                              # ID i<c- kc>n</c-> OMERO
+<c- f>"name"</c-><c- p>:</c-> <c- u>"example.tif"</c-><c- p>,</c->                # Name as show<c- kc>n</c-> i<c- kc>n</c-> <c- kc>t</c->he UI
+<c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->                     # Curre<c- kc>nt</c-> versio<c- kc>n</c->
+<c- f>"channels"</c-><c- p>:</c-> <c- p>[</c->                         # Array ma<c- kc>t</c->chi<c- kc>n</c->g <c- kc>t</c->he c dime<c- kc>ns</c->io<c- kc>n</c-> size
     <c- p>{</c->
         <c- f>"active"</c-><c- p>:</c-> <c- kc>true</c-><c- p>,</c->
         <c- f>"coefficient"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
@@ -2025,16 +2186,16 @@ <h3 class="heading settled" data-level="3.2" id="omero-md"><span class="secno">3
             <c- f>"start"</c-><c- p>:</c-> <c- mi>0</c->
         <c- p>}</c->
     <c- p>}</c->
-<c- p>]</c->,
-<c- u>"rdefs"</c->: <c- p>{</c->
-    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # First timepoint to show the user
-    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # First Z section to show the user
+<c- p>],</c->
+<c- f>"rdefs"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"defaultT"</c-><c- p>:</c-> <c- mi>0</c-><c- p>,</c->                    # Firs<c- kc>t</c-> <c- kc>t</c->imepoi<c- kc>nt</c-> <c- kc>t</c->o show <c- kc>t</c->he user
+    <c- f>"defaultZ"</c-><c- p>:</c-> <c- mi>118</c-><c- p>,</c->                  # Firs<c- kc>t</c-> Z sec<c- kc>t</c->io<c- kc>n</c-> <c- kc>t</c->o show <c- kc>t</c->he user
     <c- f>"model"</c-><c- p>:</c-> <c- u>"color"</c->                  # <c- u>"color"</c-> or <c- u>"greyscale"</c->
 <c- p>}</c->
 </pre>
    <p>See https://docs.openmicroscopy.org/omero/5.6.1/developers/Web/WebGateway.html#imgdata
 for more information.</p>
-   <h3 class="heading settled" data-level="3.3" id="labels-md"><span class="secno">3.3. </span><span class="content">"labels" metadata</span><a class="self-link" href="#labels-md"></a></h3>
+   <h3 class="heading settled" data-level="3.5" id="labels-md"><span class="secno">3.5. </span><span class="content">"labels" metadata</span><a class="self-link" href="#labels-md"></a></h3>
    <p>The special group "labels" found under an image Zarr contains the key <code>labels</code> containing
 the paths to label objects which can be found underneath the group:</p>
 <pre class="language-json highlight"><c- p>{</c->
@@ -2044,7 +2205,7 @@ <h3 class="heading settled" data-level="3.3" id="labels-md"><span class="secno">
 <c- p>}</c->
 </pre>
    <p>Unlisted groups MAY be labels.</p>
-   <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3.4. </span><span class="content">"image-label" metadata</span><a class="self-link" href="#label-md"></a></h3>
+   <h3 class="heading settled" data-level="3.6" id="label-md"><span class="secno">3.6. </span><span class="content">"image-label" metadata</span><a class="self-link" href="#label-md"></a></h3>
    <p>Groups containing the <code>image-label</code> dictionary represent an image segmentation
 in which each unique pixel value represents a separate segmented object. <code>image-label</code> groups MUST also contain <code>multiscales</code> metadata and the two
 "datasets" series MUST have the same number of entries.</p>
@@ -2055,13 +2216,18 @@ <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3
 should ignore all except the _last_ entry.</p>
    <p>Some implementations may represent overlapping labels by using a specially assigned
 value, for example the highest integer available in the pixel range.</p>
+   <p>The <code>properties</code> key defines a list of JSON objects which also describes the unique
+label values. Each entry in the list MUST contain the key "label-value" with the
+pixel value for that label. Additionally, an arbitrary number of key-value pairs
+MAY be present for each label value denoting associated metadata. Not all label
+values must share the same key-value pairs within the properties list.</p>
    <p>The <code>source</code> key is an optional dictionary which contains information on the
 image the label is associated with. If included it MAY include a key <code>image</code> whose value is the relative path to a Zarr image group. The default value is
 "../../" since most labels are stored under a subgroup named "labels/" (see
 above).</p>
-<pre class="language-json highlight"><c- u>"image-label"</c->:
+<pre class="language-json highlight"><c- f>"image-label"</c-><c- p>:</c->
   <c- p>{</c->
-    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.1"</c-><c- p>,</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
     <c- f>"colors"</c-><c- p>:</c-> <c- p>[</c->
       <c- p>{</c->
         <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
@@ -2072,18 +2238,195 @@ <h3 class="heading settled" data-level="3.4" id="label-md"><span class="secno">3
         <c- f>"rgba"</c-><c- p>:</c-> <c- p>[</c-><c- mi>0</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>255</c-><c- p>,</c-> <c- mi>128</c-><c- p>]</c->
       <c- p>},</c->
       ...
+      <c- p>],</c->
+    <c- f>"properties"</c-><c- p>:</c-> <c- p>[</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1200</c-><c- p>,</c->
+        <c- f>"class"</c-><c- p>:</c-> <c- u>"foo"</c->
+
+      <c- p>},</c->
+      <c- p>{</c->
+        <c- f>"label-value"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+        <c- f>"area (pixels)"</c-><c- p>:</c-> <c- mi>1650</c->
+      <c- p>},</c->
+      ...
       <c- p>]</c->
-    <c- p>}</c->,
-    <c- u>"source"</c->: <c- p>{</c->
-      <c- f>"image"</c-><c- p>:</c-> <c- u>"../../"</c->
-    <c- p>}</c->
-]
+  <c- p>},</c->
+  <c- f>"source"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"image"</c-><c- p>:</c-> <c- u>"../../"</c->
+  <c- p>}</c->
+<c- p>]</c->
+</pre>
+   <h3 class="heading settled" data-level="3.7" id="plate-md"><span class="secno">3.7. </span><span class="content">"plate" metadata</span><a class="self-link" href="#plate-md"></a></h3>
+   <p>For high-content screening datasets, the plate layout can be found under the
+custom attributes of the plate group under the <code>plate</code> key.</p>
+   <dl>
+    <dt><strong>acquisitions</strong>
+    <dd>An optional list of JSON objects defining the acquisitions for a given
+      plate. Each acquisition object MUST contain an <code>id</code> key providing an
+      unique identifier within the context of the plate to which fields of
+      view can refer to. It SHOULD contain  a <code>name</code> key identifying the name
+      of the acquisition. It SHOULD contain a <code>maximumfieldcount</code> key
+      indicating the maximum number of fields of view for the acquisition. It
+      MAY contain a <code>description</code> key providing a description for the
+      acquisition. It MAY contain a <code>startime</code> and/or <code>endtime</code> key specifying
+      the start and/or end timestamp of the acquisition using an epoch
+      string.
+    <dt><strong>columns</strong>
+    <dd>A list of JSON objects defining the columns of the plate. Each column
+      object defines the properties of the column at the index of the object
+      in the list. If not empty, it MUST contain a <code>name</code> key specifying the
+      column name.
+    <dt><strong>field_count</strong>
+    <dd>An integer defining the maximum number of fields per view across all
+      wells.
+    <dt><strong>name</strong>
+    <dd>A string defining the name of the plate.
+    <dt><strong>rows</strong>
+    <dd>A list of JSON objects defining the rows of the plate. Each row object
+      defines the properties of the row at the index of the object in the
+      list. If not empty, it MUST contain a <code>name</code> key specifying the row
+      name.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+    <dt><strong>wells</strong>
+    <dd>A list of JSON objects defining the wells of the plate. Each well object
+      MUST contain a <code>path</code> key identifying the path to the well subgroup.
+   </dl>
+   <p>For example the following JSON object defines a plate with two acquisition and
+6 wells (2 rows and 3 columns), containing up 2 fields of view per acquistion.</p>
+<pre class="language-json highlight"><c- f>"plate"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"acquisitions"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_01(2012-07-31_10-41-12)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343731272000</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"id"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"maximumfieldcount"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"Meas_02(201207-31_11-56-41)"</c-><c- p>,</c->
+            <c- f>"starttime"</c-><c- p>:</c-> <c- mi>1343735801000</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"columns"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"field_count"</c-><c- p>:</c-> <c- mi>4</c-><c- p>,</c->
+    <c- f>"name"</c-><c- p>:</c-> <c- u>"test"</c-><c- p>,</c->
+    <c- f>"rows"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"A"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"name"</c-><c- p>:</c-> <c- u>"B"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c-><c- p>,</c->
+    <c- f>"wells"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/A/3"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2020-10-10/B/3"</c->
+        <c- p>}</c->
+    <c- p>]</c->
+  <c- p>}</c->
+</pre>
+   <h3 class="heading settled" data-level="3.8" id="well-md"><span class="secno">3.8. </span><span class="content">"well" metadata</span><a class="self-link" href="#well-md"></a></h3>
+   <p>For high-content screening datasets, the metadata about all fields of views
+under a given  well can be found under the "well" key in the attributes of the
+well group.</p>
+   <dl>
+    <dt><strong>images</strong>
+    <dd>A list of JSON objects defining the fields of views for a given well.
+      Each object MUST contain a <code>path</code> key identifying the path to the
+      field of view. If multiple acquisitions were performed in the plate, it
+      SHOULD contain an <code>acquisition</code> key identifying the id of the
+      acquisition which must match one of acquisition JSON objects defined in
+      the plate metadata.
+    <dt><strong>version</strong>
+    <dd>A string defining the version of the specification.
+   </dl>
+   <p>For example the following JSON object defines a well with four fields of
+views. The first two fields of view were part of the first acquisition while
+the last two fields of view were part of the second acquisition.</p>
+<pre class="language-json highlight"><c- f>"well"</c-><c- p>:</c-> <c- p>{</c->
+    <c- f>"images"</c-><c- p>:</c-> <c- p>[</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"0"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>1</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"1"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"2"</c->
+        <c- p>},</c->
+        <c- p>{</c->
+            <c- f>"acquisition"</c-><c- p>:</c-> <c- mi>2</c-><c- p>,</c->
+            <c- f>"path"</c-><c- p>:</c-> <c- u>"3"</c->
+        <c- p>}</c->
+    <c- p>],</c->
+    <c- f>"version"</c-><c- p>:</c-> <c- u>"0.3"</c->
+  <c- p>}</c->
 </pre>
-   <h2 class="heading settled" data-level="4" id="citing"><span class="secno">4. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
-   <p><a href="https://ngff.openmicroscopy.org/0.1">Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a> J. Moore, <em>et al</em>. Editors. Open Microscopy Environment Consortium, 20 November 2020.
-This edition of the specification is <a href="https://ngff.openmicroscopy.org/0.1/]">https://ngff.openmicroscopy.org/0.1/</a>.
+   <h2 class="heading settled" data-level="4" id="naming-style"><span class="secno">4. </span><span class="content">Specification naming style</span><a class="self-link" href="#naming-style"></a></h2>
+   <p>Multi-word keys in this specification should use the <code>camelCase</code> style.
+NB: some parts of the specification don’t obey this convention as they
+were added before this was adopted, but they should be updated in due course.</p>
+   <h2 class="heading settled" data-level="5" id="implementations"><span class="secno">5. </span><span class="content">Implementations</span><a class="self-link" href="#implementations"></a></h2>
+   <p>Projects which support reading and/or writing OME-NGFF data include:</p>
+   <dl>
+    <dt><strong><a href="https://github.com/mobie/bigdataviewer-ome-zarr">bigdataviewer-ome-zarr</a></strong>
+    <dd>Fiji-plugin for reading OME-Zarr.
+    <dt><strong><a href="https://github.com/glencoesoftware/bioformats2raw">bioformats2raw</a></strong>
+    <dd>A performant, Bio-Formats image file format converter.
+    <dt><strong><a href="https://github.com/ome/omero-ms-zarr">omero-ms-zarr</a></strong>
+    <dd>A microservice for OMERO.server that converts images stored in OMERO to OME-Zarr files on the fly, served via a web API.
+    <dt><strong><a href="https://github.com/IDR/idr-zarr-tools">idr-zarr-tools</a></strong>
+    <dd>A full workflow demonstrating the conversion of IDR images to OME-Zarr images on S3.
+    <dt><strong><a href="https://github.com/ome/omero-cli-zarr">OMERO CLI Zarr plugin</a></strong>
+    <dd>An OMERO CLI plugin that converts images stored in OMERO.server into a local Zarr file.
+    <dt><strong><a href="https://github.com/ome/ome-zarr-py">ome-zarr-py</a></strong>
+    <dd>A napari plugin for reading ome-zarr files.
+    <dt><strong><a href="https://github.com/hms-dbmi/vizarr/">vizarr</a></strong>
+    <dd>A minimal, purely client-side program for viewing Zarr-based images with Viv &amp; ImJoy.
+   </dl>
+   <p><img alt="Diagram of related projects" src="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/images/zarr-ome-diagram.png"></p>
+   <p>All implementations prevent an equivalent representation of a dataset which can be downloaded or uploaded freely. An interactive
+version of this diagram is available from the <a href="https://downloads.openmicroscopy.org/presentations/2020/Dundee/Workshops/NGFF/zarr_diagram/">OME2020 Workshop</a>.
+Mouseover the blackboxes representing the implementations above to get a quick tip on how to use them.</p>
+   <p class="note" role="note"><span>Note:</span> If you would like to see your project listed, please open an issue or PR on the <a href="https://github.com/ome/ngff">ome/ngff</a> repository.</p>
+   <h2 class="heading settled" data-level="6" id="citing"><span class="secno">6. </span><span class="content">Citing</span><a class="self-link" href="#citing"></a></h2>
+   <p><a href="https://ngff.openmicroscopy.org/0.3">Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a> J. Moore, <em>et al</em>. Editors. Open Microscopy Environment Consortium, 24 August 2021.
+This edition of the specification is <a href="https://ngff.openmicroscopy.org/0.3/]">https://ngff.openmicroscopy.org/0.3/</a>.
 The latest edition is available at <a href="https://ngff.openmicroscopy.org/latest/">https://ngff.openmicroscopy.org/latest/</a>. <a href="https://doi.org/10.5281/zenodo.4282107">(doi:10.5281/zenodo.4282107)</a></p>
-   <h2 class="heading settled" data-level="5" id="history"><span class="secno">5. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
+   <h2 class="heading settled" data-level="7" id="history"><span class="secno">7. </span><span class="content">Version History</span><a class="self-link" href="#history"></a></h2>
    <table>
     <thead>
      <tr>
@@ -2092,21 +2435,21 @@ <h2 class="heading settled" data-level="5" id="history"><span class="secno">5. <
       <td>Description
     <tbody>
      <tr>
-      <td>0.1.3-dev4
-      <td>2020-09-14
-      <td>Add the image-label object 
+      <td>0.3.0
+      <td>2021-08-24
+      <td>Add axes field to multiscale metadata 
      <tr>
-      <td>0.1.3-dev3
-      <td>2020-09-01
-      <td>Convert labels to multiscales 
+      <td>0.2.0
+      <td>2021-03-29
+      <td>Change chunk dimension separator to "/" 
      <tr>
-      <td>0.1.3-dev2
-      <td>2020-08-18
-      <td>Rename masks as labels 
+      <td>0.1.4
+      <td>2020-11-26
+      <td>Add HCS specification 
      <tr>
-      <td>0.1.3-dev1
-      <td>2020-07-07
-      <td>Add mask metadata 
+      <td>0.1.3
+      <td>2020-09-14
+      <td>Add labels specification 
      <tr>
       <td>0.1.2 
       <td>2020-05-07
@@ -2162,25 +2505,25 @@ <h3 class="no-ref no-num heading settled" id="w3c-conformant-algorithms"><span c
     and are not intended to be performant.
     Implementers are encouraged to optimize. </p>
   </div>
-<script src="https://www.w3.org/scripts/TR/2016/fixup.js"></script>
+<script src="https://www.w3.org/scripts/TR/2021/fixup.js"></script>
   <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
   <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
   <ul class="index">
-   <li><a href="#hdf5">HDF5</a><span>, in §1.1</span>
-   <li><a href="#ngff">NGFF</a><span>, in §1.1</span>
+   <li><a href="#hdf5">HDF5</a><span>, in § 1.1</span>
+   <li><a href="#ngff">NGFF</a><span>, in § 1.1</span>
   </ul>
   <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
   <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
   <dl>
    <dt id="biblio-rfc2119">[RFC2119]
-   <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>. March 1997. Best Current Practice. URL: <a href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
+   <dd>S. Bradner. <a href="https://datatracker.ietf.org/doc/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="https://datatracker.ietf.org/doc/html/rfc2119">https://datatracker.ietf.org/doc/html/rfc2119</a>
   </dl>
   <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
   <dl>
    <dt id="biblio-n5">[N5]
-   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62">N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
+   <dd>John A. Bogovic; et al. <a href="https://github.com/saalfeldlab/n5/issues/62"><cite>N5---a scalable Java API for hierarchies of chunked n-dimensional tensors and structured meta-data</cite></a>. 2020. Informational. URL: <a href="https://github.com/saalfeldlab/n5/issues/62">https://github.com/saalfeldlab/n5/issues/62</a>
    <dt id="biblio-ome-zarr-py">[OME-ZARR-PY]
-   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931">ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
+   <dd>OME; et al. <a href="https://doi.org/10.5281/zenodo.4113931"><cite>ome-zarr-py: Experimental implementation of next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4113931">https://doi.org/10.5281/zenodo.4113931</a>
    <dt id="biblio-zarr">[ZARR]
-   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231">Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
+   <dd>Alistair Miles; et al. <a href="https://doi.org/10.5281/zenodo.4069231"><cite>Zarr: An implementation of chunked, compressed, N-dimensional arrays for Python.</cite></a>. 06 October 2020. Informational. URL: <a href="https://doi.org/10.5281/zenodo.4069231">https://doi.org/10.5281/zenodo.4069231</a>
   </dl>
\ No newline at end of file