Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2301

File Format for Internet Fax

Pages: 77
Obsoleted by:  3949
Part 2 of 3 – Pages 24 to 49
First   Prev   Next

ToP   noToC   RFC2301 - Page 24   prevText
4. Extended Black-and-White fax mode

   This section defines the extended black-and-white mode or Profile F
   of TIFF for facsimile. It provides a standard definition of what has
   historically been known as TIFF Class F and now TIFF-F. In doing so,
   it aligns this mode with current ITU-T Recommendations for black-
   and-white fax and with existing industry practice. Implementations of
   this profile include implementations of Profile S.
ToP   noToC   RFC2301 - Page 25
   This section describes extensions to the minimal interchange set of
   fields (Profile S) that provide a richer set of black-and-white
   capabilities. The fields and values described in this section are a
   superset of the fields and values defined for the minimal interchange
   set in Section 3. In addition to the MH encoding, Modified READ (MR)
   and Modified Modified READ (MMR) encoding as described in [T.4] and
   [T.6] are supported.

   Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the
   TIFF fields that SHALL be used in this mode. Section 4.3 describes
   the fields that MAY be used in this mode. In the spirit of the
   original TIFF-F specification, Sections 4.4 and 4.5 discuss technical
   implementation issues and warnings. Section 4.6 gives an example use
   of TIFF-F. Section 4.7 gives a summary of the required and
   recommended fields and their values.

4.1 TIFF-F Overview

   Though it has been in common usage for many years, TIFF-F has
   previously never been documented in the form of a standard.  An
   informal TIFF-F document was originally created by a small group of
   fax experts led by Joe Campbell.  The existence of TIFF-F is noted in
   [TIFF] but it is not defined.  This document serves as the formal
   definition of the F application of [TIFF] for Internet applications.
   For ease of reference, the term TIFF-F will be used throughout this
   document as a shorthand for the extended black-and-white mode or
   profile of TIFF for facsimile.

   Up until the TIFF 6.0 specification, TIFF supported various "Classes"
   which defined the use of TIFF for various applications. Classes were
   used to support specific applications. In this spirit, TIFF-F has
   been known historically as "TIFF Class F".  Previous informal TIFF-F
   documents [TIFF-F0] used the "Class F" terminology.  As of TIFF 6.0
   [TIFF], the TIFF Class concept has been eliminated in favor of the
   concept of Baseline TIFF.  Therefore, this document updates the
   definition of TIFF-F as the F profile of TIFF for facsimile, by using
   Baseline  TIFF as defined in [TIFF] as the starting point and then
   adding the TIFF extensions to Baseline TIFF which apply for TIFF-F.
   In almost all  cases, the resulting definition of TIFF-F fields and
   values remains  consistent with those used historically in earlier
   definitions of TIFF  Class F.  Where some of the values for fields
   have been updated to provide more precise conformance with the ITU-T
   [T.4] and [T.30] fax recommendations, these differences are noted.
ToP   noToC   RFC2301 - Page 26
4.2. Required TIFF Fields

   This section lists the required fields and the values they must have
   to be ITU-compatible. Besides the fields listed in Section 2.2.1, the
   extended black-and-white fax mode SHALL use the following fields.

4.2.1. Baseline fields

BitsPerSample(258) = 1.                                            SHORT
    RequiredByTIFFBaseline
    Binary data only.
    Default = 1 (field may be omitted if this is the value)

Compression(259) = 3, 4.                                           SHORT
    RequiredByTIFFBaseline
    3 = 1- or 2- dimensional coding, must have T4Options field This is
    a TIFF Extension value [TIFF].
    4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
    Read, must have T6Options field)) This is a TIFF Extension value.
    Default = 1 (and is not applicable; field must be specified)

   NOTE: Baseline TIFF permits use of value 2 for Modified Huffman
   encoding, but data is presented in a form which does not use EOLs,
   and so TIFF for facsimile uses Compression=3 instead. See Sections
   4.4.4, 4.5.1 and 4.5.2 for more information on compression and
   encoding.

FillOrder(266) = 1 , 2.                                            SHORT
    RequiredByTIFFBaseline
    Profile F readers must be able to read data in both bit orders,
    but the vast majority of facsimile products store data LSB
    first, exactly as it appears on the telephone line.
              1 = Most Significant Bit first.
              2 = Least Significant Bit first

