Previous Next
TIFF 6.0 Specification Final—June 3, 1992
Part 1: Baseline TIFF
The TIFF specification is divided into two parts. Part 1 describes Baseline TIFF.
Baseline TIFF is the core of TIFF, the essentials that all mainstream TIFF devel-
opers should support in their products.
11
TIFF 6.0 Specification Final—June 3, 1992
Section 1: Notation
Decimal and Hexadecimal
Unless otherwise noted, all numeric values in this document are expressed in
decimal. (“.H” is appended to hexidecimal values.)
Compliance
Is and shall indicate mandatory requirements. All compliant writers and readers
must meet the specification.
Should indicates a recommendation.
May indicates an option.
Features designated ‘not recommended for general data interchange’ are consid-
ered extensions to Baseline TIFF. Files that use such features shall be designated
“Extended TIFF 6.0” files, and the particular extensions used should be docu-
mented. A Baseline TIFF 6.0 reader is not required to support any extensions.
12
TIFF 6.0 Specification Final—June 3, 1992
Section 2: TIFF Structure
TIFF is an image file format. In this document, a file is defined to be a sequence of
8-bit bytes, where the bytes are numbered from 0 to N. The largest possible TIFF
file is 2**32 bytes in length.
A TIFF file begins with an 8-byte image file header that points to an image file
directory (IFD). An image file directory contains information about the image, as
well as pointers to the actual image data.
The following paragraphs describe the image file header and IFD in more detail.
See Figure 1.
Image File Header
A TIFF file begins with an 8-byte image file header, containing the following
information:
Bytes 0-1: The byte order used within the file. Legal values are:
“II” (4949.H)
“MM” (4D4D.H)
In the “II” format, byte order is always from the least significant byte to the most
significant byte, for both 16-bit and 32-bit integers This is called little-endian byte
order. In the “MM” format, byte order is always from most significant to least
significant, for both 16-bit and 32-bit integers. This is called big-endian byte
order.
Bytes 2-3 An arbitrary but carefully chosen number (42) that further identifies the file as a
TIFF file.
The byte order depends on the value of Bytes 0-1.
Bytes 4-7 The offset (in bytes) of the first IFD. The directory may be at any location in the
file after the header but must begin on a word boundary. In particular, an Image
File Directory may follow the image data it describes. Readers must follow the
pointers wherever they may lead.
The term byte offset is always used in this document to refer to a location with
respect to the beginning of the TIFF file. The first byte of the file has an offset of
0.
13
TIFF 6.0 Specification Final—June 3, 1992
Figure 1
Header Directory Entry
0 Byte Order X Tag
2 42 X+2 Type
4 Offset of 0th IFD X+4 Count
A
6
X+8 Value or Offset
IFD
A B Number of Directory Entries
A+2 Directory Entry 0 Value
A+14 Directory Entry 1
A+26 Directory Entry 2
A+2+B*12 Offset of next IFD
Image File Directory
An Image File Directory (IFD) consists of a 2-byte count of the number of direc-
tory entries (i.e., the number of fields), followed by a sequence of 12-byte field
entries, followed by a 4-byte offset of the next IFD (or 0 if none). (Do not forget to
write the 4 bytes of 0 after the last IFD.)
There must be at least 1 IFD in a TIFF file and each IFD must have at least one
entry.
See Figure 1.
IFD Entry
Each 12-byte IFD entry has the following format:
Bytes 0-1 The Tag that identifies the field.
Bytes 2-3 The field Type.
Bytes 4-7 The number of values, Count of the indicated Type.
14
TIFF 6.0 Specification Final—June 3, 1992
Bytes 8-11 The Value Offset, the file offset (in bytes) of the Value for the field.
The Value is expected to begin on a word boundary; the correspond-
ing Value Offset will thus be an even number. This file offset may
point anywhere in the file, even after the image data.
IFD Terminology
A TIFF field is a logical entity consisting of TIFF tag and its value. This logical
concept is implemented as an IFD Entry, plus the actual value if it doesn’t fit into
the value/offset part, the last 4 bytes of the IFD Entry. The terms TIFF field and
IFD entry are interchangeable in most contexts.
Sort Order
The entries in an IFD must be sorted in ascending order by Tag. Note that this is
not the order in which the fields are described in this document. The Values to
which directory entries point need not be in any particular order in the file.
Value/Offset
To save time and space the Value Offset contains the Value instead of pointing to
the Value if and only if the Value fits into 4 bytes. If the Value is shorter than 4
bytes, it is left-justified within the 4-byte Value Offset, i.e., stored in the lower-
numbered bytes. Whether the Value fits within 4 bytes is determined by the Type
and Count of the field.
Count
Count—called Length in previous versions of the specification—is the number of
values. Note that Count is not the total number of bytes. For example, a single 16-
bit word (SHORT) has a Count of 1; not 2.
Types
The field types and their sizes are:
1 = BYTE 8-bit unsigned integer.
2 = ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte
must be NUL (binary zero).
3 = SHORT 16-bit (2-byte) unsigned integer.
4 = LONG 32-bit (4-byte) unsigned integer.
5 = RATIONAL Two LONGs: the first represents the numerator of a
fraction; the second, the denominator.
The value of the Count part of an ASCII field entry includes the NUL. If padding
is necessary, the Count does not include the pad byte. Note that there is no initial
“count byte” as in Pascal-style strings.
15
TIFF 6.0 Specification Final—June 3, 1992
Any ASCII field can contain multiple strings, each terminated with a NUL. A
single string is preferred whenever possible. The Count for multi-string fields is
the number of bytes in all the strings in that field plus their terminating NUL
bytes. Only one NUL is allowed between strings, so that the strings following the
first string will often begin on an odd byte.
The reader must check the type to verify that it contains an expected value. TIFF
currently allows more than 1 valid type for some fields. For example, ImageWidth
and ImageLength are usually specified as having type SHORT. But images with
more than 64K rows or columns must use the LONG field type.
TIFF readers should accept BYTE, SHORT, or LONG values for any unsigned
integer field. This allows a single procedure to retrieve any integer value, makes
reading more robust, and saves disk space in some situations.
In TIFF 6.0, some new field types have been defined:
6 = SBYTE An 8-bit signed (twos-complement) integer.
7 = UNDEFINED An 8-bit byte that may contain anything, depending on
the definition of the field.
8 = SSHORT A 16-bit (2-byte) signed (twos-complement) integer.
9 = SLONG A 32-bit (4-byte) signed (twos-complement) integer.
10 = SRATIONAL Two SLONG’s: the first represents the numerator of a
fraction, the second the denominator.
11 = FLOAT Single precision (4-byte) IEEE format.
12 = DOUBLE Double precision (8-byte) IEEE format.
These new field types are also governed by the byte order (II or MM) in the TIFF
header.
Warning: It is possible that other TIFF field types will be added in the future.
Readers should skip over fields containing an unexpected field type.
Fields are arrays
Each TIFF field has an associated Count. This means that all fields are actually
one-dimensional arrays, even though most fields contain only a single value.
For example, to store a complicated data structure in a single private field, use
the UNDEFINED field type and set the Count to the number of bytes required to
hold the data structure.
Multiple Images per TIFF File
There may be more than one IFD in a TIFF file. Each IFD defines a subfile. One
potential use of subfiles is to describe related images, such as the pages of a fac-
simile transmission. A Baseline TIFF reader is not required to read any IFDs
beyond the first one.
16
TIFF 6.0 Specification Final—June 3, 1992
Section 3: Bilevel Images
Now that the overall TIFF structure has been described, we can move on to filling
the structure with actual fields (tags and values) that describe raster image data.
To make all of this clearer, the discussion will be organized according to the four
Baseline TIFF image types: bilevel, grayscale, palette-color, and full-color im-
ages. This section describes bilevel images.
Fields required to describe bilevel images are introduced and described briefly
here. Full descriptions of each field can be found in Section 8.
Color
A bilevel image contains two colors—black and white. TIFF allows an applica-
tion to write out bilevel data in either a white-is-zero or black-is-zero format. The
field that records this information is called PhotometricInterpretation.
PhotometricInterpretation
Tag = 262 (106.H)
Type = SHORT
Values:
0= WhiteIsZero. For bilevel and grayscale images: 0 is imaged as white. The maxi-
mum value is imaged as black. This is the normal value for Compression=2.
1= BlackIsZero. For bilevel and grayscale images: 0 is imaged as black. The maxi-
mum value is imaged as white. If this value is specified for Compression=2, the
image should display and print reversed.
Compression
Data can be stored either compressed or uncompressed.
Compression
Tag = 259 (103.H)
Type = SHORT
Values:
1 = No compression, but pack data into bytes as tightly as possible, leaving no unused
bits (except at the end of a row). The component values are stored as an array of
type BYTE. Each scan line (row) is padded to the next BYTE boundary.
2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding. See
17
TIFF 6.0 Specification Final—June 3, 1992
Section 10 for a description of Modified Huffman Compression.
32773 = PackBits compression, a simple byte-oriented run length scheme. See the
PackBits section for details.
Data compression applies only to raster image data. All other TIFF fields are
unaffected.
Baseline TIFF readers must handle all three compression schemes.
Rows and Columns
An image is organized as a rectangular array of pixels. The dimensions of this
array are stored in the following fields:
ImageLength
Tag = 257 (101.H)
Type = SHORT or LONG
The number of rows (sometimes described as scanlines) in the image.
ImageWidth
Tag = 256 (100.H)
Type = SHORT or LONG
The number of columns in the image, i.e., the number of pixels per scanline.
Physical Dimensions
Applications often want to know the size of the picture represented by an image.
This information can be calculated from ImageWidth and ImageLength given the
following resolution data:
ResolutionUnit
Tag = 296 (128.H)
Type = SHORT
Values:
1= No absolute unit of measurement. Used for images that may have a non-square
aspect ratio but no meaningful absolute dimensions.
2= Inch.
3= Centimeter.
Default = 2 (inch).
18
TIFF 6.0 Specification Final—June 3, 1992
XResolution
Tag = 282 (11A.H)
Type = RATIONAL
The number of pixels per ResolutionUnit in the ImageWidth (typically, horizontal
- see Orientation) direction.
YResolution
Tag = 283 (11B.H)
Type = RATIONAL
The number of pixels per ResolutionUnit in the ImageLength (typically, vertical)
direction.
Location of the Data
Compressed or uncompressed image data can be stored almost anywhere in a
TIFF file. TIFF also supports breaking an image into separate strips for increased
editing flexibility and efficient I/O buffering. The location and size of each strip is
given by the following fields:
RowsPerStrip
Tag = 278 (116.H)
Type = SHORT or LONG
The number of rows in each strip (except possibly the last strip.)
For example, if ImageLength is 24, and RowsPerStrip is 10, then there are 3
strips, with 10 rows in the first strip, 10 rows in the second strip, and 4 rows in the
third strip. (The data in the last strip is not padded with 6 extra rows of dummy
data.)
StripOffsets
Tag = 273 (111.H)
Type = SHORT or LONG
For each strip, the byte offset of that strip.
StripByteCounts
Tag = 279 (117.H)
Type = SHORT or LONG
For each strip, the number of bytes in that strip after any compression.
19
TIFF 6.0 Specification Final—June 3, 1992
Putting it all together (along with a couple of less-important fields that are dis-
cussed later), a sample bilevel image file might contain the following fields:
A Sample Bilevel TIFF File
Offset Description Value
(hex) (numeric values are expressed in hexadecimal notation)
Header:
0000 Byte Order 4D4D
0002 42 002A
0004 1st IFD offset 00000014
IFD:
0014 Number of Directory Entries 000C
0016 NewSubfileType 00FE 0004 00000001 00000000
0022 ImageWidth 0100 0004 00000001 000007D0
002E ImageLength 0101 0004 00000001 00000BB8
003A Compression 0103 0003 00000001 8005 0000
0046 PhotometricInterpretation 0106 0003 00000001 0001 0000
0052 StripOffsets 0111 0004 000000BC 000000B6
005E RowsPerStrip 0116 0004 00000001 00000010
006A StripByteCounts 0117 0003 000000BC 000003A6
0076 XResolution 011A 0005 00000001 00000696
0082 YResolution 011B 0005 00000001 0000069E
008E Software 0131 0002 0000000E 000006A6
009A DateTime 0132 0002 00000014 000006B6
00A6 Next IFD offset 00000000
Values longer than 4 bytes:
00B6 StripOffsets Offset0, Offset1, ... Offset187
03A6 StripByteCounts Count0, Count1, ... Count187
0696 XResolution 0000012C 00000001
069E YResolution 0000012C 00000001
06A6 Software “PageMaker 4.0”
06B6 DateTime “1988:02:18 13:59:59”
Image Data:
00000700 Compressed data for strip 10
xxxxxxxx Compressed data for strip 179
xxxxxxxx Compressed data for strip 53
xxxxxxxx Compressed data for strip 160
.
.
End of example
20
Previous Next