ISO 12234-2:2001

Electronic still-picture imaging - Removable memory - Part 2: TIFF/EP image data format

This part of ISO 12234 specifies the TIFF/EP data format described in ISO 12234-1.

Imagerie de prises de vue électroniques — Mémoire mobile — Partie 2: Format de données image TIFF/EP

General Information

• Status: Published
• Publication Date: 24-Oct-2001
• ICS: 37.040.99 - Other standards related to photography
• Technical Committee: ISO/TC 42 - Photography
• Drafting Committee: ISO/TC 42/WG 18 - Electronic still picture imaging
• Current Stage: 9093 - International Standard confirmed
• Start Date: 16-Jun-2021
• Completion Date: 13-Dec-2025

Overview

ISO 12234-2:2001 - TIFF/EP image data format defines the TIFF/EP (Tag Image File Format / Electronic Photography) file structure for electronic still-picture imaging on removable memory. TIFF/EP is explicitly designed for compatibility with TIFF 6.0 readers while adding new tags and constraints to support camera-centric features such as thumbnails, burst sequences, camera metadata and JPEG-compressed image storage. The standard describes the file header, image file directory (IFD) structure, tag definitions and recommended usage for interchange between digital cameras, software and storage media.

Key topics and technical requirements

• TIFF-compatible header and versioning: TIFF/EP uses the same 8‑byte TIFF header; readers should check the header version (test VERSION >= 42) to detect TIFF/EP files and future revisions.
• File structure and limits: Files are sequences of 8‑bit bytes (largest possible TIFF file = 2**32 bytes). A TIFF file begins with an 8‑byte header and one or more IFDs; each IFD holds a 2‑byte count, 12‑byte entries and a 4‑byte offset to the next IFD.
• IFD and tag handling: IFD entries are 12 bytes (tag, type, count, value/offset) and must be sorted by tag. TIFF/EP defines new tags (e.g., TIFF/EPStandardID) while reusing TIFF 6.0 tags where possible. All tag values must be explicitly stated (no implicit defaults).
• Image data and compression: Images may be uncompressed or use JPEG baseline (DCT-based) compression compliant with ISO/IEC 10918-1. TIFF/EP uses the TIFF/JPEG method where each tile/strip may contain a complete JPEG data stream; readers are required to support the DCT-based lossy JPEG process.
• Related images and sequences: TIFF/EP supports storing related images in one file - high-resolution “parent” images, embedded thumbnails, and burst (temporal) sequences via chaining.
• Camera metadata and color info: Tags carry camera settings, color space and characterization to improve interchange and post-processing.
• Interoperability recommendations: TIFF/EP files are recommended to be stored read-only on removable media to prevent non-compliant editors from stripping unknown tags; editors must warn users when saving newer-version TIFF/EP files with older tools.
• Patent notices: ISO lists firms that claim patents related to the standard (e.g., Canon, Kodak, Fuji, Nikon, Olympus); licensing considerations may apply.

Applications and who uses it

• Camera manufacturers and firmware developers - implement TIFF/EP for camera RAW or TIFF-based image output on removable memory.
• Imaging software and photo editors - read/write compatibility with camera files and multi-resolution assets (thumbnails, bursts).
• Digital asset management and archiving - standardized metadata and file structure for long-term interchange.
• Forensic, industrial and scientific imaging - reliable storage of image plus camera characterization and metadata.

Related standards

• ISO 12234-1 (Basic removable-memory module)
• ISO 12234-3 (Design rule for camera file system / DCF)
• TIFF Revision 6.0 (Adobe)
• Exif (JEIDA / Exif 2.1 interoperability)
• ISO/IEC 10918-1 (JPEG)
• ISO 12232, ISO 12233, ISO 14524 (camera measurement methods)

Keywords: ISO 12234-2:2001, TIFF/EP, TIFF, electronic still-picture imaging, removable memory, image data format, TIFF tags, JPEG baseline, camera metadata.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 12234-2
First edition
2001-10-15
Electronic still-picture imaging —
Removable memory —
Part 2:
TIFF/EP image data format
Imagerie de prises de vue électroniques — Mémoire mobile —
Partie 2: Format de données image TIFF/EP
Reference number
©
ISO 2001
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO 2001 – All rights reserved

