Hubbry Logo
TIFFTIFFMain
Open search
TIFF
Community hub
TIFF
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
TIFF
TIFF
TIFF
View on Wikipedia
from Wikipedia
TIFF
Wordmark of the TIFF Revision 6.0
Filename extensions.tiff, .tif
Internet media type
  • image/tiff
  • image/tiff-fx
Type codeTIFF
Uniform Type Identifier (UTI)public.tiff
Magic number49 49 2A 00 or 4D 4D 00 2A
Developed byAldus Corporation, now Adobe Inc.
Initial release12 September 1986; 39 years ago (1986-09-12)
Latest release
TIFF 6.0
3 June 1992; 33 years ago (1992-06-03)
TIFF Supplement 2 / 22 March 2002; 23 years ago (2002-03-22)
Type of formatImage file format
Extended fromtiff
Extended toExif, DCF, TIFF/EP, TIFF/IT, TIFF-FX, GeoTIFF
Websitewww.loc.gov/preservation/digital/formats/fdd/fdd000022.shtml

Tag Image File Format[1] or Tagged Image File Format,[2] commonly known by the abbreviations TIFF or TIF, is an image file format for storing raster graphics images, popular among graphic artists, the publishing industry,[3] and photographers. TIFF is widely supported by scanning, faxing, word processing, optical character recognition, image manipulation, desktop publishing, and page-layout applications.[4]

The format was created by the 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 (ISO 12234-2), TIFF/IT (ISO 12639),[5][6][7] TIFF-F (RFC 2306) and TIFF-FX (RFC 3949).[8]

History

[edit]

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 (only two possible values for each pixel), 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 the 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.[9]

TIFF is a complex format, defining many tags of which typically only a few are used in each file. This led to implementations supporting many varying subsets of the format, a situation that gave rise to the joke that TIFF stands for Thousands of Incompatible File Formats.[10] This problem was addressed in revision 6.0[9] of the TIFF specification (June 1992) by introducing a distinction between Baseline TIFF (which all implementations were required to support) and TIFF Extensions (which are optional). Additional extensions are defined in two supplements to the specification which were published in September 1995[11] and March 2002[12] respectively.

Overview

[edit]

A TIFF file contains one or several images, termed subfiles in the specification. The basic use case for having multiple subfiles is to encode a multipage telefax in a single file, but it is also allowed to have different subfiles be different variants of the same image, for example scanned at different resolutions. Rather than being a continuous range of bytes in the file, each subfile is a data structure whose top-level entity is called an image file directory (IFD). Baseline TIFF readers are only required to make use of the first subfile, but each IFD has a field for linking to a next IFD.

The IFDs are where the tags for which TIFF is named are located. Each IFD contains one or several entries, each of which is identified by its tag. The tags are arbitrary 16-bit numbers; their symbolic names such as ImageWidth often used in discussions of TIFF data do not appear explicitly in the file itself. Each IFD entry has an associated value, which may be decoded based on general rules of the format, but it depends on the tag what that value then means. There may within a single IFD be no more than one entry with any particular tag. Some tags are for linking to the actual image data, other tags specify how the image data should be interpreted, and still other tags are used for image metadata.

TIFF images are made up of rectangular[13] grids of pixels. The two axes of this geometry are termed horizontal (or X, or width) and vertical (or Y, or length). Horizontal and vertical resolution need not be equal (since in a telefax they typically would not be equal). A baseline TIFF image divides the vertical range of the image into one or several strips, which are encoded (in particular: compressed) separately. Historically this served to facilitate TIFF readers (such as fax machines) with limited capacity to store uncompressed data — one strip would be decoded and then immediately printed — but the present specification motivates it by "increased editing flexibility and efficient I/O buffering".[9]: 19  A TIFF extension provides the alternative of tiled images, in which case both the horizontal and the vertical ranges of the image are decomposed into smaller units.

An example of these things, which also serves to give a flavor of how tags are used in the TIFF encoding of images, is that a striped TIFF image would use tags 273 (StripOffsets), 278 (RowsPerStrip), and 279 (StripByteCounts). The StripOffsets point to the blocks of image data, the StripByteCounts say how long each of these blocks are (as stored in the file), and RowsPerStrip says how many rows of pixels there are in a strip; the latter is required even in the case of having just one strip, in which case it merely duplicates the value of tag 257 (ImageLength). A tiled TIFF image instead uses tags 322 (TileWidth), 323 (TileLength), 324 (TileOffsets), and 325 (TileByteCounts). The pixels within each strip or tile appear in row-major order, left to right and top to bottom.

The data for one pixel is made up of one or several samples; for example an RGB image would have one Red sample, one Green sample, and one Blue sample per pixel, whereas a greyscale or palette color image only has one sample per pixel. TIFF allows for both additive (e.g. RGB, RGBA) and subtractive (e.g. CMYK) color models. TIFF does not constrain the number of samples per pixel (except that there must be enough samples for the chosen color model), nor does it constrain how many bits are encoded for each sample, but baseline TIFF only requires that readers support a few combinations of color model and bit-depth of images. Support for custom sets of samples is very useful for scientific applications; 3 samples per pixel is at the low end of multispectral imaging, and hyperspectral imaging may require hundreds of samples per pixel. TIFF supports having all samples for a pixel next to each other within a single strip/tile (PlanarConfiguration = 1) but also different samples in different strips/tiles (PlanarConfiguration = 2). The default format for a sample value is as an unsigned integer, but a TIFF extension allows declaring them as alternatively being signed integers or IEEE-754 floats, as well as specify a custom range for valid sample values.

TIFF images may be uncompressed, compressed using a lossless compression scheme, or compressed using a lossy compression scheme. The lossless LZW compression scheme has at times been regarded as the standard compression for TIFF, but this is technically a TIFF extension, and the TIFF6 specification notes the patent situation regarding LZW. Compression schemes vary significantly in at what level they process the data: LZW acts on the stream of bytes encoding a strip or tile (without regard to sample structure, bit depth, or row width), whereas the JPEG compression scheme both transforms the sample structure of pixels (switching to a different color model) and encodes pixels in 8×8 blocks rather than row by row.

Most data in TIFF files are numerical, but the format supports declaring data as rather being textual, if appropriate for a particular tag. Tags that take textual values include Artist, Copyright, DateTime, DocumentName, InkNames, and Model.

MIME type

[edit]

The MIME type image/tiff (defined in RFC 3302) 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 (Example: Content-type: image/tiff; application=foo) 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.[14]

MIME type image/tiff-fx (defined in RFC 3949 and RFC 3950) is based on TIFF 6.0 with TIFF Technical Notes TTN1 (Trees) and TTN2 (Replacement TIFF/JPEG specification). It is used for Internet fax compatible with the ITU-T Recommendations for Group 3 black-and-white, grayscale and color fax.

Digital preservation

[edit]

Adobe holds the copyright on the TIFF specification (aka TIFF 6.0) along with the two supplements that have been published. These documents can be found on the Adobe TIFF Resources page.[15] The Fax standard in RFC 3949 is based on these TIFF specifications.[16]

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, or contain "wrappers" or other containers around the TIFF datasets, 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 (bitonal, monochrome) 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 (not in color or in grayscale) 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.[citation needed]

Details

[edit]

TIFF is a flexible, adaptable file format for handling images and data within a single file, by including the header tags (size, definition, image-data arrangement, applied image compression) defining the image's geometry. A TIFF file, for example, can be a container holding JPEG (lossy) and PackBits (lossless) compressed images. A TIFF file also can include a vector-based clipping path (outlines, croppings, image frames). 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 (or none) 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:[9]

  • Introduction (contains information about TIFF Administration, usage of Private fields and values, etc.)
  • Part 1: Baseline TIFF
  • Part 2: TIFF Extensions
  • Part 3: Appendices

Part 1: Baseline TIFF

[edit]

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.[10] 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:[9]

Multiple subfiles

[edit]

TIFF readers must be prepared for multiple/multi-page images (subfiles) 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 (IFD) 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.[9]

Strips

[edit]

A baseline TIFF image is composed of one or more strips. A strip (or band) 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

[edit]

Baseline TIFF readers must handle the following three compression schemes:[9]

Image types

[edit]

Baseline TIFF image types are: bilevel, grayscale, palette-color, and RGB full-color images.[9]

Byte order

[edit]

