idnits 2.17.1 draft-ietf-fax-tiff-fx-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 47) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 79 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 247 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1127 has weird spacing: '...y after the I...' == Line 1274 has weird spacing: '...ost all cases...' == Line 1275 has weird spacing: '...remains consi...' == Line 1737 has weird spacing: '...olution and "...' == Line 2190 has weird spacing: '...alue is mappe...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7286 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3220 -- Looks like a reference, but probably isn't: '1' on line 3221 -- Looks like a reference, but probably isn't: '2' on line 2885 -- Looks like a reference, but probably isn't: '3' on line 2891 -- Looks like a reference, but probably isn't: '4' on line 2306 -- Looks like a reference, but probably isn't: '5' on line 2307 -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF-F0' -- Possible downref: Non-RFC (?) normative reference: ref. 'TTN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'TTN2' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF-FX-REG' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Buckley 2 Fax Working Group Xerox Corporation 3 May 26, 2004 D. Venable 4 draft-ietf-fax-tiff-fx-14.txt Xerox Corporation 5 L. McIntyre 6 G. Parsons 7 Nortel Networks 8 J. Rafferty 9 Brooktrout 10 May 2004 12 File Format for Internet Fax 14 Status of this Memo: 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 32 The list of Internet-Draft Shadow Directories can be accessed at 33 . 35 A version of this document is intended for submission to the 36 RFC editor as a Draft Standard for the Internet Community. 37 Discussion and suggestions for improvement are requested. 39 Copyright Notice 41 Copyright (C) The Internet Society 2003. All Rights Reserved. 43 Abstract 45 This document is a revised version of RFC 2301. 46 The revisions, summarized in the list attached as Annex B to this 47 document, are based on the discussions and suggestions for 48 improvements that have been made since RFC 2301 was issued in March 49 1998, and on the results of independent implementations and 50 interoperability testing. 52 This RFC 2301 revision describes the TIFF (Tag Image File Format) 53 representation of image data specified by the ITU-T Recommendations 54 for black-and-white and color facsimile. This file format 55 specification is commonly known as TIFF-FX. It formally defines 56 minimal, extended and lossless JBIG profiles (Profiles S, F, J) for 57 black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster 58 Content profiles (Profiles C, L, M) for color and grayscale fax. 59 These profiles correspond to the content of the applicable ITU-T 60 Recommendations. 62 Table of Contents 64 1. INTRODUCTION........................................................4 65 1.1. Scope..........................................................5 66 1.2. Approach.......................................................5 67 1.3. Overview of this document......................................5 68 1.4. IPR Notification...............................................7 69 2. TIFF and Fax........................................................7 70 2.1. TIFF Overview..................................................7 71 2.1.1. File Structure.............................................7 72 2.1.2. Image Structure............................................9 73 2.1.3. TIFF File Structure for Fax Applications..................10 74 2.2 TIFF Fields for All Fax Applications...........................11 75 2.2.1. TIFF Fields required for all fax profiles.................12 76 2.2.2. Additional TIFF Fields required for all fax profiles......13 77 2.2.3. TIFF Fields recommended for all fax profiles..............15 78 2.2.4. New TIFF Fields recommended for fax profiles..............16 79 3. Profile S - Minimal Black-and-White Fax Profile....................18 80 3.1. Overview......................................................18 81 3.2. Required TIFF Fields..........................................18 82 3.2.1 Baseline Fields............................................18 83 3.2.2 Extension Fields...........................................20 84 3.2.3 New Fields.................................................20 85 3.3. Recommended TIFF Fields.......................................20 86 3.4. End of Line (EOL) and Return to Control (RTC).................20 87 3.4.1 RTC Exclusion..............................................21 88 3.5. File Structure................................................22 89 3.6. Profile S - Minimal Black-and-White Profile Summary...........23 90 4. Profile F- Extended Black-and-White Fax Profile....................24 91 4.1. TIFF-F Overview...............................................25 92 4.2. Required TIFF Fields..........................................26 93 4.2.1. Baseline Fields...........................................26 94 4.2.2. Extension Fields..........................................28 95 4.2.3. New Fields................................................29 96 4.3. Recommended TIFF Fields.......................................29 97 4.3.1. Baseline Fields...........................................29 98 4.3.2. Extension Fields..........................................29 99 4.3.3. New Fields................................................29 100 4.4. Technical Implementation Issues...............................30 101 4.4.1. Strips....................................................30 102 4.4.2. Bit Order.................................................31 103 4.4.3. Multi-Page................................................31 104 4.4.4. Compression...............................................31 105 4.4.5. Example Use of Page-quality Fields........................32 106 4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F 107 Files..............................................33 108 4.4.7. Use of TIFF-F for Streaming Applications..................34 109 4.5. Implementation Warnings.......................................34 110 4.5.1. Uncompressed Data.........................................34 111 4.5.2. Encoding and Resolution...................................35 112 4.5.3. EOL byte-aligned..........................................35 113 4.5.4. EOL.......................................................36 114 4.5.5. RTC Exclusion.............................................36 115 4.5.6. Use of EOFB for T.6 Compressed Images.....................37 116 4.6. Example Use of TIFF-F.........................................37 117 4.7. Profile F - Extended Black-and-white Fax Profile Summary......37 118 5. Profile J - Lossless JBIG Black-and-White Fax Profile..............39 119 5.1. Overview......................................................40 120 5.2. Required TIFF Fields..........................................40 121 5.2.1. Baseline Fields...........................................40 122 5.2.2. Extension Fields..........................................40 123 5.2.3. New Fields................................................40 124 5.3. Recommended TIFF Fields.......................................41 125 5.4. Profile J - Lossless JBIG Black-and-White Profile Summary.....41 126 6. Profile C - Base Color Fax Profile.................................43 127 6.1. Overview......................................................43 128 6.2. Required TIFF Fields..........................................43 129 6.2.1. Baseline Fields...........................................43 130 6.2.2. Extension Fields..........................................45 131 6.2.3. New Fields................................................46 132 6.3. Recommended TIFF Fields.......................................47 133 6.4. Profile C - Base Color Fax Profile Summary....................47 134 7. Profile L - Lossless Color Profile.................................49 135 7.1. Overview......................................................50 136 7.1.1. Color Encoding............................................50 137 7.1.2. JBIG Compression..........................................50 138 7.2. Required TIFF Fields..........................................51 139 7.2.1. Baseline Fields...........................................51 140 7.2.2. Extension Fields..........................................52 141 7.2.3. New Fields................................................53 142 7.3. Recommended TIFF Fields.......................................53 143 7.4. Profile L - Lossless Color Fax Profile Summary................53 144 8. Profile M - Mixed Raster Content Profile...........................55 145 8.1 Overview.......................................................55 146 8.1.1. MRC 3-layer model.........................................55 147 8.1.2. A TIFF Representation for the MRC 3-layer model...........57 148 8.2. Required TIFF Fields..........................................59 149 8.2.1. Baseline Fields...........................................59 150 8.2.2. Extension Fields..........................................60 151 8.2.3. New Fields................................................61 152 8.3. Recommended TIFF Fields.......................................63 153 8.4. Rules and Requirements for Images.............................64 154 8.5. Profile M - MRC Fax Profile Summary...........................65 155 9. MIME content-types image/tiff and image/tiff-fx....................68 156 10. Security Considerations...........................................69 157 11. References........................................................69 158 12. Authors' Addresses................................................71 159 Annex A: Summary of TIFF Fields for Internet Fax .....................72 160 Annex B. List of technical edits to RFC2301...........................77 161 Full Copyright Statement..............................................78 163 1. Introduction 165 This document describes the use of TIFF (Tag Image File Format) to 166 represent the data content and structure generated by the current 167 suite of ITU-T Recommendations for Group 3 facsimile. These 168 Recommendations and the TIFF fields described here support the 169 following facsimile profiles: 171 S: minimal black-and-white profile, using binary MH compression 172 [T.4] 173 F: extended black-and-white profile, using binary MH, MR and MMR 174 compression [T.4, T.6] 175 J: lossless JBIG black-and-white profile, with JBIG compression 176 [T.85, T.82] 177 C: lossy color and grayscale profile, using JPEG compression 178 [T.42, T.81] 179 L: lossless color and grayscale profile, using JBIG compression 180 [T.43, T.82] 181 M: mixed raster content profile [T.44], using a combination of 182 existing compression methods 184 Each profile corresponds to the content of ITU-T Recommendations 185 shown and is a subset of the full TIFF for facsimile specification. 187 Profile S describes a minimal interchange set of fields, which will 188 guarantee that, at least, binary black-and-white images will be 189 supported. Implementations are required to support this minimal 190 interchange set of fields. 192 With the intent of specifying a file format for Internet Fax, this 193 document: 195 1. specifies the structure of TIFF files for facsimile data, 196 2. defines ITU fax-compatible values for existing TIFF fields, 197 3. defines new TIFF fields and values required for compatibility 198 with ITU color fax. 200 This specification of TIFF for facsimile is known as TIFF-FX (TIFF 201 for Fax eXtended). References to the format described by this 202 specification should always use the term "TIFF-FX", and some profiles 203 in this specification may not be interpreted correctly by other TIFF 204 applications. 206 1.1 Scope 208 This document defines a TIFF-based file format specification for 209 enabling standardized messaging-based fax over the Internet. It 210 specifies the TIFF fields and field values required for compatibility 211 with the existing ITU-T Recommendations for Group 3 black-and-white, 212 grayscale and color facsimile. TIFF has historically been used for 213 handling fax image files in applications such as store-and-forward 214 messaging. Implementations that support this file format 215 specification for import/export may elect to support it as a native 216 format. This document recommends a TIFF file structure that is 217 compatible with low-memory and page-level streaming implementations. 219 Unless otherwise noted, the current TIFF specification [TIFF] and 220 selected TIFF Technical Notes [TTN1, TTN2] are the primary references 221 for describing TIFF and defining TIFF fields. This document is the 222 primary reference for defining TIFF field values for fax 223 applications. 225 1.2 Approach 227 The basic approach to using TIFF for facsimile data is to insert the 228 compressed fax image data in a TIFF file and use TIFF fields to 229 encode the parameters that describe the image data. These fields will 230 have values that comply with the ITU-T Recommendations. 232 This approach takes advantage of TIFF features and structures that 233 bridge the data formats and performance requirements of both legacy 234 fax machines and host-based fax applications. TIFF constructs for 235 pages, images, and strips allow a TIFF file to preserve the fax data 236 stream structure and the performance advantages that come with it. A 237 TIFF-based approach also builds on an established base of users and 238 implementors and ensures backward compatibility with existing TIFF- 239 based IETF proposals and work in progress for Internet fax. 241 1.3 Overview of this document 243 Section 2 gives an overview of TIFF. Section 2.1 describes the 244 structure of TIFF files, including general guidelines for structuring 245 multi-page TIFF files. Section 2.2 lists the TIFF fields that are 246 required or recommended for all fax profiles. The TIFF fields used 247 only by specific fax profiles are described in Sections 3-8, which 248 describe the individual fax profiles. These sections also specify the 249 ITU-compatible field values (image parameters) for each profile. 251 The full set of permitted fields of TIFF for facsimile are included 252 in the current TIFF specification, Section 2 of this document and the 253 sections on specific profiles of facsimile operation. This document 254 defines profiles of TIFF for facsimile, where a profile is a subset 255 of the full set of permitted fields and field values of TIFF for 256 facsimile. 258 Section 3 defines the minimal black-and-white facsimile profile 259 (Profile S), which is required in all implementations. Section 4 260 defines the extended black-and-white fax profile (Profile F), which 261 provides a standard definition of TIFF-F. Section 5 describes the 262 lossless black-and-white profile using JBIG compression (Profile J). 264 Section 6 defines the base color profile, required in all color 265 implementations, for the lossy JPEG representation of color and 266 grayscale facsimile data (Profile C). Section 7 defines the lossless 268 JBIG color and grayscale facsimile profile(Profile L) and Section 8 269 defines the Mixed Raster Content facsimile profile(Profile M). Each 270 of these sections concludes with a table summarizing the required and 271 recommended fields for each profile and the values they can have. 273 Section 9 refers to the MIME content types used in connection 274 with TIFF for facsimile. Sections 10, 11, 12 and 13 give Security 275 Considerations, the ISOC Copyright Notice, References and Authors' 276 Addresses. Annex A gives a summary of the TIFF fields used or defined 277 in this document and provides a convenient reference for implementors. 279 To implement only the minimal interchange black-and-white set of 280 fields and values (Profile S), one need read only Sections 1, 2, 3, 9 281 and 10. 283 The following tree diagram shows the relationship among profiles and 284 between profiles and coding methods. 286 S (MH) 287 / \ 288 B&W / \ Color 289 ------------ ---------- 290 / \ \ 291 / F (MH, MR, MMR) C (JPEG) 292 / / \ 293 J (JBIG) ---- \ 294 / \ 295 L (JBIG) \ 296 \ 297 M (MRC) 299 A profile is based on a collection of ITU-T facsimile coding methods. 300 For example, Profile S, the minimal profile, is based on Modified 301 Huffman (MH) compression, which is defined in ITU-T Rec. T.4. 302 Profile F specifies Modified Huffman (MH), Modified Read (MR) and 303 Modified Modified Read (MMR) compressions, which are defined in ITU-T 304 Rec. T.4 and T.6. 306 All implementations of TIFF for facsimile MUST implement Profile S, 307 which is the root node of the tree. All color implementations of TIFF 308 for facsimile MUST implement Profile C. The implementation of a 309 particular profile MUST also implement those profiles on the path 310 that connect it to the root node, and MAY optionally implement 311 profiles not on the path connecting it to the root node. For example, 312 an implementation of Profile M must also implement Profiles C and S, 313 and may optionally implement Profile F, J or L. For another example, 314 an implementation of Profile C must also implement Profile S, and may 315 optionally implement Profile F or J. 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 319 document are to be interpreted as described in [REQ]. 321 1.4 IPR Notification 323 The IETF has been notified of intellectual property rights claimed in 324 regard to some or all of the specification contained in this 325 document. For more information consult the online list of claimed 326 rights in . 328 2. TIFF and Fax 330 2.1. TIFF Overview 332 TIFF provides a means for describing, storing and interchanging 333 raster image data. A primary goal of TIFF is to provide a rich 334 environment within which applications can exchange image data. The 335 current TIFF specification [TIFF] defines a commonly used, core set 336 of TIFF fields known as Baseline TIFF. The current specification, 337 the set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical 338 Note 2 [TTN2] define several TIFF extensions. The TIFF- based 339 specification for fax applications uses a subset of Baseline TIFF 340 fields, with selected extensions, as described in this document. In 341 a few cases, this document defines new TIFF fields specifically for 342 fax applications. 344 2.1.1. File Structure 346 TIFF is designed for raster images, which makes it a good match for 347 facsimile documents, which are multi-page raster images. Each raster 348 image consists of a number of rows or scanlines, each of which has 349 the same number of pixels, the unit of sampling. Each pixel has at 350 least one sample or component (exactly one for black-and-white 351 images). 353 A TIFF file begins with an 8-byte image file header. The first two 354 bytes describe the byte order used within the file. Legal values are 355 "II" (0x4949) when bytes are ordered from least to most significant 356 (little- endian), and "MM" (0x4D4D), when bytes are ordered from most 357 to least significant (big-endian) within a 16- or 32-bit integer. 358 Either byte order can be used, except in the case of the minimal 359 black-and-white profile, which SHALL use value "II". The next two 360 bytes contain the value 42 that identifies the file as a TIFF file 361 and is ordered according to the value in the first two bytes of the 362 header. The last four bytes give the offset that points to the first 363 image file directory (IFD). This and all other offsets in a TIFF file 364 are with respect to the beginning of the TIFF file. An IFD can be at 365 any location in the file after the header but must begin on a word 366 boundary. 368 An IFD is a sequence of tagged fields, sorted in ascending order by 369 tag value. An IFD consists of a 2-byte count of the number of fields, 370 a sequence of field entries and a 4-byte offset to the next IFD. The 371 fields contain information about the image and pointers to the image 372 data. Each separate raster image in the file is represented by an 373 IFD. 375 Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag, 376 2 bytes identifying the field type (e.g. short, long, rational, 377 ASCII), 4 bytes giving the count (number of values or offsets), and 4 378 bytes that either contain the offset to a field value stored outside 379 the IFD, or, based on the type and count, the field value itself. 380 Resolution and metadata such as dates, names and descriptions are 381 examples of "long" field values that do not fit in 4 bytes and 382 therefore use offsets in the field entry. Details are given in the 383 TIFF specification [TIFF]. 385 A TIFF file can contain more than one IFD, where each IFD is a 386 subfile whose type is given in the NewSubfileType field. Multiple 387 IFDs can be organized either as a linked list, with the last entry in 388 each IFD pointing to the next IFD (the pointer in the last IFD is 0), 389 or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The 390 SubIFDs field contains an array of pointers to child IFDs of the 391 primary IFD. 393 Child IFDs describe related images, such as reduced resolution 394 versions of the primary IFD image. The same IFD can point both to a 395 next IFD and to child IFDs, and child IFDs can themselves point to 396 other IFDs. 398 All fax profiles represent a multi-page fax image as a linked list of 399 IFDs, with a NewSubfileType field containing a bit that identifies 400 the IFD as one page of a multi-page document. Each IFD has a 401 PageNumber field, identifying the page number in ascending order, 402 starting at 0 for the first page. While a Baseline TIFF reader is not 403 required to read any IFDs beyond the first, an implementation that 404 reads the files that comply with this specification SHALL read 405 multiple IFDs. Only the Mixed Raster Content fax profile, described 406 in Section 8, requires the use of child IFDs. 408 The following figure illustrates the structure of a multi-page TIFF 409 file. 411 +-----------------------+ 412 | Header |------------+ 413 +-----------------------+ | First IFD 414 | IFD (page 0) |<-----------+ Offset 415 +---| |------------+ 416 Value | +-----------------------+ | 417 Offset +-->| Long Values |--+ | 418 +-----------------------| | Strip | 419 | Image Data |<-+ Offset | 420 | strip 1 page 0 | | | 421 +-----------------------+ | | 422 | : | : | 423 | 424 +-----------------------+ | Next IFD 425 | IFD (page 1) |<-----------+ Offset 426 +---| |------------+ 427 Value | +-----------------------+ | 428 Offset +-->| Long Values |--+ | 429 +-----------------------| | Strip | 430 | Image Data |<-+ Offset | 431 | strip 1 page 1 | | | 432 +-----------------------+ | | 433 | strip 2 page 1 |<-+ | 434 +-----------------------+ | | 435 | : | : | 436 | 437 +-----------------------+ | Next IFD 438 | IFD (page 2) |<-----------+ Offset 439 | : | 441 2.1.2 Image Structure 443 An IFD stores an image as one or more strips, as shown in the 444 preceding figure. A strip consists of 1 or more scanlines (rows) of 445 raster image data in compressed form. An image may be stored in a 446 single strip or may be divided into several strips, which would 447 require less memory to buffer. (Baseline TIFF recommends about 8k 448 bytes per strip, but existing fax usage is typically one strip per 449 image.) 450 Each IFD requires three strip-related fields: StripOffsets, 451 RowsPerStrip and StripByteCounts. The StripOffsets field is an array 452 of pointers to the strip or strips that contain the actual image 453 data. The StripByteCounts field gives the number of bytes in each 454 strip after compression. TIFF requires that each strip, except the 455 last, contain the same number of scanlines, which is given in the 456 RowsPerStrip field. This document introduces the new StripRowCounts 457 field that allows a variable number of scanlines per strip, which is 458 required by the Mixed Raster Content fax profile (Section 8). 460 Image data is stored as uninterpreted, compressed image data streams 461 within a strip. The formats of these streams follow the ITU-T 462 Recommendations. The Compression field in the IFD indicates the type 463 of compression, and other TIFF fields in the IFD describe image 464 attributes, such as color encoding and spatial resolution. 465 Compression parameters are stored in the compressed data stream, 466 rather than in TIFF fields. This makes the TIFF representation and 467 compressed data format specification independent of each another. 468 This approach, modeled on [TTN2], allows TIFF to gracefully add new 469 compression schemes as they become available. 471 Some attributes can be specified both in the compressed data stream 472 and within a TIFF field. It is possible that the two values will 473 differ. When this happens for values required to interpret the data 474 stream, then the values in the data stream take precedence. For 475 informational values that are not required to interpret the data 476 stream, such as author name, then the TIFF field value takes 477 precedence. 479 2.1.3 TIFF File Structure for Fax Applications 481 The TIFF specification has a very flexible file structure, which does 482 not specify the ordering of IFDs, field values and image data in a 483 file. Individual applications may require or recommend an ordering. 485 This specification recommends that when using a TIFF file for 486 facsimile, a multi-page fax document SHOULD be represented as a 487 linked list of IFDs. It also recommends that a TIFF file for 488 facsimile SHOULD order pages in a TIFF file in the same way that they 489 are ordered in a fax data stream. In a TIFF file, a page consists of 490 several elements: one or more IFDs (including subIFDs), long field 491 values that are stored outside the IFDs, and image data (in one or 492 more strips). 494 The minimal black-and-white profile (Profile S) specifies a required 495 ordering of pages and elements within a page (Section 3.5). The 496 extended black-and-white profile (Profile F) provides guidelines for 497 ordering pages and page elements (Section 4.4.6). Other profiles 498 SHOULD follow these guidelines. This recommendation is intended to 499 simplify the implementation of TIFF writers and readers in fax 500 applications and the conversion between TIFF file and fax data stream 501 representations. However, for interchange robustness, readers SHOULD 502 be prepared to read TIFF files whose structure is consistent with 503 [TIFF], which supports a more flexible file structure than is 504 recommended here. 506 This specification introduces an optional new GlobalParametersIFD 507 field, defined in Section 2.2.4. This field has type IFD and 508 indicates parameters describing the fax session. While it is often 509 possible to obtain these parameters by scanning the file, it is 510 convenient to make them available together in one place for fast and 511 easy access. If the GlobalParametersIFD occurs in a TIFF file, it 512 SHOULD be located in the first IFD, immediately following the 8-byte 513 image file header. 515 2.2 TIFF Fields for All Fax Applications 517 The TIFF specification [TIFF] is organized as a baseline set and 518 several extensions, including technical notes [TTN1, TTN2] that will 519 be incorporated in the next release of TIFF. The baseline and 520 extensions have required and optional fields. 522 Facsimile applications require (and recommend) a mixture of baseline 523 and extensions fields, as well as some new fields that are not part 524 of the TIFF specification and that are defined in this document. This 525 sub- section lists the fields that are required or recommended for 526 all profiles. In particular, Section 2.2.1 lists the fields that are 527 required by all profiles and that have values that do not depend on 528 the profile. Section 2.2.2 lists the fields that are required by all 530 profiles and that have values which do depend on the profile. Section 531 2.2.3 lists the fields that are recommended for all profiles. Fields 533 that are required or recommended by some but not all profiles are 534 given in the section (Section 3-8) that describes that profile. The 535 sections for each fax profile have sub-sections for required and 536 recommended fields; each sub-section organizes the fields according 537 to whether they are baseline, extension or new. 539 The fields required for facsimile have only a few legal values, 540 specified in the ITU-T Recommendations. Of these legal values, some 541 are required and some are optional, just as they are required 542 (mandatory) or optional in fax implementations that conform to the 543 ITU-T Recommendations. The required and optional values are noted in 544 the sections on the different fax profiles. 546 This section describes the fields required or recommended by all fax 547 profiles. The pattern for the description of TIFF fields in this 548 document is: 550 FieldName(TagValueInDecimal) = allowable values. 551 TYPE 552 WhetherRequiredByTIFForTIFFforFAX 553 Count = (omitted if =1) = (if not in current spec but available) 554 Explanation of the field, how it's used, and the values it can have. 555 Default value, if any, as specified in [TIFF] 557 When a field's default value is the desired value, that field may be 558 omitted from the relevant IFD unless specifically required by the 559 text of this specification. 561 2.2.1. TIFF fields required for all fax profiles 563 The TIFF fields listed in this section SHALL be used by all fax 564 profiles, but have field values that are not specified by the ITU 565 standards, i.e. the fields do not depend on the profile. The next 566 sub-section lists the fields that SHALL be used by all fax profiles, 568 but which do have values specified by the ITU-specified or profile- 569 specific values. Fields that SHALL be used by some but not all 570 profiles are given in the sections (3-8) which describe the profiles 571 that uses them. 573 ImageLength(257) SHORT or 574 LONG 575 RequiredByTIFFBaseline 576 Total number of scanlines in image. 577 No default, must be specified. 579 PageNumber(297) 580 SHORT 581 RequiredByTIFFforFAX, TIFFExtension 582 Count = 2 583 The first number represents the page number (0 for the first page); 584 the second number is the total number of pages in the document. If 585 the second value is 0, then the total page count is not available. 586 No default, must be specified 588 RowsPerStrip(278) SHORT or 589 LONG 590 RequiredByTIFFBaseline 591 The number of scanlines per TIFF strip, except for the last strip. 592 For a single strip image, this is the same as the value of the 593 ImageLength field. 594 Default = 2**32 - 1 (meaning all scanlines in one strip) 596 StripByteCounts(279) SHORT or 597 LONG 598 RequiredByTIFFBaseline 599 Count = number of strips 600 For each strip, the number of bytes in that strip after compression. 602 No default, must be specified. 604 StripOffsets(273) SHORT or 605 LONG 606 RequiredByTIFFBaseline 607 Count = number of strips 608 For each strip, the byte offset from the beginning of the file to 609 the start of that strip. 610 No default, must be specified. 612 2.2.2 Additional TIFF fields required for all fax profiles 614 The TIFF fields listed in this section SHALL be used by all fax 615 profiles, but the values associated with them depend on the profile 616 being described and the associated ITU Recommendations. Therefore, 617 only the fields are defined here; the values applicable to a 618 particular fax profile are described in Sections 3-8. Fields that 619 SHALL be used by some but not all profiles are given in the section 620 (3-8) describing the profile that uses them. 622 BitsPerSample(258) 623 SHORT 624 RequiredByTIFFBaseline 625 Number of bits per image sample 626 Default = 1 (field may be omitted if this is the value) 628 Compression(259) 629 SHORT 630 RequiredByTIFFBaseline 631 Compression method used for image data 632 Default = 1 (no compression, so may not be omitted for FAX) 634 FillOrder(266) 635 SHORT 636 RequiredByTIFFforFax 637 The default bit order in Baseline TIFF per [TIFF] is indicated by 638 FillOrder=1, where bits are not reversed before being stored. 639 However, TIFF for Fax typically utilizes the setting of 640 FillOrder=2, 641 where the bit order within bytes is reversed before storage (i.e., 642 bits are stored with the Least Significant Bit first). 643 Default = 1 (field may be omitted if this is the value) 644 Facsimile data appears on the phone line in bit-reversed order 645 relative to its description in the relevant ITU compression 646 Recommendation. Therefore, a wide majority of facsimile 647 implementations choose this natural order for storage. 648 Nevertheless, 649 all readers conforming to this specification must be able to read 650 data in both bit orders, except in the case of Profile S, which only 651 requires support for FillOrder=2 (Least Significant Bit first). 653 ImageWidth(256) SHORT or 654 LONG 655 RequiredByTIFFBaseline 656 The number of pixels (columns) per scanline (row) of the image 657 No default, must be specified. 659 NewSubFileType(254) 660 LONG 661 RequiredByTIFFforFAX 662 A general indication of the kind of data contained in this IFD 663 Bit 1 is 1 if the image is a single page of a multi-page document. 664 Default = 0 (no subfile bits on, so may not be omitted for FAX) 666 PhotometricInterpretation(262) 667 SHORT 668 RequiredByTIFFBaseline 669 The color space of the image data 670 No default, must be specified 672 ResolutionUnit(296) 673 SHORT 674 RequiredByTIFFBaseline 675 The unit of measure for resolution. 2 = inch, 3 = centimeter; 676 Default = 2 (field may be omitted if this is the value) 678 SamplesPerPixel(277) 679 SHORT 680 RequiredByTIFFBaseline 681 The number of color components per pixel; SamplesPerPixel is 1 for a 682 black-and-white, grayscale or indexed (palette) image. 683 Default =1 (field may be omitted if this is the value) 685 XResolution(282) 686 RATIONAL 687 RequiredByTIFFBaseline 688 The horizontal resolution of the image in pixels per resolution 689 unit. The ITU-T Recommendations for facsimile specify a small number 690 of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and 691 80, 160 pixels per centimeter (or 204, 408 pixels per inch). The 692 allowed XResolution values for each profile are given in the section 693 defining that profile. Per [T.4], it is permissible for applications 694 to treat the following XResolution values as being equivalent: <204, 695 200> and <400,408> in pixels/inch. These equivalencies were allowed 696 by [T.4] to permit conversions between inch and metric based 697 facsimile terminals. To insure interoperability, if an application 698 accepts any member of the pairs then T.4 requires it to accept both 700 (e.g. accept 204 if 200 pixels per inch is accepted). TIFF for 701 Facsimile Writers SHOULD express XResolution in inch based units, 702 for consistency with historical practice and to maximize 703 interoperability. See the table below for information on how to 704 convert from an ITU-T metric value to its inch based equivalent 705 resolution. 706 No default, must be specified 708 YResolution(283) 709 RATIONAL 710 RequiredByTIFFBaseline 711 The vertical resolution of the image in pixels per resolution unit. 712 The ITU-T Recommendations for facsimile specify a small number of 713 vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5, 714 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The 715 allowed YResolution values for each profile are given in the section 716 defining that profile. Per [T.4], it is permissible for applications 717 to treat the following YResolution values as being equivalent: <98, 718 100>, <196, 200>, and <391, 400> in pixels/inch. These equivalencies 719 were allowed by [T.4] to permit conversions between inch and metric 720 based facsimile terminals. To insure interoperability, if an 721 application accepts any member of the pairs then T.4 requires it to 722 accept both (e.g. accept 98 if 100 pixels per inch is accepted). 723 TIFF for Facsimile Writers SHOULD express YResolution in inch based 724 units, for consistency with historical practice and to maximize 725 interoperability. See the table below for information on converting 726 from the metric value to its inch based equivalent resolution. 727 No default, must be specified 729 +-----------------------------+-----------------------------+ 730 | XResolution | YResolution | 731 +--------------+--------------+--------------+--------------+ 732 |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit| 733 | =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) | 734 +--------------+--------------+--------------+--------------+ 735 | 100 | | 100 | | 736 +--------------+--------------+--------------+--------------+ 737 | 204 | 80 | 98 | 38.5 | 738 | 200 | | 100 | | 739 +--------------+--------------+--------------+--------------+ 740 | 204 | 80 | 196 | 77 | 741 | 200 | | 200 | | 742 +--------------+--------------+--------------+--------------+ 743 | 204 | 80 | 391 | 154 | 744 +--------------+--------------+--------------+--------------+ 745 | 300 | | 300 | | 746 +--------------+--------------+--------------+--------------+ 747 | 408 | 160 | 391 | 154 | 748 | 400 | | 400 | | 749 +--------------+--------------+--------------+--------------+ 751 2.2.3 TIFF fields recommended for all fax profiles 753 The TIFF fields listed in this section MAY be used by all fax 754 profiles. However, Profile S writers (the minimal fax profile 755 described in Section 3) SHOULD NOT use these fields. Recommended 756 fields that are profile-specific are described in Sections 3-8. 758 DateTime(306) 759 ASCII 760 OptionalInTIFFBaseline 761 Date/time of image creation in 24-hour format "YYYY:MM:DD HH:MM:SS". 762 No default. 764 DocumentName(269) 765 ASCII 766 OptionalInTIFFExtension(DocumentStorageAndRetrieval) 767 The name of the scanned document. This is a TIFF extension field, 768 not a Baseline TIFF field. 769 No default. 771 ImageDescription(270) 772 ASCII 773 OptionalInTIFFBaseline 774 A string describing the contents of the image. 775 No default. 777 Orientation(274) = 1-8. 778 SHORT 779 OptionalinTIFFBaseline 780 1: 0th row represents the visual top of the image; the 0th column 781 represents the visual left side of the image. See the current TIFF 782 spec [TIFF] for further values; Baseline TIFF only requires 783 value=1. 784 Default = 1. 785 Note: It is recommended that a writer that is aware of the 786 orientation include this field to give a positive indication of 787 the orientation, even if the value is the default. Writers should 788 not generate mirror images, because many readers will not properly 789 reverse the image before display or print. 791 Software(305) 792 ASCII 793 OptionalInTIFFBaseline 794 The name and release number of the software package that 795 created the image. 796 No default. 798 2.2.4 New TIFF fields recommended for fax profiles 800 The new TIFF fields listed in this section MAY be used by all fax 801 profiles. However, Profile S writes (the minimal fax profile 802 described in Section 3) SHOULD NOT use these fields. In addition, 803 support for these new TIFF fields has not been included in historical 804 TIFF-F readers described in Section 4 and [TIFF-F]. These fields 805 describe "global" parameters of the fax session that created the image 806 data. They are optional, not part of the current TIFF specification, 807 and are defined in this document. 809 The first new field, GlobalParametersIFD, is an IFD that contains 810 global parameters and is located in a Primary IFD. 812 GlobalParametersIFD (400) IFD or 813 LONG 814 An IFD containing global parameters. It is recommended that a TIFF 815 writer place this field in the first IFD, where a TIFF reader would 816 find it quickly. 818 Each field in the GlobalParametersIFD is a TIFF field that is legal 819 in any IFD. Required baseline fields should not be located in the 820 GlobalParametersIFD, but should be in each image IFD. If a conflict 821 exists between fields in the GlobalParametersIFD and in the image 822 IFDs, then the data in the image IFD shall prevail. 824 Among the GlobalParametersIFD entries is a new ProfileType field 825 which generally describes information in this IFD and in the TIFF 826 file. 828 ProfileType(401) 829 LONG 830 The type of image data stored in this IFD. 831 0 = Unspecified 832 1 = Group 3 fax 833 No default 835 The following new global fields are defined in this document as IFD 836 entries for use with fax applications. 838 FaxProfile(402) = 0 - 6. 839 BYTE 840 The profile that applies to this file; a profile is subset of the 841 full set of permitted fields and field values of TIFF for facsimile. 842 The currently defined values are: 843 0: does not conform to a profile defined for TIFF for facsimile 844 1: minimal black & white lossless, Profile S 845 2: extended black & white lossless, Profile F 846 3: lossless JBIG black & white, Profile J 847 4: lossy color and grayscale, Profile C 848 5: lossless color and grayscale, Profile L 849 6: Mixed Raster Content, Profile M 851 CodingMethods(403) 852 LONG 853 This field indicates which coding methods are used in the file. A 854 value of 1 in a bit location indicates the corresponding coding 855 method is used. More than one bit set to 1 means more than one 856 coding method is used in the file. 857 Bit 0: unspecified compression, 858 Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman), 859 Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read), 860 Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR), 861 Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG), 862 Bit 5: ITU-T Rec. T.81 (Baseline JPEG), 863 Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color), 864 Bits 7-31: reserved for future use 865 Note: There is a limit of 32 compression types to identify standard 866 compression methods. 868 VersionYear(404) 869 BYTE 870 Count: 4 871 The year of the standard specified by the FaxProfile field, given as 872 4 characters, e.g. '1997'; used in lossy and lossless color 873 profiles. 875 ModeNumber (405) 876 BYTE 877 The mode of the standard specified by the FaxProfile field. A 878 value of 0 indicates Mode 1.0; used in Mixed Raster Content profile. 880 3. Profile S - Minimal Black-and-White Fax Profile 882 This section defines the minimal black-and-white subset of TIFF for 883 facsimile. This subset is designated Profile S. All implementations 884 of TIFF for facsimile SHALL support the minimal subset. 886 Black-and-white mode is the binary fax application most users are 887 familiar with today. This mode is appropriate for black-and-white 888 text and line art. Black-and-white mode is divided into two levels of 889 capability. This section describes the minimal interchange set of 890 TIFF fields that must be supported by all implementations in order to 891 assure that some form of image, albeit black-and-white, can be 892 interchanged. This minimum interchange set is a strict subset of the 893 fields and values defined for the extended black-and-white profile 894 (TIFF-F or Profile F) in Section 4, which describes extensions to the 895 minimal interchange set of fields that provide a richer set of 896 black-and-white capabilities. 898 3.1. Overview 900 The minimal interchange portion of the black-and-white facsimile mode 901 supports 1-dimensional Modified Huffman (MH) compression, with the 902 original Group 3 fax resolutions, commonly called "standard" and 903 "fine." 905 To assure interchange, this profile uses the minimal set of fields, 906 with a minimal set of values. There are no recommended fields in this 907 profile. Further, the TIFF file is required to be "little endian," 908 which means that the byte order value in the TIFF header is "II". 909 This profile defines a required ordering for the pages in a fax 910 document and for the IFDs and image data of a page. It also requires 912 that a single strip contain the image data for each page; see Section 913 3.5. The image data may contain RTC sequences, as specified in 914 Section 3.4. 916 3.2. Required TIFF Fields 918 Besides the fields listed in Section 2.2.1, the minimal black-and- 919 white fax profile requires the following fields. The fields listed in 920 Section 2.2.1 and the fields and fax-specific values specified in 921 this sub- section must be supported by all implementations. 923 3.2.1 Baseline fields 925 BitsPerSample(258) = 1. 926 SHORT 927 RequiredByTIFFBaseline 928 Binary data only. 929 Default = 1 (field may be omitted if this is the value) 931 Compression(259) = 3. 932 SHORT 933 RequiredByTIFFBaseline 934 3 = 1- or 2- dimensional coding. 935 The value 3 is a TIFF extension value [TIFF]. The T4Options field 936 must be specified and its value specifies that the data is encoded 937 using the Modified Huffman (MH) compression of [T.4]. 939 FillOrder(266) = 2. 940 SHORT 941 RequiredByTIFFBaseline 942 2 = Least Significant Bit first 944 NOTE: Baseline TIFF readers are only required to support FillOrder 946 1, where the lowest numbered pixel is stored in the MSB of the byte. 947 However, because many devices, such as modems, transmit the LSB first 948 when converting the data to serial form, it is common for black-and- 949 white fax products to use the second FillOrder =2, where the lowest 950 numbered pixel is stored in the LSB. Therefore, this value is 951 specified in the minimal black-and-white profile. 953 ImageWidth(256) = 1728. SHORT or 954 LONG 955 RequiredByTIFFBaseline 956 This profile only supports a page width of 1728 pixels. This width 957 corresponds to North American Letter and Legal and to ISO A4 size 958 pages. 959 No default, must be specified. 961 NewSubFileType(254) = (Bit 1=1). 962 LONG 963 RequiredByTIFFforFAX 964 Bit 1 is 1 if the image is a single page of a multi-page document. 965 Default = 0 (no subfile bits on, so may not be omitted for fax) 967 PhotometricInterpretation(262) = 0. 968 SHORT 969 RequiredByTIFFBaseline 970 0 = pixel value 1 means black 971 No default, must be specified 973 ResolutionUnit(296) = 2. 974 SHORT 975 RequiredByTIFFBaseline 976 The unit of measure for resolution. 2 = inch. 977 Default = 2 (field may be omitted if this is the value) 979 SamplesPerPixel(277) = 1. 980 SHORT 981 RequiredByTIFFBaseline 982 The number of components per pixel; 1 for black-and-white 983 Default =1 (field may be omitted if this is the value) 985 XResolution(282) = 200, 204. 986 RATIONAL 987 RequiredByTIFFBaseline 988 The horizontal resolution of the image is expressed in pixels per 989 resolution unit. In pixels/inch, the allowed values are 200 and 990 204, 991 which may be treated as equivalent. See Section 2.2.2 for inch- 992 metric equivalency. 993 No default, must be specified 995 YResolution(283) = 98, 100, 196, 200. 996 RATIONAL 997 RequiredByTIFFBaseline 998 The vertical resolution of the image is expressed in pixels per 999 resolution unit. In pixels/inch, the allowed values are 98, 100, 1000 196 and 200; 98 and 100 may be treated as equivalent, and 196 and 1001 200 may be treated as equivalent. See Section 2.2.2 for inch-metric 1002 equivalency. 1003 No default, must be specified 1005 3.2.2 Extension fields 1007 T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1) 1008 LONG 1009 RequiredTIFFExtension (when Compression = 3) 1010 Bit 0 = 0 indicates MH compression. 1011 Bit 1 must be 0 1012 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 1013 aligned 1014 Default is all bits are 0 (applies when EOLs are not byte aligned) 1016 Note: The T4Options field is required when the Compression field has 1017 a value of 3. Bit 0 of this field specifies the compression used (MH 1018 only in this profile). MH coding requires the use of EOL (End of 1019 Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned 1020 or not. See Section 3.4 for details. 1022 3.2.3. New Fields 1024 None. 1026 3.3. Recommended TIFF Fields 1028 None. 1030 3.4. End of Line (EOL) and Return to Control (RTC) 1032 TIFF extensions for fax, used in this specification, differ from 1033 Baseline TIFF in the following ways: 1034 - a 12-bit EOL sequence MUST precede each line of MH-compressed 1035 image data. (Baseline TIFF does not use these EOL sequences.) 1036 - the EOL sequence MAY be byte-aligned, in which case fill bits are 1037 added so that the EOL sequence ends on a byte boundary, and any 1038 subsequent image data begins on a byte boundary. 1039 - if the EOL codes are not byte aligned, the image data MAY be 1040 followed by an RTC (Return to Control) sequence, consisting of 1041 6 consecutive EOLs. 1043 In conventional fax, an MH-compressed fax data stream for a page 1044 consists of the following sequence: 1045 EOL, compressed data (first line), EOL, compressed data, ... , 1046 EOL, compressed data (last line), RTC (6 consecutive EOL codes) 1047 Baseline TIFF does not use EOL codes or Return to Control (RTC) 1048 sequences for MH-compressed data. However, the TIFF extension field 1049 T4Options used in this specification for MH compression (Compression 1050 = 3) requires EOLs. 1052 Furthermore, Bit 2 in the T4Options field indicates whether or not 1053 the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL 1054 codes are byte aligned, then fill bits have been added as necessary 1055 before EOL codes so that an EOL code always ends on a byte boundary, 1056 and the first bit of data following an EOL begins on a byte boundary. 1057 Without fill bits, an EOL code may end in the middle of a byte. Byte 1058 alignment relieves application software of the burden of 1059 bit-shifting 1060 every byte while parsing scan lines for line-oriented image 1061 manipulation (such as writing a TIFF file). Not all TIFF readers 1062 historically used for fax are able to deal with non-byte aligned 1063 data. 1065 While TIFF extension requires EOL codes, TIFF in fax applications has 1066 traditionally prohibited RTC sequences. Implementations that want 1067 common processing and interfaces for fax data streams and Internet 1068 fax files would prefer that the TIFF data include RTC sequences. 1070 To reconcile these differences, RTCs are allowed in cases where EOL 1071 codes are not byte aligned and no fill bits have been added to the 1072 data. This corresponds to situations where the fax data is simply 1073 inserted in a strip without being processed or interpreted. RTCs 1074 should not occur in the data when EOLs have been byte aligned. This 1075 is formally specified in the next sub-section. 1077 3.4.1. RTC Exclusion 1079 Implementations which wish to maintain strict conformance with TIFF 1080 and compatibility with the historical use of TIFF for fax SHOULD NOT 1081 include the RTC sequence when writing TIFF files. However, 1082 implementations which need to support "transparency" of T.4-generated 1083 image data MAY include RTCs when writing TIFF files if the flag 1084 settings of the T4Options field are set for non-byte aligned data, 1085 i.e. Bit 2 is 0. Implementors of TIFF readers should be aware that 1086 there are some existing TIFF implementations for fax that include the 1087 RTC sequence in MH image data. Therefore, minimal set readers MUST be 1088 able to process files which do not include RTCs and SHOULD be able to 1089 process files which do include RTCs. 1091 3.5. File Structure 1093 The TIFF header, described in Section 2.1.1, contains two bytes which 1094 describe the byte order used within the file. For the minimal black- 1095 and-white profile, these bytes SHALL have the value "II" (0x4949), 1096 denoting that the bytes in the TIFF file are in LSByte-first order 1097 (little- endian). The first or 0th IFD immediately follows the 1098 header, so that offset to the first IFD is 8. The headers values are 1099 shown in the following table: 1101 +--------+-------------------+--------+-----------+ 1102 | Offset | Description | Value | 1103 +--------+-------------------+--------+-----------+ 1104 | 0 | Byte Order | 0x4949 (II) | 1105 +--------+-------------------+--------+-----------+ 1106 | 2 | Identifier | 42 decimal | 1107 +--------+-------------------+--------+-----------+ 1108 | 4 | Offset of 0th IFD | 0x 0000 0008 | 1109 +--------+-------------------+--------+-----------+ 1111 The minimal black-and-white profile SHALL order IFDs and image data 1112 within a file as follows: 1) there SHALL be an IFD for each page in a 1113 multi- page fax document; (2) the IFDs SHALL occur in the same order 1114 in the file as the pages occur in the document; (3) the IFD SHALL 1115 precede the image data to which it has offsets; (4) the image data 1116 SHALL occur in the same order in the file as the pages occur in the 1117 document; (5) the IFD, the value data and the image data it has 1118 offsets to SHALL precede the next image IFD; and (6) the image data 1119 for each page SHALL be contained within a single strip. 1121 As a result of (6), the StripOffsets field will contain the pointer 1122 to the image data. With two exceptions, the field entries in the IFD 1123 contain the field values instead of offsets to field values located 1124 outside the IFD. The two exceptions are the values for the 1125 XResolution and YResolution fields, both of which are type RATIONAL 1126 and require 2 4- byte numbers. These "long" field values SHALL be 1127 placed immediately after the IFD which contains the offsets to them, 1128 and before the image data pointed to by that IFD. 1130 The effect of these requirements is that the IFD for the first page 1131 SHALL come first in the file after the TIFF header, followed by the 1132 long field values for XResolution and YResolution, followed by the 1133 image data for the first page, then the IFD for second page, etc. 1134 This is shown in the following figure. Each IFD is required to have a 1135 PageNumber field, which has value 0 for the first page, 1 for the 1136 second page, and so on. 1138 +-----------------------+ 1139 | Header |------------+ 1140 +-----------------------+ | First IFD 1141 | IFD (page 0) | <----------+ Offset 1142 +---| |------------+ 1143 | | |--+ | 1144 Value | +-----------------------+ | | 1145 Offset +-->| Long Values | | | 1146 +-----------------------| | Strip | 1147 | Image Data (page 0) |<-+ Offset | 1148 +-----------------------+ | Next IFD 1149 | IFD (page 1) | <----------+ Offset 1150 +---| |------------+ 1151 | | |--+ | 1152 Value | +-----------------------+ | | 1153 Offset +-->| Long Values | | | 1154 +-----------------------| | Strip | 1155 | Image Data (page 1) |<-+ Offset | 1156 +-----------------------+ | Next IFD 1157 | IFD (page 2) | <----------+ Offset 1158 +-----------------------+ 1159 | : | 1161 Using this file structure may reduce the memory requirements in 1162 implementations. It is also provides some support for streaming, in 1163 which a file can be processed as it is received and before the entire 1164 file is received. 1166 3.6 Profile S - Minimal Black-and-White Profile Summary 1168 The table below summarizes the TIFF fields that comprise the minimal 1169 interchange set for black-and-white facsimile. The Baseline and 1170 Extension fields and field values MUST be supported by all 1171 implementations. For convenience in the table, certain fields which 1172 have a value that is a sequence of flag bits are shown taking integer 1173 values that correspond to the flags that are set. An implementation 1174 should test the setting of the relevant flag bits individually, 1175 however, to allow extensions to the sequence of flag bits to be 1176 appropriately ignored. (See, for example, T4Options below.) 1178 +---------------------------+--------------------------------+ 1179 | Baseline Fields | Values | 1180 +---------------------------+--------------------------------+ 1181 | BitsPerSample | 1 | 1182 +---------------------------+--------------------------------+ 1183 | Compression | 3: 1D Modified Huffman coding | 1184 | | set T4Options = 0 or 4 | 1185 +------------------------------------------------------------+ 1186 +---------------------------+--------------------------------+ 1187 | FillOrder | 2: least significant bit first | 1188 +---------------------------+--------------------------------+ 1189 | ImageWidth | 1728 | 1190 +---------------------------+--------------------------------+ 1191 | ImageLength | n: total number of scanlines | 1192 | | in image | 1193 +---------------------------+--------------------------------+ 1194 | NewSubFileType | 2: Bit 1 identifies single | 1195 | | page of a multi-page document | 1196 +---------------------------+--------------------------------+ 1197 | PageNumber | n,m: page number n followed by | 1198 | | total page count m | 1199 +---------------------------+--------------------------------+ 1200 | PhotometricInterpretation | 0: pixel value 1 means black | 1201 +---------------------------+--------------------------------+ 1202 | ResolutionUnit | 2: inch | 1203 +---------------------------+--------------------------------+ 1204 | RowsPerStrip | number of scanlines per strip | 1205 | | = ImageLength, with one strip | 1206 +---------------------------+--------------------------------+ 1207 | SamplesPerPixel | 1 | 1208 +---------------------------+--------------------------------+ 1209 | StripByteCounts | number of bytes in TIFF strip | 1210 +---------------------------+--------------------------------+ 1211 | StripOffsets | offset from beginning of | 1212 | | file to single TIFF strip | 1213 +---------------------------+--------------------------------+ 1214 | XResolution | 204, 200 (pixels/inch) | 1215 +---------------------------+--------------------------------+ 1216 | YResolution | 98, 196, 100, 200 (pixels/inch)| 1217 +---------------------------+--------------------------------+ 1218 | Extension Fields | 1219 +---------------------------+--------------------------------+ 1220 | T4Options | 0: MH coding, EOLs not byte | 1221 | | aligned | 1222 | | 4: MH coding, EOLs byte aligned| 1223 +---------------------------+--------------------------------+ 1225 4. Profile F - Extended Black-and-White fax profile 1227 This section defines the extended black-and-white profile or Profile 1229 F of TIFF for facsimile. It provides a standard definition of what 1230 has historically been known as TIFF Class F and now TIFF-F. In doing 1232 so, it aligns this profile with current ITU-T Recommendations for 1233 black-and-white fax and with existing industry practice. 1234 Implementations of this profile include implementations of Profile S. 1236 This section describes extensions to the minimal interchange set of 1237 fields (Profile S) that provide a richer set of black-and-white 1238 capabilities. The fields and values described in this section are a 1239 superset of the fields and values defined for the minimal interchange 1240 set in Section 3. In addition to the MH compression, Modified READ 1241 (MR) and Modified Modified READ (MMR) compression as described in 1242 [T.4] and [T.6] are supported. 1244 Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the 1245 TIFF fields that SHALL be used in this profile. Section 4.3 describes 1246 the fields that MAY be used in this profile. In the spirit of the 1247 original TIFF-F specification, Sections 4.4 and 4.5 discuss technical 1248 implementation issues and warnings. Section 4.6 gives an example use 1249 of TIFF-F. Section 4.7 gives a summary of the required and 1250 recommended fields and their values. 1252 4.1 TIFF-F Overview 1254 Though it has been in common usage for many years, TIFF-F has 1255 previously never been documented in the form of a standard. An 1256 informal TIFF-F document was originally created by a small group of 1257 fax experts led by Joe Campbell. The existence of TIFF-F is noted in 1258 [TIFF] but it is not defined. This document serves as the formal 1259 definition of the F application of [TIFF] for Internet applications. 1260 For ease of reference, the term TIFF-F will be used throughout this 1261 document as a shorthand for the extended black-and-white profile 1262 of TIFF for facsimile. 1264 Up until the TIFF 6.0 specification, TIFF supported various "Classes" 1265 which defined the use of TIFF for various applications. Classes were 1266 used to support specific applications. In this spirit, TIFF-F has 1267 been known historically as "TIFF Class F". Previous informal TIFF-F 1268 documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0 1269 [TIFF], the TIFF Class concept has been eliminated in favor of the 1270 concept of Baseline TIFF. Therefore, this document updates the 1271 definition of TIFF-F as the F profile of TIFF for facsimile, by using 1272 Baseline TIFF as defined in [TIFF] as the starting point and then 1273 adding the TIFF extensions to Baseline TIFF which apply for TIFF-F. 1274 In almost all cases, the resulting definition of TIFF-F fields and 1275 values remains consistent with those used historically in earlier 1276 definitions of TIFF Class F. Where some of the values for fields 1277 have been updated to provide more precise conformance with the ITU-T 1278 [T.4] and [T.30] fax recommendations, these differences are noted. 1280 4.2. Required TIFF Fields 1282 This section lists the required fields and the values they must have 1283 to be ITU-compatible. Besides the fields listed in Section 2.2.1, the 1284 extended black-and-white fax profile SHALL use the following fields. 1286 4.2.1. Baseline fields 1288 BitsPerSample(258) = 1. 1289 SHORT 1290 RequiredByTIFFBaseline 1291 Binary data only. 1292 Default = 1 (field may be omitted if this is the value) 1294 Compression(259) = 3, 4. 1295 SHORT 1296 RequiredByTIFFBaseline 1297 3 = 1- or 2- dimensional coding, must have T4Options field This is 1298 a TIFF Extension value [TIFF]. 1299 4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified 1300 Read, must have T6Options field)) This is a TIFF Extension value. 1301 Default = 1 (and is not applicable; field must be specified) 1303 NOTE: Baseline TIFF permits use of value 2 for Modified Huffman 1304 compression, but data is presented in a form which does not use EOLs, 1305 and so TIFF for facsimile uses Compression=3 instead. See Sections 1306 4.4.4, 4.5.1 and 4.5.2 for more information on compression and 1307 encoding. 1309 FillOrder(266) = 1 , 2. 1310 SHORT 1311 RequiredByTIFFBaseline 1312 Profile F readers must be able to read data in both bit orders, 1313 but the vast majority of facsimile products store data LSB 1314 first, exactly as it appears on the telephone line. 1315 1 = Most Significant Bit first. 1316 2 = Least Significant Bit first 1318 ImageWidth(256) SHORT or 1319 LONG 1320 RequiredByTIFFBaseline 1321 This profile supports the following fixed page widths: 1728, 2592, 1322 3456 (corresponding to North American Letter and Legal, ISO A4 paper 1323 sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and 1324 2432, 3648, 4864 (corresponding to ISO A3 paper size). 1325 No default; must be specified 1327 NOTE: Historical TIFF-F did not include support for the following 1328 widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096 1329 and 4864. Historical TIFF-F documents also included the following 1330 values related to A5 and A6 widths: 816 and 1216. Per the most recent 1331 version of [T.4], A5 and A6 documents are no longer supported in 1332 Group 3 facsimile, so the related width values are now obsolete. See 1333 section 4.5.2 for more information on inch/metric equivalencies and 1334 other implementation details. 1336 NewSubFileType(254) = (Bit 1=1). 1337 LONG 1338 RequiredByTIFFforFAX 1339 Bit 1 is 1 if the image is a single page of a multi-page document. 1340 Default = 0 (no subfile bits on, so may not be omitted for fax) 1342 NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page 1343 of a multi-page image. The same bit settings are used when TIFF-F is 1344 used for a one page fax image. See Section 4.4.3 for details on 1345 multi-page files. 1347 PhotometricInterpretation(262) = 0, 1. 1348 SHORT 1349 RequiredByTIFFBaseline 1350 0 = pixel value 1 means black, 1 = pixel value 1 means white. 1351 This field allows notation of an inverted or negative image. 1352 No default, must be specified 1354 ResolutionUnit(296) = 2, 3. 1355 SHORT 1356 RequiredByTIFFBaseline 1357 The unit of measure for resolution. 2 = inch, 3 = centimeter; = TIFF-F 1358 has traditionally used inch-based measures. 1359 Default = 2 (field may be omitted if this is the value) 1361 SamplesPerPixel(277) = 1. 1362 SHORT 1363 RequiredByTIFFBaseline 1364 1 = monochrome, bilevel in this case (see BitsPerSample) 1365 Default =1 (field may be omitted if this is the value) 1367 XResolution(282) = 200, 204, 300, 400, 408 1368 RATIONAL 1369 RequiredByTIFFBaseline 1370 The horizontal resolution of the image is expressed in pixels per 1371 resolution unit. In pixels/inch, the allowed values are: 200, 204, 1372 300, 400, and 408. See Section 2.2.2 for inch-metric equivalency. 1373 No default, must be specified 1375 NOTE: The values of 200 and 408 have been added to the historical 1376 TIFF-F values, for consistency with [T.30]. Some existing TIFF-F 1377 implementations may also support values of 80 pixels/cm, which is 1378 equivalent to 204 pixels per inch. See section 4.5.2 for information 1379 on implementation details. 1381 YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 1382 RATIONAL 1383 RequiredByTIFFBaseline 1384 The vertical resolution of the image is expressed in pixels per 1385 resolution unit. In pixels/inch, the allowed values are: 98, 100, 1386 196, 200, 300, 391, and 400 pixels/inch. 1387 See Section 2.2.2 for inch-metric equivalency. 1388 No default, must be specified 1390 NOTE: The values of 100, 200, and 391 have been added to the 1391 historical TIFF-F values, for consistency with [T.30]. Some existing 1392 TIFF-F implementations may also support values of 77 and 38.5 (cm), 1393 which are equivalent to 196 and 98 pixels per inch respectively. See 1394 section 4.5.2 for more information on implementation details. 1396 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 1397 are legal. The following table gives the legal combinations and 1398 corresponding paper size [T.30]. 1400 +--------------+-----------------+---------------------------+ 1401 | XResolution x YResolution | ImageWidth | 1402 +--------------+-----------------+---------+--------+--------+ 1403 | 200x100, 204x98 | | | | 1404 | 200x200, 204x196 | 1728 | 2048 | 2432 | 1405 | 204x391 | | | | 1406 +--------------+-----------------+---------+--------+--------+ 1407 | 300 x 300 | 2592 | 3072 | 3648 | 1408 +--------------+-----------------+---------+--------+--------+ 1409 | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | 1410 +--------------+-----------------+---------+--------+--------+ 1411 |Letter,A4| B4 | A3 | 1412 | Legal | | | 1413 +---------+--------+--------+ 1414 | Paper Size | 1415 +---------------------------+ 1417 4.2.2. Extension fields 1419 T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) 1420 LONG 1421 RequiredTIFFExtension (when Compression = 3) 1422 T4Options was also known as Group3Options in a prior version of 1423 [TIFF]. 1424 Bit 0 = 1 indicates MR compression, = 0 indicates MH compression. 1425 Bit 1 must be 0 1426 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 1427 aligned 1428 Default is all bits are 0 (applies when MH compression is used and 1429 EOLs are not byte aligned) (See Section 3.2.2.) 1430 The T4Options field is required when the Compression field has a 1431 value of 3. This field specifies the compression used (MH or MR) and 1432 whether the EOL codes are byte-aligned or not. If they are byte 1433 aligned, then fill bits have been added as necessary so that the End 1434 of Line (EOL) codes always end on byte boundaries See Sections 3.4, 1435 4.5.3 and 4.5.4 for details. 1437 T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG 1438 RequiredTIFFExtension (when Compression = 4) 1439 Used to indicate parameterization of 2D Modified Modified Read (MMR) 1440 compression. T6Options was also known as Group4Options in a prior 1441 version of [TIFF]. 1442 Bit 0 must be 0. 1443 Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1 1444 indicates uncompressed data is allowed (see [TIFF]). 1445 Default is all bits 0. For FAX, the field must be present and have 1446 the value 0. The use of uncompressed data where compression would 1447 expand the data size is not allowed for FAX. 1449 NOTE: MMR compressed data is two-dimensional and does not use EOLs. 1450 Each MMR encoded image MUST include an "end-of-facsimile-block" 1451 (EOFB) code at the end of each coded strip; see Section 4.5.6. 1453 4.2.3. New fields 1455 None. 1457 4.3. Recommended TIFF fields 1459 4.3.1. Baseline fields 1461 See Section 2.2.3. 1463 4.3.2. Extension fields 1465 See Section 2.2.3. 1467 4.3.3. New fields 1469 See Section 2.2.4 and optional fields below. 1471 Three new, optional fields, used in the original TIFF-F description 1472 to describe page quality, are defined in this specification. The 1473 information contained in these fields is usually obtained from 1474 receiving facsimile hardware (if applicable). They SHOULD NOT be used 1475 in writing TIFF-F files for facsimile image data that is error 1476 corrected or otherwise guaranteed not to have coding errors. Some 1477 applications need to understand exactly the error content of the 1478 data. For example, a CAD program might wish to verify that a file 1479 has a low error level before importing it into a high-accuracy 1480 document. Because Group 3 facsimile devices do not necessarily 1481 perform error correction on the image data, the quality of a received 1482 page must be inferred from the pixel count of decoded scan lines. A 1483 "good" scan line is defined as a line that, when decoded, contains 1484 the correct number of pixels. Conversely, a "bad" scan line is 1485 defined as a line that, when decoded, comprises an incorrect number 1486 of pixels. 1488 BadFaxLines(326) SHORT or 1489 LONG 1490 The number of "bad" scan lines encountered by the facsimile device 1491 during reception. A "bad" scanline is defined as a scanline that, 1492 when decoded, comprises an incorrect number of pixels. Note that 1493 PercentBad = (BadFaxLines/ImageLength) * 100 1494 No default. 1496 CleanFaxData(327) = 0, 1, 2. 1497 SHORT 1498 Indicates if "bad" lines encountered during reception are stored in 1499 the data, or if "bad" lines have been replaced by the receiver. 1500 0 = No "bad" lines 1501 1 = "bad" lines exist, but were regenerated by the receiver, 1502 2 = "bad" lines exist, but have not been regenerated. 1503 No default. 1505 NOTE: Many facsimile devices do not actually output bad lines. 1506 Instead, the previous good line is repeated in place of a bad line. 1507 Although this substitution, known as line regeneration, results in a 1508 visual improvement to the image, the data is nevertheless corrupted. 1509 The CleanFaxData field describes the error content of the data. That 1510 is, when the BadFaxLines and ImageLength fields indicate that the 1511 facsimile device encountered lines with an incorrect number of pixels 1512 during reception, the CleanFaxData field indicates whether these bad 1513 lines are actually still in the data or if the receiving facsimile 1514 device replaced them with regenerated lines. 1516 ConsecutiveBadFaxLines(328) LONG or SHORT 1517 Maximum number of consecutive "bad" scanlines received. The 1518 BadFaxLines field indicates only the quantity of bad lines. 1519 No Default. 1521 NOTE: The BadFaxLines and ImageLength data indicate only the quantity 1522 of bad lines. The ConsecutiveBadFaxLines field is an indicator of the 1523 distribution of bad lines and may therefore be a better general 1524 indicator of perceived image quality. See Section 4.4.5 for examples 1525 of the use of these fields. 1527 4.4. Technical Implementation Issues 1529 4.4.1 Strips 1531 In general, TIFF files divide an image into "strips," also known as 1532 "bands." Each strip contains a few scanlines of the image. By using 1533 strips, a TIFF reader need not load the entire image into memory, 1534 thus enabling it to fetch and decompress small random portions of the 1535 image as necessary. 1537 The number of scanlines in a strip is described by the RowsPerStrip 1538 value and the number of bytes in the strip after compression by the 1539 StripByteCount value. The location in the TIFF file of each strip is 1540 given by the StripOffsets values. 1542 Strip size is application dependent. The recommended approach for 1543 multi- page TIFF-F images is to represent each page as a single 1544 strip. Existing TIFF-F usage is typically one strip per page in 1545 multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3. 1547 4.4.2 Bit Order 1549 The current TIFF specification [TIFF] does not require a Baseline 1550 TIFF reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel 1551 in the least significant bit of a byte. It further recommends that 1552 FillOrder=2 be used only in special purpose applications. 1554 Facsimile data appears on the phone line in bit-reversed order 1555 relative to its description in ITU-T Recommendation T.4. Therefore, 1556 a wide majority of facsimile applications choose this natural order 1557 for data in a file. Nevertheless, TIFF-F readers must be able to read 1558 data in both bit orders and support FillOrder values of 1 and 2. 1560 4.4.3. Multi-Page 1562 Many existing applications already read TIFF-F-like files, but do not 1563 support the multi-page field. Since a multi-page format greatly 1564 simplifies file management in fax application software, TIFF-F 1565 specifies multi-page documents (NewSubfileType = 2) as the standard 1566 case. 1568 It is recommended that applications export multiple page TIFF-F files 1569 without manipulating fields and values. Historically, some TIFF-F 1570 writers have attempted to produce individual single-page TIFF-F files 1571 with modified NewSubFileType and PageNumber (page one-of-one) values 1572 for export purposes. However, there is no easy way to link such 1573 multiple single page files together into a logical multiple page 1574 document, so that this practice is not recommended. 1576 4.4.4. Compression 1578 In Group 3 facsimile, there are three compression methods which had 1579 been standardized as of 1994 and are in common use. The ITU-T T.4 1580 Recommendation [T.4] defines a one-dimensional compression method 1581 known as Modified Huffman (MH) and a two-dimensional method known as 1582 Modified READ (MR) (READ is short for Relative Element Address 1583 Designate). In 1984, a somewhat more efficient compression method 1584 known as Modified Modified READ (MMR) was defined in the ITU-T T.6 1585 Recommendation [T.6]. MMR was originally defined for use with Group 4 1586 facsimile, so that this compression method has been commonly called 1587 Group 4 compression. In 1991, the MMR method was approved for use in 1588 Group 3 facsimile and has since been widely utilized. 1590 TIFF-F supports these three compression methods. The most common 1591 practice is the one-dimensional Modified Huffman (MH) compression 1592 method. This is specified by setting the Compression field value to 1593 3 and then setting bit 0 of the T4Options field to 0. Alternatively, 1594 the two dimensional Modified READ (MR) method, which is much less 1595 frequently used in historical TIFF-F implementations, may be selected 1596 by setting bit 0 of the T4Options field to 1. The value of Bit 2 in 1597 this field is determined by the use of fill bits. 1599 Depending upon the application, the more efficient two-dimensional 1600 Modified Modified Read (MMR)compression method from T.6 may be 1601 selected by setting the Compression field value to 4 and then setting 1602 the first two bits (and all unused bits) of the T6Options field to 0. 1603 More information to aid the implementor in making a compression 1604 selection is contained in Section 4.5.2. 1606 Baseline TIFF also permits use of Compression=2 to specify Modified 1607 Huffman compression, but the data does not use EOLs. As a result, 1608 TIFF-F uses Compression=3 instead of Compression=2 to specify 1609 Modified Huffman compression. 1611 4.4.5. Example Use of Page-quality Fields 1613 Here are examples for writing the CleanFaxData, BadFaxLines, and 1614 ConsecutiveBadFaxLines fields: 1616 1. Facsimile hardware does not provide page quality 1617 information: MUST NOT write page-quality fields. 1618 2. Facsimile hardware provides page quality information, but 1619 reports no bad lines. Write only BadFaxLines = 0. 1620 3. Facsimile hardware provides page quality information, and 1621 reports bad lines. Write both BadFaxLines and 1622 ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or 2 if 1623 the hardware's regeneration capability is known. 1624 4. Source image data stream is error-corrected or otherwise 1625 guaranteed to be error-free such as for a computer generated 1626 file: SHOULD NOT write page-quality fields. 1628 TIFF Writers SHOULD only generate these fields when the image has 1629 been generated from a fax image data stream where error correction, 1630 e.g. Group 3 Error Correction Mode, was not used. 1632 4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F 1633 Files 1635 Traditionally, historical TIFF-F has required readers and writers to 1636 be able to handle multi-page TIFF-F files. Based on the experience 1637 of various TIFF-F implementors, it has been seen that the 1638 implementation of TIFF-F can be greatly simplified if certain 1639 practical guidelines are followed when writing multi-page TIFF-F 1640 files. 1642 The structure for a multi-page TIFF-F file will include one IFD per 1643 page of the document. In this case, this IFD will define the 1644 attributes for a single page. A second simplifying guideline is that 1645 the writer of TIFF-F files SHOULD present IFDs in the same order as 1646 the actual sequence of pages. (The pages are numbered within TIFF-F 1647 beginning with page 0 as the first page and then ascending (i.e. 0, 1648 1, 2,...). However, any field values over 4 bytes will be stored 1649 separately from the IFD. TIFF-F readers SHOULD expect IFDs to be 1650 presented in page order, but be able to handle exceptions. 1652 Per [TIFF], the exact placement of image data is not specified. 1653 However, the strip offsets for each strip of image are defined from 1654 within each IFD. Where possible, another simplifying guideline for 1655 the writing of TIFF-F files is to specify that the image data for 1656 each page of a multi-page document SHOULD be contained within a 1657 single strip (i.e. one image strip per fax page). The use of a single 1658 image strip per page is very useful for applications such as store 1659 and forward messaging, where the file is usually prepared in advance 1660 of the transmission, but other assumptions may apply for the size of 1661 the image strip for applications which require the use of "streaming" 1662 techniques (see section 4.4.7). In the event a different image strip 1663 size guideline has been used (e.g. constant size for image strips 1664 that may be less than the page size), this will immediately be 1665 evident from the values/offsets of the fields that are related to 1666 strips. 1668 A third simplifying guideline is that each IFD SHOULD be placed in 1669 the TIFF-F file structure at a point which precedes the image which 1670 the IFD describes. 1672 In addition, a fourth simplifying guideline for TIFF-F writers and 1673 readers is to place the actual image data in a physical order within 1674 the TIFF file structure which is consistent with the logical page 1675 order. In practice, TIFF-F readers will need to use the strip 1676 offsets to find the exact physical location of the image data, 1677 whether or not it is presented in logical page order. 1679 If the image data is stored in multiple strips, then the strips 1680 SHOULD occur in the file in the same order that the data they contain 1681 occurs in the facsimile transmission, starting at the top of the 1682 page. 1684 TIFF-F writers MAY make a fifth simplifying guideline, in which the 1685 IFD, the value data and the image data to which the IFD has offsets 1686 precede the next image IFD. However, this guideline has been relaxed 1687 (writers MAY rather than SHOULD use it) compared to the other 1688 guidelines given here to reflect past practices for TIFF-F. 1690 In the case of the minimal profile, which is also the minimal subset 1692 of Profile F, the SHOULD's and MAY's of these guidelines become 1693 SHALL's (see Section 3.5). 1695 So, a TIFF-F file which is structured using the guidelines of this 1696 section will essentially be composed of a linked list of IFDs, 1697 presented in ascending page order, which in turn each point to a 1698 single page of image data (one strip per page), where the pages of 1699 image data are also placed in a logical page order within the TIFF- F 1700 file structure. (The pages of image data may themselves be stored in 1701 a contiguous manner, at the option of the implementor). 1703 4.4.7. Use of TIFF-F for Streaming Applications 1705 TIFF-F has historically been used for handling fax image files in 1706 applications such as store and forward messaging where the entire 1707 size of the file is known in advance. While TIFF-F may also possibly 1708 be used as a file format for cases such as streaming applications, 1709 assumptions may be required that differ from those provided in this 1710 section (e.g., the entire size and number of pages within the image 1711 are not known in advance). As a result, a definition for the 1712 streaming application of TIFF-F is beyond the scope of this document. 1714 4.5. Implementation Warnings 1716 4.5.1 Uncompressed data 1718 TIFF-F requires the ability to read and write at least one- 1719 dimensional T.4 Huffman ("compressed") data. Uncompressed data is 1720 not allowed. This means that the "Uncompressed" bit in T4Options or 1721 T6Options must be set to 0. 1723 4.5.2. Encoding and Resolution 1725 Since two-dimensional encoding is not required for Group 3 1726 compatibility, some historic TIFF-F readers have not been able to 1727 read such files. The minimum subset of TIFF-F REQUIRES support for 1728 one dimensional (Modified Huffman) files, so this choice maximizes 1729 portability. However, implementors seeking greater efficiency SHOULD 1730 use T.6 MMR compression when writing TIFF-F files. Some TIFF-F 1731 readers will also support two-dimensional Modified READ files. 1732 Implementors that wish to have the maximum flexibility in reading 1733 TIFF-F files should support all three of these compression methods 1734 (MH, MR and MMR). 1736 For the case of resolution, almost all facsimile products support 1737 both standard (98 dpi) vertical resolution and "fine" (196 dpi) 1738 resolution. Therefore, fine-resolution files are quite portable in 1739 the real world. 1741 In 1993, the ITU-T added support for higher resolutions in the T.30 1742 recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per 1743 inch based units. At the same time, support was added for metric 1744 dimensions which are equivalent to the following inch based 1745 resolutions: 391v x 204h and 391v x 408h. Therefore, the full set of 1746 inch-based equivalents of the new resolutions are supported in the 1747 TIFF-F writer, since they may appear in some image data streams 1748 received from Group 3 facsimile devices. However, many facsimile 1749 terminals and older versions of TIFF-F readers are likely to not 1750 support the use of these higher resolutions. 1752 Per [T.4], it is permissible for applications to treat the following 1753 XResolution values as being equivalent: <204,200> and <400,408>. In 1754 a similar respect, the following YResolution values may also be 1755 treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>. 1756 These equivalencies were allowed by [T.4] to permit conversions 1757 between inch and metric based facsimile terminals. 1759 In a similar respect, the optional support of metric based 1760 resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for 1761 completeness, since they are used in some legacy TIFF-F applications, 1762 but this use is not recommended for the creation of TIFF-F files by a 1763 writer. 1765 4.5.3. EOL byte-aligned 1767 The historical convention for TIFF-F has been that all EOLs in 1768 Modified Huffman or Modified READ data must be byte-aligned. However, 1769 Baseline TIFF has permitted use of non-byte-aligned EOLs by default, 1770 so that a large percentage of TIFF-F reader implementations support 1771 both conventions. Therefore, the minimum subset of TIFF-F, or Profile 1772 S, as defined in Section 3 includes support for both byte-aligned and 1773 non- byte-aligned EOLs; see Section 3.2.2. 1775 An EOL is said to be byte-aligned when Fill bits have been added as 1776 necessary before EOL codes such that EOL always ends on a byte 1777 boundary, thus ensuring an EOL-sequence of a one byte preceded by a 1778 zero nibble: xxxx0000 00000001. 1780 Modified Huffman compression encodes bits, not bytes. This means that 1781 the end-of-line token may end in the middle of a byte. In byte 1782 alignment, extra zero bits (Fill) are added so that the first bit of 1783 data following an EOL begins on a byte boundary. In effect, byte 1784 alignment relieves application software of the burden of bit- 1785 shifting every byte while parsing scan lines for line-oriented image 1786 manipulation (such as writing a TIFF file). 1788 For Modified READ compression, each line is terminated by an EOL and 1790 a one bit tag bit. Per [T.4], the value of the tag bit is 0 if the 1791 next line contains two dimensional data and 1 if the next line is a 1792 reference line. To maintain byte alignment, fill bits are added 1793 before the EOL/tag bit sequence, so that the first bit of data 1794 following an MR tag bit begins on a byte boundary. 1796 4.5.4. EOL 1798 As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded 1799 with Modified Huffman begin with an EOL, which in TIFF-F may be byte- 1800 aligned. The last line of the image is not terminated by an EOL. In 1801 a similar respect, images encoded with Modified READ two-dimensional 1802 compression begin with an EOL, followed by a tag bit. 1804 4.5.5. RTC Exclusion 1806 Aside from EOLs, TIFF-F files have historically only contained image 1807 data. This means that applications which wish to maintain strict 1808 conformance with the rules in [TIFF] and compatibility with 1809 historical TIFF-F, SHOULD NOT include the Return To Control sequence 1810 (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. 1811 However, applications which need to support "transparency" of [T.4] 1812 image data MAY include RTCs if the flag settings of the T4Options 1813 field are set for non-byte aligned MH or MR image data. Implementors 1814 of TIFF readers should also be aware that there are some existing 1815 TIFF-F implementations which include the RTC sequence in MH/MR image 1816 data. Therefore, TIFF-F readers MUST be able to process files which 1817 do not include RTCs and SHOULD be able to process files which do 1818 include RTCs. 1820 4.5.6 Use of EOFB for T.6 Compressed Images 1822 TIFF-F pages which are encoded with the T.6 Modified Modified READ 1823 compression method MUST include an "end-of-facsimile-block" (EOFB) 1824 code at the end of each coded strip. Per [TIFF], the EOFB code is 1825 followed by pad bits as needed to align on a byte boundary. TIFF 1826 readers SHOULD ignore any bits other than pad bits beyond the EOFB. 1828 4.6. Example Use of TIFF-F 1830 The Profile F of TIFF (i.e. TIFF-F content) is a secondary component 1831 of the VPIM Message, as defined in [VPIM 2]. Voice messaging 1832 systems can often handle fax store-and-forward capabilities in 1833 addition to traditional voice message store-and-forward functions. 1834 As a result, TIFF-F fax messages can optionally be sent between 1835 compliant VPIM systems, and may be rejected if the recipient system 1836 cannot deal with fax. 1838 Refer to the VPIM Specification for proper usage of this content. 1840 4.7. Profile F - Extended Black-and-white Fax Profile Summary 1842 Recommended fields are shown with an asterisk *. 1844 Required fields or values are shown with a double asterisk **. If the 1845 double asterisk is on the field name, then all the listed values are 1846 required of implementations; if the double asterisks are in the 1847 Values column, then only the values suffixed with a double asterisk 1848 are required of implementations. 1850 +---------------------------+--------------------------------+ 1851 | Baseline Fields | Values | 1852 +---------------------------+--------------------------------+ 1853 | BitsPerSample | 1** | 1854 +---------------------------+--------------------------------+ 1855 | Compression | 3**: 1D Modified Huffman and | 1856 | | 2D Modified Read coding | 1857 | | 4: 2D Modified Modified Read | 1858 | | coding | 1859 +---------------------------+--------------------------------+ 1860 | DateTime* | {ASCII}: date/time in 24-hour | 1861 | | format "YYYY:MM:DD HH:MM:SS" | 1862 +---------------------------+--------------------------------+ 1863 | FillOrder** | 1: most significant bit first | 1864 | | 2: least significant bit first | 1865 +------------------------------------------------------------+ 1866 +------------------------------------------------------------+ 1867 | ImageDescription* | {ASCII}: A string describing | 1868 | | the contents of the image. | 1869 +---------------------------+--------------------------------+ 1870 | ImageWidth | 1728**, 2048, 2432, 2592, | 1871 | | 3072, 3456, 3648, 4096, 4864 | 1872 +---------------------------+--------------------------------+ 1873 | ImageLength** | n: total number of scanlines | 1874 | | in image | 1875 +---------------------------+--------------------------------+ 1876 | NewSubFileType | 2**: Bit 1 identifies single | 1877 | | page of a multi-page document | 1878 +---------------------------+--------------------------------+ 1879 | Orientation | 1**-8, Default 1 | 1880 +---------------------------+--------------------------------+ 1881 | PhotometricInterpretation | 0: pixel value 1 means black | 1882 | ** | 1: pixel value 1 means white | 1883 +---------------------------+--------------------------------+ 1884 | ResolutionUnit** | 2: inch | 1885 | | 3: centimeter | 1886 +---------------------------+--------------------------------+ 1887 | RowsPerStrip** | n: number of scanlines per | 1888 | | TIFF strip | 1889 +---------------------------+--------------------------------+ 1890 | SamplesPerPixel | 1** | 1891 +---------------------------+--------------------------------+ 1892 | Software* | {ASCII}: name & release | 1893 | | number of creator software | 1894 +---------------------------+--------------------------------+ 1895 | StripByteCounts** | : number or bytes in TIFF | 1896 | | strip | 1897 +---------------------------+--------------------------------+ 1898 | StripOffsets** | : offset from beginning of | 1899 | | file to each TIFF strip | 1900 +---------------------------+--------------------------------+ 1901 | XResolution | 200, 204**, 300, 400, 408 | 1902 | | (written in pixels/inch) | 1903 +---------------------------+--------------------------------+ 1904 | YResolution | 98**, 196**, 100, | 1905 | | 200, 300, 391, 400 | 1906 | | (written in pixels/inch) | 1907 +---------------------------+--------------------------------+ 1908 | Extension Fields | 1909 +---------------------------+--------------------------------+ 1910 +---------------------------+--------------------------------+ 1911 | T4Options | 0**: required if Compression | 1912 | | is Modified Huffman, EOLs are | 1913 | | not byte aligned | 1914 | | 1: required if Compression is | 1915 | | 2D Modified Read, EOLs are | 1916 | | not byte aligned | 1917 | | 4**: required if Compression | 1918 | | is Modified Huffman, EOLs are | 1919 | | byte aligned | 1920 +---------------------------+--------------------------------+ 1921 | T4Options (continued) | 5: required if Compression | 1922 | | is 2D Modified Read, EOLs are | 1923 | | byte aligned | 1924 +---------------------------+--------------------------------+ 1925 | T6Options | 0: required if Compression is | 1926 | | 2D Modified Modified Read | 1927 +---------------------------+--------------------------------+ 1928 | DocumentName* | {ASCII}: name of scanned | 1929 | | document | 1930 +---------------------------+--------------------------------+ 1931 | PageNumber** | n,m: page number followed by | 1932 | | total page count | 1933 +---------------------------+--------------------------------+ 1934 | New Fields | 1935 +---------------------------+--------------------------------+ 1936 | BadFaxLines* | number of "bad" scanlines | 1937 | | encountered during reception | 1938 +---------------------------+--------------------------------+ 1939 | CleanFaxData* | 0: no "bad" lines | 1940 | | 1: "bad" lines exist, but were | 1941 | | regenerated by receiver | 1942 | | 2: "bad" lines exist, but have | 1943 | | not been regenerated | 1944 +---------------------------+--------------------------------+ 1945 | ConsecutiveBadFaxLines* | Max number of consecutive | 1946 | | "bad" lines received | 1947 +---------------------------+--------------------------------+ 1948 | GlobalParametersIFD* | IFD: global parameters IFD | 1949 +---------------------------+--------------------------------+ 1950 | ProfileType* | n: type of data stored in file | 1951 +---------------------------+--------------------------------+ 1952 | FaxProfile* | n: ITU-compatible fax profile | 1953 +---------------------------+--------------------------------+ 1954 | CodingMethods* | n: compression algorithms used | 1955 | | in file | 1956 +---------------------------+--------------------------------+ 1958 5. Profile J - Lossless JBIG Black-and-White Fax profile 1960 This section defines the lossless JBIG black-and-white profile or 1961 Profile J of TIFF for facsimile. Implementations of this profile are 1962 required to also implement Profile S. 1964 The previous section described the extended interchange set of TIFF 1965 fields for black-and-white fax, which provided support for the MH, MR 1966 and MMR compression of black-and-white images. This section adds a 1967 profile with JBIG compression capability. 1969 5.1. Overview 1971 This section describes a black-and-white profile that uses JBIG 1972 compression. The ITU-T has approved the single-progression sequential 1973 mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers 1974 improved compression for halftoned originals. JBIG compression is 1975 used in accordance with the application rules given in ITU-T Rec. 1976 T.85 [T.85]. 1978 This profile is essentially the extended black-and-white profile with 1979 JBIG compression used instead of MH, MR or MMR. 1981 5.2. Required TIFF Fields 1983 This section lists the required fields and the values they must have 1984 to be ITU-compatible. Besides the fields listed in Section 2.2.1, the 1985 extended black-and-white fax profile requires the following fields. 1987 5.2.1. Baseline fields 1989 The TIFF fields that SHALL be used in this profile are the same as 1990 those described in Section 4.2.1 for the extended black-and-white 1991 profile, with two exceptions: the following text replaces the text in 1992 Section 4.2.1 for the Compression and FillOrder fields. 1994 Compression(259) = 9. 1995 SHORT 1996 RequiredByTIFFBaseline 1997 9 = JBIG coding. This is a TIFF extension value. 1998 Default = 1 (and is not applicable; field must be specified). 1999 Profile J uses ITU-T T.85 profile of T.82; see T82Options field. 2001 FillOrder(266) = 1, 2. 2002 SHORT 2003 RequiredByTIFFBaseline 2004 1 = Pixels are arranged within a byte such that pixels with lower 2005 values are stored in the higher-order bits of the byte, i.e. most 2006 significant bit first (MSB). 2007 2 = Pixels are arranged within a byte such that pixels with lower 2008 column values are stored in the lower-order bits of the bytes, i.e., 2009 least significant bit first (LSB). 2011 Profile J readers must be able to read data in both bit orders. 2013 5.2.2. Extension fields 2015 Same fields as those in Section 2.2.1. 2017 5.2.3. New fields 2019 T82Options(435) = 0 2020 LONG 2021 Required when Compression = 9 2022 Individual bits are set to indicate the applicable profile of JBIG 2023 coding; all bits set to 0 indicates ITU-T T.85 profile of T.82; 2024 Other values are for further study. 2025 Default is all bits 0 and field may be omitted if this is the value 2026 (Field may be omitted in Profile J files.) 2028 Note: A T.82 decoder can decode a T.85 encoded image when it handles 2029 the NEWLE marker code as described Corrigendum 1 in [T.85]. 2031 5.3. Recommended TIFF Fields 2033 See Section 2.2.3 and 2.2.4. 2035 5.4. Profile J - Lossless JBIG Black-and-white Fax Profile Summary 2037 Recommended fields are shown with an asterisk *. 2039 Required fields or values are shown with a double asterisk **. If the 2040 double asterisk is on the field name, then all the listed values are 2041 required of implementations; if the double asterisks are in the 2042 Values column, then only the values suffixed with a double asterisk 2043 are required of implementations. 2045 +---------------------------+--------------------------------+ 2046 | Baseline Fields | Values | 2047 +---------------------------+--------------------------------+ 2048 | BitsPerSample | 1** | 2049 +---------------------------+--------------------------------+ 2050 | Compression | 9**: JBIG coding | 2051 +---------------------------+--------------------------------+ 2052 | DateTime* | {ASCII}: date/time in 24-hour | 2053 | | format "YYYY:MM:DD HH:MM:SS" | 2054 +---------------------------+--------------------------------+ 2055 | FillOrder** | 1: most significant bit first | 2056 | | 2: least significant bit first | 2057 +---------------------------+--------------------------------+ 2058 | ImageDescription* | {ASCII}: A string describing | 2059 | | the contents of the image. | 2060 +---------------------------+--------------------------------+ 2061 +---------------------------+--------------------------------+ 2062 | ImageWidth | 1728**, 2048, 2432, 2592, | 2063 | | 3072, 3456, 3648, 4096, 4864 | 2064 +---------------------------+--------------------------------+ 2065 | ImageLength** | n: total number of scanlines | 2066 | | in image | 2067 +---------------------------+--------------------------------+ 2068 | NewSubFileType** | 2: Bit 1 identifies single | 2069 | | page of a multi-page document | 2070 +---------------------------+--------------------------------+ 2071 | Orientation | 1**-8, Default 1 | 2072 +---------------------------+--------------------------------+ 2073 | PhotometricInterpretation | 0: pixel value 1 means black | 2074 | ** | 1: pixel value 1 means white | 2075 +---------------------------+--------------------------------+ 2076 | ResolutionUnit** | 2: inch | 2077 | | 3: centimeter | 2078 +---------------------------+--------------------------------+ 2079 | RowsPerStrip** | n: number of scanlines per | 2080 | | TIFF strip | 2081 +---------------------------+--------------------------------+ 2082 | SamplesPerPixel** | 1 | 2083 +---------------------------+--------------------------------+ 2084 | Software* | {ASCII}: name & release | 2085 | | number of creator software | 2086 +---------------------------+--------------------------------+ 2087 | StripByteCounts** | : number of bytes in TIFF | 2088 | | strip | 2089 +---------------------------+--------------------------------+ 2090 | StripOffsets** | : offset from beginning of | 2091 | | file to each TIFF strip | 2092 +---------------------------+--------------------------------+ 2093 | XResolution | 200, 204**, 300, 400, 408 | 2094 | | (written in pixels/inch) | 2095 +---------------------------+--------------------------------+ 2096 | YResolution | 98**, 196**, 100, | 2097 | | 200, 300, 391, 400 | 2098 | | (written in pixels/inch) | 2099 +---------------------------+--------------------------------+ 2100 | Extension Fields | 2101 +---------------------------+--------------------------------+ 2102 | DocumentName* | {ASCII}: name of document | 2103 | | scanned | 2104 +---------------------------+--------------------------------+ 2105 | PageNumber** | n,m: page number followed by | 2106 | | total page count | 2107 +---------------------------+--------------------------------+ 2108 | New Fields | 2109 +---------------------------+--------------------------------+ 2110 | GlobalParametersIFD* | IFD: global parameters IFD | 2111 +---------------------------+--------------------------------+ 2112 +---------------------------+--------------------------------+ 2113 | T82Options** | 0: T.85 profile of T.82 | 2114 +---------------------------+--------------------------------+ 2115 | ProfileType* | n: type of data stored in file | 2116 +---------------------------+--------------------------------+ 2117 | FaxProfile* | n: ITU-compatible fax profile | 2118 +---------------------------+--------------------------------+ 2119 | CodingMethods* | n: compression algorithms used | 2120 | | in file | 2121 +---------------------------+--------------------------------+ 2123 6. Profile C - Base Color Fax profile 2125 6.1. Overview 2127 This section defines the lossy color profile or Profile C of TIFF for 2128 facsimile. Implementations of this profile are required to also 2129 implement Profile S. 2131 This is the base profile for color and grayscale facsimile, which 2132 means that all applications that support color fax must support this 2134 profile. The basic approach is the lossy JPEG compression [T.4, Annex 2135 E; T.81] of L*a*b* color data [T.42]. Grayscale applications use the 2137 L* lightness component; color applications use the L*, a* and b* 2138 components. 2140 This profile uses a new PhotometricInterpretation field value to 2141 describe the L*a*b* encoding specified in [T.42]. This encoding 2142 differs in two ways from the other L*a*b* encodings used in TIFF 2143 [TIFF, TTN1]: it specifies a different default range for the a* and 2144 b* components, based on a comprehensive evaluation of existing 2145 hardcopy output, and it optionally allows selectable range for the 2146 L*, a* and b* components. 2148 6.2. Required TIFF Fields 2150 This section lists the required fields, in addition to those given in 2151 Section 2.2.1, and the values they must support to be compatible with 2152 ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4. 2154 6.2.1. Baseline Fields 2156 ImageWidth(256). SHORT or 2157 LONG 2158 This profile supports the following fixed page widths: 864, 1024, 2159 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864. 2161 NewSubFileType(254) = (Bit 1=1). 2162 LONG 2163 RequiredByTIFFforFAX 2164 Bit 1 is 1 if the image is a single page of a multi-page document. 2165 Default = 0 (no subfile bits on, so may not be omitted for fax) 2167 BitsPerSample(258) = 8. SHORT 2168 Count = SamplesPerPixel 2169 The base color fax profile requires 8 bits per sample. 2171 Compression(259) = 7. 2172 SHORT 2173 Base color fax profile uses Baseline JPEG compression. Value 7 2174 represents JPEG compression as specified in [TTN2]. 2176 FillOrder(266) = 1 , 2. 2177 SHORT 2178 RequiredByTIFFBaseline 2179 Profile C readers must be able to read data in both bit orders, 2180 but the vast majority of facsimile products store data LSB 2181 first, exactly as it appears on the telephone line. 2182 1 = Most Significant Bit first. 2183 2 = Least Significant Bit first 2185 PhotometricInterpretation(262) = 10. 2186 SHORT 2187 Base color fax profile requires pixel values to be stored using the 2188 CIE L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is 2189 indicated by the PhotometricInterpretation value 10, referred to as 2190 ITULAB. With this encoding, the minimum sample value is mapped to 0 2191 and the maximum sample value is mapped to (2^n - 1), i.e. the 2192 maximum value, where n is the BitsPerSample value. The conversion 2193 from unsigned ITULAB-encoded samples values to signed CIE L*a*b* 2194 values is determined by the Decode field; see Sec. 6.2.3 2196 NOTE: PhotometricInterpretation values 8 and 9 specify encodings for 2197 use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1] 2198 data, but they are fixed encodings, which use different minimum and 2199 maximum samples than the T.42 default encoding. As currently defined, 2200 they are not able to represent fax-encoded L*a*b* data. 2202 ResolutionUnit(296) = 2. 2203 SHORT 2204 The unit of measure for resolution. 2 = inch 2205 ITU-T standards only specify inch-based resolutions for color fax 2206 Default = 2 (field may be omitted if this is the value) 2208 SamplesPerPixel(277) = 1, 3. 2209 SHORT 2210 1: L* component only, required in base color profile 2211 3: L*, a*, b* components 2212 Encoded according to PhotometricInterpretation field 2214 XResolution(282) = 100, 200, 300, 400. 2215 RATIONAL 2216 YResolution(283) = 100, 200, 300, 400. 2217 RATIONAL 2218 The resolution of the image is expressed in pixels per resolution 2219 unit. In pixels per inch, allowed XResolution values are: 100, 200, 2220 300, and 400. The base color fax profile requires the pixels to be 2221 square, hence YResolution must equal XResolution. Base resolution is 2222 200 pixels per inch and SHALL be supported by all implementations of 2223 this profile. 2225 NOTE: The functional equivalence of inch-based and metric-based resolu- 2226 tions is maintained, per Annex E.6.5 in [T.4]. See table in Sec. 2.2.2. 2228 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 2229 are legal. The following table gives the legal combinations for inch- 2230 based resolutions and the corresponding paper sizes [T.30]. 2232 +--------------------------------+---------------------------+ 2233 | XResolution x YResolution | ImageWidth | 2234 +--------------------------------+---------------------------+ 2235 | 100 x 100 | 864 | 1024 | 1216 | 2236 +--------------------------------+---------------------------+ 2237 | 200 x 200 | 1728 | 2048 | 2432 | 2238 +--------------------------------+---------------------------+ 2239 | 300 x 300 | 2592 | 3072 | 3648 | 2240 +--------------------------------+---------------------------+ 2241 | 400 x 400 | 3456 | 4096 | 4864 | 2242 +--------------------------------+---------------------------+ 2243 |Letter,A4| B4 | A3 | 2244 | Legal | | | 2245 +---------------------------+ 2246 | Paper Size | 2247 +---------------------------+ 2249 6.2.2 Extension Fields 2251 The JPEG compression standard allows for the a*b* chroma components of 2252 an image to be subsampled relative to the L* lightness component. The 2253 extension fields ChromaSubSampling and ChromaPositioning define the 2254 subsampling. They are the same as YCbCrSubSampling and YCbCrPositioning 2255 in [TIFF], but have been renamed to reflect their applicability to 2256 other color spaces. 2258 ChromaSubSampling(530). 2259 SHORT 2260 Count = 2 2261 Specifies the subsampling factors for the chroma components of a 2262 L*a*b* image. The two subfields of this field, ChromaSubsampleHoriz 2263 and ChromaSubsampleVert, specify the horizontal and vertical 2264 subsampling factors respectively. 2266 SHORT 0: ChromaSubsampleHoriz = 1, 2. 2267 1: equal numbers of lightness and chroma samples horizontally, 2268 2: twice as many lightness samples as chroma samples horizontally, 2270 SHORT 1: ChromaSubsampleVert = 1, 2. 2271 1: equal numbers of lightness and chroma samples vertically, 2272 2: twice as many lightness samples as chroma samples vertically, 2274 The default value for ChromaSubSampling is (2,2), which is the 2275 default for chroma subsampling in color fax [T.4, Annex E]. No 2276 chroma subsampling, i.e. ChromaSubSampling = (1,1), is an option 2277 for color fax 2279 ChromaPositioning(531) = 1. 2280 SHORT 2281 Specifies the spatial positioning of chroma components relative to 2282 the lightness component. 2283 1: centered, 2284 A value of 1 means chrominance samples are spatially offset and 2285 centered with respect to luminance samples. See the current TIFF 2286 specification under YcbCr positioning for further information. 2287 Default = 1, which is what ITU-T T.4, Annex E specifies. 2289 6.2.3. New Fields 2291 Decode(433). 2292 SRATIONAL 2293 Count = 2 * SamplesPerPixel 2294 Describes how to map image sample values into the range of values 2295 appropriate for the current color space. In general, the values are 2296 taken in pairs and specify the minimum and maximum output value for 2297 each color component. For the base color fax profile, Decode has a 2298 count of 6 values and maps the unsigned ITULAB-encoded sample 2299 values 2300 (Lsample, asample, bsample) to signed L*a*b* values, as follows:. 2302 L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1) 2303 a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1) 2304 b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1) 2306 where Decode[0], Decode[2] and Decode[4] are the minimum values for 2307 L*, a* and b*; Decode[1], Decode[3] and Decode[5] are the maximum 2308 values for L*, a* and b*; and n is the BitsPerSample. When 2309 n=8,=20 L*=Decode[0] when Lsample=0 and L*=Decode[1] when 2310 Lsample=255. 2312 ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range 2313 and offset for each component, which are related to the minimum and 2314 maximum values as follows: 2316 minimum = - (range x offset) / 2^n - 1 2317 maximum = minimum + range 2319 The Decode field default values depend on the color space. For the 2320 ITULAB color space encoding, the default values correspond to the 2321 base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The 2322 following table gives the base range and offset values for 2323 BitsPerSample=8, and the corresponding default minimum and 2324 maximum default values for the Decode field, calculated using the 2325 equations above when PhotometricInterpetation=10. 2327 Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset, 2328 and hence the minimum and maximum values, for other BitsPerSample 2329 values. 2331 +-----------------------------------------------+ 2332 | ITU-T Rec. T.42 | Decode 2333 | 2334 +---------+-----------| base values | default values 2335 | 2336 | BitsPer + Component 2337 +------------------+----------------------------+ 2338 | -Sample | | Range | Offset | Min | Max 2339 | 2341 +---------+-----------+--------+---------+--------------+-------------+ 2342 | 8 | L* | 100 | 0 | 0 | 100 2343 | 2344 | 2345 +-----------+--------+---------+--------------+-------------+ 2346 | | a* | 170 | 128 | -21760/255 | 21590/255 2347 | 2348 | 2349 +-----------+--------+---------+--------------+-------------+ 2350 | | b* | 200 | 96 | -19200/255 | 31800/255 2351 | 2353 +---------+-----------+--------+---------+--------------+-------------+ 2355 For example, when PhotometricInterpretation=10 and BitsPerSample=8, 2356 the default value for Decode is (0, 100, -21760/255, 21590/255, 2357 -19200/255, 31800/255). For guidelines on the use of the Decode field, 2358 see section 5.2.2 of [GUIDE]. 2360 6.3. Recommended TIFF Fields 2362 See Sections 2.2.3. and 2.2.4. 2364 6.4 Profile C - Base Color Fax Profile Summary 2366 Recommended fields are shown with an asterisk * 2368 Required fields or values are shown with a double asterisk **. If the 2369 double asterisk is on the field name, then all the listed values are 2370 required of implementations; if the double asterisks are in the 2371 Values column, then only the values suffixed with a double asterisk 2372 are required of implementations. 2374 +---------------------------+--------------------------------+ 2375 | Baseline Fields | Values | 2376 +---------------------------+--------------------------------+ 2377 | BitsPerSample | 8**: 8 bits per color sample | 2378 +---------------------------+--------------------------------+ 2379 | Compression** | 7: JPEG | 2380 +---------------------------+--------------------------------+ 2381 | DateTime* | {ASCII}: date/time in 24-hour | 2382 | | format "YYYY:MM:DD HH:MM:SS" | 2383 +---------------------------+--------------------------------+ 2384 +------------------------------------------------------------+ 2385 | FillOrder** | 1: most significant bit first | 2386 | | 2: least significant bit first | 2387 +---------------------------+--------------------------------+ 2388 | ImageDescription* | {ASCII}: A string describing | 2389 | | the contents of the image. | 2390 +---------------------------+--------------------------------+ 2391 | ImageWidth | 864, 1024, 1216, 1728**, 2048 | 2392 | | 2432, 2592, 3072, 3456, 3648 | 2393 | | 4096, 4864 | 2394 +---------------------------+--------------------------------+ 2395 | ImageLength** | n: total number of scanlines | 2396 | | in image | 2397 +---------------------------+--------------------------------+ 2398 | NewSubFileType** | 2: Bit 1 identifies single page| 2399 | | of a multi-page document | 2400 +---------------------------+--------------------------------+ 2401 | Orientation | 1**-8, Default 1 | 2402 +---------------------------+--------------------------------+ 2403 | PhotometricInterpretation | 10**: ITULAB | 2404 +---------------------------+--------------------------------+ 2405 | ResolutionUnit** | 2: inch | 2406 +---------------------------+--------------------------------+ 2407 | RowsPerStrip** | n: number of scanlines per | 2408 | | TIFF strip | 2409 +---------------------------+--------------------------------+ 2410 | SamplesPerPixel | 1**: L* (lightness) | 2411 | | 3: LAB | 2412 +---------------------------+--------------------------------+ 2413 | Software* | {ASCII}: name & release number | 2414 | | of creator software | 2415 +---------------------------+--------------------------------+ 2416 | StripByteCounts** | : number or bytes in | 2417 | | TIFF strip | 2418 +---------------------------+--------------------------------+ 2419 | StripOffsets** | : offset from beginning | 2420 | | of file to each TIFF strip | 2421 +---------------------------+--------------------------------+ 2422 | XResolution | 100, 200**, 300, 400 (written | 2423 | | in pixels/inch) | 2424 +---------------------------+--------------------------------+ 2425 | YResolution | 100, 200**, 300, 400 | 2426 | | (must equal XResolution) | 2427 +---------------------------+--------------------------------+ 2428 +---------------------------+--------------------------------+ 2429 | Extension Fields | 2430 +---------------------------+--------------------------------+ 2431 | DocumentName* | {ASCII}: name of scanned | 2432 | | document | 2433 +---------------------------+--------------------------------+ 2434 | PageNumber** | n,m: page number followed by | 2435 | | total page count | 2436 +---------------------------+--------------------------------+ 2437 | ChromaSubSampling | (1,1), (2, 2)** | 2438 | | (1, 1): equal numbers of | 2439 | | lightness and chroma samples | 2440 | | horizontally and vertically | 2441 | | (2, 2): twice as many lightness| 2442 | | samples as chroma samples | 2443 | | horizontally and vertically | 2444 +---------------------------+--------------------------------+ 2445 | ChromaPositioning | 1**: centered | 2446 +---------------------------+--------------------------------+ 2447 | New Fields | 2448 +---------------------------+--------------------------------+ 2449 | Decode** | minL, maxL, mina, maxa, minb, | 2450 | | maxb: minimum and maximum | 2451 | | values for L*a*b* | 2452 +---------------------------+--------------------------------+ 2453 | GlobalParametersIFD* | IFD: IFD containing | 2454 | | global parameters | 2455 +---------------------------+--------------------------------+ 2456 | ProfileType* | n: type of data stored in | 2457 | | TIFF file | 2458 +---------------------------+--------------------------------+ 2459 | FaxProfile* | n: ITU-compatible fax profile | 2460 +---------------------------+--------------------------------+ 2461 | CodingMethods* | n: compression algorithms | 2462 | | used in file | 2463 +---------------------------+--------------------------------+ 2464 | VersionYear* | byte sequence: year of ITU std | 2465 +---------------------------+--------------------------------+ 2467 7. Profile L - Lossless Color Profile 2469 This section defines the lossless color profile or Profile L of TIFF 2471 for facsimile. Implementations of this profile are required to also 2472 implement Profiles S and C. 2474 7.1. Overview 2476 This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to 2477 losslessly code three types of color and grayscale images: one bit 2478 per color CMY, CMYK and RGB images; a palettized (i.e. mapped) color 2479 image; and continuous tone color and grayscale images. The last two 2480 are multi-level and use the L*a*b* encoding specified in [T.42]. 2482 7.1.1. Color Encoding 2484 While under development, ITU-T Rec. T.43 was called T.Palette, as one 2485 of its major additions was palette or mapped color images. Baseline 2486 TIFF only allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* 2488 color maps, using the encoding specified in ITU-T Rec. T.42. Palette 2490 color images are expressed with indices (bits per sample) of 12 bits 2492 or less, or optionally 13 to 16 bits, per [T.43] and Annex G in 2493 [T.4]. Profile L files use the color table in the T.43 data stream 2494 rather than the TIFF ColorMap field. 2496 Enabling T.43 color maps in TIFF requires the extension field 2497 Indexed, defined in [TTN1], and the PhotometricInterpretation field 2498 value 10, defined in Section 6.2.1. The following table shows the 2499 corresponding PhotometricInterpretation, SamplesPerPixel, 2500 BitsPerSample and Indexed field values for the different T.43 image 2501 types. 2503 +----------------------------------------------------------+ 2504 | Image Type |PhotometricIn| Samples | Bits Per | Indexed | 2505 | |-terpretation| PerPixel | Sample | | 2506 |------------+-------------+----------+----------+---------| 2507 | RGB | 2=RGB | 3 | 1 | 0 | 2508 +----------------------------------------------------------+ 2509 | CMY | 5=CMYK | 3 | 1 | 0 | 2510 +------------+-------------+----------+----------+---------+ 2511 | CMYK | 5=CMYK | 4 | 1 | 0 | 2512 +------------+-------------+----------+----------+---------+ 2513 | Palette | 10=ITULAB | 1 | n | 1 | 2514 +------------+-------------+----------+----------+---------+ 2515 | Grayscale | 10=ITULAB | 1 |2-8, 9-12 | 0 | 2516 +------------+-------------+----------+----------+---------+ 2517 | Color | 10=ITULAB | 3 |2-8, 9-12 | 0 | 2518 +------------+-------------+----------+----------+---------+ 2520 7.1.2. JBIG Compression 2522 T.43 uses the single-progression sequential mode of JBIG, defined in 2523 ITU-T Rec. T.82. (Other compression methods are for further study.) 2524 To code multi-level images using JBIG, which is a bi-level 2525 compression method, an image is resolved into a set of bit-planes, 2526 and each bit-plane is then JBIG compressed. For continuous tone 2527 color 2528 and grayscale images, Gray code conversion is used. The Gray code 2529 conversion is part of the data stream encoding, and is therefore 2530 invisible to TIFF. 2532 7.2. Required TIFF Fields 2534 This section lists the required fields, in addition to those in 2535 Section 2.2.1, and the values they must have to be compatible with 2536 ITU-T Rec. T.43. 2538 7.2.1. Baseline Fields 2540 ImageWidth(256). SHORT or 2541 LONG 2542 Same page widths as the base color profile; see Section 6.2.1. 2544 NewSubFileType(254) = (Bit 1=1). 2545 LONG 2546 RequiredByTIFFforFAX 2547 Bit 1 is 1 if the image is a single page of a multi-page document. 2548 Default = 0 (no subfile bits on, so may not be omitted for fax) 2550 BitsPerSample(258) = 1, 2-8, 9-12. 2551 SHORT 2552 Count = SamplesPerPixel 2553 RGB, CMY, CMYK: 1 bit per sample 2554 Continuous tone (L*a*b*): 2-8 bits per sample, 9-12 bits optional 2555 Palette color: 12 or fewer bits per sample 2556 Note: More than 8 bits per sample is not baseline TIFF. 2558 Compression(259) = 10. 2559 SHORT 2560 10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG) 2561 coding 2563 FillOrder(266) = 1 , 2. 2564 SHORT 2565 RequiredByTIFFBaseline 2566 Profile L readers must be able to read data in both bit orders, 2567 but the vast majority of facsimile products store data LSB 2568 first, exactly as it appears on the telephone line. 2569 1 = Most Significant Bit first. 2570 2 = Least Significant Bit first 2572 PhotometricInterpretation(262) = 2, 5, 10. 2573 SHORT 2574 2: RGB 2575 5: CMYK, including CMY 2576 10: ITULAB 2577 Image data may also be stored as palette color images, where pixel 2578 values are represented by a single component that is an index into a 2579 color map using the ITULAB encoding. This color map is specified by 2580 the color palette table embedded in the image data stream. To use 2581 palette color images, set the PhotometricInterpretation to 10, 2582 SamplesPerPixel to 1, Indexed to 1, and use the color map in the 2583 data stream. See Section 7.1.1 for discussion of the color encoding. 2585 ResolutionUnit(296) = 2. SHORT 2586 The unit of measure for resolution. 2 = inch. 2587 ITU-T standards only specify inch-based resolutions for color fax 2588 Default = 2 (field may be omitted if this is the value) 2590 SamplesPerPixel(277) = 1, 3, 4. 2591 SHORT 2592 1: Palette color image, or L*-only if Indexed = 0 and 2593 PhotometricInterpretation is 10 (ITULAB). 2594 3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK). 2595 4: CMYK. 2597 XResolution(282) = 100, 200, 300, 400. 2598 RATIONAL 2599 YResolution(283) = 100, 200, 300, 400. 2600 RATIONAL 2601 The resolution of the image is expressed in pixels per resolution 2602 unit. In pixels per inch, allowed XResolution values are: 100, 200, 2603 300, and 400. The lossless color fax profile requires the pixels to 2604 be square, hence YResolution must equal XResolution. Base 2605 resolution 2606 is 200 pixels per inch. 2608 7.2.2. Extension Fields 2610 Indexed(346) = 0, 1. 2611 SHORT 2612 0: not a palette-color image 2613 1: palette-color image 2614 This field is used to indicate that each sample value is an index 2615 into an array of color values specified in the image data stream. 2616 Because the color map is embedded in the image data stream, the 2617 ColorMap field is not used in Profile L. Lossless color fax 2618 profile supports palette-color images with the ITULAB encoding. The 2619 SamplesPerPixel value must be 1. 2621 7.2.3. New Fields 2623 Decode(433) 2624 SRATIONAL 2625 Decode is used in connection with the ITULAB encoding of image 2626 data; 2627 see Section 6.2.3. 2629 7.3. Recommended TIFF Fields 2631 See Sections 2.2.3. and 2.2.4. 2633 7.4. Profile L - Lossless Color Fax Profile Summary 2635 Recommended fields are shown with an asterisk *. 2637 Required fields or values are shown with a double asterisk **. If the 2638 double asterisk is on the field name, then all the listed values are 2639 required of implementations; if the double asterisks are in the 2640 Values column, then only the values suffixed with a double asterisk 2641 are required of implementations. 2643 +--------------------+--------------------------------------+ 2644 | Baseline Fields | Values | 2645 +--------------------+--------------------------------------+ 2646 | BitsPerSample | 1: Binary RGB, CMY(K) | 2647 | | 8**: 8 bits per color sample | 2648 | | 9-12: optional | 2649 +--------------------+--------------------------------------+ 2650 | Compression | 10**: JBIG, per T.43 | 2651 +--------------------+--------------------------------------+ 2652 | DateTime* | {ASCII}: date/time in the 24-hour | 2653 | | format "YYYY:MM:DD HH:MM:SS" | 2654 +--------------------+--------------------------------------+ 2655 | FillOrder** | 1: Most significant bit first | 2656 | | 2: Least significant bit first | 2657 +--------------------+--------------------------------------+ 2658 | ImageDescription* | {ASCII}: A string describing the | 2659 | | contents of the image. | 2660 +--------------------+--------------------------------------+ 2661 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 2662 | | 2592, 3072, 3456, 3648, 4096, 4864 | 2663 +--------------------+--------------------------------------+ 2664 | ImageLength** | n: total number of scanlines in image| 2665 +--------------------+--------------------------------------+ 2666 | NewSubFileType | 2**: Bit 1 identifies single page of | 2667 | | a multi-page document | 2668 +--------------------+--------------------------------------+ 2669 +--------------------+--------------------------------------+ 2670 | Orientation | 1**-8, Default 1 | 2671 +--------------------+--------------------------------------+ 2672 | PhotometricInter- | 2: RGB | 2673 | pretation | 5: CMYK | 2674 | | 10**: ITULAB | 2675 +--------------------+--------------------------------------+ 2676 | ResolutionUnit** | 2: inch | 2677 +--------------------+--------------------------------------+ 2678 | RowsPerStrip** | n: number of scanlines per TIFF strip| 2679 +--------------------+--------------------------------------+ 2680 | SamplesPerPixel | 1**: L* (lightness) | 2681 | | 3: LAB, RGB, CMY | 2682 | | 4: CMYK | 2683 +--------------------+--------------------------------------+ 2684 | Software* | {ASCII}: name & release number of | 2685 | | creator software | 2686 +--------------------+--------------------------------------+ 2687 | StripByteCounts** | : number or bytes in TIFF strip | 2688 +--------------------+--------------------------------------+ 2689 | StripOffsets** | : offset from beginning of file to| 2690 | | each TIFF strip | 2691 +--------------------+--------------------------------------+ 2692 | XResolution | 100, 200**, 300, 400 (pixels/inch) | 2693 +--------------------+--------------------------------------+ 2694 | YResolution | equal to XResolution (pixels must be | 2695 | | square) | 2696 +--------------------+--------------------------------------+ 2697 | Extension Fields | 2698 +--------------------+--------------------------------------+ 2699 | DocumentName* | {ASCII}: name of scanned document | 2700 +--------------------+--------------------------------------+ 2701 | PageNumber** | n,m: page number followed by total | 2702 | | page count | 2703 +--------------------+--------------------------------------+ 2704 | Indexed | 0: not a palette-color image | 2705 | | 1: palette-color image | 2706 +--------------------+--------------------------------------+ 2707 | New Fields | 2708 +--------------------+--------------------------------------| 2709 | Decode | minL, maxL, mina, maxa, minb, maxb: | 2710 | | minimum and maximum values for L*a*b*| 2711 +--------------------+--------------------------------------+ 2712 | GlobalParameters | IFD: global parameters IFD | 2713 | IFD* | | 2714 +-----------------------------------------------------------+ 2715 +--------------------+--------------------------------------+ 2716 | ProfileType* | n: type of data stored in TIFF file | 2717 +--------------------+--------------------------------------+ 2718 | FaxProfile* | n: ITU-compatible fax profile | 2719 +--------------------+--------------------------------------+ 2720 | CodingMethods* | n: compression algorithms used in | 2721 | | file | 2722 +--------------------+--------------------------------------+ 2723 | VersionYear* | byte sequence: year of ITU fax std | 2724 +--------------------+--------------------------------------+ 2726 8. Profile M - Mixed Raster Content Profile 2728 This section defines the Mixed Raster Content profile or Profile M 2729 of TIFF for facsimile. Implementations of this profile are required 2730 To implement Profiles S and C, and may optionally implement Profiles 2731 F, J and L. 2733 8.1. Overview 2735 Unlike previous fax profiles, which use a single coding method and 2736 resolution for an entire fax page, Mixed Raster Content [T.44] 2737 enables different coding methods and resolutions within a single 2738 page. For example, consider a page that contains black-and-white 2739 text, which is best coded with MMR or JBIG, a color bar chart, best 2740 coded with JBIG, and a scanned color image, best coded with JPEG. 2741 Similarly, while spatial resolution of 400 pixels per inch may be 2742 best for the black-and- white text, 200 pixel per inch is usually 2743 sufficient for a color image. 2745 Rather than applying one coding method and resolution to all 2746 elements, MRC allows multiple coders and resolutions within a page. 2747 By itself, MRC does not define any new coding methods or 2748 resolutions. Instead it defines a 3-layer image model for 2749 structuring and combining the scanned image data. The MRC 3-layer 2750 model has been applied here using the TIFF format to yield a data 2751 structure which differs from [T.44] though it applies the same 2752 coding methods, uses the same compressed image data streams and is 2753 consistent with the TIFF principle of a single IFD per image. 2755 8.1.1. MRC 3-layer model 2757 The 3 layers of the MRC model are Foreground and Background, which 2758 are both multi-level, and Mask, which is bi-level. Each layer may 2759 appear only once on a page and is coded independently of the other 2760 two layers. The final image is obtained by using the Mask layer to 2761 determine if output pixels come from the Foreground layer or the 2762 Background layer. When the Mask layer pixel value is 1, the 2763 corresponding pixel from the Foreground layer is selected; when it 2764 is 0, the corresponding pixel from the Background layer is selected. 2765 Details are given in the Introduction of [T.44]. 2767 In our earlier example, the shape of the black-and-white text and 2768 the mask for the color chart could be in the Mask layer, the color 2769 of the chart and text in the Foreground layer, and the color image 2770 in the Background layer. If a Mask layer pixel has a value of 1, 2771 the final image pixel will be, depending on the pixel location, from 2772 either the color chart or text color in the Foreground layer. If a 2773 Mask layer pixel has a value of 0, the final image pixel will be 2774 from the color image in the Background layer. 2776 Each layer is an image and, when present, is represented by at least 2777 one IFD in a TIFF file. This is consistent with TIFF, which provides 2778 fields to define the attributes, such as resolution, image size, 2779 bits per sample, etc., of a single image or layer. The distribution 2780 of content among layers is determined by the writer, as is the 2781 choice of coding method, color encoding and spatial resolution for a 2782 layer. 2784 Not all pages, and not all parts of a page, require 3 layers. If a 2785 page consists of only one layer, then that layer is the primary 2786 image whether it is a Background, Mask, or Foreground layer. If 2787 there is more than one layer, then the Mask must be one of the 2788 layers, in which case it is the primary image. In all cases, the 2789 primary image must be page size. 2791 MRC [T.44] allows a page to be transmitted as a series of stripes 2792 with each stripe consisting of 1, 2 or 3 layers. The number of 2793 scanlines in each stripe can vary over the page. Although [T.44] 2794 does not allow overlap between images of a single layer, the MRC 2795 profile permits overlapping IFDs when one of the IFDs is used only 2796 to define a default image color. According to [T.4] Annex H, stripes 2797 having more than 1 layer SHOULD NOT be more than 256 lines in length 2798 unless the capability to receive longer stripes has been negotiated. 2800 Furthermore, color fax also requires the spatial resolutions of 2801 Background and Foreground images to be legal fax values that are 2802 also integer factors of the Mask image resolution. For example, if 2803 the Mask Layer resolution is 400 pixels per inch, then allowed 2804 resolutions for the Foreground and Background layers are 100, 200 or 2805 400 pixels per inch; if the Mask is at 300 pixels per inch, then 2806 allowed values are 100 and 300. The Foreground and Background layer 2807 resolutions can be independently set of each other. 2809 8.1.2. A TIFF Representation for the MRC 3-layer model 2811 In the TIFF representation of the 3-layer MRC model, each page is 2812 represented by a single IFD, called the Primary IFD. The nextIFD 2813 offset associated with a Primary IFD will point to the Primary IFD 2814 of the next page. If the page consists of a single layer, then the 2815 Primary IFD represents that layer. If more than one layer is present, 2816 the Primary IFD represents the Mask layer and the other layers are 2817 represented by a set of child IFDs that are referenced through the 2818 SubIFD extension field [TTN1] of the Primary IFD. To distinguish MRC- 2819 specific SubIFDs from other SubIFDs, the NewSubFileType field MUST 2820 have Bit 4 ON, indicating an MRC-related IFD. A new ImageLayer field 2821 is also introduced that consists of two values that identify the 2822 layer (Foreground, Background, or Mask) and the order within the 2823 layer (first, second, ... image of the layer); see Section 8.2.3 2825 In Profile M, the Primary IFD represents a complete layer and 2826 corresponds to the primary image described in Section 8.1.1. There 2827 must be no other MRC-related IFDs or SubIFDs that contain image data 2828 corresponding to the layer represented by the Primary IFD. 2830 MRC [T.44] allows a page to be transmitted as a series of stripes. A 2831 strip within an IFD in a Profile M file represents a stripe in a 2832 [T.44] data stream. The [T.44] stripes of the Primary image are 2833 represented by a single, multiple-strip IFD; the [T.44] stripes of 2834 other layers are represented as multiple, single-strip IFDs. 2836 The layer represented by the Primary IFD may consist of strips of 2837 image data, but all the strips must be part of the single Primary 2838 IFD. For example, if the page consisted of only the Background 2839 layer, then all strips associated with the Background layer must be 2840 treated as a single image. Because MRC allows stripes with variable 2841 numbers of scanlines, a reader MUST support StripRowCounts field 2842 because a writer may use it in place of the RowsPerStrip field to 2843 support a variable number of scanlines in each strip of the Primary 2844 IFD. In accordance with [TTN2], each strip shall be independently 2845 encoded, but coding parameters may not change between strips. 2847 Layers other than the layer represented by the Primary IFD store 2848 each strip as a separate IFD, allowing the coding parameters to 2849 change from strip-to-strip as described by the MRC standard [T.44]. 2850 In all cases, if the Mask layer exists, it shall be represented by a 2851 single IFD and a single set of coding parameters. 2853 The use of SubIFDs to store child IFDs is described in [TTN1]. When 2854 the Mask is the primary image, the Background and Foreground layer 2855 images are represented with child IFDs that are referenced by the 2856 SubIFDs field in the Primary IFD. There are many possible ways to 2857 represent the Background and Foreground layer images: (1) the 2858 SubIFD field of the Primary IFD is an array of pointers to all 2859 child image IFDs, one entry per child image; (2) the SubIFD field is 2860 a single pointer to a linked list of all child image IFDs; (3) the 2861 SubIFD field is an array of two pointers, where the first pointer is 2862 to a linked list of all Background layer image IFDs, and the second 2863 pointer is to a linked list of all Foreground layer image IFDs. A 2864 Profile M writer SHOULD structure the Background and Foreground 2865 layer images using (3), as shown in the example below. Furthermore, 2866 the child IFDs representing the Background and Foreground layer 2867 images SHOULD be ordered in the file in the same order as they occur 2868 on the page. However, a Profile M reader must scan all available 2869 child IFDs to locate and identify IFDs associated with MRC layers. 2871 (nextIFD) 2872 PRIMARY IFD PAGE 0 -----------------------> PRIMARY IFD PAGE 1--> ... 2873 ImageLayer = [2,1] 2874 NewSubFileType = 18 2875 SubIFD[0] ---------------------- SubIFD[1] 2876 | | 2877 V V 2878 Child IFD Child IFD 2879 ImageLayer = [1,1] ImageLayer [3,1] 2880 NewSubFileType = 16 NewSubFileType 16 2881 | | 2882 |(nextIFD) |(nextIFD) 2883 V V 2884 Child IFD Child IFD 2885 ImageLayer = [1,2] ImageLayer [3,2] 2886 NewSubFileType = 16 NewSubFileType 16 2887 | | 2888 |(nextIFD) |(nextIFD) 2889 V V 2890 Child IFD Child IFD 2891 ImageLayer = [1,3] ImageLayer [3,3] 2892 NewSubFileType = 16 NewSubFileType 16 2893 | | 2894 |(nextIFD) |(nextIFD) 2895 V V 2896 0 0 2898 The XPosition and YPosition TIFF fields specify the offset to the 2899 upper-left corner of the IFD in resolution units, which are inches 2900 in Profile M; see Section 8.2.2. The Primary IFD must not use 2901 XPosition or YPosition fields. 2903 MRC [T.44] allows the specification of a default image color that is 2904 to be applied in the event no image data is transmitted for a given 2905 stripe and layer. The new field ImageBaseColor is used to store 2906 default image color specifications in Profile M, see 8.2.3. By 2907 setting the StripByteCounts array to zero values, an IFD defining a 2908 default color but containing no encoded image data can be specified. 2909 ImageBaseColor can also be used in IFDs that contain encoded image 2910 data. In that case, the fields of the IFD must accurately reflect 2911 the encoding of the image data. If the StripByteCount entry for a 2912 given strip is 0, then the ImageBaseColor is used for that strip. If 2913 the encoded image data is ITU L*a*b, the ImageBaseColor is 2914 interpreted using the encoding parameters of the image data. If the 2915 image data is not ITU L*a*b*, the ImageBaseColor is interpreted as 2916 8-bit ITU L*a*b*; see Section 8.2.3. 2918 8.2. Required TIFF Fields 2920 This section describes the TIFF fields required, in addition to 2921 those in Section 2.2.1, to represent MRC fax images. Since MRC 2922 stores fax data as a collection of images corresponding to layers or 2923 parts of layers, the coding methods, color encodings and spatial 2924 resolutions used by previous profiles apply to Profile M. Therefore, 2925 the descriptions here will typically reference the appropriate 2926 earlier sections. Fields and values specific to Profile M are 2927 pointed out. 2929 8.2.1. Baseline Fields 2931 ImageWidth(256). SHORT or 2932 LONG 2933 Same page widths as Profile C, the base color profile; see Section 2934 6.2.1. In Profile M, the width of a Foreground or Background image 2935 in the coded data stream may be less than the page width, unless the 2936 Background or Foreground is the primary image, in which case the 2937 width of the coded data stream is the page width. The ImageWidth 2938 field will always store the actual width of the coded data. 2940 NewSubFileType(254) = 16, 18. 2941 LONG 2942 For Profile M, the NewSubFileType field has two bits that are 2943 required. Bit 1 indicates a single page of a multi-page document 2944 and must be set for the Primary IFD; Bit 4 indicates the MRC imaging 2945 model as described in ITU-T Recommendation T.44 [T.44], and must be 2946 set for Primary IFDs and all MRC-specific child IFDs. 2948 BitsPerSample(258) = 1, 2-8, 9-12 2949 SHORT 2950 SamplesPerPixel(277) = 1, 3, 4. 2951 SHORT 2952 Compression(259) = 1, 3, 4, 7, 9, 10. 2953 SHORT 2954 For Mask layer, see Sections 4.2.1 and 5.2.1 2955 For Foreground and Background layers, see Sections 6.2.1 and 7.2.1 2956 Compression=1 is not used by previous profiles. An IFD used only to 2957 specify the default image color for a layer and strip will not have 2958 any encoded image data associated with it, i.e., the StripByteCounts 2959 field will contain a 0. Since no image data exists in the IFD, the 2960 Compression field shall be set to 1 indicating no compression. A 2961 Compression field value of 1 is not allowed for any other IFDs. 2963 FillOrder(266) = 1 , 2. 2964 SHORT 2965 RequiredByTIFFBaseline 2966 Profile M readers must be able to read data in both bit orders, but 2967 the vast majority of facsimile products store data LSB first, 2968 exactly as it appears on the telephone line 2969 1 = Most Significant Bit first. 2970 2 = Least Significant Bit first 2972 PhotometricInterpretation(262) = 0, 2, 10. SHORT 2973 For Mask layer, 0. For Foreground and Background layers, see 2974 Sections 6.2.1 and 7.2.1. 2976 ResolutionUnit(296) = 2. 2977 SHORT 2978 The unit of measure for resolution. 2 = inch 2979 ITU-T standards only specify inch-based resolutions for color fax 2980 Default = 2 (field may be omitted if this is the value). 2982 StripByteCounts(279) SHORT or LONG 2983 In Profile M, it is permissible for the StripByteCounts value for a 2984 given strip to have a zero entry. This means there is no encoded 2985 image data corresponding to that strip. Instead, the current 2986 default image color should be used for the strip. The standard 2987 default image colors are black for the Foreground layer and White 2988 for the Background layer. The ImageBaseColor field can be used to 2989 specify other default colors, see 8.2.3. 2991 XResolution(282) = 100, 200, 300, 400. 2992 RATIONAL 2993 YResolution(283) = 100, 200, 300, 400. 2994 RATIONAL 2995 The resolution of the image is expressed in pixels per resolution 2996 unit. In pixels per inch, allowed XResolution values for all layers 2997 are: 100, 200, 300, and 400. Color fax requires the pixels to be 2998 square, hence YResolution must equal XResolution for all layers. The 2999 resolution of Background and Foreground layers must each be an 3000 integer factor of the Primary image, which is the Mask layer, when 3001 it is present; see Section 8.4. 3003 8.2.2. Extension Fields 3005 ChromaSubSampling(530). 3006 SHORT 3007 ChromaPositioning(531). 3008 SHORT 3009 For Foreground and Background layers, see Section 6.2.2. 3011 Indexed(346) = 0, 1. 3012 SHORT 3013 For Foreground and Background layers: 1 indicates a palette-color 3014 image, see Section 7.2.2. 3016 T4Options(292) = 0, 1, 4, 5. 3017 SHORT 3018 T6Options(293) = 0. 3019 SHORT 3020 For Mask layer, see Section 4.2.2. 3022 SubIFDs(330). 3023 IFD 3024 Count = number of child IFDs. Each value is an offset from the 3025 beginning of the TIFF file to a child IFD [TTN1]. 3027 XPosition(286). 3028 RATIONAL 3029 YPosition(287). 3030 RATIONAL 3031 Specifies the horizontal and vertical offsets of the top-left of the 3032 IFD from the top-left of the Primary IFD in resolution units. For 3033 example, if the Primary IFD is at 400 pixels per inch, and a 3034 foreground layer IFD is at 200 pixels per inch and located at pixel 3035 coordinate (345, 678) with respect to the Primary IFD, the XPosition 3036 value is 345/400 and the YPosition value is 678/400 in inches. 3038 The Primary IFD does not use the XPosition or YPosition fields. The 3039 XPosition and YPosition values must be specified for MRC child IFDs; 3040 there is no default value. 3042 8.2.3. New Fields 3044 Decode(433). 3045 SRATIONAL 3046 For Foreground and Background layers, see Section 6.2.3. 3048 T82Options(435) 3049 LONG 3050 For Mask layer, see Section 5.2.3. 3052 ImageBaseColor(434). 3053 SHORT 3054 Count = SamplesPerPixel 3055 In areas of an image layer where no image data is available (i.e. 3056 where no strips are defined, or where the StripByteCounts entry for 3057 a given strip is 0), the color specified by ImageBaseColor will be 3058 used. 3060 If the ImageBaseColor field is used in an IFD that contains image 3061 data encoded in ITU L*a*b*, then the ImageBaseColor will be 3062 interpreted with the color encoding parameters of the image data 3063 (i.e., color gamut, illuminant, bit/sample, and decode). If the 3064 ImageBaseColor field is used in an IFD that contains image data that 3065 is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be 3066 interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the 3067 ImageBaseColor field is used in an IFD that contains no encoded 3068 image data, then the ImageBaseColor SHALL be interpreted as 8 3069 bits/sample, 3 samples/pixel ITU L*a*b*. If the fax data stream 3070 requires a different encoding, then transferring the default color 3071 value between a TIFF file and fax data stream requires a color 3072 conversion. 3074 A [T.44] stripe may contain a Foreground or Background image less 3075 than full stripe size, with the rest of the stripe assuming a 3076 default image color. In this case, the default image color is imaged 3077 first, followed by the image data. In Profile M, this is represented 3078 as a child IFD containing no encoded image data but specifying the 3079 default image color in the ImageBaseColor field. A second child IFD 3080 contains the image data. To insure the default image color is imaged 3081 first, the order value in the ImageLayer field of the IFD defining 3082 the ImageBaseColor field MUST have a lower value than the order 3083 value in the ImageLayer field of the IFD defining the image data. 3085 To define a child IFD specifying a ImageBaseColor but containing no 3086 encoded image data, create an IFD with the following settings. 3088 ImageLayer[0]: specified layer 3089 ImageLayer[1]: less than any other IFDs corresponding 3090 to the same layer and strip. 3091 RowsPerStrip: strip height 3092 ImageLength: strip height 3093 ImageWidth: full image width 3094 BitsPerSample: 8 3095 PhotometricInterpretation: 10 (ITULAB) 3096 SamplesPerPixel: 3 3097 Compression: 1 (none) 3098 X/YResolution: that of the Primary IFD 3099 XPosition: 0 3100 YPosition: the offset from the top of the page to 3101 the beginning of the strip in the 3102 resolution units of inches 3103 StripByteCounts: single 0 value 3104 StripOffsets: single 0 entry 3105 NewSubFileType: bit 4 O (MRC) 3106 ImageBaseColor: desired color in 8 bit ITULAB 3108 For the Foreground layer image, the default value for the 3109 ImageBaseColor field is black. For other cases, including the 3110 Background layer image, the default value is white. 3112 StripRowCounts(559). 3113 LONG 3114 Count = number of strips 3115 The number of scanlines stored in a strip. Profile M allows each fax 3116 strip to store a different number of scanlines. For strips with more 3117 than one layer the maximum strip size is either 256 scanlines or 3118 full page size. The 256 maximum SHOULD be used unless the capability 3119 to receive longer strips has been negotiated. This field replaces 3120 RowsPerStrip for IFDs with variable-sized strips. Only one of the 3121 two fields, StripRowCounts and RowsPerStrip, may be used in an IFD. 3123 ImageLayer (34732). 3124 LONG 3125 Count = 2 3126 Image layers are defined such that layer 1 is the Background layer, 3127 layer 3 is the Foreground layer, and layer 2 is the Mask layer, 3128 which selects pixels from the Background and Foreground layers. The 3129 ImageLayer tag contains two values, describing the layer to which 3130 the image belongs and the order in which it is imaged. 3132 ImageLayer[0] = 1, 2, 3. 3133 1: Image is a Background image, i.e., the image that will appear 3134 whenever the Mask contains a value of 0. Background images 3135 typically contain low-resolution, continuous-tone imagery. 3136 2: Image is the Mask layer. In MRC, if the Mask layer is present, it 3137 must be the Primary IFD and be full page in extent. 3138 3: Image is a Foreground image, i.e., the image that will appear 3139 whenever the Mask contains a value of 1. The Foreground image 3140 generally defines the color of text or lines, but may also 3141 contain high-resolution imagery. 3143 ImageLayer[1]: 3144 1: first image to be imaged in this layer, 3145 2: second image to be imaged in this layer, 3146 3: ... 3148 In Profile M, more than one image can exist in a single layer. 3149 ImageLayer[1] specifies the order in which images within a single 3150 layer are to be imaged. This insures that overlapping images within 3151 a single layer are imaged correctly. 3153 If an IFD contains no encoded image data and is used to only specify 3154 the ImageBaseColor field, the value of ImageLayer[1] must be less 3155 than that of any other IFD corresponding to the same layer and strip 3156 to insure the image data is interpreted as on top of the default 3157 color. 3159 In Profile M, it is possible to have only a single layer. For 3160 example, if a page contains only a single continuous-tone 3161 photograph, then only the Background layer would occur. In this 3162 case, the Background layer will be stored as the Primary IFD. 3163 ImageLayer[0] will be 1 indicating Background; ImageLayer[1] will be 3164 1 since there can be no other IFDs associated with that layer. No 3165 Mask layer will exist. 3167 8.3. Recommended TIFF Fields 3169 See Sections 2.2.3. and 2.2.4. 3171 8.4. Rules and Requirements for Images 3173 Profile M defines a fundamental set of rules for images in the 3 3174 layer representation. 3176 1. If more than one layer exists, then the binary Mask layer SHALL 3177 be present and be the primary image. The Mask layer SHALL support 3178 the binary data representations defined in Section 3 and MAY 3179 support the binary data representations defined in Sections 4 and 3181 5, with the exception that PhotometricInterpretation MUST be 0. 3182 If only one layer exists, then the image corresponding to that 3183 layer is the primary image. 3185 2. The Primary IFD defines and extends to the entire page boundary; 3186 all attached model images cannot extend beyond the Primary image. 3188 Resolution differences may cause some pixels to "hang over" the 3189 page boundary, but no new pixels should exist completely beyond 3190 the page extent. 3192 3. The Background and Foreground images SHALL support the color 3193 representations defined in Section 6 and MAY support the color 3194 representations defined in Section 7. These images MAY optionally 3196 cover only a portion of the strip or page. 3198 4. Each Primary IFD and each MRC-specific SubIFD must have an 3199 ImageLayer field to specify which layer the IFD belongs to, and 3200 the imaging order of that IFD within the layer. 3202 5. Each Primary IFD must have a NewSubFileType field value set to 3203 18, indicating a single page of a multi-page document (bit 1) and 3205 MRC (bit 4). 3207 6. Each MRC-specific child IFD must have a NewSubFileType field 3208 value set to 16, indicating MRC (bit 4). 3210 7. In MRC fax, each layer is transmitted as a sequence of strips. 3211 If the page consists of a single layer, then all strips shall be 3212 stored in the single Primary IFD. In this case, coding 3213 parameters cannot change between strips. If the page consists of 3215 more than one layer, then all strips of the Mask layer shall be 3216 stored in the single Primary IFD. All strips of the Foreground/ 3217 Background layers SHALL be stored in separate IFDs, referenced by 3219 the Primary IFD's SubIFD field, containing an ImageLayer field 3220 with ImageLayer[0] identifying either Background (layer 1) or 3221 Foreground (layer 3), and Imagelayer[1] identifying order in 3222 which images within a single layer are to be imaged. The TIFF 3223 XPosition and YPosition fields are used to indicate the placement 3225 of these images with respect to the primary image. 3227 8. When the Mask image is present, the resolution of Background and 3228 Foreground images must each be an integer factor of the Mask 3229 image. For example, if the Mask image is 400 pixels/inch, then 3230 the Background or Foreground image may be at 400 pixels/inch 3231 (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). 3233 8.5. Profile M - MRC Fax Profile Summary 3235 Recommended fields are shown with an asterisk * 3237 Required fields or values are shown with a double asterisk **. If the 3238 double asterisk is on the field name, then all the listed values are 3239 required of implementations; if the double asterisks are in the 3240 Values column, then only the values suffixed with a double asterisk 3241 are required of implementations. 3243 +------------------+-----------------------------------------+ 3244 | Baseline Fields | Values | 3245 +------------------+-----------------------------------------+ 3246 | BitsPerSample | 1**: binary mask, RGB, CMY(K) | 3247 | | 2-8**: bits per color sample | 3248 | | 9-12: optional 12 bits/sample | 3249 +------------------+-----------------------------------------+ 3250 | Compression | 1: None (ImageBaseColor IFD only) | 3251 | | 3**: Modified Huffman and Modified Read | 3252 | | 4: Modified Modified Read | 3253 | | 7**: JPEG | 3254 | | 9: JBIG, per T.85 | 3255 | | 10: JBIG, per T.43 | 3256 +------------------+-----------------------------------------+ 3257 | DateTime* | {ASCII): date/time in the 24-hour format| 3258 | | "YYYY:MM:DD HH:MM:SS" | 3259 +------------------+-----------------------------------------+ 3260 | FillOrder** | 1: Most significant bit first | 3261 | | 2: Least significant bit first | 3262 +------------------+-----------------------------------------+ 3263 | ImageDescription*| {ASCII}: A string describing the | 3264 | | contents of the image. | 3265 +------------------+-----------------------------------------+ 3266 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 3267 | | 2592, 3072, 3456, 3648, 4096, 4864 | 3268 | | Note, legal widths for the Primary IFD. | 3269 +------------------+-----------------------------------------+ 3270 | ImageLength** | n: total number of scanlines in image | 3271 +------------------+-----------------------------------------+ 3272 | NewSubFileType** | 16, 18: | 3273 | | Bit 1 indicates single page of a multi- | 3274 | | page document on Primary IFD | 3275 | | Bit 4 indicates MRC model | 3276 +------------------+-----------------------------------------+ 3277 +------------------+-----------------------------------------+ 3278 | Orientation | 1**-8, Default 1 | 3279 +------------------+-----------------------------------------+ 3280 | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | 3281 | pretation | 2: RGB | 3282 | | 10**: ITULAB | 3283 +------------------+-----------------------------------------+ 3284 | ResolutionUnit** | 2: inch | 3285 +------------------+-----------------------------------------+ 3286 | RowsPerStrip | n: number or scanlines per strip | 3287 +------------------+-----------------------------------------+ 3288 | SamplesPerPixel | 1**: L* (lightness) | 3289 | | 3: RGB, LAB, CMY | 3290 | | 4: CMYK | 3291 +------------------+-----------------------------------------+ 3292 | Software* | {ASCII}: name & release number of | 3293 | | creator software | 3294 +------------------+-----------------------------------------+ 3295 | StripByteCounts**| : number or bytes in each strip | 3296 +------------------+-----------------------------------------+ 3297 | StripOffsets** | : offset from beginning of file to | 3298 | | each TIFF strip | 3299 +------------------+-----------------------------------------+ 3300 | XResolution | 100, 200**, 300, 400 (written in | 3301 | | pixels/inch) | 3302 +------------------+-----------------------------------------+ 3303 | YResolution | equal to XResolution (pixels must be | 3304 | | square) | 3305 +------------------+-----------------------------------------+ 3306 | Extension Fields | 3307 +------------------+-----------------------------------------+ 3308 | T4Options | 0**: required if Compression is Modified| 3309 | | Huffman, EOLs not byte aligned | 3310 | | 1: required if Compression 2D Modified | 3311 | | Read, EOLs are not byte aligned | 3312 | | 4**: required if Compression Modified | 3313 | | Huffman, EOLs byte aligned | 3314 | | 5: required if Compression 2D Modified | 3315 | | Read, EOLs are byte aligned | 3316 +------------------+-----------------------------------------+ 3317 | T6Options | 0: required if Compression is 2D | 3318 | | Modified Modified Read | 3319 +------------------+-----------------------------------------+ 3320 | DocumentName* | {ASCII}: name of scanned document | 3321 +------------------+-----------------------------------------+ 3322 | PageNumber** | n,m: page number followed by total page | 3323 | | count | 3324 +------------------+-----------------------------------------+ 3325 +------------------+-----------------------------------------+ 3326 | ChromaSubSampling| (1,1), (2, 2)** | 3327 | | (1, 1): equal numbers of lightness and | 3328 | | chroma samples horizontally & vertically| 3329 | | (2, 2): twice as many lightness samples | 3330 | | as chroma horizontally and vertically | 3331 +------------------+-----------------------------------------+ 3332 | ChromaPositioning| 1: centered | 3333 +------------------+-----------------------------------------+ 3334 | Indexed | 0: not a palette-color image | 3335 | | 1: palette-color image | 3336 +------------------+-----------------------------------------+ 3337 | SubIFDs | : byte offset to FG/BG IFDs | 3338 +------------------+-----------------------------------------+ 3339 | XPosition | horizontal offset in primary IFD | 3340 | | resolution units | 3341 +------------------+-----------------------------------------+ 3342 | YPosition | vertical offset in primary IFD | 3343 | | resolution units | 3344 +------------------+-----------------------------------------+ 3345 | New Fields | 3346 +------------------+-----------------------------------------+ 3347 | Decode | minL, maxL, mina, maxa, minb, maxb: | 3348 | | minimum and maximum values for L*a*b* | 3349 +------------------+-----------------------------------------+ 3350 | ImageBaseColor | a,b,c: background color in ITULAB | 3351 +------------------+-----------------------------------------+ 3352 | StripRowCounts | : number of scanlines in each strip | 3353 +------------------+-----------------------------------------+ 3354 | ImageLayer | n, m: layer number, imaging sequence | 3355 | | (e.g., strip number) | 3356 +------------------+-----------------------------------------+ 3357 | T82Options | 0: T.85 profile of T.82 coding | 3358 +------------------+-----------------------------------------+ 3359 | GlobalParameters | IFD: global parameters IFD | 3360 | IFD* | | 3361 +------------------+-----------------------------------------+ 3362 | ProfileType* | n: type of data stored in TIFF file | 3363 +------------------+-----------------------------------------+ 3364 | FaxProfile* | n: ITU-compatible fax profile | 3365 +------------------+-----------------------------------------+ 3366 | CodingMethods* | n: compression algorithms used in file | 3367 +------------------+-----------------------------------------+ 3368 | ModeNumber* | n: version of T.44 standard | 3369 +------------------+-----------------------------------------+ 3370 | VersionYear* | byte sequence: year of ITU fax standard | 3371 +------------------+-----------------------------------------+ 3373 9. MIME content-types image/tiff and image/tiff-fx 3375 The MIME content-types image/tiff and image/tiff-fx are used for 3376 TIFF-FX encoded image data, as defined in this document. [TIFF-REG] and 3377 [TIFF-FX-REG] describe the registration of these MIME content-types. 3379 10. Security Considerations 3381 This document describes a file format for Internet fax, which is a 3382 series of profiles of TIFF for facsimile. As such, it does not create 3383 any security issues not already identified in [TIFF-REG], in its use 3384 of fields as defined in [TIFF]. There are also new TIFF fields 3385 defined within this specification, but they are of a purely 3386 descriptive nature, so that no new security risks are incurred. 3388 Further, the encoding specified in this document does not in any way 3389 preclude the use of any Internet security protocol to encrypt, 3390 authenticate, or non-repudiate TIFF-encoded facsimile messages. 3392 11. References 3394 11.1 Normative References 3396 [REQ] Bradner, S, "Key words for use in RFCs to Indicate Requirement 3397 Levels", RFC 2119, March 1997. 3399 [T.4] ITU-T Recommendation T.4, Standardization of group 3 facsimile 3400 apparatus for document transmission, October 1997 3402 [T.6] ITU-T Recommendation T.6, Facsimile coding schemes and coding 3403 control functions for group 4 facsimile apparatus, November 1988 3405 [T.30] ITU-T Recommendation T.30 - Procedures for Document Facsimile 3406 Transmission in the General Switched Telephone Network, June 1996 3408 [T.42] ITU-T Recommendation T.42, Continuous-tone colour 3409 representation method for facsimile, February 1996 3411 [T.43] ITU-T Recommendation T.43, Colour and gray-scale image 3412 representations using lossless coding scheme for facsimile, February 3413 1997 3415 [T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC), April 3416 1999. 3418 [T.81] ITU-T Recommendation T.81, Information technology - Digital 3419 compression and coding of continuous-tone still images - Requirements 3420 and guidelines, September 1992 3422 [T.85] ITU-T Recommendation T.85, Application profile for 3423 Recommendation T.82 - Progressive bi-level image compression (JBIG 3424 coding scheme) for facsimile apparatus, August 1995 3426 [T.82] ITU-T Recommendation T.82, Information technology - Coded 3427 representation of picture and audio information - Progressive bi- 3428 level image compression, March 1995 3430 [TIFF] Tag Image File Format, Revision 6.0, Adobe Developers 3431 Association, June 3, 1992, 3432 ftp://ftp.adobe.com/pub/adobe/devrelations/ 3433 devtechnotes/pdffiles/tiff6.pdf 3435 The TIFF 6.0 specification dated June 3, 1992 specification (c) 3436 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved. 3438 [TIFF-F0] TIFF Class F specification, Apr 28, 1990, 3439 ftp://ftp.faximum.com/pub/documents/tiff_f.txt 3441 [TIFF-REG] Parsons, G. and Rafferty J., "Tag Image File 3442 Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, 3443 September 2002 3445 [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995, 3447 http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf 3449 [TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG 3450 specification, March 17, 1995, 3451 ftp://ftp.uu.net/graphics/jpeg/ 3453 [TIFF-FX-REG] McIntyre, L., Parsons, G. and Rafferty, J., "Tag Image 3455 File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type 3456 Registration", RFC 3250, September 2002 3458 The ITU-T Recommendations are available at http://www.itu.ch. 3460 11.2 Informative references 3462 [GUIDE] Cancio, V., Moldovan, M., Tamura, H., and Wing, D., 3463 "Implementers Guide for Facsimile Using Internet Mail", RFC 3249, 3464 September 2002 3466 [TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) 3467 - F Profile for Facsimile", RFC 2306, March 1998. 3469 [VPIM 2] Vaudreuil G. and G. Parsons, "Voice Profile for Internet 3470 Mail - Version 2", work in progress, draft-ietf-vpim-vpimv2r2-05.txt, 3471 February 2002 3473 12. Authors' Addresses 3475 Robert Buckley Dennis Venable 3476 Xerox Corporation Xerox Corporation 3477 Mailstop 0128-30E Mailstop 0128-27E 3478 800 Phillips Road 800 Phillips Road 3479 Webster, NY 14580, USA Webster, NY 14580, USA 3480 Voice: +1-585-422-1282 Voice: +1-585-422-3138 3481 Fax: +1-585-265-8871 Fax: +1-585-422-6117 3482 Email: rbuckley@crt.xerox.com Email: dvenable@crt.xerox.com 3484 Lloyd McIntyre 3485 10328 S. Stelling Road 3486 Cupertino, CA 95014 USA 3487 Voice: +1-408-725-1624 3488 Email: lloyd10328@pacbell.net 3490 Glenn S. Parsons James Rafferty 3491 Nortel Networks Brooktrout Technology 3492 P.O. Box 3511, Station C 410 First Avenue 3493 Ottawa, Ontario K1Y 4H7, Canada Needham, MA 02494 USA 3494 Phone: +1-613-763-7582 Phone: +1-781-433-9462 3495 Fax: +1-613-763-2697 Fax: +1-781-433-9268 3496 Email: Email: jraff@brooktrout.com 3497 gparsons@nortelnetworks.com 3499 Annex A: Summary of TIFF Fields for Internet Fax 3501 This annex includes tables which list by profile the TIFF fields used 3502 in the proposed fax file format. The fields are organized into 3 3503 categories: 3505 1) TIFF Baseline Fields 3506 2) TIFF Extension Fields 3507 3) New Fields. 3509 The tables include the allowed values for each fax profile. Entries 3510 other than explicit numbers are described by: 3512 n - single number 3513 n, m - 2 numbers 3514 a, b, c - 3 numbers 3515 r - rational number 3516 - array of numbers 3517 - byte sequence 3518 {ASCII} - string 3519 IFD - IFD byte offset 3520 - array of IFD byte offsets 3522 A blank entry in the table indicates that the field is not used by 3523 that particular fax profile. 3525 Table A.1 TIFF Baseline Fields 3527 +---------------------------------------------------------+ 3528 | Fax Profile | 3529 +---------------------------------------------------------| 3530 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3531 +----------| B&W | B&W | B&W | Color | Color | Raster | 3532 | TIFF | | | | | | Content| 3533 | Field | S | F | J | C | L | M | 3534 +----------+---------+----------+--------+---------+--------+--------+ 3535 | BitsPer | 1 | 1 | 1 | 8 | 1, 2-8 | 1, 2-8 | 3536 | Sample | | | | | 9-12 | 9-12 | 3537 +----------+---------+----------+--------+---------+--------+--------+ 3538 | Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7| 3539 | sion | | | | | | 9,10 | 3540 +----------+---------+----------+--------+---------+--------+--------+ 3541 | DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3542 +----------+---------+----------+--------+---------+--------+--------+ 3543 | FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 | 3545 +----------+---------+----------+--------+---------+--------+--------+ 3546 +----------+---------+----------+--------+---------+--------+--------+ 3547 | ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3548 | cription | | | | | | | 3549 +----------+---------+----------+--------+---------+--------+--------+ 3550 | Image- | n | n | n | n | n | n | 3551 | Length | | | | | | | 3552 +----------+---------+----------+--------+---------+--------+--------+ 3553 | Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, | 3554 | Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, | 3555 | | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 | 3556 | | | Note, for the Mixed Raster Content M profile | 3557 | | | these widths apply to the Primary IFD. | 3558 +----------+---------+----------+--------+---------+--------+--------+ 3559 | NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 | 3560 | FileType | | | | | | | 3561 +----------+---------+----------+--------+---------+--------+--------+ 3562 | Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 | 3563 | tation | | | | | | | 3564 +----------+---------+----------+--------+---------+--------+--------+ 3565 | Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, | 3566 | metric- | | | | | 10 | 2, | 3567 | Interp- | | | | | | 10 | 3568 | retation | | | | | | | 3569 +----------+---------+----------+--------+---------+--------+--------+ 3570 | Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 3571 | tionUnit | | | | | | | 3572 +----------+---------+----------+--------+---------+--------+--------+ 3573 | RowsPer- | n | n | n | n | n | n | 3574 | Strip | | | | | | | 3575 +----------+---------+----------+--------+---------+--------+--------+ 3576 | Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4| 3577 | PerPixel | | | | | | | 3578 +----------+---------+----------+--------+---------+--------+--------+ 3579 | Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3580 +----------+---------+----------+--------+---------+--------+--------+ 3581 | Strip- | n | | | | | | 3582 | Byte- | | | | | | | 3583 | Counts | | | | | | | 3584 +----------+---------+----------+--------+---------+--------+--------+ 3585 | Strip- | n | | | | | | 3586 | Offsets | | | | | | | 3587 +----------+---------+----------+--------+---------+--------+--------+ 3588 | XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 | 3589 | tion | 200 | 400, 408 | | 3590 +----------+---------+----------+--------+---------+--------+--------+ 3591 | YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 | 3592 | tion | 100,200 | 300, 391, 400 | | 3594 +----------+---------+----------+--------+---------+--------+--------+ 3596 Table A.2 TIFF Extension Fields 3598 +---------------------------------------------------------+ 3599 | Fax Profile | 3600 +---------------------------------------------------------| 3601 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3602 +----------| B&W | B&W | B&W | Color | Color | Raster | 3603 | TIFF | | | | | | Content| 3604 | Field | S | F | J | C | L | M | 3605 +----------+---------+----------+--------+---------+--------+--------+ 3606 | Chroma- | | | | 1 | | 1 | 3607 | Position-| | | | | | | 3608 | ing | | | | | | | 3609 +----------+---------+----------+--------+---------+--------+--------+ 3610 | Chroma- | | | | <1, 1> | | <1, 1> | 3611 | SubSampl-| | | | <2, 2> | | <2, 2> | 3612 | ing | | | | | | | 3613 +----------+---------+----------+--------+---------+--------+--------+ 3614 | Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3615 | Name | | | | | | | 3616 +----------+---------+----------+--------+---------+--------+--------+ 3617 | Indexed | | | | | 0,1 | 0,1 | 3618 +----------+---------+----------+--------+---------+--------+--------+ 3619 | Page- | n, m | n, m | n, m | n, m | n, m | n, m | 3620 | Number | | | | | | | 3621 +----------+---------+----------+--------+---------+--------+--------+ 3622 | SubIFDs | | | | | | | 3623 +----------+---------+----------+--------+---------+--------+--------+ 3624 | T4Options| 0, 4 | 0, 1, | | | | 0, 1, | 3625 | | | 4, 5 | | | | 4, 5 | 3626 +----------+---------+----------+--------+---------+--------+--------+ 3627 | T6Options| | 0 | | | | 0 | 3628 +----------+---------+----------+--------+---------+--------+--------+ 3629 | XPosition| | | | | | r | 3630 +----------+---------+----------+--------+---------+--------+--------+ 3631 | YPosition| | | | | | r | 3633 +----------+---------+----------+--------+---------+--------+--------+ 3635 Table A.3 New Fields 3637 +---------------------------------------------------------+ 3638 | Fax Profile | 3639 +---------------------------------------------------------| 3640 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3641 +----------| B&W | B&W | B&W | Color | Color | Raster | 3642 | TIFF | | | | | | Content| 3643 | Field | S | F | J | C | L | M | 3644 +----------+---------+----------+--------+---------+--------+--------+ 3645 | BadFax- | | n | | | | | 3646 | Lines | | | | | | | 3647 +----------+---------+----------+--------+---------+--------+--------+ 3648 | CleanFax-| | 0, 1, 2 | | | | | 3649 | Data | | | | | | | 3650 +----------+---------+----------+--------+---------+--------+--------+ 3651 | Coding- | | | n | n | n | n | 3652 | Method | | | | | | | 3653 +----------+---------+----------+--------+---------+--------+--------+ 3654 | Consecu- | | n | | | | | 3655 | tiveBad- | | | | | | | 3656 | FaxLines | | | | | | | 3657 +----------+---------+----------+--------+---------+--------+--------+ 3658 | Decode | | | | | | | 3659 +----------+---------+----------+--------+---------+--------+--------+ 3660 | Fax- | | | n | n | n | n | 3661 | Profile | | | | | | | 3662 +----------+---------+----------+--------+---------+--------+--------+ 3663 | Global- | | IFD | IFD | IFD | IFD | IFD | 3664 | Parame- | | | | | | | 3665 | tersIFD | | | | | | | 3666 +----------+---------+----------+--------+---------+--------+--------+ 3667 | Image- | | | | | | n, m | 3668 | Layer | | | | | | | 3669 +----------+---------+----------+--------+---------+--------+--------+ 3670 | T82- | | | n | | | n | 3671 | Options | | | | | | | 3672 +----------+---------+----------+--------+---------+--------+--------+ 3673 | Image- | | | | | | | 3674 | BaseColor| | | | | | | 3675 +----------+---------+----------+--------+---------+--------+--------+ 3676 | Mode- | | | | | | n | 3677 | Number | | | | | | | 3678 +----------+---------+----------+--------+---------+--------+--------| 3679 | Profile- | | | n | n | n | n | 3680 | Type | | | | | | | 3682 +--------------------------------------------------------------------+ 3683 +----------+---------+----------+--------+---------+--------+--------+ 3684 | Strip- | | | | | | | 3685 | RowCounts| | | | | | | 3686 +----------+---------+----------+--------+---------+--------+--------+ 3687 | Version- | | | | | | | 3688 | Year | | | | | | | 3690 +----------+---------+----------+--------+---------+--------+--------+ 3692 Annex B. List of technical edits to RFC2301 3694 This Annex lists technical differences between this document and 3695 RFC 2301, the Proposed Standard File Format for Internet Fax. 3697 +----+---------+-------------------------------------------------+ 3698 | No.| Section | Technical Edit | 3699 +----+---------+-------------------------------------------------+ 3700 | 1. | 5.2.1 | Added FillOrder=1 to Profile J | 3701 +----+---------+-------------------------------------------------+ 3702 | 2. | 6.2.1 | Constrained ResolutionUnit to 2 (i.e. inch) for | 3703 | | 7.2.1 | all color profiles, per ITU-T Recommendations | 3704 | | 8.2.1 | | 3705 +----+---------+-------------------------------------------------+ 3706 | 3. | 7.2.1 | Deleted ColorMap field; it re-encoded the color | 3707 | | 7.4 | palette already in the T.43 data stream | 3708 +----+---------+-------------------------------------------------+ 3709 | 4. | 7.2.2 | Changed TAG value of Indexed field from 364 to | 3710 | | | 346 to agree with Section 8.2.2 and Ref. [TTN1] | 3711 +----+---------+-------------------------------------------------+ 3712 | 5. | 8.2.1 | Added text clarifying the use of ImageWidth | 3713 | | | when Background or Foreground layer is Primary | 3714 | | | IFD | 3715 +----+---------+-------------------------------------------------+ 3716 | 6. | 8.2.3 | Changed field name from DefaultImageColor to | 3717 | | | ImageBaseColor; | 3718 +----+---------+-------------------------------------------------+ 3719 | 7. | 8.2.1 | Added Compression=1 for ImageBaseColor IFDs | 3720 +----+---------+-------------------------------------------------+ 3721 | 8. | 5.2.1 | Redefined compression = 9 to be T.82 (JBIG); | 3722 | | 5.2.3 | added T82Options field, with a default value (0)| 3723 | | | corresponding to the T.85 application profile | 3724 +----+---------+-------------------------------------------------+ 3725 | 9. | 4.3.3 | Added GlobalParametersIFD, ProfileType, | 3726 | | 4.7 | FaxProfile and CodingMethod to the New Fields | 3727 | | | portion of Profile F, per Sec. 2.2.4 | 3728 +----+---------+-------------------------------------------------+ 3729 | 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when | 3730 | |6.2.3,6.4| Compression=7 due to lack of interop testing. | 3731 | |Table A.1| | 3732 +----+---------+-------------------------------------------------+ 3733 | 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M| 3734 | |Table A.1| due to insufficient interop testing. | 3735 +----+---------+-------------------------------------------------+ 3736 | 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette color | 3737 | |8.2.1,8.5| due to lack of interop testing. | 3738 | |Table A.1| | 3739 +----+---------+-------------------------------------------------+ 3740 | 13.| Annex B | Deleted Annex B due to discontinued use of | 3741 | | | application parameter; Annex C renamed Annex B | 3742 +----+---------+-------------------------------------------------+ 3744 Full Copyright Statement 3746 Copyright (C) The Internet Society (2003). All Rights Reserved. 3748 This document and translations of it may be copied and furnished to 3749 others, and derivative works that comment on or otherwise explain it 3750 or assist in its implementation may be prepared, copied, published 3751 and distributed, in whole or in part, without restriction of any 3752 kind, provided that the above copyright notice and this paragraph are 3753 included on all such copies and derivative works. However, this 3754 document itself may not be modified in any way, such as by removing 3755 the copyright notice or references to the Internet Society or other 3756 Internet organizations, except as needed for the purpose of 3757 developing Internet standards in which case the procedures for 3758 copyrights defined in the Internet Standards process must be 3759 followed, or as required to translate it into languages other than 3760 English. 3762 The limited permissions granted above are perpetual and will not be 3763 revoked by the Internet Society or its successors or assigns. 3765 This document and the information contained herein is provided on an 3766 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3767 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3768 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3769 HEREI WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3770 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.