TIFF


Tagged Image File Format, abbreviated TIFF or TIF, is a computer file format for storing raster graphics images, popular among graphic artists, the publishing industry, and photographers. TIFF is widely supported by scanning, faxing, word processing, optical character recognition, image manipulation, desktop publishing, and page-layout applications. The format was created by Aldus Corporation for use in desktop publishing. It published the latest version 6.0 in 1992, subsequently updated with an Adobe Systems copyright after the latter acquired Aldus in 1994. Several Aldus or Adobe technical notes have been published with minor extensions to the format, and several specifications have been based on TIFF 6.0, including TIFF/EP, TIFF/IT, TIFF-F and TIFF-FX.

History

TIFF was created as an attempt to get desktop scanner vendors of the mid-1980s to agree on a common scanned image file format, in place of a multitude of proprietary formats. In the beginning, TIFF was only a binary image format, because that was all that desktop scanners could handle. As scanners became more powerful, and as desktop computer disk space became more plentiful, TIFF grew to accommodate grayscale images, then color images. Today, TIFF, along with JPEG and PNG, is a popular format for deep-color images.
The first version of the TIFF specification was published by Aldus Corporation in the autumn of 1986 after two major earlier draft releases. It can be labeled as Revision 3.0. It was published after a series of meetings with various scanner manufacturers and software developers. In April 1987 Revision 4.0 was released and it contained mostly minor enhancements. In October 1988 Revision 5.0 was released and it added support for palette color images and LZW compression.

Features and options

TIFF is a flexible, adaptable file format for handling images and data within a single file, by including the header tags defining the image's geometry. A TIFF file, for example, can be a container holding JPEG and PackBits compressed images. A TIFF file also can include a vector-based clipping path. The ability to store image data in a lossless format makes a TIFF file a useful image archive, because, unlike standard JPEG files, a TIFF file using lossless compression may be edited and re-saved without losing image quality. This is not the case when using the TIFF as a container holding compressed JPEG. Other TIFF options are layers and pages.
TIFF offers the option of using LZW compression, a lossless data-compression technique for reducing a file's size. Use of this option was limited by patents on the LZW technique until their expiration in 2004.
The TIFF 6.0 specification consists of the following parts:
When TIFF was introduced, its extensibility provoked compatibility problems. The flexibility in encoding gave rise to the joke that TIFF stands for Thousands of Incompatible File Formats. To avoid these problems, every TIFF reader was required to read Baseline TIFF. Among other things, Baseline TIFF does not include layers, or compressed JPEG or LZW images. Baseline TIFF is formally known as TIFF 6.0, Part 1: Baseline TIFF.
The following is an incomplete list of required Baseline TIFF features:

Multiple subfiles

TIFF readers must be prepared for multiple/multi-page images per TIFF file, although they are not required to actually do anything with images after the first one.
There may be more than one Image File Directory in a TIFF file. Each IFD defines a subfile. One use of subfiles is to describe related images, such as the pages of a facsimile document. A Baseline TIFF reader is not required to read any IFD beyond the first one.

Strips

A baseline TIFF image is composed of one or more strips. A strip is a subsection of the image composed of one or more rows. Each strip may be compressed independently of the entire image, and each begins on a byte boundary. If the image height is not evenly divisible by the number of rows in the strip, the last strip may contain fewer rows. If strip definition tags are omitted, the image is assumed to contain a single strip.

Compression

Baseline TIFF readers must handle the following three compression schemes:
Baseline TIFF image types are: bilevel, grayscale, palette-color, and RGB full-color images.

Byte order

Every TIFF file begins with a two-byte indicator of byte order: "II" for little-endian or "MM" for big-endian byte ordering. The next two-byte word contains the format version number, which has always been 42 for every version of TIFF.
All words, double words, etc., in the TIFF file are assumed to be in the indicated byte order. The TIFF 6.0 specification states that compliant TIFF readers must support both byte orders ; writers may use either.

Other TIFF fields

TIFF readers must be prepared to encounter and ignore private fields not described in the TIFF specification. TIFF readers must not refuse to read a TIFF file if optional fields do not exist.

Part 2: TIFF Extensions

Many TIFF readers support tags additional to those in Baseline TIFF, but not every reader supports every extension. As a consequence, Baseline TIFF features became the lowest common denominator for TIFF. Baseline TIFF features are extended in TIFF Extensions but extensions can also be defined in private tags.
The TIFF Extensions are formally known as TIFF 6.0, Part 2: TIFF Extensions. Here are some examples of TIFF extensions defined in TIFF 6.0 specification:

