OPENSLIDE-FORMATS(3)

NAME
openslide-formats - Reference supported formats

DESCRIPTION

LIST OF KNOWN PROPERTIES

  Properties generated by OpenSlide

openslide.background-color
    The background color of the slide, given as an RGB hex triplet. This property is not always present.

openslide.barcode
    The contents of the slide’s barcode. This property is not always present.

openslide.bounds-height
    The height of the rectangle bounding the non-empty region of the slide. This property is not always present.

openslide.bounds-width
    The width of the rectangle bounding the non-empty region of the slide. This property is not always present.

openslide.bounds-x
    The X coordinate of the rectangle bounding the non-empty region of the slide. This property is not always present.

openslide.bounds-y
    The Y coordinate of the rectangle bounding the non-empty region of the slide. This property is not always present.

openslide.comment
    A free-form text comment. This property is not always present.

openslide.icc-size
    The size of the slide’s ICC profile, if any.

openslide.mpp-x
    Microns per pixel in the X dimension of level 0. May not be present or accurate.

openslide.mpp-y
    Microns per pixel in the Y dimension of level 0. May not be present or accurate.

openslide.objective-power
    Magnification power of the objective. Often inaccurate; sometimes missing.

openslide.quickhash-1
    A non-cryptographic hash of a subset of the slide data. It can be used to uniquely identify a particular virtual slide, but cannot be used to detect file corruption or modification.

openslide.vendor
    The name of the vendor backend.

  Properties for TIFF-based formats

tiff.Artist
    The contents of the TIFF Artist tag.

tiff.Copyright
    The contents of the TIFF Copyright tag.

tiff.DateTime
    The contents of the TIFF DateTime tag.

tiff.DocumentName
    The contents of the TIFF DocumentName tag.

tiff.HostComputer
    The contents of the TIFF HostComputer tag.

tiff.ImageDescription
    The contents of the TIFF ImageDescripton tag.

tiff.Make
    The contents of the TIFF Make tag.

tiff.Model
    The contents of the TIFF Model tag.

tiff.ResolutionUnit
    The contents of the TIFF ResolutionUnit tag.

tiff.Software
    The contents of the TIFF Software tag.

tiff.XPosition
    The contents of the TIFF XPosition tag.

tiff.XResolution
    The contents of the TIFF XResolution tag.

tiff.YPosition
    The contents of the TIFF YPosition tag.

tiff.YResolution
    The contents of the TIFF YResolution tag.

  Vendor-specific properties

A list of vendor-specific properties can be found on the pages for each vendor format[1].

APERIO FORMAT

Format
    single-file pyramidal tiled TIFF, with non-standard metadata and compression

File extensions
    .svs

OpenSlide vendor backend
    aperio

  Vendor Documentation

Documentation PDF[2]

  Detection

Aperio slides are stored in single-file TIFF format. OpenSlide will detect a file as Aperio if:

    1. The file is TIFF.

    2. The initial image is tiled.

    3. The ImageDescription tag starts with Aperio.

  Relevant TIFF tags
Tag | Description
ImageDescription | Stores some important key-value pairs and other information, see below
Compression | May be 33003 or 33005, which represent specific kinds of JPEG 2000 compression, see below
NewSubfileType | 1 for the label associated image, 9 for the macro associated image

  Extra data stored in ImageDescription

For tiled images, the ImageDescription tag contains some dimensional downsample information as well as what look like offsets. Additionally, vertical line-delimited key-value pairs are stored, in at least the full-resolution image. A key-value pair is equals-delimited. These key-values are stored as properties starting with “aperio.”. Currently, OpenSlide does not use any of the information present in these key-value fields.

  TIFF Image Directory Organization

Digital Slides and Third-Party Data Interchange[2] page 14:

The first image in an SVS file is always the baseline image (full resolution). This image is always tiled, usually with a tile size of 240x240 pixels. The second image is always a thumbnail, typically with dimensions of about 1024x768 pixels. Unlike the other slide images, the thumbnail image is always stripped. Following the thumbnail there may be one or more intermediate “pyramid” images. These are always compressed with the same type of compression as the baseline image, and have a tiled organization with the same tile size.

Optionally at the end of an SVS file there may be a slide label image, which is a low resolution picture taken of the slide’s label, and/or a macro camera image, which is a low resolution picture taken of the entire slide. The label and macro images are always stripped.

  JPEG 2000 (compression types 33003 or 33005)

Some Aperio files use compression type 33003 or 33005. Images using this compression need to be decoded as a JPEG 2000 codestream. For 33003: YCbCr format with no MCT, possibly with a chroma subsampling of 4:2:2. For 33005: MCT, which OpenJPEG decodes into RGB. Note that the TIFF file may not encode the colorspace or subsampling parameters in the PhotometricInterpretation field, nor the YCbCrSubsampling field, even though the TIFF standard seems to require this. The correct subsampling can be found in the JPEG 2000 codestream.

  ICC Profiles

The slide ICC profile is taken from the ICC Profile tag of the first image.

  Associated Images

There are up to three stripped images: a thumbnail image, which is always the second image in the file; and label and macro images at the end of the file, with subfile types 1 and 9 respectively.

label
    optional, non-tiled image with subfile type 1

macro
    optional, non-tiled image with subfile type 9

thumbnail
    the second image in the file

  Known Properties

All key-value data encoded in the ImageDescription TIFF field is represented as properties prefixed with “aperio.”.

openslide.mpp-x
    normalized aperio.MPP

openslide.mpp-y
    normalized aperio.MPP

openslide.objective-power
    normalized aperio.AppMag

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/[3]

ARGOS FORMAT

Format
    single-file pyramidal tiled BigTIFF with non-standard metadata

File extensions
    .avs

OpenSlide vendor backend
    argos

  Vendor Documentation

Documentation PDF[4]

  Detection

ARGOS slides are stored in single-file BigTIFF format. OpenSlide will detect a file as ARGOS if:

    1. The file is TIFF.

    2. The initial image is tiled.

    3. Tag 65000 contains valid XML whose root element is Argos.Scan.Metadata.

  Relevant TIFF tags
Tag | Description
65000 | Metadata XML

  Metadata XML

The first TIFF directory includes metadata XML in TIFF tag 65000. The field type is ASCII, but in our samples the value is not NUL-terminated as required by TIFF, causing libtiff to warn about it.
Value | Description
MaxZ | Integer identifier for highest focal plane
MinZ | Integer identifier for lowest focal plane
ScanArea | Coordinates of scanned portion of the slide (cm)
ZRange | Distance between outermost focal planes (μm)

  TIFF Image Directory Organization

The TIFF file contains the image pyramid of the lowest focal plane, followed by each higher plane in succession. Images are sparse, with missing tiles represented by a zero TileOffset and a zero TileByteCount.