Every TIFF file begins with a two-byte indicator of byte order: "II" for little-endian (a.k.a. "Intel byte ordering", c. 1980)[17] or "MM" for big-endian (a.k.a. "Motorola byte ordering", c. 1980)[17] byte ordering. The next two-byte word contains the format version number, which has always been 42 for every version of TIFF (e.g., TIFF v5.0 and TIFF v6.0).[18] All two-byte 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 (II and MM); writers may use either.[19]

Other TIFF fields

[edit]

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.[9]

Part 2: TIFF Extensions

[edit]

Many TIFF readers support tags additional to those in Baseline TIFF, but not every reader supports every extension.[20][21][22] As a consequence, Baseline TIFF features became the lowest common denominator for TIFF. Baseline TIFF features are extended in TIFF Extensions (defined in the TIFF 6.0 Part 2 specification) 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:[9]

Compression

[edit]
  • CCITT T.4 bi-level encoding
  • CCITT T.6 bi-level encoding
  • LZW
  • JPEG

Image types

[edit]

Image trees

[edit]

A baseline TIFF file can contain a sequence of images (IFD). 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.[11] 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
[edit]

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 (see above). 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

[edit]

According to TIFF 6.0 specification (Introduction), all TIFF files using proposed TIFF extensions that are not approved by Adobe as part of Baseline TIFF (typically for specialized uses of TIFF that do not fall within the domain of publishing or general graphics or picture interchange) 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

[edit]

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 (currently Adobe) 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.[9]

TIFF Compression Tag

[edit]

The TIFF Tag 259 (010316) 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:

TIFF Compression Tag[21][23][24][25][26][27][28][29][30]
Tag value Compression scheme Lossy/lossless Specification Description Image types Usage and support
000116 None Lossless TIFF 6.0 Baseline TIFF All Common[31]
000216 CCITT Group 3 1-Dimensional Modified Huffman run-length encoding (a.k.a. MH or CCITT 1D) Lossless TIFF 6.0 Baseline TIFF; compression based on ITU-T T.4 Black and white Common
000316 CCITT T.4 bi-level encoding as specified in section 4, Coding, of ITU-T Recommendation T.4 (a.k.a. CCITT Group 3 fax encoding or CCITT Group 3 2D) Lossless TIFF 6.0 TIFF 6.0 Extensions; compression based on ITU-T T.4 Black and white Common
000416 CCITT T.6 bi-level encoding as specified in section 2 of ITU-T Recommendation T.6 (a.k.a. CCITT Group 4 fax encoding) Lossless TIFF 6.0 TIFF 6.0 extensions; compression based on ITU-T T.6 Black and white Common
000516 Lempel–Ziv–Welch Lossless TIFF 6.0 TIFF 6.0 Extensions; first defined in TIFF 5 (1988); a patented compression algorithm, but the patents expired in 2003 and 2004 All Common[32]
000616 JPEG (obsolete 'old-style' JPEG, later superseded in Technote2) Lossy TIFF 6.0 TIFF 6.0 Extensions; first defined in TIFF 6 (1992); obsolete, should never be written. Continuous-tone Rare
000716 JPEG ('new-style' JPEG) Lossy TIFF 6 Technote2 (1995) supersedes old-style JPEG compression; it is a TIFF 6.0 extension. Continuous-tone Uncommon
000816 Deflate (zlib), Adobe variant (official) Lossless TIFF Specification Supplement 2 (2002) RFC 1950 (1996), RFC 1951 (1996), Adobe Photoshop TIFF Technical Notes; it is a TIFF 6.0 extension. All Common
000916 JBIG, per ITU-T T.85 Lossless TIFF-FX RFC 2301 (1998), RFC 3949 (2005) Black and white Rare
000A16 JBIG, per ITU-T T.43 Lossless TIFF-FX RFC 2301 (1998), RFC 3949 (2005) Black and white Rare
7FFE16 NeXT RLE 2-bit greyscale encoding Proprietary Rare
800516 PackBits (a.k.a. Macintosh RLE) Lossless TIFF 6.0 Baseline TIFF All Rare[32]
802916 ThunderScan RLE 4-bit encoding Proprietary Black and white Rare
807F16 RasterPadding in continuous tone (CT) or monochrome picture (MP) Lossless TIFF/IT (1998, 2004) ISO 12639 Rare
808016 RLE for line work (LW) Lossless TIFF/IT (1998, 2004) ISO 12639 Rare
808116 RLE for high-resolution continuous-tone (HC) Lossless TIFF/IT (1998, 2004) ISO 12639 Rare
808216 RLE for binary line work (BL) Lossless TIFF/IT (1998, 2004) ISO 12639 Rare
80B216 Deflate, PKZIP variant (obsolete) Lossless Proprietary According to TIFF Specification Supplement 2 it should be considered obsolete but reading is recommended All Uncommon
80B316 Kodak DCS Proprietary Rare
876516 JBIG LibTIFF Black and white Rare
879816 JPEG2000 Proprietary Includes a complete JP2 file inside a TIFF file, not recommended. Introduced by Leadtools.[33] Uncommon
879916 Nikon NEF Compressed Proprietary Rare
879B16 JBIG2 Lossless, lossy TIFF-FX Extension Set 1.0 Abandoned IETF draft from 2001[34] Rare
884716 LERC Lossy ESRI LERC Rare
884C16[35] Lossy non-YCbCr JPEG Lossy DNG 1.4.0.0[36] Used for DNG semantic masks[35] and for images in the LinearRaw colorspace; explicitly indicates baseline DCT JPEG compression as opposed to "lossless Huffman JPEG".[36] Rare
C35016 ZSTD Lossless LibTIFF Rare
C35116 WebP Lossless, lossy LibTIFF Rare
CD4216[35] JPEG XL Lossless, lossy DNG 1.7.0.0[36] Rare
[edit]

BigTIFF

[edit]

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 (up to 18 exabytes in size).[37][38] 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.

Exif

[edit]

The Exif specification[39] builds upon TIFF. For uncompressed image data, an Exif file is straight off a TIFF file with some private tags. For JPEG compressed image data, Exif uses the JPEG File Interchange Format but embeds a TIFF file in the APP1 segment of the file. The first IFD (termed 0th in the Exif specification) of that embedded TIFF does not contain image data, and only houses metadata for the primary image. There may however be a thumbnail image in that embedded TIFF, which is provided by the second IFD (termed 1st in the Exif specification). The Exif audio file format does not build upon TIFF.

Exif defines a large number of private tags for image metadata, particularly camera settings and geopositioning data, but most of those do not appear in the ordinary TIFF IFDs. Instead these reside in separate IFDs which are pointed at by private tags in the main IFD.

TIFF/IT

[edit]
TIFF/IT
Filename extension
.fp, .ct, .lw, .hc, .mp, .bp, .bl, .sd[14]
Internet media type
not defined[14]
Developed byANSI, ISO
Initial release1993 (1993)
Latest release
TIFF/IT
2004; 21 years ago (2004)
Type of formatImage file format
Extended fromTIFF 6.0
StandardISO 12639[5][40][41]

TIFF/IT is used to send data for print-ready pages that have been designed on high-end prepress systems.[42] The TIFF/IT specification (ISO 12639) describes a multiple-file format, which can describe a single page per file set.[43] TIFF/IT files are not interchangeable with common TIFF files.[44][45][46]

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.[47]

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.[6]

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 (defined in RFC 3302) 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.[14]

TIFF/IT files

[edit]

TIFF/IT consists of a number of different files and it cannot be created or opened by common desktop applications.[14][44][48] TIFF/IT-P1 file sets usually consist of the following files:[6][7][49]

  • Final Page (FP)
  • Continuous Tone image (CT)
  • Line Work image (LW)
  • High resolution Continuous-tone files (HC - optional)

TIFF/IT also defines the following files:[6]

  • Monochrome continuous-tone Picture images (MP)
  • Binary Picture images (BP)
  • Binary Line-art images (BL)
  • Screened Data (SD)

Some of these data types are partly compatible with the corresponding definitions in the TIFF 6.0 specification. The Final Page (FP) 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 (of types CT, LW, etc.) 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.[6][47][50]

The primary color space for this standard is CMYK, but also other color spaces and the use of ICC Profiles are supported.[6]

TIFF/IT compression

[edit]

TIFF/IT makes no provision for compression within the file structure itself, but there are no restrictions.[47] (For example, it is allowed to compress the whole file structure in a ZIP archive.)

