Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2301

File Format for Internet Fax

Pages: 77
Obsoleted by:  3949
Part 1 of 3 – Pages 1 to 24
None   None   Next

ToP   noToC   RFC2301 - Page 1
Network Working Group                                       L. McIntyre
Request for Comments: 2301                            Xerox Corporation
Category: Standards Track                                     S. Zilles
                                                    Adobe Systems, Inc.
                                                             R. Buckley
                                                      Xerox Corporation
                                                             D. Venable
                                                      Xerox Corporation
                                                             G. Parsons
                                                       Northern Telecom
                                                            J. Rafferty
                                                   Human Communications
                                                             March 1998



                      File Format for Internet Fax


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document describes the TIFF (Tag Image File Format)
   representation of image data specified by the ITU-T Recommendations
   for black-and-white and color facsimile. This file format
   specification is commonly known as TIFF-FX. It formally defines
   minimal, extended and lossless JBIG modes (Profiles S, F, J) for
   black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster
   Content modes (Profiles C, L, M) for color and grayscale fax. These
   modes or profiles correspond to the content of the applicable ITU-T
   Recommendations. Files formatted according to this specification use
   the image/tiff MIME Content Type.
ToP   noToC   RFC2301 - Page 2
Table of Contents

 1. INTRODUCTION.......................................................4
   1.1. Scope..........................................................5
   1.2. Approach.......................................................5
   1.3. Overview of this draft.........................................5
 2. TIFF and Fax.......................................................7
   2.1. TIFF Overview..................................................7
     2.1.1. File Structure.............................................7
     2.1.2. Image Structure............................................9
     2.1.3. TIFF File Structure for Fax Applications..................10
   2.2 TIFF Fields for All Fax Applications...........................11
     2.2.1. TIFF Fields required for all fax modes....................12
     2.2.2. Additional TIFF Fields required for all fax modes.........13
     2.2.3. TIFF Fields recommended for all fax modes.................15
     2.2.4. New TIFF Fields recommended for fax modes.................16
 3. Minimal Black-and-White Fax Mode..................................18
   3.1. Overview......................................................18
   3.2. Required TIFF Fields..........................................18
     3.2.1 Baseline Fields............................................18
     3.2.2 Extension Fields...........................................20
     3.2.3 New Fields.................................................20
   3.3. Recommended TIFF Fields.......................................20
   3.4. End of Line (EOL) and Return to Control (RTC).................20
     3.4.1 RTC Exclusion..............................................21
   3.5. File Structure................................................22
   3.6. Minimal Black-and-White Mode Summary..........................23
 4. Extended Black-and-White Fax Mode.................................24
   4.1. TIFF-F Overview...............................................25
   4.2. Required TIFF Fields..........................................26
     4.2.1. Baseline Fields...........................................26
     4.2.2. Extension Fields..........................................28
     4.2.3. New Fields................................................29
   4.3. Recommended TIFF Fields.......................................29
     4.3.1. Baseline Fields...........................................29
     4.3.2. Extension Fields..........................................29
     4.3.3. New Fields................................................29
   4.4. Technical Implementation Issues...............................30
     4.4.1. Strips....................................................30
     4.4.2. Bit Order.................................................31
     4.4.3. Multi-Page................................................31
     4.4.4. Compression...............................................31
     4.4.5. Example Use of Page-quality Fields........................32
     4.4.6. Practical Guidelines for Writing and Reading Multi-Page
            TIFF-F Files..............................................33
     4.4.7. Use of TIFF-F for Streaming Applications..................34
   4.5. Implementation Warnings.......................................34
     4.5.1. Uncompressed Data.........................................34