The last two TIFF directories are the thumbnail and macro images, which are both stripped.

  Associated Images

thumbnail
    second-to-last image in the file, non-tiled

macro
    last image in the file, non-tiled

  Known Properties

All simple key-value data encoded in the metadata XML is represented as properties prefixed with “argos.”.

openslide.barcode
    argos.Barcode

openslide.mpp-x
    calculated as 10000/tiff.XResolution, if tiff.ResolutionUnit is centimeter

openslide.mpp-y
    calculated as 10000/tiff.YResolution, if tiff.ResolutionUnit is centimeter

openslide.objective-power
    normalized argos.ObjectiveMagnification

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Argos/[5]

DICOM FORMAT

Format
    international standard multi-file medical imaging format

File extensions
    .dcm

OpenSlide vendor backend
    dicom

  Format Documentation

DICOM Whole Slide Imaging[6]

  Detection

OpenSlide will detect a file as DICOM if:

    1. The file can be parsed as a DICOM Part 10 file.

    2. The file does not have a .tif or .tiff filename extension or cannot be parsed as a TIFF file.

    3. The Media Storage SOP Class UID is VL Whole Slide Microscopy Image Storage (1.2.840.10008.5.1.4.1.1.77.1.6).

  File Organization

OpenSlide uses libdicom[7] to parse and load DICOM files.

OpenSlide non-recursively scans the containing directory for other DICOM files with the same Series Instance UID attribute value as the specified file. It uses the Image Flavor (value 3 of the Image Type attribute) of each matching file to determine the file’s role within the whole slide image:
Role | Image Flavor values
Slide level | VOLUME
Associated image | LABEL OVERVIEW THUMBNAIL
Ignored | All others

A slide level can be spread across multiple files that share a Concatenation UID.

If multiple files in the directory have the same SOP Instance UID, the extra copies are ignored.

A file’s Dimension Organization Type can be TILED_FULL, TILED_SPARSE, or 3D. These transfer syntaxes and photometric interpretations are supported:
Pixel encoding | Transfer Syntax UID | Allowed Photometric Interpretation values
Uncompressed little-endian | 1.2.840.10008.1.2.1 | RGB
JPEG baseline | 1.2.840.10008.1.2.4.50 | RGB YBR_FULL_422
JPEG 2000 | 1.2.840.10008.1.2.4.91 | RGB YBR_ICT YBR_RCT
JPEG 2000 (lossless only) | 1.2.840.10008.1.2.4.90 | RGB YBR_RCT

  ICC Profiles

The slide ICC profile is taken from the ICC Profile attribute of the highest-resolution image. Associated image ICC profiles are taken from the ICC Profile of the associated image.

  Associated Images
Associated image | Image Flavor
label | LABEL
macro | OVERVIEW
thumbnail | THUMBNAIL

  Known Properties

Many DICOM attributes are represented hierarchically as properties prefixed with “dicom.”.

openslide.barcode
    Barcode Value from highest-resolution level

openslide.mpp-x
    normalized X component of Pixel Spacing from highest-resolution level

openslide.mpp-y
    normalized Y component of Pixel Spacing from highest-resolution level

openslide.objective-power
    Objective Lens Power from highest-resolution level

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/DICOM/[8]

HAMAMATSU FORMAT

Format
    multi-file JPEG/NGR with proprietary metadata and index file formats, and single-file TIFF-like format with proprietary metadata

File extensions
    .vms, .vmu, .ndpi

OpenSlide vendor backend
    hamamatsu

  Detection

OpenSlide will detect a file as Hamamatsu if:

    1. The file given is a INI-style text file.

    2. It has a [Virtual Microscope Specimen] (VMS) or [Uncompressed Virtual Microscope Specimen] (VMU) group.

    3. If VMS, there are at least 1 row and 1 column of JPEG images (NoJpegColumns and NoJpegRows).

or if:

    1. The file has a TIFF directory structure.

    2. TIFF tag 65420 is present.

  Overview

The Hamamatsu format has three variants. VMS and VMU consist of an index file, 2 or more image files, and (in the case of VMS) an “optimisation” file. NDPI consists of a single TIFF-like file with some custom TIFF tags. VMS and NDPI contain JPEG images; VMU contains NGR images (a custom uncompressed format).

Multiple focal planes are ignored, only focal plane 0 is read.

JPEG does not allow for files larger than 65535 pixels on a side. In VMS, multiple JPEG files are used to encode large images. To avoid having many files, VMS uses close to maximum size (65K by 65K) JPEG files. NDPI, instead, stuffs large levels into a single JPEG and sets the overflowed width/height fields to 0.

Unfortunately, JPEG provides very poor support for random-access decoding of parts of a file. To get around this, JPEG restart markers are placed at regular intervals, and these offsets are specified in the optimisation file (in VMS) or in a TIFF tag (in NDPI). With restart markers identified, OpenSlide can treat JPEG as a tiled format, where the height is the height of an MCU row, and the width is the number of MCUs per row divided by the restart marker interval times the width of an MCU. (This often leads to oddly-shaped and inefficient tiles of 4096x8, for example.)

Unfortunately, the VMS optimisation file does not give the location of every restart marker, only the ones found at the beginning of an MCU row. It also seems that the file ends early, and does not give the location of the restart marker at the last MCU row of the last image file.

Thus, the optimisation file can only be taken as a hint, and cannot be trusted. The entire set of JPEG files must be scanned for restart markers in order to facilitate random access. OpenSlide does this lazily as needed, and also in a background thread that runs only when OpenSlide is otherwise idle.

The VMS map file is a lower-resolution version of the other images, and can be used to make a 2-level JPEG pyramid. JPEG also allows for lower-resolution decoding, so further pyramid levels are synthesized from each JPEG file.

  VMS File

The .vms file is the main index file for the VMS format. It is a Windows INI-style key-value pair file, with sections. Only keys in the Virtual Microscope Specimen group are read by OpenSlide.

Here are known keys from the file:
Key | Description
NoLayers | Number of layers, currently must be 1 to be accepted
NoJpegColumns | Number of JPEG files across, given in ImageFile attributes
NoJpegRows | Number of JPEG files down, given in ImageFile attributes
ImageFile | Semantically equivalent to ImageFile(0,0,0), though not specified that way. The image in position (0,0,0) of the set of images
ImageFile(x,y) | Semantically equivalent to ImageFile(0,x,y), though not specified that way. The image in position (0,x,y) of the set of images
ImageFile(z,x,y) | Where x and y are non-negative integers. Both x and y cannot be 0. z is a positive integer. These are the images that make up the virtual slide, as a concatenation of JPEG images. x and y specify the location of each JPEG, z specifies the focal plane
MapFile | A lower-resolution version of all the ImageFiles
OptimisationFile | File specifying some of the restart marker offsets in each ImageFile
AuthCode | Unknown
SourceLens | Apparently the objective power
PhysicalWidth | Width of the main image in nm
PhysicalHeight | Height of the main image in nm
LayerSpacing | Unknown
MacroImage | Image file for the “macro” associated image
PhysicalMacroWidth | Width of the macro image in nm
PhysicalMacroHeight | Height of the macro image in nm, sometimes with a trailing semicolon
XOffsetFromSlideCentre | Distance in X from the center of the entire slide (i.e., the macro image) to the center of the main image, in nm
YOffsetFromSlideCentre | Distance in Y from the center of the entire slide to the center of the main image, in nm

  VMU File

