Columbia Kermit/kermit.zip/mskermit/msgtif.txt

Text File | 2020-01-01 | 133KB | 3,721 lines

An Aldus/Microsoft Technical Memorandum:  8/8/88    Page 1

Preface

This memorandum     has been prepared jointly by Aldus and Microsoft
in conjunction    with leading scanner vendors and other interested
parties.   This document  does not  represent a commitment on the
part of     either Microsoft  or Aldus  to provide     support for this
file format  in any  application.   When responding  to     specific
issues raised  in this memo, or when requesting additional tag or
field assignments, please address your correspondence to either:

   Developers_ Desk        Windows Marketing Group
   Aldus Corporation        Microsoft Corporation
   411 First Ave. South        16011 NE 36th Way
   Suite 200            Box 97017
   Seattle, WA    98104        Redmond, WA     98073-9717
   [phone]        [phone]

Revision Notes

This revision  replaces _TIFF  Revision 4._   Sections in italics
are new or substantially changed in this revision.  Also new, but
not in italics, are Appendices F, G, and H.

The major enhancements in TIFF 5.0 are:

1.   Compression of  grayscale and  color images, for better disk
space utilization.  See Appendix F.

2.   TIFF Classes_restricted  TIFF subsets  that can simplify the
job of    the TIFF  implementor.     You may  wish to scan Appendix G
before reading the rest of this document.   In fact, you may want
to use    Appendix G as your main guide, and refer back to the main
body of     the specification  as needed for details concerning TIFF
structures and field definitions.

3.   Support for  _palette color_   images.  See the TIFF Class P
description  in      Appendix  G,     and  the   new     ColorMap   field
description.

4.   Two new  tags that     can be     used to  more fully  define  the
characteristics of  full color    RGB data, and thereby potentially
improve the quality of color image reproduction.  See Appendix H.

The organization  of the  document has also changed slightly.  In
particular, the     tags are  listed in  alphabetical order,  within
several categories, in the main body of the specification.

TIFF 5.0                      page 2


As always,  every attempt  has been  made to add functionality in
such a    way as    to minimize  incompatibility problems  with older
TIFF software.     In  particular, many  TIFF  5.0  files     will  be
readable even  by older     applications that  assume TIFF 4.0 or an
earlier version     of the     specification.      One exception     is  with
files that  use the  new TIFF  5.0 LZW    compression scheme.   Old
applications will  have to  give up  in this case, of course, and
will do so _gracefully_ if they have been following the rules.

We  are     grateful  to  all  of    the  draft  reviewers  for  their
suggestions.   Especially helpful  were Herb  Weiner  of  Kitchen
Wisdom    Publishing   Company,  Brad  Pillow  of     TrueVision,  and
engineers from Hewlett Packard and Quark.  Chris Sears of Magenta
Graphics provided information which is included as Appendix H.


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 possible that other
sorts of imaging applications may find TIFF to be useful.

The general  scenario 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.

TIFF is     not a printer language or page description 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.   This     richness is  required in  order to  take
advantage of  the varying  capabilities of  scanners and  similar
devices.  TIFF is therefore designed to be a superset of existing
image file  formats for     _desktop_   scanners (and paint programs
and anything  else that     produces images with pixels in them) and
will be enhanced on a continuing basis as new capabilities arise.
A 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 an extensible interchange format.

Although TIFF  is claimed  to be  in some sense a rich format, it
can easily  be used for simple scanners and applications as well,
since the  application developer  need only be concerned with the
capabilities that he requires.

TIFF is intended to be independent of specific operating systems,
filing systems,     compilers, and processors.  The only significant
assumption is  that the     storage medium supports something like a
_file,_      defined as  a sequence  of 8-bit bytes, where the bytes

TIFF 5.0                      page 3


are numbered  from 0  to N.   The  largest possible  TIFF file is
2**32 bytes  in length.      Since TIFF uses pointers (byte offsets)
quite liberally,  a TIFF  file is  most easily read from a random
access device  such as a hard disk or flexible diskette, although
it should  be possible    to read     and write TIFF files on magnetic
tape.

The recommended     MS-DOS, UNIX,    and OS/2  file extension for TIFF
files is  _.TIF._   The recommended Macintosh filetype is _TIFF_.
Suggestions for     conventions in     other computing environments are
welcome.


1) 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.  For an explanation of the rationale
behind using a tag structure format, see Appendix A.

A TIFF file begins with an 8-byte _image file header_ that points
to one    or  more  _image  file    directories._     The  image  file
directories contain  information about    the images,  as     well  as
pointers to the actual image data.

See Figure 1.

We will now describe these structures in more detail.

Image file header

A TIFF    file begins  with an 8-byte image file header, containing
the following information:

Bytes 0-1:     The first  word of  the file  specifies    the  byte
order used within the file.  Legal values are:

    _II_ (hex 4949)
    _MM_ (hex 4D4D)

   In the  _II_      format,  byte     order    is  always  from  least
significant to    most significant,  for    both  16-bit  and  32-bit
integers.   In the  _MM_   format, byte order is always from most
significant to    least significant,  for both  16-bit  and  32-bit
integers.   In both  formats, character     strings are  stored into
sequential byte locations.

   All    TIFF   readers    should    support     both  byte  orders_see
Appendix G.

Bytes 2-3 The second  word of  the  file  is  the  TIFF     _version
number._   This number, 42 (2A in hex), is not to be equated with
the current  Revision of  the TIFF  specification.   In fact, the
TIFF version  number (42)  has never  changed, and probably never

TIFF 5.0                      page 4


will.    If it  ever does,  it means that TIFF has changed in some
way so    radical that  a TIFF  reader should  give up immediately.
The number 42 was chosen for its deep philosophical significance.
It can and should be used as additional verification that this is
indeed a TIFF file.

   A TIFF  file does  not have    a real version/revision number.
This was  an explicit,    conscious design  decision.  In many file
formats, fields     take on different meanings depending on a single
version number.      The  problem is that as the file format _ages,_
it becomes  increasingly difficult  to document which fields mean
what in     a given  version, and older software usually has to give
up if  it encounters  a file  with a  newer version  number.   We
wanted TIFF  fields to have a permanent and well-defined meaning,
so that     _older_ software  can usually    read _newer_  TIFF files.
The bottom line is lower software release costs and more reliable
software.

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.
In particular,    an Image File Directory may follow the image data
it describes.    Readers must simply 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 file.
The first byte of the file has an offset of 0.)


Image file directory

An Image  File Directory  (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 a 4-byte offset of
the next  Image File  Directory (or 0 if none).     Do not forget to
write the 4 bytes of 0 after the last IFD.

Each 12-byte IFD entry has the following format:

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     contain the  Value Offset,  the    file  offset  (in
bytes) of  the Value  for the  field.    The Value  is expected to
begin on  a word  boundary; the     corresponding Value  Offset will
thus be     an even  number.  This file offset may point to anywhere
in the file, including after the image data.

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.   For a  numerically ordered list of tags, see

TIFF 5.0                      page 5


Appendix E.  The Values to which directory entries point need not
be in any particular order in the file.

In order  to save time and space, the Value Offset is interpreted
to contain  the Value  instead of  pointing to    the Value  if the
Value fits  into 4  bytes.  If the Value is less than 4 bytes, it
is left-justified within the 4-byte Value Offset, i.e., stored in
the lower-numbered bytes.  Whether or not the Value fits within 4
bytes is  determined by     looking at  the Type  and Length  of the
field.

The Length  is specified in terms of the data type, not the total
number of bytes.  A single 16-bit word (SHORT) has a Length of 1,
not 2,    for example.   The  data  types     and  their  lengths  are
described below:

1 = BYTE  An 8-bit unsigned integer.
2 = ASCII 8-bit bytes  that store ASCII codes; the last byte must
be null.
3 = SHORT A 16-bit (2-byte) unsigned integer.
4 = LONG  A 32-bit (4-byte) 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.   Note  that there  is no  _count byte,_ as there is in
Pascal-type strings.   The Length part of the field takes care of
that.    The null  is not  strictly necessary, but may make things
slightly simpler for C programmers.

The reader  should check  the type  to ensure  that it is what he
expects.   TIFF currently  allows more than 1 valid type for some
fields.      For example,    ImageWidth and ImageLength were specified
as having  type SHORT.    Very large images with more than 64K rows
or columns  are possible with some devices even now.  Rather than
add parallel  LONG tags     for these fields, it is cleaner to allow
both SHORT  and LONG  for ImageWidth  and similar  fields.    See
Appendix G for specific recommendations.

Note that  there may  be more  than one IFD.  Each IFD is said to
define a _subfile._   One potential use of subsequent subfiles is
to describe  a _sub-image_   that  is somehow related to the main
image, such as a reduced resolution version of the image.

If you have not already done so, you may wish to turn to Appendix
G to study the sample TIFF images.


2) Definitions

Note that the TIFF structure as described in the previous section
is not    specific to  imaging applications in any way.  It is only

TIFF 5.0                      page 6


the definitions of the fields themselves that jointly describe an
image.

Before we  begin defining  the fields,    we will define some basic
concepts.   An image  is defined  to be     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.     RGB  color  data
contains three samples per pixel.


3) The Fields

This section  describes the  fields defined  in this  version  of
TIFF.    More fields  may be  added in future versions_if possible
they will  be added in such a way so as not to break old software
that encounters a newer TIFF file.

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, comments describing the field,
and the     default, if  any.  Readers must assume the default value
if the field does not exist.

_No default_  does not    mean that  a TIFF  writer should  not pay
attention to  the tag.    It simply means that there is no default.
If the    writer has reason to believe that readers will care about
the value  of this  field, the writer should write the field with
the appropriate value.    TIFF readers can do whatever they want if
they encounter a missing _no default_ field that they care about,
short of  refusing to  import the file.     For example, if a writer
does  not  write  out  a  PhotometricInterpretation  field,  some
applications will  interpret the  image _correctly,_  and  others
will display  the image     inverted.  This is not a good situation,
and writers should be careful not to let it happen.

The  fields   are  grouped   into  several  categories:       basic,
informational, facsimile,  document storage and retrieval, and no
longer recommended.   A     future version     of the specification may
pull some of these categories into separate companion documents.

Many fields  are described  in this  document, but  most are  not
_required._   See Appendix  G for  a list  of required fields, as
well as     examples of  how to combine fields into valid and useful
TIFF files.
Basic Fields


Basic fields  are  fields  that     are  fundamental  to  the  pixel
architecture or visual characteristics of an image.

BitsPerSample
Tag  = 258  (102)
Type = SHORT

TIFF 5.0                      page 7


N    = SamplesPerPixel

Number of bits per sample.  Note that this tag allows a different
number of  bits per  sample for     each sample  corresponding to    a
pixel.     For example, RGB color data could use a different number
of bits     per sample for each of the three color planes.     Most RGB
files will have the same number of BitsPerSample for each sample.
Even in this case, be sure to include all three entries.  Writing
_8_ when you mean _8,8,8_ sets a bad precedent for other fields.

Default = 1.  See also SamplesPerPixel.


ColorMap
Tag  = 320 (140)
Type = SHORT
N    = 3 * (2**BitsPerSample)

This tag  defines a  Red-Green-Blue color  map for  palette color
images.      The palette color pixel value is used to index into all
3 subcurves.   For  example, a Palette color pixel having a value
of 0  would be    displayed according  to the 0th entry of the Red,
Green, and Blue subcurves.

The subcurves  are stored  sequentially.   The Red  entries  come
first, followed     by the     Green    entries,  followed  by    the  Blue
entries.   The length  of each    subcurve is  2**BitsPerSample.    A
ColorMap entry    for an    8-bit Palette color image would therefore
have 3    * 256  entries.      The width  of each entry is 16 bits, as
implied     by  the  type    of  SHORT.    0     represents  the  minimum
intensity, and    65535 represents the maximum intensity.     Black is
represented by    0,0,0, and  white by  65535, 65535,  65535.   The
purpose of  the color  map is to act as a _lookup_  table mapping
pixel values from 0 to 2**BitsPerSample-1 into RGB triplets.

The ColorResponseCurves     field may  be used  in conjunction  with
ColorMap to further refine the meaning of the RGB triplets in the
ColorMap.   However, the  ColorResponseCurves default  should  be
sufficient in most cases.

See also PhotometricInterpretation_palette color.

No default.   ColorMap    must be     included in  all  palette  color
images.


ColorResponseCurves
Tag  = 301 (12D)
Type = SHORT
N    = 3 * (2**BitsPerSample)

This tag  defines three     color response curves, one each for Red,
Green and  Blue color  information.   The Red entries come first,
followed by the Green entries, followed by the Blue entries.  The

TIFF 5.0                      page 8


length    of   each  subcurve   is  2**BitsPerSample,   using   the
BitsPerSample value corresponding to the respective primary.  The
width of  each entry is 16 bits, as implied by the type of SHORT.
0 represents  the minimum  intensity, and  65535  represents  the
maximum intensity.   Black  is represented by 0,0,0, and white by
65535, 65535,  65535.    Therefore, a ColorResponseCurve entry for
RGB data  where each of the samples is 8 bits deep would have 3 *
256 entries, each consisting of a SHORT.

The purpose of the color response curves is to refine the content
of RGB color images.

See Appendix H, section VII, for further information.

Default:  curves based on the NTSC recommended gamma of 2.2.


Compression
Tag  = 259  (103)
Type = SHORT
N    = 1

1 =  No compression,  but pack    data into  bytes  as  tightly  as
possible, with    no unused  bits except    at the end of a row.  The
bytes are  stored as  an array of type BYTE, for BitsPerSample <=
8,  SHORT   if    BitsPerSample    >  8  and  <=  16,  and     LONG  if
BitsPerSample >     16 and <= 32.    The byte ordering of data >8 bits
must be     consistent with  that specified  in the TIFF file header
(bytes 0  and 1).   _II_    format  files  will     have  the  least
significant bytes  preceeding the  most significant  bytes  while
_MM_  format files will have the opposite.

   If the  number of  bits per    sample is not a power of 2, and
you are willing to give up some space for better performance, you
may wish to use the next higher power of 2.  For example, if your
data can  be represented  in 6 bits, you may wish to specify that
it is 8 bits deep.

   Rows are  required to  begin on byte boundaries.  The number
of bytes  per row  is therefore     (ImageWidth *    SamplesPerPixel *
BitsPerSample  +   7)  /  8,  assuming    integer     arithmetic,  for
PlanarConfiguration=1.       Bytes  per    row  is      (ImageWidth    *
BitsPerSample + 7) / 8 for PlanarConfiguration=2.

   Some graphics  systems want rows to be word- or double-word-
aligned.   Uncompressed TIFF  rows will     need to  be copied  into
word- or  double-word-padded row  buffers before  being passed to
the graphics routines in these environments.

2 =  CCITT Group  3 1-Dimensional  Modified  Huffman  run  length
encoding.   See Appendix  B:   _Data Compression  --  Scheme  2._
BitsPerSample must  be 1,  since  this    type  of  compression  is
defined only for bilevel images.