ToP   noToC   RFC2301 - Page 3
     4.5.2. Encoding and Resolution...................................35
     4.5.3. EOL byte-aligned..........................................35
     4.5.4. EOL.......................................................36
     4.5.5. RTC Exclusion.............................................36
     4.5.6. Use of EOFB for T.6 Compressed Images.....................37
   4.6. Example Use of TIFF-F.........................................37
   4.7. Extended Black-and-white Fax Mode Summary.....................37
 5. Lossless JBIG Black-and-White Fax Mode............................39
   5.1. Overview......................................................40
   5.2. Required TIFF Fields..........................................40
     5.2.1. Baseline Fields...........................................40
     5.2.2. Extension Fields..........................................40
     5.2.3. New Fields................................................41
   5.3. Recommended TIFF Fields.......................................41
   5.4. Lossless JBIG Black-and-White Mode Summary....................41
 6. Base Color Fax Mode...............................................43
   6.1. Overview......................................................43
   6.2. Required TIFF Fields..........................................43
     6.2.1. Baseline Fields...........................................43
     6.2.2. Extension Fields..........................................45
     6.2.3. New Fields................................................46
   6.3. Recommended TIFF Fields.......................................47
   6.4. Base Color Fax Mode Summary...................................47
 7. Lossless Color Mode...............................................49
   7.1. Overview......................................................50
     7.1.1. Color Encoding............................................50
     7.1.2. JBIG Encoding.............................................50
   7.2. Required TIFF Fields..........................................51
     7.2.1. Baseline Fields...........................................51
     7.2.2. Extension Fields..........................................52
     7.2.3. New Fields................................................53
   7.3. Recommended TIFF Fields.......................................53
   7.4. Lossless Color Fax Mode Summary...............................53
 8. Mixed Raster Content Mode.........................................55
   8.1 Overview.......................................................55
     8.1.1. MRC 3-layer model.........................................55
     8.1.2. A TIFF Representation for the MRC 3-layer model...........56
   8.2. Required TIFF Fields..........................................58
     8.2.1. Baseline Fields...........................................58
     8.2.2. Extension Fields..........................................59
     8.2.3. New Fields................................................60
   8.3. Recommended TIFF Fields.......................................62
   8.4. Rules and Requirements for Images.............................62
   8.5. MRC Fax Mode Summary..........................................63
 9. MIME content-type image/tiff......................................66
   9.1 Refinement of MIME content-type image/tiff for Facsimile
       Applications...................................................66
 10. Security Considerations..........................................67
ToP   noToC   RFC2301 - Page 4
 11. References.......................................................67
 12. Authors' Addresses...............................................69
 Annex A: Summary of TIFF Fields for Internet Fax ....................70
 Annex B. IANA Registration for image/tiff Application Parameter
          Values used for facsimile...................................75
 Full Copyright Statement.............................................77

1. Introduction

   This document describes the use of TIFF (Tag Image File Format) to
   represent the data content and structure generated by the current
   suite of ITU-T Recommendations for Group 3 facsimile. These
   Recommendations and the TIFF fields described here support the
   following facsimile modes or profiles:

      S:  minimal black-and-white mode, using binary MH compression
             [T.4]
      F:  extended black-and-white mode, using binary MH, MR and MMR
             compression [T.4, T.6]
      J:  lossless JBIG black-and-white mode, with JBIG compression
             [T.85, T.82]
      C:  lossy color and grayscale mode, using JPEG compression
             [T.42, T.81]
      L:  lossless color and grayscale mode, using JBIG compression
             [T.43, T.82]
      M:  mixed raster content mode [T.44], using a combination of
             existing compression methods

   Each profile corresponds to the content of ITU-T Recommendations
   shown and is a subset of the full TIFF for facsimile specification.

   Profile S describes a minimal interchange set of fields, which will
   guarantee that, at least, binary black-and-white images will be
   supported. Implementations are required to support this minimal
   interchange set of fields.

   With the intent of specifying a file format for Internet Fax, this
   draft:

       1.  specifies the structure of TIFF files for facsimile data,
       2.  defines ITU fax-compatible values for existing TIFF fields,
       3.  defines new TIFF fields and values required for compatibility
           with ITU color fax.

   This specification of TIFF for facsimile is known as TIFF-FX.
ToP   noToC   RFC2301 - Page 5
1.1 Scope

   This document defines a TIFF-based file format specification for
   enabling standardized messaging-based fax over the Internet. It
   specifies the TIFF fields and field values required for compatibility
   with the existing ITU-T Recommendations for Group 3 black-and-white,
   grayscale and color facsimile. TIFF has historically been used for
   handling fax image files in applications such as store-and-forward
   messaging.  Implementations that support this file format
   specification for import/export may elect to support it as a native
   format. This document recommends a TIFF file structure that is
   compatible with low-memory and page-level streaming implementations.

   Unless otherwise noted, the current TIFF specification [TIFF] and
   selected TIFF Technical Notes [TTN1, TTN2] are the primary references
   for describing TIFF and defining TIFF fields. This document is the
   primary reference for defining TIFF field values for fax
   applications.