The .vmu file is the main index file for the VMU format. Only keys in the Uncompressed Virtual Microscope Specimen group are read by OpenSlide.

Here are known keys from the file:
Key | Description
NoLayers | (see VMS above)
ImageFile | (see VMS above)
ImageFile(x,y) | (see VMS above)
ImageFile(z,x,y) | (see VMS above)
MapFile | (see VMS above)
MapScale | Seems to be the downsample factor of the map
AuthCode | (see VMS above)
SourceLens | (see VMS above)
PixelWidth | Width of the image in pixels
PixelHeight | Height of the image in pixels
PhysicalWidth | (see VMS above)
PhysicalHeight | (see VMS above)
LayerSpacing | (see VMS above)
LayerOffset | Unknown
MacroImage | (see VMS above)
PhysicalMacroWidth | (see VMS above)
PhysicalMacroHeight | (see VMS above)
XOffsetFromSlideCentre | (see VMS above)
YOffsetFromSlideCentre | (see VMS above)
Reference | Unknown
BitsPerPixel | Bits per pixel, currently expected to be 36
PixelOrder | Currently expected to be RGB
Creator | String describing the software creating this image
IlluminationMode | Unknown
ExposureMultiplier | Unknown, possibly the multiplier used to scale to 15 bits?
GainRed | Unknown
GainGreen | Unknown
GainBlue | Unknown
FocalPlaneTolerance | Unknown
NMP | Unknown
MacroIllumination | Unknown
FocusOffset | Unknown
RefocusInterval | Unknown
CubeName | Unknown
HardwareModel | Name of the hardware
HardwareSerial | Serial number of the hardware
NoFocusPoints | Unknown
FocusPoint0X | Unknown
FocusPoint0Y | Unknown
FocusPoint0Z | Unknown
FocusPoint1X | Unknown
FocusPoint1Y | Unknown
FocusPoint1Z | Unknown
FocusPoint2X | Unknown
FocusPoint2Y | Unknown
FocusPoint2Z | Unknown
FocusPoint3X | Unknown
FocusPoint3Y | Unknown
FocusPoint3Z | Unknown
NoBlobPoints | Unknown
BlobPoint0Blob | Unknown
BlobPoint0FocusPoint | Unknown
BlobPoint1Blob | Unknown
BlobPoint1FocusPoint | Unknown
BlobPoint2Blob | Unknown
BlobPoint2FocusPoint | Unknown
BlobPoint3Blob | Unknown
BlobPoint3FocusPoint | Unknown
BlobMapWidth | Unknown
BlobMapHeight | Unknown

  NDPI File

NDPI uses a TIFF-like structure, but libtiff cannot read the headers of an NDPI file. This is because NDPI specifies the RowsPerStrip as the height of the file, and after doing out the multiplication, this typically overflows libtiff and it refuses to open the file. Also, the TIFF tags are not stored in sorted order, and ASCII values are always stored out-of-line even when TIFF would store them inline.

NDPI stores an image pyramid in TIFF directory entries. In some files, the lower-resolution pyramid levels contain no restart markers. The macro image, and sometimes an active-region map, seems to come last.

JPEG files in NDPI are not necessarily valid. If ImageWidth or ImageHeight exceeds the JPEG limit of 65535, then the width or height as stored in the JPEG file is 0. libjpeg will refuse to read the header of such a file, so the JPEG data stream must be altered when fed into libjpeg.

Conversely, on some pyramid levels without restart markers, the TIFF ImageWidth and ImageHeight may not match the JPEG dimensions due to inconsistent rounding.

NDPI is based on the classic TIFF format, which does not support files larger than 4 GB. However, NDPI files can be larger than 4 GB. NDPI handles this by storing the high-order bits of file offsets beyond the ends of standard TIFF structures. TIFF puts next-directory offsets (in the TIFF header and at the end of each directory) at the ends of their parent data structures, so NDPI simply extends these values to 64-bit quantities. The high-order bits of directory entry Value Offsets are stored in an array immediately after the end of each TIFF directory, 4 bytes per directory entry. Values that would normally be stored inline in the Value Offset (not ASCII, as mentioned above) are still stored inline, even if the high 32 bits are non-zero (e.g. StripOffsets and StripByteCounts, which always have a Count of 1 in NDPI), and other values are still stored out-of-line.

Here are the observed TIFF tags:
Tag | Description
ImageWidth | Width of the image
ImageHeight | Height of the image
Make | “Hamamatsu”
Model | “NanoZoomer” or “C9600-12”, etc
XResolution | Seemingly correct X resolution, when interpreted with ResolutionUnit
YResolution | Seemingly correct Y resolution, when interpreted with ResolutionUnit
ResolutionUnit | Seemingly correct resolution unit
Software | “NDP.scan”, sometimes with a version number
StripOffsets | The offset of the JPEG file for this layer
StripByteCounts | The length of the JPEG file for this layer
65420 | Always exists, always 1. File format version?
65421 | SourceLens, correctly downsampled for each entry. -1 for macro image, -2 for a map of non-empty regions.
65422 | XOffsetFromSlideCentre
65423 | YOffsetFromSlideCentre
65424 | Seemingly the Z offset from the center focal plane (in nm?)
65425 | Unknown, always 0?
65426 | Low 32 bits of optimisation entries, as above
65427 | Reference
65428 | Unknown, AuthCode?
65430 | Unknown, have seen 0.0
65432 | High 32 bits of optimisation entries
65433 | Unknown, I have seen 1500 in this tag
65439 | Unknown, perhaps some polygon ROI?
65440 | Unknown, I have seen this: <0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 1 9 1 10 1 11 1 12 1 13 1 14 1 15 1 16 1 17>
65441 | Unknown, always 0?
65442 | Scanner serial number
65443 | Unknown, have seen 0 or 16
65444 | Unknown, always 80?
65445 | Unknown, have seen 0, 2, 10
65446 | Unknown, always 0?
65449 | ASCII metadata block, key=value pairs, not always present
65455 | Unknown, have seen 13
65456 | Unknown, have seen 101
65457 | Unknown, always 0?
65458 | Unknown, always 0?
65459 | Unknown, have seen ASCII “JPEG”, “Native RGB”, and “RGB”

  Optimisation File (only for VMS)

