idnits 2.17.1 draft-ietf-fax-tiff-fx-extension1-00.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 59 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.) ** There are 4 instances of lines with control characters in the document. ** 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 219: '...l parameters. It SHALL be present for ...' RFC 2119 keyword, line 231: '...e data in the image IFD SHALL prevail....' RFC 2119 keyword, line 236: '...X extensions and SHALL be present when...' RFC 2119 keyword, line 239: '...Extensions field SHALL be placed withi...' RFC 2119 keyword, line 253: '...F-FX. This field SHALL only appear in ...' (136 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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, 12. 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 (November 2000) is 8563 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 2640 looks like a reference -- Missing reference section? 'RFCXXXX' on line 134 looks like a reference -- Missing reference section? 'TIFF' on line 2627 looks like a reference -- Missing reference section? 'TTN1' on line 760 looks like a reference -- Missing reference section? 'TTN2' on line 177 looks like a reference -- Missing reference section? 'REQ' on line 195 looks like a reference -- Missing reference section? '0' on line 2388 looks like a reference -- Missing reference section? '2' on line 792 looks like a reference -- Missing reference section? '1' on line 2117 looks like a reference -- Missing reference section? 'N-2' on line 782 looks like a reference -- Missing reference section? '3' on line 798 looks like a reference -- Missing reference section? 'N' on line 798 looks like a reference -- Missing reference section? 'TIFF-REG' on line 2626 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 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 November 17th, 2000 D. Abercrombie 4 draft-ietf-fax-tiff-fx-extension1-00.txt Xerox Corporation 5 W. Rucklidge 6 Intelligent Markets 7 R. Buckley 8 Xerox Corporation 9 November 2000 11 TIFF-FX Extensions 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 2000. All Rights Reserved. 43 Abstract 45 This document is an Internet draft for extensions to TIFF-FX 46 [RFC XXXX], extension set 1. 48 This draft describes extensions to RFC XXXX to enable new features or 49 conditions to TIFF-FX. The features are described by a set of 50 guidelines for all TIFF-FX extensions, and a set of 5 extension types 51 which enable: increased resolutions and image widths, expanding 52 Profile M from 3 layers to N layers, the use of shared data as a 53 general mechanism for sharing data across images and pages, a binary 54 profile for JBIG2 coding, and an extension to Profile M for JBIG2 and 55 "colour tag" coding. These extensions do not required modification of 56 existing TIFF-FX implementations. 58 The IETF has been notified of intellectual property rights claimed in 59 regard to some or all of the specification contained in this 60 document. For more information consult the online list of claimed 61 rights in . 63 Table of Contents 65 E1.1 INTRODUCTION -----------------------------------------------------4 66 E1.1.1 Scope--------------------------------------------------------4 67 E1.1.2. Overview of this draft--------------------------------------5 68 E1.2. TIFF Fields Required and Recommendations for All TIFF-FX 69 Extensions------------------------------------------------------6 70 E1.2.1. Required Fields---------------------------------------------6 71 E1.2.1.1. GlobalParametersIFD Field-------------------------------6 72 E1.2.2.1. TIFF-FXExtensions Field---------------------------------6 73 E1.2.2. Recommended Fields------------------------------------------8 74 E1.2.2.1. FaxProfile Field----------------------------------------8 75 E1.2.2.2. MultiProfiles Field-------------------------------------8 76 E1.3. TIFF-FX Extension 1 (E1): Resolution and ImageWidth Extensions--10 77 E1.4. TIFF-FX Extension 2 (E2): N-Layer Profile M Extension-----------14 78 E1.4.1. Introduction-----------------------------------------------14 79 E1.4.2. Section 8.1. Overview--------------------------------------15 80 E1.4.3. Section 8.1.1. MRC 3-layer model---------------------------15 81 E1.4.4. Section 8.1.2. A TIFF Representation for the MRC 3-layer 82 model------------------------------------------------------16 83 E1.4.5. Section 8.2.1. Baseline Fields-----------------------------18 84 E1.4.6. Section 8.2.2. Extension Fields----------------------------19 85 E1.4.7. Section 8.2.3. New Fields----------------------------------19 86 E1.4.8. Section 8.4. Rules and Requirements for Images-------------21 87 E1.4.9. Section 8.5. Profile M - MRC Fax Profile Summary-----------22 88 E1.5. TIFF-FX Extension 3 (E3): Shared Data Extension to Profile M----22 89 E1.5.1. Overview---------------------------------------------------22 90 E1.5.2. Required TIFF Fields---------------------------------------23 91 E1.5.3. Recommended Fields-----------------------------------------23 92 E1.5.4. Shared Data------------------------------------------------23 93 E1.5.4.1. SharedDataList-----------------------------------------26 94 E1.5.4.2. Representation of Shared Data in TIFF------------------27 95 E1.6. TIFF-FX Extension 4 (E4): Profile T - Lossy and Lossless JBIG2 96 Black-and-White Fax profile-------------------------------------28 97 E1.6.1. Overview---------------------------------------------------28 98 E1.6.2. Required TIFF Fields---------------------------------------30 99 E1.6.2.1. Baseline Fields----------------------------------------31 100 E1.6.2.2. Extension Fields---------------------------------------33 101 E1.6.2.3. New Fields---------------------------------------------33 102 E1.6.3. Recommended TIFF Fields------------------------------------33 103 E1.6.4. JBIG2 Shared Data------------------------------------------36 104 E1.6.4.1. The JBIG2 Shared Data----------------------------------36 105 E1.6.4.2. JBIG2 SharedDataMemory --------------------------------38 106 E1.6.5. The JBIG2 Image Strip--------------------------------------39 107 E1.6.5.1. Image Strip Format-------------------------------------41 108 E1.6.6. Representation of JBIG2 data in TIFF-----------------------42 109 E1.6.7. Rules and Requirements for Images--------------------------45 110 E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White 111 Fax profile Summary----------------------------------------46 113 E1.7. TIFF-FX Extension 5 (E5): JBIG2 Color Extension of Profile M----48 114 E1.7.1. Overview---------------------------------------------------48 115 E1.7.2. Required TIFF Fields---------------------------------------49 116 E1.7.2.1. Baseline Fields----------------------------------------49 117 E1.7.2.2. Extension Fields---------------------------------------49 118 E1.7.2.3. New Fields---------------------------------------------49 119 E1.7.3. Recommended TIFF Fields------------------------------------49 120 E1.7.4. JBIG2 Shared Data------------------------------------------50 121 E1.7.5. The Image Strip--------------------------------------------50 122 E1.7.6. Representation of JBIG2 data in TIFF-----------------------50 123 E1.7.7. Colour Tag (Color Symbol Compression-----------------------50 124 E1.7.7.1. Why use Colour Tag Compression-------------------------50 125 E1.7.7.2. Colour Tag Terms of Use in TIFF------------------------50 126 E1.7.8. Rules and Requirements for Images--------------------------52 127 E1.7.9. JBIG2 Extension of Profile M Summary-----------------------53 128 E1.8. Security Considerations-----------------------------------------56 129 E1.9. References------------------------------------------------------56 130 E1.10. Authors' Addresses---------------------------------------------57 131 Full Copyright Statement----------------------------------------------57 132 E1.1. Introduction 134 This document describes extensions to RFC XXXX [RFCXXXX], titled 135 "File Format for Internet Fax", also known as TIFF-FX, to augment the 136 features and capabilities for the data content and structure 137 generated by the current suite of ITU-T Recommendations for Group 3 138 facsimile. 140 These Recommendations and the TIFF fields described here support the 141 following new facsimile profile: 143 Profile T: TIFF-FX Extension 4: Black-and-White JBIG2 Extension - a 144 JBIG2 profile for binary only T.88|ISO/IEC 14492 [T.88] coded 145 data, built upon Profile M and the Shared Data extension to 146 Profile M (TIFF-FX Extension 5). 148 and create new extensions for the following new features: 150 TIFF-FX Extension 1 (E1): Resolution and ImageWidth Extensions - 151 extends the resolutions and image widths available for all 152 Profiles, with the exception of Profile S 153 TIFF-FX Extension 2 (E2): N-Layer Profile M Extension - extends 154 the 3-layer model into N layers 155 TIFF-FX Extension 3 (E3): Shared Data Extension to Profile M - 156 enables data to be shared among different images and pages; an 157 enabler for compression gains by using JBIG2 encoding 158 TIFF-FX Extension 5 (E5): JBIG2 Color Extension of Profile M - the 159 binary and color extension to Profile M which enables JBIG2 160 coding using T.88 (JBIG2,binary) and T.45 [T.45] "Run-length 161 Colour Encoding", required for colour tag extensions to JBIG2. 163 This extension specification of TIFF-FX for facsimile is known as 164 TIFF-FX Extensions 1. 166 E1.1.1 Scope 168 This document defines extensions to RFC XXXX, titled "File Format for 169 Internet Fax", known as TIFF-FX. These extensions add new 170 functionality to the profiles of TIFF-FX, with the exception of 171 Profile S, which is highly constrained. Most of these extensions can 172 be independently used; although some extensions may rely on others. 174 Unless otherwise noted, the primary reference is [RFC XXXX] "File 175 Format for Internet Fax" (TIFF-FX), which references the following as 176 it's primary references: the current TIFF specification [TIFF], 177 selected TIFF Technical Notes [TTN1, TTN2] and [T.30]. 179 E1.1.2 Overview of this draft 181 This Section gives an overview of TIFF-FX Extensions 1. Section E1.2 182 describes the requirements and recommendations associated with all 183 TIFF-FX extensions defined within this document. 184 Sections E1.3 through E1.7 describe the five new extensions. One 185 extension is a new profile, Profile T, and is located in Section 186 E1.4. This section also specifies the ITU-T compatible field values 187 (image parameters) for Profile T. 189 Throughout this document, Profiles, and section numbers without an 190 "E1" prefix, refer to [RFC XXXX]. 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [REQ]. 196 E1.2. TIFF Fields Required or Recommended for All TIFF-FX Extensions 198 E1.2.1. Required Fields 200 E1.2.1.1. GlobalParametersIFD Field 202 Status of the GlobalParametersIFD (GPIFD) is being changed from 203 Recommended to Required, for all extensions. This change is based on 204 the fact that more than one required extension, such as SharedData 205 and TIFF-FXExtensions, have global file implications (i.e. apply 206 across multiple pages or Primary IFDs), warranting their location 207 within the GPIFD. Accommodation of these required fields within the 208 GPIFD then requires change in status of the GPIFD to Required. 210 E1.2.1.1.1 Instructions 212 Remove the GlobalParametersIFD field from Section 2.2.4 "New TIFF 213 fields recommended for fax profiles" and append the following revised 214 definition to Sections 4.2.3, 5.2.3, 6.2.3, 7.2.3 and 8.2.3 "New 215 Fields": 217 GlobalParametersIFD (400) IFD or LONG 218 The GlobalParametersIFD, defined in Section 2.2.4, is an IFD 219 containing global parameters. It SHALL be present for all TIFF-FX 220 extensions. This reflects a modification to the Section 2.2.4 221 definition where GlobalParametersIFD is defined as a Recommended 222 field. The RFC XXXX GlobalParametersIFD definition is further 223 modified in that it is permitted to contain fields that are NOT 224 permitted in any other IFD. The new SharedData field is one such 225 field that is not permitted in any other IFD, see the Shared Data 226 Extension to Profile M below. 228 It is recommended that a TIFF writer place this field in the first 229 IFD, where a TIFF reader would find it quickly. If a conflict exists 230 between fields in the GlobalParametersIFD and in the image IFDs, then 231 the data in the image IFD SHALL prevail. 233 E1.2.1.2. TIFF-FXExtensions Field 235 The TIFF-FXExtensions field is introduced to be an identification 236 mechanism for all TIFF-FX extensions and SHALL be present when an 237 extension is used. The extensions are identified by bit value 238 assignment, accommodating use of more than one extensions at the same 239 time. The TIFF-FXExtensions field SHALL be placed within the 240 GlobalParametersIFD. 242 E1.2.1.2.1 Instructions 244 Add the TIFF-FXExtensions field to Sections 4.2.3, 5.2.3, 6.2.3, 245 7.2.3 and 8.2.3 "New Fields", as defined below: 247 TIFF-FXExtensions (407) LONG 248 Count = 1 249 [[The 407 tag value is subject to change]] 251 This field identifies the RFC XXXX extension(s) that apply. The field 252 accommodates the need to continually enhance the functionality of 253 TIFF-FX. This field SHALL only appear in the GlobalParametersIFD, it 254 is NOT permitted in any other IFD. It is required and SHALL be 255 present with use of any TIFF-FX extension. 257 A value of 1 in a bit location indicates the corresponding TIFF-FX 258 Extension is used. More than one bit set to 1 means more than 259 one TIFF-FX extension is used. 261 Current TIFF-FX Extensions: 262 +------+---------+---------------------------------------------------+ 263 | Bit |Extension| Meaning | 264 |number| number | | 265 +------+-------------------------------------------------------------+ 266 | 0 | 1 | Resolution and ImageWidth Extensions | 267 | | | If bit 0 is 1, then any of the X and YResolutions | 268 | | | from 300 x 600 to 1200 x 1200 pixels per | 269 | | | resolution unit, and the corresponding ImageWidths| 270 | | | MAY be used. | 271 +------+---------+---------------------------------------------------+ 272 | 1 | 2 | N-Layer Profile M Extension | 273 | | | If bit 1 is 1, then the provision for more than | 274 | | | three MRC layers is used. | 275 +------+---------+---------------------------------------------------+ 276 | 2 | 3 | Shared Data Extension to Profile M | 277 | | | If bit 2 is 1, then Profile M and Shared Data | 278 | | | provisions are used. | 279 +------+---------+---------------------------------------------------+ 280 | 3 | 4 | Profile T - Black-and-White JBIG2 Extension | 281 | | | If bit 3 is 1, then Black-and-White JBIG2 coding | 282 | | | is used (i.e. Compression = 12, TIFF-FXExtensions | 283 | | | bit 2 is set and bi-level constrained MRC model | 284 | | | is applied). | 285 +------+---------+---------------------------------------------------+ 286 | 4 | 5 | JBIG2 Extension of Profile M | 287 | | | If bit 4 is 1, JBIG2 is used for Mask layer coding| 288 | | | and colour tags may be used for foreground layers | 289 | | | (i.e. Compression = 12 and TIFF-FXExtensions bit 2| 290 | | | is set). | 291 +------+---------+---------------------------------------------------+ 293 Default = 0, no extensions being used. 295 E1.2.2. Recommended Fields 297 E1.2.2.1. FaxProfile Field 299 The FaxProfile field is revised for two reasons: 1) acknowledge the 300 new MultiProfiles field, specified below, and make provisions for 301 association of the two fields. 2) update the current profile list to 302 include the new Profile T, specified later in this document. 304 E1.2.2.1.1 Instructions 306 Replace the existing FaxProfile field in Section 2.2.4 "New TIFF 307 fields recommended for fax profiles" with the following: 309 FaxProfile(402) = 0 - 7, 255. BYTE 310 The profile that applies to this file; a profile is a subset of the 311 full set of permitted fields and field values of TIFF-FX and it's 312 extensions. 313 This field is used to indicate the profile used within the file when 314 only one profile is used. The MultiProfiles field is used when a 315 TIFF-FX extension or more than one profile is used within the file. 316 A FaxProfile value of 255 (X'FF') indicates that the MultiProfiles 317 field is used. 318 The currently defined FaxProfile values associated with a profile 319 are: 320 0: does not conform to a profile defined for TIFF for facsimile 321 1: minimal black & white lossless, Profile S 322 2: extended black & white lossless, Profile F 323 3: lossless JBIG black & white, Profile J 324 4: lossy color and grayscale, Profile C 325 5: lossless color and grayscale, Profile L 326 6: Mixed Raster Content, Profile M 327 7: lossy and lossless JBIG2 black & white, Profile T 328 255: MultiProfiles field, indicates the profiles and/or profile(s) 329 plus extension(s) used in the file 331 E1.2.2.2. MultiProfiles Field 333 This field is used to indicate when extension(s) or two or 334 more different profiles are used within a single file. RFC XXXX makes 335 no statement with regard to the appropriateness of using encodings of 336 two or more different profiles within a file. There is no question as 337 to the value of such a provision. This is illustrated by an example 338 where the first ten black-and-white text pages of a fifteen page 339 document are processed using Profile F MMR (G4) encoding while the 340 last five color pages are processed using Profile C JPEG encoding. 341 The existing FaxProfile field is used within the file to signal one 342 encoding profile. In response to requests received from implementors, 343 this extension introduces the MultiProfiles field, to be used when 344 and extended profile or more than one profile is used within a file. 346 Files containing extension(s) or more that one profile SHOULD contain 347 the MultiProfiles field, identifying the profiles or extension(s) 348 present. When present, the MultiProfiles field SHALL reside within 349 the GlobalParameterIFD. The number of profiles present within a file 350 is ambiguous without the MultiProfiles or FaxProfile field. It is 351 highly likely that readers of files without the MultiProfiles or 352 FaxProfile will assume that only one profile is present, the profile 353 that is consistent with the Compression type and other relevant 354 values that are present within the first IFD. Such readers may 355 experience difficulty if different Compression types and/or other 356 relevant parameters are encountered in subsequent IFDs within the 357 file. 359 E1.2.2.2.1 Instructions 361 a) Append the new MultiProfiles field, specified below, to Section 2.2.4 362 "New TIFF fields recommended for fax profiles" following the ModeNumber 363 field: 365 MultiProfiles(406) LONG 366 Count = N 367 [[The 406 tag value is subject to change]] 369 The extended profile (i.e. profile plus extension) or more than one 370 profiles that apply to this file; a profile is a subset of the 371 full set of permitted fields and field values of TIFF for facsimile. 372 This field is used when an extended profile or more than one 373 profiles are used within the file. This field SHALL only be present 374 when the FaxProfile field is absent or has a value of 255 (X'FF'). 375 A value of 1 in more than one bit location indicates the 376 Corresponding profiles or profile(s) plus extension(s) that are 377 used. The currently defined bits are: 379 MultiProfiles[0]: 380 Bit 0: minimal black & white lossless, Profile S 381 Bit 1: extended black & white lossless, Profile F 382 Bit 2: lossless JBIG black & white, Profile J 383 Bit 3: lossy color and grayscale, Profile C 384 Bit 4: lossless color and grayscale, Profile L 385 Bit 5: Mixed Raster Content, Profile M 386 Bit 6: lossy and lossless JBIG2 black & white, Profile T 387 Bit 7: Extension 1 (E1), resolution and imagewidth extensions 388 Bit 8: Extension 2 (E2), N-Layer Profile M extension 389 Bit 9: Extension 3 (E3), shared data extension to Profile M 390 Bit 10: Extension 5 (E5), JBIG2 extension of Profile M 391 Bits 11-31: reserved for future use. 393 WARNING: Files containing extensions or more that one profile 394 "SHOULD" contain the MultiProfiles field, identifying the profiles 396 present. See the description from the second paragraph of Section 397 E1.2.2.2. 399 NOTE: count (N) > 1 should be used to accommodate future 400 expansion beyond 32 bits. 402 b) Append the new 4.5.7 "Multiple Profiles within a file" section, 403 specified below, to Section 4.5 "Implementation Warnings" following 404 Section 4.5.6: 406 4.5.7 Multiple Profiles within a file 407 Files containing more that one profile "SHOULD" contain the 408 MultiProfiles field, identifying the profiles present. The number 409 of profiles present within a file is ambiguous without the 410 MultiProfiles or FaxProfile field. It is highly likely that 411 readers of files without the MultiProfiles or FaxProfile will 412 assume that only one profile is present, the profile that is 413 consistent with the Compression type and other relevant values that 414 are present within the first IFD. Such readers may experience 415 difficulty if different Compression types and/or other relevant 416 parameters are encountered in subsequent IFDs within the file. 418 E1.3. TIFF-FX Extension 1 (E1): Resolution and ImageWidth Extensions 420 The ITU-T has approved a new set of X and YResolutions, along with 421 corresponding image widths (i.e. page widths). This extension makes 422 provisions for using these extended resolutions. 424 The TIFF-FXExtensions field, below, SHALL be present when this extension 425 is used. 427 TIFF-FXExtensions (407) bit 0 is 1 LONG 428 See Section E1.2.1.2. 430 E1.3.1 Instructions 432 a) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields 433 required for all fax profiles" XResolution field with the following: 435 The ITU-T Recommendations for facsimile specify a small number 436 of horizontal resolutions: 100, 200, 300, 400, 600, 1200 pixels per 437 inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per 438 inch). 440 b) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields 441 required for all fax profiles" YResolution field with the following: 443 The ITU-T Recommendations for facsimile specify a small number of 444 vertical resolutions: 100, 200, 300, 400, 600, 800, 1200 pixels per 445 inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 446 pixels per inch). 448 c) Append the following five rows to the resolution table that follows 449 the YResolution field in Section 2.2.2 "Additional TIFF fields required 450 for all fax profiles": 452 +--------------+--------------+--------------+--------------+ 453 | 300 | | 600 | | 454 +--------------+--------------+--------------+--------------+ 455 | 600 | | 600 | | 456 +--------------+--------------+--------------+--------------+ 457 | 400 | | 800 | | 458 +--------------+--------------+--------------+--------------+ 459 | 600 | | 1200 | | 460 +--------------+--------------+--------------+--------------+ 461 | 1200 | | 1200 | | 462 +--------------+--------------+--------------+--------------+ 464 d) Replace the ImageWidth field in Section 4.2.1. "Baseline fields" with 465 the following: 467 ImageWidth(256) SHORT or LONG 468 RequiredByTIFFBaseline 469 This profile supports the following fixed page widths: 1728, 2592, 470 3456, 5184, 10368 (corresponding to North American Letter and Legal, 471 ISO A4 paper sizes), 2048, 3072, 4096, 6144, 12288 (corresponding to 472 ISO B4 paper size), and 2432, 3648, 4864, 7296, 14592 (corresponding 473 to ISO A3 paper size). 474 No default; must be specified 476 NOTE: Historical TIFF-F did not include support for the following 477 widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096, 478 4864, 5184, 6144, 7296, 10368, 12288 and 14592. Historical TIFF-F 479 documents also included the following values related to A5 and A6 480 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 481 documents are no longer supported in Group 3 facsimile, so the 482 related width values are now obsolete. See section 4.5.2 for more 483 information on inch/metric equivalencies and other implementation 484 details. 486 e) Replace the XResolution field in Section 4.2.1. "Baseline fields" 487 with the following: 489 XResolution(282) = 200, 204, 300, 400, 408, 600, 1200 RATIONAL 490 RequiredByTIFFBaseline 491 The horizontal resolution of the image is expressed in pixels per 492 resolution unit. In pixels/inch, the allowed values are: 200, 204, 493 300, 400, 408, 600 and 1200. See Section 2.2.2 for inch-metric 494 equivalency. 495 No default, must be specified 497 NOTE: The values of 200 and 408, 600 and 1200 have been added to the 498 Historical TIFF-F values, for consistency with [T.30]. Some existing 499 TIFF-F implementations may also support values of 80 pixels/cm, which 500 is equivalent to 204 pixels per inch. See section 4.5.2 for 501 information on implementation details. 503 f) Replace the YResolution field in Section 4.2.1. "Baseline fields" 504 with the following: 506 YResolution(283) = 98, 100, 196, 200, 300, 391, 400, RATIONAL 507 600, 800 and 1200 508 RequiredByTIFFBaseline 509 The vertical resolution of the image is expressed in pixels per 510 resolution unit. In pixels/inch, the allowed values are: 98, 100, 511 196, 200, 300, 391, 400, 600, 800 and 1200 pixels/inch. 512 See Section 2.2.2 for inch-metric equivalency. 513 No default, must be specified 515 NOTE: The values of 100, 200, 391, 600, 800 and 1200 have been added 516 to the historical TIFF-F values, for consistency with [T.30]. Some 517 existing TIFF-F implementations may also support values of 77 and 518 38.5 (cm), which are equivalent to 196 and 98 pixels per inch 519 respectively. See Section 4.5.2 for more information on 520 implementation details. 522 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 523 are legal. The following table gives the legal combinations and 524 corresponding paper size [T.30]. 526 g) Replace the Resolution and ImageWidth table that follows YResolution 527 in Section 4.2.1. "Baseline fields" with the following: 529 +--------------------------------+---------------------------+ 530 | XResolution x YResolution | ImageWidth | 531 +--------------------------------+---------+--------+--------+ 532 | 200x100, 204x98 | | | | 533 | 200x200, 204x196 | 1728 | 2048 | 2432 | 534 | 204x391 | | | | 535 +--------------------------------+---------+--------+--------+ 536 | 300 x 300, 300 x 600 | 2592 | 3072 | 3648 | 537 +--------------------------------+---------+--------+--------+ 538 | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | 539 | 400x800 | | | | 540 +--------------------------------+---------+--------+--------+ 541 +--------------------------------+---------+--------+--------+ 542 | 600 x 600, 600 x 1200 | 5184 | 6144 | 7296 | 543 +--------------------------------+---------+--------+--------+ 544 | 1200 x 1200 | 10368 | 12288 | 14592 | 545 +--------------------------------+---------+--------+--------+ 546 |Letter,A4| B4 | A3 | 547 | Legal | | | 548 +---------+--------+--------+ 549 | Paper Size | 550 +---------------------------+ 552 h) Replace the ImageWidth field in Section 6.2.1. "Baseline Fields" with 553 the following: 555 ImageWidth(256). SHORT or LONG 556 This profile supports the following fixed page widths: 864, 1024, 557 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864, 5184, 558 6144, 7296, 10368, 12288, 14592. 560 i) Replace the XResolution and YResolution fields in Section 6.2.1. 561 "Baseline Fields" with the following: 563 XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL 564 YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL 565 The resolution of the image is expressed in pixels per resolution 566 unit. In pixels per inch, allowed XResolution values are: 100, 200, 567 300, 400, 600 and 1200. The base color fax profile requires the 568 pixels to be square, hence YResolution SHALL equal XResolution. Base 569 resolution is 200 pixels per inch and SHALL be supported by all 570 implementations of this profile. 572 NOTE: The functional equivalence of inch-based and metric-based 573 resolutions is maintained, per Annex E.6.5 in [T.4]. See table in 574 Sec. 2.2.2. 576 NOTE: Not all combinations of XResolution, YResolution and ImageWidth 577 are legal. The following table gives the legal combinations for inch- 578 based resolutions and the corresponding paper sizes [T.30]. 580 j) Replace the Resolution and ImageWidth table that follows YResolution 581 in Section 6.2.1. "Baseline fields" with the following: 583 +--------------------------------+---------------------------+ 584 | XResolution x YResolution | ImageWidth | 585 +--------------------------------+---------------------------+ 586 | 100 x 100 | 864 | 1024 | 1216 | 587 +--------------------------------+---------------------------+ 588 | 200 x 200 | 1728 | 2048 | 2432 | 589 +--------------------------------+---------------------------+ 590 +--------------------------------+---------------------------+ 591 | 300 x 300 | 2592 | 3072 | 3648 | 592 +--------------------------------+---------------------------+ 593 | 400 x 400 | 3456 | 4096 | 4864 | 594 +--------------------------------+---------------------------+ 595 | 600 x 600 | 5184 | 6144 | 7296 | 596 +--------------+-----------------+---------+--------+--------+ 597 | 1200 x 1200 | 10368 | 12288 | 14592 | 598 +--------------+-----------------+---------+--------+--------+ 599 |Letter,A4| B4 | A3 | 600 | Legal | | | 601 +---------------------------+ 602 | Paper Size | 603 +---------------------------+ 605 k) Replace the XResolution and YResolution fields in Section 7.2.1. 606 "Baseline Fields" with the following: 608 XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL 609 YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL 610 The resolution of the image is expressed in pixels per resolution 611 unit. In pixels per inch, allowed XResolution values are: 100, 200, 612 300, 400, 600 and 1200. The lossless color fax profile requires the 613 pixels to be square, hence YResolution SHALL equal XResolution. Base 614 resolution is 200 pixels per inch. 616 E1.4. TIFF-FX Extension 2 (E2): N-Layer Profile M Extension 618 E1.4.1 Introduction 620 This section tracks [T.44] by defining the N-layer extension to the 621 3-layer Mixed Raster Content profile or Profile M of TIFF for 622 facsimile. By applying the appropriate black-and-white, bi-level, 623 constraints from Extension 4 (Section E1.6), the N-layer model and 624 rules of this extension may also be applied to Profile T. 626 Often times, the contents of a page can be broken up into more 627 components than a 3-layer representation would allow. For instance, a 628 complex magazine article may do well to have: 629 - a low resolution background image, for a low variance picture. 630 Let's say this is 100 dpi, and is color. 631 - a high resolution mask layer, for the large amount of text and 632 lines. Let's say this is 400 dpi (and binary). 633 - a low resolution foreground image, for the text and line color. 634 Let's say this is 100 dpi, and is color. 635 - several medium resolution, for the pictures that are scattered 636 throughout the page. Let's say they are 200 dpi, and are 637 color. Of these, several may be odd shapes (non-rectangular), and 638 would require a separate mask to select their regions. 640 Expanding the 3-layer MRC model to N-layers allows for greater 641 complexity of a page content, with the same simplicity in the 642 existing model. 644 This N-layer Profile M Extension is specified by defining specific 645 modifications to the text of Profile M. As a result of the 646 specification method, this extension should be read in conjunction 647 with Profile M. 649 E1.4.2. Section 8.1. Overview 651 The objective is to change 3-layer to N-layer references. 653 2nd paragraph - replace the 3rd and 4th sentences with the following: 655 By itself, MRC does not define any new coding methods or 656 resolutions. Instead it defines an N-layer (where N is a positive 657 integer) image model for structuring and combining the scanned image 658 data. The MRC N-layer model has been applied here using the TIFF 659 format to yield a data structure which differs from [T.44] though it 660 applies the same coding methods, uses the same compressed image data 661 streams and is consistent with the TIFF principle of a single IFD per 662 image. 664 E1.4.3. Section 8.1.1. MRC 3-layer model 666 The objective is to change 3-layer to N-layer references, specify the 667 presence of multiple foreground and mask layers, distinguish role of 668 Primary Mask relative to secondary mask layers and their 669 interactions: 671 a) Title and 1st paragraph - replace the title and paragraph with 672 the following: 674 8.1.1. MRC N-layer model 676 The N layers of the MRC model are Background (layer 1), Mask (even 677 numbered layers such as 2, 4, 6,..., N-1, where N is odd) and 678 Foreground (odd numbered layers such as 3, 5, 7,..., N, where N is 679 odd) pairs. The Mask and Foreground layers occur in Mask and 680 Foreground pairs (i.e. layers 2 & 3, 4 & 5, 6 & 7, ..., N-1 & N 681 pairs, where N is odd). The odd numbered layers (Background and 682 Foreground) are typically encoded with multi-level coders while the 683 even numbered layers (Mask) are encoded with bi-level coders. Each 684 layer may appear only once on a page and is coded independently of 685 the other layers. 687 The final image is obtained by using the Mask layers to determine 688 which of the Foreground layer pixels are rendered over the Background 689 layer or composite of layers below the Mask. When the Mask layer 690 pixel value is 1, the corresponding pixel from the corresponding 691 Foreground layer is selected; when it is 0, the corresponding pixel 692 from the Background layer or composite of layers below the Mask is 693 selected. 694 Details are given in the Introduction of this section, and in Annex A 695 of [T.44]. 697 b) 4th paragraph - replace with the following: 699 Not all pages, and not all parts of a page, require 3 or more layers. 700 If a page consists of only one layer, then that layer is the primary 701 image whether it is a Background, Mask, or Foreground layer. If 702 there is more than one layer, then the Primary Mask (layer 2) SHALL 703 be one of the layers, in which case it is the primary image. In all 704 cases, the primary image SHALL be page size. 706 c) 5th paragraph, 1st sentence - replace with the following: 708 MRC [T.44] allows a page to be transmitted as a series of stripes 709 with each stripe consisting of 1, 2, 3 or N layers. 711 d) 6th paragraph - replace with the following: 713 Furthermore, color fax also requires the spatial resolutions of 714 Background and Foreground images to be legal fax values that are 715 also integer factors of the Primary Mask image resolution. For 716 example, if the Primary Mask Layer resolution is 400 pixels per inch, 717 then allowed resolutions for the Foreground, Background and secondary 718 Mask (layers 4, 6, ..., N-1, where N is odd) layers are 100, 200 or 719 400 pixels per inch; if the Primary Mask is at 300 pixels per inch, 720 then allowed values are 100 and 300. The Foreground, Background and 721 secondary Mask layer resolutions can be set independent of each 722 other. 724 E1.4.4. Section 8.1.2. A TIFF Representation for the MRC 3-layer model 726 The objective is to change 3-layer to N-layer references, specify 727 multiple foreground and mask layers, define their IFD and SubIFD 728 relationships and structural layout: 730 a) Title and 1st paragraph - replace the title and paragraph with 731 the following: 733 8.1.2. A TIFF Representation for the MRC N-layer model 735 In the TIFF representation of the N-layer MRC model, each page is 736 represented by a single IFD, called the Primary IFD. The nextIFD 737 offset associated with a Primary IFD SHALL point to the Primary IFD 738 of the next page. If the page consists of a single layer, then the 739 Primary IFD represents that layer. If more than one layer is present, 740 the Primary IFD represents the Primary Mask layer and the other 741 layers are represented by a set of child IFDs that are referenced 742 through the SubIFD extension field [TTN1] of the Primary IFD. To 743 distinguish MRC-specific SubIFDs from other SubIFDs, the 744 NewSubFileType field SHALL have Bit 4 ON, indicating an MRC-related 745 IFD. A new ImageLayer field is also introduced that consists of two 746 values that identify the layer (Background [layer 1], Mask [layer 2, 747 4, 6, ..., N-1, where N is odd], or Foreground [layer 3, 5, 7, ..., 748 N, where N is odd]) and the order within the layer (first, second, 749 ...image of the layer); see Section 8.2.3. 751 b) 5th paragraph, last sentence - replace the sentence with the 752 following: 754 In all cases, if the Primary Mask layer exists, it SHALL be 755 represented by a single IFD and a single set of coding parameters. 757 c) 6th paragraph, first 3 sentences - replace the sentences with the 758 following: 760 The use of SubIFDs to store child IFDs is described in [TTN1]. When 761 a Mask is the primary image, the Background and Foreground layer 762 images are represented with child IFDs that are referenced by the 763 SubIFDs field in the Primary IFD. There are many possible ways to 764 represent the Background and Foreground layer images: (1) the 765 SubIFD field of the Primary IFD is an array of pointers to all 766 child image IFDs, one entry per child image; (2) the SubIFD field is 767 a single pointer to a linked list of all child image IFDs; (3) the 768 SubIFD field is an array of N-1 pointers, where the first pointer is 769 to a linked list of all Background layer (layer 1) image IFDs, the 770 second pointer is to a linked list of all the first Foreground layer 771 (layer 3) image IFDs, the third pointer is to a linked list of all 772 the second Mask layer (layer 4) IFDs, the N-1 pointer is to a linked 773 list of all the Nth layer IFDs. 775 d) IFD - SubIFD tree diagram that follows the 6th paragraph - replace 776 the tree diagram with the following: 778 (nextIFD) 779 PRIMARY IFD PAGE 0 ----------------------> PRIMARY IFD PAGE 1--> ... 780 ImageLayer = [2,1] 781 NewSubFileType = 18 782 SubIFD[0] ------------ SubIFD[1] ---- ... --- SubIFD[N-2] 783 | | | 784 V V V 785 Child IFD Child IFD Child IFD 786 ImageLayer = [1,1] ImageLayer = [3,1] ImageLayer = [N,1] 787 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 788 | | | 789 |(nextIFD) |(nextIFD) |(nextIFD) 790 V V V 791 Child IFD Child IFD Child IFD 792 ImageLayer = [1,2] ImageLayer = [3,2] ImageLayer = [N,2] 793 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 794 | | | 795 |(nextIFD) |(nextIFD) |(nextIFD) 796 V V V 797 Child IFD Child IFD Child IFD 798 ImageLayer = [1,3] ImageLayer = [3,3] ImageLayer = [N,3] 799 NewSubFileType = 16 NewSubFileType = 16 NewSubFileType =16 800 | | | 801 |(nextIFD) |(nextIFD) |(nextIFD) 802 V V V 803 0 0 0 805 e) Last paragraph, last sentence - replace the sentence with the 806 following: 808 If the image data is not ITU L*a*b*, the ImageBaseColor is 809 interpreted as 8-bit ITU L*a*b*; see Section 8.2.3. 811 E1.4.5. Section 8.2.1. Baseline Fields 813 The objective is to reflect presence of the multiple foreground and 814 mask layers and the distinct Primary Mask layer in some fields and 815 specify the impact of having no image data in the multiple mask and 816 foreground layer pairs. 818 a) ImageWidth - replace with the following: 820 ImageWidth(256). SHORT or LONG 821 Primary images define the page widths, which SHALL be limited to the 822 same set of widths as defined in Profile C, the base color profile; 823 see Section 6.2.1. In Profile M, the width of an image (i.e. 824 Foreground, Background, or Mask layer) in the coded data stream may 825 be less than the page width, unless the Background, Foreground or 826 Mask is the primary image (i.e. the Primary IFD), in which case the 827 width of the coded data stream is the page width. The ImageWidth 828 field SHALL always store the actual width of the coded data. 830 b) Compression - replace the first sentence with the following: 832 For Mask layers, see Sections 4.2.1 and 5.2.1 834 c) PhotometricInterpretation - replace with the following: 836 PhotometricInterpretation(262) = 0, 2, 5, 10. SHORT 837 For Mask layers, 0. For Foreground and Background layers, see 838 Sections 6.2.1 and 7.2.1. 840 d) StripByteCounts - replace the field with the following: 842 StripByteCounts(279) SHORT or LONG 843 In Profile M, it is permissible for the StripByteCounts value for a 844 given strip, other than one corresponding to a mask, to have 845 a zero entry. This means there is no encoded image data corresponding 846 to that strip. Instead, for the Foreground or Background layers the 847 current default image color should be used for the strip. The 848 standard default image colors are black for the Foreground layers and 849 White for the Background layer. The ImageBaseColor field can be used 850 to specify other default image colors, see 8.2.3. 852 e) YResolution - replace the last sentence with the following: 854 The resolution of Mask, Background and Foreground layers SHALL each 855 be an integer factor of the Primary image, which is the Primary Mask 856 layer, when it is present; see Section 8.4. 858 E1.4.6. Section 8.2.2. Extension Fields 860 The objective is to reflect presence of the multiple mask layers. 862 a) T6Options - replace the field with the following: 864 T6Options(293) = 0. SHORT 865 For Mask layers, see Section 4.2.2. 867 E1.4.7. Section 8.2.3. New Fields 869 The objective is to reflect presence of the multiple mask and 870 foreground layers, their impact on the ImageLayer field and resulting 871 extension of the ImageLayer[0] field values. The newly required TIFF- 872 FXExtension field and minimal bit setting are specified. 874 a) T82Options - replace the field with the following: 876 T82Options(435) LONG 877 For Mask layers, see Section 5.2.3. 879 b) ImageLayer - replace the field, descriptive paragraph and 880 ImageLayer[0]field with the following: 882 ImageLayer (34732). LONG 883 Count = 2 884 Image layers are defined such that layer 1 is the Background layer. 885 Layers above layer 1 are arranged in mask (i.e. even numbered layers) 886 and foreground (i.e. odd numbered layers) pairs. The mask selects 887 pixels from the associated foreground that will be rendered on top of 888 the Background or composite of layers below the mask. For example, 889 layer 2 (i.e. the Primary Mask or first mask layer) selects pixels 890 from layer 3 (i.e. the first foreground layer) that will be rendered 891 on top of the Background. Layer 4 (i.e. the second mask layer) 892 selects pixels from layer 5 (i.e. the second foreground layer) that 893 will be rendered on top of the composite of layers 1through 3 below. 894 The ImageLayer field contains two values, describing the layer to 895 which the image belongs and the order in which it is imaged. 897 ImageLayer[0] = 1, 2, 3, ..., N. 898 1: Image is a Background image, i.e., the image that will appear 899 whenever the Primary Mask contains a value of 0. Background 900 images typically contain low-resolution, continuous-tone 901 imagery. 902 2: Image is the Primary Mask layer. In MRC, if more than one layer 903 is present then the Primary Mask layer (layer 2) is present, it 904 SHALL be the Primary IFD and be full page in extent. 905 3: Image is the first Foreground image, i.e. the image that will 906 be rendered on top of the lower layer (layer 1) whenever the 907 Primary Mask contains a value of 1. The Foreground image 908 generally defines the color of text or lines, but may also 909 contain high-resolution imagery. 910 4: Image is the second Mask layer (layer 4). 911 5: Image is the second Foreground image (layer 5), i.e. the image 912 that will be rendered on top of the composite of layers 1 913 through 3 below whenever the second Mask contains a value of 1. 914 N-1: If N is odd, then layer N-1 is the (N-1)/2-th Mask layer. 915 N: If N is odd, then layer N is the (N-1)/2-th Foreground image, 916 i.e. the image that will be rendered on top of the composite of 917 layers 1 through N-2 below whenever the (N-1)/2 Mask contains a 918 value of 1. 919 If N is even, then layer N is the N/2-th Mask layer, which will 920 rendered as black on top of the composite layers of 1 through 921 N-1, whenever the image contains a value of 1. 923 c) TIFF-FX extensions - append the following field at the end of the 924 section: 926 TIFF-FXExtensions (407) bit 1 is 1 LONG 927 See Section E1.2.1.2. 929 E1.4.8. Section 8.4. Rules and Requirements for Images 931 The objective is to reflect presence and impact of the multiple mask 932 and Foreground layers and the Primary IFD role in rules 1, 4, 8 and 933 9. 935 a) Replace the introductory sentence, along with rules 1, 4, 8 and 9 936 with the following: 938 Profile M defines a fundamental set of rules for images in the N- 939 layer representation. These rules, with the appropriate black-and- 940 white (bi-level) constraints, also apply to Profile T. 942 1. If more than one layer exists, then a binary Mask layer SHALL 943 be present and the first mask layer SHALL be the primary image. 944 Mask layers SHALL support the binary data representations defined 945 in Section 3 and MAY support the binary data representations 946 defined in Sections 4, 5 or E1.6. PhotometricInterpretation SHALL 947 be set to "0". If only one layer exists, then the image 948 corresponding to that layer is the primary image. 950 4. Images other than the Primary Image (i.e. Primary IFD) MAY 951 optionally cover only a portion of the strip or page. 953 8. In MRC Internet Fax, each layer is transmitted as a sequence of 954 strips. If the page consists of a single layer, then all strips 955 SHALL be stored in the single Primary IFD. In this case, coding 956 parameters SHALL NOT change between strips. If the page consists 957 of more than one layer, then all strips of the Primary Mask layer 958 SHALL be stored in the single Primary IFD. All strips of the 959 Foreground/Background/secondary mask layers SHALL be stored in 960 separate IFDs, referenced by the Primary IFD's SubIFD field, 961 containing an ImageLayer field with ImageLayer[0] identifying 962 Background (layer 1), Foreground layers (layer 3, 5, 7, ..., N, 963 where N is odd) or mask layers (layer 2, 4, 6, ..., N-1, where N 964 is odd), and Imagelayer[1] identifying order in which images 965 within a single layer are to be imaged. The TIFF XPosition and 966 Yposition fields are used to indicate the placement of these 967 images with respect to the primary image. 969 9. When the Primary Mask image is present, the resolution of 970 Background, Foreground and secondary mask images SHALL each be an 971 integer factor of the Primary Mask image. For example, if the 972 Primary Mask image is 400pixels/inch, then the Background, 973 Foreground or secondary mask images may be at 400 pixels/inch 974 (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). 976 E1.4.9. Section 8.5. Profile M - MRC Fax Profile Summary 978 The objective is to identify the secondary mask layers as being among 979 the data blocks pointed to by the SubIFD offsets, reflect the 980 required status of the GlobalParametersIFD, append the required TIFF- 981 FXExtensions field to the table and callout the need to activate the 982 N-Layer Profile M Extension bit. 984 a) Revise the following Section 8.5 table entries to read as shown: 986 +------------------+-----------------------------------------+ 987 | SubIFDs | : byte offset to FG, BG, | 988 | | or secondary mask IFDs | 989 +------------------+-----------------------------------------+ 991 +------------------+-----------------------------------------+ 992 | GlobalParameters | IFD: global parameters IFD | 993 | IFD** | | 994 +------------------+-----------------------------------------+ 996 b) Append the following to Section 8.5 table: 998 +------------------+-----------------------------------------+ 999 | TIFF-FXExtensions| n: extension(s) identification number, | 1000 | ** | bit 1 for N-Layer Profile M Extension | 1001 | | SHALL be among the set bits | 1002 +------------------+-----------------------------------------+ 1004 E1.5. TIFF-FX Extension 3 (E3): Shared Data Extension to Profile M 1006 This section defines the Shared Data extension to Profile M. Shared 1007 Data accommodate a single representation of reusable resources, 1008 such as image data or encoding tables, that appear or are used 1009 multiple times within a file. Most importantly, it provides a 1010 mechanism for access to the redundant resources by multiple 1011 components (i.e. sharing) within the encoding process. The sharing of 1012 resources is a new encoding provision defined in ITU-T Rec. T.44 1013 Annex B [T.44Amd1]. Use of Shared Data is restricted to the MRC 1014 structure defined in Profile M or M with N layers, as defined 1015 in this document. Rational for Shared Data in Profile M only is 1016 traceable to T.44 Annex B [T.44Amd1]. 1018 E1.5.1. Overview 1020 Many pages and/or documents have repeating components such as shapes 1021 or symbols, words, images and meta-data (i.e. Huffman Tables). 1022 This is especially true for images of text, where the repeating 1023 shapes are the characters themselves. The SharedData field is 1024 defined below to leverage the redundancy of these repeating 1025 components by storing each component once, and then referring to each 1026 stored component as many times as possible. Reference to a resource 1027 must be made with an explicit and unique reference to the Shared 1028 Data, from within the data stream that uses it (the referencing data 1029 stream). 1031 E1.5.2. Required TIFF Fields 1033 This section describes the TIFF fields required, in addition to 1034 those in Section 8.2, to represent Shared Data. 1036 E1.5.2.1. Baseline Fields 1037 See Section 8.2.1. 1039 E1.5.2.2. Extension Fields 1040 See Section 8.2.2. 1042 E1.5.2.3. New Fields 1043 Append the following to the fields of 8.2.3: 1045 GlobalParametersIFD (400) IFD or LONG 1046 See Section E1.2.1 1048 TIFF-FXExtensions (407) bit 2 SHALL be 1 LONG 1049 See Section E1.2.1 1051 SharedData (437) LONG 1052 [[The 437 tag value is subject to change]] 1053 See Section E1.5.4. 1055 E1.5.3. Recommended TIFF Fields 1057 See Sections 8.3, with exception of GlobalParametersIFD. 1059 E1.5.4 Shared Data 1061 The following new field is defined: 1063 SharedData (437) LONG 1064 Count = 1 1065 [[The 437 tag value is subject to change]] 1067 The SharedData field contains the file offset (E), in bytes, from the 1068 beginning of the file of the first Shared Data Table. Each Shared 1069 Data Table contains a count of the number of Shared Data Entries that 1070 physically exist in the table (whether filled with a shared data or 1071 not) , the Shared Data Entries themselves, and the file location of 1072 the next Shared Data Table (if any). 1074 There can be as many Shared Data Tables as necessary to describe the 1075 number of shared data items, but there SHALL be only one SharedData 1076 field in a file, and it SHALL be in the GlobalParametersIFD 1077 (recommended to be in the first IFD in the file). The SharedData 1078 field is required when sharing data and SHALL be present. A 1079 SharedData value of zero "0" means that there are no Shared Data 1080 Tables present and that no data is currently being shared. 1082 Each Shared Data Table consists of a 2-byte count of the number of 1083 physical entries, a sequence of 16-byte shared data entries, and a 4- 1084 byte offset to the next Shared Data Table. The last shared data 1085 table has a "next table file offset" of 0. 1087 NOTE: In all the tables shown below, all multi-byte quantities are 1088 written/read in the endianness convention established by the TIFF 1089 file ("II" or "MM"). 1091 Shared Data Table 1092 +-----+--------------+-----+---------------------------------------+ 1093 |Bytes| Byte offsets |Type | Description | 1094 +-----+--------------+-----+---------------------------------------+ 1095 | 2 | E - E+1 |SHORT| Items in table - (i) The number of | 1096 | | | | shared data entries that are | 1097 | | | | physically in this table, whether | 1098 | | | | populated (non-zero byte entries) or | 1099 | | | | not. | 1100 +-----+--------------+-----+---------------------------------------+ 1101 | 16 | E+2 - E+17 | - | Item 1 - First shared data entry. | 1102 +-----+--------------+-----+---------------------------------------+ 1103 | 16 | E+18 - E+33 | - | Item 2 - Second shared data entry. | 1104 +-----+--------------+-----+---------------------------------------+ 1105 |. . .| . . . Etc. | - | Item i - i-th item entry. (i | 1106 | | | | determined by "items in table" value | 1107 | | | | above.) | 1108 +-----+--------------+-----+---------------------------------------+ 1109 | 4 | N - N+3 |LONG | Next table file offset: 4-byte file | 1110 | | | | offset, in bytes from beginning of | 1111 | | | | file, of the next Shared Data Table. | 1112 | | | | Where i = shared data entries in this | 1113 | | | | table (see "items in table", above), | 1114 | | | | and each shared data item entry is 16 | 1115 | | | | bytes, N = E+2+16*i. | 1116 +-----+--------------+-----+---------------------------------------+ 1118 Shared Data Entries 1119 +-----+--------------+-----+---------------------------------------+ 1120 |Bytes| Byte offsets |Type | Description | 1121 +-----+--------------+-----+---------------------------------------+ 1122 | 4 | Y - Y+3 |LONG | Shared Data bytes - Size of the | 1123 | | | | shared data data block, in bytes. | 1124 +-----+--------------+-----+---------------------------------------+ 1125 | 4 | Y+4 - Y+7 |LONG | Shared Data file offset - File offset | 1126 | | | | of this shared data data block, in | 1127 | | | | bytes, from beginning of file. | 1128 +-----+--------------+-----+---------------------------------------+ 1129 | 2 | Y+8 - Y+9 |SHORT| SharedDataType - The type of data | 1130 | | | | being represented as a shared data. | 1131 | | | | The table below contains the type of | 1132 | | | | shared data currently defined. | 1133 +-----+--------------+-----+---------------------------------------+ 1134 | 2 | Y+10 - Y+11 |SHORT| Last page used - The page (primary | 1135 | | | | IFD) ordinal (1, 2, ...) of the last | 1136 | | | | page that references this shared data.| 1137 | | | | A value of 0 indicates that the last | 1138 | | | | page to use the shared data is not | 1139 | | | | known. | 1140 | | | | The page ordinal SHOULD be based on | 1141 | | | | the order within the primary IFD | 1142 | | | | chain. | 1143 +-----+--------------+-----+---------------------------------------+ 1144 | 4 | Y+12 - Y+15 |LONG | SharedDataMemory - the number of bytes| 1145 | | | | required by the referencing data | 1146 | | | | stream to hold this shared data. If | 1147 | | | | the shared data is encoded then the | 1148 | | | | memory required SHOULD be consistent | 1149 | | | | with the decoded form of the shared | 1150 | | | | data. | 1151 | | | | A value of 0 indicates that the | 1152 | | | | SharedDataMemory is not known, or this| 1153 | | | | field is not applicable. | 1154 | | | | When defining a shared data and | 1155 | | | | SharedDataMemory is applicable, a | 1156 | | | | formula for computing the | 1157 | | | | SharedDataMemory SHALL be given within| 1158 | | | | the definition of the referencing data| 1159 | | | | stream. | 1160 | | | | An example of such a formula may be | 1161 | | | | found in Section E1.6.4.2 for JBIG2. | 1162 +-----+--------------+-----+---------------------------------------+ 1164 Current SharedDataTypes: 1165 +----------------+---------------------------------------------+ 1166 | SharedDataType | Description | 1167 | Value | | 1168 +----------------+---------------------------------------------+ 1169 | 0 | undefined | 1170 +----------------+---------------------------------------------+ 1171 | 1 | JBIG2 Shared Data (i.e. JBIG2 symbol | 1172 | | dictionaries, pattern dictionaries, Huffman | 1173 | | tables, etc) | 1174 +----------------+---------------------------------------------+ 1176 Shared Data ID: 1177 The reference to a shared data entry SHALL be by a unique ID, which 1178 SHALL be the offset of the entry in the list described by the Shared 1179 Data Tables; the first shared data entry SHALL have ID 0. Note that 1180 the "list" of shared data entries is what the series of Shared Data 1181 Tables SHALL contain, when collected together. The order of the 1182 shared data tables SHALL determine the order of the shared data IDs. 1183 For example, if the first three tables (A, B and C) have 3, 1 and 2 1184 shared data respectively; then table A will contain shared data with 1185 IDs 0, 1, and 2; table B will contain the shared data with ID 3; and 1186 table C will contain shared data with IDs 4 and 5. Note that if 1187 copying shared data from one file to another, the shared data ID will 1188 likely need revision to be brought in alignment with the destination 1189 table; additionally, any copied data that refers to the copied shared 1190 data will require a change in the reference to the new ID. 1192 E1.5.4.1 SharedDataList 1194 The data stream that requires inclusion of one or more Shared Data 1195 (i.e. the reference data stream) may include a list of IDs in a 1196 SharedDataList. For instance, an image strip that requires a shared 1197 data in order to be a complete compressed data stream, will include a 1198 SharedDataList. It is up to the interpretation of the reference data 1199 type (i.e. Compression type) as to how the shared data will be used. 1201 A SharedDataList, located at file offset P, in bytes, from the 1202 beginning of the file, SHALL contain a 2-byte count of the number of 1203 IDs (i) in the list, followed by i 4-byte IDs. 1205 SharedDataList Structure 1206 +-----+---------------+-----+---------------------------------------+ 1207 |Bytes| Byte offsets |Type | Description | 1208 +-----+---------------+-----+---------------------------------------+ 1209 | 2 | P - P+1 |SHORT| The number of shared data IDs (i) | 1210 +-----+---------------+-----+---------------------------------------+ 1211 | 4 | P+2 - P+5 |LONG | First shared data ID | 1212 +-----+---------------+-----+---------------------------------------+ 1213 +-----+---------------+-----+---------------------------------------+ 1214 | 4 | ... |LONG | ... | 1215 +-----+---------------+-----+---------------------------------------+ 1216 | 4 | P+2+(i-1)*4 - |LONG | i-th shared data ID | 1217 | | P+5+(i-1)*4 | | | 1218 +-----+---------------+-----+---------------------------------------+ 1220 E1.5.4.2 Representation of Shared Data in TIFF 1222 The representation of Shared Data in a TIFF file is shown below: 1223 +------+----------------------+---------------------------------+ 1224 | | | "II" or "MM" | 1225 | | +---------------------------------+ 1226 | | TIFF Header | 42 | 1227 | | +---------------------------------+ 1228 | | | FirstIFD offset (IFD0) |---: 1229 | +----------------------+---------------------------------+ | 1230 | | ... | | 1231 | :---|---------------------------<----------------------------|---: 1232 | | | ... | 1233 | v +----------------------+---------------------------------+ 1234 | | | | ... | 1235 | | | +---------------------------------+ 1236 | :-->| IFD0 | GlobalParametersIFD offset |---: 1237 | | +---------------------------------+ | 1238 | | | ... | | 1239 | +----------------------+---------------------------------+ v 1240 | | ... | | 1241 | :---|---------------------------<----------------------------|---: 1242 | | | ... | 1243 | v +----------------------+---------------------------------+ 1244 | | | | ... | 1245 | | | +---------------------------------+ 1246 | :-->| GlobalParametersIFD | SharedData offset (1st Shared |---: 1247 | | | Data Table offset) | | 1248 | | +---------------------------------+ | 1249 | TIFF | | ... | v 1250 | file +----------------------+---------------------------------+ | 1251 | | ... | | 1252 | :---|---------------------------<----------------------------|---: 1253 | | | ... | 1254 | | +----------------------+---------------------------------+ 1255 | | +----------------------+---------------------------------+ 1256 | | | | Number of items in table | 1257 | | | +-----------------+---------------+ 1258 | | | | | Byte count | 1259 | v | | +---------------+ 1260 | | | | | File offset | 1261 | | | | +---------------+ 1262 | | | | Shared Data 0 | SharedDataType| 1263 | | | | +---------------+ 1264 | :-->| Shared Data Table 0 | | Last page used| 1265 | | | +---------------+ 1266 | | | | SharedData | 1267 | | | | Memory | 1268 | | +-----------------+---------------+ 1269 | | | Shared Data 1 | ... | 1270 | | +-----------------+---------------+ 1271 | | | ... | ... | 1272 | | +-----------------+---------------+ 1273 | | | Next Shared Data Table offset | 1274 | +----------------------+---------------------------------+ 1275 | | ... | 1276 +------+--------------------------------------------------------+ 1278 E1.6. TIFF-FX Extension 4 (E4): Profile T - Lossy and Lossless JBIG2 1279 Black-and-White Fax profile 1281 This section defines the lossy and lossless JBIG2 black-and-white 1282 profile or Profile T of TIFF for facsimile. JBIG2, ITU-T Rec. T.88 / 1283 ISO-IEC 14492 [T.88], is frequently referenced as symbol or token- 1284 based compression because it makes use of repeating shapes. The 1285 Profile T designation is representative of the term token-based 1286 compression. It must be noted that there are modes of JBIG2 that do 1287 not make use of repeating shapes, such as generic region coding. 1288 All profile T readers and writers SHALL also be able to read and 1289 write Profile S, since Profile S is the minimal binary TIFF-FX 1290 profile. 1292 E1.6.1. Overview 1294 This section describes a black-and-white profile that uses JBIG2 1295 compression. The ITU-T has approved the lossy and lossless modes of 1296 JBIG2 for Group 3 facsimile. JBIG2 compression is typically used in 1297 accordance with the application rules given in ITU-T Rec. T.89 1298 [T.89]. 1300 This profile is essentially a JBIG2 encoded black-and-white 1301 constrained profile of Profile M plus the Profile M Shared Data 1302 extension. The MRC 3-layer model and TIFF representation, defined in 1303 Section 8.1 and constrained to a single image layer (i.e. only one 1304 layer with image data), SHALL be used. 1306 The behavior and structure of this profile is that of a 1307 plain single-layer image, similar to that of Profiles S, F and J, 1308 with some added structure to accommodate JBIG2's meta-data. Within 1309 this context, bit 4 of the NewSubFileType field SHALL be set, 1310 indicating the MRC imaging model with multiple layers. It must be 1311 noted, however, that the SubIFDs SHOULD consist of only even-numbered 1312 layers. In other words, only even-numbered values of the 1313 ImageLayer[0] field, representing mask layers, SHOULD be present. 1314 Additionally the SharedData field SHALL be used to store JBIG2 Shared 1315 Data, such as symbol or pattern dictionaries, and the Compression 1316 type SHALL be set to 12 (JBIG2 Compression). These requirements are 1317 consistent with ITU-T's definitions in Rec. T.4 Annex H [T.4Amd1] and 1318 Rec. T.44 Annex B [T.44 Ammd1]. 1320 JBIG2 compression utilizes the fact that many images have repeating 1321 shapes or symbols. This is especially true for images of text, where 1322 the repeating shapes are the characters themselves. Symbol or token- 1323 based compression makes use of these repeating shapes, by storing a 1324 set of images for the symbols once, and then referring to the symbol 1325 images as many times as possible. 1327 In a multi-page document, the same shape can occur on multiple pages. 1328 In fact, this is quite common: any shape occurring on the first page, 1329 is likely to show up on other pages as well. JBIG2 compression is 1330 improved by collecting all the repeating shapes from multiple pages, 1331 and allowing this collection to be referred to by more than one page. 1332 This collection of symbol images is referred to as a symbol 1333 dictionary. A document can contain more than one symbol dictionary. 1334 For example, one symbol dictionary might contain all the symbols that 1335 occurred on more than one page; each page then might have its own 1336 symbol dictionary, containing all the symbols that occurred only on 1337 that page. 1339 There are two typical ways of compressing symbols on a page using (or 1340 generating) a symbol dictionary. One is by finding an exact match 1341 (lossless), and the other is by allowing a small amount of 1342 discrepancy between the symbol candidate, and the matching symbol in 1343 the symbol dictionary (lossy). The mode used can be distinguished by 1344 the value of the "Lossless" bit in the T88Options[0] field, which is 1345 defined below. 1347 The representation of a symbol-compressed image consists of a shared 1348 data list, which identifies which "JBIG2 Shared Data" are used, and 1349 a "JBIG2-coded position block". A JBIG2 Shared Data is used to 1350 represent a variety of JBIG2 shared entities (i.e. JBIG2 resources) 1351 such as symbol dictionaries, pattern dictionaries, which are used in 1352 halftone coding, and Huffman tables. The symbol dictionaries are 1353 typically contained within one or more JBIG2 Shared Data, represented 1354 within the Shared Data provisions of the Shared Data Extension of 1355 Profile M. The JBIG2-coded position block consists of a series of 1356 symbol X and Y-Position coordinates, plus the IDs of the symbols 1357 located by the coordinates. The symbol bitmaps are stored in the 1358 referenced symbol dictionaries. 1360 Each TIFF strip in an IFD whose Compression is equal to 12 (the TIFF 1361 Compression value defined for JBIG2 below) SHALL be formatted as 1362 described in Section E1.6.5 (The JBIG2 Image Strip). 1364 E1.6.1.1 Why Use JBIG2 1366 The symbol-based compression model is incorporated in the JBIG2 1367 standard. This standard boosts compression of text-like documents 1368 by retaining similar shapes across multiple images. In the case of 1369 text, the shapes are the character symbols, and for multi-page 1370 documents, the set of unique character symbols may be fairly small, 1371 especially when the same font is used on each page. 1373 A typical image of binary text, at 300 dpi might take about 80 1374 kilobytes to store using T.6 compression; a similar JBIG2 file might 1375 only require around 20 kilobytes to store. The compression gain can 1376 be up to a factor of two for multi-page files. Sharing 1377 dictionaries between multiple pages makes this high compression 1378 possible, but requires some way to refer to the dictionaries used by 1379 more than one page. This is the reason for using Profile M and its 1380 Shared Data provisions. 1382 E1.6.2. Required TIFF Fields 1384 This section describes the TIFF fields required, in addition to those 1385 in Sections 8.2 and E1.5.2, for Profile T. Additionally it describes 1386 those not required in Section 8.2 and constrained differently from 1387 those in Section 8.2. 1389 Note that these fields are defined under the premise that all odd- 1390 numbered layers are omitted, in conformance to the Profile T black- 1391 and-white constraint. However, there are application conditions that 1392 could benefit from inclusion of these odd-numbered layers and setting 1393 the associated StripByteCounts to 0. This may be true when an 1394 application wishes to represent a reverse video image (i.e. a white 1395 image on a black background). Under these conditions the list of 1396 required fields and/or values will be modified per the 1397 StripByteCounts field below. 1399 E1.6.2.1. Baseline Fields 1401 ImageWidth(256). SHORT or LONG 1402 Same page widths as Profile F, the extended black-and-white profile, 1403 and the ImageWidth extensions available to Profile F; see Section 1404 4.2.1 and E1.3. 1405 The change in ImageWidth reference, to those of Profile F rather than 1406 Profile C, is consistent with the black-and-white constraint of this 1407 profile. 1408 Note that for layers other than layer 2, the ImageWidth could be a 1409 fragment of the page width, as when the XPosition is greater than 0. 1411 BitsPerSample (258) = 1. SHORT 1412 Constraint is consistent with the black-and-white constraint. 1414 SamplesPerPixel (277) = 1. SHORT 1415 Constraint is consistent with the black-and-white constraint. 1417 Compression(259) = 12. SHORT 1418 [[The compression value of 12 is subject to change]] 1420 12 = JBIG2 coding, ITU-T Rec. T.88 / ISO-IEC 14492 (Lossy/Lossless 1421 coding of Bi-level Images, frequently referenced as symbol-based 1422 compression), T88Options field may be present when using JBIG2. 1423 The format of the data pointed to by the StripByteOffsets when 1424 Compresstion=12 is described later. 1426 FillOrder (266) = 1, 2. SHORT 1427 See Section 8.2.1 1429 PhotometricInterpretation(262) = 0. SHORT 1430 The '0' constraint is consistent with the black-and-white constraint 1431 of Section E1.6.1 and the MRC mask layer PhotometricInterpretation 1432 constraint defined in Section 8.2.1. 1434 ResolutionUnit (296) = 2. SHORT 1435 See Section 8.2.1. 1437 StripByteCounts(279) SHORT or LONG 1438 In the event that SubIFDs consists of odd-numbered layers, then the 1439 value of the StripByteCounts for all odd-numbered values of the 1440 ImageLayer[0] field SHALL be fixed to zero "0". In Profile M, it is 1441 permissible for the StripByteCounts value for a given odd-numbered 1442 layer strip to have a zero entry. This means there is no encoded 1443 image data corresponding to that strip. Instead, the current default 1444 image color should be used for the strip. The standard default image 1445 colors are white for the Background layer and black for the 1446 Foreground layer(s). 1448 It would be efficient to omit all odd numbered layers for Profile T. 1449 However, it may be useful to identify portions of a background and/or 1450 foreground image where the default color should be reversed; namely 1451 where a background image portion is all black, or where reverse video 1452 appears. 1454 To define a child IFD specifying an odd-numbered layer (i.e. 1455 foreground or background) but containing no encoded image data, 1456 create an IFD with the following settings: 1457 ImageLayer[0]: specified odd numbered layer 1458 ImageLayer[1]: specified order 1459 RowsPerStrip: strip height 1460 ImageLength: image height 1461 ImageWidth: specified value, often the Primary IFD 1462 width 1463 BitsPerSample: 8 1464 PhotometricInterpretation: 10 1465 SamplesPerPixel: 3 1466 Compression: 1 (none) 1467 XPosition: specified value, frequently 0 1468 YPosition: specified value, frequently to top of 1469 strip 1470 XResolution: that of the Primary IFD 1471 YResolution: that of the Primary IFD 1472 StripByteCounts: single 0 value 1473 StripOffsets: single 0 entry 1474 NewSubFileType: bit 4 set to 1 (MRC) 1475 ImageBaseColor: default is white and black for 1476 background and foreground layers 1477 respectively, the reverse may be 1478 specified, no other colors SHALL be 1479 specified 1481 XResolution(282) RATIONAL 1482 Same XResolution as Profile F, the extended black-and-white profile, 1483 and the XResolution extensions available to Profile F; see Section 1484 4.2.1 and E1.3. 1485 The change in XResolution reference, to those of Profile F rather 1486 than Profile M, is consistent with the black-and-white constraint of 1487 this profile. 1489 YResolution(283) RATIONAL 1490 Same YResolution as Profile F, the extended black-and-white profile, 1491 and the YResolution extensions available to Profile F; see Section 1492 4.2.1 and E1.3. 1493 The change in YResolution reference, to those of Profile F rather 1494 than Profile M, is consistent with the black-and-white constraint of 1495 this profile. 1497 Note that unlike Profile M, Profile F and Profile T may both have 1498 non-square resolutions (i.e. different X and YResolution values). 1500 E1.6.2.2. Extension Fields 1502 These fields SHALL NOT be present: 1503 ChromaSubSampling(530) 1504 ChromaPositioning(531) 1505 Indexed(346) 1506 T4Options(292) 1507 T6Options(293) 1509 These fields are as described in Section 8.2.2: 1510 SubIFDs(330). 1511 XPosition(286). 1512 YPosition(287). 1514 E1.6.2.3. New Fields 1516 These Section 8.2.3 fields SHALL NOT be present: 1517 Decode(433). 1518 T82Options(435) 1520 This Section 8.2.3 field SHOULD NOT be present: 1521 ImageBaseColor(434). The field SHOULD be omitted and the default 1522 color of black and white SHALL be applied to foreground and 1523 background layers respectively. When present, the default 1524 Background or Foreground colors are typicallytypicallyty revised to 1525 black or white respectively, see StripByteCounts above. 1527 These fields, described in Section 8.2.3 SHALL be present: 1528 StripRowCounts(559). 1529 ImageLayer (34732). 1531 The fields described in E1.5.2.3 SHALL be present. 1532 GlobalParametersIFD (400) 1533 SharedData (437) 1534 TIFF-FXExtensions (407) 1535 Bits 2 and 3 of the TIFF-FXExtensions field SHALL be set to 1. 1537 E1.6.3. Recommended TIFF Fields 1539 See Sections 8.3, with exception of GlobalParametersIFD and append 1540 the Following: 1542 T88Options (436). LONG 1543 Count = 1 or 2 1544 [[The 436 tag value is subject to change]] 1546 The T88Options field contains one or two values, describing options 1547 applied to the encoded data stream and any application profile to 1548 which the encoded data stream may conform. It SHALL only be present 1549 when the IFD's Compression field is equal to 12 (JBIG2). The content 1550 provides an aid to TIFF readers, in that they describe JBIG2 options 1551 that may or may not be handled by a specific JBIG2 decoder. None of 1552 the values in the field are required for correct decoding, and the 1553 field may be ignored. In the event that this field is omitted, a 1554 reader SHALL assume that the data stream is encoded per the ITU-T 1555 T.89 Base profile (i.e. profile identification number 0x00000101), 1556 see T88Options[1] below. 1558 T88Options[0] = 1, 2, ..., 7. 1559 This value represents options that are being applied to the encoded 1560 data stream. 1562 NOTE: In all the tables shown below, all multi-byte quantities are 1563 written/read in the endianness convention established by the TIFF 1564 file ("II" or "MM"). 1566 The following options are defined: 1567 +--------------+----------------------------------------------------+ 1568 | Bit number | Meaning | 1569 +--------------+----------------------------------------------------+ 1570 | 0 | HuffmanCodingNotPresent | 1571 | | If bit 0 is 1, then the JBIG2-compressed data in | 1572 | | this IFD SHALL NOT use Huffman or MMR (T.6) coding.| 1573 +--------------+----------------------------------------------------+ 1574 | 1 | ArithmeticCodingPresent | 1575 | | If bit 1 is 1, then the JBIG2-compressed data in | 1576 | | this IFD MAY contain segments that contain | 1577 | | arithmetic (MQ) coding. | 1578 +--------------+----------------------------------------------------+ 1579 | 2 | Lossless | 1580 | | If bit 2 is 1, then the JBIG2-compressed data in | 1581 | | this IFD SHALL be a lossless representation of the | 1582 | | original image. | 1583 +--------------+----------------------------------------------------+ 1584 | 3 | SingleStriped | 1585 | | If bit 3 is 1, then each TIFF strip SHALL contain a| 1586 | | JBIG2 Position Block that has only one JBIG2 stripe| 1587 | | (not the same as a TIFF strip). | 1588 | | Note: There is a limit of 32767 lines per JBIG2 | 1589 | | stripe in the event that multi-stripe mode is used.| 1590 +--------------+----------------------------------------------------+ 1591 +--------------+----------------------------------------------------+ 1592 | 4 | TextStripesMixed | 1593 | | If bit 4 is 1, then some JBIG2-compressed stripes | 1594 | | that have text region segment(s) MAY also have | 1595 | | region segments with other data types (e.g. generic| 1596 | | or halftone region segment). | 1597 +--------------+----------------------------------------------------+ 1598 | 5 | ColourTagsFollow | 1599 | | If bit 5 is 1, then this IFD SHALL be in a mask | 1600 | | layer whose corresponding foreground layer SHALL be| 1601 | | coded with JBIG2 (Compression = 12) and the JBIG2- | 1602 | | data SHALL be augmented with ITU-T Rec. T.45 (Run- | 1603 | | length colour encoding) [T.45] coded colour tags. | 1604 +--------------+----------------------------------------------------+ 1605 | 6 | ColourTagsPresent | 1606 | | If bit 6 is 1, then this IFD SHALL be in a | 1607 | | foreground layer, which SHALL be coded with JBIG2 | 1608 | | (Compression = 12) and the JBIG2-data SHALL be | 1609 | | augmented with T.45-coded colour tags. | 1610 +--------------+----------------------------------------------------+ 1611 | 7 | HalftoneRegionPresent | 1612 | | If bit 7 is 1, then the JBIG2-compressed data in | 1613 | | this IFD SHALL contain halftone region segment(s). | 1614 +--------------+----------------------------------------------------+ 1615 Note: Bits 5 or 6 SHALL be 0 within Profile T, which is constrained 1616 to black-and-white images. 1618 T88Options[1] = 0x00000101, 0x00000102, 0x00000103. 1619 This value represents the JBIG2 profile identification number. This 1620 value may be omitted. 1621 Default = 0x00000101. 1623 The profile identification number of the T88Options identifies a 1624 subset of the full set of permitted parameters and parameter values 1625 that the JBIG2 coded data stream is in compliance with. None of the 1626 values of the T88Options field is required for correct decoding of a 1627 JBIG2 coded data stream and may be ignored. It allows a decoder to 1628 find out quickly which of the set of JBIG2 parameters and parameter 1629 values may be required to decode a given data stream. 1631 The four-byte profile identification numbers 0x00000000 through 1632 0xFFFFFFFF are administered by ISO/IEC JTC1 SC29. ISO/IEC JTC1 SC29 1633 has reserved profile identification numbers 0x00000100 through 1634 0x00000FFF for ITU-T disposition. Interpretation of profiles 1635 0x00000100 through 0x00000FFF is documented in ITU-T Rec. T.89, while 1636 interpretation of profiles 0x00000000 through 0x000000FF is 1637 documented in ISO/IEC 14492 | ITU-T T.88. 1639 Current profiles: 1640 +------------------+------------------------------------------------+ 1641 | JBIG2 Profile ID | Description | 1642 +------------------+------------------------------------------------+ 1643 | 0x00000101 | ITU-T T.89 Base (minimal Fax Application | 1644 | | Profile) - MMR and Huffman coding, minimum of | 1645 | | two stripes per page, stripes containing text | 1646 | | region segment(s) SHALL NOT contain other | 1647 | | region segments | 1648 +------------------+------------------------------------------------+ 1649 | 0x00000102 | ITU-T T.89 Upper MMR | 1650 | | - MMR and Huffman coding, minimum of two | 1651 | | stripes per page, accommodates halftone and | 1652 | | colour tags | 1653 +------------------+------------------------------------------------+ 1654 | 0x00000103 | ITU-T T.89 Lower Arithmetic | 1655 | | - Arithmetic coding, minimum of two stripes per| 1656 | | page, stripes containing text region segment(s)| 1657 | | SHALL NOT contain other region segments | 1658 +------------------+------------------------------------------------+ 1660 NOTE: In this table, the term "stripe" means JBIG2 stripe (i.e. a 1661 stripe within a JBIG2 Position Block), not a TIFF strip, nor a 1662 TIFF-FX stripe. 1664 E1.6.4 JBIG2 Shared Data 1666 For JBIG2 Shared Data, the SharedDataType value in the Shared Data 1667 Entry SHALL have a value of 1. 1669 E1.6.4.1 The JBIG2 Shared Data 1671 The JBIG2 Shared Data stored in a TIFF file contains three pieces: 1672 1. A JBIG2 Shared Data version 1673 2. A JBIG2-coded shared data block 1674 3. Extensions to the JBIG2 Shared Data (these extensions contain 1675 data that are outside the scope of T.88-JBIG2) 1677 The JBIG2-coded shared data block can have a series of JBIG2 1678 segments. The following segment types may occur: 1679 - Symbol dictionary segment 1680 - Pattern dictionary segment 1681 - Extension segment (future extensions to be defined within the 1682 T.88 JBIG2 standard) 1683 - Supported profiles segment 1684 - Table segment 1685 Each segment in a JBIG2-coded shared data block SHALL be associated 1686 with no page (i.e., SHALL have a page association field value of 0, 1687 as described in T.88 - JBIG2 Section 7.2.6). 1689 To put it into perspective, when sharing data is required, a file 1690 contains one SharedData field, which is located in the 1691 GlobalParametersIFD. The SharedData field contains the file offset of 1692 the first Shared Data Table. Each Shared Data Table contains a count 1693 of the number of Shared Data Entries (i.e. JBIG2 Shared Data) that 1694 physically exist in the table , the location and size of the JBIG2 1695 Shared Data themselves, and the file location of the next Shared Data 1696 Table (if any). There can be as many Shared Data Tables as necessary 1697 to describe the number of JBIG2 Shared Data items. 1699 The JBIG2 image strip (i.e. the reference data stream), described in 1700 the next section, that requires inclusion of one or more JBIG2 Shared 1701 Data SHALL include a list of JBIG2 Shared Data IDs in a 1702 SharedDataList. 1704 E1.6.4.1.1 JBIG2 Shared Data Format 1706 The JBIG2 Shared Data format consists of a version number, which 1707 identifies the version of the format that follows, followed by the 1708 size of the JBIG2 data block, then the data block itself, followed 1709 by any extensions. The start of the JBIG2 Shared Data is located at 1710 file offset T, in bytes, from the beginning of the file. 1712 The JBIG2 Shared Data has the following format: 1713 +-----+--------------+-----+----------------------------------------+ 1714 |Bytes| Byte offsets | Type| Description | 1715 +-----+--------------+-----+----------------------------------------+ 1716 | 1 | T |BYTE | The JBIG2 Shared Data version number, | 1717 | | | | which is currently 0. | 1718 +-----+--------------+-----+----------------------------------------+ 1719 | 4 | T+1 - T+4 |LONG | Size of JBIG2-coded shared data block | 1720 | | | | (not including extensions) = Y. | 1721 +-----+--------------+-----+----------------------------------------+ 1722 | Y | T+5 - T+4+Y |BYTE | The JBIG2-coded shared data block. | 1723 +-----+--------------+-----+----------------------------------------+ 1724 | 2 | . . . . |SHORT| Extension type for first extension | 1725 | | | | (these extensions contain data that are| 1726 | | | | outside the scope of T.88-JBIG2) | 1727 +-----+--------------+-----+----------------------------------------+ 1728 | 4 | . . . . |LONG | Size of first extension=Z1 | 1729 +-----+--------------+-----+----------------------------------------+ 1730 | Z1 | . . . . |BYTE | Data for first extension | 1731 +-----+--------------+-----+----------------------------------------+ 1732 | 2 | . . . . |SHORT| Extension type for second extension | 1733 +-----+--------------+-----+----------------------------------------+ 1734 | 4 | . . . . |LONG | Size of second extension=Z2 | 1735 +-----+--------------+-----+----------------------------------------+ 1736 | Z2 | . . . . |BYTE | Data for second extension | 1737 +-----+--------------+-----+----------------------------------------+ 1739 +-----+--------------+-----+----------------------------------------+ 1740 | ....| . . . . | ....| Further extensions | 1741 +-----+--------------+-----+----------------------------------------+ 1743 E1.6.4.2 JBIG2 SharedDataMemory 1745 For JBIG2 dictionary Shared Data the SharedDataMemory requirement is 1746 represented by the total amount of decoded symbol dictionary 1747 information a decoder will accommodate in memory at one time to 1748 decode a file. This SharedDataMemory requirement is referenced as the 1749 decoder memory. If decoder memory is specified (non-zero value), then 1750 it follows the formula described in [T.89]. Namely, the decoder 1751 memory, composed of two components (a fixed and per-symbol 1752 component), is a measure of how much memory is required to hold a 1753 decoded dictionary. The fixed component does not depend on the number 1754 of symbols, while the per-symbol component does depend on the number 1755 of symbols. The decoder memory algorithm does have dependence on 1756 whether Huffman (see note 1) or Arithmetic (see note 2) coding is 1757 used and whether the dictionaries contain symbols or halftone 1758 patterns (see note 3). 1760 decoder memory = fixed component + per-symbol component 1762 fixed component = 2^{direct coding template size} 1763 + 2^{refinement coding template size} + 8K 1765 per-symbol component = SUM (32 + (round32(Wi) ( Hi) / 8) over i, 1766 i= 1 to N 1768 where: 1769 i = ith symbol in the dictionary 1770 N = the number of symbols in the dictionary 1771 32 = a fixed per-symbol overhead required to represent: 1772 - width of symbol 1773 - height of symbol 1774 - symbol ID Huffman code 1775 - length of symbol ID Huffman code 1776 - pointer to memory where symbol bitmap resides 1777 round32 = is a rounding up to the next multiple of 32 bits (e.g., 1778 33 rounds to 64, 128 rounds to 128) 1779 Wi = width of the ith symbol 1780 Hi = height of the ith symbol 1782 This means that for each symbol there are 32 bytes overhead, plus 1783 Hi rows of bitmap data, each of which is round32(Wi)/8 bytes. 1785 Note: 1786 1) For Huffman coding there are no templates, so the fixed component 1787 is about 8K bytes. The fixed component can in fact be zero if 1788 custom Huffman tables are not used. 1789 2) For Arithmetic coding the per-symbol component is the same. The 1790 amount of memory needed to store the decoded dictionary bitmaps 1791 (that's the (round32(Wi) * Hi) / 8 component) is unchanged. 1792 Differences occur in the 32 bytes per-symbol overhead component. 1793 The width, height and pointer fractions of the overhead still 1794 apply, however the Huffman code parts do not apply. There are, 1795 however, context tables for symbol ID probability modeling that 1796 take the place of the Huffman code parts. Bottom line, 32 bytes is 1797 also a reasonable per-symbol overhead for Arithmetic coding. 1798 The template options documented in [T.89] range from a 10 pixels 1799 direct bitmap template with no refinement bitmap coding to a 16 1800 pixels direct bitmap template with a 13 pixels refinement bitmap 1801 template. Given this range of templates, the fixed component will 1802 range from 9K to 80K bytes. 1803 3) The same expression holds for pattern dictionaries of halftone 1804 image regions, since pattern dictionaries are similar to 1805 symbol dictionaries but contain halftone patterns. In this 1806 context, the references to symbol above should be taken to include 1807 patterns stored in pattern dictionaries. The pattern dictionaries, 1808 however, tend to be small relative to symbol dictionaries, since 1809 the pattern count is frequently low. This isThis only a few K of 1810 memory. It is the space required by a decoder to hold the halftone 1811 bit-planes that is of significance and determines the 1812 SharedDataMemory. This memory requirement is document in [T.89] to 1813 be typically 110% of the resolution dependent page buffer size 1814 (i.e. 1.0 Mbytes at 300 dpi and 2.0 Mbytes at 400 dpi). 1816 E1.6.5 The JBIG2 Image Strip 1818 The JBIG2 image stored in a TIFF file will have components that 1819 require a TIFF reader to parse through its strip content. This is 1820 due to the fact that JBIG2 is represented by two types of data: 1821 1. shared components: namely the symbol or pattern bitmaps that 1822 are associated with multiple images, which are compressed into 1823 dictionaries and stored in one or more JBIG2 Resources. 1824 2. image specific components: data that is specific to one image 1825 only, that with the aid of the shared components, will allow 1826 the image to be decoded. 1828 To couple these two component sets together, each JBIG2 Image Strip 1829 within an IFD has a corresponding list of shared data IDs in the 1830 SharedDataList section of each image strip. The concatenation of the 1831 shared data and the JBIG2 position block will comprise a decodable 1832 JBIG2 stream for the image described by the IFD for that strip. 1834 A position block is the JBIG2 encoding of the binary image code 1835 stream. Included in the position block are the encoded positions and 1836 IDs of the symbols within the dictionaries, which may lie within the 1837 position block, and/or outside of it (as JBIG2 Shared Data). Within 1838 the position block, the following segment types may occur: 1839 1. Page information segment 1840 - Exactly one page information segment SHALL be present, and it 1841 SHALL be the first segment in the JBIG2-coded position block 1842 2. End of page segment 1843 - Exactly one end of page segment SHALL be present, and it SHALL 1844 be the last segment in the JBIG2-coded position block 1845 3. End of stripe segment 1846 4. Symbol dictionary segment 1847 5. Pattern dictionary segment 1848 6. Generic region segment 1849 7. Generic refinement region segment 1850 8. Text region segment 1851 9. Halftone region segment 1852 10. Extension segment (future extensions to be defined within the 1853 T.88 JBIG2 standard) 1854 11. Supported profiles segment 1855 12. Table segment. 1857 Each segment in a JBIG2-coded position block SHALL be associated with 1858 the page defined by the page information segment. 1860 The TIFF JBIG2 Image Strip SHALL consist of four pieces: 1861 1. A JBIG2 Image Strip version 1862 2. A SharedDataList: list of JBIG2 Shared Data IDs 1863 3. The JBIG2-coded position block 1864 4. Extensions to the image strip (these extensions contain data 1865 that are outside the scope of JBIG2, such as colour tags, which 1866 are defined within the JBIG2 Extension of Profile M. Colour tags 1867 are not permitted within this profile, Profile T). 1869 If the JBIG2 Image Strip contains extensions, each extension is 1870 preceded by a two-byte type giving its extension type, and a 4-byte 1871 count of its length in bytes. Other data that could possibly be 1872 stored in an extension includes ASCII text, hyperlinks, and so on. 1873 The current image strip extensions and the data that may be stored in 1874 them are defined in Section E1.6.5.1. If a TIFF reader is not able to 1875 interpret an extension (if it does not recognize the extension type), 1876 then it SHOULD ignore that extension, but may skip over it to find 1877 further extensions that it can interpret. 1879 To decode a JBIG2-coded image strip, follow these steps: 1880 1. Retrieve the list of shared data IDs from the SharedDataList. 1881 2. Search the collection of JBIG2 Shared Data for all the JBIG2 1882 Shared Data, such as dictionaries, whose IDs are given in the 1883 SharedDataList. 1884 From each one, extract its JBIG2-coded shared data block. 1886 3. Concatenate those JBIG2-coded shared data blocks, in the order 1887 in which their IDs are given in the SharedDataList, followed 1888 by the JBIG2-coded position block. 1889 4. This concatenated data stream can then be decoded as a JBIG2 1890 data stream. This SHALL be a valid JBIG2 data stream 1891 containing a single page: no segment numbers may be 1892 duplicated, and so on. 1893 As an optimization, you won't actually concatenate and decode the 1894 JBIG2-coded shared data block(s) for every position block that uses 1895 them, as that is quite inefficient. Instead, the JBIG2-coded shared 1896 data block(s) can be decoded and kept in an intermediate format, 1897 designed so that the effect of logical concatenation can be 1898 simulated. 1900 E1.6.5.1 Image Strip Format 1902 The image strip has the following format, which includes a 1903 ResourceList, delimited by "====": 1905 +-----+--------------+-----+----------------------------------------+ 1906 |Bytes| Byte offsets | Type| Description | 1907 +-----+--------------+-----+----------------------------------------+ 1908 | 1 | P |BYTE | Strip format version number, which is | 1909 | | | | currently 0. | 1910 +=====+==============+=====+========================================+ 1911 | 2 | P+1 - P+2 |SHORT| Number of resource IDs = X (i.e. JBIG2 | 1912 | | | | Shared Data) | 1913 +-----+--------------+-----+----------------------------------------+ 1914 | X*4 | P+3 - P+2 |LONG | The sequence of shared data IDs of the | 1915 | | +(X*4) | | JBIG2 Shared Data required by this | 1916 | | | | JBIG2-coded position block. The JBIG2 | 1917 | | | | Shared Data (e.g. dictionaries) will be| 1918 | | | | prepended in the order specified by | 1919 | | | | this sequence of IDs, to construct the | 1920 | | | | array of symbols that will be used to | 1921 | | | | decode the JBIG2-coded position block. | 1922 +=====+==============+=====+========================================+ 1923 | 4 | P+3+(X*4) - |LONG | Size of JBIG2-coded position block not | 1924 | | P+6+(X*4) | | including extensions = Y | 1925 +-----+--------------+-----+----------------------------------------+ 1926 | Y | . . . . |BYTE | The JBIG2-coded Position Block. | 1927 +-----+--------------+-----+----------------------------------------+ 1928 | 2 | . . . . |SHORT| Extension type for first extension | 1929 | | | | (these extensions contain data that are| 1930 | | | | outside the scope of T.88-JBIG2, such | 1931 | | | | as colour tags) | 1932 +-----+--------------+-----+----------------------------------------+ 1933 +-----+--------------+-----+----------------------------------------+ 1934 | 4 | . . . . |LONG | Size of first extension=Z1 | 1935 +-----+--------------+-----+----------------------------------------+ 1936 | Z1 | . . . . |BYTE | Data for first extension | 1937 +-----+--------------+-----+----------------------------------------+ 1938 | 2 | . . . . |SHORT| Extension type for second extension | 1939 +-----+--------------+-----+----------------------------------------+ 1940 | 4 | . . . . |LONG | Size of second extension=Z2 | 1941 +-----+--------------+-----+----------------------------------------+ 1942 | Z2 | . . . . |BYTE | Data for second extension | 1943 +-----+--------------+-----+----------------------------------------+ 1944 | ... | . . . . |.... | Further extensions | 1945 +-----+--------------+-----+----------------------------------------+ 1947 Current JBIG2 Image Strip Extension Types: 1948 +----------------+--------------------------------------------------+ 1949 | Extension Type | Meaning | 1950 +----------------+--------------------------------------------------+ 1951 | 0 | Undefined | 1952 +----------------+--------------------------------------------------+ 1953 | 1 | Colour tags | 1954 | | This extension contains colour tag data, T.45 | 1955 | | encoded. | 1956 | | This value SHALL NOT be used when using Profile T| 1957 +----------------+--------------------------------------------------+ 1959 E1.6.6 Representation of JBIG2 data in TIFF 1961 The embedding of JBIG2 data in TIFF then takes the following form: 1962 +------+-----------------+---------------------------------------+ 1963 | | | "II" or "MM" | 1964 | | +---------------------------------------+ 1965 | TIFF | TIFF Header | 42 | 1966 | file | +---------------------------------------+ 1967 | | | FirstIFD offset (IFD0) |--: 1968 | +-----------------+---------------------------------------+ | 1969 | | ... | 1970 | :---|-----------------------------<---------------------------|--: 1971 | | | ... | 1972 | | +-----------------+---------------------------------------+ 1973 | | +-----------------+---------------------------------------+ 1974 | | | | ... | 1975 | | | +---------------------------------------+ 1976 | v | | Next IFD offset (IFD 1) |----: 1977 | | | +---------------------------------------+ | 1978 | | | | ... | | 1979 | | | +---------------------------------------+ | 1980 | :-->| IFD0 | GlobalParametersIFD |--: | 1981 | | +---------------------------------------+ | v 1982 | | | StripOffsets/StripByteCounts | | | 1983 | | +---------------------------------------+ v | 1984 | | | ... | | | 1985 | +-----------------+---------------------------------------+ | | 1986 | | ... | | | 1987 | :---|-----------------------------<---------------------------|--: | 1988 | | | ... | | 1989 | v +-----------------+---------------------------------------+ v 1990 | | | | ... | | 1991 | | | +---------------------------------------+ | 1992 | :-->| GlobalParameters| SharedData offset (1st Shared |--: | 1993 | | IFD | Data Table offset) | | | 1994 | | +---------------------------------------+ | | 1995 | TIFF | | ... | v | 1996 | file +-----------------+---------------------------------------+ | | 1997 | | ... | | v 1998 | :---|-----------------------------<---------------------------|--: | 1999 | | | ... | | 2000 | | +-----------------+---------------------------------------+ | 2001 | | | | Number of items in table | | 2002 | | | +----------------+----------------------+ | 2003 | | | | | Byte count (of JBIG2 | | 2004 | | | | | Shared Data 0) | | 2005 | v | | +----------------------+ v 2006 | | | | | File offset (to |--: | 2007 | | | | | JBIG2 Shared Data 0) | | | 2008 | | | | +----------------------+ | | 2009 | | | | Shared Data 0 | SharedDataType (1) | | | 2010 | | | | +----------------------+ v | 2011 | :-->| Shared Data | | Last page used | | | 2012 | | Table 0 | +----------------------+ | | 2013 | | | | SharedDataMemory | | | 2014 | | +----------------+----------------------+ | v 2015 | TIFF | | Shared Data 1 | ... | | | 2016 | file | +----------------+----------------------+ v | 2017 | | | ... | ... | | | 2018 | | +----------------+----------------------+ | | 2019 | | | Next Shared Data Table offset | | | 2020 | +-----------------+---------------------------------------+ | | 2021 | +-----------------+---------------------------------------+ | | 2022 | | ... | | v 2023 | :---|-----------------------------<---------------------------|--: | 2024 | | | ... | | 2025 | v +-----------------+---------------------------------------+ | 2026 | | | | 0 (version) | | 2027 | | | +---------------------------------------+ | 2028 | | | | | | 2030 | v | +---------------------------------------+ | 2031 | | | | JBIG2-coded block> block (may contain | v 2032 | | | | multiple JBIG2 segments) | | 2033 | :-->| JBIG2 Shared +---------------------------------------+ | 2034 | | Data 0 | Extension type for first extension | | 2035 | | | (data that are outside the scope of | | 2036 | | | T.88-JBIG2) | | 2037 | | +---------------------------------------+ | 2038 | | | | | 2039 | TIFF | +---------------------------------------+ | 2040 | file | | Data for first Extension | | 2041 | | +---------------------------------------+ v 2042 | | | ... | | 2043 | +-----------------+---------------------------------------+ | 2044 | | ... | | 2045 | :---|-----------------------------<---------------------------|----: 2046 | | | ... | 2047 | v +-----------------+---------------------------------------+ 2048 | | | | ... | 2049 | | | +---------------------------------------+ 2050 | :-->| IFD1(page 0) | StripOffset (strip 0) |---: 2051 | | +---------------------------------------+ | 2052 | | | ... | | 2053 | +-----------------+---------------------------------------+ | 2054 | | ... | | 2055 | :---|-----------------------------<---------------------------|---: 2056 | | | ... | 2057 | | +-----------------+---------------------------------------+ 2058 | | | | Strip format version | 2059 | | | +---------------------------------------+ 2060 | | | | SharedDataList | 2061 | | | Strip 0 +---------------------------------------+ 2062 | :-->| | JBIG2-coded position block | 2063 | | +---------------------------------------+ 2064 | | | Extensions | 2065 | TIFF +-----------------+---------------------------------------+ 2066 | file | | 2067 | | ... | 2068 +------+---------------------------------------------------------+ 2070 E1.6.7 Rules and Requirements for Images 2072 Profile T defines a fundamental set of rules for images in the 2073 3-layer representation. 2075 1. Typically, only ONE layer with image data SHALL exist and it SHALL 2076 be the binary Mask layer, which SHALL be the Primary IFD. 2077 Compression 12 SHALL be used in this layer and the 2078 PhotometricInterpretation SHALL be 0. 2080 2. A Foreground and/or Background layer without image data (i.e. IFD 2081 with StripByteCounts = 0) MAY be present. If present, then only 2082 black and white colors SHALL be used. The Foreground and 2083 Background defaults for ImageBaseColor SHALL be black and 2084 white respectively. 2086 3. The Primary IFD defines and extends to the entire page boundary; 2087 all attached SubIFD images cannot extend beyond the Primary image. 2088 Resolution differences may cause some pixels to "hang over" the 2089 page boundary, but no new pixels should exist completely beyond 2090 the page extent. 2092 4. Images other than the Primary Image (i.e. Primary IFD) MAY 2093 optionally cover only a portion of the strip or page. 2095 5. Each Primary IFD and each MRC-specific SubIFD SHALL have an 2096 ImageLayer field to specify which layer the IFD belongs to, and 2097 the imaging order of that IFD within the layer. 2099 6. Each Primary IFD SHALL have a NewSubFileType field value set to 2100 18, indicating a single page of a multi-page document (bit 1) and 2101 MRC (bit 4). 2103 7. Each MRC-specific child IFD SHALL have a NewSubFileType field 2104 value set to 16, indicating MRC (bit 4). 2106 8. In MRC Internet Fax, each layer is transmitted as a sequence of 2107 strips. If the page consists of a single layer, then all strips 2108 SHALL be stored in the single Primary IFD. In this case, coding 2109 parameters cannot change between strips. If the page consists of 2110 more than one layer, then all strips of the Primary Mask layer 2111 SHALL be stored in the single Primary IFD. Should Foreground 2112 /Background layers be present, the StripByteCounts SHALL be set to 2113 "0". Each strip of the Foreground/Background layers SHALL be 2114 stored in one IFD, referenced by the Primary IFD's SubIFD field, 2115 containing an ImageLayer field with ImageLayer[0] identifying 2116 Background (layer 1) or Foreground layer (layer 3), and 2117 Imagelayer[1] identifying order in which images within a single 2118 layer are to be rendered. The TIFF XPosition and YPosition fields 2119 are used to indicate the placement of these images with respect to 2120 the primary image. 2122 9. If Background and/or Foreground images are present, their 2123 resolution SHALL be that of the Primary Mask image. 2125 E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile 2126 Summary 2128 Recommended fields are shown with an asterisk * 2130 Required fields or values are shown with a double asterisk **. If the 2131 double asterisk is on the field name, then all the listed values are 2132 required of implementations; if the double asterisks are in the 2133 Values column, then only the values suffixed with a double asterisk 2134 are required of implementations. 2136 +------------------+-----------------------------------------+ 2137 | Baseline Fields | Values | 2138 +------------------+-----------------------------------------+ 2139 | BitsPerSample | 1**: binary mask | 2140 +------------------+-----------------------------------------+ 2141 | Compression | 1: None (ImageBaseColor IFD only) | 2142 | | 12**: JBIG2 | 2143 +------------------+-----------------------------------------+ 2144 | DateTime* | {ASCII): date/time in the 24-hour format| 2145 | | "YYYY:MM:DD HH:MM:SS" | 2146 +------------------+-----------------------------------------+ 2147 | FillOrder** | 1: Most significant bit first | 2148 | | 2: Least significant bit first | 2149 +------------------+-----------------------------------------+ 2150 | ImageDescription*| {ASCII}: A string describing the | 2151 | | contents of the image. | 2152 +------------------+-----------------------------------------+ 2153 | ImageWidth | 1728**, 2048, 2432, 2592, | 2154 | | 3072, 3456, 3648, 4096, 4864 | 2155 +------------------+-----------------------------------------+ 2156 | ImageLength** | n: total number of scanlines in image | 2157 +------------------+-----------------------------------------+ 2158 | NewSubFileType** | 16, 18: | 2159 | | Bit 1 indicates single page of a multi- | 2160 | | page document on Primary IFD | 2161 | | Bit 4 indicates MRC model | 2162 +------------------+-----------------------------------------+ 2163 | Orientation | 1**-8, Default 1 | 2164 +------------------+-----------------------------------------+ 2165 | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | 2166 | pretation | | 2167 +------------------+-----------------------------------------+ 2168 +------------------+-----------------------------------------+ 2169 | ResolutionUnit** | 2: inch | 2170 +------------------+-----------------------------------------+ 2171 | RowsPerStrip | n: number or scanlines per strip | 2172 +------------------+-----------------------------------------+ 2173 | SamplesPerPixel | 1**, 3 (ImageBaseColor IFD only) | 2174 +------------------+-----------------------------------------+ 2175 | Software* | {ASCII}: name & release number of | 2176 | | creator software | 2177 +------------------+-----------------------------------------+ 2178 | StripByteCounts**| : number or bytes in each strip, | 2179 | | fixed to "0" for FG/BG (when present) | 2180 +------------------+-----------------------------------------+ 2181 | StripOffsets** | : offset from beginning of file to | 2182 | | each TIFF strip | 2183 +------------------+-----------------------------------------+ 2184 | XResolution | 200**, 204**, 300, 400, 408 (written in | 2185 | | pixels/inch) | 2186 +------------------+-----------------------------------------+ 2187 | YResolution | 98**, 196**, 100**, 200**, | 2188 | | 300, 391, 400 (written in pixels/inch) | 2189 +------------------+-----------------------------------------+ 2190 | Extension Fields | 2191 +------------------+-----------------------------------------+ 2192 | DocumentName* | {ASCII}: name of scanned document | 2193 +------------------+-----------------------------------------+ 2194 | PageNumber** | n, m: page number followed by total page| 2195 | | count | 2196 +------------------+-----------------------------------------+ 2197 | SubIFDs | : byte offset to FG/BG IFDs | 2198 +------------------+-----------------------------------------+ 2199 | XPosition | horizontal offset in primary IFD | 2200 | | resolution units | 2201 +------------------+-----------------------------------------+ 2202 | YPosition | vertical offset in primary IFD | 2203 | | resolution units | 2204 +------------------+-----------------------------------------+ 2205 | New Fields | 2206 +------------------+-----------------------------------------+ 2207 | StripRowCounts | : number of scanlines in each strip | 2208 +------------------+-----------------------------------------+ 2209 | ImageLayer | n, m: layer number, imaging sequence | 2210 | | (e.g., strip number) | 2211 +------------------+-----------------------------------------+ 2212 | GlobalParameters | IFD: global parameters IFD | 2213 | IFD** | | 2214 +------------------+-----------------------------------------+ 2215 | ProfileType* | n: type of data stored in TIFF file | 2216 +------------------+-----------------------------------------+ 2217 +------------------+-----------------------------------------+ 2218 | FaxProfile* | n: ITU-T compatible fax profile | 2219 +------------------+-----------------------------------------+ 2220 | CodingMethods* | n: compression algorithms used in file | 2221 +------------------+-----------------------------------------+ 2222 | VersionYear* | byte sequence: year of ITU-T standard | 2223 +------------------+-----------------------------------------+ 2224 | ModeNumber* | n: mode (i.e. functional level) of T.44 | 2225 | | standard | 2226 +------------------+-----------------------------------------+ 2227 | TIFF-FXExtensions| n: extension(s) identification number, | 2228 | ** | bits 2 and 3 for SharedData and | 2229 | | Profile T SHALL be among the set bits | 2230 +------------------+-----------------------------------------+ 2231 | T88Options* | n, m: option numbers, profile number | 2232 +------------------+-----------------------------------------+ 2233 | SharedData** | : offset from beginning of file to | 2234 | | the first Shared Data | 2235 +------------------+-----------------------------------------+ 2237 E1.7. TIFF-FX Extension 5 (E5): JBIG2 Color Extension of Profile M 2239 This section defines extensions to Profile M that augment the pool of 2240 coders and encoding mechanisms available for use in the mask and 2241 foreground layers when encoding documents with color. The JBIG2, ITU- 2242 T Rec. T.88 / ISO-IEC 14492, bi-level coder is made available for use 2243 in both mask and foreground layer(s). It must be noted that simple 2244 JBIG2 symbol-based compression is limited to matching symbols in a 2245 binary image, but ITU-T Rec. T.44 Annex B [T.44Amd1] expands this to 2246 include single-color images, such as colored text. The T.44 defined 2247 mechanism, referenced as "colour tag" encoding, is only available for 2248 use in foreground layers that are associated with JBIG2 coded mask 2249 layers. The more conventional multi-level color coders, such JPEG, 2250 are also available for use in the encoding of foreground layer colors 2251 when JBIG2 is used in the mask layer(s). 2253 E1.7.1. Overview 2255 Use of JBIG2 in Profile M effectively amounts to application of 2256 Profile T (i.e. Section E.2) to the mask layer(s), without imposition 2257 of the Profile T black-and-white constraints that prohibit the 2258 presence of background and/or foreground image data (i.e. if present 2259 StripByteCounts = 0). This translates to augmenting the MRC 3-layer 2260 model and TIFF representation, defined in Profile M, with the Shared 2261 Data extension E1 (Extension 1), and using JBIG2 coding (i.e. 2262 Compression =12) in the mask layer. The N-layer model and TIFF 2263 representation, defined in extension E2 (Section E1.4) MAY also be 2264 used if the corresponding TIFF-FXExtensions bit is set. 2266 Use of JBIG2 and "colour tagging" to encode the colors of the 2267 foreground layer(s) translates to attaching discrete color values to 2268 the JBIG2 coded symbols (shapes) that are represented in the 2269 associated mask layer. 2271 E1.7.2. Required TIFF Fields 2273 This section describes the TIFF fields required, in addition to those 2274 in Sections 8.2, E1.4 and E1.5.2.3. 2276 E1.7.2.1. Baseline Fields 2277 Augment the Section 8.2.1 compression field with JBIG2 (i.e. value = 2278 12) as below: 2280 Compression(259) = 1, 3, 4, 7, 9, 10, 12. SHORT 2281 For Mask layer, see Sections 4.2.1, 5.2.1 and E1.6.2.1. 2282 For Foreground and Background layers, see Sections 6.2.1, 7.2.1 and 2283 E1.6.2.1. Compression=1 is not used by previous profiles. An IFD used 2284 only to specify the default image color for a layer SHALL 2285 not have any encoded image data associated with it, i.e., the 2286 StripByteCounts field SHALL contain a 0. Since no image data exists 2287 in the IFD, the Compression field SHALL be set to 1 indicating no 2288 compression. A Compression field value of 1 is not allowed for any 2289 other IFDs. 2291 E1.7.2.2. Extension Fields 2292 See Section 8.2.2. 2294 E1.7.2.3. New Fields 2295 Augment Section 8.2.3 with the fields from E1.5.2.3. 2297 Bits 2 and 4 of the TIFF-FXExtensions field SHALL be set to 1. 2299 E1.7.3. Recommended TIFF Fields 2301 See Section E1.6.3. 2303 The note that appears at the end of the T88Options[0] table, 2304 prohibiting activation of bits 5 or 6 (i.e. ColourTagsFollow or 2305 ColourTagsPresent respectively) for Profile T SHALL be disregarded. 2307 If the IFD's T88Options[0] field has the ColourTagsFollow or 2308 ColourTagsPresent bits set, then the following segment types SHALL 2309 NOT occur in the JBIG2-coded position block: 2310 - Pattern dictionary 2311 - Halftone region 2312 - Generic region 2313 - Generic refinement region segment 2315 E1.7.4 JBIG2 Shared Data 2316 See Section E1.6.4. 2318 E1.7.5 The Image Strip 2319 See Section E1.6.5. 2321 E1.7.6 Representation of JBIG2 data in TIFF 2322 See Section E1.6.6. 2324 E1.7.7 Colour Tag (Color Symbol) Compression 2326 E1.7.7.1 Why Use Colour Tag Compression 2328 Another opportunity that is afforded by JBIG2 is improved compression 2329 of the foreground layer for documents containing colored text. In 2330 most cases, if a document contains text, each individual text 2331 character is a single, flat, color (e.g., black or red), and the 2332 number of such colors is limited. The foreground layer in this case 2333 looks like a number of colored blobs, one for each character, each 2334 one having the shape of the corresponding character. This foreground 2335 layer can be compressed using a new method that takes advantage of 2336 the JBIG2 structure. If the mask layer is compressed using JBIG2 2337 symbols, then decoding it essentially yields a sequence of 2338 (XPosition, YPosition, Symbol ID) triples. Each triple indicates that 2339 the symbol (from some dictionary) specified by "Symbol ID" SHOULD be 2340 drawn at the location "(X, Y)". Simply augmenting a text region 2341 triple with a fourth component, the color of that individual 2342 character (the symbols "colour tag"), allows storage of the 2343 foreground layer in a very small amount of space, using run-length 2344 coding on those colors. The total space taken by the foreground layer 2345 can be small in comparison to an encoded contone image. 2347 E1.7.7.2 Colour Tag Terms of Use in TIFF 2349 Colour tags are one of the JBIG2 image strip extensions referenced in 2350 Section E1.6.5 (The JBIG2 Image Strip). Their Representation within 2351 the image strip is expressed within Section E1.6.5.1 (Image Strip 2352 Format). Stepping back and considering the MRC (Mixed Raster Content) 2353 mask (bi-level data) and foreground (color data) layer pairs, we 2354 arrive at the following terms of use to be applied when colour 2355 tagging is used in foreground representation: 2357 1. the (JBIG2-compressed) bi-level data (position block) SHALL be 2358 followed immediately (in the file) by the colour tags. The 2359 colour tags SHALL appear as an extension in the JBIG2 image 2360 strip, with the image strip extension type = 1 (colour tags, as 2361 defined in Section E1.6.5.1). The colour tags SHALL be 2362 compressed using ITU-T Rec. T.45. 2363 2. the mask IFD points to the start of the bi-level data, and the 2364 associated byte count SHALL include ONLY the bi-level data (the 2365 position block, but not the colour tags). The IFD's Compression 2366 field SHALL be set to 12 (JBIG2). If present, the T88Options[0] 2367 field SHOULD have bit 5 set to 1 (ColourTagsFollow). 2368 3. the foreground IFD points to the bi-level data, and the 2369 associated byte count SHALL include BOTH the bi-level data and 2370 the colour tag extension. The IFD's Compression field SHALL be 2371 set to 12 (JBIG2). The IFD's PhotometricInterpretation SHALL 2372 indicate the color space used to interpret the colors found in 2373 the colour tag data. If present, the T88Options[0] field SHOULD 2374 have bit 6 set to 1 (ColourTagsPresent). 2375 4. in the event that two symbol instances overlap, the 2376 reconstructed image SHOULD be the one obtained by drawing each 2377 JBIG2 symbol with the appropriate color, where the drawing SHALL 2378 be done in the order that the JBIG2 symbols appear in the 2379 encoded JBIG2 image strip. 2380 Thus, the foreground IFD completely describes an image: it points to 2381 enough data to reconstruct a colored image that contains the right 2382 color at each pixel selected by the mask. It is reasonable that a 2383 decoder will recognize that both a mask IFD and a foreground IFD 2384 point to the same JBIG2 data, and decode the JBIG2 data only once 2385 (not once for the mask, and again for the foreground). The 2386 T88Options[0] bits "ColourTagsFollow" and "ColourTagsPresent" are 2387 designed to make the decoder's job easier: if it sees 2388 ColourTagsFollow in the T88Options[0] field of a mask IFD, it knows 2389 it should defer decoding it until it decodes the corresponding 2390 foreground IFD. 2392 Similarly, if it sees ColourTagsPresent in a foreground IFD, then it 2393 can optimize the drawing/decoding operations. 2395 Note: This representation has two pointers to the same part of the 2396 TIFF-FX file, which is a violation of a TIFF guideline, and could 2397 conceivably cause problems in some unsuspecting TIFF editors. 2398 However, these unsuspecting TIFF editors would probably not be able 2399 to decode the JBIG2 data anyway. The shared pointers occur only in a 2400 restricted case. 2402 The nature of the two pointers is illustrated below: 2404 +----------------------------+ 2405 | | 2406 | | 2407 | | 2408 | | 2409 +----------------------------+ 2410 | ... | 2411 | SubIFD 0 StripOffsets |--: 2412 | StripByteCounts|--|-: 2413 | ... | | | mask IFD's 2414 +----------------------------+ | | StripByteCounts 2415 | | | | includes only 2416 :---|------------<---------------|--: | bi-level data 2417 | | | | 2418 mask and | +----------------------------+<---:<--: 2419 foreground :-->| JBIG2 Symbols & | | | foreground IFD's 2420 IFD both | | data positions | | | StripByteCounts 2421 point to | | _______________ |<---: | includes both 2422 bi-level | | Colour Tag extension | | bi-level data and 2423 data | +----------------------------+ <--: colour tags 2424 | | | | 2425 :---|------------<---------------|--: | 2426 | | | | 2427 +----------------------------+ | | 2428 | ... | | | 2429 | SubIFD 1 StripOffsets |--: | 2430 | StripByteCounts|--------: 2431 | ... | 2432 +----------------------------+ 2433 | | 2434 | | 2435 | | 2436 | | 2437 | | 2438 | | 2439 +----------------------------+ 2441 E1.7.8 Rules and Requirements for Images 2443 Revise the identified Profile M Section 8.4 Rules and Requirements 2444 for Images as follows: 2445 a. Revise Rule 1 to read: 2446 1. If more than one layer exists, then the binary Mask layer SHALL 2447 be present and be the primary image. The Mask layer SHALL 2448 support the binary data representations defined in Section 3 2449 and MAY support the binary data representations defined in 2450 Sections 4, 5 and E1.6, with the exception that 2451 PhotometricInterpretation SHALL be 0. If only one layer exists, 2452 then the image corresponding to that layer is the primary 2453 image. 2455 b. Revise Rule 3 to read: 2456 3. The Background and Foreground images SHALL support the color 2457 representations defined in Section 6 and MAY support the color 2458 representations defined in Sections 7 or E1.7. 2460 E1.7.9. JBIG2 Extension of Profile M Summary 2462 Recommended fields are shown with an asterisk * 2464 Required fields or values are shown with a double asterisk **. If the 2465 double asterisk is on the field name, then all the listed values are 2466 required of implementations; if the double asterisks are in the 2467 Values column, then only the values suffixed with a double asterisk 2468 are required of implementations. 2470 +------------------+-----------------------------------------+ 2471 | Baseline Fields | Values | 2472 +------------------+-----------------------------------------+ 2473 | BitsPerSample | 1**: binary mask | 2474 | | 2-8**: bits per color sample for FG/BG | 2475 | | 9-16: optional 12 bits/sample | 2476 +------------------+-----------------------------------------+ 2477 | Compression | 1: None (ImageBaseColor IFD only) | 2478 | | 3**: Modified Huffman and Modified Read | 2479 | | (mask layer) | 2480 | | 4: Modified Modified Read | 2481 | | 7**: JPEG (FG/BG layers) | 2482 | | 9: JBIG, per T.85 | 2483 | | 10: JBIG, per T.43 | 2484 | | 12**: JBIG2, per T.88 (Note that T.45 | 2485 | | Run-length Colour Encoding is also| 2486 | | required for FG/BG layers) | 2487 +------------------+-----------------------------------------+ 2488 | DateTime* | {ASCII): date/time in the 24-hour format| 2489 | | "YYYY:MM:DD HH:MM:SS" | 2490 +------------------+-----------------------------------------+ 2491 | FillOrder** | 1: Most significant bit first | 2492 | | 2: Least significant bit first | 2493 +------------------+-----------------------------------------+ 2494 | ImageDescription*| {ASCII}: A string describing the | 2495 | | contents of the image. | 2496 +------------------+-----------------------------------------+ 2497 | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | 2498 | | 2592, 3072, 3456, 3648, 4096, 4864 | 2499 +------------------+-----------------------------------------+ 2500 | ImageLength** | n: total number of scanlines in image | 2501 +------------------+-----------------------------------------+ 2502 +------------------+-----------------------------------------+ 2503 | NewSubFileType** | 16, 18: | 2504 | | Bit 1 indicates single page of a multi- | 2505 | | page document on Primary IFD | 2506 | | Bit 4 indicates MRC model | 2507 +------------------+-----------------------------------------+ 2508 | Orientation | 1**-8, Default 1 | 2509 +------------------+-----------------------------------------+ 2510 | PhotometricInter | 0**: WhiteIsZero (Mask layer) | 2511 | pretation | 2: RGB | 2512 | | 5: CMYK | 2513 | | 10**: ITULAB (FG/BG layers) | 2514 +------------------+-----------------------------------------+ 2515 | ResolutionUnit** | 2: inch | 2516 +------------------+-----------------------------------------+ 2517 | RowsPerStrip | n: number or scanlines per strip | 2518 +------------------+-----------------------------------------+ 2519 | SamplesPerPixel | 1**: L* (lightness) | 2520 | | 3: RGB, LAB, CMY | 2521 | | 4: CMYK | 2522 +------------------+-----------------------------------------+ 2523 | Software* | {ASCII}: name & release number of | 2524 | | creator software | 2525 +------------------+-----------------------------------------+ 2526 | StripByteCounts**| : number or bytes in each strip | 2527 +------------------+-----------------------------------------+ 2528 | StripOffsets** | : offset from beginning of file to | 2529 | | each TIFF strip | 2530 +------------------+-----------------------------------------+ 2531 | XResolution | 100, 200**, 300, 400 (written in | 2532 | | pixels/inch) | 2533 +------------------+-----------------------------------------+ 2534 | YResolution | equal to XResolution (pixels SHALL be | 2535 | | square) | 2536 +------------------+-----------------------------------------+ 2537 | Extension Fields | 2538 +------------------+-----------------------------------------+ 2539 | T4Options | 0**: required if Compression is Modified| 2540 | | Huffman, EOLs not byte aligned | 2541 | | 1: required if Compression 2D Modified | 2542 | | Read, EOLs are not byte aligned | 2543 | | 4**: required if Compression Modified | 2544 | | Huffman, EOLs byte aligned | 2545 | | 5: required if Compression 2D Modified | 2546 | | Read, EOLs are byte aligned | 2547 +------------------+-----------------------------------------+ 2548 | T6Options | 0: required if Compression is 2D | 2549 | | Modified Modified Read | 2550 +------------------+-----------------------------------------+ 2551 +------------------+-----------------------------------------+ 2552 | DocumentName* | {ASCII}: name of scanned document | 2553 +------------------+-----------------------------------------+ 2554 | PageNumber** | n, m: page number followed by total page| 2555 | | count | 2556 +------------------+-----------------------------------------+ 2557 | ChromaSubSampling| (1,1), (2, 2)** | 2558 | | (1, 1): equal numbers of lightness and | 2559 | | chroma samples horizontally & vertically| 2560 | | (2, 2): twice as many lightness samples | 2561 | | as chroma horizontally and vertically | 2562 +------------------+-----------------------------------------+ 2563 | ChromaPositioning| 1: centered | 2564 +------------------+-----------------------------------------+ 2565 | Indexed | 0: not a palette-color image | 2566 | | 1: palette-color image | 2567 +------------------+-----------------------------------------+ 2568 | SubIFDs | : byte offset to FG/BG IFDs | 2569 +------------------+-----------------------------------------+ 2570 | XPosition | horizontal offset in primary IFD | 2571 | | resolution units | 2572 +------------------+-----------------------------------------+ 2573 | YPosition | vertical offset in primary IFD | 2574 | | resolution units | 2575 +------------------+-----------------------------------------+ 2576 | New Fields | 2577 +------------------+-----------------------------------------+ 2578 | Decode | minL, maxL, mina, maxa, minb, maxb: | 2579 | | minimum and maximum values for L*a*b* | 2580 +------------------+-----------------------------------------+ 2581 | ImageBaseColor | a, b, c: background color in ITULAB | 2582 +------------------+-----------------------------------------+ 2583 | StripRowCounts | : number of scanlines in each strip | 2584 +------------------+-----------------------------------------+ 2585 | ImageLayer | n, m: layer number, imaging sequence | 2586 | | (e.g., strip number) | 2587 +------------------+-----------------------------------------+ 2588 | T82Options | 0: T.85 profile of T.82 coding | 2589 +------------------+-----------------------------------------+ 2590 | GlobalParameters | IFD: global parameters IFD | 2591 | IFD** | | 2592 +------------------+-----------------------------------------+ 2593 | ProfileType* | n: type of data stored in TIFF file | 2594 +------------------+-----------------------------------------+ 2595 | FaxProfile* | n: ITU-T compatible fax profile | 2596 +------------------+-----------------------------------------+ 2597 | CodingMethods* | n: compression algorithms used in file | 2598 +------------------+-----------------------------------------+ 2599 +------------------+-----------------------------------------+ 2600 | VersionYear* | byte sequence: year of ITU-T standard | 2601 +------------------+-----------------------------------------+ 2602 | ModeNumber* | n: mode of T.44 standard | 2603 +------------------+-----------------------------------------+ 2604 | TIFF-FXExtensions| n: extension(s) identification number, | 2605 | ** | bits 2 and 4 for SharedData and | 2606 | | Profile M SHALL be among the set bits | 2607 +------------------+-----------------------------------------+ 2608 | T88Options* | n, m: option numbers, profile number | 2609 | | - if colour tag is used then bit 1 of n | 2610 | | SHALL NOT be set | 2611 | | - if bit 5 is set then IFD is in mask | 2612 | | layer with colour tag augmented JBIG2 | 2613 | | coded corresponding foreground layer | 2614 | | - if bit 6 is set then IFD is in | 2615 | | foreground layer with colour tag | 2616 | | augmented JBIG2 coding | 2617 +------------------+-----------------------------------------+ 2618 | SharedData** | : offset from beginning of file to | 2619 | | the first Shared Data | 2620 +------------------+-----------------------------------------+ 2622 E1.8. Security Considerations 2624 This document describes a file format for Internet fax, which is a 2625 series of profiles of TIFF for facsimile. As such, it does not create 2626 any security issues not already identified in [TIFF-REG], in its use 2627 of fields as defined in [TIFF]. There is also new TIFF fields 2628 defined within this specification, but they are of a purely 2629 descriptive nature, so that no new security risks are incurred. 2631 Further, the encoding specified in this document does not in any way 2632 preclude the use of any Internet security protocol to encrypt, 2633 authenticate, or non-repudiate TIFF-encoded facsimile messages. 2635 E1.9. References 2637 The following references are appended to the list in Section 11 of 2638 RFC XXXX. 2640 [RFC XXXX] RFC XXXX, Draft Standard "File Format for Internet Fax", 2641 known as TIFF-FX (pending issue) 2643 [T.4 Amd1] Amendment 1 to ITU-T Recommendation T.4, Standardization 2644 of group 3 facsimile apparatus for document transmission, March 2000 2646 [T.44Amd1] Amendment 1 to ITU-T Recommendation T.44, Mixed Raster 2647 Content (MRC), March 2000. 2649 [T.45] ITU-T Recommendation T.45, Run-length Colour Encoding, March 2650 2000. 2652 [T.88] ITU-T Recommendation T.88|ISO/IEC 14492:2000, Information 2653 technology - Lossy/Lossless coding of Bi-level Images. (Commonly 2654 referred to as JBIG2 standard.) 2656 [T.89] ITU-T Draft Recommendation T.89, Application Profiles for 2657 Recommendation T.88 - Lossy/Lossless Coding of Bi-level Images 2658 (JBIG2) for Facsimile, November 2000. 2660 E1.10 Authors' Addresses 2662 Dave Abercrombie Robert Buckley 2663 Xerox Corporation Xerox Corporation 2664 Mailstop PAHV-121 Mailstop 0128-30E 2665 3400 Hillview Ave 800 Phillips Road 2666 Palo Alto, CA 94304, USA Webster, NY 14580, USA 2667 Voice: +1-650-813-6811 Voice: +1-716-422-1282 2668 Fax: +1-650-813-6860 Fax: +1-716-265-8871 2669 Email: aber@pahv.xerox.com Email:rbuckley@crt.xerox.com 2671 Lloyd McIntyre William Rucklidge 2672 Xerox Corporation Intelligent Markets 2673 Mailstop PAHV-121 410 Jessie St., Suite 602 2674 3400 Hillview Ave San Francisco, CA 94103, USA 2675 Palo Alto, CA 94304, USA Voice: +1-415-369-5013 2676 Voice: +1-650-813-6762 Email: wjr@imarkets.com 2677 Fax: +1-650-845-2340 2678 Email: lmcintyre@pahv.xerox.com 2680 Full Copyright Statement 2682 Copyright (C) The Internet Society (2000). All Rights Reserved. 2684 This document and translations of it may be copied and furnished to 2685 others, and derivative works that comment on or otherwise explain it 2686 or assist in its implementation may be prepared, copied, published 2687 and distributed, in whole or in part, without restriction of any 2688 kind, provided that the above copyright notice and this paragraph are 2689 included on all such copies and derivative works. However, this 2690 document itself may not be modified in any way, such as by removing 2691 the copyright notice or references to the Internet Society or other 2692 Internet organizations, except as needed for the purpose of 2693 developing Internet standards in which case the procedures for 2694 copyrights defined in the Internet Standards process must be 2695 followed, or as required to translate it into languages other than 2696 English. 2698 The limited permissions granted above are perpetual and will not be 2699 revoked by the Internet Society or its successors or assigns. 2701 This document and the information contained herein is provided on an 2702 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2703 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2704 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2705 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2706 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.