LW files use a specific compression scheme known as Run-length encoding for LW (Compression tag value is 808016). HC files also use a specific Run-length encoding for HC (Compression tag value is 808116). 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:[41]

TIFF/IT compression schemes
File type TIFF/IT conformance TIFF/IT-P1 conformance TIFF/IT-P2 conformance
Final Page (FP) 0th IFD field Uncompressed (000116), Deflate (000816) or PackBits (800516)
Continuous Tone (CT) Uncompressed (000116), JPEG (000716), Deflate (000816) or RasterPadding in CT or MP (807F16) Uncompressed (000116) Uncompressed (000116), JPEG (000716), Deflate (000816)
Line Work (LW) RLE for LW (808016)
High resolution Continuous tone (HC) RLE for HC (808116)
Monochrome continuous-tone Picture (MP) Uncompressed (000116), JPEG (000716), Deflate (000816) or RasterPadding in CT or MP (807F16) Uncompressed (000116) Uncompressed (000116), JPEG (000716), Deflate (000816)
Binary Picture images (BP) Uncompressed (000116), CCITT T.6 bi-level encoding (000416), Deflate (000816) Uncompressed (000116) Uncompressed (000116), CCITT T.6 bi-level encoding (000416), Deflate (000816)
Binary Line art (BL) RLE for BL (808216)
Screened Data (SD) Uncompressed (000116), CCITT T.6 bi-level encoding (000416), Deflate (000816) Uncompressed (000116), CCITT T.6 bi-level encoding (000416), Deflate (000816)

TIFF/IT P1

[edit]

The ISO 12639:1998 introduced TIFF/IT-P1 (Profile 1) - a direct subset of the full TIFF/IT standard (previously defined in ANSI IT8.8–1993). 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 (because of its complexity), and unnecessary (because Profile 1 would cover most applications for digital ad delivery). Almost all TIFF/IT files in digital advertising were distributed as TIFF/IT-P1 file sets in 2001.[51][52] When people talk about TIFF/IT, they usually mean the P1 standard.[7]

Here are some of the restrictions on TIFF/IT-P1 (compared to TIFF/IT):[50]

  • Uses CMYK only (when appropriate)
  • It is pixel interleaved (when appropriate)
  • 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 (CEPS) and Desk Top Publishing (DTP) worlds.[47][53] It provides a clean interface for the proprietary CEPS formats such as the Scitex CT/LW format.

TIFF/IT P2

[edit]

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 (Profile 2). TIFF/IT-P2 added a number of functions to TIFF/IT-P1 like:[7]

  • CMYK spot colors only (when appropriate)
  • Support for the compression of CT and BP data (JPEG and Deflate)
  • Support for multiple LW and CT files in a single file
  • Support for copydot files through a new file type called SD (Screened Data)
  • There was some effort to create a possibility to concatenate FP, LW, and CT files into a single file called the GF (Group Final) file, but this was not defined in a draft version of ISO 12639:2004.[41]

This format was not widely used.

Private tags

[edit]

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.[54]

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 (e.g., Scitex) 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 (the TIFF administrator) and registered.

In 1992, the DDAP (Digital Distribution of Advertising for Publication, later Digital Directions in Applications for Production) developed their requirement statement for digital ad delivery. This was presented to ANSI-accredited CGATS (Committee for Graphic Arts Technology Standards) 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 (the TIFF administrator) 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.[54]

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

[edit]

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 (TIFF/IT).[5] The ISO standard replaces ANSI IT8.8–1993. It specifies a media-independent means for prepress electronic data exchange.[55]

The ISO 12639:2004 (Second edition) 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.[56]

See also

[edit]
Wikimedia Commons has media related to Tagged Image File Format.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

TIFF

View on Grokipedia
from Grokipedia
The Tagged Image File Format (TIFF) is a flexible, tag-based format designed for storing and interchanging images, serving as a container that wraps various bitstream encodings for bit-mapped (pixel-based) images, including support for color, , and data. Developed by in 1986 and later maintained by Systems after acquiring Aldus in 1994, TIFF was created to facilitate the exchange of high-quality scanned images between applications and imaging devices like scanners and printers. The format's extensible structure uses tagged fields to describe image properties such as resolution, compression method, , and metadata, allowing it to accommodate diverse image types without loss of quality. TIFF supports a range of compression algorithms, including uncompressed, , and PackBits for lossless encoding, as well as lossy options like in later extensions, making it suitable for both archival preservation and efficient storage. A key strength is its ability to store multiple images or pages within a single file, along with auxiliary data like thumbnails, which enhances its utility in professional workflows. Widely adopted in industries such as , , , and , TIFF remains a preferred format for high-fidelity applications due to its lossless nature and broad compatibility with software. Although not formally an ISO standard itself, TIFF forms the basis for several standardized profiles, including TIFF/IT (ISO 12639:2004) for data exchange and (ISO 12234-2:2001) for electronic .

History

Origins and Initial Development

The Tagged Image File Format (TIFF) was developed by the , founded in Seattle, Washington, in 1984 to advance technologies. Aldus created TIFF as a flexible, extensible raster image format specifically to handle output from high-resolution scanners used in the emerging industry. The format's tagged structure allowed for metadata and image data interchange without tying to specific hardware, addressing the need for a universal standard amid diverse scanner and software vendors. Initially, TIFF focused on supporting high-quality (black-and-white) images suitable for integration into documents destined for PostScript-based printers, which were central to professional publishing workflows on platforms like the Apple Macintosh. Aldus collaborated closely with on the format's design, incorporating input from scanner manufacturers during development meetings to ensure broad compatibility. Key early contributors included for technical specifications and Apple Computer for ecosystem integration, as TIFF aligned with Aldus PageMaker—the pioneering software released for Macintosh in 1985. The first public specification for TIFF was released by Aldus in the fall of 1986, establishing it as an open standard for monochrome scanned images. This was followed by Revision 5.0 in August 1988, co-authored as an Aldus/Microsoft Technical Memorandum, which introduced support for palette-color images and LZW compression to expand its utility beyond grayscale. These early versions laid the foundation for TIFF's role in high-fidelity image handling, though further formalization occurred later.

Standardization and Evolution

The Tagged Image File Format (TIFF) reached its formal standardization with the release of version 6.0 on June 3, 1992, by , which established it as the baseline specification emphasizing extensibility through private tags while maintaining backward compatibility for core features. Following acquisition by Systems in August 1994 for $500 million, assumed ownership of the TIFF specification and continued to uphold its design principles, including the commitment to across diverse imaging applications. Subsequent minor updates focused on clarifications and corrections rather than major overhauls; for instance, TIFF Specification Supplement 2, released in 1995, addressed flaws in the compression integration defined in the original TIFF 6.0 appendix, providing a revised scheme for embedding data while preserving the format's overall structure. No further core revisions to TIFF 6.0 have been issued since, reflecting Adobe's strategy to prioritize stability and extensibility over frequent changes. To overcome the 4 GB file size limitation imposed by 32-bit offsets in standard TIFF, the BigTIFF extension was proposed in 2005 by a including contributors from and AWare Systems, introducing 64-bit offsets for compatibility with larger datasets while retaining near-identical syntax to the original format. This development was driven by the need for handling high-resolution imagery in fields like and , and it gained implementation in libraries such as LibTIFF starting in 2007. Ongoing maintenance of TIFF remains under Adobe's stewardship, with community-driven extensions filling specialized needs; for example, the standard, which embeds into TIFF files, was updated and published by the Open Geospatial Consortium in 2019, aligning with broader geographic information standards like ISO 19115-1 for metadata . Additionally, in September 2002, the formalized the type registration for TIFF as image/tiff via RFC 3302, facilitating its use in web and email protocols while specifying handling for variants like BigTIFF. Adobe's enduring emphasis on has ensured that TIFF 6.0 remains the , supporting seamless integration of extensions without breaking legacy software.

Overview

Purpose and Core Features