Compression

A baseline TIFF file can contain a sequence of images. Typically, all the images are related but represent different data, such as the pages of a document. In order to explicitly support multiple views of the same data, the SubIFD tag was introduced. This allows the images to be defined along a tree structure. Each image can have a sequence of children, each child being itself an image. The typical usage is to provide thumbnails or several versions of an image in different color spaces.
Tiles
A TIFF image may also be composed of a number of tiles. All tiles in the same image have the same dimensions and may be compressed independently of the entire image, similar to strips. Tiled images are part of TIFF 6.0, Part 2: TIFF Extensions, so the support for tiled images is not required in Baseline TIFF readers.

Other extensions

According to TIFF 6.0 specification, all TIFF files using proposed TIFF extensions that are not approved by Adobe as part of Baseline TIFF should be either not called TIFF files or should be marked some way so that they will not be confused with mainstream TIFF files.

Private tags

Developers can apply for a block of "private tags" to enable them to include their own proprietary information inside a TIFF file without causing problems for file interchange. TIFF readers are required to ignore tags that they do not recognize, and a registered developer's private tags are guaranteed not to clash with anyone else's tags or with the standard set of tags defined in the specification. Private tags are numbered in the range 32,768 and higher.
Private tags are reserved for information meaningful only for some organization, or for experiments with a new compression scheme within TIFF. Upon request, the TIFF administrator will allocate and register one or more private tags for an organization, to avoid possible conflicts with other organizations. Organizations and developers are discouraged from choosing their own tag numbers arbitrarily, because doing so could cause serious compatibility problems. However, if there is little or no chance that TIFF files will escape a private environment, organizations and developers are encouraged to consider using TIFF tags in the "reusable" 65,000–65,535 range. There is no need to contact Adobe when using numbers in this range.

Internet Media Type

The MIME type image/tiff without an application parameter is used for Baseline TIFF 6.0 files or to indicate that it is not necessary to identify a specific subset of TIFF or TIFF extensions. The optional "application" parameter is defined for image/tiff to identify a particular subset of TIFF and TIFF extensions for the encoded image data, if it is known. According to RFC 3302, specific TIFF subsets or TIFF extensions used in the application parameter must be published as an RFC.
MIME type image/tiff-fx is based on TIFF 6.0 with TIFF Technical Notes TTN1 and TTN2. It is used for Internet fax compatible with the ITU-T Recommendations for Group 3 black-and-white, grayscale and color fax.

TIFF Compression Tag

The TIFF Tag 259 stores the information about the Compression method. The default value is 1 = no compression.
Most TIFF writers and TIFF readers support only some TIFF compression schemes. Here are some examples of used TIFF compression schemes:
Tag valueCompression schemeLossy/losslessSpecificationDescriptionImage typesUsage and support
000116-LosslessTIFF 6.0Baseline TIFFAll
000216CCITT Group 3 1-Dimensional Modified Huffman run-length encoding LosslessTIFF 6.0Baseline TIFF; compression based on ITU-T T.4Black and white
000316CCITT T.4 bi-level encoding as specified in section 4, Coding, of LosslessTIFF 6.0TIFF 6.0 Extensions; compression based on ITU-T T.4Black and white
000416CCITT T.6 bi-level encoding as specified in section 2 of LosslessTIFF 6.0TIFF 6.0 extensions; compression based on ITU-T T.6Black and white
000516Lempel–Ziv–WelchLosslessTIFF 6.0TIFF 6.0 Extensions; first defined in TIFF 5 ; a patented compression algorithm, but the patents expired in 2003 and 2004All
000616JPEG LossyTIFF 6.0TIFF 6.0 Extensions; first defined in TIFF 6 ; obsolete, should never be written.Continuous-tone
000716JPEG LossyTIFF 6 Technote2 Technote2 supersedes old-style JPEG compression; it is a TIFF 6.0 extension.Continuous-tone
000816Deflate, Adobe variant LosslessTIFF Specification Supplement 2 RFC 1950, RFC 1951, Adobe Photoshop TIFF Technical Notes; it is a TIFF 6.0 extension.All
000916JBIG, per LosslessTIFF-FXRFC 2301, RFC 3949 Black and white
000A16JBIG, per LosslessTIFF-FXRFC 2301, RFC 3949 Black and white
7FFE16NeXT RLE 2-bit greyscale encodingProprietary
800516PackBits LosslessTIFF 6.0Baseline TIFFAll
802916ThunderScan RLE 4-bit encodingProprietaryBlack and white
807F16RasterPadding in continuous tone or monochrome picture LosslessTIFF/IT ISO 12639
808016RLE for line work LosslessTIFF/IT ISO 12639
808116RLE for high-resolution continuous-tone LosslessTIFF/IT ISO 12639
808216RLE for binary line work LosslessTIFF/IT ISO 12639
80B216Deflate, PKZIP variant LosslessProprietaryAccording to TIFF Specification Supplement 2 it should be considered obsolete but reading is recommendedAll
80B316Kodak DCSProprietary
876516JBIGLibTiffBlack and white
879816JPEG2000ProprietaryIncludes a complete JP2 file inside a TIFF file, not recommended. Introduced by Leadtools.
879916Nikon NEF CompressedProprietary
879B16JBIG2Lossless, lossyTIFF-FX Extension Set 1.0Abandoned IETF draft from 2001

