Previous Next
TIFF 6.0 Specification Final—June 3, 1992
Comments on the Bilevel Image Example
• The IFD in this example starts at 14h. It could have started anywhere in the file
providing the offset was an even number greater than or equal to 8 (since the
TIFF header is always the first 8 bytes of a TIFF file).
• With 16 rows per strip, there are 188 strips in all.
• The example uses a number of optional fields such as DateTime. TIFF readers
must safely skip over these fields if they do not understand or do not wish to
use the information. Baseline TIFF readers must not require that such fields be
present.
• To make a point, this example has highly-fragmented image data. The strips of
the image are not in sequential order. The point of this example is to illustrate
that strip offsets must not be ignored. Never assume that strip N+1 follows
strip N on disk. It is not required that the image data follow the IFD informa-
tion.
Required Fields for Bilevel Images
Here is a list of required fields for Baseline TIFF bilevel images. The fields are
listed in numerical order, as they would appear in the IFD. Note that the previous
example omits some of these fields. This is permitted because the fields that were
omitted each have a default and the default is appropriate for this file.
TagName Decimal Hex Type Value
ImageWidth 256 100 SHORT or LONG
ImageLength 257 101 SHORT or LONG
Compression 259 103 SHORT 1, 2 or 32773
PhotometricInterpretation 262 106 SHORT 0 or 1
StripOffsets 273 111 SHORT or LONG
RowsPerStrip 278 116 SHORT or LONG
StripByteCounts 279 117 LONG or SHORT
XResolution 282 11A RATIONAL
YResolution 283 11B RATIONAL
ResolutionUnit 296 128 SHORT 1, 2 or 3
Baseline TIFF bilevel images were called TIFF Class B images in earlier versions
of the TIFF specification.
21
TIFF 6.0 Specification Final—June 3, 1992
Section 4: Grayscale Images
Grayscale images are a generalization of bilevel images. Bilevel images can store
only black and white image data, but grayscale images can also store shades of
gray.
To describe such images, you must add or change the following fields. The other
required fields are the same as those required for bilevel images.
Differences from Bilevel Images
Compression = 1 or 32773 (PackBits). In Baseline TIFF, grayscale images can
either be stored as uncompressed data or compressed with the PackBits algorithm.
Caution: PackBits is often ineffective on continuous tone images, including many
grayscale images. In such cases, it is better to leave the image uncompressed.
BitsPerSample
Tag = 258 (102.H)
Type = SHORT
The number of bits per component.
Allowable values for Baseline TIFF grayscale images are 4 and 8, allowing either
16 or 256 distinct shades of gray.
Required Fields for Grayscale Images
These are the required fields for grayscale images (in numerical order):
TagName Decimal Hex Type Value
ImageWidth 256 100 SHORT or LONG
ImageLength 257 101 SHORT or LONG
BitsPerSample 258 102 SHORT 4 or 8
Compression 259 103 SHORT 1 or 32773
PhotometricInterpretation 262 106 SHORT 0 or 1
StripOffsets 273 111 SHORT or LONG
RowsPerStrip 278 116 SHORT or LONG
StripByteCounts 279 117 LONG or SHORT
XResolution 282 11A RATIONAL
YResolution 283 11B RATIONAL
ResolutionUnit 296 128 SHORT 1 or 2 or 3
Baseline TIFF grayscale images were called TIFF Class G images in earlier ver-
sions of the TIFF specification.
22
TIFF 6.0 Specification Final—June 3, 1992
Section 5: Palette-color Images
Palette-color images are similar to grayscale images. They still have one compo-
nent per pixel, but the component value is used as an index into a full RGB-lookup
table. To describe such images, you need to add or change the following fields.
The other required fields are the same as those for grayscale images.
Differences from Grayscale Images
PhotometricInterpretation = 3 (Palette Color).
ColorMap
Tag = 320 (140.H)
Type = SHORT
N = 3 * (2**BitsPerSample)
This field defines a Red-Green-Blue color map (often called a lookup table) for
palette color images. In a palette-color image, a pixel value is used to index into an
RGB-lookup table. For example, a palette-color pixel having a value of 0 would
be displayed according to the 0th Red, Green, Blue triplet.
In a TIFF ColorMap, all the Red values come first, followed by the Green values,
then the Blue values. In the ColorMap, black is represented by 0,0,0 and white is
represented by 65535, 65535, 65535.
Required Fields for Palette Color Images
These are the required fields for palette-color images (in numerical order):
TagName Decimal Hex Type Value
ImageWidth 256 100 SHORT or LONG
ImageLength 257 101 SHORT or LONG
BitsPerSample 258 102 SHORT 4 or 8
Compression 259 103 SHORT 1 or 32773
PhotometricInterpretation 262 106 SHORT 3
StripOffsets 273 111 SHORT or LONG
RowsPerStrip 278 116 SHORT or LONG
StripByteCounts 279 117 LONG or SHORT
XResolution 282 11A RATIONAL
YResolution 283 11B RATIONAL
ResolutionUnit 296 128 SHORT 1 or 2 or 3
ColorMap 320 140 SHORT
Baseline TIFF palette-color images were called TIFF Class P images in earlier
versions of the TIFF specification.
23
TIFF 6.0 Specification Final—June 3, 1992
Section 6: RGB Full Color Images
In an RGB image, each pixel is made up of three components: red, green, and
blue. There is no ColorMap.
To describe an RGB image, you need to add or change the following fields and
values. The other required fields are the same as those required for palette-color
images.
Differences from Palette Color Images
BitsPerSample = 8,8,8. Each component is 8 bits deep in a Baseline TIFF RGB
image.
PhotometricInterpretation = 2 (RGB).
There is no ColorMap.
SamplesPerPixel
Tag = 277 (115.H)
Type = SHORT
The number of components per pixel. This number is 3 for RGB images, unless
extra samples are present. See the ExtraSamples field for further information.
Required Fields for RGB Images
These are the required fields for RGB images (in numerical order):
TagName Decimal Hex Type Value
ImageWidth 256 100 SHORT or LONG
ImageLength 257 101 SHORT or LONG
BitsPerSample 258 102 SHORT 8,8,8
Compression 259 103 SHORT 1 or 32773
PhotometricInterpretation 262 106 SHORT 2
StripOffsets 273 111 SHORT or LONG
SamplesPerPixel 277 115 SHORT 3 or more
RowsPerStrip 278 116 SHORT or LONG
StripByteCounts 279 117 LONG or SHORT
XResolution 282 11A RATIONAL
YResolution 283 11B RATIONAL
ResolutionUnit 296 128 SHORT 1, 2 or 3
24
TIFF 6.0 Specification Final—June 3, 1992
The BitsPerSample values listed above apply only to the main image data. If
ExtraSamples are present, the appropriate BitsPerSample values for those
samples must also be included.
Baseline TIFF RGB images were called TIFF Class R images in earlier versions
of the TIFF specification.
25
TIFF 6.0 Specification Final—June 3, 1992
Section 7: Additional Baseline TIFF
Requirements
This section describes characteristics required of all Baseline TIFF files.
General Requirements
Options. Where there are options, TIFF writers can use whichever they want.
Baseline TIFF readers must be able to handle all of them.
Defaults. TIFF writers may, but are not required to, write out a field that has a
default value, if the default value is the one desired. TIFF readers must be pre-
pared to handle either situation.
Other fields. TIFF readers must be prepared to encounter fields other than those
required in TIFF files. TIFF writers are allowed to write optional fields such as
Make, Model, and DateTime, and TIFF readers may use such fields if they exist.
TIFF readers must not, however, refuse to read the file if such optional fields do
not exist. TIFF readers must also be prepared to encounter and ignore private
fields not described in the TIFF specification.
‘MM’ and ‘II’ byte order. TIFF readers must be able to handle both byte orders.
TIFF writers can do whichever is most convenient or efficient.
Multiple subfiles. TIFF readers must be prepared for multiple images (subfiles)
per TIFF file, although they are not required to do anything with images after the
first one. TIFF writers are required to write a long word of 0 after the last IFD (to
signal that this is the last IFD), as described earlier in this specification.
If multiple subfiles are written, the first one must be the full-resolution image.
Subsequent images, such as reduced-resolution images, may be in any order in the
TIFF file. If a reader wants to use such images, it must scan the corresponding
IFD’s before deciding how to proceed.
TIFF Editors. Editors—applications that modify TIFF files—have a few addi-
tional requirements:
• TIFF editors must be especially careful about subfiles. If a TIFF editor edits a
full-resolution subfile, but does not update an accompanying reduced-resolu-
tion subfile, a reader that uses the reduced-resolution subfile for screen display
will display the wrong thing. So TIFF editors must either create a new reduced-
resolution subfile when they alter a full-resolution subfile or they must delete
any subfiles that they aren’t prepared to deal with.
• A similar situation arises with the fields in an IFD. It is unnecessary—and
possibly dangerous—for an editor to copy fields it does not understand be-
cause the editor might alter the file in a way that is incompatible with the un-
known fields.
No Duplicate Pointers. No data should be referenced from more than one place.
TIFF readers and editors are under no obligation to detect this condition and
handle it properly. This would not be a problem if TIFF files were read-only enti-
26
TIFF 6.0 Specification Final—June 3, 1992
ties, but they are not. This warning covers both TIFF field value offsets and fields
that are defined as offsets, such as StripOffsets.
Point to real data. All strip offsets must reference valid locations. (It is not legal to
use an offset of 0 to mean something special.)
Beware of extra components. Some TIFF files may have more components per
pixel than you think. A Baseline TIFF reader must skip over them gracefully,
using the values of the SamplesPerPixel and BitsPerSample fields. For example,
it is possible that the data will have a PhotometricInterpretation of RGB but have
4 SamplesPerPixel. See ExtraSamples for further details.
Beware of new field types. Be prepared to handle unexpected field types such as
floating-point data. A Baseline TIFF reader must skip over such fields gracefully.
Do not expect that BYTE, ASCII, SHORT, LONG, and RATIONAL will always be
a complete list of field types.
Beware of new pixel types. Some TIFF files may have pixel data that consists of
something other than unsigned integers. If the SampleFormat field is present and
the value is not 1, a Baseline TIFF reader that cannot handle the SampleFormat
value must terminate the import process gracefully.
Notes on Required Fields
ImageWidth, ImageLength. Both “SHORT” and “LONG” TIFF field types are
allowed and must be handled properly by readers. TIFF writers can use either
type. TIFF readers are not required to read arbitrarily large files however. Some
readers will give up if the entire image cannot fit into available memory. (In such
cases the reader should inform the user about the problem.) Others will probably
not be able to handle ImageWidth greater than 65535.
RowsPerStrip. SHORT or LONG. Readers must be able to handle any value
between 1 and 2**32-1. However, some readers may try to read an entire strip
into memory at one time. If the entire image is one strip, the application may run
out of memory. Recommendation: Set RowsPerStrip such that the size of each
strip is about 8K bytes. Do this even for uncompressed data because it is easy for
a writer and makes things simpler for readers. Note that extremely wide high-
resolution images may have rows larger than 8K bytes; in this case, RowsPerStrip
should be 1, and the strip will be larger than 8K.
StripOffsets. SHORT or LONG.
StripByteCounts. SHORT or LONG.
XResolution, YResolution. RATIONAL. Note that the X and Y resolutions may
be unequal. A TIFF reader must be able to handle this case. Typically, TIFF pixel-
editors do not care about the resolution, but applications (such as page layout
programs) do care.
ResolutionUnit. SHORT. TIFF readers must be prepared to handle all three
values for ResolutionUnit.
27
TIFF 6.0 Specification Final—June 3, 1992
Section 8: Baseline Field Reference Guide
This section contains detailed information about all the Baseline fields defined in
this version of TIFF. A Baseline field is any field commonly found in a Baseline
TIFF file, whether required or not.
For convenience, fields that were defined in earlier versions of the TIFF specifica-
tion but are no longer generally recommended have also been included in this
section.
New fields that are associated with optional features are not listed in this section.
See Part 2 for descriptions of these new fields. There is a complete list of all fields
described in this specification in Appendix A, and there are entries for all TIFF
fields in the index.
More fields may be added in future versions. Whenever possible they will be
added in a way that allows old TIFF readers to read newer TIFF files.
The documentation for each field contains:
• the name of the field
• the Tag number
• the field Type
• the required Number of Values (N); i.e., the Count
• comments describing the field
• the default, if any
If the field does not exist, readers must assume the default value for the field.
Most of the fields described in this part of the document are not required or are
required only for particular types of TIFF files. See the preceding sections for lists
of required fields.
Before defining the fields, you must understand these basic concepts: A Baseline
TIFF image is defined to be a two-dimensional array of pixels, each of which
consists of one or more color components. Monochromatic data has one color
component per pixel, while RGB color data has three color components per pixel.
The Fields
Artist
Person who created the image.
Tag = 315 (13B.H)
Type = ASCII
Note: some older TIFF files used this tag for storing Copyright information.
28
TIFF 6.0 Specification Final—June 3, 1992
BitsPerSample
Number of bits per component.
Tag = 258 (102.H)
Type = SHORT
N = SamplesPerPixel
Note that this field allows a different number of bits per component for each
component corresponding to a pixel. For example, RGB color data could use a
different number of bits per component for each of the three color planes. Most RGB
files will have the same number of BitsPerSample for each component. Even in this
case, the writer must write all three values.
Default = 1. See also SamplesPerPixel.
CellLength
The length of the dithering or halftoning matrix used to create a dithered or
halftoned bilevel file.
Tag = 265 (109.H)
Type = SHORT
N =1
This field should only be present if Threshholding = 2
No default. See also Threshholding.
CellWidth
The width of the dithering or halftoning matrix used to create a dithered or
halftoned bilevel file.Tag = 264 (108.H)
Type = SHORT
N =1
No default. See also Threshholding.
ColorMap
A color map for palette color images.
Tag = 320 (140.H)
Type = SHORT
N = 3 * (2**BitsPerSample)
This field defines a Red-Green-Blue color map (often called a lookup table) for
palette-color images. In a palette-color image, a pixel value is used to index into
an RGB lookup table. For example, a palette-color pixel having a value of 0
would be displayed according to the 0th Red, Green, Blue triplet.
29
TIFF 6.0 Specification Final—June 3, 1992
In a TIFF ColorMap, all the Red values come first, followed by the Green values,
then the Blue values. The number of values for each color is 2**BitsPerSample.
Therefore, the ColorMap field for an 8-bit palette-color image would have 3 * 256
values.
The width of each value is 16 bits, as implied by the type of SHORT. 0 represents
the minimum intensity, and 65535 represents the maximum intensity. Black is
represented by 0,0,0, and white by 65535, 65535, 65535.
See also PhotometricInterpretation—palette color.
No default. ColorMap must be included in all palette-color images.
Compression
Compression scheme used on the image data.
Tag = 259 (103.H)
Type = SHORT
N =1
1 = No compression, but pack data into bytes as tightly as possible leaving no unused
bits except at the end of a row.
If Then the sample values are stored as an array of type:
BitsPerSample = 16 for all samples SHORT
BitsPerSample = 32 for all samples LONG
Otherwise BYTE
Each row is padded to the next BYTE/SHORT/LONG boundary, consistent with
the preceding BitsPerSample rule.
If the image data is stored as an array of SHORTs or LONGs, the byte ordering
must be consistent with that specified in bytes 0 and 1 of the TIFF file header.
Therefore, little-endian format files will have the least significant bytes preceding
the most significant bytes, while big-endian format files will have the opposite
order.
If the number of bits per component is not a power of 2, and you are willing to give up
some space for better performance, use the next higher power of 2. For example, if
your data can be represented in 6 bits, set BitsPerSample to 8 instead of 6, and then
convert the range of the values from [0,63] to [0,255].
Rows must begin on byte boundaries. (SHORT boundaries if the data is stored as
SHORTs, LONG boundaries if the data is stored as LONGs).
Some graphics systems require image data rows to be word-aligned or double-word-
aligned, and padded to word-boundaries or double-word boundaries. Uncompressed
TIFF rows will need to be copied into word-aligned or double-word-aligned row
buffers before being passed to the graphics routines in these environments.
2 = CCITT Group 3 1-Dimensional Modified Huffman run-length encoding. See
Section 10. BitsPerSample must be 1, since this type of compression is defined
only for bilevel images.
30
Previous Next