1.2 Approach

   The basic approach to using TIFF for facsimile data is to insert the
   compressed fax image data in a TIFF file and use TIFF fields to
   encode the parameters that describe the image data. These fields will
   have values that comply with the ITU-T Recommendations. The MIME
   content type of the resulting file will be image/tiff, with an
   optional Application parameter [TIFF-REG]; see Section 9.

   This approach takes advantage of TIFF features and structures that
   bridge the data formats and performance requirements of both legacy
   fax machines and host-based fax applications. TIFF constructs for
   pages, images, and strips allow a TIFF file to preserve the fax data
   stream structure and the performance advantages that come with it. A
   TIFF-based approach also builds on an established base of users and
   implementors and ensures backward compatibility with existing TIFF-
   based IETF proposals and work in progress for Internet fax.

1.3 Overview of this draft

   Section 2 gives an overview of TIFF. Section 2.1 describes the
   structure of TIFF files, including general guidelines for structuring
   multi-page TIFF files. Section 2.2 lists the TIFF fields that are
   required or recommended for all fax modes. The TIFF fields used only
   by specific fax modes are described in Sections 3-8, which describe
   the individual fax modes. These sections also specify the ITU-
   compatible field values (image parameters) for each mode.
ToP   noToC   RFC2301 - Page 6
   The full set of permitted fields of TIFF for facsimile are included
   in the current TIFF specification, Section 2 of this document and the
   sections on specific modes of facsimile operation. This document
   defines profiles of TIFF for facsimile, where a profile is a subset
   of the full set of permitted fields and field values of TIFF for
   facsimile.

   Section 3 defines the minimal black-and-white facsimile mode (Profile
   S), which is required in all implementations. Section 4 defines the
   extended black-and-white fax mode (Profile F), which provides a
   standard definition of TIFF-F. Section 5 describes the lossless
   black-and-white mode using JBIG compression (Profile J). Section 6
   defines the base color mode, required in all color implementations,
   for the lossy JPEG representation of color and grayscale facsimile
   data (Profile C). Section 7 defines the lossless JBIG color and
   grayscale facsimile mode (Profile L) and Section 8 defines the Mixed
   Raster Content facsimile mode (Profile M). Each of these sections
   concludes with a table summarizing the required and recommended
   fields for each mode and the values they can have.

   Section 9 describes the MIME content type image/tiff and the use of
   the optional Application parameter in connection with TIFF for
   facsimile. Sections 10, 11, 12 and 13 give Security Considerations,
   the ISOC Copyright Notice, References and Authors' Addresses. Annex A
   gives a summary of the TIFF fields used or defined in this document
   and provides a convenient reference for implementors.

   To implement only the minimal interchange black-and-white set of
   fields and values (Profile S), one need read only Sections 1, 2, 3, 9
   and 10.

   The following tree diagram shows the relationship among profiles and
   between profiles and coding methods.

                                S (MH)
                               / \
                       B&W    /   \   Color
                  ------------     ----------
                 /      \                    \
                /        F (MMR, MR)          C (JPEG)
               /                             / \
              J (JBIG)                   ----   \
                                        /        \
                                       L (JBIG)   \
                                                   \
                                                    M (MRC)

   A profile is based on a collection of ITU-T facsimile coding methods.
ToP   noToC   RFC2301 - Page 7
   For example, Profile S, the minimal mode, is based on Modified
   Huffman (MH) compression, which are defined in ITU-T Rec. T.4.
   Profile F specifies Modified Read (MR) and Modified Modified Read
   (MMR) compressions, which are defined in ITU-T Rec. T.4 and T.6.

   All implementations of TIFF for facsimile MUST implement Profile S,
   which is the root node of the tree. All color implementations of TIFF
   for facsimile MUST implement Profile C. The implementation of a
   particular profile MUST also implement those profiles on the path
   that connect it to the root node, and MAY optionally implement
   profiles not on the path connecting it to the root node. For example,
   an implementation of Profile M must also implement Profiles C and S,
   and may optionally implement Profile F, J or L. For another example,
   an implementation of Profile C must also implement Profile S, and may
   optionally implement Profile F or J.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [REQ].

