rfc1314.txt

RFC 的详细文档！

        rather than publishing.  Therefore, we are more concerned
        with compression ratios and compatibility with CCITT fax
        than Aldus is.]

   TIFF itself allows for gray-scale and color images.  Image files
   should be restricted to TIFF-B for now because most of the currently
   available hardware is bi-level (1 bit per pixel).  In the future,
   when gray-scale or color scanners, printers, and fax becomes
   available, the file format suggested here can already accommodate it.
   (For example, though JPEG is not currently a TIFF defined compression
   type, work is currently underway for including it as such.)



Katz & Cohen                                                    [Page 6]

RFC 1314                 Image Exchange Format                April 1992


        [NOTE: In this document, we will use the term "reader"
        or "TIFF reader" to refer to the process or device
        which reads and parses a TIFF file.]

3.A. TIFF File Format

   Figure 1 below (reproduced here from Figure 1 of reference [3])
   depicts the structure of a TIFF file.

   TIFF files start with a file header which specifies the byte order
   used in the file (i.e., Big or Little Endian), the TIFF version
   number, and points to the first "Image File Directory" (IFD).  If the
   first two bytes are hex 4D4D, the byte order is from most to least
   significant for both 16 and 32 bit integers (Big Endian).  If the
   first two bytes are hex 4949, the byte order is from least to most
   significant (Little Endian).  In both formats, character strings are
   stored into sequential bytes and are null terminated.

   The next two bytes (called the TIFF Version) must be 42 (hex 002A).
   This does not refer to the current TIFF revision number.  The
   following 4 bytes contain the offset (in bytes from the beginning of
   the file) to the first IFD.

   An IFD contains a 2 byte count of the number of entries in the IFD, a
   sequence of 12 byte directory entries, and a 4 byte pointer to the
   next IFD.  One of these fields (StripOffsets) points to (parts of) an
   image in the file.  There may be more than one image in the file
   (e.g., a "multi-page" TIFF file) and therefore more then one IFD.
   IFD field entries may appear in any order.

   Each directory entry is 12 bytes and consists of a tag, its type, a
   length, and an offset to its value.  If the value can fit into 4
   bytes (i.e., if the type is BYTE, SHORT, or LONG), the actual value
   rather than an offset is given.  If the value is less than 4 bytes
   (i.e., if the type is BYTE or SHORT), it is left-justified within the
   4 byte value offset.  More details about directory entries and the
   possible tags will be given in Section 3.C.

   All pointers (called offsets in the TIFF reference [3]) are the
   number of bytes from the beginning of the file and are 4 bytes long.
   The first byte of the file has an offset of 0.  In the case of only
   one image per file, there should therefore be only one IFD.  The last
   IFD's pointer to the next IFD is set to hex 00000000 (32 bits).

   The entries in an IFD must be sorted in ascending order by Tag.






Katz & Cohen                                                    [Page 7]

RFC 1314                 Image Exchange Format                April 1992


              Header
        +--------+--------+                     Directory Entry
      0 |        |        | Byte Order        +--------+--------+
        +--------+--------|               X   |        |        | Tag
      2 |        |        | Version(42)       +--------+--------|
        +--------+--------|               X+2 |        |        | Type
      4 |        |        | Offset of         +--------+--------|
        +-     - A -     -+  0th IFD      X+4 |        |        |
      6 |        |        |                   +-               -+ Length
        +--------+--------+                   |        |        |
                 |                            +--------+--------+
                 |                        X+8 |        |        | Value
                 |                            +-     - Y -     -+   or
                 V                            |        |        | Value
                                              +--------+--------+ Offset
                IFD
        +--------+--------+                            |
  A     |      - B -      | Entry Count                |
        +--------+--------|                            |
        |        |        |                            V
  A+2                       Entry 0
        |        |        |                   +--------+--------+
        +--------+--------+                   |        |        |
        |        |        |                 Y                     Value
  A+14                      Entry 1           |        |        |
        |        |        |                   +--------+--------|
        +--------+--------+
        |        |        |
  A+26                      Entry 2
        |        |        |
        +--------+--------+
        |        |        |    .
                               .
        |        |        |    .
        +--------+--------+
        |        |        |
                             Entry B-1
        |        |        |
        +--------+--------+
        |        |        |  Offset of
A+2+B*12       - C -      +  Next IFD
        |        |        |
        +--------+--------+
                 |
                 V
            (next IFD)

                 Figure 1: The Structure of a TIFF File



Katz & Cohen                                                    [Page 8]

RFC 1314                 Image Exchange Format                April 1992