The optimisation file contains a list of 32- (or 64- or 320- ?) bit little endian values, giving the file offset into an MCU row, each offset starts at a 40-byte alignment, and the last row (of the entire file, not each image) seems to be missing. The offsets are all packed into 1 file, even with multiple images. The order of images is left-to-right, top-to-bottom.

  Map File (only for VMS/VMU)

The VMS map file is a standard JPEG file. Its restart markers (if any) are not included in the optimisation file. The VMU map file is in NGR format. This file can be used to provide a lower-resolution view of the slide.

  Image Files (only for VMS/VMU)

These files are given by the VMS/VMU ImageFile keys. They are assumed to have a height which is a multiple of the MCU height. They are assumed to have a width which is a multiple of MCUs per row divided by the restart interval.

For VMS, these files are in JPEG, for VMU they are in NGR format.

  NGR Format

The NGR file contains uncompressed 16-bit RGB data, with a small header. The files we have encountered start with GN, two more bytes, and then width, height, and column width in little endian 32-bit format. The column width must divide evenly into the width. Column width is important, since NGR files are generated in columns, where the first column comes first in the file, followed by subsequent files. Columns are painted left-to-right.

At offset 24 is another 32-bit integer which gives the offset in the file to the start of the image data. The image data we have encountered is in 16-bit little endian format.

  Associated Images

macro
    the image file given by the MacroImage value in the VMS/VMU file, or SourceLens of -1 in NDPI

  Known Properties

All key-value data stored in the VMS/VMU file, and known tags from the NDPI file, are encoded as properties prefixed with “hamamatsu.”.

openslide.mpp-x
    For VMS, calculated as hamamatsu.PhysicalWidth/(1000*openslide.level[0].width). For NDPI, calculated as 10000/tiff.XResolution, if tiff.ResolutionUnit is centimeter.

openslide.mpp-y
    For VMS, calculated as hamamatsu.PhysicalHeight/(1000*openslide.level[0].height). For NDPI, calculated as 10000/tiff.YResolution, if tiff.ResolutionUnit is centimeter.

openslide.objective-power
    normalized hamamatsu.SourceLens

  Test Data

NDPI format
    https://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu/[9]

VMS format
    https://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu-vms/[10]

  ImHex Patterns
<listitem>VMS optimisation file[11] </listitem><listitem>VMU NGR file[12] </listitem><listitem>NDPI file[13] </listitem>.SH "HURON FORMAT"

Format
    single-file pyramidal tiled TIFF with non-standard metadata

File extensions
    .tif

OpenSlide vendor backend
    huron

  Detection

Huron slides are stored in single-file TIFF format. OpenSlide will detect a file as Huron if:

    1. The file is TIFF.

    2. The initial image is tiled.

    3. The ImageMake tag starts with Huron.

  Relevant TIFF tags
Tag | Description
ImageDescription | Stores some important key-value pairs, see below
ImageMake | Starts with Huron
NewSubfileType | 1 for the label associated image, 9 for the macro associated image
XResolution, YResolution, ResolutionUnit | The pixel size in pyramid level 0

  Extra data stored in ImageDescription

The ImageDescription tag of the first TIFF directory contains newline-delimited key-value pairs. A key-value pair is equals-delimited with extra padding spaces. These key-values are stored as properties starting with “huron.”. Currently, OpenSlide does not use any of the information present in these key-value fields.

  TIFF Image Directory Organization

The directory organization follows the same pattern as the Aperio format[14].

  Associated Images

There are up to three stripped images: a thumbnail image, which is always the second image in the file; and label and macro images at the end of the file, with subfile types 1 and 9 respectively.

label
    optional, non-tiled image with subfile type 1

macro
    optional, non-tiled image with subfile type 9

thumbnail
    the second image in the file

  Known Properties

All key-value data encoded in the ImageDescription TIFF field is represented as properties prefixed with “huron.”.

openslide.mpp-x
    normalized TIFF resolution

openslide.mpp-y
    normalized TIFF resolution

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Huron/[15]

LEICA FORMAT

Format
    single-file pyramidal tiled BigTIFF with non-standard metadata

File extensions
    .scn

OpenSlide vendor backend
    leica

  Detection

Leica slides are stored in single-file BigTIFF format. OpenSlide will detect a file as Leica if:

    1. The file is TIFF.

    2. The initial image is tiled.

    3. The ImageDescription tag contains valid XML in either of these namespaces:<listitem>http://www.leica-microsystems.com/scn/2010/03/10 </listitem><listitem>http://www.leica-microsystems.com/scn/2010/10/01 </listitem>

  Relevant TIFF tags
Tag | Description
ImageDescription | Stores an XML document containing various metadata

  File Organization

The ImageDescription tag of the first TIFF directory contains an XML document that defines the structure of the slide.

Leica slides are structured as a collection of images, each of which has multiple dimensions (pyramid levels). The collection has a size, and images have a size and position, measured in nanometers. Each dimension has a size in pixels, an optional focal plane number, and a TIFF directory containing the image data. Fluorescence images have different dimensions (and thus different TIFF directories) for each channel. OpenSlide currently rejects fluorescence images and ignores focal planes other than plane 0.

Brightfield slides have at least two images: a low-resolution macro image and one or more main images corresponding to regions of the macro image. The macro image has a position of (0, 0) and a size matching the size of the collection. Fluorescence slides can have two macro images: one brightfield and one fluorescence.

The slide provides enough information to composite the various images, including the macro image, into a single pyramid. However, there are some complications: <listitem>The resolution of the macro image is generally not related to the resolution of the main images by a power of two. </listitem><listitem>Downsampled dimensions are generally downsampled from the next larger dimension by a factor of 4, but main images can be scanned with distinct objectives that may differ by only a factor of 2. </listitem>.PP Thus, in general, the images in a collection cannot be rendered into a unified pyramid without scaling the original pixel data. OpenSlide does not attempt to do this. Instead, OpenSlide omits the macro image from the pyramid and refuses to open slides whose main images have inconsistent resolutions.

  Associated Images

macro
    the highest-resolution dimension of the macro image

  Known Properties

leica.aperture
    the numericalAperture of the main image

leica.barcode
    the barcode text. (For slides in the 2010/10/01 namespace, OpenSlide 3.4.0 and earlier report this property as a Base64-encoded string; OpenSlide 3.4.1 and later report it in plain text. For slides in the 2010/03/10 namespace, OpenSlide reports the barcode as it is stored in the XML, since we do not know whether those barcodes are Base64-encoded. If you have a 2010/03/10 slide with a bar code, please comment in this bug[16] or contact the OpenSlide mailing list.)