The Tagged Image File Format (TIFF) serves as a versatile for storing images, utilizing a tag-based structure to encapsulate both image data and associated metadata in a platform-independent manner. This design enables lossless storage, preserving the original image quality without degradation, making it suitable for high-fidelity applications such as professional photography and digital archiving. Developed initially by in collaboration with , TIFF's primary purpose is to facilitate the interchange of raster images across diverse systems and software, supporting a wide range of image types from monochrome bitmaps to multi-channel color representations. At its core, TIFF features extensibility through private tags, which allow vendors and developers to incorporate custom metadata or functionality without disrupting the standard structure. It also supports embedding multiple images within a single file, enabling complex documents like multipage scans or image sequences, while maintaining backward compatibility in its baseline specification to ensure interoperability with legacy systems. The tagged structure permits arbitrary metadata inclusion, such as resolution, orientation, and color profiles, enhancing its utility for precise image management. TIFF's advantages lie in its emphasis on archival integrity and versatility, offering no inherent limitations in extensions like BigTIFF, which employs 64-bit offsets to handle files up to 18 exabytes—far exceeding the 4 GB cap of the original format. This makes it ideal for large-scale imaging in fields requiring long-term preservation, where data fidelity is paramount. In contrast to lossy formats like , which sacrifice detail for smaller file sizes, or web-optimized , which prioritizes transparency and compression for online display, TIFF focuses on uncompressed or lossless quality retention, ensuring no information loss during storage or repeated processing.

MIME Type and Compatibility

The official MIME type for TIFF files is image/tiff, registered with the (IANA) in September 2002 via RFC 3302, which refines an earlier provisional registration from RFC 1528. This registration specifies no required parameters and supports Baseline TIFF 6.0 files, with an optional "application" parameter to indicate specific TIFF profiles or subsets for better interoperability. Subtypes such as image/tiff-fx exist for specialized profiles like TIFF-FX, used in applications, as defined in RFC 3950. TIFF compatibility varies across systems due to its extensible nature, where baseline readers are not required to support extensions, leading to inconsistent handling of or advanced features like compression variants or additional tags. Libraries such as libtiff provide robust parsing for TIFF files, supporting a wide range of tags, compression methods, and extensions while handling potential variations in reader implementations. Cross-platform compatibility is facilitated by explicit byte order indicators at the file's start—"II" for little-endian () and "MM" for big-endian ()—ensuring proper interpretation of tags and data regardless of the host system's architecture. On the web, TIFF usage is limited by its typically large file sizes and lack of native browser support outside Safari; most browsers require plugins or extensions, such as AlternaTIFF, to display TIFF content. In contrast, professional software like Adobe Photoshop offers comprehensive TIFF support, including alpha channels and multiple pages, as well as layers via vendor-specific extensions, making it a standard for editing and archiving. Multi-page TIFFs are commonly handled as single attachments in email via the image/tiff MIME type, with email clients treating the entire file as one entity without needing multipart structures for the pages within.

Applications in Digital Preservation

TIFF has been widely adopted by cultural heritage institutions for long-term digital archiving, particularly as a format for master images of scanned or born-digital still works. The Library of Congress has recommended TIFF as the preferred format for preserving digital photographs and other graphic images since the 1990s, emphasizing its suitability for high-resolution, bitonal, grayscale, or color content without loss of fidelity. Similarly, the Federal Agencies Digital Guidelines Initiative (FADGI) endorses TIFF in its technical guidelines for digitizing cultural heritage materials, specifying it for production masters in levels 1 through 4 (star ratings) to ensure consistent quality across federal digitization programs. Key advantages of TIFF in digital preservation stem from its lossless compression options, extensive metadata capabilities, and the stability of its core specification. TIFF supports embedding detailed technical and descriptive metadata via tags, allowing institutions to document provenance, scanning parameters, and rights information directly within the file, which aids in future interpretability and authenticity verification. The TIFF 6.0 specification, finalized in 1992 and unchanged in its baseline structure since then, provides a mature, open standard that minimizes risks of format obsolescence compared to more rapidly evolving alternatives. This longevity has made TIFF a reliable choice for archival masters, as it permits reversible processing without introducing artifacts. Best practices for using TIFF in preservation prioritize uncompressed or methods to maintain over decades. Institutions recommend uncompressed TIFF for ultimate fidelity, or LZW compression for moderate reduction while ensuring no information loss, as both align with baseline TIFF 6.0 requirements. To enhance sustainability, practitioners advise avoiding proprietary vendor-specific tags or extensions, which could hinder future access, and instead adhering to standard profiles like those defined in TIFF 6.0 or for geospatial content. Validation tools such as JHOVE play a crucial role by checking TIFF files for well-formedness—verifying headers, image file directories, and tag compliance—and validity against specific profiles, helping curators confirm conformance before ingestion into repositories. Despite these strengths, TIFF presents challenges in digital preservation, particularly related to file size and long-term manageability. High-resolution scans of large cultural artifacts can exceed the 4 GB limit of standard TIFF due to 32-bit offsets, necessitating the adoption of BigTIFF, an extension using 64-bit offsets to support files up to 18 exabytes, which is essential for modern high-fidelity projects. Additionally, migration risks arise from potential software or subtle alterations during format updates, such as shifting from TIFF 4.0 to 6.0, which could affect metadata integrity if not carefully managed through rigorous testing. Specific standards further guide TIFF's application in preservation workflows. The FADGI guidelines, originally issued in 2016 and updated in the third edition of 2023, outline TIFF parameters for , including bit depth, , and embedding of ICC profiles to ensure reproducible rendering. Principles from ISO 19005 (), which emphasize self-contained, device-independent files for archival documents, have influenced TIFF practices by promoting embedded metadata and avoidance of external dependencies, facilitating hybrid workflows where TIFF masters are converted to for dissemination while retaining TIFF for preservation.

Baseline TIFF Specification

File Structure and Organization

A TIFF file is structured as a sequence of 8-bit bytes, with a maximum length of 2³² bytes, beginning with an 8-byte image file header that establishes the file's basic parameters and points to the first Image File Directory (IFD). The header's first two bytes specify the byte order () used throughout the file: "II" (hexadecimal 4949, 18761) indicates little-endian format, where multi-byte values are stored with the least significant byte first, while "MM" (hexadecimal 4D4D, 19789) denotes big-endian format, with the most significant byte first. Bytes 2 through 3 contain the fixed magic number (hexadecimal 002A), serving as the version identifier for baseline TIFF compliance. The remaining four bytes (4 through 7) provide a 32-bit unsigned offset, measured in bytes from the start of the file, to the location of the first IFD; this offset must be evenly divisible by 2 for word alignment. The Image File Directory (IFD) functions as a directory or table of metadata entries that describe the associated image data, including pointers to its location within the file, and can be positioned anywhere after the header as long as the offset is valid and the IFD does not precede the header. Each IFD begins with a 16-bit unsigned integer indicating the number of entries (n) it contains, typically ranging from a few dozen to a few hundred for baseline files, followed by n consecutive 12-byte entries, and concludes with a 32-bit unsigned integer offset to the next IFD (or 0 if none follows). Every entry adheres to a fixed 12-byte format to ensure consistent parsing regardless of endianness: the first two bytes hold the 16-bit tag identifier (a numeric code categorizing the metadata); the next two bytes specify the 16-bit data type (e.g., 1 for unsigned byte, 3 for unsigned short); the following four bytes contain a 32-bit unsigned count of values; and the final four bytes store either the value itself (if it fits within 32 bits) or an offset to the value's location elsewhere in the file. Offsets within IFD entries are calculated relative to the file's start (byte 0), and all multi-byte fields—such as the tag, type, count, and offset—are interpreted according to the endianness declared in the header. To support multiple images or "subfiles" within a single TIFF file—enabling multi-page documents or related image sets—IFDs are chained sequentially: the offset at the end of one IFD points to the start of the next, forming a that applications traverse until an offset of is encountered. This structure allows for flexible organization, where each IFD independently describes its image data without interfering with others, and the total accommodates the cumulative offsets. Software implementing TIFF must detect and handle both variants by reading the header's byte order indicator first, then applying the appropriate interpretation to all subsequent multi-byte values to ensure cross-platform compatibility. For clarity, the 8-byte header can be represented as follows:
BytesFieldDescriptionSize (bits)
0-1Byte Order"II" (little-endian) or "MM" (big-endian)16
2-3VersionFixed value (0x002A)16
4-7IFD Offset32-bit unsigned integer offset to first IFD (word-aligned)32
Similarly, each 12-byte IFD entry follows this layout:
Bytes (relative to entry start)FieldDescriptionSize (bits)
0-1Tag16-bit unsigned integer identifier16
2-3Type16-bit unsigned integer data type code16
4-7Count32-bit unsigned integer number of values32
8-11Value/Offset32-bit value or offset to data (if >32 bits)32
These components ensure the file's organization remains extensible yet rigidly defined for reliable parsing.