TIFF 5.0                      page 9


   When     you  decompress  data    that  has  been     compressed  by
Compression=2, you  must translate  white runs into 0_s and black
runs into  1_s.      Therefore, the normal PhotometricInterpretation
for those  compression types  is 0  (WhiteIsZero).   If a  reader
encounters a  PhotometricInterpretation of  1  (BlackIsZero)  for
such an     image, the  image should  be displayed     and printed with
black and white reversed.

5 = LZW Compression,  for grayscale, mapped color, and full color
images.     See Appendix F.

32773 =     PackBits compression,    a simple byte oriented run length
scheme for 1-bit images.  See Appendix C.

Data compression only applies to raster image data, as pointed to
by StripOffsets.  All other TIFF information is unaffected.

Default = 1.


GrayResponseCurve
Tag  = 291 (123)
Type = SHORT
N    = 2**BitsPerSample

The purpose  of the  gray response curve and the gray units is to
provide more  exact photometric     interpretation     information  for
gray scale image data, in terms of optical density.

The  GrayScaleResponseUnits   specifies     the   accuracy     of   the
information contained  in the  curve.    Since optical  density is
specified in  terms of    fractional numbers, this tag is necessary
to know     how to     interpret the    stored integer    information.  For
example, if  GrayScaleResponseUnits is    set to 4 (ten-thousandths
of a  unit), and a GrayScaleResponseCurve number for gray level 4
is 3455,  then the  resulting actual  value is    0.3455.      Optical
densitometers typically measure densities within the range of 0.0
to 2.0.

If the    gray scale  response curve  is known  for the data in the
TIFF file, and if the gray scale response of the output device is
known, then  an intelligent  conversion can  be made  between the
input data and the output device.  For example, the output can be
made to     look just  like the  input.   In addition,  if the input
image lacks  contrast (as  can be  seen from the response curve),
then appropriate contrast enhancements can be made.

The purpose  of the  gray scale     response curve     is to    act as    a
_lookup_   table mapping values from 0 to 2**BitsPerSample-1 into
specific   density    values.       The     0th   element     of   the
GrayResponseCurve array     is used to define the gray value for all
pixels    having     a  value   of    0,   the  1st    element     of   the
GrayResponseCurve array     is used to define the gray value for all
pixels having  a value of 1, and so on, up to 2**BitsPerSample-1.

TIFF 5.0                      page 10


If your     data is  _really,_ say, 7-bit data, but you are adding a
1-bit pad  to each  pixel to  turn it into 8-bit data, everything
still works:   If  the data is high-order justified, half of your
GrayResponseCurve entries  (the odd ones, probably) will never be
used, but  that doesn_t     hurt anything.     If the data is low-order
justified, your     pixel values  will be between 0 and 127, so make
your GrayResponseCurve    accordingly.   What your  curve does from
128 to    255 doesnÆt matter.    Note that low-order justification is
probably not  a good  idea, however,  since not     all applications
look at GrayResponseCurve.  Note also that LZW compression yields
the same  compression ratio  regardless of  whether the     data  is
high-order or low-order justified.

It is  permissable to  have a  GrayResponseCurve even for bilevel
(1-bit) images.      The  GrayResponseCurve will  have 2 values.  It
should be noted, however, that TIFF B readers are not required to
pay attention  to  GrayResponseCurves  in  TIFF     B  files.    See
Appendix G.

If both     GrayResponseCurve and    PhotometricInterpretation  fields
exist  in   the     IFD,    GrayResponseCurve  values   override  the
PhotometricInterpretation value.   But it is a good idea to write
out both, since some applications do not yet pay attention to the
GrayResponseCurve.

Writers may  wish to  purchase a  Kodak Reflection Density Guide,
catalog number    146 5947,  available for  $10 or  so at     prepress
supply houses,    to help them figure out reasonable density values
for their scanner or frame grabber.  If that sounds like too much
work,    we    recommend      a    curve   that    is    linear    in
intensity/reflectance.    To compute reflectance from density:  R =
1 /  pow(10,D).      To compute  density from reflectance: D = log10
(1/R).     A typical  4-bit GrayResponseCurve  may  look    therefore
something like:      2000,     1177, 875, 699, 574, 477, 398, 331, 273,
222, 176,  135, 97, 62, 30, 0, assuming GrayResponseUnit=3.  Such
a curve would be consistent with PhotometricInterpretation=1.

See also GrayResponseUnit, PhotometricInterpretation, ColorMap.


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.

Modifies GrayResponseCurve.

See also GrayResponseCurve.

TIFF 5.0                      page 11



For historical    reasons, the  default is 2.  However, for greater
accuracy, we recommend using 3.


ImageLength
Tag  = 257  (101)
Type = SHORT or LONG
N    = 1

The image_s  length (height) in pixels (Y: vertical).  The number
of rows     (sometimes described as _scan lines") in the image.  See
also ImageWidth.

No default.


ImageWidth
Tag  = 256  (100)
Type = SHORT or LONG
N    = 1

The image_s  width, in    pixels (X:  horizontal).   The number  of
columns in the image.  See also ImageLength.

No default.


NewSubfileType
Tag =  254  (FE)
Type = LONG
N = 1

Replaces the  old SubfileType  field, due  to limitations  in the
definition of that field.

A general  indication of  the kind  of data  that is contained in
this subfile.    This  field is    made up of a set of 32 flag bits.
Unused bits are expected to be 0.  Bit 0 is the low-order bit.

Currently defined values are:

Bit 0      is 1    if the    image is  a reduced resolution version of
another image in this TIFF file; else the bit is 0.
Bit 1      is 1    if the    image is  a single  page of  a multi-page
image (see the PageNumber tag description); else the bit is 0.
Bit 2      is 1    if the    image defines  a  transparency    mask  for
another image  in this    TIFF file.  The PhotometricInterpretation
value must be 4, designating a transparency mask.

These values  have been     defined as  bit flags    because they  are
pretty much independent of each other.    For example, it be useful
to have     four images  in a  single TIFF     file: a  full resolution
image, a  reduced resolution  image, a    transparency mask for the

TIFF 5.0                      page 12


full resolution     image, and  a transparency  mask for the reduced
resolution image.  Each of the four images would have a different
value for the NewSubfileType field.

Default is 0.


PhotometricInterpretation
Tag  = 262  (106)
Type = SHORT
N    = 1

0 =  For bilevel  and grayscale     images:   0 is     imaged as white.
2**BitsPerSample-1 is  imaged as  black.    If    GrayResponseCurve
exists,     it   overrides     the   PhotometricInterpretation   value,
although  it  is  safer     to  make  them     match,     since    some  old
applications may still be ignoring GrayResponseCurve. This is the
normal value for Compression=2.

1 =  For bilevel  and grayscale     images:   0 is     imaged as black.
2**BitsPerSample-1  is    imaged    as  white.  If    GrayResponseCurve
exists,     it   overrides     the   PhotometricInterpretation   value,
although  it  is  safer     to  make  them     match,     since    some  old
applications may  still be  ignoring GrayResponseCurve.     If  this
value is  specified for     Compression=2, the  image should display
and print reversed.

2 = RGB.  In the RGB model, a color is described as a combination
of the    three primary  colors of  light (red, green, and blue) in
particular concentrations.   For  each of  the three  samples,    0
represents minimum intensity, and 2**BitsPerSample - 1 represents
maximum intensity.   Thus  an RGB  value  of  (0,0,0)  represents
black,    and   (255,255,255)  represents      white,  assuming  8-bit
samples.   For PlanarConfiguration = 1, the samples are stored in
the indicated  order:    first Red,  then Green,     then Blue.   For
PlanarConfiguration =  2, the  StripOffsets for the sample planes
are stored  in the  indicated order:   first the Red sample plane
StripOffsets, then  the Green  plane StripOffsets,  then the Blue
plane StripOffsets.

   The ColorResponseCurves field may be used to globally refine
or alter  the color  balance of     an RGB     image without    having to
change the values of the pixels themselves.

3="Palette color._     In this    mode, a color is described with a
single sample.     The  sample is     used as  an index into ColorMap.
The sample  is used to index into each of the red, green and blue
curve tables to retrieve an RGB triplet defining an actual color.
When this  PhotometricInterpretation value  is    used,  the  color
response curves     must also  be supplied.  SamplesPerPixel must be
1.

4 =  Transparency Mask.      This    means that  the image  is used to
define an  irregularly shaped region of another image in the same

TIFF 5.0                      page 13


TIFF  file.    SamplesPerPixel     and  BitsPerSample  must  be  1.
PackBits compression  is recommended.     The  1-bits  define  the
interior of  the region;  the 0-bits  define the  exterior of the
region.     The Transparency Mask must have the same ImageLength and
ImageWidth as the main image.

   A reader  application can  use the  mask to    determine which
parts of the image to display.    Main image pixels that correspond
to 1-bits  in the  transparency mask  are imaged to the screen or
printer, but  main image  pixels that correspond to 0-bits in the
mask are not displayed or printed.

   It is  possible to  generalize the  notion of a transparency
mask to     include partial  transparency, but  it is not clear that
such information would be useful to a desktop publishing program.

No default.   That  means that    if you    care  if  your    image  is
displayed and  printed as  _normal_ vs _inverted,_ you must write
out this  field.   Do not rely on applications defaulting to what
you want!   PhotometricInterpretation  =  1  is     recommended  for
bilevel (except     for Compression=2)  and grayscale images, due to
popular user  interfaces for changing the brightness and contrast
of images.


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 the samples
within the  pixel data.      So,  for RGB    data, the  data is stored
RGBRGBRGB...and so on.

2 =  The samples  are stored  in separate  _sample planes._   The
values in StripOffsets and StripByteCounts are then arranged as a
2-dimensional array, with SamplesPerPixel rows and StripsPerImage
columns.      (All of  the columns  for 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.     For example,  RGB data is stored
with the  Red samples  in one sample plane, the Green in another,
and the Blue in another.

If SamplesPerPixel  is 1,  PlanarConfiguration is irrelevant, and
should not be included.
Default is 1.  See also BitsPerSample, SamplesPerPixel.


Predictor
Tag  = 317 (13D)
Type = SHORT

TIFF 5.0                      page 14


N    = 1

To be used when Compression=5 (LZW).  See Appendix F.

1 = No prediction scheme used before coding.

Default is 1.


ResolutionUnit
Tag  = 296 (128)
Type = SHORT
N    = 1

To be used with XResolution and YResolution.

1 =  No absolute  unit of  measurement.     Used for images that may
have a    non-square  aspect  ratio,  but     no  meaningful     absolute
dimensions.   The drawback  of ResolutionUnit=1 is that different
applications will  import the  image at different sizes.  Even if
the decision  is quite    arbitrary, it might be better to use dots
per inch  or  dots  per     centimeter,  and  pick     XResolution  and
YResolution such that the aspect ratio is correct and the maximum
dimension of  the image is about four inches (the _four_ is quite
arbitrary.)
2 = Inch.
3 = Centimeter.

Default is 2.  See also XResolution, YResolution.


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  if the  data is not
compressed.

RowsPerStrip and  ImageLength together    tell  us  the  number  of
strips in  the entire  image.    The equation  is StripsPerImage =
(ImageLength + RowsPerStrip - 1) / RowsPerStrip, assuming integer
arithmetic.

Note that  either SHORT     or LONG  values can  be used  to specify
RowsPerStrip.    SHORT values  may be  used for    small TIFF files.
It should  be noted,  however, that  earlier  TIFF  specification
revisions required  LONG values     and that  some software  may not
expect SHORT values.  See Appendix G for further recommendations.

Default is  2**32 -  1, which  is effectively infinity.     That is,
the entire  image is  one strip.   We  do not  recommend a single

TIFF 5.0                      page 15


strip, however.      Choose  RowsPerStrip such  that each    strip  is
about 8K  bytes, even  if the  data is    not compressed,     since it
makes buffering     simpler for  readers.     The _8K_  part is pretty
arbitrary, but seems to work well.

See also ImageLength, StripOffsets, StripByteCounts.


SamplesPerPixel
Tag  = 277  (115)
Type = SHORT
N    = 1

The number  of samples    per pixel.    SamplesPerPixel  is  1  for
bilevel, grayscale, and palette color images.  SamplesPerPixel is
3 for RGB images.

Default = 1.  See also BitsPerSample, PhotometricInterpretation.


StripByteCounts
Tag  = 279  (117)
Type = SHORT or 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.  The existence
of  this   field  greatly   simplifies    the  chore  of    buffering
compressed data, if the strip size is reasonable.

No default.  See also StripOffsets, RowsPerStrip.


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.  Note
that this  implies that     each strip has a location independent of
the locations  of other     strips.   This feature may be useful for
editing applications.  This field is the only way for a reader to
find the image data, and hence must exist.

Note that  either SHORT or LONG values can be used to specify the
strip offsets.     SHORT    values    may be used for small TIFF files.
It should  be noted,  however, that  earlier TIFF  specifications
required LONG strip offsets and that some software may not expect
SHORT values.  See Appendix G for further recommendations.

TIFF 5.0                      page 16


No default.  See also StripByteCounts, RowsPerStrip.


XResolution
Tag  = 282  (11A)
Type = RATIONAL
N    = 1

The number of pixels per ResolutionUnit 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.  See also YResolution, ResolutionUnit.


YResolution
Tag  = 283  (11B)
Type = RATIONAL
N    = 1

The number of pixels per ResolutionUnit in the Y direction, i.e.,
in the ImageLength direction.

No default.  See also XResolution, ResolutionUnit.


Informational Fields


Informational  fields    are  fields   that  can      provide  useful
information to    a user,     such as where the image came from.  Most
are ASCII  fields.   An application could have some sort of _More
Info..._ dialog box to display such information.

Artist
Tag  = 315  (13B)
Type = ASCII

Person who created the image.

If you need to attach a Copyright notice to an image, this is the
place to  do it.  In fact, you may wish to write out the contents
of the field immediately after the 8-byte TIFF header.    Just make
sure your  IFD and field pointers are set accordingly, and you_re
all set.


DateTime
Tag  = 306  (132)
Type = ASCII
N    = 20

TIFF 5.0                      page 17


Date and  time of  image creation.   Use  the format  _YYYY:MM:DD
HH:MM:SS_, with hours on a 24-hour clock, and one space character
between the  date and  the time.    The     length     of  the  string,
including the null, is 20 bytes.


HostComputer
Tag  = 316  (13C)
Type = ASCII

_ENIAC_, or whatever.

See also Make, Model, Software.


ImageDescription
Tag  = 270 (10E)
Type = ASCII

For example,  a user  may wish    to attach a comment such as _1988
company picnic_ to an image.

It has    been suggested    that  this  is    what  the  newspaper  and
magazine industry calls a _slug._


Make
Tag  = 271  (10F)
Type = ASCII

Manufacturer of the scanner, video digitizer, or whatever.

See also Model, Software.


Model
Tag  = 272  (110)
Type = ASCII

The  model  name/number     of  the  scanner,  video  digitizer,  or
whatever.

This tag is intended for user information only.

See also Make, Software.


Software
Tag  = 305  (131)
Type = ASCII

Name and  release number of the software package that created the
image.

TIFF 5.0                      page 18


This tag is intended for user information only.

See also Make, Model.


Facsimile Fields


Facsimile fields  may be  useful if  you are  using TIFF to store
facsimile messages  in _raw_  form.  They are not recommended for
use in interchange with desktop publishing applications.

Compression (a basic tag)
Tag  = 259  (103)
Type = SHORT
N    = 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, pages  16 through  31.     Each strip  must
begin on  a byte  boundary.   (But recall  that an image can be a
single strip.)     Rows  that are     not the first row of a strip are
not required  to begin on a byte boundary.  The data is stored as
bytes,    not   words_byte-reversal  is    not  allowed.     See  the
Group3Options field for Group 3 options such as 1D vs 2D coding.

4 =  Facsimile-compatible CCITT     Group 4, exactly as specified in
_Facsimile Coding  Schemes and Coding Control Functions for Group
4 Facsimile Apparatus,_     Recommendation T.6, Volume VII, Fascicle
VII.3, Terminal     Equipment and    Protocols for Telematic Services,
The International  Telegraph and Telephone Consultative Committee
(CCITT), Geneva,  1985, pages  40 through  48.     Each strip  must
begin on  a byte  boundary.  Rows that are not the first row of a
strip are  not required to begin on a byte boundary.  The data is
stored as  bytes, not  words.    See the     Group4Options field  for
Group 4 options.


Group3Options
Tag  = 292  (124)
Type = LONG
N    = 1

See Compression=3.   This  field is  made up  of a set of 32 flag
bits.    Unused bits are expected to be 0.  Bit 0 is the low-order
bit.   It is probably not safe 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-dimensional is
assumed).   For 2-D  coding, if more than one strip is specified,
each strip  must begin    with a    1-dimensionally coded line.  That

TIFF 5.0                      page 19


is, RowsPerStrip  should be  a multiple     of  _Parameter     K_    as
documented in the CCITT specification.

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.    See  also
Compression.


Group4Options
Tag  =    293  (125)
Type = LONG
N    = 1

See Compression=4.   This  field is  made up  of a set of 32 flag
bits.    Unused bits are expected to be 0.  Bit 0 is the low-order
bit.   It is probably not safe to try to read the file if any bit
of this     field is  set that  you don_t know the meaning of.  Gray
scale and color coding schemes are under study, and will be added
when finalized.

For 2-D     coding, each  strip is     encoded as if it were a separate
image.     In particular, each strip begins on a byte boundary; and
the coding  for the first row of a strip is encoded independently
of the    previous row,  using horizontal codes, as if the previous
row is    entirely white.      Each strip ends with the 24-bit end-of-
facsimile block (EOFB).

Bit 0      is unused.
Bit 1      is 1 if uncompressed mode is used.

Default is  0, for  basic 2-dimensional     binary compression.  See
also Compression.


Document Storage and Retrieval Fields


These fields  may be  useful for  document storage  and retrieval
applications.    They are  not recommended  for use in interchange
with desktop publishing applications.

DocumentName
Tag  = 269  (10D)
Type = ASCII

The name of the document from which this image was scanned.

See also PageName.

TIFF 5.0                      page 20




PageName
Tag  = 285  (11D)
Type = ASCII

The name of the page from which this image was scanned.

See also DocumentName.

No default.

PageNumber
Tag  = 297  (129)
Type = SHORT
N    = 2

This tag is used to specify page numbers of a multiple page (e.g.
facsimile) document.   Two SHORT values are specified.    The first
value is the page number; the second value is the total number of
pages in the document.

Note that  pages need  not appear  in numerical order.    The first
page is 0 (zero).

No default.


XPosition
Tag  = 286  (11E)
Type = RATIONAL

The X  offset of  the left side of the image, with respect to the
left side of the page, in ResolutionUnits.

No default.  See also YPosition.


YPosition
Tag  = 287  (11F)
Type = RATIONAL

The Y  offset of the top of the image, with respect to the top of
the page, in ResolutionUnits.  In the TIFF coordinate scheme, the
positive Y  direction  is  down,  so  that  YPosition  is  always
positive.

No default.  See also XPosition.


No Longer Recommended

TIFF 5.0                      page 21


These fields  are not  recommended except  perhaps for local use.
They should  not be used for image interchange.     They have either
been superseded     by other fields, have been found to have serious
drawbacks, or are simply not as useful as once thought.     They may
be dropped entirely from a future revision of the specification.

CellLength
Tag  = 265  (109)
Type = SHORT
N    = 1

The length, in 1-bit samples, of the dithering/halftoning matrix.
Assumes that Threshholding = 2.

This field,  plus CellWidth  and Threshholding,     are  problematic
because they  cannot safely be used to reverse-engineer grayscale
image data  out of dithered/halftoned black-and-white data, which
is their  only plausible  purpose.  The only _right_ way to do it
is to  not bother  with anything  like these  fields, and instead
write  some  sophisticated  pattern-matching  software    that  can
handle screen  angles that  are not  multiples of 45 degrees, and
other such challenging dithered/halftoned data.

So we  do not  recommend trying     to convert dithered or halftoned
data into  grayscale data.   Dithered  and halftoned data require
careful treatment  to avoid  _stretch marks,_ but it can be done.
If you    want grayscale images, get them directly from the scanner
or frame grabber or whatever.

No default.  See also Threshholding.


CellWidth
Tag  = 264  (108)
Type = SHORT
N    = 1

The width, in 1-bit samples, of the dithering/halftoning matrix.

No default.   See  also Threshholding.      See  the  comments  for
CellLength.


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 a byte.
2 =  least significant    bits are  filled  first.    Since  little
interest has  been expressed  in least-significant  fill order to

TIFF 5.0                      page 22


date, and since it is easy and inexpensive for writers to reverse
bit order (use a 256-byte lookup table), we recommend FillOrder=2
for private (non-interchange) use only.

Default is FillOrder = 1.


FreeByteCounts
Tag  = 289  (121)
Type = LONG

For each  _free block_     in  the file, the number of bytes in the
block.

TIFF  readers    can  ignore  FreeOffsets  and  FreeByteCounts  if
present.

FreeOffsets and     FreeByteCounts do  not constitute a remapping of
the logical address space of the file.

Since this  information can  be generated  by scanning    the IFDs,
StripOffsets, and StripByteCounts, FreeByteCounts and FreeOffsets
are not needed.

In addition, it is not clear what should happen if FreeByteCounts
and FreeOffsets exist in more than one IFD.

See also FreeOffsets.


FreeOffsets
Tag  = 288  (120)
Type = LONG

For each _free block_  in the file, its byte offset.

See also FreeByteCounts.


MaxSampleValue
Tag  = 281  (119)
Type = SHORT
N    = SamplesPerPixel

The maximum  used sample  value.    For     example,  if  the  image
consists of  6-bit data     low-order-justified  into  8-bit  bytes,
MaxSampleValue will  be no  greater than 63. This is field is not
to be  used to    affect the  visual appearance  of the  image when
displayed.   Nor should     the values  of     this  field  affect  the
interpretation of  any other  field.    Use  it     for  statistical
purposes only.

Default is 2**(BitsPerSample) - 1.

TIFF 5.0                      page 23



MinSampleValue
Tag  = 280  (118)
Type = SHORT
N    = SamplesPerPixel

The minimum  used sample  value.  This field is not to be used to
affect the  visual appearance  of the  image when displayed.  See
the comments for MaxSampleValue.

Default is 0.


SubfileType
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 resolution  image is  a reduced     version  of  the  entire
extent of the corresponding full resolution data.
3 =  single page  of a    multi-page image  (see the PageNumber tag
description).

Note that several image types can be found in a single TIFF file,
with each subfile described by its own IFD.

No default.

Continued use  of this    field is not recommended.  Writers should
instead use the new and more general NewSubfileType field.


Orientation
Tag  = 274 (112)
Type = SHORT
N    = 1

1 =  The 0th  row represents the visual top of the image, and the
0th column represents the visual left hand side.
2 =  The 0th  row represents the visual top of the image, and the
0th column represents the visual right hand side.
3 =  The 0th  row represents  the visual bottom of the image, and
the 0th column represents the visual right hand side.
4 =  The 0th  row represents  the visual bottom of the image, and
the 0th column represents the visual left hand side.
5 =  The 0th  row represents  the visual  left hand  side of  the
image, and the 0th column represents the visual top.

TIFF 5.0                      page 24


6 =  The 0th  row represents  the visual  right hand  side of the
image, and the 0th column represents the visual top.
7 =  The 0th  row represents  the visual  right hand  side of the
image, and the 0th column represents the visual bottom.
8 =  The 0th  row represents  the visual  left hand  side of  the
image, and the 0th column represents the visual bottom.

Default is 1.

This field is recommended for private (non-interchange) use only.
It is extremely costly for most readers to perform image rotation
_on the     fly,_ i.e.,  when importing  and printing;  and users of
most  desktop  publishing  applications     do  not  expect  a  file
imported by the application to be altered permanently in any way.


Threshholding
Tag  = 263  (107)
Type = SHORT
N    = 1

1 = a bilevel _line art_  scan.     BitsPerSample must be 1.
2 =  a _dithered_   scan, usually of continuous tone data such as
photographs. BitsPerSample must be 1.
3 = Error Diffused.

Default is Threshholding = 1.  See also CellWidth, CellLength.
4) Private Fields

