diff --git a/latest/index.bs b/latest/index.bs index 3ed6d7d7..61935db6 100644 --- a/latest/index.bs +++ b/latest/index.bs @@ -184,8 +184,7 @@ The following specification defines the hierarchy for a high-content screening dataset. Three groups MUST be defined above the images: - the group above the images defines the well and MUST implement the - [well specification](#well-md). All images contained in a well are fields - of view of the same well + [well specification](#well-md). A well is a collection of 1 to m images. - the group above the well defines a row of wells - 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 @@ -194,6 +193,12 @@ dataset. Three groups MUST be defined above the images: A well row group SHOULD NOT be present if there are no images in the well row. A well group SHOULD NOT be present if there are no images in the well. +Note: Field of views of the microscope may be saved as individual images in each +well to allow for maximal flexibility regarding translations between field of views. +However, having wells with many individual images does not scale well for visualisation of +large plates. In that case, combining the fields and saving as a single image +per Well is likely to improve performance. + 
 .                             # Root folder, potentially in S3,
@@ -208,7 +213,7 @@ A well group SHOULD NOT be present if there are no images in the well.
     │   │   ├── .zgroup
     │   │   ├── .zattrs       # Implements "well" specification
     │   │   │
-    │   │   ├── 0             # First field of view of well A1
+    │   │   ├── 0             # First image of well A1
     │   │   │   │
     │   │   │   ├── .zgroup
     │   │   │   ├── .zattrs   # Implements "multiscales", "omero"
@@ -216,7 +221,7 @@ A well group SHOULD NOT be present if there are no images in the well.
     │   │   │   │   ...       # Resolution levels
     │   │   │   ├── n
     │   │   │   └── labels    # Labels (optional)
-    │   │   ├── ...           # Fields of view
+    │   │   ├── ...           # Images belonging to well A1
     │   │   └── m
     │   ├── ...               # Columns
     │   └── 12
@@ -418,11 +423,11 @@ custom attributes of the plate group under the `plate` key in the group-level me
 The `plate` dictionary MAY contain an `acquisitions` key whose value MUST be a list of
 JSON objects defining the acquisitions for a given plate to which wells can refer to. Each
 acquisition object MUST contain an `id` key whose value MUST be an unique integer identifier
-greater than or equal to 0 within the context of the plate to which fields of view can refer
+greater than or equal to 0 within the context of the plate to which images can refer
 to (see #well-md).
 Each acquisition object SHOULD contain a `name` key whose value MUST be a string identifying
 the name of the acquisition. Each acquisition object SHOULD contain a `maximumfieldcount`
-key whose value MUST be a positive integer indicating the maximum number of fields of view for the
+key whose value MUST be a positive integer indicating the maximum number of images per well for the
 acquisition. Each acquisition object MAY contain a `description` key whose value MUST be a
 string specifying a description for the acquisition. Each acquisition object MAY contain
 a `starttime` and/or `endtime` key whose values MUST be integer epoch timestamps specifying
@@ -438,7 +443,7 @@ other `name` in the `columns` list. Care SHOULD be taken to avoid collisions on
 case-insensitive filesystems (e.g. avoid using both `Aa` and `aA`).
 
 The `plate` dictionary SHOULD contain a `field_count` key whose value MUST be a positive integer
-defining the maximum number of fields per view across all wells.
+defining the maximum number of images per well across all wells and all acquisitions.
 
 The `plate` dictionary SHOULD contain a `name` key whose value MUST be a string defining the
 name of the plate.
@@ -466,7 +471,7 @@ the index into the `columns` list. `rowIndex` and `columnIndex` MUST be 0-based.
 `rowIndex`, `columnIndex`, and `path` MUST all refer to the same row/column pair.
 
 For example the following JSON object defines a plate with two acquisitions and
-6 wells (2 rows and 3 columns), containing up to 2 fields of view per acquisition.
+6 wells (2 rows and 3 columns), containing up to 2 images per acquisition.
 
 
 path: examples/plate_strict/plate_6wells.json
@@ -474,7 +479,7 @@ highlight: json
 

 
 The following JSON object defines a sparse plate with one acquisition and
-2 wells in a 96 well plate, containing one field of view per acquisition.
+2 wells in a 96 well plate, containing one image per acquisition.
 
 
 path: examples/plate_strict/plate_2wells.json
@@ -484,13 +489,13 @@ highlight: json
 "well" metadata {#well-md}
 --------------------------
 
-For high-content screening datasets, the metadata about all fields of views
+For high-content screening datasets, the metadata about all images
 under a given well can be found under the "well" key in the attributes of the
 well group.
 
 The `well` dictionary MUST contain an `images` key whose value MUST be a list of JSON objects
-specifying all fields of views for a given well. Each image object MUST contain a
-`path` key whose value MUST be a string specifying the path to the field of view. The `path`
+specifying all images for a given well. Each image object MUST contain a
+`path` key whose value MUST be a string specifying the path to the image. The `path`
 MUST contain only alphanumeric characters, MUST be case-sensitive, and MUST NOT be a duplicate
 of any other `path` in the `images` list. If multiple acquisitions were performed in the plate,
 it MUST contain an `acquisition` key whose value MUST be an integer identifying the acquisition
@@ -499,18 +504,18 @@ which MUST match one of the acquisition JSON objects defined in the plate metada
 The `well` dictionary SHOULD contain a `version` key whose value MUST be a string specifying the
 version of the well specification.
 
-For example the following JSON object defines a well with four fields of
-view. 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.
+For example the following JSON object defines a well with four images.
+The first two images were part of the first acquisition while
+the last two images were part of the second acquisition.
 
 
 path: examples/well_strict/well_4fields.json
 highlight: json
 

 
-The following JSON object defines a well with two fields of view in a plate with
-four acquisitions. The first field is part of the first acquisition, and the second
-field is part of the last acquisition.
+The following JSON object defines a well with two images in a plate with
+four acquisitions. The first image is part of the first acquisition, and the second
+image is part of the last acquisition.
 
 
 path: examples/well_strict/well_2fields.json