leica.creation-date
    the creationDate of the main image

leica.device-model
    the device model of the main image

leica.device-version
    the device version of the main image

leica.illumination-source
    the illuminationSource of the main image

leica.objective
    the objective of the main image

openslide.barcode
    leica.barcode

openslide.mpp-x
    calculated as 10000/tiff.XResolution, if tiff.ResolutionUnit is centimeter

openslide.mpp-y
    calculated as 10000/tiff.YResolution, if tiff.ResolutionUnit is centimeter

openslide.objective-power
    normalized leica.objective

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Leica/[17]

MIRAX FORMAT

Format
    multi-file with very complicated proprietary metadata and indexes

File extensions
    .mrxs

OpenSlide vendor backend
    mirax

  Detection

OpenSlide will detect a file as MIRAX if:

    1. The file is not a TIFF.

    2. The filename ends with .mrxs.

    3. A directory exists in the same location as the file, with the same name as the file minus the extension.

    4. A file named Slidedat.ini exists in the directory.

  Overview

MIRAX can store slides in JPEG, PNG, or BMP formats. Because JPEG does not allow for large images, and JPEG and PNG provide very poor support for random-access decoding of part of an image, multiple images are needed to encode a slide. To avoid having many individual files, MIRAX packs these images into a small number of data files. The index file provides offsets into the data files for each required piece of data.

The camera on MIRAX scanners takes overlapping photos and records the position of each one. Each photo is then split into multiple images which do not overlap. Overlaps only occur between images that come from different photos.

To generate level n + 1, each image from level n is downsampled by 2 and then concatenated into a new image, 4 old images per new image (2 x 2). This process is repeated for each level, irrespective of image overlaps. Therefore, at sufficiently high levels, a single image can contain one or more embedded overlaps of non-integral width.

  Index File

The index file starts with a five-character ASCII version string, followed by the SLIDE_ID from the slidedat file. The rest of the file consists of 32-bit little-endian integers (unaligned), which can be data values or pointers to byte offsets within the index file.

The first two integers point to offset tables for the hierarchical and nonhierarchical roots, respectively. These tables contain one record for each VAL in the HIERARCHICAL slidedat section. For example, the record for NONHIER_1_VAL_2 would be stored at nonhier_root + 4 * (NONHIER_0_COUNT + 2).

Each record is a pointer to a linked list of data pages. The first two values in a data page are the number of data items in the page and a pointer to the next page. The first page always has 0 data items, and the last page has a 0 next pointer.

There is one hierarchical record for each zoom level. The record contains data items consisting of an image index, offset and length within a file, and a file number. The file number can be converted to a data file name via the DATAFILE slidedat section. The image index is equal to image_y * GENERAL.IMAGENUMBER_X + image_x. Image coordinates which are not multiples of the zoom level’s downsample factor are omitted.

Nonhierarchical records refer to associated images and additional metadata. Nonhierarchical data items consist of two values which are usually zero, followed by an offset, length, and file number as in hierarchical records.

  Data Files

A data file begins with a header containing a five-character ASCII version string, the SLIDE_ID from the slidedat file, the file number encoded into three ASCII characters, and 256 bytes of padding. (In newer slides, the SLIDE_ID and file number are encoded as UTF-16LE, so the second half of each value is truncated away.) The remainder of the file contains packed data referenced by the index file.

  Slide Position File

The slide position file is referenced by the VIMSLIDE_POSITION_BUFFER.default nonhierarchical section. It contains one entry for each camera position (not each image position) in row-major order. Each entry is nine bytes: a flag byte, the X pixel coordinate of the photo (4 bytes, little-endian, may be negative), and the Y coordinate (4 bytes, little-endian, may be negative). In slides with CURRENT_SLIDE_VERSION ≥ 1.9, the flag byte is 1 if the slide file contains images for this camera position, 0 otherwise. In older slides, the flag byte is always 0.

In slides with CURRENT_SLIDE_VERSION ≥ 2.2, the slide position file is compressed with DEFLATE and referenced by the StitchingIntensityLayer.StitchingIntensityLevel nonhierarchical section. In some such slides, the nonhierarchical record has a second data item which points to a DEFLATE-compressed blob with four bytes of additional metadata per camera position.

  Associated Images

label
    the image named “ScanDataLayer_SlideBarcode” in Slidedat.ini (optional)

macro
    the image named “ScanDataLayer_SlideThumbnail” in Slidedat.ini (optional)

thumbnail
    the image named “ScanDataLayer_SlidePreview” in Slidedat.ini (optional)

  Known Properties

All key-value data stored in the Slidedat.ini file are encoded as properties prefixed with “mirax.”.

openslide.mpp-x
    normalized MICROMETER_PER_PIXEL_X from the Slidedat section corresponding to level 0 (typically mirax.LAYER_0_LEVEL_0_SECTION.MICROMETER_PER_PIXEL_X)

openslide.mpp-y
    normalized MICROMETER_PER_PIXEL_Y from the Slidedat section corresponding to level 0 (typically mirax.LAYER_0_LEVEL_0_SECTION.MICROMETER_PER_PIXEL_Y)

openslide.objective-power
    normalized mirax.GENERAL.OBJECTIVE_MAGNIFICATION

  See Also

Introduction to MIRAX/MRXS[18]. Note that our terminology has changed since that document was written; where it says “tile”, substitute “image”, and where it says “subtile”, substitute “tile”.

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Mirax/[19]

  ImHex Patterns
<listitem>Index file[20] </listitem><listitem>Slide position file[21] </listitem>.SH "PHILIPS FORMAT"

Format
    single-file pyramidal tiled TIFF or BigTIFF with non-standard metadata

File extensions
    .tiff

OpenSlide vendor backend
    philips

  Detection

Philips TIFF files are stored in single-file TIFF or BigTIFF format. OpenSlide will detect a file as Philips if:

    1. The file is TIFF.

    2. The TIFF Software tag starts with Philips.

    3. The ImageDescription tag contains valid XML.

    4. The root element of the XML is DataObject and has an ObjectType attribute with a value of DPUfsImport.

  File Organization

Philips TIFF is an export format. The native Philips format, iSyntax, is a custom multi-file format not currently supported by OpenSlide.

The ImageDescription tag of the first TIFF directory contains an XML document with a hierarchical structure containing key-value pairs. The keys are based on DICOM tags.

The level dimensions given in the TIFF ImageWidth and ImageLength fields, and also in the ImageDescription XML, are merely the TIFF tile size multiplied by the number of tiles in each dimension. Thus, they include the size of the padding in the right-most column and bottom-most row of tiles. Each level typically uses the same tile size but requires a different amount of padding, so the aspect ratios of the levels are inconsistent and the level dimensions are not proportional to the level downsamples. Correct downsamples can be calculated from the levels’ pixel spacings in the XML metadata.