An organization     may wish to store information that is meaningful
to only that organization in a TIFF file.  Tags numbered 32768 or
higher    are  reserved  for  that  purpose.    Upon  request,  the
administrator will  allocate and register a block of private tags
for an    organization, to  avoid     possible  conflicts  with  other
organizations.     Tags are  normally allocated  in blocks of five.
If that is not enough, feel free to ask for more. You do not need
to tell     the TIFF administrator or anyone else what you are going
to use them for.

Private enumerated  values  can     be  accommodated  in  a  similar
fashion.   For example,     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  a    block  of
enumerated values  for a  particular field  (Compression, in  our
example), to avoid possible conflicts.

Tags and  values which    are allocated in the private number range
are not     prohibited from  being included  in a future revision of
this specification.   Several  such instances can be found in the
TIFF specification.

Do not    choose your  own tag  numbers.    If you do, it could cause
serious problems some day.

TIFF 5.0                      page 25




5) Image File Format Issues

In the    quest to  give users no reason NOT to buy a product, some
scanning and  image editing  applications overwhelm users with an
incredible number  of _Save  As..._ options.  Let_s get rid of as
many of     these as  we possibly    can.   For example, a single TIFF
choice should  suffice once most major readers are supporting the
three TIFF compression schemes; then writers can always compress.
And given  TIFF_s flexibility,    including private  tag and  image
editing     support   features,  there  does  not    seem  to  be  any
legitimate reason  for continuing  to  write  image  files  using
proprietary formats.

Along the  same lines,    there is no excuse for making a user have
to know     the file  format of  a file  that is  to be  read by  an
application program.   TIFF  files, as    well as     most other  file
formats, contain  sufficient information  to enable  software  to
automatically and  reliably distinguish     one type  of  file  from
another.


6) For Further Information

Contact the  Aldus Developers_ Desk for sample TIFF files, source
code fragments,     and  a     list  of  features  that  are    currently
supported in  Aldus products.    The Aldus Developers_ Desk is the
current _TIFF administrator._

Various TIFF  related  aids  are  found     in  Microsoft_s  Windows
Developers Tookit for developers writing Windows applications.

Finally, a  number of  scanner vendors are providing various TIFF
services, such    as helping  to distribute  the TIFF specification
and answering  TIFF questions.     Contact  the appropriate product
manager or developer support service group.

TIFF 5.0                      page 26


Appendix A:  Tag Structure Rationale


A file    format is  defined by  both form (structure) and content.
The content of TIFF consists of definitions of individual fields.
It is therefore the content that we are ultimately interested in.
The structure  merely tells  us how  to find the fields.  Yet the
structure deserves  serious consideration for a number of reasons
that are not at all obvious at first glance.  Since the structure
described  herein   departs  significantly   from  several  other
approaches, it may be useful to discuss the rationale behind it.

The simplest,  most straightforward  structure for something like
an image  file is  a positional     format.  In a positional scheme,
the location  of the  data defines  what the  data  means.    For
example, the  field for     _number of  rows_ might  begin     at  byte
offset 30 in the image file.

This approach  is simple and easy to implement and is perfect for
static environments.   But  if a  significant amount  of  ongoing
change must  be accommodated,  subtle problems    begin to  appear.
For example,  suppose that  a field  must be superseded by a new,
more general  field.  You could bump a version number to flag the
change.      Then    new  software  has  no    problem     doing    something
sensible with  old data, and all old software will reject the new
data, even  software that  didn_t care about the old field.  This
may seem like no more than a minor annoyance at first glance, but
causing old  software to  break more  often than  it would really
need to     can be very costly and, inevitably, causes much gnashing
of teeth among customers.

Furthermore, it     can be     avoided.   One approach  is to     store    a
_valid_ flag  bit for each field.  Now you don_t have to bump the
version number,     as long  as you  can put the new field somewhere
that doesn_t  disturb any  of the  old fields.    Old software that
didn_t care about that old field anyway can continue to function.
(Old software  that did     care will of course have to give up, but
this is an unavoidable price to be paid for the sake of progress,
barring total omniscience.)

Another problem     that crops  up frequently is that certain fields
are likely  to make  sense only     if  other  fields  have  certain
values.      This is not such a serious problem in practice; it just
makes things  more confusing.    Nevertheless,  we note    that  the
_valid_ flag bits described in the previous paragraph can help to
clarify the situation.

Field-dumping  programs      can  be  very     helpful  for  diagnostic
purposes.   A desirable     characteristic of such a program is that
it doesn_t  have to  know much    about what  it is  dumping.    In
particular, it would be nice if the program could dump ASCII data
in ASCII  format, integer  data in  integer format,  and  so  on,
without having    to teach  the program  about new  fields all  the
time.    So maybe  we should  add a  _data type_     component to our

TIFF 5.0                      page 27


fields, plus  information on  how long    the field is, so that our
dump program can walk through the fields without knowing what the
fields _mean."

But note  that if we add one more component to each field, namely
a tag  that tells  what the field means, we can dispense with the
_valid_ flag  bits, and     we can     also avoid  wasting space on the
non-valid fields in the file.  Simple image creation applications
can write out several fields and be done.

We have     now derived  the essentials  of a  tag-based image  file
format.

Finally, a  caveat.  A tag based scheme cannot guarantee painless
growth.      But is  does provide    a useful  tool to  assist in  the
process.

TIFF 5.0                      page 28


Appendix B:  Data Compression_Scheme 2


Abstract