Contents Page
Foreword.iv
Introduction.v
1 Scope .1
2 Normative references .1
3 Terms and definitions .1
4 Image data features .2
4.1 TIFF/EP file encoding structure.2
4.2 Image data .5
4.3 Thumbnail images .6
4.4 Burst sequences using chaining .8
4.5 Camera colour space information.9
4.6 Image data compression.9
4.7 Camera information.11
4.8 Picture annotation .11
4.9 Camera and lens settings .11
4.10 Camera characterization .12
5 TIFF/EP tag definitions.13
5.1 TIFF/EP tag list.13
5.2 TIFF/EP tag definitions grouped by function.16
Annex A (informative) Examples of TIFF/EP files .51
A.1 General.51
A.2 Uncompressed RGB.51
A.3 JPEG compressed .55
Bibliography.59
Alphabetical index of TIFF/EP tag definitions .60
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO 12234 may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 12234-2 was prepared by Technical Committee ISO/TC 42, Photography.
ISO 12234 consists of the following parts, under the general title Electronic still-picture imaging — Removable
memory :
� Part 1: Basic removable-memory module
� Part 2: TIFF/EP image data format
� Part 3: Design rule for camera file system (DCF)
Annex A of this part of ISO 12234 is for information only.
iv © ISO 2001 – All rights reserved

Introduction
The term TIFF/EP refers to Tag Image File Format/Electronic Photography, defined in this part of ISO 12234. The
term “TIFF 6.0” refers to the TIFF Revision 6.0 specification. TIFF/EP is defined to be as compatible as possible
with existing desktop software packages, to enable them to operate with images from electronic still-picture
cameras. TIFF Revision 6.0 is used as the basis for achieving this interoperability with the large installed base of
imaging software. Wherever possible, TIFF/EP uses tags already defined in TIFF 6.0 and provides guidelines for
the use of these tags as well as the allowed field values. New tags are defined to encode image data features that
are not included in TIFF 6.0. These new tags conform to the practices specified in TIFF 6.0. This document also
describes how related images, such as both “parent” high resolution and “thumbnail” low resolution images of the
same subject, or temporal sequence “bursts” of the same scene, can be stored in a single TIFF/EP file.
With the permission of Adobe Systems Incorporated, sections of this TIFF/EP specification have been copied
verbatim from the TIFF 6.0 specification dated June 3, 1992 specification � 1986-1988, 1992 Adobe Systems
Incorporated. All Rights Reserved.
In this part of ISO 12234, references to tags and tag values defined in TIFF 6.0 are shown in bold typeface. Tags
and tag values that are not defined in TIFF 6.0 are identified in italic type face. These new tags have been chosen
to be as compatible as possible with the Exif tags defined in “Digital Still Camera Image File Format Standard
(Exchangeable image file format for Digital Still Cameras: Exif)”, Version 2.1, June 1998 by the Japan Electronic
Industry Development Association (JEIDA). The new TIFF/EP tag-fields containing enumerated values follow the
TIFF 6.0 convention, where the lower half of the values (0 to 127 for byte values, 0 to 32,767 for short values, and
0 to 2,147,483,647 for long values) are reserved by TIFF/EP and the upper half of the values (128 to 255 for byte
values, 32,768 to 65,535 for short values, and 2,147,483,648 to 4,294,967,296 for long values) are private values
that may be registered by I3A.
I3A may be contacted at the Photographic and Imaging Manufacturers Association, 550 Mamaroneck Avenue,
Suite 307, Harrison, NY 10528-1612 USA, or by e-mail at [e-mail].
TIFF/EP complies with the TIFF 6.0 specification and uses the same header specified in TIFF 6.0. The reason for
this is to maintain the highest degree of compatibility with existing TIFF readers and to make the adoption of
TIFF/EP, including the new TIFF/EP tags, as easy as possible. In the future, if TIFF is revised, a revised version of
TIFF/EP may be developed using the revised TIFF specification. TIFF/EP editors of a given TIFF/EP version
number shall not update TIFF/EP files having a higher version number without warning the user that, in doing so,
unknown tags will be deleted. This is explained in the section describing the TIFF/EPStandardID tag.
TIFF/EP tag definitions do not allow default values. All values shall be explicitly stated in order to improve
interoperability with future versions of TIFF/EP. Images may be stored in uncompressed form or using JPEG
baseline (DCT based) compression. In the latter case, an uncompressed baseline-TIFF-readable reduced
resolution “thumbnail” image should also be stored in the 0th IFD to allow the images to be identified using a
baseline TIFF 6.0 reader.
TIFF/EP uses the TIFF/JPEG specification given in “DRAFT TIFF Technical Note No. 2”. This method differs from
the JPEG method described in the TIFF 6.0 specification. In the method used within TIFF/EP, each image segment
(tile or strip) contains a complete JPEG data stream that is valid according to the ISO JPEG standard
(ISO/IEC 10918-1). TIFF/EP requires that readers only support the DCT based lossy JPEG process.
TIFF/EP currently does not define how to embed audio information within a TIFF/EP image file. Audio can be
stored in a separate file on the same removable media, if desired, or stored within a TIFF/EP file using a private
TIFF tag obtained from Adobe Corp. This does not preclude a future release of TIFF/EP from implementing
embedded audio as part of the TIFF/EP file.
TIFF/EP image files should be stored in a READ-ONLY fashion using the appropriate file system mechanism. This
will prevent accidental loss of important TIFF/EP tag-value information if the image is edited by a non-TIFF/EP
compliant application. TIFF editors generally remove unknown tags when saving or updating an image file to
maintain the integrity of the TIFF file, since the unknown tags might not apply to the edited image. By creating
TIFF/EP image files READ-ONLY, accidental loss of important information is prevented. TIFF/EP editors, on the
other hand, shall warn the user, whenever editing a newer version TIFF/EP file with an older version TIFF/EP
editor, that proceeding may result in the loss of information. The mandatory TIFF/EPStandardID tag-field specifies
theTIFF/EP version used increatingaTIFF/EP imagefile.
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed that
compliance with this International Standard may involve the use of patents from the following companies:
� Canon Incorporated
� Eastman Kodak Company
� Fuji Photo Film Company Ltd.
� Nikon Corporation
� Olympus Optical Company Ltd.
The holders of these patent rights have assured ISO that they are willing to negotiate licenses under reasonable
and non-discriminatory terms and conditions throughout the world. In this respect, the statement of the holder of
this patent right is registered with ISO. Information may be obtained from the companies listed. Other companies
have also determined that, upon approval of this International Standard, they too will grant patent licenses in
accordance with ISO Directives, Part 2. Information regarding these companies may also be obtained from the ISO
Central Secretariat
ISO takes no position concerning the evidence, validity and scope of any of the patent rights listed.
vi © ISO 2001 – All rights reserved

