INTERNET-DRAFT L. McIntyre Fax Working Group Xerox Corporation July 16th, 2000 D. Abercrombie draft-mcintyre-fax-tiff-fx-extension-00.txt Xerox Corporation W. Rucklidge Intelligent Markets July 2000 TIFF-FX Extensions 1 Status of this Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at . A version of this draft document is intended for submission to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. McIntyre et al. Expires January 2001 [Page 0] Internet Draft TIFF-FX Extension 1.0 July 2000 Abstract This document is an internet draft for extensions to TIFF-FX [RFC XXXX], extension set 1. This draft describes extensions to RFC XXXX to enable new features or conditions to TIFF-FX. The features are described by a set of guidelines for all TIFF-FX extensions, and a set of 5 extension types which enable: increased resolutions and image widths, expanding Profile M from 3 layers to N layers, the use of shared resources as a general mechanism for sharing data across images and pages, a binary profile for JBIG2 coding, and an extension to Profile M for JBIG2 and colour tag coding. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in . McIntyre et al. Expires January 2001 [Page 1] Internet Draft TIFF-FX Extension 1.0 July 2000 Table of Contents E1.1 INTRODUCTION.......................................................4 E1.1.1 Scope.........................................................4 E1.1.2. Overview of this draft.......................................5 E1.2. TIFF Fields Required and Recommendations for All TIFF-FX Extensions.......................................................6 E1.2.1. Required Fields..............................................6 E1.2.1.1. GlobalParametersIFD Field................................6 E1.2.2.1. TIFF-FXExtensions Field..................................6 E1.2.2. Recommended Fields...........................................8 E1.2.2.1. FaxProfile Field.........................................8 E1.2.2.2. MultiProfile Field.......................................8 E1.3. TIFF-FX Extension 1: Resolution and ImageWidth Extensions.........9 E1.4. TIFF-FX Extension 2: N-Layer Profile M Extension.................14 E1.4.1. Introduction................................................14 E1.4.2. 8.1. Overview...............................................15 E1.4.3. 8.1.1. MRC 3-layer model....................................15 E1.4.4. 8.1.2. A TIFF Representation for the MRC 3-layer model......16 E1.4.5. 8.2.1. Baseline Fields......................................18 E1.4.6. 8.2.2. Extension Fields.....................................19 E1.4.7. 8.2.3. New Fields...........................................19 E1.4.8. 8.4. Rules and Requirements for Images......................20 E1.4.9. 8.5. Profile M - MRC Fax Profile Summary....................21 E1.5. TIFF-FX Extension 3: Shared Resources Extension to Profile M.....22 E1.5.1. Overview....................................................22 E1.5.2. Required TIFF Fields........................................22 E1.5.3. Recommended Fields..........................................23 E1.5.4. Shared Resources............................................23 E1.5.4.1. Resource Lists..........................................26 E1.5.4.2. Representation of Shared Resources in TIFF..............27 E1.6. TIFF-FX Extension 4: Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile......................................28 E1.6.1. Overview....................................................28 E1.6.2. Required TIFF Fields........................................30 E1.6.3. Recommended TIFF Fields.....................................33 E1.6.4. JBIG2 Resources.............................................35 E1.6.4.1. The JBIG2 Resource......................................36 E1.6.4.2. Decoder Memory..........................................37 E1.6.5. The JBIG2 Image Strip.......................................37 E1.6.5.1. Image Strip Format......................................39 E1.6.6. Representation of JBIG2 data in TIFF........................40 E1.6.7. Rules and Requirements for Images...........................43 E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile Summary.........................................44 McIntyre et al. Expires January 2001 [Page 2] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.7. TIFF-FX Extension 5: JBIG2 Extension of Profile M................46 E1.7.1. Overview....................................................46 E1.7.2. Required TIFF Fields........................................47 E1.7.3. Recommended TIFF Fields.....................................47 E1.7.4. JBIG2 Resources.............................................47 E1.7.5. The Image Strip.............................................48 E1.7.6. Representation of JBIG2 data in TIFF........................48 E1.7.7. Colour Tag (Colour Symbol Compression.......................48 E1.7.7.1. Why use Colour Tag Compression..........................48 E1.7.7.2. Colour Tag Terms of Use in TIFF.........................48 E1.7.8. Rules and Requirements for Images...........................50 E1.7.9. JBIG2 Extension of Profile M Summary........................51 E1.8. Security Considerations..........................................54 E1.9. References.......................................................54 E1.10. Authors' Addresses..............................................55 Full Copyright Statement...............................................55 McIntyre et al. Expires January 2001 [Page 3] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.1. Introduction This document describes extensions to RFC XXXX [RFCXXXX], TIFF-FX (File Format for Internet Fax, or TIFF Fax eXtended), to augment the features and capabilities for the data content and structure generated by the current suite of ITU-T Recommendations for Group 3 facsimile. These Recommendations and the TIFF fields described here support the following new facsimile profile: T: TIFF-FX Extension 4: Black-and-White JBIG2 Extension - a JBIG2 profile for binary data, built upon extensions used for the JBIG2 extension to Profile M (TIFF-FX Extension 5), but with limitations for binary-only data. and create new extensions for the following new features: TIFF-FX Extension 1: Resolution and ImageWidth Extensions - extends the resolutions and image widths available for all Profiles TIFF-FX Extension 2: N-Layer Profile M Extension - extends the 3-layer model into N layers TIFF-FX Extension 3: Shared Resources Extension to Profile M - enables data to be shared among different images and pages; an enabler for compression gains by using JBIG2 encoding TIFF-FX Extension 5: JBIG2 Extension of Profile M - the binary and color extension to Profile M which enables JBIG2 coding using T.88 (JBIG2, binary) and T.45 (colour tag extensions to JBIG2) This extension specification of TIFF-FX for facsimile is known as TIFF-FX Extension 1. E1.1.1 Scope This document defines extensions to RFC XXXX, titled "File Format for Internet Fax", known as TIFF-FX. These extensions add new functionality to the profiles of TIFF-FX, with the exception of Profile S, which is highly constrained. Most of these extensions can be independently used; although some extensions may rely on others. Unless otherwise noted, the primary reference is RFC XXXX "File Format for Internet Fax" (TIFF-FX), which references the following as it's primary references: the current TIFF specification [TIFF] and selected TIFF Technical Notes [TTN1, TTN2]. McIntyre et al. Expires January 2001 [Page 4] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.1.2 Overview of this draft This Section gives an overview of TIFF-FX Extensions 1. Section E1.2 describes the requirements imposed on all TIFF-FX extensions. Sections E1.3 through E1.7 describe the five new extensions. One extension is a new profile, Profile T, and is located in Section E1.4. This section also specifies the ITU-compatible field values (image parameters) for Profile T. Throughout this document, Profiles, and section numbers without an "E1" prefix, refer to RFC XXXX, the pending Draft Standard for TIFF-FX. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ]. McIntyre et al. Expires January 2001 [Page 5] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.2. TIFF Fields Required and Recommendations for All TIFF-FX Extensions E1.2.1. Required Fields E1.2.1.1. GlobalParametersIFD Field Status of the GlobalParametersIFD (GPIFD) is being changed from Recommended to Required, for all extensions. This change is based on the fact that more than one required extensions, such as SharedResources and TIFF-FXExtensions, have global file implications (i.e. apply across multiple pages or Primary IFDs), warranting their location within the GPIFD. Accommodation of these required fields within the GPIFD then requires change in status of the GPIFD to Required. E1.2.1.1.1 Instructions Remove the GlobalParametersIFD filed from Section 2.2.4 "New TIFF fields recommended for fax profiles" and append the following revised definition to Sections 4.2.3, 5.2.3, 6.2.3, 7.2.3 and 8.2.3 "New Fields": GlobalParametersIFD (400) IFD or LONG The GlobalParametersIFD, defined in RFC XXXX Section 2.2.4, is an IFD containing global parameters. It SHALL be present for all TIFF-FX extensions. This reflects a modification to the Section 2.2.4 definition where GlobalParametersIFD is defined as a Recommended field. The RFC XXXX GlobalParametersIFD definition is further modified in that it is permitted to contain fields that are NOT legal in any other IFD. The new SharedResources field is one such field that is not permitted in any other IFD, see the Shared Resources Extension to Profile M below. It is recommended that a TIFF writer place this field in the first IFD, where a TIFF reader would find it quickly. If a conflict exists between fields in the GlobalParametersIFD and in the image IFDs, then the data in the image IFD shall prevail. E1.2.1.2. TIFF-FXExtensions Field The TIFF-FXExtensions field is introduced to be an identification mechanism for all TIFF-FX extensions and SHALL be present when an extension is used. The extensions are identified by bit value assignment, accommodating use of more than one extensions at the same time. The TIFF-FXExtensions field SHALL be placed within the GlobalParametersIFD. E1.2.1.2.1 Instructions Add the TIFF-FXExtensions filed to Sections 4.2.3, 5.2.3, 6.2.3, 7.2.3 and 8.2.3 "New Fields", as defined below: McIntyre et al. Expires January 2001 [Page 6] Internet Draft TIFF-FX Extension 1.0 July 2000 TIFF-FXExtensions (407) LONG Count = 1 [[Note assignment of the 407 tag value has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] This field identifies the RFC XXXX extension(s) that apply to this file. The field accommodates the need to continually enhance the functionality of TIFF-FX since it was issued as a Draft Standard. This field SHALL only appear in the GlobalParametersIFD, it is NOT legal in any other IFD. It is required and SHALL be present with use of any TIFF-FX extension. A value of 1 in a bit location indicates the corresponding TIFF-FX Extension is used. More than one bit set to 1 means more than one TIFF-FX Extension is used in the file. Current TIFF-FX Extensions: +------+-------+-----------------------------------------------------------+ | Bit |Ext. | Meaning | |number|number | | +------+-------------------------------------------------------------------+ | 0 | 1 | Resolution and ImageWidth Extensions | | | | If bit 0 is 1, then any of the X and YResolutions from | | | | 300 x 600 to 1200 x 1200 pixels per resolution | | | | unit, and the corresponding ImageWidths MAY be available. | +------+-------+-----------------------------------------------------------+ | 1 | 2 | N-Layer Profile M Extension | | | If bit 1 is 1, then the provision to use more than three | | | MRC layers SHALL be available. | +------+-------+-----------------------------------------------------------+ | 2 | 3 | Shared Resources Extension to Profile M | | | | If bit 2 is 1, then Profile M and Shared Resources | | | | provisions SHALL be available. | +------+-------+-----------------------------------------------------------+ | 3 | 4 | Profile T - Black-and-White JBIG2 Extension | | | | If bit 3 is 1, then Black-and-White JBIG2 coding SHALL be | | | | available (i.e. Compression = 12, TIFF-FXExtension bit 2 | | | | is set and bilevel constrained MRC model is applied). | +------+-------+-----------------------------------------------------------+ | 4 | 5 | JBIG2 Extension of Profile M | | | | If bit 4 is 1, JBIG2 SHALL be available for Mask layer | | | | coding and colour tags for foreground layers (i.e. | | | | Compression = 12 and TIFF-FXExtension bit 2 is set). | +------+-------+-----------------------------------------------------------+ McIntyre et al. Expires January 2001 [Page 7] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.2.2. Recommended Fields E1.2.2.1. FaxProfile Field The FaxProfile field is revised for two reasons: 1) acknowledge the new MultiProfiles field, specified below, and make provisions for association of the two fields. 2) update the current profiles list to include the new Profile T, specified later in this document. E1.2.2.1.1 Instructions Replace the existing FaxProfile filed in Section 2.2.4 "New TIFF fields recommended for fax profiles" with the following: FaxProfile(402) = 0 - 7, 255. BYTE The profile that applies to this file; a profile is a subset of the full set of permitted fields and field values of TIFF for facsimile. This field is used to indicate the profile used within the file when only one profile is used. The MultiProfiles field is used when more than one profiles are used within the file. A FaxProfile value of 255 (X'FF') indicates that the MultiProfiles is used. The currently defined FaxProfile values associated with a profile are: 0: does not conform to a profile defined for TIFF for facsimile 1: minimal black & white lossless, Profile S 2: extended black & white lossless, Profile F 3: lossless JBIG black & white, Profile J 4: lossy color and grayscale, Profile C 5: lossless color and grayscale, Profile L 6: Mixed Raster Content, Profile M 7: lossy and lossless JBIG2 black & white, Profile T E1.2.2.2. MultiProfiles Field This field makes provision to signal the use of two or more different encoding profiles in the processing of a single file. RFC XXXX makes no statement with regard to the appropriateness of using encodings of two or more different profiles within a file. There is no question as to the value of such a provision. This is illustrated by an example where the first ten black-and-white text pages of a fifteen page document are processed using Profile F MMR (G4) encoding while the last five colour pages are processed using Profile C JPEG encoding. The existing FaxProfile field is used within the file to signal one encoding profile. In response to requests received from implementors, this extension introduces the MultiProfiles field, to be used when more than one profile is used within a file. McIntyre et al. Expires January 2001 [Page 8] Internet Draft TIFF-FX Extension 1.0 July 2000 Files containing more that one profile SHOULD contain the MultiProfiles field, identifying the profiles present. When present, the MultiProfiles field SHALL reside within the GlobalParameterIFD. The number of profiles present within a file is ambiguous without the MultiProfiles or FaxProfile field. It is highly likely that readers of files without the MultiProfiles or FaxProfile will assume that only one profile is present, the profile that is consistent with the Compression type and other relevant values that are present within the first IFD. Such readers may experience difficulty if different Compression types and/or other relevant parameters are encountered in subsequent IFDs within the file. E1.2.2.2.1 Instructions a) Append the new MultiProfiles field, specified below, to Section 2.2.4 "New TIFF fields recommended for fax profiles" following the ModeNumber field: MultiProfiles(406) LONG Count = 1 [[Note assignment of the 406 tag value has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] The profiles that apply to this file; a profile is a subset of the full set of permitted fields and field values of TIFF for facsimile. This field is used when more than one profiles are used within the file. This field SHALL only be present when the FaxProfile field has a value of 255 (X'FF'). A value of 1 in a bit location indicates the corresponding profile is used. The currently defined bits are: Bit 0: minimal black & white lossless, Profile S Bit 1: extended black & white lossless, Profile F Bit 2: lossless JBIG black & white, Profile J Bit 3: lossy color and grayscale, Profile C Bit 4: lossless color and grayscale, Profile L Bit 5: Mixed Raster Content, Profile M Bit 6: lossy and lossless JBIG2 black & white, Profile T Bits 7-31: reserved for future use. WARNING: Files containing more that one profiles "SHOULD" contain the MultiProfiles field, identifying the profiles present. The number of profiles present within a file is ambiguous without the MultiProfiles or FaxProfile field. It is highly likely that readers of files without the MultiProfiles or FaxProfile will assume that only one profile is present, the profile that is consistent with the Compression type and other relevant values that are present within the first IFD. Such readers may experience difficulty if different Compression types and/or other relevant parameters are encountered in subsequent IFDs within the file. McIntyre et al. Expires January 2001 [Page 9] Internet Draft TIFF-FX Extension 1.0 July 2000 b) Append the new 4.5.7 "Multiple Profiles within a file" section, specified below, to Section 4.5 "Implementation Warnings" following Section 4.5.6: 4.5.7 Multiple Profiles within a file Files containing more that one profile "SHOULD" contain the MultiProfiles field, identifying the profiles present. The number of profiles present within a file is ambiguous without the MultiProfiles or FaxProfile field. It is highly likely that readers of files without the MultiProfiles or FaxProfile will assume that only one profile is present, the profile that is consistent with the Compression type and other relevant values that are present within the first IFD. Such readers may experience difficulty if different Compression types and/or other relevant parameters are encountered in subsequent IFDs within the file. E1.3. TIFF-FX Extension 1: Resolution and ImageWidth Extensions The ITU-T has approved a new set of X and YResolutions, along with corresponding image widths (i.e. page widths). This extension makes provisions for using these extended resolutions. The TIFF-FXExtensions field, below, SHALL be present when this extension is used. TIFF-FXExtensions (407) bit 0 is 1 LONG See Section E1.2.1.2. E1.3.1 Instructions a) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields required for all fax profiles" XResolution field with the following: The ITU-T Recommendations for facsimile specify a small number of horizontal resolutions: 100, 200, 300, 400, 600, 1200 pixels per inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per inch). b) Replace the 2nd sentence of Section 2.2.2 "Additional TIFF fields required for all fax profiles" YResolution field with the following: The ITU-T Recommendations for facsimile specify a small number of vertical resolutions: 100, 200, 300, 400, 600, 800, 1200 pixels per inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). c) Append the following five rows to the resolution table that follows the YResolution field in Section 2.2.2 "Additional TIFF fields required for all fax profiles": McIntyre et al. Expires January 2001 [Page 10] Internet Draft TIFF-FX Extension 1.0 July 2000 +--------------+--------------+--------------+--------------+ | 300 | | 600 | | +--------------+--------------+--------------+--------------+ | 600 | | 600 | | +--------------+--------------+--------------+--------------+ | 400 | | 800 | | +--------------+--------------+--------------+--------------+ | 600 | | 1200 | | +--------------+--------------+--------------+--------------+ | 1200 | | 1200 | | +--------------+--------------+--------------+--------------+ d) Replace the ImageWidth field in Section 4.2.1. "Baseline fields" with the following: ImageWidth(256) SHORT or LONG RequiredByTIFFBaseline This profile supports the following fixed page widths: 1728, 2592, 3456, 5184, 10368 (corresponding to North American Letter and Legal, ISO A4 paper sizes), 2048, 3072, 4096, 6144, 12288 (corresponding to ISO B4 paper size), and 2432, 3648, 4864, 7296, 14592 (corresponding to ISO A3 paper size). No default; must be specified NOTE: Historical TIFF-F did not include support for the following widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096, 4864, 5184, 6144, 7296, 10368, 12288 and 14592. Historical TIFF-F documents also included the following values related to A5 and A6 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 documents are no longer supported in Group 3 facsimile, so the related width values are now obsolete. See section 4.5.2 for more information on inch/metric equivalencies and other implementation details. e) Replace the XResolution field in Section 4.2.1. "Baseline fields" with the following: XResolution(282) = 200, 204, 300, 400, 408, 600, 1200 RATIONAL RequiredByTIFFBaseline The horizontal resolution of the image is expressed in pixels per resolution unit. In pixels/inch, the allowed values are: 200, 204, 300, 400, 408, 600 and 1200. See Section 2.2.2 for inch-metric equivalency. No default, must be specified NOTE: The values of 200 and 408, 600 and 1200 have been added to the Historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 80 pixels/cm, which is equivalent to 204 pixels per inch. See section 4.5.2 for information on implementation details. McIntyre et al. Expires January 2001 [Page 11] Internet Draft TIFF-FX Extension 1.0 July 2000 f) Replace the YResolution field in Section 4.2.1. "Baseline fields" with the following: YResolution(283) = 98, 100, 196, 200, 300, 391, 400, RATIONAL 600, 800 and 1200 RequiredByTIFFBaseline The vertical resolution of the image is expressed in pixels per resolution unit. In pixels/inch, the allowed values are: 98, 100, 196, 200, 300, 391, 400, 600, 800 and 1200 pixels/inch. See Section 2.2.2 for inch-metric equivalency. No default, must be specified NOTE: The values of 100, 200, 391, 600, 800 and 1200 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77 and 38.5 (cm), which are equivalent to 196 and 98 pixels per inch respectively. See section 4.5.2 for more information on implementation details. NOTE: Not all combinations of XResolution, YResolution and ImageWidth are legal. The following table gives the legal combinations and corresponding paper size [T.30]. g) Replace the Resolution and ImageWidth table that follows YResolution in Section 4.2.1. "Baseline fields" with the following: +--------------------------------+---------------------------+ | XResolution x YResolution | ImageWidth | +--------------------------------+---------+--------+--------+ | 200x100, 204x98 | | | | | 200x200, 204x196 | 1728 | 2048 | 2432 | | 204x391 | | | | +--------------------------------+---------+--------+--------+ | 300 x 300, 300 x 600 | 2592 | 3072 | 3648 | +--------------------------------+---------+--------+--------+ | 408 x 391, 400 x 400 | 3456 | 4096 | 4864 | | 400x800 | | | | +--------------------------------+---------+--------+--------+ | 600 x 600, 600 x 1200 | 5184 | 6144 | 7296 | +--------------------------------+---------+--------+--------+ | 1200 x 1200 | 10368 | 12288 | 14592 | +--------------------------------+---------+--------+--------+ |Letter,A4| B4 | A3 | | Legal | | | +---------+--------+--------+ | Paper Size | +---------------------------+ McIntyre et al. Expires January 2001 [Page 12] Internet Draft TIFF-FX Extension 1.0 July 2000 h) Replace the ImageWidth field in Section 6.2.1. "Baseline Fields" with the following: ImageWidth(256). SHORT or LONG This profile supports the following fixed page widths: 864, 1024, 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864, 5184, 6144, 7296, 10368, 12288, 14592. i) Replace the XResolution and YResolution fields in Section 6.2.1. "Baseline Fields" with the following: XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL The resolution of the image is expressed in pixels per resolution unit. In pixels per inch, allowed XResolution values are: 100, 200, 300, 400, 600 and 1200. The base color fax profile requires the pixels to be square, hence YResolution must equal XResolution. Base resolution is 200 pixels per inch and SHALL be supported by all implementations of this profile. NOTE: The functional equivalence of inch-based and metric-based resolu- tions is maintained, per Annex E.6.5 in [T.4]. See table in Sec. 2.2.2. NOTE: Not all combinations of XResolution, YResolution and ImageWidth are legal. The following table gives the legal combinations for inch- based resolutions and the corresponding paper sizes [T.30]. j) Replace the Resolution and ImageWidth table that follows YResolution in Section 6.2.1. "Baseline fields" with the following: +--------------------------------+---------------------------+ | XResolution x YResolution | ImageWidth | +--------------------------------+---------------------------+ | 100 x 100 | 864 | 1024 | 1216 | +--------------------------------+---------------------------+ | 200 x 200 | 1728 | 2048 | 2432 | +--------------------------------+---------------------------+ | 300 x 300 | 2592 | 3072 | 3648 | +--------------------------------+---------------------------+ | 400 x 400 | 3456 | 4096 | 4864 | +--------------------------------+---------------------------+ | 600 x 600 | 5184 | 6144 | 7296 | +--------------+-----------------+---------+--------+--------+ | 1200 x 1200 | 10368 | 12288 | 14592 | +--------------+-----------------+---------+--------+--------+ |Letter,A4| B4 | A3 | | Legal | | | +---------------------------+ | Paper Size | +---------------------------+ McIntyre et al. Expires January 2001 [Page 13] Internet Draft TIFF-FX Extension 1.0 July 2000 k) Replace the XResolution and YResolution fields in Section 7.2.1. "Baseline Fields" with the following: XResolution(282) = 100, 200, 300, 400, 600, 1200. RATIONAL YResolution(283) = 100, 200, 300, 400, 600, 1200. RATIONAL The resolution of the image is expressed in pixels per resolution unit. In pixels per inch, allowed XResolution values are: 100, 200, 300, 400, 600 and 1200. The lossless color fax profile requires the pixels to be square, hence YResolution must equal XResolution. Base resolution is 200 pixels per inch. E1.4. TIFF-FX Extension 2: N-Layer Profile M Extension E1.4.1 Introduction This section defines the N-layer extension to the 3-layer Mixed Raster Content profile or Profile M of TIFF for facsimile. By applying the appropriate black-and-white, bilevel, constraints from Extension 4 (Section E1.6), the N-layer model and rules of this extension may also be applied to Profile T. Often times, the contents of a page can be broken up into more components than a 3-layer representation would allow. For instance, a complex magazine article may do well to have: - a low resolution background image, for a low variance picture. Let's say this is 100 dpi, and is color. - a high resolution mask layer, for the large amount of text and lines. Let's say this is 400 dpi (and binary). - a low resolution foreground image, for the text and line color. Let's say this is 100 dpi, and is color. - several medium resolution, for the pictures that are scattered throughout the page. Let's say they are 200 dpi, and are color. Of these, several may be odd shapes (non-rectangular), and would require a separate mask to select their regions. It would also help to have page regions broken up into many components or objects, which would aid in page editing. The pictures separated from the rest of the page could individually be modified, copied, or removed. Expanding the 3-layer MRC model to N-layers allows for greater complexity of a page content, with the same simplicity in the existing model. This N-layer Profile M Extension is specified by defining specific modifications to the text of Profile M. As a result of the specification method, this extension should be read in conjunction with Profile M. McIntyre et al. Expires January 2001 [Page 14] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.4.2. 8.1. Overview The objective is to change 3-layer to N-layer references. 2nd paragraph - replace the 3rd and 4th sentences with the following: By itself, MRC does not define any new coding methods or resolutions. Instead it defines an N-layer (where N is a positive integer) image model for structuring and combining the scanned image data. The MRC N-layer model has been applied here using the TIFF format to yield a data structure which differs from [T.44] though it applies the same coding methods, uses the same compressed image data streams and is consistent with the TIFF principle of a single IFD per image. E1.4.3. 8.1.1. MRC 3-layer model The objective is to change 3-layer to N-layer references, specify the presence of multiple foreground and mask layers, distinguish role of Primary Mask relative to secondary mask layers and their interactions: a) Title and 1st paragraph - replace the title and paragraph with the following: 8.1.1. MRC N-layer model The N layers of the MRC model are Background (layer 1), Mask (even numbered layers such as 2, 4, 6,..., N-1) and Foreground (odd numbered layers such as 3, 5, 7,..., N) pairs. The Mask and Foreground layers occur in Mask and Foreground pairs (i.e. layers 2 & 3, 4 & 5, 6 & 7, ..., N-1 & N pairs). The odd numbered layers (Background and Foreground) are encoded with multi-level coders while the even numbered layers (Mask) are encoded with bi-level coders. Each layer may appear only once on a page and is coded independently of the other layers. The final image is obtained by using the Mask layers to determine which of the Foreground layer pixels are rendered over the Background layer or composite of layers below the Mask. When the Mask layer pixel value is 1, the corresponding pixel from the corresponding Foreground layer is selected; when it is 0, the corresponding pixel from the Background layer or composite of layers below the Mask is selected. Details are given in the Introduction and in Annex A of [T.44]. b) 4th paragraph - replace with the following: Not all pages, and not all parts of a page, require 3 or more layers. If a page consists of only one layer, then that layer is the primary image whether it is a Background, Mask, or Foreground layer. If there is more than one layer, then the Primary Mask (layer 2) must be one of the layers, in which case it is the primary image. In all cases, the primary image must be page size. McIntyre et al. Expires January 2001 [Page 15] Internet Draft TIFF-FX Extension 1.0 July 2000 c) 5th paragraph, 1st sentence - replace with the following: MRC [T.44] allows a page to be transmitted as a series of stripes with each stripe consisting of 1, 2, 3 or N layers. d) 6th paragraph - replace with the following: Furthermore, color fax also requires the spatial resolutions of Background and Foreground images to be legal fax values that are also integer factors of the Primary Mask image resolution. For example, if the Primary Mask Layer resolution is 400 pixels per inch, then allowed resolutions for the Foreground, Background and secondary Mask (layers 2, 4, 6, ..., N-1) layers are 100, 200 or 400 pixels per inch; if the Primary Mask is at 300 pixels per inch, then allowed values are 100 and 300. The Foreground, Background and secondary Mask layer resolutions can be independently set of each other. E1.4.4. 8.1.2. A TIFF Representation for the MRC 3-layer model The objective is to change 3-layer to N-layer references, specify multiple foreground and mask layers, define their IFD and SubIFD relationships and structural layout: a) Title and 1st paragraph - replace the title and paragraph with the following: 8.1.2. A TIFF Representation for the MRC N-layer model In the TIFF representation of the N-layer MRC model, each page is represented by a single IFD, called the Primary IFD. The nextIFD offset associated with a Primary IFD will point to the Primary IFD of the next page. If the page consists of a single layer, then the Primary IFD represents that layer. If more than one layer is present, the Primary IFD represents the Primary Mask layer and the other layers are represented by a set of child IFDs that are referenced through the SubIFD extension field [TTN1] of the Primary IFD. To distinguish MRC- specific SubIFDs from other SubIFDs, the NewSubFileType field MUST have Bit 4 ON, indicating an MRC-related IFD. A new ImageLayer field is also introduced that consists of two values that identify the layer (Background [layer 1], Mask [layer 2, 4, 6, ..., N-1], or Foreground [layer 3, 5, 7, ..., N]) and the order within the layer (first, second, ... image of the layer); see Section 8.2.3. b) 5th paragraph, last sentence - replace the sentence with the following: In all cases, if the Primary Mask layer exists, it shall be represented by a single IFD and a single set of coding parameters. McIntyre et al. Expires January 2001 [Page 16] Internet Draft TIFF-FX Extension 1.0 July 2000 c) 6th paragraph, first 3 sentences - replace the sentences with the following: The use of SubIFDs to store child IFDs is described in [TTN1]. When a Mask is the primary image, the Background and Foreground layer images are represented with child IFDs that are referenced by the SubIFDs field in the Primary IFD. There are many possible ways to represent the Background and Foreground layer images: (1) the SubIFD field of the Primary IFD is an array of pointers to all child image IFDs, one entry per child image; (2) the SubIFD field is a single pointer to a linked list of all child image IFDs; (3) the SubIFD field is an array of N-1 pointers, where the first pointer is to a linked list of all Background layer (layer 1) image IFDs, the second pointer is to a linked list of all the first Foreground layer (layer 3) image IFDs, the third pointer is to a linked list of all the second Mask layer (layer 4) IFDs, the N-1 pointer is to a linked list of all the Nth layer IFDs. d) IFD - SubIFD tree diagram that follows the 6th paragraph - replace the tree diagram with the following: (nextIFD) PRIMARY IFD PAGE 0 --------------------------> PRIMARY IFD PAGE 1--> ... ImageLayer = [2,1] NewSubFileType = 18 SubIFD[0] --------------- SubIFD[1] ----- ... ----- SubIFD[N-2] | | | V V V Child IFD Child IFD Child IFD ImageLayer = [1,1] ImageLayer = [3,1] ImageLayer = [N,1] NewSubFileType = 16 NewSubFileType = 16 NewSubFileType = 16 | | | |(nextIFD) |(nextIFD) |(nextIFD) V V V Child IFD Child IFD Child IFD ImageLayer = [1,2] ImageLayer = [3,2] ImageLayer = [N,2] NewSubFileType = 16 NewSubFileType = 16 NewSubFileType = 16 | | | |(nextIFD) |(nextIFD) |(nextIFD) V V V Child IFD Child IFD Child IFD ImageLayer = [1,3] ImageLayer = [3,3] ImageLayer = [N,3] NewSubFileType = 16 NewSubFileType = 16 NewSubFileType = 16 | | | |(nextIFD) |(nextIFD) |(nextIFD) V V V 0 0 0 McIntyre et al. Expires January 2001 [Page 17] Internet Draft TIFF-FX Extension 1.0 July 2000 e) Last paragraph, last sentence - replace the sentence with the following: If the image data is not ITU L*a*b*, the ImageBaseColor is interpreted as 8-bit ITU L*a*b*; see Section 8.2.3. E1.4.5. 8.2.1. Baseline Fields The objective is to reflect presence of the multiple foreground and mask layers and the distinct Primary Mask layer in some tags and specify the impact of have no image data in the multiple mask and foreground layer pairs. a) ImageWidth - replace with the following: ImageWidth(256). SHORT or LONG Same page widths as Profile C, the base color profile; see Section 6.2.1. In Profile M, the width of an image (i.e. Foreground, Background, or Mask layer) in the coded data stream may be less than the page width, unless the Background, Foreground or Mask is the primary image (i.e. the Primary IFD), in which case the width of the coded data stream is the page width. The ImageWidth field will always store the actual width of the coded data. b) Compression - replace the first sentence with the following: For Mask layers, see Sections 4.2.1 and 5.2.1 c) PhotometricInterpretation - replace with the following: PhotometricInterpretation(262) = 0, 2, 5, 10. SHORT For Mask layers, 0. For Foreground and Background layers, see Sections 6.2.1 and 7.2.1. d) StripByteCounts - replace the tag with the following: StripByteCounts(279) SHORT or LONG In Profile M, it is permissible for the StripByteCounts value for a given strip, other than one corresponding to a Primary Mask, to have a zero entry. This means there is no encoded image data corresponding to that strip. Instead, for the Foreground or Background layers the current default image color should be used for the strip. The standard default image colors are black for the Foreground layer and White for the Background layer. The ImageBaseColor field can be used to specify other default colors, see 8.2.3. Since the absence of a mask layer, other than a Primary Mask, defaults to selecting the corresponding foreground layer, a zero-byte mask strip equates to a missing portion of the mask layer. In which case, the foreground is selected for that region.e) YResolution - replace the last sentence with the following: McIntyre et al. Expires January 2001 [Page 18] Internet Draft TIFF-FX Extension 1.0 July 2000 The resolution of Mask, Background and Foreground layers must each be an integer factor of the Primary image, which is the Primary Mask layer, when it is present; see Section 8.4. E1.4.6. 8.2.2. Extension Fields The objective is to reflect presence of the multiple mask layers. a) T6Options - replace the tag with the following: T6Options(293) = 0. SHORT For Mask layers, see Section 4.2.2. E1.4.7. 8.2.3. New Fields The objective is to reflect presence of the multiple mask and foreground Layers, their impact on the ImageLayer tag and resulting extension of the ImageLayer[0] field values. The newly required TIFF-FXExtension tag and minimal bit setting is specified. a) T82Options - replace the tag with the following: T82Options(435) LONG For Mask layers, see Section 5.2.3. b) ImageLayer - replace the tag, descriptive paragraph and ImageLayer[0] field with the following: ImageLayer (34732). LONG Count = 2 Image layers are defined such that layer 1 is the Background layer. Layers above layer 1 are arranged in mask (i.e. even numbered layers) and foreground (i.e. odd numbered layers) pairs. The mask selects pixels from the associated foreground that will be rendered on top of the Background or composite of layers below the mask. For example, layer 2 (i.e. the Primary Mask or first mask layer) selects pixels from layer 3 (i.e. the first foreground layer) that will be rendered on top of the Background. Layer 4 (i.e. the second mask layer) selects pixels from layer 5 (i.e. the second foreground layer) that will be rendered on top of the composite of layers 1 through 3 below. The ImageLayer tag contains two values, describing the layer to which the image belongs and the order in which it is imaged. McIntyre et al. Expires January 2001 [Page 19] Internet Draft TIFF-FX Extension 1.0 July 2000 ImageLayer[0] = 1, 2, 3, ..., N. 1: Image is a Background image, i.e., the image that will appear whenever the Primary Mask contains a value of 0. Background images typically contain low-resolution, continuous-tone imagery. 2: Image is the Primary Mask layer. In MRC, if more than one layer is present then the Primary Mask layer (layer 2) is present, it must be the Primary IFD and be full page in extent. 3: Image is the first Foreground image, i.e., the image that will appear whenever the Primary Mask contains a value of 1. The Foreground image generally defines the color of text or lines, but may also contain high-resolution imagery. 4: Image is the second Mask layer (layer 4). 5: Image is the second Foreground image (layer 5), i.e., the image that will be rendered on top of the composite of layers 1 through 3 below whenever the second Mask contains a value of 1. N-1: Image is the (N-1)/2 Mask layer. N: Image is the (N-1)/2 Foreground image, i.e., the image that will be rendered on top of the composite of layers N-2 below whenever the (N-1)/2 Mask contains a value of 1. TIFF-FXExtensions (407) bit 1 is 1 LONG See Section E1.2.1.2. E1.4.8. 8.4. Rules and Requirements for Images The objective is to reflect presence and impact of the multiple mask and Foreground layers and the Primary IFD role in rules 1, 4, 8 and 9. a) Replace the introductory sentence, along with rules 1, 4, 8 and 9 with the following: Profile M defines a fundamental set of rules for images in the N-layer representation. The rules, with the appropriate black-and-white (bilevel) constraints, also apply to Profile T. 1. If more than one layer exists, then the a binary Mask layer SHALL be present and the first mask layer SHALL be the primary image. Mask layers SHALL support the binary data representations defined in Section 3 and MAY support the binary data representations defined in Sections 4, 5 and E1.6, with the exception that PhotometricInterpretation SHALL be 0. If only one layer exists, then the image corresponding to that layer is the primary image. 4. Images other than the Primary Image (i.e. Primary IFD) MAY optionally cover only a portion of the strip or page. McIntyre et al. Expires January 2001 [Page 20] Internet Draft TIFF-FX Extension 1.0 July 2000 8. In MRC Internet Fax, each layer is transmitted as a sequence of strips. If the page consists of a single layer, then all strips shall be stored in the single Primary IFD. In this case, coding parameters cannot change between strips. If the page consists of more than one layer, then all strips of the Primary Mask layer shall be stored in the single Primary IFD. All strips of the Foreground/Background layers SHALL be stored in separate IFDs, referenced by the Primary IFD's SubIFD field, containing an ImageLayer field with ImageLayer[0] identifying Background (layer 1), Foreground layers (layer 3, 5, 7, ..., N) or mask layers (layer 2, 4, 6, ..., N-1), and Imagelayer[1] identifying order in which images within a single layer are to be imaged. The TIFF XPosition and Yposition fields are used to indicate the placement of these images with respect to the primary image. 9. When the Primary Mask image is present, the resolution of Background, Foreground and secondary mask images must each be an integer factor of the Primary Mask image. For example, if the Primary Mask image is 400 pixels/inch, then the Background, Foreground or secondary mask images may be at 400 pixels/inch (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). E1.4.9. 8.5. Profile M - MRC Fax Profile Summary The objective is to identify the secondary mask layers as being among the data blocks pointed to by the SubIFD offsets, reflect the required status of the GlobalParametersIFD, append the required TIFF-FXExtensions tag to the table and callout the need to activate the N-Layer Profile M Extension bit. a) Replace the introductory sentence, along with rules 1, 4, 8 and 9 with the following: Revise the following Section 8.5 table entries to read as shown: +------------------+-----------------------------------------+ | SubIFDs | : byte offset to FG, BG, | | | or secondary mask IFDs | +------------------+-----------------------------------------+ +------------------+-----------------------------------------+ | GlobalParameters | IFD: global parameters IFD | | IFD** | | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 21] Internet Draft TIFF-FX Extension 1.0 July 2000 Append the following to Section 8.5 table: +------------------+-----------------------------------------+ | TIFF-FXExtensions| n: extension(s) identification number, | | ** | bit for N-Layer Profile M Extension | | | shall be among the set bits | +------------------+-----------------------------------------+ E1.5. TIFF-FX Extension 3: Shared Resources Extension to Profile M This section defines the Shared Resources extension to Profile M. Shared Resources accommodates a single representation of redundant resources, such as image data or encoding tables that appear multiple times within a document. Most importantly, it provides a mechanism for access to the redundant resources by multiple components (i.e. sharing) within the encoding process. The sharing of resources is a new encoding provision defined in ITU-T Rec. T.44 Annex B [T.44Amd1]. The T.44 MRC standard references this provision as Shared Data. Shared Resources is the terminology used in this document. As in T.44, use of Shared Resources is restricted to the MRC structure defined in Profile M and its N-layer Extension, defined in this document. E1.5.1. Overview Many pages and/or documents have repeating components such as shapes or symbols, words, images and meta-data (e.g. JPEG Huffman Tables). This is especially true for images of text, where the repeating shapes are the characters themselves. The SharedResources field, which references Shared Resource Tables that contain Shared Resource Entries, are defined below to leverage the redundancy of these repeating components by storing each component once, and then referring to each stored component as many times as possible. E1.5.2. Required TIFF Fields This section describes the TIFF fields required, in addition to those in Section 8.2, to represent Shared Resources. E1.5.2.1. Baseline Fields See Section 8.2.1. E1.5.2.2. Extension Fields See Section 8.2.2. McIntyre et al. Expires January 2001 [Page 22] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.5.2.3. New Fields Append the following to the fields of 8.2.3: GlobalParametersIFD (400) IFD or LONG See Section E0.2. TIFF-FXExtensions (407) bit 2 SHALL be 1 LONG See Section E0.2. SharedResources (437) LONG [[Note assignment of the 437 tag value has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] See Section E1.5.4. E1.5.3. Recommended TIFF Fields See Sections 8.3, with exception of GlobalParametersIFD. E1.5.4 Shared Resources The following new field is defined: SharedResources (437) LONG Count = 1 [[Note assignment of the 437 tag value has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] The SharedResources field contains the file location (E) of the first Shared Resource Table. Each Shared Resource Table contains a count of the number of Shared Resource Entries that physically exist in the table (whether filled with a shared resource or not) , the Shared Resource Entries themselves, and the file location of the next Shared Resource Table (if any). There can be as many Shared Resources Tables as necessary to describe the number of shared resource items, but there SHALL be only one SharedResources field in a file, and it SHALL be attached to the GlobalParametersIFD (recommended to be attached to the first IFD in the file). The SharedResources field is required when sharing resources and SHALL be present. Each Shared Resources Table consists of a 2-byte count of the number of physical entries, a sequence of 16-byte shared resource entries, and a 4- byte offset to the next Shared Resources Table. The last shared resources table has a "next table file offset" of 0. McIntyre et al. Expires January 2001 [Page 23] Internet Draft TIFF-FX Extension 1.0 July 2000 NOTE: In all the tables shown below, all multi-byte quantities are written/read in the endianness convention established by the TIFF file ("II" or "MM"). Shared Resources Table +-----+--------------+-----+-------------------------------------------+ |Bytes| Byte offsets |Type | Description | +-----+--------------+-----+-------------------------------------------+ | 2 | E - E+1 |SHORT|Items in table - (i) The number of shared | | | | |resource entries that are physically in | | | | |this table, whether populated (non-zero | | | | |byte resource) or not. | +-----+--------------+-----+-------------------------------------------+ | 16 | E+2 - E+17 | - |Item 1 - First shared resource entry. | +-----+--------------+-----+-------------------------------------------+ | 16 | E+18 - E+31 | - |Item 2 - Second shared resource entry. | +-----+--------------+-----+-------------------------------------------+ |. . .| . . . Etc. | - |Item i - i-th item entry. (i determined by | | | | |"items in table" value above.) | +-----+--------------+-----+-------------------------------------------+ | 4 | N - N+3 |LONG |Next table file offset - 4-byte file | | | | |offset, in bytes from beginning of file, of| | | | |the next Shared Resources Table. Where i = | | | | |shared resource entries in this table | | | | |(see "items in table", above), and each | | | | |shared resource item entry is 16 bytes, | | | | | N = E+2+16*i. | +-----+--------------+-----+-------------------------------------------+ Shared Resource Entries +-----+--------------+-----+-------------------------------------------+ |Bytes| Byte offsets |Type | Description | +-----+--------------+-----+-------------------------------------------+ | 4 | Y - Y+3 |LONG | Resource bytes - Size of the shared | | | | | resource data block, in bytes. | +-----+--------------+-----+-------------------------------------------+ | 4 | Y+4 - Y+7 |LONG | Resource file offset - File offset of | | | | | this shared resource data block, in bytes,| | | | | from beginning of file. | +-----+--------------+-----+-------------------------------------------+ | 2 | Y+8 - Y+9 |SHORT| ResourceType - The type of data being | | | | | represented as a shared resource. The | | | | | table below contains the type of shared | | | | | resources that are currently defined. | +-----+--------------+-----+-------------------------------------------+ McIntyre et al. Expires January 2001 [Page 24] Internet Draft TIFF-FX Extension 1.0 July 2000 +-----+--------------+-----+-------------------------------------------+ | 2 | Y+10 - Y+11 |SHORT| Last page used - The page (primary IFD) | | | | | ordinal (1, 2, ...) of the last page that | | | | | references this shared resource. A value | | | | | of 0 indicates that the last page to use | | | | | the shared resource is not known. | | | | | Note: the page ordinal is based on the | | | | | order within the primary IFD chain, not | | | | | the PageNumber field. Because the | | | | | PageNumber field could have inconsistent | | | | | values (due to editing, odd/even page | | | | | scanning, or interpretation of the field | | | | | meaning) the PageNumber field should not | | | | | be relied on. Also note that the page | | | | | ordinal is one more than the PageNumber[0]| | | | | field value, which starts at 0. | +-----+--------------+-----+-------------------------------------------+ | 4 | Y+12 - Y+15 |LONG | Decoder memory required - the number of | | | | | bytes required by a decoder to hold this | | | | | shared resource in decoded form. This | | | | | value may depend on an interpretation of | | | | | the form of the data when decoded (i.e. a | | | | | specification of the form of decoded image| | | | | may be that each scan-line be a multiple | | | | | of 32 bits; thus the reported decoded | | | | | memory requirement would always be | | | | | computed this way). | | | | | When defining a shared resource and | | | | | decoder memory is applicable, a formula | | | | | for computing the decoder memory required | | | | | SHALL be given. | | | | | A value of 0 indicates that the decoder | | | | | memory required is not known, or this | | | | | field is not applicable. | +-----+--------------+-----+-------------------------------------------+ Current ResourceTypes: +--------------+-------------------------------------------------+ | ResourceType | Description | | Value | | +--------------+-------------------------------------------------+ | 0 | undefined | +--------------+-------------------------------------------------+ | 1 | JBIG2 Resource (JBIG2 symbol dictionaries, | | | pattern dictionaries, Huffman tables, etc) | +--------------+-------------------------------------------------+ McIntyre et al. Expires January 2001 [Page 25] Internet Draft TIFF-FX Extension 1.0 July 2000 The reference to a shared resource entry SHALL be by a unique ID, which SHALL be the offset of the entry in the list described by the Shared Resources Tables; the first shared resource entry SHALL have ID 0. Note that the "list" of shared resource entries is what the series of Shared Resources Tables will contain, when collected together. The order of the shared resource tables SHALL determine the order of the resource IDs. For example, if the first three tables (A, B and C) have 3, 1 and 2 resources respectively; then table A will contain resources with IDs 0, 1, and 2; table B will contain the resource with ID 3; and table C will contain resources with IDs 4 and 5. Note that if copying resources from one file to another, the resource ID will likely need revision to be brought in alignment with the destination table; additionally, any copied data that refers to the copied resource will require a change in the reference to the new ID. E1.5.4.1 Resource Lists To reference entire resources, their IDs may be enumerated in a Resource List that will appear in data that directly requires inclusion of the resource to be complete. For instance, an image strip that requires a resource in order to be a complete compressed data stream, will include a ResourceList. It is up to the interpretation of the reference data type (i.e. Compression type) as to how the resource will be used. A ResourceList list will contain a 2-byte count of the number of IDs (i) in the list, followed by i 4-byte IDs. ResourceList Structure +-----+---------------+-----+---------------------------------------------+ |Bytes| Byte offsets |Type | Description | +-----+---------------+-----+---------------------------------------------+ | 2 | P - P+1 |SHORT| The number of resource IDs (i) | +-----+---------------+-----+---------------------------------------------+ | 4 | P+2 - P+5 |LONG | First shared resource ID | +-----+---------------+-----+---------------------------------------------+ | 4 | ... |LONG | ... | +-----+---------------+-----+---------------------------------------------+ | 4 | P+2+(i-1)*4 - |LONG | i-th shared resource ID | | | P+5+(i-1)*4 | | | +-----+---------------+-----+---------------------------------------------+ McIntyre et al. Expires January 2001 [Page 26] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.5.4.2 Representation of Shared Resources in TIFF The representation of Shared Resources in a TIFF file is shown below: +------+--------------------------+------------------------------------+ | | | "II" or "MM" | | | +------------------------------------+ | | TIFF Header | 42 | | | +------------------------------------+ | | | FirstIFD offset (IFD0) |---: | +--------------------------+------------------------------------+ | | | ... | | | :---|-------------------------------<-------------------------------|---: | | | ... | | v +--------------------------+------------------------------------+ | | | | ... | | | | +------------------------------------+ | :-->| IFD0 | GlobalParametersIFD offset |---: | | +------------------------------------+ | | | | ... | | | +--------------------------+------------------------------------+ v | | ... | | | :---|-------------------------------<-------------------------------|---: | | | ... | | v +--------------------------+------------------------------------+ | | | | ... | | | | +------------------------------------+ | :-->| GlobalParametersIFD | SharedResources offset (1st Shared |---: | | | Resources Table offset) | | | | +------------------------------------+ | | TIFF | | ... | v | file +--------------------------+------------------------------------+ | | | ... | | | :---|-------------------------------<-------------------------------|---: | | | ... | | | +--------------------------+------------------------------------+ McIntyre et al. Expires January 2001 [Page 27] Internet Draft TIFF-FX Extension 1.0 July 2000 | | +--------------------------+------------------------------------+ | | | | Number of items in table | | | | +--------------------+---------------+ | | | | | Byte count | | v | | +---------------+ | | | | | File offset | | | | | +---------------+ | | | | Shared Resources 0 | ResourceType | | | | | +---------------+ | :-->| Shared Resources Table 0 | | Last page used| | | | +---------------+ | | | | Decoder memory| | | | | required | | | +--------------------+---------------+ | | | Shared Resources 1 | ... | | | +--------------------+---------------+ | | | ... | ... | | | +--------------------+---------------+ | | | Next Shared Resources Table offset | | +--------------------------+------------------------------------+ | | ... | +------+---------------------------------------------------------------+ E1.6. TIFF-FX Extension 4: Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile This section defines the lossy and lossless JBIG2 black-and-white profile or Profile T of TIFF for facsimile. JBIG2, ITU-T Rec. T.88 / ISO-IEC 14492 [T.88], is frequently referenced as symbol or token-based compression because it makes use of repeating shapes. The Profile T designation is representative of token-based compression. All profile T readers and writers SHALL also be able to read and write Profile S, since Profile S is the minimal binary TIFF-FX profile. E1.6.1. Overview This section describes a black-and-white profile that uses JBIG2 compression. The ITU-T has approved the lossy and lossless modes of JBIG2 for Group 3 facsimile. JBIG2 compression is typically used in accordance with the application rules given in ITU-T Rec. T.89 [T.89]. This profile is essentially a black-and-white constrained profile of Profile M plus the Profile M Shared Resources extension. The MRC 3-layer model and TIFF representation, defined in Section 8.1 and constrained to a single image layer (i.e. only one layer with image data), SHALL be used. McIntyre et al. Expires January 2001 [Page 28] Internet Draft TIFF-FX Extension 1.0 July 2000 The behavior and structure of this profile is effectively that of a plain single-layer image, similar to that of Profiles S, F and C, with some added structure to accommodate JBIG2's meta-data. Within this context, bit 4 of the NewSubFileType field SHALL be set, indicating the MRC imaging model, also only even numbered values of the ImageLayer[0] field SHALL have non- zero values of StripByteCounts, indicating mask layer. Additionally the SharedResources field SHALL be used to store JBIG2 Resources, such as symbol dictionaries, and the Compression type SHALL be set to 12 (JBIG2 Compression). These requirements are consistent with ITU-T's definitions in Rec. T.4 Annex H [T.4Amd1] and Rec. T.44 Annex B. JBIG2 compression utilizes the fact that many images have repeating shapes or symbols. This is especially true for images of text, where the repeating shapes are the characters themselves. Symbol or token-based compression makes use of these repeating shapes, by storing a set of images for the symbols once, and then referring to the symbol image as many times as possible. In a multi-page document, the same shape can occur on multiple pages. In fact, this is quite common: any shape occurring on the first page is likely to show up on all the other pages in the document. JBIG2 compresses even better by collecting all the repeating shapes from multiple pages, and allowing this collection to be referred to by more than one page. This collection of symbol images is referred to as a symbol dictionary. A document can contain more than one symbol dictionary. For example, one symbol dictionary might contain all the symbols that occurred on more than one page; each page then might have its own symbol dictionary, containing all the symbols that occurred only on that page. There are two typical ways of compressing symbols on a page using (or generating) a symbol dictionary. One is by finding an exact match (lossless), and the other is by allowing a small amount of discrepancy between the symbol candidate, and the matching symbol in the symbol dictionary (lossy). The mode used can be distinguished by the value of the "Lossless" bit in the T88Options[0] field, which is defined below. The representation of a symbol-compressed image consists of a resource list, which identifies which "JBIG2 Resources" are used, and a "JBIG2-coded position block". A JBIG2 Resource is used to represent a variety of JBIG2 shared entities (i.e. JBIG2 resources) such as symbol dictionaries, pattern dictionaries, which are used in halftone coding, and Huffman tables. The symbol dictionaries are typically contained within one or more JBIG2 Resources, represented within the SharedResoures provisions of the Shared Resources Extension of Profile M. The JBIG2-coded position block contains of a series of symbol X and Y-Position coordinates, plus the IDs of the symbols located by the coordinates. The symbol bitmaps are stored in the referenced symbol dictionaries. McIntyre et al. Expires January 2001 [Page 29] Internet Draft TIFF-FX Extension 1.0 July 2000 Each TIFF strip in an IFD whose Compression is equal to 12 (the TIFF Compression value defined for JBIG2 below) SHALL be formatted as described in Section E1.6.5 (The JBIG2 Image Strip). E1.6.1.1 Why Use JBIG2 The symbol-based compression model is incorporated in the JBIG2 standard; this standard boosts compression of text-like documents by retaining similar shapes across multiple images. In the case of text, the shapes are the character symbols, and for multi-page documents, the set of unique character symbols may be fairly small, especially when the same font is used on each page. A typical image of binary text, at 300 dpi might take about 80 kilobytes to store using T.6 compression; a similar JBIG2 file might only require around 20 kilobytes to store. The compression gain can be up to a factor of two larger for multi-page documents. Sharing dictionaries between multiple pages makes this high compression possible, but requires some way to refer to the dictionaries used by more than one page; this is the reason for using Profile M and its Shared Resources provisions. E1.6.2. Required TIFF Fields This section describes the TIFF fields required, in addition to those in Sections 8.2 and E1.5.2, for Profile T. Additionally it describes those not required in Section 8.2 and constrained differently from those in Section 8.2. Note that these fields are defined under the premise that all odd-numbered layers are omitted, in conformance to the Profile T black-and-white constraint. However, there are application conditions that would benefit from inclusion of these odd-numbered layers and setting the associated StripByteCounts to 0. Under these conditions the list of required fields and/or values will be modified. Reference the StripByteCounts field below for appropriate modifications. E1.6.2.1. Baseline Fields ImageWidth(256). SHORT or LONG Same page widths as Profile F, the extended black-and-white profile, and the ImageWidth extensions available to Profile F; see Section 4.2.1 and E1.3. The change in ImageWidth reference, to those of Profile F rather than Profile C, is consistent with the black-and-white constraint of this profile. Note that for layers other than layer 2, the ImageWidth could be a fragment of the page width, as when the XPosition is greater than 0. BitsPerSample(258) = 1. SHORT Constraint is consistent with the black-and-white constraint. McIntyre et al. Expires January 2001 [Page 30] Internet Draft TIFF-FX Extension 1.0 July 2000 SamplesPerPixel(277) = 1. SHORT Constraint is consistent with the black-and-white constraint. Compression(259) = 12. SHORT [[Note that assignment of value 12 to JBIG2 has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] 12 = JBIG2 coding, ITU-T Rec. T.88 / ISO-IEC 14492 (Lossy/Lossless coding of Bilevel Images, frequently referenced as symbol-based compression), T88Options field may be present when using JBIG2. The format of the data pointed to by the StripByteOffsets when Compresstion=12 is described later. FillOrder(266) = 1, 2. SHORT See Section 8.2.1 PhotometricInterpretation(262) = 0. SHORT Constraint is consistent with the black-and-white constraint and MRC mask layer requirements. ResolutionUnit(296) = 2. SHORT See Section 8.2.1. StripByteCounts(279) SHORT or LONG SHALL be fixed to zero "0" for all odd numbered values of the ImageLayer[0] field. In Profile M, it is permissible for the StripByteCounts value for a given strip to have a zero entry. This means there is no encoded image data corresponding to that strip. Instead, the current default image color should be used for the strip. The standard default image colours are white for the Background layer and black for the Foreground layer. It would be efficient to omit all odd numbered layers for Profile T. However, it may be useful to identify portions of a background and/or foreground image where the default color should be reversed; namely where a background image portion is all black, or where reverse video appears. To define a child IFD specifying an odd numbered layer (i.e. foreground or background) but containing no encoded image data, create an IFD with the following settings: ImageLayer[0]: specified odd numbered layer ImageLayer[1]: specified order RowsPerStrip: strip height ImageLength: strip height ImageWidth: specified value, often the Primary IFD width BitsPerSample: 8 PhotometricInterpretation: 10 SamplesPerPixel: 3 McIntyre et al. Expires January 2001 [Page 31] Internet Draft TIFF-FX Extension 1.0 July 2000 Compression: 1 (none) XPosition: specified value, frequently 0 YPosition: specified value, frequently to top of strip XResolution: that of the Primary IFD YResolution: that of the Primary IFD StripByteCounts: single 0 value StripOffsets: single 0 entry NewSubFileType: bit 4 set to 1 (MRC) ImageBaseColor: default is white and black for background and foreground layers respectively, the reverse may be specified XResolution(282) RATIONAL Same XResolution as Profile F, the extended black-and-white profile, and the XResolution extensions available to Profile F; see Section 4.2.1 and E1.3. The change in XResolution reference, to those of Profile F rather than Profile M, is consistent with the black-and-white constraint of this profile. YResolution(283) RATIONAL Same YResolution as Profile F, the extended black-and-white profile, and the YResolution extensions available to Profile F; see Section 4.2.1 and E1.3. The change in YResolution reference, to those of Profile F rather than Profile M, is consistent with the black-and-white constraint of this profile. Note that unlike Profile M, Profile F and Profile T may both have non-square resolutions (i.e. different X and YResolution values). E1.6.2.2. Extension Fields These fields SHALL NOT be present: ChromaSubSampling(530) ChromaPositioning(531) Indexed(346) T4Options(292) T6Options(293) These fields are as described in Section 8.2.2: SubIFDs(330). XPosition(286). YPosition(287). McIntyre et al. Expires January 2001 [Page 32] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.6.2.3. New Fields These Section 8.2.3 fields SHALL NOT be present: Decode(433). T82Options(435) ImageBaseColor(434). The field SHALL be omitted and the default colour of black and white SHALL be applied to foreground and background layers respectively. These fields, described in Section 8.2.3 SHALL be present: StripRowCounts(559). ImageLayer (34732). The fields described in E1.5.2.3 SHALL be present. GlobalParametersIFD (400) SharedResources (437) ResourceList (438) TIFF-FXExtensions (407) Bits 2 and 3 of the TIFF-FXExtensions field SHALL be set to 1. E1.6.3. Recommended TIFF Fields See Sections 8.3, with exception of GlobalParametersIFD and append the Following: T88Options (436). LONG Count = 1 or 2 [[Note that assignment of tag value 436 has been requested of Adobe. This value is subject to change until Adobe's confirmation has been received]] The T88Options tag contains two values, describing options applied to the encoded data stream and any application profile to which the encoded data stream may conform. It SHALL only be present when the IFD's Compression tag is equal to 12 (JBIG2). The content provides an aid to TIFF readers. None of the values in the field are required for correct decoding, and the field may be ignored. In the event that this tag is omitted, a reader SHALL assume that the data stream is encoded per the ITU-T T.89 Base profile (i.e. profile identification number 0x00000101), see T88Options[1] below. T88Options[0] = 1, 2, ..., 7. This value represents options that are being applied to the encoded data stream. NOTE: In all the tables shown below, all multi-byte quantities are written/read in the endianness convention established by the TIFF file ("II" or "MM"). McIntyre et al. Expires January 2001 [Page 33] Internet Draft TIFF-FX Extension 1.0 July 2000 The following options are defined: +--------------+-----------------------------------------------------------+ | Bit number | Meaning | +--------------+-----------------------------------------------------------+ | 0 | HuffmanCodingNotPresent | | | If bit 0 is 1, then the JBIG2-compressed data in this IFD | | | SHALL NOT use Huffman or MMR (T.6) coding. | +--------------+-----------------------------------------------------------+ | 1 | ArithmeticCodingPresent | | | If bit 1 is 1, then the JBIG2-compressed data in this IFD | | | MAY contain segments that contain arithmetic (MQ) coding. | +--------------+-----------------------------------------------------------+ | 2 | Lossless | | | If bit 2 is 1, then the JBIG2-compressed data in this IFD | | | SHALL be a lossless representation of the original image. | +--------------+-----------------------------------------------------------+ | 3 | SingleStriped | | | If bit 3 is 1, then each TIFF strip (or tile) SHALL | | | contain a JBIG2 Position Block which has only one JBIG2 | | | stripe. | | | Note: There is a limit of 32767 lines per JBIG2 stripe in | | | the event that multi-stripe mode is used. | +--------------+-----------------------------------------------------------+ | 4 | TextStripesMixed | | | If bit 4 is 1, then some JBIG2-compressed stripes that | | | have text region segment(s) MAY also have region segments | | | with other data types (e.g. generic or halftone region | | | segment). | +--------------+-----------------------------------------------------------+ | 5 | ColourTagsFollow | | | If bit 5 is 1, then this IFD SHALL be in a mask layer | | | whose corresponding foreground layer SHALL be coded with | | | JBIG2 (Compression = 12) and the JBIG2-data SHALL be | | | augmented with ITU-T Rec. T.45 (Run-length colour | | | encoding) [T.45] coded colour tags. | +--------------+-----------------------------------------------------------+ | 6 | ColourTagsPresent | | | If bit 6 is 1, then this IFD SHALL be in a foreground | | | layer, which SHALL be coded with JBIG2 (Compression = 12) | | | and the JBIG2-data SHALL be augmented with T.45-coded | | | colour tags. | +--------------+-----------------------------------------------------------+ | 7 | HalftoneRegionPresent | | | If bit 7 is 1, then the JBIG2-compressed data in this IFD | | | SHALL contain halftone region segment(s). | +--------------+-----------------------------------------------------------+ Note: Bits 5 or 6 SHALL not be set within Profile T, which is constrained to black-and-white images. McIntyre et al. Expires January 2001 [Page 34] Internet Draft TIFF-FX Extension 1.0 July 2000 T88Options[1] = 0x00000101, 0x00000102, 0x00000103. This value represents the JBIG2 profile identification number. This value may be omitted. No default. The profile identification number of the T88Options identifies a subset of the full set of permitted parameters and parameter values that the JBIG2 coded data stream is in compliance with. While T88Options is not required to decode a JBIG2 coded data stream and may be ignored, it allows a decoder to find out quickly that it cannot decode a given data stream. The four-byte profile identification numbers 0x00000000 through 0xFFFFFFFF are administered by ISO/IEC JTC1 SC29. ISO/IEC JTC1 SC29 has reserved profile identification numbers 0x00000100 through 0x00000FFF for ITU-T disposition. Interpretation of profiles 0x00000100 through 0x00000FFF is document in ITU-T Rec. T.89. While Interpretation of profiles 0x00000000 through 0x000000FF is documented in ISO/IEC 14492 | ITU-T T.88. Current profiles: +------------------+----------------------------------------------------+ | JBIG2 Profile ID | Description | +------------------+----------------------------------------------------+ | 0x00000101 | ITU-T T.89 Base (minimal Fax Application Profile) | | | - MMR and Huffman coding, minimum of two stripes | | | per page, stripes containing text region segment(s)| | | SHALL NOT contain other region segments | +------------------+----------------------------------------------------+ | 0x00000102 | ITU-T T.89 Upper MMR | | | - MMR and Huffman coding, minimum of two stripes | | | per page, accommodates halftone and colour tags | +------------------+----------------------------------------------------+ | 0x00000103 | ITU-T T.89 Lower Arithmetic | | | - Arithmetic coding, minimum of two stripes per | | | page, stripes containing text region segment(s) | | | SHALL NOT contain other region segments | +------------------+----------------------------------------------------+ NOTE: In this table, the term "stripe" means JBIG2 stripe (i.e. a stripe within a JBIG2 Position Block), not a TIFF strip, nor a TIFF-FX stripe. E1.6.4 JBIG2 Resources For JBIG2 Resources, the ResourceType value in the Shared Resource Entry will have a value of 1. McIntyre et al. Expires January 2001 [Page 35] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.6.4.1 The JBIG2 Resource The JBIG2 Resource stored in a TIFF file contains three pieces: 1. A JBIG2 Resource version 2. A JBIG2-coded resource block 3. Extensions to the JBIG2 Resource (these extensions contain data that are outside the scope of T.88-JBIG2) The JBIG2-coded resource block can have a series of JBIG2 segments. The following segment types may occur: - Symbol dictionary segment - Pattern dictionary segment - Extension segment (future extensions to be defined within the T.88 JBIG2 standard) - Supported profiles segment - Table segment Each segment in a JBIG2-coded resource block SHALL be associated with no page (i.e., SHALL have a page association field value of 0, as described in T.88 - JBIG2 Section 7.2.6). E1.6.4.1.1 JBIG2 Resource Format The JBIG2 Resource has the following format: +-----+--------------+-----+---------------------------------------------+ |Bytes| Byte offsets | Type| Description | +-----+--------------+-----+---------------------------------------------+ | 1 | T |BYTE | The JBIG2 Resource version number, which | | | | | is currently 0. | +-----+--------------+-----+---------------------------------------------+ | 4 | T+1 - T+4 |LONG | Size of JBIG2-coded resource block (not | | | | | including extensions) = Y. | +-----+--------------+-----+---------------------------------------------+ | Y | T+5 - T+4+Y |BYTE | The JBIG2-coded resource block. | +-----+--------------+-----+---------------------------------------------+ | 2 | . . . . |SHORT| Extension type for first extension (these | | | | | extensions contain data that are outside the| | | | | scope of T.88-JBIG2) | +-----+--------------+-----+---------------------------------------------+ | 4 | . . . . |LONG | Size of first extension=Z1 | +-----+--------------+-----+---------------------------------------------+ | Z1 | . . . . |.... | Data for first extension | +-----+--------------+-----+---------------------------------------------+ | 2 | . . . . |LONG | Extension type for second extension | +-----+--------------+-----+---------------------------------------------+ | 4 | . . . . |LONG | Size of second extension=Z2 | +-----+--------------+-----+---------------------------------------------+ | Z2 | . . . . | ....| Data for second extension | +-----+--------------+-----+---------------------------------------------+ | ....| . . . . | ....| Further extensions | +-----+--------------+-----+---------------------------------------------+ McIntyre et al. Expires January 2001 [Page 36] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.6.4.2 Decoder Memory For JBIG2 dictionary Resources, if decoder memory is specified (non-zero value), then it follows the formula described in ITU-T Rec. T.89 (Application Profiles for Recommendation T.88). Namely, the decoder memory is a measure of how much memory is required to hold a decoded dictionary, according to: decoder memory = SUM (32 + (round32(Wi) ( Hi) / 8) over i, i= 1 to N where: i = ith symbol in the dictionary N = the number of symbols in the dictionary 32 = a fixed per-symbol overhead required to represent: - width of symbol - height of symbol - symbol ID Huffman code - length of symbol ID Huffman code - pointer to memory where symbol bitmap resides round32 = is a rounding up to the next multiple of 32 bits (e.g., 33 rounds to 64, 128 rounds to 128) Wi = width of the ith symbol Hi = height of the ith symbol This means that for each symbol there are 32 bytes overhead, plus Hi rows of bitmap data, each of which is round32(Wi)/8 bytes. Note: pattern dictionaries are similar to symbol dictionaries but contain halftone patterns; thus references to symbol above should be taken to include patterns stored in pattern dictionaries. E1.6.5 The JBIG2 Image Strip The JBIG2 image stored in a TIFF file will have components that require a TIFF reader to parse through its content. This is due to the fact that JBIG2 is represented by two types of data: 1. shared components: namely the symbol or pattern bitmaps that are associated with multiple images, which are compressed into dictionaries and stored in one or more JBIG2 Resources. 2. image specific components: data that is specific to one image only, that with the aid of the shared components, will allow the image to be decoded. To couple these two component sets together, each JBIG2 Image Strip within an IFD has a corresponding list of resource IDs in the ResourceList section of each image strip. The concatenization of the resources and the JBIG2 position block will comprise a decodable JBIG2 stream for the image described by the IFD for that strip. McIntyre et al. Expires January 2001 [Page 37] Internet Draft TIFF-FX Extension 1.0 July 2000 A position block is the base JBIG2 encoding of the binary image. Included in the position block are the positions and IDs of the symbol dictionaries, which may lie within the position block, and/or outside of it (as JBIG2 resources). Within the position block, the following segment types may occur: 1. Page information segment - Exactly one page information segment SHALL be present, and it SHALL be the first segment in the JBIG2-coded position block 2. End of page segment - Exactly one end of page segment SHALL be present, and it SHALL be the last segment in the JBIG2-coded position block 3. End of stripe segment 4. Symbol dictionary segment 5. Pattern dictionary segment 6. Generic region segment 7. Text region segment 8. Supported profiles segment 9. Table segment. Extension segments are future extensions, to be defined within the T.88 JBIG2 standard. Extension segments may be included in an image strip, but outside of the position block. Each segment in a JBIG2-coded position block SHALL be associated with the page defined by the page information segment. The image strip consists of four pieces: 1. A JBIG2 Image Strip version 2. A ResourceList: list of JBIG2 Resource IDs 3. The JBIG2-coded position block 4. Extensions to the image strip (these extensions contain data that are outside the scope of JBIG2, such as colour tags, which are defined within the JBIG2 Extension of Profile M. Colour tags are not permitted within this profile, Profile T). If the JBIG2 Image Strip contains extensions, each extension is preceded by a two-byte type giving its extension type, and a 4-byte count of its length in bytes. Other data that could be stored in an extension includes ASCII text, hyperlinks, and so on. If a TIFF reader is not able to interpret an extension (if it does not recognize the extension type), then it SHOULD ignore that extension, but may skip over it to find further extensions that it can interpret. To decode a JBIG2-coded image strip, follow these steps: 1. Retrieve the list of shared resource IDs from the ResourceList. 2. Search the collection of JBIG2 Resources for all the JBIG2 Resource, such as dictionaries, whose IDs are given in the ResourceList. From each one, extract its JBIG2-coded resource block. McIntyre et al. Expires January 2001 [Page 38] Internet Draft TIFF-FX Extension 1.0 July 2000 3. Concatenate those JBIG2-coded resource blocks, in the order in which their IDs are given, followed by the JBIG2-coded position block. 4. Decode the resulting data as a JBIG2 data stream. This SHALL be a valid JBIG2 data stream containing a single page: no segment numbers may be duplicated, and so on. In practice, you won't actually concatenate and decode the JBIG2-coded resource block(s) for every position block that uses them, as that's quite inefficient. Instead, the JBIG2-coded resource block(s) can be decoded and kept in an intermediate format, designed so that the effect of logical concatenation can be simulated. Note, the description of JBIG2 embedding in TIFF strips does not exclude the use of tiles instead of strips. However, the smaller the image fragments are, the greater the possibility that symbols will be sliced up; which may cause strange effects when using lossy JBIG2 symbol matching. E1.6.5.1 Image Strip Format The image strip has the following format, which includes a ResourceList, delimited by "====": +-----+--------------+-----+---------------------------------------------+ |Bytes| Byte offsets | Type| Description | +-----+--------------+-----+---------------------------------------------+ | 1 | P |BYTE | Strip format version number, which is | | | | | currently 0. | +=====+==============+=====+=============================================+ | 2 | P+1 - P+2 |SHORT| Number of resource IDs = X (i.e. JBIG2 | | | | | Resources) | +-----+--------------+-----+---------------------------------------------+ | X*4 | P+3 - P+2 |LONG | The sequence of shared resource IDs of the | | | +(X*4) | | JBIG2 Resources required by this JBIG2-coded| | | | | position block. The JBIG2 Resources (e.g. | | | | | dictionaries) will be prepended in the | | | | | order specified by this sequence of IDs, to | | | | | construct the array of symbols that will be | | | | | used to decode the JBIG2-coded position | | | | | block. | +=====+==============+=====+=============================================+ | 4 | P+3+(X*4) - |LONG | Size of JBIG2-coded position block not | | | P+6+(X*4) | | including extensions = Y | +-----+--------------+-----+---------------------------------------------+ | Y | . . . . |BYTE | The JBIG2-coded Position Block. | +-----+--------------+-----+---------------------------------------------+ | 2 | . . . . |SHORT| Extension type for first extension (these | | | | | extensions contain data that are outside the| | | | | scope of T.88-JBIG2, such as colour tags) | +-----+--------------+-----+---------------------------------------------+ McIntyre et al. Expires January 2001 [Page 39] Internet Draft TIFF-FX Extension 1.0 July 2000 +-----+--------------+-----+---------------------------------------------+ | 4 | . . . . |LONG | Size of first extension=Z1 | +-----+--------------+-----+---------------------------------------------+ | Z1 | . . . . |BYTE | Data for first extension | +-----+--------------+-----+---------------------------------------------+ | 2 | . . . . |SHORT| Extension type for second extension | +-----+--------------+-----+---------------------------------------------+ | 4 | . . . . |LONG | Size of second extension=Z2 | +-----+--------------+-----+---------------------------------------------+ | Z2 | . . . . | ... | Data for second extension | +-----+--------------+-----+---------------------------------------------+ | ... | . . . . |BYTE | Further extensions | +-----+--------------+-----+---------------------------------------------+ Current Image Strip Extension Types: +----------------+---------------------------------------------------------+ | Extension Type | Meaning | +----------------+---------------------------------------------------------+ | 0 | Undefined | +----------------+---------------------------------------------------------+ | 1 | Colour tags | | | This extension contains colour tag data (T.45). | | | This value SHALL NOT be used when using Profile T | +----------------+---------------------------------------------------------+ E1.6.6 Representation of JBIG2 data in TIFF The embedding of JBIG2 data in TIFF then takes the following form: +------+-------------------+-------------------------------------------+ | | | "II" or "MM" | | | +-------------------------------------------+ | TIFF | TIFF Header | 42 | | file | +-------------------------------------------+ | | | FirstIFD offset (IFD0) |--: | +-------------------+-------------------------------------------+ | | | ... | | | :---|-------------------------------<-------------------------------|--: | | | ... | | | +-------------------+-------------------------------------------+ McIntyre et al. Expires January 2001 [Page 40] Internet Draft TIFF-FX Extension 1.0 July 2000 | | +-------------------+-------------------------------------------+ | | | | ... | | | | +-------------------------------------------+ | v | | Next IFD offset (IFD 1) |----: | | | +-------------------------------------------+ | | | | | ... | | | | | +-------------------------------------------+ | | :-->| IFD0 | GlobalParametersIFD |--: | | | +-------------------------------------------+ | v | | | StripOffsets/StripByteCounts | | | | | +-------------------------------------------+ v | | | | ... | | | | +-------------------+-------------------------------------------+ | | | | ... | | | | :---|-------------------------------<-------------------------------|--: | | | | ... | | | v +-------------------+-------------------------------------------+ v | | | | ... | | | | | +-------------------------------------------+ | | :-->| GlobalParameters | SharedResources offset (1st Shared |--: | | | IFD | Resources Table offset) | | | | | +-------------------------------------------+ | | | TIFF | | ... | v | | file +-------------------+-------------------------------------------+ | | | | ... | | v | :---|-------------------------------<-------------------------------|--: | | | | ... | | | | +-------------------+-------------------------------------------+ | | | | | Number of items in table | | | | | +--------------------+----------------------+ | | | | | | Byte count (of JBIG2 | | | | | | | Resource 0) | | | v | | +----------------------+ v | | | | | File offset (to |--: | | | | | | JBIG2 Resource 0) | | | | | | | +----------------------+ | | | | | | Shared Resources 0 | ResourceType (1) | | | | | | | +----------------------+ v | | :-->| Shared Resources | | Last page used | | | | | Table 0 | +----------------------+ | | | | | | Decoder memory | | | | | | | required | | v | | +--------------------+----------------------+ | | | TIFF | | Shared Resources 1 | ... | | | | file | +--------------------+----------------------+ v | | | | ... | ... | | | | | +--------------------+----------------------+ | | | | | Next Shared Resources Table offset | | | | +-------------------+-------------------------------------------+ | | McIntyre et al. Expires January 2001 [Page 41] Internet Draft TIFF-FX Extension 1.0 July 2000 | +-------------------+-------------------------------------------+ | | | | ... | | v | :---|-------------------------------<-------------------------------|--: | | | | ... | | | v +-------------------+-------------------------------------------+ | | | | | 0 (version) | | | | | +-------------------------------------------+ | | | | | | | | v | +-------------------------------------------+ | | | | | JBIG2-coded block> block (may contain | v | | | | multiple JBIG2 segments) | | | :-->| JBIG2 Resource 0 +-------------------------------------------+ | | | | Extension type for first extension (data | | | | | that are outside the scope of T.88-JBIG2) | | | | +-------------------------------------------+ | | | | | | | TIFF | +-------------------------------------------+ | | file | | Data for first Extension | | | | +-------------------------------------------+ v | | | ... | | | +-------------------+-------------------------------------------+ | | | ... | | | :---|-------------------------------<-------------------------------|----: | | | ... | | v +-------------------+-------------------------------------------+ | | | | ... | | | | +-------------------------------------------+ | :-->| IFD1(page 0) | StripOffset (strip 0) |---: | | +-------------------------------------------+ | | | | ... | | | +-------------------+-------------------------------------------+ | | | ... | | | :---|-------------------------------<-------------------------------|---: | | | ... | | | +-------------------+-------------------------------------------+ | | | | Strip format version | | | | +-------------------------------------------+ | | | | ResourceList | | | | Strip 0 +-------------------------------------------+ | :-->| | JBIG2-coded position block | | | +-------------------------------------------+ | | | Extensions | | TIFF +-------------------+-------------------------------------------+ | file | | | | ... | +------+---------------------------------------------------------------+ McIntyre et al. Expires January 2001 [Page 42] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.6.7 Rules and Requirements for Images Profile T defines a fundamental set of rules for images in the 3-layer representation. 1. Only ONE layer with image data SHALL exists and it SHALL be the binary Mask layer, which SHALL be represented Primary IFD. Compression 12 SHALL Be used in this layer and the PhotometricInterpretation SHALL be 0. 2. A Foreground and/or Background layer without image data (i.e. IFD with StripByteCounts = 0) MAY be presented. If present, then black Foreground and white Background default ImageBaseColor SHALL be used, unless specified otherwise as white and black respectively. 3. The Primary IFD defines and extends to the entire page boundary; all attached model images cannot extend beyond the Primary image. Resolution differences may cause some pixels to "hang over" the page boundary, but no new pixels should exist completely beyond the page extent. 4. Images other than the Primary Image (i.e. Primary IFD) MAY optionally cover only a portion of the strip or page. 5. Each Primary IFD and each MRC-specific SubIFD must have an ImageLayer field to specify which layer the IFD belongs to, and the imaging order of that IFD within the layer. 6. Each Primary IFD must have a NewSubFileType field value set to 18, indicating a single page of a multi-page document (bit 1) and MRC (bit 4). 7. Each MRC-specific child IFD must have a NewSubFileType field value set to 16, indicating MRC (bit 4). 8. In MRC Internet Fax, each layer is transmitted as a sequence of strips. If the page consists of a single layer, then all strips shall be stored in the single Primary IFD. In this case, coding parameters cannot change between strips. If the page consists of more than one layer, then all strips of the Primary Mask layer shall be stored in the single Primary IFD. All strips of the Foreground/ Background layers MAY be stored in one or more IFDs, referenced by the Primary IFD's SubIFD field, containing an ImageLayer field with ImageLayer[0] identifying Background (layer 1) or Foreground layer (layer 3), and Imagelayer[1] identifying order in which images within a single layer are to be imaged. The TIFF XPosition and YPosition fields are used to indicate the placement of these images with respect to the primary image. McIntyre et al. Expires January 2001 [Page 43] Internet Draft TIFF-FX Extension 1.0 July 2000 9. When the Primary Mask image is present, The resolution of Background and Foreground images must each be an integer factor of the Primary Mask image. For example, if the Primary Mask image is 400 pixels/inch, then the Background or Foreground images may be at 400 pixels/inch (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White Fax profile Summary Recommended fields are shown with an asterisk * Required fields or values are shown with a double asterisk **. If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations. +------------------+-----------------------------------------+ | Baseline Fields | Values | +------------------+-----------------------------------------+ | BitsPerSample | 1**: binary mask | +------------------+-----------------------------------------+ | Compression | 1: None (ImageBaseColor IFD only) | | | 12**: JBIG2 | +------------------+-----------------------------------------+ | DateTime* | {ASCII): date/time in the 24-hour format| | | "YYYY:MM:DD HH:MM:SS" | +------------------+-----------------------------------------+ | FillOrder** | 1: Most significant bit first | | | 2: Least significant bit first | +------------------+-----------------------------------------+ | ImageDescription*| {ASCII}: A string describing the | | | contents of the image. | +------------------+-----------------------------------------+ | ImageWidth | 1728**, 2048, 2432, 2592, | | | 3072, 3456, 3648, 4096, 4864 | +------------------+-----------------------------------------+ | ImageLength** | n: total number of scanlines in image | +------------------+-----------------------------------------+ | NewSubFileType** | 16, 18: | | | Bit 1 indicates single page of a multi- | | | page document on Primary IFD | | | Bit 4 indicates MRC model | +------------------+-----------------------------------------+ | Orientation | 1**-8, Default 1 | +------------------+-----------------------------------------+ | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | | pretation | | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 44] Internet Draft TIFF-FX Extension 1.0 July 2000 +------------------+-----------------------------------------+ | ResolutionUnit** | 2: inch | +------------------+-----------------------------------------+ | RowsPerStrip | n: number or scanlines per strip | +------------------+-----------------------------------------+ | SamplesPerPixel | 1**, 3 (ImageBaseColor IFD only) | +------------------+-----------------------------------------+ | Software* | {ASCII}: name & release number of | | | creator software | +------------------+-----------------------------------------+ | StripByteCounts**| : number or bytes in each strip | +------------------+-----------------------------------------+ | StripOffsets** | : offset from beginning of file to | | | each TIFF strip | +------------------+-----------------------------------------+ | XResolution | 200**, 204**, 300, 400, 408 (written in | | | pixels/inch) | +------------------+-----------------------------------------+ | YResolution | 98**, 196**, 100**, 200**, | | | 300, 391, 400 (written in pixels/inch) | +------------------+-----------------------------------------+ | Extension Fields | +------------------+-----------------------------------------+ | DocumentName* | {ASCII}: name of scanned document | +------------------+-----------------------------------------+ | PageNumber** | n,m: page number followed by total page | | | count | +------------------+-----------------------------------------+ | SubIFDs | : byte offset to FG/BG IFDs | +------------------+-----------------------------------------+ | XPosition | horizontal offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | YPosition | vertical offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | New Fields | +------------------+-----------------------------------------+ | StripRowCounts | : number of scanlines in each strip | +------------------+-----------------------------------------+ | ImageLayer | n, m: layer number, imaging sequence | | | (e.g., strip number) | +------------------+-----------------------------------------+ | GlobalParameters | IFD: global parameters IFD | | IFD** | | +------------------+-----------------------------------------+ | ProfileType* | n: type of data stored in TIFF file | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 45] Internet Draft TIFF-FX Extension 1.0 July 2000 +------------------+-----------------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +------------------+-----------------------------------------+ | CodingMethods* | n: compression algorithms used in file | +------------------+-----------------------------------------+ | VersionYear* | byte sequence: year of ITU fax standard | +------------------+-----------------------------------------+ | ModeNumber* | n: version of T.44 standard | +------------------+-----------------------------------------+ | TIFF-FXExtensions| n: extension(s) identification number, | | ** | bits 2 and 3 for SharedResources and | | | Profile T shall be among the set bits | +------------------+-----------------------------------------+ | T88Options* | n, m: option numbers, profile number | +------------------+-----------------------------------------+ | SharedResources**| : offset from beginning of file to | | | the first Shared Resource | +------------------+-----------------------------------------+ E1.7. TIFF-FX Extension 5: JBIG2 Extension of Profile M This section defines extensions to Profile M that augment the pool of coders and encoding mechanisms available for use in the mask and foreground layers when encoding documents with colour. The JBIG2, ITU-T Rec. T.88 / ISO-IEC 14492, bilevel coder is made available for use in both mask and foreground layer(s). It must be noted that simple JBIG2 symbol-based compression is limited to matching symbols in a binary image, but ITU-T Rec. T.44 Annex B [T.44Amd1] expands this to include single-colour images, such as coloured text. The T.44 defined mechanism, referenced as color tag encoding, is only available for use in foreground layers that are associated with JBIG2 coded mask layers. The more conventional multi-level colour coders, such JPEG, are also available for use in the encoding of foreground layer colours when JBIG2 is used in the mask layer(s). E1.7.1. Overview Use of JBIG2 in Profile M effectively amounts to application of Profile T (i.e. Section E.2) to the mask layer(s), without imposition of the Profile T black-and-white constraints that prohibit the presence of background and/or foreground image data. This translates to augmenting the MRC 3-layer model and TIFF representation, defined in Profile M, with the Shared Resources extension E1, and using JBIG2 coding (i.e. Compression = 12) in the mask layer. The N-layer model and TIFF representation, defined in Extension 2 (Section E1.4) MAY also be used if the corresponding TIFF- FXExtension bit is set. McIntyre et al. Expires January 2001 [Page 46] Internet Draft TIFF-FX Extension 1.0 July 2000 Use of JBIG2 and colour tagging to encode the colours of the foreground layer(s) translates to attaching discrete colour values to the JBIG2 coded symbols (shapes) that are represented in the associated mask layer. E1.7.2. Required TIFF Fields This section describes the TIFF fields required, in addition to those in Sections 8.2, E1.4 and E1.5.2.3. E1.7.2.1. Baseline Fields Augment the Section 8.2.1 compression field with JBIG2 (i.e. value = 12) as below: 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 colour for a layer and strip will not have any encoded image data associated with it, i.e., the StripByteCounts field will 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. E1.7.2.2. Extension Fields See Section 8.2.2. E1.7.2.3. New Fields Augment Section 8.2.3 with the fields from E1.5.2.3. Bits 2 and 4 of the TIFF-FXExtensions field SHALL be set to 1. E1.7.3. Recommended TIFF Fields See Section E1.6.3. The note that appears at the end of the T88Options[0] table, prohibiting activation of bits 5 or 6 (i.e. ColourTagsFollow or ColourTagsPresent respectively) SHALL be disregarded. If the IFD's T88Options[0] field has the ColourTagsFollow or ColourTagsPresent bits set, then the following segment types SHALL NOT occur in the JBIG2-coded position block: - Pattern dictionary - Halftone region - Generic region E1.7.4 JBIG2 Resources See Section E1.6.4. McIntyre et al. Expires January 2001 [Page 47] Internet Draft TIFF-FX Extension 1.0 July 2000 E1.7.5 The Image Strip See Section E1.6.5. E1.7.6 Representation of JBIG2 data in TIFF See Section E1.6.6. E1.7.7 Colour Tag (Colour Symbol) Compression E1.7.7.1 Why Use Colour Tag Compression Another opportunity that is afforded by JBIG2 is improved compression of the foreground layer for documents containing coloured text. In most cases, if a document contains text, each individual text character is a single, flat, colour (e.g., black or red), and the number of such colours is limited. The foreground layer in this case looks like a number of coloured blobs, one for each character, each one having the shape of the corresponding character. This foreground layer can be compressed using a new method that takes advantage of the JBIG2 structure. If the mask layer is compressed using JBIG2 symbols, then decoding it essentially yields a sequence of (XPositon, YPosition, Symbol ID) triples. Each triple indicates that the symbol (from some dictionary) specified by "Symbol ID" SHOULD be drawn at the location "(X, Y)". Simply augmenting a text region triple with a fourth component, the colour of that individual character (the symbols "colour tag"), allows storage of the foreground layer in a very small amount of space: using run- length coding on those colours. The total space taken by the foreground layer can be as small as a few tens of bytes. For example, if the mask layer contained two characters, an "R" in a red colour and a "B" in a blue colour, then the mask layer would decompress to (100, 0, "R") (120, 0, "B") and the foreground layer would decompress to ITULAB #7AE29D (corresponding to CIELAB (48.0, 65.5, 48.0), using the default gamut range for ITULAB) ITULAB #3B9F1E (corresponding to CIELAB (23.1, 20.4, -52.1), using the default gamut range for ITULAB) or some other suitable representation of the colours, such as indexes into a palette. Matching up the "R" symbol with the colour #7AE29D and drawing the symbol's shape in the red colour gives the correct result. This is a single drawing operation, and is extremely efficient. E1.7.7.2 Colour Tag Terms of Use in TIFF Colour tags are one of the JBIG2 image strip extensions referenced in Section E1.6.5 (The JBIG2 Image Strip) of the Profile T extension. Their Representation within the image strip is expressed within Section E1.6.5.1 (Image Strip Format). Stepping back and considering the MRC (Mixed Raster Content) mask (bilevel data) and foreground (colour data) layer pairs, we arrive at the following terms of use to be applied when colour tagging is used in foreground representation: McIntyre et al. Expires January 2001 [Page 48] Internet Draft TIFF-FX Extension 1.0 July 2000 1. the (JBIG2-compressed) bilevel data (position block) SHALL be followed immediately (in the file) by the colour tags. The colour tags SHALL appear as an extension in the JBIG2 image strip, with the image strip extension type = 1 (colour tags). The colour tags SHALL be compressed using ITU-T Rec. T.45. the mask IFD points to the start of the bilevel data, and the associated byte count SHALL include ONLY the bilevel data (the position block, but not the colour tags). The IFD's Compression tag SHALL be set to 12 (JBIG2). If present, the T88Options[0] field SHOULD have bit 5 set to 1 (ColorTagsFolow). 3. the foreground IFD points to the bilevel data, and the associated byte count SHALL include BOTH the bilevel data and the colour tag extension. The IFD's Compression tag SHALL be set to 12 (JBIG2). The IFD's PhotometricInterpretation will indicate the colour space used to interpret the colors found in the colour tag data. If present, the T88Options[0] field SHOULD have bit 6 set to 1 (ColorTagsPresent). 4. in the event that two symbol instances overlap, the reconstructed image SHOULD be the one obtained by drawing each JBIG2 symbol with the appropriate colour, where the drawing SHALL be done in the order that the JBIG2 symbols appear in the encoded JBIG2 image strip. Thus, the foreground IFD completely describes an image: it points to enough data to reconstruct a coloured image that contains the right colour at each pixel selected by the mask. It is reasonable that a decoder will recognize that both a mask IFD and a foreground IFD point to the same JBIG2 data, and decode the JBIG2 data only once (not once for the mask, and again for the foreground). The T88Options[0] bits "ColourTagsFollow" and "ColourTagsPresent" are designed to make the decoder's job easier: if it sees ColourTagsFollow in the T88Options[0] field of a mask IFD, it knows it should defer decoding it until it decodes the corresponding foreground IFD. Similarly, if it sees ColourTagsPresent in a foreground IFD, then it can optimize the drawing/decoding operations. Note: This representation has two pointers to the same part of the TIFF-FX file, which is a violation of a TIFF guideline, and could conceivably cause problems in some unsuspecting TIFF editors. However, these unsuspecting TIFF editors would probably be confused anyway by the IFD structure required by MRC, let alone the JBIG2 data. The shared pointers occur only in a restricted case. The nature of the two pointers is illustrated below: McIntyre et al. Expires January 2001 [Page 49] Internet Draft TIFF-FX Extension 1.0 July 2000 +----------------------------+ | | | | | | | | +----------------------------+ | ... | | SubIFD 0 StripOffsets |--: | StripByteCounts|--|-: | ... | | | +----------------------------+ | | mask IFD's | | | | StripByteCounts includes :---|------------<---------------|--: | only bilevel data | | | | mask and | +----------------------------+<---:<--: foreground :-->| JBIG2 Symbols & | | | IFD both | | data positions | | | foreground IFD's point to | | _______________ |<---: | StripByteCounts includes bilevel | | Colour Tag extension | | both bilevel data and data | +----------------------------+ <--: colour tags | | | | :---|------------<---------------|--: | | | | | +----------------------------+ | | | ... | | | | SubIFD 1 StripOffsets |--: | | StripByteCounts|--------: | ... | +----------------------------+ | | | | | | | | | | | | +----------------------------+ E1.7.8 Rules and Requirements for Images Revise the identified Profile M Section 8.4 Rules and Requirements for Images as follows: a. Revise Rule 1 to read: 1. If more than one layer exists, then the binary Mask layer SHALL be present and be the primary image. The Mask layer SHALL support the binary data representations defined in Section 3 and MAY support the binary data representations defined in Sections 4, 5 and E1.6, with the exception that PhotometricInterpretation MUST be 0. If only one layer exists, then the image corresponding to that layer is the primary image. McIntyre et al. Expires January 2001 [Page 50] Internet Draft TIFF-FX Extension 1.0 July 2000 b. Revise Rule 3 to read: 3. The Background and Foreground images SHALL support the color representations defined in Section 6 and MAY support the color representations defined in Sections 7 or E1.7. E1.7.9. JBIG2 Extension of Profile M Summary Recommended fields are shown with an asterisk * Required fields or values are shown with a double asterisk **. If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations. +------------------+-----------------------------------------+ | Baseline Fields | Values | +------------------+-----------------------------------------+ | BitsPerSample | 1**: binary mask | | | 2-8**: bits per color sample | | | 9-16: optional 12 bits/sample | +------------------+-----------------------------------------+ | Compression | 1: None (ImageBaseColor IFD only) | | | 3**: Modified Huffman and Modified Read | | | 4: Modified Modified Read | | | 7**: JPEG | | | 9: JBIG, per T.85 | | | 10: JBIG, per T.43 | | | 12: JBIG2, per T.88 and T.45 | +------------------+-----------------------------------------+ | DateTime* | {ASCII): date/time in the 24-hour format| | | "YYYY:MM:DD HH:MM:SS" | +------------------+-----------------------------------------+ | FillOrder** | 1: Most significant bit first | | | 2: Least significant bit first | +------------------+-----------------------------------------+ | ImageDescription*| {ASCII}: A string describing the | | | contents of the image. | +------------------+-----------------------------------------+ | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | | | 2592, 3072, 3456, 3648, 4096, 4864 | +------------------+-----------------------------------------+ | ImageLength** | n: total number of scanlines in image | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 51] Internet Draft TIFF-FX Extension 1.0 July 2000 +------------------+-----------------------------------------+ | NewSubFileType** | 16, 18: | | | Bit 1 indicates single page of a multi- | | | page document on Primary IFD | | | Bit 4 indicates MRC model | +------------------+-----------------------------------------+ | Orientation | 1**-8, Default 1 | +------------------+-----------------------------------------+ | PhotometricInter | 0**: WhiteIsZero (Mask Layer) | | pretation | 2: RGB | | | 5: CMYK | | | 10**: ITULAB | +------------------+-----------------------------------------+ | ResolutionUnit** | 2: inch | +------------------+-----------------------------------------+ | RowsPerStrip | n: number or scanlines per strip | +------------------+-----------------------------------------+ | SamplesPerPixel | 1**: L* (lightness) | | | 3: RGB, LAB, CMY | | | 4: CMYK | +------------------+-----------------------------------------+ | Software* | {ASCII}: name & release number of | | | creator software | +------------------+-----------------------------------------+ | StripByteCounts**| : number or bytes in each strip | +------------------+-----------------------------------------+ | StripOffsets** | : offset from beginning of file to | | | each TIFF strip | +------------------+-----------------------------------------+ | XResolution | 100, 200**, 300, 400 (written in | | | pixels/inch) | +------------------+-----------------------------------------+ | YResolution | equal to XResolution (pixels must be | | | square) | +------------------+-----------------------------------------+ | Extension Fields | +------------------+-----------------------------------------+ | T4Options | 0**: required if Compression is Modified| | | Huffman, EOLs not byte aligned | | | 1: required if Compression 2D Modified | | | Read, EOLs are not byte aligned | | | 4**: required if Compression Modified | | | Huffman, EOLs byte aligned | | | 5: required if Compression 2D Modified | | | Read, EOLs are byte aligned | +------------------+-----------------------------------------+ | T6Options | 0: required if Compression is 2D | | | Modified Modified Read | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 52] Internet Draft TIFF-FX Extension 1.0 July 2000 +------------------+-----------------------------------------+ | DocumentName* | {ASCII}: name of scanned document | +------------------+-----------------------------------------+ | PageNumber** | n,m: page number followed by total page | | | count | +------------------+-----------------------------------------+ | ChromaSubSampling| (1,1), (2, 2)** | | | (1, 1): equal numbers of lightness and | | | chroma samples horizontally & vertically| | | (2, 2): twice as many lightness samples | | | as chroma horizontally and vertically | +------------------+-----------------------------------------+ | ChromaPositioning| 1: centered | +------------------+-----------------------------------------+ | Indexed | 0: not a palette-color image | | | 1: palette-color image | +------------------+-----------------------------------------+ | SubIFDs | : byte offset to FG/BG IFDs | +------------------+-----------------------------------------+ | XPosition | horizontal offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | YPosition | vertical offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | New Fields | +------------------+-----------------------------------------+ | Decode | minL, maxL, mina, maxa, minb, maxb: | | | minimum and maximum values for L*a*b* | +------------------+-----------------------------------------+ | ImageBaseColor | a,b,c: background color in ITULAB | +------------------+-----------------------------------------+ | StripRowCounts | : number of scanlines in each strip | +------------------+-----------------------------------------+ | ImageLayer | n, m: layer number, imaging sequence | | | (e.g., strip number) | +------------------+-----------------------------------------+ | T82Options | 0: T.85 profile of T.82 coding | +------------------+-----------------------------------------+ | GlobalParameters | IFD: global parameters IFD | | IFD** | | +------------------+-----------------------------------------+ | ProfileType* | n: type of data stored in TIFF file | +------------------+-----------------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +------------------+-----------------------------------------+ | CodingMethods* | n: compression algorithms used in file | +------------------+-----------------------------------------+ McIntyre et al. Expires January 2001 [Page 53] Internet Draft TIFF-FX Extension 1.0 July 2000 +------------------+-----------------------------------------+ | VersionYear* | byte sequence: year of ITU fax standard | +------------------+-----------------------------------------+ | ModeNumber* | n: version of T.44 standard | +------------------+-----------------------------------------+ | TIFF-FXExtensions| n: extension(s) identification number, | | ** | bits 2 and 4 for SharedResources and | | | Profile M shall be among the set bits | +------------------+-----------------------------------------+ | T88Options* | n, m: option numbers, profile number | | | - if colour tag is used then bit 1 of n | | | SHALL NOT be set | | | - if bit 5 is set then IFD is in mask | | | layer with colour tag augmented JBIG2 | | | coded corresponding foreground layer | | | - if bit 6 is set then IFD is in | | | foreground layer with colour tag | | | augmented JBIG2 coding | +------------------+-----------------------------------------+ | SharedResources**| : offset from beginning of file to | | | the first Shared Resource | +------------------+-----------------------------------------+ E1.8. Security Considerations This document describes a file format for Internet fax, which is a series of profiles of TIFF for facsimile. As such, it does not create any security issues not already identified in [TIFF-REG], in its use of fields as defined in [TIFF]. There are also new TIFF fields defined within this specification, but they are of a purely descriptive nature, so that no new security risks are incurred. Further, the encoding specified in this document does not in any way preclude the use of any Internet security protocol to encrypt, authenticate, or non-repudiate TIFF-encoded facsimile messages. E1.9. References The following references are appended to the list in Section 11 of RFC XXXX. [RFC XXXX] RFC XXXX, Draft Standard "File Format for Internet Fax", known as TIFF-FX (pending issue) [T.4 Amd1] Amendment 1 to ITU-T Recommendation T.4, Standardization of group 3 facsimile apparatus for document transmission, March 2000 McIntyre et al. Expires January 2001 [Page 54] Internet Draft TIFF-FX Extension 1.0 July 2000 [T.44Amd1] Amendment 1 to ITU-T Recommendation T.44, Mixed Raster Content (MRC), March 2000. [T.45] ITU-T Recommendation T.45, Run-length Colour Encoding, March 2000. [T.88] ITU-T Recommendation T.88|ISO/IEC 14492:2000, Information technology- Lossy/Lossless coding of Bi-level Images. (Commonly referred to as JBIG2 standard.) [T.89] ITU-T Draft Recommendation T.89, Appliction Profiles for Recommendation T.88 - Lossy/Lossless Coding of Bi-level Images (JBIG2) for Facsimile, March 2000. E1.10 Authors' Addresses Dave Abercrombie Xerox Corporation Mailstop PAHV-121 3333 Coyote Hill Road Palo Alto, CA 94304 USA Voice: +1-650-812-4789 Fax: +1-650-812-4777 Email: dabercro@parc.xerox.com Lloyd McIntyre William Rucklidge Xerox Corporation Intelligent Markets Mailstop PAHV-121 410 Jessie St., Suite 602 3400 Hillview Ave San Fransisco, CA 94103, USA Palo Alto, CA 94304 USA Voice: +1-415-369-5013 Voice: +1-650-813-6762 Email: wjr@imarkets.com Fax: +1-650-845-2340 Email: lmcintyre@pahv.xerox.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of McIntyre et al. Expires January 2001 [Page 55] Internet Draft TIFF-FX Extension 1.0 July 2000 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McIntyre et al. Expires January 2001 [Page 56]