ImageWidth(256)                                            SHORT or LONG
    RequiredByTIFFBaseline
    This mode supports the following fixed page widths: 1728, 2592, 3456
    (corresponding to North American Letter and Legal, ISO A4 paper
    sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and
    2432, 3648, 4864 (corresponding to ISO A3 paper size).
    No default; must be specified

   NOTE: Historical TIFF-F did not include support for the following
   widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096
   and 4864. Historical TIFF-F documents also included the following
   values related to A5 and A6 widths: 816 and 1216. Per the most recent
ToP   noToC   RFC2301 - Page 27
   version of [T.4], A5 and A6 documents are no longer supported in
   Group 3 facsimile, so the related width values are now obsolete. See
   section 4.5.2 for more information on inch/metric equivalencies and
   other implementation details.

NewSubFileType(254) = (Bit 1=1).                                    LONG
    RequiredByTIFFforFAX
    Bit 1 is 1 if the image is a single page of a multi-page document.
    Default = 0 (no subfile bits on, so may not be omitted for fax)

   NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page
   of a multi-page image. The same bit settings are used when TIFF-F is
   used for a one page fax image. See Section 4.4.3 for details on
   multi-page files.

PhotometricInterpretation(262) = 0, 1.                             SHORT
    RequiredByTIFFBaseline
    0 = pixel value 1 means black, 1 = pixel value 1 means white.
    This field allows notation of an inverted or negative image.
    No default, must be specified

ResolutionUnit(296) = 2, 3.                                        SHORT
    RequiredByTIFFBaseline
    The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F
    has traditionally used inch-based measures.
    Default = 2 (field may be omitted if this is the value)

SamplesPerPixel(277) = 1.                                          SHORT
    RequiredByTIFFBaseline
    1 = monochrome, bilevel in this case (see BitsPerSample)
    Default =1 (field may be omitted if this is the value)

XResolution(282) = 200, 204, 300, 400, 408                      RATIONAL
    RequiredByTIFFBaseline
    The horizontal resolution of the image is expressed in pixels per
    resolution unit. In pixels/inch, the allowed values are: 200, 204,
    300, 400, and 408. See Section 2.2.2 for inch-metric equivalency.
    No default, must be specified

   NOTE: The values of 200 and 408 have been added to the historical
   TIFF-F values, for consistency with [T.30]. Some existing TIFF-F
   implementations may also support values of 80 pixels/cm, which is
   equivalent to 204 pixels per inch. See section 4.5.2 for information
   on implementation details.

YResolution(283) = 98, 100, 196, 200, 300, 391, and 400       RATIONAL
    RequiredByTIFFBaseline
    The vertical resolution of the image is expressed in pixels per
ToP   noToC   RFC2301 - Page 28
    resolution unit. In pixels/inch, the allowed values are: 98, 100,
    196, 200, 300, 391, and 400 pixels/inch.
    See Section 2.2.2 for inch-metric equivalency.
    No default, must be specified

   NOTE: The values of 100, 200, and 391 have been added to the
   historical TIFF-F values, for consistency with [T.30].  Some existing
   TIFF-F implementations may also support values of 77 and 38.5 (cm),
   which are equivalent to 196 and 98 pixels per inch respectively. See
   section 4.5.2 for more information on implementation details.

   NOTE: Not all combinations of XResolution, YResolution and ImageWidth
   are legal. The following table gives the legal combinations and
   corresponding paper size [T.30].

    +--------------+-----------------+---------------------------+
    |   XResolution x YResolution    |         ImageWidth        |
    +--------------+-----------------+---------+--------+--------+
    |      200x100, 204x98           |         |        |        |
    |      200x200, 204x196          |  1728   |  2048  |  2432  |
    |           204x391              |         |        |        |
    +--------------+-----------------+---------+--------+--------+
    |          300 x 300             |  2592   |  3072  |  3648  |
    +--------------+-----------------+---------+--------+--------+
    |     408 x 391, 400 x 400       |  3456   |  4096  |  4864  |
    +--------------+-----------------+---------+--------+--------+
                                     |Letter,A4|   B4   |   A3   |
                                     |  Legal  |        |        |
                                     +---------+--------+--------+
                                     |         Paper Size        |
                                     +---------------------------+


4.2.2. Extension fields

T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1)        LONG
    RequiredTIFFExtension (when Compression = 3)
    T4Options was also known as Group3Options in a prior version of
    [TIFF].
    Bit 0 = 1 indicates MR encoding, = 0 indicates MH encoding.
    Bit 1 must be 0
    Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
    aligned
    Default is all bits are 0 (applies when MH encoding is used and EOLs
    are not byte aligned EOLs) (See Section 3.2.2.)
    The T4Options field is required when the Compression field has a
    value of 3. This field specifies the encoding used (MH or MR) and
    whether the EOL codes are byte-aligned or not. If they are byte
ToP   noToC   RFC2301 - Page 29
    aligned, then fill bits have been added as necessary so that the End
    of Line (EOL) codes always end on byte boundaries See Sections 3.4,
    4.5.3 and 4.5.4 for details.

T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG
    RequiredTIFFExtension (when Compression = 4)
    Used to indicate parameterization of 2D Modified Modified Read
    compression. T6Options was also known as Group4Options in a prior
    version of [TIFF].
    Bit 0 must be 0.
    Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
    indicates uncompressed data is allowed (see [TIFF]).
    Default is all bits 0. For FAX, the field must be present and have
    the value 0. The use of uncompressed data where compression would
    expand the data size is not allowed for FAX.

   NOTE: MMR compressed data is two-dimensional and does not use EOLs.
   Each MMR encoded image MUST include an "end-of-facsimile-block"
   (EOFB) code at the end of each coded strip; see Section 4.5.6.

4.2.3. New fields

   None.

4.3. Recommended TIFF fields

4.3.1. Baseline fields

   See Section 2.2.3.

4.3.2. Extension fields

   See Section 2.2.3.

4.3.3. New fields

   Three new, optional fields, used in the original TIFF-F description
   to describe page quality, are defined in this specification.  The
   information contained in these fields is usually obtained from
   receiving facsimile hardware (if applicable). They SHOULD NOT be used
   in writing TIFF-F files for facsimile image data that is error
   corrected or otherwise guaranteed not to have coding errors. Some
   applications need to understand exactly the error content of the
   data.  For example, a CAD program might wish to verify that a  file
   has a low error level before importing it into a high-accuracy
   document. Because Group 3 facsimile devices do not necessarily
   perform error correction on the image data, the quality of a received
   page must be inferred from the pixel count of decoded scan lines. A
ToP   noToC   RFC2301 - Page 30
   "good" scan line is defined as a line that, when decoded, contains
   the correct number of pixels. Conversely, a "bad" scan line is
   defined as a line that, when decoded, comprises an incorrect number
   of pixels.

BadFaxLines(326)                                           SHORT or LONG
    The number of "bad" scan lines encountered by the facsimile device
    during reception. A "bad" scanline is defined as a scanline that,
    when decoded, comprises an incorrect number of pixels. Note that
    PercentBad = (BadFaxLines/ImageLength) * 100
    No default.

CleanFaxData(327) = 0, 1, 2.                                       SHORT
    Indicates if "bad" lines encountered during reception are stored in
    the data, or if "bad" lines have been replaced by the receiver.
    0 = No "bad" lines
    1 = "bad" lines exist, but were regenerated by the receiver,
    2 = "bad" lines exist, but have not been regenerated.
    No default.

   NOTE: Many facsimile devices do not actually output bad lines.
   Instead, the previous good line is repeated in place of a bad line.
   Although this substitution, known as line regeneration, results in a
   visual improvement to the image, the data is nevertheless corrupted.
   The CleanFaxData field describes the error content of the data.  That
   is, when the BadFaxLines and ImageLength fields indicate that the
   facsimile device encountered lines with an incorrect number of pixels
   during reception, the CleanFaxData field indicates whether these bad
   lines are actually still in the data or if the receiving facsimile
   device replaced them with regenerated lines.

ConsecutiveBadFaxLines(328)                               LONG or SHORT
    Maximum number of consecutive "bad" scanlines received.  The
    BadFaxLines field indicates only the quantity of bad lines.
    No Default.

   NOTE: The BadFaxLines and ImageLength data indicate only the quantity
   of bad lines. The ConsecutiveBadFaxLines field is an indicator of the
   distribution of bad lines and may therefore be a better general
   indicator of perceived image quality. See Section 4.4.5 for examples
   of the use of these fields.

4.4. Technical Implementation Issues

