diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2301.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2301.txt')
| -rw-r--r-- | doc/rfc/rfc2301.txt | 4315 |
1 files changed, 4315 insertions, 0 deletions
diff --git a/doc/rfc/rfc2301.txt b/doc/rfc/rfc2301.txt new file mode 100644 index 0000000..c91a9f4 --- /dev/null +++ b/doc/rfc/rfc2301.txt @@ -0,0 +1,4315 @@ + + + + + + +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. + + + + + + + + +McIntyre, et. al. Standards Track [Page 1] + +RFC 2301 File Format for Internet Fax March 1998 + + +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 + + + +McIntyre, et. al. Standards Track [Page 2] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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 + + + +McIntyre, et. al. Standards Track [Page 3] + +RFC 2301 File Format for Internet Fax March 1998 + + +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. + + + + + + +McIntyre, et. al. Standards Track [Page 4] + +RFC 2301 File Format for Internet Fax March 1998 + + +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. + + + + + +McIntyre, et. al. Standards Track [Page 5] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 6] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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 + + + +McIntyre, et. al. Standards Track [Page 7] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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 + + + + + +McIntyre, et. al. Standards Track [Page 8] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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.) + + + + +McIntyre, et. al. Standards Track [Page 9] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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 + + + +McIntyre, et. al. Standards Track [Page 10] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + + + + +McIntyre, et. al. Standards Track [Page 11] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 12] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 13] + +RFC 2301 File Format for Internet Fax March 1998 + + +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 + + + +McIntyre, et. al. Standards Track [Page 14] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 15] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 16] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 17] + +RFC 2301 File Format for Internet Fax March 1998 + + +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) + + + + +McIntyre, et. al. Standards Track [Page 18] + +RFC 2301 File Format for Internet Fax March 1998 + + +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 + + + +McIntyre, et. al. Standards Track [Page 19] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + + +McIntyre, et. al. Standards Track [Page 20] + +RFC 2301 File Format for Internet Fax March 1998 + + + 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. + + + +McIntyre, et. al. Standards Track [Page 21] + +RFC 2301 File Format for Internet Fax March 1998 + + +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. + + + + + +McIntyre, et. al. Standards Track [Page 22] + +RFC 2301 File Format for Internet Fax March 1998 + + + +-----------------------+ + | 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 | + +------------------------------------------------------------+ + + + +McIntyre, et. al. Standards Track [Page 23] + +RFC 2301 File Format for Internet Fax March 1998 + + + +---------------------------+--------------------------------+ + | FillOrder | 2: least significant bit first | + +---------------------------+--------------------------------+ + | ImageWidth | 1728 | + +---------------------------+--------------------------------+ + | ImageLength | n: total number of scanlines | + | | in image | + +---------------------------+--------------------------------+ + | NewSubFileType | 2: Bit 1 identifies single | + | | page of a multi-page document | + +---------------------------+--------------------------------+ + | PageNumber | n,m: page number n followed by | + | | total page count m | + +---------------------------+--------------------------------+ + | PhotometricInterpretation | 0: pixel value 1 means black | + +---------------------------+--------------------------------+ + | ResolutionUnit | 2: inch | + +---------------------------+--------------------------------+ + | RowsPerStrip | number of scanlines per strip | + | | = ImageLength, with one strip | + +---------------------------+--------------------------------+ + | SamplesPerPixel | 1 | + +---------------------------+--------------------------------+ + | StripByteCounts | number of bytes in TIFF strip | + +---------------------------+--------------------------------+ + | StripOffsets | offset from beginning of | + | | file to single TIFF strip | + +---------------------------+--------------------------------+ + | XResolution | 204, 200 (pixels/inch) | + +---------------------------+--------------------------------+ + | YResolution | 98, 196, 100, 200 (pixels/inch)| + +---------------------------+--------------------------------+ + | Extension Fields | + +---------------------------+--------------------------------+ + | T4Options | 0: MH coding, EOLs not byte | + | | aligned | + | | 4: MH coding, EOLs byte aligned| + +---------------------------+--------------------------------+ + +4. Extended Black-and-White fax mode + + This section defines the extended black-and-white mode or Profile F + of TIFF for facsimile. It provides a standard definition of what has + historically been known as TIFF Class F and now TIFF-F. In doing so, + it aligns this mode with current ITU-T Recommendations for black- + and-white fax and with existing industry practice. Implementations of + this profile include implementations of Profile S. + + + + +McIntyre, et. al. Standards Track [Page 24] + +RFC 2301 File Format for Internet Fax March 1998 + + + This section describes extensions to the minimal interchange set of + fields (Profile S) that provide a richer set of black-and-white + capabilities. The fields and values described in this section are a + superset of the fields and values defined for the minimal interchange + set in Section 3. In addition to the MH encoding, Modified READ (MR) + and Modified Modified READ (MMR) encoding as described in [T.4] and + [T.6] are supported. + + Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the + TIFF fields that SHALL be used in this mode. Section 4.3 describes + the fields that MAY be used in this mode. In the spirit of the + original TIFF-F specification, Sections 4.4 and 4.5 discuss technical + implementation issues and warnings. Section 4.6 gives an example use + of TIFF-F. Section 4.7 gives a summary of the required and + recommended fields and their values. + +4.1 TIFF-F Overview + + Though it has been in common 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 serves as the formal + definition of the F application of [TIFF] for Internet applications. + For ease of reference, the term TIFF-F will be used throughout this + document as a shorthand for the extended black-and-white mode or + profile of TIFF for facsimile. + + Up until the TIFF 6.0 specification, TIFF supported various "Classes" + which defined the use of TIFF for various applications. Classes were + used to support specific applications. In this spirit, TIFF-F has + been known historically as "TIFF Class F". Previous informal TIFF-F + documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0 + [TIFF], the TIFF Class concept has been eliminated in favor of the + concept of Baseline TIFF. Therefore, this document updates the + definition of TIFF-F as the F profile of TIFF for facsimile, by using + Baseline TIFF as defined in [TIFF] as the starting point and then + adding the TIFF extensions to Baseline TIFF 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 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. + + + + + + + + +McIntyre, et. al. Standards Track [Page 25] + +RFC 2301 File Format for Internet Fax March 1998 + + +4.2. Required TIFF Fields + + This section lists the required fields and the values they must have + to be ITU-compatible. Besides the fields listed in Section 2.2.1, the + extended black-and-white fax mode SHALL use the following fields. + +4.2.1. Baseline fields + +BitsPerSample(258) = 1. SHORT + RequiredByTIFFBaseline + Binary data only. + Default = 1 (field may be omitted if this is the value) + +Compression(259) = 3, 4. SHORT + RequiredByTIFFBaseline + 3 = 1- or 2- dimensional coding, must have T4Options field This is + a TIFF Extension value [TIFF]. + 4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified + Read, must have T6Options field)) This is a TIFF Extension value. + Default = 1 (and is not applicable; field must be specified) + + NOTE: Baseline TIFF permits use of value 2 for Modified Huffman + encoding, but data is presented in a form which does not use EOLs, + and so TIFF for facsimile uses Compression=3 instead. See Sections + 4.4.4, 4.5.1 and 4.5.2 for more information on compression and + encoding. + +FillOrder(266) = 1 , 2. SHORT + RequiredByTIFFBaseline + Profile F readers must be able to read data in both bit orders, + but the vast majority of facsimile products store data LSB + first, exactly as it appears on the telephone line. + 1 = Most Significant Bit first. + 2 = Least Significant Bit first + +ImageWidth(256) SHORT or LONG + RequiredByTIFFBaseline + This mode supports the following fixed page widths: 1728, 2592, 3456 + (corresponding to North American Letter and Legal, ISO A4 paper + sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and + 2432, 3648, 4864 (corresponding to ISO A3 paper size). + No default; must be specified + + NOTE: Historical TIFF-F did not include support for the following + widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096 + and 4864. Historical TIFF-F documents also included the following + values related to A5 and A6 widths: 816 and 1216. Per the most recent + + + + +McIntyre, et. al. Standards Track [Page 26] + +RFC 2301 File Format for Internet Fax March 1998 + + + version of [T.4], A5 and A6 documents are no longer supported in + Group 3 facsimile, so the related width values are now obsolete. See + section 4.5.2 for more information on inch/metric equivalencies and + other implementation details. + +NewSubFileType(254) = (Bit 1=1). LONG + RequiredByTIFFforFAX + Bit 1 is 1 if the image is a single page of a multi-page document. + Default = 0 (no subfile bits on, so may not be omitted for fax) + + NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page + of a multi-page image. The same bit settings are used when TIFF-F is + used for a one page fax image. See Section 4.4.3 for details on + multi-page files. + +PhotometricInterpretation(262) = 0, 1. SHORT + RequiredByTIFFBaseline + 0 = pixel value 1 means black, 1 = pixel value 1 means white. + This field allows notation of an inverted or negative image. + No default, must be specified + +ResolutionUnit(296) = 2, 3. SHORT + RequiredByTIFFBaseline + The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F + has traditionally used inch-based measures. + Default = 2 (field may be omitted if this is the value) + +SamplesPerPixel(277) = 1. SHORT + RequiredByTIFFBaseline + 1 = monochrome, bilevel in this case (see BitsPerSample) + Default =1 (field may be omitted if this is the value) + +XResolution(282) = 200, 204, 300, 400, 408 RATIONAL + RequiredByTIFFBaseline + The horizontal resolution of the image is expressed in pixels per + resolution unit. In pixels/inch, the allowed values are: 200, 204, + 300, 400, and 408. See Section 2.2.2 for inch-metric equivalency. + No default, must be specified + + NOTE: The values of 200 and 408 have been added to the historical + TIFF-F values, for consistency with [T.30]. Some existing TIFF-F + implementations may also support values of 80 pixels/cm, which is + equivalent to 204 pixels per inch. See section 4.5.2 for information + on implementation details. + +YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 RATIONAL + RequiredByTIFFBaseline + The vertical resolution of the image is expressed in pixels per + + + +McIntyre, et. al. Standards Track [Page 27] + +RFC 2301 File Format for Internet Fax March 1998 + + + resolution unit. In pixels/inch, the allowed values are: 98, 100, + 196, 200, 300, 391, and 400 pixels/inch. + See Section 2.2.2 for inch-metric equivalency. + No default, must be specified + + NOTE: The values of 100, 200, and 391 have been added to the + historical TIFF-F values, for consistency with [T.30]. Some existing + TIFF-F implementations may also support values of 77 and 38.5 (cm), + which are equivalent to 196 and 98 pixels per inch respectively. See + section 4.5.2 for more information on implementation details. + + NOTE: Not all combinations of XResolution, YResolution and ImageWidth + are legal. The following table gives the legal combinations and + corresponding paper size [T.30]. + + +--------------+-----------------+---------------------------+ + | XResolution x YResolution | ImageWidth | + +--------------+-----------------+---------+--------+--------+ + | 200x100, 204x98 | | | | + | 200x200, 204x196 | 1728 | 2048 | 2432 | + | 204x391 | | | | + +--------------+-----------------+---------+--------+--------+ + | 300 x 300 | 2592 | 3072 | 3648 | + +--------------+-----------------+---------+--------+--------+ + | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | + +--------------+-----------------+---------+--------+--------+ + |Letter,A4| B4 | A3 | + | Legal | | | + +---------+--------+--------+ + | Paper Size | + +---------------------------+ + + +4.2.2. Extension fields + +T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) LONG + RequiredTIFFExtension (when Compression = 3) + T4Options was also known as Group3Options in a prior version of + [TIFF]. + Bit 0 = 1 indicates MR encoding, = 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 MH encoding is used and EOLs + are not byte aligned EOLs) (See Section 3.2.2.) + The T4Options field is required when the Compression field has a + value of 3. This field specifies the encoding used (MH or MR) and + whether the EOL codes are byte-aligned or not. If they are byte + + + +McIntyre, et. al. Standards Track [Page 28] + +RFC 2301 File Format for Internet Fax March 1998 + + + aligned, then fill bits have been added as necessary so that the End + of Line (EOL) codes always end on byte boundaries See Sections 3.4, + 4.5.3 and 4.5.4 for details. + +T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG + RequiredTIFFExtension (when Compression = 4) + Used to indicate parameterization of 2D Modified Modified Read + compression. T6Options was also known as Group4Options in a prior + version of [TIFF]. + Bit 0 must be 0. + Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1 + indicates uncompressed data is allowed (see [TIFF]). + Default is all bits 0. For FAX, the field must be present and have + the value 0. The use of uncompressed data where compression would + expand the data size is not allowed for FAX. + + NOTE: MMR compressed data is two-dimensional and does not use EOLs. + Each MMR encoded image MUST include an "end-of-facsimile-block" + (EOFB) code at the end of each coded strip; see Section 4.5.6. + +4.2.3. New fields + + None. + +4.3. Recommended TIFF fields + +4.3.1. Baseline fields + + See Section 2.2.3. + +4.3.2. Extension fields + + See Section 2.2.3. + +4.3.3. New fields + + Three new, optional fields, used in the original TIFF-F description + to describe page quality, are defined in this specification. The + information contained in these fields is usually obtained from + receiving facsimile hardware (if applicable). They SHOULD NOT be used + in writing TIFF-F files for facsimile image data that is error + corrected or otherwise guaranteed not to have coding errors. Some + applications need to understand exactly the error content of the + data. For example, a CAD program might wish to verify that a file + has a low error level before importing it into a high-accuracy + document. Because Group 3 facsimile devices do not necessarily + perform error correction on the image data, the quality of a received + page must be inferred from the pixel count of decoded scan lines. A + + + +McIntyre, et. al. Standards Track [Page 29] + +RFC 2301 File Format for Internet Fax March 1998 + + + "good" scan line is defined as a line that, when decoded, contains + the correct number of pixels. Conversely, a "bad" scan line is + defined as a line that, when decoded, comprises an incorrect number + of pixels. + +BadFaxLines(326) SHORT or LONG + The number of "bad" scan lines encountered by the facsimile device + during reception. A "bad" scanline is defined as a scanline that, + when decoded, comprises an incorrect number of pixels. Note that + PercentBad = (BadFaxLines/ImageLength) * 100 + No default. + +CleanFaxData(327) = 0, 1, 2. SHORT + Indicates if "bad" lines encountered during reception are stored in + the data, or if "bad" lines have been replaced by the receiver. + 0 = No "bad" lines + 1 = "bad" lines exist, but were regenerated by the receiver, + 2 = "bad" lines exist, but have not been regenerated. + No default. + + NOTE: Many facsimile devices do not actually output bad lines. + Instead, the previous good line is repeated in place of a bad line. + Although this substitution, known as line regeneration, results in a + visual improvement to the image, the data is nevertheless corrupted. + The CleanFaxData field describes the error content of the data. That + is, when the BadFaxLines and ImageLength fields indicate that the + facsimile device encountered lines with an incorrect number of pixels + during reception, the CleanFaxData field indicates whether these bad + lines are actually still in the data or if the receiving facsimile + device replaced them with regenerated lines. + +ConsecutiveBadFaxLines(328) LONG or SHORT + Maximum number of consecutive "bad" scanlines received. The + BadFaxLines field indicates only the quantity of bad lines. + No Default. + + NOTE: The BadFaxLines and ImageLength data indicate only the quantity + of bad lines. The ConsecutiveBadFaxLines field is an indicator of the + distribution of bad lines and may therefore be a better general + indicator of perceived image quality. See Section 4.4.5 for examples + of the use of these fields. + +4.4. Technical Implementation Issues + +4.4.1 Strips + + In general, TIFF files divide an image into "strips," also known as + "bands." Each strip contains a few scanlines of the image. By using + + + +McIntyre, et. al. Standards Track [Page 30] + +RFC 2301 File Format for Internet Fax March 1998 + + + strips, a TIFF reader need not load the entire image into memory, + thus enabling it to fetch and decompress small random portions of the + image as necessary. + + The number of scanlines in a strip is described by the RowsPerStrip + value and the number of bytes in the strip after compression by the + StripByteCount value. The location in the TIFF file of each strip is + given by the StripOffsets values. + + Strip size is application dependent. The recommended approach for + multi- page TIFF-F images is to represent each page as a single + strip. Existing TIFF-F usage is typically one strip per page in + multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3. + +4.4.2 Bit Order + + The current TIFF specification [TIFF] does not require a Baseline + TIFF reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel + in the least significant bit of a byte. It further recommends that + FillOrder=2 be used only in special purpose applications. + + Facsimile data appears on the phone line in bit-reversed order + relative to its description in ITU-T Recommendation T.4. Therefore, + a wide majority of facsimile applications choose this natural order + for data in a file. Nevertheless, TIFF-F readers must be able to read + data in both bit orders and support FillOrder values of 1 and 2. + +4.4.3. Multi-Page + + Many existing applications already read TIFF-F-like files, but do not + support the multi-page field. Since a multi-page format greatly + simplifies file management in fax application software, TIFF-F + specifies multi-page documents (NewSubfileType = 2) as the standard + case. + + It is recommended that applications export multiple page TIFF-F files + without manipulating fields and values. Historically, some TIFF-F + writers have attempted to produce individual single-page TIFF-F files + with modified NewSubFileType and PageNumber (page one-of-one) values + for export purposes. However, there is no easy way to link such + multiple single page files together into a logical multiple page + document, so that this practice is not recommended. + +4.4.4. Compression + + In Group 3 facsimile, there are three compression methods which had + been standardized as of 1994 and are in common use. The ITU-T T.4 + Recommendation [T.4] defines a one-dimensional compression method + + + +McIntyre, et. al. Standards Track [Page 31] + +RFC 2301 File Format for Internet Fax March 1998 + + + known as Modified Huffman (MH) and a two-dimensional method known as + Modified READ (MR) (READ is short for Relative Element Address + Designate). In 1984, a somewhat more efficient compression method + known as Modified Modified READ (MMR) was defined in the ITU-T T.6 + Recommendation [T.6]. MMR was originally defined for use with Group 4 + facsimile, so that this compression method has been commonly called + Group 4 compression. In 1991, the MMR method was approved for use in + Group 3 facsimile and has since been widely utilized. + + TIFF-F supports these three compression methods. The most common + practice is the one-dimensional Modified Huffman (MH) compression + method. This is specified by setting the Compression field value to + 3 and then setting bit 0 of the T4Options field to 0. Alternatively, + the two dimensional Modified READ (MR) method, which is much less + frequently used in historical TIFF-F implementations, may be selected + by setting bit 0 of the T4Options field to 1. The value of Bit 2 in + this field is determined by the use of fill bits. + + Depending upon the application, the more efficient two-dimensional + Modified Modified Read (MMR)compression method from T.6 may be + selected by setting the Compression field value to 4 and then setting + the first two bits (and all unused bits) of the T6Options field to 0. + More information to aid the implementor in making a compression + selection is contained in Section 4.5.2. + + Baseline TIFF also permits use of Compression=2 to specify Modified + Huffman compression, but the data does not use EOLs. As a result, + TIFF-F uses Compression=3 instead of Compression=2 to specify + Modified Huffman compression. + +4.4.5. Example Use of Page-quality Fields + + Here are examples for writing the CleanFaxData, BadFaxLines, and + ConsecutiveBadFaxLines fields: + + 1. Facsimile hardware does not provide page quality + information: MUST NOT write page-quality fields. + 2. Facsimile hardware provides page quality information, but + reports no bad lines. Write only BadFaxLines = 0. + 3. Facsimile hardware provides page quality information, and + reports bad lines. Write both BadFaxLines and + ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or 2 if + the hardware's regeneration capability is known. + 4. Source image data stream is error-corrected or otherwise + guaranteed to be error-free such as for a computer generated + file: SHOULD NOT write page-quality fields. + + + + + +McIntyre, et. al. Standards Track [Page 32] + +RFC 2301 File Format for Internet Fax March 1998 + + + TIFF Writers SHOULD only generate these fields when the image has + been generated from a fax image data stream where error correction, + e.g. Group 3 Error Correction Mode, was not used. + +4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F + Files + + Traditionally, 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. + + The structure for a multi-page TIFF-F file will include one IFD per + page of the document. In this case, this IFD will define the + attributes for a single page. A second simplifying guideline is that + the writer of TIFF-F files SHOULD present IFDs in the same order as + the actual sequence of pages. (The pages are numbered within TIFF-F + beginning with page 0 as the first page and then ascending (i.e. 0, + 1, 2,...). However, any field values over 4 bytes will be stored + separately from the IFD. TIFF-F readers SHOULD expect IFDs to be + presented in page order, but be able to handle exceptions. + + Per [TIFF], the exact placement of image data is not specified. + However, the strip offsets for each strip of image are defined from + within each IFD. Where possible, another simplifying guideline 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 applications such as store + and forward messaging, where the file is usually prepared in advance + of the transmission, but other assumptions may apply for the size of + the image strip for applications which require the use of "streaming" + techniques (see section 4.4.7). In the event a different image strip + size guideline has been used (e.g. constant size for image strips + that may be less than the page size), this will immediately be + evident from the values/offsets of the fields that are related to + strips. + + A third simplifying guideline is that each IFD SHOULD be placed in + the TIFF-F file structure at a point which precedes the image which + the IFD describes. + + In addition, a fourth simplifying guideline 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 + + + +McIntyre, et. al. Standards Track [Page 33] + +RFC 2301 File Format for Internet Fax March 1998 + + + offsets to find the exact physical location of the image data, + whether or not it is presented in logical page order. + + If the image data is stored in multiple strips, then the strips + SHOULD occur in the file in the same order that the data they contain + occurs in the facsimile transmission, starting at the top of the + page. + + TIFF-F writers MAY make a fifth simplifying guideline, in which the + IFD, the value data and the image data to which the IFD has offsets + precede the next image IFD. However, this guideline has been relaxed + (writers MAY rather than SHOULD use it) compared to the other + guidelines given here to reflect past practices for TIFF-F. + + In the case of the minimal mode, which is also the minimal subset of + Profile S, the SHOULD's and MAY's of these guidelines become SHALL's + (see Section 3.5). + + 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). + +4.4.7. Use of TIFF-F for Streaming Applications + + TIFF-F has historically been used for handling fax image files in + applications such as store and forward messaging where the entire + size of the file is known in advance. While TIFF-F may also possibly + be used as a file format for cases such as streaming applications, + assumptions may be required that differ from those provided in this + section (e.g., the entire size and number of pages within the image + are not known in advance). As a result, a definition for the + streaming application of TIFF-F is beyond the scope of this document. + +4.5. Implementation Warnings + +4.5.1 Uncompressed data + + TIFF-F requires the ability to read and write at least one- + dimensional T.4 Huffman ("compressed") data. Uncompressed data is + not allowed. This means that the "Uncompressed" bit in T4Options or + T6Options must be set to 0. + + + + + + +McIntyre, et. al. Standards Track [Page 34] + +RFC 2301 File Format for Internet Fax March 1998 + + +4.5.2. Encoding and Resolution + + Since two-dimensional encoding is not required for Group 3 + compatibility, some historic TIFF-F readers have not been able to + read such files. The minimum subset of TIFF-F REQUIRES support for + one dimensional (Modified Huffman) files, so this choice maximizes + portability. However, implementors seeking greater efficiency SHOULD + use T.6 MMR compression when writing TIFF-F files. Some TIFF-F + readers will also support two-dimensional Modified READ files. + Implementors that wish to have the maximum flexibility in reading + TIFF-F files should support all three of these compression methods + (MH, MR and MMR). + + For the case of resolution, almost all facsimile products support + both standard (98 dpi) vertical resolution and "fine" (196 dpi) + resolution. Therefore, fine-resolution files are quite portable in + the real world. + + In 1993, the ITU-T added support for higher resolutions in the T.30 + recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per + inch based units. At the same time, support was added for metric + dimensions which are equivalent to the following inch based + resolutions: 391v x 204h and 391v x 408h. Therefore, the full set of + inch-based equivalents of the new resolutions are supported in the + TIFF-F writer, since they may appear in some image data streams + received from Group 3 facsimile devices. However, many facsimile + terminals and older versions of TIFF-F readers are likely to not + support the use of these higher resolutions. + + Per [T.4], it is permissible for applications to treat the following + XResolution values as being equivalent: <204,200> and <400,408>. In + a similar respect, the following YResolution values may also be + treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>. + These equivalencies were allowed by [T.4] to permit conversions + between inch and metric based facsimile terminals. + + In a similar respect, the optional support of metric based + resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for + completeness, since they are used in some legacy TIFF-F applications, + but this use is not recommended for the creation of TIFF-F files by a + writer. + +4.5.3. EOL byte-aligned + + The historical convention for TIFF-F has been that all EOLs in + Modified Huffman or Modified READ data must be byte-aligned. However, + Baseline TIFF has permitted use of non-byte-aligned EOLs by default, + so that a large percentage of TIFF-F reader implementations support + + + +McIntyre, et. al. Standards Track [Page 35] + +RFC 2301 File Format for Internet Fax March 1998 + + + both conventions. Therefore, the minimum subset of TIFF-F, or Profile + S, as defined in Section 3 includes support for both byte-aligned and + non- byte-aligned EOLs; see Section 3.2.2. + + An EOL is said to be byte-aligned when Fill bits have been added as + necessary before EOL codes such that EOL always ends on a byte + boundary, thus ensuring an EOL-sequence of a one byte preceded by a + zero nibble: xxxx0000 00000001. + + Modified Huffman encoding encodes bits, not bytes. This means that + the end-of-line token may end in the middle of a byte. In byte + alignment, extra zero bits (Fill) are added so that the first bit of + data following an EOL begins on a byte boundary. In effect, byte + alignment relieves application software of the burden of bit- + shifting every byte while parsing scan lines for line-oriented image + manipulation (such as writing a TIFF file). + + For Modified READ encoding, each line is terminated by an EOL and a + one bit tag bit. Per [T.4], the value of the tag bit is 0 if the + next line contains two dimensional data and 1 if the next line is a + reference line. To maintain byte alignment, fill bits are added + before the EOL/tag bit sequence, so that the first bit of data + following an MR tag bit begins on a byte boundary. + +4.5.4. EOL + + As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded + with Modified Huffman begin with an EOL, which in TIFF-F may be byte- + aligned. The last line of the image is not terminated by an EOL. In + a similar respect, images encoded with Modified READ two-dimensional + encoding begin with an EOL, followed by a tag bit. + +4.5.5. RTC Exclusion + + Aside from EOLs, TIFF-F files have historically only contained image + data. This means that applications which wish to maintain strict + conformance with the rules in [TIFF] and compatibility with + historical TIFF-F, SHOULD NOT include the Return To Control sequence + (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. + However, applications which need to support "transparency" of [T.4] + image data MAY include RTCs if the flag settings of the T4Options + field are set for non-byte aligned MH or MR image data. Implementors + of TIFF readers should also be aware that there are some existing + TIFF-F implementations which include the RTC sequence in MH/MR image + data. Therefore, TIFF-F readers MUST be able to process files which + do not include RTCs and SHOULD be able to process files which do + include RTCs. + + + + +McIntyre, et. al. Standards Track [Page 36] + +RFC 2301 File Format for Internet Fax March 1998 + + +4.5.6 Use of EOFB for T.6 Compressed Images + + TIFF-F pages which are encoded with the T.6 Modified Modified READ + compression method MUST include an "end-of-facsimile-block" (EOFB) + code at the end of each coded strip. Per [TIFF], the EOFB code is + followed by pad bits as needed to align on a byte boundary. TIFF + readers SHOULD ignore any bits other than pad bits beyond the EOFB. + +4.6. Example Use of TIFF-F + + The Profile F of TIFF (i.e. TIFF-F content) is a secondary component + of the VPIM Message, as defined in [VPIM2]. Voice messaging systems + can often handle fax store-and-forward capabilities in addition to + tradi- tional voice message store-and-forward functions. As a + result, TIFF-F fax messages can optionally be sent between compliant + VPIM systems, and may be rejected if the recipient system cannot deal + with fax. + + Refer to the VPIM Specification for proper usage of this content. + +4.7. Extended Black-and-white Fax Mode Summary + + Recommended fields are shown with an asterisk *. + + Required fields or values are shown with a double asterisk **. If the + double asterisk is on the field name, then all the listed values are + required of implementations; if the double asterisks are in the + Values column, then only the values suffixed with a double asterisk + are required of implementations. + + +---------------------------+--------------------------------+ + | Baseline Fields | Values | + +---------------------------+--------------------------------+ + | BitsPerSample | 1** | + +---------------------------+--------------------------------+ + | Compression | 3**: 1D Modified Huffman and | + | | 2D Modified Read coding | + | | 4: 2D Modified Modified Read | + | | coding | + +---------------------------+--------------------------------+ + | DateTime* | {ASCII}: date/time in 24-hour | + | | format "YYYY:MM:DD HH:MM:SS" | + +---------------------------+--------------------------------+ + | FillOrder** | 1: most significant bit first | + | | 2: least significant bit first | + +------------------------------------------------------------+ + + + + + +McIntyre, et. al. Standards Track [Page 37] + +RFC 2301 File Format for Internet Fax March 1998 + + + +------------------------------------------------------------+ + | ImageDescription* | {ASCII}: A string describing | + | | the contents of the image. | + +---------------------------+--------------------------------+ + | ImageWidth | 1728**, 2048, 2432, 2592, | + | | 3072, 3456, 3648, 4096, 4864 | + +---------------------------+--------------------------------+ + | ImageLength** | n: total number of scanlines | + | | in image | + +---------------------------+--------------------------------+ + | NewSubFileType | 2**: Bit 1 identifies single | + | | page of a multi-page document | + +---------------------------+--------------------------------+ + | Orientation | 1**-8, Default 1 | + +---------------------------+--------------------------------+ + | PhotometricInterpretation | 0: pixel value 1 means black | + | ** | 1: pixel value 1 means white | + +---------------------------+--------------------------------+ + | ResolutionUnit** | 2: inch | + | | 3: centimeter | + +---------------------------+--------------------------------+ + | RowsPerStrip** | n: number of scanlines per | + | | TIFF strip | + +---------------------------+--------------------------------+ + | SamplesPerPixel | 1** | + +---------------------------+--------------------------------+ + | Software* | {ASCII}: name & release | + | | number of creator software | + +---------------------------+--------------------------------+ + | StripByteCounts** | <n>: number or bytes in TIFF | + | | strip | + +---------------------------+--------------------------------+ + | StripOffsets** | <n>: offset from beginning of | + | | file to each TIFF strip | + +---------------------------+--------------------------------+ + | XResolution | 200, 204**, 300, 400, 408 | + | | (written in pixels/inch) | + +---------------------------+--------------------------------+ + | YResolution | 98**, 196**, 100, | + | | 200, 300, 391, 400 | + | | (written in pixels/inch) | + +---------------------------+--------------------------------+ + | Extension Fields | + +---------------------------+--------------------------------+ + + + + + + + +McIntyre, et. al. Standards Track [Page 38] + +RFC 2301 File Format for Internet Fax March 1998 + + + +---------------------------+--------------------------------+ + | T4Options | 0**: required if Compression | + | | is Modified Huffman, EOLs are | + | | not byte aligned | + | | 1: required if Compression is | + | | 2D Modified Read, EOLs are | + | | not byte aligned | + | | 4**: required if Compression | + | | is Modified Huffman, EOLs are | + | | byte aligned | + +---------------------------+--------------------------------+ + | T4Options (continued) | 5: required if Compression | + | | is 2D Modified Read, EOLs are | + | | byte aligned | + +---------------------------+--------------------------------+ + | T6Options | 0: required if Compression is | + | | 2D Modified Modified Read | + +---------------------------+--------------------------------+ + | DocumentName* | {ASCII}: name of scanned | + | | document | + +---------------------------+--------------------------------+ + | PageNumber** | n,m: page number followed by | + | | total page count | + +---------------------------+--------------------------------+ + | New Fields | + +---------------------------+--------------------------------+ + | BadFaxLines* | number of "bad" scanlines | + | | encountered during reception | + +---------------------------+--------------------------------+ + | CleanFaxData* | 0: no "bad" lines | + | | 1: "bad" lines exist, but were | + | | regenerated by receiver | + | | 2: "bad" lines exist, but have | + | | not been regenerated | + +---------------------------+--------------------------------+ + | ConsecutiveBadFaxLines* | Max number of consecutive | + | | "bad" lines received | + +---------------------------+--------------------------------+ + +5. Lossless JBIG Black-and-White Fax Mode + + This section defines the lossless JBIG black-and-white mode or + Profile J of TIFF for facsimile. Implementations of this profile are + required to also implement Profile S. + + + + + + + +McIntyre, et. al. Standards Track [Page 39] + +RFC 2301 File Format for Internet Fax March 1998 + + + The previous section described the extended interchange set of TIFF + fields for black-and-white fax, which provided support for the MH, MR + and MMR compression of black-and-white images. This section adds a + mode with JBIG compression capability. + +5.1. Overview + + This section describes a black-and-white mode that uses JBIG + compression. The ITU-T has approved the single-progression sequential + mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers + improved compression for halftoned originals. JBIG compression is + used in accordance with the application rules given in ITU-T Rec. + T.85 [T.85]. + + This mode is essentially the extended black-and-white mode with JBIG + compression used instead of MH, MR or MMR. + +5.2. Required TIFF Fields + + This section lists the required fields and the values they must have + to be ITU-compatible. Besides the fields listed in Section 2.2.1, the + extended black-and-white fax mode requires the following fields. + +5.2.1. Baseline fields + + The TIFF fields that SHALL be used in this mode are the same as those + described in Section 4.2.1 for the extended black-and-white mode, + with two exceptions: the following text replaces the text in Section + 4.2.1 for the Compression and FillOrder fields. + +Compression(259) = 9. SHORT + RequiredByTIFFBaseline + 9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG). This is + a TIFF extension value. + Default = 1 (and is not applicable; field must be specified). + +FillOrder(266) = 2. SHORT + RequiredByTIFFBaseline + 2 = Pixels are arranged within a byte such that pixels with lower + column values are stored in the lower-order bits of the bytes, i.e., + least significant bit first (LSB). + + NOTE: The JBIG coding of black-and-white image data in Profile J + follows ITU-T Rec. T.85 [T.85], which specifies LSB first ordering + within a byte. Note that Baseline TIFF readers are only required to + support MSB first ordering or FillOrder = 1. + +5.2.2. Extension fields + + + +McIntyre, et. al. Standards Track [Page 40] + +RFC 2301 File Format for Internet Fax March 1998 + + + Same fields as those in Section 2.2.1. + +5.2.3. New fields + + None. + +5.3. Recommended TIFF Fields + + See Section 2.2.3 and 2.2.4. + +5.4. Lossless JBIG Black-and-white Fax Mode Summary + + Recommended fields are shown with an asterisk *. + + Required fields or values are shown with a double asterisk **. If the + double asterisk is on the field name, then all the listed values are + required of implementations; if the double asterisks are in the + Values column, then only the values suffixed with a double asterisk + are required of implementations. + + +---------------------------+--------------------------------+ + | Baseline Fields | Values | + +---------------------------+--------------------------------+ + | BitsPerSample | 1** | + +---------------------------+--------------------------------+ + | Compression | 9**: JBIG coding | + +---------------------------+--------------------------------+ + | DateTime* | {ASCII}: date/time in 24-hour | + | | format "YYYY:MM:DD HH:MM:SS" | + +---------------------------+--------------------------------+ + | FillOrder** | 1: most significant bit first | + | | 2: least significant bit first | + +---------------------------+--------------------------------+ + | ImageDescription* | {ASCII}: A string describing | + | | the contents of the image. | + +---------------------------+--------------------------------+ + | ImageWidth | 1728**, 2048, 2432, 2592, | + | | 3072, 3456, 3648, 4096, 4864 | + +---------------------------+--------------------------------+ + | ImageLength** | n: total number of scanlines | + | | in image | + +---------------------------+--------------------------------+ + | NewSubFileType** | 2: Bit 1 identifies single | + | | page of a multi-page document | + +---------------------------+--------------------------------+ + | Orientation | 1**-8, Default 1 | + +------------------------------------------------------------+ + + + + +McIntyre, et. al. Standards Track [Page 41] + +RFC 2301 File Format for Internet Fax March 1998 + + + +---------------------------+--------------------------------+ + | PhotometricInterpretation | 0: pixel value 1 means black | + | ** | 1: pixel value 1 means white | + +---------------------------+--------------------------------+ + | ResolutionUnit** | 2: inch | + | | 3: centimeter | + +---------------------------+--------------------------------+ + | RowsPerStrip** | n: number of scanlines per | + | | TIFF strip | + +---------------------------+--------------------------------+ + | SamplesPerPixel** | 1 | + +---------------------------+--------------------------------+ + | Software* | {ASCII}: name & release | + | | number of creator software | + +---------------------------+--------------------------------+ + | StripByteCounts** | <n>: number of bytes in TIFF | + | | strip | + +---------------------------+--------------------------------+ + | StripOffsets** | <n>: offset from beginning of | + | | file to each TIFF strip | + +---------------------------+--------------------------------+ + | XResolution | 200, 204**, 300, 400, 408 | + | | (written in pixels/inch) | + +---------------------------+--------------------------------+ + | YResolution | 98**, 196**, 100, | + | | 200, 300, 391, 400 | + | | (written in pixels/inch) | + +---------------------------+--------------------------------+ + | Extension Fields | + +---------------------------+--------------------------------+ + | DocumentName* | {ASCII}: name of document | + | | scanned | + +---------------------------+--------------------------------+ + | PageNumber** | n,m: page number followed by | + | | total page count | + +---------------------------+--------------------------------+ + | New Fields | + +---------------------------+--------------------------------+ + | GlobalParametersIFD* | IFD: global parameters IFD | + +---------------------------+--------------------------------+ + | ProfileType* | n: type of data stored in file | + +---------------------------+--------------------------------+ + | FaxProfile* | n: ITU-compatible fax mode | + +---------------------------+--------------------------------+ + | CodingMethods* | n: compression algorithms used | + | | in file | + +---------------------------+--------------------------------+ + + + + +McIntyre, et. al. Standards Track [Page 42] + +RFC 2301 File Format for Internet Fax March 1998 + + +6. Base Color Fax Mode + +6.1. Overview + + This section defines the lossy color mode or Profile C of TIFF for + facsimile. Implementations of this profile are required to also + implement Profile S. + + This is the base mode for color and grayscale facsimile, which means + that all applications that support color fax must support this mode. + The basic approach is the lossy JPEG compression [T.4, Annex E; T.81] + of L*a*b* color data [T.42]. Grayscale applications use the L* + lightness component; color applications use the L*, a* and b* + components. + + This mode uses a new PhotometricInterpretation field value to + describe the L*a*b* encoding specified in [T.42]. This encoding + differs in two ways from the other L*a*b* encodings used in TIFF + [TIFF, TTN1]: it specifies a different default range for the a* and + b* components, based on a comprehensive evaluation of existing + hardcopy output, and it optionally allows selectable range for the + L*, a* and b* components. + +6.2. Required TIFF Fields + + This section lists the required fields, in addition to those given in + Section 2.2.1, and the values they must support to be compatible with + ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4. + +6.2.1. Baseline Fields + +ImageWidth(256). SHORT or LONG + This mode supports the following fixed page widths: 864, 1024, 1216, + 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864. + +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) + +BitsPerSample(258) = 8, 12. SHORT + Count = SamplesPerPixel + The base color fax mode requires 8 bits per sample, with 12 as an + option. 12 bits per sample is not baseline TIFF. + +Compression(259) = 7. SHORT + Base color fax mode uses Baseline JPEG compression. Value 7 + represents JPEG compression as specified in [TTN2]. + + + +McIntyre, et. al. Standards Track [Page 43] + +RFC 2301 File Format for Internet Fax March 1998 + + +FillOrder(266) = 1 , 2. SHORT + RequiredByTIFFBaseline + Profile C readers must be able to read data in both bit orders, + but the vast majority of facsimile products store data LSB + first, exactly as it appears on the telephone line. + 1 = Most Significant Bit first. + 2 = Least Significant Bit first + +PhotometricInterpretation(262) = 10. SHORT + Base color fax mode requires pixel values to be stored using the CIE + L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is + indicated by the PhotometricInterpretation value 10, referred to as + ITULAB. With this encoding, the minimum sample value is mapped to 0 + and the maximum sample value is mapped to (2^n - 1), i.e. the + maximum value, where n is the BitsPerSample value. The conversion + from unsigned ITULAB-encoded samples values to signed CIE L*a*b* + values is determined by the Decode field; see Sec. 6.2.3 + + NOTE: PhotometricInterpretation values 8 and 9 specify encodings for + use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1] + data, but they are fixed encodings, which use different minimum and + maximum samples than the T.42 default encoding. As currently defined, + they are not able to represent fax-encoded L*a*b* data. + +ResolutionUnit(296) = 2, 3. SHORT + The unit of measure for resolution. 2 = inch, 3 = centimeter; + Default = 2 (field may be omitted if this is the value) + +SamplesPerPixel(277) = 1, 3. SHORT + 1: L* component only, required in base color mode + 3: L*, a*, b* components + Encoded according to PhotometricInterpretation field + +XResolution(282) = 100, 200, 300, 400. RATIONAL +YResolution(283) = 100, 200, 300, 400. RATIONAL + The resolution of the image is expressed in pixels per resolution + unit. In pixels per inch, allowed XResolution values are: 100, 200, + 300, and 400. The base color fax mode requires the pixels to be + square, hence YResolution must equal XResolution. Base resolution is + 200 pixels per inch and SHALL be supported by all implementations of + this mode. See Section 2.2.2 for inch-metric equivalency. + +NOTE: Not all combinations of XResolution, YResolution and ImageWidth +are legal. The following table gives the legal combinations for inch- +based resolutions and the corresponding paper sizes [T.30]. + + + + + + +McIntyre, et. al. Standards Track [Page 44] + +RFC 2301 File Format for Internet Fax March 1998 + + + +--------------------------------+---------------------------+ + | XResolution x YResolution | ImageWidth | + +--------------------------------+---------------------------+ + | 100 x 100 | 864 | 1024 | 1216 | + +--------------------------------+---------------------------+ + | 200 x 200 | 1728 | 2048 | 2432 | + +--------------------------------+---------------------------+ + | 300 x 300 | 2592 | 3072 | 3648 | + +--------------------------------+---------------------------+ + | 400 x 400 | 3456 | 4096 | 4864 | + +--------------------------------+---------------------------+ + |Letter,A4| B4 | A3 | + | Legal | | | + +---------------------------+ + | Paper Size | + +---------------------------+ + +6.2.2 Extension Fields + +The JPEG compression standard allows for the a*b* chroma components of +an image to be subsampled relative to the L* lightness component. The +extension fields ChromaSubSampling and ChromaPositioning define the +subsampling. They are the same as YCbCrSubSampling and YCbCrPositioning +in [TIFF], but have been renamed to reflect their applicability to other +color spaces. + +ChromaSubSampling(530). SHORT + Count = 2 + Specifies the subsampling factors for the chroma components of a + L*a*b* image. The two subfields of this field, ChromaSubsampleHoriz + and ChromaSubsampleVert, specify the horizontal and vertical + subsampling factors respectively. + + SHORT 0: ChromaSubsampleHoriz = 1, 2. + 1: equal numbers of lightness and chroma samples horizontally, + 2: twice as many lightness samples as chroma samples horizontally, + + SHORT 1: ChromaSubsampleVert = 1, 2. + 1: equal numbers of lightness and chroma samples vertically, + 2: twice as many lightness samples as chroma samples vertically, + + The default value for ChromaSubSampling is (2,2), which is the + default for chroma subsampling in color fax [T.4, Annex E]. No + chroma subsampling, i.e. ChromaSubSampling = (1,1), is an option + for color fax + +ChromaPositioning(531) = 1. SHORT + Specifies the spatial positioning of chroma components relative to + + + +McIntyre, et. al. Standards Track [Page 45] + +RFC 2301 File Format for Internet Fax March 1998 + + + the lightness component. + 1: centered, + A value of 1 means chrominance samples are spatially offset and + centered with respect to luminance samples. See the current TIFF + specification under YcbCr positioning for further information. + Default = 1, which is what ITU-T T.4, Annex E specifies. + +6.2.3. New Fields + +Decode(433). SRATIONAL + Count = 2 * SamplesPerPixel + Describes how to map image sample values into the range of values + appropriate for the current color space. In general, the values are + taken in pairs and specify the minimum and maximum output value for + each color component. For the base color fax mode, Decode has a + count of 6 values and maps the unsigned ITULAB-encoded sample values + (Lsample, asample, bsample) to signed L*a*b* values, as follows:. + + L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1) + a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1) + b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1) + + where Decode[0], Decode[2] and Decode[4] are the minimum values for + L*, a* and b*; Decode[1], Decode[3] and Decode[5] are the maximum + values for L*, a* and b*; and n is the BitsPerSample, either 8 or + 12. For example, when n=8, L*=Decode[0] when Lsample=0 and + L*=Decode[1] when Lsample=255. + + ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range + and offset for each component, which are related to the minimum and + maximum values as follows: + + minimum = - (range x offset) / 2^n - 1 + maximum = minimum + range + + The Decode field default values depend on the color space. For the + ITULAB color space encoding, the default values correspond to the + base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The + following table gives the base range and offset values for + BitsPerSample=8 and 12, and the corresponding default minimum and + maximum default values for the Decode field, calculated using the + equations above when PhotometricInterpetation=10. + + + + + + + + + +McIntyre, et. al. Standards Track [Page 46] + +RFC 2301 File Format for Internet Fax March 1998 + + + +-----------------------------------------------+ + | ITU-T Rec. T.42 | Decode | + +---------+-----------| base values | default values | + | BitsPer + Component +------------------+----------------------------+ + | -Sample | | Range | Offset | Min | Max | + +---------+-----------+--------+---------+--------------+-------------+ + | 8 | L* | 100 | 0 | 0 | 100 | + | +-----------+--------+---------+--------------+-------------+ + | | a* | 170 | 128 | -21760/255 | 21590/255 | + | +-----------+--------+---------+--------------+-------------+ + | | b* | 200 | 96 | -19200/255 | 31800/255 | + +---------+-----------+--------+---------+--------------+-------------+ + | 12 | L* | 100 | 0 | 0 | 100 | + | +-----------+--------+---------+--------------+-------------+ + | | a* | 170 | 2048 | -348160/4095 | 347990/4095 | + | +-----------+--------+---------+--------------+-------------+ + | | b* | 200 | 1536 | -307200/4095 | 511800/4095 | + +---------+-----------+--------+---------+--------------+-------------+ + + For example, when PhotometricInterpretation=10 and BitsPerSample=8, + the default value for Decode is (0, 100, -21760/255, 21590/255, + -19200/255, 31800/255). + +6.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + +6.4 Base Color Fax Mode Summary + + Recommended fields are shown with an asterisk * + + Required fields or values are shown with a double asterisk **. If the + double asterisk is on the field name, then all the listed values are + required of implementations; if the double asterisks are in the + Values column, then only the values suffixed with a double asterisk + are required of implementations. + + +---------------------------+--------------------------------+ + | Baseline Fields | Values | + +---------------------------+--------------------------------+ + | BitsPerSample | 8**: 8 bits per color sample | + | | 12: optional 12 bits/sample | + +---------------------------+--------------------------------+ + | Compression** | 7: JPEG | + +---------------------------+--------------------------------+ + | DateTime* | {ASCII}: date/time in 24-hour | + | | format "YYYY:MM:DD HH:MM:SS" | + +---------------------------+--------------------------------+ + + + +McIntyre, et. al. Standards Track [Page 47] + +RFC 2301 File Format for Internet Fax March 1998 + + + +------------------------------------------------------------+ + | FillOrder** | 1: most significant bit first | + | | 2: least significant bit first | + +---------------------------+--------------------------------+ + | ImageDescription* | {ASCII}: A string describing | + | | the contents of the image. | + +---------------------------+--------------------------------+ + | ImageWidth | 864, 1024, 1216, 1728**, 2048 | + | | 2432, 2592, 3072, 3456, 3648 | + | | 4096, 4864 | + +---------------------------+--------------------------------+ + | ImageLength** | n: total number of scanlines | + | | in image | + +---------------------------+--------------------------------+ + | NewSubFileType** | 2: Bit 1 identifies single page| + | | of a multi-page document | + +---------------------------+--------------------------------+ + | Orientation | 1**-8, Default 1 | + +---------------------------+--------------------------------+ + | PhotometricInterpretation | 10**: ITULAB | + +---------------------------+--------------------------------+ + | ResolutionUnit** | 2: inch | + | | 3: centimeter | + +---------------------------+--------------------------------+ + | RowsPerStrip** | n: number of scanlines per | + | | TIFF strip | + +---------------------------+--------------------------------+ + | SamplesPerPixel | 1**: L* (lightness) | + | | 3: LAB | + +---------------------------+--------------------------------+ + | Software* | {ASCII}: name & release number | + | | of creator software | + +---------------------------+--------------------------------+ + | StripByteCounts** | <n>: number or bytes in | + | | TIFF strip | + +---------------------------+--------------------------------+ + | StripOffsets** | <n>: offset from beginning | + | | of file to each TIFF strip | + +---------------------------+--------------------------------+ + | XResolution | 100, 200**, 300, 400 (written | + | | in pixels/inch) | + +---------------------------+--------------------------------+ + | YResolution | 100, 200**, 300, 400 | + | | (must equal XResolution) | + +---------------------------+--------------------------------+ + + + + + + +McIntyre, et. al. Standards Track [Page 48] + +RFC 2301 File Format for Internet Fax March 1998 + + + +---------------------------+--------------------------------+ + | Extension Fields | + +---------------------------+--------------------------------+ + | DocumentName* | {ASCII}: name of scanned | + | | document | + +---------------------------+--------------------------------+ + | PageNumber** | n,m: page number followed by | + | | total page count | + +---------------------------+--------------------------------+ + | ChromaSubSampling | (1,1), (2, 2)** | + | | (1, 1): equal numbers of | + | | lightness and chroma samples | + | | horizontally and vertically | + | | (2, 2): twice as many lightness| + | | samples as chroma samples | + | | horizontally and vertically | + +---------------------------+--------------------------------+ + | ChromaPositioning | 1**: centered | + +---------------------------+--------------------------------+ + | New Fields | + +---------------------------+--------------------------------+ + | Decode** | minL, maxL, mina, maxa, minb, | + | | maxb: minimum and maximum | + | | values for L*a*b* | + +---------------------------+--------------------------------+ + | GlobalParametersIFD* | IFD: IFD containing | + | | global parameters | + +---------------------------+--------------------------------+ + | ProfileType* | n: type of data stored in | + | | TIFF file | + +---------------------------+--------------------------------+ + | FaxProfile* | n: ITU-compatible fax mode | + +---------------------------+--------------------------------+ + | CodingMethods* | n: compression algorithms | + | | used in file | + +---------------------------+--------------------------------+ + | VersionYear* | byte sequence: year of ITU std | + +---------------------------+--------------------------------+ + +7. Lossless Color Mode + + This section defines the lossless color mode or Profile L of TIFF for + facsimile. Implementations of this profile are required to also + implement Profiles S and C. + + + + + + + +McIntyre, et. al. Standards Track [Page 49] + +RFC 2301 File Format for Internet Fax March 1998 + + +7.1. Overview + + This mode, defined in [T.43], uses JBIG to losslessly code three + types of color and grayscale images: one bit per color CMY, CMYK and + RGB images; a palettized (i.e. mapped) color image; and continuous + tone color and grayscale images. The last two are multi-level and use + the L*a*b* encoding specified in [T.42]. + +7.1.1. Color Encoding + + While under development, this mode was called T.Palette, as one of + its major additions was palette or mapped color images. Baseline TIFF + only allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* color + maps, using the encoding specified in ITU-T Rec. T.42. Palette color + images are expressed with indices (bits per sample) of 12 bits or + less, or optionally 13 to 16 bits, per [T.43]. + + Enabling T.43 color maps in TIFF requires the extension field + Indexed, defined in [TTN1], and the PhotometricInterpretation field + value 10, defined in Section 6.2.1. The following table shows the + corresponding PhotometricInterpretation, SamplesPerPixel, + BitsPerSample and Indexed field values for the different T.43 image + types. + + +----------------------------------------------------------+ + | Image Type |PhotometricIn| Samples | Bits Per | Indexed | + | |-terpretation| PerPixel | Sample | | + |------------+-------------+----------+----------+---------| + | RGB | 2=RGB | 3 | 1 | 0 | + +----------------------------------------------------------+ + | CMY | 5=CMYK | 3 | 1 | 0 | + +------------+-------------+----------+----------+---------+ + | CMYK | 5=CMYK | 4 | 1 | 0 | + +------------+-------------+----------+----------+---------+ + | Palette | 10=ITULAB | 1 | n | 1 | + +------------+-------------+----------+----------+---------+ + | Grayscale | 10=ITULAB | 1 | 8, 12 | 0 | + +------------+-------------+----------+----------+---------+ + | Color | 10=ITULAB | 3 | 8, 12 | 0 | + +------------+-------------+----------+----------+---------+ + +7.1.2. JBIG Encoding + + T.43 uses the single-progression sequential mode of JBIG, defined in + ITU-T Rec. T.82. To code multi-level images using JBIG, which is a + bi-level compression method, an image is resolved into a set of bit- + planes, and each bit-plane is then JBIG compressed. For continuous + tone color and grayscale images, Gray code conversion is used. The + + + +McIntyre, et. al. Standards Track [Page 50] + +RFC 2301 File Format for Internet Fax March 1998 + + + Gray code conversion is part of the data stream encoding, and is + therefore invisible to TIFF. + +7.2. Required TIFF Fields + + This section lists the required fields, in addition to those in + Section 2.2.1, and the values they must have to be compatible with + ITU-T Rec. T.43. + +7.2.1. Baseline Fields + +ImageWidth(256). SHORT or LONG + Same page widths as the base color mode; see Section 6.2.1. + +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) + +BitsPerSample(258) = 1, 2-8, 9-16. SHORT + Count = SamplesPerPixel + RGB, CMY, CMYK: 1 bit per sample + Continuous tone (L*a*b*): 2-8 bits per sample, 9-12 bits optional + Palette color: 12 or fewer bits per sample, 13-16 bits optional + Note: More than 8 bits per sample is not baseline TIFF. + +ColorMap(320). SHORT + Count = 3 * number of sample values + Lossless color fax mode supports palette-color (indexed) images + where the single component value is used as an index into a full + color lookup table stored in the ColorMap field. The sample value is + encoded using the number of bits given by the BitsPerSample field + value. However, per [T.43],the number of sample values may be less + than 2**BitsPerSample. The color lookup table is only required to + have as many entries as there are number of sample values. For + palette-color images in lossless color fax mode, the ITULAB encoding + with 8 or optionally 12 bits per color map value is supported. To + utilize a color map, the TIFF Indexed field must be present. TIFF + orders the color map values so that all the L* values come first, + followed by all the a* values and then all the b* values. Because + ITU-T Rec. T.43 specifies a "chunky" ordering with the L*a*b* + components of the first value, followed by those of the second + value, and so on, reproducing color map values from a fax data + stream in a TIFF file requires reordering values. + +Compression(259) = 10. SHORT +10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG) + coding + + + +McIntyre, et. al. Standards Track [Page 51] + +RFC 2301 File Format for Internet Fax March 1998 + + +FillOrder(266) = 1 , 2. SHORT + RequiredByTIFFBaseline + Profile F readers must be able to read data in both bit orders, + but the vast majority of facsimile products store data LSB + first, exactly as it appears on the telephone line. + 1 = Most Significant Bit first. + 2 = Least Significant Bit first + +PhotometricInterpretation(262) = 2, 5, 10. SHORT + 2: RGB + 5: CMYK, including CMY + 10: ITULAB + Image data may also be stored as palette color images, where pixel + values are represented by a single component that is an index into a + color map using the ITULAB encoding. This color map is specified by + the ColorMap field. To use palette color images, set the + PhotometricInterpretation to 10,SamplesPerPixel to 1, and Indexed to + 1. The color map is stored in the ColorMap field. See Section 7.1.1 + for further discussion on the color encoding. + +ResolutionUnit(296) = 2, 3. SHORT + The unit of measure for resolution. 2 = inch, 3 = centimeter; + Default = 2 (field may be omitted if this is the value) + +SamplesPerPixel(277) = 1, 3, 4. SHORT + 1: Palette color image, or L*-only if Indexed = 0 and + PhotometricInterpretation is 10 (ITULAB). + 3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK). + 4: CMYK. + +XResolution(282) = 100, 200, 300, 400. RATIONAL +YResolution(283) = 100, 200, 300, 400. RATIONAL + The resolution of the image is expressed in pixels per resolution + unit. In pixels per inch, allowed XResolution values are: 100, 200, + 300, and 400. The lossless color fax mode requires the pixels to be + square, hence YResolution must equal XResolution. Base resolution is + 200 pixels per inch. See Section 2.2.2 for inch-metric equivalency. + +7.2.2. Extension Fields + +Indexed(364) = 0, 1. SHORT + 0: not a palette-color image + 1: palette-color image + This field is used to indicate that each sample value is an index + into an array of color values specified in the ColorMap field. + Lossless color fax mode supports palette-color images with the + ITULAB encoding. The SamplesPerPixel value must be 1. + + + + +McIntyre, et. al. Standards Track [Page 52] + +RFC 2301 File Format for Internet Fax March 1998 + + +7.2.3. New Fields + +Decode(433) SRATIONAL + Decode is used in connection with the ITULAB encoding of image data + and color map values; see Section 6.2.3. + +7.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + +7.4. Lossless Color Fax Mode Summary + + Recommended fields are shown with an asterisk *. + + +--------------------+--------------------------------------+ + | Baseline Fields | Values | + +--------------------+--------------------------------------+ + | BitsPerSample | 1: Binary RGB, CMY(K) | + | | 8: 8 bits per color sample | + | | 9-16: optional | + +--------------------+--------------------------------------+ + | ColorMap | n: LAB color map | + +--------------------+--------------------------------------+ + | Compression | 10: JBIG, per T.43 | + +--------------------+--------------------------------------+ + | DateTime* | {ASCII}: date/time in the 24-hour | + | | format "YYYY:MM:DD HH:MM:SS" | + +--------------------+--------------------------------------+ + | FillOrder** | 1: Most significant bit first | + | | 2: Least significant bit first | + +--------------------+--------------------------------------+ + | ImageDescription* | {ASCII}: A string describing the | + | | contents of the image. | + +--------------------+--------------------------------------+ + | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | + | | 2592, 3072, 3456, 3648, 4096, 4864 | + +--------------------+--------------------------------------+ + | ImageLength** | n: total number of scanlines in image| + +--------------------+--------------------------------------+ + | NewSubFileType | 2: Bit 1 identifies single page of a | + | | multi-page document | + +--------------------+--------------------------------------+ + | Orientation | 1**-8, Default 1 | + +--------------------+--------------------------------------+ + | PhotometricInter- | 2: RGB | + | pretation | 5: CMYK | + | | 10: ITULAB | + +--------------------+--------------------------------------+ + + + +McIntyre, et. al. Standards Track [Page 53] + +RFC 2301 File Format for Internet Fax March 1998 + + + +--------------------+--------------------------------------+ + | ResolutionUnit | 2: inch | + | | 3: centimeter | + +--------------------+--------------------------------------+ + | RowsPerStrip | n: number of scanlines per TIFF strip| + +--------------------+--------------------------------------+ + | SamplesPerPixel | 1: L* (lightness) | + | | 3: LAB, RGB, CMY | + | | 4: CMYK | + +--------------------+--------------------------------------+ + | Software* | {ASCII}: name & release number of | + | | creator software | + +--------------------+--------------------------------------+ + | StripByteCounts | <n>: number or bytes in TIFF strip | + +--------------------+--------------------------------------+ + | StripOffsets | <n>: offset from beginning of file to| + | | each TIFF strip | + +--------------------+--------------------------------------+ + | XResolution | 100, 200, 300, 400 (written in | + | | pixels/inch) | + +--------------------+--------------------------------------+ + | YResolution | equal to XResolution (pixels must be | + | | square) | + +--------------------+--------------------------------------+ + | Extension Fields | + +--------------------+--------------------------------------+ + | DocumentName* | {ASCII}: name of scanned document | + +--------------------+--------------------------------------+ + | PageNumber | n,m: page number followed by total | + | | page count | + +--------------------+--------------------------------------+ + | Indexed | 0: not a palette-color image | + | | 1: palette-color image | + +--------------------+--------------------------------------+ + | New Fields | + +--------------------+--------------------------------------| + | Decode | minL, maxL, mina, maxa, minb, maxb: | + | |minimum and maximum values for L*a*b* | + +--------------------+--------------------------------------+ + | GlobalParameters | IFD: global parameters IFD | + | IFD* | | + +-----------------------------------------------------------+ + + + + + + + + + +McIntyre, et. al. Standards Track [Page 54] + +RFC 2301 File Format for Internet Fax March 1998 + + + +--------------------+--------------------------------------+ + | ProfileType* | n: type of data stored in TIFF file | + +--------------------+--------------------------------------+ + | FaxProfile* | n: ITU-compatible fax mode | + +--------------------+--------------------------------------+ + | CodingMethods* | n:compression algorithms used in | + | | file | + +--------------------+--------------------------------------+ + | VersionYear* | byte sequence: year of ITU fax std | + +--------------------+--------------------------------------+ + +8. Mixed Raster Content Mode + + This section defines the Mixed Raster Content mode or Profile M of + TIFF for facsimile. Implementations of this profile are required to + implement Profiles S and C, and may optionally implement Profiles F, + J and L. + +8.1. Overview + + Unlike previous fax modes, which use a single coding method and + spatial resolution for an entire fax page, the Mixed Raster Content + mode [T.44] enables different coding methods and resolutions within a + single page. For example, consider a page that contains black-and- + white text, which is best coded with MMR or JBIG, a color bar chart, + best coded with JBIG, and a scanned color image, best coded with + JPEG. Similarly, while spatial resolution of 400 pixels per inch may + be best for the black-and- white text, 200 pixel per inch is usually + sufficient for a color image. + + Rather than applying one coding method and resolution to all + elements, MRC allows multiple coders and resolutions within a page. + By itself, MRC does not define any new coding methods or resolutions. + Instead it defines a 3-layer image model for structuring and + combining the scanned image data. The MRC 3-layer model has been + applied here using the TIFF format to yield a data structure which + differs from [T.44] though it applies the same coding methods, uses + the same compressed image data stream and is consistent with the TIFF + principle of a single IFD per image. + +8.1.1. MRC 3-layer model + + The 3 layers of the MRC model are Foreground and Background, which + are both multi-level, and Mask, which is bi-level. Each layer may + appear only once on a page and is coded independently of the other + two. In our earlier example, the black-and-white text could be in the + Mask layer, the color chart in the Foreground layer, and the color + image in the Background layer. + + + +McIntyre, et. al. Standards Track [Page 55] + +RFC 2301 File Format for Internet Fax March 1998 + + + Each layer is an image and, when present, is represented by at least + one IFD in a TIFF file. This is consistent with TIFF, which provides + fields to define the attributes, such as resolution, image size, bits + per sample, etc., of a single image or layer. The distribution of + content among layers is determined by the writer, as is the choice of + coding method, color encoding and spatial resolution for a layer. + + The final image is obtained by using the Mask layer to select pixels + from the other two layers. When the Mask layer pixel value is 1, the + corresponding pixel from the Foreground layer is selected; when it is + 0, the corresponding pixel from the Background layer is selected. + Details are given in the Introduction of [T.44]. + + Not all pages, and not all parts of a page, require 3 layers. If + there is only one layer present, then that layer is the primary image + or IFD. If there is more than one layer, then the Mask must be one of + the layers, in which case it is the primary image and it must be page + size. + + MRC allows a page to be split into strips, with a variable number of + scanlines in a strip. A strip can have 1, 2 or 3 layers. A single, + stripped layer may be stored as a single, stripped image in an IFD, + e.g., all strips associated with the Background layer may be treated + as a single image. Alternatively, each strip associated with a layer + may be stored as a separate image or IFD, e.g., the Background layer + can be composed of several images that are offset vertically with + respect to the page. In this case, there can be no overlap between + images associated with a single layer. According to [T.4] Annex G, + strips having more than 1 layer SHOULD NOT be more than 256 lines in + length unless the capability to receive longer strips has been + negotiated. + + Furthermore, color fax also requires the spatial resolutions of + Background and Foreground images to be legal fax values that are also + integer factors of the Mask image resolution. For example, if the + Mask Layer resolution is 400 pixels per inch, then allowed + resolutions for the Foreground and Background layers are 100, 200 or + 400 pixels per inch; if the Mask is at 300 pixels per inch, then + allowed values are 100 and 300. The Foreground and Background layer + resolutions can be independently set. + +8.1.2. A TIFF Representation for the MRC 3-layer model + + In the TIFF representation of the 3-layer MRC model, each page is + represented by a single IFD, called the Primary IFD, that represents + the Mask layer (unless the Foreground or Background is the single + layer present), and a set of child IFDs that are referenced through + the SubIFDs extension field [TTN1]. To distinguish MRC-specific + + + +McIntyre, et. al. Standards Track [Page 56] + +RFC 2301 File Format for Internet Fax March 1998 + + + SubIFDs from other SubIFDs, the NewSubFileType field MUST have Bit 4 + ON, indicating an MRC-related IFD. A new ImageLayer field is also + introduced that consists of two values that identify the layer + (Foreground, Background, or Mask) and the order within the layer + (first, second, ... image of the layer); see Section 8.2.3. + + Because MRC allows strips with variable numbers of scanlines, a + reader MUST support StripRowCounts field because a writer may use it + in place of the RowsPerStrip field in this mode. The StripRowCounts + field allows each layer, with a variable number of scanlines in each + strip, to be represented by a single IFD, when the coding parameters + are the same for all strips in the layer. The MRC standard [T.44] + allows the Foreground and Background layers to have strips with + different coding parameters. In this case, a separate IFD is required + to represent the strips which use different coding parameters; see + text in next paragraph. In all cases, the Mask layer is required to + be represented by a single IFD and a single set of coding parameters. + + The use of SubIFDs to store child IFDs is described in [TTN1]. An + example is shown graphically below. The Primary IFD associated with + page 1 (PrimaryIFD 0) points to page 2 (PrimaryIFD 1) with the + nextIFD offset. The Primary IFD, corresponding to the Mask layer + (ImageLayer=[2,1]), contains a SubIFDs field that points to a list of + child IFDs. The first child IFD represents one image of the + Background layer, i.e., ImageLayer=[1,1]. This child IFD points to + the second child IFD via the nextIFD offset. This child represents + the second Background layer image, ImageLayer=[1,2]. Finally, the + second child points to the third child, which corresponds to the + single Foreground layer image, ImageLayer=[3,1]. The next IFD offset + associated with this Foreground image is 0, indicating no more child + IFDs exist. Each primary IFD has the NewSubFileType set to 18, + indicating the IFD is MRC-specific (bit 4) and that it is a single + page of a multi-page document (bit 1). Each child IFD has the + NewSubFileType set to 16, indicating the IFD is MRC-specific. The 'V' + character should be read as a down-pointing arrow. + + (nextIFD) + PRIMARY IFD 0 ------------> PRIMARY IFD 1--> ... + ImageLayer = [2,1] + NewSubFileType = 18 + SubIFDs + | + V + Child IFD + ImageLayer = [1,1] + NewSubFileType = 16 + | + |(nextIFD) + + + +McIntyre, et. al. Standards Track [Page 57] + +RFC 2301 File Format for Internet Fax March 1998 + + + | + V + Child IFD + ImageLayer = [1,2] + NewSubFileType = 16 + | + |(nextIFD) + | + V + Child IFD + ImageLayer = [3,1] + NewSubFileType = 16 + | + |(nextIFD) + V + 0 + + In the example above, the SubIFDs field of the Primary IFD points to + the first IFD in a list of child IFDs. TIFF allows the SubIFDs field + to point to an array of IFDs, each of which can be the first of a + list of IFDs. An MRC-enabled TIFF reader must scan all available + child IFDs to locate and identify IFDs associated with MRC layers. + + In the case where the Background or Foreground layers are described + with multiple IFDs, the XPosition and YPosition TIFF fields specify + the offset to the upper-left corner of the IFD with respect to the + Mask layer; see Section 8.2.2. When there is only a single layer + (Mask, Foreground, or Background), it is stored as the Primary IFD. + +8.2. Required TIFF Fields + + This section describes the TIFF fields required, in addition to those + in Section 2.2.1, to represent MRC mode fax images. Since MRC mode + stores fax data as a collection of images corresponding to layers or + parts of layers, the coding methods, color encodings and spatial + resolutions used by previous modes apply to MRC. Therefore, the + descriptions here will typically reference the appropriate earlier + section. Fields and values specific to MRC mode are pointed out. + +8.2.1. Baseline Fields + +ImageWidth(256). SHORT or LONG + Same page widths as the base color mode; see Section 6.2.1. + In the MRC mode, the width of a Foreground or Background image in + the coded data stream may be less than the page width. In this case, + the image width in the coded data steam is used to interpret the + coded data, and the value of this field is used as the page width. + + + + +McIntyre, et. al. Standards Track [Page 58] + +RFC 2301 File Format for Internet Fax March 1998 + + +NewSubFileType(254) = 16, 18. LONG + For MRC fax mode, the NewSubFileType field has two bits that are + required. + Bit 1 indicates a single page of a multi-page document and must be + set for the Primary IFD; + Bit 4 indicates MRC imaging model as described in ITU-T + Recommendation T.44 [T.44], and must be set for Primary IFDs + and all MRC-specific child IFDs. + +BitsPerSample(258) = 1, 2-8, 9-16 SHORT +Compression(259) = 3, 4, 7, 9, 10. SHORT +SamplesPerPixel(277) = 1, 3, 4. SHORT + +FillOrder(266) = 1 , 2. SHORT + RequiredByTIFFBaseline + Profile F readers must be able to read data in both bit orders, + but the vast majority of facsimile products store data LSB + first, exactly as it appears on the telephone line. + 1 = Most Significant Bit first. + 2 = Least Significant Bit first + +ResolutionUnit(296) = 2, 3. SHORT +PhotometricInterpretation(262) = 0, 1, 2, 5, 10. SHORT + For Mask layer, see Sections 4.2.1 and 5.2.1. + For Foreground and Background layers, see Sections 6.2.1 and 7.2.1. + +ColorMap(320). SHORT +Count = 3 * (2**BitsPerSample) + Used when Foreground or Background layer is a palette-color image; + see Section 7.2.1. + +XResolution(282) = 100, 200, 300, 400. RATIONAL +YResolution(283) = 100, 200, 300, 400. RATIONAL + The resolution of the image is expressed in pixels per resolution + unit. In pixels per inch, allowed XResolution values for all layers + are: 100, 200, 300, and 400. MRC color fax mode requires the pixels + to be square, hence YResolution must equal XResolution for all + layers. The resolution of Background and Foreground layers must each + be an integer factor of the Primary image, which is the Mask layer, + when it is present; see Section 8.4. + See Section 2.2.2 for inch-metric equivalency. + +8.2.2. Extension Fields + +ChromaSubSampling(530). SHORT +ChromaPositioning(531). SHORT + For Foreground and Background layers, see Section 6.2.2. + + + + +McIntyre, et. al. Standards Track [Page 59] + +RFC 2301 File Format for Internet Fax March 1998 + + +Indexed(346) = 0, 1. SHORT + For Foreground and Background layers: 1 indicates a palette-color + image, see Section 7.2.2. + +T4Options(292) = 0, 1, 4, 5. SHORT +T6Options(293) = 0. SHORT + For Mask layer, see Section 4.2.2. + +SubIFDs(330). IFD + Count = number of child IFDs + Each value is an offset from the beginning of the TIFF file to a + child IFD [TTN1]. + +XPosition(286). RATIONAL +YPosition(287). RATIONAL + Specifies the horizontal and vertical offsets of the top-left of the + IFD from the top-left of the Primary IFD in page resolution units. + For example, if the Primary IFD is at 400 pixels per inch, and a + foreground layer IFD is at 200 pixels per inch and located at pixel + coordinate (345, 678) with respect to the Primary IFD, the XPosition + value is 345/400 and the YPosition value is 678/400. + Color fax does not currently allow overlap of any component images + within a single layer. + Default values for XPosition and YPosition are 0. + +8.2.3. New Fields + +Decode(433). SRATIONAL + For Foreground and Background layers, see Section 6.2.3. + +DefaultImageColor(434). SHORT + Count = SamplesPerPixel + In areas where no image data is available, a default color is needed + to specify the color value. If the StripByteCounts value for a strip + is 0, then the color for that strip must be defined by a default + image color. + + The DefaultImageColor field uses the same encoding as the image + data, and its value is therefore interpreted using the + PhotometricInterpretation, SamplesPerPixel, BitsPerSample, and + Indexed fields. If the fax data stream requires a different + encoding, then transferring the default color value between a TIFF + file and fax data stream requires a color conversion. + For the Foreground layer image, the default value for the + DefaultImageColor field is black. For other cases, including the + Background layer image, the default value is white. + + + + + +McIntyre, et. al. Standards Track [Page 60] + +RFC 2301 File Format for Internet Fax March 1998 + + +StripRowCounts(559). LONG + Count = number of strips + The number of scanlines stored in a strip. MRC allows each fax strip + to store a different number of scanlines. For strips with more than + one layer there is a maximum strip size of 256 scanlines or full + page size. The 256 maximum SHOULD be used unless the capability to + receive longer strips has been negotiated. This field replaces + RowsPerStrip for IFDs with variable-sized strips. Only one of the + two fields, StripRowCounts and RowsPerStrip, may be used in an IFD. + +ImageLayer (34732). SHORT or LONG. + Count = 2 + Image layers are defined such that layer 1 is the Background layer, + layer 3 is the Foreground layer, and layer 2 is the Mask layer, + which selects pixels from the Background and Foreground layers. The + ImageLayer tag contains two values, describing the layer to which + the image belongs and the order in which it is imaged. + + ImageLayer[0] = 1, 2, 3. + 1: Image is a Background image, i.e., the image that will appear + whenever the Mask contains a value of 0. Background images + typically contain low-resolution, continuous-tone imagery. + 2: Image is the Mask layer. In MRC, if the Mask layer is present, it + must be the Primary IFD and be full page in extent (no gaps.) + 3: Image is a Foreground image, i.e., the image that will appear + whenever the Mask contains a value of 1. The Foreground image + generally defines the color of text or lines, but may also + contain high-resolution imagery. + + ImageLayer[1]: + 1: first image to be imaged in this layer, + 2: second image to be imaged in this layer, + 3: ... + + Value describing the image order. In MRC, this may be considered + the strip number. Since MRC mode currently does not allow overlap + between images within a layer, the order value does not have any + visual effect. + + In MRC fax mode, it is possible that only a single layer is + transmitted. For example, if a page contains only a single + continuous-tone photograph, then only the Background layer may be + transmitted. In this case, the Background layer will be stored as the + Primary IFD. ImageLayer[0] will be 1 indicating Background; + ImageLayer[1] will be 1 since there can be no other IFDs associated + with that layer. No Mask layer will exist. + + + + + +McIntyre, et. al. Standards Track [Page 61] + +RFC 2301 File Format for Internet Fax March 1998 + + +8.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + +8.4. Rules and Requirements for Images + + The MRC mode defines a fundamental set of rules for images in the 3- + layer representation. + + 1. If more than one layer exists, then the binary Mask layer SHALL be + present and be the primary image. The Mask layer SHALL support the + encoding defined in Section 3 and MAY support the encodings + defined in Sections 4 and 5. If only one layer exists, then the + image corresponding to that layer is the primary image. + + 2. When the binary Mask layer is the Primary IFD, the Primary IFD + defines and extends to the entire page boundary; all attached + model images cannot extend beyond the Primary image. Resolution + differences may cause some pixels to "hang over" the page + boundary, but no new pixels should exist completely beyond the + page extent. When the Foreground or Background layer is the + Primary IFD, the Primary IFD may not be page width. + + 3. The Background and Foreground images SHALL support the color + encoding defined in Section 6 and MAY support the color encoding + defined in Section 7. These images MAY optionally cover only a + portion of the strip or page. + + 4. Each Primary IFD and each MRC-specific SubIFD must have an + ImageLayer field to specify which layer the IFD belongs to, and + the imaging order of that IFD within the layer. + + 5. Each Primary IFD must have a NewSubFileType field value set to 18, + indicating a single page of a multi-page document (bit 1) and MRC + mode (bit 4). + + 6. Each MRC-specific child IFD must have a NewSubFileType field value + set to 16, indicating MRC mode (bit 4). + + 7. In MRC mode, each layer is transmitted as a sequence of strips. It + is possible that each strip of each layer can be stored as a + separate IFD. In this case, the SubIFDs structure pointed to by + the Primary IFD will contain several IFDs that have an ImageLayer + field with the layer identified as either Background (layer 1) or + Foreground (layer 3). There may be no overlap in the vertical + direction between IFDs associated with a single layer, although + + + + + +McIntyre, et. al. Standards Track [Page 62] + +RFC 2301 File Format for Internet Fax March 1998 + + + there may be a gap from one of these images to the next. The TIFF + XPosition and YPosition fields are used to indicate the placement + of these images with respect to the primary image. + + 8. When the Mask image is present, the resolution of Background and + Foreground images must each be an integer factor of the Mask + image. For example, if the Mask image is 400 pixels/inch, then the + Background or Foreground image may be at 400 pixels/inch (400/1), + 200 pixels/inch (400/2) or 100 pixels/inch (400/4). + +8.5. MRC Fax Mode Summary + + Recommended fields are shown with an asterisk * + + +------------------+-----------------------------------------+ + | Baseline Fields | Values | + |------------------|-----------------------------------------| + | BitsPerSample | 1: binary mask | + | | 8: 8 bits per color sample | + | | 9-16: optional 12 bits/sample | + +------------------+-----------------------------------------+ + | ColorMap | n: LAB color map | + +------------------+-----------------------------------------+ + | Compression | 3: Modified Huffman and Modified Read | + | | 4: Modified Modified Read | + | | 7: JPEG | + | | 9: JBIG, per T.85 | + | | 10: JBIG, per T.43 | + +------------------+-----------------------------------------+ + | DateTime* | {ASCII): date/time in the 24-hour format| + | | "YYYY:MM:DD HH:MM:SS" | + +------------------+-----------------------------------------| + | FillOrder** | 1: Most significant bit first | + | | 2: Least significant bit first | + +------------------+-----------------------------------------| + | ImageDescription*| {ASCII}: A string describing the | + | | contents of the image. | + +------------------+-----------------------------------------+ + | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | + | | 2592, 3072, 3456, 3648, 4096, 4864 | + +------------------+-----------------------------------------+ + | ImageLength** | n: total number of scanlines in image | + +------------------+-----------------------------------------+ + | NewSubFileType | 16, 18: | + | | Bit 1 indicates single page of a multi- | + | | page document on Primary IFD | + | | Bit 4 indicates MRC model | + +------------------+-----------------------------------------+ + + + +McIntyre, et. al. Standards Track [Page 63] + +RFC 2301 File Format for Internet Fax March 1998 + + + +------------------+-----------------------------------------+ + | Orientation | 1**-8, Default 1 | + +------------------+-----------------------------------------+ + | PhotometricInter | 0: WhiteIsZero | + | pretation | 1: BlackIsZero | + | | 2: RGB | + | | 5: CMYK | + | | 10: ITULAB | + +------------------+-----------------------------------------+ + | ResolutionUnit | 2: inch | + | | 3: centimeter | + +------------------+-----------------------------------------+ + | RowsPerStrip | n: number or scanlines per strip | + +------------------+-----------------------------------------+ + | SamplesPerPixel | 1: L* (lightness) | + | | 3: RGB, LAB, CMY | + | | 4: CMYK | + +------------------+-----------------------------------------+ + | Software* | {ASCII}: name & release number of | + | | creator software | + +------------------+-----------------------------------------+ + | StripByteCounts | <n>: number or bytes in each strip | + +------------------+-----------------------------------------+ + | StripOffsets | <n>: offset from beginning of file to | + | | each TIFF strip | + +------------------+-----------------------------------------| + | XResolution | 100, 200, 300, 400 (written in | + | | pixels/inch) | + +------------------+-----------------------------------------| + | YResolution | equal to XResolution (pixels must be | + | | square) | + +------------------+-----------------------------------------+ + | Extension Fields | + +------------------+-----------------------------------------+ + | T4Options | 0: required if Compression is Modified | + | | Huffman, EOLs not byte aligned | + | | 1: required if Compression 2D Modified | + | | Read, EOLs are not byte aligned | + | | 4: required if Compression Modified | + | | Huffman, EOLs byte aligned | + | | 5: required if Compression 2D Modified | + | | Read, EOLs are byte aligned | + +------------------+-----------------------------------------+ + | T6Options | 0: required if Compression is 2D | + | | Modified Modified Read | + +------------------+-----------------------------------------+ + + + + + +McIntyre, et. al. Standards Track [Page 64] + +RFC 2301 File Format for Internet Fax March 1998 + + + +------------------+-----------------------------------------+ + | DocumentName* | {ASCII}: name of scanned document | + +------------------+-----------------------------------------+ + | PageNumber | n,m: page number followed by total page | + | | count | + +------------------+-----------------------------------------+ + | ChromaSubSampling| (1,1), (2, 2)** | + | | (1, 1): equal numbers of lightness and | + | | chroma samples horizontally & vertically| + | | (2, 2): twice as many lightness samples | + | | as chroma horizontally and vertically | + +------------------+-----------------------------------------+ + | ChromaPositioning| 1: centered | + +------------------+-----------------------------------------+ + | Indexed | 0: not a palette-color image | + | | 1: palette-color image | + +------------------+-----------------------------------------+ + | SubIFDs | <IFD>: byte offset to fg/bg IFDs | + +------------------+-----------------------------------------+ + | XPosition | horizontal offset in primary IFD | + | | resolution units | + +------------------+-----------------------------------------+ + | YPosition | vertical offset in primary IFD | + | | resolution units | + +------------------+-----------------------------------------+ + | New Fields | + +------------------+-----------------------------------------+ + | Decode | minL, maxL, mina, maxa, minb, maxb: | + | | minimum and maximum values for L*a*b* | + +------------------+-----------------------------------------+ + | DefaultImageColor| <n>: background color | + +------------------+-----------------------------------------+ + | StripRowCounts | <n>: number of scanlines in each strip | + +------------------+-----------------------------------------+ + | ImageLayer | n, m: layer number, imaging sequence | + | | (e.g., strip number) | + +------------------+-----------------------------------------+ + | GlobalParameters | IFD: global parameters IFD | + | IFD* | | + +------------------+-----------------------------------------+ + | ProfileType* | n: type of data stored in TIFF file | + +------------------+-----------------------------------------+ + | FaxProfile* | n: ITU-compatible fax mode | + +------------------+-----------------------------------------+ + | CodingMethods* | n: compression algorithms used in file | + +------------------+-----------------------------------------+ + | ModeNumber* | n: version of ITU fax standard | + +------------------+-----------------------------------------+ + + + +McIntyre, et. al. Standards Track [Page 65] + +RFC 2301 File Format for Internet Fax March 1998 + + + +------------------------------------------------------------+ + | VersionYear* | byte sequence: year of ITU fax standard | + +------------------+-----------------------------------------+ + +9. MIME content-type image/tiff + + [TIFF-REG] describes the registration of the MIME content-type + image/tiff to refer to TIFF encoded image data. When transported by + MIME, the TIFF content defined by this document must be encoded + within an image/tiff content type. In addition, an optional + "application" parameter is defined for image/tiff to identify a + particular application's subset of TIFF and TIFF extensions for the + encoded image data, if it is known. Typically, this would be used to + assist the recipient in dispatching a suitable rendering package to + handle the display or processing of the image file. + +9.1 Refinement of MIME content-type image/tiff for Facsimile + Applications + + Since this document defines facsimile specific profiles of TIFF, it + is useful to note an appropriate application parameter for the + image/tiff MIME content-type. + + The two values of the image/tiff application parameter as defined for + facsimile are shown below, separated by a comma: + + faxbw, faxcolor + + The "faxbw" application parameter is suitable for use by applications + that can process one or more TIFF for facsimile profiles or subsets + used for the encoding of black and white facsimile data. + + The "faxcolor" application parameter is suitable for use by + applications that can process one or more TIFF for facsimile profiles + or subsets that can be used for the encoding of black and white, AND + color facsimile data. + + Since this document defines several profiles of TIFF for facsimile, + the following rules should be followed when setting the application + parameter value. For TIFF image data which is encoded for the + profiles of TIFF for Facsimile that support black-and-white image + data (Profiles S, F or J), applications which use one of these + profiles or a subset should set the value of the application + parameter to "faxbw". For TIFF image data which is encoded for the + defined profiles of TIFF for Facsimile that support color image data + (Profiles C, L or M), as well as black-and-white image data, + applications which use one of these profiles or a subset should set + the value of the application parameter to "faxcolor". + + + +McIntyre, et. al. Standards Track [Page 66] + +RFC 2301 File Format for Internet Fax March 1998 + + + An example of the use of the image/tiff MIME Content-type with the + application parameter set with the value 'faxbw' follows: + + Content-type: image/tiff; application=faxbw + + In this example, use of this parameter value will enable applications + to identify the content as being within a profile or subset of TIFF + for Facsimile that is suitable for encoding black and white image + data, Before attempting to process the image data. + + In a similar respect, an example of the image/tiff MIME Content-type + with the application parameter setting suitable for handling a color + subset or profile of TIFF for facsimile is shown below: + + Content-type: image/tiff; application=faxcolor + +10. Security Considerations + + This document describes a file format for Internet fax, which is a + series of profiles of TIFF for facsimile. As such, it does not create + any security issues not already identified in [TIFF-REG], in its use + of fields as defined in [TIFF]. There are also new TIFF fields + defined within this specification, but they are of a purely + descriptive nature, so that no new security risks are incurred. + + Further, the encoding specified in this document does not in any way + preclude the use of any Internet security protocol to encrypt, + authenticate, or non-repudiate TIFF-encoded facsimile messages. + +11. References + + [REQ] Bradner, S, "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [T.4] ITU-T Recommendation T.4, Standardization of group 3 facsimile + apparatus for document transmission, October 1997 + + [T.6] ITU-T Recommendation T.6, Facsimile coding schemes and coding + control functions for group 4 facsimile apparatus, November 1988 + + [T.30] ITU-T Recommendation T.30 - Procedures for Document Facsimile + Transmission in the General Switched Telephone Network, June 1996 + + [T.42] ITU-T Recommendation T.42, Continuous-tone colour + representation method for facsimile, February 1996 + + + + + + +McIntyre, et. al. Standards Track [Page 67] + +RFC 2301 File Format for Internet Fax March 1998 + + + [T.43] ITU-T Recommendation T.43, Colour and gray-scale image + representations using lossless coding scheme for facsimile, February + 1997 + + [T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC), October + 1997. + + [T.81] ITU-T Recommendation T.81, Information technology - Digital + compression and coding of continuous-tone still images - Requirements + and guidelines, September 1992 + + [T.82] ITU-T Recommendation T.82, Information technology - Coded + representation of picture and audio information - Progressive bi- + level image compression, March 1995 + + [T.85] ITU-T Recommendation T.85, Application profile for + Recommendation T.82 - Progressive bi-level image compression (JBIG + coding scheme) for facsimile apparatus, August 1995 + + [TIFF] Tag Image File Format, Revision 6.0, Adobe Developers + Association, June 3, 1992, + ftp://ftp.adobe.com/pub/adobe/devrelations/ + devtechnotes/pdffiles/tiff6.pdf + + The TIFF 6.0 specification dated June 3, 1992 specification (c) + 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved. + + [TIFF-FY] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) + - F Profile for Facsimile", RFC 2306, March 1998. + + [TIFF-F0] TIFF Class F specification, Apr 28, 1990, + ftp://ftp.faximum.com/pub/documents/tiff_f.txt + + [TIFF-REG] Parsons, G., Rafferty J. and S. Zilles, "Tag Image File + Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 2302, + March 1998. + + [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995, + http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf + + [TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG + specification, March 17, 1995, + ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt + + [VPIM2] Vaudreui,l G. and G. Parsons, "Voice Profile for Internet + Mail - version 2", work in progress, <draft-ema-vpim-06.txt> + + The ITU-T Recommendations are available at http://www.itu.ch. + + + +McIntyre, et. al. Standards Track [Page 68] + +RFC 2301 File Format for Internet Fax March 1998 + + +12. Authors' Addresses + + Lloyd McIntyre Stephen Zilles + Xerox Corporation Adobe Systems Inc. + Mailstop PAHV-305 Mailstop W14 + 3400 Hillview Ave. 345 Park Avenue + Palo Alto, CA 94304 USA San Jose, CA 95110-2704, USA + Voice: +1-650-813-6762 Voice: +1-408-536-4766 + Fax: +1-650-845-2340 Fax: +1-408-536-4042 + Email: lmcintyre@adoc.xerox.com Email: szilles@adobe.com + + Robert Buckley Dennis Venable + Xerox Corporation Xerox Corporation + Mailstop 0128-30E Mailstop 0128-27E + 800 Phillips Road 800 Phillips Road + Webster, NY 14580, USA Webster, NY 14580, USA + Voice: +1-716-422-1282 Voice: +1-716-422-8009 + Fax: +1-716-422-6117 Fax: +1-716-422-6117 + Email: Rob_Buckley@wb.xerox.com Email: venable@wrc.xerox.com + + Glenn S. Parsons James Rafferty + Northern Telecom Human Communications + P.O. Box 3511, Station C 12 Kevin Drive + Ottawa, ON K1Y 4H7, Canada Danbury, CT 06811-2901, USA + Phone: +1-613-763-7582 Phone: +1-203-746-4367 + Fax: +1-613-763-2697 Fax: +1-203-746-4367 + Email: Glenn.Parsons@Nortel.ca Email: Jrafferty@worldnet.att.net + + + + + + + + + + + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 69] + +RFC 2301 File Format for Internet Fax March 1998 + + +Annex A: Summary of TIFF Fields for Internet Fax + + This annex includes tables which list by mode the TIFF fields used in + the proposed fax file format. The fields are organized into 3 + categories: + + 1) TIFF Baseline Fields + 2) TIFF Extension Fields + 3) New Fields. + + The tables include the allowed values for each fax mode. Entries + other than explicit numbers are described by: + + n - single number + n, m - 2 numbers + a, b, c - 3 numbers + r - rational number + <n> - array of numbers + <b> - byte sequence + {ASCII} - string + IFD - IFD byte offset + <IFD> - array of IFD byte offsets + + A blank entry in the table indicates that the field is not used by + that particular fax mode. + +Table A.1 TIFF Baseline Fields + + +---------------------------------------------------------+ + | Fax Mode/Profile | + +---------------------------------------------------------| + | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | + +----------| B&W | B&W | B&W | Color | Color | Raster | + | TIFF | | | | | | Content| + | Field | S | F | J | C | L | M | + +----------+---------+----------+--------+---------+--------+--------+ + | BitsPer | 1 | 1 | 1 | 8, 12 | 1, 2-8 | 1, 2-8 | + | Sample | | | | | 9-16 | 9-16 | + +----------+---------+----------+--------+---------+--------+--------+ + | ColorMap | | | | | <n> | <n> | + +----------+---------+----------+--------+---------+--------+--------+ + | Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7| + | sion | | | | | | 9,10 | + +----------+---------+----------+--------+---------+--------+--------+ + | DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| + +----------+---------+----------+--------+---------+--------+--------+ + | FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 | + +----------+---------+----------+--------+---------+--------+--------+ + + + +McIntyre, et. al. Standards Track [Page 70] + +RFC 2301 File Format for Internet Fax March 1998 + + + +----------+---------+----------+--------+---------+--------+--------+ + | ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| + | cription | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Image- | n | n | n | n | n | n | + | Length | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, | + | Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, | + | | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 | + +----------+---------+----------+--------+---------+--------+--------+ + | NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 | + | FileType | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 | + | tation | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, 1, | + | metric- | | | | | 10 | 2, 5, | + | Interp- | | | | | | 10 | + | retation | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | + | tionUnit | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | RowsPer- | n | n | n | n | n | n | + | Strip | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4| + | PerPixel | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| + +----------+---------+----------+--------+---------+--------+--------+ + | Strip- | n | <n> | <n> | <n> | <n> | <n> | + | Byte- | | | | | | | + | Counts | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Strip- | n | <n> | <n> | <n> | <n> | <n> | + | Offsets | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 | + | tion | 200 | 400, 408 | | + +----------+---------+----------+--------+---------+--------+--------+ + | YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 | + | tion | 100,200 | 300, 391, 400 | | + +----------+---------+----------+--------+---------+--------+--------+ + + + + + +McIntyre, et. al. Standards Track [Page 71] + +RFC 2301 File Format for Internet Fax March 1998 + + +Table A.2 TIFF Extension Fields + + +---------------------------------------------------------+ + | Fax Mode/Profile | + +---------------------------------------------------------| + | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | + +----------| B&W | B&W | B&W | Color | Color | Raster | + | TIFF | | | | | | Content| + | Field | S | F | J | C | L | M | + +----------+---------+----------+--------+---------+--------+--------+ + | Chroma- | | | | 1 | | 1 | + | Position-| | | | | | | + | ing | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Chroma- | | | | <1, 1> | | <1, 1> | + | SubSampl-| | | | <2, 2> | | <2, 2> | + | ing | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| + | Name | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Indexed | | | | | 0,1 | 0,1 | + +----------+---------+----------+--------+---------+--------+--------+ + | Page- | n, m | n, m | n, m | n, m | n, m | n, m | + | Number | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | SubIFDs | | | | | | <IFD> | + +----------+---------+----------+--------+---------+--------+--------+ + | T4Options| 0, 4 | 0, 1, | | | | 0, 1, | + | | | 4, 5 | | | | 4, 5 | + +----------+---------+----------+--------+---------+--------+--------+ + | T6Options| | 0 | | | | 0 | + +----------+---------+----------+--------+---------+--------+--------+ + | XPosition| | | | | | r | + +----------+---------+----------+--------+---------+--------+--------+ + | YPosition| | | | | | r | + +----------+---------+----------+--------+---------+--------+--------+ + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 72] + +RFC 2301 File Format for Internet Fax March 1998 + + +Table A.3 New Fields + + +---------------------------------------------------------+ + | Fax Mode/Profile | + +---------------------------------------------------------| + | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | + +----------| B&W | B&W | B&W | Color | Color | Raster | + | TIFF | | | | | | Content| + | Field | S | F | J | C | L | M | + +----------+---------+----------+--------+---------+--------+--------+ + | BadFax- | | n | | | | | + | Lines | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | CleanFax-| | 0, 1, 2 | | | | | + | Data | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Coding- | | | n | n | n | n | + | Method | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Consecu- | | n | | | | | + | tiveBad- | | | | | | | + | FaxLines | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Decode | | | | <r> | <r> | <r> | + +----------+---------+----------+--------+---------+--------+--------+ + | Default- | | | | | | <n> | + |ImageColor| | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Fax- | | | n | n | n | n | + | Profile | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Global- | | IFD | IFD | IFD | IFD | IFD | + | Parame- | | | | | | | + | tersIFD | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Image- | | | | | | n, m | + | Layer | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Mode- | | | | | | n | + | Number | | | | | | | + +----------+---------+----------+--------+---------+--------+--------| + | Profile- | | | n | n | n | n | + | Type | | | | | | | + +--------------------------------------------------------------------+ + + + + + + + +McIntyre, et. al. Standards Track [Page 73] + +RFC 2301 File Format for Internet Fax March 1998 + + + +----------+---------+----------+--------+---------+--------+--------+ + | Strip- | | | | | | <n> | + | RowCounts| | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + | Version- | | | | <b> |<b> | | + | Year | | | | | | | + +----------+---------+----------+--------+---------+--------+--------+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 74] + +RFC 2301 File Format for Internet Fax March 1998 + + +Annex B. IANA Registration for image/tiff Application Parameter +Values used for facsimile + + To: IANA@isi.edu + + Subject: Registration of new Application parameter values for + image/tiff + + MIME media type name: image/tiff + + Optional parameters: Application + + New Value(s): faxbw, faxcolor + + Description of Use: + + faxbw - The "faxbw" application parameter is suitable for use by + applications that can process one or more TIFF for facsimile profiles + or subsets used for the encoding of black-and-white facsimile data. + The definition of the use of this value is contained in Section 9 of + this document (TIFFPLUS). + + Faxcolor - The "faxcolor" application parameter is suitable for use + by applications that can process one or more TIFF for facsimile + profiles or subsets that can be used for the encoding of black and + white, AND color facsimile data. The definition of the use of this + value is contained in Section 9 of this document (TIFFPLUS). + + + + + + + + + + + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 75] + +RFC 2301 File Format for Internet Fax March 1998 + + +Security Considerations: + + Security considerations related to use of the TIFF subsets described + by the "faxbw" and "faxcolor" values of the Application parameter are + identified in Section 10 of this document (TIFFPLUS). + +Persons & email addresses to contact for further information: + + Glenn W. Parsons (Glenn.Parsons@Nortel.ca) + James Rafferty (Jrafferty@worldnet.att.net) + Stephen Zilles (szilles@adobe.com) + + Change Controller: Stephen Zilles + +INFORMATION TO THE SUBMITTER: + + The accepted registrations will be listed in the "Assigned Numbers" + series of RFCs. The information in the registration form is freely + distributable. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 76] + +RFC 2301 File Format for Internet Fax March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +McIntyre, et. al. Standards Track [Page 77] + |