2. TIFF and Fax

2.1. TIFF Overview

   TIFF provides a means for describing, storing and interchanging
   raster image data. A primary goal of TIFF is to provide a rich
   environment within which applications can exchange image data. The
   current TIFF specification [TIFF] defines a commonly used, core set
   of TIFF fields known as Baseline TIFF. The current specification and
   TIFF Technical Notes 1 and 2 [TTN1, TTN2] define several TIFF
   extensions. The TIFF- based specification for fax applications uses a
   subset of Baseline TIFF fields, with selected extensions, as
   described in this document. In a few cases, this document defines new
   TIFF fields specifically for fax applications.

2.1.1. File Structure

   TIFF is designed for raster images, which makes it a good match for
   facsimile documents, which are multi-page raster images. Each raster
   image consists of a number of rows or scanlines, each of which has
   the same number of pixels, the unit of sampling. Each pixel has at
   least one sample or component (exactly one for black-and-white
   images).

   A TIFF file begins with an 8-byte image file header. The first two
   bytes describe the byte order used within the file. Legal values are
   "II" (0x4949) when bytes are ordered from least to most significant
   (little- endian), and "MM" (0x4D4D), when bytes are ordered from most
ToP   noToC   RFC2301 - Page 8
   to least significant (big-endian) within a 16- or 32-bit integer.
   Either byte order can be used, except in the case of the minimal
   black-and-white mode, which SHALL use value "II". The next two bytes
   contain the value 42 that identifies the file as a TIFF file and is
   ordered according to the value in the first two bytes of the header.
   The last four bytes give the offset that points to the first image
   file directory (IFD). This and all other offsets in a TIFF file are
   with respect to the beginning of the TIFF file. An IFD can be at any
   location in the file after the header but must begin on a word
   boundary.

   An IFD is a sequence of tagged fields, sorted in ascending order by
   tag value. An IFD consists of a 2-byte count of the number of fields,
   a sequence of field entries and a 4-byte offset to the next IFD. The
   fields contain information about the image and pointers to the image
   data. Each separate raster image in the file is represented by an
   IFD.

   Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag,
   2 bytes identifying the field type (e.g. short, long, rational,
   ASCII), 4 bytes giving the count (number of values or offsets), and 4
   bytes that either contain the offset to a field value stored outside
   the IFD, or, based on the type and count, the field value itself.
   Resolution and metadata such as dates, names and descriptions are
   examples of "long" field values that do not fit in 4 bytes and
   therefore use offsets in the field entry. Details are given in the
   TIFF specification [TIFF].

   A TIFF file can contain more than one IFD, where each IFD is a
   subfile whose type is given in the NewSubfileType field. Multiple
   IFDs can be organized either as a linked list, with the last entry in
   each IFD pointing to the next IFD (the pointer in the last IFD is 0),
   or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The
   SubIFDs field contains an array of pointers to child IFDs of the
   primary IFD.

   Child IFDs describe related images, such as reduced resolution
   versions of the primary IFD image. The same IFD can point both to a
   next IFD and to child IFDs, and child IFDs can themselves point to
   other IFDs.

   All fax modes represent a multi-page fax image as a linked list of
   IFDs, with a NewSubfileType field containing a bit that identifies
   the IFD as one page of a multi-page document. Each IFD has a
   PageNumber field, identifying the page number in ascending order,
   starting at 0 for the first page. While a Baseline TIFF reader is not
ToP   noToC   RFC2301 - Page 9
   required to read any IFDs beyond the first, an implementation that
   reads the files that comply with this specification SHALL read
   multiple IFDs. Only the Mixed Raster Content fax mode, described in
   Section 8, requires the use of child IFDs.

   The following figure illustrates the structure of a multi-page TIFF
   file.

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