This document  describes a  method for    compressing bilevel  data
that is     based on  the CCITT  Group 3  1D  facsimile  compression
scheme.


References

1.   _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, pages 16 through 31.
2.   _Facsimile Coding    Schemes and  Coding Control Functions for
Group 4     Facsimile Apparatus,_    Recommendation T.6,  Volume  VII,
Fascicle VII.3,     Terminal Equipment  and Protocols  for Telematic
Services, The  International Telegraph and Telephone Consultative
Committee (CCITT), Geneva, 1985, pages 40 through 48.

We do  not believe that these documents are necessary in order to
implement Compression=2.   We  have included  (verbatim     in  most
places) all the pertinent information in this Appendix.     However,
if you    wish to     order the  documents, you  can     write    to  ANSI,
Attention: Sales,  1430 Broadway, New York, N.Y., 10018.  Ask for
the publication     listed above_it contains both Recommendation T.4
and T.6.


Relationship to the CCITT Specifications

The  CCITT   Group  3    and  Group   4    specifications     describe
communications protocols for a particular class of devices.  They
are not     by themselves sufficient to describe a disk data format.
Fortunately, however,  the CCITT  coding schemes  can be  readily
adapted to this different environment.    The following is one such
adaptation.   Most of  the language  is copied    directly from the
CCITT specifications.


Coding Scheme

A line    (row) of  data is composed of a series of variable length
code words.  Each code word represents a run length of either all
white or  all black.   (Actually,  more than one code word may be
required to  code a  given run,     in a  manner  described  below.)
White runs and black runs alternate.

In order  to ensure  that the  receiver (decompressor)    maintains
color synchronization, all data lines will begin with a white run
length code  word set.     If  the actual     scan line  begins with a

TIFF 5.0                      page 29


black run,  a white  run length     of zero  will be sent (written).
Black or  white run  lengths are  defined by  the code    words  in
Tables 1  and 2.   The    code words are of two types:  Terminating
code  words   and  Make-up  code  words.    Each  run  length  is
represented by    zero or     more  Make-up    code  words  followed  by
exactly one Terminating code word.

Run lengths  in the  range of  0 to  63 pels (pixels) are encoded
with their appropriate Terminating code word.  Note that there is
a different list of code words for black and white run lengths.

Run lengths in the range of 64 to 2623 (2560+63) pels are encoded
first by  the Make-up  code word representing the run length that
is nearest  to, not  longer than,  that required.   This  is then
followed by the Terminating code word representing the difference
between the required run length and the run length represented by
the Make-up code.

Run lengths  in the range of lengths longer than or equal to 2624
pels are  coded first  by the  Make-up code  of     2560.      If  the
remaining part    of the run (after the first Make-up code of 2560)
is 2560     pels or  greater, additional Make-up code(s) of 2560 are
issued until the remaining part of the run becomes less than 2560
pels.    Then  the  remaining  part  of    the  run  is  encoded  by
Terminating code  or  by  Make-up  code     plus  Terminating  code,
according to the range mentioned above.

It is  considered an  unrecoverable error  if the  sum of the run
lengths for  a line  does not  equal the  value of the ImageWidth
field.

New rows always begin on the next available byte boundary.

No EOL    code words  are used.    No fill bits are used, except for
the ignored  bits at  the end  of the last byte of a row.  RTC is
not used.


Table 1/T.4  Terminating codes


White           Black
run Code  run Code
length      word length     word
----     ---- ------    ----

0   00110101   0   0000110111
1   000111     1   010
2   0111  2   11
3   1000  3   10
4   1011  4   011
5   1100  5   0011
6   1110  6   0010
7   1111  7   00011

TIFF 5.0                      page 30


8   10011      8   000101
9   10100      9   000100
10   00111     10   0000100
11   01000     11   0000101
12   001000    12   0000111
13   000011    13   00000100
14   110100    14   00000111
15   110101    15   000011000
16   101010    16   0000010111
17   101011    17   0000011000
18   0100111   18   0000001000
19   0001100   19   00001100111
20   0001000   20   00001101000
21   0010111   21   00001101100
22   0000011   22   00000110111
23   0000100   23   00000101000
24   0101000   24   00000010111
25   0101011   25   00000011000
26   0010011   26   000011001010
27   0100100   27   000011001011
28   0011000   28   000011001100
29   00000010  29   000011001101
30   00000011  30   000001101000
31   00011010  31   000001101001
32   00011011  32   000001101010
33   00010010  33   000001101011
34   00010011  34   000011010010
35   00010100  35   000011010011
36   00010101  36   000011010100
37   00010110  37   000011010101
38   00010111  38   000011010110
39   00101000  39   000011010111
40   00101001  40   000001101100
41   00101010  41   000001101101
42   00101011  42   000011011010
43   00101100  43   000011011011
44   00101101  44   000001010100
45   00000100  45   000001010101
46   00000101  46   000001010110
47   00001010  47   000001010111
48   00001011  48   000001100100
49   01010010  49   000001100101
50   01010011  50   000001010010
51   01010100  51   000001010011
52   01010101  52   000000100100
53   00100100  53   000000110111
54   00100101  54   000000111000
55   01011000  55   000000100111
56   01011001  56   000000101000
57   01011010  57   000001011000
58   01011011  58   000001011001
59   01001010  59   000000101011
60   01001011  60   000000101100
61   00110010  61   000001011010

TIFF 5.0                      page 31


62   00110011  62   000001100110
63   00110100  63   000001100111




Table 2/T.4  Make-up codes

White           Black
run Code  run Code
length      word        length    word
------      ---- ------     ----

64 11011       64 0000001111
128 10010      128 000011001000
192 010111     192 000011001001
256 0110111    256 000001011011
320 00110110   320 000000110011
384 00110111   384 000000110100
448 01100100   448 000000110101
512 01100101   512 0000001101100
576 01101000   576 0000001101101
640 01100111   640 0000001001010
704 011001100  704 0000001001011
768 011001101  768 0000001001100
832 011010010  832 0000001001101
896 011010011  896 0000001110010
960 011010100  960 0000001110011
1024 011010101 1024 0000001110100
1088 011010110 1088 0000001110101
1152 011010111 1152 0000001110110
1216 011011000 1216 0000001110111
1280 011011001 1280 0000001010010
1344 011011010 1344 0000001010011
1408 011011011 1408 0000001010100
1472 010011000 1472 0000001010101
1536 010011001 1536 0000001011010
1600 010011010 1600 0000001011011
1664 011000    1664 0000001100100
1728 010011011 1728 0000001100101
EOL 000000000001    EOL 000000000001




Additional make-up codes

White
and
Black      Make-up
run  code
length      word
------      ----

TIFF 5.0                      page 32


1792 00000001000
1856 00000001100
1920 00000001101
1984 000000010010
2048 000000010011
2112 000000010100
2176 000000010101
2240 000000010110
2304 000000010111
2368 000000011100
2432 000000011101
2496 000000011110
2560 000000011111

TIFF 5.0                      page 33


Appendix C: Data Compression_Scheme 32773_
_PackBits_


Abstract

This document  describes a  simple compression scheme for bilevel
scanned and paint type files.


Motivation

The TIFF  specification defines     a number of compression schemes.
Compression type  1 is    really no  compression, other  than basic
pixel  packing.        Compression      type    2,   based  on    CCITT  1D
compression,  is   powerful,  but   not     trivial   to  implement.
Compression type  5 is    typically very effective for most bilevel
images, as  well as  many deeper images such as palette color and
grayscale images, but is also not trivial to implement.     PackBits
is a simple but often effective alternative.


Description

Several good schemes were already in use in various settings.  We
somewhat arbitrarily picked the Macintosh PackBits scheme.  It is
byte oriented,    so there  is no problem with word alignment.  And
it has a good worst case behavior (at most 1 extra byte for every
128 input  bytes).    For  Macintosh  users,  there  are  toolbox
utilities PackBits  and UnPackBits that will do the work for you,
but it is easy to implement your own routines.

A pseudo code fragment to unpack might look like this:

Loop  until  you  get  the  number  of    unpacked  bytes     you  are
expecting:
   Read the next source byte into n.
   If n is between 0 and 127 inclusive, copy the next n+1 bytes
literally.
   Else if  n is  between -127    and -1 inclusive, copy the next
byte -n+1 times.
   Else if n is 128, noop.
Endloop

In the    inverse routine,  it_s best to encode a 2-byte repeat run
as a replicate run except when preceded and followed by a literal
run, in     which case it_s best to merge the three into one literal
run.  Always encode 3-byte repeats as replicate runs.

So that_s the algorithm.  Here are some other rules:

╤    Each row  must be packed separately.  Do not compress across
row boundaries.

TIFF 5.0                      page 34


╤    The number  of uncompressed  bytes per    row is defined to be
(ImageWidth +  7) / 8.    If the uncompressed bitmap is required to
have an     even number  of bytes    per row,  decompress  into  word-
aligned buffers.
╤    If a  run is  larger  than  128     bytes,     simply     encode     the
remainder of the run as one or more additional replicate runs.

When  PackBits     data  is  uncompressed,  the  result  should  be
interpreted as per compression type 1 (no compression).

TIFF 5.0                      page 35


Appendix D


Appendix D  has been  deleted.     It formerly contained guidelines
for passing  TIFF files on the Microsoft Windows Clipboard.  This
was judged to not be a good idea, in light of the ever-increasing
size of     scanned images.   Applications are instead encouraged to
employ file-based  mechanisms to  exchange  TIFF  data.       Aldus_
PageMaker, for    example, implements  a _File  Place_  command  to
allow TIFF files to be imported.

TIFF 5.0                      page 36


Appendix E:  Numerical List of TIFF Tags


NewSubfileType
Tag  =    254  (FE)
Type = LONG
N    = 1

SubfileType
Tag  = 255  (FF)
Type = SHORT
N    = 1

ImageWidth
Tag  = 256  (100)
Type = SHORT or LONG
N    = 1

ImageLength
Tag  = 257  (101)
Type = SHORT or LONG
N    = 1

BitsPerSample
Tag  = 258  (102)
Type = SHORT
N    = SamplesPerPixel

Compression
Tag  = 259  (103)
Type = SHORT
N    = 1

PhotometricInterpretation
Tag  = 262  (106)
Type = SHORT
N    = 1


Threshholding
Tag  = 263  (107)
Type = SHORT
N    = 1

CellWidth
Tag  = 264  (108)
Type = SHORT
N    = 1

CellLength
Tag  = 265  (109)
Type = SHORT
N    = 1

TIFF 5.0                      page 37


FillOrder
Tag  = 266  (10A)
Type = SHORT
N    = 1

DocumentName
Tag  = 269  (10D)
Type = ASCII

ImageDescription
Tag  = 270 (10E)
Type = ASCII

Make
Tag  = 271  (10F)
Type = ASCII

Model
Tag  = 272  (110)
Type = ASCII

StripOffsets
Tag  = 273  (111)
Type = SHORT or LONG
N    = StripsPerImage for PlanarConfiguration equal to 1.
   = SamplesPerPixel  * StripsPerImage    for PlanarConfiguration
equal to 2

Orientation
Tag  = 274 (112)
Type = SHORT
N    = 1

SamplesPerPixel
Tag  = 277  (115)
Type = SHORT
N    = 1

RowsPerStrip
Tag  = 278  (116)
Type = SHORT or LONG
N    = 1

StripByteCounts
Tag  = 279  (117)
Type = LONG or SHORT
N    = StripsPerImage for PlanarConfiguration equal to 1.
   = SamplesPerPixel  * StripsPerImage    for PlanarConfiguration
equal to 2.

MinSampleValue
Tag  = 280  (118)
Type = SHORT
N    = SamplesPerPixel

TIFF 5.0                      page 38



MaxSampleValue
Tag  = 281  (119)
Type = SHORT
N    = SamplesPerPixel

XResolution
Tag  = 282  (11A)
Type = RATIONAL
N    = 1

YResolution
Tag  = 283  (11B)
Type = RATIONAL
N    = 1

PlanarConfiguration
Tag  = 284  (11C)
Type = SHORT
N    = 1

PageName
Tag  = 285  (11D)
Type = ASCII


XPosition
Tag  = 286  (11E)
Type = RATIONAL

YPosition
Tag  = 287  (11F)
Type = RATIONAL

FreeOffsets
Tag  = 288  (120)
Type = LONG

FreeByteCounts
Tag  = 289  (121)
Type = LONG

GrayResponseUnit
Tag  = 290 (122)
Type = SHORT
N    = 1

GrayResponseCurve
Tag  = 291 (123)
Type = SHORT
N    = 2**BitsPerSample

Group3Options
Tag  = 292  (124)

TIFF 5.0                      page 39


Type = LONG
N    = 1

Group4Options
Tag  =    293  (125)
Type = LONG
N    = 1

ResolutionUnit
Tag  = 296 (128)
Type = SHORT
N    = 1

PageNumber
Tag  = 297  (129)
Type = SHORT
N    = 2

ColorResponseCurves
Tag  = 301 (12D)
Type = SHORT
N    = 3 * (2**BitsPerSample)

Software
Tag  = 305  (131)
Type = ASCII

DateTime
Tag  = 306  (132)
Type = ASCII
N    = 20

Artist
Tag  = 315  (13B)
Type = ASCII

HostComputer
Tag  = 316  (13C)
Type = ASCII

Predictor
Tag  = 317 (13D)
Type = SHORT
N    = 1

WhitePoint
Tag  = 318 (13E)
Type = RATIONAL
N    = 2

PrimaryChromaticities
Tag  = 319 (13F)
Type = RATIONAL
N    = 6

TIFF 5.0                      page 40



ColorMap
Tag  = 320 (140)
Type = SHORT
N    = 3 * (2**BitsPerSample)

TIFF 5.0                      page 41


Appendix F:  Data Compression_Scheme 5_LZW
Compression


Abstract

This document describes an adaptive compression scheme for raster
images.


Reference

Terry  A.   Welch,  _A     Technique  for      High    Performance  Data
Compression_,  IEEE   Computer,     vol.    17  no.     6  (June  1984).
Describes the  basic Lempel-Ziv     & Welch  (LZW) algorithm.    The
author_s goal  in the  article is  to describe    a  hardware-based
compressor that could be built into a disk controller or database
engine, and  used on  all types     of data.   There  is no specific
discussion of  raster images.     We  intend  to     give  sufficient
information in    this Appendix so that the article is not required
reading.


Requirements

A compression  scheme with  the following  characteristics should
work well in a desktop publishing environment:

