Microscopy#

Support for Microscopy was developed as a BIDS Extension Proposal.

Please see Citing BIDS on how to appropriately credit this extension when referring to it in the context of the academic literature.

Microscopy datasets formatted using this specification are available on the BIDS examples repository and can be used for practical guidance when curating a new dataset.

Further Microscopy datasets are available:

Microscopy imaging data#

Microscopy data MUST be stored in the micr directory.

File formats#

The Microscopy community uses a variety of formats for storing raw data, and there is no single standard that all researchers agree on. However, a standardized file structure has been developed by the Open Microscopy Environment for whole-slide imaging with the OME-TIFF file specifications. The OME-TIFF file allows for multi-page TIFF files to store multiple image planes and supports multi-resolution pyramidal tiled images. An OME-XML data block is also embedded inside the file’s header.

The BIDS standard accepts microscopy data in a number of file formats to accommodate datasets stored in 2D image formats and whole-slide imaging formats, to accommodate lossless and lossy compression, and to avoid unnecessary conversions of the original data from a non-tiled to a tiled format, or vice-versa.

Microscopy raw data MUST be stored in one of the following formats:

If different from PNG, TIFF or OME-TIFF, the original unprocessed data in the native format MAY be stored in the /sourcedata directory.

Future versions may extend this list of supported file formats, for example with the Next-Generation File Formats currently developed by OME (OME-NGFF) as a successor to OME-TIFF for better remote sharing of large datasets.

Modality suffixes#

Microscopy data currently support the following imaging modalities:

Filename entities#

In the context of Microscopy, a session (ses-<label>) can refer to all the acquisitions between the start and the end of an imaging experiment for ex vivo imaging, or a subject lab visit for biopsy procedure and/or in vivo imaging. Consistent with other data types in BIDS, the session entity is optional.

The sample-<label> entity is REQUIRED for Microscopy data and is used to distinguish between different samples from the same subject. The label MUST be unique per subject and is RECOMMENDED to be unique throughout the dataset.

For example: Three brain slices (sample-01 to sample-03) extracted from subject sub-01, imaged by scanning electron microscopy (SEM) in PNG format

In this example, the JSON metadata is common for all samples of sub-01. JSON metadata may be defined per subject or per sample as appropriate, as per the inheritance principle.

The acq-<label> entity corresponds to a custom label that MAY be used to distinguish a different set of parameters used for acquiring the same modality. For example, two images of the same sample acquired by bright-field microscopy (BF) in PNG format at different magnification of 40x and 60x. In such case two files could have the following names: sub-01_sample-01_acq-40x_BF.png and sub-01_sample-01_acq-60x_BF.png, however the user is free to choose any other label as long as they are consistent across subjects and sessions.

The stain-<label> entity MAY be used to distinguish image files from the same sample using different stains or antibodies for contrast enhancement.

For example: One brain slice (sample-01) extracted from subject sub-01 with three stains (stain-01, stain-02 and stain-03) in three separate files, imaged by selective plane illumination microscopy (SPIM) in OME-TIFF format

In this example, the entity stain is used to distinguish images with different stains in separate files from the same sample. In the case where a single file contains different staining in each channel, the stain-<label> is omitted.

Stains SHOULD be indicated in the "SampleStaining" key in the sidecar JSON file, although the label may be different. Description of antibodies SHOULD also be indicated in "SamplePrimaryAntibodies" and/or "SampleSecondaryAntobodies" as appropriate.

If more than one run of the same sample, acquisition and stain are acquired during the same session, the run-<index> entity MUST be used: _run-1, _run-2, _run-3, and so on. If only one run was acquired the run-<index> can be omitted.

The chunk-<index> entity is used when multiples regions (2D images or 3D volumes files) of the same physical sample are imaged with different fields of view, regardless if they overlap or not.

In some cases, the chunks can be “ordered” and, for example, correspond to the displacement of the microscope stage. In other cases, the chunks can be different images of the same sample with no explicit spatial relation between them.

Examples of different chunks configurations can be seen in Figure 1. Figure 1