Slides with multiple regions of interest are structured as a single image pyramid enclosing all regions. Slides may omit pixel data for TIFF tiles not in an ROI; this is represented as a TileOffset of 0 and a TileByteCount of 0. When such tiles are downsampled into a tile that does contain pixel data, their contents are rendered as white pixels.

Label and macro images are stored as Base64-encoded JPEGs in the ImageDescription XML. Some slides also store these images as stripped TIFF directories whose ImageDescriptions start with Label and Macro, respectively.

  Relevant TIFF tags
Tag | Description
ImageDescription | Stores an XML document containing various metadata and associated image data
Software | Starts with Philips

  Associated Images

label
    the TIFF directory with an ImageDescription starting with Label, or the image data in the DPScannedImage with a PIM_DP_IMAGE_TYPE of LABELIMAGE

macro
    the TIFF directory with an ImageDescription starting with Macro, or the image data in the DPScannedImage with a PIM_DP_IMAGE_TYPE of MACROIMAGE

  Known Properties

All key-value data encoded in the DPUfsImport object, in the first DPScannedImage object with a PIM_DP_IMAGE_TYPE of WSI, and in that object’s PixelDataRepresentation objects is represented as properties prefixed with “philips.”.

openslide.barcode
    Base64-decoded philips.PIM_DP_UFS_BARCODE

openslide.mpp-x
    calculated as 1000 * philips.DICOM_PIXEL_SPACING[1]

openslide.mpp-y
    calculated as 1000 * philips.DICOM_PIXEL_SPACING[0]

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Philips-TIFF/[22]

SAKURA FORMAT

Format
    SQLite database containing pyramid tiles and metadata

File extensions
    .svslide

OpenSlide vendor backend
    sakura

  Detection

OpenSlide will detect a file as Sakura if:

    1. The file is a SQLite database.

    2. The DataManagerSQLiteConfigXPO table contains exactly one row, and its TableName field refers to a unique table.

    3. The unique table contains a row with id = "++MagicBytes" and data = "SVGigaPixelImage".

  File Organization

Sakura slides are SQLite 3 database files written by the eXpress Persistent Objects ORM. Tables contain slide metadata, associated images, and JPEG tiles. Tiles are addressed as (focal plane, downsample, level-0 X coordinate, level-0 Y coordinate, color channel), with separate grayscale JPEGs for each color channel. Despite the generality of the address format, tiles appear to be organized in a regular grid, with power-of-two level downsamples and without overlapping tiles. The structure of the file allows scans to be sparse, but it is not clear if this is actually done.

  SQL Tables

Some irrelevant tables and columns have been omitted from the summary below. DataManagerSQLiteConfigXPO.PP Useful only to get a reference to the unique table. OpenSlide requires this table to contain exactly one row.
Column | Type | Description
TableName | text | Name of the unique table, described below

SVSlideDataXPO.PP High-level metadata about a slide. OpenSlide assumes this table will contain exactly one row.
Column | Type | Description
OID | integer | Primary key
m_labelScan | integer | Foreign key to label associated image in SVScannedImageDataXPO
m_overviewScan | integer | Foreign key to macro associated image in SVScannedImageDataXPO
SlideId | text | UUID
Date | text | File creation date?
Description | text | Descriptive text?
Creator | text | Author?
DiagnosisCode | text | Unknown, have seen “0”
HRScanCount | integer | Presumably the number of corresponding rows in SVHRScanDataXPO
Keywords | text | Descriptive text?
TotalDataSizeBytes | integer | Presumably the sum of TotalDataSizeBytes in corresponding SVHRScanDataXPO rows

SVHRScanDataXPO.PP A single high-resolution scan of a slide from SVSlideDataXPO. OpenSlide assumes this table will contain exactly one row.
Column | Type | Description
OID | integer | Primary key
ParentSlide | integer | Foreign key to SVSlideDataXPO
ScanId | text | UUID
Date | text | Scan date?
Description | text | Descriptive text?
Name | text | Scan name?
PosOnSlideMm | blob | 16 bytes of binary
ResolutionMmPerPix | real | Millimeters per pixel
NominalLensMagnification | real | Objective power
ThumbnailImage | blob | thumbnail associated image data
TotalDataSizeBytes | integer | Same as TOTAL_SIZE blob in unique table
FocussingMethod | integer | Unknown; have seen “1”
FocusStack | blob | 8 bytes of binary per focal plane; the center focal plane apparently has all zeroes

SVScannedImageDataXPO.PP Contains associated images other than the thumbnail.
Column | Type | Description
OID | integer | Primary key
Id | text | UUID
PosOnSlideMm | blob | 16 bytes of binary
ScanCenterPosMm | blob | 16 bytes of binary
ResolutionMmPerPix | real | Millimeters per pixel
Image | blob | JPEG image data
ThumbnailImage | blob | Low-resolution JPEG thumbnail

tile.PP This table is most naturally used to map tile coordinates to tile IDs, but is not suitable for individual lookups because it has no useful indexes. In addition, some Sakura slides don’t have it. OpenSlide ignores the table and constructs tile IDs directly from tile coordinates.
Column | Type | Description
TILEID | text | Foreign key to unique table
PYRAMIDLEVEL | integer | Downsample of the pyramid level
COLUMNINDEX | integer | Level-0 X coordinate of the top-left corner of the tile
ROWINDEX | integer | Level-0 Y coordinate of the top-left corner of the tile
COLORINDEX | integer | 0 for red, 1 for green, 2 for blue

Unique table.PP This is the table named by DataManagerSQLiteConfigXPO.TableName. It contains named blobs including the JPEG tile data.
Column | Type | Description
id | text | Primary key
size | integer | Length of data field
data | blob | Data item

This table stores a variety of blob types.
id | Description
++MagicBytes | SVGigaPixelImage
++VersionBytes | Format version, e.g. 1.0.0
Header | See below
TOTAL_SIZE | The data field is empty. The size field is the sum of all other size fields except ++MagicBytes and ++VersionBytes.
T;2048|4096;4;2;0 | Image tile with downsample 4, X coordinate 2048, Y coordinate 4096, channel 2 (blue), focal plane 0
T;2048|4096;4;2;0# | MD5 hash of the T;2048|4096;4;2;0 image tile