╤    Must work well for images of any bit depth, including images
deeper than 8 bits per sample.
╤    Must be effective:  an average compression ratio of at least
2:1 or    better.       And    it  must  have    a  reasonable  worst-case
behavior, in case something really strange is thrown at it.
╤    Should    not  depend  on     small    variations  between  pixels.
Palette color  images tend  to contain    abrupt changes    in  index
values, due to common patterning and dithering techniques.  These
abrupt changes    do tend to be repetitive, however, and the scheme
should make use of this fact.
╤    For images  generated by  paint programs,  the scheme should
not depend on a particular pattern width.  8x8 pixel patterns are
common now, but we should not assume that this situation will not
change.
╤    Must be     fast.     It should  not take  more than 5 seconds to
decompress a  100K byte     grayscale image on a 68020- or 386-based
computer.   Compression can  be slower,     but probably not by more
than a factor of 2 or 3.
╤    The level  of implementation  complexity must be reasonable.
We would like something that can be implemented in no more than a
couple of  weeks  by  a_competent  software  engineer  with  some
experience  in     image    processing.    The   compiled    code  for
compression and     decompression combined     should be  no more  than
about 10K.
╤    Does not require floating point software or hardware.

TIFF 5.0                      page 42



The following  sections describe  an algorithm based on the _LZW_
(Lempel-Ziv & Welch) technique that meets the above requirements.
In addition  meeting our  requirements,     LZW  has  the    following
characteristics:

╤    LZW is fully reversible.  All information is preserved.     But
if noise  or information  is removed  from an  image, perhaps  by
smoothing or  zeroing some  low-order bitplanes,  LZW  compresses
images to  a smaller  size.   Thus,   5-bit, 6-bit, or 7-bit data
masquerading as     8-bit data  compresses better    than  true  8-bit
data. Smooth  images also  compress better than noisy images, and
simple images compress better than complex images.
φ    On a  68082- or     386-based computer,  LZW  software  can  be
written to  compress at     between 30K  and 80K  bytes per  second,
depending on image characteristics.  LZW decompression speeds are
typically about 50K bytes per second.
φ    LZW works  well on  bilevel images,  too.   It always  beats
PackBits,  and     generally  ties   CCITT  1D  (Modified     Huffman)
compression, on our test images.  Tying CCITT 1D is impressive in
that LZW  seems to be considerably faster than CCITT 1D, at least
in our implementation.
φ    Our implementation is written in C, and compiles to about 2K
bytes of object code each for the compressor and decompressor.
φ    One of    the nice  things about    LZW is that it is used quite
widely in  other applications  such as    archival programs, and is
therefore more of a known quantity.


The Algorithm

Each strip  is compressed  independently.   We strongly recommend
that RowsPerStrip  be chosen  such that each strip contains about
8K bytes  before compression.    We  want to keep the strips small
enough so  that the  compressed and  uncompressed versions of the
strip can  be kept entirely in memory even on small machines, but
large enough to maintain nearly optimal compression ratios.

The LZW     algorithm is  based on     a translation    table, or  string
table, that  maps strings  of input  characters into  codes.  The
TIFF implementation  uses variable-length  codes, with    a maximum
code length of 12 bits.     This string table is different for every
strip, and,  remarkably, does  not need to be kept around for the
decompressor.      The  trick   is  to    make   the   decompressor
automatically build  the same  table as is built when compressing
the data.   We    use a  C-like pseudocode  to describe  the coding
scheme:

   InitializeStringTable();
   WriteCode(ClearCode);
   _ = the empty string;
   for each character in the strip {
    K = GetNextCharacter();
    if _+K is in the string table {

TIFF 5.0                      page 43


         _ = _+K;  /* string concatenation */
    } else {
         WriteCode (CodeFromString(_));
         AddTableEntry(_+K);
         _ = K;
    }
   } /* end of for loop */
   WriteCode (CodeFromString(_));
   WriteCode (EndOfInformation);

That_s    it.    The  scheme  is    simple,     although  it  is  fairly
challenging  to     implement  efficiently.    But     we  need  a  few
explanations before we go on to decompression.

The  _characters_   that  make    up  the     LZW  strings  are  bytes
containing TIFF     uncompressed (Compression=1)  image data, in our
implementation.      For example,    if BitsPerSample is 4, each 8-bit
LZW character will contain two 4-bit pixels.  If BitsPerSample is
16, each 16-bit pixel will span two 8-bit LZW characters.

(It is    also possible to implement a version of LZW where the LZW
character depth equals BitsPerSample, as was described by Draft 2
of Revision  5.0.   But     there    is  a  major  problem  with  this
approach.   If BitsPerSample  is greater  than 11, we can not use
12-bit-maximum    codes,     so  that  the    resulting  LZW    table  is
unacceptably large.   Fortunately,  due to the adaptive nature of
LZW, we     do not     pay a    significant compression ratio penalty for
combining several  pixels into    one byte before compressing.  For
example, our  4-bit sample  images  compressed    about  3  percent
worse, and  our 1-bit  images compressed  about 5 percent better.
And it    is easier to write an LZW compressor that always uses the
same character    depth than  it is  to write  one which can handle
varying depths.)

We can    now describe  some of the routine and variable references
in our pseudocode:

InitializeStringTable() initializes  the string     table to contain
all possible  single-character strings.      There     are 256 of them,
numbered 0 through 255, since our characters are bytes.

WriteCode() writes  a code  to the output stream.  The first code
written is a Clear code, which is defined to be code #256.

_ is our _prefix string._

GetNextCharacter() retrieves  the next    character value     from the
input stream.    This  will be number between 0 and 255, since our
characters are bytes.

The _+_ signs indicate string concatenation.

AddTableEntry() adds a table entry.  (InitializeStringTable() has
already put  256 entries  in our table.     Each entry consists of a

TIFF 5.0                      page 44


single-character string, and its associated code value, which is,
in our    application, identical to the character itself.     That is,
the 0th     entry in  our table  consists of  the string  <0>,  with
corresponding code  value of  <0>, the    1st entry  in  the  table
consists of the string <1>, with corresponding code value of <1>,
..., and  the 255th  entry in  our table  consists of  the string
<255>, with  corresponding code     value of  <255>.)   So the first
entry that  we add  to our  string table will be at position 256,
right?     Well, not  quite, since  we will reserve code #256 for a
special      _Clear_   code,   and      code     #257    for   a      special
_EndOfInformation_ code     that we will write out at the end of the
strip.    So the first multiple-character entry added to the string
table will be at position 258.

Let_s try  an example.     Suppose  we have  input data  that looks
like:

Pixel 0:  <7>
Pixel 1:  <7>
Pixel 2:  <7>
Pixel 3:  <8>
Pixel 4:  <8>
Pixel 5:  <7>
Pixel 6:  <7>
Pixel 7:  <6>
Pixel 8:  <6>

First, we read Pixel 0 into K.    _K is then simply <7>, since _ is
the empty string at this point.     Is the string <7> already in the
string table?  Of course, since all single character strings were
put in    the table  by InitializeStringTable().    So set _ equal to
<7>, and go to the top of the loop.

Read Pixel 1 into K.  Does _K (<7><7>) exist in the string table?
No, so we get to do some real work.  We write the code associated
with _    to output  (write <7>  to output), and add _K (<7><7>) to
the table  as entry  258.   Store K  (<7>) into     _.    Note  that
although we have added the string consisting of Pixel 0 and Pixel
1 to  the table, we _re-use_ Pixel 1 as the beginning of the next
string.

Back at     the top  of the  loop.     We read Pixel 2 into K.  Does _K
(<7><7>) exist    in the    string table?    Yes,  the entry     we  just
added, entry 258, contains exactly <7><7>.  So we just add K onto
the end of _, so that _ is now <7><7>.

Back at     the top  of the  loop.     We read Pixel 3 into K.  Does _K
(<7><7><8>) exist  in the  string table?   No,    so write the code
associated with     _ (<258>)  to output, and add _K to the table as
entry 259.  Store K (<8>) into _.

Back at     the top  of the  loop.     We read Pixel 4 into K.  Does _K
(<8><8>) exist    in the    string table?    No,  so     write    the  code

TIFF 5.0                      page 45


associated with     _ (<8>)  to output,  and add  _K to the table as
entry 260.  Store K (<8>) into _.

Continuing, we get the following results:

   After reading: We write to output: And add table entry:
   Pixel 0
   Pixel 1   <7>  258: <7><7>
   Pixel 2
   Pixel 3   <258>     259: <7><7><8>
   Pixel 4   <8>  260: <8><8>
   Pixel 5   <8>  261: <8><7>
   Pixel 6
   Pixel 7   <258>     262: <7><7><6>
   Pixel 8   <6>  263: <6><6>

WriteCode() also  requires some     explanation.    The  output  code
stream,     <7><258><8><8><258><6>...  in    our  example,  should  be
written using as few bits as possible.    When we are just starting
out, we     can use  9-bit codes, since our new string table entries
are greater  than 255  but less     than 512.  But when we add table
entry 512,  we must  switch to 10-bit codes.  Likewise, we switch
to 11-bit  codes at  1024, and    12-bit codes  at 2048.     We  will
somewhat arbitrarily limit ourselves to 12-bit codes, so that our
table can  have at most 4096 entries.  If we push it any farther,
tables tend to get too large.

What happens  if we run out of room in our string table?  This is
where the afore-mentioned Clear code comes in.    As soon as we use
entry 4094, we write out a (12-bit) Clear code.      (If we wait any
longer to  write the  Clear code,  the decompressor  might try to
interpret the  Clear code  as a 13-bit code.)  At this point, the
compressor re-initializes the string table and starts writing out
9-bit codes again.

Note that  whenever you     write a code and add a table entry, _ is
not left  empty.   It contains exactly one character.  Be careful
not to    lose it     when you  write an end-of-table Clear code.  You
can either write it out as a 12-bit code before writing the Clear
code, in  which case  you will    want to     do it right after adding
table entry  4093, or  after the  clear code  as  a  9-bit  code.
Decompression gives the same result in either case.

To make     things a  little simpler  for the  decompressor, we will
require that  each strip  begins with a Clear code, and ends with
an EndOfInformation code.

Every LZW-compressed  strip must  begin on  a byte  boundary.  It
need not  begin on  a word  boundary.    LZW compression codes are
stored into  bytes in  high-to-low-order fashion, i.e., FillOrder
is assumed  to be  1.  The compressed codes are written as bytes,
not  words,  so     that  the  compressed    data  will  be    identical
regardless of whether it is an _II_ or _MM_ file.

TIFF 5.0                      page 46


Note that  the LZW string table is a continuously updated history
of the    strings that  have been encountered in the data.  It thus
reflects the characteristics of the data, providing a high degree
of adaptability.


LZW Decoding

The procedure for decompression is a little more complicated, but
still not too bad:

   while ((Code = GetNextCode()) != EoiCode) {
    if (Code == ClearCode) {
         InitializeTable();
         Code = GetNextCode();
         if (Code == EoiCode)
          break;
         WriteString(StringFromCode(Code));
         OldCode = Code;
    }  /* end of ClearCode case */

    else {
         if (IsInTable(Code)) {
          WriteString(StringFromCode(Code));
          AddStringToTable(StringFromCode(OldCode)+Firs
tChar(StringFromCode(Code)));
          OldCode = Code;
         } else {
          OutString   =       StringFromCode(OldCode)    +
FirstChar(StringFromCode(OldCode));
          WriteString(OutString);
          AddStringToTable(OutString);
          OldCode = Code;
         }
    } /* end of not-ClearCode case */
   } /* end of while loop */

The function  GetNextCode() retrieves the next code from the LZW-
coded data.  It must keep track of bit boundaries.  It knows that
the first code that it gets will be a 9-bit code.  We add a table
entry each  time we get a code, so GetNextCode() must switch over
to 10-bit codes as soon as string #511 is stored into the table.

The function  StringFromCode() gets  the string associated with a
particular code from the string table.

The function  AddStringToTable() adds  a  string  to  the  string
table.     The _+_  sign joining    the two     parts of the argument to
AddStringToTable indicate string concatenation.

StringFromCode() looks    up the    string associated  with     a  given
code.

WriteString() adds a string to the output stream.

TIFF 5.0                      page 47




When SamplesPerPixel Is Greater Than 1

We  have   so  far   described    the   compression  scheme  as  if
SamplesPerPixel were  always 1,     as will  be  be  the  case  with
palette color  and grayscale  images.  But what do we do with RGB
image data?

Tests on  our sample  images indicate  that the     LZW  compression
ratio     is    nearly     identical    regardless    of      whether
PlanarConfiguration=1 or  PlanarConfiguration=2, for  RGB images.
So use    whichever configuration     you prefer,  and simply compress
the bytes in the strip.

It is  worth cautioning     that compression  ratios on our test RGB
images were disappointing low: somewhere between 1.1 to 1 and 1.5
to 1,  depending on the image.    Vendors are urged to do what they
can to    remove as  much noise  from  their  images  as    possible.
Preliminary tests  indicate that significantly better compression
ratios are  possible with  less noisy  images.    Even something as
simple as  zeroing out one or two least-significant bitplanes may
be  quite   effective,    with   little  or  no  perceptible  image
degradation.


Implementation

The exact  structure of     the string  table and the method used to
determine if  a string    is already  in the table are probably the
most significant  design decisions in the implementation of a LZW
compressor and    decompressor.    Hashing has  been suggested  as a
useful technique for the compressor.  We have chosen a tree based
approach, with    good results.    The decompressor is actually more
straightforward,  as   well  as      faster,  since   no  search  is
involved_strings can be accessed directly by code value.


Performance

Many  people   do  not     realize  that    the  performance  of  any
compression scheme  depends greatly  on the type of data to which
it is  applied.      A scheme that works well on one data set may do
poorly on the next.

But since  we do  not want  to burden  the world  with    too  many
compression schemes, an adaptive scheme such as LZW that performs
quite well  on a wide range of images is very desirable.  LZW may
not always  give optimal  compression ratios,  but  its     adaptive
nature and relative simplicity seem to make it a good choice.

Experiments thus  far indicate    that we     can  expect  compression
ratios of  between 1.5    and 3.0     to 1  from LZW,  with no loss of
data, on  continuous tone  grayscale scanned  images.  If we zero

TIFF 5.0                      page 48


the least  significant one or two bitplanes of 8-bit data, higher
ratios can be achieved.     These bitplanes often consist chiefly of
noise, in  which case  little or no loss in image quality will be
perceived.   Palette color  images created  in    a  paint  program
generally compress  much  better  than    continuous  tone  scanned
images, since paint images tend to be more repetitive.    It is not
unusual to  achieve compression     ratios of 10 to 1 or better when
using LZW on palette color paint images.

By way    of comparison, PackBits, used in TIFF for black and white
bilevel images, does not do well on color paint images, much less
continuous tone     grayscale and    color images.  1.2 to 1 seemed to
be about average for 4-bit images, and 8-bit images are worse.

It has    been suggested that the CCITT 1D scheme could be used for
continuous tone     images, by compressing each bitplane separately.
No doubt  some    compression  could  be    achieved,  but    it  seems
unlikely that  a scheme     based on a fixed table that is optimized
for short  black runs  separated by  longer white runs would be a
very good choice on any of the bitplanes.  It would do quite well
on the    high-order bitplanes  (but so would a simpler scheme like
PackBits), and    would do quite poorly on the low-order bitplanes.
We believe  that the  compression ratios  would generally  not be
very impressive, and the process would in addition be quite slow.
Splitting  the    pixels    into  bitplanes     and  putting  them  back
together is  somewhat expensive,  and the  coding is  also fairly
slow when implemented in software.