4.4.1   Strips

   In general, TIFF files divide an image into "strips," also known as
   "bands."  Each strip contains a few scanlines of the image. By using
ToP   noToC   RFC2301 - Page 31
   strips, a TIFF reader need not load the entire image into memory,
   thus enabling it to fetch and decompress small random portions of the
   image as necessary.

   The number of scanlines in a strip is described by the RowsPerStrip
   value and the number of bytes in the strip after compression by the
   StripByteCount value.  The location in the TIFF file of each strip is
   given by the StripOffsets values.

   Strip size is application dependent. The recommended approach for
   multi- page TIFF-F images is to represent each page as a single
   strip. Existing TIFF-F usage is typically one strip per page in
   multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3.

4.4.2  Bit Order

   The current TIFF specification [TIFF] does not require a Baseline
   TIFF reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel
   in the least significant bit of a byte. It further recommends that
   FillOrder=2 be used only in special purpose applications.

   Facsimile data appears on the phone line in bit-reversed order
   relative to its description in ITU-T Recommendation T.4.  Therefore,
   a wide majority of facsimile applications choose this natural order
   for data in a file. Nevertheless, TIFF-F readers must be able to read
   data in both bit orders and support FillOrder values of 1 and 2.

4.4.3. Multi-Page

   Many existing applications already read TIFF-F-like files, but do not
   support the multi-page field.  Since a multi-page format greatly
   simplifies file management in fax application software, TIFF-F
   specifies multi-page documents (NewSubfileType = 2) as the standard
   case.

   It is recommended that applications export multiple page TIFF-F files
   without manipulating fields and values.   Historically, some TIFF-F
   writers have attempted to produce individual single-page TIFF-F files
   with modified NewSubFileType and PageNumber (page one-of-one) values
   for export purposes.  However, there is no easy way to link such
   multiple single page files together into a logical multiple page
   document, so that this practice is not recommended.

4.4.4. Compression

   In Group 3 facsimile, there are three compression methods which had
   been standardized as of 1994 and are in common use. The ITU-T T.4
   Recommendation [T.4] defines a one-dimensional compression method
ToP   noToC   RFC2301 - Page 32
   known as Modified Huffman (MH) and a two-dimensional method known as
   Modified READ (MR) (READ is short for Relative Element Address
   Designate). In 1984, a somewhat more efficient compression method
   known as Modified Modified READ (MMR) was defined in the ITU-T T.6
   Recommendation [T.6]. MMR was originally defined for use with Group 4
   facsimile, so that this compression method has been commonly called
   Group 4 compression.  In 1991, the MMR method was approved for use in
   Group 3 facsimile and has since been widely utilized.

   TIFF-F supports these three compression methods. The most common
   practice is the one-dimensional Modified Huffman (MH) compression
   method.  This is specified by setting the Compression field value to
   3 and then setting bit 0 of the T4Options field to 0.  Alternatively,
   the two dimensional Modified READ (MR) method, which is much less
   frequently used in historical TIFF-F implementations, may be selected
   by setting bit 0 of the T4Options field to 1.  The value of Bit 2 in
   this field is determined by the use of fill bits.

   Depending upon the application, the more efficient two-dimensional
   Modified Modified Read (MMR)compression method from T.6 may be
   selected by setting the Compression field value to 4 and then setting
   the first two bits (and all unused bits) of the T6Options field to 0.
   More information to aid the implementor in making a compression
   selection is contained in Section 4.5.2.

   Baseline TIFF also permits use of Compression=2 to specify Modified
   Huffman compression, but the data does not use EOLs. As a result,
   TIFF-F uses Compression=3 instead of Compression=2 to specify
   Modified Huffman compression.

4.4.5.  Example Use of Page-quality Fields

   Here are examples for writing the CleanFaxData, BadFaxLines, and
   ConsecutiveBadFaxLines fields:

     1.  Facsimile hardware does not provide page quality
         information: MUST NOT write page-quality fields.
     2.  Facsimile hardware provides page quality information, but
         reports no bad lines.  Write only BadFaxLines = 0.
     3.  Facsimile hardware provides page quality information, and
         reports bad lines.  Write both BadFaxLines and
         ConsecutiveBadFaxLines.  Also write CleanFaxData = 1 or 2 if
         the hardware's regeneration capability is known.
     4.  Source image data stream is error-corrected or otherwise
         guaranteed to be error-free such as for a computer generated
         file:  SHOULD NOT write page-quality fields.
ToP   noToC   RFC2301 - Page 33
   TIFF Writers SHOULD only generate these fields when the image has
   been generated from a fax image data stream where error correction,
   e.g. Group 3 Error Correction Mode, was not used.