BigTIFF

The TIFF file formats use 32-bit offsets, which limits file size to around 4 GiB. Some implementations even use a signed 32-bit offset, running into issues around 2 GiB. BigTIFF is a TIFF variant file format which uses 64-bit offsets and supports much larger files. The BigTIFF file format specification was implemented in 2007 in development releases of LibTIFF version 4.0, which was finally released as stable in December 2011. Support for BigTIFF file formats by applications is limited.

Digital preservation

Adobe holds the copyright on the TIFF specification along with the two supplements that have been published. These documents can be found on the Adobe TIFF Resources page. The Fax standard in RFC 3949 is based on these TIFF specifications.
TIFF files that strictly use the basic "tag sets" as defined in TIFF 6.0 along with restricting the compression technology to the methods identified in TIFF 6.0 and are adequately tested and verified by multiple sources for all documents being created can be used for storing documents. Commonly seen issues encountered in the content and document management industry associated with the use of TIFF files arise when the structures contain proprietary headers, are not properly documented, and/or contain "wrappers" or other containers around the TIFF datasets, and/or include improper compression technologies, or those compression technologies are not properly implemented.
Variants of TIFF can be used within document imaging and content/document management systems using CCITT Group IV 2D compression which supports black-and-white images, among other compression technologies that support color. When storage capacity and network bandwidth was a greater issue than commonly seen in today's server environments, high-volume storage scanning, documents were scanned in black and white to conserve storage capacity.
The inclusion of the SampleFormat tag in TIFF 6.0 allows TIFF files to handle advanced pixel data types, including integer images with more than 8 bits per channel and floating point images. This tag made TIFF 6.0 a viable format for scientific image processing where extended precision is required. An example would be the use of TIFF to store images acquired using scientific CCD cameras that provide up to 16 bits per photosite of intensity resolution. Storing a sequence of images in a single TIFF file is also possible, and is allowed under TIFF 6.0, provided the rules for multi-page images are followed.

TIFF/IT

TIFF/IT is used to send data for print-ready pages that have been designed on high-end prepress systems. The TIFF/IT specification describes a multiple-file format, which can describe a single page per file set. TIFF/IT files are not interchangeable with common TIFF files.
The goals in developing TIFF/IT were to carry forward the original IT8 magnetic-tape formats into a medium-independent version. TIFF/IT is based on Adobe TIFF 6.0 specification and both extends TIFF 6, by adding additional tags, and restricts, it by limiting some tags and the values within tags. Not all valid TIFF/IT images are valid TIFF 6.0 images.
TIFF/IT defines image-file formats for encoding color continuous-tone picture images, color line art images, high-resolution continuous-tone images, monochrome continuous-tone images, binary picture images, binary line-art images, screened data, and images of composite final pages.
There is no MIME type defined for TIFF/IT. The MIME type image/tiff should not be used for TIFF/IT files, because TIFF/IT does not conform to Baseline TIFF 6.0 and the widely deployed TIFF 6.0 readers cannot read TIFF/IT. The MIME type image/tiff without an application parameter is used for Baseline TIFF 6.0 files or to indicate that it is not necessary to identify a specific subset of TIFF or TIFF extensions. The application parameter should be used with image/tiff to distinguish TIFF extensions or TIFF subsets. According to RFC 3302, specific TIFF subsets or TIFF extensions must be published as an RFC. There is no such RFC for TIFF/IT. There is also no plan by the ISO committee that oversees TIFF/IT standard to register TIFF/IT with either a parameter to image/tiff or as new separate MIME type.