Tags, Fields, and Byte Order

The byte order in TIFF files is specified at the beginning of the file using two mandatory 8-bit bytes: the sequence 4949 (ASCII "II") indicates little-endian order, where the least significant byte precedes the most significant byte for all multi-byte values, while 4D4D (ASCII "MM") indicates big-endian order, where the most significant byte precedes the least significant byte. This byte order applies uniformly to all multi-byte numeric fields throughout the file, including tag values and offsets, ensuring consistent interpretation across different hardware architectures. Compliant baseline TIFF readers must support both byte orders, while writers may choose either based on the target platform. Tags in baseline TIFF are stored within Image File Directories (IFDs) and serve as metadata descriptors for image and data locations. Each tag is a fixed 12-byte entry consisting of: bytes 0-1 for the 16-bit tag ID (a unique numeric identifier), bytes 2-3 for the 16-bit field type (indicating the data format), bytes 4-7 for the 32-bit count (number of values), and bytes 8-11 for the value itself if it fits within 4 bytes or an offset to the external value otherwise. This structure allows for efficient parsing while accommodating variable-length data by referencing external storage when necessary. Tags within an IFD must be sorted in ascending order by their ID for sequential reading. Baseline TIFF defines 12 field types to represent diverse data, including BYTE (8-bit unsigned , type 1), ASCII (7-bit ASCII string terminated by a null byte, type 2), SHORT (16-bit unsigned , type 3), LONG (32-bit unsigned , type 4), RATIONAL (pair of LONGs representing a , type 5), SBYTE (8-bit signed , type 6), UNDEFINED (8-bit uninterpreted bytes, type 7), SSHORT (16-bit signed , type 8), SLONG (32-bit signed , type 9), SRATIONAL (pair of SLONGs, type 10), FLOAT (32-bit IEEE floating point, type 11), and DOUBLE (64-bit IEEE floating point, type 12). These types ensure precise representation of dimensions, color spaces, and other attributes, with all multi-byte types adhering to the file's byte order. For example, SHORT values are stored as two consecutive bytes in little-endian ("II") or big-endian ("MM") format. The baseline TIFF 6.0 specification includes approximately 40 tags, categorized as required (essential for defining a valid ) or optional (providing additional details that enhance but are not mandatory). Required tags ensure core image readability, while optional ones allow flexibility without breaking compatibility. Key baseline tags describe fundamental image characteristics, as shown in the following table:
Tag ID (Hex)NameTypeDescription
0100 (256)ImageWidthSHORT or LONGNumber of in the image width direction; required and must be greater than zero.
0101 (257)ImageLengthSHORT or LONGNumber of in the image length (height) direction; required and must be greater than zero.
0102BitsPerSampleSHORTNumber of bits per sample for each color component; required for non- images, with typical values like 8 for 8-bit RGB.
0106PhotometricInterpretationSHORT encoding, such as 0 (white is zero), 1 (black is zero), 2 (RGB), or 3 (palette color); required to interpret pixel values correctly.
0115 (277)SamplesPerPixelSHORTNumber of components per pixel, such as 1 for or 3 for RGB; required and defaults to 1 if omitted.
These tags collectively define the image's dimensions, depth, and interpretation, forming the foundation for rendering. For instance, an RGB would typically set SamplesPerPixel to , BitsPerSample to [8,8,8], and PhotometricInterpretation to 2. To support extensibility, baseline TIFF readers must ignore any unknown tags encountered in an IFD, preserving future compatibility without requiring updates for new identifiers. This design allows vendors to introduce private tags above the baseline range (typically IDs 0-65535) while ensuring core functionality remains intact across implementations. Writers should only include recognized tags to avoid unnecessary warnings, though ignoring extras does not invalidate the file.

Image Storage: Strips, Tiles, and Types

In baseline TIFF, image data is organized into strips to enable efficient storage and access of raster images. Strips divide the image into horizontal bands, each comprising a configurable number of rows for sequential processing. The RowsPerStrip tag (number 278, SHORT or LONG type) specifies the number of rows in each strip, defaulting to the full image height if set to a value exceeding it; StripOffsets (tag 273, LONG type) provides the file byte offsets to the start of each strip; and StripByteCounts (tag 279, LONG type) indicates the byte length of each strip's data. This structure supports direct mapping of image rows to file positions, making it suitable for linear access patterns. Tiling provides an alternative to strips as part of the TIFF 6.0 extensions (not baseline), partitioning the image into a regular grid of rectangular blocks to facilitate random access. Baseline TIFF does not support tiles; when extensions are used, the TileWidth (tag 322, SHORT or LONG), TileLength (tag 323, SHORT or LONG), TileOffsets (tag 324, LONG), and TileByteCounts (tag 325, LONG) tags are employed, and strip-related tags are ignored. Baseline readers are not required to support tiles. Supported image types in baseline TIFF are characterized by the SamplesPerPixel (tag 277, SHORT), BitsPerSample (tag 258, SHORT array), and PhotometricInterpretation (tag 262, SHORT) tags, limiting complexity to ensure broad interoperability. Bilevel images, akin to monochrome or fax documents, use 1 sample per pixel with 1 bit per sample, employing PhotometricInterpretation values of WhiteIsZero (0, where white pixels have value 0) or BlackIsZero (1, black pixels value 0). Grayscale images feature 1 sample per pixel with 8 or 16 bits per sample, using the same photometric interpretations for intensity levels. Palette-color images consist of 1 sample per pixel at 8 bits, with PhotometricInterpretation Palette (3) and a required ColorMap tag (320, SHORT array of 3×2BitsPerSample entries) mapping indices to red, green, and blue values. RGB contone images have 3 samples per pixel (one each for red, green, blue) at 8 bits per sample, with PhotometricInterpretation RGB (2). RGBA variants extend to 4 samples per pixel, incorporating an alpha channel via the ExtraSamples tag (338, SHORT) to denote transparency, while maintaining RGB photometric interpretation. The PlanarConfiguration tag (284, SHORT) governs the arrangement of multi-sample data in strips: a value of 1 (default) indicates chunky (interleaved) format, where samples for corresponding pixels are stored adjacently (e.g., R-G-B sequences); a value of 2 specifies separate planar format, storing all values for one sample across the entire strip before proceeding to the next sample. Baseline readers are not required to support PlanarConfiguration=2. This choice affects data layout without altering the total byte count, allowing flexibility for processing workflows.

TIFF Extensions

Extension Mechanisms and Image Trees

TIFF 6.0 maintains for extensions by reserving tag numbers greater than 32,767 for new or private fields, ensuring that baseline readers can process files without disruption. Readers are required to ignore any unknown tags or values they encounter, allowing future enhancements without invalidating existing files. Private tags, starting from 32,768, are designated for proprietary extensions and must be registered with the TIFF administrator to prevent conflicts across implementations. A key mechanism for handling complex, multi-part images is the use of hierarchical Image File Directories (IFDs), often referred to as image trees. The SubIFDs tag (330) enables this by providing offsets to one or more child IFDs from a parent IFD, forming a that links related image data. This is particularly useful for pyramidal or multi-resolution images, where each level of detail is stored in a separate IFD, allowing efficient access to scaled versions without duplicating full-resolution data. Additional extensibility features include value offsets, where tag values exceeding the 4-byte field limit are stored elsewhere in the file and referenced by offset, preventing truncation of large datasets like color maps or lookup tables. Conditional reading is facilitated by baseline tags; for instance, if TileWidth (322) and TileLength (323) are present, the reader uses TileOffsets (324) and TileByteCounts (325) to access data, bypassing strip-based organization. Tile-based pyramids exemplify these mechanisms, with a root IFD linking via SubIFDs to successively lower-resolution tiled layers, supporting zoomable displays in applications such as geographic information systems. Similarly, embedding data within TIFF is achieved through tag 513 (JPEGInterchangeFormat), which points to the offset of the JPEG stream, and tag 514 (JPEGInterchangeFormatLength) for its size, allowing hybrid compression without altering the core raster structure. Post-TIFF 6.0 developments have introduced features like the XMLPacket tag (50341), an experimental addition for embedding structured XML metadata, notably Adobe's Extensible Metadata Platform (XMP) packets, to enhance interoperability with modern workflows.