2.1.2 Image Structure

   An IFD stores an image as one or more strips, as shown in the
   preceding figure. A strip consists of 1 or more scanlines (rows) of
   raster image data in compressed form. An image may be stored in a
   single strip or may be divided into several strips, which would
   require less memory to buffer. (Baseline TIFF recommends about 8k
   bytes per strip, but existing fax usage is typically one strip per
   image.)
ToP   noToC   RFC2301 - Page 10
   Each IFD requires three strip-related fields: StripOffsets,
   RowsPerStrip and StripByteCounts. The StripOffsets field is an array
   of pointers to the strip or strips that contain the actual image
   data. The StripByteCounts field gives the number of bytes in each
   strip after compression. TIFF requires that each strip, except the
   last, contain the same number of scanlines, which is given in the
   RowsPerStrip field. This document introduces the new StripRowCounts
   field that allows a variable number of scanlines per strip, which is
   required by the Mixed Raster Content fax mode (Section 8).

   Image data is stored as uninterpreted, compressed image data streams
   within a strip. The formats of these streams follow the ITU-T
   Recommendations. The Compression field in the IFD indicates the type
   of compression, and other TIFF fields in the IFD describe image
   attributes, such as color encoding and spatial resolution.
   Compression parameters are stored in the compressed data stream,
   rather than in TIFF fields. This makes the TIFF representation and
   compressed data format specification independent of each another.
   This approach, modeled on [TTN2], allows TIFF to gracefully add new
   compression schemes as they become available.

   Some attributes can be specified both in the compressed data stream
   and within a TIFF field. It is possible that the two values will
   differ. When this happens for values required to interpret the data
   stream, then the values in the data stream take precedence. For
   informational values that are not required to interpret the data
   stream, such as author name, then the TIFF field value takes
   precedence.

2.1.3 TIFF File Structure for Fax Applications

   The TIFF specification has a very flexible file structure, which does
   not specify the ordering of IFDs, field values and image data in a
   file. Individual applications may require or recommend an ordering.

   This specification recommends that when using a TIFF file for
   facsimile, A multi-page fax document SHOULD be represented as a
   linked list of IFDs. It also recommends that a TIFF file for
   facsimile SHOULD order pages in a TIFF file in the same way that they
   are ordered in a fax data stream. In a TIFF file, a page consists of
   several elements: one or more IFDs (including subIFDs), long field
   values that are stored outside the IFDs, and image data (in one or
   more strips).

   The minimal black-and-white mode (Profile S) specifies a required
   ordering of pages and elements within a page (Section 3.5). The
   extended black-and-white mode (Profile F) provides guidelines for
   ordering pages and page elements (Section 4.4.6). Other profiles
ToP   noToC   RFC2301 - Page 11
   SHOULD follow these guidelines. This recommendation is intended to
   simplify the implementation of TIFF writers and readers in fax
   applications and the conversion between TIFF file and fax data stream
   representations. However, for interchange robustness, readers SHOULD
   be prepared to read TIFF files whose structure is consistent with
   [TIFF], which supports a more flexible file structure than is
   recommended here.

   This specification introduces an optional new GlobalParametersIFD
   field, defined in Section 2.2.4. This field has type IFD and
   indicates parameters describing the fax session. While it is often
   possible to obtain these parameters by scanning the file, it is
   convenient to make them available together in one place for fast and
   easy access. If the GlobalParametersIFD occurs in a TIFF file, it
   SHOULD be located in the first IFD, immediately following the 8-byte
   image file header.

2.2 TIFF Fields for All Fax Applications

   The TIFF specification [TIFF] is organized as a baseline set and
   several extensions, including technical notes [TTN1, TTN2] that will
   be incorporated in the next release of TIFF. The baseline and
   extensions have required and optional fields.

   Facsimile applications require (and recommend) a mixture of baseline
   and extensions fields, as well as some new fields that are not part
   of the TIFF specification and that are defined in this document. This
   sub- section lists the fields that are required or recommended for
   all modes. In particular, Section 2.2.1 lists the fields that are
   required by all modes and that have values that do not depend on the
   mode. Section 2.2.2 lists the fields that are required by all modes
   and that have values which do depend on the mode. Section 2.2.3 lists
   the fields that are recommended for all modes. Fields that are
   required or recommended by some but not all modes are given in the
   section (Section 3-8) that describes that mode. The sections for each
   fax mode have sub-sections for required and recommended fields; each
   sub-section organizes the fields according to whether they are
   baseline, extension or new.

   The fields required for facsimile have only a few legal values,
   specified in the ITU-T Recommendations. Of these legal values, some
   are required and some are optional, just as they are required
   (mandatory) or optional in fax implementations that conform to the
   ITU-T Recommendations. The required and optional values are noted in
   the sections on the different fax modes.
