rfc2306.txt

来自「RFC 的详细文档!」· 文本 代码 · 共 1,404 行 · 第 1/4 页

TXT
1,404
字号






Network Working Group                                        G. Parsons
Request for Comments: 2306                             Northern Telecom
Category: Informational                                     J. Rafferty
                                                   Human Communications
                                                             March 1998


         Tag Image File Format (TIFF) - F Profile for Facsimile


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Overview

   This document describes in detail the definition of TIFF-F that is
   used to store facsimile images.  The TIFF-F encoding has been
   folklore with no standard reference definition before this document.

Internet Fax Working Group

   This document is a product of the IETF Internet Fax Working Group.
   All comments on this document should be forwarded to the email
   distribution list at <ietf-fax@imc.org>.

1.  Abstract

   This document references the Tag Image File Format (TIFF) to define
   the F profile of TIFF for facsimile (TIFF-F) as a file format that
   may be used for the storage and interchange of facsimile images.

2.  TIFF Definition

   TIFF (Tag Image File Format) Revision 6.0 is defined in detail within
   [TIFF].

   A brief review of concepts used in TIFF is included in this document
   as background information, but the reader is directed to the original
   TIFF specification [TIFF] to obtain specific technical details.





Parsons & Rafferty           Informational                      [Page 1]

RFC 2306                     TIFF-F Profile                   March 1998


2.1  Baseline TIFF and Applications

   TIFF provides a method to describe and store raster image data.  A
   primary goal of TIFF is to provide a rich environment within which
   implementations can exchange image data.  [TIFF] characterizes
   Baseline TIFF as being the core of TIFF, the essentials that all
   mainstream TIFF developers should support in their products.
   Applications of TIFF are defined by using Baseline TIFF as a starting
   point and then defining "extensions" to TIFF that are used for the
   specific "application", as well as specifying any other differences
   from Baseline TIFF.

3.  TIFF-F Definition

3.1 Introduction

   Though it has been in common usage for many years, TIFF-F has
   previously never been documented in the form of a standard.  An
   informal TIFF-F document was originally created by a small group of
   fax experts led by Joe Campbell.  The existence of TIFF-F is noted in
   [TIFF] but it is not defined.  This document defines the F
   application of [TIFF]. For ease of reference, the term TIFF-F will be
   used throughout this document as a shorthand for "F Profile of TIFF
   for Facsimile".  TIFF-F files are intended for use with the
   image/tiff MIME media content-type which includes support for the
   "application" parameter (e.g., application=faxbw).

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

 3.1.1 TIFF-F Historical Background

   Up until TIFF 6.0, TIFF supported various "Classes" which defined the
   use of TIFF for various applications. Classes were used to support
   specific applications and in this spirit, TIFF-F has been known
   historically as "TIFF Class F".  Previous informal TIFF-F documents
   used the "Class F" terminology.

   As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in
   favor of the concept of Baseline TIFF.  Therefore, this document
   updates the definition of TIFF-F as the F profile of TIFF for
   facsimile, by using Baseline TIFF as defined in [TIFF] as the
   starting point and then defining the differences from Baseline TIFF
   which apply for TIFF-F.   In almost all cases, the resulting
   definition of TIFF-F fields and values remains consistent with those
   used historically in earlier definitions of TIFF Class F.  Where some




Parsons & Rafferty           Informational                      [Page 2]

RFC 2306                     TIFF-F Profile                   March 1998


   of the values for fields have been updated to provide more precise
   conformance with the ITU-T [T.4] and [T.30] fax recommendations,
   these differences are noted.

3.1.2     Overview

   The intent of this specification is to document:

   1)  The fields and values which are applicable for this F profile
       of TIFF for facsimile.
   2)  A minimum set of TIFF-F fields and values which should be able
       to interwork with virtually all historic TIFF-F readers.
   3)  A broader range of values for the traditional TIFF-F fields
       that will provide support for the most widely used facsimile
       compressions, page sizes and resolutions, consistent with the
       ITU-T [T.4] and [T.30] recommendations.

   The structure of the TIFF-F definition will be as follows.  A brief
   review of the structure of TIFF files and practical guidelines for
   the writing and reading of multi-page TIFF-F files is provided in
   sections 3.1.3 and 3.1.4.

   A review of TIFF-F fields follows.  Section 3.2 reviews the fields
   from Baseline TIFF that are applicable for black and white (bi-
   level) images and are also used by TIFF-F.

   Section 3.3 reviews the other required TIFF-F fields. Several fields
   that are specific extensions for  TIFF-F  are reviewed in section
   3.4.  There are also fields that may be helpful, but are not
   required.  These recommended fields are listed in the section 3.5.
   Section 3.6 defines the requirements for the minimum subset of TIFF-F
   fields and values to maximize interoperability.  Several technical
   topics, including implementation issues and warnings are discussed in
   subsequent sections.  Finally, section 3.9 introduces the TIFF-F
   Reader and Writer.  A table of the required and recommended fields
   for a TIFF-F Reader is provided, along with details on the permitted
   set of values.

3.1.3 Structure of TIFF Files

   The structure of TIFF files is specified within [TIFF].  In this
   section, a short summary of the TIFF structure is included for the
   informational purposes.   In addition, some practical guidelines for
   the use of this structure in reading and writing TIFF-F files are
   addressed in the following section 3.1.4.  The structure for writing
   "minimum subset" TIFF-F files is defined in section 3.6.2.





Parsons & Rafferty           Informational                      [Page 3]

