ZIF File Format Specification

Zoom-and-pan viewing of ultra-high-resolution images on the Internet is possible with an interface such as the Zoomify Image Viewer and image content that has been prepared with an authoring tool such as the Zoomify Converter. The Converter processes a source image and creates a Zoomify Image, a collection of many small image tiles at many resolutions, grouped in a folder. These tiles are stored as JPEG or PNG files and are loaded as needed as a user navigates from one view within the image to the next.

Such a Zoomify Image folder may include tens of files for a multi-megabyte image or tens of thousands for a multi-gigabyte image. For large collections of large images, storing these collections as separate files in folders can present challenges when uploading the content to a server or when backing up a gallery of such content.

The ZIF file format combines the many files in a Zoomify Image folder into a single file. ZIF files greatly simplify file management while delivering the fastest, simplest, most optimized access to the image data. ZIF requires no special server-side software or setup and makes ultra-high-resolution zoom-and-pan image viewing easy and efficient on the Net.

ZIF implements a BigTIFF container for JPEG image tiles with two optimizations: edge tiles are cropped, and all Image File Directories (IFDs) are positioned as a single header at the start of the file to enable access to all basic file information in a small initial data request (the BigTIFF specification can be found here)

Every IFD in the header contains the 15 tags for a basic implementation: 6 of these are essential for zoom imaging applications (the other 9 simply supporting the TIFF standard). Essential tags include image width and height, tile width and height, and tile offsets and byte counts. ZIF delivers simplicity while offering the extensibility of optional application-specific tags. While custom implementations may include additional tags, basic implementations can simply ignore unused and/or unrecognized tags.

A single initial data request of can load all header information sufficient for images several million pixels in width and height. Parsing this data enables all subsequent tile offset, byte count, and image data requests. For each image tile, offsets and byte counts can be easily loaded in chunks to reduce requests.

A detailed ZIF format specification follows. In addition, Zoomify provides the ZIF Check utility to validate ZIF files and the ZIF Test example web page demonstrating header and image loading, parsing, and display. The Zoomify Image Viewer implements asynchronous image data management and display and includes complete JavaScript source code (Zoomify HTML5 Pro and Zoomify HTML5 Enterprise products). Links follow.

Implementing authoring and/or viewing support for ZIF is simplified by access to the following resources. Additional examples and tools will follow.

File validation: ZIF Check www.zoomify.com/downloads/tools/ZIFCheck.zip
Data access example: ZIF Test www.zoomify.com/downloads/tools/ZIFTest.zip

Example implementation: Zoomify Image Viewer www.zoomify.com (Zoomify HTML5 Pro and Zoomify HTML5 Enterprise products include complete source code)

Download this page as a PDF file.

The ZIF format is an emerging storage standard for interactive, high-resolution imaging. It has been developed and is promoted by Zoomify, Inc. and Objective Pathology Services, leaders in Internet and digital pathology imaging solutions. Input, support, and adoption are welcomed.

Header

The ZIF BigTIFF header and initial offset begin with the following 16 bytes. If these are not present the file is not valid:

0x49,0x49,0x2b,0x00,0x08,0x00,0x00,0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

Each subsequent IFD will be 316 bytes long for a basic implementation. This includes an 8 byte (64-bit long long) count of entries, 15 entries of 20 bytes each and an 8 byte (64-bit long long) offset to the next IFD. Custom implementations may include additional entries and may therefore be longer, however, basic implementations may simply ignore the additional data.

A standard initial read of 8192 bytes will load sufficient data to encompass the header IFDs of an image file that would range between 2,164,260,864 x 2,164,260,864 pixels and 4,294,967,296 x 4,294,967,296 pixels (depending on image content and assuming a tile size of 256 x 256).

Every IFD will contain 15 basic tags, of which 6 are essential to zoom image viewing (the other 9 are simply required by the TIFF standard). As noted above, custom implementations may include additional tags, however, basic implementations may simply ignore unused and/or unrecognized tags.

Tags – essential:

IFD 2: TAG_IMAGEWIDTH: tier width in pixels
IFD 3: TAG_IMAGELENGTH: tier height in pixels
IFD 11: TAG_TILEWIDTH: tile width in pixels
IFD 12: TAG_TILELENGTH: tile height in pixels
IFD 13: TAG_TILEOFFSETS: tile offsets
IFD 14: TAG_TILEBYTECOUNTS: tile byte counts

Tags – additional:

1. TAG_SBFILETYPE: type of data
4. TAG_BITSPERSAMPLE: bits per sample
5. TAG_COMPRESSION: compression type
6. TAG_PHOTOMETRIC: photometric data type
7. TAG_DESCRIPTION: description
8. TAG_ORIENTATION: image orientation
9. TAG_SAMPLESPERPIXEL: samples per pixel
10. TAG_PLANARCONFIG: planar configuration
15. TIFFTAG_YCBCRSBSAMPLING: JPEG YCbCr subsampling