INTERNATIONAL STANDARD ISO 12234-2:2001(E)
Electronic still-picture imaging — Removable memory —
Part 2:
TIFF/EP image data format
1 Scope
This part of ISO 12234 specifies the TIFF/EP data format described in ISO 12234-1.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO 12234. For dated references, subsequent amendments to, or revisions of, any of these publications
do not apply. However, parties to agreements based on this part of ISO 12234 are encouraged to investigate the
possibility of applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain
registers of currently valid International Standards.
ISO 12232:1998, Photography — Electronic still-picture cameras — Determination of ISO speed
ISO 12233:2000, Photography — Electronic still-picture cameras — Resolution measurements
ISO 12234-1:2001, Electronic still-picture imaging — Removable memory — Part 1: Basic removable-memory
module
ISO 14524:1999, Photography — Electronic still-picture cameras — Methods for measuring opto-electronic
conversion functions (OECFs)
ISO/IEC 10918-1:1994, Information technology — Digital compression and coding of continuous-tone still images:
Requirements and guidelines
ITU-R BT.709-4 (03/00), Parameter values for the HDTV standards for production and international programme
exchange
3 Terms and definitions
For the purposes of this part of ISO 12234, the following terms and definitions apply.
3.1
file system
software structure which specifies how the data is logically organized on a given storage medium
3.2
image data format
structure and content which specifies how the data is logically organized on a given storage medium
4 Image data features
This clause describes all the features of the TIFF/EP standard and lists the tags used to implement each feature.
4.1 TIFF/EP file encoding structure
A TIFF/EP file is a valid TIFF file that contains the TIFF/EP format identifier and conforms to the restrictions
described in this part of ISO 12234. The TIFF/EP header is exactly the same as the TIFF header. The use of the
TIFF/EP format and revision number is identified in the TIFF/EPStandardID tag-field.
TIFF is an image file format. In this part of ISO 12234, a file is 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.
A TIFF file structure is shown in Figure 1.
Figure 1 — TIFF file structure
4.1.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 the most significant byte to the least significant byte, for both 16-bit and 32-bit integers.
This is called big-endian byte order.
2 © ISO 2001 – All rights reserved

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.
Note that, in order to allow backward compatibility with future versions of TIFF/EP based on future
versions of TIFF, all TIFF/EP readers should test the TIFF header version value to determine if
VERSION >= 42, not to test if VERSION == 42. This will allow higher version numbers to be used in
the future and to be detected as TIFF/EP files.
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 shall begin on a word boundary. In particular, an image file directory may follow the image data
it describes. Readers shall follow the pointers wherever they may lead.
The term byte offset is always used in this part of ISO 12234 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.
4.1.2 Image file directory (IFD)
An IFD consists of a 2-byte count of the number of directory 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
4 bytes of 0 after the last IFD.
There shall be at least 1 IFD in a TIFF file and each IFD shall have at least one entry.
4.1.2.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.
Bytes 8-11: The value offset, i.e. the file offset (in bytes) to the value(s) for the field. This value offset is
expected to begin on a word boundary; the corresponding value offset will thus be an even
number. This file offset may point anywhere in the file, even after the image data. (See below for
more information.)
4.1.2.2 IFD terminology
A TIFF field is a logical entity consisting of a 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.
4.1.2.3 Sort order
The entries in an IFD shall be sorted in ascending order by tag. The values to which directory entries point need not
be in any particular order in the file.
4.1.2.4 Value/Offset
To save time and space, the value offset contains the value instead of pointing to the value 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.
Note that the 4 byte value offset should not be thought of as a LONG data type since, if the value is shorter than
4 bytes, it is always left-justified regardless of whether the II or MM byte order is used. For example, to store the
SHORT hex value “AB CD” in MM byte order, the 4 bytes are “AB CD xx xx” (where x indicates “don’tcare”). The
samehex valueinII byteorder is given by “CD AB xx xx”.
4.1.2.5 Count
Count, called Length in previous versions of the TIFF 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.
4.1.2.6 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 shall 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 represents the
denominator.
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 SLONGs: the first represents the numerator of the fraction, the second represents the
denominator.
11=FLOAT Single precision (4-byte) IEEE format.
12=DOUBLE Double precision (8-byte) IEEE format.
WARNING — It is possible that other TIFF field types will be added in the future. Readers should ignore
fields containing an unexpected field type.
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. Any ASCII field can contain
multiple strings, each terminated with a NUL. A single string is preferred whenever possible. The count for
multistring fields is the number of bytes in all 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 shall 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 shall 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.
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.
4.1.3 Vendor unique information
Each camera manufacturer may choose to store additional information in the form of private tags or private tag-
values. This can be done by obtaining private tags and/or tag-values for TIFF 6.0 tags from the Adobe Developers
Desk and vendor unique tag-values from PIMA/IT10 for the new TIFF/EP defined tags. When storing additional
vendor unique information within TIFF/EP files, care shall be taken not to violate the TIFF/EP guidelines described
in this part of ISO 12234.
4 © ISO 2001 – All rights reserved

