.TIFF File Format – Image data

Strips

A striped image is cut into bands of whole rows. RowsPerStrip gives the rows in each band; the last band holds what is left and is not padded.

• StripsPerImage = floor((ImageLength + RowsPerStrip − 1) ÷ RowsPerStrip). With ImageLength 24 and RowsPerStrip 10 there are three strips of 10, 10 and 4 rows.
• StripOffsets and StripByteCounts hold one value per strip: where it starts in the file and how many bytes it takes after compression.
• Strips may be stored in any order and anywhere, before or after the directory. Never assume strip N + 1 follows strip N. An offset of 0 is not allowed to mean anything special.
• The specification recommends about 8 KB per strip, and no more than 64 KB for old MS-DOS and Windows readers.

Tiles

A tiled image uses TileWidth, TileLength, TileOffsets and TileByteCounts in place of the strip fields; a file must not have both.

• TilesAcross = (ImageWidth + TileWidth − 1) ÷ TileWidth, TilesDown = (ImageLength + TileLength − 1) ÷ TileLength, TilesPerImage = TilesAcross × TilesDown, in integer arithmetic.
• TileWidth and TileLength must be multiples of 16. Tiles need not be square, and about 4 to 32 KB each before compression is recommended.
• Every tile has the full tile size. Tiles on the right and bottom edges are padded past the image; readers show only ImageWidth × ImageLength pixels, and the padding value does not matter.
• Offsets run left to right, then top to bottom. Each row of a tile counts as a separate scan line when compressing.

Planes and sample order

With PlanarConfiguration 1 (chunky) the components of each pixel are stored together in PhotometricInterpretation’s order: R G B R G B… With 2 (planar) each component has its own strips or tiles. The offsets then form SamplesPerPixel groups: every strip or tile of the first component, then every one of the second, and so on. Planar files need not be supported by baseline readers.

Extra samples, such as alpha, are always the last components of a pixel, and their size comes from BitsPerSample like any other. With associated alpha the colour components are stored premultiplied: a pixel (r, g, b) with opacity A, all scaled to 0 to 1, is stored as (A·r, A·g, A·b, A).

Uncompressed samples (Compression 1)

• Samples are packed as tightly as possible, with no unused bits except at the end of a row.
• If every sample is 16 bits the data is an array of SHORTs; if every sample is 32 bits, an array of LONGs; otherwise an array of bytes. SHORTs and LONGs use the file’s byte order.
• Each row starts on a byte boundary (a SHORT or LONG boundary in those two cases) and is padded to one.
• With FillOrder 1, the default, the first pixel of a row is in the most significant bit of its byte. A 1-bit row of width W takes (W + 7) ÷ 8 bytes.
• Every other compression scheme, once decoded, produces data laid out exactly like this.

YCbCr data units

A chunky YCbCr image is a sequence of data units. Each unit is the luma samples of a block of H × V pixels, row by row, then one Cb and one Cr sample, where H and V are the YCbCrSubSampling factors. With H = 4 and V = 2 the order is:

Y00 Y01 Y02 Y03 Y10 Y11 Y12 Y13 Cb00 Cr00 Y04 Y05 …

A planar YCbCr image stores the full-size Y plane and the two smaller chroma planes separately. RGB is recovered with the YCbCrCoefficients: R = Cr × (2 − 2 × LumaRed) + Y, B = Cb × (2 − 2 × LumaBlue) + Y, G = (Y − LumaBlue × B − LumaRed × R) ÷ LumaGreen, after ReferenceBlackWhite has turned codes into full-range values: value = (code − black) × range ÷ (white − black), where range is 2^BPS − 1 for Y and RGB and 127 for Cb and Cr.

CIE L*a*b* samples

With PhotometricInterpretation 8 each component is 8 bits: L* unsigned, 0 to 255 standing for 0 to 100, and a* and b* signed, −127 to 127. One component means L* only. The reference white is the perfect reflecting diffuser.

PackBits (Compression 32773)

Each row is packed separately. A decoder reads a control byte n as a signed value:

The decoded data is then read as uncompressed data. Runs longer than 128 bytes are split, and the worst case adds one byte per 128.

Modified Huffman (Compression 2)

CCITT Group 3 one-dimensional coding, adapted for files. Each row is a series of alternating white and black runs, always starting with white: a row that starts black begins with a white run of 0. Each run is zero or more make-up codes followed by exactly one terminating code.

• Runs of 0 to 63 use one terminating code.
• Runs of 64 to 2623 use the largest make-up code not longer than the run, then the terminating code for the rest.
• Runs of 2624 or more use make-up codes of 2560 until less than 2560 is left, then continue as above.
• Each row starts on a new byte. There are no EOL codes, no fill bits and no RTC. The runs of a row must add up to ImageWidth, or the data is broken.
• White runs are white when PhotometricInterpretation is 0, the normal value; with 1 the image is shown reversed.

Terminating codes

Make-up codes

Make-up codes shared by white and black

The end-of-line code, used by Compression 3 but not by 2, is 000000000001. (The specification prints the black EOL with eleven zeros and no 1; the code is the same for both colours.)

T4 and T6 coding (Compression 3 and 4)

These store CCITT Recommendations T.4 and T.6 coding. Each strip or tile is coded as a separate image, starting on a fresh byte, so it can be decoded alone; segments of a multiple of 4 rows suit the coding best. FillOrder should always be written, and 1 should be used for interchange.