Another     approach   that  has  been  suggested    uses  uses  a  2D
differencing step  following by     coding the  differences using    a
fixed table  of variable-length codes.    This type of scheme works
quite well  on many  8-bit  grayscale  images,    and  is     probably
simpler     to  implement    than  LZW.    But  it  has  a  number  of
disadvantages when  used on  a wide variety of images.    First, it
is not    adaptive.   This makes    a big difference when compressing
data such as 8-bit images that have been _sharpened_ using one of
the standard  techniques.  Such images tend to get larger instead
of smaller  when  compressed.     Another  disadvantage    of  these
schemes is  that they  do not  do well    with a    wide range of bit
depths.      The built-in    code table  has to  be    optimized  for    a
particular bit depth in order to be effective.

Finally,  we   should  mention     _lossy_   compression     schemes.
Extensive research  has been  done in  the area of lossy, or non-
information-preserving    image    compression.    These  techniques
generally yield     much  higher  compression  ratios  than  can  be
achieved  by   fully-reversible,   information-preserving   image
compression  techniques      such    as   PackBits  and   LZW.    Some
disadvantages:       many     of   the   lossy   techniques     are   so
computationally expensive  that hardware  assists  are    required.
Others    are  so     complicated  that  most  microcomputer     software
vendors could  not afford either the expense of implementation or
the increase  in  application  object  code  size.    Yet  others

TIFF 5.0                      page 49


sacrifice enough  image     quality  to  make  them  unsuitable  for
publishing use.

In spite  of these  difficulties, we  believe that there will one
day be    a standardized    lossy compression  scheme for  full color
images    that  will  be    usable    for  publishing     applications  on
microcomputers.      An International  Standards Organization group,
ISO/IEC/JTC1/SC2/WG8, in cooperation with CCITT Study Group VIII,
is hard at work on a scheme that might be appropriate.    We expect
that a    future revision of TIFF will incorporate this scheme once
it is  finalized, if it turns out to satisfy the needs of desktop
publishers and    others in the microcomputer community.    This will
augment, not replace, LZW as an approved TIFF compression scheme.
LZW will  very likely  remain the  scheme of  choice for  Palette
color images,  and perhaps  4-bit grayscale  images, and may well
overtake CCITT 1D and PackBits for bilevel images.


Future LZW Extensions

Some images  compress better  using LZW     coding if they are first
subjected to  a process     wherein each  pixel value is replaced by
the  difference     between  the  pixel  and  the    preceding  pixel.
Performing this     differencing in two dimensions helps some images
even more.  However, many images do not compress better with this
extra preprocessing,  and for a significant number of images, the
compression ratio is actually worse.  We are therefore not making
differencing an integral part of the TIFF LZW compression scheme.

However,  it   is  possible   that  a    _prediction_  stage  like
differencing may  exist which  is effective over a broad range of
images.     If such a scheme is found, it may be incorporated in the
next major TIFF revision.  If so, a new value will be defined for
the new     _Predictor_ TIFF  tag.     Therefore, all TIFF readers that
read LZW files must pay attention to the Predictor tag.     If it is
1, which  is the  default case,     LZW  decompression  may  proceed
safely.      If it     is not     1, and the reader does not recognize the
specified prediction scheme, the reader should give up.


Acknowledgements

The original  LZW reference  has already  been given.  The use of
ClearCode as a technique to handle overflow was borrowed from the
compression scheme used by the Graphics Interchange Format (GIF),
a small-color-paint-image-file    format used  by     CompuServe  that
also is an adaptation of the LZW technique.  Joff Morgan and Eric
Robinson of  Aldus were     each instrumental  in their  own way  in
getting LZW off the ground.

TIFF 5.0                      page 50


Appendix G: TIFF Classes


Rationale

TIFF was  designed to  make  life  easier  for    scanner     vendors,
desktop publishing  software developers,  and users  of these two
classes of products, by reducing the proliferation of proprietary
scanned     image     formats.    It     has  succeeded     far  beyond  our
expectations in     this respect.     But  we had  expected that  TIFF
would be of interest to only a dozen or so scanner vendors (there
weren_t any  more than    that in     1985), and  another dozen  or so
desktop publishing  software vendors.    This  turned out  to be a
gross underestimate.   The only problem with this sort of success
is that     TIFF was  designed to    be powerful  and flexible, at the
expense of  simplicity.      It takes  a fair  amount of  effort  to
handle all  the options     currently defined  in this specification
(probably no  application does    a  complete  job),  and     that  is
currently the  only way     you can be sure that you will be able to
import any  TIFF image,     since there are so many image-generating
applications out there now.

So here     is an attempt to channel some of the flexibility of TIFF
into more  restrictive paths,  using what  we have learned in the
past two  years about which options are the most useful.  Such an
undertaking is    of course filled with fairly arbitrary decisions.
But the     result is  that writers can more easily write files that
will be     successfully read by a wide variety of applications, and
readers can know when they can stop adding TIFF features.

The price  we pay for TIFF Classes is some loss in the ability to
adapt.     Once we  establish the requirements for a TIFF Class, we
can never add new requirements, since old software would not know
about these  new requirements.    (The best we can do at that point
is establish new TIFF Classes.    But the problem with that is that
we could quickly have too many TIFF Classes.)  So we must believe
that we know what we are doing in establishing these Classes.  If
we do not, any mistakes will be expensive.


Overview

Four TIFF Classes have been defined:

╤    Class B for bilevel (1-bit) images
╤    Class G for grayscale images
╤    Class P for palette color images
╤    Class R for RGB full color images

To save     time and  space, we will usually say _TIFF B_, _TIFF G_,
_TIFF P,_  and _TIFF R._  If we are talking about all four types,
we may write _TIFF X._

TIFF 5.0                      page 51


(Note to  fax people:    if  you are  interested in  a fax  TIFF F
Class, please  get together  and decide     what should  be in  TIFF
Class F     files.     Let us know if we can help in any way.     When you
have decided,  send us    your results,  so that we can include the
information here.)


Core Requirements

This section  describes requirements  that are common to all TIFF
Class X images.

General Requirements

The following  are required  characteristics of     all TIFF Class X
files.

Where there are options, TIFF X writers can do whichever one they
want, though  we will  often recommend    a particular  choice, but
TIFF X    readers must  be able  to handle all of them.  Please pay
close attention     to the     recommendations.  It is possible that at
some point  in the future, new and even-simpler TIFF classes will
be defined that include only recommended features.

You will  need to  read at  least the first three sections of the
main specification  in order  to fully    understand the    following
discussion.

Defaults.  TIFF X writers may, but are not required, to write out
a field that has a default value, if the default value is the one
desired.   TIFF X  readers must     be  prepared  to  handle  either
situation.

Other fields.    TIFF  X readers     must be  prepared  to    encounter
fields other  than the    required fields     in TIFF X files.  TIFF X
writers     are  allowed  to  write  fields  such    as  Make,  Model,
DateTime, and so on, and TIFF X readers can certainly make use of
such fields  if they  exist.   TIFF X  readers must not, however,
refuse to read the file if such optional fields do not exist.

_MM_ and  æIIÆ byte order.  TIFF X readers must be able to handle
both byte  orders.    TIFF  writers  can  do  whichever     is  most
convenient  or     efficient.    Images    are   crossing    the   IBM
PC/Macintosh boundary  (and others  as well)  with a surprisingly
high frequency.      We could force writers to all use the same byte
order, but  preliminary evidence  indicates that  this will cause
problems  when     we  start   seeing  greater-than-8-bit      images.
Reversing bytes     while scanning could well slow down the scanning
process enough    to cause  the scanning    mechanism to  stop, which
tends to create image quality problems.

Multiple subfiles.   TIFF X readers must be prepared for multiple
images (i.e.,  subfiles) per  TIFF file,  although they     are  not
required to do anything with any image after the first one.  TIFF

TIFF 5.0                      page 52


X writers  must be  sure to write a long word of 0 after the last
IFD (this is the standard way of signalling that this IFD was the
last one) as indicated in the TIFF structure discussion.

If a  TIFF X  writer writes multiple subfiles, the first one must
be the    full resolution     image.      Subsequent subimages,     such  as
reduced resolution  images and    transparency masks, may be in any
order in  the TIFF  file.   If a reader wants to make use of such
subimages, it  will have to scan the IFDÆs before deciding how to
proceed.

TIFF X    Editors.   Editors, applications  that modify TIFF files,
have a few additional requirements.

TIFF editors  must be  especially careful  about subfiles.   If a
TIFF editor  edits a full-resolution subfile, but does not update
an accompanying     reduced-resolution subfile,  a reader    that uses
the reduced-resolution    subfile for  screen display  will display
the wrong  thing.   So TIFF  editors must  either  create  a  new
reduced-resolution subfile  when  they    alter  a  full-resolution
subfile, or  else they    must simply delete any subfiles that they
aren_t prepared to deal with.

A similar  situation arises with the fields themselves.     A TIFF X
editor need  only worry     about the  TIFF X  required fields.   In
particular, it    is unnecessary,     and probably  dangerous, for  an
editor to  copy fields    that it does not understand.  It may have
altered the  file in  a way that is incompatible with the unknown
fields.


Required Fields

NewSubfileType.     LONG.    Recommended but not required.

ImageWidth.   SHORT or    LONG.    (That is, both _SHORT_ and _LONG_
TIFF data  types are  allowed, and  must be  handled properly  by
readers.   TIFF writers     can use either.)  TIFF X readers are not
required to  read arbitrarily  large files however.  Some readers
will give  up if the entire image cannot fit in available memory.
(In such cases the reader should inform the user of the nature of
the problem.)    Others    will  probably    not  be     able  to  handle
ImageWidth greater  than 65535.      Recommendation: use LONG, since
resolutions seem to keep going up.

ImageLength.  SHORT or LONG.  Recommendation: use  LONG.

RowsPerStrip.  SHORT or LONG.  Readers must be able to handle any
value between  1 and  2**32-1.     However, some readers may try to
read an     entire strip  into memory  at one  time, so  that if the
entire image is one strip, the application may run out of memory.
Recommendation 1:   Set     RowsPerStrip such  that the size of each
strip is  about 8K  bytes.   Do this  even for uncompressed data,
since it  is easy  for a  writer and  makes  things  simpler  for

TIFF 5.0                      page 53