4.2 Image data
The image width, i.e. horizontal or X dimension, is recorded as a binary value in the ImageWidth tag-field. The
image width may be the shorter or longer dimension of the image, depending upon the orientation of the camera
during image capture. The image orientation is defined by the Orientation tag-field. The image length, i.e. vertical
or Y dimension, is recorded as a binary value in the ImageLength tag-field. The camera’s desired image output
rendering resolution in the X-dimension, i.e. the horizontal dimension when the camera is normally oriented, is
recorded using the XResolution tag-field, while the output resolution in the Y-dimension is recorded in the
YResolution tag-field. The ResolutionUnits tag-value gives the units for the XResolution and YResolution
values. These mandatory TIFF 6.0 tag-fields are typically used to determine the default size of the image on the
screen. They do not indicate the sample spacing of the image sensor in an electronic still-picture camera. The latter
is giveninthe FocalPlaneXResolution, FocalPlaneYResolution and FocalPlaneResolutionUnits tag-values.
The pixel aspect ratio (ratio of the pixel width to pixel height) is determined by the ratio of the XResolution and
YResolution values. The recommended TIFF/EP pixel aspect ratio is 1:1 (square), so that XResolution equals
YResolution.
The number of colour components or samples per pixel in the image is recorded using the SamplesPerPixel tag-
field as a binary value. For example, an image captured using a monochrome sensor has only one colour
component or sample per pixel, while a 3-sensor colour RGB camera has three colour components or samples per
pixel. The number of bits needed to store each of the colour components (samples) is recorded using the
BitsPerSample tag-field as a set of binary values. In the case of a monochrome image, the BitsPerSample tag-
field contains only one value, equal to the actual number of bits per pixel. In the case of an RGB image having
three colour samples per pixel, the BitsPerSample tag-field contains three values equal to the actual number of
bits of storage used to store each component or sample. In the latter case, the number of bits for each colour-
component could be different and hence is explicitly stated.
The type of image data components are provided by the PhotometricInterpretation tag-value. All TIFF/EP
readers shall handle greyscale, RGB and YCbCr data. If YCbCr data values are stored, the number of Cb and Cr
values may either be equal to the number of Y values or smaller owing to subsampling. The chrominance
subsampling factors of a YCbCr image are encoded in the YCbCrSubSampling tag-field. This tag-field contains
both the horizontal and vertical subsampling factors, which are labelled YCbCrSubSamplingHoriz and
YCbCrSubSamplingVert respectively. The subsampling factors are given relative to the appropriate dimension of
the corresponding luminance image. The positions of the subsampled chrominance components relative to the
luminance samples are encoded in the YCbCrPositioning tag-field. The headroom/footroom image data values
(codes) for each each pixel component associated with a YCbCr image is specified within the
ReferenceBlackWhite tag-field. The pair of headroom/footroom values (codes) associated with the luminance
component (Y) refer to this component’s ReferenceWhite and ReferenceBlack. The pair of headroom/footroom
values (codes) associated with the chrominance components, Cb and Cr, refer to these components'
ReferenceBlack and ReferenceWhite, where here the ReferenceWhite value is used to code reference blue and
reference red respectively.
The image data may optionally be stored using a single image component having a colour filter array (CFA) area
pattern of the image data derived from a single-chip colour CCD image sensor. TIFF/EP readers are not required to
handle this type of image data. The colour filter array area pattern is the repetitive spatial colour sampling pattern of
photosites on the CCD image sensor. There are many different CFA-type CCDs which capture only one colour
component per photosite on the CCD. The tags used to describe a CCD’s CFA pattern are: SamplesPerPixel,
PlanarConfiguration, CFARepeatPatternDim, CFAPattern and SensingMethod.
The image data is stored using either strips or tiles, which are collectively termed segments. If strips are used, the
following tag-fields define the number of strips and the number of rows of image data stored in each strip:
StripOffsets, RowsPerStrip and StripByteCounts. The image shall be divided into an integral number of strips,
from one strip to the maximum number of strips, which equals the image’s length. If necessary, the final strip can
be “padded” with zeros. TIFF/EP recommends that the image data, prior to compression, does not exceed
64 Kbytes per strip. This value is chosen to maximize compatibility with various operating systems. The
StripOffsets tag-field stores the offsets from the start of the image file to the start of each image data strip. In this
way, the reader can easily access various parts of the image. The number of rows per strip is stored in the
RowsPerStrip tag-field. The number of image data bytes stored within each strip is recorded in the
StripByteCounts tag-field. The “strip” mechanism is very useful in accessing images, because it uses less buffer
memory than would otherwise be needed to read in the entire image all at one time. The order of the image strips is
from the top to the bottom of the image.
EXAMPLE ImageWidth = 768
ImageLength = 512
PhotometricInterpretation = 2 (RGB)
SamplesPerPixel = 3
BitsPerSample = 8,8,8
PlanarConfiguration = 1 (Chunky), i.e. RGBRGBRGB.
The size in bytes of each row in this image is 768 PixelsPerRow * (3 SamplesPerPixel * 8 BitsPerSample)/8
BitsPerByte ==> 2304 BytesPerRow. Assuming 8 rows of image data in each strip, the number of bytes per strip is
8 RowsPerStrip * 2304 BytesPerRow ==> 18,432 BytesPerStrip. The number of strips equals 512 Rows/8
RowsPerStrip ==> 64 strips.
If tiles are used, the following tag-fields define the number of tiles and the size of each tile: TileWidth, TileLength,
TileOffsets and TileByteCounts. The image shall be divided into an integral number of tiles. The purpose of tiles
is to provide the reader with the ability to perform image “panning”, i.e. to view portions of the image on a display
which is smaller than the overall image size. The TileWidth tag-field stores the width of the tile in pixels. The
TileLength tag-field stores the length of the tile in rows. The TileOffsets tag-field stores the offsets from the start
of the image file to the start of each image data tile. The number of image data bytes in each tile is recorded in the
TileByteCounts tag-field. TIFF/EP recommends that the image data, prior to compression, does not exceed
64 Kbytes per tile.
Using the above example, the image could be broken up into 64 tiles each having a width of 96 pixels and a length
of 64 pixels. Each tile would have a size in bytes of 96 PixelsPerTileWidth * 64 RowsPerTileLength *
(3 SamplesPerPixel * 8 BitsPerSample)/8 BitsPerByte ==> 18,432 BytesPerTile, i.e. 18K BytesPerTile.
NOTE If the image data is compressed using JPEG, i.e. Compression tag-field contains the value of 7, each segment
(strip or tile) shall contain a valid JPEG datastream according to the ISO JPEG standard’s rules for interchange-format or
abbreviated-image-format data.
4.3 Thumbnail images
There may be more than one IFD in a TIFF 6.0 file. Each IFD defines a subfile. One potential use of subfiles in
TIFF 6.0 is to describe related images, such as the pages of a facsimile transmission. A baseline TIFF 6.0 reader is
not required to read any IFDs beyond the first one.
In TIFF/EP files, the 0th IFD should be an image that can be read by a baseline TIFF 6.0 reader. Note that JPEG
compression is not required for baseline TIFF 6.0 readers. Therefore, if the full-resolution image is stored using
compression, the TIFF/EP file should include a thumbnail (reduced-resolution) image stored in the 0th IFD that is
readable by a baseline TIFF 6.0 reader. This thumbnail should not be compressed, and should be stored in strips,
rather than in tiles, in order to be fully compatible with TIFF 6.0. A SubIFDs tag in the 0th IFD is used to point to the
compressed full-resolution image. If the full-resolution image is stored uncompressed as a baseline-readable TIFF
image, the full-resolution image could be stored in the 0th IFD. However, TIFF/EP recommends that a thumbnail
image be stored in the 0th IFD, regardless of whether the full-resolution image is baseline TIFF readable or not.
This provides a version of the image that is small (relative to the full-resolution image) and that may be quickly
accessed by reader software. The use of the SubIFDs tag is the TIFF recommended method of performing this
“treeing” mechanism. The idea of IFD treeing via the use of the SubIFDs tag is described below. TIFF/EP uses the
IFD “chaining” mechanism to store a “burst” motion sequence of temporally related images in the same TIFF/EP
file. Figure 2 shows graphically an example of IFD treeing to store both the thumbnail image and the full resolution
“main” image. This is done using the SubIFDs tag. The SubIFDstagis used withina givenIFD to initiate a “tree” or
“branch” to another IFD describing another rendition of the same image within a TIFF/EP file. This tag is described
in detail in the tag-definition section of this document. The SubIFDs tag is not described in the TIFF 6.0
specification, but is described in “TIFF Technical Note 1: TIFF Trees” available from Adobe Corporation. This
technical note describes the mechanism to use if treeing is needed. The TIFF/EP SubIFDs tag value provides the
offset from the start of the TIFF/EP file to the beginning of the IFD for the full resolution image. The
NewSubFileType tag identifies the image as a full resolution image. This IFD treeing technique, using the
6 © ISO 2001 – All rights reserved

