idnits 2.17.1 draft-ietf-fax-tiff-fx-13.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 == 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 4 instances of too long lines in the document, the longest one being 2 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 1076 has weird spacing: '...y after the I...' == Line 1221 has weird spacing: '...ost all cases...' == Line 1222 has weird spacing: '...remains consi...' == Line 1670 has weird spacing: '...olution and "...' == Line 2112 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 (June 2003) is 7614 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 3076 -- Looks like a reference, but probably isn't: '1' on line 3077 -- Looks like a reference, but probably isn't: '2' on line 2769 -- Looks like a reference, but probably isn't: '3' on line 2775 -- Looks like a reference, but probably isn't: '4' on line 2220 -- Looks like a reference, but probably isn't: '5' on line 2221 -- 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' ** Obsolete normative reference: RFC 3250 (ref. 'TIFF-FX-REG') (Obsoleted by RFC 3950) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 12 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 June 12, 2003 D. Venable 4 draft-ietf-fax-tiff-fx-13.txt Xerox Corporation 5 L. McIntyre 6 G. Parsons 7 Nortel Networks 8 J. Rafferty 9 Brooktrout 10 June 2003 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 draft document is intended for submission to the 36 RFC editor as a Proposed 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 C 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 draft.........................................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 107 TIFF-F 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 draft: 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 draft 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). 263 Section 6defines the base color profile, required in all color 264 implementations, for the lossy JPEG representation of color and 265 grayscale facsimile data (Profile C). Section 7 defines the lossless 266 JBIG color and grayscale facsimile profile(Profile L) and Section 8 267 defines the Mixed Raster Content facsimile profile(Profile M). Each 268 of these sections concludes with a table summarizing the required and 269 recommended fields for each profile and the values they can have. 271 Section 9 refers to the MIME content types used in connection 272 with TIFF for facsimile. Sections 10, 11, 12 and 13 give Security 273 Considerations, the ISOC Copyright Notice, References and Authors' 274 Addresses. Annex A gives a summary of the TIFF fields used or defined 275 in this document and provides a convenient reference for implementors. 277 To implement only the minimal interchange black-and-white set of 278 fields and values (Profile S), one need read only Sections 1, 2, 3, 9 279 and 10. 281 The following tree diagram shows the relationship among profiles and 282 between profiles and coding methods. 284 S (MH) 285 / \ 286 B&W / \ Color 287 ------------ ---------- 288 / \ \ 289 / F (MH, MR, MMR) C (JPEG) 290 / / \ 291 J (JBIG) ---- \ 292 / \ 293 L (JBIG) \ 294 \ 295 M (MRC) 297 A profile is based on a collection of ITU-T facsimile coding methods. 298 For example, Profile S, the minimal profile, is based on Modified 299 Huffman (MH) compression, which is defined in ITU-T Rec. T.4. 300 Profile F specifies Modified Huffman (MH), Modified Read (MR) and 301 Modified Modified Read (MMR) compressions, which are defined in ITU-T 302 Rec. T.4 and T.6. 304 All implementations of TIFF for facsimile MUST implement Profile S, 305 which is the root node of the tree. All color implementations of TIFF 306 for facsimile MUST implement Profile C. The implementation of a 307 particular profile MUST also implement those profiles on the path 308 that connect it to the root node, and MAY optionally implement 309 profiles not on the path connecting it to the root node. For example, 310 an implementation of Profile M must also implement Profiles C and S, 311 and may optionally implement Profile F, J or L. For another example, 312 an implementation of Profile C must also implement Profile S, and may 313 optionally implement Profile F or J. 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 317 document are to be interpreted as described in [REQ]. 319 1.4 IPR Notification 321 The IETF has been notified of intellectual property rights claimed in 322 regard to some or all of the specification contained in this 323 document. For more information consult the online list of claimed 324 rights in . 326 2. TIFF and Fax 328 2.1. TIFF Overview 330 TIFF provides a means for describing, storing and interchanging 331 raster image data. A primary goal of TIFF is to provide a rich 332 environment within which applications can exchange image data. The 333 current TIFF specification [TIFF] defines a commonly used, core set 334 of TIFF fields known as Baseline TIFF. The current specification, 335 the set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical 336 Note 2 [TTN2] define several TIFF extensions. The TIFF- based 337 specification for fax applications uses a subset of Baseline TIFF 338 fields, with selected extensions, as described in this document. In 339 a few cases, this document defines new TIFF fields specifically for 340 fax applications. 342 2.1.1. File Structure 344 TIFF is designed for raster images, which makes it a good match for 345 facsimile documents, which are multi-page raster images. Each raster 346 image consists of a number of rows or scanlines, each of which has 347 the same number of pixels, the unit of sampling. Each pixel has at 348 least one sample or component (exactly one for black-and-white 349 images). 351 A TIFF file begins with an 8-byte image file header. The first two 352 bytes describe the byte order used within the file. Legal values are 353 "II" (0x4949) when bytes are ordered from least to most significant 354 (little- endian), and "MM" (0x4D4D), when bytes are ordered from most 355 to least significant (big-endian) within a 16- or 32-bit integer. 356 Either byte order can be used, except in the case of the minimal 357 black-and-white profile, which SHALL use value "II". The next two 358 bytes contain the value 42 that identifies the file as a TIFF file 359 and is ordered according to the value in the first two bytes of the 360 header. The last four bytes give the offset that points to the first 361 image file directory (IFD). This and all other offsets in a TIFF file 362 are with respect to the beginning of the TIFF file. An IFD can be at 363 any location in the file after the header but must begin on a word 364 boundary. 366 An IFD is a sequence of tagged fields, sorted in ascending order by 367 tag value. An IFD consists of a 2-byte count of the number of fields, 368 a sequence of field entries and a 4-byte offset to the next IFD. The 369 fields contain information about the image and pointers to the image 370 data. Each separate raster image in the file is represented by an 371 IFD. 373 Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag, 374 2 bytes identifying the field type (e.g. short, long, rational, 375 ASCII), 4 bytes giving the count (number of values or offsets), and 4 376 bytes that either contain the offset to a field value stored outside 377 the IFD, or, based on the type and count, the field value itself. 378 Resolution and metadata such as dates, names and descriptions are 379 examples of "long" field values that do not fit in 4 bytes and 380 therefore use offsets in the field entry. Details are given in the 381 TIFF specification [TIFF]. 383 A TIFF file can contain more than one IFD, where each IFD is a 384 subfile whose type is given in the NewSubfileType field. Multiple 385 IFDs can be organized either as a linked list, with the last entry in 386 each IFD pointing to the next IFD (the pointer in the last IFD is 0), 387 or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The 388 SubIFDs field contains an array of pointers to child IFDs of the 389 primary IFD. 391 Child IFDs describe related images, such as reduced resolution 392 versions of the primary IFD image. The same IFD can point both to a 393 next IFD and to child IFDs, and child IFDs can themselves point to 394 other IFDs. 396 All fax profiles represent a multi-page fax image as a linked list of 397 IFDs, with a NewSubfileType field containing a bit that identifies 398 the IFD as one page of a multi-page document. Each IFD has a 399 PageNumber field, identifying the page number in ascending order, 400 starting at 0 for the first page. While a Baseline TIFF reader is not 401 required to read any IFDs beyond the first, an implementation that 402 reads the files that comply with this specification SHALL read 403 multiple IFDs. Only the Mixed Raster Content fax profile, described 404 in Section 8, requires the use of child IFDs. 406 The following figure illustrates the structure of a multi-page TIFF 407 file. 409 +-----------------------+ 410 | Header |------------+ 411 +-----------------------+ | First IFD 412 | IFD (page 0) |<-----------+ Offset 413 +---| |------------+ 414 Value | +-----------------------+ | 415 Offset +-->| Long Values |--+ | 416 +-----------------------| | Strip | 417 | Image Data |<-+ Offset | 418 | strip 1 page 0 | | | 419 +-----------------------+ | | 420 | : | : | 421 | 422 +-----------------------+ | Next IFD 423 | IFD (page 1) |<-----------+ Offset 424 +---| |------------+ 425 Value | +-----------------------+ | 426 Offset +-->| Long Values |--+ | 427 +-----------------------| | Strip | 428 | Image Data |<-+ Offset | 429 | strip 1 page 1 | | | 430 +-----------------------+ | | 431 | strip 2 page 1 |<-+ | 432 +-----------------------+ | | 433 | : | : | 434 | 435 +-----------------------+ | Next IFD 436 | IFD (page 2) |<-----------+ Offset 437 | : | 439 2.1.2 Image Structure 441 An IFD stores an image as one or more strips, as shown in the 442 preceding figure. A strip consists of 1 or more scanlines (rows) of 443 raster image data in compressed form. An image may be stored in a 444 single strip or may be divided into several strips, which would 445 require less memory to buffer. (Baseline TIFF recommends about 8k 446 bytes per strip, but existing fax usage is typically one strip per 447 image.) 448 Each IFD requires three strip-related fields: StripOffsets, 449 RowsPerStrip and StripByteCounts. The StripOffsets field is an array 450 of pointers to the strip or strips that contain the actual image 451 data. The StripByteCounts field gives the number of bytes in each 452 strip after compression. TIFF requires that each strip, except the 453 last, contain the same number of scanlines, which is given in the 454 RowsPerStrip field. This document introduces the new StripRowCounts 455 field that allows a variable number of scanlines per strip, which is 456 required by the Mixed Raster Content fax profile (Section 8). 458 Image data is stored as uninterpreted, compressed image data streams 459 within a strip. The formats of these streams follow the ITU-T 460 Recommendations. The Compression field in the IFD indicates the type 461 of compression, and other TIFF fields in the IFD describe image 462 attributes, such as color encoding and spatial resolution. 463 Compression parameters are stored in the compressed data stream, 464 rather than in TIFF fields. This makes the TIFF representation and 465 compressed data format specification independent of each another. 466 This approach, modeled on [TTN2], allows TIFF to gracefully add new 467 compression schemes as they become available. 469 Some attributes can be specified both in the compressed data stream 470 and within a TIFF field. It is possible that the two values will 471 differ. When this happens for values required to interpret the data 472 stream, then the values in the data stream take precedence. For 473 informational values that are not required to interpret the data 474 stream, such as author name, then the TIFF field value takes 475 precedence. 477 2.1.3 TIFF File Structure for Fax Applications 479 The TIFF specification has a very flexible file structure, which does 480 not specify the ordering of IFDs, field values and image data in a 481 file. Individual applications may require or recommend an ordering. 483 This specification recommends that when using a TIFF file for 484 facsimile, a multi-page fax document SHOULD be represented as a 485 linked list of IFDs. It also recommends that a TIFF file for 486 facsimile SHOULD order pages in a TIFF file in the same way that they 487 are ordered in a fax data stream. In a TIFF file, a page consists of 488 several elements: one or more IFDs (including subIFDs), long field 489 values that are stored outside the IFDs, and image data (in one or 490 more strips). 492 The minimal black-and-white profile (Profile S) specifies a required 493 ordering of pages and elements within a page (Section 3.5). The 494 extended black-and-white profile (Profile F) provides guidelines for 495 ordering pages and page elements (Section 4.4.6). Other profiles 496 SHOULD follow these guidelines. This recommendation is intended to 497 simplify the implementation of TIFF writers and readers in fax 498 applications and the conversion between TIFF file and fax data stream 499 representations. However, for interchange robustness, readers SHOULD 500 be prepared to read TIFF files whose structure is consistent with 501 [TIFF], which supports a more flexible file structure than is 502 recommended here. 504 This specification introduces an optional new GlobalParametersIFD 505 field, defined in Section 2.2.4. This field has type IFD and 506 indicates parameters describing the fax session. While it is often 507 possible to obtain these parameters by scanning the file, it is 508 convenient to make them available together in one place for fast and 509 easy access. If the GlobalParametersIFD occurs in a TIFF file, it 510 SHOULD be located in the first IFD, immediately following the 8-byte 511 image file header. 513 2.2 TIFF Fields for All Fax Applications 515 The TIFF specification [TIFF] is organized as a baseline set and 516 several extensions, including technical notes [TTN1, TTN2] that will 517 be incorporated in the next release of TIFF. The baseline and 518 extensions have required and optional fields. 520 Facsimile applications require (and recommend) a mixture of baseline 521 and extensions fields, as well as some new fields that are not part 522 of the TIFF specification and that are defined in this document. This 523 sub- section lists the fields that are required or recommended for 524 all profiles. In particular, Section 2.2.1 lists the fields that are 525 required by all profiles and that have values that do not depend on 526 the profile. Section 2.2.2 lists the fields that are required by all 527 profiles and that have values which do depend on the profile. Section 528 2.2.3 lists the fields that are recommended for all profiles. Fields 529 that are required or recommended by some but not all profiles are 530 given in the section (Section 3-8) that describes that profile. The 531 sections for each fax profile have sub-sections for required and 532 recommended fields; each sub-section organizes the fields according 533 to whether they are baseline, extension or new. 535 The fields required for facsimile have only a few legal values, 536 specified in the ITU-T Recommendations. Of these legal values, some 537 are required and some are optional, just as they are required 538 (mandatory) or optional in fax implementations that conform to the 539 ITU-T Recommendations. The required and optional values are noted in 540 the sections on the different fax profiles. 542 This section describes the fields required or recommended by all fax 543 profiles. The pattern for the description of TIFF fields in this 544 draft is: 546 FieldName(TagValueInDecimal) = allowable values. TYPE 547 WhetherRequiredByTIFForTIFFforFAX 548 Count = (omitted if =1) = (if not in current spec but available) 549 Explanation of the field, how it's used, and the values it can have. 550 Default value, if any, as specified in [TIFF] 552 When a field's default value is the desired value, that field may be 553 omitted from the relevant IFD unless specifically required by the 554 text of this specification. 556 2.2.1. TIFF fields required for all fax profiles 558 The TIFF fields listed in this section SHALL be used by all fax 559 profiles, but have field values that are not specified by the ITU 560 standards, i.e. the fields do not depend on the profile. The next 561 sub-section lists the fields that SHALL be used by all fax profiles, 562 but which do have values specified by the ITU-specified or profile- 563 specific values. Fields that SHALL be used by some but not all 564 profiles are given in the sections (3-8) which describe the profiles 565 that uses them. 567 ImageLength(257) SHORT or LONG 568 RequiredByTIFFBaseline 569 Total number of scanlines in image. 570 No default, must be specified. 572 PageNumber(297) SHORT 573 RequiredByTIFFforFAX, TIFFExtension 574 Count = 2 575 The first number represents the page number (0 for the first page); 576 the second number is the total number of pages in the document. If 577 the second value is 0, then the total page count is not available. 578 No default, must be specified 580 RowsPerStrip(278) SHORT or LONG 581 RequiredByTIFFBaseline 582 The number of scanlines per TIFF strip, except for the last strip. 583 For a single strip image, this is the same as the value of the 584 ImageLength field. 585 Default = 2**32 - 1 (meaning all scanlines in one strip) 587 StripByteCounts(279) SHORT or LONG 588 RequiredByTIFFBaseline 589 Count = number of strips 590 For each strip, the number of bytes in that strip after compression. 592 No default, must be specified. 594 StripOffsets(273) SHORT or LONG 595 RequiredByTIFFBaseline 596 Count = number of strips 597 For each strip, the byte offset from the beginning of the file to 598 the start of that strip. 599 No default, must be specified. 601 2.2.2 Additional TIFF fields required for all fax profiles 603 The TIFF fields listed in this section SHALL be used by all fax 604 profiles, but the values associated with them depend on the profile 605 being described and the associated ITU Recommendations. Therefore, 606 only the fields are defined here; the values applicable to a 607 particular fax profile are described in Sections 3-8. Fields that 608 SHALL be used by some but not all profiles are given in the section 609 (3-8) describing the profile that uses them. 611 BitsPerSample(258) SHORT 612 RequiredByTIFFBaseline 613 Number of bits per image sample 614 Default = 1 (field may be omitted if this is the value) 616 Compression(259) SHORT 617 RequiredByTIFFBaseline 618 Compression method used for image data 619 Default = 1 (no compression, so may not be omitted for FAX) 621 FillOrder(266) SHORT 622 RequiredByTIFFforFax 623 The default bit order in Baseline TIFF per [TIFF] is indicated by 624 FillOrder=1, where bits are not reversed before being stored. 625 However, TIFF for Fax typically utilizes the setting of FillOrder=2, 626 where the bit order within bytes is reversed before storage (i.e., 627 bits are stored with the Least Significant Bit first). 628 Default = 1 (field may be omitted if this is the value) 629 Facsimile data appears on the phone line in bit-reversed order 630 relative to its description in the relevant ITU compression 631 Recommendation. Therefore, a wide majority of facsimile 632 implementations choose this natural order for storage. Nevertheless, 633 all readers conforming to this specification must be able to read 634 data in both bit orders, except in the case of Profile S, which only 635 requires support for FillOrder=2 (Least Significant Bit first). 637 ImageWidth(256) SHORT or LONG 638 RequiredByTIFFBaseline 639 The number of pixels (columns) per scanline (row) of the image 640 No default, must be specified. 642 NewSubFileType(254) LONG 643 RequiredByTIFFforFAX 644 A general indication of the kind of data contained in this IFD 645 Bit 1 is 1 if the image is a single page of a multi-page document. 646 Default = 0 (no subfile bits on, so may not be omitted for FAX) 648 PhotometricInterpretation(262) SHORT 649 RequiredByTIFFBaseline 650 The color space of the image data 651 No default, must be specified 653 ResolutionUnit(296) SHORT 654 RequiredByTIFFBaseline 655 The unit of measure for resolution. 2 = inch, 3 = centimeter; 656 Default = 2 (field may be omitted if this is the value) 658 SamplesPerPixel(277) SHORT 659 RequiredByTIFFBaseline 660 The number of color components per pixel; SamplesPerPixel is 1 for a 661 black-and-white, grayscale or indexed (palette) image. 662 Default =1 (field may be omitted if this is the value) 664 XResolution(282) RATIONAL 665 RequiredByTIFFBaseline 666 The horizontal resolution of the image in pixels per resolution 667 unit. The ITU-T Recommendations for facsimile specify a small number 668 of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and 669 80, 160 pixels per centimeter (or 204, 408 pixels per inch). The 670 allowed XResolution values for each profile are given in the section 671 defining that profile. Per [T.4], it is permissible for applications 672 to treat the following XResolution values as being equivalent: <204, 673 200> and <400,408> in pixels/inch. These equivalencies were allowed 674 by [T.4] to permit conversions between inch and metric based 675 facsimile terminals. To insure interoperability, if an application 676 accepts any member of the pairs then T.4 requires it to accept both 677 (e.g. accept 204 if 200 pixels per inch is accepted). TIFF for 678 Facsimile Writers SHOULD express XResolution in inch based units, 679 for consistency with historical practice and to maximize 680 interoperability. See the table below for information on how to 681 convert from an ITU-T metric value to its inch based equivalent 682 resolution. 683 No default, must be specified 685 YResolution(283) RATIONAL 686 RequiredByTIFFBaseline 687 The vertical resolution of the image in pixels per resolution unit. 688 The ITU-T Recommendations for facsimile specify a small number of 689 vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5, 690 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The 691 allowed YResolution values for each profile are given in the section 692 defining that profile. Per [T.4], it is permissible for applications 693 to treat the following YResolution values as being equivalent: <98, 694 100>, <196, 200>, and <391, 400> in pixels/inch. These equivalencies 695 were allowed by [T.4] to permit conversions between inch and metric 696 based facsimile terminals. To insure interoperability, if an 697 application accepts any member of the pairs then T.4 requires it to 698 accept both (e.g. accept 98 if 100 pixels per inch is accepted). 699 TIFF for Facsimile Writers SHOULD express YResolution in inch based 700 units, for consistency with historical practice and to maximize 701 interoperability. See the table below for information on converting 702 from the metric value to its inch based equivalent resolution. 703 No default, must be specified 705 +-----------------------------+-----------------------------+ 706 | XResolution | YResolution | 707 +--------------+--------------+--------------+--------------+ 708 |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit| 709 | =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) | 710 +--------------+--------------+--------------+--------------+ 711 | 100 | | 100 | | 712 +--------------+--------------+--------------+--------------+ 713 | 204 | 80 | 98 | 38.5 | 714 | 200 | | 100 | | 715 +--------------+--------------+--------------+--------------+ 716 | 204 | 80 | 196 | 77 | 717 | 200 | | 200 | | 718 +--------------+--------------+--------------+--------------+ 719 | 204 | 80 | 391 | 154 | 720 +--------------+--------------+--------------+--------------+ 721 | 300 | | 300 | | 722 +--------------+--------------+--------------+--------------+ 723 | 408 | 160 | 391 | 154 | 724 | 400 | | 400 | | 725 +--------------+--------------+--------------+--------------+ 727 2.2.3 TIFF fields recommended for all fax profiles 729 The TIFF fields listed in this section MAY be used by all fax 730 profiles. However, Profile S writers (the minimal fax profile 731 described in Section 3) SHOULD NOT use these fields. Recommended 732 fields that are profile-specific are described in Sections 3-8. 734 DateTime(306) ASCII 735 OptionalInTIFFBaseline 736 Date/time of image creation in 24-hour format "YYYY:MM:DD HH:MM:SS". 737 No default. 739 DocumentName(269) ASCII 740 OptionalInTIFFExtension(DocumentStorageAndRetrieval) 741 The name of the scanned document. This is a TIFF extension field, 742 not a Baseline TIFF field. 743 No default. 745 ImageDescription(270) ASCII 746 OptionalInTIFFBaseline 747 A string describing the contents of the image. 748 No default. 750 Orientation(274) = 1-8. SHORT 751 OptionalinTIFFBaseline 752 1: 0th row represents the visual top of the image; the 0th column 753 represents the visual left side of the image. See the current TIFF 754 spec [TIFF] for further values; Baseline TIFF only requires value=1. 755 Default = 1. 756 Note: It is recommended that a writer that is aware of the 757 orientation include this field to give a positive indication of 758 the orientation, even if the value is the default. Writers should 759 not generate mirror images, because many readers will not properly 760 reverse the image before display or print. 762 Software(305) ASCII 763 OptionalInTIFFBaseline 764 The name and release number of the software package that 765 created the image. 766 No default. 768 2.2.4 New TIFF fields recommended for fax profiles 770 The new TIFF fields listed in this section MAY be used by all fax 771 profiles. However, Profile S writes (the minimal fax profile 772 described in Section 3) SHOULD NOT use these fields. In addition, 773 support for these new TIFF fields has not been included in historical 774 TIFF-F readers described in Section 4 and [TIFF-F]. These fields 775 describe "global" parameters of the fax session that created the image 776 data. They are optional, not part of the current TIFF specification, 777 and are defined in this document. 779 The first new field, GlobalParametersIFD, is an IFD that contains 780 global parameters and is located in a Primary IFD. 782 GlobalParametersIFD (400) IFD or LONG 783 An IFD containing global parameters. It is recommended that a TIFF 784 writer place this field in the first IFD, where a TIFF reader would 785 find it quickly. 787 Each field in the GlobalParametersIFD is a TIFF field that is legal 788 in any IFD. Required baseline fields should not be located in the 789 GlobalParametersIFD, but should be in each image IFD. If a conflict 790 exists between fields in the GlobalParametersIFD and in the image 791 IFDs, then the data in the image IFD shall prevail. 793 Among the GlobalParametersIFD entries is a new ProfileType field 794 which generally describes information in this IFD and in the TIFF 795 file. 797 ProfileType(401) LONG 798 The type of image data stored in this IFD. 799 0 = Unspecified 800 1 = Group 3 fax 801 No default 803 The following new global fields are defined in this document as IFD 804 entries for use with fax applications. 806 FaxProfile(402) = 0 - 6. BYTE 807 The profile that applies to this file; a profile is subset of the 808 full set of permitted fields and field values of TIFF for facsimile. 809 The currently defined values are: 810 0: does not conform to a profile defined for TIFF for facsimile 811 1: minimal black & white lossless, Profile S 812 2: extended black & white lossless, Profile F 813 3: lossless JBIG black & white, Profile J 814 4: lossy color and grayscale, Profile C 815 5: lossless color and grayscale, Profile L 816 6: Mixed Raster Content, Profile M 818 CodingMethods(403) LONG 819 This field indicates which coding methods are used in the file. A 820 value of 1 in a bit location indicates the corresponding coding 821 method is used. More than one bit set to 1 means more than one 822 coding method is used in the file. 823 Bit 0: unspecified compression, 824 Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman), 825 Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read), 826 Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR), 827 Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG), 828 Bit 5: ITU-T Rec. T.81 (Baseline JPEG), 829 Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color), 830 Bits 7-31: reserved for future use 831 Note: There is a limit of 32 compression types to identify standard 832 compression methods. 834 VersionYear(404) BYTE 835 Count: 4 836 The year of the standard specified by the FaxProfile field, given as 837 4 characters, e.g. '1997'; used in lossy and lossless color 838 profiles. 840 ModeNumber (405) BYTE 841 The mode of the standard specified by the FaxProfile field. A 842 value of 0 indicates Mode 1.0; used in Mixed Raster Content profile. 844 3. Profile S - Minimal Black-and-White Fax Profile 846 This section defines the minimal black-and-white subset of TIFF for 847 facsimile. This subset is designated Profile S. All implementations 848 of TIFF for facsimile SHALL support the minimal subset. 850 Black-and-white mode is the binary fax application most users are 851 familiar with today. This mode is appropriate for black-and-white 852 text and line art. Black-and-white mode is divided into two levels of 853 capability. This section describes the minimal interchange set of 854 TIFF fields that must be supported by all implementations in order to 855 assure that some form of image, albeit black-and-white, can be 856 interchanged. This minimum interchange set is a strict subset of the 857 fields and values defined for the extended black-and-white profile 858 (TIFF-F or Profile F) in Section 4, which describes extensions to the 859 minimal interchange set of fields that provide a richer set of 860 black-and-white capabilities. 862 3.1. Overview 864 The minimal interchange portion of the black-and-white facsimile mode 865 supports 1-dimensional Modified Huffman (MH) compression, with the 866 original Group 3 fax resolutions, commonly called "standard" and 867 "fine." 869 To assure interchange, this profile uses the minimal set of fields, 870 with a minimal set of values. There are no recommended fields in this 871 profile. Further, the TIFF file is required to be "little endian," 872 which means that the byte order value in the TIFF header is "II". 873 This profile defines a required ordering for the pages in a fax 874 document and for the IFDs and image data of a page. It also requires 875 that a single strip contain the image data for each page; see Section 876 3.5. The image data may contain RTC sequences, as specified in 877 Section 3.4. 879 3.2. Required TIFF Fields 881 Besides the fields listed in Section 2.2.1, the minimal black-and- 882 white fax profile requires the following fields. The fields listed in 883 Section 2.2.1 and the fields and fax-specific values specified in 884 this sub- section must be supported by all implementations. 886 3.2.1 Baseline fields 888 BitsPerSample(258) = 1. SHORT 889 RequiredByTIFFBaseline 890 Binary data only. 891 Default = 1 (field may be omitted if this is the value) 893 Compression(259) = 3. SHORT 894 RequiredByTIFFBaseline 895 3 = 1- or 2- dimensional coding. 896 The value 3 is a TIFF extension value [TIFF]. The T4Options field 897 must be specified and its value specifies that the data is encoded 898 using the Modified Huffman (MH) compression of [T.4]. 900 FillOrder(266) = 2. SHORT 901 RequiredByTIFFBaseline 902 2 = Least Significant Bit first 904 NOTE: Baseline TIFF readers are only required to support FillOrder = 905 1, where the lowest numbered pixel is stored in the MSB of the byte. 906 However, because many devices, such as modems, transmit the LSB first 907 when converting the data to serial form, it is common for black-and- 908 white fax products to use the second FillOrder =2, where the lowest 909 numbered pixel is stored in the LSB. Therefore, this value is 910 specified in the minimal black-and-white profile. 912 ImageWidth(256) = 1728. SHORT or LONG 913 RequiredByTIFFBaseline 914 This profile only supports a page width of 1728 pixels. This width 915 corresponds to North American Letter and Legal and to ISO A4 size 916 pages. 917 No default, must be specified. 919 NewSubFileType(254) = (Bit 1=1). LONG 920 RequiredByTIFFforFAX 921 Bit 1 is 1 if the image is a single page of a multi-page document. 922 Default = 0 (no subfile bits on, so may not be omitted for fax) 924 PhotometricInterpretation(262) = 0. SHORT 925 RequiredByTIFFBaseline 926 0 = pixel value 1 means black 927 No default, must be specified 929 ResolutionUnit(296) = 2. SHORT 930 RequiredByTIFFBaseline 931 The unit of measure for resolution. 2 = inch. 932 Default = 2 (field may be omitted if this is the value) 934 SamplesPerPixel(277) = 1. SHORT 935 RequiredByTIFFBaseline 936 The number of components per pixel; 1 for black-and-white 937 Default =1 (field may be omitted if this is the value) 939 XResolution(282) = 200, 204. RATIONAL 940 RequiredByTIFFBaseline 941 The horizontal resolution of the image is expressed in pixels per 942 resolution unit. In pixels/inch, the allowed values are 200 and 204, 943 which may be treated as equivalent. See Section 2.2.2 for inch- 944 metric equivalency. 945 No default, must be specified 947 YResolution(283) = 98, 100, 196, 200. RATIONAL 948 RequiredByTIFFBaseline 949 The vertical resolution of the image is expressed in pixels per 950 resolution unit. In pixels/inch, the allowed values are 98, 100, 951 196 and 200; 98 and 100 may be treated as equivalent, and 196 and 952 200 may be treated as equivalent. See Section 2.2.2 for inch-metric 953 equivalency. 954 No default, must be specified 956 3.2.2 Extension fields 958 T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1) LONG 959 RequiredTIFFExtension (when Compression = 3) 960 Bit 0 = 0 indicates MH compression. 961 Bit 1 must be 0 962 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 963 aligned 964 Default is all bits are 0 (applies when EOLs are not byte aligned) 966 Note: The T4Options field is required when the Compression field has 967 a value of 3. Bit 0 of this field specifies the compression used (MH 968 only in this profile). MH coding requires the use of EOL (End of 969 Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned 970 or not. See Section 3.4 for details. 972 3.2.3. New Fields 974 None. 976 3.3. Recommended TIFF Fields 978 None. 980 3.4. End of Line (EOL) and Return to Control (RTC) 982 TIFF extensions for fax, used in this specification, differ from 983 Baseline TIFF in the following ways: 984 - a 12-bit EOL sequence MUST precede each line of MH-compressed 985 image data. (Baseline TIFF does not use these EOL sequences.) 986 - the EOL sequence MAY be byte-aligned, in which case fill bits are 987 added so that the EOL sequence ends on a byte boundary, and any 988 subsequent image data begins on a byte boundary. 989 - if the EOL codes are not byte aligned, the image data MAY be 990 followed by an RTC (Return to Control) sequence, consisting of 991 6 consecutive EOLs. 993 In conventional fax, an MH-compressed fax data stream for a page 994 consists of the following sequence: 995 EOL, compressed data (first line), EOL, compressed data, ... , 996 EOL, compressed data (last line), RTC (6 consecutive EOL codes) 997 Baseline TIFF does not use EOL codes or Return to Control (RTC) 998 sequences for MH-compressed data. However, the TIFF extension field 999 T4Options used in this specification for MH compression (Compression 1000 = 3) requires EOLs. 1002 Furthermore, Bit 2 in the T4Options field indicates whether or not 1003 the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL 1004 codes are byte aligned, then fill bits have been added as necessary 1005 before EOL codes so that an EOL code always ends on a byte boundary, 1006 and the first bit of data following an EOL begins on a byte boundary. 1007 Without fill bits, an EOL code may end in the middle of a byte. Byte 1008 alignment relieves application software of the burden of bit-shifting 1009 every byte while parsing scan lines for line-oriented image 1010 manipulation (such as writing a TIFF file). Not all TIFF readers 1011 historically used for fax are able to deal with non-byte aligned. 1012 data. 1014 While TIFF extension requires EOL codes, TIFF in fax applications has 1015 traditionally prohibited RTC sequences. Implementations that want 1016 common processing and interfaces for fax data streams and Internet 1017 fax files would prefer that the TIFF data include RTC sequences. 1019 To reconcile these differences, RTCs are allowed in cases where EOL 1020 codes are not byte aligned and no fill bits have been added to the 1021 data. This corresponds to situations where the fax data is simply 1022 inserted in a strip without being processed or interpreted. RTCs 1023 should not occur in the data when EOLs have been byte aligned. This 1024 is formally specified in the next sub-section. 1026 3.4.1. RTC Exclusion 1028 Implementations which wish to maintain strict conformance with TIFF 1029 and compatibility with the historical use of TIFF for fax SHOULD NOT 1030 include the RTC sequence when writing TIFF files. However, 1031 implementations which need to support "transparency" of T.4-generated 1032 image data MAY include RTCs when writing TIFF files if the flag 1033 settings of the T4Options field are set for non-byte aligned data, 1034 i.e. Bit 2 is 0. Implementors of TIFF readers should be aware that 1035 there are some existing TIFF implementations for fax that include the 1036 RTC sequence in MH image data. Therefore, minimal set readers MUST be 1037 able to process files which do not include RTCs and SHOULD be able to 1038 process files which do include RTCs. 1040 3.5. File Structure 1042 The TIFF header, described in Section 2.1.1, contains two bytes which 1043 describe the byte order used within the file. For the minimal black- 1044 and-white profile, these bytes SHALL have the value "II" (0x4949), 1045 denoting that the bytes in the TIFF file are in LSByte-first order 1046 (little- endian). The first or 0th IFD immediately follows the 1047 header, so that offset to the first IFD is 8. The headers values are 1048 shown in the following table: 1050 +--------+-------------------+--------+-----------+ 1051 | Offset | Description | Value | 1052 +--------+-------------------+--------+-----------+ 1053 | 0 | Byte Order | 0x4949 (II) | 1054 +--------+-------------------+--------+-----------+ 1055 | 2 | Identifier | 42 decimal | 1056 +--------+-------------------+--------+-----------+ 1057 | 4 | Offset of 0th IFD | 0x 0000 0008 | 1058 +--------+-------------------+--------+-----------+ 1060 The minimal black-and-white profile SHALL order IFDs and image data 1061 within a file as follows: 1) there SHALL be an IFD for each page in a 1062 multi- page fax document; (2) the IFDs SHALL occur in the same order 1063 in the file as the pages occur in the document; (3) the IFD SHALL 1064 precede the image data to which it has offsets; (4) the image data 1065 SHALL occur in the same order in the file as the pages occur in the 1066 document; (5) the IFD, the value data and the image data it has 1067 offsets to SHALL precede the next image IFD; and (6) the image data 1068 for each page SHALL be contained within a single strip. 1070 As a result of (6), the StripOffsets field will contain the pointer 1071 to the image data. With two exceptions, the field entries in the IFD 1072 contain the field values instead of offsets to field values located 1073 outside the IFD. The two exceptions are the values for the 1074 XResolution and YResolution fields, both of which are type RATIONAL 1075 and require 2 4- byte numbers. These "long" field values SHALL be 1076 placed immediately after the IFD which contains the offsets to them, 1077 and before the image data pointed to by that IFD. 1079 The effect of these requirements is that the IFD for the first page 1080 SHALL come first in the file after the TIFF header, followed by the 1081 long field values for XResolution and YResolution, followed by the 1082 image data for the first page, then the IFD for second page, etc. 1083 This is shown in the following figure. Each IFD is required to have a 1084 PageNumber field, which has value 0 for the first page, 1 for the 1085 second page, and so on. 1087 +-----------------------+ 1088 | Header |------------+ 1089 +-----------------------+ | First IFD 1090 | IFD (page 0) | <----------+ Offset 1091 +---| |------------+ 1092 | | |--+ | 1093 Value | +-----------------------+ | | 1094 Offset +-->| Long Values | | | 1095 +-----------------------| | Strip | 1096 | Image Data (page 0) |<-+ Offset | 1097 +-----------------------+ | Next IFD 1098 | IFD (page 1) | <----------+ Offset 1099 +---| |------------+ 1100 | | |--+ | 1101 Value | +-----------------------+ | | 1102 Offset +-->| Long Values | | | 1103 +-----------------------| | Strip | 1104 | Image Data (page 1) |<-+ Offset | 1105 +-----------------------+ | Next IFD 1106 | IFD (page 2) | <----------+ Offset 1107 +-----------------------+ 1108 | : | 1110 Using this file structure may reduce the memory requirements in 1111 implementations. It is also provides some support for streaming, in 1112 which a file can be processed as it is received and before the entire 1113 file is received. 1115 3.6 Profile S - Minimal Black-and-White Profile Summary 1117 The table below summarizes the TIFF fields that comprise the minimal 1118 interchange set for black-and-white facsimile. The Baseline and 1119 Extension fields and field values MUST be supported by all 1120 implementations. For convenience in the table, certain fields which 1121 have a value that is a sequence of flag bits are shown taking integer 1122 values that correspond to the flags that are set. An implementation 1123 should test the setting of the relevant flag bits individually, 1124 however, to allow extensions to the sequence of flag bits to be 1125 appropriately ignored. (See, for example, T4Options below.) 1127 +---------------------------+--------------------------------+ 1128 | Baseline Fields | Values | 1129 +---------------------------+--------------------------------+ 1130 | BitsPerSample | 1 | 1131 +---------------------------+--------------------------------+ 1132 | Compression | 3: 1D Modified Huffman coding | 1133 | | set T4Options = 0 or 4 | 1134 +------------------------------------------------------------+ 1135 +---------------------------+--------------------------------+ 1136 | FillOrder | 2: least significant bit first | 1137 +---------------------------+--------------------------------+ 1138 | ImageWidth | 1728 | 1139 +---------------------------+--------------------------------+ 1140 | ImageLength | n: total number of scanlines | 1141 | | in image | 1142 +---------------------------+--------------------------------+ 1143 | NewSubFileType | 2: Bit 1 identifies single | 1144 | | page of a multi-page document | 1145 +---------------------------+--------------------------------+ 1146 | PageNumber | n,m: page number n followed by | 1147 | | total page count m | 1148 +---------------------------+--------------------------------+ 1149 | PhotometricInterpretation | 0: pixel value 1 means black | 1150 +---------------------------+--------------------------------+ 1151 | ResolutionUnit | 2: inch | 1152 +---------------------------+--------------------------------+ 1153 | RowsPerStrip | number of scanlines per strip | 1154 | | = ImageLength, with one strip | 1155 +---------------------------+--------------------------------+ 1156 | SamplesPerPixel | 1 | 1157 +---------------------------+--------------------------------+ 1158 | StripByteCounts | number of bytes in TIFF strip | 1159 +---------------------------+--------------------------------+ 1160 | StripOffsets | offset from beginning of | 1161 | | file to single TIFF strip | 1162 +---------------------------+--------------------------------+ 1163 | XResolution | 204, 200 (pixels/inch) | 1164 +---------------------------+--------------------------------+ 1165 | YResolution | 98, 196, 100, 200 (pixels/inch)| 1166 +---------------------------+--------------------------------+ 1167 | Extension Fields | 1168 +---------------------------+--------------------------------+ 1169 | T4Options | 0: MH coding, EOLs not byte | 1170 | | aligned | 1171 | | 4: MH coding, EOLs byte aligned| 1172 +---------------------------+--------------------------------+ 1174 4. Profile F - Extended Black-and-White fax profile 1176 This section defines the extended black-and-white profile or Profile 1177 F of TIFF for facsimile. It provides a standard definition of what 1178 has historically been known as TIFF Class F and now TIFF-F. In doing 1179 so, it aligns this profile with current ITU-T Recommendations for 1180 black-and-white fax and with existing industry practice. 1181 Implementations of this profile include implementations of Profile S. 1183 This section describes extensions to the minimal interchange set of 1184 fields (Profile S) that provide a richer set of black-and-white 1185 capabilities. The fields and values described in this section are a 1186 superset of the fields and values defined for the minimal interchange 1187 set in Section 3. In addition to the MH compression, Modified READ 1188 (MR) and Modified Modified READ (MMR) compression as described in 1189 [T.4] and [T.6] are supported. 1191 Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the 1192 TIFF fields that SHALL be used in this profile. Section 4.3 describes 1193 the fields that MAY be used in this profile. In the spirit of the 1194 original TIFF-F specification, Sections 4.4 and 4.5 discuss technical 1195 implementation issues and warnings. Section 4.6 gives an example use 1196 of TIFF-F. Section 4.7 gives a summary of the required and 1197 recommended fields and their values. 1199 4.1 TIFF-F Overview 1201 Though it has been in common usage for many years, TIFF-F has 1202 previously never been documented in the form of a standard. An 1203 informal TIFF-F document was originally created by a small group of 1204 fax experts led by Joe Campbell. The existence of TIFF-F is noted in 1205 [TIFF] but it is not defined. This document serves as the formal 1206 definition of the F application of [TIFF] for Internet applications. 1207 For ease of reference, the term TIFF-F will be used throughout this 1208 document as a shorthand for the extended black-and-white profile 1209 of TIFF for facsimile. 1211 Up until the TIFF 6.0 specification, TIFF supported various "Classes" 1212 which defined the use of TIFF for various applications. Classes were 1213 used to support specific applications. In this spirit, TIFF-F has 1214 been known historically as "TIFF Class F". Previous informal TIFF-F 1215 documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0 1216 [TIFF], the TIFF Class concept has been eliminated in favor of the 1217 concept of Baseline TIFF. Therefore, this document updates the 1218 definition of TIFF-F as the F profile of TIFF for facsimile, by using 1219 Baseline TIFF as defined in [TIFF] as the starting point and then 1220 adding the TIFF extensions to Baseline TIFF which apply for TIFF-F. 1221 In almost all cases, the resulting definition of TIFF-F fields and 1222 values remains consistent with those used historically in earlier 1223 definitions of TIFF Class F. Where some of the values for fields 1224 have been updated to provide more precise conformance with the ITU-T 1225 [T.4] and [T.30] fax recommendations, these differences are noted. 1227 4.2. Required TIFF Fields 1229 This section lists the required fields and the values they must have 1230 to be ITU-compatible. Besides the fields listed in Section 2.2.1, the 1231 extended black-and-white fax profile SHALL use the following fields. 1233 4.2.1. Baseline fields 1235 BitsPerSample(258) = 1. SHORT 1236 RequiredByTIFFBaseline 1237 Binary data only. 1238 Default = 1 (field may be omitted if this is the value) 1240 Compression(259) = 3, 4. SHORT 1241 RequiredByTIFFBaseline 1242 3 = 1- or 2- dimensional coding, must have T4Options field This is 1243 a TIFF Extension value [TIFF]. 1244 4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified 1245 Read, must have T6Options field)) This is a TIFF Extension value. 1246 Default = 1 (and is not applicable; field must be specified) 1248 NOTE: Baseline TIFF permits use of value 2 for Modified Huffman 1249 compression, but data is presented in a form which does not use EOLs, 1250 and so TIFF for facsimile uses Compression=3 instead. See Sections 1251 4.4.4, 4.5.1 and 4.5.2 for more information on compression and 1252 encoding. 1254 FillOrder(266) = 1 , 2. SHORT 1255 RequiredByTIFFBaseline 1256 Profile F readers must be able to read data in both bit orders, 1257 but the vast majority of facsimile products store data LSB 1258 first, exactly as it appears on the telephone line. 1259 1 = Most Significant Bit first. 1260 2 = Least Significant Bit first 1262 ImageWidth(256) SHORT or LONG 1263 RequiredByTIFFBaseline 1264 This profile supports the following fixed page widths: 1728, 2592, 1265 3456 (corresponding to North American Letter and Legal, ISO A4 paper 1266 sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and 1267 2432, 3648, 4864 (corresponding to ISO A3 paper size). 1268 No default; must be specified 1270 NOTE: Historical TIFF-F did not include support for the following 1271 widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096 1272 and 4864. Historical TIFF-F documents also included the following 1273 values related to A5 and A6 widths: 816 and 1216. Per the most recent 1274 version of [T.4], A5 and A6 documents are no longer supported in 1275 Group 3 facsimile, so the related width values are now obsolete. See 1276 section 4.5.2 for more information on inch/metric equivalencies and 1277 other implementation details. 1279 NewSubFileType(254) = (Bit 1=1). LONG 1280 RequiredByTIFFforFAX 1281 Bit 1 is 1 if the image is a single page of a multi-page document. 1282 Default = 0 (no subfile bits on, so may not be omitted for fax) 1284 NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page 1285 of a multi-page image. The same bit settings are used when TIFF-F is 1286 used for a one page fax image. See Section 4.4.3 for details on 1287 multi-page files. 1289 PhotometricInterpretation(262) = 0, 1. SHORT 1290 RequiredByTIFFBaseline 1291 0 = pixel value 1 means black, 1 = pixel value 1 means white. 1292 This field allows notation of an inverted or negative image. 1293 No default, must be specified 1295 ResolutionUnit(296) = 2, 3. SHORT 1296 RequiredByTIFFBaseline 1297 The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F 1298 has traditionally used inch-based measures. 1299 Default = 2 (field may be omitted if this is the value) 1301 SamplesPerPixel(277) = 1. SHORT 1302 RequiredByTIFFBaseline 1303 1 = monochrome, bilevel in this case (see BitsPerSample) 1304 Default =1 (field may be omitted if this is the value) 1306 XResolution(282) = 200, 204, 300, 400, 408 RATIONAL 1307 RequiredByTIFFBaseline 1308 The horizontal resolution of the image is expressed in pixels per 1309 resolution unit. In pixels/inch, the allowed values are: 200, 204, 1310 300, 400, and 408. See Section 2.2.2 for inch-metric equivalency. 1311 No default, must be specified 1313 NOTE: The values of 200 and 408 have been added to the historical 1314 TIFF-F values, for consistency with [T.30]. Some existing TIFF-F 1315 implementations may also support values of 80 pixels/cm, which is 1316 equivalent to 204 pixels per inch. See section 4.5.2 for information 1317 on implementation details. 1319 YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 RATIONAL 1320 RequiredByTIFFBaseline 1321 The vertical resolution of the image is expressed in pixels per 1322 resolution unit. In pixels/inch, the allowed values are: 98, 100, 1323 196, 200, 300, 391, and 400 pixels/inch. 1324 See Section 2.2.2 for inch-metric equivalency. 1325 No default, must be specified 1327 NOTE: The values of 100, 200, and 391 have been added to the 1328 historical TIFF-F values, for consistency with [T.30]. Some existing 1329 TIFF-F implementations may also support values of 77 and 38.5 (cm), 1330 which are equivalent to 196 and 98 pixels per inch respectively. See 1331 section 4.5.2 for more information on implementation details. 1333 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 1334 are legal. The following table gives the legal combinations and 1335 corresponding paper size [T.30]. 1337 +--------------+-----------------+---------------------------+ 1338 | XResolution x YResolution | ImageWidth | 1339 +--------------+-----------------+---------+--------+--------+ 1340 | 200x100, 204x98 | | | | 1341 | 200x200, 204x196 | 1728 | 2048 | 2432 | 1342 | 204x391 | | | | 1343 +--------------+-----------------+---------+--------+--------+ 1344 | 300 x 300 | 2592 | 3072 | 3648 | 1345 +--------------+-----------------+---------+--------+--------+ 1346 | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | 1347 +--------------+-----------------+---------+--------+--------+ 1348 |Letter,A4| B4 | A3 | 1349 | Legal | | | 1350 +---------+--------+--------+ 1351 | Paper Size | 1352 +---------------------------+ 1354 4.2.2. Extension fields 1356 T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) LONG 1357 RequiredTIFFExtension (when Compression = 3) 1358 T4Options was also known as Group3Options in a prior version of 1359 [TIFF]. 1360 Bit 0 = 1 indicates MR compression, = 0 indicates MH compression. 1361 Bit 1 must be 0 1362 Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte 1363 aligned 1364 Default is all bits are 0 (applies when MH compression is used and 1365 EOLs are not byte aligned) (See Section 3.2.2.) 1366 The T4Options field is required when the Compression field has a 1367 value of 3. This field specifies the compression used (MH or MR) and 1368 whether the EOL codes are byte-aligned or not. If they are byte 1369 aligned, then fill bits have been added as necessary so that the End 1370 of Line (EOL) codes always end on byte boundaries See Sections 3.4, 1371 4.5.3 and 4.5.4 for details. 1373 T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG 1374 RequiredTIFFExtension (when Compression = 4) 1375 Used to indicate parameterization of 2D Modified Modified Read (MMR) 1376 compression. T6Options was also known as Group4Options in a prior 1377 version of [TIFF]. 1378 Bit 0 must be 0. 1379 Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1 1380 indicates uncompressed data is allowed (see [TIFF]). 1381 Default is all bits 0. For FAX, the field must be present and have 1382 the value 0. The use of uncompressed data where compression would 1383 expand the data size is not allowed for FAX. 1385 NOTE: MMR compressed data is two-dimensional and does not use EOLs. 1386 Each MMR encoded image MUST include an "end-of-facsimile-block" 1387 (EOFB) code at the end of each coded strip; see Section 4.5.6. 1389 4.2.3. New fields 1391 None. 1393 4.3. Recommended TIFF fields 1395 4.3.1. Baseline fields 1397 See Section 2.2.3. 1399 4.3.2. Extension fields 1401 See Section 2.2.3. 1403 4.3.3. New fields 1405 See Section 2.2.4 and optional fields below. 1407 Three new, optional fields, used in the original TIFF-F description 1408 to describe page quality, are defined in this specification. The 1409 information contained in these fields is usually obtained from 1410 receiving facsimile hardware (if applicable). They SHOULD NOT be used 1411 in writing TIFF-F files for facsimile image data that is error 1412 corrected or otherwise guaranteed not to have coding errors. Some 1413 applications need to understand exactly the error content of the 1414 data. For example, a CAD program might wish to verify that a file 1415 has a low error level before importing it into a high-accuracy 1416 document. Because Group 3 facsimile devices do not necessarily 1417 perform error correction on the image data, the quality of a received 1418 page must be inferred from the pixel count of decoded scan lines. A 1419 "good" scan line is defined as a line that, when decoded, contains 1420 the correct number of pixels. Conversely, a "bad" scan line is 1421 defined as a line that, when decoded, comprises an incorrect number 1422 of pixels. 1424 BadFaxLines(326) SHORT or LONG 1425 The number of "bad" scan lines encountered by the facsimile device 1426 during reception. A "bad" scanline is defined as a scanline that, 1427 when decoded, comprises an incorrect number of pixels. Note that 1428 PercentBad = (BadFaxLines/ImageLength) * 100 1429 No default. 1431 CleanFaxData(327) = 0, 1, 2. SHORT 1432 Indicates if "bad" lines encountered during reception are stored in 1433 the data, or if "bad" lines have been replaced by the receiver. 1434 0 = No "bad" lines 1435 1 = "bad" lines exist, but were regenerated by the receiver, 1436 2 = "bad" lines exist, but have not been regenerated. 1437 No default. 1439 NOTE: Many facsimile devices do not actually output bad lines. 1440 Instead, the previous good line is repeated in place of a bad line. 1441 Although this substitution, known as line regeneration, results in a 1442 visual improvement to the image, the data is nevertheless corrupted. 1443 The CleanFaxData field describes the error content of the data. That 1444 is, when the BadFaxLines and ImageLength fields indicate that the 1445 facsimile device encountered lines with an incorrect number of pixels 1446 during reception, the CleanFaxData field indicates whether these bad 1447 lines are actually still in the data or if the receiving facsimile 1448 device replaced them with regenerated lines. 1450 ConsecutiveBadFaxLines(328) LONG or SHORT 1451 Maximum number of consecutive "bad" scanlines received. The 1452 BadFaxLines field indicates only the quantity of bad lines. 1453 No Default. 1455 NOTE: The BadFaxLines and ImageLength data indicate only the quantity 1456 of bad lines. The ConsecutiveBadFaxLines field is an indicator of the 1457 distribution of bad lines and may therefore be a better general 1458 indicator of perceived image quality. See Section 4.4.5 for examples 1459 of the use of these fields. 1461 4.4. Technical Implementation Issues 1463 4.4.1 Strips 1465 In general, TIFF files divide an image into "strips," also known as 1466 "bands." Each strip contains a few scanlines of the image. By using 1467 strips, a TIFF reader need not load the entire image into memory, 1468 thus enabling it to fetch and decompress small random portions of the 1469 image as necessary. 1471 The number of scanlines in a strip is described by the RowsPerStrip 1472 value and the number of bytes in the strip after compression by the 1473 StripByteCount value. The location in the TIFF file of each strip is 1474 given by the StripOffsets values. 1476 Strip size is application dependent. The recommended approach for 1477 multi- page TIFF-F images is to represent each page as a single 1478 strip. Existing TIFF-F usage is typically one strip per page in 1479 multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3. 1481 4.4.2 Bit Order 1483 The current TIFF specification [TIFF] does not require a Baseline 1484 TIFF reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel 1485 in the least significant bit of a byte. It further recommends that 1486 FillOrder=2 be used only in special purpose applications. 1488 Facsimile data appears on the phone line in bit-reversed order 1489 relative to its description in ITU-T Recommendation T.4. Therefore, 1490 a wide majority of facsimile applications choose this natural order 1491 for data in a file. Nevertheless, TIFF-F readers must be able to read 1492 data in both bit orders and support FillOrder values of 1 and 2. 1494 4.4.3. Multi-Page 1496 Many existing applications already read TIFF-F-like files, but do not 1497 support the multi-page field. Since a multi-page format greatly 1498 simplifies file management in fax application software, TIFF-F 1499 specifies multi-page documents (NewSubfileType = 2) as the standard 1500 case. 1502 It is recommended that applications export multiple page TIFF-F files 1503 without manipulating fields and values. Historically, some TIFF-F 1504 writers have attempted to produce individual single-page TIFF-F files 1505 with modified NewSubFileType and PageNumber (page one-of-one) values 1506 for export purposes. However, there is no easy way to link such 1507 multiple single page files together into a logical multiple page 1508 document, so that this practice is not recommended. 1510 4.4.4. Compression 1512 In Group 3 facsimile, there are three compression methods which had 1513 been standardized as of 1994 and are in common use. The ITU-T T.4 1514 Recommendation [T.4] defines a one-dimensional compression method 1515 known as Modified Huffman (MH) and a two-dimensional method known as 1516 Modified READ (MR) (READ is short for Relative Element Address 1517 Designate). In 1984, a somewhat more efficient compression method 1518 known as Modified Modified READ (MMR) was defined in the ITU-T T.6 1519 Recommendation [T.6]. MMR was originally defined for use with Group 4 1520 facsimile, so that this compression method has been commonly called 1521 Group 4 compression. In 1991, the MMR method was approved for use in 1522 Group 3 facsimile and has since been widely utilized. 1524 TIFF-F supports these three compression methods. The most common 1525 practice is the one-dimensional Modified Huffman (MH) compression 1526 method. This is specified by setting the Compression field value to 1527 3 and then setting bit 0 of the T4Options field to 0. Alternatively, 1528 the two dimensional Modified READ (MR) method, which is much less 1529 frequently used in historical TIFF-F implementations, may be selected 1530 by setting bit 0 of the T4Options field to 1. The value of Bit 2 in 1531 this field is determined by the use of fill bits. 1533 Depending upon the application, the more efficient two-dimensional 1534 Modified Modified Read (MMR)compression method from T.6 may be 1535 selected by setting the Compression field value to 4 and then setting 1536 the first two bits (and all unused bits) of the T6Options field to 0. 1537 More information to aid the implementor in making a compression 1538 selection is contained in Section 4.5.2. 1540 Baseline TIFF also permits use of Compression=2 to specify Modified 1541 Huffman compression, but the data does not use EOLs. As a result, 1542 TIFF-F uses Compression=3 instead of Compression=2 to specify 1543 Modified Huffman compression. 1545 4.4.5. Example Use of Page-quality Fields 1547 Here are examples for writing the CleanFaxData, BadFaxLines, and 1548 ConsecutiveBadFaxLines fields: 1550 1. Facsimile hardware does not provide page quality 1551 information: MUST NOT write page-quality fields. 1552 2. Facsimile hardware provides page quality information, but 1553 reports no bad lines. Write only BadFaxLines = 0. 1554 3. Facsimile hardware provides page quality information, and 1555 reports bad lines. Write both BadFaxLines and 1556 ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or 2 if 1557 the hardware's regeneration capability is known. 1558 4. Source image data stream is error-corrected or otherwise 1559 guaranteed to be error-free such as for a computer generated 1560 file: SHOULD NOT write page-quality fields. 1562 TIFF Writers SHOULD only generate these fields when the image has 1563 been generated from a fax image data stream where error correction, 1564 e.g. Group 3 Error Correction Mode, was not used. 1566 4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F 1567 Files 1569 Traditionally, historical TIFF-F has required readers and writers to 1570 be able to handle multi-page TIFF-F files. Based on the experience 1571 of various TIFF-F implementors, it has been seen that the 1572 implementation of TIFF-F can be greatly simplified if certain 1573 practical guidelines are followed when writing multi-page TIFF-F 1574 files. 1576 The structure for a multi-page TIFF-F file will include one IFD per 1577 page of the document. In this case, this IFD will define the 1578 attributes for a single page. A second simplifying guideline is that 1579 the writer of TIFF-F files SHOULD present IFDs in the same order as 1580 the actual sequence of pages. (The pages are numbered within TIFF-F 1581 beginning with page 0 as the first page and then ascending (i.e. 0, 1582 1, 2,...). However, any field values over 4 bytes will be stored 1583 separately from the IFD. TIFF-F readers SHOULD expect IFDs to be 1584 presented in page order, but be able to handle exceptions. 1586 Per [TIFF], the exact placement of image data is not specified. 1587 However, the strip offsets for each strip of image are defined from 1588 within each IFD. Where possible, another simplifying guideline for 1589 the writing of TIFF-F files is to specify that the image data for 1590 each page of a multi-page document SHOULD be contained within a 1591 single strip (i.e. one image strip per fax page). The use of a single 1592 image strip per page is very useful for applications such as store 1593 and forward messaging, where the file is usually prepared in advance 1594 of the transmission, but other assumptions may apply for the size of 1595 the image strip for applications which require the use of "streaming" 1596 techniques (see section 4.4.7). In the event a different image strip 1597 size guideline has been used (e.g. constant size for image strips 1598 that may be less than the page size), this will immediately be 1599 evident from the values/offsets of the fields that are related to 1600 strips. 1602 A third simplifying guideline is that each IFD SHOULD be placed in 1603 the TIFF-F file structure at a point which precedes the image which 1604 the IFD describes. 1606 In addition, a fourth simplifying guideline for TIFF-F writers and 1607 readers is to place the actual image data in a physical order within 1608 the TIFF file structure which is consistent with the logical page 1609 order. In practice, TIFF-F readers will need to use the strip 1610 offsets to find the exact physical location of the image data, 1611 whether or not it is presented in logical page order. 1613 If the image data is stored in multiple strips, then the strips 1614 SHOULD occur in the file in the same order that the data they contain 1615 occurs in the facsimile transmission, starting at the top of the 1616 page. 1618 TIFF-F writers MAY make a fifth simplifying guideline, in which the 1619 IFD, the value data and the image data to which the IFD has offsets 1620 precede the next image IFD. However, this guideline has been relaxed 1621 (writers MAY rather than SHOULD use it) compared to the other 1622 guidelines given here to reflect past practices for TIFF-F. 1624 In the case of the minimal profile, which is also the minimal subset 1625 of Profile F, the SHOULD's and MAY's of these guidelines become 1626 SHALL's (see Section 3.5). 1628 So, a TIFF-F file which is structured using the guidelines of this 1629 section will essentially be composed of a linked list of IFDs, 1630 presented in ascending page order, which in turn each point to a 1631 single page of image data (one strip per page), where the pages of 1632 image data are also placed in a logical page order within the TIFF- F 1633 file structure. (The pages of image data may themselves be stored in 1634 a contiguous manner, at the option of the implementor). 1636 4.4.7. Use of TIFF-F for Streaming Applications 1638 TIFF-F has historically been used for handling fax image files in 1639 applications such as store and forward messaging where the entire 1640 size of the file is known in advance. While TIFF-F may also possibly 1641 be used as a file format for cases such as streaming applications, 1642 assumptions may be required that differ from those provided in this 1643 section (e.g., the entire size and number of pages within the image 1644 are not known in advance). As a result, a definition for the 1645 streaming application of TIFF-F is beyond the scope of this document. 1647 4.5. Implementation Warnings 1649 4.5.1 Uncompressed data 1651 TIFF-F requires the ability to read and write at least one- 1652 dimensional T.4 Huffman ("compressed") data. Uncompressed data is 1653 not allowed. This means that the "Uncompressed" bit in T4Options or 1654 T6Options must be set to 0. 1656 4.5.2. Encoding and Resolution 1658 Since two-dimensional encoding is not required for Group 3 1659 compatibility, some historic TIFF-F readers have not been able to 1660 read such files. The minimum subset of TIFF-F REQUIRES support for 1661 one dimensional (Modified Huffman) files, so this choice maximizes 1662 portability. However, implementors seeking greater efficiency SHOULD 1663 use T.6 MMR compression when writing TIFF-F files. Some TIFF-F 1664 readers will also support two-dimensional Modified READ files. 1665 Implementors that wish to have the maximum flexibility in reading 1666 TIFF-F files should support all three of these compression methods 1667 (MH, MR and MMR). 1669 For the case of resolution, almost all facsimile products support 1670 both standard (98 dpi) vertical resolution and "fine" (196 dpi) 1671 resolution. Therefore, fine-resolution files are quite portable in 1672 the real world. 1674 In 1993, the ITU-T added support for higher resolutions in the T.30 1675 recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per 1676 inch based units. At the same time, support was added for metric 1677 dimensions which are equivalent to the following inch based 1678 resolutions: 391v x 204h and 391v x 408h. Therefore, the full set of 1679 inch-based equivalents of the new resolutions are supported in the 1680 TIFF-F writer, since they may appear in some image data streams 1681 received from Group 3 facsimile devices. However, many facsimile 1682 terminals and older versions of TIFF-F readers are likely to not 1683 support the use of these higher resolutions. 1685 Per [T.4], it is permissible for applications to treat the following 1686 XResolution values as being equivalent: <204,200> and <400,408>. In 1687 a similar respect, the following YResolution values may also be 1688 treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>. 1689 These equivalencies were allowed by [T.4] to permit conversions 1690 between inch and metric based facsimile terminals. 1692 In a similar respect, the optional support of metric based 1693 resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for 1694 completeness, since they are used in some legacy TIFF-F applications, 1695 but this use is not recommended for the creation of TIFF-F files by a 1696 writer. 1698 4.5.3. EOL byte-aligned 1700 The historical convention for TIFF-F has been that all EOLs in 1701 Modified Huffman or Modified READ data must be byte-aligned. However, 1702 Baseline TIFF has permitted use of non-byte-aligned EOLs by default, 1703 so that a large percentage of TIFF-F reader implementations support 1704 both conventions. Therefore, the minimum subset of TIFF-F, or Profile 1705 S, as defined in Section 3 includes support for both byte-aligned and 1706 non- byte-aligned EOLs; see Section 3.2.2. 1708 An EOL is said to be byte-aligned when Fill bits have been added as 1709 necessary before EOL codes such that EOL always ends on a byte 1710 boundary, thus ensuring an EOL-sequence of a one byte preceded by a 1711 zero nibble: xxxx0000 00000001. 1713 Modified Huffman compression encodes bits, not bytes. This means that 1714 the end-of-line token may end in the middle of a byte. In byte 1715 alignment, extra zero bits (Fill) are added so that the first bit of 1716 data following an EOL begins on a byte boundary. In effect, byte 1717 alignment relieves application software of the burden of bit- 1718 shifting every byte while parsing scan lines for line-oriented image 1719 manipulation (such as writing a TIFF file). 1721 For Modified READ compression, each line is terminated by an EOL and 1722 a one bit tag bit. Per [T.4], the value of the tag bit is 0 if the 1723 next line contains two dimensional data and 1 if the next line is a 1724 reference line. To maintain byte alignment, fill bits are added 1725 before the EOL/tag bit sequence, so that the first bit of data 1726 following an MR tag bit begins on a byte boundary. 1728 4.5.4. EOL 1730 As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded 1731 with Modified Huffman begin with an EOL, which in TIFF-F may be byte- 1732 aligned. The last line of the image is not terminated by an EOL. In 1733 a similar respect, images encoded with Modified READ two-dimensional 1734 compression begin with an EOL, followed by a tag bit. 1736 4.5.5. RTC Exclusion 1738 Aside from EOLs, TIFF-F files have historically only contained image 1739 data. This means that applications which wish to maintain strict 1740 conformance with the rules in [TIFF] and compatibility with 1741 historical TIFF-F, SHOULD NOT include the Return To Control sequence 1742 (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. 1743 However, applications which need to support "transparency" of [T.4] 1744 image data MAY include RTCs if the flag settings of the T4Options 1745 field are set for non-byte aligned MH or MR image data. Implementors 1746 of TIFF readers should also be aware that there are some existing 1747 TIFF-F implementations which include the RTC sequence in MH/MR image 1748 data. Therefore, TIFF-F readers MUST be able to process files which 1749 do not include RTCs and SHOULD be able to process files which do 1750 include RTCs. 1752 4.5.6 Use of EOFB for T.6 Compressed Images 1754 TIFF-F pages which are encoded with the T.6 Modified Modified READ 1755 compression method MUST include an "end-of-facsimile-block" (EOFB) 1756 code at the end of each coded strip. Per [TIFF], the EOFB code is 1757 followed by pad bits as needed to align on a byte boundary. TIFF 1758 readers SHOULD ignore any bits other than pad bits beyond the EOFB. 1760 4.6. Example Use of TIFF-F 1762 The Profile F of TIFF (i.e. TIFF-F content) is a secondary component 1763 of the VPIM Message, as defined in [VPIM 2]. Voice messaging 1764 systems can often handle fax store-and-forward capabilities in 1765 addition to traditional voice message store-and-forward functions. 1766 As a result, TIFF-F fax messages can optionally be sent between 1767 compliant VPIM systems, and may be rejected if the recipient system 1768 cannot deal with fax. 1770 Refer to the VPIM Specification for proper usage of this content. 1772 4.7. Profile F - Extended Black-and-white Fax Profile Summary 1774 Recommended fields are shown with an asterisk *. 1776 Required fields or values are shown with a double asterisk **. If the 1777 double asterisk is on the field name, then all the listed values are 1778 required of implementations; if the double asterisks are in the 1779 Values column, then only the values suffixed with a double asterisk 1780 are required of implementations. 1782 +---------------------------+--------------------------------+ 1783 | Baseline Fields | Values | 1784 +---------------------------+--------------------------------+ 1785 | BitsPerSample | 1** | 1786 +---------------------------+--------------------------------+ 1787 | Compression | 3**: 1D Modified Huffman and | 1788 | | 2D Modified Read coding | 1789 | | 4: 2D Modified Modified Read | 1790 | | coding | 1791 +---------------------------+--------------------------------+ 1792 | DateTime* | {ASCII}: date/time in 24-hour | 1793 | | format "YYYY:MM:DD HH:MM:SS" | 1794 +---------------------------+--------------------------------+ 1795 | FillOrder** | 1: most significant bit first | 1796 | | 2: least significant bit first | 1797 +------------------------------------------------------------+ 1798 +------------------------------------------------------------+ 1799 | ImageDescription* | {ASCII}: A string describing | 1800 | | the contents of the image. | 1801 +---------------------------+--------------------------------+ 1802 | ImageWidth | 1728**, 2048, 2432, 2592, | 1803 | | 3072, 3456, 3648, 4096, 4864 | 1804 +---------------------------+--------------------------------+ 1805 | ImageLength** | n: total number of scanlines | 1806 | | in image | 1807 +---------------------------+--------------------------------+ 1808 | NewSubFileType | 2**: Bit 1 identifies single | 1809 | | page of a multi-page document | 1810 +---------------------------+--------------------------------+ 1811 | Orientation | 1**-8, Default 1 | 1812 +---------------------------+--------------------------------+ 1813 | PhotometricInterpretation | 0: pixel value 1 means black | 1814 | ** | 1: pixel value 1 means white | 1815 +---------------------------+--------------------------------+ 1816 | ResolutionUnit** | 2: inch | 1817 | | 3: centimeter | 1818 +---------------------------+--------------------------------+ 1819 | RowsPerStrip** | n: number of scanlines per | 1820 | | TIFF strip | 1821 +---------------------------+--------------------------------+ 1822 | SamplesPerPixel | 1** | 1823 +---------------------------+--------------------------------+ 1824 | Software* | {ASCII}: name & release | 1825 | | number of creator software | 1826 +---------------------------+--------------------------------+ 1827 | StripByteCounts** | : number or bytes in TIFF | 1828 | | strip | 1829 +---------------------------+--------------------------------+ 1830 | StripOffsets** | : offset from beginning of | 1831 | | file to each TIFF strip | 1832 +---------------------------+--------------------------------+ 1833 | XResolution | 200, 204**, 300, 400, 408 | 1834 | | (written in pixels/inch) | 1835 +---------------------------+--------------------------------+ 1836 | YResolution | 98**, 196**, 100, | 1837 | | 200, 300, 391, 400 | 1838 | | (written in pixels/inch) | 1839 +---------------------------+--------------------------------+ 1840 | Extension Fields | 1841 +---------------------------+--------------------------------+ 1842 +---------------------------+--------------------------------+ 1843 | T4Options | 0**: required if Compression | 1844 | | is Modified Huffman, EOLs are | 1845 | | not byte aligned | 1846 | | 1: required if Compression is | 1847 | | 2D Modified Read, EOLs are | 1848 | | not byte aligned | 1849 | | 4**: required if Compression | 1850 | | is Modified Huffman, EOLs are | 1851 | | byte aligned | 1852 +---------------------------+--------------------------------+ 1853 | T4Options (continued) | 5: required if Compression | 1854 | | is 2D Modified Read, EOLs are | 1855 | | byte aligned | 1856 +---------------------------+--------------------------------+ 1857 | T6Options | 0: required if Compression is | 1858 | | 2D Modified Modified Read | 1859 +---------------------------+--------------------------------+ 1860 | DocumentName* | {ASCII}: name of scanned | 1861 | | document | 1862 +---------------------------+--------------------------------+ 1863 | PageNumber** | n,m: page number followed by | 1864 | | total page count | 1865 +---------------------------+--------------------------------+ 1866 | New Fields | 1867 +---------------------------+--------------------------------+ 1868 | BadFaxLines* | number of "bad" scanlines | 1869 | | encountered during reception | 1870 +---------------------------+--------------------------------+ 1871 | CleanFaxData* | 0: no "bad" lines | 1872 | | 1: "bad" lines exist, but were | 1873 | | regenerated by receiver | 1874 | | 2: "bad" lines exist, but have | 1875 | | not been regenerated | 1876 +---------------------------+--------------------------------+ 1877 | ConsecutiveBadFaxLines* | Max number of consecutive | 1878 | | "bad" lines received | 1879 +---------------------------+--------------------------------+ 1880 | GlobalParametersIFD* | IFD: global parameters IFD | 1881 +---------------------------+--------------------------------+ 1882 | ProfileType* | n: type of data stored in file | 1883 +---------------------------+--------------------------------+ 1884 | FaxProfile* | n: ITU-compatible fax profile | 1885 +---------------------------+--------------------------------+ 1886 | CodingMethods* | n: compression algorithms used | 1887 | | in file | 1888 +---------------------------+--------------------------------+ 1890 5. Profile J - Lossless JBIG Black-and-White Fax profile 1892 This section defines the lossless JBIG black-and-white profile or 1893 Profile J of TIFF for facsimile. Implementations of this profile are 1894 required to also implement Profile S. 1896 The previous section described the extended interchange set of TIFF 1897 fields for black-and-white fax, which provided support for the MH, MR 1898 and MMR compression of black-and-white images. This section adds a 1899 profile with JBIG compression capability. 1901 5.1. Overview 1903 This section describes a black-and-white profile that uses JBIG 1904 compression. The ITU-T has approved the single-progression sequential 1905 mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers 1906 improved compression for halftoned originals. JBIG compression is 1907 used in accordance with the application rules given in ITU-T Rec. 1908 T.85 [T.85]. 1910 This profile is essentially the extended black-and-white profile with 1911 JBIG compression used instead of MH, MR or MMR. 1913 5.2. Required TIFF Fields 1915 This section lists the required fields and the values they must have 1916 to be ITU-compatible. Besides the fields listed in Section 2.2.1, the 1917 extended black-and-white fax profile requires the following fields. 1919 5.2.1. Baseline fields 1921 The TIFF fields that SHALL be used in this profile are the same as 1922 those described in Section 4.2.1 for the extended black-and-white 1923 profile, with two exceptions: the following text replaces the text in 1924 Section 4.2.1 for the Compression and FillOrder fields. 1926 Compression(259) = 9. SHORT 1927 RequiredByTIFFBaseline 1928 9 = JBIG coding. This is a TIFF extension value. 1929 Default = 1 (and is not applicable; field must be specified). 1930 Profile J uses ITU-T T.85 profile of T.82; see T82Options field. 1932 FillOrder(266) = 1, 2. SHORT 1933 RequiredByTIFFBaseline 1934 1 = Pixels are arranged within a byte such that pixels with lower 1935 values are stored in the higher-order bits of the byte, i.e. most 1936 significant bit first (MSB). 1937 2 = Pixels are arranged within a byte such that pixels with lower 1938 column values are stored in the lower-order bits of the bytes, i.e., 1939 least significant bit first (LSB). 1941 Profile J readers must be able to read data in both bit orders. 1943 5.2.2. Extension fields 1945 Same fields as those in Section 2.2.1. 1947 5.2.3. New fields 1949 T82Options(435) = 0 LONG 1950 Required when Compression = 9 1951 Individual bits are set to indicate the applicable profile of JBIG 1952 coding; all bits set to 0 indicates ITU-T T.85 profile of T.82; 1953 Other values are for further study. 1954 Default is all bits 0 and field may be omitted if this is the value 1955 (Field may be omitted in Profile J files.) 1957 Note: A T.82 decoder can decode a T.85 encoded image when it handles 1958 the NEWLE marker code as described Corrigendum 1 in [T.85]. 1960 5.3. Recommended TIFF Fields 1962 See Section 2.2.3 and 2.2.4. 1964 5.4. Profile J - Lossless JBIG Black-and-white Fax Profile Summary 1966 Recommended fields are shown with an asterisk *. 1968 Required fields or values are shown with a double asterisk **. If the 1969 double asterisk is on the field name, then all the listed values are 1970 required of implementations; if the double asterisks are in the 1971 Values column, then only the values suffixed with a double asterisk 1972 are required of implementations. 1974 +---------------------------+--------------------------------+ 1975 | Baseline Fields | Values | 1976 +---------------------------+--------------------------------+ 1977 | BitsPerSample | 1** | 1978 +---------------------------+--------------------------------+ 1979 | Compression | 9**: JBIG coding | 1980 +---------------------------+--------------------------------+ 1981 | DateTime* | {ASCII}: date/time in 24-hour | 1982 | | format "YYYY:MM:DD HH:MM:SS" | 1983 +---------------------------+--------------------------------+ 1984 | FillOrder** | 1: most significant bit first | 1985 | | 2: least significant bit first | 1986 +---------------------------+--------------------------------+ 1987 | ImageDescription* | {ASCII}: A string describing | 1988 | | the contents of the image. | 1989 +---------------------------+--------------------------------+ 1990 +---------------------------+--------------------------------+ 1991 | ImageWidth | 1728**, 2048, 2432, 2592, | 1992 | | 3072, 3456, 3648, 4096, 4864 | 1993 +---------------------------+--------------------------------+ 1994 | ImageLength** | n: total number of scanlines | 1995 | | in image | 1996 +---------------------------+--------------------------------+ 1997 | NewSubFileType** | 2: Bit 1 identifies single | 1998 | | page of a multi-page document | 1999 +---------------------------+--------------------------------+ 2000 | Orientation | 1**-8, Default 1 | 2001 +---------------------------+--------------------------------+ 2002 | PhotometricInterpretation | 0: pixel value 1 means black | 2003 | ** | 1: pixel value 1 means white | 2004 +---------------------------+--------------------------------+ 2005 | ResolutionUnit** | 2: inch | 2006 | | 3: centimeter | 2007 +---------------------------+--------------------------------+ 2008 | RowsPerStrip** | n: number of scanlines per | 2009 | | TIFF strip | 2010 +---------------------------+--------------------------------+ 2011 | SamplesPerPixel** | 1 | 2012 +---------------------------+--------------------------------+ 2013 | Software* | {ASCII}: name & release | 2014 | | number of creator software | 2015 +---------------------------+--------------------------------+ 2016 | StripByteCounts** | : number of bytes in TIFF | 2017 | | strip | 2018 +---------------------------+--------------------------------+ 2019 | StripOffsets** | : offset from beginning of | 2020 | | file to each TIFF strip | 2021 +---------------------------+--------------------------------+ 2022 | XResolution | 200, 204**, 300, 400, 408 | 2023 | | (written in pixels/inch) | 2024 +---------------------------+--------------------------------+ 2025 | YResolution | 98**, 196**, 100, | 2026 | | 200, 300, 391, 400 | 2027 | | (written in pixels/inch) | 2028 +---------------------------+--------------------------------+ 2029 | Extension Fields | 2030 +---------------------------+--------------------------------+ 2031 | DocumentName* | {ASCII}: name of document | 2032 | | scanned | 2033 +---------------------------+--------------------------------+ 2034 | PageNumber** | n,m: page number followed by | 2035 | | total page count | 2036 +---------------------------+--------------------------------+ 2037 | New Fields | 2038 +---------------------------+--------------------------------+ 2039 | GlobalParametersIFD* | IFD: global parameters IFD | 2040 +---------------------------+--------------------------------+ 2041 +---------------------------+--------------------------------+ 2042 | T82Options** | 0: T.85 profile of T.82 | 2043 +---------------------------+--------------------------------+ 2044 | ProfileType* | n: type of data stored in file | 2045 +---------------------------+--------------------------------+ 2046 | FaxProfile* | n: ITU-compatible fax profile | 2047 +---------------------------+--------------------------------+ 2048 | CodingMethods* | n: compression algorithms used | 2049 | | in file | 2050 +---------------------------+--------------------------------+ 2052 6. Profile C - Base Color Fax profile 2054 6.1. Overview 2056 This section defines the lossy color profile or Profile C of TIFF for 2057 facsimile. Implementations of this profile are required to also 2058 implement Profile S. 2060 This is the base profile for color and grayscale facsimile, which 2061 means that all applications that support color fax must support this 2062 profile. The basic approach is the lossy JPEG compression [T.4, Annex 2063 E; T.81] of L*a*b* color data [T.42]. Grayscale applications use the 2064 L* lightness component; color applications use the L*, a* and b* 2065 components. 2067 This profile uses a new PhotometricInterpretation field value to 2068 describe the L*a*b* encoding specified in [T.42]. This encoding 2069 differs in two ways from the other L*a*b* encodings used in TIFF 2070 [TIFF, TTN1]: it specifies a different default range for the a* and 2071 b* components, based on a comprehensive evaluation of existing 2072 hardcopy output, and it optionally allows selectable range for the 2073 L*, a* and b* components. 2075 6.2. Required TIFF Fields 2077 This section lists the required fields, in addition to those given in 2078 Section 2.2.1, and the values they must support to be compatible with 2079 ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4. 2081 6.2.1. Baseline Fields 2083 ImageWidth(256). SHORT or LONG 2084 This profile supports the following fixed page widths: 864, 1024, 2085 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864. 2087 NewSubFileType(254) = (Bit 1=1). LONG 2088 RequiredByTIFFforFAX 2089 Bit 1 is 1 if the image is a single page of a multi-page document. 2090 Default = 0 (no subfile bits on, so may not be omitted for fax) 2092 BitsPerSample(258) = 8. SHORT 2093 Count = SamplesPerPixel 2094 The base color fax profile requires 8 bits per sample. 2096 Compression(259) = 7. SHORT 2097 Base color fax profile uses Baseline JPEG compression. Value 7 2098 represents JPEG compression as specified in [TTN2]. 2100 FillOrder(266) = 1 , 2. SHORT 2101 RequiredByTIFFBaseline 2102 Profile C readers must be able to read data in both bit orders, 2103 but the vast majority of facsimile products store data LSB 2104 first, exactly as it appears on the telephone line. 2105 1 = Most Significant Bit first. 2106 2 = Least Significant Bit first 2108 PhotometricInterpretation(262) = 10. SHORT 2109 Base color fax profile requires pixel values to be stored using the 2110 CIE L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is 2111 indicated by the PhotometricInterpretation value 10, referred to as 2112 ITULAB. With this encoding, the minimum sample value is mapped to 0 2113 and the maximum sample value is mapped to (2^n - 1), i.e. the 2114 maximum value, where n is the BitsPerSample value. The conversion 2115 from unsigned ITULAB-encoded samples values to signed CIE L*a*b* 2116 values is determined by the Decode field; see Sec. 6.2.3 2118 NOTE: PhotometricInterpretation values 8 and 9 specify encodings for 2119 use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1] 2120 data, but they are fixed encodings, which use different minimum and 2121 maximum samples than the T.42 default encoding. As currently defined, 2122 they are not able to represent fax-encoded L*a*b* data. 2124 ResolutionUnit(296) = 2. SHORT 2125 The unit of measure for resolution. 2 = inch 2126 ITU-T standards only specify inch-based resolutions for color fax 2127 Default = 2 (field may be omitted if this is the value) 2129 SamplesPerPixel(277) = 1, 3. SHORT 2130 1: L* component only, required in base color profile 2131 3: L*, a*, b* components 2132 Encoded according to PhotometricInterpretation field 2134 XResolution(282) = 100, 200, 300, 400. RATIONAL 2135 YResolution(283) = 100, 200, 300, 400. RATIONAL 2136 The resolution of the image is expressed in pixels per resolution 2137 unit. In pixels per inch, allowed XResolution values are: 100, 200, 2138 300, and 400. The base color fax profile requires the pixels to be 2139 square, hence YResolution must equal XResolution. Base resolution is 2140 200 pixels per inch and SHALL be supported by all implementations of 2141 this profile. 2143 NOTE: The functional equivalence of inch-based and metric-based resolu- 2144 tions is maintained, per Annex E.6.5 in [T.4]. See table in Sec. 2.2.2. 2146 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 2147 are legal. The following table gives the legal combinations for inch- 2148 based resolutions and the corresponding paper sizes [T.30]. 2150 +--------------------------------+---------------------------+ 2151 | XResolution x YResolution | ImageWidth | 2152 +--------------------------------+---------------------------+ 2153 | 100 x 100 | 864 | 1024 | 1216 | 2154 +--------------------------------+---------------------------+ 2155 | 200 x 200 | 1728 | 2048 | 2432 | 2156 +--------------------------------+---------------------------+ 2157 | 300 x 300 | 2592 | 3072 | 3648 | 2158 +--------------------------------+---------------------------+ 2159 | 400 x 400 | 3456 | 4096 | 4864 | 2160 +--------------------------------+---------------------------+ 2161 |Letter,A4| B4 | A3 | 2162 | Legal | | | 2163 +---------------------------+ 2164 | Paper Size | 2165 +---------------------------+ 2167 6.2.2 Extension Fields 2169 The JPEG compression standard allows for the a*b* chroma components of 2170 an image to be subsampled relative to the L* lightness component. The 2171 extension fields ChromaSubSampling and ChromaPositioning define the 2172 subsampling. They are the same as YCbCrSubSampling and YCbCrPositioning 2173 in [TIFF], but have been renamed to reflect their applicability to other 2174 color spaces. 2176 ChromaSubSampling(530). SHORT 2177 Count = 2 2178 Specifies the subsampling factors for the chroma components of a 2179 L*a*b* image. The two subfields of this field, ChromaSubsampleHoriz 2180 and ChromaSubsampleVert, specify the horizontal and vertical 2181 subsampling factors respectively. 2183 SHORT 0: ChromaSubsampleHoriz = 1, 2. 2184 1: equal numbers of lightness and chroma samples horizontally, 2185 2: twice as many lightness samples as chroma samples horizontally, 2187 SHORT 1: ChromaSubsampleVert = 1, 2. 2188 1: equal numbers of lightness and chroma samples vertically, 2189 2: twice as many lightness samples as chroma samples vertically, 2191 The default value for ChromaSubSampling is (2,2), which is the 2192 default for chroma subsampling in color fax [T.4, Annex E]. No 2193 chroma subsampling, i.e. ChromaSubSampling = (1,1), is an option 2194 for color fax 2196 ChromaPositioning(531) = 1. SHORT 2197 Specifies the spatial positioning of chroma components relative to 2198 the lightness component. 2199 1: centered, 2200 A value of 1 means chrominance samples are spatially offset and 2201 centered with respect to luminance samples. See the current TIFF 2202 specification under YcbCr positioning for further information. 2203 Default = 1, which is what ITU-T T.4, Annex E specifies. 2205 6.2.3. New Fields 2207 Decode(433). SRATIONAL 2208 Count = 2 * SamplesPerPixel 2209 Describes how to map image sample values into the range of values 2210 appropriate for the current color space. In general, the values are 2211 taken in pairs and specify the minimum and maximum output value for 2212 each color component. For the base color fax profile, Decode has a 2213 count of 6 values and maps the unsigned ITULAB-encoded sample values 2214 (Lsample, asample, bsample) to signed L*a*b* values, as follows:. 2216 L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1) 2217 a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1) 2218 b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1) 2220 where Decode[0], Decode[2] and Decode[4] are the minimum values for 2221 L*, a* and b*; Decode[1], Decode[3] and Decode[5] are the maximum 2222 values for L*, a* and b*; and n is the BitsPerSample. When n=8, 2223 L*=Decode[0] when Lsample=0 and L*=Decode[1] when Lsample=255. 2225 ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range 2226 and offset for each component, which are related to the minimum and 2227 maximum values as follows: 2229 minimum = - (range x offset) / 2^n - 1 2230 maximum = minimum + range 2232 The Decode field default values depend on the color space. For the 2233 ITULAB color space encoding, the default values correspond to the 2234 base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The 2235 following table gives the base range and offset values for 2236 BitsPerSample=8, and the corresponding default minimum and 2237 maximum default values for the Decode field, calculated using the 2238 equations above when PhotometricInterpetation=10. 2240 Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset, 2241 and hence the minimum and maximum values, for other BitsPerSample 2242 values. 2244 +-----------------------------------------------+ 2245 | ITU-T Rec. T.42 | Decode | 2246 +---------+-----------| base values | default values | 2247 | BitsPer + Component +------------------+----------------------------+ 2248 | -Sample | | Range | Offset | Min | Max | 2249 +---------+-----------+--------+---------+--------------+-------------+ 2250 | 8 | L* | 100 | 0 | 0 | 100 | 2251 | +-----------+--------+---------+--------------+-------------+ 2252 | | a* | 170 | 128 | -21760/255 | 21590/255 | 2253 | +-----------+--------+---------+--------------+-------------+ 2254 | | b* | 200 | 96 | -19200/255 | 31800/255 | 2255 +---------+-----------+--------+---------+--------------+-------------+ 2257 For example, when PhotometricInterpretation=10 and BitsPerSample=8, 2258 the default value for Decode is (0, 100, -21760/255, 21590/255, 2259 -19200/255, 31800/255). For guidelines on the use of the Decode field, 2260 see section 5.2.2 of [GUIDE]. 2262 6.3. Recommended TIFF Fields 2264 See Sections 2.2.3. and 2.2.4. 2266 6.4 Profile C - Base Color Fax Profile Summary 2268 Recommended fields are shown with an asterisk * 2270 Required fields or values are shown with a double asterisk **. If the 2271 double asterisk is on the field name, then all the listed values are 2272 required of implementations; if the double asterisks are in the 2273 Values column, then only the values suffixed with a double asterisk 2274 are required of implementations. 2276 +---------------------------+--------------------------------+ 2277 | Baseline Fields | Values | 2278 +---------------------------+--------------------------------+ 2279 | BitsPerSample | 8**: 8 bits per color sample | 2280 +---------------------------+--------------------------------+ 2281 | Compression** | 7: JPEG | 2282 +---------------------------+--------------------------------+ 2283 | DateTime* | {ASCII}: date/time in 24-hour | 2284 | | format "YYYY:MM:DD HH:MM:SS" | 2285 +---------------------------+--------------------------------+ 2286 +------------------------------------------------------------+ 2287 | FillOrder** | 1: most significant bit first | 2288 | | 2: least significant bit first | 2289 +---------------------------+--------------------------------+ 2290 | ImageDescription* | {ASCII}: A string describing | 2291 | | the contents of the image. | 2292 +---------------------------+--------------------------------+ 2293 | ImageWidth | 864, 1024, 1216, 1728**, 2048 | 2294 | | 2432, 2592, 3072, 3456, 3648 | 2295 | | 4096, 4864 | 2296 +---------------------------+--------------------------------+ 2297 | ImageLength** | n: total number of scanlines | 2298 | | in image | 2299 +---------------------------+--------------------------------+ 2300 | NewSubFileType** | 2: Bit 1 identifies single page| 2301 | | of a multi-page document | 2302 +---------------------------+--------------------------------+ 2303 | Orientation | 1**-8, Default 1 | 2304 +---------------------------+--------------------------------+ 2305 | PhotometricInterpretation | 10**: ITULAB | 2306 +---------------------------+--------------------------------+ 2307 | ResolutionUnit** | 2: inch | 2308 +---------------------------+--------------------------------+ 2309 | RowsPerStrip** | n: number of scanlines per | 2310 | | TIFF strip | 2311 +---------------------------+--------------------------------+ 2312 | SamplesPerPixel | 1**: L* (lightness) | 2313 | | 3: LAB | 2314 +---------------------------+--------------------------------+ 2315 | Software* | {ASCII}: name & release number | 2316 | | of creator software | 2317 +---------------------------+--------------------------------+ 2318 | StripByteCounts** | : number or bytes in | 2319 | | TIFF strip | 2320 +---------------------------+--------------------------------+ 2321 | StripOffsets** | : offset from beginning | 2322 | | of file to each TIFF strip | 2323 +---------------------------+--------------------------------+ 2324 | XResolution | 100, 200**, 300, 400 (written | 2325 | | in pixels/inch) | 2326 +---------------------------+--------------------------------+ 2327 | YResolution | 100, 200**, 300, 400 | 2328 | | (must equal XResolution) | 2329 +---------------------------+--------------------------------+ 2330 +---------------------------+--------------------------------+ 2331 | Extension Fields | 2332 +---------------------------+--------------------------------+ 2333 | DocumentName* | {ASCII}: name of scanned | 2334 | | document | 2335 +---------------------------+--------------------------------+ 2336 | PageNumber** | n,m: page number followed by | 2337 | | total page count | 2338 +---------------------------+--------------------------------+ 2339 | ChromaSubSampling | (1,1), (2, 2)** | 2340 | | (1, 1): equal numbers of | 2341 | | lightness and chroma samples | 2342 | | horizontally and vertically | 2343 | | (2, 2): twice as many lightness| 2344 | | samples as chroma samples | 2345 | | horizontally and vertically | 2346 +---------------------------+--------------------------------+ 2347 | ChromaPositioning | 1**: centered | 2348 +---------------------------+--------------------------------+ 2349 | New Fields | 2350 +---------------------------+--------------------------------+ 2351 | Decode** | minL, maxL, mina, maxa, minb, | 2352 | | maxb: minimum and maximum | 2353 | | values for L*a*b* | 2354 +---------------------------+--------------------------------+ 2355 | GlobalParametersIFD* | IFD: IFD containing | 2356 | | global parameters | 2357 +---------------------------+--------------------------------+ 2358 | ProfileType* | n: type of data stored in | 2359 | | TIFF file | 2360 +---------------------------+--------------------------------+ 2361 | FaxProfile* | n: ITU-compatible fax profile | 2362 +---------------------------+--------------------------------+ 2363 | CodingMethods* | n: compression algorithms | 2364 | | used in file | 2365 +---------------------------+--------------------------------+ 2366 | VersionYear* | byte sequence: year of ITU std | 2367 +---------------------------+--------------------------------+ 2369 7. Profile L - Lossless Color Profile 2371 This section defines the lossless color profile or Profile L of TIFF 2372 for facsimile. Implementations of this profile are required to also 2373 implement Profiles S and C. 2375 7.1. Overview 2377 This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to 2378 losslessly code three types of color and grayscale images: one bit 2379 per color CMY, CMYK and RGB images; a palettized (i.e. mapped) color 2380 image; and continuous tone color and grayscale images. The last two 2381 are multi-level and use the L*a*b* encoding specified in [T.42]. 2383 7.1.1. Color Encoding 2385 While under development, ITU-T Rec. T.43 was called T.Palette, as one 2386 of its major additions was palette or mapped color images. Baseline 2387 TIFF only allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* 2388 color maps, using the encoding specified in ITU-T Rec. T.42. Palette 2389 color images are expressed with indices (bits per sample) of 12 bits 2390 or less, or optionally 13 to 16 bits, per [T.43] and Annex G in 2391 [T.4]. Profile L files use the color table in the T.43 data stream 2392 rather than the TIFF ColorMap field. 2394 Enabling T.43 color maps in TIFF requires the extension field 2395 Indexed, defined in [TTN1], and the PhotometricInterpretation field 2396 value 10, defined in Section 6.2.1. The following table shows the 2397 corresponding PhotometricInterpretation, SamplesPerPixel, 2398 BitsPerSample and Indexed field values for the different T.43 image 2399 types. 2401 +----------------------------------------------------------+ 2402 | Image Type |PhotometricIn| Samples | Bits Per | Indexed | 2403 | |-terpretation| PerPixel | Sample | | 2404 |------------+-------------+----------+----------+---------| 2405 | RGB | 2=RGB | 3 | 1 | 0 | 2406 +----------------------------------------------------------+ 2407 | CMY | 5=CMYK | 3 | 1 | 0 | 2408 +------------+-------------+----------+----------+---------+ 2409 | CMYK | 5=CMYK | 4 | 1 | 0 | 2410 +------------+-------------+----------+----------+---------+ 2411 | Palette | 10=ITULAB | 1 | n | 1 | 2412 +------------+-------------+----------+----------+---------+ 2413 | Grayscale | 10=ITULAB | 1 |2-8, 9-12 | 0 | 2414 +------------+-------------+----------+----------+---------+ 2415 | Color | 10=ITULAB | 3 |2-8, 9-12 | 0 | 2416 +------------+-------------+----------+----------+---------+ 2418 7.1.2. JBIG Compression 2420 T.43 uses the single-progression sequential mode of JBIG, defined in 2421 ITU-T Rec. T.82. (Other compression methods are for further study.) 2422 To code multi-level images using JBIG, which is a bi-level 2423 compression method, an image is resolved into a set of bit-planes, 2424 and each bit-plane is then JBIG compressed. For continuous tone color 2425 and grayscale images, Gray code conversion is used. The Gray code 2426 conversion is part of the data stream encoding, and is therefore 2427 invisible to TIFF. 2429 7.2. Required TIFF Fields 2431 This section lists the required fields, in addition to those in 2432 Section 2.2.1, and the values they must have to be compatible with 2433 ITU-T Rec. T.43. 2435 7.2.1. Baseline Fields 2437 ImageWidth(256). SHORT or LONG 2438 Same page widths as the base color profile; see Section 6.2.1. 2440 NewSubFileType(254) = (Bit 1=1). LONG 2441 RequiredByTIFFforFAX 2442 Bit 1 is 1 if the image is a single page of a multi-page document. 2443 Default = 0 (no subfile bits on, so may not be omitted for fax) 2445 BitsPerSample(258) = 1, 2-8, 9-12. SHORT 2446 Count = SamplesPerPixel 2447 RGB, CMY, CMYK: 1 bit per sample 2448 Continuous tone (L*a*b*): 2-8 bits per sample, 9-12 bits optional 2449 Palette color: 12 or fewer bits per sample 2450 Note: More than 8 bits per sample is not baseline TIFF. 2452 Compression(259) = 10. SHORT 2453 10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG) 2454 coding 2456 FillOrder(266) = 1 , 2. SHORT 2457 RequiredByTIFFBaseline 2458 Profile L readers must be able to read data in both bit orders, 2459 but the vast majority of facsimile products store data LSB 2460 first, exactly as it appears on the telephone line. 2461 1 = Most Significant Bit first. 2462 2 = Least Significant Bit first 2464 PhotometricInterpretation(262) = 2, 5, 10. SHORT 2465 2: RGB 2466 5: CMYK, including CMY 2467 10: ITULAB 2468 Image data may also be stored as palette color images, where pixel 2469 values are represented by a single component that is an index into a 2470 color map using the ITULAB encoding. This color map is specified by 2471 the color palette table embedded in the image data stream. To use 2472 palette color images, set the PhotometricInterpretation to 10, 2473 SamplesPerPixel to 1, Indexed to 1, and use the color map in the 2474 data stream. See Section 7.1.1 for discussion of the color encoding. 2476 ResolutionUnit(296) = 2. SHORT 2477 The unit of measure for resolution. 2 = inch. 2478 ITU-T standards only specify inch-based resolutions for color fax 2479 Default = 2 (field may be omitted if this is the value) 2481 SamplesPerPixel(277) = 1, 3, 4. SHORT 2482 1: Palette color image, or L*-only if Indexed = 0 and 2483 PhotometricInterpretation is 10 (ITULAB). 2484 3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK). 2485 4: CMYK. 2487 XResolution(282) = 100, 200, 300, 400. RATIONAL 2488 YResolution(283) = 100, 200, 300, 400. RATIONAL 2489 The resolution of the image is expressed in pixels per resolution 2490 unit. In pixels per inch, allowed XResolution values are: 100, 200, 2491 300, and 400. The lossless color fax profile requires the pixels to 2492 be square, hence YResolution must equal XResolution. Base resolution 2493 is 200 pixels per inch. 2495 7.2.2. Extension Fields 2497 Indexed(346) = 0, 1. SHORT 2498 0: not a palette-color image 2499 1: palette-color image 2500 This field is used to indicate that each sample value is an index 2501 into an array of color values specified in the image data stream. 2502 Because the color map is embedded in the image data stream, the 2503 ColorMap field is not used in Profile L. Lossless color fax 2504 profile supports palette-color images with the ITULAB encoding. The 2505 SamplesPerPixel value must be 1. 2507 7.2.3. New Fields 2509 Decode(433) SRATIONAL 2510 Decode is used in connection with the ITULAB encoding of image data; 2511 see Section 6.2.3. 2513 7.3. Recommended TIFF Fields 2515 See Sections 2.2.3. and 2.2.4. 2517 7.4. Profile L - Lossless Color Fax Profile Summary 2519 Recommended fields are shown with an asterisk *. 2521 Required fields or values are shown with a double asterisk **. If the 2522 double asterisk is on the field name, then all the listed values are 2523 required of implementations; if the double asterisks are in the 2524 Values column, then only the values suffixed with a double asterisk 2525 are required of implementations. 2527 +--------------------+--------------------------------------+ 2528 | Baseline Fields | Values | 2529 +--------------------+--------------------------------------+ 2530 | BitsPerSample | 1: Binary RGB, CMY(K) | 2531 | | 8**: 8 bits per color sample | 2532 | | 9-12: optional | 2533 +--------------------+--------------------------------------+ 2534 | Compression | 10**: JBIG, per T.43 | 2535 +--------------------+--------------------------------------+ 2536 | DateTime* | {ASCII}: date/time in the 24-hour | 2537 | | format "YYYY:MM:DD HH:MM:SS" | 2538 +--------------------+--------------------------------------+ 2539 | FillOrder** | 1: Most significant bit first | 2540 | | 2: Least significant bit first | 2541 +--------------------+--------------------------------------+ 2542 | ImageDescription* | {ASCII}: A string describing the | 2543 | | contents of the image. | 2544 +--------------------+--------------------------------------+ 2545 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 2546 | | 2592, 3072, 3456, 3648, 4096, 4864 | 2547 +--------------------+--------------------------------------+ 2548 | ImageLength** | n: total number of scanlines in image| 2549 +--------------------+--------------------------------------+ 2550 | NewSubFileType | 2**: Bit 1 identifies single page of | 2551 | | a multi-page document | 2552 +--------------------+--------------------------------------+ 2553 +--------------------+--------------------------------------+ 2554 | Orientation | 1**-8, Default 1 | 2555 +--------------------+--------------------------------------+ 2556 | PhotometricInter- | 2: RGB | 2557 | pretation | 5: CMYK | 2558 | | 10**: ITULAB | 2559 +--------------------+--------------------------------------+ 2560 | ResolutionUnit** | 2: inch | 2561 +--------------------+--------------------------------------+ 2562 | RowsPerStrip** | n: number of scanlines per TIFF strip| 2563 +--------------------+--------------------------------------+ 2564 | SamplesPerPixel | 1**: L* (lightness) | 2565 | | 3: LAB, RGB, CMY | 2566 | | 4: CMYK | 2567 +--------------------+--------------------------------------+ 2568 | Software* | {ASCII}: name & release number of | 2569 | | creator software | 2570 +--------------------+--------------------------------------+ 2571 | StripByteCounts** | : number or bytes in TIFF strip | 2572 +--------------------+--------------------------------------+ 2573 | StripOffsets** | : offset from beginning of file to| 2574 | | each TIFF strip | 2575 +--------------------+--------------------------------------+ 2576 | XResolution | 100, 200**, 300, 400 (pixels/inch) | 2577 +--------------------+--------------------------------------+ 2578 | YResolution | equal to XResolution (pixels must be | 2579 | | square) | 2580 +--------------------+--------------------------------------+ 2581 | Extension Fields | 2582 +--------------------+--------------------------------------+ 2583 | DocumentName* | {ASCII}: name of scanned document | 2584 +--------------------+--------------------------------------+ 2585 | PageNumber** | n,m: page number followed by total | 2586 | | page count | 2587 +--------------------+--------------------------------------+ 2588 | Indexed | 0: not a palette-color image | 2589 | | 1: palette-color image | 2590 +--------------------+--------------------------------------+ 2591 | New Fields | 2592 +--------------------+--------------------------------------| 2593 | Decode | minL, maxL, mina, maxa, minb, maxb: | 2594 | | minimum and maximum values for L*a*b*| 2595 +--------------------+--------------------------------------+ 2596 | GlobalParameters | IFD: global parameters IFD | 2597 | IFD* | | 2598 +-----------------------------------------------------------+ 2599 +--------------------+--------------------------------------+ 2600 | ProfileType* | n: type of data stored in TIFF file | 2601 +--------------------+--------------------------------------+ 2602 | FaxProfile* | n: ITU-compatible fax profile | 2603 +--------------------+--------------------------------------+ 2604 | CodingMethods* | n: compression algorithms used in | 2605 | | file | 2606 +--------------------+--------------------------------------+ 2607 | VersionYear* | byte sequence: year of ITU fax std | 2608 +--------------------+--------------------------------------+ 2610 8. Profile M - Mixed Raster Content Profile 2612 This section defines the Mixed Raster Content profile or Profile M 2613 of TIFF for facsimile. Implementations of this profile are required 2614 To implement Profiles S and C, and may optionally implement Profiles 2615 F, J and L. 2617 8.1. Overview 2619 Unlike previous fax profiles, which use a single coding method and 2620 resolution for an entire fax page, Mixed Raster Content [T.44] 2621 enables different coding methods and resolutions within a single 2622 page. For example, consider a page that contains black-and-white 2623 text, which is best coded with MMR or JBIG, a color bar chart, best 2624 coded with JBIG, and a scanned color image, best coded with JPEG. 2625 Similarly, while spatial resolution of 400 pixels per inch may be 2626 best for the black-and- white text, 200 pixel per inch is usually 2627 sufficient for a color image. 2629 Rather than applying one coding method and resolution to all 2630 elements, MRC allows multiple coders and resolutions within a page. 2631 By itself, MRC does not define any new coding methods or 2632 resolutions. Instead it defines a 3-layer image model for 2633 structuring and combining the scanned image data. The MRC 3-layer 2634 model has been applied here using the TIFF format to yield a data 2635 structure which differs from [T.44] though it applies the same 2636 coding methods, uses the same compressed image data streams and is 2637 consistent with the TIFF principle of a single IFD per image. 2639 8.1.1. MRC 3-layer model 2641 The 3 layers of the MRC model are Foreground and Background, which 2642 are both multi-level, and Mask, which is bi-level. Each layer may 2643 appear only once on a page and is coded independently of the other 2644 two layers. The final image is obtained by using the Mask layer to 2645 determine if output pixels come from the Foreground layer or the 2646 Background layer. When the Mask layer pixel value is 1, the 2647 corresponding pixel from the Foreground layer is selected; when it 2648 is 0, the corresponding pixel from the Background layer is selected. 2649 Details are given in the Introduction of [T.44]. 2651 In our earlier example, the shape of the black-and-white text and 2652 the mask for the color chart could be in the Mask layer, the color 2653 of the chart and text in the Foreground layer, and the color image 2654 in the Background layer. If a Mask layer pixel has a value of 1, 2655 the final image pixel will be, depending on the pixel location, from 2656 either the color chart or text color in the Foreground layer. If a 2657 Mask layer pixel has a value of 0, the final image pixel will be 2658 from the color image in the Background layer. 2660 Each layer is an image and, when present, is represented by at least 2661 one IFD in a TIFF file. This is consistent with TIFF, which provides 2662 fields to define the attributes, such as resolution, image size, 2663 bits per sample, etc., of a single image or layer. The distribution 2664 of content among layers is determined by the writer, as is the 2665 choice of coding method, color encoding and spatial resolution for a 2666 layer. 2668 Not all pages, and not all parts of a page, require 3 layers. If a 2669 page consists of only one layer, then that layer is the primary 2670 image whether it is a Background, Mask, or Foreground layer. If 2671 there is more than one layer, then the Mask must be one of the 2672 layers, in which case it is the primary image. In all cases, the 2673 primary image must be page size. 2675 MRC [T.44] allows a page to be transmitted as a series of stripes 2676 with each stripe consisting of 1, 2 or 3 layers. The number of 2677 scanlines in each stripe can vary over the page. Although [T.44] 2678 does not allow overlap between images of a single layer, the MRC 2679 profile permits overlapping IFDs when one of the IFDs is used only 2680 to define a default image color. According to [T.4] Annex H, stripes 2681 having more than 1 layer SHOULD NOT be more than 256 lines in length 2682 unless the capability to receive longer stripes has been negotiated. 2684 Furthermore, color fax also requires the spatial resolutions of 2685 Background and Foreground images to be legal fax values that are 2686 also integer factors of the Mask image resolution. For example, if 2687 the Mask Layer resolution is 400 pixels per inch, then allowed 2688 resolutions for the Foreground and Background layers are 100, 200 or 2689 400 pixels per inch; if the Mask is at 300 pixels per inch, then 2690 allowed values are 100 and 300. The Foreground and Background layer 2691 resolutions can be independently set of each other. 2693 8.1.2. A TIFF Representation for the MRC 3-layer model 2695 In the TIFF representation of the 3-layer MRC model, each page is 2696 represented by a single IFD, called the Primary IFD. The nextIFD 2697 offset associated with a Primary IFD will point to the Primary IFD 2698 of the next page. If the page consists of a single layer, then the 2699 Primary IFD represents that layer. If more than one layer is present, 2700 the Primary IFD represents the Mask layer and the other layers are 2701 represented by a set of child IFDs that are referenced through the 2702 SubIFD extension field [TTN1] of the Primary IFD. To distinguish MRC- 2703 specific SubIFDs from other SubIFDs, the NewSubFileType field MUST 2704 have Bit 4 ON, indicating an MRC-related IFD. A new ImageLayer field 2705 is also introduced that consists of two values that identify the 2706 layer (Foreground, Background, or Mask) and the order within the 2707 layer (first, second, ... image of the layer); see Section 8.2.3 2709 In Profile M, the Primary IFD represents a complete layer and 2710 corresponds to the primary image described in Section 8.1.1. There 2711 must be no other MRC-related IFDs or SubIFDs that contain image data 2712 corresponding to the layer represented by the Primary IFD. 2714 MRC [T.44] allows a page to be transmitted as a series of stripes. A 2715 strip within an IFD in a Profile M file represents a stripe in a 2716 [T.44] data stream. The [T.44] stripes of the Primary image are 2717 represented by a single, multiple-strip IFD; the [T.44] stripes of 2718 other layers are represented as multiple, single-strip IFDs. 2720 The layer represented by the Primary IFD may consist of strips of 2721 image data, but all the strips must be part of the single Primary 2722 IFD. For example, if the page consisted of only the Background 2723 layer, then all strips associated with the Background layer must be 2724 treated as a single image. Because MRC allows stripes with variable 2725 numbers of scanlines, a reader MUST support StripRowCounts field 2726 because a writer may use it in place of the RowsPerStrip field to 2727 support a variable number of scanlines in each strip of the Primary 2728 IFD. In accordance with [TTN2], each strip shall be independently 2729 encoded, but coding parameters may not change between strips. 2731 Layers other than the layer represented by the Primary IFD store 2732 each strip as a separate IFD, allowing the coding parameters to 2733 change from strip-to-strip as described by the MRC standard [T.44]. 2734 In all cases, if the Mask layer exists, it shall be represented by a 2735 single IFD and a single set of coding parameters. 2737 The use of SubIFDs to store child IFDs is described in [TTN1]. When 2738 the Mask is the primary image, the Background and Foreground layer 2739 images are represented with child IFDs that are referenced by the 2740 SubIFDs field in the Primary IFD. There are many possible ways to 2741 represent the Background and Foreground layer images: (1) the 2742 SubIFD field of the Primary IFD is an array of pointers to all 2743 child image IFDs, one entry per child image; (2) the SubIFD field is 2744 a single pointer to a linked list of all child image IFDs; (3) the 2745 SubIFD field is an array of two pointers, where the first pointer is 2746 to a linked list of all Background layer image IFDs, and the second 2747 pointer is to a linked list of all Foreground layer image IFDs. A 2748 Profile M writer SHOULD structure the Background and Foreground 2749 layer images using (3), as shown in the example below. Furthermore, 2750 the child IFDs representing the Background and Foreground layer 2751 images SHOULD be ordered in the file in the same order as they occur 2752 on the page. However, a Profile M reader must scan all available 2753 child IFDs to locate and identify IFDs associated with MRC layers. 2755 (nextIFD) 2756 PRIMARY IFD PAGE 0 -----------------------> PRIMARY IFD PAGE 1--> ... 2757 ImageLayer = [2,1] 2758 NewSubFileType = 18 2759 SubIFD[0] ---------------------- SubIFD[1] 2760 | | 2761 V V 2762 Child IFD Child IFD 2763 ImageLayer = [1,1] ImageLayer = [3,1] 2764 NewSubFileType = 16 NewSubFileType = 16 2765 | | 2766 |(nextIFD) |(nextIFD) 2767 V V 2768 Child IFD Child IFD 2769 ImageLayer = [1,2] ImageLayer = [3,2] 2770 NewSubFileType = 16 NewSubFileType = 16 2771 | | 2772 |(nextIFD) |(nextIFD) 2773 V V 2774 Child IFD Child IFD 2775 ImageLayer = [1,3] ImageLayer = [3,3] 2776 NewSubFileType = 16 NewSubFileType = 16 2777 | | 2778 |(nextIFD) |(nextIFD) 2779 V V 2780 0 0 2782 The XPosition and YPosition TIFF fields specify the offset to the 2783 upper-left corner of the IFD in resolution units, which are inches 2784 in Profile M; see Section 8.2.2. The Primary IFD must not use 2785 XPosition or YPosition fields. 2787 MRC [T.44] allows the specification of a default image color that is 2788 to be applied in the event no image data is transmitted for a given 2789 stripe and layer. The new field ImageBaseColor is used to store 2790 default image color specifications in Profile M, see 8.2.3. By 2791 setting the StripByteCounts array to zero values, an IFD defining a 2792 default color but containing no encoded image data can be specified. 2793 ImageBaseColor can also be used in IFDs that contain encoded image 2794 data. In that case, the fields of the IFD must accurately reflect 2795 the encoding of the image data. If the StripByteCount entry for a 2796 given strip is 0, then the ImageBaseColor is used for that strip. If 2797 the encoded image data is ITU L*a*b, the ImageBaseColor is 2798 interpreted using the encoding parameters of the image data. If the 2799 image data is not ITU L*a*b*, the ImageBaseColor is interpreted as 2800 8-bit ITU L*a*b*; see Section 8.2.3. 2802 8.2. Required TIFF Fields 2804 This section describes the TIFF fields required, in addition to 2805 those in Section 2.2.1, to represent MRC fax images. Since MRC 2806 stores fax data as a collection of images corresponding to layers or 2807 parts of layers, the coding methods, color encodings and spatial 2808 resolutions used by previous profiles apply to Profile M. Therefore, 2809 the descriptions here will typically reference the appropriate 2810 earlier sections. Fields and values specific to Profile M are 2811 pointed out. 2813 8.2.1. Baseline Fields 2815 ImageWidth(256). SHORT or LONG 2816 Same page widths as Profile C, the base color profile; see Section 2817 6.2.1. In Profile M, the width of a Foreground or Background image 2818 in the coded data stream may be less than the page width, unless the 2819 Background or Foreground is the primary image, in which case the 2820 width of the coded data stream is the page width. The ImageWidth 2821 field will always store the actual width of the coded data. 2823 NewSubFileType(254) = 16, 18. LONG 2824 For Profile M, the NewSubFileType field has two bits that are 2825 required. Bit 1 indicates a single page of a multi-page document 2826 and must be set for the Primary IFD; Bit 4 indicates the MRC imaging 2827 model as described in ITU-T Recommendation T.44 [T.44], and must be 2828 set for Primary IFDs and all MRC-specific child IFDs. 2830 BitsPerSample(258) = 1, 2-8, 9-12 SHORT 2831 SamplesPerPixel(277) = 1, 3, 4. SHORT 2832 Compression(259) = 1, 3, 4, 7, 9, 10. SHORT 2833 For Mask layer, see Sections 4.2.1 and 5.2.1 2834 For Foreground and Background layers, see Sections 6.2.1 and 7.2.1 2835 Compression=1 is not used by previous profiles. An IFD used only to 2836 specify the default image color for a layer and strip will not have 2837 any encoded image data associated with it, i.e., the StripByteCounts 2838 field will contain a 0. Since no image data exists in the IFD, the 2839 Compression field shall be set to 1 indicating no compression. A 2840 Compression field value of 1 is not allowed for any other IFDs. 2842 FillOrder(266) = 1 , 2. SHORT 2843 RequiredByTIFFBaseline 2844 Profile M readers must be able to read data in both bit orders, but 2845 the vast majority of facsimile products store data LSB first, 2846 exactly as it appears on the telephone line 2847 1 = Most Significant Bit first. 2848 2 = Least Significant Bit first 2850 PhotometricInterpretation(262) = 0, 2, 10. SHORT 2851 For Mask layer, 0. For Foreground and Background layers, see 2852 Sections 6.2.1 and 7.2.1. 2854 ResolutionUnit(296) = 2. SHORT 2855 The unit of measure for resolution. 2 = inch 2856 ITU-T standards only specify inch-based resolutions for color fax 2857 Default = 2 (field may be omitted if this is the value). 2859 StripByteCounts(279) SHORT or LONG 2860 In Profile M, it is permissible for the StripByteCounts value for a 2861 given strip to have a zero entry. This means there is no encoded 2862 image data corresponding to that strip. Instead, the current 2863 default image color should be used for the strip. The standard 2864 default image colors are black for the Foreground layer and White 2865 for the Background layer. The ImageBaseColor field can be used to 2866 specify other default colors, see 8.2.3. 2868 XResolution(282) = 100, 200, 300, 400. RATIONAL 2869 YResolution(283) = 100, 200, 300, 400. RATIONAL 2870 The resolution of the image is expressed in pixels per resolution 2871 unit. In pixels per inch, allowed XResolution values for all layers 2872 are: 100, 200, 300, and 400. Color fax requires the pixels to be 2873 square, hence YResolution must equal XResolution for all layers. The 2874 resolution of Background and Foreground layers must each be an 2875 integer factor of the Primary image, which is the Mask layer, when 2876 it is present; see Section 8.4. 2878 8.2.2. Extension Fields 2880 ChromaSubSampling(530). SHORT 2881 ChromaPositioning(531). SHORT 2882 For Foreground and Background layers, see Section 6.2.2. 2884 Indexed(346) = 0, 1. SHORT 2885 For Foreground and Background layers: 1 indicates a palette-color 2886 image, see Section 7.2.2. 2888 T4Options(292) = 0, 1, 4, 5. SHORT 2889 T6Options(293) = 0. SHORT 2890 For Mask layer, see Section 4.2.2. 2892 SubIFDs(330). IFD 2893 Count = number of child IFDs. Each value is an offset from the 2894 beginning of the TIFF file to a child IFD [TTN1]. 2896 XPosition(286). RATIONAL 2897 YPosition(287). RATIONAL 2898 Specifies the horizontal and vertical offsets of the top-left of the 2899 IFD from the top-left of the Primary IFD in resolution units. For 2900 example, if the Primary IFD is at 400 pixels per inch, and a 2901 foreground layer IFD is at 200 pixels per inch and located at pixel 2902 coordinate (345, 678) with respect to the Primary IFD, the XPosition 2903 value is 345/400 and the YPosition value is 678/400 in inches. 2905 The Primary IFD does not use the XPosition or YPosition fields. The 2906 XPosition and YPosition values must be specified for MRC child IFDs; 2907 there is no default value. 2909 8.2.3. New Fields 2911 Decode(433). SRATIONAL 2912 For Foreground and Background layers, see Section 6.2.3. 2914 T82Options(435) LONG 2915 For Mask layer, see Section 5.2.3. 2917 ImageBaseColor(434). SHORT 2918 Count = SamplesPerPixel 2919 In areas of an image layer where no image data is available (i.e. 2920 where no strips are defined, or where the StripByteCounts entry for 2921 a given strip is 0), the color specified by ImageBaseColor will be 2922 used. 2924 If the ImageBaseColor field is used in an IFD that contains image 2925 data encoded in ITU L*a*b*, then the ImageBaseColor will be 2926 interpreted with the color encoding parameters of the image data 2927 (i.e., color gamut, illuminant, bit/sample, and decode). If the 2928 ImageBaseColor field is used in an IFD that contains image data that 2929 is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be 2930 interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the 2931 ImageBaseColor field is used in an IFD that contains no encoded 2932 image data, then the ImageBaseColor SHALL be interpreted as 8 2933 bits/sample, 3 samples/pixel ITU L*a*b*. If the fax data stream 2934 requires a different encoding, then transferring the default color 2935 value between a TIFF file and fax data stream requires a color 2936 conversion. 2938 A [T.44] stripe may contain a Foreground or Background image less 2939 than full stripe size, with the rest of the stripe assuming a 2940 default image color. In this case, the default image color is imaged 2941 first, followed by the image data. In Profile M, this is represented 2942 as a child IFD containing no encoded image data but specifying the 2943 default image color in the ImageBaseColor field. A second child IFD 2944 contains the image data. To insure the default image color is imaged 2945 first, the order value in the ImageLayer field of the IFD defining 2946 the ImageBaseColor field MUST have a lower value than the order 2947 value in the ImageLayer field of the IFD defining the image data. 2949 To define a child IFD specifying a ImageBaseColor but containing no 2950 encoded image data, create an IFD with the following settings. 2952 ImageLayer[0]: specified layer 2953 ImageLayer[1]: less than any other IFDs corresponding 2954 to the same layer and strip. 2955 RowsPerStrip: strip height 2956 ImageLength: strip height 2957 ImageWidth: full image width 2958 BitsPerSample: 8 2959 PhotometricInterpretation: 10 (ITULAB) 2960 SamplesPerPixel: 3 2961 Compression: 1 (none) 2962 X/YResolution: that of the Primary IFD 2963 XPosition: 0 2964 YPosition: the offset from the top of the page to 2965 the beginning of the strip in the 2966 resolution units of inches 2967 StripByteCounts: single 0 value 2968 StripOffsets: single 0 entry 2969 NewSubFileType: bit 4 O (MRC) 2970 ImageBaseColor: desired color in 8 bit ITULAB 2972 For the Foreground layer image, the default value for the 2973 ImageBaseColor field is black. For other cases, including the 2974 Background layer image, the default value is white. 2976 StripRowCounts(559). LONG 2977 Count = number of strips 2978 The number of scanlines stored in a strip. Profile M allows each fax 2979 strip to store a different number of scanlines. For strips with more 2980 than one layer the maximum strip size is either 256 scanlines or 2981 full page size. The 256 maximum SHOULD be used unless the capability 2982 to receive longer strips has been negotiated. This field replaces 2983 RowsPerStrip for IFDs with variable-sized strips. Only one of the 2984 two fields, StripRowCounts and RowsPerStrip, may be used in an IFD. 2986 ImageLayer (34732). LONG 2987 Count = 2 2988 Image layers are defined such that layer 1 is the Background layer, 2989 layer 3 is the Foreground layer, and layer 2 is the Mask layer, 2990 which selects pixels from the Background and Foreground layers. The 2991 ImageLayer tag contains two values, describing the layer to which 2992 the image belongs and the order in which it is imaged. 2994 ImageLayer[0] = 1, 2, 3. 2995 1: Image is a Background image, i.e., the image that will appear 2996 whenever the Mask contains a value of 0. Background images 2997 typically contain low-resolution, continuous-tone imagery. 2998 2: Image is the Mask layer. In MRC, if the Mask layer is present, it 2999 must be the Primary IFD and be full page in extent. 3000 3: Image is a Foreground image, i.e., the image that will appear 3001 whenever the Mask contains a value of 1. The Foreground image 3002 generally defines the color of text or lines, but may also 3003 contain high-resolution imagery. 3005 ImageLayer[1]: 3006 1: first image to be imaged in this layer, 3007 2: second image to be imaged in this layer, 3008 3: ... 3010 In Profile M, more than one image can exist in a single layer. 3011 ImageLayer[1] specifies the order in which images within a single 3012 layer are to be imaged. This insures that overlapping images within 3013 a single layer are imaged correctly. 3015 If an IFD contains no encoded image data and is used to only specify 3016 the ImageBaseColor field, the value of ImageLayer[1] must be less 3017 than that of any other IFD corresponding to the same layer and strip 3018 to insure the image data is interpreted as on top of the default 3019 color. 3021 In Profile M, it is possible to have only a single layer. For 3022 example, if a page contains only a single continuous-tone 3023 photograph, then only the Background layer would occur. In this 3024 case, the Background layer will be stored as the Primary IFD. 3025 ImageLayer[0] will be 1 indicating Background; ImageLayer[1] will be 3026 1 since there can be no other IFDs associated with that layer. No 3027 Mask layer will exist. 3029 8.3. Recommended TIFF Fields 3031 See Sections 2.2.3. and 2.2.4. 3033 8.4. Rules and Requirements for Images 3035 Profile M defines a fundamental set of rules for images in the 3 3036 layer representation. 3038 1. If more than one layer exists, then the binary Mask layer SHALL 3039 be present and be the primary image. The Mask layer SHALL support 3040 the binary data representations defined in Section 3 and MAY 3041 support the binary data representations defined in Sections 4 and 3042 5, with the exception that PhotometricInterpretation MUST be 0. 3043 If only one layer exists, then the image corresponding to that 3044 layer is the primary image. 3046 2. The Primary IFD defines and extends to the entire page boundary; 3047 all attached model images cannot extend beyond the Primary image. 3048 Resolution differences may cause some pixels to "hang over" the 3049 page boundary, but no new pixels should exist completely beyond 3050 the page extent. 3052 3. The Background and Foreground images SHALL support the color 3053 representations defined in Section 6 and MAY support the color 3054 representations defined in Section 7. These images MAY optionally 3055 cover only a portion of the strip or page. 3057 4. Each Primary IFD and each MRC-specific SubIFD must have an 3058 ImageLayer field to specify which layer the IFD belongs to, and 3059 the imaging order of that IFD within the layer. 3061 5. Each Primary IFD must have a NewSubFileType field value set to 3062 18, indicating a single page of a multi-page document (bit 1) and 3063 MRC (bit 4). 3065 6. Each MRC-specific child IFD must have a NewSubFileType field 3066 value set to 16, indicating MRC (bit 4). 3068 7. In MRC fax, each layer is transmitted as a sequence of strips. 3069 If the page consists of a single layer, then all strips shall be 3070 stored in the single Primary IFD. In this case, coding 3071 parameters cannot change between strips. If the page consists of 3072 more than one layer, then all strips of the Mask layer shall be 3073 stored in the single Primary IFD. All strips of the Foreground/ 3074 Background layers SHALL be stored in separate IFDs, referenced by 3075 the Primary IFD's SubIFD field, containing an ImageLayer field 3076 with ImageLayer[0] identifying either Background (layer 1) or 3077 Foreground (layer 3), and Imagelayer[1] identifying order in 3078 which images within a single layer are to be imaged. The TIFF 3079 XPosition and YPosition fields are used to indicate the placement 3080 of these images with respect to the primary image. 3082 8. When the Mask image is present, the resolution of Background and 3083 Foreground images must each be an integer factor of the Mask 3084 image. For example, if the Mask image is 400 pixels/inch, then 3085 the Background or Foreground image may be at 400 pixels/inch 3086 (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). 3088 8.5. Profile M - MRC Fax Profile Summary 3090 Recommended fields are shown with an asterisk * 3092 Required fields or values are shown with a double asterisk **. If the 3093 double asterisk is on the field name, then all the listed values are 3094 required of implementations; if the double asterisks are in the 3095 Values column, then only the values suffixed with a double asterisk 3096 are required of implementations. 3098 +------------------+-----------------------------------------+ 3099 | Baseline Fields | Values | 3100 +------------------+-----------------------------------------+ 3101 | BitsPerSample | 1**: binary mask, RGB, CMY(K) | 3102 | | 2-8**: bits per color sample | 3103 | | 9-12: optional 12 bits/sample | 3104 +------------------+-----------------------------------------+ 3105 | Compression | 1: None (ImageBaseColor IFD only) | 3106 | | 3**: Modified Huffman and Modified Read | 3107 | | 4: Modified Modified Read | 3108 | | 7**: JPEG | 3109 | | 9: JBIG, per T.85 | 3110 | | 10: JBIG, per T.43 | 3111 +------------------+-----------------------------------------+ 3112 | DateTime* | {ASCII): date/time in the 24-hour format| 3113 | | "YYYY:MM:DD HH:MM:SS" | 3114 +------------------+-----------------------------------------+ 3115 | FillOrder** | 1: Most significant bit first | 3116 | | 2: Least significant bit first | 3117 +------------------+-----------------------------------------+ 3118 | ImageDescription*| {ASCII}: A string describing the | 3119 | | contents of the image. | 3120 +------------------+-----------------------------------------+ 3121 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 3122 | | 2592, 3072, 3456, 3648, 4096, 4864 | 3123 | | Note, legal widths for the Primary IFD. | 3124 +------------------+-----------------------------------------+ 3125 | ImageLength** | n: total number of scanlines in image | 3126 +------------------+-----------------------------------------+ 3127 | NewSubFileType** | 16, 18: | 3128 | | Bit 1 indicates single page of a multi- | 3129 | | page document on Primary IFD | 3130 | | Bit 4 indicates MRC model | 3131 +------------------+-----------------------------------------+ 3132 +------------------+-----------------------------------------+ 3133 | Orientation | 1**-8, Default 1 | 3134 +------------------+-----------------------------------------+ 3135 | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | 3136 | pretation | 2: RGB | 3137 | | 10**: ITULAB | 3138 +------------------+-----------------------------------------+ 3139 | ResolutionUnit** | 2: inch | 3140 +------------------+-----------------------------------------+ 3141 | RowsPerStrip | n: number or scanlines per strip | 3142 +------------------+-----------------------------------------+ 3143 | SamplesPerPixel | 1**: L* (lightness) | 3144 | | 3: RGB, LAB, CMY | 3145 | | 4: CMYK | 3146 +------------------+-----------------------------------------+ 3147 | Software* | {ASCII}: name & release number of | 3148 | | creator software | 3149 +------------------+-----------------------------------------+ 3150 | StripByteCounts**| : number or bytes in each strip | 3151 +------------------+-----------------------------------------+ 3152 | StripOffsets** | : offset from beginning of file to | 3153 | | each TIFF strip | 3154 +------------------+-----------------------------------------+ 3155 | XResolution | 100, 200**, 300, 400 (written in | 3156 | | pixels/inch) | 3157 +------------------+-----------------------------------------+ 3158 | YResolution | equal to XResolution (pixels must be | 3159 | | square) | 3160 +------------------+-----------------------------------------+ 3161 | Extension Fields | 3162 +------------------+-----------------------------------------+ 3163 | T4Options | 0**: required if Compression is Modified| 3164 | | Huffman, EOLs not byte aligned | 3165 | | 1: required if Compression 2D Modified | 3166 | | Read, EOLs are not byte aligned | 3167 | | 4**: required if Compression Modified | 3168 | | Huffman, EOLs byte aligned | 3169 | | 5: required if Compression 2D Modified | 3170 | | Read, EOLs are byte aligned | 3171 +------------------+-----------------------------------------+ 3172 | T6Options | 0: required if Compression is 2D | 3173 | | Modified Modified Read | 3174 +------------------+-----------------------------------------+ 3175 | DocumentName* | {ASCII}: name of scanned document | 3176 +------------------+-----------------------------------------+ 3177 | PageNumber** | n,m: page number followed by total page | 3178 | | count | 3179 +------------------+-----------------------------------------+ 3180 +------------------+-----------------------------------------+ 3181 | ChromaSubSampling| (1,1), (2, 2)** | 3182 | | (1, 1): equal numbers of lightness and | 3183 | | chroma samples horizontally & vertically| 3184 | | (2, 2): twice as many lightness samples | 3185 | | as chroma horizontally and vertically | 3186 +------------------+-----------------------------------------+ 3187 | ChromaPositioning| 1: centered | 3188 +------------------+-----------------------------------------+ 3189 | Indexed | 0: not a palette-color image | 3190 | | 1: palette-color image | 3191 +------------------+-----------------------------------------+ 3192 | SubIFDs | : byte offset to FG/BG IFDs | 3193 +------------------+-----------------------------------------+ 3194 | XPosition | horizontal offset in primary IFD | 3195 | | resolution units | 3196 +------------------+-----------------------------------------+ 3197 | YPosition | vertical offset in primary IFD | 3198 | | resolution units | 3199 +------------------+-----------------------------------------+ 3200 | New Fields | 3201 +------------------+-----------------------------------------+ 3202 | Decode | minL, maxL, mina, maxa, minb, maxb: | 3203 | | minimum and maximum values for L*a*b* | 3204 +------------------+-----------------------------------------+ 3205 | ImageBaseColor | a,b,c: background color in ITULAB | 3206 +------------------+-----------------------------------------+ 3207 | StripRowCounts | : number of scanlines in each strip | 3208 +------------------+-----------------------------------------+ 3209 | ImageLayer | n, m: layer number, imaging sequence | 3210 | | (e.g., strip number) | 3211 +------------------+-----------------------------------------+ 3212 | T82Options | 0: T.85 profile of T.82 coding | 3213 +------------------+-----------------------------------------+ 3214 | GlobalParameters | IFD: global parameters IFD | 3215 | IFD* | | 3216 +------------------+-----------------------------------------+ 3217 | ProfileType* | n: type of data stored in TIFF file | 3218 +------------------+-----------------------------------------+ 3219 | FaxProfile* | n: ITU-compatible fax profile | 3220 +------------------+-----------------------------------------+ 3221 | CodingMethods* | n: compression algorithms used in file | 3222 +------------------+-----------------------------------------+ 3223 | ModeNumber* | n: version of T.44 standard | 3224 +------------------+-----------------------------------------+ 3225 | VersionYear* | byte sequence: year of ITU fax standard | 3226 +------------------+-----------------------------------------+ 3228 9. MIME content-types image/tiff and image/tiff-fx 3230 The MIME content-types image/tiff and image/tiff-fx are used for 3231 TIFF-FX encoded image data, as defined in this document. [TIFF-REG] and 3232 [TIFF-FX-REG] describe the registration of these MIME content-types. 3234 10. Security Considerations 3236 This document describes a file format for Internet fax, which is a 3237 series of profiles of TIFF for facsimile. As such, it does not create 3238 any security issues not already identified in [TIFF-REG], in its use 3239 of fields as defined in [TIFF]. There are also new TIFF fields 3240 defined within this specification, but they are of a purely 3241 descriptive nature, so that no new security risks are incurred. 3243 Further, the encoding specified in this document does not in any way 3244 preclude the use of any Internet security protocol to encrypt, 3245 authenticate, or non-repudiate TIFF-encoded facsimile messages. 3247 11. References 3249 11.1 Normative References 3251 [REQ] Bradner, S, "Key words for use in RFCs to Indicate Requirement 3252 Levels", RFC 2119, March 1997. 3254 [T.4] ITU-T Recommendation T.4, Standardization of group 3 facsimile 3255 apparatus for document transmission, October 1997 3257 [T.6] ITU-T Recommendation T.6, Facsimile coding schemes and coding 3258 control functions for group 4 facsimile apparatus, November 1988 3260 [T.30] ITU-T Recommendation T.30 - Procedures for Document Facsimile 3261 Transmission in the General Switched Telephone Network, June 1996 3263 [T.42] ITU-T Recommendation T.42, Continuous-tone colour 3264 representation method for facsimile, February 1996 3266 [T.43] ITU-T Recommendation T.43, Colour and gray-scale image 3267 representations using lossless coding scheme for facsimile, February 3268 1997 3270 [T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC), April 3271 1999. 3273 [T.81] ITU-T Recommendation T.81, Information technology - Digital 3274 compression and coding of continuous-tone still images - Requirements 3275 and guidelines, September 1992 3277 [T.85] ITU-T Recommendation T.85, Application profile for 3278 Recommendation T.82 - Progressive bi-level image compression (JBIG 3279 coding scheme) for facsimile apparatus, August 1995 3281 [T.82] ITU-T Recommendation T.82, Information technology - Coded 3282 representation of picture and audio information - Progressive bi- 3283 level image compression, March 1995 3285 [TIFF] Tag Image File Format, Revision 6.0, Adobe Developers 3286 Association, June 3, 1992, 3287 ftp://ftp.adobe.com/pub/adobe/devrelations/ 3288 devtechnotes/pdffiles/tiff6.pdf 3290 The TIFF 6.0 specification dated June 3, 1992 specification (c) 3291 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved. 3293 [TIFF-F0] TIFF Class F specification, Apr 28, 1990, 3294 ftp://ftp.faximum.com/pub/documents/tiff_f.txt 3296 [TIFF-REG] Parsons, G. and Rafferty J., "Tag Image File 3297 Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, 3298 September 2002 3300 [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995, 3301 http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf 3303 [TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG 3304 specification, March 17, 1995, 3305 ftp://ftp.uu.net/graphics/jpeg/ 3307 [TIFF-FX-REG] McIntyre, L., Parsons, G. and Rafferty, J., "Tag Image 3308 File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type 3309 Registration", RFC 3250, September 2002 3311 The ITU-T Recommendations are available at http://www.itu.ch. 3313 11.2 Informative references 3315 [GUIDE] Cancio, V., Moldovan, M., Tamura, H., and Wing, D., 3316 "Implementers Guide for Facsimile Using Internet Mail", RFC 3249, 3317 September 2002 3319 [TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) 3320 - F Profile for Facsimile", RFC 2306, March 1998. 3322 [VPIM 2] Vaudreuil G. and G. Parsons, "Voice Profile for Internet 3323 Mail - Version 2", work in progress, draft-ietf-vpim-vpimv2r2-05.txt, 3324 February 2002 3326 12. Authors' Addresses 3328 Robert Buckley Dennis Venable 3329 Xerox Corporation Xerox Corporation 3330 Mailstop 0128-30E Mailstop 0128-27E 3331 800 Phillips Road 800 Phillips Road 3332 Webster, NY 14580, USA Webster, NY 14580, USA 3333 Voice: +1-585-422-1282 Voice: +1-585-422-3138 3334 Fax: +1-585-265-8871 Fax: +1-585-422-6117 3335 Email: rbuckley@crt.xerox.com Email: dvenable@crt.xerox.com 3337 Lloyd McIntyre 3338 10328 S. Stelling Road 3339 Cupertino, CA 95014 USA 3340 Voice: +1-408-725-1624 3341 Email: lloyd10328@pacbell.net 3343 Glenn S. Parsons James Rafferty 3344 Nortel Networks Brooktrout Technology 3345 P.O. Box 3511, Station C 410 First Avenue 3346 Ottawa, Ontario K1Y 4H7, Canada Needham, MA 02494 USA 3347 Phone: +1-613-763-7582 Phone: +1-781-433-9462 3348 Fax: +1-613-763-2697 Fax: +1-781-433-9268 3349 Email: Email: jraff@brooktrout.com 3350 Glenn.Parsons@NortelNetworks.com 3352 Annex A: Summary of TIFF Fields for Internet Fax 3354 This annex includes tables which list by profile the TIFF fields used 3355 in the proposed fax file format. The fields are organized into 3 3356 categories: 3358 1) TIFF Baseline Fields 3359 2) TIFF Extension Fields 3360 3) New Fields. 3362 The tables include the allowed values for each fax profile. Entries 3363 other than explicit numbers are described by: 3365 n - single number 3366 n, m - 2 numbers 3367 a, b, c - 3 numbers 3368 r - rational number 3369 - array of numbers 3370 - byte sequence 3371 {ASCII} - string 3372 IFD - IFD byte offset 3373 - array of IFD byte offsets 3375 A blank entry in the table indicates that the field is not used by 3376 that particular fax profile. 3378 Table A.1 TIFF Baseline Fields 3380 +---------------------------------------------------------+ 3381 | Fax Profile | 3382 +---------------------------------------------------------| 3383 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3384 +----------| B&W | B&W | B&W | Color | Color | Raster | 3385 | TIFF | | | | | | Content| 3386 | Field | S | F | J | C | L | M | 3387 +----------+---------+----------+--------+---------+--------+--------+ 3388 | BitsPer | 1 | 1 | 1 | 8 | 1, 2-8 | 1, 2-8 | 3389 | Sample | | | | | 9-12 | 9-12 | 3390 +----------+---------+----------+--------+---------+--------+--------+ 3391 | Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7| 3392 | sion | | | | | | 9,10 | 3393 +----------+---------+----------+--------+---------+--------+--------+ 3394 | DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3395 +----------+---------+----------+--------+---------+--------+--------+ 3396 | FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 | 3397 +----------+---------+----------+--------+---------+--------+--------+ 3398 +----------+---------+----------+--------+---------+--------+--------+ 3399 | ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3400 | cription | | | | | | | 3401 +----------+---------+----------+--------+---------+--------+--------+ 3402 | Image- | n | n | n | n | n | n | 3403 | Length | | | | | | | 3404 +----------+---------+----------+--------+---------+--------+--------+ 3405 | Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, | 3406 | Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, | 3407 | | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 | 3408 | | | Note, for the Mixed Raster Content M profile | 3409 | | | these widths apply to the Primary IFD. | 3410 +----------+---------+----------+--------+---------+--------+--------+ 3411 | NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 | 3412 | FileType | | | | | | | 3413 +----------+---------+----------+--------+---------+--------+--------+ 3414 | Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 | 3415 | tation | | | | | | | 3416 +----------+---------+----------+--------+---------+--------+--------+ 3417 | Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, | 3418 | metric- | | | | | 10 | 2, | 3419 | Interp- | | | | | | 10 | 3420 | retation | | | | | | | 3421 +----------+---------+----------+--------+---------+--------+--------+ 3422 | Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 3423 | tionUnit | | | | | | | 3424 +----------+---------+----------+--------+---------+--------+--------+ 3425 | RowsPer- | n | n | n | n | n | n | 3426 | Strip | | | | | | | 3427 +----------+---------+----------+--------+---------+--------+--------+ 3428 | Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4| 3429 | PerPixel | | | | | | | 3430 +----------+---------+----------+--------+---------+--------+--------+ 3431 | Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3432 +----------+---------+----------+--------+---------+--------+--------+ 3433 | Strip- | n | | | | | | 3434 | Byte- | | | | | | | 3435 | Counts | | | | | | | 3436 +----------+---------+----------+--------+---------+--------+--------+ 3437 | Strip- | n | | | | | | 3438 | Offsets | | | | | | | 3439 +----------+---------+----------+--------+---------+--------+--------+ 3440 | XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 | 3441 | tion | 200 | 400, 408 | | 3442 +----------+---------+----------+--------+---------+--------+--------+ 3443 | YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 | 3444 | tion | 100,200 | 300, 391, 400 | | 3445 +----------+---------+----------+--------+---------+--------+--------+ 3447 Table A.2 TIFF Extension Fields 3449 +---------------------------------------------------------+ 3450 | Fax Profile | 3451 +---------------------------------------------------------| 3452 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3453 +----------| B&W | B&W | B&W | Color | Color | Raster | 3454 | TIFF | | | | | | Content| 3455 | Field | S | F | J | C | L | M | 3456 +----------+---------+----------+--------+---------+--------+--------+ 3457 | Chroma- | | | | 1 | | 1 | 3458 | Position-| | | | | | | 3459 | ing | | | | | | | 3460 +----------+---------+----------+--------+---------+--------+--------+ 3461 | Chroma- | | | | <1, 1> | | <1, 1> | 3462 | SubSampl-| | | | <2, 2> | | <2, 2> | 3463 | ing | | | | | | | 3464 +----------+---------+----------+--------+---------+--------+--------+ 3465 | Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}| 3466 | Name | | | | | | | 3467 +----------+---------+----------+--------+---------+--------+--------+ 3468 | Indexed | | | | | 0,1 | 0,1 | 3469 +----------+---------+----------+--------+---------+--------+--------+ 3470 | Page- | n, m | n, m | n, m | n, m | n, m | n, m | 3471 | Number | | | | | | | 3472 +----------+---------+----------+--------+---------+--------+--------+ 3473 | SubIFDs | | | | | | | 3474 +----------+---------+----------+--------+---------+--------+--------+ 3475 | T4Options| 0, 4 | 0, 1, | | | | 0, 1, | 3476 | | | 4, 5 | | | | 4, 5 | 3477 +----------+---------+----------+--------+---------+--------+--------+ 3478 | T6Options| | 0 | | | | 0 | 3479 +----------+---------+----------+--------+---------+--------+--------+ 3480 | XPosition| | | | | | r | 3481 +----------+---------+----------+--------+---------+--------+--------+ 3482 | YPosition| | | | | | r | 3483 +----------+---------+----------+--------+---------+--------+--------+ 3485 Table A.3 New Fields 3487 +---------------------------------------------------------+ 3488 | Fax Profile | 3489 +---------------------------------------------------------| 3490 | Minimal | Extended | JBIG | Lossy |Lossless| Mixed | 3491 +----------| B&W | B&W | B&W | Color | Color | Raster | 3492 | TIFF | | | | | | Content| 3493 | Field | S | F | J | C | L | M | 3494 +----------+---------+----------+--------+---------+--------+--------+ 3495 | BadFax- | | n | | | | | 3496 | Lines | | | | | | | 3497 +----------+---------+----------+--------+---------+--------+--------+ 3498 | CleanFax-| | 0, 1, 2 | | | | | 3499 | Data | | | | | | | 3500 +----------+---------+----------+--------+---------+--------+--------+ 3501 | Coding- | | | n | n | n | n | 3502 | Method | | | | | | | 3503 +----------+---------+----------+--------+---------+--------+--------+ 3504 | Consecu- | | n | | | | | 3505 | tiveBad- | | | | | | | 3506 | FaxLines | | | | | | | 3507 +----------+---------+----------+--------+---------+--------+--------+ 3508 | Decode | | | | | | | 3509 +----------+---------+----------+--------+---------+--------+--------+ 3510 | Fax- | | | n | n | n | n | 3511 | Profile | | | | | | | 3512 +----------+---------+----------+--------+---------+--------+--------+ 3513 | Global- | | IFD | IFD | IFD | IFD | IFD | 3514 | Parame- | | | | | | | 3515 | tersIFD | | | | | | | 3516 +----------+---------+----------+--------+---------+--------+--------+ 3517 | Image- | | | | | | n, m | 3518 | Layer | | | | | | | 3519 +----------+---------+----------+--------+---------+--------+--------+ 3520 | T82- | | | n | | | n | 3521 | Options | | | | | | | 3522 +----------+---------+----------+--------+---------+--------+--------+ 3523 | Image- | | | | | | | 3524 | BaseColor| | | | | | | 3525 +----------+---------+----------+--------+---------+--------+--------+ 3526 | Mode- | | | | | | n | 3527 | Number | | | | | | | 3528 +----------+---------+----------+--------+---------+--------+--------| 3529 | Profile- | | | n | n | n | n | 3530 | Type | | | | | | | 3531 +--------------------------------------------------------------------+ 3532 +----------+---------+----------+--------+---------+--------+--------+ 3533 | Strip- | | | | | | | 3534 | RowCounts| | | | | | | 3535 +----------+---------+----------+--------+---------+--------+--------+ 3536 | Version- | | | | | | | 3537 | Year | | | | | | | 3538 +----------+---------+----------+--------+---------+--------+--------+ 3540 Annex B. List of technical edits to RFC2301 3542 This Annex lists technical differences between this document and 3543 RFC 2301, the Proposed Standard File Format for Internet Fax. 3545 +----+---------+-------------------------------------------------+ 3546 | No.| Section | Technical Edit | 3547 +----+---------+-------------------------------------------------+ 3548 | 1. | 5.2.1 | Added FillOrder=1 to Profile J | 3549 +----+---------+-------------------------------------------------+ 3550 | 2. | 6.2.1 | Constrained ResolutionUnit to 2 (i.e. inch) for | 3551 | | 7.2.1 | all color profiles, per ITU-T Recommendations | 3552 | | 8.2.1 | | 3553 +----+---------+-------------------------------------------------+ 3554 | 3. | 7.2.1 | Deleted ColorMap field; it re-encoded the color | 3555 | | 7.4 | color palette already in the T.43 data stream | 3556 +----+---------+-------------------------------------------------+ 3557 | 4. | 7.2.2 | Changed TAG value of Indexed field from 364 to | 3558 | | | 346 to agree with Section 8.2.2 and Ref. [TTN1] | 3559 +----+---------+-------------------------------------------------+ 3560 | 5. | 8.2.1 | Added text clarifying the use of ImageWidth | 3561 | | | when Background or Foreground layer is Primary | 3562 | | | IFD | 3563 +----+---------+-------------------------------------------------+ 3564 | 6. | 8.2.3 | Changed field name from DefaultImageColor to | 3565 | | | ImageBaseColor; | 3566 +----+---------+-------------------------------------------------+ 3567 | 7. | 8.2.1 | Added Compression=1 for ImageBaseColor IFDs | 3568 +----+---------+-------------------------------------------------+ 3569 | 8. | 5.2.1 | Redefined compression = 9 to be T.82 (JBIG); | 3570 | | 5.2.3 | added T82Options field, with a default value (0)| 3571 | | | corresponding to the T.85 application profile | 3572 +----+---------+-------------------------------------------------+ 3573 | 9. | 4.3.3 | Added GlobalParametersIFD, ProfileType, | 3574 | | 4.7 | FaxProfile and CodingMethod to the New Fields | 3575 | | | portion of Profile F, per Sec. 2.2.4 | 3576 +----+---------+-------------------------------------------------+ 3577 | 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when | 3578 | |6.2.3,6.4| Compression=7 due to lack of interop testing. | 3579 | |Table A.1| | 3580 +----+---------+-------------------------------------------------+ 3581 | 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M| 3582 | |Table A.1| due to insufficient interop testing. | 3583 +----+---------+-------------------------------------------------+ 3584 | 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette color | 3585 | |8.2.1,8.5| due to lack of interop testing. | 3586 | |Table A.1| | 3587 +----+---------+-------------------------------------------------+ 3588 | 13.| Annex B | Deleted Annex B due to discontinued use of | 3589 | | | application parameter; Annex C renamed Annex B | 3590 +----+---------+-------------------------------------------------+ 3592 Full Copyright Statement 3594 Copyright (C) The Internet Society (2003). All Rights Reserved. 3596 This document and translations of it may be copied and furnished to 3597 others, and derivative works that comment on or otherwise explain it 3598 or assist in its implementation may be prepared, copied, published 3599 and distributed, in whole or in part, without restriction of any 3600 kind, provided that the above copyright notice and this paragraph are 3601 included on all such copies and derivative works. However, this 3602 document itself may not be modified in any way, such as by removing 3603 the copyright notice or references to the Internet Society or other 3604 Internet organizations, except as needed for the purpose of 3605 developing Internet standards in which case the procedures for 3606 copyrights defined in the Internet Standards process must be 3607 followed, or as required to translate it into languages other than 3608 English. 3610 The limited permissions granted above are perpetual and will not be 3611 revoked by the Internet Society or its successors or assigns. 3613 This document and the information contained herein is provided on an 3614 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3615 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3616 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3617 HEREI WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3618 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.