The Iris File Extension

Abstract

A modern digital pathology vendor-agnostic binary slide format specifically targeting the unmet need of efficient real-time transfer and display has not yet been established. The growing adoption of digital pathology only intensifies the need for an intermediary digital slide format that emphasizes performance for use between slide servers and image management software. The DICOM standard is a well-established format widely used for the long-term storage of both images and associated critical metadata. However, it was inherently designed for radiology rather than digital pathology, a discipline that imposes a unique set of performance requirements due to high-speed multi-pyramidal rendering within whole slide viewer applications. Here, we introduce the Iris file extension, a binary container specification explicitly designed for performance-oriented whole slide image (WSI) viewer systems. The Iris file extension specification is explicit and straightforward, adding modern compression support, a dynamic structure with fully optional metadata features, computationally trivial deep file validation, corruption recovery capabilities, and slide annotations. In addition to the file specification document, we provide source code to allow for (de)serialization and validation of a binary stream against the standard. We also provide corresponding binary builds with C++, Python, and JavaScript language support. Finally, we provide full encoder and decoder implementation source code, as well as binary builds (part of the separate Iris Codec Community module), with language bindings for C++ and Python, allowing for easy integration with existing WSI solutions. We provide the Iris File Extension specification openly to the community in the form of a Creative Commons Attribution-No Derivative 4.0 International license.

Keywords: DICOM; Digital pathology; File format; File specification; Iris; Performance digital pathology; Whole slide image.

Fig. 1

An example implementation of the Iris file extension file structure in a digital pathology workflow. WSI data, following digital quality assurance pipelines, are stored as single high-resolution layers in DICOM within the long-term slide storage archives and are simultaneously converted to Iris files for performance viewer application access. If Iris files are purged from the viewer server, they may be unarchived and regenerated from DICOM storage, if needed.

Fig. 2

File offset linkage structure and validation scheme. Iris data-blocks are dynamically situated at encoder-defined 64-bit unsigned byte offset locations within the slide file. The 64-bit byte offset location is encoded at the beginning of any data-block such that a deserialize/read function read(x) at the offset byte location x evaluates as read(x) = x. In the above illustration, X is an unsigned 64-bit integer value. These offset pointers create the offset chain such that the valid data-block found at X points to the valid data-blocks located at W- and Y-bytes into the file.

Fig. 3

The Iris file structure follows a series of linked data-blocks that extend four layers deep. More data-blocks may be added in future revisions and more layers may be added to the file depth if needed. The file-header points to tile-table and clinical-metadata blocks. The tile-table points to the layer-extents and tile-offsets array, which describes where to read serialized tile data (Fig. 5). In the same layer, the metadata points to attributes, associated-images, ICC color profile, and annotations array. Many of these tertiary data-blocks are array types and point to data-blocks wrapping serialized byte arrays (white boxes).

Fig. 4

Global Tile Indexing Scheme. Tiles are packed by layer with a unique index value assigned to each tile, regardless of layer. The indexing of layers is arranged from lowest scale, on the SOF side, to highest scale towards the EOF. Tiles within layers are arranged with upper left tiles towards the SOF and bottom right towards the EOF. The tile-offset array (A) makes use of this global indexing scheme, while the packing of tile pixel data (B) may be arranged in any order the encoder chooses, which can be entirely stochastic.

Fig. 5

Slide tile encoding scheme detailing the offset trees of the tile-tables and tile arrays, and the slide/layer extents. Offset parameters are shown as horizontal hash marks, while value parameters are shown as gray boxes. Variable sized or a variable number of entries are illustrated with a texture. The tile-table points to a tile-offset array and a layer-extents array. The tile-offsets array encodes the offset and size in bytes of the each variably sized slide tile pixel data array. The layer-extent array lists parameters such as the number of tiles in each dimension and relative scale of each layer encoded in the file.

Fig. 6

Slide objects are graphical figures, in the form of a raster graphic (that may optionally be derived from vector graphics) with the height and width dimensions in pixels (bottom-left). The rendered dimensions are separate from the raster dimensions, as they must be mapped to the slide within slide space, a coordinate notation that maps well to digital slides' multi-resolution layers. The slide space is defined in floating-point tile numbers at the lowest-resolution layer (0). This range for each axis is defined as [0.0, number of tiles], and in the above example, it would be [0.0, 2.0] in both x- and y-dimensions. This space may be transformed based on the viewer's zoom/resolution by simply multiplying by the current zoom amount. The location of an annotation is represented in terms of the offset and size. In the above implementation, the X-offset is approximately 0.73 tiles with an X-size of approximately 1.0 tiles at the initial layer (0). When drawn using a whole slide image viewer, such a structure can be appropriately scaled with ease as the viewer changes scale (right).

Fig. 7

Tile access speeds for the National Cancer Institute Imaging Data Commons WSI example slide files. Read rates for three datasets (CCDI-MCI, CPTAC, and CMB-BRCA; Table 1) are compared between the DICOMweb protocol from the Slim image viewer and local slide files in DICOM and IFE formats using WsiDicom and the Iris-Codec implementations. Median number of tiles retrieved per second (access speed) is noted below, each in square brackets.