4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F
   Files

   Traditionally, historical TIFF-F has required readers and writers to
   be able to handle multi-page TIFF-F files.  Based on the experience
   of various TIFF-F implementors, it has been seen that the
   implementation of TIFF-F can be greatly simplified if certain
   practical guidelines are followed when writing multi-page TIFF-F
   files.

   The structure for a multi-page TIFF-F file will include one IFD per
   page of the document.  In this case, this IFD will define the
   attributes for a single page. A second simplifying guideline is that
   the writer of TIFF-F files SHOULD present IFDs in the same order as
   the actual sequence of pages.  (The pages are numbered within TIFF-F
   beginning with page 0 as the first page and then ascending (i.e. 0,
   1, 2,...). However, any field values over 4 bytes will be stored
   separately from the IFD. TIFF-F readers SHOULD expect IFDs to be
   presented in page order, but be able to handle exceptions.

   Per [TIFF], the exact placement of image data is not specified.
   However, the strip offsets for each strip of image are defined from
   within each IFD.   Where possible, another simplifying guideline for
   the writing of TIFF-F files is to specify that the image data for
   each page of a multi-page document SHOULD be contained within a
   single strip (i.e. one image strip per fax page). The use of a single
   image strip per page is very useful for applications such as store
   and forward messaging, where the file is usually prepared in advance
   of the transmission, but other assumptions may apply for the size of
   the image strip for applications which require the use of "streaming"
   techniques (see section 4.4.7).  In the event a different image strip
   size guideline has been used (e.g. constant size for image strips
   that may be less than the page size), this will immediately be
   evident from the values/offsets of the fields that are related to
   strips.

   A third simplifying guideline is that each IFD SHOULD be placed in
   the TIFF-F file structure at a point which precedes the image which
   the IFD describes.

   In addition, a fourth simplifying guideline for TIFF-F writers and
   readers is to place the actual image data in a physical order within
   the TIFF file structure which is consistent with the logical page
   order.  In practice, TIFF-F readers will need to use the strip
ToP   noToC   RFC2301 - Page 34
   offsets to find the exact physical location of the image data,
   whether or not it is presented in logical page order.

   If the image data is stored in multiple strips, then the strips
   SHOULD occur in the file in the same order that the data they contain
   occurs in the facsimile transmission, starting at the top of the
   page.

   TIFF-F writers MAY make a fifth simplifying guideline, in which the
   IFD, the value data and the image data to which the IFD has offsets
   precede the next image IFD. However, this guideline has been relaxed
   (writers MAY rather than SHOULD use it) compared to the other
   guidelines given here to reflect past practices for TIFF-F.

   In the case of the minimal mode, which is also the minimal subset of
   Profile S, the SHOULD's and MAY's of these guidelines become SHALL's
   (see Section 3.5).

   So, a TIFF-F file which is structured using the guidelines of this
   section will essentially be composed of a linked list of IFDs,
   presented in ascending page order, which in turn each point to a
   single page of image data (one strip per page), where the pages of
   image data are also placed in a logical page order within the TIFF- F
   file structure.  (The pages of image data may themselves be stored in
   a contiguous manner, at the option of the implementor).

4.4.7.   Use of TIFF-F for Streaming Applications

   TIFF-F has historically been used for handling fax image files in
   applications such as store and forward messaging where the entire
   size of the file is known in advance.  While TIFF-F may also possibly
   be used as a file format for cases such as streaming applications,
   assumptions may be required that differ from those provided in this
   section (e.g., the entire size and number of pages within the image
   are not known in advance).  As a result, a definition for the
   streaming application of TIFF-F is beyond the scope of this document.

4.5. Implementation Warnings

4.5.1  Uncompressed data

   TIFF-F requires the ability to read and write at least one-
   dimensional T.4 Huffman ("compressed") data.  Uncompressed data is
   not allowed. This means that the "Uncompressed" bit in T4Options or
   T6Options must be set to 0.
ToP   noToC   RFC2301 - Page 35
4.5.2. Encoding and Resolution

   Since two-dimensional encoding is not required for Group 3
   compatibility, some historic TIFF-F readers have not been able to
   read such files.  The minimum subset of TIFF-F REQUIRES support for
   one dimensional (Modified Huffman) files, so this choice maximizes
   portability.  However, implementors seeking greater efficiency SHOULD
   use T.6 MMR compression when writing TIFF-F files.  Some TIFF-F
   readers will also support two-dimensional Modified READ files.
   Implementors that wish to have the maximum flexibility in reading
   TIFF-F files should support all three of these compression methods
   (MH, MR and MMR).

   For the case of resolution, almost all facsimile products support
   both standard (98 dpi) vertical resolution  and "fine" (196 dpi)
   resolution. Therefore, fine-resolution files are quite portable in
   the real world.

   In 1993, the ITU-T added support for higher resolutions in the T.30
   recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per
   inch based units.  At the same time, support was added for metric
   dimensions which are equivalent to the following inch based
   resolutions: 391v x 204h and 391v x 408h.  Therefore, the full set of
   inch-based equivalents of the new resolutions are supported in the
   TIFF-F writer, since they may appear in some image data streams
   received from Group 3 facsimile devices.  However, many facsimile
   terminals and older versions of  TIFF-F readers are likely to not
   support the use of these higher resolutions.

   Per [T.4], it is permissible for applications to treat the following
   XResolution values as being equivalent: <204,200> and <400,408>.  In
   a similar respect, the following YResolution values may also be
   treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>.
   These equivalencies were allowed by [T.4] to permit conversions
   between inch and metric based facsimile terminals.

   In a similar respect, the optional support of metric based
   resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for
   completeness, since they are used in some legacy TIFF-F applications,
   but this use is not recommended for the creation of TIFF-F files by a
   writer.

4.5.3. EOL byte-aligned

   The historical convention for TIFF-F has been that all EOLs in
   Modified Huffman or Modified READ data must be byte-aligned. However,
   Baseline TIFF has permitted use of non-byte-aligned EOLs by default,
   so that a large percentage of TIFF-F reader implementations support
ToP   noToC   RFC2301 - Page 36
   both conventions. Therefore, the minimum subset of TIFF-F, or Profile
   S, as defined in Section 3 includes support for both byte-aligned and
   non- byte-aligned EOLs; see Section 3.2.2.

   An EOL is said to be byte-aligned when 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 one byte preceded by a
   zero nibble: xxxx0000 00000001.

   Modified Huffman encoding encodes bits, not bytes. This means that
   the end-of-line token may end in the middle of a byte. In byte
   alignment, extra zero bits (Fill) are added so that the first bit of
   data following an EOL begins on a byte boundary. In effect, byte
   alignment relieves application software of the burden of bit-
   shifting every byte while parsing scan lines for line-oriented image
   manipulation (such as writing a TIFF file).

   For Modified READ encoding, each line is terminated by an EOL and a
   one bit tag bit.  Per [T.4], the value of the tag bit is 0 if the
   next line contains two dimensional data and 1 if the next line is a
   reference line.   To maintain byte alignment, fill bits are added
   before the EOL/tag bit sequence, so that the first bit of data
   following an MR tag bit begins on a byte boundary.

4.5.4. EOL

   As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
   with Modified Huffman begin with an EOL, which in TIFF-F may be byte-
   aligned. The last line of the image is not terminated by an EOL.  In
   a similar respect, images encoded with Modified READ two-dimensional
   encoding begin with an EOL, followed by a tag bit.

4.5.5. RTC Exclusion

   Aside from EOLs, TIFF-F files have historically only contained image
   data. This means that applications which wish to maintain strict
   conformance with the rules in [TIFF] and compatibility with
   historical TIFF-F, SHOULD NOT include the Return To Control sequence
   (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files.
   However, applications which need to support "transparency" of [T.4]
   image data MAY include RTCs if the flag settings of the T4Options
   field are set for non-byte aligned MH or MR image data.  Implementors
   of TIFF readers should also be aware that there are some existing
   TIFF-F implementations which include the RTC sequence in MH/MR image
   data. Therefore, TIFF-F readers MUST be able to process files which
   do not include RTCs and SHOULD be able to process files which do
   include RTCs.
ToP   noToC   RFC2301 - Page 37
4.5.6 Use of EOFB for T.6 Compressed Images

   TIFF-F pages which are encoded with the T.6 Modified Modified READ
   compression method MUST include an "end-of-facsimile-block" (EOFB)
   code at the end of each coded strip. Per [TIFF], the EOFB code is
   followed by pad bits as needed to align on a byte boundary. TIFF
   readers SHOULD ignore any bits other than pad bits beyond the EOFB.

4.6. Example Use of TIFF-F

   The Profile F of TIFF (i.e. TIFF-F content) is a secondary component
   of the VPIM Message, as defined in [VPIM2].  Voice messaging systems
   can often handle fax store-and-forward capabilities in addition to
   tradi- tional voice message store-and-forward functions.  As a
   result, TIFF-F fax messages can optionally be sent between compliant
   VPIM systems, and may be rejected if the recipient system cannot deal
   with fax.

   Refer to the VPIM Specification for proper usage of this content.

4.7. Extended Black-and-white Fax Mode Summary

   Recommended fields are shown with an asterisk *.

   Required fields or values are shown with a double asterisk **. If the
   double asterisk is on the field name, then all the listed values are
   required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

       +---------------------------+--------------------------------+
       | Baseline Fields           |  Values                        |
       +---------------------------+--------------------------------+
       | BitsPerSample             | 1**                            |
       +---------------------------+--------------------------------+
       | Compression               | 3**: 1D Modified Huffman and   |
       |                           |      2D Modified Read coding   |
       |                           | 4: 2D Modified Modified Read   |
       |                           |    coding                      |
       +---------------------------+--------------------------------+
       | DateTime*                 | {ASCII}: date/time in 24-hour  |
       |                           | format "YYYY:MM:DD HH:MM:SS"   |
       +---------------------------+--------------------------------+
       | FillOrder**               | 1: most significant bit first  |
       |                           | 2: least significant bit first |
       +------------------------------------------------------------+
ToP   noToC   RFC2301 - Page 38
       +------------------------------------------------------------+
       | ImageDescription*         | {ASCII}: A string describing   |
       |                           | the contents of the image.     |
       +---------------------------+--------------------------------+
       | ImageWidth                | 1728**, 2048, 2432, 2592,      |
       |                           | 3072, 3456, 3648, 4096, 4864   |
       +---------------------------+--------------------------------+
       | ImageLength**             | n: total number of scanlines   |
       |                           | in image                       |
       +---------------------------+--------------------------------+
       | NewSubFileType            | 2**: Bit 1 identifies single   |
       |                           | page of a multi-page document  |
       +---------------------------+--------------------------------+
       | Orientation               | 1**-8, Default 1               |
       +---------------------------+--------------------------------+
       | PhotometricInterpretation | 0: pixel value 1 means black   |
       |  **                       | 1: pixel value 1 means white   |
       +---------------------------+--------------------------------+
       | ResolutionUnit**          | 2: inch                        |
       |                           | 3: centimeter                  |
       +---------------------------+--------------------------------+
       | RowsPerStrip**            | n: number of scanlines per     |
       |                           | TIFF strip                     |
       +---------------------------+--------------------------------+
       | SamplesPerPixel           | 1**                            |
       +---------------------------+--------------------------------+
       | Software*                 | {ASCII}: name & release        |
       |                           | number of creator software     |
       +---------------------------+--------------------------------+
       | StripByteCounts**         | <n>: number or bytes in TIFF   |
       |                           | strip                          |
       +---------------------------+--------------------------------+
       | StripOffsets**            | <n>: offset from beginning of  |
       |                           | file to each TIFF strip        |
       +---------------------------+--------------------------------+
       | XResolution               | 200, 204**, 300, 400, 408      |
       |                           | (written in pixels/inch)       |
       +---------------------------+--------------------------------+
       | YResolution               | 98**, 196**, 100,              |
       |                           | 200, 300, 391, 400             |
       |                           | (written in pixels/inch)       |
       +---------------------------+--------------------------------+
       | Extension Fields                                           |
       +---------------------------+--------------------------------+
ToP   noToC   RFC2301 - Page 39
       +---------------------------+--------------------------------+
       | T4Options                 | 0**: required if Compression   |
       |                           | is Modified Huffman, EOLs are  |
       |                           | not byte aligned               |
       |                           | 1: required if Compression is  |
       |                           | 2D Modified Read, EOLs are     |
       |                           | not byte aligned               |
       |                           | 4**: required if Compression   |
       |                           | is Modified Huffman, EOLs are  |
       |                           | byte aligned                   |
       +---------------------------+--------------------------------+
       | T4Options (continued)     | 5: required if Compression     |
       |                           | is 2D Modified Read, EOLs are  |
       |                           | byte aligned                   |
       +---------------------------+--------------------------------+
       | T6Options                 | 0: required if Compression is  |
       |                           | 2D Modified Modified Read      |
       +---------------------------+--------------------------------+
       | DocumentName*             | {ASCII}: name of scanned       |
       |                           | document                       |
       +---------------------------+--------------------------------+
       | PageNumber**              | n,m: page number followed by   |
       |                           | total page count               |
       +---------------------------+--------------------------------+
       | New Fields                                                 |
       +---------------------------+--------------------------------+
       | BadFaxLines*              | number of "bad" scanlines      |
       |                           | encountered during reception   |
       +---------------------------+--------------------------------+
       | CleanFaxData*             | 0: no "bad" lines              |
       |                           | 1: "bad" lines exist, but were |
       |                           | regenerated by receiver        |
       |                           | 2: "bad" lines exist, but have |
       |                           | not been regenerated           |
       +---------------------------+--------------------------------+
       | ConsecutiveBadFaxLines*   | Max number of consecutive      |
       |                           | "bad" lines received           |
       +---------------------------+--------------------------------+

5. Lossless JBIG Black-and-White Fax Mode

   This section defines the lossless JBIG black-and-white mode or
   Profile J of TIFF for facsimile. Implementations of this profile are
   required to also implement Profile S.
ToP   noToC   RFC2301 - Page 40
   The previous section described the extended interchange set of TIFF
   fields for black-and-white fax, which provided support for the MH, MR
   and MMR compression of black-and-white images. This section adds a
   mode with JBIG compression capability.

5.1. Overview

   This section describes a black-and-white mode that uses JBIG
   compression. The ITU-T has approved the single-progression sequential
   mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers
   improved compression for halftoned originals. JBIG compression is
   used in accordance with the application rules given in ITU-T Rec.
   T.85 [T.85].

   This mode is essentially the extended black-and-white mode with JBIG
   compression used instead of MH, MR or MMR.

5.2. Required TIFF Fields

   This section lists the required fields and the values they must have
   to be ITU-compatible. Besides the fields listed in Section 2.2.1, the
   extended black-and-white fax mode requires the following fields.

5.2.1. Baseline fields

   The TIFF fields that SHALL be used in this mode are the same as those
   described in Section 4.2.1 for the extended black-and-white mode,
   with two exceptions: the following text replaces the text in Section
   4.2.1 for the Compression and FillOrder fields.

Compression(259) = 9.                                              SHORT
    RequiredByTIFFBaseline
    9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG). This is
    a TIFF extension value.
    Default = 1 (and is not applicable; field must be specified).

FillOrder(266) = 2.                                            SHORT
    RequiredByTIFFBaseline
    2 = Pixels are arranged within a byte such that pixels with lower
    column values are stored in the lower-order bits of the bytes, i.e.,
    least significant bit first (LSB).

   NOTE: The JBIG coding of black-and-white image data in Profile J
   follows ITU-T Rec. T.85 [T.85], which specifies LSB first ordering
   within a byte. Note that Baseline TIFF readers are only required to
   support MSB first ordering or FillOrder = 1.

5.2.2. Extension fields
ToP   noToC   RFC2301 - Page 41
   Same fields as those in Section 2.2.1.

5.2.3. New fields

   None.

5.3. Recommended TIFF Fields

   See Section 2.2.3 and 2.2.4.

5.4.  Lossless JBIG Black-and-white Fax Mode Summary

   Recommended fields are shown with an asterisk *.

   Required fields or values are shown with a double asterisk **. If the
   double asterisk is on the field name, then all the listed values are
   required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

       +---------------------------+--------------------------------+
       | Baseline Fields           |  Values                        |
       +---------------------------+--------------------------------+
       | BitsPerSample             | 1**                            |
       +---------------------------+--------------------------------+
       | Compression               | 9**: JBIG coding               |
       +---------------------------+--------------------------------+
       | DateTime*                 | {ASCII}: date/time in 24-hour  |
       |                           | format "YYYY:MM:DD HH:MM:SS"   |
       +---------------------------+--------------------------------+
       | FillOrder**               | 1: most significant bit first  |
       |                           | 2: least significant bit first |
       +---------------------------+--------------------------------+
       | ImageDescription*         | {ASCII}: A string describing   |
       |                           | the contents of the image.     |
       +---------------------------+--------------------------------+
       | ImageWidth                | 1728**, 2048, 2432, 2592,      |
       |                           | 3072, 3456, 3648, 4096, 4864   |
       +---------------------------+--------------------------------+
       | ImageLength**             | n: total number of scanlines   |
       |                           | in image                       |
       +---------------------------+--------------------------------+
       | NewSubFileType**          | 2: Bit 1 identifies single     |
       |                           | page of a multi-page document  |
       +---------------------------+--------------------------------+
       | Orientation               | 1**-8, Default 1               |
       +------------------------------------------------------------+
ToP   noToC   RFC2301 - Page 42
       +---------------------------+--------------------------------+
       | PhotometricInterpretation | 0: pixel value 1 means black   |
       |  **                       | 1: pixel value 1 means white   |
       +---------------------------+--------------------------------+
       | ResolutionUnit**          | 2: inch                        |
       |                           | 3: centimeter                  |
       +---------------------------+--------------------------------+
       | RowsPerStrip**            | n: number of scanlines per     |
       |                           | TIFF strip                     |
       +---------------------------+--------------------------------+
       | SamplesPerPixel**         | 1                              |
       +---------------------------+--------------------------------+
       | Software*                 | {ASCII}: name & release        |
       |                           | number of creator software     |
       +---------------------------+--------------------------------+
       | StripByteCounts**         | <n>: number of bytes in TIFF   |
       |                           | strip                          |
       +---------------------------+--------------------------------+
       | StripOffsets**            | <n>: offset from beginning of  |
       |                           | file to each TIFF strip        |
       +---------------------------+--------------------------------+
       | XResolution               | 200, 204**, 300, 400, 408      |
       |                           | (written in pixels/inch)       |
       +---------------------------+--------------------------------+
       | YResolution               | 98**, 196**, 100,              |
       |                           | 200, 300, 391, 400             |
       |                           | (written in pixels/inch)       |
       +---------------------------+--------------------------------+
       | Extension Fields                                           |
       +---------------------------+--------------------------------+
       | DocumentName*             | {ASCII}: name of document      |
       |                           |  scanned                       |
       +---------------------------+--------------------------------+
       | PageNumber**              | n,m: page number followed by   |
       |                           | total page count               |
       +---------------------------+--------------------------------+
       | New Fields                                                 |
       +---------------------------+--------------------------------+
       | GlobalParametersIFD*      | IFD: global parameters IFD     |
       +---------------------------+--------------------------------+
       | ProfileType*              | n: type of data stored in file |
       +---------------------------+--------------------------------+
       | FaxProfile*               | n: ITU-compatible fax mode     |
       +---------------------------+--------------------------------+
       | CodingMethods*            | n: compression algorithms used |
       |                           | in file                        |
       +---------------------------+--------------------------------+
ToP   noToC   RFC2301 - Page 43
6. Base Color Fax Mode

6.1. Overview

   This section defines the lossy color mode or Profile C of TIFF for
   facsimile. Implementations of this profile are required to also
   implement Profile S.

   This is the base mode for color and grayscale facsimile, which means
   that all applications that support color fax must support this mode.
   The basic approach is the lossy JPEG compression [T.4, Annex E; T.81]
   of L*a*b* color data [T.42]. Grayscale applications use the L*
   lightness component; color applications use the L*, a* and b*
   components.

   This mode uses a new PhotometricInterpretation field value to
   describe the L*a*b* encoding specified in [T.42]. This encoding
   differs in two ways from the other L*a*b* encodings used in TIFF
   [TIFF, TTN1]: it specifies a different default range for the a* and
   b* components, based on a comprehensive evaluation of existing
   hardcopy output, and it optionally allows selectable range for the
   L*, a* and b* components.

6.2. Required TIFF Fields

   This section lists the required fields, in addition to those given in
   Section 2.2.1, and the values they must support to be compatible with
   ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4.

6.2.1. Baseline Fields

ImageWidth(256).                                           SHORT or LONG
    This mode supports the following fixed page widths: 864, 1024, 1216,
    1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.

NewSubFileType(254) = (Bit 1=1).                                    LONG
    RequiredByTIFFforFAX
    Bit 1 is 1 if the image is a single page of a multi-page document.
    Default = 0 (no subfile bits on, so may not be omitted for fax)

BitsPerSample(258) = 8, 12.                                        SHORT
    Count = SamplesPerPixel
    The base color fax mode requires 8 bits per sample, with 12 as an
    option. 12 bits per sample is not baseline TIFF.

Compression(259) = 7.                                              SHORT
    Base color fax mode uses Baseline JPEG compression. Value 7
    represents JPEG compression as specified in [TTN2].
ToP   noToC   RFC2301 - Page 44
FillOrder(266) = 1 , 2.                                            SHORT
    RequiredByTIFFBaseline
    Profile C readers must be able to read data in both bit orders,
    but the vast majority of facsimile products store data LSB
    first, exactly as it appears on the telephone line.
              1 = Most Significant Bit first.
              2 = Least Significant Bit first

PhotometricInterpretation(262) = 10.                               SHORT
    Base color fax mode requires pixel values to be stored using the CIE
    L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is
    indicated by the PhotometricInterpretation value 10, referred to as
    ITULAB. With this encoding, the minimum sample value is  mapped to 0
    and the maximum sample value is mapped to (2^n - 1), i.e. the
    maximum value, where n is the BitsPerSample value. The conversion
    from unsigned ITULAB-encoded samples values to signed CIE L*a*b*
    values is determined by the Decode field; see Sec. 6.2.3

   NOTE: PhotometricInterpretation values 8 and 9 specify encodings for
   use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1]
   data, but they are fixed encodings, which use different minimum and
   maximum samples than the T.42 default encoding. As currently defined,
   they are not able to represent fax-encoded L*a*b* data.