SubIFDs and NewSubFileType tags, is a clear and unambiguous method associating the thumbnail images and
main images. IFD treeing is used instead of IFD chaining because TIFF/EP recommends that chaining be used to
store a burst of temporally related images in the same file, as described in 4.4.
Figure 2 — TIFF/EP encoding structure with treeing
TIFF/EP requires that the thumbnail image be stored in strips, so that the thumbnails may be read by any baseline
TIFF 6.0 reader. The dimensions of the thumbnail image are restricted by TIFF/EP to 256 pixels maximum
horizontally and 256 pixels maximum vertically. The following tag-fields are necessary to define the number of
strips and the number of rows of thumbnail image data stored in each strip: StripOffsets, RowsPerStrip and
StripByteCounts.
In the example below, the thumbnail image has one eighth the number of lines and one eighth the number of pixels
per line as its parent image. The thumbnail image is a single strip which holds the thumbnail image data. The
StripOffsets tag-field stores the offset from the start of the image file to the start of the thumbnail image data strip.
The number of rows per strip, i.e. 64 rows, is stored in the RowsPerStrip tag-field. The number of thumbnail image
data bytes stored in the strip is recorded in the StripByteCounts tag-field.
EXAMPLE Parent ImageWidth = 768
Parent ImageLength = 512
Parent PhotometricInterpretation = 2 (RGB)
Parent SamplesPerPixel = 3
Parent BitsPerSample = 8,8,8
Parent PlanarConfiguration = 1 (Chunky), i.e. RGBRGBRGB.
Thumbnail ImageWidth = 96
Thumbnail ImageLength = 64
Thumbnail PhotometricInterpretation = 2 (RGB)
Thumbnail SamplesPerPixel = 3
Thumbnail BitsPerSample = 8,8,8
Thumbnail PlanarConfiguration = 1 (Chunky), i.e. RGBRGBRGB.
The size in bytes of the single thumbnail image strip is 96 PixelsPerRow * (3 SamplesPerPixel * 8
BitsPerSample)/8 BitsPerByte ==> 288 BytesPerRow. We are storing 64 rows of thumbnail image data in the strip,
hence the number of bytes per strip is 64 RowsPerStrip * 288 BytesPerRow ==>18,432 BytesPerStrip. The number
of strips is equal to 64 Rows/64 RowsPerStrip ==> 1 strip.
4.4 Burst sequences using chaining
Figure 3 shows how TIFF/EP allows image chaining to be used to store a burst motion sequence of temporally
related images. The Image0 IFD stores the first image in the sequence, the Image1 IFD stores the second image in
the sequence and so on. Therefore, the IFD numbers indicate the temporal sequence of the burst of images. By
storing the entire sequence in a single TIFF/EP file via chaining, the sequence is encapsulated in a way that allows
it to be copied without losing images or altering the image sequence. As noted earlier, the SubIFDs tag provides
the mechanism to store both thumbnail and main images for each temporal sample of the “chain” all in the same
TIFF/EP file.
Figure 3 — TIFF/EP encoding structure with image chaining
8 © ISO 2001 – All rights reserved

