Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Generalize well organization in high-content screening: field of view => image #137

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Generalize well organization in high-content screening: field of view => image #137

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
55e28bf
Change field of view to image in well content
jluethi Aug 29, 2022
20261ac
Add note about trade-offs for single- vs multi-image wells
jluethi Aug 29, 2022
03e2812
Improve wordingwith feedback from @will-moore
jluethi Aug 29, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 23 additions & 18 deletions latest/index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.


<pre>
. # Root folder, potentially in S3,
Expand All @@ -208,15 +213,15 @@ 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"
│ │ │ ├── 0
│ │ │ │ ... # Resolution levels
│ │ │ ├── n
│ │ │ └── labels # Labels (optional)
│ │ ├── ... # Fields of view
│ │ ├── ... # Images belonging to well A1
│ │ └── m
│ ├── ... # Columns
│ └── 12
Expand Down Expand Up @@ -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
Expand All @@ -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.
Expand Down Expand Up @@ -466,15 +471,15 @@ 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.

<pre class=include-code>
path: examples/plate_strict/plate_6wells.json
highlight: json
</pre>

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.

<pre class=include-code>
path: examples/plate_strict/plate_2wells.json
Expand All @@ -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
Expand All @@ -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.

<pre class=include-code>
path: examples/well_strict/well_4fields.json
highlight: json
</pre>

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.

<pre class=include-code>
path: examples/well_strict/well_2fields.json
Expand Down