ToP   noToC   RFC2301 - Page 12
   This section describes the fields required or recommended by all fax
   modes. The pattern for the description of TIFF fields in this draft
   is:

FieldName(TagValueInDecimal) = allowable values.                    TYPE
    WhetherRequiredByTIFForTIFFforFAX
    Count = (omitted if =1) = (if not in current spec but available)
    Explanation of the field, how it's used, and the values it can have.
    Default value, if any, as specified in [TIFF]

   When a field's default value is the desired value, that field may be
   omitted from the relevant IFD unless specifically required by the
   text of this specification.

2.2.1.  TIFF fields required for all fax modes

   The TIFF fields listed in this section SHALL be used by all fax
   modes, but have field values that are not specified by the ITU
   standards, i.e. the fields do not depend on the mode. The next sub-
   section lists the fields that SHALL be used by all fax modes, but
   which do have values specified by the ITU-specified or mode-specific
   values. Fields that SHALL be used by some but not all modes are given
   in the sections (3-8) which describe the modes that uses them.

ImageLength(257)                                           SHORT or LONG
    RequiredByTIFFBaseline
    Total number of scanlines in image.
    No default, must be specified.

PageNumber(297)                                                    SHORT
    RequiredByTIFFforFAX, TIFFExtension
    Count = 2
    The first number represents the page number (0 for the first page);
    the second number is the total number of pages in the document. If
    the second value is 0, then the total page count is not available.
    No default, must be specified

RowsPerStrip(278)                                          SHORT or LONG
    RequiredByTIFFBaseline
    The number of scanlines per TIFF strip, except for the last strip.
    For a single strip image, this is the same as the value of the
    ImageLength field.
    Default = 2**32 - 1 (meaning all scanlines in one strip)

StripByteCounts(279)                                       SHORT or LONG
    RequiredByTIFFBaseline
    Count = number of strips
    For each strip, the number of bytes in that strip after compression.
ToP   noToC   RFC2301 - Page 13
    No default, must be specified.

StripOffsets(273)                                          SHORT or LONG
    RequiredByTIFFBaseline
    Count = number of strips
    For each strip, the byte offset from the beginning of the file to
    the start of that strip.
    No default, must be specified.

2.2.2 Additional TIFF fields required for all fax modes

   The TIFF fields listed in this section SHALL be used by all fax
   modes, but the values associated with them depend on the mode being
   described and the associated ITU Recommendations. Therefore, only the
   fields are defined here; the values applicable to a particular fax
   mode are described in Sections 3-8. Fields that SHALL be used by some
   but not all modes are given in the section (3-8) describing the mode
   that uses them.

BitsPerSample(258)                                                 SHORT
    RequiredByTIFFBaseline
    Number of bits per image sample
    Default = 1 (field may be omitted if this is the value)

Compression(259)                                                   SHORT
    RequiredByTIFFBaseline
    Compression method used for image data
    Default = 1 (no compression, so may not be omitted for FAX)

FillOrder(266)                                                     SHORT
    RequiredByTIFFforFax
    The default bit order in Baseline TIFF per [TIFF] is indicated by
    FillOrder=1, where bits are not reversed before being stored.
    However, TIFF for Fax typically utilizes the setting of FillOrder=2,
    where the bit order within bytes is reversed before storage (i.e.,
    bits are stored with the Least Significant Bit first).
    Default = 1 (field may be omitted if this is the value)
    Facsimile data appears on the phone line in bit-reversed order
    relative to its description in the relevant ITU compression
    Recommendation. Therefore, a wide majority of facsimile
    implementations choose this natural order for storage. Nevertheless,
    all readers conforming to this specification must be able to read
    data in both bit orders.

