3.  Profile S: Minimal Black-and-White Fax Profile

   This section defines the minimal black-and-white subset of TIFF for
   facsimile.  This subset is designated Profile S.  All implementations
   of TIFF for facsimile SHALL support the minimal subset.

   Black-and-white mode is the binary fax application most users are
   familiar with today.  This mode is appropriate for black-and-white
   text and line art.  Black-and-white mode is divided into two levels
   of capability.  This section describes the minimal interchange set of
   TIFF fields that must be supported by all implementations in order to
   assure that some form of image, albeit black-and-white, can be
   interchanged.  This minimum interchange set is a strict subset of the
   fields and values defined for the extended black-and-white profile
   (TIFF-F or Profile F) in Section 4, which describes extensions to the
   minimal interchange set of fields that provide a richer set of
   black-and-white capabilities.

3.1.  Overview

   The minimal interchange portion of the black-and-white facsimile mode
   supports 1-dimensional Modified Huffman (MH) compression, with the
   original Group 3 fax resolutions, commonly called "standard" and
   "fine."

   To assure interchange, this profile uses the minimal set of fields
   with a minimal set of values.  There are no recommended fields in
   this profile.  Further, the TIFF file is required to be "little-
   endian", which means that the byte order value in the TIFF header is
   "II".  This profile defines a required ordering for the pages in a
   fax document and for the IFDs and image data of a page.  It also
   requires

   that a single strip contain the image data for each page; see Section
   3.5.  The image data may contain RTC sequences, as specified in
   Section 3.4.

3.2.  Required TIFF Fields

   Besides the fields listed in Section 2.2.1, the minimal black-and-
   white fax profile requires the following fields.  The fields listed
   in Section 2.2.1 and the fields and fax-specific values specified in
   this subsection must be supported by all implementations.

3.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.
   SHORT
      RequiredByTIFFBaseline
      3 = 1- or 2- dimensional coding.
      The value 3 is a TIFF extension value [TIFF].  The T4Options field
      must be specified, and its value specifies that the data is
      encoded with the Modified Huffman (MH) compression of [T.4].

   FillOrder(266) = 2.
   SHORT
      RequiredByTIFFBaseline
      2 = Least Significant Bit first

      NOTE: Baseline TIFF readers are only required to support FillOrder
      1, where the lowest numbered pixel is stored in the MSB of the
      byte.  However, because many devices, such as modems, transmit the
      LSB first when converting the data to serial form, it is common
      for black-and-white fax products to use the second FillOrder = 2,
      where the lowest numbered pixel is stored in the LSB.  Therefore,
      this value is specified in the minimal black-and-white profile.

   ImageWidth(256) = 1728.
   SHORT or LONG
      RequiredByTIFFBaseline
      This profile only supports a page width of 1728 pixels.  This
      width corresponds to North American Letter and Legal and to ISO A4
      size pages.  No default, must be specified.

   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).

   PhotometricInterpretation(262) = 0.
   SHORT
      RequiredByTIFFBaseline
      0 = pixel value 1 means black.
      No default, must be specified.

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

   SamplesPerPixel(277) = 1.
   SHORT
      RequiredByTIFFBaseline
      The number of components per pixel; 1 for black-and-white.
      Default = 1 (field may be omitted if this is the value).

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

   YResolution(283) = 98, 100, 196, 200.
   RATIONAL
      RequiredByTIFFBaseline The vertical resolution of the image is
      expressed in pixels per resolution unit.  In pixels/inch, the
      allowed values are 98, 100, 196, and 200; 98 and 100 may be
      treated as equivalent, and 196 and 200 may be treated as
      equivalent.  See Section 2.2.2 for inch metric equivalency.  No
      default, must be specified.