Header blob.PP The Header blob is a small binary structure containing little-endian integers as follows:
Offset | Size | Description
0 | 4 | Tile size in pixels
4 | 4 | Image width in pixels
8 | 4 | Image height in pixels
12 | 4 | Unknown; have seen “8” (bits per channel?)
16 | 4 | Number of focal planes
20 | 4 | Unknown; have seen “3” (number of channels?)
24 | 4 | Unknown; have seen “1”
28 | 2 | Unknown; have seen “256”
30 | 4 | Unknown; have seen “1”
34 | 4 | Unknown; have seen “2”
38 | 4 | Unknown; have seen “3”
42 | 4 | Unknown; have seen “4”
46 | 4 | Unknown; have seen “5”
50 | 4 | Unknown; have seen “6”

  Associated Images

label
    SVScannedImageDataXPO.Image corresponding to SVSlideDataXPO.m_labelScan

macro
    SVScannedImageDataXPO.Image corresponding to SVSlideDataXPO.m_overviewScan

thumbnail
    SVHRScanDataXPO.ThumbnailImage

  Known Properties

sakura.Creator
    SVSlideDataXPO.Creator

sakura.Date
    SVSlideDataXPO.Date

sakura.Description
    SVSlideDataXPO.Description

sakura.DiagnosisCode
    SVSlideDataXPO.DiagnosisCode

sakura.FocussingMethod
    SVHRScanDataXPO.FocussingMethod

sakura.Keywords
    SVSlideDataXPO.Keywords

sakura.NominalLensMagnification
    SVHRScanDataXPO.NominalLensMagnification

sakura.ResolutionMmPerPix
    SVHRScanDataXPO.ResolutionMmPerPix

sakura.ScanId
    SVHRScanDataXPO.ScanId

sakura.SlideId
    SVSlideDataXPO.SlideId

openslide.mpp-x
    calculated as 1000 * sakura.ResolutionMmPerPix

openslide.mpp-y
    calculated as 1000 * sakura.ResolutionMmPerPix

openslide.objective-power
    normalized sakura.NominalLensMagnification

  Test Data

No public data available. Contact the mailing list[23] if you have some.

TRESTLE FORMAT

Format
    single-file pyramidal tiled TIFF, with non-standard metadata and overlaps; additional files contain more metadata and detailed overlap info

File extensions
    .tif

OpenSlide vendor backend
    trestle

  Detection

Trestle slides are stored in single-file TIFF format. OpenSlide will detect a file as Trestle if:

    1. The file is TIFF.

    2. The TIFF Software tag starts with MedScan.

    3. The ImageDescription tag is present.

    4. All images are tiled.

  Relevant TIFF tags
Tag | Description
ImageDescription | Stores some important key-value pairs, see below
Software | Starts with “MedScan”
XResolution, YResolution | Seems to store microns-per-pixel (MPP), which may or may not take into account the correct objective power. Note that this is inverted from standard TIFF, which stores pixels-per-unit, not units-per-pixel.

  Extra data stored in ImageDescription

The ImageDescription tag contains semicolon-delimited key-value pairs. A key-value pair is equals-delimited. We use the OverlapsXY and Background Color keys from the ImageDescription, and ignore the rest. All of these values are stored as properties starting with “trestle.”.
Key | Description
Background Color | Hex-encoded background color info, assumed to be in the format RRGGBB.
White Balance | Hex-encoded white balance
Objective Power | Reported objective power, often incorrect.
JPEG Quality | The JPEG quality value.
OverlapsXY | Overlaps, see below.

  TIFF Image Directory Organization

The first image in the TIFF file is the full-resolution image. The subsequent images are assumed to be decreasingly sized reduced-resolution images.

  Overlaps

The OverlapsXY pseudo-field encodes a list of tile overlap values as ASCII.

Example: “64 64 32 32 16 16” (note the initial space).

These values represent the standard overlaps between adjacent tiles in X and Y, in pixels. This example encodes 3 levels worth of overlaps. Further overlaps are assumed to have the value 0.

Individual tile overlaps may differ from the standard overlaps. These individual overlaps are recorded in .tif-Nb files adjacent to the .tif file, where N is the level number. OpenSlide does not read these files, though they have been partially decoded; see issue 21[24] for details.

  Associated Images

macro
    the image with a filename extension of “.Full” (optional)

  Known Properties

All data encoded in the ImageDescription TIFF field is represented as properties prefixed with “trestle.”.

openslide.mpp-x
    copy of tiff.XResolution (note that this is a totally non-standard use of this TIFF tag)

openslide.mpp-y
    copy of tiff.YResolution (note that this is a totally non-standard use of this TIFF tag)

openslide.objective-power
    normalized trestle.Objective Power

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Trestle/[25]

VENTANA FORMAT

Format
    single-file pyramidal tiled BigTIFF with non-standard metadata and overlaps

File extensions
    .bif, .tif

OpenSlide vendor backend
    ventana

  Detection

Ventana slides are stored in single-file BigTIFF format. OpenSlide will detect a file as Ventana if:

    1. The file is TIFF.

    2. The XMP tag contains valid XML.

    3. The XML contains an iScan element, either as the root element or as a child of a Metadata root element.

  ICC Profiles

The slide ICC profile is taken from the ICC Profile tag of the highest-resolution level.

  Associated Images

macro
    the TIFF directory whose ImageDescription is Label Image or Label_Image

thumbnail
    the TIFF directory whose ImageDescription is Thumbnail

  Known Properties

All XML attributes in the iScan element are represented as properties prefixed with “ventana.”.

openslide.mpp-x
    normalized ventana.ScanRes

openslide.mpp-y
    normalized ventana.ScanRes

openslide.objective-power
    normalized ventana.Magnification

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Ventana/[26]

ZEISS FORMAT

Format
    single-file binary format

File extensions
    .czi

OpenSlide vendor backend
    zeiss

  Detection

OpenSlide will detect a file as Zeiss if:

    1. The file is not a TIFF.

    2. The file has at least 32 bytes and starts with ZISRAWFILE.

  CZI format

CZI slides consist of overlapping image tiles at arbitrary pixel positions. Tiles in level 0 are typically large, e.g. 2056 x 2464 pixels. A slide may or may not include downsampled levels. Slides may include multiple scenes (scan regions), whose pyramids can have different numbers of downsampled levels. Scenes are reflected in the metadata but aren’t very important for rendering the slide, since tile positions are relative to the slide and not the scene.

The storage unit for an image tile is the subblock. A subblock contains pixel data, a small piece of XML metadata (which is ignored by OpenSlide), and a directory entry containing the subblock’s dimensions, pixel format, and compression type. Directory entries are stored alongside individual subblocks, and a second copy of each entry is stored in an array whose location is recorded in the file header.

A dimension represents coordinates along an axis; it contains a short string identifying the dimension, an offset, and for some dimensions, a size in level 0 and in the subblock’s level. Possible dimensions are “X” and “Y” pixel coordinates, a scene identifier “S”, a channel identifier “C” (with value 0 for brightfield), and the tile’s Z-index “M”. Higher Z-indexes should be rendered after lower Z-indexes. The downsample of a subblock can be computed by dividing its X or Y size in level 0 by its size in the subblock’s level.