3.B. Image Format and Encoding Issues

   Images in TIFF files are organized as horizontal strips for fast
   access to individual rows.  One can specify how many rows there are
   in each strip and all of the strips are the same size (except
   possibly the last one).  Each strip must begin on a byte boundary but
   successive rows are not so required.  For two-dimensional G3
   compression (MR), each strip must begin with an "absolute" one-
   dimensional line.  For MMR (G4) compression, each strip must be
   encoded as if it were a separate image.

   For a variety of reasons, each page must be a single strip (e.g., not
   broken up into multiple strips).

   One problem with multiple strips per page is that images which come
   from G4 fax machines as well as most scanned images will be generated
   as a single strip per page.  These would have to be decoded and re-
   encoded as multiple strips (remember that for MMR compression, each
   strip must be start with a one-dimensionally encoded line).

   Another problem with multiple strips per page arises in MR
   compression.  Here, there MAY be at most k-1 two-dimensionally
   encoded lines following a one-dimensionally encoded line, but this is
   not required.  It is possible to have one-dimensional lines more
   frequently than every k lines.  However, since each strip (except
   possibly the last one) is required to be the same size, it may be
   necessary to re-encode the image to insure that each strip starts
   with a one-dimensional line.  This is not a problem if each page is a
   single strip.

        [NOTE: The TIFF document [3] suggests using strips which
        are about 8K bytes long.  However, TIFF-F [4] recommends
        that each page be a single strip regardless of its size.
        The format specified in this document follows the TIFF-F
        recommendation.]

   Also, as TIFF-F recommends, all G3 encoded images (MH and MR) should
   be "byte-aligned."  This means that extra zero bits (fill bits) are
   added before each EOL (end-of-line) so that every line starts on a
   byte boundary.

   In addition, as in the TIFF-F specification, the RTC (Return to
   Control signal which consists of 6 continuous EOL's) of G3 shall not
   be included at the end of G3 encoded documents.  RTC is to be
   considered part of the G3 transmission protocol and not part of the
   encoding.  Most, if not all, G3 fax modems attach RTC to outgoing
   images and remove it from incoming ones.




Katz & Cohen                                                    [Page 9]

RFC 1314                 Image Exchange Format                April 1992


   For MMR (G4) encoded files, readers should be able to read images
   with only one EOFB (End Of Facsimile Block) at the end of the page
   and should not assume that Facsimile Blocks are of any particular
   size.  (It has been reported that some MMR readers assume that all
   Facsimile Blocks are the maximum size.)

   Systems may optionally choose to store the entire image uncompressed
   if the compression increases the size of the image file.  Also,
   uncompressed mode (specified in Group3Options or Group4Options, see
   below) allows portions of the image to be uncompressed.

   The multi-page capability of TIFF is supported and should be used for
   multi-page documents.  TIFF files which have multiple pages have an
   IFD for each page of the document each of which describes and points
   to a single page image.  (Note: though the current TIFF specification
   does not specifically prohibit having a single IFD point to an image
   which is actually multiple pages, with one strip for each page, most
   if not all TIFF readers would probably not be able to read such a
   file.  Therefore, this should not be done.)

     [A NOTE ON TIFF AND MULTI-PAGE DOCUMENTS:

        Since most publications (e.g., reports, books, and
        magazine articles) are composed of more than a single
        page, multi-page TIFF files should be used where
        appropriate.  However, many current TIFF implementations
        now only handle single-page files.

        It is hoped that in the future, more TIFF implementations
        will handle multi-page files correctly.  In the meantime,
        it would be useful to develop a utility program which
        could join several single-page TIFF files into a single
        multi-page file and also separate a multi-page TIFF file
        into several single page files.

        For example, the utility could take a single TIFF file
        with N pages, called doc.tif, and create the files
        doc.000, doc.001, doc.002, ..., doc.N.  doc.000 would be
        an ASCII listing of the files created.  This naming
        scheme is compatible with that used by the image systems
        we have seen which only handle single page files.

        In going the other way, the N+1 single page files could
        be combined into a single multi-page TIFF file.  In this
        case, if the file doc.000 exists but contains information
        contrary to what is found in looking for the files
        doc.001, doc.002, ..., the program would notify the user.]




Katz & Cohen                                                   [Page 10]

RFC 1314                 Image Exchange Format                April 1992


3.C. TIFF Fields

   TIFF is tag or field based.  The various fields and their format are
   listed in [3].  There are Basic Fields (common to all TIFF files),
   Informational Fields (which provide useful information to a user),
   Facsimile Fields (used here), and Private Fields.

   Each directory entry contains:

       The Tag for the field (2 bytes)

       The field Type (2 bytes)

       The field Length (4 bytes)
           (This is in terms of the data type, not in bytes.  For
            example, a single 16-bit word or SHORT has a Length
            of 1, not 2)

       The Value Offset (4 bytes)
           (Pointer to the actual value, which must begin on a
            word boundary.  Therefore, this offset will always
            be an even number.  If the Value fits into 4 bytes, the
            Value Offset contains the Value instead.  If the Value
            takes less than 4 bytes, it is left justified)


   The allowed types and their codes are:

        1 = BYTE        8-bit unsigned integer (1 byte)

        2 = ASCII       8-bit ASCII terminated with a null (variable
                        length)

        3 = SHORT       16-bit unsigned integer (2 bytes)

        4 = LONG        32-bit unsigned integer (4 bytes)

        5 = RATIONAL    Two LONGs (64 bits) representing the
                        numerator and denominator of a fraction.
                        In this document, RATIONAL's will be written
                        as numerator/denominator. (8 bytes)

   For ASCII, the Length specifies the number of characters and includes
   the null.  It does not, however, include padding if such is
   necessary.

   (Note that ASCII strings of length 3 or less may be stored in the
   Value Offset field instead of being pointed to.)



Katz & Cohen                                                   [Page 11]

RFC 1314                 Image Exchange Format                April 1992


   The following fields should be used in a TIFF image file.  Only the
   Basic Fields are mandatory; the others are optional (except that for
   MH and MR encoded files, the Group3Options Facsimile Field is
   mandatory).  The optional fields have default values which are given
   in the TIFF specification.  (Note that the TIFF reference [3]
   recommends not relying on the default values.)

   Some fields contain one or more flag bits all stored as one value.
   In these cases, the bit labeled 0 is the least significant bit (i.e.,
   Little Endian order).  Where there is more than one suggested value
   for a tag, the possible values are separated by |.

   Note that some fields (such as ImageLength or ImageWidth) can be of
   more than one type.

   It would be useful to develop a TIFF viewer and editor which would
   allow one to read, add, and edit the fields in a TIFF file.  Such an
   editor would display fields in sorted order and force the inclusion
   of all mandatory fields.  Also, resolution and position should always
   be displayed or specified together with their units.

   3.C.1.  Basic Fields (Mandatory)

      Basic Fields are those which are fundamental to the pixel