Additional Image Types and Features

TIFF extensions enable a variety of advanced image types and features, expanding beyond the baseline specifications to support professional workflows in printing, photography, and high dynamic range (HDR) imaging. These include separated color models like CMYK, which uses four samples per pixel (cyan, magenta, yellow, and black) indicated by PhotometricInterpretation tag value 5, making it suitable for prepress and print applications where device-specific color separation is required. YCbCr, with tag value 6, facilitates efficient storage and processing in photographic pipelines by leveraging chroma subsampling for color images derived from RGB sources. Similarly, CIELAB (tag value 8) provides a device-independent color space based on the CIE Lab* model, useful for color management in cross-device workflows. For HDR content, the LogLUV encoding offers logarithmic representation of and , supporting dynamic ranges up to 37 orders of magnitude while preserving perceptual uniformity; it employs PhotometricInterpretation values 10 (for 24-bit LogL) or 11 (for 32-bit LogLUV), originally developed for the Radiance lighting simulation system. This format encodes XYZ tristimulus values in a compact manner, enabling high-fidelity storage of radiometrically accurate images without floating-point overhead in standard TIFF readers. TIFF also supports multi-channel images through the SamplesPerPixel tag (258), allowing up to 32 samples per pixel for applications like scientific imaging or multi-spectral analysis, where each channel represents distinct data such as spectral bands. Transparency and matte channels are handled via the ExtraSamples tag (338), which specifies the interpretation of additional samples beyond the core photometric ones—such as associated alpha (value 1, premultiplied with color) or unassociated alpha (value 2, independent opacity)—enabling in . Color management is enhanced by the ICCProfile tag (34675), an undefined-type field that embeds International Color Consortium (ICC) profiles directly into the file for precise color transformation across devices. Compatibility with Exchangeable Image File Format (Exif) metadata is achieved via the ExifIFD tag (34665), a long integer pointing to a sub-IFD containing camera-specific details like exposure and orientation, integrating seamlessly with photographic standards. These features, enabled through TIFF's extensible tag system, ensure versatility in diverse imaging contexts without altering the core file structure.

Private Tags and Vendor-Specific Extensions

Private tags in the TIFF format allow developers and vendors to extend the standard with custom metadata or features without altering the core specification. These tags are assigned numerical identifiers starting from 32,768 up to 65,535, distinguishing them from the public tags numbered 0 to 32,767. Within this range, tags are designated for private use, with registration recommended to avoid conflicts. Readers that do not support specific private tags are required to ignore them entirely, ensuring the file remains readable while preserving proprietary data. The registration of private tags is managed by , the current TIFF administrator, succeeding , to prevent conflicts and promote . Organizations can request blocks of private tags (usually limited to five or fewer) via to Adobe's developer support, without needing to the intended purpose. For applications requiring more than a handful of tags, the recommendation is to reserve a single private tag as a LONG pointer to a separate private Image File Directory (IFD), which can contain additional custom fields. This process, outlined in the TIFF 6.0 specification and subsequent Adobe technical notes, has resulted in numerous registered private tags. Notable examples of registered private tags include Photoshop's tag 34,377, which stores Image Resources data such as layer information, resolution settings, and annotations in a binary format compatible with Photoshop files. Another is tag 33,723, used for embedding IPTC-IIM (International Press Telecommunications Council-Information Interchange Model) metadata, enabling the inclusion of descriptive like captions and keywords directly in TIFF files. Vendor-specific implementations further illustrate this: Canon's CRW leverages private tags and IFDs to store sensor data, color profiles, and camera-specific parameters within a TIFF-based structure; similarly, Nikon's NEF format employs private tags for raw pixel data, white balance, and lens corrections. In geospatial applications, utilizes private tag 33,922 for the GeoKeyDirectory, which organizes keys like projection parameters and coordinate systems, though full details are covered in dedicated documentation. While private tags enhance flexibility, they introduce interoperability risks, as non-compliant readers may fail to parse files if they do not properly ignore unknown tags, potentially leading to or software crashes. To mitigate this, best practices include always registering tags through , documenting their structure publicly when possible, and embedding extensive private data in sub-IFDs rather than the main directory to avoid bloating standard fields. Vendors are also encouraged to use established extensions like private IFDs for complex data, ensuring baseline TIFF compatibility remains intact.

Compression Methods

Baseline Compression Options

The Compression tag (tag number 259) specifies the compression scheme applied to the image data in a TIFF file, with baseline TIFF 6.0 requiring support for a core set of values: 1 for no compression, 2 for CCITT 1-dimensional Modified Huffman run-length encoding (also known as CCITT Group 3 1D), and 32773 for PackBits compression. Values 3 for T.4-encoded CCITT Group 3 (supporting both 1D and 2D coding), 4 for T.6-encoded CCITT Group 4 (2D coding without end-of-line codes), and 5 for Lempel-Ziv-Welch (LZW) compression are extensions that are commonly supported. PackBits is a simple, lossless (RLE) algorithm that operates on bytes, efficiently compressing sequences of identical bytes by encoding runs with a count byte followed by the repeated value, while handling non-repeating data through direct copies; it is particularly effective for images with long runs of similar colors, such as in bilevel or simple scans. LZW is a dictionary-based lossless that builds a code table of substrings encountered in the data stream, replacing repeated sequences with shorter codes to achieve better ratios on complex data; originally patented by (U.S. Patent No. 4,558,302, expired June 20, 2003), its use in TIFF was widespread post-expiration without licensing restrictions. CCITT compressions (values 2, 3, and 4) are lossless schemes derived from standards for transmission, with value 2 using 1D for run-lengths of black and white pixels, value 3 adding optional 2D differential encoding per T.4, and value 4 employing pure 2D coding per T.6 for higher efficiency on bilevel images. These methods have specific applicability: CCITT schemes (2, 3, and 4) are restricted to bilevel (1-bit per sample) images due to their design for binary fax data, while LZW (5) and PackBits (32773) support palettized, , and full-color images with multiple bits per sample, and no compression (1) is universal. To enhance LZW performance on images with horizontal correlations, such as photographs, the optional Predictor tag (tag 317, SHORT type, value 2) applies horizontal differencing, where each pixel's value is predicted as the left neighbor's and the difference is encoded instead of the raw value. Baseline compressions trade off decoding speed and file size: PackBits offers fast encoding/decoding with modest ratios (often under 2:1 for mixed data), suitable for quick operations; LZW provides modest ratios (around 1.1:1 for typical 24-bit photographs without predictor, improving to about 1.4:1 with horizontal differencing) but slower processing due to dictionary management; CCITT methods excel on bilevel content with high ratios (up to 10:1 or more for sparse ) and reasonable speed, though limited to use.

Extended and Specialized Compression

The extended compression methods in TIFF expand the capabilities of the format beyond baseline options by introducing additional values for the Compression tag (tag 259, SHORT type), enabling lossy algorithms for photographic content and specialized lossless techniques for specific domains like bilevel . These extensions are defined in the TIFF 6.0 specification and subsequent technical notes, allowing TIFF files to incorporate more efficient storage for diverse types while maintaining compatibility through optional tag usage. JPEG compression represents a key lossy extension, supporting high compression ratios for continuous-tone images such as photographs. The tag value 6 denotes the old-style JPEG (also known as OJPEG), an initial implementation in TIFF 6.0 that embedded raw JPEG entropy-coded data but suffered from issues due to inconsistent table handling. In contrast, value 7 specifies the revised "new-style" JPEG, which adheres to processes 1 through 14 of the JPEG standard (ISO/IEC 10918-1) for both intra-frame (single-image) and inter-frame (multi-image) coding, improving robustness by storing essential parameters separately. This method requires the presence of the JPEGTables tag (347, UNDEFINED type) to hold shared quantization and Huffman tables, ensuring decoders can reconstruct the without embedded headers. JPEG-in-TIFF is particularly employed in fax applications under the TIFF-FX profile (ITU-T Recommendation T.88), where it facilitates efficient transmission of or color documents. However, its lossy nature trades file size reductions—often achieving 10:1 or higher ratios—for potential artifacts like blocking or loss of fine detail, limiting its use in preservation contexts. Deflate compression, a lossless based on the zlib deflate method, is another widely adopted extension, with tag values 8 ( Deflate, specific to Adobe implementations) and 32946 (standard Deflate). It applies LZ77-based sliding window matching followed by to image strips or tiles, offering versatile compression suitable for both grayscale and color data without quality degradation. This method gained prominence through Adobe's Photoshop TIFF technical notes and is now broadly supported, providing moderate to high compression efficiency for general-purpose images. For bilevel (black-and-white) images, compression via tag value 34661 enables advanced lossless encoding, targeting document and line art content. Defined in T.82, uses and to achieve superior ratios over baseline CCITT methods, especially for text-heavy scans, and is integrated into TIFF through the TIFF-FX framework for interoperability. In TIFF-FX ( T.88), supports both single- and multi-layer profiles, enhancing efficiency in scenarios like exchange. Unlike lossy options, preserves exact pixel fidelity, making it ideal for archival bilevel data, though it requires more computational resources for encoding and decoding. Specialized applications, such as TIFF/IT for printing, leverage these extensions selectively—employing (value 7) for continuous-tone separations (P1 profile) and retaining baseline Group 4 for halftones (P2 profile)—to balance quality and throughput in workflows. Overall, these methods highlight TIFF's extensibility, prioritizing space savings in lossy cases like while ensuring lossless integrity for specialized uses like in systems. Modern extensions in implementations like libtiff include Zstandard (Compression=34925), LZMA (34924), and lossless (34933), providing improved compression efficiency for various image types without altering the core specification.

