LinuxDig.com Request For Comments

RFC Number : 2301 Title : File Format for Internet Fax. Network Working Group L. McIntyre Request for Comments: 2301 Xerox Corporation Category: Standards Track S. Zilles Adobe Systems, Inc. R. Buckley Xerox Corporation D. Venable Xerox Corporation G. Parsons Northern Telecom J. Rafferty Human Communications March 1998 File Format for Internet Fax Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the 'Internet Official Protocol Standards' (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. McIntyre, et. al. Standards Track [Page 1]  RFC 2301 File Format for Internet Fax March 1998 Table of Contents 1. INTRODUCTION........................................................4 1.1. Scope..........................................................5 1.2. Approach.......................................................5 1.3. Overview of this draft.........................................5 2. TIFF and Fax........................................................7 2.1. TIFF Overview..................................................7 2.1.1. File Structure.............................................7 2.1.2. Image Structure............................................9 2.1.3. TIFF File Structure for Fax Applications..................10 2.2 TIFF Fields for All Fax Applications...........................11 2.2.1. TIFF Fields required for all fax modes....................12 2.2.2. Additional TIFF Fields required for all fax modes.........13 2.2.3. TIFF Fields recommended for all fax modes.................15 2.2.4. New TIFF Fields recommended for fax modes.................16 3. Minimal Black-and-White Fax Mode...................................18 3.1. Overview......................................................18 3.2. Required TIFF Fields..........................................18 3.2.1 Baseline Fields............................................18 3.2.2 Extension Fields...........................................20 3.2.3 New Fields.................................................20 3.3. Recommended TIFF Fields.......................................20 3.4. End of Line (EOL) and Return to Control (RTC).................20 3.4.1 RTC Exclusion..............................................21 3.5. File Structure................................................22 3.6. Minimal Black-and-White Mode Summary..........................23 4. Extended Black-and-White Fax Mode..................................24 4.1. TIFF-F Overview...............................................25 4.2. Required TIFF Fields..........................................26 4.2.1. Baseline Fields...........................................26 4.2.2. Extension Fields..........................................28 4.2.3. New Fields................................................29 4.3. Recommended TIFF Fields.......................................29 4.3.1. Baseline Fields...........................................29 4.3.2. Extension Fields..........................................29 4.3.3. New Fields................................................29 4.4. Technical Implementation Issues...............................30 4.4.1. Strips....................................................30 4.4.2. Bit Order.................................................31 4.4.3. Multi-Page................................................31 4.4.4. Compression...............................................31 4.4.5. Example Use of Page-quality Fields........................32 4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F Files..............................................33 4.4.7. Use of TIFF-F for Streaming Applications..................34 4.5. Implementation Warnings.......................................34 4.5.1. Uncompressed Data.........................................34 McIntyre, et. al. Standards Track [Page 2]  RFC 2301 File Format for Internet Fax March 1998 4.5.2. Encoding and Resolution...................................35 4.5.3. EOL byte-aligned..........................................35 4.5.4. EOL.......................................................36 4.5.5. RTC Exclusion.............................................36 4.5.6. Use of EOFB for T.6 Compressed Images.....................37 4.6. Example Use of TIFF-F.........................................37 4.7. Extended Black-and-white Fax Mode Summary.....................37 5. Lossless JBIG Black-and-White Fax Mode.............................39 5.1. Overview......................................................40 5.2. Required TIFF Fields..........................................40 5.2.1. Baseline Fields...........................................40 5.2.2. Extension Fields..........................................40 5.2.3. New Fields................................................41 5.3. Recommended TIFF Fields.......................................41 5.4. Lossless JBIG Black-and-White Mode Summary....................41 6. Base Color Fax Mode................................................43 6.1. Overview......................................................43 6.2. Required TIFF Fields..........................................43 6.2.1. Baseline Fields...........................................43 6.2.2. Extension Fields..........................................45 6.2.3. New Fields................................................46 6.3. Recommended TIFF Fields.......................................47 6.4. Base Color Fax Mode Summary...................................47 7. Lossless Color Mode................................................49 7.1. Overview......................................................50 7.1.1. Color Encoding............................................50 7.1.2. JBIG Encoding.............................................50 7.2. Required TIFF Fields..........................................51 7.2.1. Baseline Fields...........................................51 7.2.2. Extension Fields..........................................52 7.2.3. New Fields................................................53 7.3. Recommended TIFF Fields.......................................53 7.4. Lossless Color Fax Mode Summary...............................53 8. Mixed Raster Content Mode..........................................55 8.1 Overview.......................................................55 8.1.1. MRC 3-layer model.........................................55 8.1.2. A TIFF Representation for the MRC 3-layer model...........56 8.2. Required TIFF Fields..........................................58 8.2.1. Baseline Fields...........................................58 8.2.2. Extension Fields..........................................59 8.2.3. New Fields................................................60 8.3. Recommended TIFF Fields.......................................62 8.4. Rules and Requirements for Images.............................62 8.5. MRC Fax Mode Summary..........................................63 9. MIME content-type image/tiff.......................................66 9.1 Refinement of MIME content-type image/tiff for Facsimile Applications...................................................66 10. Security Considerations...........................................67 McIntyre, et. al. Standards Track [Page 3]  RFC 2301 File Format for Internet Fax March 1998 11. References........................................................67 12. Authors' Addresses................................................69 Annex A: Summary of TIFF Fields for Internet Fax .....................70 Annex B. IANA Registration for image/tiff Application Parameter Values used for facsimile....................................75 Full Copyright Statement..............................................77 1. Introduction This document describes the use of TIFF (Tag Image File Format) to represent the data content and structure generated by the current suite of ITU-T Recommendations for Group 3 facsimile. These Recommendations and the TIFF fields described here support the following facsimile modes or profiles: S: minimal black-and-white mode, using binary MH compression [T.4] F: extended black-and-white mode, using binary MH, MR and MMR compression [T.4, T.6] J: lossless JBIG black-and-white mode, with JBIG compression [T.85, T.82] C: lossy color and grayscale mode, using JPEG compression [T.42, T.81] L: lossless color and grayscale mode, using JBIG compression [T.43, T.82] M: mixed raster content mode [T.44], using a combination of existing compression methods Each profile corresponds to the content of ITU-T Recommendations shown and is a subset of the full TIFF for facsimile specification. Profile S describes a minimal interchange set of fields, which will guarantee that, at least, binary black-and-white images will be supported. Implementations are required to support this minimal interchange set of fields. With the intent of specifying a file format for Internet Fax, this draft: 1. specifies the structure of TIFF files for facsimile data, 2. defines ITU fax-compatible values for existing TIFF fields, 3. defines new TIFF fields and values required for compatibility with ITU color fax. This specification of TIFF for facsimile is known as TIFF-FX. McIntyre, et. al. Standards Track [Page 4]  RFC 2301 File Format for Internet Fax March 1998 1.1 Scope This document defines a TIFF-based file format specification for enabling standardized messaging-based fax over the Internet. It specifies the TIFF fields and field values required for compatibility with the existing ITU-T Recommendations for Group 3 black-and-white, grayscale and color facsimile. TIFF has historically been used for handling fax image files in applications such as store-and-forward messaging. Implementations that support this file format specification for import/export may elect to support it as a native format. This document recommends a TIFF file structure that is compatible with low-memory and page-level streaming implementations. Unless otherwise noted, the current TIFF specification [TIFF] and selected TIFF Technical Notes [TTN1, TTN2] are the primary references for describing TIFF and defining TIFF fields. This document is the primary reference for defining TIFF field values for fax applications. 1.2 Approach The basic approach to using TIFF for facsimile data is to insert the compressed fax image data in a TIFF file and use TIFF fields to encode the parameters that describe the image data. These fields will have values that comply with the ITU-T Recommendations. The MIME content type of the resulting file will be image/tiff, with an optional Application parameter [TIFF-REG]; see Section 9. This approach takes advantage of TIFF features and structures that bridge the data formats and performance requirements of both legacy fax machines and host-based fax applications. TIFF constructs for pages, images, and strips allow a TIFF file to preserve the fax data stream structure and the performance advantages that come with it. A TIFF-based approach also builds on an established base of users and implementors and ensures backward compatibility with existing TIFF- based IETF proposals and work in progress for Internet fax. 1.3 Overview of this draft Section 2 gives an overview of TIFF. Section 2.1 describes the structure of TIFF files, including general guidelines for structuring multi-page TIFF files. Section 2.2 lists the TIFF fields that are required or recommended for all fax modes. The TIFF fields used only by specific fax modes are described in Sections 3-8, which describe the individual fax modes. These sections also specify the ITU- compatible field values (image parameters) for each mode. McIntyre, et. al. Standards Track [Page 5]  RFC 2301 File Format for Internet Fax March 1998 The full set of permitted fields of TIFF for facsimile are included in the current TIFF specification, Section 2 of this document and the sections on specific modes of facsimile operation. This document defines profiles of TIFF for facsimile, where a profile is a subset of the full set of permitted fields and field values of TIFF for facsimile. Section 3 defines the minimal black-and-white facsimile mode (Profile S), which is required in all implementations. Section 4 defines the extended black-and-white fax mode (Profile F), which provides a standard definition of TIFF-F. Section 5 describes the lossless black-and-white mode using JBIG compression (Profile J). Section 6 defines the base color mode, required in all color implementations, for the lossy JPEG representation of color and grayscale facsimile data (Profile C). Section 7 defines the lossless JBIG color and grayscale facsimile mode (Profile L) and Section 8 defines the Mixed Raster Content facsimile mode (Profile M). Each of these sections concludes with a table summarizing the required and recommended fields for each mode and the values they can have. Section 9 describes the MIME content type image/tiff and the use of the optional Application parameter in connection with TIFF for facsimile. Sections 10, 11, 12 and 13 give Security Considerations, the ISOC Copyright Notice, References and Authors' Addresses. Annex A gives a summary of the TIFF fields used or defined in this document and provides a convenient reference for implementors. To implement only the minimal interchange black-and-white set of fields and values (Profile S), one need read only Sections 1, 2, 3, 9 and 10. The following tree diagram shows the relationship among profiles and between profiles and coding methods. S (MH) / B&W / Color ------------ ---------- / / F (MMR, MR) C (JPEG) / / J (JBIG) ---- / L (JBIG) M (MRC) A profile is based on a collection of ITU-T facsimile coding methods. McIntyre, et. al. Standards Track [Page 6]  RFC 2301 File Format for Internet Fax March 1998 For example, Profile S, the minimal mode, is based on Modified Huffman (MH) compression, which are defined in ITU-T Rec. T.4. Profile F specifies Modified Read (MR) and Modified Modified Read (MMR) compressions, which are defined in ITU-T Rec. T.4 and T.6. All implementations of TIFF for facsimile MUST implement Profile S, which is the root node of the tree. All color implementations of TIFF for facsimile MUST implement Profile C. The implementation of a particular profile MUST also implement those profiles on the path that connect it to the root node, and MAY optionally implement profiles not on the path connecting it to the root node. For example, an implementation of Profile M must also implement Profiles C and S, and may optionally implement Profile F, J or L. For another example, an implementation of Profile C must also implement Profile S, and may optionally implement Profile F or J. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', ' NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [REQ]. 2. TIFF and Fax 2.1. TIFF Overview TIFF provides a means for describing, storing and interchanging raster image data. A primary goal of TIFF is to provide a rich environment within which applications can exchange image data. The current TIFF specification [TIFF] defines a commonly used, core set of TIFF fields known as Baseline TIFF. The current specification and TIFF Technical Notes 1 and 2 [TTN1, TTN2] define several TIFF extensions. The TIFF- based specification for fax applications uses a subset of Baseline TIFF fields, with selected extensions, as described in this document. In a few cases, this document defines new TIFF fields specifically for fax applications. 2.1.1. File Structure TIFF is designed for raster images, which makes it a good match for facsimile documents, which are multi-page raster images. Each raster image consists of a number of rows or scanlines, each of which has the same number of pixels, the unit of sampling. Each pixel has at least one sample or component (exactly one for black-and-white images). A TIFF file begins with an 8-byte image file header. The first two bytes describe the byte order used within the file. Legal values are 'II' (0x4949) when bytes are ordered from least to most significant (little- endian), and 'MM' (0x4D4D), when bytes are ordered from most McIntyre, et. al. Standards Track [Page 7]  RFC 2301 File Format for Internet Fax March 1998 to least significant (big-endian) within a 16- or 32-bit integer. Either byte order can be used, except in the case of the minimal black-and-white mode, which SHALL use value 'II'. The next two bytes contain the value 42 that identifies the file as a TIFF file and is ordered according to the value in the first two bytes of the header. The last four bytes give the offset that points to the first image file directory (IFD). This and all other offsets in a TIFF file are with respect to the beginning of the TIFF file. An IFD can be at any location in the file after the header but must begin on a word boundary. An IFD is a sequence of tagged fields, sorted in ascending order by tag value. An IFD consists of a 2-byte count of the number of fields, a sequence of field entries and a 4-byte offset to the next IFD. The fields contain information about the image and pointers to the image data. Each separate raster image in the file is represented by an IFD. Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag, 2 bytes identifying the field type (e.g. short, long, rational, ASCII), 4 bytes giving the count (number of values or offsets), and 4 bytes that either contain the offset to a field value stored outside the IFD, or, based on the type and count, the field value itself. Resolution and metadata such as dates, names and descriptions are examples of 'long' field values that do not fit in 4 bytes and therefore use offsets in the field entry. Details are given in the TIFF specification [TIFF]. A TIFF file can contain more than one IFD, where each IFD is a subfile whose type is given in the NewSubfileType field. Multiple IFDs can be organized either as a linked list, with the last entry in each IFD pointing to the next IFD (the pointer in the last IFD is 0), or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The SubIFDs field contains an array of pointers to child IFDs of the primary IFD. Child IFDs describe related images, such as reduced resolution versions of the primary IFD image. The same IFD can point both to a next IFD and to child IFDs, and child IFDs can themselves point to other IFDs. All fax modes represent a multi-page fax image as a linked list of IFDs, with a NewSubfileType field containing a bit that identifies the IFD as one page of a multi-page document. Each IFD has a PageNumber field, identifying the page number in ascending order, starting at 0 for the first page. While a Baseline TIFF reader is not McIntyre, et. al. Standards Track [Page 8]  RFC 2301 File Format for Internet Fax March 1998 required to read any IFDs beyond the first, an implementation that reads the files that comply with this specification SHALL read multiple IFDs. Only the Mixed Raster Content fax mode, described in Section 8, requires the use of child IFDs. The following figure illustrates the structure of a multi-page TIFF file. +-----------------------+ | Header |------------+ +-----------------------+ | First IFD | IFD (page 0) |<-----------+ Offset +---| |------------+ Value | +-----------------------+ | Offset +-->| Long Values |--+ | +-----------------------| | Strip | | Image Data |<-+ Offset | | strip 1 page 0 | | | +-----------------------+ | | | : | : | | +-----------------------+ | Next IFD | IFD (page 1) |<-----------+ Offset +---| |------------+ Value | +-----------------------+ | Offset +-->| Long Values |--+ | +-----------------------| | Strip | | Image Data |<-+ Offset | | strip 1 page 1 | | | +-----------------------+ | | | strip 2 page 1 |<-+ | +-----------------------+ | | | : | : | | +-----------------------+ | Next IFD | IFD (page 2) |<-----------+ Offset | : | 2.1.2 Image Structure An IFD stores an image as one or more strips, as shown in the preceding figure. A strip consists of 1 or more scanlines (rows) of raster image data in compressed form. An image may be stored in a single strip or may be divided into several strips, which would require less memory to buffer. (Baseline TIFF recommends about 8k bytes per strip, but existing fax usage is typically one strip per image.) McIntyre, et. al. Standards Track [Page 9]  RFC 2301 File Format for Internet Fax March 1998 Each IFD requires three strip-related fields: StripOffsets, RowsPerStrip and StripByteCounts. The StripOffsets field is an array of pointers to the strip or strips that contain the actual image data. The StripByteCounts field gives the number of bytes in each strip after compression. TIFF requires that each strip, except the last, contain the same number of scanlines, which is given in the RowsPerStrip field. This document introduces the new StripRowCounts field that allows a variable number of scanlines per strip, which is required by the Mixed Raster Content fax mode (Section 8). Image data is stored as uninterpreted, compressed image data streams within a strip. The formats of these streams follow the ITU-T Recommendations. The Compression field in the IFD indicates the type of compression, and other TIFF fields in the IFD describe image attributes, such as color encoding and spatial resolution. Compression parameters are stored in the compressed data stream, rather than in TIFF fields. This makes the TIFF representation and compressed data format specification independent of each another. This approach, modeled on [TTN2], allows TIFF to gracefully add new compression schemes as they become available. Some attributes can be specified both in the compressed data stream and within a TIFF field. It is possible that the two values will differ. When this happens for values required to interpret the data stream, then the values in the data stream take precedence. For informational values that are not required to interpret the data stream, such as author name, then the TIFF field value takes precedence. 2.1.3 TIFF File Structure for Fax Applications The TIFF specification has a very flexible file structure, which does not specify the ordering of IFDs, field values and image data in a file. Individual applications may require or recommend an ordering. This specification recommends that when using a TIFF file for facsimile, A multi-page fax document SHOULD be represented as a linked list of IFDs. It also recommends that a TIFF file for facsimile SHOULD order pages in a TIFF file in the same way that they are ordered in a fax data stream. In a TIFF file, a page consists of several elements: one or more IFDs (including subIFDs), long field values that are stored outside the IFDs, and image data (in one or more strips). The minimal black-and-white mode (Profile S) specifies a required ordering of pages and elements within a page (Section 3.5). The extended black-and-white mode (Profile F) provides guidelines for ordering pages and page elements (Section 4.4.6). Other profiles McIntyre, et. al. Standards Track [Page 10]  RFC 2301 File Format for Internet Fax March 1998 SHOULD follow these guidelines. This recommendation is intended to simplify the implementation of TIFF writers and readers in fax applications and the conversion between TIFF file and fax data stream representations. However, for interchange robustness, readers SHOULD be prepared to read TIFF files whose structure is consistent with [TIFF], which supports a more flexible file structure than is recommended here. This specification introduces an optional new GlobalParametersIFD field, defined in Section 2.2.4. This field has type IFD and indicates parameters describing the fax session. While it is often possible to obtain these parameters by scanning the file, it is convenient to make them available together in one place for fast and easy access. If the GlobalParametersIFD occurs in a TIFF file, it SHOULD be located in the first IFD, immediately following the 8-byte image file header. 2.2 TIFF Fields for All Fax Applications The TIFF specification [TIFF] is organized as a baseline set and several extensions, including technical notes [TTN1, TTN2] that will be incorporated in the next release of TIFF. The baseline and extensions have required and optional fields. Facsimile applications require (and recommend) a mixture of baseline and extensions fields, as well as some new fields that are not part of the TIFF specification and that are defined in this document. This sub- section lists the fields that are required or recommended for all modes. In particular, Section 2.2.1 lists the fields that are required by all modes and that have values that do not depend on the mode. Section 2.2.2 lists the fields that are required by all modes and that have values which do depend on the mode. Section 2.2.3 lists the fields that are recommended for all modes. Fields that are required or recommended by some but not all modes are given in the section (Section 3-8) that describes that mode. The sections for each fax mode have sub-sections for required and recommended fields; each sub-section organizes the fields according to whether they are baseline, extension or new. The fields required for facsimile have only a few legal values, specified in the ITU-T Recommendations. Of these legal values, some are required and some are optional, just as they are required (mandatory) or optional in fax implementations that conform to the ITU-T Recommendations. The required and optional values are noted in the sections on the different fax modes. McIntyre, et. al. Standards Track [Page 11]  RFC 2301 File Format for Internet Fax March 1998 This section describes the fields required or recommended by all fax modes. The pattern for the description of TIFF fields in this draft is: FieldName(TagValueInDecimal) = allowable values. TYPE WhetherRequiredByTIFForTIFFforFAX Count = (omitted if =1) = (if not in current spec but available) Explanation of the field, how it's used, and the values it can have. Default value, if any, as specified in [TIFF] When a field's default value is the desired value, that field may be omitted from the relevant IFD unless specifically required by the text of this specification. 2.2.1. TIFF fields required for all fax modes The TIFF fields listed in this section SHALL be used by all fax modes, but have field values that are not specified by the ITU standards, i.e. the fields do not depend on the mode. The next sub- section lists the fields that SHALL be used by all fax modes, but which do have values specified by the ITU-specified or mode-specific values. Fields that SHALL be used by some but not all modes are given in the sections (3-8) which describe the modes that uses them. ImageLength(257) SHORT or LONG RequiredByTIFFBaseline Total number of scanlines in image. No default, must be specified. PageNumber(297) SHORT RequiredByTIFFforFAX, TIFFExtension Count = 2 The first number represents the page number (0 for the first page); the second number is the total number of pages in the document. If the second value is 0, then the total page count is not available. No default, must be specified RowsPerStrip(278) SHORT or LONG RequiredByTIFFBaseline The number of scanlines per TIFF strip, except for the last strip. For a single strip image, this is the same as the value of the ImageLength field. Default = 2**32 - 1 (meaning all scanlines in one strip) StripByteCounts(279) SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, the number of bytes in that strip after compression. McIntyre, et. al. Standards Track [Page 12]  RFC 2301 File Format for Internet Fax March 1998 No default, must be specified. StripOffsets(273) SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, the byte offset from the beginning of the file to the start of that strip. No default, must be specified. 2.2.2 Additional TIFF fields required for all fax modes The TIFF fields listed in this section SHALL be used by all fax modes, but the values associated with them depend on the mode being described and the associated ITU Recommendations. Therefore, only the fields are defined here; the values applicable to a particular fax mode are described in Sections 3-8. Fields that SHALL be used by some but not all modes are given in the section (3-8) describing the mode that uses them. BitsPerSample(258) SHORT RequiredByTIFFBaseline Number of bits per image sample Default = 1 (field may be omitted if this is the value) Compression(259) SHORT RequiredByTIFFBaseline Compression method used for image data Default = 1 (no compression, so may not be omitted for FAX) FillOrder(266) SHORT RequiredByTIFFforFax The default bit order in Baseline TIFF per [TIFF] is indicated by FillOrder=1, where bits are not reversed before being stored. However, TIFF for Fax typically utilizes the setting of FillOrder=2, where the bit order within bytes is reversed before storage (i.e., bits are stored with the Least Significant Bit first). Default = 1 (field may be omitted if this is the value) Facsimile data appears on the phone line in bit-reversed order relative to its description in the relevant ITU compression Recommendation. Therefore, a wide majority of facsimile implementations choose this natural order for storage. Nevertheless, all readers conforming to this specification must be able to read data in both bit orders. ImageWidth(256) SHORT or LONG RequiredByTIFFBaseline The number of pixels (columns) per scanline (row) of the image No default, must be specified. McIntyre, et. al. Standards Track [Page 13]  RFC 2301 File Format for Internet Fax March 1998 NewSubFileType(254) LONG RequiredByTIFFforFAX A general indication of the kind of data contained in this IFD Bit 1 is 1 if the image is a single page of a multi-page document. Default = 0 (no subfile bits on, so may not be omitted for FAX) PhotometricInterpretation(262) SHORT RequiredByTIFFBaseline The color space of the image data No default, must be specified ResolutionUnit(296) SHORT RequiredByTIFFBaseline The unit of measure for resolution. 2 = inch, 3 = centimeter; Default = 2 (field may be omitted if this is the value) SamplesPerPixel(277) SHORT RequiredByTIFFBaseline The number of color components per pixel; SamplesPerPixel is 1 for a black-and-white, grayscale or indexed (palette) image. Default =1 (field may be omitted if this is the value) XResolution(282) RATIONAL RequiredByTIFFBaseline The horizontal resolution of the image in pixels per resolution unit. The ITU-T Recommendations for facsimile specify a small number of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per inch). The allowed XResolution values for each mode are given in the section defining that mode. Per [T.4], it is permissible for applications to treat the following XResolution values as being equivalent: <204, 200> and <400,408> in pixels/inch. These equivalencies were allowed by [T.4] to permit conversions between inch and metric based facsimile terminals. TIFF for Facsimile Writers SHOULD express XResolution in inch based units, for consistency with historical practice and to maximize interoperability. See the table below for information on how to convert from an ITU-T metric value to its inch based equivalent resolution. No default, must be specified YResolution(283) RATIONAL RequiredByTIFFBaseline The vertical resolution of the image in pixels per resolution unit. The ITU-T Recommendations for facsimile specify a small number of vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The allowed YResolution values for each mode are given in the section McIntyre, et. al. Standards Track [Page 14]  RFC 2301 File Format for Internet Fax March 1998 defining that mode. Per [T.4], it is permissible for applications to treat the following YResolution values as being equivalent: <98, 100>, <196, 200>, and <391, 400> in pixels/inch. These equivalencies were allowed by [T.4] to permit conversions between inch and metric based facsimile terminals. TIFF for Facsimile Writers SHOULD express YResolution in inch based units, for consistency with historical practice and to maximize interoperability. See the table below for information on how to convert from an ITU-T metric value to its inch based equivalent resolution. No default, must be specified +-----------------------------+-----------------------------+ | XResolution | YResolution | +--------------+--------------+--------------+--------------+ |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit| | =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) | +--------------+--------------+--------------+--------------+ | 100 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 98 | 38.5 | | 200 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 196 | 77 | | 200 | | 200 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 391 | 154 | +--------------+--------------+--------------+--------------+ | 300 | | 300 | | +--------------+--------------+--------------+--------------+ | 408 | 160 | 391 | 154 | | 400 | | 400 | | +--------------+--------------+--------------+--------------+ 2.2.3 TIFF fields recommended for all fax modes The TIFF fields listed in this section MAY be used by all fax modes. However, Profile S writers (the minimal fax mode described in Section 3) SHOULD NOT use these fields. Recommended fields that are mode- specific are described in Sections 3-8. DateTime(306) ASCII OptionalInTIFFBaseline Date/time of image creation in 24-hour format 'YYYY:MM:DD HH:MM:SS'. No default. DocumentName(269) ASCII OptionalInTIFFExtension(DocumentStorageAndRetrieval) The name of the scanned document. This is a TIFF extension field, not a Baseline TIFF field. McIntyre, et. al. Standards Track [Page 15]  RFC 2301 File Format for Internet Fax March 1998 No default. ImageDescription(270) ASCII OptionalInTIFFBaseline A string describing the contents of the image. No default. Orientation(274) = 1-8. SHORT OptionalinTIFFBaseline 1: 0th row represents the visual top of the image; the 0th column represents the visual left side of the image. See the current TIFF spec [TIFF] for further values; Baseline TIFF only requires value=1. Default = 1. Note: It is recommended that a writer that is aware of the orientation will include this field to give a positive indication of the orientation, even if the value is the default. If the Orientation field is omitted, the reader SHALL assume a value of 1. Software(305) ASCII OptionalInTIFFBaseline The optional name and release number of the software package that created the image. No default. 2.2.4 New TIFF fields recommended for fax modes The new TIFF fields listed in this section MAY be used by all fax modes, but their support is not expected for the minimal fax mode described in Section 3. In addition, support for these new TIFF fields has not been included in historical TIFF-F readers described in Section 4 and [TIFF- F]. These fields describe 'global' parameters of the fax session that created the image data. They are optional, not part of the current TIFF specification, and are defined in this document. The first new field, GlobalParametersIFD, is an IFD that contains global parameters and is located in a Primary IFD. GlobalParametersIFD (400) IFD An IFD containing global parameters. It is recommended that a TIFF writer place this field in the first IFD, where a TIFF reader would find it quickly. Each field in the GlobalParametersIFD is a TIFF field that is legal in any IFD. Required baseline fields should not be located in the GlobalParametersIFD, but should be in each image IFD. If a conflict exists between fields in the GlobalParametersIFD and in the image IFDs, then the data in the image IFD shall prevail. McIntyre, et. al. Standards Track [Page 16]  RFC 2301 File Format for Internet Fax March 1998 Among the GlobalParametersIFD entries is a new ProfileType field which generally describes information in this IFD and in the TIFF file. ProfileType(401) LONG The type of image data stored in this IFD. 0 = Unspecified 1 = Group 3 fax No default The following new global fields are defined in this document as IFD entries for use with fax applications. FaxProfile(402) = 0 - 6. BYTE The profile that applies to this file; a profile is subset of the full set of permitted fields and field values of TIFF for facsimile. The currently defined values are: 0: does not conform to a profile defined for TIFF for facsimile 1: minimal black & white lossless, Profile S 2: extended black & white lossless, Profile F 3: lossless JBIG black & white, Profile J 4: lossy color and grayscale, Profile C 5: lossless color and grayscale, Profile L 6: Mixed Raster Content, Profile M CodingMethods(403) LONG This field indicates which coding methods are used in the file. A bit value of 1 indicates which of the following coding methods is used: Bit 0: unspecified compression, Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman), Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read), Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR), Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG), Bit 5: ITU-T Rec. T.81 (Baseline JPEG), Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color), Bits 7-31: reserved for future use Note: There is a limit of 32 compression types to identify standard compression methods. VersionYear(404) BYTE Count: 4 The year of the standard specified by the FaxProfile field, given as 4 characters, e.g. '1997'; used in lossy and lossless color modes. ModeNumber (405) BYTE The mode of the standard specified by the FaxProfile field. A value of 0 indicates Mode 1.0; used in Mixed Raster Content mode. McIntyre, et. al. Standards Track [Page 17]  RFC 2301 File Format for Internet Fax March 1998 3. Minimal Black-and-White Fax Mode This section defines the minimal black-and-white subset of TIFF for facsimile. This subset is designated Profile S. All implementations of TIFF for facsimile SHALL support the minimal subset. Black-and-white mode is the binary fax application most users are familiar with today. This mode is appropriate for black-and-white text and line art. Black-and-white mode is divided into two levels of capability. This section describes the minimal interchange set of TIFF fields that must be supported by all implementations in order to assure that some form of image, albeit black-and-white, can be interchanged. This minimum interchange set is a strict subset of the fields and values defined for the extended black-and-white mode (TIFF-F or Profile F) in Section 4, which describes extensions to the minimal interchange set of fields that provide a richer set of black-and-white capabilities. 3.1. Overview The minimal interchange portion of the black-and-white facsimile mode supports 1-dimensional Modified Huffman (MH) compression, with the original Group 3 fax resolutions, commonly called 'standard' and 'fine.' To assure interchange, this mode uses the minimal set of fields, with a minimal set of values. There are no recommended fields in this mode. Further, the TIFF file is required to be 'little endian,' which means that the byte order value in the TIFF header is 'II'. This mode defines a required ordering for the pages in a fax document and for the IFDs and image data of a page. It also requires that a single strip contain the image data for each page; see Section 3.5. The image data may contain RTC sequences, as specified in Section 3.4. 3.2. Required TIFF Fields Besides the fields listed in Section 2.2.1, the minimal black-and- white fax mode requires the following fields. The fields listed in Section 2.2.1 and the fields and fax-specific values specified in this sub- section must be supported by all implementations. 3.2.1 Baseline fields BitsPerSample(258) = 1. SHORT RequiredByTIFFBaseline Binary data only. Default = 1 (field may be omitted if this is the value) McIntyre, et. al. Standards Track [Page 18]  RFC 2301 File Format for Internet Fax March 1998 Compression(259) = 3. SHORT RequiredByTIFFBaseline 3 = 1- or 2- dimensional coding. The value 3 is a TIFF extension value [TIFF]. The T4Options field must be specified and its value specifies that the data is encoded using the Modified Huffman (MH) encoding of [T.4]. FillOrder(266) = 2. SHORT RequiredByTIFFBaseline 2 = Least Significant Bit first NOTE: Baseline TIFF readers are only required to support FillOrder = 1, where the lowest numbered pixel is stored in the MSB of the byte. However, because many devices, such as modems, transmit the LSB first when converting the data to serial form, it is common for black-and- white fax products to use the second FillOrder =2, where the lowest numbered pixel is stored in the LSB. Therefore, this value is specified in the minimal black-and-white mode. ImageWidth(256) = 1728. SHORT or LONG RequiredByTIFFBaseline This mode only supports a page width of 1728 pixels. This width corresponds to North American Letter and Legal and to ISO A4 size pages. No default, must be specified. NewSubFileType(254) = (Bit 1=1). LONG RequiredByTIFFforFAX Bit 1 is 1 if the image is a single page of a multi-page document. Default = 0 (no subfile bits on, so may not be omitted for fax) PhotometricInterpretation(262) = 0. SHORT RequiredByTIFFBaseline 0 = pixel value 1 means black No default, must be specified ResolutionUnit(296) = 2. SHORT RequiredByTIFFBaseline The unit of measure for resolution. 2 = inch. Default = 2 (field may be omitted if this is the value) SamplesPerPixel(277) = 1. SHORT RequiredByTIFFBaseline The number of components per pixel; 1 for black-and-white Default =1 (field may be omitted if this is the value) XResolution(282) = 200, 204. RATIONAL RequiredByTIFFBaseline McIntyre, et. al. Standards Track [Page 19]  RFC 2301 File Format for Internet Fax March 1998 The horizontal resolution of the image is expressed in pixels per resolution unit. In pixels/inch, the allowed values are 200 and 204, which may be treated as equivalent. See Section 2.2.2 for inch- metric equivalency. No default, must be specified YResolution(283) = 98, 100, 196, 200. RATIONAL RequiredByTIFFBaseline The vertical resolution of the image is expressed in pixels per resolution unit. In pixels/inch, the allowed values are 98, 100, 196 and 200; 98 and 100 may be treated as equivalent, and 196 and 200 may be treated as equivalent. See Section 2.2.2 for inch-metric equivalency. No default, must be specified 3.2.2 Extension fields T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1) LONG RequiredTIFFExtension (when Compression = 3) Bit 0 = 0 indicates MH encoding. Bit 1 must be 0 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte aligned Default is all bits are 0 (applies when EOLs are not byte aligned) Note: The T4Options field is required when the Compression field has a value of 3. Bit 0 of this field specifies the encoding used (MH only in this mode) and Bit 2 indicates whether the EOL codes are byte-aligned or not. If they are byte aligned, then fill bits have been added as necessary so that the End of Line (EOL) codes always end on byte boundaries. See Section 3.4 for details. 3.2.3. New Fields None. 3.3. Recommended TIFF Fields None. 3.4. End of Line (EOL) and Return to Control (RTC) The handling of End of Line (EOL) codes and Return to Control (RTC) sequences illustrate the differences between conventional fax, which is bit and stream oriented, and TIFF, which is byte and file oriented. Conventional fax, Baseline TIFF and TIFF extensions for fax all handle EOLs and RTCs differently. McIntyre, et. al. Standards Track [Page 20]  RFC 2301 File Format for Internet Fax March 1998 In conventional fax, an MH-compressed fax data stream for a page consists of the following sequence: EOL, compressed data (first line), EOL, compressed data, ... , EOL, compressed data (last line), RTC (6 consecutive EOL codes) Baseline TIFF does not use EOL codes or Return to Control (RTC) sequences for MH-compressed data. However, the TIFF extension field T4Options used in this specification for MH compression (Compression = 3) requires EOLs. Furthermore, Bit 2 in the T4Options field indicates whether or not the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL codes are byte aligned, then fill bits have been added as necessary before EOL codes so that an EOL code always ends on a byte boundary, and the first bit of data following an EOL begins on a byte boundary. Without fill bits, an EOL code may end in the middle of a byte. Byte alignment relieves application software of the burden of bit-shifting every byte while parsing scan lines for line-oriented image manipulation (such as writing a TIFF file). Not all TIFF readers historically used for fax are able to deal with non-byte aligned data. While TIFF extension requires EOL codes, TIFF in fax applications has traditionally prohibited RTC sequences. Implementations that want common processing and interfaces for fax data streams and Internet fax files would prefer that the TIFF data include RTC sequences. To reconcile these differences, RTCs are allowed in cases where EOL codes are not byte aligned and no fill bits have been added to the data. This corresponds to situations where the fax data is simply inserted in a strip without being processed or interpreted. RTCs should not occur in the data when EOLs have been byte aligned. This is formally specified in the next sub-section. 3.4.1. RTC Exclusion Implementations which wish to maintain strict conformance with TIFF and compatibility with the historical use of TIFF for fax SHOULD NOT include the RTC sequence when writing TIFF files. However, implementations which need to support 'transparency' of T.4-generated image data MAY include RTCs when writing TIFF files if the flag settings of the T4Options field are set for non-byte aligned data, i.e. Bit 2 is 0. Implementors of TIFF readers should be aware that there are some existing TIFF implementations for fax that include the RTC sequence in MH image data. Therefore, minimal set readers MUST be able to process files which do not include RTCs and SHOULD be able to process files which do include RTCs. McIntyre, et. al. Standards Track [Page 21]  RFC 2301 File Format for Internet Fax March 1998 3.5. File Structure The TIFF header, described in Section 2.1.1, contains two bytes which describe the byte order used within the file. For the minimal black- and- white mode, these bytes SHALL have the value 'II' (0x4949), denoting that the bytes in the TIFF file are in LSByte-first order (little- endian). The first or 0th IFD immediately follows the header, so that offset to the first IFD is 8. The headers values are shown in the following table: +--------+-------------------+--------+-----------+ | Offset | Description | Value | +--------+-------------------+--------+-----------+ | 0 | Byte Order | 0x4949 (II) | +--------+-------------------+--------+-----------+ | 2 | Identifier | 42 decimal | +--------+-------------------+--------+-----------+ | 4 | Offset of 0th IFD | 0x 0000 0008 | +--------+-------------------+--------+-----------+ The minimal black-and-white mode SHALL order IFDs and image data within a file as follows: 1) there SHALL be an IFD for each page in a multi- page fax document; (2) the IFDs SHALL occur in the same order in the file as the pages occur in the document; (3) the IFD SHALL precede the image data to which it has offsets; (4) the image data SHALL occur in the same order in the file as the pages occur in the document; (5) the IFD, the value data and the image data it has offsets to SHALL precede the next image IFD; and (6) the image data for each page SHALL be contained within a single strip. As a result of (6), the StripOffsets field will contain the pointer to the image data. With two exceptions, the field entries in the IFD contain the field values instead of offsets to field values located outside the IFD. The two exceptions are the values for the XResolution and YResolution fields, both of which are type RATIONAL and require 2 4- byte numbers. These 'long' field values SHALL be placed immediately after the IFD which contains the offsets to them, and before the image data pointed to by that IFD. The effect of these requirements is that the IFD for the first page SHALL come first in the file after the TIFF header, followed by the long field values for XResolution and YResolution, followed by the image data for the first page, then the IFD for second page, etc. This is shown in the following figure. Each IFD is required to have a PageNumber field, which has value 0 for the first page, 1 for the second page, and so on. McIntyre, et. al. Standards Track [Page 22]  RFC 2301 File Format for Internet Fax March 1998 +-----------------------+ | Header |------------+ +-----------------------+ | First IFD | IFD (page 0) | <----------+ Offset +---| |------------+ | | |--+ | Value | +-----------------------+ | | Offset +-->| Long Values | | | +-----------------------| | Strip | | Image Data (page 0) |<-+ Offset | +-----------------------+ | Next IFD | IFD (page 1) | <----------+ Offset +---| |------------+ | | |--+ | Value | +-----------------------+ | | Offset +-->| Long Values | | | +-----------------------| | Strip | | Image Data (page 1) |<-+ Offset | +-----------------------+ | Next IFD | IFD (page 2) | <----------+ Offset +-----------------------+ | : | Using this file structure may reduce the memory requirements in implementations. It is also provides some support for streaming, in which a file can be processed as it is received and before the entire file is received. 3.6 Minimal Black-and-white Mode Summary The table below summarizes the TIFF fields that comprise the minimal interchange set for black-and-white facsimile. The Baseline and Extension fields and field values MUST be supported by all implementations. For convenience in the table, certain fields which have a value that is a sequence of flag bits are shown taking integer values that correspond to the flags that are set. An implementation should test the setting of the relevant flag bits individually, however, to allow extensions to the sequence of flag bits to be appropriately ignored. (See, for example, T4Options below.) +---------------------------+--------------------------------+ | Baseline Fields | Values | +---------------------------+--------------------------------+ | BitsPerSample | 1 | +---------------------------+--------------------------------+ | Compression | 3: 1D Modified Huffman coding | | | set T4Options = 0 or 4 | +------------------------------------------------------------+ McIntyre, et. al. Standards Track [Page 23]  RFC 2301 File Format for Internet Fax March 1998 +---------------------------+--------------------------------+ | FillOrder | 2: least significant bit first | +---------------------------+--------------------------------+ | ImageWidth | 1728 | +---------------------------+--------------------------------+ | ImageLength | n: total number of scanlines | | | in image | +---------------------------+--------------------------------+ | NewSubFileType | 2: Bit 1 identifies single | | | page of a multi-page document | +---------------------------+--------------------------------+ | PageNumber | n,m: page number n followed by | | | total page count m | +---------------------------+--------------------------------+ | PhotometricInterpretation | 0: pixel value 1 means black | +---------------------------+--------------------------------+ | ResolutionUnit | 2: inch | +---------------------------+--------------------------------+ | RowsPerStrip | number of scanlines per strip | | | = ImageLength, with one strip | +---------------------------+--------------------------------+ | SamplesPerPixel | 1 | +---------------------------+--------------------------------+ | StripByteCounts | number of bytes in TIFF strip | +---------------------------+--------------------------------+ | StripOffsets | offset from beginning of | | | file to single TIFF strip | +---------------------------+--------------------------------+ | XResolution | 204, 200 (pixels/inch) | +---------------------------+--------------------------------+ | YResolution | 98, 196, 100, 200 (pixels/inch)| +---------------------------+--------------------------------+ | Extension Fields | +---------------------------+--------------------------------+ | T4Options | 0: MH coding, EOLs not byte | | | aligned | | | 4: MH coding, EOLs byte aligned| +---------------------------+--------------------------------+ 4. Extended Black-and-White fax mode This section defines the extended black-and-white mode or Profile F of TIFF for facsimile. It provides a standard definition of what has historically been known as TIFF Class F and now TIFF-F. In doing so, it aligns this mode with current ITU-T Recommendations for black- and-white fax and with existing industry practice. Implementations of this profile include implementations of Profile S. McIntyre, et. al. Standards Track [Page 24]  RFC 2301 File Format for Internet Fax March 1998 This section describes extensions to the minimal interchange set of fields (Profile S) that provide a richer set of black-and-white capabilities. The fields and values described in this section are a superset of the fields and values defined for the minimal interchange set in Section 3. In addition to the MH encoding, Modified READ (MR) and Modified Modified READ (MMR) encoding as described in [T.4] and [T.6] are supported. Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the TIFF fields that SHALL be used in this mode. Section 4.3 describes the fields that MAY be used in this mode. In the spirit of the original TIFF-F specification, Sections 4.4 and 4.5 discuss technical implementation issues and warnings. Section 4.6 gives an example use of TIFF-F. Section 4.7 gives a summary of the required and recommended fields and their values. 4.1 TIFF-F Overview Though it has been in common usage for many years, TIFF-F has previously never been documented in the form of a standard. An informal TIFF-F document was originally created by a small group of fax experts led by Joe Campbell. The existence of TIFF-F is noted in [TIFF] but it is not defined. This document serves as the formal definition of the F application of [TIFF] for Internet applications. For ease of reference, the term TIFF-F will be used throughout this document as a shorthand for the extended black-and-white mode or profile of TIFF for facsimile. Up until the TIFF 6.0 specification, TIFF supported various 'Classes' which defined the use of TIFF for various applications. Classes were used to support specific applications. In this spirit, TIFF-F has been known historically as 'TIFF Class F'. Previous informal TIFF-F documents [TIFF-F0] used the 'Class F' terminology. As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in favor of the concept of Baseline TIFF. Therefore, this document updates the definition of TIFF-F as the F profile of TIFF for facsimile, by using Baseline TIFF as defined in [TIFF] as the starting point and then adding the TIFF extensions to Baseline TIFF which apply for TIFF-F. In almost all cases, the resulting definition of TIFF-F fields and values remains consistent with those used historically in earlier definitions of TIFF Class F. Where some of the values for fields have been updated to provide more precise conformance with the ITU-T [T.4] and [T.30] fax recommendations, these differences are noted. McIntyre, et. al. Standards Track [Page 25]  RFC 2301 File Format for Internet Fax March 1998 4.2. Required TIFF Fields This section lists the required fields and the values they must have to be ITU-compatible. Besides the fields listed in Section 2.2.1, the extended black-and-white fax mode SHALL use the following fields. 4.2.1. Baseline fields BitsPerSample(258) = 1. SHORT RequiredByTIFFBaseline Binary data only. Default = 1 (field may be omitted if this is the value) Compression(259) = 3, 4. SHORT RequiredByTIFFBaseline 3 = 1- or 2- dimensional coding, must have T4Options field This is a TIFF Extension value [TIFF]. 4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified Read, must have T6Options field)) This is a TIFF Extension value. Default = 1 (and is not applicable; field must be specified) NOTE: Baseline TIFF permits use of value 2 for Modified Huffman encoding, but data is presented in a form which does not use EOLs, and so TIFF for facsimile uses Compression=3 instead. See Sections 4.4.4, 4.5.1 and 4.5.2 for more information on compression and encoding. FillOrder(266) = 1 , 2. SHORT RequiredByTIFFBaseline Profile F readers must be able to read data in both bit orders, but the vast majority of facsimile products store data LSB first, exactly as it appears on the telephone line. 1 = Most Significant Bit first. 2 = Least Significant Bit first ImageWidth(256) SHORT or LONG RequiredByTIFFBaseline This mode supports the following fixed page widths: 1728, 2592, 3456 (corresponding to North American Letter and Legal, ISO A4 paper sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and 2432, 3648, 4864 (corresponding to ISO A3 paper size). No default; must be specified NOTE: Historical TIFF-F did not include support for the following widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096 and 4864. Historical TIFF-F documents also included the following values related to A5 and A6 widths: 816 and 1216. Per the most recent McIntyre, et. al. Standards Track [Page 26]  RFC 2301 File Format for Internet Fax March 1998 version of [T.4], A5 and A6 documents are no longer supported in Group 3 facsimile, so the related width values are now obsolete. See section 4.5.2 for more information on inch/metric equivalencies and other implementation details. NewSubFileType(254) = (Bit 1=1). LONG RequiredByTIFFforFAX Bit 1 is 1 if the image is a single page of a multi-page document. Default = 0 (no subfile bits on, so may not be omitted for fax) NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page of a multi-page image. The same bit settings are used when TIFF-F is used for a one page fax image. See Section 4.4.3 for details on multi-page files. PhotometricInterpretation(262) = 0, 1. SHORT RequiredByTIFFBaseline 0 = pixel value 1 means black, 1 = pixel value 1 means white. This field allows notation of an inverted or negative image. No default, must be specified ResolutionUnit(296) = 2, 3. SHORT RequiredByTIFFBaseline The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F has traditionally used inch-based measures. Default = 2 (field may be omitted if this is the value) SamplesPerPixel(277) = 1. SHORT RequiredByTIFFBaseline 1 = monochrome, bilevel in this case (see BitsPerSample) Default =1 (field may be omitted if this is the value) XResolution(282) = 200, 204, 300, 400, 408 RATIONAL RequiredByTIFFBaseline The horizontal resolution of the image is expressed in pixels per resolution unit. In pixels/inch, the allowed values are: 200, 204, 300, 400, and 408. See Section 2.2.2 for inch-metric equivalency. No default, must be specified NOTE: The values of 200 and 408 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 80 pixels/cm, which is equivalent to 204 pixels per inch. See section 4.5.2 for information on implementation details. YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 RATIONAL RequiredByTIFFBaseline The vertical resolution of the image is expressed in pixels per McIntyre, et. al. Standards Track [Page 27]  RFC 2301 File Format for Internet Fax March 1998 resolution unit. In pixels/inch, the allowed values are: 98, 100, 196, 200, 300, 391, and 400 pixels/inch. See Section 2.2.2 for inch-metric equivalency. No default, must be specified NOTE: The values of 100, 200, and 391 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77 and 38.5 (cm), which are equivalent to 196 and 98 pixels per inch respectively. See section 4.5.2 for more information on implementation details. NOTE: Not all combinations of XResolution, YResolution and ImageWidth are legal. The following table gives the legal combinations and corresponding paper size [T.30]. +--------------+-----------------+---------------------------+ | XResolution x YResolution | ImageWidth | +--------------+-----------------+---------+--------+--------+ | 200x100, 204x98 | | | | | 200x200, 204x196 | 1728 | 2048 | 2432 | | 204x391 | | | | +--------------+-----------------+---------+--------+--------+ | 300 x 300 | 2592 | 3072 | 3648 | +--------------+-----------------+---------+--------+--------+ | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | +--------------+-----------------+---------+--------+--------+ |Letter,A4| B4 | A3 | | Legal | | | +---------+--------+--------+ | Paper Size | +---------------------------+ 4.2.2. Extension fields T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) LONG RequiredTIFFExtension (when Compression = 3) T4Options was also known as Group3Options in a prior version of [TIFF]. Bit 0 = 1 indicates MR encoding, = 0 indicates MH encoding. Bit 1 must be 0 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte aligned Default is all bits are 0 (applies when MH encoding is used and EOLs are not byte aligned EOLs) (See Section 3.2.2.) The T4Options field is required when the Compression field has a value of 3. This field specifies the encoding used (MH or MR) and whether the EOL codes are byte-aligned or not. If they are byte McIntyre, et. al. Standards Track [Page 28]  RFC 2301 File Format for Internet Fax March 1998 aligned, then fill bits have been added as necessary so that the End of Line (EOL) codes always end on byte boundaries See Sections 3.4, 4.5.3 and 4.5.4 for details. T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG RequiredTIFFExtension (when Compression = 4) Used to indicate parameterization of 2D Modified Modified Read compression. T6Options was also known as Group4Options in a prior version of [TIFF]. Bit 0 must be 0. Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1 indicates uncompressed data is allowed (see [TIFF]). Default is all bits 0. For FAX, the field must be present and have the value 0. The use of uncompressed data where compression would expand the data size is not allowed for FAX. NOTE: MMR compressed data is two-dimensional and does not use EOLs. Each MMR encoded image MUST include an 'end-of-facsimile-block' (EOFB) code at the end of each coded strip; see Section 4.5.6. 4.2.3. New fields None. 4.3. Recommended TIFF fields 4.3.1. Baseline fields See Section 2.2.3. 4.3.2. Extension fields See Section 2.2.3. 4.3.3. New fields Three new, optional fields, used in the original TIFF-F description to describe page quality, are defined in this specification. The information contained in these fields is usually obtained from receiving facsimile hardware (if applicable). They SHOULD NOT be used in writing TIFF-F files for facsimile image data that is error corrected or otherwise guaranteed not to have coding errors. Some applications need to understand exactly the error content of the data. For example, a CAD program might wish to verify that a file has a low error level before importing it into a high-accuracy document. Because Group 3 facsimile devices do not necessarily perform error correction on the image data, the quality of a received page must be inferred from the pixel count of decoded scan lines. A McIntyre, et. al. Standards Track [Page 29]  RFC 2301 File Format for Internet Fax March 1998 'good' scan line is defined as a line that, when decoded, contains the correct number of pixels. Conversely, a 'bad' scan line is defined as a line that, when decoded, comprises an incorrect number of pixels. BadFaxLines(326) SHORT or LONG The number of 'bad' scan lines encountered by the facsimile device during reception. A 'bad' scanline is defined as a scanline that, when decoded, comprises an incorrect number of pixels. Note that PercentBad = (BadFaxLines/ImageLength) * 100 No default. CleanFaxData(327) = 0, 1, 2. SHORT Indicates if 'bad' lines encountered during reception are stored in the data, or if 'bad' lines have been replaced by the receiver. 0 = No 'bad' lines 1 = 'bad' lines exist, but were regenerated by the receiver, 2 = 'bad' lines exist, but have not been regenerated. No default. NOTE: Many facsimile devices do not actually output bad lines. Instead, the previous good line is repeated in place of a bad line. Although this substitution, known as line regeneration, results in a visual improvement to the image, the data is nevertheless corrupted. The CleanFaxData field describes the error content of the data. That is, when the BadFaxLines and ImageLength fields indicate that the facsimile device encountered lines with an incorrect number of pixels during reception, the CleanFaxData field indicates whether these bad lines are actually still in the data or if the receiving facsimile device replaced them with regenerated lines. ConsecutiveBadFaxLines(328) LONG or SHORT Maximum number of consecutive 'bad' scanlines received. The BadFaxLines field indicates only the quantity of bad lines. No Default. NOTE: The BadFaxLines and ImageLength data indicate only the quantity of bad lines. The ConsecutiveBadFaxLines field is an indicator of the distribution of bad lines and may therefore be a better general indicator of perceived image quality. See Section 4.4.5 for examples of the use of these fields. 4.4. Technical Implementation Issues 4.4.1 Strips In general, TIFF files divide an image into 'strips,' also known as 'bands.' Each strip contains a few scanlines of the image. By using McIntyre, et. al. Standards Track [Page 30]  RFC 2301 File Format for Internet Fax March 1998 strips, a TIFF reader need not load the entire image into memory, thus enabling it to fetch and decompress small random portions of the image as necessary. The number of scanlines in a strip is described by the RowsPerStrip value and the number of bytes in the strip after compression by the StripByteCount value. The location in the TIFF file of each strip is given by the StripOffsets values. Strip size is application dependent. The recommended approach for multi- page TIFF-F images is to represent each page as a single strip. Existing TIFF-F usage is typically one strip per page in multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3. 4.4.2 Bit Order The current TIFF specification [TIFF] does not require a Baseline TIFF reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel in the least significant bit of a byte. It further recommends that FillOrder=2 be used only in special purpose applications. Facsimile data appears on the phone line in bit-reversed order relative to its description in ITU-T Recommendation T.4. Therefore, a wide majority of facsimile applications choose this natural order for data in a file. Nevertheless, TIFF-F readers must be able to read data in both bit orders and support FillOrder values of 1 and 2. 4.4.3. Multi-Page Many existing applications already read TIFF-F-like files, but do not support the multi-page field. Since a multi-page format greatly simplifies file management in fax application software, TIFF-F specifies multi-page documents (NewSubfileType = 2) as the standard case. It is recommended that applications export multiple page TIFF-F files without manipulating fields and values. Historically, some TIFF-F writers have attempted to produce individual single-page TIFF-F files with modified NewSubFileType and PageNumber (page one-of-one) values for export purposes. However, there is no easy way to link such multiple single page files together into a logical multiple page document, so that this practice is not recommended. 4.4.4. Compression In Group 3 facsimile, there are three compression methods which had been standardized as of 1994 and are in common use. The ITU-T T.4 Recommendation [T.4] defines a one-dimensional compression method McIntyre, et. al. Standards Track [Page 31]  RFC 2301 File Format for Internet Fax March 1998 known as Modified Huffman (MH) and a two-dimensional method known as Modified READ (MR) (READ is short for Relative Element Address Designate). In 1984, a somewhat more efficient compression method known as Modified Modified READ (MMR) was defined in the ITU-T T.6 Recommendation [T.6]. MMR was originally defined for use with Group 4 facsimile, so that this compression method has been commonly called Group 4 compression. In 1991, the MMR method was approved for use in Group 3 facsimile and has since been widely utilized. TIFF-F supports these three compression methods. The most common practice is the one-dimensional Modified Huffman (MH) compression method. This is specified by setting the Compression field value to 3 and then setting bit 0 of the T4Options field to 0. Alternatively, the two dimensional Modified READ (MR) method, which is much less frequently used in historical TIFF-F implementations, may be selected by setting bit 0 of the T4Options field to 1. The value of Bit 2 in this field is determined by the use of fill bits. Depending upon the application, the more efficient two-dimensional Modified Modified Read (MMR)compression method from T.6 may be selected by setting the Compression field value to 4 and then setting the first two bits (and all unused bits) of the T6Options field to 0. More information to aid the implementor in making a compression selection is contained in Section 4.5.2. Baseline TIFF also permits use of Compression=2 to specify Modified Huffman compression, but the data does not use EOLs. As a result, TIFF-F uses Compression=3 instead of Compression=2 to specify Modified Huffman compression. 4.4.5. Example Use of Page-quality Fields Here are examples for writing the CleanFaxData, BadFaxLines, and ConsecutiveBadFaxLines fields: 1. Facsimile hardware does not provide page quality information: MUST NOT write page-quality fields. 2. Facsimile hardware provides page quality information, but reports no bad lines. Write only BadFaxLines = 0. 3. Facsimile hardware provides page quality information, and reports bad lines. Write both BadFaxLines and ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or 2 if the hardware's regeneration capability is known. 4. Source image data stream is error-corrected or otherwise guaranteed to be error-free such as for a computer generated file: SHOULD NOT write page-quality fields. McIntyre, et. al. Standards Track [Page 32]  RFC 2301 File Format for Internet Fax March 1998 TIFF Writers SHOULD only generate these fields when the image has been generated from a fax image data stream where error correction, e.g. Group 3 Error Correction Mode, was not used. 4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F Files Traditionally, historical TIFF-F has required readers and writers to be able to handle multi-page TIFF-F files. Based on the experience of various TIFF-F implementors, it has been seen that the implementation of TIFF-F can be greatly simplified if certain practical guidelines are followed when writing multi-page TIFF-F files. The structure for a multi-page TIFF-F file will include one IFD per page of the document. In this case, this IFD will define the attributes for a single page. A second simplifying guideline is that the writer of TIFF-F files SHOULD present IFDs in the same order as the actual sequence of pages. (The pages are numbered within TIFF-F beginning with page 0 as the first page and then ascending (i.e. 0, 1, 2,...). However, any field values over 4 bytes will be stored separately from the IFD. TIFF-F readers SHOULD expect IFDs to be presented in page order, but be able to handle exceptions. Per [TIFF], the exact placement of image data is not specified. However, the strip offsets for each strip of image are defined from within each IFD. Where possible, another simplifying guideline for the writing of TIFF-F files is to specify that the image data for each page of a multi-page document SHOULD be contained within a single strip (i.e. one image strip per fax page). The use of a single image strip per page is very useful for applications such as store and forward messaging, where the file is usually prepared in advance of the transmission, but other assumptions may apply for the size of the image strip for applications which require the use of 'streaming' techniques (see section 4.4.7). In the event a different image strip size guideline has been used (e.g. constant size for image strips that may be less than the page size), this will immediately be evident from the values/offsets of the fields that are related to strips. A third simplifying guideline is that each IFD SHOULD be placed in the TIFF-F file structure at a point which precedes the image which the IFD describes. In addition, a fourth simplifying guideline for TIFF-F writers and readers is to place the actual image data in a physical order within the TIFF file structure which is consistent with the logical page order. In practice, TIFF-F readers will need to use the strip McIntyre, et. al. Standards Track [Page 33]  RFC 2301 File Format for Internet Fax March 1998 offsets to find the exact physical location of the image data, whether or not it is presented in logical page order. If the image data is stored in multiple strips, then the strips SHOULD occur in the file in the same order that the data they contain occurs in the facsimile transmission, starting at the top of the page. TIFF-F writers MAY make a fifth simplifying guideline, in which the IFD, the value data and the image data to which the IFD has offsets precede the next image IFD. However, this guideline has been relaxed (writers MAY rather than SHOULD use it) compared to the other guidelines given here to reflect past practices for TIFF-F. In the case of the minimal mode, which is also the minimal subset of Profile S, the SHOULD's and MAY's of these guidelines become SHALL's (see Section 3.5). So, a TIFF-F file which is structured using the guidelines of this section will essentially be composed of a linked list of IFDs, presented in ascending page order, which in turn each point to a single page of image data (one strip per page), where the pages of image data are also placed in a logical page order within the TIFF- F file structure. (The pages of image data may themselves be stored in a contiguous manner, at the option of the implementor). 4.4.7. Use of TIFF-F for Streaming Applications TIFF-F has historically been used for handling fax image files in applications such as store and forward messaging where the entire size of the file is known in advance. While TIFF-F may also possibly be used as a file format for cases such as streaming applications, assumptions may be required that differ from those provided in this section (e.g., the entire size and number of pages within the image are not known in advance). As a result, a definition for the streaming application of TIFF-F is beyond the scope of this document. 4.5. Implementation Warnings 4.5.1 Uncompressed data TIFF-F requires the ability to read and write at least one- dimensional T.4 Huffman ('compressed') data. Uncompressed data is not allowed. This means that the 'Uncompressed' bit in T4Options or T6Options must be set to 0. McIntyre, et. al. Standards Track [Page 34]  RFC 2301 File Format for Internet Fax March 1998 4.5.2. Encoding and Resolution Since two-dimensional encoding is not required for Group 3 compatibility, some historic TIFF-F readers have not been able to read such files. The minimum subset of TIFF-F REQUIRES support for one dimensional (Modified Huffman) files, so this choice maximizes portability. However, implementors seeking greater efficiency SHOULD use T.6 MMR compression when writing TIFF-F files. Some TIFF-F readers will also support two-dimensional Modified READ files. Implementors that wish to have the maximum flexibility in reading TIFF-F files should support all three of these compression methods (MH, MR and MMR). For the case of resolution, almost all facsimile products support both standard (98 dpi) vertical resolution and 'fine' (196 dpi) resolution. Therefore, fine-resolution files are quite portable in the real world. In 1993, the ITU-T added support for higher resolutions in the T.30 recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per inch based units. At the same time, support was added for metric dimensions which are equivalent to the following inch based resolutions: 391v x 204h and 391v x 408h. Therefore, the full set of inch-based equivalents of the new resolutions are supported in the TIFF-F writer, since they may appear in some image data streams received from Group 3 facsimile devices. However, many facsimile terminals and older versions of TIFF-F readers are likely to not support the use of these higher resolutions. Per [T.4], it is permissible for applications to treat the following XResolution values as being equivalent: <204,200> and <400,408>. In a similar respect, the following YResolution values may also be treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>. These equivalencies were allowed by [T.4] to permit conversions between inch and metric based facsimile terminals. In a similar respect, the optional support of metric based resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for completeness, since they are used in some legacy TIFF-F applications, but this use is not recommended for the creation of TIFF-F files by a writer. 4.5.3. EOL byte-aligned The historical convention for TIFF-F has been that all EOLs in Modified Huffman or Modified READ data must be byte-aligned. However, Baseline TIFF has permitted use of non-byte-aligned EOLs by default, so that a large percentage of TIFF-F reader implementations support McIntyre, et. al. Standards Track [Page 35]  RFC 2301 File Format for Internet Fax March 1998 both conventions. Therefore, the minimum subset of TIFF-F, or Profile S, as defined in Section 3 includes support for both byte-aligned and non- byte-aligned EOLs; see Section 3.2.2. An EOL is said to be byte-aligned when Fill bits have been added as necessary before EOL codes such that EOL always ends on a byte boundary, thus ensuring an EOL-sequence of a one byte preceded by a zero nibble: xxxx0000 00000001. Modified Huffman encoding encodes bits, not bytes. This means that the end-of-line token may end in the middle of a byte. In byte alignment, extra zero bits (Fill) are added so that the first bit of data following an EOL begins on a byte boundary. In effect, byte alignment relieves application software of the burden of bit- shifting every byte while parsing scan lines for line-oriented image manipulation (such as writing a TIFF file). For Modified READ encoding, each line is terminated by an EOL and a one bit tag bit. Per [T.4], the value of the tag bit is 0 if the next line contains two dimensional data and 1 if the next line is a reference line. To maintain byte alignment, fill bits are added before the EOL/tag bit sequence, so that the first bit of data following an MR tag bit begins on a byte boundary. 4.5.4. EOL As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded with Modified Huffman begin with an EOL, which in TIFF-F may be byte- aligned. The last line of the image is not terminated by an EOL. In a similar respect, images encoded with Modified READ two-dimensional encoding begin with an EOL, followed by a tag bit. 4.5.5. RTC Exclusion Aside from EOLs, TIFF-F files have historically only contained image data. This means that applications which wish to maintain strict conformance with the rules in [TIFF] and compatibility with historical TIFF-F, SHOULD NOT include the Return To Control sequence (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. However, applications which need to support 'transparency' of [T.4] image data MAY include RTCs if the flag settings of the T4Options field are set for non-byte aligned MH or MR image data. Implementors of TIFF readers should also be aware that there are some existing TIFF-F implementations which include the RTC sequence in MH/MR image data. Therefore, TIFF-F readers MUST be able to process files which do not include RTCs and SHOULD be able to process files which do include RTCs. McIntyre, et. al. Standards Track [Page 36]  RFC 2301 File Format for Internet Fax March 1998 4.5.6 Use of EOFB for T.6 Compressed Images TIFF-F pages which are encoded with the T.6 Modified Modified READ compression method MUST include an 'end-of-facsimile-block' (EOFB) code at the end of each coded strip. Per [TIFF], the EOFB code is followed by pad bits as needed to align on a byte boundary. TIFF readers SHOULD ignore any bits other than pad bits beyond the EOFB. 4.6. Example Use of TIFF-F The Profile F of TIFF (i.e. TIFF-F content) is a secondary component of the VPIM Message, as defined in [VPIM2]. Voice messaging systems can often handle fax store-and-forward capabilities in addition to tradi- tional voice message store-and-forward functions. As a result, TIFF-F fax messages can optionally be sent between compliant VPIM systems, and may be rejected if the recipient system cannot deal with fax. Refer to the VPIM Specification for proper usage of this content. 4.7. Extended Black-and-white Fax Mode Summary Recommended fields are shown with an asterisk *. Required fields or values are shown with a double asterisk **. If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations. +---------------------------+--------------------------------+ | Baseline Fields | Values | +---------------------------+--------------------------------+ | BitsPerSample | 1** | +---------------------------+--------------------------------+ | Compression | 3**: 1D Modified Huffman and | | | 2D Modified Read coding | | | 4: 2D Modified Modified Read | | | coding | +---------------------------+--------------------------------+ | DateTime* | {ASCII}: date/time in 24-hour | | | format 'YYYY:MM:DD HH:MM:SS' | +---------------------------+--------------------------------+ | FillOrder** | 1: most significant bit first | | | 2: least significant bit first | +------------------------------------------------------------+ McIntyre, et. al. Standards Track [Page 37]  RFC 2301 File Format for Internet Fax March 1998 +------------------------------------------------------------+ | ImageDescription* | {ASCII}: A string describing | | | the contents of the image. | +---------------------------+--------------------------------+ | ImageWidth | 1728**, 2048, 2432, 2592, | | | 3072, 3456, 3648, 4096, 4864 | +---------------------------+--------------------------------+ | ImageLength** | n: total number of scanlines | | | in image | +---------------------------+--------------------------------+ | NewSubFileType | 2**: Bit 1 identifies single | | | page of a multi-page document | +---------------------------+--------------------------------+ | Orientation | 1**-8, Default 1 | +---------------------------+--------------------------------+ | PhotometricInterpretation | 0: pixel value 1 means black | | ** | 1: pixel value 1 means white | +---------------------------+--------------------------------+ | ResolutionUnit** | 2: inch | | | 3: centimeter | +---------------------------+--------------------------------+ | RowsPerStrip** | n: number of scanlines per | | | TIFF strip | +---------------------------+--------------------------------+ | SamplesPerPixel | 1** | +---------------------------+--------------------------------+ | Software* | {ASCII}: name & release | | | number of creator software | +---------------------------+--------------------------------+ | StripByteCounts** | : number or bytes in TIFF | | | strip | +---------------------------+--------------------------------+ | StripOffsets** | : offset from beginning of | | | file to each TIFF strip | +---------------------------+--------------------------------+ | XResolution | 200, 204**, 300, 400, 408 | | | (written in pixels/inch) | +---------------------------+--------------------------------+ | YResolution | 98**, 196**, 100, | | | 200, 300, 391, 400 | | | (written in pixels/inch) | +---------------------------+--------------------------------+ | Extension Fields | +---------------------------+--------------------------------+ McIntyre, et. al. Standards Track [Page 38]  RFC 2301 File Format for Internet Fax March 1998 +---------------------------+--------------------------------+ | T4Options | 0**: required if Compression | | | is Modified Huffman, EOLs are | | | not byte aligned | | | 1: required if Compression is | | | 2D Modified Read, EOLs are | | | not byte aligned | | | 4**: required if Compression | | | is Modified Huffman, EOLs are | | | byte aligned | +---------------------------+--------------------------------+ | T4Options (continued) | 5: required if Compression | | | is 2D Modified Read, EOLs are | | | byte aligned | +---------------------------+--------------------------------+ | T6Options | 0: required if Compression is | | | 2D Modified Modified Read | +---------------------------+--------------------------------+ | DocumentName* | {ASCII}: name of scanned | | | document | +---------------------------+--------------------------------+ | PageNumber** | n,m: page number followed by | | | total page count | +---------------------------+--------------------------------+ | New Fields | +---------------------------+--------------------------------+ | BadFaxLines* | number of 'bad' scanlines | | | encountered during reception | +---------------------------+--------------------------------+ | CleanFaxData* | 0: no 'bad' lines | | | 1: 'bad' lines exist, but were | | | regenerated by receiver | | | 2: 'bad' lines exist, but have | | | not been regenerated | +---------------------------+--------------------------------+ | ConsecutiveBadFaxLines* | Max number of consecutive | | | 'bad' lines received | +---------------------------+--------------------------------+ 5. Lossless JBIG Black-and-White Fax Mode This section defines the lossless JBIG black-and-white mode or Profile J of TIFF for facsimile. Implementations of this profile are required to also implement Profile S. McIntyre, et. al. Standards Track [Page 39]  RFC 2301 File Format for Internet Fax March 1998 The previous section described the extended interchange set of TIFF fields for black-and-white fax, which provided support for the MH, MR and MMR compression of black-and-white images. This section adds a mode with JBIG compression capability. 5.1. Overview This section describes a black-and-white mode that uses JBIG compression. The ITU-T has approved the single-progression sequential mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers improved compression for halftoned originals. JBIG compression is used in accordance with the application rules given in ITU-T Rec. T.85 [T.85]. This mode is essentially the extended black-and-white mode with JBIG compression used instead of MH, MR or MMR. 5.2. Required TIFF Fields This section lists the required fields and the values they must have to be ITU-compatible. Besides the fields listed in Section 2.2.1, the extended black-and-white fax mode requires the following fields. 5.2.1. Baseline fields The TIFF fields that SHALL be used in this mode are the same as those described in Section 4.2.1 for the extended black-and-white mode, with two exceptions: the following text replaces the text in Section 4.2.1 for the Compression and FillOrder fields. Compression(259) = 9. SHORT RequiredByTIFFBaseline 9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG). This is a TIFF extension value. Default = 1 (and is not applicable; field must be specified). FillOrder(266) = 2. SHORT RequiredByTIFFBaseline 2 = Pixels are arranged within a byte such that pixels with lower column values are stored in the lower-order bits of the bytes, i.e., least significant bit first (LSB). NOTE: The JBIG coding of black-and-white image data in Profile J follows ITU-T Rec. T.85 [T.85], which specifies LSB first ordering within a byte. Note that Baseline TIFF readers are only required to support MSB first ordering or FillOrder = 1. 5.2.2. Extension fields McIntyre, et. al. Standards Track [Page 40]  RFC 2301 File Format for Internet Fax March 1998 Same fields as those in Section 2.2.1. 5.2.3. New fields None. 5.3. Recommended TIFF Fields See Section 2.2.3 and 2.2.4. 5.4. Lossless JBIG Black-and-white Fax Mode Summary Recommended fields are shown with an asterisk *. Required fields or values are shown with a double asterisk **. If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations. +---------------------------+--------------------------------+ | Baseline Fields | Values | +---------------------------+--------------------------------+ | BitsPerSample | 1** | +---------------------------+--------------------------------+ | Compression | 9**: JBIG coding | +---------------------------+--------------------------------+ | DateTime* | {ASCII}: date/time in 24-hour | | | format 'YYYY:MM:DD HH:MM:SS' | +---------------------------+--------------------------------+ | FillOrder** | 1: most significant bit first | | | 2: least significant bit first | +---------------------------+--------------------------------+ | ImageDescription* | {ASCII}: A string describing | | | the contents of the image. | +---------------------------+--------------------------------+ | ImageWidth | 1728**, 2048, 2432, 2592, | | | 3072, 3456, 3648, 4096, 4864 | +---------------------------+--------------------------------+ | ImageLength** | n: total number of scanlines | | | in image | +---------------------------+--------------------------------+ | NewSubFileType** | 2: Bit 1 identifies single | | | page of a multi-page document | +---------------------------+--------------------------------+ | Orientation | 1**-8, Default 1 | +------------------------------------------------------------+ McIntyre, et. al. Standards Track [Page 41]  RFC 2301 File Format for Internet Fax March 1998 +---------------------------+--------------------------------+ | PhotometricInterpretation | 0: pixel value 1 means black | | ** | 1: pixel value 1 means white | +---------------------------+--------------------------------+ | ResolutionUnit** | 2: inch | | | 3: centimeter | +---------------------------+--------------------------------+ | RowsPerStrip** | n: number of scanlines per | | | TIFF strip | +---------------------------+--------------------------------+ | SamplesPerPixel** | 1 | +---------------------------+--------------------------------+ | Software* | {ASCII}: name & release | | | number of creator software | +---------------------------+--------------------------------+ | StripByteCounts** | : number of bytes in TIFF | | | strip | +---------------------------+--------------------------------+ | StripOffsets** | : offset from beginning of | | | file to each TIFF strip | +---------------------------+--------------------------------+ | XResolution | 200, 204**, 300, 400, 408 | | | (written in pixels/inch) | +---------------------------+--------------------------------+ | YResolution | 98**, 196**, 100, | | | 200, 300, 391, 400 | | | (written in pixels/inch) | +---------------------------+--------------------------------+ | Extension Fields | +---------------------------+--------------------------------+ | DocumentName* | {ASCII}: name of document | | | scanned | +---------------------------+--------------------------------+ | PageNumber** | n,m: page number followed by | | | total page count | +---------------------------+--------------------------------+ | New Fields | +---------------------------+--------------------------------+ | GlobalParametersIFD* | IFD: global parameters IFD | +---------------------------+--------------------------------+ | ProfileType* | n: type of data stored in file | +---------------------------+--------------------------------+ | FaxProfile* | n: ITU-compatible fax mode | +---------------------------+--------------------------------+ | CodingMethods* | n: compression algorithms used | | | in file | +---------------------------+--------------------------------+ McIntyre, et. al. Standards Track [Page 42]  RFC 2301 File Format for Internet Fax March 1998 6. Base Color Fax Mode 6.1. Overview This section defines the lossy color mode or Profile C of TIFF for facsimile. Implementations of this profile are required to also implement Profile S. This is the base mode for color and grayscale facsimile, which means that all applications that support color fax must support this mode. The basic approach is the lossy JPEG compression [T.4, Annex E; T.81] of L*a*b* color data [T.42]. Grayscale applications use the L* lightness component; color applications use the L*, a* and b* components. This mode uses a new PhotometricInterpretation field value to describe the L*a*b* encoding specified in [T.42]. This encoding differs in two ways from the other L*a*b* encodi