13-Apr-89 7:06:02-GMT,19029;000000000001 Return-Path: Received: from Forsythe.Stanford.EDU by sumex-aim.stanford.edu (4.0/inc-1.0) id AA01714; Thu, 13 Apr 89 00:06:02 PDT Message-Id: <8904130706.AA01714@sumex-aim.stanford.edu> Received: by Forsythe.Stanford.EDU; Wed, 12 Apr 89 23:33:24 PDT Date: Thu 13 Apr 1989 01:32 CDT From: Subject: Tiff File Format To: The following describes the tiff file format. I will get more information on the format and post what I have found. --------------------------- Cut Here -------------------------------------- Tag Image File Format Rev 4.0 (The following is an excerp from a memorandum by Aldus and Microsoft) Revision Notes This revision of the TIFF specification has been given a Revision number. It is really the fourth major revision so the Revision number was set to 4.0. Abstract This document describes TIFF, a tag based file format that is designed to promote the interchange of digital image data. The fields were defined primarily with desktop publishing and related applications in mind, although it is conceivable that other sorts of imaging applications may find TIFF useful. The general senario for which TIFF was invented assumes that applications software for scanning or painting creates a TIFF file, which can then be read and incorporated into a "document" or "publication" by an application such as a desktop publishing package. The intent of TIFF is to organize and codify existing practice with respect to the definition and usage of "desktop" digital data, not to blaze new paths or promote unproven techniques. Yet a very high priority has been given to structuring the data in such a way as to minimize the pain of future additions TIFF was designed to be a very extensible interchange format. TIFF is not a printer language or page definition language, nor is it intended to be a general document interchange standard. The primary design goal was to provide a rich environment within which the exchange of image data between application programs can be accomplished. TIFF does not support object oriented graphics or text; it is strictly designed for image data. TIFF assumes nothing about operating systems other than the operating system supports something like a "file", defined as a sequence of 8-bit bytes. The largest possible TIFF file is 2**32 bytes. 1) Conformance Many of the application programs that read the contents of TIFF image files will no support all of the features described in this document. In some cases, little more than the default options will be supported. It is up to each organization to determine the costs and benefits associated with different levels of conformity. Therefore, claims of conformity to this specification should be met with a certain amount of caution. 2) Structure In TIFF, individual fields are identified with a unique tag. This allows particular fields to be present or absent from the file as required by the application. Some TIFF files will have only a few fields in them; others will have many. Software that creates TIFF files should write out as many fields as it believes will be meaningful and useful (and no more). Software that read TIFF files should do the best it can with the fields that it finds there. There are three main parts to a TIFF file. First a short file header. Next a directory of all the fields in the file. Finally, data for the fields. Figure 1: TIFF file structure Header Directory Entry +-------------------+ +------------------+ 0  Byte Order  X  Tag  +-------------------+ +------------------+ 2  Version  X+2  Type  +-------------------+ +------------------+ 4  Offset  X+4   +--- of 0th ---+ +-- Length --+ 6  IFD    +-------------------+ +------------------+  X+8  Value Offset   +------------------+   V  IFD V +-------------------+ +------------------+ IFD  Entry Count   Value(s)  +-------------------+ +------------------+ +2  Directory Entry 0  +-------------------+ +14  Directory Entry 1  +-------------------+ +26  Directory Entry 1  +-------------------+ +38   +-------------------+ +2+  Offset  n*12+--- of next ---+  IFD  +-------------------+ 3) Header and Directory A TIFF file begins with a small amount of positionally defined data, containing the following information: Bytes 0-1: The first word of the file serves to specify the byte order used within the file. The currently defined values are: "II" (hex 4949) (Intel) "MM" (hex 4D4D) (Motorola) The "II" format byte order is LSB to MSB for both 16-bit and 32-bit integers. The "MM" format is the opposite. In both formats, strings are stored into sequential byte locations. Bytes 2-3: The second word of the file is the version number. This number shouldn't change. The current number is 42 (2A in hex). Bytes 4-7: This long word contains the offset (in bytes) of the first Image File Directory. The directory may be at any location in the file after the header but must begin on a word boundary. (The term "byte offset" is always used in this document to refer to a location wrt the beginning of the file.) Image File Directories (IFD): An IFD consists of a 2-byte count of the number of entries (i.e., the number of fields), followed by a sequence of 12-byte field entries, followed by the 4-byte offset of the next IFD (or 0 if none). Each 12-byte field entry has the following form: Bytes 0-1 contain the Tag for the field. Bytes 2-3 contain the field Type. Bytes 4-7 contain the length ("Count" might have been a better term) of the field. Bytes 8-11 contains either the file offset of the value for the field, or if the value will fit in 4 bytes, the value itself. Values are expected to begin on word boundaries. The entires in an IFD must be sorted in ascending order by Tag. The values to which directory entries point need not be in any particular order in the file. The length part is specified in terms of the data type. The true length of a value, in bytes, will be sizeof(Type)*length. The data types are defined as follows: 1=BYTE 8-bit unsigned integer. 2=ASCII 8-bit bytes for ASCII characters; the last byte must be 0. 3=SHORT 16-bit unsigned integer. 4=LONG 32-bit unsigned integer. 5=RATIONAL Two LONG's; the first represents the numerator of a fraction, the second the denominator. The value of the Length part of an ASCII field entry includes the null. If padding is necessary, the length does not include the pad byte. More than one valid type may exist for a given field. Be sure to check the type when reading a file. 4) Definitions The TIFF structure itself is not specific to imaging applications in any way. It is only the definitions of the fields themselves that jointly describe an image. Before we begin describing fields, a few image related definitions may be useful. An image is a rectangular array of pixels, each of which consists of one or more samples. With monochromatic data, we have one sample per pixel, and sample and pixel can be used interchangeably. Color data usually contains three samples per pixel, as in, for example, an RGB scheme. Each sample can be made up of one or more bits (bits per sample). 5) The Fields The following fields are defined in this version of TIFF. More will be added in future versions, if possible in such a way so as not to break old software that encounters a newer TIFF file. An attempt has been made to group related fields, although the grouping is necessarily somewhat arbitrary. The documentation for each field contains the name of the field (quite arbitrary, but convenient), the Tag value, the field Type, the Number of Values (N) expected (per IFD, in case of multiple subfiles), comments describing the field, and the default, in any. The default value is used if the field does not exist. General Descriptions Subfile Type Tag = 255 (FF) Type = SHORT N = 1 A general indication of the kind of data that is contained in this subfile. Currently defined values are: 1=full resolution image data -- ImageWidth, ImageLength, and StripOffsets are required fields; and 2=reduced resolution image data -- ImageWidth, ImageLength and StripOffsets are required fields. It is further assumed that a reduced image is a reduced version of the entire extent of the corresponding full resolution data. 3=Single page of a multi-page image. No default. Data Architecture ImageWidth Tag = 256 (100) Type = SHORT N = 1 The image's width, in pixels (X:horizontal). The number of columns in the image. No default. ImageLength Tag = 257 (101) Type = SHORT N = 1 The image's height in pixels (Y:vertical). RowsPerStrip Tag = 278 (116) Type = SHORT or LONG N = 1 The number of rows per strip. The image data is organized into strips for fast access to individual rows when the data is compressed (though this field is valid even when the data is not compressed). Default is 2**32 -1, which is effectively infinity. That is, entire image is in one strip. [StripsPerImage] N = 1 The number of strips per image. This value is not a field, since it can be computed from two other fields, but it is convenient to give it a name for use in description of other fields. StripsPerImage = (ImageLength + RowsPerStrip - 1)/RowsPerStrip, assuming integer arithmetic. StripOffsets Tag = 273 (111) Type = SHORT or LONG N = StripsPerImage for PlanarConfiguration equal to 1 = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 For each strip, the byte offset of that strip. The offset is specified with respect to the beginning of the TIFF file. This field is the only way for a reader to find the image data, and hence it must exist. No default StripByteCounts Tag = 279 (117) Type = LONG N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 For each strip, the number of bytes in that strip. No default. SamplesPerPixel Tag = 277 (115) Type = SHORT N = 1 The number of samples per pixel. Usually 1 for monochromatic data and 3 for color data (i.e. one sample for each of the color planes.) Default = 1. BitsPerSample Tag = 258 (102) Type = SHORT N = SamplesPerPixel Number of bits per sample. Default = 1. PlanarConfiguration Tag = 284 (11C) Type = SHORT N = 1 1 = the sample values for each pixel are stored contiguously, so that there is a single image plane. See PhotometricInterpretation to determine the order of samples within pixel data. 2 = the sample are stored in separate "sample planes." The values in StripOffsets and StripByteCounts are the arranged as a 2-dimensional array, with SamplesPerPixel rows and StripsPerImage columns. (All of the columns of row 0 are stored first, followed by the columns of row 1, and so on). PhotometricInterpretation describes the type of data that is stored in each sample plane. If SamplesPerPixel is 1, a PlanarConfiguration value of 1 is equivalent to a value of 2. No default. Compression Tag = 259 (103) Type = SHORT N = SamplesPerPixel for PlanarConfiguration equal to 1 or 2. 1 = No compression, but pack data into bytes as tightly as possible, with no unused bits except at the end of a row. See also FillOrder. 2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding. BitsPerSample must be 1. 3 = Facsimile-compatible CCITT Group 3, exactly as specified in "Standardization of Group 3 facsimile apparatus for document transmission," Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, page 16 through 31. 4 = Facsimile-compatible CCITT Group 3, exactly as specified in "Standardization of Group 3 facsimile apparatus for document transmission," Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, page 40 through 48. Data compression applies only to pixel data. All other TIFF information is unaffected. Default = 1 Group3Options Tag = 292 (124) Type = LONG N = 1 This field is made up of 32 flag bits. Unused bits are expected to be 0. Bit 0 is the low-order bit. It is probably unsafe to try to read the file if any bit of this field is set that you don't know the meaning of. Bit 0 is 1 for 2-dimensional coding (else 1-D is assumed). Bit 1 is 1 if uncompressed mode is used. Bit 2 is 1 if fill bits have been added as necessary before EOL codes such that EOL always ends on a byte boundary, thus ensuring an eol-sequence of a 1 byte preceded by a zero nibble: xxxx-0000 0000-0001 Default is 0, for basic 1 dimensional coding. FillOrder Tag = 266 (10A) Type = SHORT N = 1 The order of data values within a byte. 1 = most significant bits of the byte are filled first. That is, data values (or code words) are ordered from high order bit to low order bit within byte. 2 = lest significant bits are filled first. Default = 1. Thresholding Tag = 263 (107) Type = SHORT N = 1 1 = a bilevel "line art" scan. BitsPerSample must be 1. 2 = a "halftone" or "dithered" scan, usually of continous tone data such as photographs. BitsPerSample must be 1. 3 = Error Diffused. Default = 1. CellWidth Tag = 264 (108) Type = SHORT N = 1 The width, in 1-bit samples, of the dithering/halftoning matrix. Assumes Thresholding = 2 (only relevant if Thresholding = 2). No default. CellLength Tag = 265 (109) Type = SHORT N = 1 The length, in 1-bit samples, of the dithering/halftoning matrix. No default. Photometrics MinSampleValue Tag = 280 (118) Type = SHORT N = SamplesPerPixel The minimum valid sample value. Default = 0. MaxSampleValue Tag = 281 (119) Type = SHORT N = SamplesPerPixel The maximum valid sample value. Default = 2**(BitsPerSample)-1. PhotometricInterpretation Tag = 262 (106) Type = SHORT N = 1 0 = MinSampleValue should be imaged as white. MaxSampleValue should be imaged as black. 1 = MinSampleValue should be imaged as black. MaxSampelValues should be imaged as white. 2 = RGB. In the RGB model, a color is described as a combination of the three primary colors of light (red, green, and blue). MinSampleValue=minimum intensi ty, MaxSampleValue=maximum intensity. For PlanarConfiguration = 1, samples are stored as triplets of samples Red, Green, Blue. For PlanarConfiguration = 2, samples are stored in three planes, Red plane, Green plane, Blue plane. GrayResponseUnit Tag = 290 (122) Type = SHORT N = 1 1 = number represents tenths of a unit 2 = number represents hundredths of a unit 3 = number represents thousandths of a unit 4 = number represents ten-thousandths of a unit 5 = number represents hundred-thousandths of a unit Default = 2. GrayResponseCurve Tag = 291 (123) Type = SHORT N = 2**BitsPerSample The purpose of the gray response curve and the gray units is to further provide photometric interpretion information for gray scale image data. The gray response curve specifies for given levels of gray between the minimum and maximum sample values the actual photometric gray level of the value. It represents this gray level in terms of optical density. The GrayResponseUnit specifies the accuracy of the information contained in the curve. ColorResponseUnit Tag = 290 (122) Type = SHORT N = 1 1 = number represents tenths of a unit 2 = number represents hundredths of a unit 3 = number represents thousandths of a unit 4 = number represents ten-thousandths of a unit 5 = number represents hundred-thousandths of a unit Default = 2. ColorResponseCurve Tag = 291 (123) Type = SHORT N = 2**BitsPerSample (Red) + 2**BitsPerSample (Green) + 2**BitsPerSample (Blue) The three color intensity response curves for red, green and blue. The ColorResponseUnit specifies the accuracy of the information contained in the curve. XResolution Tag = 282 (11A) Type = RATIONAL N = 1 The number of pixels per ResolutionUnit (see below) in the X direction, i.e., in the ImageWidth direction. It is, of course, not mandatory that the image be actually printed at the size implied by this parameter. It is up to the application to use this information as it wishes. No default YResolution Tag = 283 (11B) Type = RATIONAL N = 1 The number of pixels per ResolutionUnit in the Y direction. No default. ResolutionUnit Tag = 296 (128) Type = SHORT N = 1 1 = no absolute unit of measurement. Used for images with non-square aspect ratios, but no meaningful dimensions. 2 = inch 3 = centimeter Default = 2. Orientation Tag = 274 (112) Type = SHORT N = 1 1 = The 0th row represents the visual top of image, 0th column is the left side 2 = 0th row on top, 0th column on right 3 = 0th row on bottom, 0th column on right 4 = 0th row on bottom, 0th column on left 5 = 0th row on left, 0th column on top 6 = 0th row on right, 0th column on top 7 = 0th row on right, 0th column on bottom 8 = 0th row on left, 0th column on bottom Default = 1.