TIFF/IT files

TIFF/IT consists of a number of different files and it cannot be created or opened by common desktop applications. TIFF/IT-P1 file sets usually consist of the following files:
  • Final Page
  • Continuous Tone image
  • Line Work image
  • High resolution Continuous-tone files
TIFF/IT also defines the following files:
  • Monochrome continuous-tone Picture images
  • Binary Picture images
  • Binary Line-art images
  • Screened Data
Some of these data types are partly compatible with the corresponding definitions in the TIFF 6.0 specification. The Final Page allows the various files needed to define a complete page to be grouped together: it provides a mechanism for creating a package that includes separate image layers to be combined to create the final printed image. Its use is recommended but not required. There must be at least one subfile in an FP file, but no more than one of each type. It typically contains a CT subfile and an LW subfile.
The primary color space for this standard is CMYK, but also other color spaces and the use of ICC Profiles are supported.

TIFF/IT compression

TIFF/IT makes no provision for compression within the file structure itself, but there are no restrictions.
LW files use a specific compression scheme known as Run-length encoding for LW. HC files also use a specific Run-length encoding for HC. The TIFF/IT P1 specs do not allow use of compression within the CT file.
The following is a list of defined TIFF/IT compression schemes:

TIFF/IT P1

The ISO 12639:1998 introduced TIFF/IT-P1 - a direct subset of the full TIFF/IT standard. This subset was developed on the ground of the mutual realization by both the standards and the software development communities that an implementation of the full TIFF/IT standard by any one vendor was both unlikely, and unnecessary. Almost all TIFF/IT files in digital advertising were distributed as TIFF/IT-P1 file sets in 2001. When people talk about TIFF/IT, they usually mean the P1 standard.
Here are some of the restrictions on TIFF/IT-P1 :
  • Uses CMYK only
  • It is pixel interleaved
  • Has a single choice of image orientation
  • Has a single choice of dot range
  • Restricted compression methods
TIFF/IT-P1 is a simplified conformance level of TIFF/IT and it maximizes the compatibility between Color Electronic Prepress Systems and Desk Top Publishing worlds. It provides a clean interface for the proprietary CEPS formats such as the Scitex CT/LW format.

TIFF/IT P2

Because TIFF/IT P1 had a number of limitations, an extended format was developed. The ISO 12639:2004 introduced a new extended conformance level - TIFF/IT-P2. TIFF/IT-P2 added a number of functions to TIFF/IT-P1 like:
  • CMYK spot colors only
  • Support for the compression of CT and BP data
  • Support for multiple LW and CT files in a single file
  • Support for copydot files through a new file type called SD
  • There was some effort to create a possibility to concatenate FP, LW, and CT files into a single file called the GF file, but this was not defined in a draft version of ISO 12639:2004.
This format was not widely used.

Private tags

The TIFF/IT specification preserved the TIFF possibility for developers to utilize private tags. The TIFF/IT specification is very precise regarding how these private tags should be treated - they should be parsed, but ignored.
Private tags in the TIFF/IT-P1 specification were originally intended to provide developers with ways to add specific functionality for specific applications. Private tags can be used by developers to preserve specific printing values or other functionality. Private tags are typically labelled with tag numbers greater than or equal to 32768.
All private tags must be requested from Adobe and registered.
In 1992, the DDAP developed their requirement statement for digital ad delivery. This was presented to ANSI-accredited CGATS for development of an accredited file format standard for the delivery of digital ads. CGATS reviewed their alternatives for this purpose and TIFF seemed like the ideal candidate, except for the fact that it could not handle certain required functionalities. CGATS asked Aldus for a block of their own TIFF private tags in order to implement what eventually became TIFF/IT. For example, the ability to identify the sequence of the colors is handled by tag 34017 - the Color Sequence Tag.
TIFF/IT was created to satisfy the need for a transport-independent method of encoding raster data in the IT8.1,
IT8.2 and IT8.5 standards.

Standards

TIFF/IT was defined in ANSI IT8.8–1993 standard in 1993 and later revised in the International Standard ISO 12639:1998 - Prepress digital data exchange – Tag image file format for image technology . The ISO standard replaces ANSI IT8.8–1993. It specifies a media-independent means for prepress electronic data exchange.
The ISO 12639:2004 standard for TIFF/IT superseded the ISO 12639:1998. It was also later extended in ISO 12639:2004 / Amd. 1:2007 - Use of JBIG2-Amd2 compression in TIFF/IT.