ImageWidth(256)                                            SHORT or LONG
    RequiredByTIFFBaseline
    The number of pixels (columns) per scanline (row) of the image
    No default, must be specified.
ToP   noToC   RFC2301 - Page 14
NewSubFileType(254)                                                 LONG
    RequiredByTIFFforFAX
    A general indication of the kind of data contained in this IFD
    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)                                     SHORT
    RequiredByTIFFBaseline
    The color space of the image data
    No default, must be specified

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

SamplesPerPixel(277)                                               SHORT
    RequiredByTIFFBaseline
    The number of color components per pixel; SamplesPerPixel is 1 for a
    black-and-white, grayscale or indexed (palette) image.
    Default =1 (field may be omitted if this is the value)

XResolution(282)                                                RATIONAL
    RequiredByTIFFBaseline
    The horizontal resolution of the image in pixels per resolution
    unit. The ITU-T Recommendations for facsimile specify a small number
    of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and
    80, 160 pixels per centimeter (or 204, 408 pixels per inch). The
    allowed XResolution values for each mode are given in the section
    defining that mode. Per [T.4], it is permissible for applications to
    treat the following XResolution values as being equivalent: <204,
    200> and <400,408> in pixels/inch. These equivalencies were allowed
    by [T.4] to permit conversions between inch and metric based
    facsimile terminals.
    TIFF for Facsimile Writers SHOULD express XResolution in inch based
    units, for consistency with historical practice and to maximize
    interoperability. See the table below for information on how to
    convert from an ITU-T metric value to its inch based equivalent
    resolution.
    No default, must be specified

YResolution(283)                                                RATIONAL
    RequiredByTIFFBaseline
    The vertical resolution of the image in pixels per resolution unit.
    The ITU-T Recommendations for facsimile specify a small number of
    vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5,
    77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The
    allowed YResolution values for each mode are given in the section
ToP   noToC   RFC2301 - Page 15
    defining that mode. Per [T.4], it is permissible for applications to
    treat the following YResolution values as being equivalent: <98,
    100>, <196, 200>, and <391, 400> in pixels/inch. These equivalencies
    were allowed by [T.4] to permit conversions between inch and metric
    based facsimile terminals. TIFF for Facsimile Writers SHOULD express
    YResolution in inch based units, for consistency with historical
    practice and to maximize interoperability. See the table below for
    information on how to convert from an ITU-T metric value to its inch
    based equivalent resolution. No default, must be specified

      +-----------------------------+-----------------------------+
      |         XResolution         |         YResolution         |
      +--------------+--------------+--------------+--------------+
      |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit|
      |  =2 (inch)   |   =3 (cm)    |  =2 (inch)   |   =3 (cm)    |
      +--------------+--------------+--------------+--------------+
      |     100      |              |     100      |              |
      +--------------+--------------+--------------+--------------+
      |     204      |      80      |      98      |     38.5     |
      |     200      |              |     100      |              |
      +--------------+--------------+--------------+--------------+
      |     204      |      80      |     196      |      77      |
      |     200      |              |     200      |              |
      +--------------+--------------+--------------+--------------+
      |     204      |      80      |     391      |     154      |
      +--------------+--------------+--------------+--------------+
      |     300      |              |     300      |              |
      +--------------+--------------+--------------+--------------+
      |     408      |     160      |     391      |     154      |
      |     400      |              |     400      |              |
      +--------------+--------------+--------------+--------------+

2.2.3 TIFF fields recommended for all fax modes

   The TIFF fields listed in this section MAY be used by all fax modes.
   However, Profile S writers (the minimal fax mode described in Section
   3) SHOULD NOT use these fields. Recommended fields that are mode-
   specific are described in Sections 3-8.

DateTime(306)                                                      ASCII
    OptionalInTIFFBaseline
    Date/time of image creation in 24-hour format "YYYY:MM:DD HH:MM:SS".
    No default.

DocumentName(269)                                                  ASCII
    OptionalInTIFFExtension(DocumentStorageAndRetrieval)
    The name of the scanned document. This is a TIFF extension field,
    not a Baseline TIFF field.
ToP   noToC   RFC2301 - Page 16
    No default.