BigTIFF

BigTIFF is an extension of the Tagged Image File Format (TIFF) designed to support files larger than 4 GB, addressing the limitations of the standard TIFF's 32-bit offsets that restrict file sizes to approximately 4 GB. Developed in 2005 through collaboration among TIFF developers, including a proposal by Steve Carlsen of , BigTIFF maintains structural similarity to classic TIFF for broad compatibility while enabling 64-bit addressing to accommodate massive datasets, such as high-resolution scans exceeding 1 GB in size. The primary structural changes in BigTIFF include an extended 16-byte file header, compared to the 8-byte header in standard TIFF. This header begins with a 2-byte byte order indicator (II for little-endian or MM for big-endian), followed by a 2-byte version number of 43 (0x002B in ), which distinguishes it from the classic TIFF version 42 (0x002A). Bytes 4-5 specify the offset size as 8 (indicating 64-bit offsets), bytes 6-7 are reserved (must be 0), and bytes 8-15 provide an 8-byte offset to the first Image File Directory (IFD). All offsets and values throughout the file use 64-bit integers, allowing theoretical file sizes up to 18 exabytes, though practical limits depend on implementation. BigTIFF also introduces additional data types, such as TIFF_LONG8 and TIFF_SLONG8 for 64-bit unsigned and signed integers, respectively, and TIFF_IFD8 for 64-bit IFD pointers, to handle large values without overflow. For , BigTIFF files can be read by updated software that recognizes version 43, while classic TIFF readers may reject them due to the unfamiliar version number; however, libraries like LibTIFF support a "classic mode" for writing smaller files (<4 GB) in the standard 32-bit TIFF format to ensure . A new private tag, TIFFTAG_TIFF_RSID ( 50908), can be used in some implementations to identify BigTIFF-specific IFD structures, though it is not mandatory. The format's IFD entries are expanded to 20 bytes each (versus 12 bytes in classic TIFF), consisting of a 2-byte tag , 2-byte type, 8-byte count, and 8-byte value or offset field, and tags are sorted by for consistency. BigTIFF is essential for applications involving very large images, such as geospatial rasters, medical imaging, and digitized cultural heritage materials where file sizes routinely surpass 4 GB. It has been widely adopted in open-source libraries, including LibTIFF version 4.0 (released in 2010 with initial support from 2007 development builds) and later versions, which provide full read/write capabilities. The specification is detailed in the BigTIFF Design document from 2005, maintained by the LibTIFF project, but it remains an informal extension without formal ISO standardization, unlike the original TIFF 6.0 specification.

Exif

The Exchangeable Image File Format () is a developed by the Japan Electronics and Information Technology Industries Association (JEITA) in October 1995 to store technical and descriptive information about digital images, primarily those captured by cameras. It builds on the Tagged Image File Format (TIFF) structure, allowing embedding of data such as camera settings, timestamps, and device details directly into image files without altering the visual content. has become integral to , with over 100 defined tags organized into Image File Directories (IFDs) for efficient access. Exif metadata is integrated into TIFF files via the main IFD (IFD 0) using the Exif IFD Pointer tag (34665, type LONG), which points to a sub-IFD containing the core data; this setup treats the metadata as a TIFF subfile while maintaining compatibility with baseline TIFF. In JPEG files, resides in the APP1 application marker segment, prefixed by the identifier "Exif\0\0", enabling seamless inclusion in compressed images. The format supports thumbnails through a dedicated IFD (e.g., tag 513 for JPEG thumbnail offset), typically a 160x120 preview image stored as a compressed within the file. Key Exif tags capture essential capture details, such as DateTime (tag 306, ASCII string for YYYY:MM:DD HH:MM:SS), Make (tag 271, ASCII for manufacturer), Model (tag 272, ASCII for camera model), ExposureTime (tag 34855, rational for in seconds), and GPSInfo (tag 34853, LONG pointing to a GPS IFD for , , and other coordinates). The MakerNote tag (tag 37500) allows vendors to append proprietary extensions, such as lens information or custom algorithms, though its format varies by manufacturer. Exif versions have evolved from 1.0 in 1995 to the current 3.0 (CIPA DC-008-2023), which introduces support for international text and enhanced interoperability, building on 2.32 (2019) by refining tag definitions without altering core structure. While Exif enhances image management and analysis, the inclusion of GPSInfo tags can inadvertently disclose precise locations, posing privacy risks when images are shared publicly, as metadata may persist through uploads or edits unless explicitly stripped.

TIFF/IT

TIFF/IT is a standardized subset of the TIFF format specifically designed for prepress digital data exchange in the graphic arts industry, defined by ISO 12639:1998 and updated in 2004 to support high-quality image interchange for printing workflows. This standard, which superseded the earlier ANSI/IT8.8 specification from 1993, ensures compatibility and predictability in prepress processes by imposing strict constraints on TIFF features to facilitate reliable data transfer between systems. It defines three conformance levels: full TIFF/IT, Profile 1 (P1) for monochrome images, and Profile 2 (P2) for color separation images, with P1 and P2 providing simplified subsets for broader adoption in printing environments. TIFF/IT is widely used in prepress workflows to exchange images for proofing, plating, and final output, ensuring consistent rendering across vendor tools. The structure of TIFF/IT files adheres to a strict baseline TIFF framework, limited to single-page images without support for tiles, multi-page documents, or complex hierarchies to maintain simplicity and . Mandatory tags include ImageWidth, ImageLength, BitsPerSample, Compression, PhotometricInterpretation, StripOffsets, SamplesPerPixel, RowsPerStrip, StripByteCounts, ResolutionUnit, XResolution, and YResolution, with specific resolutions typically set to 2400 dpi or higher for precise reproduction. Files are categorized by type: contone (continuous tone) for or images like CT ( picture) or MP ( picture), and for screened data like HC (halftone contour); binary line art (BL) and binary picture (BP) handle elements. Key tags such as InkSet (tag 332) specify the ink configuration, with value 1 for CMYK and 2 for multi-ink setups, enabling accurate in . Compression in TIFF/IT is tightly controlled to preserve image integrity for print production. Profile 1 (P1) uses exclusively for binary monochrome components like BL and BP files, providing efficient lossless encoding for and pictures, while contone files such as CT and MP remain uncompressed to avoid any potential artifacts. Profile 2 (P2) extends P1 by incorporating compression (process 1 only) for color contone images in CT files, supporting spot colors and larger color palettes, but excludes LZW compression across all profiles due to concerns and to ensure universal decoding without licensing issues. These choices prioritize lossless or minimally lossy methods suitable for high-fidelity , with P2 enabling more flexible color workflows while maintaining strict adherence to baseline TIFF rules.

GeoTIFF