readers.  (Note:  extremely wide, high-resolution images may have
rows larger  than 8K  bytes; in this case, RowsPerStrip should be
1,  and      the  strip  will  just  have    to  be    larger    than  8K.
Recommendation 2: use LONG.

StripOffsets.    SHORT or  LONG.     As explained in the main part of
the  specification,   the  number   of    StripOffsets  depends  on
RowsPerStrip and  ImageLength.    Recommendation:     always use LONG.
(LONG must, of course, be used if the file is more than 64K bytes
in length.)

StripByteCounts.   SHORT or  LONG.   Many existing TIFF images do
not contain StripByteCounts, because, in a strict sense, they are
unnecessary.   It is  possible to  write an efficient TIFF reader
that does  not need  to know  in advance  the  exact  size  of    a
compressed strip.   But     it does  make things  considerably  more
complicated, so     we will require StripByteCounts in TIFF X files.
Recommendation:      use SHORT,  since strips are not supposed to be
very large.

XResolution, YResolution.   RATIONAL.    Note  that the    X  and    Y
resolutions may     be unequal.   A  TIFF X  reader must  be able to
handle this  case.   TIFF X pixel-editors will typically not care
about the  resolution,    but  applications  such     as  page  layout
programs will.

ResolutionUnit.      SHORT.   TIFF X  readers must     be  prepared  to
handle all three values for ResolutionUnit.


TIFF Class B - Bilevel

Required (in addition to the above core requirements)

The following fields and values are required for TIFF B files, in
addition to  the fields     required for  all  TIFF  X  images  (see
above).

SamplesPerPixel =  1.    SHORT.     (Since this  is the default, the
field need  not be  present.   The same     thing    holds  for  other
required TIFF X fields that have defaults.)

BitsPerSample = 1.  SHORT.

Compression = 1, 2 (CCITT 1D), or 32773 (PackBits).  SHORT.  TIFF
B readers  must handle all three.  Recommendation:  use PackBits.
It  is    simple,     effective,  fast,  and     has  a     good  worst-case
behavior.    CCITT  1D    is  definitely    more  effective     in  some
situations, such as scanning a page of body text, but is tough to
implement and  test, fairly  slow,  and     has  a     poor  worst-case
behavior.   Besides, scanning a page of 12 point text is not very
useful for  publishing applications,  unless the  image     data  is
turned into  ASCII text     via OCR  software, which  is outside the
scope of TIFF.

TIFF 5.0                      page 54



PhotometricInterpretation = 0 or 1.  SHORT.
A Sample TIFF B Image

Offset           Value
(hex)      Name (mostly hex)

Header:
0000 Byte Order        4D4D
0002 Version   002A
0004 1st IFD pointer     00000014

IFD:
0014 Entry Count    000D
0016 NewSubfileType 00FE 0004 00000001    00000000
0022 ImageWidth        0100 0004 00000001    000007D0
002E ImageLength    0101 0004 00000001    00000BB8
003A Compression    0103 0003 00000001    8005 0000
0046 PhotometricInterpretation       0106 0003 00000001  0001 0000
0052 StripOffsets   0111 0004 000000BC    000000B6
005E RowsPerStrip   0116 0004 00000001    00000010
006A StripByteCounts     0117 0003 000000BC  000003A6
0076 XResolution    011A 0005 00000001    00000696
0082 YResolution    011B 0005 00000001    0000069E
008E Software  0131 0002 0000000E  000006A6
009A DateTime  0132 0002 00000014  000006B6
00A6 Next IFD pointer     00000000

Fields pointed to by the tags:
00B6 StripOffsets   Offset0, Offset1, ... Offset187
03A6 StripByteCounts     Count0, Count1, ... Count187
0696 XResolution    0000012C 00000001
069E YResolution    0000012C 00000001
06A6 Software  "PageMaker 3.0"
06B6 DateTime  "1988:02:18 13:59:59"


Image Data:
00000700  Compressed data for strip 10
xxxxxxxx  Compressed data for strip 179
xxxxxxxx  Compressed data for strip 53
xxxxxxxx  Compressed data for strip 160
.
.
.

End of example

Comments on the TIFF B example

1.   The IFD  in our example starts at position hex 14.     It could
have been  anywhere in    the file  as long as the position is even
and greater  than or equal to 8, since the TIFF header is 8 bytes
long and must be the first thing in a TIFF file.

TIFF 5.0                      page 55



2.   With 16 rows per strip, we have 188 strips in all.

3.   The example  uses a  number  of  optional    fields,     such  as
DateTime.   TIFF X  readers must safely skip over these fields if
they do not want to use the information.  And TIFF X readers must
not require that such fields be present.

4.   Just for  fun, our example has highly fragmented image data;
the strips  of our  image are  not even in sequential order.  The
point is  that strip  offsets must  not be ignored.  Never assume
that strip  N+1 follows     strip N.    Incidentally,  there  is  no
requirement that  the image  data follows  the    IFD  information.
Just the follow the pointers, whether they be IFD pointers, field
pointers, or Strip Offsets.



TIFF Class G - Grayscale

Required (in addition to the above core requirements)

SamplesPerPixel = 1.  SHORT.

BitsPerSample =     4,  8.       SHORT.    There  seems  to  be  little
justification for  working with grayscale images shallower than 4
bits, and 5-bit , 6-bit, and 7-bit images can easily be stored as
8-bit images, as long as you can compress the _unused_ bit planes
without penalty.  And we can do just that with LZW (Compression =
5.)

Compression = 1 or 5 (LZW).  SHORT.  Recommendation: use 5, since
LZW decompression is turning out to be quite fast.

PhotometricInterpretation = 0 or 1.  SHORT.   Recommendation: use
1, due    to popular  user interfaces  for adjusting brightness and
contrast.



TIFF Class P - Palette Color

Required (in addition to the above core requirements)

SamplesPerPixel = 1.  SHORT.  We use each pixel value as an index
into all three color tables in ColorMap.

BitsPerSample =     1,2,3,4,5,6,7, or 8.  SHORT.  1,2,3,4, and 8 are
probably the  most common,  but as long as we are doing that, the
rest come pretty much for free.

Compression = 1 or 5.  SHORT.

PhotometricInterpretation = 3 (Palette Color).    SHORT.

TIFF 5.0                      page 56



ColorMap.  SHORT.

Note that  bilevel and    grayscale images  can be  represented  as
special cases  of palette  color images.  As soon as enough major
applications support  palette color  images, we may want to start
getting rid  of     distinctions  between    bilevel,  grayscale,  and
palette color images.


TIFF Class R - RGB Full Color

Required (in addition to the above Core Requirements)

SamplesPerPixel = 3.  SHORT.  One sample each for Red, Green, and
Blue.

BitsPerSample =     8,8,8.      SHORT.  Shallower samples can easily be
stored as 8-bit samples with no penalty if the data is compressed
with LZW.  And evidence to date indicates that images deeper than
8 bits    per sample are not worth the extra work, even in the most
demanding publishing applications.

PlanarConfiguration = 1 or 2.  SHORT.  Recommendation:    use 1.

Compression = 1 or 5.  SHORT.

PhotometricInterpretation = 2 (RGB).  SHORT.

Recommended

Recommended for     TIFF Class  R, but not required, are the new (as
of Revision 5.0) colorimetric information tags.     See Appendix H.


Conformance and User Interface

Applications that  write valid    TIFF X files should include _TIFF
B_ and/or  _TIFF G_  and/or _TIFF  P_ and/or  _TIFF R_    and/or in
their product  spec sheets, if they can write the respective TIFF
Class X     files.      If your  application writes  all four     of these
types, you  may wish to write it as _TIFF B,G,P,R._  Of course, a
term like  _TIFF B,_  while fine  for  communicating  with  other
vendors, will  not convey much information to a typical user.  In
this case,  a  phrase  such  as     _Standard  TIFF  Black-and-White
Scanned Images_ might be better.

The same  terminology guidelines  apply to applications that read
TIFF Class X files.

If your     application reads more kinds of files than it writes, or
vice versa,  it would  be a  good idea    to make that clear to the
buyer.     For example, if your application reads TIFF B and TIFF G

TIFF 5.0                      page 57


files, but writes only TIFF G files, you should write it that way
in the spec sheet.

TIFF 5.0                      page 58


Appendix H: Image Colorimetry Information

Chris Sears
210 Lake Street
San Francisco, CA 94118

June 4, 1988
Revised August 8, 1988


I. Introduction

Our goal is to accurately reproduce a color image using different
devices.   Accuracy requires  techniques  of  measurement  and    a
standard  of   comparison.     Different  devices   imply  device
independence.    Colorimetry provides the framework to solve these
problems.  When an image has a complete colorimetric description,
in principle  it  can  be  reproduced  identically  on    different
monitors and using different media, such as offset lithography.

The colorimetry     data is  specified when  the image is created or
changed.   A scanned image has colorimetry data derived from  the
filters and  light sources  of the  scanner and a synthetic image
has colorimetry     data corresponding to the monitor used to create
it or  the monitor model of the rendering environment.    This data
is used     to map     an input  image to  the markings  or colors of a
particular output device.

Section II  describes various  standards organizations    and their
work in color.
Section III describes our motivation for seeking these tags.
Section IV describes our goals of reproduction.
Sections V, VI and VII introduce the colorimetry tags.
Section VIII specifies the tags themselves.
Section IX describes the defaults.
Section X discusses the limitations and some of the other issues.
Section XI provides a few references.


II. Related Standards

TIFF is     a general  standard for describing image data.     It would
be foolish  for us  to change  TIFF in    a way  that did not match
existing industry  and international  standards.   Therefore,  we
have taken  pains to  note in the discussion below the efforts of
various standards organizations and select defaults from the work
of these organizations.

CIE  (Commission Internationale de lÆEclairage)  The basis of the
colorimetry information     is the     CIE 1931  Standard Observer [3].
While other color models could be supported [1] [4], CIE 1931 XYZ
is the    international standard    accepted  across  industries  for
specifying  color   and     CIE  xyY  is  the  chromaticity  diagram
associated with CIE 1931 XYZ tristimulus values.

TIFF 5.0                      page 59



NTSC (National Television  System Committee)  NTSC is of interest
primarily  for     historical  reasons  and  its    use  in     encoding
television data.   Manufacturing  standards for monitors have for
some time  drifted significantly  from the  1953 NTSC colorimetry
specification.

SMPTE      (Society of  Motion Picture  and Television  Engineers)
Most of     the work  by NTSC  has been  largely subsumed    by SMPTE.
This organization  has a  set of  standards  called  "Recommended
Practices" that     apply to  various technical  aspects of film and
television production [5] [6].

ISO  (International  Standards    Organization)     ISO  has  become
involved in  color standards  through work on a color addendum to
"Office Document Architecture (ODA) and Interchange Format" [7].

ANSI (American    National   Standards  Institute)    ANSI  is  the
American representative to ISO .


III. Motivation

Our motivation    for defining  these tags  stems from our research
and  development  in  color  separation     technology.    With  the
information described here and the RGB pixel data, we have all of
the  information  necessary  for  generating  high-quality  color
separations.  We could supply the colorimetry information outside
of the    image  file.    But  since  TIFF  provides  a  convenient
mechanism for  bundling all  of the  relevant  information  in    a
single place,  tags are     defined to  describe this information in
color TIFF files.

A color     image rendered     with incorrect     colorimetry  information
looks different     from the original.  One of our early test images
has an artifact in it where the image was scanned with one set of
primaries and  color ramps  were  overlaid  on    top  of     it  with
different primaries.  The blue ramp looked purple when we printed
it. Using incorrect gamma tables or white points can also lead to
distorted images.  The best way to avoid these kinds of errors is
to allow  the creator  of an  image  to     supply     the  colorimetry
information along with the RGB values [1] [2].

The purpose  of the  colorimetry data  is to  allow a  projective
transformation from the primaries and white point of the image to
the primaries  and white  point of  the rendering  media.   Gamma
reflects the non-linear transfer gradient of real media.


IV. Colorimetric Color Reproduction

Earlier we  said that given the proper colorimetric data an image
could be  rendered identically    using  two  different  calibrated
devices.   By identical,  we mean  colorimetric reproduction [9].

TIFF 5.0                      page 60


Specifically, the  chromaticities  match  and  the  luminance  is
scaled to correspond to the luminance range of the output device.
Because of this, we only need the chromaticity coordinates of the
white point  and primaries.   The absolute luminance is arbitrary
and unnecessary.


V. White Point

In TIFF 4.0, the white point was specified as D65.  This appendix
allocates a  separate tag  for describing the white point and D65
is the logical default since it is the SMPTE standard [6].

The white  point is  defined  colorimetrically    in  the     CIE  xyY
chromaticity diagram.    While  it is  rare for monitors to differ
from D65,  scanned images  often  have    different  white  points.
Rendered images     can have  arbitrary white  points.   The graphic
arts use D50 as the standard viewing light source [8].


VI. Primary Chromaticities

In TIFF     4.0, the  primary color  chromaticities matched the NTSC
specification.    With the wide variety of color scanners, monitors
and renderers,    TIFF needs  a mechanism for accurately describing
the chromaticities  of the  primary colors.   We use SMPTE as the
default chromaticity  since conventional  monitors are    closer to
SMPTE and  some monitors  (Conrac 6545)     are manufactured  to the
SMPTE specifications.    We  donÆt use the NTSC chromaticities and
white point  because present day monitors donÆt use them and must
be _matrixed_ to approximate them.

As an  example, the primary color chromaticities used by the Sony
Trinatron differ  from those  recommended by  SMPTE.  In general,
since  real  monitors  vary  from  the    industry  standards,  the
chromaticities of  primaries are described in the CIE xyY system.
This  allows   a  reproduction     system     to  compensate     for  the
differences.


VII. Color Response Curves

This tag  defines three     color response curves, one each for red,
green, and blue color information.  The width of each entry is 16
bits, as  implied by  the type    SHORT.     The minimum intensity is
represented by 0 and the maximum by 65535.  For example, black is
represented by    0,0,0 and  white by  65535, 65535,  65535.    The
length of  each curve is 2**BitsPerSample.  A ColorResponseCurves
field for RGB data where each of the samples is 8 bits deep would
have 3*256  entries.   The 256    red  entries  would  come  first,
followed by 256 green entries, followed by 256 blue entries.

The purpose  of the  ColorResponseCurves field    is to  act  as    a
lookup table  mapping sample values to specific intensity values,

TIFF 5.0                      page 61


so that     an image  created on  one system  can    be  displayed  on
another      with     minimal   loss      of   color   fidelity.      The
ColorResponseCurves field thus describes the _gamma_ of an image,
so that     a TIFF     reader on another system can compensate for both
the image gamma and the gamma of the reading system.

Gamma is  a term that relates to the typically nonlinear response
of most     display devices,  including monitors.     In  most display
systems, the  voltage applied to the CRT is directly proportional
to the    value of  the red,  green, or  blue sample.  However, the
resulting luminance  emitted by     the  phosphor    is  not     directly
proportional to     the voltage.    This relationship is approximated
in most displays by

   luminance = voltage ** gamma

The NTSC  standard gamma  of 2.2 adequately describes most common
video systems.    The standard  gamma of    2.2 implies a dim viewing
surround.   (We know of no SMPTE recommended practice for gamma.)
The following example uses an 8 bit sample with value of 127.

   voltage = 127 / 255 = 0.4980
   luminance = 0.4980 ** 2.2 = 0.2157

In the    examples below,     we only  consider a  single primary  and
therefore only a single curve.    The same analysis applies to each
of the    red, green,  and blue  primaries and  curves.    Also, and
without loss  of generality,  we assume that there is no hardware
color map, so that we must alter the pixel values themselves.  If
there is  a color  map, the  manipulations can be done on the map
instead of on the pixels.

If no  ColorResponseCurves field  exists in  a color  image,  the
reader should  assume a     gamma of  2.2 for each of the primaries.
This default curve can be generated with the following C code:

   ValuesPerSample = 1 << BitsPerSample;
   for (curve[0] = 0, i = 1; i < ValuesPerSample; i++)
    curve[i] =  floor (pow    (i /  (ValuesPerSample -  1.0),
2.2) * 65535.0 + .5);

The displaying    or rendering  application can know its own gamma,
which we  will call  the _destination  gamma._     (An uncalibrated
system can usually assume that its gamma is 2.2 without going too
far  wrong.)     Using     this  information  the     application  can
compensate for the gamma of the image, as we shall see below.

If  the     source     and  destination  systems  are     both  adequately
described  by    a  gamma  of  2.2,  the     writer     would    omit  the
ColorResponseCurves field,  and the  reader can     simply read  the
image directly into the frame buffer.  If a writer writes out the
ColorResponseCurves field,  then a  reader must     assume that  the
gammas    differ.       A  reader  must  then  perform  the    following
computation on each sample in the image:

TIFF 5.0                      page 62



   NewSampleValue  =   floor  (pow   (curve[OldSampleValue]   /
65535.0, 1.0 / DestinationGamma) *
     (ValuesPerSample - 1.0) + .5);

Of course,  if the _gamma_ of the destination system is not well-
approximated with  an exponential  function, an     arbitrary  table
lookup may  be used  in place  of raising  the    value  to  1.0    /
DestinationGamma.

Leave out  ColorResponseCurves if  using the default gamma.  This
saves about  1.5K in  the  most     common     case,    and,  after  all,
omission is the better part of compression.

Do not    use this  field to  store frame     buffer color  maps.  Use
instead      the     ColorMap   field.     Note,      however,   that
ColorResponseCurves may     be used  to refine  the information in a
ColorMap if desired.

The above  examples assume  that a  single parameter gamma system
adequately approximates the response characteristics of the image
source and  destination systems.   This will usually be true, but
our use     of a table instead of a single gamma parameter gives the
flexibility  to     describe  more     complex  relationships,  without
requiring additional computation or complexity.


VIII. New Tags and Changes
The following tags should be placed in the "Basic Fields" section
of
the TIFF specification:

White Point
Tag  = 318 (13E)
Type = RATIONAL
N    = 2

The white  point of the image.    Note that this value is described
using  the  1931  CIE  xyY  chromaticity  diagram  and    only  the
chromaticity is     specified.  The luminance component is arbitrary
and not     specified.   This can correspond to the white point of a
monitor that  the image     was painted  on,  the    filter    set/light
source combination  of a  scanner, or  to the  white point of the
illumination model of a rendering package.

Default is the SMPTE white point, D65:    x = 0.313, y = 0.329.

The ordering is x, y.


PrimaryChromaticities
Tag  = 319 (13F)
Type = RATIONAL
N    = 6

TIFF 5.0                      page 63



The primary  color chromaticities.   Note  that these  values are
described using     the 1931  CIE xyY  chromaticity diagram and only
the chromaticities  are     specified.    For  paint  images,  these
represent the  chromaticities of  the  monitor    and  for  scanned
images    they   are  derived  from  the    filter    set/light  source
combination of a scanner.

Default is the SMPTE primary color chromaticities:

   Red: x = 0.635 y = 0.340
   Green:    x = 0.305 y = 0.595
   Blue:     x = 0.155 y = 0.070

The ordering is red x, red y, green x, green y, blue x, blue y.

Color Response Curves

Default for  ColorResponseCurves represents  curves corresponding
to the NTSC standard gamma of 2.2.


IX. Defaults

The defaults  used by  TIFF reflect industry standards.     Both the
WhitePoint and    PrimaryChromaticities tags have defaults that are
promoted  by   SMPTE  .        In    addition,  the    default     for  the
ColorResponseCurves tag matches the NTSC specification of a gamma
of 2.2.

The purpose  of these  defaults is to allow reasonable results in
the absence  of     accurate  colorimetry    data.     An  uncalibrated
scanner or  paint system  produces an  image  that  be    displayed
identically, though  probably incorrectly  on two  different  but
calibrated systems.   This is better then the uncertain situation
where the  image might    be rendered  differently on two different
but calibrated systems.


X. Limitations and Issues

This section  discusses several     of the     limitations  and  issues
involved in colorimetric reproduction.

Scope of Usefulness

For many  purposes the    data recommended  here is unnecessary and
can be omitted.     For presentation graphics where there are only a
few colors,  being able     to tell  red from green is probably good
enough.      In this  case the  tags can  be ignored and there is no
overhead.   In more  demanding color  reproduction  environments,
this data  allows images to be described device independently and
at small cost.

TIFF 5.0                      page 64


User Burdens

The data we recommend isnÆt a user burden; it is really a systems
issue.     It allows  a systems  solution but  doesnÆt require user
intercession.    Calibration however  is a  separate issue.  It is
likely to involve the user.

Resolution Versus Fidelity

Some manufacturers  supply greater than 24 bits of resolution for
color specification.   The  purpose of    this is     either to  avoid
artifacts such    as contouring  in the shadows or in some cases to
be more     specific or  device independent  about the  color.  Both
reasons can  be misguided.   Other, less expensive techniques can
be used     to prevent artifacts, such as deeper color maps.  As for
accuracy, fidelity is more important than precision.

Colorimetric Color Reproduction

There are other choices for objectives of color reproduction [9].
Spectral color    reproduction is a stronger condition and most are
weaker, such  as preferred  color  reproduction.    While  device
independent spectral  color reproduction  is  impossible,  device
independent  colorimetric  reproduction     is  possible,    within    a
tolerance and within the limits of the gamuts of the devices.  By
choosing a  strong criteria  we allow the important objectives of
weaker criteria, such as preferred color reproduction, to be part
of design packages.

Metamerism

If two    patches of  color  are    identical  under  one  light  and
different under     another, they    are said  to be     metameric pairs.
Colorimetric  color  reproduction  is  a  weaker  condition  than
spectral color reproduction and hence allows metamerism problems.
By standardizing  the viewing  conditions we  can largely finesse
the metamerism    problem for  print.   Because television is self-
luminous and doesnÆt use spectral absorption, metamerism isnÆt so
much a problem.

Color Models - xyY Versus Luv, etc.

We choose  xyY over  Luv [1]  because XYZ  is  the  international
standard for  color specification  and xyY  is    the  chromaticity
diagram associated  with XYZ.    Luv is meant for color difference
measurement.

Ambient Environment And Viewing Surrounds

The viewing environment affects how the eye perceives color.  The
eye adapts  to a  dark room  and it adapts to a colored surround.
While  these   problems     can   be  compensated     for  within  the
colorimetric framework    [4], it is much better to finesse them by
standardizing.     The design environment should match the intended

TIFF 5.0                      page 65


viewing environment.   Specifically it should not be a pitch dark
room and,  on average,    it should  be of  a neutral  color.   For
print, ANSI recommends a Munsell N-8 surface [8].


XI. References

In particular,    we would  like to mention the work of Stuart Ring
of the    Copy Products  Division of the Eastman Kodak Company.  He
and  his  colleagues  are  promoting  a     color    data  interchange
paradigm.   They are  working closely  with the     ISO 8613 Working
Group [7].

[1]  Color Data     Interchange Paradigm,    Eastman Kodak, Rochester,
New York, 7 December 1987.

[2]  Color  Reproduction   and    Illumination  Models,  Roy  Hall,
International Summer  Institute:   State of  the Art  in Computer
Graphics, 1986.

[3]  CIE   Colorimetry:       Official   Recommendations     of   the
International Commission on Illumination, Publication 15-2, 1986.

[4]  Color Science:  Concepts and  Methods, Quantitative Data and
Formulae, Gunter  Wyszecki, W.S.  Stiles, John    Wiley  and  Sons,
Inc., New York, New York, 1982.

[5]  Color Monitor  Colorimetry, SMPTE    Recommended  Practice  RP
145-1987.

[6]  Color Temperature    for  Color  Television    Studio    Monitors,
SMPTE Recommended Practice RP 37.

[7]  Office   Document     Architecture    (ODA)    and   Interchange
Format_Addendum on Colour, ISO 8613 Working Draft.

[8]  ANSI Standard PH 2.30-1985.

[9]  The Reproduction  of Colour  in  Photography,  Printing  and
Television, R.    W. G.  Hunt, Fountain  Press, Tolworth,     England,
1987.

[10] Raster  Graphics    Handbook,  The    Conrac    Corporation,  Van
Nostrand Reinhold  Company, New     York,    New  York,  1985.    Good
description of gamma.

TIFF 5.0                      page 66


Appendix I:  Horizontal Differencing Predictor


This appendix,    written after  the release of Revision 5.0 of the
TIFF specification,  is still  in draft     form.     Please send  any
comments to the Aldus Developers Desk.


Revision 5.0  of the  TIFF specification defined a new tag called
_Predictor_  that  describes  techniques  that    may  be     used  in
conjuction with     TIFF compression  schemes.    We  now    define    a
Predictor that    greatly     improves  compression    ratios    for  some
images.

The horizontal    differencing predictor    is assigned the tag value
Predictor = 2:

Predictor
Tag  = 317 (13D)
Type = SHORT
N    = 1

A predictor  a mathematical operator that is applied to the image
data before  the encoding  scheme is  applied.     Currently (as of
revision 5.0)  this tag     is used  only with  LZW  (Compression=5)
encoding, since     LZW is     probably the  only TIFF  encoding scheme
that benefits  significantly from a predictor step.  See Appendix
F.

1 = No prediction scheme used before coding.
2 = Horizontal differencing. See Appendix I.

Default is 1.


The algorithm

The idea  is to     make use  of the  fact that many continuous tone
images rarely  vary much  in pixel  value from    one pixel  to the
next.    In such     images,  if  we  replace  the    pixel  values  by
differences between  consecutive pixels,  many of the differences
should be  0, plus  or minus  1, and  so on.   This  reduces  the
apparent information  content, and  thus allows LZW to encode the
data more compactly.

Assuming 8-bit    grayscale  pixels  for    the  moment,  a     basic    C
implementation might look something like this:

   char image[ ][ ];
   int    row, col;

   /* take horizontal differences:
    */
   for (row = 0; row < nrows; row++)

TIFF 5.0                      page 67


    for (col = ncols - 1; col >= 1; col--)
         image[row][col] -= image[row][col-1];

If we  don_t have 8-bit samples, we need to work a little harder,
so that     we can make better use of the architecture of most CPUs.
Suppose we  have 4-bit    samples, packed     two to a byte, in normal
TIFF uncompressed  (i.e., Compression=1)  fashion.   In order  to
find differences,  we want to first expand each 4-bit sample into
an 8-bit  byte, so  that we  have one  sample per byte, low-order
justified.   We then  perform the  above horizontal differencing.
Once the  differencing has  been completed, we then repack the 4-
bit differences     two to     a  byte,  in  normal  TIFF  uncompressed
fashion.

If the    samples are  greater than  8  bits  deep,  expanding  the
samples into  16-bit words  instead of 8-bit bytes seems like the
best way to perform the subtraction on most computers.

Note that we have not lost any data up to this point, nor will we
lose any  data later  on.   It    might  at  first  seem    that  our
differencing might  turn 8-bit samples into 9-bit differences, 4-
bit samples  into 5-bit differences, and so on.     But it turns out
that we     can completely     ignore the  _overflow_     bits  caused  by
subtracting a  larger number  from a  smaller  number  and  still
reverse the  process  without  error.     Normal     twos  complement
arithmetic does just what we want.  Try an example by hand if you
need more convincing.

Up  to    this  point  we     have  implicitly  assumed  that  we  are
compressing  bilevel   or  grayscale   images.       An  additional
consideration arises in the case of color images.

If PlanarConfiguration    is 2,  there is no problem.  Differencing
proceeds the same way as it would for grayscale data.

If  PlanarConfiguration     is  1,     however,  things  get    a  little
trickier.   If    we  didnÆt  do  anything  special,  we  would  be
subtracting red     sample values    from green  sample values,  green
sample values  from blue  sample values,  and blue  sample values
from red sample values, which would not give the LZW coding stage
much redundancy     to work  with.      So we     will do  our  horizontal
differences with  an offset  of SamplesPerPixel     (3, in     the  RGB
case).    In other words, we will subtract red from red, green from
green, and  blue from blue.  The LZW coding stage is identical to
the SamplesPerPixel=1 case.  We require that BitsPerSample be the
same for all 3 samples.


Results and guidelines

LZW without  differencing works     well  for  1-bit  images,  4-bit
grayscale images, and synthetic color images.  But natural 24-bit
color images  and some 8-bit grayscale images do much better with
differencing.  For example, our 24-bit natural test images hardly

TIFF 5.0                      page 68


compressed at  all using  _plain_ LZW:    the  average  compression
ratio was  1.04     to  1.       The    average     compression  ratio  with
horizontal differencing     was 1.40  to 1.  (A compression ratio of
1.40 to 1 means that if the uncompressed image is 1.40MB in size,
the compressed version is 1MB in size.)

Although  the    combination  of      LZW  coding    with   horizontal
differencing does  not result  in any  loss of    data, it  may  be
worthwhile in  some situations    to give     up some  information  by
removing as  much noise     as possible  from the    image data before
doing the  differencing, especially  with  8-bit  samples.    The
simplest way  to get  rid of noise is to mask off one or two low-
order bits  of each 8-bit sample.  On our 24-bit test images, LZW
with horizontal differencing yielded an average compression ratio
of 1.4 to 1.  When the low-order bit was masked from each sample,
the compression     ratio climbed to 1.8 to 1; the compression ratio
was 2.4     to 1  when masking  two bits,    and 3.4 to 1 when masking
three bits.   Of  course, the  more you     mask, the  more you risk
losing useful information along with the noise.     We encourage you
to experiment  to find    the best compromise for your device.  For
some applications it may be useful to let the user make the final
decision.

Interestingly, most  of our RGB images compressed slightly better
using PlanarConfiguration=1.   One  might think     that compressing
the  red,   green,  and      blue     difference   planes   separately
(PlanarConfiguration=2) might  give  better  compression  results
than  mixing   the  differences      together   before   compressing
(PlanarConfiguration=1), but this does not appear to be the case.

Incidentally,  we  tried  taking  both    horizontal  and     vertical
differences,  but   the     extra     complexity  of      two-dimensional
differencing did  not appear  to pay  off for  most of    our  test
images.     About one third of the images compressed slightly better
with two-dimensional  differencing, about  one    third  compressed
slightly worse, and the rest were about the same.

TIFF 5.0                      page 69


Appendix J:  Palette Color


This appendix,    written after  the release of Revision 5.0 of the
TIFF specification,  is still  in draft     form.     Please send  any
comments to the Aldus Developers Desk.


Revision  5.0    of  the      TIFF    specification    defined      a   new
PhotometricInterpretation value     called _palette color._  We have
been wondering    lately if this additional complexity is worth the
implementation expense.      If  not, let_s  drop it before too many
people start creating palette color images.


The Proposal

Instead of a separate palette color image type, there seems to be
no compelling reason why palette (mapped) color images should not
be stored as _full color_ (usually 24-bit) RGB images.


Objections

The most  obvious objection is the amount of space required.  But
if you    care about how much space the image takes up on disk, you
should use  LZW compression,  which is    ideally     suited     to  most
palette color  images.     (LZW compresses  most paint-type palette
color images  5:1 or  more.)   And if you use LZW compression, it
turns out  that palette     color images stored as full color images
compress to  almost exactly the same size as palette color images
stored as  palette color  images.  That is, with LZW compression,
there is  no penalty  for storing  palette color  images as  full
color RGB  images.   The resulting  file may  be  a  few  percent
larger, but  it will not be three times as large.  See Appendix F
for more information on how LZW works.

Another objection  might be  that an  application might     want  to
process the  image differently    if it is _really_ a palette color
image. But  we can easily add auxiliary information that can help
a TIFF    reader to quickly categorize color images if it wants to.
See the _New tags_ section below.


Benefits

It may    be obvious,  but it  is probably  worth discussing why we
want  to   abolish   palette   color   images    as   a     distinct
classification.

The main  problem is  that palette color as a separate type makes
life more  hazardous and  confusing for     users.       The    confusion
factor is  aggravated because  users already  have to be somewhat
aware of  distinctions    between     bilevel,  grayscale,  and  color

TIFF 5.0                      page 70


images.      Having two  main types of color images is hard for many
users to  grasp, and  it is probably not possible to totally hide
this complexity     from the user in certain situations.  The hazard
level goes  up because some applications may accept palette color
but not     full color  images, or     full color but not palette color
images, or may accept 8-bit palette color images but not 4-bit or
3-bit palette color images.

The second  problem is    that writing and maintaining code to deal
with an     additional image  type is  somewhat expensive    for  TIFF
readers.  The cost of supporting palette color images will depend
on the    application, but  we believe  that, in    general, the cost
will be     substantial.    It seems  to make  more sense  to put the
burden on  TIFF writers to convert palette color images into full
color image  form than    to make TIFF readers handle an additional
color image  type, since there are more TIFF readers than writers
at this point.


New tags

Here are  some proposed     new tags that can help to classify color
images, and  make up  for not  having a     separate  palette  color
class.    They are not required for TIFF Class R , but are strongly
recommended for     color TIFF  images created by palette-type color
paint programs.

ColorImageType
Tag  = 318 (13E)
Type = SHORT
N    = 1

Gives TIFF  color image     readers a  better idea     of what  kind of
color image it is.  There will be borderline cases.

1 = Continuous tone, natural image.
2 =  Synthetic image, using a greatly restricted range of colors.
Such images  are produced  by most  color paint     programs.    See
ColorList for a list of colors used in this image.

Default is 1.

ColorList
Tag  = 319 (13F)
Type = BYTE or SHORT
N    = the  number of  colors that  are used in this image, times
SamplesPerPixel

A list    of colors that are used in this image.    Use of this field
is only     practical for    images containing  a  greatly  restricted
(usually  less     than  or   equal  to    256)  range   of  colors.
ColorImageType should be 2.  See ColorImageType.

TIFF 5.0                      page 71


The list  is organized    as an array of RGB triplets, with no pad.
The RGB     triplets are  not guaranteed  to be  in  any  particular
order.     Note that the red, green, and blue components can either
be a  BYTE or  a SHORT    in length.  BYTE should be sufficient for
most applications.

No default.