ResolutionUnit(296) = 2, 3.                                        SHORT
    The unit of measure for resolution. 2 = inch, 3 = centimeter;
    Default = 2 (field may be omitted if this is the value)

SamplesPerPixel(277) = 1, 3.                                       SHORT
    1: L* component only, required in base color mode
    3: L*, a*, b* components
    Encoded according to PhotometricInterpretation field

XResolution(282) = 100, 200, 300, 400.                          RATIONAL
YResolution(283) = 100, 200, 300, 400.                          RATIONAL
    The resolution of the image is expressed in pixels per resolution
    unit. In pixels per inch, allowed XResolution values are: 100, 200,
    300, and 400. The base color fax mode requires the pixels to be
    square, hence YResolution must equal XResolution. Base resolution is
    200 pixels per inch and SHALL be supported by all implementations of
    this mode. See Section 2.2.2 for inch-metric equivalency.

NOTE: Not all combinations of XResolution, YResolution and ImageWidth
are legal. The following table gives the legal combinations for inch-
based resolutions and the corresponding paper sizes [T.30].
ToP   noToC   RFC2301 - Page 45
    +--------------------------------+---------------------------+
    |   XResolution x YResolution    |         ImageWidth        |
    +--------------------------------+---------------------------+
    |           100 x 100            |   864   |  1024  |  1216  |
    +--------------------------------+---------------------------+
    |           200 x 200            |  1728   |  2048  |  2432  |
    +--------------------------------+---------------------------+
    |           300 x 300            |  2592   |  3072  |  3648  |
    +--------------------------------+---------------------------+
    |           400 x 400            |  3456   |  4096  |  4864  |
    +--------------------------------+---------------------------+
                                     |Letter,A4|   B4   |   A3   |
                                     |  Legal  |        |        |
                                     +---------------------------+
                                     |         Paper Size        |
                                     +---------------------------+

