diff options
Diffstat (limited to 'doc/rfc/rfc2306.txt')
| -rw-r--r-- | doc/rfc/rfc2306.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2306.txt b/doc/rfc/rfc2306.txt new file mode 100644 index 0000000..a93c6c0 --- /dev/null +++ b/doc/rfc/rfc2306.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group G. Parsons +Request for Comments: 2306 Northern Telecom +Category: Informational J. Rafferty + Human Communications + March 1998 + + + Tag Image File Format (TIFF) - F Profile for Facsimile + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Overview + + This document describes in detail the definition of TIFF-F that is + used to store facsimile images. The TIFF-F encoding has been + folklore with no standard reference definition before this document. + +Internet Fax Working Group + + This document is a product of the IETF Internet Fax Working Group. + All comments on this document should be forwarded to the email + distribution list at <ietf-fax@imc.org>. + +1. Abstract + + This document references the Tag Image File Format (TIFF) to define + the F profile of TIFF for facsimile (TIFF-F) as a file format that + may be used for the storage and interchange of facsimile images. + +2. TIFF Definition + + TIFF (Tag Image File Format) Revision 6.0 is defined in detail within + [TIFF]. + + A brief review of concepts used in TIFF is included in this document + as background information, but the reader is directed to the original + TIFF specification [TIFF] to obtain specific technical details. + + + + + +Parsons & Rafferty Informational [Page 1] + +RFC 2306 TIFF-F Profile March 1998 + + +2.1 Baseline TIFF and Applications + + TIFF provides a method to describe and store raster image data. A + primary goal of TIFF is to provide a rich environment within which + implementations can exchange image data. [TIFF] characterizes + Baseline TIFF as being the core of TIFF, the essentials that all + mainstream TIFF developers should support in their products. + Applications of TIFF are defined by using Baseline TIFF as a starting + point and then defining "extensions" to TIFF that are used for the + specific "application", as well as specifying any other differences + from Baseline TIFF. + +3. TIFF-F Definition + +3.1 Introduction + + Though it has been in common usage for many years, TIFF-F has + previously never been documented in the form of a standard. An + informal TIFF-F document was originally created by a small group of + fax experts led by Joe Campbell. The existence of TIFF-F is noted in + [TIFF] but it is not defined. This document defines the F + application of [TIFF]. For ease of reference, the term TIFF-F will be + used throughout this document as a shorthand for "F Profile of TIFF + for Facsimile". TIFF-F files are intended for use with the + image/tiff MIME media content-type which includes support for the + "application" parameter (e.g., application=faxbw). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [REQ]. + + 3.1.1 TIFF-F Historical Background + + Up until TIFF 6.0, TIFF supported various "Classes" which defined the + use of TIFF for various applications. Classes were used to support + specific applications and in this spirit, TIFF-F has been known + historically as "TIFF Class F". Previous informal TIFF-F documents + used the "Class F" terminology. + + As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in + favor of the concept of Baseline TIFF. Therefore, this document + updates the definition of TIFF-F as the F profile of TIFF for + facsimile, by using Baseline TIFF as defined in [TIFF] as the + starting point and then defining the differences from Baseline TIFF + which apply for TIFF-F. In almost all cases, the resulting + definition of TIFF-F fields and values remains consistent with those + used historically in earlier definitions of TIFF Class F. Where some + + + + +Parsons & Rafferty Informational [Page 2] + +RFC 2306 TIFF-F Profile March 1998 + + + of the values for fields have been updated to provide more precise + conformance with the ITU-T [T.4] and [T.30] fax recommendations, + these differences are noted. + +3.1.2 Overview + + The intent of this specification is to document: + + 1) The fields and values which are applicable for this F profile + of TIFF for facsimile. + 2) A minimum set of TIFF-F fields and values which should be able + to interwork with virtually all historic TIFF-F readers. + 3) A broader range of values for the traditional TIFF-F fields + that will provide support for the most widely used facsimile + compressions, page sizes and resolutions, consistent with the + ITU-T [T.4] and [T.30] recommendations. + + The structure of the TIFF-F definition will be as follows. A brief + review of the structure of TIFF files and practical guidelines for + the writing and reading of multi-page TIFF-F files is provided in + sections 3.1.3 and 3.1.4. + + A review of TIFF-F fields follows. Section 3.2 reviews the fields + from Baseline TIFF that are applicable for black and white (bi- + level) images and are also used by TIFF-F. + + Section 3.3 reviews the other required TIFF-F fields. Several fields + that are specific extensions for TIFF-F are reviewed in section + 3.4. There are also fields that may be helpful, but are not + required. These recommended fields are listed in the section 3.5. + Section 3.6 defines the requirements for the minimum subset of TIFF-F + fields and values to maximize interoperability. Several technical + topics, including implementation issues and warnings are discussed in + subsequent sections. Finally, section 3.9 introduces the TIFF-F + Reader and Writer. A table of the required and recommended fields + for a TIFF-F Reader is provided, along with details on the permitted + set of values. + +3.1.3 Structure of TIFF Files + + The structure of TIFF files is specified within [TIFF]. In this + section, a short summary of the TIFF structure is included for the + informational purposes. In addition, some practical guidelines for + the use of this structure in reading and writing TIFF-F files are + addressed in the following section 3.1.4. The structure for writing + "minimum subset" TIFF-F files is defined in section 3.6.2. + + + + + +Parsons & Rafferty Informational [Page 3] + +RFC 2306 TIFF-F Profile March 1998 + + + A TIFF file begins with an 8-byte image file header that defines the + byte order used within a file (see section 3.9.1), includes a magic + number sequence that identifies the content as a TIFF file, and then + uses an offset to point to the first Image File Directory (IFD). An + IFD is a sequence of tagged fields, sorted in ascending order (by tag + value), that contains attributes of an image and pointers to the + image data. TIFF fields (also called entries) contain a tag, its + type (e.g. short, long, rational, etc.), a count (which indicates the + number of values/offsets) and a value/offset. However, the actual + value for the field will only be present if it fits into 4 bytes; + otherwise, an offset will be used to point to the location of the + data associated with the field. In turn, this offset may itself be + used to point to an array of offsets. + + For the case of facsimile data, many documents consist of a series of + multiple pages. Within TIFF, these may be represented using more + than one IFD within the TIFF file. Each IFD defines a subfile whose + type is given in the NewSubfileType field. For the case of facsimile + data that is placed in a TIFF-F file, each facsimile page in a + multi-page document has its own IFD. For bi- level facsimile files, + multiple IFDs are organized as a linked list, with the last entry in + each IFD pointing to the next IFD (the pointer in the last IFD is 0). + (There is also another technique for organizing multiple IFDs as a + tree, that uses the SubIFDs field, but this technique is not + applicable for TIFF-F images.) Within each IFD, the location of the + related image data is defined by using fields that are associated + with strips. These fields identify the size of strips (in rows), the + number of bytes per strip after compression and a strip offset, which + is used to point to the actual location of the image strip. + + TIFF has a very flexible file structure, but the use of some + practical guidelines for implementors when writing multi-page TIFF- + F files can produce TIFF structures which are easier for readers to + process. This is especially for implementations in environments + such as facsimile terminals where a complex file structure is + difficult to support. + +3.1.4 Practical Guidelines for Writing/Reading Multi-Page TIFF-F Files + + Traditionally, historical TIFF-F has required readers and writers to + be able to handle multi-page TIFF-F files. Based on the experience + of various TIFF-F implementors, it has been seen that the + implementation of TIFF-F can be greatly simplified if certain + practical guidelines are followed when writing multi-page TIFF-F + files. However, for interchange robustness, TIFF-F readers SHOULD be + prepared to read TIFF files whose structure is consistent with + [TIFF], which supports a more flexible file structure than is + recommended here. + + + +Parsons & Rafferty Informational [Page 4] + +RFC 2306 TIFF-F Profile March 1998 + + + The structure for a multi-page TIFF-F file will include one IFD per + page of the document. Therefore, each IFD will define the + attributes for a single page. For simplicity, the writer of TIFF- F + files SHOULD present IFDs in the same order as the actual sequence of + pages. (The pages are numbered within TIFF-F beginning with page 0 + as the first page and then ascending (i.e. 0, 1, 2,...). However, as + noted in section 3.1.3, any field values over 4 bytes will be stored + separately from the IFD. TIFF-F readers SHOULD expect IFDs to be + presented in page order, but be able to handle exceptions. + + Per [TIFF], the exact placement of image data is not specified. + However, the strip offsets for each strip of image are defined from + within each IFD. Where possible, a second simplifying assumption + for the writing of TIFF-F files is to specify that the image data for + each page of a multi-page document SHOULD be contained within a + single strip (i.e. one image strip per fax page). The use of a + single image strip per page is very useful for implementations such + as store and forward messaging, where the file is usually prepared in + advance of the transmission, but other assumptions may apply for the + size of the image strip for implementations which require the use of + "streaming" techniques (see section 3.7.6). In the event a different + image strip size assumption has been used (e.g. constant size for + image strips which may be less than the page size), this will + immediately be evident from the values/offsets of the fields that are + related to strips. From the TIFF-F reader standpoint, one image + strip per page permits the image data to be found through reference + via a single offset, resulting in a much simplified image structure + and faster processing. + + A third simplifying assumption is that each IFD SHOULD be placed in + the TIFF-F file structure at a point which precedes the image which + the IFD describes. If any long field values are present (see section + 3.1.3) then these SHOULD be placed after their referencing IFD and + before the image data they describe. + + A fourth simplifying assumption for TIFF-F writers and readers is to + place the actual image data in a physical order within the TIFF file + structure which is consistent with the logical page order. In + practice, TIFF-F readers will need to use the strip offsets to find + the exact physical location of the image data, whether or not it is + presented in logical page order. + + TIFF-F writers MAY make a fifth simplifying assumption, in which the + IFD, the value data and the image data for which the IFD has offsets + precede the next image IFD. These elements MUST precede the next + image IFD in the minimum set TIFF-F files (see section 3.6.2). + However, this principle has been relaxed in the case of TIFF-F to + reflect past practices. + + + +Parsons & Rafferty Informational [Page 5] + +RFC 2306 TIFF-F Profile March 1998 + + + So, a TIFF-F file which is structured using the guidelines of this + section will essentially be composed of a linked list of IFDs, + presented in ascending page order, which in turn each point to a + single page of image data (one strip per page), where the pages of + image data are also placed in a logical page order within the TIFF-F + file structure. (The pages of image data may themselves be stored in + a contiguous manner, at the option of the implementor). + +3.2 Baseline TIFF Required Fields for BiLevel Images + + Baseline TIFF per [TIFF] requires that the following fields be + present for all BiLevel Images: ImageWidth, ImageLength, + Compression, PhotometricInterpretation, StripOffsets, RowsPerStrip, + StripByteCounts, XResolution, YResolution and ResolutionUnit. TIFF-F + uses all of these fields, but in some cases specifies a different + range of acceptable values than Baseline TIFF. Per [TIFF], if + fields are omitted, the Baseline TIFF default value(if specified) + will apply. + + In the field definitions which follow in this section and subsequent + sections, the fields will be presented in the following form: + + Fieldname (tag-number) = values (if applicable). TYPE + + A brief summary of the Baseline TIFF fields and their use in TIFF-F + follows: + + ImageWidth(256) = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096, + 4864. + SHORT or LONG. These are the fixed page widths in pixels. The + permissible values are dependent upon X and Y resolutions as + shown in sections 2 and 3 of [T.4] and reproduced here for + convenience: + + XResolution x Yresolution | ImageWidth + --------------------------------------------|------------------ + 204x98, 204x196, 204x391, 200x100, 200x200 | 1728, 2048, 2432 + 300x300 | 2592, 3072, 3648 + 408x391, 400x400 | 3456, 4096, 4864 + --------------------------------------------|------------------ + + Historical TIFF-F did not include support for the following + widths related to higher resolutions: 2592, 3072, 3648, 3456, + 4096 and 4864. Historical TIFF-F documents also included the + following values related to A5 and A6 widths: 816 and 1216. Per + the most recent version of [T.4], A5 and A6 documents are no + + + + + +Parsons & Rafferty Informational [Page 6] + +RFC 2306 TIFF-F Profile March 1998 + + + longer supported in Group 3 facsimile, so the related width + values are now obsolete. See section 3.8.2 for more information + on inch/metric equivalencies and other implementation details. + + ImageLength (257). SHORT or LONG. LONG recommended. + The total number of scan lines in the image. + + Compression (259) = 3,4. SHORT. + This is a required TIFF-F field. The permitted values for TIFF- + F purposes are 3 and 4 as shown. The default value per Baseline + TIFF is 1 (Uncompressed), but this value is invalid for facsimile + images. Baseline TIFF also permits use of value 2 (Modified + Huffman encoding), but the data is presented in a form which does + not contain EOLs. Instead, TIFF-F specifies the value 3 for + encoding one-dimensional T.4 Modified Huffman or 2-dimensional + Modified READ data. The detailed settings which apply for T.4 + encoded data are specified using the T4Options field. TIFF-F + also permits use of the value 4 for the compression field, which + indicates that the data is coded using a [T.6] compression method + (i.e the Modified Modified READ two-dimensional method). The + detailed settings which apply for T.6 encoded data are specified + using the T6Options field. + + Please refer to the definitions of the T4Options and T6Options + fields in section 3.3, and section 3.8 for more information on + the encoding of images and conventions used within TIFF-F. + + PhotometricInterpretation (260) = 0,1. SHORT. + This field allows notation of an inverted ("negative") image: + 0 = normal + 1 = inverted + + StripOffsets (273). SHORT or LONG. + For each strip, the offset of that strip. The offset is measured + from the beginning of the file. If a page is expressed as one + large strip, there is one such entry per page. + + RowsPerStrip (278). SHORT or LONG. LONG recommended. + The number of scan lines per strip. When a page is expressed as + one large strip, this is the same as the ImageLength field. + + StripByteCounts (279). LONG or SHORT. LONG recommended. + For each strip, the number of bytes in that strip. If a page is + expressed as one large strip, this is the total number of bytes + in the page after compression. Note that the choice of LONG or + SHORT depends upon the size of the strip. + + + + + +Parsons & Rafferty Informational [Page 7] + +RFC 2306 TIFF-F Profile March 1998 + + + ResolutionUnit (296) = 2,3. SHORT. + The units of measure for resolution: + 2 = Inch + 3 = Centimeter + + TIFF-F has traditionally used inch based measures. + + XResolution (282) = 204, 200, 300, 400, 408 (inches). RATIONAL. + The horizontal resolution of the TIFF-F image expressed in pixels + per resolution unit. 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 77 + (cm). See section 3.8.2 for more information on inch/metric + equivalencies and other implementation details. + + YResolution (283) = 98, 196, 100, 200, 300, 391, 400 (inches). + RATIONAL. + The vertical resolution of the TIFF-F image expressed in pixels + per resolution unit. 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, 38.5 (cm). See section 3.8.2 for more information + on inch/metric equivalencies and other implementation details. + +3.3 TIFF-F Required Fields + + In addition to the Baseline TIFF fields, there are additional + required fields for TIFF-F. A review of the additional required + fields for TIFF-F follows: + + BitsPerSample (258) = 1. SHORT. + Since TIFF-F is only used for black-and-white facsimile images, + the value is 1 (the default) for all files. + + FillOrder (266) = 1, 2. SHORT. + TIFF 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. + + NewSubFileType (254)= (Bit 1 = 1). LONG. + This field is made up of 32 flag bits. Unused bits are + expected to be 0 and bit 0 is the low order bit. Bit 0 is set + to 0 for TIFF-F. Bit 1 is always set to 1 for TIFF-F, + indicating a single page of a multi-page image. The same bit + + + + + +Parsons & Rafferty Informational [Page 8] + +RFC 2306 TIFF-F Profile March 1998 + + + settings are used when TIFF-F is used for a one page fax image. + See sections 3.1.1 and 3.1.2 for more details on the structure + of multi-page TIFF-F image files. + + PageNumber (297). SHORT/SHORT. + This field specifies the page numbers in the fax document. The + field comprises two SHORT values: the first value is the page + number, the second is the total number of pages. Single-page + documents therefore use 0000/0001 hex. If the second value is + 0, the total number of pages in the document is not available. + + SamplesPerPixel (277) = 1. SHORT. + The value of 1 denotes a bi-level, grayscale, or palette color + image. + + There is also a requirement to include either the T4Options or the + T6Options field in a TIFF-F IFD, depending upon the setting of the + Compression field. These fields are defined in the next section on + TIFF extensions. + +3.4 TIFF-F Extensions + + These are fields which are extensions beyond the required TIFF-F + fields. The following fields have been defined as extensions in + [TIFF]. + + T4Options (292) (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1). LONG. + This field is required if the value for the compression field + has been set to 3. The values are set as shown below for TIFF- + F. For TIFF-F, uncompressed data is not allowed and EOLs MAY + be byte aligned (see section 3.8.3). + bit 0 = 0 for 1-Dimensional, 1 for 2-Dimensional (MR) + bit 1 = must be 0 (uncompressed data not allowed) + bit 2 = 0 for non-byte-aligned EOLs or 1 for byte- + aligned EOLs + + This field is made up of a set of 32 flag bits. Unused bits + must be set to 0. Bit 0 is the low order bit. Please note + that T4Options was known as G3Options in earlier versions of + TIFF and TIFF-F. The data in a TIFF-F image encoded using + one of the T.4 methods is not terminated with an RTC (see + section 3.8.5). + + T6Options (293) = (Bit 0 = 0, Bit 1 = 0) LONG. + This field is required for TIFF-F if value of the compression + field has been set to 4. The value for this field is made up of + a set of 32 flag bits. Setting bit 0 to 0 indicates that the + data is compressed using the Modified Modified READ (MMR) two- + + + +Parsons & Rafferty Informational [Page 9] + +RFC 2306 TIFF-F Profile March 1998 + + + dimensional compression method. 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 3.8.6). Uncompressed data is not + applicable for bi-level facsimile images, so that bit 1 must be + set to 0. Unused bits must be set to 0. Bit 0 is the low-order + bit. The default value is 0 (all bits 0). + bit 0 = 0 for 2-Dimensional + bit 1 = must be 0 (uncompressed data not allowed) + + In earlier versions of TIFF, this field was named Group4Options. + The significance has not changed and the present definition is + compatible. + + In addition, three new fields, defined as TIFF-F extensions, + describe page quality. The information contained in these fields + is usually obtained from receiving facsimile hardware (if + applicable). These fields are optional. 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 implementations 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 "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 + This field reports the number of scan lines with an incorrect + number of pixels encountered by the facsimile during reception + (but not necessarily in the file). + + Note: PercentBad = (BadFaxLines/ImageLength) * 100 + + CleanFaxData (327). SHORT + N = + 0 = Data contains no lines with incorrect pixel counts or + regenerated lines (i.e., computer generated) + 1 = Lines with an incorrect pixel count were regenerated by + receiving device + + + + + +Parsons & Rafferty Informational [Page 10] + +RFC 2306 TIFF-F Profile March 1998 + + + 2 = Lines with an incorrect pixel count are in the data and + were not regenerated by receiving device (i.e. data + contains bad scan lines) + + 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. + This field reports the maximum number of consecutive lines + containing an incorrect number of pixels encountered by the + facsimile device during reception (but not necessarily in the + file). + + The BadFaxLines and ImageLength data indicate only the quantity + of such lines. The ConsecutiveBadFaxLines field is an + indicator of their distribution and may therefore be a better + general indicator of perceived image quality. + +3.5 Recommended Fields + + hese are fields that MAY be used in encoding TIFF-F files, but are + ptional in nature and may be ignored by many TIFF readers. These + ields are called recommended consistent with historical TIFF-F + ractice. + + BadFaxLines (326) [defined in section 3.4] + + CleanFaxData (327) [defined in section 3.4] + + ConsecutiveBadFaxLines (328) [defined in section 3.4] + + DateTime (306). ASCII. + Date and time in the format YYYY:MM:DD HH:MM:SS, in 24-hour + format. String length including NUL byte is 20 bytes. Space + between DD and HH. + + DocumentName (269). ASCII. + This is the name of the document from which the document was + scanned. + + + +Parsons & Rafferty Informational [Page 11] + +RFC 2306 TIFF-F Profile March 1998 + + + + ImageDescription (270). ASCII. + This is an ASCII string describing the contents of the image. + + Orientation (274). SHORT. + This field is designated as "Recommended" for consistency with + historical TIFF-F, but is also a Baseline TIFF field with a + default value of 1 per [TIFF]. The default value of 1 applies + if the field is omitted, but for clarity, TIFF-F writers SHOULD + include this field. This field might be useful for displayers + that always want to show the same orientation, regardless of + the image. The default value of 1 is "0th row is visual top of + image, and 0th column is the visual left." An 180-degree + rotation is 3. See [TIFF] for an explanation of other values. + + Software (305). ASCII. + The optional name and release number of the software package + that created the image. + +3.6 Requirements for TIFF-F Minimum Subset + + This section defines the requirements for a minimum subset of TIFF-F + fields and values that all TIFF-F readers SHOULD support to maximize + interoperability with current and historical TIFF-F implementations. + The TIFF-F structure for writing minimum subset files is also + defined. + +3.6.1 Summary of Minimum Subset Fields and Values + + A summary of the minimum subset TIFF-F fields and values is provided + in the following table. The required fields for the minimum subset + are shown under the column labeled "Field". The values for these + fields in the minimum subset are shown under the column labeled + "Minimum". + + Field | Minimum | Comment + ------------------|--------------|------------------------------- + BitsPerSample | 1 |one bit per sample + Compression | 3 |3 for T.4 (MH) + FillOrder | 2 |LSB first + ImageWidth | 1728 | + ImageLength | |required + NewSubFileType | Bit 1 = 1 |single page of multipage file + PageNumber | X/X |pg/tot, 0 base, tot in 1st IFD + PhotometricInterp | 0 |0 is white + ResolutionUnit | 2 |inches (default) + RowsPerStrip |=ImageLength | + SamplesPerPixel | 1 |one sample per pixel + + + +Parsons & Rafferty Informational [Page 12] + +RFC 2306 TIFF-F Profile March 1998 + + + StripByteCounts | |required + StripOffsets | |required + T4Options | Bit 0 = 0 |MH + | Bit 1 = 0 | + | Bit 2 = 0,1 |Non-Byte-aligned, + | | Byte-Aligned EOLs + XResolution | 204 |Units is per inch + YResolution | 196,98 |Units is per inch + ------------------|--------------|------------------------------ + +3.6.2 TIFF-F Minimum Subset File Structure + + For implementations which need to write minimum subset TIFF-F files, + the file structure shown in Figure 3.1 MUST be used: + + +-----------------------+ + | 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 + +-----------------------+ + | : | + | : | + + Figure 3.1 TIFF-F Minimum Subset File Structure + + As depicted in Figure 3.1, the IFD of each page precedes the related + Image Data for that page. If present, any long field values appear + between the IFD and the image data for that page. For multiple page + documents, each IFD/image pair is immediately followed by the next + IFD/image pair in logical page order within the file structure, until + all pages have been defined. + + + + +Parsons & Rafferty Informational [Page 13] + +RFC 2306 TIFF-F Profile March 1998 + + + The format for the TIFF Header is as defined in [TIFF]. When writing + TIFF-F minimum subset files, the value for the byte order in the + Header SHOULD be II (0x4949, denoting that the bytes in the TIFF file + are in LSB first (little-endian) order. + + This results in a TIFF header whose content is as shown in Figure + 3.2. + + | Offset | Description | Type | Value | + +--------+-------------------+--------+--------------------+ + | 0 | Byte Order | Short | 0x4949 (II) | + +--------+-------------------+--------+--------------------+ + | 2 | Version | Short | 42 | + +--------+-------------------+--------+--------------------+ + | 4 | Offset of 0th IFD | Long | 0x 0000 0008 | + +--------+-------------------+--------+--------------------+ + + Figure 3.2: Image File Header for Minimum Subset TIFF-F Files + + 3.7 Technical Implementation Issues + +3.7.1 Strips + + Those new to TIFF may not be familiar with the concept of "strips" + embodied in the three fields RowsPerStrip, StripByteCount, + StripOffsets. + + In general, third-party implementations that read and write TIFF + files expect the image to be divided into "strips," also known as + "bands." Each strip contains a few lines of the image. By using + 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 dimensions of a strip are described by the RowsPerStrip and + StripByteCount fields. The location in the TIFF file of each strip + is contained in the StripOffsets field. + + The size of TIFF-F strips is application dependent. The recommended + approach for multi-page TIFF-F images is to represent each page as a + single strip. + + + + + + + + + + +Parsons & Rafferty Informational [Page 14] + +RFC 2306 TIFF-F Profile March 1998 + + +3.7.2 Bit Order + + The default bit order in Baseline TIFF per [TIFF] is indicated by + FillOrder=1, where bits are not reversed before being stored. + However, TIFF-F 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). + + Facsimile data appears on the phone line in bit-reversed order + relative to its description in CCITT Recommendation T.4. Therefore, + a wide majority of facsimile implementations choose this natural + order for storage. Nevertheless, TIFF-F readers must be able to read + data in both bit orders. + +3.7.3 Multi-Page + + Many existing implementations 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. + +3.7.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 defines a one-dimensional compression method known as + Modified Huffman (MH) and a two-dimensional method known as Modified + READ (MR) (READ is short for Relative Element Address Designate). In + 1984, a somewhat more efficient compression method known as Modified + Modified READ (MMR) was defined in the T.6 recommendation. It 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 permits three different compression methods. In the most + common practice, the one-dimensional compression method (Modified + Huffman) is used. This is specified by setting the value of the + Compression field to 3 and then setting bit 0 of the T4Options field + to 0. Alternatively, the two dimensional Modified READ method (which + is much less frequently used in historical TIFF-F implementations) + may be selected by setting bit 0 to a value of 1. + + Optionally, depending upon the implementation requirements, the more + efficient two-dimensional compression method from T.6 (i.e. MMR or + "Group 4 compression") may be selected. This method is selected by + + + + +Parsons & Rafferty Informational [Page 15] + +RFC 2306 TIFF-F Profile March 1998 + + + setting the value of the Compression field to 4 and then setting the + value of the first two bits (and all unused bits) of T6options to 0. + More information to aid the implementer in making a compression + selection is contained in section 3.8 on Implementation Warnings. + +3.7.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. + +3.7.6 Use of TIFF-F for Streaming Applications + + TIFF-F has historically been used for handling fax image files in + implementations 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, + different assumptions may be required than those provided in this + document (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. + +3.7.7 TIFF-F Export and Import + + Fax implementations that do not wish to support TIFF-F as a native + format may elect to support it as import/export medium. + + Export + + It is recommended that implementations 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. + + + + +Parsons & Rafferty Informational [Page 16] + +RFC 2306 TIFF-F Profile March 1998 + + + Import + + A TIFF-F reader MUST be able to handle a TIFF-F file containing + multiple pages. + +3.8 Implementation Warnings + + 3.8.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. + +3.8.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, implementers 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. + Implementers 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 implementations to treat the + following XResolution values as being equivalent: <204,200> and + <400,408>. In a similar respect, the following YResolution values + + + + + +Parsons & Rafferty Informational [Page 17] + +RFC 2306 TIFF-F Profile March 1998 + + + 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 + implementations, but this use is not recommended for the creation of + TIFF-F files by a writer. + +3.8.3 EOL byte-aligned + + The historical convention for TIFF-F has been that all EOLs in + Modified Huffman or Modified READ data must be byte-aligned. + However, Baseline TIFF has permitted use of non-byte-aligned EOLs by + default, so that a large percentage of TIFF-F reader implementations + support both conventions. Therefore, the minimum subset of TIFF-F + as defined in this document includes support for both byte-aligned + and non-byte-aligned EOLs. + + 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. + +3.8.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. + + + + +Parsons & Rafferty Informational [Page 18] + +RFC 2306 TIFF-F Profile March 1998 + + +3.8.5 RTC Exclusion + + Aside from EOLs, TIFF-F files have historically only contained image + data. This means that implementations 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, implementations which need to support "transparency" of + [T.4] image data MAY include RTCs when writing TIFF-F files 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. + +3.8.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. + +3.9 TIFF-F Fields Summary + + Implementations may choose to implement a TIFF-F Reader, TIFF-F + Writer or both, depending upon application requirements. The TIFF- F + Reader is typically used to read an existing TIFF-F file which + resides on a computer or peripheral device. The TIFF-F Writer is + typically used to convert a bi-level image bit stream into a TIFF-F + compliant file. For many Internet applications, only the Reader needs + to be implemented. The specific field support required for TIFF-F + Readers and Writers is summarized below. + +3.9.1 TIFF Reader + + The fields in the following table are specified for a TIFF-F Reader. + The range of values for required and recommended fields are as shown. + The minimum subset of values are also shown. If required fields are + omitted in a TIFF-F file, the Baseline TIFF default value will apply. + Image data must not have any coding errors. In the table, certain + fields have a value that is a sequence of flag bits (e.g. T4Options). + An implementation should test the setting of the relevant flag bits + individually to allow extensions to the sequence of flag bits to be + appropriately ignored. + + + + + +Parsons & Rafferty Informational [Page 19] + +RFC 2306 TIFF-F Profile March 1998 + + + As noted within [TIFF], a TIFF file begins with an 8-byte image file + header, of which the first two bytes (0-1) contain the byte order + within the file. The permissible values are: + + II- Byte order from least significant byte to the most + significant byte (little-endian) + MM - byte order is always from most significant to least + significant (big-endian) + + For a TIFF-F Reader, the legal values are: + + ByteOrder: MM,II (Either byte order is allowed) + +3.9.1.1 Fields for TIFF-F Reader + + Recommended Fields in the table are shown with an asterisk (*). + + Other fields may be present, but they should be of an informational + nature, so that a reader can elect to ignore them. + + Informational fields which are often present in TIFF-F images are: + Software, Datetime, BadFaxLines, CleanFaxData and + ConsecutiveBadFaxLines. + + Field | Values | Minimum | Comment + ------------------|-------------|-------------|---------------------- + BitsPerSample | 1 | 1 |one bit per sample + Compression | 3,4 | 3 |3 for T.4 (MH, MR) + | | |4 for T.6 - MMR + FillOrder | 2,1 | 2 |LSB first or MSB first + ImageWidth | 1728, 2048, | 1728 |depends on XResolution + | 2432, 2592, | | + | 3072, 3648, | | + | 3456, 4096, | | + | 4864 | | + ImageLength | >0 | |required + NewSubFileType | Bit 1 = 1 | Bit 1 = 1 |single page of + | | |multipage file + Orientation * | 1 | |1st row=top left, + | | | 1st col=top + PageNumber | X/X | 0/1 |pg/tot, 0 base, + | | | tot in 1st IFD + PhotometricInterp | 0,1 | 0 |0 is white + ResolutionUnit | 2,3 | 2 |inches (default) + RowsPerStrip |=ImageLength |=ImageLength | + | or other | | + SamplesPerPixel | 1 | 1 |one sample per pixel + StripByteCounts | >0 | |required + + + +Parsons & Rafferty Informational [Page 20] + +RFC 2306 TIFF-F Profile March 1998 + + + StripOffsets | >0 | |required + T4Options | Bit 0 = 0,1 | Bit 0 = 0 |MH,MR(incl if not MMR) + | Bit 1 = 0 | Bit 1 = 0 | + | Bit 2 = 0,1 | Bit 2 = 0,1 | Non-Byte-aligned and + | | | Byte-Aligned EOLs + T6Options | 0 | |MMR (incl only if MMR) + XResolution | 204,200,300,| 204 | If unit is per inch + | 400,408, | | + | 77 | | If unit is per cm + YResolution | 196,98,100, | 196,98 | If unit is per inch + | 200,300,391,| | + | 400, | | + | 77,38.5 | | If unit is per cm + ------------------|-------------|-------------|---------------------- + +3.9.2 TIFF-F Writer + + For the case of writing (creating) a TIFF-F file format from an image + data stream or other raster data, implementations SHOULD write files + which can be read by a TIFF-F Reader as defined in 3.9.1. It is + recommended that all fields from the table in 3.9.1.1 SHOULD be + included when writing TIFF-F files in order to minimize dependencies + on default values. Image data must not have any coding errors. + + Other fields may be present, but they should be of an informational + nature, so that a Reader may elect to ignore them. + + For the case of writing "minimum subset" TIFF-F files, the rules + defined in section 3.6 apply. + + Informational fields that may be useful for TIFF-F files are: + Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines + + TIFF Writers SHOULD only generate the fields that describe facsimile + image quality 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. These fields are: CleanFaxData, BadFaxLines and + ConsecutiveBadFaxLines. + +4. MIME sub-type image/tiff + + [TIFFREG] describes the registration of the MIME content-type image/ + tiff to refer to TIFF 6.0 encoded image data. When transported by + MIME, the TIFF content defined by this document must be encoded + within an image/tiff content type. In addition, an optional + "application" parameter is defined for image/tiff to identify a + particular application's subset of TIFF and TIFF extensions for the + + + + +Parsons & Rafferty Informational [Page 21] + +RFC 2306 TIFF-F Profile March 1998 + + + encoded image data, if it is known. Typically, this would be used to + assist the recipient in dispatching a suitable rendering package to + handle the display or processing of the image file. + +4.1 Refinement of MIME sub-type image/tiff for Application F + + Since this document defines a facsimile specific profile of TIFF, it + is useful to note an appropriate application parameter for the + image/tiff MIME content-type. + + The "faxbw" application parameter is defined for black and white + facsimile. It is suitable for use by applications that can process + one or more TIFF for facsimile profiles or subsets used for the + encoding of black and white facsimile data. + + Since this document defines a profile of TIFF for facsimile which is + suitable for use with black and white facsimile image data, + applications which use this profile or its minimum subset should set + the value of the application parameter to "faxbw". + + An example of the use of the image/tiff MIME Content-type with the + application parameter set with the value "faxbw" follows: + + Example: + + Content-type: image/tiff; application=faxbw + + In this example, use of this parameter value will enable applications + to identify the content as being within a profile or subset of TIFF + for Facsimile that is suitable for encoding black and white image + data, before attempting to process the image data. + +5. Implementation Usage + + 5.1 Internet Fax Usage + + The usage of TIFF-F is envisioned as a component of Internet Fax. It + is anticipated that Internet Fax may use both a TIFF-F Reader and + TIFF-F Writer. The details of the Internet Fax services and their use + of TIFF-F will be specified in other documents. + +5.2 VPIM Usage + + The Application 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 traditional voice message store-and- forward functions. + + + + +Parsons & Rafferty Informational [Page 22] + +RFC 2306 TIFF-F Profile March 1998 + + + 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. + +6. Security Considerations + + This document describes the encoding for TIFF-F, which is a profile + of the TIFF encoding for facsimile. As such, it does not create any + security issues not already identified in [TIFFREG], in its use of + fields as defined in [TIFF]. There are also new TIFF fields defined + within this specification, but they are of a purely descriptive + nature, so that no new security risks are incurred. + + Further, the encoding specified in this document does not in any way + preclude the use of any Internet security protocol to encrypt, + authenticate, or non-repudiate TIFF-F encoded facsimile messages. + +7. Authors' Addresses + + Glenn W. Parsons + Northern Telecom + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + Phone: +1-613-763-7582 + Fax: +1-613-763-2697 + Email: Glenn.Parsons@Nortel.ca + + James Rafferty + Human Communications + 12 Kevin Drive + Danbury, CT 06811-2901 + USA + Phone: +1-203-746-4367 + Fax: +1-203-746-4367 + Email: Jrafferty@worldnet.att.net + +8. References + + [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Four: Registration Procedures", RFC 2048, + November 1996. + + + + +Parsons & Rafferty Informational [Page 23] + +RFC 2306 TIFF-F Profile March 1998 + + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + [T.30] ITU-T Recommendation T.30 - "Procedures for Document + Facsimile Transmission in the General Switched Telephone + Network", June, 1996 + [T.4] ITU-T Recommendation T.4 - "Standardization of Group 3 + Facsimile Apparatus for Document Transmission", June, 1996 + [T.6] ITU-T Recommendation T.6 - "Facsimile Coding Schemes and + Coding Control Functions for Group 4 Facsimile Apparatus", + March, 1993 + [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - + Final, June 3, 1992. + [TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File + Format (TIFF) - image/tiff: MIME Sub-type Registration ", RFC + 2302, March 1998. + [VPIM2] G. Vaudreuil and G. Parsons, "Voice Profile for Internet + Mail - version 2", Work In Progress, <draft-ema-vpim-06.txt>, + November 1997. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Parsons & Rafferty Informational [Page 24] + +RFC 2306 TIFF-F Profile March 1998 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Parsons & Rafferty Informational [Page 25] + |