RFC 2306                     TIFF-F Profile                   March 1998


   A TIFF file begins with an 8-byte image file header that defines the
   byte order used within a file (see section 3.9.1), includes a magic
   number sequence that identifies the content as a TIFF file, and then
   uses an offset to point to the first Image File Directory (IFD).  An
   IFD is a sequence of tagged fields, sorted in ascending order (by tag
   value), that contains attributes of an image and pointers to the
   image data.   TIFF fields (also called entries) contain a tag, its
   type (e.g. short, long, rational, etc.), a count (which indicates the
   number of values/offsets) and a value/offset.  However, the actual
   value for the field will only be present if it fits into 4 bytes;
   otherwise, an offset will be used to point to the location of the
   data associated with the field.  In turn, this offset may itself be
   used to point to an array of offsets.

   For the case of facsimile data, many documents consist of a series of
   multiple pages.   Within TIFF, these may be represented using more
   than one IFD within the TIFF file.   Each IFD defines a subfile whose
   type is given in the NewSubfileType field.  For the case of facsimile
   data that is placed in a TIFF-F file, each facsimile page in a
   multi-page document has its own IFD.   For bi- level facsimile files,
   multiple IFDs are organized as a linked list, with the last entry in
   each IFD pointing to the next IFD (the pointer in the last IFD is 0).
   (There is also another technique for organizing multiple IFDs as a
   tree, that uses the SubIFDs field, but this technique is not
   applicable for TIFF-F images.)  Within each IFD, the location of the
   related image data is defined by using fields that are associated
   with strips.  These fields identify the size of strips (in rows), the
   number of bytes per strip after compression and a strip offset, which
   is used to point to the actual location of the image strip.

   TIFF has a very flexible file structure, but the use of some
   practical guidelines for implementors when writing  multi-page TIFF-
   F files can produce TIFF structures which are easier for readers to
   process.   This is especially for implementations in environments
   such as facsimile terminals where a complex file structure is
   difficult to support.

3.1.4 Practical Guidelines for Writing/Reading Multi-Page TIFF-F Files

   Traditionally, historical TIFF-F has required readers and writers to
   be able to handle multi-page TIFF-F files.  Based on the experience
   of various TIFF-F implementors, it has been seen that the
   implementation of TIFF-F can be greatly simplified if certain
   practical guidelines are followed when writing multi-page TIFF-F
   files.  However, for interchange robustness, TIFF-F 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.



Parsons & Rafferty           Informational                      [Page 4]

RFC 2306                     TIFF-F Profile                   March 1998


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

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

   A third simplifying assumption is that each IFD SHOULD be placed in
   the TIFF-F file structure at a point which precedes the image which
   the IFD describes.  If any long field values are present (see section
   3.1.3) then these SHOULD be placed after their referencing IFD and
   before the image data they describe.

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

   TIFF-F writers MAY make a fifth simplifying assumption, in which the
   IFD, the value data and the image data for which the IFD has offsets
   precede the next image IFD. These elements MUST precede the next
   image IFD in the minimum set TIFF-F files (see section 3.6.2).
   However, this principle has been relaxed in the case of TIFF-F to
   reflect past practices.



Parsons & Rafferty           Informational                      [Page 5]

RFC 2306                     TIFF-F Profile                   March 1998


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

3.2  Baseline TIFF  Required Fields for BiLevel Images

   Baseline TIFF per [TIFF] requires that the following fields be
   present for all BiLevel Images:  ImageWidth, ImageLength,
   Compression, PhotometricInterpretation, StripOffsets, RowsPerStrip,
   StripByteCounts, XResolution, YResolution and ResolutionUnit.  TIFF-F
   uses all of these fields, but in some cases specifies a different
   range of acceptable values than Baseline TIFF.   Per [TIFF], if
   fields are omitted, the Baseline TIFF default value(if specified)
   will apply.

   In the field definitions which follow in this section and subsequent
   sections, the fields will be presented in the following form:

   Fieldname (tag-number) = values (if applicable). TYPE

   A brief summary of the Baseline TIFF fields and their use in TIFF-F
   follows:

   ImageWidth(256) = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096,
                     4864.
       SHORT or LONG.  These are the fixed page widths in pixels.  The
       permissible values are dependent upon X and Y resolutions as
       shown in sections 2 and 3 of [T.4] and reproduced here for
       convenience:

       XResolution x Yresolution                  | ImageWidth
      --------------------------------------------|------------------
       204x98, 204x196, 204x391, 200x100, 200x200 | 1728, 2048, 2432
       300x300                                    | 2592, 3072, 3648
       408x391, 400x400                           | 3456, 4096, 4864
      --------------------------------------------|------------------

       Historical TIFF-F did not include support for the following
       widths related to higher resolutions:  2592, 3072, 3648, 3456,
       4096 and 4864.   Historical TIFF-F documents also included the
       following values related to A5 and A6 widths:  816 and 1216.  Per
       the most recent version of [T.4], A5 and A6 documents are no





Parsons & Rafferty           Informational                      [Page 6]

RFC 2306                     TIFF-F Profile                   March 1998


       longer supported in Group 3 facsimile, so the related width
       values are now obsolete.  See section 3.8.2 for more information
       on inch/metric equivalencies and other implementation details.

   ImageLength (257).  SHORT or LONG. LONG recommended.
       The total number of scan lines in the image.

   Compression (259) = 3,4.  SHORT.
       This is a required TIFF-F field.  The permitted values for TIFF-

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?