6.2.2 Extension Fields

The JPEG compression standard allows for the a*b* chroma components of
an image to be subsampled relative to the L* lightness component. The
extension fields ChromaSubSampling and ChromaPositioning define the
subsampling. They are the same as YCbCrSubSampling and YCbCrPositioning
in [TIFF], but have been renamed to reflect their applicability to other
color spaces.

ChromaSubSampling(530).                                            SHORT
    Count = 2
    Specifies the subsampling factors for the chroma components of a
    L*a*b* image. The two subfields of this field, ChromaSubsampleHoriz
    and ChromaSubsampleVert, specify the horizontal and vertical
    subsampling factors respectively.

    SHORT 0: ChromaSubsampleHoriz = 1, 2.
    1: equal numbers of lightness and chroma samples horizontally,
    2: twice as many lightness samples as chroma samples horizontally,

    SHORT 1: ChromaSubsampleVert = 1, 2.
    1: equal numbers of lightness and chroma samples vertically,
    2: twice as many lightness samples as chroma samples vertically,

    The default value for ChromaSubSampling is (2,2), which is the
    default for chroma subsampling in color fax [T.4, Annex E]. No
    chroma subsampling, i.e. ChromaSubSampling = (1,1), is an option
    for color fax

ChromaPositioning(531) = 1.                                        SHORT
    Specifies the spatial positioning of chroma components relative to
