idnits 2.17.1 draft-ietf-fax-tiff-fx-extension1-01.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 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 63 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 263: '...l parameters. It SHALL be present for ...' RFC 2119 keyword, line 275: '...e data in the image IFD SHALL prevail....' RFC 2119 keyword, line 280: '...X extensions and SHALL be present when...' RFC 2119 keyword, line 283: '...Extensions field SHALL be placed withi...' RFC 2119 keyword, line 296: '...F-FX. This field SHALL only appear in ...' (147 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2674 has weird spacing: '...e among the |...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Compression(259) = 1, 3, 4, 7, 9, 10, 34715. SHORT For Mask layer, see Sections 4.2.1, 5.2.1 and E1.6.2.1. For Foreground and Background layers, see Sections 6.2.1, 7.2.1 and E1.6.2.1. Compression=1 is not used by previous profiles. An IFD used only to specify the default image color for a layer SHALL not have any encoded image data associated with it, i.e., the StripByteCounts field SHALL contain a 0. Since no image data exists in the IFD, the Compression field SHALL be set to 1 indicating no compression. A Compression field value of 1 is not allowed for any other IFDs. -- 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 (March 2001) is 8437 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) -- Missing reference section? 'RFC XXXX' on line 2715 looks like a reference -- Missing reference section? 'RFCXXXX' on line 143 looks like a reference -- Missing reference section? 'TIFF' on line 2699 looks like a reference -- Missing reference section? 'TTN1' on line 801 looks like a reference -- Missing reference section? 'TTN2' on line 190 looks like a reference -- Missing reference section? 'REQ' on line 2801 looks like a reference -- Missing reference section? '0' on line 2459 looks like a reference -- Missing reference section? '2' on line 840 looks like a reference -- Missing reference section? '1' on line 2176 looks like a reference -- Missing reference section? 'N-2' on line 830 looks like a reference -- Missing reference section? '3' on line 846 looks like a reference -- Missing reference section? 'N' on line 846 looks like a reference -- Missing reference section? 'TIFF-REG' on line 2698 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. McIntyre 2 Fax Working Group Xerox Corporation 3 March 1st, 2001 D. Abercrombie 4 draft-ietf-fax-tiff-fx-extension1-01.txt Xerox Corporation 5 W. Rucklidge 6 Intelligent Markets 7 R. Buckley 8 Xerox Corporation 9 March 2001 11 TIFF-FX Extension Set 1 13 Status of this Memo: 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "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 2001. All Rights Reserved. 43 Abstract 45 This document is an Internet draft for extensions to TIFF-FX 46 [RFC XXXX], extension set 1. 48 [[[RFC XXXX is a placeholder for the pending Draft Standard revision to 49 RFC 2301, currently documented in draft-ietf-fax-tiff-fx-09.txt.]]] 51 This draft describes extensions to RFC XXXX to enable new features or 52 conditions to TIFF-FX. The features are described by a set of 53 guidelines for all TIFF-FX extensions, and a set of 5 extension types 54 which enable: increased set of resolutions and image widths, 55 expanding Profile M from 3 layers to N layers, the use of shared data 56 as a general mechanism for sharing data across images and pages, a 57 binary profile for JBIG2 coding, and an extension to Profile M for 58 JBIG2 and "colour tag" coding. These extensions do not required 59 modification of existing TIFF-FX implementations. 61 The IETF has been notified of intellectual property rights claimed in 62 regard to some or all of the specification contained in this 63 document. For more information consult the online list of claimed 64 property rights in . 66 The revisions to draft 00 are summarized in the list attached as 67 Annex A to this document. 69 Table of Contents 71 E1.1 INTRODUCTION -----------------------------------------------------4 72 E1.1.1 Scope--------------------------------------------------------4 73 E1.1.2. Overview of this draft--------------------------------------5 74 E1.2. TIFF Fields Required and Recommendations for All TIFF-FX 75 Extensions------------------------------------------------------6 76 E1.2.1. Required Fields---------------------------------------------6 77 E1.2.1.1. GlobalParametersIFD Field-------------------------------6 78 E1.2.1.2. TIFF-FXExtensions Field---------------------------------6 79 E1.2.2. Recommended Fields------------------------------------------8 80 E1.2.2.1. FaxProfile Field----------------------------------------8 81 E1.2.2.2. MultiProfiles Field-------------------------------------8 82 E1.3. TIFF-FX Extension 1: Resolution and ImageWidth Extensions-------10 83 E1.4. TIFF-FX Extension 2: N-Layer Profile M Extension----------------14 84 E1.4.1. Introduction-----------------------------------------------14 85 E1.4.2. Section 8.1. Overview--------------------------------------15 86 E1.4.3. Section 8.1.1. MRC 3-layer model---------------------------15 87 E1.4.4. Section 8.1.2. A TIFF Representation for the MRC 3-layer 88 model------------------------------------------------------16 89 E1.4.5. Section 8.2.1. Baseline Fields-----------------------------18 90 E1.4.6. Section 8.2.2. Extension Fields----------------------------19 91 E1.4.7. Section 8.2.3. New Fields----------------------------------19 92 E1.4.8. Section 8.4. Rules and Requirements for Images-------------21 93 E1.4.9. Section 8.5. Profile M - MRC Fax Profile Summary-----------22 94 E1.5. TIFF-FX Extension 3: Shared Data Extension----------------------22 95 E1.5.1. Overview---------------------------------------------------23 96 E1.5.2. Required TIFF Fields---------------------------------------23 97 E1.5.2.1. Baseline Fields----------------------------------------23 98 E1.5.2.2. Extension Fields---------------------------------------23 99 E1.5.2.3. New Fields---------------------------------------------23 100 E1.5.3. Recommended Fields-----------------------------------------23 101 E1.5.4. Shared Data------------------------------------------------23 102 E1.5.4.1. SharedDataList-----------------------------------------26 103 E1.5.4.2. Representation of Shared Data in TIFF------------------27 104 E1.6. TIFF-FX Extension 4: Profile T - Lossy and Lossless JBIG2 105 Black-and-White Fax profile-------------------------------------28 106 E1.6.1. Overview---------------------------------------------------28 107 E1.6.2. Required TIFF Fields---------------------------------------30 108 E1.6.2.1. Baseline Fields----------------------------------------31 109 E1.6.2.2. Extension Fields---------------------------------------33 110 E1.6.2.3. New Fields---------------------------------------------33 111 E1.6.3. Recommended TIFF Fields------------------------------------33 112 E1.6.4. JBIG2 Shared Data------------------------------------------36 113 E1.6.4.1. The JBIG2 Shared Data----------------------------------36 114 E1.6.4.2. JBIG2 SharedDataMemory --------------------------------38 115 E1.6.5. The JBIG2 Image Strip--------------------------------------39 116 E1.6.5.1. Image Strip Format-------------------------------------41 117 E1.6.6. Representation of JBIG2 data in TIFF-----------------------42 118 E1.6.7. Rules and Requirements for Images--------------------------45 119 E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White 120 Fax profile Summary----------------------------------------46 121 E1.7. TIFF-FX Extension 5: JBIG2 Color Extension of Profile M---------48 122 E1.7.1. Overview---------------------------------------------------48 123 E1.7.2. Required TIFF Fields---------------------------------------49 124 E1.7.2.1. Baseline Fields----------------------------------------49 125 E1.7.2.2. Extension Fields---------------------------------------49 126 E1.7.2.3. New Fields---------------------------------------------49 127 E1.7.3. Recommended TIFF Fields------------------------------------49 128 E1.7.4. JBIG2 Shared Data------------------------------------------50 129 E1.7.5. The Image Strip--------------------------------------------50 130 E1.7.6. Representation of JBIG2 data in TIFF-----------------------50 131 E1.7.7. Colour Tag (Color Symbol Compression)----------------------50 132 E1.7.7.1. Why use Colour Tag Compression-------------------------50 133 E1.7.7.2. Colour Tag Terms of Use in TIFF------------------------50 134 E1.7.8. Rules and Requirements for Images--------------------------52 135 E1.7.9. JBIG2 Extension of Profile M Summary-----------------------53 136 E1.8. Security Considerations-----------------------------------------56 137 E1.9. References------------------------------------------------------56 138 E1.10. Authors' Addresses---------------------------------------------57 139 Full Copyright Statement----------------------------------------------57 140 Annex A. List of edits to draft-ietf-fax-tiff-fx-Extension1-00--------59 141 E1.1. Introduction 143 This document describes extensions to RFC XXXX [RFCXXXX], titled 144 "File Format for Internet Fax", also known as TIFF-FX, to augment the 145 features and capabilities for the data content and structure 146 generated by the current suite of ITU-T Recommendations for Group 3 147 facsimile. As an RFC XXXX extension, this specification should be 148 read in conjunction with RFC XXXX. 150 [[[RFC XXXX is a placeholder for the pending Draft Standard revision to 151 RFC 2301, currently documented in draft-ietf-fax-tiff-fx-09.txt.]]] 153 These Recommendations and the TIFF fields described here support the 154 following new facsimile profile: 156 Profile T: TIFF-FX Extension 4: Black-and-White JBIG2 Extension - a 157 JBIG2 profile for binary only T.88|ISO/IEC 14492 [T.88] coded 158 data, built upon Profile M and the Shared Data extension 159 (TIFF-FX Extension 5). 161 and create new extensions for the following new features: 163 TIFF-FX Extension 1: Resolution and ImageWidth Extensions - 164 extends the resolutions and image widths available for all 165 Profiles, with the exception of Profile S 166 TIFF-FX Extension 2: N-Layer Profile M Extension - extends 167 the 3-layer model to N layers 168 TIFF-FX Extension 3: Shared Data Extension - enables data to be 169 shared among different images and pages; an enabler for 170 additional compression gains when using JBIG2 encoding 171 TIFF-FX Extension 5: JBIG2 Color Extension of Profile M - the 172 binary and color extension to Profile M which enables JBIG2 173 coding using T.88 (JBIG2, binary) and T.45 [T.45] "Run-length 174 Colour Encoding", required for colour tag extensions to JBIG2. 176 This extension specification of TIFF-FX for facsimile is known as 177 TIFF-FX Extension Set 1. 179 E1.1.1 Scope 181 This document defines extensions to RFC XXXX, titled "File Format for 182 Internet Fax", known as TIFF-FX. These extensions add new 183 functionality to the profiles of TIFF-FX, with the exception of 184 Profile S, which is highly constrained. Most of these extensions can 185 be independently used; although some extensions may rely on others. 187 Unless otherwise noted, the primary reference is [RFC XXXX] "File 188 Format for Internet Fax" (TIFF-FX), which references the following as 189 it's primary references: the current TIFF specification [TIFF], 190 selected TIFF Technical Notes [TTN1, TTN2] and [T.30]. 192 E1.1.2 Overview of this draft 194 This Section gives an overview of TIFF-FX Extension Set 1.0. Section 195 E1.2 describes the requirements and recommendations associated with 196 all TIFF-FX extensions defined within this document. 197 Sections E1.3 through E1.7 describe the five new extensions. Section 198 E1.3 defines the new resolutions and associated image widths. 199 E1.4 defines the N-Layer extension to the 3-Layer MRC model. Sections 200 E1.5 through E1.7 are all associated with making provisions for JIBG2 201 encoding. The ShardData structure of Section E1.5 accommodates a 202 single representation of reusable data, such as JBIG2 symbols, that 203 appear or are used multiple times within a file. The sharing or 204 reusing of image components within and across pages is the 205 fundamental difference between JBIG2 and other encodings. The new 206 JBIG2 black-and-white profile, Profile T, is defined in Section E1.6, 207 while the JBIG2 color extension to Profile M is defined in Section 208 E1.7. 210 The following tree diagram shows the relationship among profiles, 211 between profiles and coding methods, and between profiles and 212 extensions. Profiles are represented by their single character 213 designation (e.g. S, F and C), coding methods are represented by 214 their multi-character acronym (e.g. MH, MR and JBIG2), and extensions 215 are represented by their numeric designation (e.g. 1, 2 and 5). 217 S (MH) 218 / \ 219 Black & White / \ Color 220 ------------------------- ------------C (JPEG)1 221 | | | / \ 222 | | F (MH, MR, MMR)1 / \ 223 | | / \ 224 | | / \ 225 | J (JBIG)1 L(JBIG)1 \ 226 | \ 227 | \ 228 T (JBIG2)1, 2, 3 M (MRC)1, 2, 3, 5 230 This document is an extension to RFC XXXX and portions are specified 231 by defining specific modifications to sections of RFC XXXX, as such 232 it should be read in conjunction with RFC XXXX. Throughout this 233 document, section number references without an "E1" prefix should be 234 interpreted as [RFC XXXX] section references. 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in [REQ]. 240 E1.2. TIFF Fields Required or Recommended for All TIFF-FX Extensions 242 E1.2.1. Required Fields 244 E1.2.1.1. GlobalParametersIFD Field 246 Status of the GlobalParametersIFD (GPIFD) is being changed from 247 Recommended to Required, for all extensions. This change is based on 248 the fact that more than one required extension, such as SharedData 249 and TIFF-FXExtensions, have global file implications (i.e. apply 250 across multiple pages or Primary IFDs), warranting their location 251 within the GPIFD. Accommodation of these required fields within the 252 GPIFD then requires change in status of the GPIFD to Required. 254 E1.2.1.1.1 Instructions 256 Remove the GlobalParametersIFD field from Section 2.2.4 "New TIFF 257 fields recommended for fax profiles" and append the following revised 258 definition to Sections 4.2.3, 5.2.3, 6.2.3, 7.2.3 and 8.2.3 "New 259 Fields": 261 GlobalParametersIFD(400) IFD or LONG 262 The GlobalParametersIFD, defined in Section 2.2.4, is an IFD 263 containing global parameters. It SHALL be present for all TIFF-FX 264 extensions. This reflects a modification to the Section 2.2.4 265 definition where GlobalParametersIFD is defined as a Recommended 266 field. The RFC XXXX GlobalParametersIFD definition is further 267 modified in that it is permitted to contain fields that are NOT 268 permitted in any other IFD. The new SharedData field is one such 269 field that is not permitted in any other IFD, see the Shared Data 270 Extension below. 272 It is recommended that a TIFF writer place this field in the first 273 IFD, where a TIFF reader would find it quickly. If a conflict exists 274 between fields in the GlobalParametersIFD and in the image IFDs, then 275 the data in the image IFD SHALL prevail. 277 E1.2.1.2. TIFF-FXExtensions Field 279 The TIFF-FXExtensions field is introduced to be an identification 280 mechanism for all TIFF-FX extensions and SHALL be present when an 281 extension is used. The extensions are identified by bit value 282 assignment, accommodating use of more than one extensions at the same 283 time. The TIFF-FXExtensions field SHALL be placed within the 284 GlobalParametersIFD. 286 E1.2.1.2.1 Instructions 288 Add the TIFF-FXExtensions field to Sections 4.2.3, 5.2.3, 6.2.3, 289 7.2.3 and 8.2.3 "New Fields", as defined below: 291 TIFF-FXExtensions(34687) LONG 292 Count = 1 294 This field identifies the RFC XXXX extension(s) that apply. The field 295 accommodates the need to continually enhance the functionality of 296 TIFF-FX. This field SHALL only appear in the GlobalParametersIFD, it 297 is NOT permitted in any other IFD. It is required and SHALL be 298 present with use of any TIFF-FX extension. 300 A value of 1 in a bit location indicates the corresponding TIFF-FX 301 Extension is used. More than one bit set to 1 means more than 302 one TIFF-FX extension is used. 304 Current TIFF-FX Extensions: 305 +------+---------+---------------------------------------------------+ 306 | Bit |Extension| Meaning | 307 |number| number | | 308 +------+-------------------------------------------------------------+ 309 | 0 | 1 | Resolution and ImageWidth Extensions | 310 | | | If bit 0 is 1, then any of the X and YResolutions | 311 | | | from 300 x 600 to 1200 x 1200 pixels per | 312 | | | resolution unit, and the corresponding ImageWidths| 313 | | | may be used. | 314 +------+---------+---------------------------------------------------+ 315 | 1 | 2 | N-Layer Profile M Extension | 316 | | | If bit 1 is 1, then the provision for more than | 317 | | | three MRC layers is used. | 318 +------+---------+---------------------------------------------------+ 319 | 2 | 3 | Shared Data Extension | 320 | | | If bit 2 is 1, then Shared Data provisions is | 321 | | | used. | 322 +------+---------+---------------------------------------------------+ 323 | 3 | 4 | Profile T - Black-and-White JBIG2 Extension | 324 | | | If bit 3 is 1, then Black-and-White JBIG2 coding | 325 | | | is used (i.e. Compression = 34715, | 326 | | | TIFF-FXExtensions bit 2 is frequently set and | 327 | | | bi-level constrains to the MRC model are applied).| 328 +------+---------+---------------------------------------------------+ 329 +------+---------+---------------------------------------------------+ 330 | 4 | 5 | JBIG2 Extension of Profile M | 331 | | | If bit 4 is 1, JBIG2 is used for Mask layer coding| 332 | | | and colour tags may be used for foreground layers | 333 | | | (i.e. Compression = 34715 and TIFF-FXExtensions | 334 | | | bit 2 is frequently set). | 335 +------+---------+---------------------------------------------------+ 336 Default = 0, no extensions being used. 338 E1.2.2. Recommended Fields 340 E1.2.2.1. FaxProfile Field 342 The FaxProfile field is revised for two reasons: 1) acknowledge the 343 new MultiProfiles field, specified below, and make provisions for 344 association of the two fields. 2) update the current profile list to 345 include the new Profile T, specified later in this document. 347 E1.2.2.1.1 Instructions 349 Replace the existing FaxProfile field in Section 2.2.4 "New TIFF 350 fields recommended for fax profiles" with the following: 352 FaxProfile(402) = 0 - 7, 255. BYTE 353 The profile that applies to this file; a profile is a subset of the 354 full set of permitted fields and field values of TIFF-FX and it's 355 extensions. 356 This field is used to indicate the profile used within the file when 357 only one profile is used. The MultiProfiles field is used when a 358 TIFF-FX extension or more than one profile is used within the file. 359 A FaxProfile value of 255 (X'FF') indicates that the MultiProfiles 360 field is used. 361 The currently defined FaxProfile values associated with a profile 362 are: 363 0: does not conform to a profile defined for TIFF for facsimile 364 1: minimal black & white lossless, Profile S 365 2: extended black & white lossless, Profile F 366 3: lossless JBIG black & white, Profile J 367 4: lossy color and grayscale, Profile C 368 5: lossless color and grayscale, Profile L 369 6: Mixed Raster Content, Profile M 370 7: lossy and lossless JBIG2 black & white, Profile T 371 255: more than one profile and/or an extension is used. See 372 MultiProfiles field, which indicates the profiles and/or 373 profile(s) plus extension(s) used in the file 375 E1.2.2.2. MultiProfiles Field 377 This field is used to indicate when extension(s) or two or 378 more different profiles are used within a single file. RFC XXXX makes 379 no statement with regard to the appropriateness of using encodings of 380 two or more different profiles within a file. There is no question as 381 to the value of such a provision. This is illustrated by an example 382 where the first ten black-and-white text pages of a fifteen page 383 document are processed using Profile F MMR (G4) encoding while the 384 last five color pages are processed using Profile C JPEG encoding. 385 The existing FaxProfile field is used within the file to signal one 386 encoding profile. In response to requests received from implementors, 387 this extension introduces the MultiProfiles field, to be used when 388 an extended profile or more than one profile is used within a file. 390 Files containing extension(s) or more that one profile SHOULD contain 391 the MultiProfiles field, identifying the profiles or extension(s) 392 present. When present, the MultiProfiles field SHALL reside within 393 the GlobalParameterIFD. The number of profiles present within a file 394 is ambiguous without the MultiProfiles or FaxProfile field. It is 395 highly likely that readers of files without the MultiProfiles or 396 FaxProfile will assume that only one profile is present, the profile 397 that is consistent with the Compression type and other relevant 398 values that are present within the first IFD. Such readers may 399 experience difficulty if different Compression types and/or other 400 relevant parameters are encountered in subsequent IFDs within the 401 file. 403 E1.2.2.2.1 Instructions 405 a) Append the new MultiProfiles field, specified below, to Section 2.2.4 406 "New TIFF fields recommended for fax profiles" following the ModeNumber 407 field: 409 MultiProfiles(34689) LONG 410 Count = N 412 The extended profile (i.e. profile plus extension) or more than one 413 profiles that apply to this file; a profile is a subset of the 414 full set of permitted fields and field values of TIFF for facsimile. 415 This field is used when an extended profile or more than one 416 profile are used within the file. This field SHALL only be present 417 when the FaxProfile field is absent or has a value of 255 (X'FF'). 418 A value of 1 in more than one bit location indicates the 419 corresponding profiles or profile(s) plus extension(s) that are 420 used. The currently defined bits are: 422 MultiProfiles[0]: 423 Bit 0: minimal black & white lossless, Profile S 424 Bit 1: extended black & white lossless, Profile F 425 Bit 2: lossless JBIG black & white, Profile J 426 Bit 3: lossy color and grayscale, Profile C 427 Bit 4: lossless color and grayscale, Profile L 428 Bit 5: Mixed Raster Content, Profile M 429 Bit 6: lossy and lossless JBIG2 black & white, Profile T 430 Bit 7: Extension 1, resolution and imagewidth extensions 431 Bit 8: Extension 2, N-Layer Profile M extension 432 Bit 9: Extension 3, shared data extension 433 Bit 10: Extension 5, JBIG2 extension of Profile M 434 Bits 11-31: reserved for future use. 436 WARNING: Files containing extensions or more than one profile 437 "SHOULD" contain the MultiProfiles field, identifying the profiles 438 present. See the description from the second paragraph of Section 439 E1.2.2.2. 441 NOTE: count (N) > 1 should be used to accommodate future 442 expansion beyond 32 bits. 444 b) Append the new 4.5.7 "Multiple Profiles within a file" section, 445 specified below, to Section 4.5 "Implementation Warnings" following 446 Section 4.5.6: 448 4.5.7 Multiple Profiles within a file 449 Files containing more that one profile "SHOULD" contain the 450 MultiProfiles field, identifying the profiles present. The number 451 of profiles present within a file is ambiguous without the 452 MultiProfiles or FaxProfile field. It is highly likely that 453 readers of files without the MultiProfiles or FaxProfile fields will 454 assume that only one profile is present, the profile that is 455 consistent with the Compression type and other relevant values that 456 are present within the first IFD. Such readers may experience 457 difficulty if different Compression types and/or other relevant 458 parameters are encountered in subsequent IFDs within the file. 460 E1.3. TIFF-FX Extension 1: Resolution and ImageWidth Extensions 462 The ITU-T has approved a new set of X and YResolutions, along with 463 corresponding image widths (i.e. page widths). This extension makes 464 provisions for using these extended resolutions. 466 The TIFF-FXExtensions field, below, SHALL be present when this extension 467 is used. 469 TIFF-FXExtensions(34687) bit 0 is 1 LONG 470 See Section E1.2.1.2. 472 E1.3.1 Instructions 474 a) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields 475 required for all fax profiles" XResolution field with the following: 477 The ITU-T Recommendations for facsimile specify a small number 478 of horizontal resolutions: 100, 200, 300, 400, 600, 1200 pixels per 479 inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per 480 inch). 482 b) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields 483 required for all fax profiles" YResolution field with the following: 485 The ITU-T Recommendations for facsimile specify a small number of 486 vertical resolutions: 100, 200, 300, 400, 600, 800, 1200 pixels per 487 inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 488 pixels per inch). 490 c) Append the following five rows to the resolution table that follows 491 the YResolution field in Section 2.2.2 "Additional TIFF fields required 492 for all fax profiles": 494 +--------------+--------------+--------------+--------------+ 495 | 300 | | 600 | | 496 +--------------+--------------+--------------+--------------+ 497 | 600 | | 600 | | 498 +--------------+--------------+--------------+--------------+ 499 | 400 | | 800 | | 500 +--------------+--------------+--------------+--------------+ 501 | 600 | | 1200 | | 502 +--------------+--------------+--------------+--------------+ 503 | 1200 | | 1200 | | 504 +--------------+--------------+--------------+--------------+ 506 d) Replace the ImageWidth field in Section 4.2.1. "Baseline fields" with 507 the following: 509 ImageWidth(256) SHORT or LONG 510 RequiredByTIFFBaseline 511 This profile supports the following fixed page widths: 1728, 2592, 512 3456, 5184, 10368 (corresponding to North American Letter and Legal, 513 ISO A4 paper sizes), 2048, 3072, 4096, 6144, 12288 (corresponding to 514 ISO B4 paper size), and 2432, 3648, 4864, 7296, 14592 (corresponding 515 to ISO A3 paper size). 516 No default; must be specified 518 NOTE: Historical TIFF-F did not include support for the following 519 widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096, 520 4864, 5184, 6144, 7296, 10368, 12288 and 14592. Historical TIFF-F 521 documents also included the following values related to A5 and A6 522 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 523 documents are no longer supported in Group 3 facsimile, so the 524 related width values are now obsolete. See section 4.5.2 for more 525 information on inch/metric equivalencies and other implementation 526 details. 528 e) Replace the XResolution field in Section 4.2.1. "Baseline fields" 529 with the following: 531 XResolution(282) = 200, 204, 300, 400, 408, 600, 1200 RATIONAL 532 RequiredByTIFFBaseline 533 The horizontal resolution of the image is expressed in pixels per 534 resolution unit. In pixels/inch, the allowed values are: 200, 204, 535 300, 400, 408, 600 and 1200. See Section 2.2.2 for inch-metric 536 equivalency. 537 No default, must be specified 539 NOTE: The values of 200 and 408, 600 and 1200 have been added to the 540 historical TIFF-F values, for consistency with [T.30]. Some existing 541 TIFF-F implementations may also support values of 80 pixels/cm, which 542 is equivalent to 204 pixels per inch. See section 4.5.2 for 543 information on implementation details. 545 f) Replace the YResolution field in Section 4.2.1. "Baseline fields" 546 with the following: 548 YResolution(283) = 98, 100, 196, 200, 300, 391, 400, RATIONAL 549 600, 800 and 1200 550 RequiredByTIFFBaseline 551 The vertical resolution of the image is expressed in pixels per 552 resolution unit. In pixels/inch, the allowed values are: 98, 100, 553 196, 200, 300, 391, 400, 600, 800 and 1200 pixels/inch. 554 See Section 2.2.2 for inch-metric equivalency. 555 No default, must be specified 557 NOTE: The values of 100, 200, 391, 600, 800 and 1200 have been added 558 to the historical TIFF-F values, for consistency with [T.30]. Some 559 existing TIFF-F implementations may also support values of 77 and 560 38.5 (cm), which are equivalent to 196 and 98 pixels per inch 561 respectively. See Section 4.5.2 for more information on 562 implementation details. 564 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 565 are legal. The following table gives the legal combinations and 566 corresponding paper size [T.30]. 568 g) Replace the Resolution and ImageWidth table that follows YResolution 569 in Section 4.2.1. "Baseline fields" with the following: 571 +--------------------------------+---------------------------+ 572 | XResolution x YResolution | ImageWidth | 573 +--------------------------------+---------+--------+--------+ 574 | 200x100, 204x98 | | | | 575 | 200x200, 204x196 | 1728 | 2048 | 2432 | 576 | 204x391 | | | | 577 +--------------------------------+---------+--------+--------+ 578 | 300 x 300, 300 x 600 | 2592 | 3072 | 3648 | 579 +--------------------------------+---------+--------+--------+ 580 | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | 581 | 400x800 | | | | 582 +--------------------------------+---------+--------+--------+ 583 | 600 x 600, 600 x 1200 | 5184 | 6144 | 7296 | 584 +--------------------------------+---------+--------+--------+ 585 | 1200 x 1200 | 10368 | 12288 | 14592 | 586 +--------------------------------+---------+--------+--------+ 587 |Letter,A4| B4 | A3 | 588 | Legal | | | 589 +---------+--------+--------+ 590 | Paper Size | 591 +---------------------------+ 593 h) Replace the ImageWidth field in Section 6.2.1. "Baseline Fields" with 594 the following: 596 ImageWidth(256). SHORT or LONG 597 This profile supports the following fixed page widths: 864, 1024, 598 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864, 5184, 599 6144, 7296, 10368, 12288, 14592. 601 i) Replace the XResolution and YResolution fields in Section 6.2.1. 602 "Baseline Fields" with the following: 604 XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL 605 YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL 606 The resolution of the image is expressed in pixels per resolution 607 unit. In pixels per inch, allowed XResolution values are: 100, 200, 608 300, 400, 600 and 1200. The base color fax profile requires the 609 pixels to be square, hence YResolution SHALL equal XResolution. Base 610 resolution is 200 pixels per inch and SHALL be supported by all 611 implementations of this profile. 613 NOTE: The functional equivalence of inch-based and metric-based 614 resolutions is maintained, per Annex E.6.5 in [T.4]. See table in 615 Sec. 2.2.2. 616 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 617 are legal. The following table gives the legal combinations for inch- 618 based resolutions and the corresponding paper sizes [T.30]. 620 j) Replace the Resolution and ImageWidth table that follows YResolution 621 in Section 6.2.1. "Baseline fields" with the following: 623 +--------------------------------+---------------------------+ 624 | XResolution x YResolution | ImageWidth | 625 +--------------------------------+---------------------------+ 626 | 100 x 100 | 864 | 1024 | 1216 | 627 +--------------------------------+---------------------------+ 628 | 200 x 200 | 1728 | 2048 | 2432 | 629 +--------------------------------+---------------------------+ 630 | 300 x 300 | 2592 | 3072 | 3648 | 631 +--------------------------------+---------------------------+ 632 | 400 x 400 | 3456 | 4096 | 4864 | 633 +--------------------------------+---------------------------+ 634 | 600 x 600 | 5184 | 6144 | 7296 | 635 +--------------------------------+---------+--------+--------+ 636 | 1200 x 1200 | 10368 | 12288 | 14592 | 637 +--------------------------------+---------+--------+--------+ 638 |Letter,A4| B4 | A3 | 639 | Legal | | | 640 +---------------------------+ 641 | Paper Size | 642 +---------------------------+ 644 k) Replace the XResolution and YResolution fields in Section 7.2.1. 645 "Baseline Fields" with the following: 647 XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL 648 YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL 649 The resolution of the image is expressed in pixels per resolution 650 unit. In pixels per inch, allowed XResolution values are: 100, 200, 651 300, 400, 600 and 1200. The lossless color fax profile requires the 652 pixels to be square, hence YResolution SHALL equal XResolution. Base 653 resolution is 200 pixels per inch. 655 E1.4. TIFF-FX Extension 2: N-Layer Profile M Extension 657 E1.4.1 Introduction 659 This extension tracks [T.44] by defining the N-layer extension to the 660 3-layer Mixed Raster Content profile or Profile M of TIFF for 661 facsimile. It also extends the provision for using a single multi- 662 stripped IFD to represent a multi-striped layer, with no coding 663 parameter changes between stripes, to layers other than the Primary 664 Mask. By applying the appropriate black-and-white, bi-level, 665 constraints from Extension 4 (Section E1.6), the N-layer model and 666 rules of this extension may also be applied to Profile T. 668 Often times, the contents of a page can be broken up into more 669 components than a 3-layer representation would allow. For instance, a 670 complex magazine article may be represented by: 672 - a low resolution background image, for a low variance picture. 673 Let's say this is 100 dpi, and is color. 674 - a high resolution mask layer, for the large amount of text and 675 lines. Let's say this is 400 dpi (and binary). 676 - a low resolution foreground image, for the text and line color. 677 Let's say this is 100 dpi, and is color. 678 - several medium resolution images, for the pictures that are 679 scattered throughout the page. Let's say they are 200 dpi, and 680 are color. Of these, several may be odd shapes (non-rectangular), 681 which would require separate masks to select their regions. 683 Expanding the 3-layer MRC model to N-layers allows for us to 684 represent a richer variety of image types and page structure. 686 This N-layer and multi-stripped single IFD Profile M Extension is 687 specified by defining specific modifications to the text of Profile 688 M. As a result of the specification method, this extension should be 689 read in conjunction with Profile M. 691 E1.4.2. Section 8.1. Overview 693 The objective is to change 3-layer to N-layer references. 695 2nd paragraph - replace the 3rd and 4th sentences with the following: 697 By itself, MRC does not define any new coding methods or 698 resolutions. Instead it defines an N-layer (where N is a positive 699 integer) image model for structuring and combining the scanned image 700 data. The MRC N-layer model has been applied here using the TIFF 701 format to yield a data structure which differs from [T.44] though it 702 applies the same coding methods, uses the same compressed image data 703 streams and is consistent with the TIFF principle of a single IFD per 704 image. 706 E1.4.3. Section 8.1.1. MRC 3-layer model 708 The objective is to change 3-layer to N-layer references, specify the 709 presence of multiple foreground and mask layers, distinguish role of 710 Primary Mask relative to secondary Mask layers and their 711 interactions: 713 a) Title and 1st paragraph - replace the title and paragraph with 714 the following: 716 8.1.1. MRC N-layer model 718 The N layers of the MRC model are Background (layer 1), Mask (even 719 numbered layers such as 2, 4, 6,..., N-1, where N is odd) and 720 Foreground (odd numbered layers such as 3, 5, 7,..., N, where N is 721 odd) pairs. The Mask and Foreground layers occur in Mask and 722 Foreground pairs (i.e. layers 2 & 3, 4 & 5, 6 & 7, ..., N-1 & N 723 pairs, where N is odd). The odd numbered layers (Background and 724 Foreground) are typically encoded with multi-level coders while the 725 even numbered layers (Mask) are encoded with bi-level coders. Each 726 layer may appear only once on a page and the images of each layer 727 are coded independently of those of the other layers. 729 The final image is obtained by using the Mask layers to determine 730 which of the Foreground layer pixels are rendered over the Background 731 layer or composite of layers below the Mask. When the Mask layer 732 pixel value is 1, the corresponding pixel from the Foreground layer 733 is selected; when it is 0, the corresponding pixel from the 734 Background layer or composite of layers below the Mask is selected. 736 Details are given in the Introduction of this section, and in Annex A 737 of [T.44]. 739 b) 4th paragraph - replace with the following: 741 Not all pages, and not all parts of a page, require 3 or more layers. 742 If a page consists of only one layer, then that layer is the primary 743 image whether it is a Background, Mask, or Foreground layer. If 744 there is more than one layer, then the Primary Mask (layer 2) SHALL 745 be one of the layers, in which case it is the primary image. In all 746 cases, the primary image SHALL be page size. 748 c) 5th paragraph, 1st sentence - replace with the following: 750 MRC [T.44] allows a page to be transmitted as a series of stripes 751 with each stripe consisting of 1, 2, 3 or N layers. 753 d) 6th paragraph - replace with the following: 755 Furthermore, color fax also requires the spatial resolutions of 756 Background, Foreground and secondary Mask images to be legal fax 757 values that are also integer factors of the Primary Mask image 758 resolution. For example, if the Primary Mask Layer resolution is 400 759 pixels per inch,then allowed resolutions for the Foreground, 760 Background and secondary Mask (layers 4, 6, ..., N-1, where N is odd) 761 layers are 100, 200 or 400 pixels per inch; if the Primary Mask is at 762 300 pixels per inch, then allowed values are 100 and 300. The 763 Foreground, Background and secondary Mask layer image resolutions can 764 be set independent of each other. 766 E1.4.4. Section 8.1.2. A TIFF Representation for the MRC 3-layer model 768 The objectives are to change 3-layer to N-layer references, specify 769 multiple foreground and mask layers, define their IFD and SubIFD 770 relationships and structural layout: 772 a) Title and 1st paragraph - replace the title and paragraph with 773 the following: 775 8.1.2. A TIFF Representation for the MRC N-layer model 777 In the TIFF representation of the N-layer MRC model, each page is 778 represented by a single IFD, called the Primary IFD. The nextIFD 779 offset associated with a Primary IFD SHALL point to the Primary IFD 780 of the next page. If the page consists of a single layer, then the 781 Primary IFD represents that layer. If more than one layer is present, 782 the Primary IFD represents the Primary Mask layer and the other 783 layers are represented by a set of child IFDs that are referenced 784 through the SubIFD extension field [TTN1] of the Primary IFD. To 785 distinguish MRC-specific SubIFDs from other SubIFDs, the 786 NewSubFileType field SHALL have Bit 4 ON, indicating an MRC-related 787 IFD. A new ImageLayer field is also introduced that consists of two 788 values that identify the layer (Background [layer 1], Mask [layer 2, 789 4, 6, ..., N, where N is even], or Foreground [layer 3, 5, 7, ..., 790 N, where N is odd]) and the order within the layer (first, second, 791 ...image of the layer); see Section 8.2.3. 793 b) 5th paragraph, last sentence - replace the sentence with the 794 following: 796 In all cases, if the Primary Mask layer exists, it SHALL be 797 represented by a single IFD and a single set of coding parameters. 799 c) 6th paragraph, - replace with the following: 801 The use of SubIFDs to store child IFDs is described in [TTN1]. When 802 a Mask is the primary image, the secondary Mask, Background and 803 Foreground layer images are represented with child IFDs that are 804 referenced by the SubIFDs field in the Primary IFD. There are many 805 possible ways to represent the secondary Mask, Background and 806 Foreground layer images: (1) the SubIFD field of the Primary IFD is 807 an array of pointers to all child image IFDs, one entry per child 808 image; (2) the SubIFD field is a single pointer to a linked list of 809 all child image IFDs; (3) the SubIFD field is an array of N-1 810 pointers, where the first pointer is to a linked list of all 811 Background layer (layer 1) image IFDs, the second pointer is to a 812 linked list of all the first Foreground layer (layer 3) image IFDs, 813 the third pointer is to a linked list of all the second Mask layer 814 (layer 4) IFDs, the N-1 pointer is to a linked list of all the Nth 815 layer IFDs. A Profile M writer SHOULD structure the Background, 816 Foreground and secondary Mask layer images using (3), as shown in the 817 example below. Furthermore, the child IFDs representing the 818 Background, Foreground and secondary Mask layer images SHOULD be 819 ordered in the file in the same order as they occur on the page. 820 However, a Profile M reader must scan all available child IFDs to 821 locate and identify IFDs associated with MRC layers. 823 d) IFD - SubIFD tree diagram that follows the 6th paragraph - replace 824 the tree diagram with the following: 826 (nextIFD) 827 PRIMARY IFD PAGE 0 ----------------------> PRIMARY IFD PAGE 1--> ... 828 ImageLayer = [2,1] 829 NewSubFileType = 18 830 SubIFD[0] ------------ SubIFD[1] ---- ... --- SubIFD[N-2] 831 | | | 832 V V V 833 Child IFD Child IFD Child IFD 834 ImageLayer = [1,1] ImageLayer = [3,1] ImageLayer = [N,1] 835 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 836 | | | 837 |(nextIFD) |(nextIFD) |(nextIFD) 838 V V V 839 Child IFD Child IFD Child IFD 840 ImageLayer = [1,2] ImageLayer = [3,2] ImageLayer = [N,2] 841 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 842 | | | 843 |(nextIFD) |(nextIFD) |(nextIFD) 844 V V V 845 Child IFD Child IFD Child IFD 846 ImageLayer = [1,3] ImageLayer = [3,3] ImageLayer = [N,3] 847 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 848 | | | 849 |(nextIFD) |(nextIFD) |(nextIFD) 850 V V V 851 0 0 0 853 E1.4.5. Section 8.2.1. Baseline Fields 855 The objectives are to reflect presence of the multiple foreground and 856 mask layers and the distinct Primary Mask layer in some fields, and 857 to specify the impact of having no image data in the multiple mask 858 and foreground layer pairs. 860 a) ImageWidth - replace with the following: 862 ImageWidth(256). SHORT or LONG 863 Primary images define the page widths, which SHALL be limited to the 864 same set of widths as defined in Profile C, the base color profile; 865 see Section 6.2.1. In Profile M, the width of an image (i.e. 866 Foreground, Background, or Mask layer) in the coded data stream may 867 be less than the page width, unless the Background, Foreground or 868 Mask is the primary image (i.e. the Primary IFD), in which case the 869 width of the coded data stream is the page width. The ImageWidth 870 field SHALL always store the actual width of the coded data. 872 b) Compression - replace the first sentence with the following: 874 For Mask layers, see Sections 4.2.1 and 5.2.1 876 c) PhotometricInterpretation - replace with the following: 878 PhotometricInterpretation(262) = 0, 2, 5, 10. SHORT 879 For Mask layers, 0. For Foreground and Background layers, see 880 Sections 6.2.1 and 7.2.1. 882 d) StripByteCounts - replace the field with the following: 884 StripByteCounts(279) SHORT or LONG 885 In Profile M, it is permissible for the StripByteCounts value for a 886 given strip, other than one corresponding to a mask, to have 887 a zero entry. This means there is no encoded image data corresponding 888 to that strip. Instead, for the Foreground or Background layers the 889 current default image color should be used for the strip. The 890 standard default image colors are black for the Foreground layers and 891 white for the Background layer. The ImageBaseColor field can be used 892 to specify other default image colors, see 8.2.3. 894 e) YResolution - replace the last sentence with the following: 896 The resolution of secondary Mask, Background and Foreground layers 897 SHALL each be an integer factor of the Primary image, which is the 898 Primary Mask layer, when it is present; see Section 8.4. 900 E1.4.6. Section 8.2.2. Extension Fields 902 The objective is to reflect presence of the multiple mask layers. 904 a) T6Options - replace the field with the following: 906 T6Options(293) = 0. SHORT 907 For Mask layers, see Section 4.2.2. 909 E1.4.7. Section 8.2.3. New Fields 911 The objectives are to reflect presence of the multiple mask and 912 foreground layers, their impact on the ImageLayer field and resulting 913 extension of the ImageLayer[0] field values. The newly required TIFF- 914 FXExtension field and minimal bit setting are specified. 916 a) T82Options - replace the field with the following: 918 T82Options(435) LONG 919 For Mask layers, see Section 5.2.3. 921 b) ImageLayer - replace the field, descriptive paragraph and 922 ImageLayer[0]field with the following: 924 ImageLayer(34732). LONG 925 Count = 2 926 Image layers are defined such that layer 1 is the Background layer. 927 Layers above layer 1 are arranged in mask (i.e. even numbered layers) 928 and foreground (i.e. odd numbered layers) pairs. The mask selects 929 pixels from the associated foreground that will be rendered on top of 930 the Background or composite of layers below the mask. For example, 931 layer 2 (i.e. the Primary Mask or first mask layer) selects pixels 932 from layer 3 (i.e. the first foreground layer) that will be rendered 933 on top of the Background. Layer 4 (i.e. the second mask layer) 934 selects pixels from layer 5 (i.e. the second foreground layer) that 935 will be rendered on top of the composite of layers 1 through 3 below. 936 The ImageLayer field contains two values, describing the layer to 937 which the image belongs and the order in which it is imaged. 939 ImageLayer[0] = 1, 2, 3, ..., N. 940 1: Image is a Background image, i.e., the image that will appear 941 whenever the Primary Mask contains a value of 0. Background 942 images typically contain low-resolution, continuous-tone 943 imagery. 944 2: Image is the Primary Mask layer. In MRC, if more than one layer 945 is present then the Primary Mask layer (layer 2) is present, it 946 SHALL be the Primary IFD and be full page in extent. 947 3: Image is the first Foreground image, i.e. the image that will 948 be rendered on top of the lower layer (layer 1) whenever the 949 Primary Mask contains a value of 1. The Foreground image 950 generally defines the color of text or lines, but may also 951 contain high-resolution imagery. 952 4: Image is the second Mask layer (layer 4). 953 5: Image is the second Foreground image (layer 5), i.e. the image 954 that will be rendered on top of the composite of layers 1 955 through 3 below whenever the second Mask contains a value of 1. 956 N-1: If N is odd, then layer N-1 is the (N-1)/2-th Mask layer. 957 N: If N is odd, then layer N is the (N-1)/2-th Foreground image, 958 i.e. the image that will be rendered on top of the composite of 959 layers 1 through N-2 below whenever the (N-1)/2 Mask contains a 960 value of 1. 961 If N is even, then layer N is the N/2-th Mask layer, which will 962 rendered black (i.e. default color of the unspecified 963 foreground layer pair) on top of the composite layers of 1 964 through N-1, whenever the mask image contains a value of 1. 966 c) TIFF-FX extensions - append the following field at the end of the 967 section: 969 TIFF-FXExtensions(34687) bit 1 is 1 LONG 970 See Section E1.2.1.2. 972 E1.4.8. Section 8.4. Rules and Requirements for Images 974 The objectives are: i) to reflect presence and impact of the multiple 975 mask and Foreground layers and the Primary IFD role, ii) to 976 accommodate multi-stripped single IFD representations. These 977 objectives are realized through changes in Section 8.4 rules: 978 a) replace the introductory sentence, along with rules 1, 3, 7 and 8; b) 979 b) split rule 3 into two parts and renumber accordingly; 980 c) append a new rule 10 as reflected below. 982 Profile M defines a fundamental set of rules for images in the N- 983 layer representation. These rules, with the appropriate black-and- 984 white (bi-level) constraints, MAY also be applied to Profile T. 986 1. If more than one layer exists, then a binary Mask layer SHALL 987 be present and the first mask layer SHALL be the primary image. 988 Mask layers SHALL support the binary data representations defined 989 in Section 3 and MAY support the binary data representations 990 defined in other Sections, including E1.6. 991 PhotometricInterpretation SHALL be set to "0". If only one layer 992 exists, then the image corresponding to that layer is the Primary 993 Image. 995 3. The Background and Foreground images SHALL support the color 996 representations defined in Section 6 and MAY support other color 997 representations. 999 4. Images other than the Primary Image (i.e. Primary IFD) MAY 1000 optionally cover only a portion of the stripe or page. 1002 8. In MRC Internet Fax, each layer is transmitted as a sequence of 1003 TIFF strips. If the page consists of a single layer, then 1004 all page stripes SHALL be stored in the single Primary IFD. In 1005 this case, coding parameters SHALL NOT change between strips. If 1006 the page consists of more than one layer, then all stripes of the 1007 Primary Mask layer SHALL be stored in the single Primary IFD as a 1008 series of corresponding strips. Without constraint on coding 1009 parameter changes, all stripes of the Foreground/Background/ 1010 secondary Mask layers SHALL be stored in separate single-stripped 1011 IFDs. These IFDs are referenced by the Primary IFD's SubIFD field, 1012 containing an ImageLayer field with ImageLayer[0] identifying 1013 Background (layer 1), Foreground layers (layer 3, 5, 7, ..., N, 1014 where N is odd) or mask layers (layer 2, 4, 6, ..., N-1, where N 1015 is odd), and Imagelayer[1] identifying order in which images 1016 within a single layer are to be imaged. The TIFF XPosition and 1017 Yposition fields are used to indicate the placement of these 1018 images with respect to the primary image. 1020 9. When the Primary Mask image is present, the resolution of 1021 Background, Foreground and secondary Mask images SHALL each be an 1022 integer factor of the Primary Mask image. For example, if the 1023 Primary Mask image is 400pixels/inch, then the Background, 1024 Foreground or secondary Mask images may be at 400 pixels/inch 1025 (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). 1027 10. When there are no coding parameter changes between stripes, a 1028 single multi-stripped IFD (i.e. each strip corresponding to a 1029 stripe) MAY be used to represent a multi-striped layer that is not 1030 a Primary Mask layer. 1032 E1.4.9. Section 8.5. Profile M - MRC Fax Profile Summary 1034 The objective is to identify the secondary Mask layers as being among 1035 the data blocks pointed to by the SubIFD offsets, reflect the 1036 required status of the GlobalParametersIFD, append the required TIFF- 1037 FXExtensions field to the table and callout the need to activate the 1038 N-Layer Profile M Extension bit. 1040 a) Revise the following Section 8.5 table entries to read as shown: 1042 +------------------+-----------------------------------------+ 1043 | SubIFDs | : byte offset to FG, BG, | 1044 | | or secondary Mask IFDs | 1045 +------------------+-----------------------------------------+ 1047 +------------------+-----------------------------------------+ 1048 | GlobalParameters | IFD: global parameters IFD | 1049 | IFD** | | 1050 +------------------+-----------------------------------------+ 1052 b) Append the following to Section 8.5 table: 1054 +------------------+-----------------------------------------+ 1055 | TIFF-FXExtensions| n: extension(s) identification number, | 1056 | ** | bit 1 for N-Layer Profile M Extension | 1057 | | SHALL be among the set bits | 1058 +------------------+-----------------------------------------+ 1060 E1.5. TIFF-FX Extension 3: Shared Data Extension 1062 This section defines the Shared Data extension. Shared 1063 Data accommodate a single representation of reusable resources, 1064 such as image data or encoding tables, that appear or are used 1065 multiple times within a file. Most importantly, it provides a 1066 mechanism for access to the redundant resources by multiple 1067 components (i.e. sharing) within the encoding process. The sharing of 1068 resources is a new encoding provision defined in ITU-T Rec. T.44 1069 Annex B [T.44Amd1]. 1071 E1.5.1. Overview 1073 Many pages and/or documents have repeating components such as shapes 1074 or symbols, words, images and meta-data (i.e. Huffman Tables). 1075 This is especially true for images of text, where the repeating 1076 shapes are the characters themselves. The SharedData field is 1077 defined below to leverage the redundancy of these repeating 1078 components by storing each component once, and then referring to each 1079 stored component as many times as possible. Reference to a resource 1080 must be made with an explicit and unique reference to the Shared 1081 Data, from within the data stream that uses it (the referencing data 1082 stream). 1084 E1.5.2. Required TIFF Fields 1086 E1.5.2.1. Baseline Fields 1087 None 1089 E1.5.2.2. Extension Fields 1090 None 1092 E1.5.2.3. New Fields 1094 GlobalParametersIFD(400) IFD or LONG 1095 See Section E1.2.1 1097 TIFF-FXExtensions(34687) bit 2 SHALL be 1 LONG 1098 See Section E1.2.1 1100 SharedData(34689) LONG 1101 See Section E1.5.4. 1103 E1.5.3. Recommended TIFF Fields 1104 None 1106 E1.5.4 Shared Data 1108 The following new field is defined: 1110 SharedData(34689) LONG 1111 Count = 1 1113 The SharedData field contains the file offset (E), in bytes, from the 1114 beginning of the file of the first Shared Data Table. Each Shared 1115 Data Table contains a count of the number of Shared Data Entries that 1116 physically exist in the table (whether populated with an entry or 1117 not) , the Shared Data Entries themselves, and the file location of 1118 the next Shared Data Table (if any). 1120 There can be as many Shared Data Tables as necessary to describe the 1121 number of shared data items, but there SHALL be only one SharedData 1122 field in a file, and it SHALL be in the GlobalParametersIFD 1123 (recommended to be in the first IFD in the file). The SharedData 1124 field is required when sharing data and SHALL be present. A 1125 SharedData value of zero "0" means that there are no Shared Data 1126 Tables present and that no data are currently being shared. 1128 Each Shared Data Table consists of a 2-byte count of the number of 1129 physical entries, a sequence of 16-byte shared data entries, and a 4- 1130 byte offset to the next Shared Data Table. The last shared data 1131 table has a "next table file offset" of 0. 1133 NOTE: In all the tables shown below, all multi-byte quantities are 1134 Stored in the endianness convention established by the TIFF 1135 file ("II" or "MM"). 1137 Shared Data Table 1138 +-----+--------------+-----+---------------------------------------+ 1139 |Bytes| Byte offsets |Type | Description | 1140 +-----+--------------+-----+---------------------------------------+ 1141 | 2 | E - E+1 |SHORT| Items in table - (i) The number of | 1142 | | | | shared data entries that are | 1143 | | | | physically in this table, whether | 1144 | | | | populated (non-zero byte entries) or | 1145 | | | | not. | 1146 +-----+--------------+-----+---------------------------------------+ 1147 | 16 | E+2 - E+17 | - | Item 1 - First shared data entry. | 1148 +-----+--------------+-----+---------------------------------------+ 1149 | 16 | E+18 - E+33 | - | Item 2 - Second shared data entry. | 1150 +-----+--------------+-----+---------------------------------------+ 1151 |. . .| . . . Etc. | - | Item i - i-th item entry. (i | 1152 | | | | determined by "items in table" value | 1153 | | | | above.) | 1154 +-----+--------------+-----+---------------------------------------+ 1155 | 4 | N - N+3 |LONG | Next table file offset: 4-byte file | 1156 | | | | offset, in bytes from beginning of | 1157 | | | | file, of the next Shared Data Table. | 1158 | | | | Where i = shared data entries in this | 1159 | | | | table (see "items in table", above), | 1160 | | | | and each shared data item entry is 16 | 1161 | | | | bytes, N = E+2+16*i. | 1162 +-----+--------------+-----+---------------------------------------+ 1164 Shared Data Entries 1165 +-----+--------------+-----+---------------------------------------+ 1166 |Bytes| Byte offsets |Type | Description | 1167 +-----+--------------+-----+---------------------------------------+ 1168 | 4 | Y - Y+3 |LONG | Shared Data bytes - Size of the | 1169 | | | | shared data data block, in bytes. | 1170 +-----+--------------+-----+---------------------------------------+ 1171 | 4 | Y+4 - Y+7 |LONG | Shared Data file offset - File offset | 1172 | | | | of this shared data data block, in | 1173 | | | | bytes, from beginning of file. | 1174 +-----+--------------+-----+---------------------------------------+ 1175 | 2 | Y+8 - Y+9 |SHORT| SharedDataType - The type of data | 1176 | | | | being represented as a shared data. | 1177 | | | | The table below contains the type of | 1178 | | | | shared data currently defined. | 1179 +-----+--------------+-----+---------------------------------------+ 1180 | 2 | Y+10 - Y+11 |SHORT| Last page used - The page (primary | 1181 | | | | IFD) ordinal (1, 2, ...) of the last | 1182 | | | | page that references this shared data.| 1183 | | | | A value of 0 indicates that the last | 1184 | | | | page to use the shared data is not | 1185 | | | | known. | 1186 | | | | The page ordinal SHALL be based on | 1187 | | | | the order within the primary IFD | 1188 | | | | chain. | 1189 +-----+--------------+-----+---------------------------------------+ 1190 | 4 | Y+12 - Y+15 |LONG | SharedDataMemory - the number of bytes| 1191 | | | | required by the referencing data | 1192 | | | | stream to hold this shared data. If | 1193 | | | | the shared data is encoded then the | 1194 | | | | memory required SHOULD be consistent | 1195 | | | | with the decoded form of the shared | 1196 | | | | data. | 1197 | | | | A value of 0 indicates that the | 1198 | | | | SharedDataMemory is not known, or this| 1199 | | | | field is not applicable. | 1200 | | | | When defining a shared data and | 1201 | | | | SharedDataMemory is applicable, a | 1202 | | | | formula for computing the | 1203 | | | | SharedDataMemory SHALL be given within| 1204 | | | | the definition of the referencing data| 1205 | | | | stream. | 1206 | | | | An example of such a formula may be | 1207 | | | | found in Section E1.6.4.2 for JBIG2. | 1208 +-----+--------------+-----+---------------------------------------+ 1210 Current SharedDataTypes: 1211 +----------------+---------------------------------------------+ 1212 | SharedDataType | Description | 1213 | Value | | 1214 +----------------+---------------------------------------------+ 1215 | 0 | undefined | 1216 +----------------+---------------------------------------------+ 1217 | 1 | JBIG2 Shared Data (i.e. JBIG2 symbol | 1218 | | dictionaries, pattern dictionaries, Huffman | 1219 | | tables, etc) | 1220 +----------------+---------------------------------------------+ 1222 Shared Data ID: 1223 The reference to a shared data entry SHALL be by a unique ID, which 1224 SHALL be the offset of the entry in the list described by the Shared 1225 Data Tables; the first shared data entry SHALL have ID 0. Note that 1226 the "list" of shared data entries is what the series of Shared Data 1227 Tables SHALL contain, when collected together. The order of the 1228 shared data tables SHALL determine the order of the shared data IDs. 1229 For example, if the first three tables (A, B and C) have 3, 1 and 2 1230 shared data entry respectively; then table A will refer to shared 1231 data with IDs 0, 1, and 2; table B will refer to the shared data with 1232 ID 3; and table C will refer to shared data with IDs 4 and 5. Note 1233 that if copying shared data from one file to another, the shared data 1234 ID will likely need revision to be brought in alignment with the 1235 destination table; additionally, any copied data that refers to the 1236 copied shared data will require a change in the reference to the new 1237 ID. 1239 E1.5.4.1 SharedDataList 1241 The data stream that requires inclusion of one or more Shared Data 1242 (i.e. the reference data stream) SHALL include a list of IDs in a 1243 SharedDataList. For instance, an image strip that requires a shared 1244 data in order to be a complete compressed data stream, will include a 1245 SharedDataList. It is up to the interpretation of the reference data 1246 type (i.e. Compression type) as to how the shared data will be used. 1248 A SharedDataList, located at file offset P, in bytes, from the 1249 beginning of the file, SHALL contain a 2-byte count of the number of 1250 IDs (i) in the list, followed by i 4-byte IDs. 1252 SharedDataList Structure 1253 +-----+---------------+-----+---------------------------------------+ 1254 |Bytes| Byte offsets |Type | Description | 1255 +-----+---------------+-----+---------------------------------------+ 1256 | 2 | P - P+1 |SHORT| The number of shared data IDs (i) | 1257 +-----+---------------+-----+---------------------------------------+ 1258 | 4 | P+2 - P+5 |LONG | First shared data ID | 1259 +-----+---------------+-----+---------------------------------------+ 1260 +-----+---------------+-----+---------------------------------------+ 1261 | 4 | ... |LONG | ... | 1262 +-----+---------------+-----+---------------------------------------+ 1263 | 4 | P+2+(i-1)*4 - |LONG | i-th shared data ID | 1264 | | P+5+(i-1)*4 | | | 1265 +-----+---------------+-----+---------------------------------------+ 1267 E1.5.4.2 Representation of Shared Data in TIFF 1269 The representation of Shared Data in a TIFF file is shown below: 1270 +------+----------------------+---------------------------------+ 1271 | | | "II" or "MM" | 1272 | | +---------------------------------+ 1273 | | TIFF Header | 42 | 1274 | | +---------------------------------+ 1275 | | | FirstIFD offset (IFD0) |---: 1276 | +----------------------+---------------------------------+ | 1277 | | ... | | 1278 | :---|---------------------------<----------------------------|---: 1279 | | | ... | 1280 | v +----------------------+---------------------------------+ 1281 | | | | ... | 1282 | | | +---------------------------------+ 1283 | :-->| IFD0 | GlobalParametersIFD offset |---: 1284 | | +---------------------------------+ | 1285 | | | ... | | 1286 | +----------------------+---------------------------------+ v 1287 | | ... | | 1288 | :---|---------------------------<----------------------------|---: 1289 | | | ... | 1290 | v +----------------------+---------------------------------+ 1291 | | | | ... | 1292 | | | +---------------------------------+ 1293 | :-->| GlobalParametersIFD | SharedData offset (1st Shared |---: 1294 | | | Data Table offset) | | 1295 | | +---------------------------------+ | 1296 | TIFF | | ... | v 1297 | file +----------------------+---------------------------------+ | 1298 | | ... | | 1299 | :---|---------------------------<----------------------------|---: 1300 | | | ... | 1301 | | +----------------------+---------------------------------+ 1302 | | +----------------------+---------------------------------+ 1303 | | | | Number of items in table | 1304 | | | +-----------------+---------------+ 1305 | | | | | Byte count | 1306 | v | | +---------------+ 1307 | | | | | File offset | 1308 | | | | +---------------+ 1309 | | | | Shared Data 0 | SharedDataType| 1310 | | | | +---------------+ 1311 | :-->| Shared Data Table 0 | | Last page used| 1312 | | | +---------------+ 1313 | | | | SharedData | 1314 | | | | Memory | 1315 | | +-----------------+---------------+ 1316 | | | Shared Data 1 | ... | 1317 | | +-----------------+---------------+ 1318 | | | ... | ... | 1319 | | +-----------------+---------------+ 1320 | | | Next Shared Data Table offset | 1321 | +----------------------+---------------------------------+ 1322 | | ... | 1323 +------+--------------------------------------------------------+ 1325 E1.6. TIFF-FX Extension 4: Profile T - Lossy and Lossless JBIG2 1326 Black-and-White Fax profile 1328 This section defines the lossy and lossless JBIG2 black-and-white 1329 profile or Profile T of TIFF for facsimile. JBIG2, ITU-T Rec. T.88 / 1330 ISO-IEC 14492 [T.88], is frequently referenced as symbol or token- 1331 based compression because it makes use of repeating shapes. The 1332 Profile T designation is representative of the term token-based 1333 compression. It must be noted that there are modes of JBIG2 that do 1334 not make use of repeating shapes, such as generic region coding. 1335 All profile T readers and writers SHALL also be able to read and 1336 write Profile S, since Profile S is the minimal binary TIFF-FX 1337 profile. 1339 E1.6.1. Overview 1341 This section describes a black-and-white profile that uses JBIG2 1342 compression. The ITU-T has approved the lossy and lossless modes of 1343 JBIG2 for Group 3 facsimile. JBIG2 compression is typically used in 1344 accordance with the application rules given in ITU-T Rec. T.89 1345 [T.89]. 1347 This profile is essentially a JBIG2 encoded black-and-white 1348 constrained profile of Profile M plus the Shared Data 1349 extension. The MRC 3-layer model and TIFF representation, defined in 1350 Section 8.1 and constrained to a single image layer (i.e. only one 1351 layer with image data), SHALL be used. The N-layer extension 1352 (Extension2) MAY be used to accommodate more demanding binary image 1353 requirements. Odd-numbered layers (i.e. Background and Foreground) 1354 are optional since they SHALL NOT contain image data, and are 1355 typically omitted. Rational for Profile T using the Profile M 1356 structure is traceable to T.44 Annex B [T.44Amd1], in which MRC is 1357 currently the only ITU-T encoding structure that has provisions to 1358 accommodate meta data, such as JBIG2 dictionaries. 1360 The behavior and structure of this profile is that of a 1361 plain single-layer image, similar to that of Profiles S, F and J, 1362 with some added structure to accommodate JBIG2's meta-data. Within 1363 this context, bit 4 of the NewSubFileType field SHALL be set, 1364 indicating the MRC imaging model with multiple layers. The 1365 Compression type SHALL be set to 34715 (JBIG2 Compression). When 1366 JBIG2 resources, such as symbol or pattern dictionaries, are used 1367 across more than image (i.e. stripe, layer or page) the SharedData 1368 field SHALL be used to store them. These requirements are consistent 1369 with ITU-T's definitions in Rec. T.4 Annex H [T.4Amd1] and Rec. T.44 1370 Annex B [T.44 Amd1]. 1372 JBIG2 compression utilizes the fact that many images have repeating 1373 shapes or symbols. This is especially true for images of text, where 1374 the repeating shapes are the characters themselves. Symbol or token- 1375 based compression makes use of these repeating shapes, by storing a 1376 set of images for the symbols once, and then referring to the symbol 1377 images as many times as possible. 1379 In a multi-page document, the same shape can occur on multiple pages. 1380 In fact, this is quite common: any shape occurring on the first page, 1381 is likely to show up on other pages as well. JBIG2 compression is 1382 improved by collecting all the repeating shapes from multiple pages, 1383 and allowing this collection to be referred to by more than one page. 1384 This collection of symbol images is referred to as a symbol 1385 dictionary. A document can contain more than one symbol dictionary. 1386 For example, one symbol dictionary might contain all the symbols that 1387 occurred on more than one page; each page then might have its own 1388 symbol dictionary, containing symbols that occurred only on 1389 that page. 1391 There are two typical ways of compressing symbols on a page using (or 1392 generating) a symbol dictionary. One is by finding an exact match 1393 (lossless), and the other is by allowing a small amount of 1394 discrepancy between the symbol candidate, and the matching symbol in 1395 the symbol dictionary (lossy). The mode used can be distinguished by 1396 the value of the "Lossless" bit in the T88Options[0] field, which is 1397 defined below. 1399 The representation of a symbol-compressed image consists of a shared 1400 data list, which identifies which "JBIG2 Shared Data" are used, and 1401 a "JBIG2-coded position block". A JBIG2 Shared Data is used to 1402 represent a variety of JBIG2 shared entities (i.e. JBIG2 resources) 1403 such as symbol dictionaries, pattern dictionaries, which are used in 1404 halftone coding, and Huffman tables. The symbol dictionaries are 1405 typically contained within one or more JBIG2 Shared Data, represented 1406 within the Shared Data provisions of the Shared Data Extension. The 1407 JBIG2-coded position block consists of a series of symbol X and Y- 1408 Position coordinates, plus the IDs of the symbols located by the 1409 coordinates. The symbol bitmaps are stored in the referenced symbol 1410 dictionaries. 1412 Each TIFF strip in an IFD whose Compression is equal to 34715 (the 1413 TIFF Compression value defined for JBIG2 below) SHALL be formatted as 1414 described in Section E1.6.5 "The JBIG2 Image Strip". 1416 E1.6.1.1 Why Use JBIG2 1418 The symbol-based compression model is incorporated in the JBIG2 1419 standard. This standard boosts compression of text-like documents 1420 by retaining similar shapes across multiple images. In the case of 1421 text, the shapes are the character symbols, and for multi-page 1422 documents, the set of unique character symbols may be fairly small, 1423 especially when the same font is used on each page. 1425 A typical image of binary text, at 300 dpi might take about 80 1426 kilobytes to store using T.6 compression; a similar JBIG2 file might 1427 only require around 20 kilobytes to store. The compression gain can 1428 be up to a factor of two for multi-page files. Sharing 1429 dictionaries between multiple images (i.e. stripes layers or pages) 1430 makes this high compression possible, but requires some way to refer 1431 to the dictionaries used by more than one page. 1433 E1.6.2. Required TIFF Fields 1435 This section describes the TIFF fields required, in addition to those 1436 in Sections 8.2 and E1.5.2, for Profile T. Additionally it describes 1437 those not required in Section 8.2 and constrained differently from 1438 those in Section 8.2. 1440 Note that these fields are defined under the premise that all odd- 1441 numbered layers are omitted, in conformance to the Profile T black- 1442 and-white constraint. However, there are application conditions that 1443 could benefit from inclusion of these odd-numbered layers and setting 1444 the associated StripByteCounts to 0. This may be true when an 1445 application wishes to represent a reverse video image (i.e. a white 1446 image on a black background). Under these conditions the list of 1447 required fields and/or values will be modified per the 1448 StripByteCounts field below. 1450 E1.6.2.1. Baseline Fields 1452 ImageWidth(256). SHORT or LONG 1453 Same page widths as Profile F, the extended black-and-white profile, 1454 and the ImageWidth extensions available to Profile F; see Section 1455 4.2.1 and E1.3. 1456 The change in ImageWidth reference, to those of Profile F rather than 1457 Profile C, is consistent with the black-and-white constraint of this 1458 profile. 1459 Note that for layers other than layer 2, the ImageWidth could be a 1460 fragment of the page width, as when the XPosition is greater than 0. 1462 BitsPerSample(258) = 1. SHORT 1463 Constraint is consistent with the black-and-white constraint. 1465 SamplesPerPixel(277) = 1. SHORT 1466 Constraint is consistent with the black-and-white constraint. 1468 Compression(259) = 34715. SHORT 1470 34715 = JBIG2 coding, ITU-T Rec. T.88 / ISO-IEC 14492 (Lossy/Lossless 1471 coding of Bi-level Images, frequently referenced as symbol-based 1472 compression), T88Options field may be present when using JBIG2. 1473 The format of the data pointed to by the StripByteOffsets when 1474 Compresstion= 34715 is described later. 1476 FillOrder(266) = 1, 2. SHORT 1477 See Section 8.2.1 1479 PhotometricInterpretation(262) = 0. SHORT 1480 The '0' constraint is consistent with the black-and-white constraint 1481 of Section E1.6.1 and the MRC mask layer PhotometricInterpretation 1482 constraint defined in Section 8.2.1. 1484 ResolutionUnit(296) = 2. SHORT 1485 See Section 8.2.1. 1487 StripByteCounts(279) SHORT or LONG 1488 In the event that SubIFDs consists of odd-numbered layers, then the 1489 value of the StripByteCounts for all odd-numbered values of the 1490 ImageLayer[0] field SHALL be fixed to zero "0". In Profile M, it is 1491 permissible for the StripByteCounts value for a given odd-numbered 1492 layer strip to have a zero entry. This means there is no encoded 1493 image data corresponding to that strip. Instead, the current default 1494 image color should be used for the strip. The standard default image 1495 colors are white for the Background layer and black for the 1496 Foreground layer(s). 1498 It would be efficient to omit all odd numbered layers, which are 1499 optional for Profile T. However, it may be useful to identify 1500 portions of a background and/or foreground image where the default 1501 color should be reversed; namely where a background image portion is 1502 all black, or where reverse video appears. 1504 To define a child IFD specifying an odd-numbered layer (i.e. 1505 foreground or background) but containing no encoded image data, 1506 create an IFD with the following settings: 1507 ImageLayer[0]: specified odd numbered layer 1508 ImageLayer[1]: specified order 1509 RowsPerStrip: strip height 1510 ImageLength: image height 1511 ImageWidth: specified value, often the Primary IFD 1512 width 1513 BitsPerSample: 8 1514 PhotometricInterpretation: 10 1515 SamplesPerPixel: 3 1516 Compression: 1 (none) 1517 XPosition: specified value, frequently 0 1518 YPosition: specified value, frequently to top of 1519 strip 1520 XResolution: that of the Primary IFD 1521 YResolution: that of the Primary IFD 1522 StripByteCounts: single 0 value 1523 StripOffsets: single 0 entry 1524 NewSubFileType: bit 4 set to 1 (MRC) 1525 ImageBaseColor: default is white and black for 1526 background and foreground layers 1527 respectively, the reverse may be 1528 specified, no other colors SHALL be 1529 specified 1531 XResolution(282) RATIONAL 1532 Same XResolution as Profile F, the extended black-and-white profile, 1533 and the XResolution extensions available to Profile F; see Section 1534 4.2.1 and E1.3. 1535 The change in XResolution reference, to those of Profile F rather 1536 than Profile M, is consistent with the black-and-white constraint of 1537 this profile. 1539 YResolution(283) RATIONAL 1540 Same YResolution as Profile F, the extended black-and-white profile, 1541 and the YResolution extensions available to Profile F; see Section 1542 4.2.1 and E1.3. 1543 The change in YResolution reference, to those of Profile F rather 1544 than Profile M, is consistent with the black-and-white constraint of 1545 this profile. 1547 Note that unlike Profile M, Profile F and Profile T may both have 1548 non-square resolutions (i.e. different X and YResolution values). 1550 E1.6.2.2. Extension Fields 1552 These fields SHALL NOT be present: 1553 ChromaSubSampling(530) 1554 ChromaPositioning(531) 1555 Indexed(346) 1556 T4Options(292) 1557 T6Options(293) 1559 These fields are as described in Section 8.2.2: 1560 SubIFDs(330) 1561 XPosition(286) 1562 YPosition(287) 1564 E1.6.2.3. New Fields 1566 These Section 8.2.3 fields SHALL NOT be present: 1567 Decode(433) 1568 T82Options(435) 1570 These fields, described in Section 8.2.3 SHALL be present: 1571 StripRowCounts(559) 1572 ImageLayer(34732) 1574 The ImageBaseColor field has been moved from required to recommended. 1576 The fields described in E1.5.2.3 SHALL be present. 1577 GlobalParametersIFD(400) 1578 TIFF-FXExtensions(34687) 1579 Bit 3 of the TIFF-FXExtensions field SHALL be set to 1. 1581 E1.6.3. Recommended TIFF Fields 1583 See Sections 8.3, with exception of GlobalParametersIFD, which has 1584 being changed to required, and append these fields: 1586 ImageBaseColor(434). The field MAY be omitted, in which case the 1587 default color of black and white SHALL be applied to foreground 1588 and background layers respectively. When present, the default 1589 Background or Foreground colors are typicallytypicallyty revised to 1590 black or white respectively, see StripByteCounts above. 1592 MultiProfiles(34688). See Section E1.2.2.2 1594 SharedData(34689). This Section E1.5.4 defined field SHALL be 1595 present when data is being shared between pages. 1597 T88Options(34690) LONG 1598 Count = 1 or 2 1600 The T88Options field contains one or two values, describing options 1601 applied to the encoded data stream and any application profile to 1602 which the encoded data stream may conform. It SHALL only be present 1603 when the IFD's Compression field is equal to 34715 (JBIG2). The 1604 content provides an aid to TIFF readers, in that they describe JBIG2 1605 options that may or may not be handled by a specific JBIG2 decoder. 1606 None of the values in the field are required for correct decoding, 1607 and the field may be ignored. In the event that this field is 1608 omitted, a reader SHALL assume that the data stream is encoded per 1609 the ITU-T T.89 Base profile (i.e. profile identification number 1610 0x00000101), see T88Options[1] below. 1612 T88Options[0] = 1, 2, ..., 7. 1613 This value represents options that are being applied to the encoded 1614 data stream. 1616 NOTE: In all the tables shown below, all multi-byte quantities are 1617 stored in the endianness convention established by the TIFF 1618 file ("II" or "MM"). 1620 The following options are defined: 1621 +--------------+----------------------------------------------------+ 1622 | Bit number | Meaning | 1623 +--------------+----------------------------------------------------+ 1624 | 0 | HuffmanCodingNotPresent | 1625 | | If bit 0 is 1, then the JBIG2-compressed data in | 1626 | | this IFD SHALL NOT use Huffman or MMR (T.6) coding.| 1627 +--------------+----------------------------------------------------+ 1628 | 1 | ArithmeticCodingPresent | 1629 | | If bit 1 is 1, then the JBIG2-compressed data in | 1630 | | this IFD MAY contain segments that contain | 1631 | | arithmetic (MQ) coding. | 1632 +--------------+----------------------------------------------------+ 1633 | 2 | Lossless | 1634 | | If bit 2 is 1, then the JBIG2-compressed data in | 1635 | | this IFD SHALL be a lossless representation of the | 1636 | | original image. | 1637 +--------------+----------------------------------------------------+ 1638 | 3 | SingleStriped | 1639 | | If bit 3 is 1, then each TIFF strip SHALL contain a| 1640 | | JBIG2 Position Block that has only one JBIG2 stripe| 1641 | | (not the same as a TIFF strip). | 1642 | | Note: There is a limit of 32767 lines per JBIG2 | 1643 | | stripe in the event that multi-stripe mode is used.| 1644 +--------------+----------------------------------------------------+ 1645 +--------------+----------------------------------------------------+ 1646 | 4 | TextStripesMixed | 1647 | | If bit 4 is 1, then some JBIG2-compressed stripes | 1648 | | that have text region segment(s) MAY also have | 1649 | | region segments with other data types (e.g. generic| 1650 | | or halftone region segment). | 1651 +--------------+----------------------------------------------------+ 1652 | 5 | ColourTagsFollow | 1653 | | If bit 5 is 1, then this IFD SHALL be in a mask | 1654 | | layer whose corresponding foreground layer SHALL be| 1655 | | coded with JBIG2 (Compression =34715) and the JBIG2| 1656 | | -data SHALL be augmented with ITU-T Rec. T.45 (Run-| 1657 | | length colour encoding) [T.45] coded colour tags. | 1658 +--------------+----------------------------------------------------+ 1659 | 6 | ColourTagsPresent | 1660 | | If bit 6 is 1, then this IFD SHALL be in a | 1661 | | foreground layer, which SHALL be coded with JBIG2 | 1662 | | (Compression =34715) and the JBIG2-data SHALL be | 1663 | | augmented with T.45-coded colour tags. | 1664 +--------------+----------------------------------------------------+ 1665 | 7 | HalftoneRegionPresent | 1666 | | If bit 7 is 1, then the JBIG2-compressed data in | 1667 | | this IFD SHALL contain halftone region segment(s). | 1668 +--------------+----------------------------------------------------+ 1669 Note: Bits 5 and 6 SHALL be 0 within Profile T, which is constrained 1670 to black-and-white images. 1671 Also, bits 8-31 are reserved for future use, and SHALL be 0. 1673 T88Options[1] = 0x00000101, 0x00000102, 0x00000103. 1674 This value represents the JBIG2 profile identification number. This 1675 value may be omitted. 1676 Default = 0x00000101. 1678 The profile identification number of the T88Options identifies a 1679 subset of the full set of permitted parameters and parameter values 1680 that the JBIG2 coded data stream is in compliance with. None of the 1681 values of the T88Options field is required for correct decoding of a 1682 JBIG2 coded data stream and may be ignored. It allows a decoder to 1683 find out quickly which of the set of JBIG2 parameters and parameter 1684 values may be needed to decode a given data stream. 1686 The four-byte profile identification numbers 0x00000000 through 1687 0xFFFFFFFF are administered by ISO/IEC JTC1 SC29. ISO/IEC JTC1 SC29 1688 has reserved profile identification numbers 0x00000100 through 1689 0x00000FFF for ITU-T disposition. Interpretation of profiles 1690 0x00000100 through 0x00000FFF is documented in ITU-T Rec. T.89, while 1691 interpretation of profiles 0x00000000 through 0x000000FF is 1692 documented in ISO/IEC 14492 | ITU-T T.88. 1694 Current profiles: 1695 +------------------+------------------------------------------------+ 1696 | JBIG2 Profile ID | Description | 1697 +------------------+------------------------------------------------+ 1698 | 0x00000101 | ITU-T T.89 Base (minimal Fax Application | 1699 | | Profile) - MMR and Huffman coding, minimum of | 1700 | | two stripes per page, stripes containing text | 1701 | | region segment(s) SHALL NOT contain other | 1702 | | region segments | 1703 +------------------+------------------------------------------------+ 1704 | 0x00000102 | ITU-T T.89 Upper MMR | 1705 | | - MMR and Huffman coding, minimum of two | 1706 | | stripes per page, accommodates halftone and | 1707 | | colour tags | 1708 +------------------+------------------------------------------------+ 1709 | 0x00000103 | ITU-T T.89 Lower Arithmetic | 1710 | | - Arithmetic coding, minimum of two stripes per| 1711 | | page, stripes containing text region segment(s)| 1712 | | SHALL NOT contain other region segments | 1713 +------------------+------------------------------------------------+ 1715 NOTE: In this table, the term "stripe" means JBIG2 stripe (i.e. a 1716 stripe within a JBIG2 Position Block), not a TIFF strip, nor a 1717 TIFF-FX/MRC page stripe. 1719 E1.6.4 JBIG2 Shared Data 1721 For JBIG2 Shared Data, the SharedDataType value in the Shared Data 1722 Entry SHALL have a value of 1. 1724 E1.6.4.1 The JBIG2 Shared Data 1726 The JBIG2 Shared Data stored in a TIFF file contains three pieces: 1727 1. A JBIG2 Shared Data version 1728 2. A JBIG2-coded shared data block 1729 3. Extensions to the JBIG2 Shared Data (these extensions contain 1730 data that are outside the scope of T.88-JBIG2) 1732 The JBIG2-coded shared data block can have a series of JBIG2 1733 segments. The following segment types may occur: 1734 - Symbol dictionary segment 1735 - Pattern dictionary segment 1736 - JBIG2 Extension segment (future extensions to be defined within 1737 the T.88 JBIG2 standard) 1738 - Supported profiles segment 1739 - Table segment 1740 Each segment in a JBIG2-coded shared data block SHALL be associated 1741 with no page (i.e., SHALL have a page association field value of 0, 1742 as described in T.88 - JBIG2 Section 7.2.6). 1744 To put it into perspective, when sharing data is required, a file 1745 contains one SharedData field, which is located in the 1746 GlobalParametersIFD. The SharedData field contains the file offset of 1747 the first Shared Data Table. Each Shared Data Table SHOULD include 1748 one or more Shared Data Entry (i.e. JBIG2 Shared Data). A 1749 populated entry SHALL describe the location and size of the JBIG2 1750 Shared Data themselves. There can be as many Shared Data Tables as 1751 necessary to describe the number of JBIG2 Shared Data items. 1753 The JBIG2 image strip (i.e. the reference data stream), described in 1754 the next section, that requires inclusion of one or more JBIG2 Shared 1755 Data SHALL include a list of JBIG2 Shared Data IDs in a 1756 SharedDataList. 1758 E1.6.4.1.1 JBIG2 Shared Data Format 1760 The JBIG2 Shared Data format consists of a version number, which 1761 identifies the version of the format that follows, followed by the 1762 size of the JBIG2 data block, then the data block itself, followed 1763 by any extensions. The start of the JBIG2 Shared Data is located at 1764 file offset T, in bytes, from the beginning of the file. 1766 The JBIG2 Shared Data has the following format: 1767 +-----+--------------+-----+----------------------------------------+ 1768 |Bytes| Byte offsets | Type| Description | 1769 +-----+--------------+-----+----------------------------------------+ 1770 | 1 | T |BYTE | The JBIG2 Shared Data version number, | 1771 | | | | which is currently 0. | 1772 +-----+--------------+-----+----------------------------------------+ 1773 | 4 | T+1 - T+4 |LONG | Size of JBIG2-coded shared data block | 1774 | | | | (not including extensions) = Y. | 1775 +-----+--------------+-----+----------------------------------------+ 1776 | Y | T+5 - T+4+Y |BYTE | The JBIG2-coded shared data block. | 1777 +-----+--------------+-----+----------------------------------------+ 1778 | 2 | . . . . |SHORT| Extension type for first extension | 1779 | | | | (these extensions contain data that are| 1780 | | | | outside the scope of T.88-JBIG2) | 1781 +-----+--------------+-----+----------------------------------------+ 1782 | 4 | . . . . |LONG | Size of first extension=Z1 | 1783 +-----+--------------+-----+----------------------------------------+ 1784 | Z1 | . . . . |BYTE | Data for first extension | 1785 +-----+--------------+-----+----------------------------------------+ 1786 | 2 | . . . . |SHORT| Extension type for second extension | 1787 +-----+--------------+-----+----------------------------------------+ 1788 | 4 | . . . . |LONG | Size of second extension=Z2 | 1789 +-----+--------------+-----+----------------------------------------+ 1790 | Z2 | . . . . |BYTE | Data for second extension | 1791 +-----+--------------+-----+----------------------------------------+ 1792 +-----+--------------+-----+----------------------------------------+ 1793 | ....| . . . . | ....| Further extensions | 1794 +-----+--------------+-----+----------------------------------------+ 1796 E1.6.4.2 JBIG2 SharedDataMemory 1798 For JBIG2 dictionary Shared Data the SharedDataMemory requirement is 1799 represented by the total amount of decoded symbol dictionary 1800 information a decoder will accommodate in memory at one time to 1801 decode a file. This SharedDataMemory requirement is referenced as the 1802 decoder memory. If decoder memory is specified (non-zero value), then 1803 it follows the formula described in [T.89]. Namely, the decoder 1804 memory, composed of two components (a fixed and per-symbol 1805 component), is a measure of how much memory is required to hold a 1806 decoded dictionary. The fixed component does not depend on the number 1807 of symbols, while the per-symbol component does depend on the number 1808 of symbols. The decoder memory algorithm does have dependence on 1809 whether Huffman (see note 1) or Arithmetic (see note 2) coding is 1810 used and whether the dictionaries contain symbols or halftone 1811 patterns (see note 3). 1813 decoder memory = fixed component + per-symbol component 1815 fixed component = 2^{direct coding template size} 1816 + 2^{refinement coding template size} + 8K 1818 per-symbol component = SUM (32 + (round32(Wi) ( Hi) / 8) over i, 1819 i= 1 to N 1821 where: 1822 i = ith symbol in the dictionary 1823 N = the number of symbols in the dictionary 1824 32 = a fixed per-symbol overhead required to represent: 1825 - width of symbol 1826 - height of symbol 1827 - symbol ID Huffman code 1828 - length of symbol ID Huffman code 1829 - pointer to memory where symbol bitmap resides 1830 round32 = is a rounding up to the next multiple of 32 bits (e.g., 1831 33 rounds to 64, 128 rounds to 128) 1832 Wi = width of the ith symbol 1833 Hi = height of the ith symbol 1835 This means that for each symbol there are 32 bytes overhead, plus 1836 Hi rows of bitmap data, each of which is round32(Wi)/8 bytes. 1838 Note: 1839 1) For Huffman coding there are no templates, so the fixed component 1840 is about 8K bytes. The fixed component can in fact be zero if 1841 custom Huffman tables are not used. 1842 2) For Arithmetic coding the per-symbol component is the same. The 1843 amount of memory needed to store the decoded dictionary bitmaps 1844 (that's the (round32(Wi) * Hi) / 8 component) is unchanged. 1845 Differences occur in the 32 bytes per-symbol overhead component. 1846 The width, height and pointer fractions of the overhead still 1847 apply, however the Huffman code parts do not apply. There are, 1848 however, context tables for symbol ID probability modeling that 1849 take the place of the Huffman code parts. Bottom line, 32 bytes is 1850 also a reasonable per-symbol overhead for Arithmetic coding. 1851 The template options documented in [T.89] range from a 10 pixels 1852 direct bitmap template with no refinement bitmap coding to a 16 1853 pixels direct bitmap template with a 13 pixels refinement bitmap 1854 template. Given this range of templates, the fixed component will 1855 range from 9K to 80K bytes. 1856 3) The same expression holds for pattern dictionaries of halftone 1857 image regions, since pattern dictionaries are similar to 1858 symbol dictionaries but contain halftone patterns. In this 1859 context, the references to symbol above should be taken to include 1860 patterns stored in pattern dictionaries. The pattern dictionaries, 1861 however, tend to be small relative to symbol dictionaries, since 1862 the pattern count is frequently low. This isThis only a few K of 1863 memory. It is the space required by a decoder to hold the halftone 1864 bit-planes that is of significance and determines the 1865 SharedDataMemory. This memory requirement is document in [T.89] to 1866 be typically 110% of the resolution dependent page buffer size 1867 (i.e. 1.0 Mbytes at 300 dpi and 2.0 Mbytes at 400 dpi). 1869 E1.6.5 The JBIG2 Image Strip 1871 The JBIG2 image stored in a TIFF file will have components that 1872 require a TIFF reader to parse through its strip content. This is 1873 due to the fact that JBIG2 is represented by two types of data: 1874 1. shared components: namely the symbol or pattern bitmaps that 1875 are associated with multiple images, which are compressed into 1876 dictionaries and stored in one or more JBIG2 Resources. 1877 2. image specific components: data that is specific to one image 1878 only, that with the aid of the shared components, will allow 1879 the image to be decoded. 1881 To couple these two component sets together, each JBIG2 Image Strip 1882 within an IFD has a corresponding list of shared data IDs in the 1883 SharedDataList section of each image strip. The concatenation of the 1884 shared data and the JBIG2 position block will comprise a decodable 1885 JBIG2 stream for the image described by the IFD for that strip. 1887 A position block is the JBIG2 encoding of the binary image code 1888 stream. Included in the position block are the encoded positions and 1889 IDs of the symbols or patterns found in the dictionaries. The 1890 dictionaries may lie within the position block, typically if they are 1891 used for only one image (stripe, layer or page), and/or outside of it 1892 (i.e. as JBIG2 Shared Data), typically if they are used for more than 1893 image. Within the position block, the following segment types may 1894 occur: 1895 1. Page information segment 1896 - Exactly one page information segment SHALL be present, and it 1897 SHALL be the first segment in the JBIG2-coded position block 1898 2. End of page segment 1899 - Exactly one end of page segment SHALL be present, and it SHALL 1900 be the last segment in the JBIG2-coded position block 1901 3. End of stripe segment 1902 4. Symbol dictionary segment 1903 5. Pattern dictionary segment 1904 6. Generic region segment 1905 7. Generic refinement region segment 1906 8. Text region segment (i.e. position and ID for each symbol 1907 instance) 1908 9. Halftone region segment (i.e. position and ID for each pattern 1909 instance) 1910 10. Extension segment (future extensions to be defined within the 1911 T.88 JBIG2 standard, not to be confused with the extension 1912 component of the TIFF JBIG2 Image Strip below) 1913 11. Supported profiles segment 1914 12. Table segment. 1916 Each segment in a JBIG2-coded position block SHALL be associated with 1917 the page defined by the page information segment. 1919 The TIFF JBIG2 Image Strip SHALL consist of four pieces: 1920 1. A JBIG2 Image Strip version 1921 2. A SharedDataList: list of JBIG2 Shared Data IDs 1922 3. The JBIG2-coded position block 1923 4. Extensions to the image strip (these extensions contain data 1924 that are outside the scope of JBIG2, such as colour tags, which 1925 are defined within the JBIG2 Extension of Profile M. Colour tags 1926 are not permitted within this profile, Profile T). 1928 If the JBIG2 Image Strip contains extensions, each extension is 1929 preceded by a two-byte type giving its extension type, and a 4-byte 1930 count of its length in bytes. Other data that could possibly be 1931 stored in an extension includes ASCII text, hyperlinks, and so on. 1932 The current image strip extensions and the data that may be stored in 1933 them are defined in Section E1.6.5.1. If a TIFF reader is not able to 1934 interpret an extension (if it does not recognize the extension type), 1935 then it SHOULD ignore that extension, but may skip over it to find 1936 further extensions that it can interpret. 1938 To decode a JBIG2-coded image strip, follow these steps: 1939 1. Retrieve the list of shared data IDs from the SharedDataList. 1941 2. Search the collection of JBIG2 Shared Data for all the JBIG2 1942 Shared Data, such as dictionaries, whose IDs are given in the 1943 SharedDataList. 1944 From each one, extract its JBIG2-coded shared data block. 1945 3. Concatenate those JBIG2-coded shared data blocks, in the order 1946 in which their IDs are given in the SharedDataList, followed 1947 by the JBIG2-coded position block. 1948 4. This concatenated data stream can then be decoded as a JBIG2 1949 data stream. This SHALL be a valid JBIG2 data stream 1950 containing a single page: no segment numbers may be 1951 duplicated, and so on. 1952 As an optimization, you won't actually concatenate and decode the 1953 JBIG2-coded shared data block(s) for every position block that uses 1954 them, as that is quite inefficient. Instead, the JBIG2-coded shared 1955 data block(s) can be decoded and kept in an intermediate format, 1956 designed so that the effect of logical concatenation can be 1957 simulated. 1959 E1.6.5.1 Image Strip Format 1961 The image strip has the following format, which includes a 1962 SharedDataList, delimited by "====": 1963 +-----+--------------+-----+----------------------------------------+ 1964 |Bytes| Byte offsets | Type| Description | 1965 +-----+--------------+-----+----------------------------------------+ 1966 | 1 | P |BYTE | Strip format version number, which is | 1967 | | | | currently 0. | 1968 +=====+==============+=====+========================================+ 1969 | 2 | P+1 - P+2 |SHORT| Number of shared data IDs = X | 1970 | | | | (i.e. JBIG2 Shared Data) | 1971 +-----+--------------+-----+----------------------------------------+ 1972 | X*4 | P+3 - P+2 |LONG | The sequence of shared data IDs of the | 1973 | | +(X*4) | | JBIG2 Shared Data required by this | 1974 | | | | JBIG2-coded position block. The JBIG2 | 1975 | | | | Shared Data (e.g. dictionaries) will be| 1976 | | | | prepended in the order specified by | 1977 | | | | this sequence of IDs, to construct the | 1978 | | | | array of symbols that will be used to | 1979 | | | | decode the JBIG2-coded position block. | 1980 +=====+==============+=====+========================================+ 1981 | 4 | P+3+(X*4) - |LONG | Size of JBIG2-coded position block not | 1982 | | P+6+(X*4) | | including extensions = Y | 1983 +-----+--------------+-----+----------------------------------------+ 1984 | Y | . . . . |BYTE | The JBIG2-coded Position Block. | 1985 +-----+--------------+-----+----------------------------------------+ 1986 | 2 | . . . . |SHORT| Extension type for first extension | 1987 | | | | (these extensions contain data that are| 1988 | | | | outside the scope of T.88-JBIG2, such | 1989 | | | | as colour tags) | 1990 +-----+--------------+-----+----------------------------------------+ 1991 +-----+--------------+-----+----------------------------------------+ 1992 | 4 | . . . . |LONG | Size of first extension=Z1 | 1993 +-----+--------------+-----+----------------------------------------+ 1994 | Z1 | . . . . |BYTE | Data for first extension | 1995 +-----+--------------+-----+----------------------------------------+ 1996 | 2 | . . . . |SHORT| Extension type for second extension | 1997 +-----+--------------+-----+----------------------------------------+ 1998 | 4 | . . . . |LONG | Size of second extension=Z2 | 1999 +-----+--------------+-----+----------------------------------------+ 2000 | Z2 | . . . . |BYTE | Data for second extension | 2001 +-----+--------------+-----+----------------------------------------+ 2002 | ... | . . . . |.... | Further extensions | 2003 +-----+--------------+-----+----------------------------------------+ 2005 Current JBIG2 Image Strip Extension Types: 2006 +----------------+--------------------------------------------------+ 2007 | Extension Type | Meaning | 2008 +----------------+--------------------------------------------------+ 2009 | 0 | Undefined | 2010 +----------------+--------------------------------------------------+ 2011 | 1 | Colour tags | 2012 | | This extension contains colour tag data, T.45 | 2013 | | encoded. | 2014 | | This value SHALL NOT be used when using Profile T| 2015 +----------------+--------------------------------------------------+ 2017 E1.6.6 Representation of JBIG2 data in TIFF 2019 The embedding of JBIG2 data in TIFF then takes the following form: 2020 +------+-----------------+---------------------------------------+ 2021 | | | "II" or "MM" | 2022 | | +---------------------------------------+ 2023 | TIFF | TIFF Header | 42 | 2024 | file | +---------------------------------------+ 2025 | | | FirstIFD offset (IFD0) |--: 2026 | +-----------------+---------------------------------------+ | 2027 | | ... | 2028 | :---|-----------------------------<---------------------------|--: 2029 | | | ... | 2030 | | +-----------------+---------------------------------------+ 2031 | | +-----------------+---------------------------------------+ 2032 | | | | ... | 2033 | | | +---------------------------------------+ 2034 | v | | GlobalParametersIFD |--: 2035 | | | +---------------------------------------+ | 2036 | | | | StripOffsets/StripByteCounts | | 2037 | | | +---------------------------------------+ | 2038 | :-->| IFD0 | ... | | 2039 | | +---------------------------------------+ v 2040 | | | ... | | 2041 | | +---------------------------------------+ | 2042 | | | Next IFD offset (IFD 1) |--|-: 2043 | +-----------------+---------------------------------------+ | | 2044 | | ... | | | 2045 | :---|-----------------------------<---------------------------|--: | 2046 | | | ... | | 2047 | v +-----------------+---------------------------------------+ v 2048 | | | | ... | | 2049 | | | +---------------------------------------+ | 2050 | :-->| GlobalParameters| SharedData offset (1st Shared |--: | 2051 | | IFD | Data Table offset) | | | 2052 | | +---------------------------------------+ | | 2053 | TIFF | | ... | v | 2054 | file +-----------------+---------------------------------------+ | | 2055 | | ... | | v 2056 | :---|-----------------------------<---------------------------|--: | 2057 | | | ... | | 2058 | | +-----------------+---------------------------------------+ | 2059 | | | | Number of items in table | | 2060 | | | +----------------+----------------------+ | 2061 | | | | | Byte count (of JBIG2 | | 2062 | | | | | Shared Data 0) | | 2063 | v | | +----------------------+ v 2064 | | | | | File offset (to |--: | 2065 | | | | | JBIG2 Shared Data 0) | | | 2066 | | | | +----------------------+ | | 2067 | | | | Shared Data 0 | SharedDataType (1) | | | 2068 | | | | +----------------------+ v | 2069 | :-->| Shared Data | | Last page used | | | 2070 | | Table 0 | +----------------------+ | | 2071 | | | | SharedDataMemory | | | 2072 | | +----------------+----------------------+ | v 2073 | TIFF | | Shared Data 1 | ... | | | 2074 | file | +----------------+----------------------+ v | 2075 | | | ... | ... | | | 2076 | | +----------------+----------------------+ | | 2077 | | | Next Shared Data Table offset | | | 2078 | +-----------------+---------------------------------------+ | | 2079 | +-----------------+---------------------------------------+ | | 2080 | | ... | | v 2081 | :---|-----------------------------<---------------------------|--: | 2082 | | | ... | | 2083 | v +-----------------+---------------------------------------+ | 2084 | | | | 0 (version) | | 2085 | | | +---------------------------------------+ | 2086 | | | | | | 2088 | v | +---------------------------------------+ | 2089 | | | | JBIG2-coded block (block may contain | v 2090 | | | | multiple JBIG2 segments) | | 2091 | :-->| JBIG2 Shared +---------------------------------------+ | 2092 | | Data 0 | Extension type for first extension | | 2093 | | | (data that are outside the scope of | | 2094 | | | T.88-JBIG2) | | 2095 | | +---------------------------------------+ | 2096 | | | | | 2097 | TIFF | +---------------------------------------+ | 2098 | file | | Data for first Extension | | 2099 | | +---------------------------------------+ v 2100 | | | ... | | 2101 | +-----------------+---------------------------------------+ | 2102 | | ... | | 2103 | :---|-----------------------------<---------------------------|----: 2104 | | | ... | 2105 | v +-----------------+---------------------------------------+ 2106 | | | | ... | 2107 | | | +---------------------------------------+ 2108 | :-->| IFD1(page 0) | StripOffset (strip 0) |---: 2109 | | +---------------------------------------+ | 2110 | | | ... | | 2111 | +-----------------+---------------------------------------+ | 2112 | | ... | | 2113 | :---|-----------------------------<---------------------------|---: 2114 | | | ... | 2115 | | +-----------------+---------------------------------------+ 2116 | | | | Strip format version | 2117 | | | +---------------------------------------+ 2118 | | | | SharedDataList | 2119 | | | Strip 0 +---------------------------------------+ 2120 | :-->| | JBIG2-coded position block | 2121 | | +---------------------------------------+ 2122 | | | Extensions | 2123 | TIFF +-----------------+---------------------------------------+ 2124 | file | | 2125 | | ... | 2126 +------+---------------------------------------------------------+ 2128 E1.6.7 Rules and Requirements for Images 2130 Profile T defines a fundamental set of imaging rules. 2132 1. Typically, only ONE layer with image data SHALL exist and it SHALL 2133 be the binary Mask layer, which SHALL be the Primary IFD. 2134 JBIG2 Compression(34715) SHALL be used in this layer and the 2135 PhotometricInterpretation SHALL be 0. 2137 2. A Foreground and/or Background layer without image data (i.e. 2138 IFD(s) with StripByteCounts = 0) MAY be present. If present, then 2139 only black and white colors SHALL be used. The Foreground and 2140 Background defaults for ImageBaseColor SHALL be black and 2141 white respectively. 2143 3. The Primary IFD defines and extends to the entire page boundary; 2144 all attached SubIFD images cannot extend beyond the Primary image. 2145 Resolution differences may cause some pixels to "hang over" the 2146 page boundary, but no new pixels should exist completely beyond 2147 the page extent. 2149 4. Images other than the Primary Image (i.e. Primary IFD) MAY 2150 optionally cover only a portion of the stripe or page. 2152 5. Each Primary IFD and each MRC-specific SubIFD SHALL have an 2153 ImageLayer field to specify which layer the IFD belongs to, and 2154 the imaging order of that IFD within the layer. 2156 6. Each Primary IFD SHALL have a NewSubFileType field value set to 2157 18, indicating a single page of a multi-page document (bit 1) and 2158 MRC (bit 4). 2160 7. Each MRC-specific child IFD SHALL have a NewSubFileType field 2161 value set to 16, indicating MRC (bit 4). 2163 8. In MRC Internet Fax, each layer is transmitted as a sequence of 2164 TIFF strips. If the page consists of a single layer, then 2165 all page stripes SHALL be stored in the single Primary IFD. In 2166 this case, coding parameters cannot change between strips. If the 2167 page consists of more than one layer, then all stripes of the 2168 Primary Mask layer SHALL be stored in the single Primary IFD as a 2169 series of corresponding strips. Should Foreground/Background 2170 layers be present, the StripByteCounts SHALL be set to "0". 2171 Without constraint on coding parameter changes, each stripe of the 2172 Foreground/Background layers SHALL be stored in one IFD containing 2173 a single strip , referenced by the Primary IFD's SubIFD field, 2174 containing an ImageLayer field with ImageLayer[0] identifying 2175 Background (layer 1) or Foreground layer (layer 3), and 2176 Imagelayer[1] identifying order in which images within a single 2177 layer are to be rendered. The TIFF XPosition and Yposition fields 2178 are used to indicate the placement of these images with respect to 2179 the primary image. 2181 9. If Background and/or Foreground images are present, their 2182 resolution SHALL be that of the Primary Mask image. 2184 10. As define in Rule 10 of Section 1.4.8. 2186 E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile 2187 Summary 2189 Recommended fields are shown with an asterisk * 2191 Required fields or values are shown with a double asterisk **. If the 2192 double asterisk is on the field name, then all the listed values are 2193 required of implementations; if the double asterisks are in the 2194 Values column, then only the values suffixed with a double asterisk 2195 are required of implementations. 2197 +------------------+-----------------------------------------+ 2198 | Baseline Fields | Values | 2199 +------------------+-----------------------------------------+ 2200 | BitsPerSample | 1**: binary mask | 2201 +------------------+-----------------------------------------+ 2202 | Compression | 1: None (ImageBaseColor IFD only) | 2203 | | 34715**: JBIG2 | 2204 +------------------+-----------------------------------------+ 2205 | DateTime* | {ASCII): date/time in the 24-hour format| 2206 | | "YYYY:MM:DD HH:MM:SS" | 2207 +------------------+-----------------------------------------+ 2208 | FillOrder** | 1: Most significant bit first | 2209 | | 2: Least significant bit first | 2210 +------------------+-----------------------------------------+ 2211 | ImageDescription*| {ASCII}: A string describing the | 2212 | | contents of the image. | 2213 +------------------+-----------------------------------------+ 2214 | ImageWidth | 1728**, 2048, 2432, 2592, | 2215 | | 3072, 3456, 3648, 4096, 4864 | 2216 +------------------+-----------------------------------------+ 2217 | ImageLength** | n: total number of scanlines in image | 2218 +------------------+-----------------------------------------+ 2219 | NewSubFileType** | 16, 18: Bit 1 indicates single page of a| 2220 | | multi-page document on Primary IFD | 2221 | | Bit 4 indicates MRC model | 2222 +------------------+-----------------------------------------+ 2223 | Orientation | 1**-8, Default 1 | 2224 +------------------+-----------------------------------------+ 2225 | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | 2226 | pretation | | 2227 +------------------+-----------------------------------------+ 2228 +------------------+-----------------------------------------+ 2229 | ResolutionUnit** | 2: inch | 2230 +------------------+-----------------------------------------+ 2231 | RowsPerStrip | n: number of scanlines per strip | 2232 +------------------+-----------------------------------------+ 2233 | SamplesPerPixel | 1**, 3 (ImageBaseColor IFD only) | 2234 +------------------+-----------------------------------------+ 2235 | Software* | {ASCII}: name & release number of | 2236 | | creator software | 2237 +------------------+-----------------------------------------+ 2238 | StripByteCounts**| : number or bytes in each strip, | 2239 | | fixed to "0" for FG/BG (when present) | 2240 +------------------+-----------------------------------------+ 2241 | StripOffsets** | : offset from beginning of file to | 2242 | | each TIFF strip | 2243 +------------------+-----------------------------------------+ 2244 | XResolution | 200**, 204**, 300, 400, 408 (written in | 2245 | | pixels/inch) | 2246 +------------------+-----------------------------------------+ 2247 | YResolution | 98**, 196**, 100**, 200**, | 2248 | | 300, 391, 400 (written in pixels/inch) | 2249 +------------------+-----------------------------------------+ 2250 | Extension Fields | 2251 +------------------+-----------------------------------------+ 2252 | DocumentName* | {ASCII}: name of scanned document | 2253 +------------------+-----------------------------------------+ 2254 | PageNumber** | n, m: page number followed by total page| 2255 | | count | 2256 +------------------+-----------------------------------------+ 2257 | SubIFDs | : byte offset to FG/BG IFDs | 2258 +------------------+-----------------------------------------+ 2259 | XPosition | horizontal offset in primary IFD | 2260 | | resolution units | 2261 +------------------+-----------------------------------------+ 2262 | YPosition | vertical offset in primary IFD | 2263 | | resolution units | 2264 +------------------+-----------------------------------------+ 2265 | New Fields | 2266 +------------------+-----------------------------------------+ 2267 | StripRowCounts | : number of scanlines in each strip | 2268 +------------------+-----------------------------------------+ 2269 | ImageLayer | n, m: layer number, imaging sequence | 2270 | | (e.g., strip number) | 2271 +------------------+-----------------------------------------+ 2272 | GlobalParameters | IFD: global parameters IFD | 2273 | IFD** | | 2274 +------------------+-----------------------------------------+ 2275 | ProfileType* | n: type of data stored in TIFF file | 2276 +------------------+-----------------------------------------+ 2277 +------------------+-----------------------------------------+ 2278 | FaxProfile* | n: ITU-T compatible fax profile | 2279 +------------------+-----------------------------------------+ 2280 | CodingMethods* | n: compression algorithms used in file | 2281 +------------------+-----------------------------------------+ 2282 | VersionYear* | byte sequence: year of ITU-T standard | 2283 +------------------+-----------------------------------------+ 2284 | ModeNumber* | n: mode (i.e. functional level) of T.44 | 2285 | | standard | 2286 +------------------+-----------------------------------------+ 2287 | TIFF-FXExtensions| n: extension(s) identification number, | 2288 | ** | bit 3 for Profile T SHALL be among the | 2289 | | set bits | 2290 +------------------+-----------------------------------------+ 2291 | MultiProfiles* | n: profiles or profile(s) plus | 2292 | | extension(s) applied within the file | 2293 +------------------+-----------------------------------------+ 2294 | T88Options* | n, m: option numbers, profile number | 2295 +------------------+-----------------------------------------+ 2296 | SharedData | : offset from beginning of file to | 2297 | | the first Shared Data | 2298 +------------------+-----------------------------------------+ 2300 E1.7. TIFF-FX Extension 5: JBIG2 Color Extension of Profile M 2302 This section defines extensions to Profile M that augment the pool of 2303 coders and encoding mechanisms available for use in the mask and 2304 foreground layers when encoding documents with color. The JBIG2, ITU- 2305 T Rec. T.88 / ISO-IEC 14492, bi-level coder is made available for use 2306 in both mask and foreground layer(s). It must be noted that simple 2307 JBIG2 symbol-based compression is limited to matching symbols in a 2308 binary image, but ITU-T Rec. T.44 Annex B [T.44Amd1] expands this to 2309 include single-color images, such as colored text. The T.44 defined 2310 mechanism, referenced as "colour tag" encoding, is only available for 2311 use in foreground layers that are associated with JBIG2 coded mask 2312 layers. The more conventional multi-level color coders, such JPEG, 2313 are also available for use in the encoding of foreground layer colors 2314 when JBIG2 is used in the mask layer(s). 2316 Revise Section 8, 2nd sentence to read as follows: 2318 Implementers of this profile are required to implement Profiles S 2319 and C, and may optionally implement other profiles. 2321 E1.7.1. Overview 2323 Use of JBIG2 in Profile M effectively amounts to application of 2324 Profile T (i.e. Section E.2) to the mask layer(s), without imposition 2325 of the Profile T black-and-white constraints that prohibit the 2326 presence of background and/or foreground image data (i.e. if present 2327 StripByteCounts = 0). This translates to augmenting the MRC 2328 model and TIFF representation, defined in Profile M, with the Shared 2329 Data extension (Extension 1), and using JBIG2 coding (i.e. 2330 Compression = 34715) in the mask layer. The N-layer model and TIFF 2331 representation, defined in Extension 2 (Section E1.4) MAY also be 2332 used if the corresponding TIFF-FXExtensions bit is set. 2334 Use of JBIG2 and "colour tagging" to encode the colors of the 2335 foreground layer(s) translates to attaching discrete color values to 2336 the JBIG2 coded symbols (shapes) that are represented in the 2337 associated mask layer. 2339 E1.7.2. Required TIFF Fields 2341 This section describes the TIFF fields required, in addition to those 2342 in Sections 8.2, E1.4 and E1.5.2.3. 2344 E1.7.2.1. Baseline Fields 2345 Augment the Section 8.2.1 compression field with JBIG2 (i.e. value = 2346 34715) as below: 2348 Compression(259) = 1, 3, 4, 7, 9, 10, 34715. SHORT 2349 For Mask layer, see Sections 4.2.1, 5.2.1 and E1.6.2.1. 2350 For Foreground and Background layers, see Sections 6.2.1, 7.2.1 and 2351 E1.6.2.1. Compression=1 is not used by previous profiles. An IFD used 2352 only to specify the default image color for a layer SHALL 2353 not have any encoded image data associated with it, i.e., the 2354 StripByteCounts field SHALL contain a 0. Since no image data exists 2355 in the IFD, the Compression field SHALL be set to 1 indicating no 2356 compression. A Compression field value of 1 is not allowed for any 2357 other IFDs. 2359 E1.7.2.2. Extension Fields 2360 See Section 8.2.2. 2362 E1.7.2.3. New Fields 2363 Augment Section 8.2.3 with these two fields from E1.5.2.3. 2364 GlobalParametersIFD(400) 2365 TIFF-FXExtensions(34687) 2366 Bit 4 of the TIFF-FXExtensions field SHALL be set to 1. 2368 E1.7.3. Recommended TIFF Fields 2370 See Section E1.6.3. 2372 The note that appears at the end of the T88Options[0] table, 2373 prohibiting activation of bits 5 or 6 (i.e. ColourTagsFollow or 2374 ColourTagsPresent respectively) for Profile T SHALL be disregarded. 2376 If the IFD's T88Options[0] field has the ColourTagsFollow or 2377 ColourTagsPresent bits set, then the following segment types SHALL 2378 NOT occur in the JBIG2-coded position block: 2379 - Pattern dictionary 2380 - Halftone region 2381 - Generic region 2382 - Generic refinement region 2384 E1.7.4 JBIG2 Shared Data 2385 See Section E1.6.4. 2387 E1.7.5 The Image Strip 2388 See Section E1.6.5. 2390 E1.7.6 Representation of JBIG2 data in TIFF 2391 See Section E1.6.6. 2393 E1.7.7 Colour Tag (Color Symbol) Compression 2395 E1.7.7.1 Why Use Colour Tag Compression 2397 Another opportunity that is afforded by JBIG2 is improved compression 2398 of the foreground layer for documents containing colored text. In 2399 most cases, if a document contains text, each individual text 2400 character is a single, flat, color (e.g., black or red), and the 2401 number of such colors is limited. The foreground layer in this case 2402 looks like a number of colored blobs, one for each character, each 2403 one having the shape of the corresponding character. This foreground 2404 layer can be compressed using a new method that takes advantage of 2405 the JBIG2 structure. If the mask layer is compressed using JBIG2 2406 symbols, then decoding it essentially yields a sequence of 2407 (XPosition, YPosition, Symbol ID) triples that represent each symbol 2408 instance. Each triple indicates that the symbol (from some 2409 dictionary) specified by "Symbol ID" SHOULD be drawn at the location 2410 "(X, Y)". Simply augmenting a text region triple with a fourth 2411 component, the color of that individual character (the symbols 2412 "colour tag"), allows storage of the foreground layer in a very small 2413 amount of space, using run-length coding on those colors. The total 2414 space taken by the foreground layer can be small in comparison to an 2415 encoded contone image. 2417 E1.7.7.2 Colour Tag Terms of Use in TIFF 2419 Colour tags are one of the JBIG2 image strip extensions referenced in 2420 Section E1.6.5 (The JBIG2 Image Strip). Their Representation within 2421 the image strip is expressed within Section E1.6.5.1 (Image Strip 2422 Format). Stepping back and considering the MRC (Mixed Raster Content) 2423 mask (bi-level data) and foreground (color data) layer pairs, we 2424 arrive at the following terms of use to be applied when colour 2425 tagging is used in foreground representation: 2427 1. the (JBIG2-compressed) bi-level data (position block) SHALL be 2428 followed immediately (in the file) by the colour tags. The 2429 colour tags SHALL appear as an extension in the JBIG2 image 2430 strip, with the image strip extension type = 1 (colour tags, as 2431 defined in Section E1.6.5.1). The colour tags SHALL be 2432 compressed using ITU-T Rec. T.45. 2433 2. the mask IFD points to the start of the bi-level data, and the 2434 associated byte count SHALL include ONLY the bi-level data (the 2435 position block, but not the colour tags). The IFD's Compression 2436 field SHALL be set to 34715 (JBIG2). If present, the 2437 T88Options[0] field SHALL have bit 5 set to 1 2438 (ColourTagsFollow). 2439 3. the foreground IFD points to the bi-level data, and the 2440 associated byte count SHALL include BOTH the bi-level data and 2441 the colour tag extension. The IFD's Compression field SHALL be 2442 set to 34715 (JBIG2). The IFD's PhotometricInterpretation SHALL 2443 indicate the color space used to interpret the colors found in 2444 the colour tag data. If present, the T88Options[0] field SHALL 2445 have bit 6 set to 1 (ColourTagsPresent). 2446 4. in the event that two symbol instances overlap, the 2447 reconstructed image SHALL be the one obtained by drawing each 2448 JBIG2 symbol with the appropriate color, where the drawing SHALL 2449 be done in the order that the JBIG2 symbols appear in the 2450 encoded JBIG2 image strip. 2451 Thus, the foreground IFD completely describes an image: it points to 2452 enough data to reconstruct a colored image that contains the right 2453 color at each pixel selected by the mask. It is reasonable that a 2454 decoder will recognize that both a mask IFD and a foreground IFD 2455 point to the same JBIG2 data, and decode the JBIG2 data only once 2456 (not once for the mask, and again for the foreground). The 2457 T88Options[0] bits "ColourTagsFollow" and "ColourTagsPresent" are 2458 designed to make the decoder's job easier: if it sees 2459 ColourTagsFollow in the T88Options[0] field of a mask IFD, it knows 2460 it should defer decoding it until it decodes the corresponding 2461 foreground IFD. 2463 Similarly, if it sees ColourTagsPresent in a foreground IFD, then it 2464 can optimize the drawing/decoding operations. 2466 Note: This representation has two pointers to the same part of the 2467 TIFF-FX file, which is a violation of a TIFF guideline, and could 2468 conceivably cause problems in some unsuspecting TIFF editors. 2469 However, these unsuspecting TIFF editors would probably not be able 2470 to decode the JBIG2 data anyway. The shared pointers occur only in a 2471 restricted case. 2473 The nature of the two pointers is illustrated below: 2475 +----------------------------+ 2476 | | 2477 | | 2478 | | 2479 | | 2480 +----------------------------+ 2481 | ... | 2482 | SubIFD 0 StripOffsets |--: 2483 | StripByteCounts|--|-: 2484 | ... | | | mask IFD's 2485 +----------------------------+ | | StripByteCounts 2486 | | | | includes only 2487 :---|------------<---------------|--: | bi-level data 2488 | | | | 2489 mask and | +----------------------------+<---:<--: 2490 foreground :-->| JBIG2 Position | | | foreground IFD's 2491 IFD both | | data block | | | StripByteCounts 2492 point to | | _______________ |<---: | includes both 2493 bi-level | | Colour Tag extension | | bi-level data and 2494 data | +----------------------------+ <--: colour tags 2495 | | | | 2496 :---|------------<---------------|--: | 2497 | | | | 2498 +----------------------------+ | | 2499 | ... | | | 2500 | SubIFD 1 StripOffsets |--: | 2501 | StripByteCounts|--------: 2502 | ... | 2503 +----------------------------+ 2504 | | 2505 | | 2506 | | 2507 | | 2508 | | 2509 | | 2510 +----------------------------+ 2512 E1.7.8 Rules and Requirements for Images 2514 Revise the identified Profile M Section 8.4 Rules and Requirements 2515 for Images as follows: 2516 a). Revise Rule 1 to read as defined in Section E1.4.8. 2518 b). Revise Rule 3 by splitting, renumbering and editing to read: 2519 3. The Background and Foreground images SHALL support the color 2520 representations defined in Section 6 and MAY support the color 2521 representations defined in other Sections. Additionally, the 2522 Foreground MAY support Section E1.7.7 Color Tag representation. 2524 4. Images other than the Primary Image (i.e. Primary IFD) MAY 2525 optionally cover only a portion of the stripe or page. 2527 c). Append a Rule 1o to read as defined in Section E1.4.8. 2529 E1.7.9. JBIG2 Extension of Profile M Summary 2531 Recommended fields are shown with an asterisk * 2533 Required fields or values are shown with a double asterisk **. If the 2534 double asterisk is on the field name, then all the listed values are 2535 required of implementations; if the double asterisks are in the 2536 Values column, then only the values suffixed with a double asterisk 2537 are required of implementations. 2539 +------------------+-----------------------------------------+ 2540 | Baseline Fields | Values | 2541 +------------------+-----------------------------------------+ 2542 | BitsPerSample | 1**: binary mask | 2543 | | 2-8**: bits per color sample for FG/BG | 2544 | | 9-16: optional 12 bits/sample | 2545 +------------------+-----------------------------------------+ 2546 | Compression | 1: None (ImageBaseColor IFD only) | 2547 | | 3**: Modified Huffman and Modified Read | 2548 | | (mask layer) | 2549 | | 4: Modified Modified Read | 2550 | | 7**: JPEG (FG/BG layers) | 2551 | | 9: JBIG, per T.85 | 2552 | | 10: JBIG, per T.43 | 2553 | | 34715**: JBIG2, per T.88 (Note that T.45| 2554 | | Run-length Colour Encoding is also| 2555 | | required for FG layers) | 2556 +------------------+-----------------------------------------+ 2557 | DateTime* | {ASCII): date/time in the 24-hour format| 2558 | | "YYYY:MM:DD HH:MM:SS" | 2559 +------------------+-----------------------------------------+ 2560 | FillOrder** | 1: Most significant bit first | 2561 | | 2: Least significant bit first | 2562 +------------------+-----------------------------------------+ 2563 | ImageDescription*| {ASCII}: A string describing the | 2564 | | contents of the image. | 2565 +------------------+-----------------------------------------+ 2566 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 2567 | | 2592, 3072, 3456, 3648, 4096, 4864 | 2568 +------------------+-----------------------------------------+ 2569 | ImageLength** | n: total number of scanlines in image | 2570 +------------------+-----------------------------------------+ 2571 +------------------+-----------------------------------------+ 2572 | NewSubFileType** | 16, 18: | 2573 | | Bit 1 indicates single page of a multi- | 2574 | | page document on Primary IFD | 2575 | | Bit 4 indicates MRC model | 2576 +------------------+-----------------------------------------+ 2577 | Orientation | 1**-8, Default 1 | 2578 +------------------+-----------------------------------------+ 2579 | PhotometricInter | 0**: WhiteIsZero (Mask layer) | 2580 | pretation | 2: RGB | 2581 | | 5: CMYK | 2582 | | 10**: ITULAB (FG/BG layers) | 2583 +------------------+-----------------------------------------+ 2584 | ResolutionUnit** | 2: inch | 2585 +------------------+-----------------------------------------+ 2586 | RowsPerStrip | n: number or scanlines per strip | 2587 +------------------+-----------------------------------------+ 2588 | SamplesPerPixel | 1**: L* (lightness) | 2589 | | 3: RGB, LAB, CMY | 2590 | | 4: CMYK | 2591 +------------------+-----------------------------------------+ 2592 | Software* | {ASCII}: name & release number of | 2593 | | creator software | 2594 +------------------+-----------------------------------------+ 2595 | StripByteCounts**| : number or bytes in each strip | 2596 +------------------+-----------------------------------------+ 2597 | StripOffsets** | : offset from beginning of file to | 2598 | | each TIFF strip | 2599 +------------------+-----------------------------------------+ 2600 | XResolution | 100, 200**, 300, 400 (written in | 2601 | | pixels/inch) | 2602 +------------------+-----------------------------------------+ 2603 | YResolution | equal to XResolution (pixels SHALL be | 2604 | | square) | 2605 +------------------+-----------------------------------------+ 2606 | Extension Fields | 2607 +------------------+-----------------------------------------+ 2608 | T4Options | 0**: required if Compression is Modified| 2609 | | Huffman, EOLs not byte aligned | 2610 | | 1: required if Compression 2D Modified | 2611 | | Read, EOLs are not byte aligned | 2612 | | 4**: required if Compression Modified | 2613 | | Huffman, EOLs byte aligned | 2614 | | 5: required if Compression 2D Modified | 2615 | | Read, EOLs are byte aligned | 2616 +------------------+-----------------------------------------+ 2617 | T6Options | 0: required if Compression is 2D | 2618 | | Modified Modified Read | 2619 +------------------+-----------------------------------------+ 2620 +------------------+-----------------------------------------+ 2621 | DocumentName* | {ASCII}: name of scanned document | 2622 +------------------+-----------------------------------------+ 2623 | PageNumber** | n, m: page number followed by total page| 2624 | | count | 2625 +------------------+-----------------------------------------+ 2626 | ChromaSubSampling| (1,1), (2, 2)** | 2627 | | (1, 1): equal numbers of lightness and | 2628 | | chroma samples horizontally & vertically| 2629 | | (2, 2): twice as many lightness samples | 2630 | | as chroma horizontally and vertically | 2631 +------------------+-----------------------------------------+ 2632 | ChromaPositioning| 1: centered | 2633 +------------------+-----------------------------------------+ 2634 | Indexed | 0: not a palette-color image | 2635 | | 1: palette-color image | 2636 +------------------+-----------------------------------------+ 2637 | SubIFDs | : byte offset to FG/BG IFDs | 2638 +------------------+-----------------------------------------+ 2639 | XPosition | horizontal offset in primary IFD | 2640 | | resolution units | 2641 +------------------+-----------------------------------------+ 2642 | YPosition | vertical offset in primary IFD | 2643 | | resolution units | 2644 +------------------+-----------------------------------------+ 2645 | New Fields | 2646 +------------------+-----------------------------------------+ 2647 | Decode | minL, maxL, mina, maxa, minb, maxb: | 2648 | | minimum and maximum values for L*a*b* | 2649 +------------------+-----------------------------------------+ 2650 | ImageBaseColor | a, b, c: background color in ITULAB | 2651 +------------------+-----------------------------------------+ 2652 | StripRowCounts | : number of scanlines in each strip | 2653 +------------------+-----------------------------------------+ 2654 | ImageLayer | n, m: layer number, imaging sequence | 2655 | | (e.g., strip number) | 2656 +------------------+-----------------------------------------+ 2657 | T82Options | 0: T.85 profile of T.82 coding | 2658 +------------------+-----------------------------------------+ 2659 | GlobalParameters | IFD: global parameters IFD | 2660 | IFD** | | 2661 +------------------+-----------------------------------------+ 2662 | ProfileType* | n: type of data stored in TIFF file | 2663 +------------------+-----------------------------------------+ 2664 | FaxProfile* | n: ITU-T compatible fax profile | 2665 +------------------+-----------------------------------------+ 2666 | CodingMethods* | n: compression algorithms used in file | 2667 +------------------+-----------------------------------------+ 2668 +------------------+-----------------------------------------+ 2669 | VersionYear* | byte sequence: year of ITU-T standard | 2670 +------------------+-----------------------------------------+ 2671 | ModeNumber* | n: mode of T.44 standard | 2672 +------------------+-----------------------------------------+ 2673 | TIFF-FXExtensions| n: extension(s) identification number, | 2674 | ** | bit 4 for Profile M SHALL be among the | 2675 | | set bits | 2676 +------------------+-----------------------------------------+ 2677 | MultiProfiles* | n: profiles or profile(s) plus | 2678 | | extension(s) applied within the file | 2679 +------------------+-----------------------------------------+ 2680 | T88Options* | n, m: option numbers, profile number | 2681 | | - if colour tag is used then bit 1 of n | 2682 | | SHALL NOT be set | 2683 | | - if bit 5 is set then IFD is in mask | 2684 | | layer with colour tag augmented JBIG2 | 2685 | | coded corresponding foreground layer | 2686 | | - if bit 6 is set then IFD is in | 2687 | | foreground layer with colour tag | 2688 | | augmented JBIG2 coding | 2689 +------------------+-----------------------------------------+ 2690 | SharedData | : offset from beginning of file to | 2691 | | the first Shared Data | 2692 +------------------+-----------------------------------------+ 2694 E1.8. Security Considerations 2696 This document describes a file format for Internet fax, which is a 2697 series of profiles of TIFF for facsimile. As such, it does not create 2698 any security issues not already identified in [TIFF-REG], in its use 2699 of fields as defined in [TIFF]. There is also new TIFF fields 2700 defined within this specification, but they are of a purely 2701 descriptive nature, so that no new security risks are incurred. 2703 Further, the encoding specified in this document does not in any way 2704 preclude the use of any Internet security protocol to encrypt, 2705 authenticate, or non-repudiate TIFF-encoded facsimile messages. 2707 E1.9. References 2709 The following references are appended to the list in Section 11 of 2710 RFC XXXX. 2712 [[[RFC XXX is a placeholder for the pending Draft Standard revision to 2713 RFC 2301, currently documented in draft-ietf-fax-tiff-fx-09.txt.]]] 2715 [RFC XXXX] RFC XXXX, Draft Standard "File Format for Internet Fax", 2716 known as TIFF-FX (pending issue of draft-ietf-fax-tiff-fx-09.txt) 2718 [T.4 Amd1] Amendment 1 to ITU-T Recommendation T.4, Standardization 2719 of group 3 facsimile apparatus for document transmission, March 2000 2720 [T.44Amd1] Amendment 1 to ITU-T Recommendation T.44, Mixed Raster 2721 Content (MRC), March 2000. 2723 [T.45] ITU-T Recommendation T.45, Run-length Colour Encoding, March 2724 2000. 2726 [T.88] ITU-T Recommendation T.88|ISO/IEC 14492:2000, Information 2727 technology - Lossy/Lossless coding of Bi-level Images. (Commonly 2728 referred to as JBIG2 standard.) 2730 [T.89] ITU-T Draft Recommendation T.89, Application Profiles for 2731 Recommendation T.88 - Lossy/Lossless Coding of Bi-level Images 2732 (JBIG2) for Facsimile, November 2000. 2734 [REQ] RFC 2119, "Key words for use in RFCs to Indicate Requirement 2735 Levels", S. Bradner, Harvard University, March 1997. 2737 E1.10 Authors' Addresses 2739 Dave Abercrombie Robert Buckley 2740 Xerox Corporation Xerox Corporation 2741 Mailstop PAHV-121 Mailstop 0128-30E 2742 3400 Hillview Ave 800 Phillips Road 2743 Palo Alto, CA 94304, USA Webster, NY 14580, USA 2744 Voice: +1-650-813-6811 Voice: +1-716-422-1282 2745 Fax: +1-650-813-6860 Fax: +1-716-265-8871 2746 Email: aber@pahv.xerox.com Email:rbuckley@crt.xerox.com 2748 Lloyd McIntyre William Rucklidge 2749 Xerox Corporation Intelligent Markets 2750 Mailstop PAHV-121 410 Jessie St., Suite 602 2751 3400 Hillview Ave San Francisco, CA 94103, USA 2752 Palo Alto, CA 94304, USA Voice: +1-415-369-5013 2753 Voice: +1-650-813-6762 Email: wjr@imarkets.com 2754 Fax: +1-650-845-2340 2755 Email: lmcintyre@pahv.xerox.com 2757 Full Copyright Statement 2759 Copyright (C) The Internet Society (2001). All Rights Reserved. 2761 This document and translations of it may be copied and furnished to 2762 others, and derivative works that comment on or otherwise explain it 2763 or assist in its implementation may be prepared, copied, published 2764 and distributed, in whole or in part, without restriction of any 2765 kind, provided that the above copyright notice and this paragraph are 2766 included on all such copies and derivative works. However, this 2767 document itself may not be modified in any way, such as by removing 2768 the copyright notice or references to the Internet Society or other 2769 Internet organizations, except as needed for the purpose of 2770 developing Internet standards in which case the procedures for 2771 copyrights defined in the Internet Standards process must be 2772 followed, or as required to translate it into languages other than 2773 English. 2775 The limited permissions granted above are perpetual and will not be 2776 revoked by the Internet Society or its successors or assigns. 2778 This document and the information contained herein is provided on an 2779 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2780 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2781 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2782 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2783 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2785 Annex A. List of edits to draft-ietf-fax-tiff-fx-Extension1-00 2787 Note: "e" below the item number indicates that the change is editorial, 2788 while "r" indicates a requirement change. Less significant 2789 editorial changes are not identified in this list. 2790 +----+---------+-------------------------------------------------+ 2791 | No.| Section | Edit March 01, 2000 | 2792 +----+---------+-------------------------------------------------+ 2793 | 1. | Abstract| Added comment clarifying RFC XXXX reference as | 2794 | e | E1.1 | being current draft-ietf-fax-tiff-fx-09.txt and | 2795 | | E1.9 | Abstract, 2nd sentence, changed "increased | 2796 | | | resolutions" to "increased set of resolutions" | 2797 +----+---------+-------------------------------------------------+ 2798 | 2. | E1.1.2 | Expanded description of document layout, added a| 2799 | e | E1.9 | tree diagram, clarified that some specifications| 2800 | | | are defined via edits to sections of RFC XXXX, | 2801 | | | and added the appropriate [REQ] reference | 2802 +----+---------+-------------------------------------------------+ 2803 | 3. | All | E1, E2, E3, E4 and E5 extension abbreviations | 2804 | e | | are unnecessary and have been removed | 2805 +----+---------+-------------------------------------------------+ 2806 | 4. | E1.2.2.1| Clarified that FaxProfile value of 255 signals | 2807 | e | | use of MultiProfiles field rather than | 2808 | | | designates the MultiProfiles field | 2809 +----+---------+-------------------------------------------------+ 2810 | 5. | E1.4.1 | 3rd paragraph, clarified value of expanding | 2811 | e | | 3-layer MRC model to N-layers | 2812 +----+---------+-------------------------------------------------+ 2813 | 6. | E1.4.1 | added provisions for multi-stripped single IFD | 2814 | r | E1.4.8 | representation of multi-striped layers other | 2815 | | E1.6.7 | than Primary Mask layers | 2816 | | E1.7.8 | | 2817 +----+---------+-------------------------------------------------+ 2818 | 7. | E1.4.3 | 1st paragraph, last sentence, clarify | 2819 | e | a | it is the images of each layer that are coded | 2820 | | | independently | 2821 +----+---------+-------------------------------------------------+ 2822 | 8. | E1.4.4 | last sentence, changed "layer 2, 4, 6, ..., N-1,| 2823 | e | a | where N is odd" to "layer 2, 4, 6, ..., N, where| 2824 | | | N is even", clarifying layer reference | 2825 +----+---------+-------------------------------------------------+ 2826 | 9. | E1.4.4 | instructions should indicate replacement of the | 2827 | e | c | entire 6th paragraph since there are references | 2828 | | | to the background and foreground throughout | 2829 +----+---------+-------------------------------------------------+ 2830 | 10.| E1.4.4 | Inserted "secondary Mask" into the 2nd and 3rd | 2831 | e | c) | sentence, clarifying that secondary Masks are | 2832 | | | also included in the SubIFD IFD representations | 2833 +----+---------+-------------------------------------------------+ 2834 +----+---------+-------------------------------------------------+ 2835 | 11.| E1.4.4 | Deleted edit item "e)" since it is already | 2836 | e | e) | addressed in RFC XXXX. | 2837 +----+---------+-------------------------------------------------+ 2838 | 12.| E1.4.7 | Clarified black rendering when ImageLayer[0]=N | 2839 | e | b) | and if N is even. | 2840 +----+---------+-------------------------------------------------+ 2841 | 13.| E1.4.8 | item 8, clarified correlation of strips to TIFF | 2842 | e | E1.6.7 | structure and stripes to page structure | 2843 +----+---------+-------------------------------------------------+ 2844 | 14.| E1.5 | Increased potential for broader usage of Shared | 2845 | r | all | Data by removing restriction permitting use only| 2846 | | | within the Profile M MRC structure plus | 2847 | | | references to Shared Data being a Profile M | 2848 | | | extension | 2849 +----+---------+-------------------------------------------------+ 2850 | 15.| E1.5.2 | Reduced the set of Required and Recommended | 2851 | e | E1.5.3 | fields to only those associated with the Shared | 2852 | | | Data structure representation. Fields Required | 2853 | | | or Recommended for the data being stored within | 2854 | | | the structure will be defined during definition | 2855 | | | of the particular data type that uses it, as in | 2856 | | | E1.6 for JBIG2 Shared Data | 2857 +----+---------+-------------------------------------------------+ 2858 | 16.| E1.5.4 | Shared Data Entries table, Byte offsets | 2859 | r | | Y+10 - Y+11, changed recommendation to a | 2860 | | | requirement that page ordinal is based on IFD | 2861 | | | order, this minimizes compatibility concerns | 2862 +----+---------+-------------------------------------------------+ 2863 | 17.| E1.5.4 | Shared Data ID, 4th sentence, clarification | 2864 | e | | extension | 2865 +----+---------+-------------------------------------------------+ 2866 | 18.| E1.5.4.1| 1st sentence, changed may to SHALL since the | 2867 | r | | SharedDataList must be present in the stream | 2868 +----+---------+-------------------------------------------------+ 2869 | 19.| E1.6.1 | clarified Profile T image layer constraints | 2870 | e | | | 2871 +----+---------+-------------------------------------------------+ 2872 | 20.| E1.6.1 | Moved rational for Profile T using the Profile M| 2873 | e | E1.6.1.1| structure from E1.6.1.1 to 2nd paragraph of | 2874 | | | E1.6.1 and added clarification | 2875 +----+---------+-------------------------------------------------+ 2876 | 21.| E1.6.1 | clarified requirement to use SharedData only | 2877 | e | E1.6.2.3| when resources are being shared between pages | 2878 | | E1.6.8 | | 2879 | | E1.7.9 | | 2880 +----+---------+-------------------------------------------------+ 2881 +----+---------+-------------------------------------------------+ 2882 | 22.| E1.6.2.3| 2nd paragraph, changed "SHOULD" to "MAY" since | 2883 | r | | there are reasons for inclusion | 2884 +----+---------+-------------------------------------------------+ 2885 | 23.| E1.6.3 | T88Options table, appended note clarifying that | 2886 | e | | bits 8 - 31 are reserved and set to zero. | 2887 +----+---------+-------------------------------------------------+ 2888 | 24.| E1.6.3 | For consistency, changed "or" to "and" in note | 2889 | e | | at the end of the T88Options table | 2890 +----+---------+-------------------------------------------------+ 2891 | 25.| E1.6.3 | Added MultiProfiles and SharedData fields | 2892 | e | | | 2893 +----+---------+-------------------------------------------------+ 2894 | 26.| E1.6.4.1| 2nd last paragraph, simplified Shared Data Table| 2895 | e | | description to reduce redundancy and clarified | 2896 | | | Shared Data Table requirements | 2897 +----+---------+-------------------------------------------------+ 2898 | 27.| E1.6.5 | 3rd paragraph, clarified reason for dictionary | 2899 | e | | location within or outside the position block | 2900 | | | and content of text and halftone region segments| 2901 +----+---------+-------------------------------------------------+ 2902 | 28.| E1.6.5 | item 10, clarified presence of JBIG2 defined | 2903 | e | | extensions located within the position block and| 2904 | | | TIFF defined extensions located outside the | 2905 | | | position block but within the TIFF image strip | 2906 +----+---------+-------------------------------------------------+ 2907 | 29.| E1.6.5.1| 1st sentence and byte 2 of table, changed | 2908 | e | | ResourceList and "resource IDs" to | 2909 | | | SharedDataList and "shared data IDs" | 2910 +----+---------+-------------------------------------------------+ 2911 | 30.| E1.6.6 | IFD0, changed location of "Next IFD offset | 2912 | e | | (IFD 1)" to the bottom of the 3 entries | 2913 +----+---------+-------------------------------------------------+ 2914 | 31.| E1.6.8 | Inserted MultiProfiles field into the summary | 2915 | e | E1.7.9 | tables following TIFF-FXExtensions field | 2916 +----+---------+-------------------------------------------------+ 2917 | 32.| E1.7 | Appended qualification that is more generic, | 2918 | e | | inclusive of new profiles | 2919 +----+---------+-------------------------------------------------+ 2920 | 33.| E1.7.1 | 1st paragraph, 2nd sentence, deleted "3-layer" | 2921 | e | | as the restriction is unnecessary | 2922 +----+---------+-------------------------------------------------+ 2923 | 34.| E1.7.2.3| Clarified that GlobalParametersIFD and | 2924 | e | | TIFF-FXExtensions are the fields being appended | 2925 | | | to those of 8.2.3 | 2926 +----+---------+-------------------------------------------------+ 2927 | 35.| E1.7.7.1| 5th sentence, clarified that the triplets | 2928 | e | | represent symbol instance | 2929 +----+---------+-------------------------------------------------+ 2930 +----+---------+-------------------------------------------------+ 2931 | 36.| E1.7.7.2| TIFF diagram, changed "Symbol & positions" to | 2932 | e | | "Position block", which is more encompassing | 2933 +----+---------+-------------------------------------------------+ 2934 | 37.| E1.7.7.2| terms of use items 2, 3 and 4, changed SHOULD to| 2935 | r | | SHALL, eliminating any ambiguity | 2936 +----+---------+-------------------------------------------------+ 2937 | 38.| Title | To reduce confusion with individual extensions, | 2938 | e | | changed to "TIFF-FX Extension Set 1" | 2939 +----+---------+-------------------------------------------------+ 2940 | 39.| all | Changed tag values and compression type for | 2941 | r | | TIFF-FXExtensions, MultiProfiles, SharedData, | 2942 | | | T88Options and JBIG2 from public to private | 2943 | | | values, avoiding potential Adobe constraints | 2944 +----+---------+-------------------------------------------------+ 2945 | 40.| E1.2.1.2| Current TIFF-FX Extensions table, Bit numbers 3 | 2946 | e | E1.6.2.3| and 4, and TIFF-FXExtensions, changed "bit 2 is | 2947 | | E1.7.2.3| set" or bit 2 SHALL be set to "bit 2 is | 2948 | | E1.6.8 | frequently set", consistent with dictionaries | 2949 | | E1.7.9 | being in locations other than Shared Data | 2950 +----+---------+-------------------------------------------------+