GeoTIFF is a public domain extension to the TIFF 6.0 format that embeds georeferencing and geocoding metadata directly into TIFF tags, enabling raster images to be tied to specific locations on Earth or other coordinate systems. Developed by the GeoTIFF Working Group, the initial specification was released in 1995 as GeoTIFF Revision 1.0, providing a standardized mechanism for describing cartographic information associated with imagery from sources like satellite imaging and aerial photography. This extension builds on baseline TIFF by utilizing private tags to store geospatial details without altering the core image data structure, ensuring that non-GeoTIFF-aware software can still access the raster content. The core structure of GeoTIFF relies on a set of private TIFF tags numbered 32,768 and above, which are reserved for vendor-specific or extension use in the TIFF standard. Central to this is the GeoKeyDirectoryTag (tag 34735), a SHORT-type tag that serves as an array defining the coordinate reference system through GeoKeys—numeric codes representing parameters like projections, datums, and units. Complementing this, the GeoDoubleParamsTag (tag 34736) stores double-precision floating-point values referenced by the directory for parameters that exceed SHORT range, such as specific coordinate offsets or scales. For spatial transformations, the ModelTiepointTag (tag 33922, DOUBLE type) specifies tiepoints that map coordinates (i, j, z) in raster space to model coordinates (x, y, z), often combined with the ModelPixelScaleTag to define affine relationships between the image grid and real-world positions. GeoTIFF supports a wide array of projections, including Universal Transverse Mercator (UTM) and the 1984 (WGS84), through dedicated GeoKeys that encode these systems for accurate geolocation. Over 50 standard GeoKeys are defined in the specification, covering categories such as geographic coordinate systems (e.g., GTModelTypeGeoKey for model type), projected coordinate systems (e.g., ProjectedCSTypeGeoKey for PCS codes), and linear units (e.g., GeogLinearUnitsGeoKey), allowing flexible description of complex geospatial models. The format maintains with TIFF 6.0 by treating geospatial tags as optional and non-essential for image rendering, so standard TIFF readers ignore them without data loss. In 2019, the Open Geospatial Consortium (OGC) adopted and updated as an official standard (version 1.1), enhancing interoperability with modern geospatial frameworks while preserving compatibility with the 1995 revision through requirements for tag encoding and key usage. A notable extension is the Cloud Optimized GeoTIFF (COG) standard (OGC v1.0, published July 2023), which profiles GeoTIFF for efficient cloud storage and HTTP range-request access, enabling faster partial reads of large raster datasets without downloading entire files. This has become increasingly important for web-based geospatial applications and big data processing as of 2025. GeoTIFF is extensively adopted in geographic information systems (GIS) software, notably the Geospatial Data Abstraction Library (GDAL), which implements full read/write support for GeoTIFF files, including projection handling and overviews for efficient processing. It is particularly prevalent in satellite imagery workflows, such as those involving Landsat data from the U.S. Geological Survey, where GeoTIFF serves as the primary format for distributing georeferenced multispectral rasters used in environmental monitoring and land-use analysis.

References

  1. https://www.loc.gov/preservation/digital/formats/fdd/fdd000022.shtml
  2. https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf
  3. https://www.adobe.com/creativecloud/file-types/image/raster/tiff-file.html
  4. https://www.fileformat.info/format/tiff/egff.htm
  5. https://www.iso.org/standard/34342.html
  6. https://www.loc.gov/preservation/digital/formats/fdd/fdd000073.shtml
  7. https://www.computinghistory.org.uk/det/66562/Aldus-Corporation/
  8. https://www.researchgate.net/publication/11984892_Image_File_Formats_Past_Present_and_Future1
  9. https://www.computerhistory.org/revolution/personal-computers/17/306
  10. https://cool.culturalheritage.org/bytopic/imaging/std/tiff5.html
  11. https://paulbourke.net/dataformats/tiff/tiff_summary.pdf
  12. https://www.nationalarchives.gov.uk/pronom/fmt/353
  13. https://www.microimages.com/documentation/TechGuides/74bigTIFF.pdf
  14. https://docs.ogc.org/is/19-008r4/19-008r4.html
  15. https://datatracker.ietf.org/doc/rfc3302/
  16. https://docs.fileformat.com/image/tiff/
  17. https://www.loc.gov/preservation/digital/formats/fdd/fdd000328.shtml
  18. https://www.adobe.com/creativecloud/file-types/image/comparison/tiff-vs-png.html
  19. https://www.iana.org/assignments/media-types/image/tiff
  20. https://helpx.adobe.com/photoshop/using/saving-files-graphics-formats.html
  21. https://www.loc.gov/preservation/resources/rfs/RFS%202024-2025.pdf
  22. https://www.digitizationguidelines.gov/guidelines/FADGI%20Technical%20Guidelines%20for%20Digitizing%20Cultural%20Heritage%20Materials_3rd%20Edition_05092023.pdf
  23. https://www.dpconline.org/handbook/technical-solutions-and-tools/file-formats-and-standards
  24. https://jhove.openpreservation.org/modules/tiff/
  25. http://preservationtutorial.library.cornell.edu/tutorial/preservation/preservation-04.html
  26. https://pdfa.org/wp-content/until2016_uploads/2011/08/PDFA_The-Basics_A-new-standard-for-long-term-archiving.pdf
  27. https://www.verypdf.com/document/tiff6/pg_0013.htm
  28. https://www.loc.gov/preservation/digital/formats/content/tiff_tags.shtml
  29. https://www.leadtools.com/help/sdk/v20/dh/to/implementing-tiff-comments-and-tags.html
  30. http://www.picturel.com/pdf/ttn1.pdf
  31. https://cantaloupe-project.github.io/manual/3.3/images.html
  32. https://bitmiracle.github.io/libtiff.net/help/articles/KB/well-known-tags.html
  33. http://www.anyhere.com/gward/pixformat/tiffluv.html
  34. https://www.color.org/technotes/ICC-Technote-ProfileEmbedding.pdf
  35. https://www.vintasoft.com/docs/resources/TIFF6-JBIG2-lossy50.pdf
  36. https://www.digitizationguidelines.gov/guidelines/TIFF_Metadata_Final.pdf
  37. https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/
  38. https://exiftool.org/canon_raw.html
  39. https://gis-lab.info/docs/geotiff-1.8.2.pdf
  40. https://www.leadtools.com/help/sdk/dh/to/working-with-private-tiff-tags.html
  41. https://download.osgeo.org/libtiff/doc/TIFF6.pdf
  42. https://libtiff.gitlab.io/libtiff/specification/coverage.html
  43. https://www.loc.gov/preservation/digital/formats/fdd/fdd000135.shtml
  44. https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html
  45. https://www.fileformat.info/format/tiff/corion-lzw.htm
  46. https://www.verypdf.com/pdf2tif/compression.html
  47. https://www.alternatiff.com/resources/DftTIFF_TN2_JPEG.pdf
  48. https://www.alternatiff.com/resources/TIFFphotoshop.pdf
  49. https://libtiff.gitlab.io/libtiff/
  50. http://www.simplesystems.org/libtiff/specification/bigtiff.html
  51. https://www.researchgate.net/publication/295577012_Open_source_3_-_BigTIFF
  52. https://libtiff.gitlab.io/libtiff/releases/v4.0.0.html
  53. https://home.jeita.or.jp/tsc/std-pdf/CP3451C.pdf
  54. https://www.loc.gov/preservation/digital/formats/fdd/fdd000618.shtml
  55. https://exiv2.org/tags.html
  56. https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
  57. https://www.media.mit.edu/pia/Research/deepview/exif.html
  58. https://www.cipa.jp/std/documents/e/DC-X008-Translation-2019-E.pdf
  59. https://iptc.org/news/exif-3-0-released-featuring-utf-8-support/
  60. https://er.educause.edu/articles/2021/6/privacy-implications-of-exif-data
  61. https://standards.iteh.ai/catalog/standards/iso/a52faa43-ab70-4385-8350-f8588fefe306/iso-12639-2004
  62. https://www.loc.gov/preservation/digital/formats/fdd/fdd000072.shtml
  63. https://www.prepressure.com/library/file-formats/tiffit
  64. http://geotiff.maptools.org/spec/geotiffhome.html
  65. https://www.loc.gov/preservation/digital/formats/fdd/fdd000279.shtml
  66. https://www.earthdata.nasa.gov/s3fs-public/imported/19-008r4.pdf
  67. http://geotiff.maptools.org/spec/geotiff6.html
  68. https://docs.ogc.org/is/21-026/21-026.html
  69. https://gdal.org/en/stable/drivers/raster/gtiff.html
  70. https://www.usgs.gov/faqs/how-do-i-open-landsat-satellite-data-files
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.