TIFF/EP recommends that chaining be used to store a motion sequence burst of images. Note that if chaining is
used for both thumbnails and motion sequences, readers could be confused by the relationships between IFDs in
the file. Neither TIFF/EP nor TIFF 6.0 requires baseline readers to read past the first image in the chain. Note that if
image categorization or databasing is required, the filing system should provide this mechanism. Image chaining
should not be used for this purpose. The definition of a filing system for image databasing is outside the scope of
the TIFF/EP specification.
4.5 Camera colour space information
The ICC (InterColour) profile, contained in the InterColourProfile tag-field, may be used to provide the information
required to interpret the digital code values of a colour image. Note that the ICC profile format may be revised in the
future and the most recent version of the ICC specification should be used. To prevent duplication and confusion,
the TIFF 6.0 PrimaryChromaticities, WhitePoint and TransferFunction tags are not allowed in TIFF/EP, since this
same information is specified within the InterColourProfile tag value. In some applications, the use of an ICC
profile may be inadequate to achieve the desired level of camera colour charactization. In these applications, the
camera spectral sensitivities and OECF (opto-electronic conversion function) may be provided, using the
SpectralSensitivity and OECF tag values, in order to provide the desired camera colour characterization
information.
The target colour space describes the number and type of colour components and is recorded in the
PhotometricInterpretation tag-field. The allowed target colour spaces are greyscale, RGB, YCbCr and CFA
(colour filter array).
The chromaticities of the primaries of the image are encoded using the redColourantTag, greenColourantTag and
blueColourantTag values within the InterColourProfile tag value. The chromaticity of the white point of the image
is encoded using the mediaWhitePointTag values within the InterColourProfile tag value.
The transfer function which indicates the meaning of each image data code is encoded using the redTRCTag,
greenTRCTag and blueTRCTag values within the InterColourProfile tag value. The recommended TIFF/EP
reference colour primaries and opto-electronic conversion function (gamma correction) are equal to the values
given in ITU-R BT.709: 1993, “Basic parameter values for the HDTV standard for the studio and for international
programme exchange”.
The coefficients used in the transformation from RGB to YCbCr image data are encoded in the YCbCrCoefficients
tag-field as 3 RATIONAL numbers, i.e. LumaRed, LumaGreen and LumaBlue. These three coefficients are the
proportions of red, green and blue respectively in the luminance (Y) channel. This tag is only necessary if the
image data is stored in YCbCr form.
4.6 Image data compression
This data feature indicates the type of image data compression. The compression method is stored in the
Compression tag-field as a binary value. If no compression is used, a value of 1 is recorded in this tag-field. Other
values indicate some form of image compression. For compressed images, the average number of bits per pixel
may be recorded using the CompressedBitsPerPixel tag-field.
4.6.1 Baseline JPEG compression
All TIFF/EP readers shall support the DCT (lossy) baseline version of the TIFF/JPEG compression method defined
by the Independent JPEG Group and described in TIFF technical note number 2. This compression method is in
accordance with ISO/IEC 10918-1:1994. To indicate JPEG compression, a value of 7 is stored in the
Compression tag-field as a binary value. JPEG compression works in either strip-based or tile-based TIFF/EP
files. The term “segment” refers to either a strip or a tile. When the Compression tag-field has the value 7, each
image segment contains a complete JPEG datastream which is valid according to the ISO JPEG standard
(ISO/IEC 10918-1). TIFF/EP requires that readers only support baseline (lossy DCT) based compression.
Each image segment in a JPEG-compressed TIFF/EP file shall contain a valid JPEG datastream according to the
ISO JPEG standard’s rules for interchange-format (including JPEG quantization and Huffman tables) or
abbreviated-image-format (without JPEG quantization and Huffman tables) data. The datastream shall contain a
single JPEG frame storing that segment of the image. The required JPEG markers within a segment are:
� SOI (start of image, shall appear at the very beginning of the segment)
� SOFn (start of frame)
� SOS (start of scan, one for each scan)
� EOI (end of image, shall appear at the very end of the segment)
The actual compressed data follows SOS. It may contain RSTn (restart) markers if DRI (define restart interval) is
used.
Additional JPEG “tables and miscellaneous” markers may appear between SOI and SOFn, between SOFn and
SOS and before each subsequent SOS if there is more than one scan. These markers can include:
� DQT (define quantization tables)
� DHT (define Huffman tables)
� DRI (define restart interval)
� APPn (define application markers, see note below)
� COM (comment, ignored by TIFF/EP readers)
APPn application markers may be included in the JIF bitstream. TIFF/EP readers are not required to read Appn
markers. The EXIF image format uses application marker 1 and the SPIFF image format uses application marker 8.
In the case of EXIF, the second word of the APP1 data is the TIFF number 42. When both APP1 and the TIFF
number 42 are identified, the APP1 data includes EXIF tags. In the case of SPIFF, the three byte IDENT indentifier
in the APP8 data contains the value “SPF”. When both APP8 and “SPF” are identified, the APP8 data includes
SPIFF tags.
DNL (define number of lines) markers shall not be used in TIFF files. Readers should abort if any other marker type
is found, especially the JPEG reserved markers. Such markers are likely to indicate a JPEG extension.
The tables/miscellaneous markers may appear in any order. Readers are cautioned that, although the SOFn
marker refers to DQT tables, JPEG does not require those tables to precede the SOFn, only the SOS. Missing-
table checks should be made when SOS is reached.
4.6.2 JPEG tables
When JPEG compression is used, no other compression related tag-fields are required, but the optional
JPEGTables tag may be used. This optional tag encodes the JPEG quantization and Huffman tables for
subsequent use by the JPEG decompression process. The JPEGTables tag is useful when the image is stored in
multiple segments, in order to reduce the file size. When the JPEGTables tag is present, it shall contain a valid
JPEG “abbreviated table specification” datastream, beginning with SOI and ending with EOI. It contains one or
more JPEG tables, including DQT (define quantization tables) and DHT (define Huffman tables). When a TIFF/EP
reader decodes a JPEG compressed image having the optional JPEGTables tag, it is prudent for the reader to
send the JPEGTables abbreviated bitstream prior to each JPEG compressed image segment. This eliminates the
need for the TIFF/EP reader to manually determine which JPEG compressed image segments require these tables.
If no JPEGTables tag-field is used, then each segment shall be a co
...