TIFFT”
`
`Revision 6.0
`
`Final — June 3, 1992
`
`Adobe Developers Association
`
`Adobe Systems Incorporated
`1585 Charleston Road
`333;: $33 CA 94039_?900
`
`E-Mail: devsup-person@adobe.com
`
`A copy of this specification can be found in
`
`http:!iwww.adobe.com18u pporUTech Notes.htm|
`and
`ftpur'iftp.adCube.commubi'adobeiDevelopersupporbIr
`TechNoteslPDFfiles
`
`1
`
`APPLE1009
`
`1
`
`APPLE1009
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Copyright
`
`© 19864988, I992 by Adobe Systems Incorporated. Permission to cepy without
`fee all or part of this material is granted provided that the copies are not made or
`distributed for direct commercial advantage and the Adobe copyright notice ap-
`pears. If the majority of the document is copied or redistributed, it must be distrib-
`uted verbatim, without repagination or reformatting. To copy otherwise requires
`specific permission from the Adobe Systems Incorporated.
`
`Licenses and Trademarks
`
`PostScript is a trademark of Adobe Systems Incorporated. All instances of the
`name PostScript in the text are references to the PostScript language as defined by
`Adobe Systems Incorporated unless otherwise stated. The name PostScript also is
`used as a product trademark for Adobe Systems” implementation of the PostScript
`language interpreter.
`
`Any references to a “PostScript printer,” a “PostScript file,“ or a “PostScript
`driver” refer to printers, files, and driver programs (respective!y} which are writ-
`ten in or support the PostScript language. The sentences in this specification that
`use “PostScript language” as an adjective phrase are so constructed to reinforce
`that the name refers to the standard language definition as set forth by Adobe
`Systems Incorporated.
`
`PostScript, the PostScript logo, Display PostScript, Adobe, the Adobe logo,
`Adobe Illustrator, Aldus, PageMaker, TIFF, OPI, TrapWise, Tran-Script, Carta,
`and Sonata are trademarks of Adobe Systetns Incorporated or its subsidiaries, and
`may be registered in somejurisdictions.
`
`Apple, LaserWriter, and Macintosh are registered trademarks and Finder and
`System 7' are trademarks of Apple, Computer, Inc. Microsoft and MS-DOS are
`registered trademarks and Windows is a trademark of Microsoft Corporation.
`UNIX is a registered trademark of UNIX System Laboratories, Inc., a wholly
`owned subsidiary of Novell, Inc. All other trademarks are the property of their
`respective owners.
`
`Production Notes
`
`This document was created electronically using Adobe PageMaker” 6.0.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Contents
`
`Introduction ..............
`
`...................................................................................................... 4
`
`About this Specification ...................................................................... 4
`
`Revision Notes ..................................................................................... 6
`
`TiFF Administration8
`
`information andSupport8
`Private Fieids and Vaioes
`8
`
`Submitting a Proposai ............................................................................ 9
`The TiFF Advisory Committee ............................................................... 9
`Other TiFF Extensions ........................................................................... 9
`
`Part 1: Baseline TIFF .................................................................................................... 11
`
`Section 1: Notation ............................................................................ 12
`
`Section 2: TiFF Structure .................................................................. 13
`
`Section 3: Biieirei images .................................................................. 17
`
`Section 4: Grayscaie images ............................................................ 22
`
`Section 5: Paiette-coior images ........................................................ 23
`
`Section 6: RGB Fuii Coior images
`
`Section 7: Additionai Baseiine TiFF Requirements
`
`24
`
`26
`
`Section 8: Baseline Fieid Reference Guide28
`
`Section 9: PackBits Compression 42
`
`Section 10: Modified Huffman Compression...................................43
`
`Part 2: TIFF Extensions .............................................................................................. 48
`
`Section 11: CCiTT BiieveiEncodings49
`
`Section 12: Document Storage and Retrievai
`
`55
`
`Section 13: LZW Compression57
`
`Section 14: Differencing Predictor
`
`64
`
`Section 15: Tiied images66
`
`Section 16: CMYK images
`Section 17: Haiftonei-iints
`
`Section 18: Associated Aipha Handiing
`
`Section 19: Data Sampie Format
`
`Section 20: R63 image Coiorimetry
`
`69
`72
`
`77
`
`80
`
`82
`
`Section 21: YCbCrimages89
`
`Section 22: JPEG Compression
`
`Section 23: CE L*a*b* images
`
`95
`
`110
`
`Part 3: Appendices .................................................................................................... 116
`
`Appendix A: TiFF Tags Sorted byNumber 117
`
`119
`Appendix 3: Operating System Considerations
`Index ............................................................................... 120
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Introduction
`
`About this Specification
`
`Ffishuy
`
`Scope
`
`This document describes TIFF , a tag-based file format for storing and interchang-
`ing raster images.
`
`The first version of the TIFF specification was published by Aldus Corporation in
`the fall of 1986, after a series of meetings with various scanner manufacturers and
`software developers. It did not have a revision number but should have been la-
`beled Revision 3.0 since there were two major earlier draft releases.
`
`Revision 4.0 contained mostly minor enhancements and was released in April
`198?. Revision 5.0, released in October 1988, added support for paiette color
`images and LZW compression.
`
`TIFF describes image data that typically comes from scanners. frame grabbers,
`and paint— and photo-retouching programs.
`
`TIFF is not a printer language or page description language. The purpose of TIFF
`is to describe and store raster image data.
`
`A primary goal ofTIFF is to provide a rich environment within which applica-
`tions can exchange image data. This richness is required to take advantage of the
`varying capabilities of scanners and other imaging devices.
`
`Though TIFF is a rich format, it can easily be used for simple scanners and appli-
`cations as well because the number of required fields is small.
`
`TIFF will be enhanced on a continuing basis as new imaging needs arise. A high
`priority has been given to structuring TIFF so that future enhancements can be
`added without causing unnecessary hardship to developers.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`
`Features
`
`TIFF is capable of describing bileve], grayscale, palette-color, and fiill-color
`image data in several color spaces.
`
`TIFF includes a number of compression schemes that allow developers to
`choose the best space or time tradeoff for their applications.
`
`TIFF is not tied to specific scanners, printers, or computer display hardware.
`
`TIFF is portable. It does not favor particular operating systems, file systems,
`compilers, or processors.
`
`TIFF is designed to be extensible—to evolve gracefully as new needs arise.
`
`TIFF allows the inclusion of an unlimited amount of private or special-purpose
`information.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Revision Notes
`
`Minor changes to TIFF 6.0, March 1995
`
`Updated contact information and TIFF administration poiicies. since Aides Cor-
`poration merged with Adobe Systems incorporated on September 1 . i 994.
`
`The fechnicai content and pagination are unchangedfi'om the originai J3me 3,
`I 992 release.
`
`TIFF 5.0 to TIFF 6.0
`
`This revision replaces TIFF Revision 5.0.
`
`In the main body of the document, paragraphs that contain new or substantially-
`changed information are shown in italics.
`
`New Features in Revision 6.0
`
`Major enhancements to TIFF 6.0 are described in Part 2. They include:
`
`CMYK image definition
`
`A revised RGB Colorimetry section.
`
`YCbCr image definition
`
`CEE L*a*b* image definition
`
`Tiled image definition
`
`JPEG compression
`
`
`Clarifications
`
`The LZW compression section more clearly explains when to switch the cod-
`ing bit length.
`
`The interaction between Compression=2 {CCITT Huffman) and
`Photometriclnterpretation was clarified.
`
`The data organization of uncompressed data (Compression=l ) when
`BitsPerSample is greater than 8 was clarified. See the Compression field de-
`scription.
`
`The discussion ofCClTT Group 3 and Group 4 bilevel image encodings was
`clarified and expanded, and Group30ptions and Group40ptions fields were
`renamed T40ptions and T60ptions. See Section 1 l.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Organizational Changes
`
`0 To make the organization more consistent and expandable, appendices were
`transformed into numbered sections.
`
`0 The document was divided into two parts—Baseline and Extensions—to help
`developers make better and more consistent implementation choices. Part 1,
`the Baseline section, describes those features that all general-purpose TIFF
`readers should support. Part 2, the Extensions section, describes a number of
`features that can be used by special or advanced applications.
`' An index and table of contents were added.
`
`Changes in Requirements
`
`- To illustrate 3 Baseline TIFF file earlier in the document, the material from
`
`Appendix G (“TIFF Classes“) in Revision 5 was integrated into the main body
`of the specification . As part of this integration, the TIFF Classes terminology
`was replaced by the more monolithic Baseline TIFF terminology. The intent
`was to further encourage all mainstream TIFF readers to support the Baseline
`TIFF requirements for bilevel, grayscale, RGB, and palette-color images.
`
`0 Due to licensing issues, LZW compression support was moved out of the “Part
`1: Baseline TIFF” and into “Part 2: Extensions."
`
`- Baseline TIFF requirements for bit depths in palette~color images were weak—
`ened a bit.
`
`Changes in Terminology
`
`Compatibility
`
`In previous versions of the specification, the term "tag" reffered both to the identi-
`fying number ofa TIFF field and to the entire field. In this version, the term “tag"
`refers only to the identifying number. The term “field" refers to the entire field,
`including the value.
`
`Every attempt has been made to add functionality in such a way as to minimize
`compatibility probiems with files and software that were based on earlier versions
`of the TIFF specification. The goal is that TIFF files should never become obso-
`lete and that TIFF software should not have to be revised more frequently than
`absolutely necessary. In particular. Baseline TIFF 60 files will generally be read-
`able even by older applications that assume TIFF 5.0 or an earlier version ofthe
`specification.
`
`However, TIFF 6.0 files that use one of the major new extensions, such as a new
`compression scheme or color space, will not be successfully read by oider soft-
`ware. In such cases, the older applications must gracefully give up and refuse to
`import the image, providing the user with a reasonably informative message.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`TIFF Administration
`
`Information and Support
`
`The most recent version oftlre TIFF specification is available in PDF format on
`the Adobe WWW and Ftp servers See the cover page of the specification for the
`required addresses.
`
`Because of the widespread use of TIFF for in many environments, Adobe is un-
`able to provide a general consulting service for TIFF implementors. TIFF devel-
`opers are encouraged to study sample Tl FF files, read TIFF documentation
`thoroughly, and work with developers of other products that are important to you.
`
`If your Tl FF question specifically concerns compatibility with an Adobe Systems
`product, please contact Adobe Developer Support at devsup-person@adobe.com.
`
`Most companies that use TIFF can answer questions about support for TIFF in
`their products. Contact the appropriate product manager or developer support
`service group.
`
`Private Fields and Values
`
`An organization might wish to store information meaningful to only that organi-
`zation in a TIFF file. Tags numbered 32 763 or higher, sometimes catled private
`tags, are reserved for that purpose.
`
`Upon request, the TIFF administrator (send email to dcvsup-person@adobe.com)
`will allocate and register one or more private tags for an organization, to avoid
`possible conflicts with other organizations. You do not need to tell the TIFF ad-
`ministrator what you plan to use them for, but giving us this information may help
`other developers to avoid some duplication ofet‘fort. We will likely make the tag
`database public at some point.
`
`Private enumerated values can be accommodated in a similar fashion. For ex~
`
`ample. you may wish to experiment with a new compression scheme within TIFF.
`Enumeration constants numbered 32768 or higher are reserved for private usage.
`Upon request, the administrator will allocate and register one or more enumerated
`values for a particular field (Compression, in our example), to avoid possible
`conflicts.
`
`Tags and values allocated in the private number range are not prohibited from
`being included in a fiJture revision of this specification. Several such instances
`exist in the current TIFF specification.
`
`Do not choose your own tag numbers. Doing so could cause serious compatibility
`problems in the future. However, if there is little or no chance that your TIFF files
`will escape your private environment, please consider using TIFF tags in the
`“reusable” 65000-65535 range. You do not need to contact Adobe when using
`numbers in this range.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`If you need more than 10 tags, we suggest that you reserve a single private tag,
`define itas a LONG TIFF data type, and use its value as a pointer (offset) to a
`private [FD or other data structure of your choosing. Within that IFD, you can use
`whatever tags you want, since no one eISe will know that it is an IFD unless you
`tell them.
`
`Submitting a Proposal
`
`Any person or group that wants to propose a change or addition to the TIFF speci-
`fication should prepare a proposal that includes the following information:
`
`* Name of the person or group making the request, and your affiliation.
`
`° The reason for the request.
`
`* A list of changes exactly as you propose that they appear in the specification.
`Use inserts, callouts, or other obvious editorial techniques to indicate areas of
`change, and number each change.
`
`- Discussion of the potential impact on the installed base.
`
`' A list of contacts outside your company that support your position. lnclude
`their affiliation.
`
`Please send your proposal to devsup-person@adobe.com.
`
`The TIFF Advisory Committee
`
`The TIFF Advisory Committee is a working group of TIFF experts from a number
`of hardware and software manufacturers. It was formed in the spring of 1991 to
`provide a forum for debating and refining proposals for the 6.0 release of the TIFF
`specification.
`
`if you are a TIFF expert and think you have the time and interest to work on this
`committee, contact devsup-pcrson@adobe.com for further information. For the
`TIFF 6.0 release, the gmup met every two or three months, usually on the west
`coast of the US. Accessibility via Internet email is a requirement for membership,
`since that has proven to be an invaluable means for getting work done between
`meetings.
`
`Other TIFF Extensions
`
`WWW (new location is under
`construction; check the Adobe WWW home page (httpdiwwwadobecom) for
`future developements} will contain proposed TIFF extensions from other compa-
`nies that are not approved by Adobe as part of Baseline TIFF.
`
`These proposals typically represent specialized uses of TIFF that do not fall
`within the domain of publishing or general graphics or picture interchange. Gen-
`erally, these features will not be widely supported. If you do write files that incor-
`porate these extensions, be sure to either not call them TIFF files or mark them in
`some way so that they will not be confused with mainstream TIFF files.
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`If you have such a document, send it to devsup-person@adcbe.com. All submis-
`sions must be PDF documents or simple text. Be sure to include contact informa-
`tion—at least an email address.
`
`10
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Part 1: Baseline TIFF
`
`The TIFF specification is divided into two parts. Part 1 describes Baseline TJFF.
`Baseline TIFF is the core oleFF. the essentials that all mainstream TlFF devel—
`
`opers should support in their products.
`
`11
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Section 1: Notation
`
`Decimal and Hexadecimal
`
`Compliance
`
`Unless otherwise noted, all numeric values in this document are expressed in
`decimal. (“.H“ is appended to hexidecimal values.)
`
`Is and shaft indicate mandatory requirements. All compliant writers and readers
`must meet the specification.
`
`Shoaid indicates a recommendation.
`
`Ma]; indicates an option.
`
`Features designated 'nat reeommendecifbr general data interchange ' are consid—
`ered extensions to Baseiine TIFF. Fiies that use saeiifeatures shaii be designated
`"Extended TIFF 6. f) "flies. and the partieaiar extensions arsed shonid be dow-
`mented. A Baseiine TIFF 6. 0 reader is not required to Support any extensions.
`
`12
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Section 2: TIFF Structure
`
`TIFF is an image file format. In this docament, afii’e is defined to be a sequence of
`8-bit bytes, where the bytes are numbered from 0 to N. The largest possible TIFF
`file is 2**32 bytes in length.
`
`A TIFF file begins with an S-byte imagejii'e header that points to an imagefile
`directory (JPD). An image file directory contains information about the image, as
`well as pointers to the actual image data.
`
`The following paragraphs describe the image file header and [FD in more detail.
`
`See Figure l.
`
`Image File Header
`
`A TIFF file begins with an 8—bytc image file header, containing the following
`information:
`
`Bytes 0-] :
`
`The byte order used within the fiie. Legal values are:
`
`“11“
`
`(4949.H)
`
`“MM" (4D4D.H)
`
`lit the “11” format, byte order is always from the least significant byte to the most
`significant byte, for both 16-bit and 32-bit integers This is called Kittie-endion byte
`order. In the “MM" format, byte order is always from most significant to least
`significant, for both 16-bit and 32-bit integers. This is called big—citation byte
`Order.
`
`Bytes 2-3
`
`An arbitrary but carefully chosen number (42) that further identifies the file as a
`TIFF file.
`
`The byte order depends on the value of Bytes 0— l .
`
`Bytes 4-?
`
`The offset (in bytes) of the first IFD. The directory may be at any location in the
`file after the header but must begin on a word boundary. In particular, an Image
`File Directory may follow the image data it describes. Readers must follow the
`pointers wherever they may lead.
`
`The term byte offset is always used in this document to refer to a location with
`respect to the beginning of the TIFF file. The first byte of the file has an offset of
`0.
`
`13
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Figure 1
`
`Header
`
`Directory Entry
`
`0
`
`2
`
`4
`
`Byte Order
`
`42
`
`Offset of Dlh IFD
`
`X
`
`x+2
`
`X+4
`
`><+s
`
`Tag
`
`Type
`
`Counl
`
`Vatueor Offset
`
`|
`
`l
`
`V
`‘:| Value
`
`A
`B i—i
`l
`IFD
`8
`
`
`
`Number of Directory Entries
`Directory Entry0
`
`Directory Entry 1
`
`Directory Entry 2
`
`Offset of next IFD
`
`
`
`A
`A+2
`
`A+td
`
`A+26
`
`“2‘5" 1 2
`
`Image File Directory
`
`An Image Fife Directory (!FD) consists of a 2-byte count of the number of direc-
`tory entries (i.e., the number of fields}, followed by a sequence of lZ-byte field
`entries, followed by a 4—byte offset of the next IFD (or 0 if none). (Do not forget to
`write the 4 bytes of 0 after the last IFD.)
`
`There must be at least I IFD in a TIFF file and each IFD must have at least one
`
`entry.
`
`See Figure l.
`
`IFD Entry
`
`Each l2-byte [FD entry has the following format:
`
`Bytes 0-1
`
`The Tag that identifies the field.
`
`Bytes 2-3
`
`The field Type.
`
`Bytes 4-?
`
`The number of values, Count of the indicated Type.
`
`14
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Bytes 8-1]
`
`The Value Offset, the file offset (in bytes) ofthe Value for the field.
`The Value is expected to begin on a word boundary; the correspond-
`ing Value Offset will thus be an even number. This file offset may
`point anywhere in the file, even after the image data.
`
`iFD Terminology
`
`A TIFFfieid is a logical entity consisting of TIFF tag and its value. This logical
`concept is implemented as an [FD Entry, plus the actual value if it doesn’t fit into
`the valuefoffset part, the last 4 bytes of the IFD Entry. The terms TIFRfleid and
`JFD entry are interchangeable in most contexts.
`
`Sort Order
`
`The entries in an IFD must be sorted in ascending order by Tag. Note that this is
`not the order in which the fields are described in this document. The Values to
`
`which directory entries point need not be in any particular order in the fiie.
`
`Value/Offset
`
`To save time and space the Value Offset contains the Value instead of pointing to
`the Value if and only if the Value fits intg 4 bfies. If the Value is shorter than 4
`bytes, it is left-justified within the 4-byte Value Offset, i.e., stored in the lower-
`numbered bytes. Whether the Value fits within 4 bytes is determined by the Type
`and Count of the field.
`
`Count
`
`Count—called Length in previous versions of the specification—is the number of
`values. Note that Count is not the total number of bytes. For example, a single 16-
`bit word (SHORT) has a Count of 1; not 2.
`
`Types
`
`The field types and their sizes are:
`
`l = BYTE
`
`2 = ASCII
`
`8-bit unsigned integer.
`
`8-bit byte that contains a 7-bit ASCII code; the last byte
`must be NUL {binary zero).
`
`3 = SHORT
`
`16-bit (2-byte) unsigned integer.
`
`4 = LONG
`
`32—bit (4—byte) unsigned integer.
`
`5 = RATIONAL
`
`Two LONGs: the first represents the numerator of a
`fraction; the second, the denominator.
`
`The value ofthe Count part ofan ASCII field entry includes the NUL. pradding
`is necessary, the Count does not include the pad byte. Note that there is no initial
`“count byte" as in Pascal-style strings.
`
`15
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Any ASCllfield can contain multiple strings. each terminated with a NUL. A
`single string is preferred wheneverpossible. The Countfor multi-stringfields is
`the number ofbytes in all the strings in thatfieldplus their terminating NUL
`bytes. Only one NUL is allowed between strings. so that the stringsfbllowing the
`first string will often begin on an odd byte.
`
`The reader must check the type to verify that it contains an expected value. TIFF
`currently allows more than I valid type for some fields. For example, lmageWidth
`and lmageLength are usually specified as having type SHORT. But images with
`more than 64K rows or columns must use the LONG field type.
`
`TlFF readers should accept BYTE. SHORT, or LONG valuesfor any unsigned
`integerfield This allows a single procedure to retrieve any integer value, makes
`reading more robust. and saves disk space in some situations.
`
`In TlFF 6.0. some newfield types have been defined:
`
`6 = SBYTE
`
`An 8-bit signed (twos-eornplement) integer.
`
`”l = UNDEFINED
`
`An 8~bit byte that may contain anything, depending on
`the definition of the field.
`
`8 = SSHORT
`
`A 16-bit (2-byte) signed (Mos-complement) integer.
`
`9 = SLONG
`
`A 32—bit (4-byte) signed (mos—complement) integer.
`
`10 = SRATIONAL
`
`Two SLONG’s: the first represents the numerator of a
`fraction, the second the denominator.
`
`I l = FLOAT
`
`Single precision (4-byte) IEEE format.
`
`12 = DOUBLE
`
`Double precision (S-byte) IEEE format.
`
`These new.field types are also governed by the byte order (ll or MW in the TIFF
`header.
`
`Warning: It is possible that other TIFFfield types will be added in thefuture.
`Readers should skip overJfields containing an unetpectedfleld ape.
`
`Fields are arrays
`
`Each TlFFjield has an associated Count. This means that allfields are actually
`one-dimensional arrays, even though moslfields contain only asingle value.
`
`For example. to store a complicated data structure in a single privatefield. use
`the UNDEFlNEDfield type and set the Count to the number ofbytes required to
`hold the data structure.
`
`Multiple Images per TIFF File
`
`There may be more than one [PD in a TIFF file. Each IFD defines a subfile. One
`potential use of subfiles is to describe related images, such as the pages of a fac—
`simile transmission. A Baseline TIFF reader is not required to read any IFDs
`beyond the first one.
`
`16
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Section 3: Bilevel Images
`
`Now that the overall TIFF structure has been described, we can move on to filling
`the structure with actual fields (tags and values) that describe raster image data.
`
`To make all of this clearer. the discussion will be organized according to the four
`Baseline TIFF image types: bilevel, grayscale. palette-color, and full-color im-
`ages. This section describes bilevel images.
`
`Fields required to describe bilevel images are introduced and described briefly
`here. Full descriptions of each field can be found in Section 8.
`
`
`Color
`
`A bilcvel image contains two colors—black and white. TlFF allows an applica-
`tion to write out bilevel data in either a white-is—zero or black-is-zero format. The
`
`field that records this information is called Photometric]nterpretation.
`
`Photometriclnterpretation
`
`Tag
`
`=262 [106.H)
`
`Type =SHORT
`
`Values:
`
`WhitelsZero. For bilevel and grayscale images: 0 is imaged as white. The maxi-
`mum value is imaged as black. This is the normal value for Compression=2.
`
`BlacklsZero. For bilevel and grayscale images: 0 is imaged as black. The maxi-
`mum value is imaged as white. lfthis value is specified for Compression=2, the
`image should display and print reversed.
`
`
`Compression
`
`Data can be stored either compressed or uncompressed.
`
`Compression
`
`Tag
`
`=259(103.H)
`
`Type =SHORT
`
`Values:
`
`No compression. but pack data into bytes as tightly as possible, leaving no unused
`bits (except at the end of a row). The component values are stored as an array of
`type BYTE. Each scan line (row) is padded to the next BYTE boundary.
`
`[*3
`
`CCITT Group 3 l-Dimensional Modified Huffman run length encoding. See
`
`17
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Section IO for a description ofModified Huffman Compression.
`
`32773
`
`PackBits compression, a simple byte-oriented run length scheme. See the
`PaekBits section for details.
`
`Data compression applies only to raster image data. All other TIFF fields are
`unaffected.
`
`Baseline TlFF readers must handle all three compression schemes.
`
`Rows and Columns
`
`
`An image is organized as a rectangular array ofpixels. The dimensions ofthis
`array are stored in the following fields:
`
`lmageLength
`
`Tag
`
`= 257(10LH}
`
`Type = SHORT or LONG
`
`The number of rows (sometimes described as scanlines) in the image.
`
`image Width
`
`Tag
`
`= 256 (100.11)
`
`Type = SHORT or LONG
`
`The number ofcolumns in the image, i.e., the number ofpixels per scanline.
`
`Physical Dimensions
`
`Applications often want to know the size of the picture represented by an image.
`This information can be caiculated from lmageWidth and ImageLength given the
`following resolution data:
`
`Resolution Unit
`
`Tag
`
`= 296 (128.H)
`
`Type = SHORT
`
`Values:
`
`No absolute unit of measurement. Used for images that may have a non-square
`aspect ratio but no meaningful absolute dimensions.
`
`l‘-J
`
`Lin)
`
`Inch.
`
`Centimeter.
`
`Default = 2 (inch).
`
`18
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`XResqution
`
`Tag
`
`=282 (1 lA.l—l)
`
`Type =RATIONAL
`
`The number of pixels per ResolutionUnit in the lmachidth (typically, horizontal
`- see Orientation} direction.
`
`YRESOIution
`
`Tag
`
`=283 (l 1B.H)
`
`Type = RATIONAL
`
`The number of pixels per ResolutionUnit in the lmageLength (typically, vertical)
`direction.
`
`Location of the Data
`
`Compressed or uncompressed image data can be stored almost anywhere in a
`TlFF file. TIFF also supports breaking an image into separate strips for increased
`editing flexibility and efficient U0 buffering. The location and size of each strip is
`given by the following fields:
`
`RowsPerStn'p
`
`Tag
`
`= 2T8 (l l6.H)
`
`Type = SHORT or LONG
`
`The number of rows in each strip (except possibly the last strip.)
`
`For example, if lmageLength is 24, and RowsPerStrip is 10, then there are 3
`strips, with 10 rows in the first strip, 10 rows in the second strip, and 4 rows in the
`third strip. (The data in the last strip is not padded with 6 extra rows of dummy
`data.)
`
`StripOffsets
`
`Tag
`
`=2?3 (lll.H)
`
`Type = SHORT or LONG
`
`For each strip, the byte offset of that strip.
`
`StripByteCounts
`
`Tag
`
`= 2?9 (117.H)
`
`Type = SHORT or LONG
`
`For each strip, the number of bytes in that strip afiei' any compression.
`
`19
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Offset Description
`(hex)
`
`Header:
`
`0000
`0002
`
`0004
`
`IFD:
`
`0014
`001 6
`0022
`002 E
`003 A
`0046
`0052
`0053
`006A
`0076
`0082
`0083
`009A
`
`00A6
`
`Byte Order
`42
`
`1st IFD offset
`
`Number of Directory Entries
`NewSubfi ieType
`ImageW idth
`ImageLength
`Compression
`Photometric] nterpretation
`Stri pOffsets
`RowsPerStrip
`StripByteCounts
`XResolution
`YResolution
`Software
`DateTime
`
`Next IFD offset
`
`Values longer than 4‘ bytes:
`0036
`StripOffsets
`03A6
`StripByteCounts
`0696
`XResolution
`069E
`Y Resolution
`
`06A6
`0636
`
`Software
`DateTime
`
`Image Date:
`00000700
`XXXXXXXX
`XXXXXXXX
`XXXXXXXX
`
`End ofemmple
`
`Putting it all together (along with a couple ofless-important fields that are dis-
`cussed later), a sample bilevel image file might contain the following fields:
`
`A Sample Bilevei TIFF File
`
`Value
`
`(numeric values are expressed in hexadecimal notation)
`
`4D4D
`002A
`
`000 0001 4
`
`000C
`00FE
`0! 00
`0101
`0103
`0106
`0111
`0116
`011?
`011A
`0113
`0131
`0132
`
`0004
`0004
`0004
`0003
`0003
`0004
`0004
`0003
`0005
`0005
`0002
`0002
`
`00000001 00000000
`00000001 00000?D0
`00000001 00000338
`00000001 8005 0000
`00000001 00010000
`0000003C 00000036
`00000001 00000010
`0000003C 000003A6
`00000001 00000696
`00000001 0000069E
`00000003 000006A6
`00000014 00000636
`
`00000000
`
`OffsetO, Offset l, Offsetl 87
`CountO, Countl, CountiS?
`0000012C 00000001
`0000012C 00000001
`
`“PageMaker 40”
`“1988:02: 18 13:59:59"
`
`Cempressed data for strip 10
`Compressed data for strip 1'19
`
`Compressed data for strip 53
`Compressed data for strip 160
`
`20
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Comments on the Bilevel Image Example
`
`0 The IFD in this example starts at 14h. It could have started anywhere in the file
`providing the offset was an even number greater than or equal to 8 (since the
`TIFF header is always the first 8 bytes ofa TIFF file).
`
`0 With 16 rows per strip, there are 188 strips in all.
`
`0 The example uses a number of optional fields such as DateTime. TIFF readers
`must safely skip over these fields if they do not understand or do not wish to
`use the information. Baseline TIFF readers must not require that such fields be
`present.
`
`* To make a point, this example has highly-fragmented image data. The strips of
`the image are not in sequential order. The point of this example is to illustrate
`that strip offsets must not be ignored. Never assume that strip N+l follows
`strip N on disk. It is not required that the image data follow the IFD informa-
`tion.
`
`Required Fields for Bilevel Images
`
`Here is a list of required fields for Baseline TIFF bilevel images. The fields are
`listed in numerical order. as they would appear in the IFD. Note that the previous
`example omits some of these fields. This is pennined because the fields that were
`omitted each have a default and the default is appropriate for this file.
`
`Decimal Hex Type
`
`Value
`
`1, 2 or 32773
`
`0 or 1
`
`100
`
`101
`
`103
`
`106
`
`I
`
`I
`
`1
`
`l 16
`
`SHORT or LONG
`
`SHORT or LONG
`
`SHORT
`
`SHORT
`
`SHORT or LONG
`
`SHORT or LONG
`
`LONG or SHORT
`1 1 7'
`1 IA RATIONAL
`
`1113 RATIONAL
`
`128
`
`SHORT
`
`I, 2 or 3
`
`TagName
`
`ImageWidth
`
`ImageLength
`
`Compression
`
`256
`
`257r
`
`259
`
`Photometrielnterpretation 262
`
`StripOffsets
`
`RowsPerStrip
`
`StripByteCounts
`XResolution
`
`YResolution
`
`ResolutionUnit
`
`273
`
`278
`
`279
`282
`
`283
`
`296
`
`Baseline TIFF bilevel images were called TIFF Class B images in earlier versions
`ofthe TIFF specification.
`
`21
`
`

`

`TIFF 6.0 Specification
`
`Final—June 3, 1992
`
`Section 4: Grayscale Images
`
`Grayscale images are a generalization of bilevel images. Bilevel images can store
`only black and white image data, but grayscale images can also store shades of
`gray.
`
`To describe such images. you must add or change the following fields. The other
`required fields are the same as those required for biievel images.
`
`Differences from Bilevel Images
`
`Compression = l or 32773 (PaekBr'ts). In Baseline TIFF, grayscale images can
`either be stored as uncompressed data or compressed with the PaekBits algorithm.
`
`Caution: PackBits is often ineffective on continuous tone images, including many
`grayscale images. In such cases, it is better to leave the image uncompressed.
`
`BitsPerSample
`
`Tag
`
`= 258 (1021-1)
`
`Type = SHORT
`
`The number of bits per component.
`
`Allowable values f