ToP   noToC   RFC2301 - Page 46
    the lightness component.
    1: centered,
    A value of 1 means chrominance samples are spatially offset and
    centered with respect to luminance samples. See the current TIFF
    specification under YcbCr positioning for further information.
    Default = 1, which is what ITU-T T.4, Annex E specifies.

6.2.3. New Fields

Decode(433).                                                   SRATIONAL
    Count = 2 * SamplesPerPixel
    Describes how to map image sample values into the range of values
    appropriate for the current color space. In general, the values are
    taken in pairs and specify the minimum and maximum output value for
    each color component. For the base color fax mode, Decode has a
    count of 6 values and maps the unsigned ITULAB-encoded sample values
    (Lsample, asample, bsample) to signed L*a*b* values, as follows:.

        L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
        a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
        b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)

    where Decode[0], Decode[2] and Decode[4] are the minimum values for
    L*, a* and b*; Decode[1], Decode[3] and Decode[5] are the maximum
    values for L*, a* and b*; and n is the BitsPerSample, either 8 or
    12. For example, when n=8, L*=Decode[0] when Lsample=0 and
    L*=Decode[1] when Lsample=255.

    ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range
    and offset for each component, which are related to the minimum and
    maximum values as follows:

        minimum = - (range x offset) / 2^n - 1
        maximum = minimum + range

    The Decode field default values depend on the color space. For the
    ITULAB color space encoding, the default values correspond to the
    base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The
    following table gives the base range and offset values for
    BitsPerSample=8 and 12, and the corresponding default minimum and
    maximum default values for the Decode field, calculated using the
    equations above when PhotometricInterpetation=10.