• T4, one-dimensional (T4Options bit 0 clear): the runs above, with each row ended by EOL. With bit 2 set, zero fill bits before each EOL make it end on a byte boundary, so it appears as xxxx0000 00000001.
• T4, two-dimensional (bit 0 set): rows coded relative to the row above, with a one-dimensional row every K rows. Each strip must start with a one-dimensional row, so RowsPerStrip should be a multiple of K.
• T6: every row is coded two-dimensionally; the first is coded against an imaginary all-white row. Rows follow each other with no EOL or fill, and the last is followed by the 24-bit EOFB 000000000001000000000001, then 0 bits to the next byte. Readers stop at EOFB or after the expected number of rows; rows missing before EOFB are white.

Two-dimensional rows are made of these mode codes, from ITU-T T.4 section 4.2. b1 is the first changing element on the row above and a1 the next one on the current row.

Uncompressed mode starts with 0000001111. The pixels follow as bits, 0 white and 1 black, with a 1 inserted after every five consecutive 0s. It ends with 0000001t, where t is the colour of the next run. The specification calls this mode poorly defined and discourages it.

LZW (Compression 5)

Each strip is coded separately, with a string table that starts afresh.

• The characters are bytes of the uncompressed data, whatever BitsPerSample is.
• Codes 0 to 255 are the single bytes. 256 is Clear and 257 is EndOfInformation; the first new string gets code 258. The table holds at most 4096 entries.
• Codes are 9 bits wide at first. A decoder switches to 10 bits as soon as entry 510 is added, to 11 bits after 1022 and to 12 bits after 2046. (An encoder switches one entry later, after 511, 1023 and 2047, because it is one code ahead.)
• The encoder writes Clear as soon as it uses entry 4094, then starts again with 9-bit codes.
• Each strip starts with Clear and ends with EndOfInformation, and starts on a byte boundary. Codes are packed most significant bit first (as if FillOrder were 1) and written as bytes, so the stream is the same in II and MM files.

The decoder: on Clear, reset the table and output the next code’s string. Otherwise, if the code is in the table, output its string and add the previous string plus the first byte of this one; if it is not yet in the table, the new string is the previous string plus its own first byte; output and add that.

The specification’s example codes the bytes 07 07 07 08 08 07 07 06 06 as the 9-bit codes 256, 7, 258, 8, 8, 258, 6, 6, 257 (Clear, 7, “7 7”, 8, 8, “7 7”, 6, 6, EndOfInformation), adding table entries 258 “7 7”, 259 “7 7 8”, 260 “8 8”, 261 “8 7”, 262 “7 7 6” and 263 “6 6”. Packed most significant bit first, the 81 bits make the bytes 80 01 E0 40 80 44 08 0C 06 80 80.

Predictor

Predictor 2, horizontal differencing, is applied before compression (in TIFF 6.0, LZW). Each sample except the first of a row is replaced by its difference from the previous sample of the same component, so in chunky data the step is SamplesPerPixel samples. Arithmetic wraps at the sample size, so nothing is lost. To decode, add each sample to the decoded one before it, left to right. Samples smaller than a byte are expanded to bytes for the subtraction, and 16-bit samples are handled as 16-bit values; BitsPerSample must be the same for every component.

Predictor 3, for floating-point samples, comes from Adobe Photoshop TIFF Technical Note 3, which this site has not read. As LibTIFF implements it, the bytes of each row’s values are regrouped so that all the most significant bytes come first, then all the next bytes, and so on, and the resulting byte row is differenced with a step of SamplesPerPixel bytes.

Deflate (Compression 8 and 32946)

Each strip or tile is a zlib stream (RFC 1950) wrapping Deflate data (RFC 1951). Predictor 2 or 3 is often used with it.

JPEG (Compression 7, and the old Compression 6)

TIFF Technical Note 2 replaced the TIFF 6.0 design. With Compression 7:

• Each strip or tile is a complete JPEG stream with a single frame: SOI, then optional DQT, DHT, DAC, DRI, APPn and COM, SOFn, one SOS per scan, then EOI. DNL is not allowed, and only sequential processes may be used.
• JPEGTables (347), if present, is an abbreviated stream from SOI to EOI holding tables that every segment may use. A segment may add its own tables but may not redefine one from JPEGTables. Without it, each segment must define every table it uses.
• The SOFn size is that of the strip or tile: ImageWidth by RowsPerStrip (fewer for the last strip), or TileWidth by TileLength. RowsPerStrip, or the tile size, must be a multiple of 8 times the largest sampling factor.
• The SOFn precision must match BitsPerSample. All segments use the same process.
• PhotometricInterpretation describes the colour space actually stored: YCbCr data is subsampled 2 × 2 unless YCbCrSubSampling says otherwise, and ReferenceBlackWhite must be present. Palette and mask images may not use JPEG.
• With PlanarConfiguration 2 each segment holds one component.

The old design, Compression 6, stores bare entropy-coded data in each strip or tile and puts the tables at offsets given by JPEGQTables, JPEGDCTables and JPEGACTables, the process in JPEGProc and the restart interval in JPEGRestartInterval; strip and tile offsets point at the start of a restart interval. Technical Note 2 strongly discourages writing it, and files using it vary between writers.