ZVON > RFC Repository > RFC 2301
Prev | Next | RFC index | RFC search Download as zip/tar.gz

3. Minimal Black-and-White Fax Mode

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 mode (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 mode uses the minimal set of fields, with a minimal set of values. There are no recommended fields in this mode. Further, the TIFF file is required to be "little endian," which means that the byte order value in the TIFF header is "II". This mode 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 mode requires the following fields. The fields listed in Section 2.2.1 and the fields and fax-specific values specified in this sub- section 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
    using the Modified Huffman (MH) encoding 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 mode.

ImageWidth(256) = 1728.                                    SHORT or LONG
    RequiredByTIFFBaseline
    This mode 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 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 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 encoding used (MH
   only in this mode) and Bit 2 indicates 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 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)

   The handling of End of Line (EOL) codes and Return to Control (RTC)
   sequences illustrate the differences between conventional fax, which
   is bit and stream oriented, and TIFF, which is byte and file
   oriented. Conventional fax, Baseline TIFF and TIFF extensions for fax
   all handle EOLs and RTCs differently.

   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 scan lines 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 want
   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 sub-section.

3.4.1. RTC Exclusion

   Implementations which wish 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 which 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 which do not include RTCs and SHOULD be able to
   process files which do include RTCs.

3.5. File Structure

   The TIFF header, described in Section 2.1.1, contains two bytes which
   describe the byte order used within the file. For the minimal black-
   and- white mode, 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 that offset to the first IFD is 8. The headers 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 mode 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 it has
   offsets to 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 contains 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, etc.
   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 is 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. Minimal Black-and-white Mode Summary

   The table below summarizes the TIFF fields that comprise 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 in the table, certain fields which
   have a value that is a sequence of flag bits are shown taking integer
   values that correspond 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|
      +---------------------------+--------------------------------+

ZVON > RFC Repository > RFC 2301
Prev | Next | RFC index | RFC search Download as zip/tar.gz