ToP   noToC   RFC2301 - Page 47
                       +-----------------------------------------------+
                       | ITU-T Rec. T.42  |           Decode           |
 +---------+-----------|   base values    |       default values       |
 | BitsPer + Component +------------------+----------------------------+
 | -Sample |           |  Range | Offset  |      Min     |     Max     |
 +---------+-----------+--------+---------+--------------+-------------+
 |    8    |    L*     |   100  |    0    |       0      |     100     |
 |         +-----------+--------+---------+--------------+-------------+
 |         |    a*     |   170  |   128   |  -21760/255  |  21590/255  |
 |         +-----------+--------+---------+--------------+-------------+
 |         |    b*     |   200  |    96   |  -19200/255  |  31800/255  |
 +---------+-----------+--------+---------+--------------+-------------+
 |   12    |    L*     |   100  |    0    |       0      |     100     |
 |         +-----------+--------+---------+--------------+-------------+
 |         |    a*     |   170  |  2048   | -348160/4095 | 347990/4095 |
 |         +-----------+--------+---------+--------------+-------------+
 |         |    b*     |   200  |  1536   | -307200/4095 | 511800/4095 |
 +---------+-----------+--------+---------+--------------+-------------+

   For example, when PhotometricInterpretation=10 and BitsPerSample=8,
   the default value for Decode is (0, 100, -21760/255, 21590/255,
   -19200/255, 31800/255).

6.3. Recommended TIFF Fields

   See Sections 2.2.3. and 2.2.4.

6.4 Base Color Fax Mode Summary

   Recommended fields are shown with an asterisk *

   Required fields or values are shown with a double asterisk **. If the
   double asterisk is on the field name, then all the listed values are
   required of implementations; if the double asterisks are in the
   Values column, then only the values suffixed with a double asterisk
   are required of implementations.

       +---------------------------+--------------------------------+
       | Baseline Fields           | Values                         |
       +---------------------------+--------------------------------+
       | BitsPerSample             | 8**: 8 bits per color sample   |
       |                           | 12: optional 12 bits/sample    |
       +---------------------------+--------------------------------+
       | Compression**             | 7: JPEG                        |
       +---------------------------+--------------------------------+
       | DateTime*                 | {ASCII}: date/time in 24-hour  |
       |                           | format "YYYY:MM:DD HH:MM:SS"   |
       +---------------------------+--------------------------------+
ToP   noToC   RFC2301 - Page 48
       +------------------------------------------------------------+
       | FillOrder**               | 1: most significant bit first  |
       |                           | 2: least significant bit first |
       +---------------------------+--------------------------------+
       | ImageDescription*         | {ASCII}: A string describing   |
       |                           | the contents of the image.     |
       +---------------------------+--------------------------------+
       | ImageWidth                | 864, 1024, 1216, 1728**, 2048  |
       |                           | 2432, 2592, 3072, 3456, 3648   |
       |                           | 4096, 4864                     |
       +---------------------------+--------------------------------+
       | ImageLength**             | n: total number of scanlines   |
       |                           | in image                       |
       +---------------------------+--------------------------------+
       | NewSubFileType**          | 2: Bit 1 identifies single page|
       |                           | of a multi-page document       |
       +---------------------------+--------------------------------+
       | Orientation               | 1**-8, Default 1               |
       +---------------------------+--------------------------------+
       | PhotometricInterpretation | 10**: ITULAB                   |
       +---------------------------+--------------------------------+
       | ResolutionUnit**          | 2: inch                        |
       |                           | 3: centimeter                  |
       +---------------------------+--------------------------------+
       | RowsPerStrip**            | n: number of scanlines per     |
       |                           | TIFF strip                     |
       +---------------------------+--------------------------------+
       | SamplesPerPixel           | 1**: L* (lightness)            |
       |                           | 3: LAB                         |
       +---------------------------+--------------------------------+
       | Software*                 | {ASCII}: name & release number |
       |                           | of creator software            |
       +---------------------------+--------------------------------+
       | StripByteCounts**         | <n>: number or bytes in        |
       |                           | TIFF strip                     |
       +---------------------------+--------------------------------+
       | StripOffsets**            | <n>: offset from beginning     |
       |                           | of file to each TIFF strip     |
       +---------------------------+--------------------------------+
       | XResolution               | 100, 200**, 300, 400 (written  |
       |                           | in pixels/inch)                |
       +---------------------------+--------------------------------+
       | YResolution               | 100, 200**, 300, 400           |
       |                           | (must equal XResolution)       |
       +---------------------------+--------------------------------+
ToP   noToC   RFC2301 - Page 49
       +---------------------------+--------------------------------+
       | Extension Fields                                           |
       +---------------------------+--------------------------------+
       | DocumentName*             | {ASCII}: name of scanned       |
       |                           | document                       |
       +---------------------------+--------------------------------+
       | PageNumber**              | n,m: page number followed by   |
       |                           | total page count               |
       +---------------------------+--------------------------------+
       | ChromaSubSampling         | (1,1), (2, 2)**                |
       |                           | (1, 1): equal numbers of       |
       |                           | lightness and chroma samples   |
       |                           | horizontally and vertically    |
       |                           | (2, 2): twice as many lightness|
       |                           | samples as chroma samples      |
       |                           | horizontally and vertically    |
       +---------------------------+--------------------------------+
       | ChromaPositioning         | 1**: centered                  |
       +---------------------------+--------------------------------+
       | New Fields                                                 |
       +---------------------------+--------------------------------+
       | Decode**                  | minL, maxL, mina, maxa, minb,  |
       |                           | maxb: minimum and maximum      |
       |                           | values for L*a*b*              |
       +---------------------------+--------------------------------+
       | GlobalParametersIFD*      | IFD: IFD containing            |
       |                           | global parameters              |
       +---------------------------+--------------------------------+
       | ProfileType*              | n: type of data stored in      |
       |                           | TIFF file                      |
       +---------------------------+--------------------------------+
       | FaxProfile*               | n: ITU-compatible fax mode     |
       +---------------------------+--------------------------------+
       | CodingMethods*            | n: compression algorithms      |
       |                           | used in file                   |
       +---------------------------+--------------------------------+
       | VersionYear*              | byte sequence: year of ITU std |
       +---------------------------+--------------------------------+



(page 49 continued on part 3)

Next Section