diff options
Diffstat (limited to 'doc/rfc/rfc3949.txt')
| -rw-r--r-- | doc/rfc/rfc3949.txt | 4707 |
1 files changed, 4707 insertions, 0 deletions
diff --git a/doc/rfc/rfc3949.txt b/doc/rfc/rfc3949.txt new file mode 100644 index 0000000..1e94f1d --- /dev/null +++ b/doc/rfc/rfc3949.txt @@ -0,0 +1,4707 @@ + + + + + + +Network Working Group R. Buckley +Request for Comments: 3949 D. Venable +Obsoletes: 2301 Xerox Corporation +Category: Standards Track L. McIntyre + Consultant + G. Parsons + Nortel Networks + J. Rafferty + Brooktrout + February 2005 + + + 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 (2005). + +Abstract + + This document is a revised version of RFC 2301. The revisions, + summarized in the list attached as Annex B, are based on discussions + and suggestions for improvements that have been made since RFC 2301 + was issued in March 1998, and on the results of independent + implementations and interoperability testing. + + This RFC 2301 revision describes the Tag Image File Format (TIFF) + representation of image data specified by the International + Telecommunication Union (ITU-T) Recommendations for black-and-white + and color facsimile. This file format specification is commonly + known as TIFF for Fax eXtended (TIFF-FX). It formally defines + minimal, extended, and lossless Joint Bi-level Image experts Group + (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base + JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, + L, M) for color and grayscale fax. These profiles correspond to the + content of the applicable ITU-T Recommendations. + + + + + + + +Buckley, et al. Standards Track [Page 1] + +RFC 3949 File Format for Internet Fax February 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. Approach. . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Overview of this Document . . . . . . . . . . . . . . . . 5 + 2. TIFF and Fax . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. TIFF Overview . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.1. File Structure . . . . . . . . . . . . . . . . . . 8 + 2.1.2. Image Structure. . . . . . . . . . . . . . . . . . 10 + 2.1.3. TIFF File Structure for Fax Applications . . . . . 11 + 2.2. TIFF Fields for All Fax Applications. . . . . . . . . . . 12 + 2.2.1. TIFF Fields required for all fax profiles. . . . . 13 + 2.2.2. Additional TIFF Fields required for all fax + profiles . . . . . . . . . . . . . . . . . . . . . 14 + 2.2.3. TIFF Fields recommended for all fax profiles . . . 17 + 2.2.4. New TIFF Fields recommended for fax profiles . . . 18 + 3. Profile S: Minimal Black-and-White Fax Profile . . . . . . . . 20 + 3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 21 + 3.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 21 + 3.2.2. Extension Fields . . . . . . . . . . . . . . . . . 23 + 3.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 23 + 3.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 23 + 3.4. End of Line (EOL) and Return to Control (RTC) . . . . . . 23 + 3.4.1. RTC Exclusion. . . . . . . . . . . . . . . . . . . 24 + 3.5. File Structure. . . . . . . . . . . . . . . . . . . . . . 24 + 3.6. Profile S: Minimal Black-and-White Profile Summary. . . . 26 + 4. Profile F: Extended Black-and-White Fax Profile. . . . . . . . 27 + 4.1. TIFF-F Overview . . . . . . . . . . . . . . . . . . . . . 28 + 4.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 29 + 4.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 29 + 4.2.2. Extension Fields . . . . . . . . . . . . . . . . . 32 + 4.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 32 + 4.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 32 + 4.3.1. Baseline Fields. . . . . . . . . . . . . . . . . . 32 + 4.3.2. Extension Fields . . . . . . . . . . . . . . . . . 33 + 4.3.3. New Fields . . . . . . . . . . . . . . . . . . . . 33 + 4.4. Technical Implementation Issues . . . . . . . . . . . . . 34 + 4.4.1. Strips . . . . . . . . . . . . . . . . . . . . . . 34 + 4.4.2. Bit Order. . . . . . . . . . . . . . . . . . . . . 34 + 4.4.3. Multi-Page . . . . . . . . . . . . . . . . . . . . 35 + 4.4.4. Compression. . . . . . . . . . . . . . . . . . . . 35 + 4.4.5. Example Use of Page-quality Fields . . . . . . . . 36 + 4.4.6. Practical Guidelines for Writing and Reading + Multi-Page TIFF-F Files. . . . . . . . . . . . . . 36 + 4.4.7. Use of TIFF-F for Streaming Applications . . . . . 38 + + + + +Buckley, et al. Standards Track [Page 2] + +RFC 3949 File Format for Internet Fax February 2005 + + + 4.5. Implementation Warnings . . . . . . . . . . . . . . . . . 38 + 4.5.1. Uncompressed Data. . . . . . . . . . . . . . . . . 38 + 4.5.2. Encoding and Resolution. . . . . . . . . . . . . . 38 + 4.5.3. EOL byte-aligned . . . . . . . . . . . . . . . . . 39 + 4.5.4. EOL. . . . . . . . . . . . . . . . . . . . . . . . 40 + 4.5.5. RTC Exclusion. . . . . . . . . . . . . . . . . . . 40 + 4.5.6. Use of EOFB for T.6 Compressed Images. . . . . . . 40 + 4.6. Example Use of TIFF-F . . . . . . . . . . . . . . . . . . 40 + 4.7. Profile F: Extended Black-and-white Fax Profile Summary . 41 + 5. Profile J: Lossless JBIG Black-and-White Fax Profile . . . . . 43 + 5.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 43 + 5.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 44 + 5.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 44 + 5.2.2. Extension Fields . . . . . . . . . . . . . . . . . 44 + 5.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 44 + 5.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 45 + 5.4. Profile J: Lossless JBIG Black-and-White Profile Summary. 45 + 6. Profile C: Base Color Fax Profile. . . . . . . . . . . . . . . 47 + 6.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 47 + 6.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 47 + 6.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 47 + 6.2.2. Extension Fields . . . . . . . . . . . . . . . . . 49 + 6.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 50 + 6.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 52 + 6.4. Profile C: Base Color Fax Profile Summary . . . . . . . . 52 + 7. Profile L: Lossless Color Profile. . . . . . . . . . . . . . . 54 + 7.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 54 + 7.1.1. Color Encoding . . . . . . . . . . . . . . . . . . 54 + 7.1.2. JBIG Compression . . . . . . . . . . . . . . . . . 55 + 7.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 55 + 7.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 56 + 7.2.2. Extension Fields . . . . . . . . . . . . . . . . . 57 + 7.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 57 + 7.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 57 + 7.4. Profile L: Lossless Color Fax Profile Summary . . . . . . 58 + 8. Profile M: Mixed Raster Content Profile. . . . . . . . . . . . 60 + 8.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 60 + 8.1.1. MRC 3-layer model. . . . . . . . . . . . . . . . . 60 + 8.1.2. A TIFF Representation for the MRC 3-layer model. . 62 + 8.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 64 + 8.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 64 + 8.2.2. Extension Fields . . . . . . . . . . . . . . . . . 66 + 8.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 67 + 8.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 69 + 8.4. Rules and Requirements for Images . . . . . . . . . . . . 69 + 8.5. Profile M: MRC Fax Profile Summary. . . . . . . . . . . . 71 + 9. MIME content-types image/tiff and image/tiff-fx. . . . . . . . 74 + 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 74 + + + +Buckley, et al. Standards Track [Page 3] + +RFC 3949 File Format for Internet Fax February 2005 + + + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 74 + 11.2. Informative References . . . . . . . . . . . . . . . . . 76 + Annex A: Summary of TIFF Fields for Internet Fax . . . . . . . . . 77 + Annex B: List of technical edits to RFC 2301 . . . . . . . . . . . 81 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 84 + +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 profiles: + + S: Minimal black-and-white profile, using binary MH compression + [T.4] + F: Extended black-and-white profile, using binary MH, MR, and MMR + compression [T.4, T.6] + J: Lossless JBIG black-and-white profile, with JBIG compression + [T.85, T.82] + C: Lossy color and grayscale profile, using JPEG compression [T.42, + T.81] + L: Lossless color and grayscale profile, using JBIG compression + [T.43, T.82] + M: Mixed raster content profile [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 + document + + 1. specifies the structure of TIFF files for facsimile data, + 2. defines ITU fax-compatible values for existing TIFF fields, and + 3. defines new TIFF fields and values required for compatibility with + ITU color fax. + + + + + + + +Buckley, et al. Standards Track [Page 4] + +RFC 3949 File Format for Internet Fax February 2005 + + + This specification of TIFF for facsimile is known as TIFF-FX (TIFF + for Fax eXtended). References to the format described by this + specification should always use the term "TIFF-FX", and some profiles + in this specification may not be interpreted correctly by other TIFF + applications. + +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 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 into 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. + + 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 Document + + 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 profiles. The TIFF fields used + + + + +Buckley, et al. Standards Track [Page 5] + +RFC 3949 File Format for Internet Fax February 2005 + + + only by specific fax profiles are described in Sections 3 - 8, which + describe the individual fax profiles. These sections also specify + the ITU-compatible field values (image parameters) for each profile. + + 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 profiles 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 profile + (Profile S), which is required in all implementations. Section 4 + defines the extended black-and-white fax profile (Profile F), which + provides a standard definition of TIFF-F. Section 5 describes the + lossless black-and-white profile using JBIG compression (Profile J). + + Section 6 defines the base color profile, 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 profile (Profile L), and Section 8 + defines the Mixed Raster Content facsimile profile (Profile M). Each + of these sections concludes with a table summarizing the required and + recommended fields for each profile and the values they can have. + + Section 9 refers to the MIME content types used in connection with + TIFF for facsimile. Sections 10 and 11 give Security Considerations + and References, followed by Authors' Addresses and the Copyright + Notice. 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. + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 6] + +RFC 3949 File Format for Internet Fax February 2005 + + + S (MH) + / \ + B&W / \ Color + ------------ ---------- + / \ \ + / F (MH, MR, MMR) C (JPEG) + / / \ + J (JBIG) ---- \ + / \ + L (JBIG) \ + \ + M (MRC) + + A profile is based on a collection of ITU-T facsimile coding methods. + For example, Profile S, the minimal profile, is based on Modified + Huffman (MH) compression, which is defined in ITU-T Rec. T.4. + Profile F specifies Modified Huffman (MH), 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, the + set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical Note + 2 [TTN2] define several TIFF extensions. The TIFF-based + specification for fax applications uses a subset of Baseline TIFF + + + + +Buckley, et al. Standards Track [Page 7] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 + 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 profile, which SHALL use value "II". The next two + bytes contain the value 42, which 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 containing either 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 + + + +Buckley, et al. Standards Track [Page 8] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profiles 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. Although a Baseline TIFF reader is + not 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 profile, described + in Section 8, requires the use of child IFDs. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 9] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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.) + + 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 + + + +Buckley, et al. Standards Track [Page 10] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profile (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 add new compression + schemes gracefully 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, 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 that 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 profile (Profile S) specifies a required + ordering of pages and elements within a page (Section 3.5). The + extended black-and-white profile (Profile F) provides guidelines for + ordering pages and page elements (Section 4.4.6). Other profiles + 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 + + + + +Buckley, et al. Standards Track [Page 11] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profiles. In particular, Section 2.2.1 lists the fields that + are required by all profiles and that have values that do not depend + on the profile. Section 2.2.2 lists the fields that are required by + all profiles and that have values that do depend on the profile. + Section 2.2.3 lists the fields that are recommended for all profiles. + Fields required or recommended by some but not all profiles are given + in the section (Section 3 - 8) that describes that profile. The + sections for each fax profile have subsections for required and + recommended fields; each subsection 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 profiles. + + + + + + + + + + +Buckley, et al. Standards Track [Page 12] + +RFC 3949 File Format for Internet Fax February 2005 + + + This section describes the fields required or recommended by all fax + profiles. The pattern for the description of TIFF fields in this + document is as follows: + + 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 profiles + + The TIFF fields listed in this section SHALL be used by all fax + profiles but have field values that are not specified by the ITU + standards, i.e., the fields do not depend on the profile. The next + subsection lists the fields that SHALL be used by all fax profiles, + but which do have values specified by the ITU-specified or profile- + specific values. Fields that SHALL be used by some but not all + profiles are given in the Sections (3 - 8) that describe the profiles + that use 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 + + + + + + + + + +Buckley, et al. Standards Track [Page 13] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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. + 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 profiles + + The TIFF fields listed in this section SHALL be used by all fax + profiles, but the values associated with them depend on the profile + being described and the associated ITU Recommendations. Therefore, + only the fields are defined here; the values applicable to a + particular fax profile are described in Sections 3 - 8. Fields that + SHALL be used by some but not all profiles are given in the section + (3 - 8) describing the profile 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). + + + + + + +Buckley, et al. Standards Track [Page 14] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 uses 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, except in the case of + Profile S, which only requires support for FillOrder=2 (Least + Significant Bit first). + + ImageWidth(256) + SHORT or LONG + RequiredByTIFFBaseline + The number of pixels (columns) per scanline (row) of the image + No default, must be specified. + + 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) + + + + + + + + +Buckley, et al. Standards Track [Page 15] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profile are given + in the section defining that profile. 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. To + ensure interoperability, if an application accepts any member of + the pairs then T.4 requires it to accept both (e.g., accept 204 if + 200 pixels per inch is accepted). 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 profile + are given in the section defining that profile. 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. To insure interoperability, if an application accepts + any member of the pairs, then T.4 requires it to accept both + (e.g., accept 98 if 100 pixels per inch is accepted). TIFF for + Facsimile Writers SHOULD express YResolution in inch-based units, + for consistency with historical practice and to maximize + + + + +Buckley, et al. Standards Track [Page 16] + +RFC 3949 File Format for Internet Fax February 2005 + + + interoperability. See the table below for information on + converting from the 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 profiles + + The TIFF fields listed in this section MAY be used by all fax + profiles. However, Profile S writers (the minimal fax profile + described in Section 3) SHOULD NOT use these fields. Recommended + fields that are profile-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. No default. + + + + + + +Buckley, et al. Standards Track [Page 17] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 include this field to give a positive indication of + the orientation, even if the value is the default. Writers should + not generate mirror images, because many readers will not properly + reverse the image before display or print. + + Software(305) + ASCII + OptionalInTIFFBaseline + The name and release number of the software package that + created the image. + No default. + +2.2.4. New TIFF fields recommended for fax profiles + + The new TIFF fields listed in this section MAY be used by all fax + profiles. However, Profile S writes (the minimal fax profile + described in Section 3) SHOULD NOT use these fields. 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 or LONG + + 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 + + + +Buckley, et al. Standards Track [Page 18] + +RFC 3949 File Format for Internet Fax February 2005 + + + conflict exists between fields in the GlobalParametersIFD and in + the image IFDs, then the data in the image IFD shall prevail. + + Among the GlobalParametersIFD entries is a new ProfileType field + that 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 + value of 1 in a bit location indicates the corresponding coding + method is used. More than one bit set to 1 means more than one + coding method is used in the file. + 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 + + + + + + + +Buckley, et al. Standards Track [Page 19] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 + profiles. + + 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 + profile. + +3. Profile S: Minimal Black-and-White Fax Profile + + 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 profile + (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 profile uses the minimal set of fields + with a minimal set of values. There are no recommended fields in + this profile. Further, the TIFF file is required to be "little- + endian", which means that the byte order value in the TIFF header is + "II". This profile defines a required ordering for the pages in a + fax document and for the IFDs and image data of a page. It also + requires + + + +Buckley, et al. Standards Track [Page 20] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profile requires the following fields. The fields listed + in Section 2.2.1 and the fields and fax-specific values specified in + this subsection must be supported by all implementations. + +3.2.1. Baseline fields + + BitsPerSample(258) = 1. + SHORT + RequiredByTIFFBaseline + Binary data only. + Default = 1 (field may be omitted if this is the value) + + Compression(259) = 3. + SHORT + RequiredByTIFFBaseline + 3 = 1- or 2- dimensional coding. + The value 3 is a TIFF extension value [TIFF]. The T4Options field + must be specified, and its value specifies that the data is + encoded with the Modified Huffman (MH) compression 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 profile. + + ImageWidth(256) = 1728. + SHORT or LONG + RequiredByTIFFBaseline + This profile 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. + + + + + +Buckley, et al. Standards Track [Page 21] + +RFC 3949 File Format for Internet Fax February 2005 + + + NewSubFileType(254) = (Bit 1=1). + LONG + RequiredByTIFFforFAX + Bit 1 is 1 if the image is a single page of a multi-page document. + Default = 0 (no subfile bits on, so may not be omitted for fax). + + PhotometricInterpretation(262) = 0. + SHORT + RequiredByTIFFBaseline + 0 = pixel value 1 means black. + No default, must be specified. + + ResolutionUnit(296) = 2. + SHORT + RequiredByTIFFBaseline + The unit of measure for resolution. 2 = inch. + Default = 2 (field may be omitted if this is the value). + + SamplesPerPixel(277) = 1. + SHORT + RequiredByTIFFBaseline + The number of components per pixel; 1 for black-and-white. + Default = 1 (field may be omitted if this is the value). + + XResolution(282) = 200, 204. + RATIONAL + RequiredByTIFFBaseline + The horizontal resolution of the image is expressed in pixels per + resolution unit. In pixels/inch, the allowed values are 200 and + 204, which may be treated as equivalent. See Section 2.2.2 for + inch metric equivalency. No default, must be specified. + + YResolution(283) = 98, 100, 196, 200. + RATIONAL + RequiredByTIFFBaseline The vertical resolution of the image is + expressed in pixels per resolution unit. In pixels/inch, the + allowed values are 98, 100, 196, and 200; 98 and 100 may be + treated as equivalent, and 196 and 200 may be treated as + equivalent. See Section 2.2.2 for inch metric equivalency. No + default, must be specified. + + + + + + + + + + + +Buckley, et al. Standards Track [Page 22] + +RFC 3949 File Format for Internet Fax February 2005 + + +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 compression. + 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 compression used (MH + only in this profile). MH coding requires the use of EOL (End of + Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned + or not. 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) + + TIFF extensions for fax, used in this specification, differ from + Baseline TIFF in the following ways: + + - A 12-bit EOL sequence MUST precede each line of MH-compressed + image data. (Baseline TIFF does not use these EOL sequences.) + - The EOL sequence MAY be byte-aligned, in which case fill bits are + added so that the EOL sequence ends on a byte boundary, and any + subsequent image data begins on a byte boundary. + - If the EOL codes are not byte aligned, the image data MAY be + followed by an RTC (Return to Control) sequence, consisting of 6 + consecutive EOLs. + + 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. + + + +Buckley, et al. Standards Track [Page 23] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 scanlines 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 seek + 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 subsection. + +3.4.1. RTC Exclusion + + Implementations that seek 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 that 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 that do not include RTCs and SHOULD be able + to process files that do include RTCs. + +3.5. File Structure + + The TIFF header, described in Section 2.1.1, contains two bytes that + describe the byte order used within the file. For the minimal + black-and-white profile, 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 offset to the first IFD is 8. The header + values are shown in the following table: + + + + +Buckley, et al. Standards Track [Page 24] + +RFC 3949 File Format for Internet Fax February 2005 + + + +--------+-------------------+--------+-----------+ + | 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 profile 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 to which it + has offsets 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 containing 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, and so + on. 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. + + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 25] + +RFC 3949 File Format for Internet Fax February 2005 + + + +-----------------------+ + | 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 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. Profile S: Minimal Black-and-White Profile Summary + + The table below summarizes the TIFF fields that compose 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, certain fields that have a value + that is a sequence of flag bits are shown with integer values + corresponding 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 | + +------------------------------------------------------------+ + + + +Buckley, et al. Standards Track [Page 26] + +RFC 3949 File Format for Internet Fax February 2005 + + + +---------------------------+--------------------------------+ + | 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. Profile F: Extended Black-and-White fax profile + + This section defines the extended black-and-white profile or Profile + F of TIFF for facsimile. It provides a standard definition of what + has historically been known as TIFF Class F and now as TIFF-F. In + doing so, it aligns this profile with current ITU-T Recommendations + for black-and-white fax and with existing industry practice. + Implementations of this profile include implementations of Profile S. + + + + +Buckley, et al. Standards Track [Page 27] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 compression, Modified READ + (MR) and Modified Modified READ (MMR) compression, 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 profile. Section 4.3 + describes the fields that MAY be used in this profile. 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 of TIFF-F use. 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 use 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 profile of + TIFF for facsimile. + + Up until the TIFF 6.0 specification, TIFF supported various "Classes" + that 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 that 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. + + + + + + + + +Buckley, et al. Standards Track [Page 28] + +RFC 3949 File Format for Internet Fax February 2005 + + +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 profile 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 + compression, but data is presented in a form that 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 profile supports the following fixed page widths: 1728, 2592, + 3456 (corresponding to North American Letter and Legal and 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. + + + + +Buckley, et al. Standards Track [Page 29] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 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 measurement. + Default = 2 (field may be omitted if this is the value). + + SamplesPerPixel(277) = 1. + SHORT + RequiredByTIFFBaseline + 1 = monochrome, bi-level 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. + + + + +Buckley, et al. Standards Track [Page 30] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 + 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 sizes [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 | + +---------------------------+ + + + + + + + + + + +Buckley, et al. Standards Track [Page 31] + +RFC 3949 File Format for Internet Fax February 2005 + + +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 compression, = 0 indicates MH compression. + 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 compression is used and + EOLs are not byte aligned) (See Section 3.2.2.) The T4Options + field is required when the Compression field has a value of 3. + This field specifies the compression used (MH or MR) and 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 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 + (MMR) 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 that 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. + + + + + + +Buckley, et al. Standards Track [Page 32] + +RFC 3949 File Format for Internet Fax February 2005 + + +4.3.2. Extension fields + + See Section 2.2.3. + +4.3.3. New fields + + See Section 2.2.4 and optional fields below. + + 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 scanlines. A + "good" scan line is defined as a line that, when decoded, contains + the correct number of pixels. Conversely, a "bad" scanline is + defined as a line that, when decoded, contains an incorrect number of + pixels. + + BadFaxLines(326) + SHORT or LONG + The number of "bad" scanlines 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 whether "bad" lines encountered during reception are + stored in the data, or whether "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 + + + +Buckley, et al. Standards Track [Page 33] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 whether 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 + strips, a TIFF reader need not load the entire image into memory, + 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. + + + + + + + +Buckley, et al. Standards Track [Page 34] + +RFC 3949 File Format for Internet Fax February 2005 + + + Facsimile data appears on the phone line in bit-reversed order + relative to its description in ITU-T Recommendation T.4. Therefore, + most 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 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 + 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 commonly + used 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 + + + +Buckley, et al. Standards Track [Page 35] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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. + + 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, TIFF-F has required readers and writers to be able to + handle multi-page TIFF-F files. The experience of various TIFF-F + implementors has shown that implementing 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 + document page. 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, + + + +Buckley, et al. Standards Track [Page 36] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 offsets for each image strip are defined from within + each IFD. Where possible, another guideline for TIFF-F writers is + 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). + A single image strip per page further simplifies TIFF-F file writing + 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 that require "streaming" techniques (see section 4.4.7). + If 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 related to strips. + + Another simplifying guideline is that each IFD SHOULD be placed in + the TIFF-F file structure at a point preceding the image that the IFD + describes. + + In addition, placing the image data in a physical order within the + TIFF file structure which is consistent with the logical page order + simplifies TIFF-F file writing and reading. In practice, TIFF-F + readers will need to use the strip offsets to find the exact physical + location of the image data, whether or not it is presented in logical + page order. + + 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 from the top of the + page. + + TIFF-F writers MAY follow another 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 + compared to the others given here. + + In the case of the minimal profile, which is also the minimal subset + of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs + (see Section 3.5). + + A TIFF-F file structured using the guidelines of this section will + essentially consist of a linked list of IFDs, presented in ascending + page order, each pointing to a single page of image data + + + + +Buckley, et al. Standards Track [Page 37] + +RFC 3949 File Format for Internet Fax February 2005 + + + (one strip per page), where the pages of image data are also placed + in a logical page order sequence 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. Although TIFF-F may also be + used as a file format for cases such as streaming applications, + assumptions differing from those provided in this section (e.g., the + entire size and number of pages within the image are not known in + advance) may be required. 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. The "Uncompressed" bit in T4Options or T6Options must + be set to 0. + +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 who wish to have the maximum flexibility in reading + TIFF-F files should support all three of these compression methods + (MH, MR, and MMR). + + 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, and 400 x 400 in dots + per inch-based units. At the same time, support was added for metric + dimensions 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 + + + +Buckley, et al. Standards Track [Page 38] + +RFC 3949 File Format for Internet Fax February 2005 + + + writer, as 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 not to support these + higher resolutions. + + Per [T.4], it is permissible for applications to treat the following + XResolution values as equivalent: <204,200> and <400,408>. + Similarly, the following YResolution values may also be treated as + 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. + + The optional support of metric-based resolutions in the TIFF-F reader + (i.e., 77 x 38.5 cm) is included for completeness, as 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 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 so 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 compression 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 compression, 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. + + + + + +Buckley, et al. Standards Track [Page 39] + +RFC 3949 File Format for Internet Fax February 2005 + + +4.5.4. EOL + + As illustrated in FIGURE 1/T.4 in [T.4], MH-encoded facsimile + documents begin with an EOL, which in TIFF-F may be byte-aligned. + The last line of the image is not terminated by an EOL. Similarly, + respect, images encoded with Modified READ two-dimensional + compression 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 seeking 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 intended 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 that include the RTC sequence in MH/MR image + data. Therefore, TIFF-F readers MUST be able to process files that + do not include RTCs and SHOULD be able to process files that do + include RTCs. + +4.5.6. Use of EOFB for T.6 Compressed Images + + TIFF-F pages 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 [VPIM 2]. Voice messaging systems + can often handle fax store-and-forward capabilities in addition to + traditional 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. + + + + + + + + +Buckley, et al. Standards Track [Page 40] + +RFC 3949 File Format for Internet Fax February 2005 + + +4.7. Profile F: Extended Black-and-white Fax Profile 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 | + +------------------------------------------------------------+ + | 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 | + +------------------------------------------------------------+ + + + + + +Buckley, et al. Standards Track [Page 41] + +RFC 3949 File Format for Internet Fax February 2005 + + + +---------------------------+--------------------------------+ + | 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 | + +---------------------------+--------------------------------+ + | 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 | + +---------------------------+--------------------------------+ + + + + +Buckley, et al. Standards Track [Page 42] + +RFC 3949 File Format for Internet Fax February 2005 + + + +---------------------------+--------------------------------+ + | 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 | + +---------------------------+--------------------------------+ + | GlobalParametersIFD* | IFD: global parameters IFD | + +---------------------------+--------------------------------+ + | ProfileType* | n: type of data stored in file | + +---------------------------+--------------------------------+ + | FaxProfile* | n: ITU-compatible fax profile | + +---------------------------+--------------------------------+ + | CodingMethods* | n: compression algorithms used | + | | in file | + +---------------------------+--------------------------------+ + +5. Profile J: Lossless JBIG Black-and-White Fax profile + + This section defines the lossless JBIG black-and-white profile of + TIFF for facsimile, designated Profile J. Implementations of this + profile are required to implement Profile S as well. + + 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 profile with JBIG compression capability. + +5.1. Overview + + This section describes a black-and-white profile 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 profile is essentially the extended black-and-white profile with + JBIG compression used instead of MH, MR, or MMR. + + + + +Buckley, et al. Standards Track [Page 43] + +RFC 3949 File Format for Internet Fax February 2005 + + +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 profile requires the following + fields. + +5.2.1. Baseline fields + + The TIFF fields that SHALL be used in this profile are the same as + those described in Section 4.2.1 for the extended black-and-white + profile, 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 = JBIG coding. This is a TIFF extension value. + Default = 1 (and is not applicable; field must be specified). + Profile J uses ITU-T T.85 profile of T.82; see T82Options field. + + FillOrder(266) = 1, 2. + SHORT + RequiredByTIFFBaseline + 1 = Pixels are arranged within a byte such that pixels with lower + values are stored in the higher-order bits of the byte, i.e., most + significant bit first (MSB). + 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). + Profile J readers must be able to read data in both bit orders. + +5.2.2. Extension fields + + Same fields as those in Section 2.2.1. + +5.2.3. New fields + + T82Options(435) = 0 + LONG + Required when Compression = 9 + Individual bits are set to indicate the applicable profile of JBIG + coding; all bits set to 0 indicates ITU-T T.85 profile of T.82; + Other values are for further study. + Default is all bits 0, and field may be omitted if this is the + value. (Field may be omitted in Profile J files.) + + + + + +Buckley, et al. Standards Track [Page 44] + +RFC 3949 File Format for Internet Fax February 2005 + + + Note: A T.82 decoder can decode a T.85-encoded image when it handles + the NEWLE marker code as described Corrigendum 1 in [T.85]. + +5.3. Recommended TIFF Fields + + See Sections 2.2.3 and 2.2.4. + +5.4. Profile J: Lossless JBIG Black-and-white Fax Profile 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 | ++---------------------------+--------------------------------+ +| PhotometricInterpretation | 0: pixel value 1 means black | +| ** | 1: pixel value 1 means white | ++---------------------------+--------------------------------+ + + + + +Buckley, et al. Standards Track [Page 45] + +RFC 3949 File Format for Internet Fax February 2005 + + ++---------------------------+--------------------------------+ +| 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 | ++---------------------------+--------------------------------+ +| T82Options** | 0: T.85 profile of T.82 | ++---------------------------+--------------------------------+ +| ProfileType* | n: type of data stored in file | ++---------------------------+--------------------------------+ +| FaxProfile* | n: ITU-compatible fax profile | ++---------------------------+--------------------------------+ +| CodingMethods* | n: compression algorithms used | +| | in file | ++---------------------------+--------------------------------+ + + + + + +Buckley, et al. Standards Track [Page 46] + +RFC 3949 File Format for Internet Fax February 2005 + + +6. Profile C: Base Color Fax profile + +6.1. Overview + + This section defines the lossy color profile of TIFF for facsimile, + designated Profile C. Implementations of this profile are required + to also implement Profile S as well. + + This is the base profile for color and grayscale facsimile, which + means that all applications that support color fax must support this + profile. 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 profile 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 profile 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. + SHORT + Count = SamplesPerPixel + The base color fax profile requires 8 bits per sample. + + + + + +Buckley, et al. Standards Track [Page 47] + +RFC 3949 File Format for Internet Fax February 2005 + + + Compression(259) = 7. + SHORT + Base color fax profile uses Baseline JPEG compression. Value 7 + represents JPEG compression as specified in [TTN2]. + + 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 profile requires pixel values to be stored with 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 Section + 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. + SHORT + The unit of measure for resolution. 2 = inch. + ITU-T standards only specify inch-based resolutions for color fax. + Default = 2 (field may be omitted if this is the value). + + SamplesPerPixel(277) = 1, 3. + SHORT + 1: L* component only, required in base color profile + 3: L*, a*, b* components + Encoded according to PhotometricInterpretation field + + + + + + + + +Buckley, et al. Standards Track [Page 48] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 profile 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 profile. + + NOTE: The functional equivalence of inch-based and metric-based + resolutions is maintained, per Annex E.6.5 in [T.4]. See table in + Section 2.2.2. + + 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]. + + +--------------------------------+---------------------------+ + | 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. + + + + + + + +Buckley, et al. Standards Track [Page 49] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 + the lightness component. + 1: centered, 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 profile, + 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 + + + +Buckley, et al. Standards Track [Page 50] + +RFC 3949 File Format for Internet Fax February 2005 + + + maximum values for L*, a*, and b*; and n is the BitsPerSample. + When n=8,=20 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 the corresponding default minimum and maximum + default values for the Decode field, calculated using the equations + above when PhotometricInterpetation=10. + + Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset, + and hence the minimum and maximum values, for other BitsPerSample + values. + + +-----------------------------------------------+ + | 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 | ++---------+-----------+--------+---------+--------------+-------------+ + + For example, when PhotometricInterpretation=10 and BitsPerSample=8, + the default value for Decode is (0, 100, -21760/255, 21590/255, + -19200/255, 31800/255). For guidelines on the use of the Decode + field, see section 5.2.2 of [GUIDE]. + + + + + + + + + + + +Buckley, et al. Standards Track [Page 51] + +RFC 3949 File Format for Internet Fax February 2005 + + +6.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + +6.4. Profile C: Base Color Fax Profile 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 asterisk is 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 | + +---------------------------+--------------------------------+ + | Compression** | 7: JPEG | + +---------------------------+--------------------------------+ + | 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 | 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 | + +---------------------------+--------------------------------+ + + + + + + + + + +Buckley, et al. Standards Track [Page 52] + +RFC 3949 File Format for Internet Fax February 2005 + + + +------------------------------------------------------------+ + | PhotometricInterpretation | 10**: ITULAB | + +---------------------------+--------------------------------+ + | ResolutionUnit** | 2: inch | + +---------------------------+--------------------------------+ + | 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) | + +---------------------------+--------------------------------+ + | 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 | + +------------------------------------------------------------+ + + + + + + + +Buckley, et al. Standards Track [Page 53] + +RFC 3949 File Format for Internet Fax February 2005 + + + +---------------------------+--------------------------------+ + | 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 profile | + +---------------------------+--------------------------------+ + | CodingMethods* | n: compression algorithms | + | | used in file | + +---------------------------+--------------------------------+ + | VersionYear* | byte sequence: year of ITU std | + +---------------------------+--------------------------------+ + +7. Profile L: Lossless Color Profile + + This section defines the lossless color profile of TIFF for + facsimile, designated Profile L. Implementations of this profile are + required to also implement Profiles S and C as well. + +7.1. Overview + + This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to + code three types of color and grayscale images losslessly: 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, ITU-T Rec. T.43 was called T.Palette, as one + of its major additions was palettized 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] and Annex G in [T.4]. + Profile L files use the color table in the T.43 data stream rather + than the TIFF ColorMap field. + + + + + +Buckley, et al. Standards Track [Page 54] + +RFC 3949 File Format for Internet Fax February 2005 + + + Enabling T.43 color maps in TIFF requires the extension field + Indexed, as defined in [TTN1], and the PhotometricInterpretation + field value 10, as 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| Per Pixel| 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 |2-8, 9-12 | 0 | + +------------+-------------+----------+----------+---------+ + | Color | 10=ITULAB | 3 |2-8, 9-12 | 0 | + +------------+-------------+----------+----------+---------+ + +7.1.2. JBIG Compression + + T.43 uses the single-progression sequential mode of JBIG, defined in + ITU-T Rec. T.82. (Other compression methods are for further study.) + 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 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. + + + + + + + + + + + +Buckley, et al. Standards Track [Page 55] + +RFC 3949 File Format for Internet Fax February 2005 + + +7.2.1. Baseline Fields + + ImageWidth(256). + SHORT or LONG + Same page widths as the base color profile; 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 - 12. + 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. + Note: More than 8 bits per sample is not baseline TIFF. + + Compression(259) = 10. + SHORT + 10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG) + coding + + FillOrder(266) = 1 , 2. + SHORT + RequiredByTIFFBaseline + Profile L 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 color palette table embedded in the image data + stream. To use palette-color images, set the + PhotometricInterpretation to 10, SamplesPerPixel to 1, Indexed to + 1, and use the color map in the data stream. See Section 7.1.1 + for discussion of the color encoding. + + + + + +Buckley, et al. Standards Track [Page 56] + +RFC 3949 File Format for Internet Fax February 2005 + + + ResolutionUnit(296) = 2. + SHORT + The unit of measure for resolution. 2 = inch. + ITU-T standards only specify inch-based resolutions for color fax. + 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 profile requires the + pixels to be square, hence YResolution must equal XResolution. + Base resolution is 200 pixels per inch. + +7.2.2. Extension Fields + + Indexed(346) = 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 image data stream. + Because the color map is embedded in the image data stream, the + ColorMap field is not used in Profile L. Lossless color fax + profile supports palette-color images with the ITULAB encoding. + The SamplesPerPixel value must be 1. + +7.2.3. New Fields + + Decode(433) + SRATIONAL + Decode is used in connection with the ITULAB encoding of image + data; see Section 6.2.3. + +7.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + + + + +Buckley, et al. Standards Track [Page 57] + +RFC 3949 File Format for Internet Fax February 2005 + + +7.4. Profile L: Lossless Color Fax Profile 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: Binary RGB, CMY(K) | + | | 8**: 8 bits per color sample | + | | 9 - 12: optional | + +--------------------+--------------------------------------+ + | 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 | + +--------------------+--------------------------------------+ + + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 58] + +RFC 3949 File Format for Internet Fax February 2005 + + + +--------------------+--------------------------------------+ + | Orientation | 1**-8, Default 1 | + +--------------------+--------------------------------------+ + | PhotometricInter- | 2: RGB | + | pretation | 5: CMYK | + | | 10**: ITULAB | + +--------------------+--------------------------------------+ + | ResolutionUnit** | 2: inch | + +--------------------+--------------------------------------+ + | 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 (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* | | + +-----------------------------------------------------------+ + + + + + +Buckley, et al. Standards Track [Page 59] + +RFC 3949 File Format for Internet Fax February 2005 + + + +--------------------+--------------------------------------+ + | ProfileType* | n: type of data stored in TIFF file | + +--------------------+--------------------------------------+ + | FaxProfile* | n: ITU-compatible fax profile | + +--------------------+--------------------------------------+ + | CodingMethods* | n: compression algorithms used in | + | | file | + +--------------------+--------------------------------------+ + | VersionYear* | byte sequence: year of ITU fax std | + +--------------------+--------------------------------------+ + +8. Profile M: Mixed Raster Content Profile + + This section defines the Mixed Raster Content profile of TIFF for + facsimile, designated Profile M. 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 profiles, which use a single coding method and + resolution for an entire fax page, Mixed Raster Content [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, although spatial resolution of 400 pixels per inch may be + best for the black-and-white text, 200 pixels 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 with the TIFF format to yield a data structure that + differs from [T.44], though it applies the same coding methods, uses + the same compressed image data streams, 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 layers. The final image is obtained by using the Mask layer to + determine whether output pixels come from the Foreground layer or the + Background layer. When the Mask layer pixel value is 1, the + + + +Buckley, et al. Standards Track [Page 60] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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]. + + In our earlier example, the shape of the black-and-white text and the + mask for the color chart could be in the Mask layer, the color of the + chart and text in the Foreground layer, and the color image in the + Background layer. If a Mask layer pixel has a value of 1, the final + image pixel will be, depending on the pixel location, from either the + color chart or text color in the Foreground layer. If a Mask layer + pixel has a value of 0, the final image pixel will be from the color + image in the Background layer. + + 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. + + Not all pages, and not all parts of a page, require 3 layers. If a + page has of only one layer, then that layer is the primary image + whether it is a Background, Mask, or Foreground layer. If there is + more than one layer, then the Mask must be one of the layers, in + which case it is the primary image. In all cases, the primary image + must be page size. + + MRC [T.44] allows a page to be transmitted as a series of stripes, + each consisting of 1, 2 or 3 layers. The number of scanlines in each + stripe can vary over the page. Although [T.44] does not allow + overlap between images of a single layer, the MRC profile permits + overlapping IFDs when one of the IFDs is used only to define a + default image color. According to [T.4] Annex H, stripes having more + than 1 layer SHOULD NOT be more than 256 lines in length unless the + capability to receive longer stripes 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 allowable + 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 + allowable values are 100 and 300. The Foreground and Background + layer resolutions can be set independently of each other. + + + + + + + +Buckley, et al. Standards Track [Page 61] + +RFC 3949 File Format for Internet Fax February 2005 + + +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. The nextIFD + offset associated with a Primary IFD will point to the Primary IFD of + the next page. If the page consists of a single layer, then the + Primary IFD represents that layer. If more than one layer is + present, the Primary IFD represents the Mask layer and the other + layers are represented by a set of child IFDs that are referenced + through the SubIFD extension field [TTN1] of the Primary IFD. To + distinguish MRC-specific 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. + + In Profile M, the Primary IFD represents a complete layer and + corresponds to the primary image described in Section 8.1.1. There + must be no other MRC-related IFDs or SubIFDs that contain image data + corresponding to the layer represented by the Primary IFD. + + MRC [T.44] allows a page to be transmitted as a series of stripes. A + strip within an IFD in a Profile M file represents a stripe in a + [T.44] data stream. The [T.44] stripes of the Primary image are + represented by a single, multiple-strip IFD; the [T.44] stripes of + other layers are represented as multiple, single-strip IFDs. + + The layer represented by the Primary IFD may consist of strips of + image data, but all the strips must be part of the single Primary + IFD. For example, if the page consisted of only the Background + layer, then all strips associated with the Background layer must be + treated as a single image. Because MRC allows stripes with variable + numbers of scanlines, a reader MUST support StripRowCounts field, as + a writer may use it in place of the RowsPerStrip field to support a + variable number of scanlines in each strip of the Primary IFD. In + accordance with [TTN2], each strip shall be independently encoded, + but coding parameters may not change between strips. + + Layers other than the layer represented by the Primary IFD store each + strip as a separate IFD, allowing the coding parameters to change + from strip to strip as described by the MRC standard [T.44]. In all + cases, if the Mask layer exists, it shall 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]. When + the Mask is the primary image, the Background and Foreground layer + images are represented with child IFDs referenced by the SubIFDs + + + +Buckley, et al. Standards Track [Page 62] + +RFC 3949 File Format for Internet Fax February 2005 + + + field in the Primary IFD. There are multiple ways to organize the + images of the Background and Foreground layer images: (1) the SubIFD + field of the Primary IFD is an array of pointers to all child image + IFDs, one entry per child image; (2) the SubIFD field is a single + pointer to a linked list of all child image IFDs; (3) the SubIFD + field is an array of two pointers, where the first pointer is to a + linked list of all Background layer image IFDs, and the second + pointer is to a linked list of all Foreground layer image IFDs. A + Profile M writer SHOULD structure the Background and Foreground layer + images by using (3), as shown in the example below. Furthermore, the + child IFDs representing the images of the Background and Foreground + layers SHOULD be ordered in the file in the same order as they occur + on the page. However, a Profile M reader must scan all available + child IFDs to locate and identify IFDs associated with MRC layers. + + (nextIFD) +PRIMARY IFD PAGE 0 -----------------------> PRIMARY IFD PAGE 1--> ... + ImageLayer = [2,1] + NewSubFileType = 18 + SubIFD[0] ---------------------- SubIFD[1] + | | + V V + Child IFD Child IFD + ImageLayer = [1,1] ImageLayer [3,1] + NewSubFileType = 16 NewSubFileType 16 + | | + |(nextIFD) |(nextIFD) + V V + Child IFD Child IFD + ImageLayer = [1,2] ImageLayer [3,2] + NewSubFileType = 16 NewSubFileType 16 + | | + |(nextIFD) |(nextIFD) + V V + Child IFD Child IFD + ImageLayer = [1,3] ImageLayer [3,3] + NewSubFileType = 16 NewSubFileType 16 + | | + |(nextIFD) |(nextIFD) + V V + 0 0 + + The XPosition and YPosition TIFF fields specify the offset to the + upper left corner of the IFD in resolution units, which are inches in + Profile M; see Section 8.2.2. The Primary IFD must not use XPosition + or YPosition fields. + + + + + +Buckley, et al. Standards Track [Page 63] + +RFC 3949 File Format for Internet Fax February 2005 + + + MRC [T.44] allows the specification of a default image color that is + to be applied in the event no image data is transmitted for a given + stripe and layer. The new field ImageBaseColor is used to store + default image color specifications in Profile M, see 8.2.3. By + setting the StripByteCounts array to zero values, an IFD defining a + default color but containing no encoded image data can be specified. + ImageBaseColor can also be used in IFDs that contain encoded image + data. In that case, the fields of the IFD must accurately reflect + the encoding of the image data. If the StripByteCount entry for a + given strip is 0, then the ImageBaseColor is used for that strip. If + the encoded image data is ITU L*a*b, the ImageBaseColor is + interpreted with the encoding parameters of the image data. If the + image data is not ITU L*a*b*, the ImageBaseColor is interpreted as + 8-bit ITU L*a*b*; see Section 8.2.3. + +8.2. Required TIFF Fields + + This section describes the TIFF fields required, in addition to those + in Section 2.2.1, to represent MRC fax images. Since MRC 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 profiles apply to Profile M. Therefore, the + descriptions here will typically reference the appropriate earlier + sections. Fields and values specific to Profile M are pointed out. + +8.2.1. Baseline Fields + + ImageWidth(256). + SHORT or LONG + Same page widths as Profile C, the base color profile; see Section + 6.2.1. In Profile M, the width of a Foreground or Background + image in the coded data stream may be less than the page width, + unless the Background or Foreground is the primary image, in which + case the width of the coded data stream is the page width. The + ImageWidth field will always store the actual width of the coded + data. + + NewSubFileType(254) = 16, 18. + LONG + For Profile M, 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 the 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. + + + + + + + +Buckley, et al. Standards Track [Page 64] + +RFC 3949 File Format for Internet Fax February 2005 + + + BitsPerSample(258) = 1, 2-8, 9-12 + SHORT + SamplesPerPixel(277) = 1, 3, 4. + SHORT + Compression(259) = 1, 3, 4, 7, 9, 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 Compression=1 is + not used by previous profiles. An IFD used only to specify the + default image color for a layer and strip will not have any + encoded image data associated with it, i.e., the StripByteCounts + field will contain a 0. Since no image data exists in the IFD, + the Compression field shall be set to 1, indicating no + compression. A Compression field value of 1 is not allowed for + any other IFDs. + + FillOrder(266) = 1 , 2. + SHORT + RequiredByTIFFBaseline + Profile M 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) = 0, 2, 10. + SHORT + For Mask layer, 0. For Foreground and Background layers, see + Sections 6.2.1 and 7.2.1. + + ResolutionUnit(296) = 2. + SHORT + The unit of measure for resolution. 2 = inch. + ITU-T standards only specify inch-based resolutions for color fax + Default = 2 (field may be omitted if this is the value). + + StripByteCounts(279) + SHORT or LONG + In Profile M, it is permissible for the StripByteCounts value for + a given strip to have a zero entry. This means there is no + encoded image data corresponding to that strip. Instead, the + current default image color should be used for the strip. The + standard default image colors are black for the Foreground layer + and White for the Background layer. The ImageBaseColor field can + be used to specify other default colors; see Section 8.2.3. + + + + + + +Buckley, et al. Standards Track [Page 65] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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. Color fax 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. + +8.2.2. Extension Fields + + ChromaSubSampling(530). + SHORT + ChromaPositioning(531). + SHORT + For Foreground and Background layers, see Section 6.2.2. + + 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 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 in + inches. + + + + +Buckley, et al. Standards Track [Page 66] + +RFC 3949 File Format for Internet Fax February 2005 + + + The Primary IFD does not use the XPosition or YPosition fields. + The XPosition and YPosition values must be specified for MRC child + IFDs; there is no default value. + +8.2.3. New Fields + + Decode(433). + SRATIONAL + For Foreground and Background layers, see Section 6.2.3. + + T82Options(435) + LONG + For Mask layer, see Section 5.2.3. + + ImageBaseColor(434). + SHORT + Count = SamplesPerPixel + + In areas of an image layer where no image data is available (i.e., + where no strips are defined, or where the StripByteCounts entry for + a given strip is 0), the color specified by ImageBaseColor will be + used. + + If the ImageBaseColor field is used in an IFD that contains image + data encoded in ITU L*a*b*, then the ImageBaseColor will be + interpreted with the color-encoding parameters of the image data + (i.e., color gamut, illuminant, bit/sample, and decode). If the + ImageBaseColor field is used in an IFD that contains image data that + is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be + interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the + ImageBaseColor field is used in an IFD that contains no encoded + image data, then the ImageBaseColor SHALL be interpreted as 8 + bits/sample, 3 samples/pixel ITU L*a*b*. 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. + + A [T.44] stripe may contain a Foreground or Background image less + than full stripe size, with the rest of the stripe assuming a + default image color. In this case, the default image color is imaged + first, followed by the image data. In Profile M, this is represented + as a child IFD containing no encoded image data but specifying the + default image color in the ImageBaseColor field. A second child IFD + contains the image data. To ensure the default image color is imaged + first, the order value in the ImageLayer field of the IFD defining + the ImageBaseColor field MUST have a lower value than the order + value in the ImageLayer field of the IFD defining the image data. + + + + +Buckley, et al. Standards Track [Page 67] + +RFC 3949 File Format for Internet Fax February 2005 + + + To define a child IFD specifying a ImageBaseColor but containing no + encoded image data, create an IFD with the following settings. + + ImageLayer[0]: specified layer + ImageLayer[1]: less than any other IFDs corresponding + to the same layer and strip. + RowsPerStrip: strip height + ImageLength: strip height + ImageWidth: full image width + BitsPerSample: 8 + PhotometricInterpretation: 10 (ITULAB) + SamplesPerPixel: 3 + Compression: 1 (none) + X/YResolution: that of the Primary IFD + XPosition: 0 + YPosition: the offset from the top of the page to + the beginning of the strip in the + resolution units of inches + StripByteCounts: single 0 value + StripOffsets: single 0 entry + NewSubFileType: bit 4 O (MRC) + ImageBaseColor: desired color in 8 bit ITULAB + + For the Foreground layer image, the default value for the + ImageBaseColor field is black. For other cases, including the + Background layer image, the default value is white. + + StripRowCounts(559). + LONG + Count = number of strips. + The number of scanlines stored in a strip. Profile M allows each + fax strip to store a different number of scanlines. For strips + with more than one layer, the maximum strip size is either 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-size strips. Only one of the two fields, StripRowCounts + and RowsPerStrip, may be used in an IFD. + + ImageLayer (34732). + 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, which describe + the layer to which the image belongs and the order in which it is + imaged. + + + +Buckley, et al. Standards Track [Page 68] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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. + 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: ... + + In Profile M, more than one image can exist in a single layer. + ImageLayer[1] specifies the order in which images within a single + layer are to be imaged. This insures that overlapping images + within a single layer are imaged correctly. + + If an IFD contains no encoded image data and is used only to + specify the ImageBaseColor field, the value of ImageLayer[1] must + be less than that of any other IFD corresponding to the same layer + and strip to ensure the image data is interpreted as on top of the + default color. + + In Profile M, it is possible to have only a single layer. For + example, if a page contains only a single continuous-tone + photograph, then only the Background layer would occur. 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, as there can be no other IFDs associated with that layer. + No Mask layer will exist. + +8.3. Recommended TIFF Fields + + See Sections 2.2.3. and 2.2.4. + +8.4. Rules and Requirements for Images + + Profile M defines a fundamental set of rules for images in the 3 + layer representation. + + + + + + + + +Buckley, et al. Standards Track [Page 69] + +RFC 3949 File Format for Internet Fax February 2005 + + + 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 binary data representations defined in Section 3 and MAY + support those defined in Sections 4 and 5, with the exception that + PhotometricInterpretation MUST be 0. If only one layer exists, + then the image corresponding to that layer is the primary image. + + 2. 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. + + 3. The Background and Foreground images SHALL support the color + representations defined in Section 6 and MAY support those 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 + (bit 4). + + 6. Each MRC-specific child IFD must have a NewSubFileType field value + set to 16, indicating MRC (bit 4). + + 7. In MRC fax, each layer is transmitted as a sequence of strips. If + the page consists of a single layer, then all strips shall be + stored in the single Primary IFD. In this case, coding parameters + cannot change between strips. If the page consists of more than + one layer, then all strips of the Mask layer shall be stored in + the single Primary IFD. All strips of the Foreground/Background + layers SHALL be stored in separate IFDs, referenced by the Primary + IFD's SubIFD field, containing an ImageLayer field with + ImageLayer[0] identifying either Background (layer 1) or + Foreground (layer 3), and Imagelayer[1] identifying order in which + images within a single layer are to be imaged. 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). + + + +Buckley, et al. Standards Track [Page 70] + +RFC 3949 File Format for Internet Fax February 2005 + + +8.5. Profile M: MRC Fax Profile 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 asterisk is in the + Values column, then only the values suffixed with a double asterisk + are required of implementations. + + +------------------+-----------------------------------------+ + | Baseline Fields | Values | + +------------------+-----------------------------------------+ + | BitsPerSample | 1**: binary mask, RGB, CMY(K) | + | | 2 - 8**: bits per color sample | + | | 9 - 12: optional 12 bits/sample | + +------------------+-----------------------------------------+ + | Compression | 1: None (ImageBaseColor IFD only) | + | | 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 | + | | Note: legal widths for the Primary IFD. | + +------------------+-----------------------------------------+ + | 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 | + +------------------+-----------------------------------------+ + + + + + + + +Buckley, et al. Standards Track [Page 71] + +RFC 3949 File Format for Internet Fax February 2005 + + + +------------------+-----------------------------------------+ + | Orientation | 1**-8, Default 1 | + +------------------+-----------------------------------------+ + | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | + | pretation | 2: RGB | + | | 10**: ITULAB | + +------------------+-----------------------------------------+ + | ResolutionUnit** | 2: inch | + +------------------+-----------------------------------------+ + | 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 | + +------------------+-----------------------------------------+ + | DocumentName* | {ASCII}: name of scanned document | + +------------------+-----------------------------------------+ + | PageNumber** | n,m: page number followed by total page | + | | count | + +------------------+-----------------------------------------+ + + + +Buckley, et al. Standards Track [Page 72] + +RFC 3949 File Format for Internet Fax February 2005 + + + +------------------+-----------------------------------------+ + | 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* | + +------------------+-----------------------------------------+ + | ImageBaseColor | a,b,c: background color in ITULAB | + +------------------+-----------------------------------------+ + | StripRowCounts | <n>: number of scanlines in each strip | + +------------------+-----------------------------------------+ + | ImageLayer | n, m: layer number, imaging sequence | + | | (e.g., strip number) | + +------------------+-----------------------------------------+ + | T82Options | 0: T.85 profile of T.82 coding | + +------------------+-----------------------------------------+ + | GlobalParameters | IFD: global parameters IFD | + | IFD* | | + +------------------+-----------------------------------------+ + | ProfileType* | n: type of data stored in TIFF file | + +------------------+-----------------------------------------+ + | FaxProfile* | n: ITU-compatible fax profile | + +------------------+-----------------------------------------+ + | CodingMethods* | n: compression algorithms used in file | + +------------------+-----------------------------------------+ + | ModeNumber* | n: version of T.44 standard | + +------------------+-----------------------------------------+ + | VersionYear* | byte sequence: year of ITU fax standard | + +------------------+-----------------------------------------+ + + + + +Buckley, et al. Standards Track [Page 73] + +RFC 3949 File Format for Internet Fax February 2005 + + +9. MIME content-types image/tiff and image/tiff-fx + + The MIME content-types image/tiff and image/tiff-fx are used for + TIFF-FX encoded image data, as defined in this document. [TIFF-REG] + and [TIFF-FX-REG] describe the registration of these MIME content- + types. + +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 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 + +11.1. Normative References + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, 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 + + [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), + April 1999. + + + +Buckley, et al. Standards Track [Page 74] + +RFC 3949 File Format for Internet Fax February 2005 + + + [T.81] ITU-T Recommendation T.81, Information technology - + Digital compression and coding of continuous-tone still + images - Requirements and guidelines, September 1992 + + [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 + + [T.82] ITU-T Recommendation T.82, Information technology - + Coded representation of picture and audio information - + Progressive bi-level image compression, March 1995 + + [TIFF] Tag Image File Format, Revision 6.0, Adobe Developers + Association, June 3, 1992, + http://partners.adobe.com/public/developers/en/tiff/ + TIFF6.pdf + + The TIFF 6.0 specification dated June 3, 1992 + specification (c) 1986-1988, 1992 Adobe Systems + Incorporated. All Rights Reserved. + + [TIFF-F0] TIFF Class F specification, Apr 28, 1990, + ftp://ftp.faximum.com/pub/documents/tiff_f.txt + + [TIFF-REG] Parsons, G. and J. Rafferty, "Tag Image File Format + (TIFF) - image/tiff MIME Sub-type Registration", RFC + 3302, September 2002. + + [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, + 1995, + http://partners.adobe.com/public/developers/en/tiff/ + TIFFPM6.pdf + + [TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG + specification, March 17, 1995, + ftp://ftp.uu.net/graphics/jpeg/ + + [TIFF-FX-REG] McIntyre, L., Parsons, G., and J. Rafferty, "Tag Image + File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME + Sub-type Registration", RFC 3250, September 2002. + + + + + + + + + + +Buckley, et al. Standards Track [Page 75] + +RFC 3949 File Format for Internet Fax February 2005 + + +11.2. Informative References + + [GUIDE] Cancio, V., Moldovan, M., Tamura, H., and D. Wing, + "Implementers Guide for Facsimile Using Internet Mail", + RFC 3249, September 2002. + + [TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format + (TIFF) - F Profile for Facsimile", RFC 2306, March + 1998. + + [VPIM 2] Vaudreuil G. and G. Parsons, "Voice Profile for + Internet Mail - version 2 (VPIMv2)", RFC 3801, June + 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 76] + +RFC 3949 File Format for Internet Fax February 2005 + + +Annex A: Summary of TIFF Fields for Internet Fax + + This annex includes tables which list by profile 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 profile. 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 profile. + + Table A.1 TIFF Baseline Fields + + +---------------------------------------------------------+ + | Fax 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 | 1, 2-8 | 1, 2-8 | +| Sample | | | | | 9-12 | 9-12 | ++----------+---------+----------+--------+---------+--------+--------+ +| 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 | ++----------+---------+----------+--------+---------+--------+--------+ + + + + + +Buckley, et al. Standards Track [Page 77] + +RFC 3949 File Format for Internet Fax February 2005 + + ++----------+---------+----------+--------+---------+--------+--------+ +| 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 | +| | | Note, for the Mixed Raster Content M profile | +| | | these widths apply to the Primary IFD. | ++----------+---------+----------+--------+---------+--------+--------+ +| 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, | +| metric- | | | | | 10 | 2, | +| 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 | | ++----------+---------+----------+--------+---------+--------+--------+ + + + +Buckley, et al. Standards Track [Page 78] + +RFC 3949 File Format for Internet Fax February 2005 + + + Table A.2 TIFF Extension Fields + + +---------------------------------------------------------+ + | Fax 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 | ++----------+---------+----------+--------+---------+--------+--------+ + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 79] + +RFC 3949 File Format for Internet Fax February 2005 + + + Table A.3 New Fields + + +---------------------------------------------------------+ + | Fax 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> | ++----------+---------+----------+--------+---------+--------+--------+ +| Fax- | | | n | n | n | n | +| Profile | | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| Global- | | IFD | IFD | IFD | IFD | IFD | +| Parame- | | | | | | | +| tersIFD | | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| Image- | | | | | | n, m | +| Layer | | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| T82- | | | n | | | n | +| Options | | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| Image- | | | | | | <n> | +| BaseColor| | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| Mode- | | | | | | n | +| Number | | | | | | | ++----------+---------+----------+--------+---------+--------+--------| +| Profile- | | | n | n | n | n | +| Type | | | | | | | ++--------------------------------------------------------------------+ + + + + +Buckley, et al. Standards Track [Page 80] + +RFC 3949 File Format for Internet Fax February 2005 + + ++----------+---------+----------+--------+---------+--------+--------+ +| Strip- | | | | | | <n> | +| RowCounts| | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ +| Version- | | | | <b> |<b> | | +| Year | | | | | | | ++----------+---------+----------+--------+---------+--------+--------+ + +Annex B: List of technical edits to RFC2301 + + This Annex lists technical differences between this document and + RFC 2301, the Proposed Standard File Format for Internet Fax. + ++----+---------+-------------------------------------------------+ +| No.| Section | Technical Edit | ++----+---------+-------------------------------------------------+ +| 1. | 5.2.1 | Added FillOrder=1 to Profile J | ++----+---------+-------------------------------------------------+ +| 2. | 6.2.1 | Constrained ResolutionUnit to 2 (i.e., inch) for| +| | 7.2.1 | all color profiles, per ITU-T Recommendations | +| | 8.2.1 | | ++----+---------+-------------------------------------------------+ +| 3. | 7.2.1 | Deleted ColorMap field; it re-encoded the color | +| | 7.4 | palette already in the T.43 data stream | ++----+---------+-------------------------------------------------+ +| 4. | 7.2.2 | Changed TAG value of Indexed field from 364 to | +| | | 346 to agree with Section 8.2.2 and Ref. [TTN1] | ++----+---------+-------------------------------------------------+ +| 5. | 8.2.1 | Added text clarifying the use of ImageWidth | +| | | when Background or Foreground layer is Primary | +| | | IFD | ++----+---------+-------------------------------------------------+ +| 6. | 8.2.3 | Changed field name from DefaultImageColor to | +| | | ImageBaseColor; | ++----+---------+-------------------------------------------------+ +| 7. | 8.2.1 | Added Compression=1 for ImageBaseColor IFDs | ++----+---------+-------------------------------------------------+ +| 8. | 5.2.1 | Redefined compression = 9 to be T.82 (JBIG); | +| | 5.2.3 | added T82Options field, with a default value (0)| +| | | corresponding to the T.85 application profile | ++----+---------+-------------------------------------------------+ +| 9. | 4.3.3 | Added GlobalParametersIFD, ProfileType, | +| | 4.7 | FaxProfile and CodingMethod to the New Fields | +| | | portion of Profile F, per Sec. 2.2.4 | ++----+---------+-------------------------------------------------+ + + + + + + +Buckley, et al. Standards Track [Page 81] + +RFC 3949 File Format for Internet Fax February 2005 + + ++----+---------+-------------------------------------------------+ +| 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when | +| |6.2.3,6.4| Compression=7 due to lack of interop testing. | +| |Table A.1| | ++----+---------+-------------------------------------------------+ +| 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M| +| |Table A.1| due to insufficient interop testing. | ++----+---------+-------------------------------------------------+ +| 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette-color | +| |8.2.1,8.5| due to lack of interop testing. | +| |Table A.1| | ++----+---------+-------------------------------------------------+ +| 13.| Annex B | Deleted Annex B due to discontinued use of | +| | | application parameter; Annex C renamed Annex B | ++----+---------+-------------------------------------------------+ + +Authors' Addresses + + Robert Buckley + Xerox Corporation + Mailstop 0128-30E + 800 Phillips Road + Webster, NY 14580, USA + + Phone: +1-585-422-1282 + Fax: +1-585-422-2636 + EMail: rbuckley@crt.xerox.com + + + Dennis Venable + Xerox Corporation + Mailstop 0128-27E + 800 Phillips Road + Webster, NY 14580, USA + + Phone: +1-585-422-3138 + Fax: +1-585-422-6117 + EMail: dvenable@crt.xerox.com + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 82] + +RFC 3949 File Format for Internet Fax February 2005 + + + Lloyd McIntyre + 10328 S. Stelling Road + Cupertino, CA 95014 USA + + Phone: +1-408-725-1624 + EMail: lloyd10328@pacbell.net or + Lloyd_McIntyre@Dell.com + + + Glenn W. Parsons + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7, Canada + + Phone: +1-613-763-7582 + Fax: +1-613-967-5060 + EMail: gparsons@nortel.com + + + James Rafferty + Brooktrout Technology + 410 First Avenue + Needham, MA 02494 USA + + Phone: +1-781-433-9462 + Fax: +1-781-433-9268 + EMail: jraff@brooktrout.com + + + + + + + + + + + + + + + + + + + + + + + + +Buckley, et al. Standards Track [Page 83] + +RFC 3949 File Format for Internet Fax February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Buckley, et al. Standards Track [Page 84] + |