Pixel data may be compressed in any of several formats. JPEG XR is common. Uncompressed 24 bpp or 48 bpp pixel data is also possible, as well as pixel data compressed with lossless Zstandard[27] compression. CZI’s Zstandard support comes in two flavors, zstd0 and zstd1, with the latter prefixed by an uncompressed header typically three bytes long. A flag in that header indicates the presence of HiLo packing, in which the low bytes of 16-bit color samples are packed together in the first half of the uncompressed buffer and the high bytes in the second half. CZI also permits JPEG and LZW compression, though these do not appear to be common and OpenSlide does not support them.

CZI files can embed arbitrary named attachments, which might be JPEG images, nested CZI files, or other metadata. The Label and SlidePreview attachments are stored as nested CZIs and the Thumbnail attachment is stored as a JPEG.

CZI also includes a large XML document containing scan parameters for the slide. Gamma values.PP Color images generated by at least Axioscan 7 scanners seem not to be gamma corrected before storage, and appear dark. The zeiss.Information.Instrument.Detectors.$camera_id.GammaDefault property (where $camera_id can be read from zeiss.Information.Image.Dimensions.Channels.Channel:0.DetectorSettings.Detector.Id) might be the recommended gamma correction for displaying CZI images. Observed values include 0.45 for Axiocam705c and AxioCamEL color cameras and 1 for Axiocam712m monochrome cameras.

  Associated Images

label
    the Label attachment (optional)

macro
    the SlidePreview attachment (optional)

thumbnail
    the Thumbnail attachment (optional)

  Known Properties

Certain text nodes and attributes from the XML metadata are represented as properties prefixed with “zeiss.”. The available properties are those from the AttachmentInfos, DisplaySetting, Information, and Scaling elements of ImageDocument.Metadata.

openslide.barcode
    the value of the property matching zeiss.AttachmentInfos.*.Label.Barcodes.*.Content that occurs earliest in the XML metadata

openslide.mpp-x
    calculated as 1000000 times zeiss.Scaling.Items.X.Value

openslide.mpp-y
    calculated as 1000000 times zeiss.Scaling.Items.Y.Value

openslide.objective-power
    normalized zeiss.Information.Instrument.Objectives.$objective.NominalMagnification where the value of $objective is obtained from zeiss.Information.Image.ObjectiveSettings.ObjectiveRef.Id

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Zeiss/[28]

  ImHex Patterns
<listitem>CZI file[29] </listitem>.SH "GENERIC TILED TIFF FORMAT"

Format
    single-file pyramidal tiled TIFF

File extensions
    .tif

OpenSlide vendor backend
    generic-tiff

  Detection

OpenSlide will detect a file as generic TIFF if:

    1. No other detections succeed.

    2. The file is TIFF.

    3. The initial image is tiled.

  TIFF Image Directory Organization

The first image in the TIFF file is the full-resolution image. Any other tiled images in the file with the “reduced resolution” bit set are assumed to be reduced-resolution versions of the original.

Starting after OpenSlide 4.0.0, OpenSlide supports generic TIFF files with missing tiles, i.e. tiles with zero bytes of image data. These tiles are rendered as transparent pixels.

  ICC Profiles

The slide ICC profile is taken from the ICC Profile tag of the highest-resolution level.

  Associated Images

None.

  Known Properties

Many TIFF tags are encoded as properties starting with “tiff.”.

  Test Data

https://openslide.cs.cmu.edu/download/openslide-testdata/Generic-TIFF/[30]

AUTHORS

The Carnegie Mellon School of Computer Science.

This manual page was written by Mathieu Malaterre <malat@debian.org> for the Debian GNU/Linux system (but may be used by others).

NOTES

1.  pages for each vendor format
    http://openslide.org/formats/

2.  Documentation PDF
    https://web.archive.org/web/20120420105738/http://www.aperio.com/documents/api/Aperio_Digital_Slides_and_Third-party_data_interchange.pdf

3.  https://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/

4.  Documentation PDF
    http://openslide.orghttps://github.com/user-attachments/files/15580286/ARGOS.AVS.File.Format.pdf

5.  https://openslide.cs.cmu.edu/download/openslide-testdata/Argos/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Argos/

6.  DICOM Whole Slide Imaging
    http://openslide.orghttps://dicom.nema.org/dicom/dicomwsi/

7.  libdicom
    http://openslide.orghttps://github.com/ImagingDataCommons/libdicom/

8.  https://openslide.cs.cmu.edu/download/openslide-testdata/DICOM/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/DICOM/

9.  https://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu/

10. https://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu-vms/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Hamamatsu-vms/

11. VMS optimisation file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/hamamatsu-vms-opt.hexpat

12. VMU NGR file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/hamamatsu-vmu-ngr.hexpat

13. NDPI file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/hamamatsu-ndpi.hexpat

14. Aperio format
    http://openslide.org/formats/aperio/

15. https://openslide.cs.cmu.edu/download/openslide-testdata/Huron/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Huron/

16. this bug
    http://openslide.orghttps://github.com/openslide/openslide/issues/155

17. https://openslide.cs.cmu.edu/download/openslide-testdata/Leica/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Leica/

18. Introduction to MIRAX/MRXS
    http://openslide.orghttps://lists.andrew.cmu.edu/pipermail/openslide-users/2012-July/000373.html

19. https://openslide.cs.cmu.edu/download/openslide-testdata/Mirax/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Mirax/

20. Index file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/mirax-index.hexpat

21. Slide position file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/mirax-position.hexpat

22. https://openslide.cs.cmu.edu/download/openslide-testdata/Philips-TIFF/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Philips-TIFF/

23. mailing list
    http://openslide.orghttps://lists.andrew.cmu.edu/mailman/listinfo/openslide-users/

24. issue 21
    http://openslide.orghttps://github.com/openslide/openslide/issues/21#issuecomment-23615583

25. https://openslide.cs.cmu.edu/download/openslide-testdata/Trestle/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Trestle/

26. https://openslide.cs.cmu.edu/download/openslide-testdata/Ventana/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Ventana/

27. Zstandard
    http://openslide.orghttps://facebook.github.io/zstd/

28. https://openslide.cs.cmu.edu/download/openslide-testdata/Zeiss/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Zeiss/

29. CZI file
    http://openslide.orghttps://github.com/openslide/openslide/blob/main/misc/imhex/zeiss-czi.hexpat

30. https://openslide.cs.cmu.edu/download/openslide-testdata/Generic-TIFF/
    http://openslide.orghttps://openslide.cs.cmu.edu/download/openslide-testdata/Generic-TIFF/