Note: As an optimization, at the very top of the tile pyramid there is only a single tile and the IFD will contain the actual offset to the tile rather than a pointer to the offset values.

Detailed Tag Information

First IFD 0x0f,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in IFD = 15 (additional items possible, can be ignored)

Tag 1 0xfe,0x00, // Tag value 254 = TAG_SBFILETYPE 0x04,0x00 // Data type 4 = long 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 1 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Value is zero

Tag 2 0x00,0x01, // Tag value 256 = TAG_IMAGEWIDTH (Tier width in pixels) 0x04,0x00 // Data type 4 = long 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 2 0x78,0x3E,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 0x3E78 = 15,992

Tag 3 0x01,0x01, // Tag value 257 = TAG_IMAGELENGTH (Tier height in pixels) 0x04,0x00 // Data type 4 = long 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 3 0x58,0x16,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 0x1658 = 5,720

Tag 4 0x02,0x01, // Tag value 258 = TAG_BITSPERSAMPLE (bits per sample) 0x03,0x00 // Data type 3 = short 0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 4. 0x08,0x00,0x08,0x00,0x08,0x00,0xFD,0xFD // Values are 8,8,8 (unused values) 0xFD,0xFD at end of tag to be ignored

Tag 5 0x03,0x01, // tag value 259 = TAG_COMPRESSION (compression type) 0x03,0x00 // data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 5. 0x07,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // value is 7 = JPEG compression

Tag 6 0x06,0x01, // Tag value 262 = TAG_PHOTOMETRIC photometric data type 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 6. 0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 6 = PHOTOMETRIC_YCBCR (JPEG internal color space)

Tag 7 0x0E,0x01, // Tag value 270 = TAG_DESCRIPTION (Description tag) 0x02,0x00 // Data type 2 = ASCII 0x28,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count is 0x28 = 40 characters including zero at end 0x34,0xE9,0x8A,0x00,0x00,0x00,0x00,0x00 // Value is 0x8AE934 which is the offset in the file of the actual data

Tag 8 0x12,0x01, // Tag value 274 = TAG_ORIENTATION (image orientation) 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 8. 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 1 = top left corner

Tag 9 0x15,0x01, // Tag value 277 = TAG_SAMPLESPERPIXEL (samples per pixel) 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 9. 0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 3 (standard 24 bit color)

Tag 10 0x1C,0x01, // Tag value 284 = TAG_PLANARCONFIG (planar configuration) 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 10. 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 1 = packed pixels

Tag 11 0x42,0x01, // Tag value 322 = TAG_TILEWIDTH (width of tiles in pixels) 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 11 0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 0x100 = 256 pixels wide

Tag 12 0x43,0x01, // Tag value 323 = TAG_TILELENGTH (Tile height in pixels) 0x03,0x00 // Data type 3 = short 0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 12. 0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00 // Value is 0x100 = 256 pixels high

Tag 13 0x44,0x01, // Tag value 324 = TAG_TILEOFFSETS (Tile offsets) 0x10,0x00, // Data type 16 = 64-bit long values 0xA9,0x05,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items is 0x05A9 = 1,449 tile offset values 0x5C,0xE9,0x8A,0x00,0x00,0x00,0x00,0x00 // Value is 0x8AE95C = offset in the file of the tile offset values. Each tile offset value is 64-bits - 8 bytes long in Intel format.

Note: As an optimization, at the very top of the tile pyramid where there is only a single tile, this IFD will contain the actual offset to the tile rather than a pointer to the offset values.

Tag 14 0x45,0x01, // Tag value 325 = TAG_TILEBYTECOUNTS (tile byte counts) 0x04,0x00, // Data type 4 = long values 0xA9,0x05,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items is 0x05A9 = 1,449 tile byte counts values 0xA4,0x16,0x8B,0x00,0x00,0x00,0x00,0x00 // Value is 0x8B16A4 = offset in the file of the tile byte count values // Each tile byte count is 32-bits - 4 bytes long in Intel format

Note: When the number of tiles is two or less, the actual tile byte counts will appear directly in the IFD rather than an offset to the tile byte count values.

Tag 15 0x12,0x02, // Tag value 530 = TIFFTAG_YCBCRSBSAMPLING (JPEG YCbCr subsampling) 0x03,0x00 // Data type 3 = short 0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in tag 15. 0x01,0x00,0x01,0x00,0x00,0x00,0x00,0x00 // Values are 1,1 = 1:1 subsampling 0x4c,0x01,0x00,0x00,0x00,0x00,0x00,0x00 // Offset to next IFD (which follows immediately)

Subsequent IFDs
The next IFD follows, and thereafter, another offset to the third IFD. 0x0f,0x00,0x00,0x00,0x00,0x00,0x00,0x00 // Count of items in the second IFD = 15 (additional items possible, can be ignored)
15 data items in same order and format as previous IFD, then offset to next IFD.

IFDs End
The header IFDs end with an offset to next IFD of 0 (eight zeros).

Download this page as a PDF file.