Figure 1: Examples of chunks configurations.

  • a) ordered 2D chunks without overlap,

  • b) ordered 2D chunks with overlap,

  • c) unordered 2D chunks with and without overlap,

  • d) and e) ordered 2D chunks on different 3D planes,

  • f) ordered 3D chunks.

For example: Four chunks (chunk-01 to chunk-04) from the same brain sample (sample-01) of subject sub-01, imaged by confocal microscopy (CONF) in OME-TIFF format

The index number can be assigned arbitrarily and, in the case of “ordered” chunks, the chunks’ relative positions (in terms of scaling and translation) SHOULD be defined by an affine transformation matrix in the JSON sidecar file of each chunk, as described in Chunk Transformations.

In this example, the JSON metadata is different for each chunk of sub-01_sample-01. JSON metadata may be defined per sample or per chunk as appropriate, as per the inheritance principle.

In microscopy, many pyramidal file formats store multiple resolutions for the same acquisition. In the case where a multiple resolutions file format is converted to single resolution file format, only the higher resolution file is present in the raw data. Lower resolutions files MUST be placed under the derivatives directory and use the res-<label> entity.

For example:

See Preprocessed, coregistered and/or resampled volumes for details.

Microscopy metadata (Sidecar JSON)#

Microscopy data MUST be described by metadata fields, stored in sidecar JSON files.

Device Hardware#

Image Acquisition#

Sample#

Chunk Transformations#

Chunk transformations metadata describes the spatial relation between chunks of the same sample in an implicit coordinate system.

  • The source frame of reference is the frame of reference of the associated image.

  • The target frame of reference is the implicit coordinate system of the transform.

  • The target frame of reference has the same units as the PixelSizeUnits metadata.

  • The chunk transformation is described by 2 metadata fields: an affine transformation matrix and a description of the axis of the matrix.

  • Other transformations should be described in derivatives.

An example of chunk transformations JSON metadata for chunk-01 and chunk-05 of Figure 2 is shown below:

Figure 2

Figure 2: Example figure for chunks transformations.

In this example, there is no scaling and chunk-01 is at the origin. chunk-05 is translated by 5 um along X+ and by 3 um along Y+.

*_chunk-01_<suffix>.json:

{
        "PixelSize": [1, 1],
        "PixelSizeUnits": "um",
        "ChunkTransformationMatrix": [[1, 0, 0],
                                      [0, 1, 0],
                                      [0, 0, 1]],
        "ChunkTransformationMatrixAxis": ["X", "Y"]
}

*_chunk-05_<suffix>.json:

{
        "PixelSize": [1, 1],
        "PixelSizeUnits": "um",
        "ChunkTransformationMatrix": [[1, 0, 5],
                                      [0, 1, 3],
                                      [0, 0, 1]],
        "ChunkTransformationMatrixAxis": ["X", "Y"]
}

Example of sidecar JSON file (*_<suffix>.json)#

{
        "Manufacturer": "Hamamatsu",
        "ManufacturersModelName": "C9600-12",
        "PixelSize": [0.23, 0.23],
        "PixelSizeUnits": "um",
        "Magnification": 40,
        "BodyPart": "BRAIN",
        "BodyPartDetails": "corpus callosum",
        "SampleEnvironment": "ex vivo",
        "SampleFixation": "4% paraformaldehyde, 2% glutaraldehyde",
        "SampleStaining": "LFB",
        "SliceThickness": 5,
        "TissueDeformationScaling": 97
}

Required Samples file#

For Microscopy data, the Samples file samples.tsv is REQUIRED and its associated sidecar samples.json file is RECOMMENDED.

Additional optional columns MAY be used to describe other samples’ attributes.

Photos of the samples (*_photo.<extension>)#

Photos of the tissue sample, overview microscopy scans or blockface images from cutting MAY be included for visualization of large samples or to indicate the location of chunks in a sample.

The file <extension> for photos MUST be either .jpg, .png or .tif.

The acq-<label> entity MAY be used to indicate acquisition of different photos of the same sample.

For example:

Below is an example of a spinal cord SEM overview, modified from Zaimi et al., 2018. doi:10.1038/s41598-018-22181-4.

    sub-01_sample-01_photo.jpg

SEM overview