13-Apr-89  7:06:02-GMT,19029;000000000001
Return-Path: <MMPR004%ECNCDC.BITNET@forsythe.stanford.edu>
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: <MMPR004%ECNCDC.BITNET@forsythe.stanford.edu>
Subject:  Tiff File Format
To: <info-mac@sumex-aim.stanford.edu>


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.