3.2.2.  Extension fields

   T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
      LONG
      RequiredTIFFExtension (when Compression = 3)
      Bit 0 = 0 indicates MH compression.
      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 EOLs are not byte aligned)

   Note: The T4Options field is required when the Compression field has
   a value of 3.  Bit 0 of this field specifies the compression used (MH
   only in this profile).  MH coding requires the use of EOL (End of
   Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned
   or not.  See Section 3.4 for details.

3.2.3.  New Fields

   None.

3.3.  Recommended TIFF Fields

   None.

3.4.  End of Line (EOL) and Return to Control (RTC)

   TIFF extensions for fax, used in this specification, differ from
   Baseline TIFF in the following ways:

   -  A 12-bit EOL sequence MUST precede each line of MH-compressed
      image data.  (Baseline TIFF does not use these EOL sequences.)
   -  The EOL sequence MAY be byte-aligned, in which case fill bits are
      added so that the EOL sequence ends on a byte boundary, and any
      subsequent image data begins on a byte boundary.
   -  If the EOL codes are not byte aligned, the image data MAY be
      followed by an RTC (Return to Control) sequence, consisting of 6
      consecutive EOLs.

   In conventional fax, an MH-compressed fax data stream for a page
   consists of the following sequence:
      EOL, compressed data (first line), EOL, compressed data, ... ,
      EOL, compressed data (last line), RTC (6 consecutive EOL codes)

   Baseline TIFF does not use EOL codes or Return to Control (RTC)
   sequences for MH-compressed data.  However, the TIFF extension field
   T4Options used in this specification for MH compression (Compression
   = 3) requires EOLs.

   Furthermore, Bit 2 in the T4Options field indicates whether or not
   the EOL codes are byte aligned.  If Bit 2 = 1, indicating the EOL
   codes are byte aligned, then fill bits have been added as necessary
   before EOL codes so that an EOL code always ends on a byte boundary,
   and the first bit of data following an EOL begins on a byte boundary.
   Without fill bits, an EOL code may end in the middle of a byte.  Byte
   alignment relieves application software of the burden of bit-shifting
   every byte while parsing scanlines for line-oriented image
   manipulation (such as writing a TIFF file).  Not all TIFF readers
   historically used for fax are able to deal with non byte aligned
   data.

   While TIFF extension requires EOL codes, TIFF in fax applications has
   traditionally prohibited RTC sequences.  Implementations that seek
   common processing and interfaces for fax data streams and Internet
   fax files would prefer that the TIFF data include RTC sequences.

   To reconcile these differences, RTCs are allowed in cases where EOL
   codes are not byte aligned and no fill bits have been added to the
   data.  This corresponds to situations where the fax data is simply
   inserted in a strip without being processed or interpreted.  RTCs
   should not occur in the data when EOLs have been byte aligned.  This
   is formally specified in the next subsection.

3.4.1.  RTC Exclusion

   Implementations that seek to maintain strict conformance with TIFF
   and compatibility with the historical use of TIFF for fax SHOULD NOT
   include the RTC sequence when writing TIFF files.  However,
   implementations that need to support "transparency" of T.4-generated
   image data MAY include RTCs when writing TIFF files if the flag
   settings of the T4Options field are set for non byte aligned data,
   i.e., Bit 2 is 0.  Implementors of TIFF readers should be aware that
   there are some existing TIFF implementations for fax that include the
   RTC sequence in MH image data.  Therefore, minimal set readers MUST
   be able to process files that do not include RTCs and SHOULD be able
   to process files that do include RTCs.

3.5.  File Structure

   The TIFF header, described in Section 2.1.1, contains two bytes that
   describe the byte order used within the file.  For the minimal
   black-and-white profile, these bytes SHALL have the value "II"
   (0x4949), denoting that the bytes in the TIFF file are in LSByte-
   first order (little-endian).  The first or 0th IFD immediately
   follows the header, so offset to the first IFD is 8.  The header
   values are shown in the following table:

      +--------+-------------------+--------+-----------+
      | Offset |   Description     |     Value          |
      +--------+-------------------+--------+-----------+
      |   0    |   Byte Order      |  0x4949 (II)       |
      +--------+-------------------+--------+-----------+
      |   2    |   Identifier      |  42 decimal        |
      +--------+-------------------+--------+-----------+
      |   4    | Offset of 0th IFD |  0x 0000 0008      |
      +--------+-------------------+--------+-----------+

   The minimal black-and-white profile SHALL order IFDs and image data
   within a file as follows: (1) There SHALL be an IFD for each page in
   a multi-page fax document; (2) the IFDs SHALL occur in the same order
   in the file as the pages occur in the document; (3) the IFD SHALL
   precede the image data to which it has offsets; (4) the image data
   SHALL occur in the same order in the file as the pages occur in the
   document; (5) the IFD, the value data, and the image data to which it
   has offsets SHALL precede the next image IFD; and (6) the image data
   for each page SHALL be contained within a single strip.

   As a result of (6), the StripOffsets field will contain the pointer
   to the image data. With two exceptions, the field entries in the IFD
   contain the field values instead of offsets to field values located
   outside the IFD.  The two exceptions are the values for the
   XResolution and YResolution fields, both of which are type RATIONAL
   and require 2 4-byte numbers.  These "long" field values SHALL be
   placed immediately after the IFD which containing the offsets to
   them, and before the image data pointed to by that IFD.

   The effect of these requirements is that the IFD for the first page
   SHALL come first in the file after the TIFF header, followed by the
   long field values for XResolution and YResolution, followed by the
   image data for the first page, then the IFD for second page, and so
   on.  This is shown in the following figure.  Each IFD is required to
   have a PageNumber field, which has value 0 for the first page, 1 for
   the second page, and so on.

              +-----------------------+
              |         Header        |------------+
              +-----------------------+            | First IFD
              |      IFD (page 0)     | <----------+ Offset
          +---|                       |------------+
          |   |                       |--+         |
    Value |   +-----------------------+  |         |
   Offset +-->|      Long Values      |  |         |
              +-----------------------|  | Strip   |
              |  Image Data (page 0)  |<-+ Offset  |
              +-----------------------+            | Next IFD
              |      IFD (page 1)     | <----------+ Offset
          +---|                       |------------+
          |   |                       |--+         |
    Value |   +-----------------------+  |         |
   Offset +-->|      Long Values      |  |         |
              +-----------------------|  | Strip   |
              |  Image Data (page 1)  |<-+ Offset  |
              +-----------------------+            | Next IFD
              |      IFD (page 2)     | <----------+ Offset
              +-----------------------+
              |          :            |

   Using this file structure may reduce the memory requirements in
   implementations.  It also provides some support for streaming, in
   which a file can be processed as it is received and before the entire
   file is received.

3.6.  Profile S: Minimal Black-and-White Profile Summary

   The table below summarizes the TIFF fields that compose the minimal
   interchange set for black-and-white facsimile.  The Baseline and
   Extension fields and field values MUST be supported by all
   implementations.  For convenience, certain fields that have a value
   that is a sequence of flag bits are shown with integer values
   corresponding to the flags that are set.  An implementation should
   test the setting of the relevant flag bits individually, however, to
   allow extensions to the sequence of flag bits to be appropriately
   ignored.  (See, for example, T4Options below.)

   +---------------------------+--------------------------------+
   | Baseline Fields           |  Values                        |
   +---------------------------+--------------------------------+
   | BitsPerSample             | 1                              |
   +---------------------------+--------------------------------+
   | Compression               | 3: 1D Modified Huffman coding  |
   |                           |     set T4Options = 0 or 4     |
   +------------------------------------------------------------+

   +---------------------------+--------------------------------+
   | FillOrder                 | 2: least significant bit first |
   +---------------------------+--------------------------------+
   | ImageWidth                | 1728                           |
   +---------------------------+--------------------------------+
   | ImageLength               | n: total number of scanlines   |
   |                           | in image                       |
   +---------------------------+--------------------------------+
   | NewSubFileType            | 2: Bit 1 identifies single     |
   |                           | page of a multi-page document  |
   +---------------------------+--------------------------------+
   | PageNumber                | n,m: page number n followed by |
   |                           | total page count m             |
   +---------------------------+--------------------------------+
   | PhotometricInterpretation | 0: pixel value 1 means black   |
   +---------------------------+--------------------------------+
   | ResolutionUnit            | 2: inch                        |
   +---------------------------+--------------------------------+
   | RowsPerStrip              | number of scanlines per strip  |
   |                           | = ImageLength, with one strip  |
   +---------------------------+--------------------------------+
   | SamplesPerPixel           | 1                              |
   +---------------------------+--------------------------------+
   | StripByteCounts           | number of bytes in TIFF strip  |
   +---------------------------+--------------------------------+
   | StripOffsets              | offset from beginning of       |
   |                           | file to single TIFF strip      |
   +---------------------------+--------------------------------+
   | XResolution               | 204, 200 (pixels/inch)         |
   +---------------------------+--------------------------------+
   | YResolution               | 98, 196, 100, 200 (pixels/inch)|
   +---------------------------+--------------------------------+
   | Extension Fields                                           |
   +---------------------------+--------------------------------+
   | T4Options                 | 0: MH coding, EOLs not byte    |
   |                           |               aligned          |
   |                           | 4: MH coding, EOLs byte aligned|
   +---------------------------+--------------------------------+

4.  Profile F: Extended Black-and-White fax profile

   This section defines the extended black-and-white profile or Profile
   F of TIFF for facsimile.  It provides a standard definition of what
   has historically been known as TIFF Class F and now as TIFF-F.  In
   doing so, it aligns this profile with current ITU-T Recommendations
   for black-and-white fax and with existing industry practice.
   Implementations of this profile include implementations of Profile S.

   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 compression, Modified READ
   (MR) and Modified Modified READ (MMR) compression, 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 profile.  Section 4.3
   describes the fields that MAY be used in this profile.  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 of TIFF-F use.  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 use 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 profile of
   TIFF for facsimile.

   Up until the TIFF 6.0 specification, TIFF supported various "Classes"
   that 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 that 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.

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 profile 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
   compression, but data is presented in a form that 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 profile supports the following fixed page widths: 1728, 2592,
      3456 (corresponding to North American Letter and Legal and 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 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 measurement.
      Default = 2 (field may be omitted if this is the value).

   SamplesPerPixel(277) = 1.
   SHORT
      RequiredByTIFFBaseline
      1 = monochrome, bi-level 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
      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 sizes [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 compression, = 0 indicates MH compression.
      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 compression is used and
      EOLs are not byte aligned) (See Section 3.2.2.)  The T4Options
      field is required when the Compression field has a value of 3.
      This field specifies the compression used (MH or MR) and whether
      the EOL codes are byte aligned or not.  If they are byte 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
      (MMR) 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 that 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

   See Section 2.2.4 and optional fields below.

   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 scanlines.  A
   "good" scan line is defined as a line that, when decoded, contains
   the correct number of pixels.  Conversely, a "bad" scanline is
   defined as a line that, when decoded, contains an incorrect number of
   pixels.

   BadFaxLines(326)
   SHORT or LONG
      The number of "bad" scanlines 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 whether "bad" lines encountered during reception are
      stored in the data, or whether "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 whether 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
   strips, a TIFF reader need not load the entire image into memory,
   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,
   most 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 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
   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 commonly
   used 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.

   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, TIFF-F has required readers and writers to be able to
   handle multi-page TIFF-F files.  The experience of various TIFF-F
   implementors has shown that implementing 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
   document page.  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 offsets for each image strip are defined from within
   each IFD.  Where possible, another guideline for TIFF-F writers is
   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).
   A single image strip per page further simplifies TIFF-F file writing
   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 that require "streaming" techniques (see section 4.4.7).
   If 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 related to strips.

   Another simplifying guideline is that each IFD SHOULD be placed in
   the TIFF-F file structure at a point preceding the image that the IFD
   describes.

   In addition, placing the image data in a physical order within the
   TIFF file structure which is consistent with the logical page order
   simplifies TIFF-F file writing and reading.  In practice, TIFF-F
   readers will need to use the strip 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 from the top of the
   page.

   TIFF-F writers MAY follow another 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
   compared to the others given here.

   In the case of the minimal profile, which is also the minimal subset
   of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs
   (see Section 3.5).

   A TIFF-F file structured using the guidelines of this section will
   essentially consist of a linked list of IFDs, presented in ascending
   page order, each pointing 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 sequence 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.  Although TIFF-F may also be
   used as a file format for cases such as streaming applications,
   assumptions differing from those provided in this section (e.g., the
   entire size and number of pages within the image are not known in
   advance) may be required.  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.  The "Uncompressed" bit in T4Options or T6Options must
   be set to 0.

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 who wish to have the maximum flexibility in reading
   TIFF-F files should support all three of these compression methods
   (MH, MR, and MMR).

   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, and 400 x 400 in dots
   per inch-based units.  At the same time, support was added for metric
   dimensions 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, as 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 not to support these
   higher resolutions.

   Per [T.4], it is permissible for applications to treat the following
   XResolution values as equivalent: <204,200> and <400,408>.
   Similarly, the following YResolution values may also be treated as
   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.

   The optional support of metric-based resolutions in the TIFF-F reader
   (i.e., 77 x 38.5 cm) is included for completeness, as 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 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 so 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 compression 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 compression, 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], MH-encoded facsimile
   documents begin with an EOL, which in TIFF-F may be byte-aligned.
   The last line of the image is not terminated by an EOL.  Similarly,
   respect, images encoded with Modified READ two-dimensional
   compression 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 seeking 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 intended 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 that include the RTC sequence in MH/MR image
   data.  Therefore, TIFF-F readers MUST be able to process files that
   do not include RTCs and SHOULD be able to process files that do
   include RTCs.

4.5.6.  Use of EOFB for T.6 Compressed Images

   TIFF-F pages 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 [VPIM 2].  Voice messaging systems
   can often handle fax store-and-forward capabilities in addition to
   traditional 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.  Profile F: Extended Black-and-white Fax Profile 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 |
   +------------------------------------------------------------+
   | 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                                           |
   +---------------------------+--------------------------------+
   | 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           |
   +---------------------------+--------------------------------+
   | GlobalParametersIFD*      | IFD: global parameters IFD     |
   +---------------------------+--------------------------------+
   | ProfileType*              | n: type of data stored in file |
   +---------------------------+--------------------------------+
   | FaxProfile*               | n: ITU-compatible fax profile  |
   +---------------------------+--------------------------------+
   | CodingMethods*            | n: compression algorithms used |
   |                           | in file                        |
   +---------------------------+--------------------------------+