ImageDescription(270)                                              ASCII
    OptionalInTIFFBaseline
    A string describing the contents of the image.
    No default.

Orientation(274) = 1-8.                                            SHORT
    OptionalinTIFFBaseline
    1: 0th row represents the visual top of the image; the 0th column
    represents the visual left side of the image. See the current TIFF
    spec [TIFF] for further values; Baseline TIFF only requires value=1.
    Default = 1.
    Note: It is recommended that a writer that is aware of the
    orientation will include this field to give a positive indication of
    the orientation, even if the value is the default. If the
    Orientation field is omitted, the reader SHALL assume a value of 1.

Software(305)                                                      ASCII
    OptionalInTIFFBaseline
    The optional name and release number of the software package that
    created the image.
    No default.

2.2.4 New TIFF fields recommended for fax modes

   The new TIFF fields listed in this section MAY be used by all fax
   modes, but their support is not expected for the minimal fax mode
   described in Section 3. In addition, support for these new TIFF
   fields has not been included in historical TIFF-F readers described
   in Section 4 and [TIFF- F]. These fields describe "global" parameters
   of the fax session that created the image data. They are optional,
   not part of the current TIFF specification, and are defined in this
   document.

   The first new field, GlobalParametersIFD, is an IFD that contains
   global parameters and is located in a Primary IFD.

GlobalParametersIFD (400)                                            IFD
    An IFD containing global parameters. It is recommended that a TIFF
    writer place this field in the first IFD, where a TIFF reader would
    find it quickly.

   Each field in the GlobalParametersIFD is a TIFF field that is legal
   in any IFD. Required baseline fields should not be located in the
   GlobalParametersIFD, but should be in each image IFD. If a conflict
   exists between fields in the GlobalParametersIFD and in the image
   IFDs, then the data in the image IFD shall prevail.
ToP   noToC   RFC2301 - Page 17
   Among the GlobalParametersIFD entries is a new ProfileType field
   which generally describes information in this IFD and in the TIFF
   file.

ProfileType(401)                                                    LONG
    The type of image data stored in this IFD.
    0 = Unspecified
    1 = Group 3 fax
    No default

   The following new global fields are defined in this document as IFD
   entries for use with fax applications.

FaxProfile(402) = 0 - 6.                                            BYTE
    The profile that applies to this file; a profile is subset of the
    full set of permitted fields and field values of TIFF for facsimile.
    The currently defined values are:
    0: does not conform to a profile defined for TIFF for facsimile
    1: minimal black & white lossless, Profile S
    2: extended black & white lossless, Profile F
    3: lossless JBIG black & white, Profile J
    4: lossy color and grayscale, Profile C
    5: lossless color and grayscale, Profile L
    6: Mixed Raster Content, Profile M

CodingMethods(403)                                                  LONG
    This field indicates which coding methods are used in the file. A
    bit value of 1 indicates which of the following coding methods is
    used:
    Bit 0: unspecified compression,
    Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman),
    Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read),
    Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR),
    Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG),
    Bit 5: ITU-T Rec. T.81 (Baseline JPEG),
    Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color),
    Bits 7-31: reserved for future use
    Note: There is a limit of 32 compression types to identify standard
    compression methods.

VersionYear(404)                                                    BYTE
    Count: 4
    The year of the standard specified by the FaxProfile field, given as
    4 characters, e.g. '1997'; used in lossy and lossless color modes.

ModeNumber (405)                                                    BYTE
    The mode of the standard specified by the FaxProfile field. A
    value of 0 indicates Mode 1.0; used in Mixed Raster Content mode.
ToP   noToC   RFC2301 - Page 18
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)
ToP   noToC   RFC2301 - Page 19
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
ToP   noToC   RFC2301 - Page 20
    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.
ToP   noToC   RFC2301 - Page 21
   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.
ToP   noToC   RFC2301 - Page 22
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.
ToP   noToC   RFC2301 - Page 23
                   +-----------------------+
                   |         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     |
      +------------------------------------------------------------+
ToP   noToC   RFC2301 - Page 24
      +---------------------------+--------------------------------+
      | 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|
      +---------------------------+--------------------------------+



(page 24 continued on part 2)

Next Section