INTERNET-DRAFT L. McIntyre
Fax Working Group Xerox Corporation
November 17th, 2000 D. Abercrombie
draft-ietf-fax-tiff-fx-extension1-00.txt Xerox Corporation
W. Rucklidge
Intelligent Markets
R. Buckley
Xerox Corporation
November 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
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
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 May 2001 [Page 0]
Internet Draft TIFF-FX Extensions 1.0 November 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 data 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. These extensions do not required modification of
existing TIFF-FX implementations.
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 <http://www.ietf.org/ipr.html>.
McIntyre et al. Expires May 2001 [Page 1]
Internet Draft TIFF-FX Extensions 1.0 November 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. MultiProfiles Field-------------------------------------8
E1.3. TIFF-FX Extension 1 (E1): Resolution and ImageWidth Extensions--10
E1.4. TIFF-FX Extension 2 (E2): N-Layer Profile M Extension-----------14
E1.4.1. Introduction-----------------------------------------------14
E1.4.2. Section 8.1. Overview--------------------------------------15
E1.4.3. Section 8.1.1. MRC 3-layer model---------------------------15
E1.4.4. Section 8.1.2. A TIFF Representation for the MRC 3-layer
model------------------------------------------------------16
E1.4.5. Section 8.2.1. Baseline Fields-----------------------------18
E1.4.6. Section 8.2.2. Extension Fields----------------------------19
E1.4.7. Section 8.2.3. New Fields----------------------------------19
E1.4.8. Section 8.4. Rules and Requirements for Images-------------21
E1.4.9. Section 8.5. Profile M - MRC Fax Profile Summary-----------22
E1.5. TIFF-FX Extension 3 (E3): Shared Data Extension to Profile M----22
E1.5.1. Overview---------------------------------------------------22
E1.5.2. Required TIFF Fields---------------------------------------23
E1.5.3. Recommended Fields-----------------------------------------23
E1.5.4. Shared Data------------------------------------------------23
E1.5.4.1. SharedDataList-----------------------------------------26
E1.5.4.2. Representation of Shared Data in TIFF------------------27
E1.6. TIFF-FX Extension 4 (E4): 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.2.1. Baseline Fields----------------------------------------31
E1.6.2.2. Extension Fields---------------------------------------33
E1.6.2.3. New Fields---------------------------------------------33
E1.6.3. Recommended TIFF Fields------------------------------------33
E1.6.4. JBIG2 Shared Data------------------------------------------36
E1.6.4.1. The JBIG2 Shared Data----------------------------------36
E1.6.4.2. JBIG2 SharedDataMemory --------------------------------38
E1.6.5. The JBIG2 Image Strip--------------------------------------39
E1.6.5.1. Image Strip Format-------------------------------------41
E1.6.6. Representation of JBIG2 data in TIFF-----------------------42
E1.6.7. Rules and Requirements for Images--------------------------45
E1.6.8. Profile T - Lossy and Lossless JBIG2 Black-and-White
Fax profile Summary----------------------------------------46
McIntyre et al. Expires May 2001 [Page 2]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.7. TIFF-FX Extension 5 (E5): JBIG2 Color Extension of Profile M----48
E1.7.1. Overview---------------------------------------------------48
E1.7.2. Required TIFF Fields---------------------------------------49
E1.7.2.1. Baseline Fields----------------------------------------49
E1.7.2.2. Extension Fields---------------------------------------49
E1.7.2.3. New Fields---------------------------------------------49
E1.7.3. Recommended TIFF Fields------------------------------------49
E1.7.4. JBIG2 Shared Data------------------------------------------50
E1.7.5. The Image Strip--------------------------------------------50
E1.7.6. Representation of JBIG2 data in TIFF-----------------------50
E1.7.7. Colour Tag (Color Symbol Compression-----------------------50
E1.7.7.1. Why use Colour Tag Compression-------------------------50
E1.7.7.2. Colour Tag Terms of Use in TIFF------------------------50
E1.7.8. Rules and Requirements for Images--------------------------52
E1.7.9. JBIG2 Extension of Profile M Summary-----------------------53
E1.8. Security Considerations-----------------------------------------56
E1.9. References------------------------------------------------------56
E1.10. Authors' Addresses---------------------------------------------57
Full Copyright Statement----------------------------------------------57
McIntyre et al. Expires May 2001 [Page 3]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.1. Introduction
This document describes extensions to RFC XXXX [RFCXXXX], titled
"File Format for Internet Fax", also known as TIFF-FX, 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:
Profile T: TIFF-FX Extension 4: Black-and-White JBIG2 Extension - a
JBIG2 profile for binary only T.88|ISO/IEC 14492 [T.88] coded
data, built upon Profile M and the Shared Data extension to
Profile M (TIFF-FX Extension 5).
and create new extensions for the following new features:
TIFF-FX Extension 1 (E1): Resolution and ImageWidth Extensions -
extends the resolutions and image widths available for all
Profiles, with the exception of Profile S
TIFF-FX Extension 2 (E2): N-Layer Profile M Extension - extends
the 3-layer model into N layers
TIFF-FX Extension 3 (E3): Shared Data 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 (E5): JBIG2 Color Extension of Profile M - the
binary and color extension to Profile M which enables JBIG2
coding using T.88 (JBIG2,binary) and T.45 [T.45] "Run-length
Colour Encoding", required for colour tag extensions to JBIG2.
This extension specification of TIFF-FX for facsimile is known as
TIFF-FX Extensions 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],
selected TIFF Technical Notes [TTN1, TTN2] and [T.30].
McIntyre et al. Expires May 2001 [Page 4]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.1.2 Overview of this draft
This Section gives an overview of TIFF-FX Extensions 1. Section E1.2
describes the requirements and recommendations associated with all
TIFF-FX extensions defined within this document.
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-T compatible field values
(image parameters) for Profile T.
Throughout this document, Profiles, and section numbers without an
"E1" prefix, refer to [RFC XXXX].
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 May 2001 [Page 5]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.2. TIFF Fields Required or Recommended 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 extension, such as SharedData
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 field 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 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
permitted in any other IFD. The new SharedData field is one such
field that is not permitted in any other IFD, see the Shared Data
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 field 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 May 2001 [Page 6]
Internet Draft TIFF-FX Extensions 1.0 November 2000
TIFF-FXExtensions (407) LONG
Count = 1
[[The 407 tag value is subject to change]]
This field identifies the RFC XXXX extension(s) that apply. The field
accommodates the need to continually enhance the functionality of
TIFF-FX. This field SHALL only appear in the GlobalParametersIFD, it
is NOT permitted 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.
Current TIFF-FX Extensions:
+------+---------+---------------------------------------------------+
| Bit |Extension| 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 used. |
+------+---------+---------------------------------------------------+
| 1 | 2 | N-Layer Profile M Extension |
| | | If bit 1 is 1, then the provision for more than |
| | | three MRC layers is used. |
+------+---------+---------------------------------------------------+
| 2 | 3 | Shared Data Extension to Profile M |
| | | If bit 2 is 1, then Profile M and Shared Data |
| | | provisions are used. |
+------+---------+---------------------------------------------------+
| 3 | 4 | Profile T - Black-and-White JBIG2 Extension |
| | | If bit 3 is 1, then Black-and-White JBIG2 coding |
| | | is used (i.e. Compression = 12, TIFF-FXExtensions |
| | | bit 2 is set and bi-level constrained MRC model |
| | | is applied). |
+------+---------+---------------------------------------------------+
| 4 | 5 | JBIG2 Extension of Profile M |
| | | If bit 4 is 1, JBIG2 is used for Mask layer coding|
| | | and colour tags may be used for foreground layers |
| | | (i.e. Compression = 12 and TIFF-FXExtensions bit 2|
| | | is set). |
+------+---------+---------------------------------------------------+
Default = 0, no extensions being used.
McIntyre et al. Expires May 2001 [Page 7]
Internet Draft TIFF-FX Extensions 1.0 November 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 profile list to
include the new Profile T, specified later in this document.
E1.2.2.1.1 Instructions
Replace the existing FaxProfile field 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-FX and it's
extensions.
This field is used to indicate the profile used within the file when
only one profile is used. The MultiProfiles field is used when a
TIFF-FX extension or more than one profile is used within the file.
A FaxProfile value of 255 (X'FF') indicates that the MultiProfiles
field 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
255: MultiProfiles field, indicates the profiles and/or profile(s)
plus extension(s) used in the file
E1.2.2.2. MultiProfiles Field
This field is used to indicate when extension(s) or two or
more different profiles are used within 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 color 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
and extended profile or more than one profile is used within a file.
McIntyre et al. Expires May 2001 [Page 8]
Internet Draft TIFF-FX Extensions 1.0 November 2000
Files containing extension(s) or more that one profile SHOULD contain
the MultiProfiles field, identifying the profiles or extension(s)
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 = N
[[The 406 tag value is subject to change]]
The extended profile (i.e. profile plus extension) or more than one
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 an extended profile or more than one
profiles are used within the file. This field SHALL only be present
when the FaxProfile field is absent or has a value of 255 (X'FF').
A value of 1 in more than one bit location indicates the
Corresponding profiles or profile(s) plus extension(s) that are
used. The currently defined bits are:
MultiProfiles[0]:
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
Bit 7: Extension 1 (E1), resolution and imagewidth extensions
Bit 8: Extension 2 (E2), N-Layer Profile M extension
Bit 9: Extension 3 (E3), shared data extension to Profile M
Bit 10: Extension 5 (E5), JBIG2 extension of Profile M
Bits 11-31: reserved for future use.
WARNING: Files containing extensions or more that one profile
"SHOULD" contain the MultiProfiles field, identifying the profiles
McIntyre et al. Expires May 2001 [Page 9]
Internet Draft TIFF-FX Extensions 1.0 November 2000
present. See the description from the second paragraph of Section
E1.2.2.2.
NOTE: count (N) > 1 should be used to accommodate future
expansion beyond 32 bits.
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 (E1): 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:
McIntyre et al. Expires May 2001 [Page 10]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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":
+--------------+--------------+--------------+--------------+
| 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
McIntyre et al. Expires May 2001 [Page 11]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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.
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 | | | |
+--------------------------------+---------+--------+--------+
McIntyre et al. Expires May 2001 [Page 12]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+--------------------------------+---------+--------+--------+
| 600 x 600, 600 x 1200 | 5184 | 6144 | 7296 |
+--------------------------------+---------+--------+--------+
| 1200 x 1200 | 10368 | 12288 | 14592 |
+--------------------------------+---------+--------+--------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+
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 SHALL 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
resolutions 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 |
+--------------------------------+---------------------------+
McIntyre et al. Expires May 2001 [Page 13]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+--------------------------------+---------------------------+
| 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 |
+---------------------------+
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 SHALL equal XResolution. Base
resolution is 200 pixels per inch.
E1.4. TIFF-FX Extension 2 (E2): N-Layer Profile M Extension
E1.4.1 Introduction
This section tracks [T.44] by defining 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, bi-level,
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
McIntyre et al. Expires May 2001 [Page 14]
Internet Draft TIFF-FX Extensions 1.0 November 2000
color. Of these, several may be odd shapes (non-rectangular), and
would require a separate mask to select their regions.
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.
E1.4.2. Section 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. Section 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, where N is odd) and
Foreground (odd numbered layers such as 3, 5, 7,..., N, where N is
odd) 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, where N is odd). The odd numbered layers (Background and
Foreground) are typically 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.
McIntyre et al. Expires May 2001 [Page 15]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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 of this section, 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) SHALL
be one of the layers, in which case it is the primary image. In all
cases, the primary image SHALL be page size.
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 4, 6, ..., N-1, where N is odd) 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 set independent of each
other.
E1.4.4. Section 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:
McIntyre et al. Expires May 2001 [Page 16]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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 SHALL 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 SHALL 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, where N is odd], or Foreground [layer 3, 5, 7, ...,
N, where N is odd]) 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.
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:
McIntyre et al. Expires May 2001 [Page 17]
Internet Draft TIFF-FX Extensions 1.0 November 2000
(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
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. Section 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 fields and
specify the impact of having no image data in the multiple mask and
foreground layer pairs.
a) ImageWidth - replace with the following:
ImageWidth(256). SHORT or LONG
Primary images define the page widths, which SHALL be limited to the
same set of widths as defined in 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
McIntyre et al. Expires May 2001 [Page 18]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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 SHALL 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 field 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 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 layers and
White for the Background layer. The ImageBaseColor field can be used
to specify other default image colors, see 8.2.3.
e) YResolution - replace the last sentence with the following:
The resolution of Mask, Background and Foreground layers SHALL 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. Section 8.2.2. Extension Fields
The objective is to reflect presence of the multiple mask layers.
a) T6Options - replace the field with the following:
T6Options(293) = 0. SHORT
For Mask layers, see Section 4.2.2.
E1.4.7. Section 8.2.3. New Fields
The objective is to reflect presence of the multiple mask and
foreground layers, their impact on the ImageLayer field and resulting
extension of the ImageLayer[0] field values. The newly required TIFF-
FXExtension field and minimal bit setting are specified.
a) T82Options - replace the field with the following:
McIntyre et al. Expires May 2001 [Page 19]
Internet Draft TIFF-FX Extensions 1.0 November 2000
T82Options(435) LONG
For Mask layers, see Section 5.2.3.
b) ImageLayer - replace the field, 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 1through 3 below.
The ImageLayer field contains two values, describing the layer to
which the image belongs and the order in which it is imaged.
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
SHALL be the Primary IFD and be full page in extent.
3: Image is the first Foreground image, i.e. the image that will
be rendered on top of the lower layer (layer 1) 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: If N is odd, then layer N-1 is the (N-1)/2-th Mask layer.
N: If N is odd, then layer N is the (N-1)/2-th Foreground image,
i.e. the image that will be rendered on top of the composite of
layers 1 through N-2 below whenever the (N-1)/2 Mask contains a
value of 1.
If N is even, then layer N is the N/2-th Mask layer, which will
rendered as black on top of the composite layers of 1 through
N-1, whenever the image contains a value of 1.
c) TIFF-FX extensions - append the following field at the end of the
section:
McIntyre et al. Expires May 2001 [Page 20]
Internet Draft TIFF-FX Extensions 1.0 November 2000
TIFF-FXExtensions (407) bit 1 is 1 LONG
See Section E1.2.1.2.
E1.4.8. Section 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. These rules, with the appropriate black-and-
white (bi-level) constraints, also apply to Profile T.
1. If more than one layer exists, then 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 or E1.6. PhotometricInterpretation SHALL
be set to "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.
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 SHALL NOT 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/secondary mask 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,
where N is odd) or mask layers (layer 2, 4, 6, ..., N-1, where N
is odd), 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 SHALL each be an
integer factor of the Primary Mask image. For example, if the
Primary Mask image is 400pixels/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).
McIntyre et al. Expires May 2001 [Page 21]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.4.9. Section 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 field to the table and callout the need to activate the
N-Layer Profile M Extension bit.
a) Revise the following Section 8.5 table entries to read as shown:
+------------------+-----------------------------------------+
| SubIFDs | <IFD>: byte offset to FG, BG, |
| | or secondary mask IFDs |
+------------------+-----------------------------------------+
+------------------+-----------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD** | |
+------------------+-----------------------------------------+
b) Append the following to Section 8.5 table:
+------------------+-----------------------------------------+
| TIFF-FXExtensions| n: extension(s) identification number, |
| ** | bit 1 for N-Layer Profile M Extension |
| | SHALL be among the set bits |
+------------------+-----------------------------------------+
E1.5. TIFF-FX Extension 3 (E3): Shared Data Extension to Profile M
This section defines the Shared Data extension to Profile M. Shared
Data accommodate a single representation of reusable resources,
such as image data or encoding tables, that appear or are used
multiple times within a file. 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]. Use of Shared Data is restricted to the MRC
structure defined in Profile M or M with N layers, as defined
in this document. Rational for Shared Data in Profile M only is
traceable to T.44 Annex B [T.44Amd1].
E1.5.1. Overview
Many pages and/or documents have repeating components such as shapes
or symbols, words, images and meta-data (i.e. Huffman Tables).
This is especially true for images of text, where the repeating
shapes are the characters themselves. The SharedData field is
McIntyre et al. Expires May 2001 [Page 22]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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. Reference to a resource
must be made with an explicit and unique reference to the Shared
Data, from within the data stream that uses it (the referencing data
stream).
E1.5.2. Required TIFF Fields
This section describes the TIFF fields required, in addition to
those in Section 8.2, to represent Shared Data.
E1.5.2.1. Baseline Fields
See Section 8.2.1.
E1.5.2.2. Extension Fields
See Section 8.2.2.
E1.5.2.3. New Fields
Append the following to the fields of 8.2.3:
GlobalParametersIFD (400) IFD or LONG
See Section E1.2.1
TIFF-FXExtensions (407) bit 2 SHALL be 1 LONG
See Section E1.2.1
SharedData (437) LONG
[[The 437 tag value is subject to change]]
See Section E1.5.4.
E1.5.3. Recommended TIFF Fields
See Sections 8.3, with exception of GlobalParametersIFD.
E1.5.4 Shared Data
The following new field is defined:
SharedData (437) LONG
Count = 1
[[The 437 tag value is subject to change]]
The SharedData field contains the file offset (E), in bytes, from the
beginning of the file of the first Shared Data Table. Each Shared
Data Table contains a count of the number of Shared Data Entries that
physically exist in the table (whether filled with a shared data or
not) , the Shared Data Entries themselves, and the file location of
the next Shared Data Table (if any).
McIntyre et al. Expires May 2001 [Page 23]
Internet Draft TIFF-FX Extensions 1.0 November 2000
There can be as many Shared Data Tables as necessary to describe the
number of shared data items, but there SHALL be only one SharedData
field in a file, and it SHALL be in the GlobalParametersIFD
(recommended to be in the first IFD in the file). The SharedData
field is required when sharing data and SHALL be present. A
SharedData value of zero "0" means that there are no Shared Data
Tables present and that no data is currently being shared.
Each Shared Data Table consists of a 2-byte count of the number of
physical entries, a sequence of 16-byte shared data entries, and a 4-
byte offset to the next Shared Data Table. The last shared data
table has a "next table file offset" of 0.
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 Data Table
+-----+--------------+-----+---------------------------------------+
|Bytes| Byte offsets |Type | Description |
+-----+--------------+-----+---------------------------------------+
| 2 | E - E+1 |SHORT| Items in table - (i) The number of |
| | | | shared data entries that are |
| | | | physically in this table, whether |
| | | | populated (non-zero byte entries) or |
| | | | not. |
+-----+--------------+-----+---------------------------------------+
| 16 | E+2 - E+17 | - | Item 1 - First shared data entry. |
+-----+--------------+-----+---------------------------------------+
| 16 | E+18 - E+33 | - | Item 2 - Second shared data 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 Data Table. |
| | | | Where i = shared data entries in this |
| | | | table (see "items in table", above), |
| | | | and each shared data item entry is 16 |
| | | | bytes, N = E+2+16*i. |
+-----+--------------+-----+---------------------------------------+
McIntyre et al. Expires May 2001 [Page 24]
Internet Draft TIFF-FX Extensions 1.0 November 2000
Shared Data Entries
+-----+--------------+-----+---------------------------------------+
|Bytes| Byte offsets |Type | Description |
+-----+--------------+-----+---------------------------------------+
| 4 | Y - Y+3 |LONG | Shared Data bytes - Size of the |
| | | | shared data data block, in bytes. |
+-----+--------------+-----+---------------------------------------+
| 4 | Y+4 - Y+7 |LONG | Shared Data file offset - File offset |
| | | | of this shared data data block, in |
| | | | bytes, from beginning of file. |
+-----+--------------+-----+---------------------------------------+
| 2 | Y+8 - Y+9 |SHORT| SharedDataType - The type of data |
| | | | being represented as a shared data. |
| | | | The table below contains the type of |
| | | | shared data currently defined. |
+-----+--------------+-----+---------------------------------------+
| 2 | Y+10 - Y+11 |SHORT| Last page used - The page (primary |
| | | | IFD) ordinal (1, 2, ...) of the last |
| | | | page that references this shared data.|
| | | | A value of 0 indicates that the last |
| | | | page to use the shared data is not |
| | | | known. |
| | | | The page ordinal SHOULD be based on |
| | | | the order within the primary IFD |
| | | | chain. |
+-----+--------------+-----+---------------------------------------+
| 4 | Y+12 - Y+15 |LONG | SharedDataMemory - the number of bytes|
| | | | required by the referencing data |
| | | | stream to hold this shared data. If |
| | | | the shared data is encoded then the |
| | | | memory required SHOULD be consistent |
| | | | with the decoded form of the shared |
| | | | data. |
| | | | A value of 0 indicates that the |
| | | | SharedDataMemory is not known, or this|
| | | | field is not applicable. |
| | | | When defining a shared data and |
| | | | SharedDataMemory is applicable, a |
| | | | formula for computing the |
| | | | SharedDataMemory SHALL be given within|
| | | | the definition of the referencing data|
| | | | stream. |
| | | | An example of such a formula may be |
| | | | found in Section E1.6.4.2 for JBIG2. |
+-----+--------------+-----+---------------------------------------+
McIntyre et al. Expires May 2001 [Page 25]
Internet Draft TIFF-FX Extensions 1.0 November 2000
Current SharedDataTypes:
+----------------+---------------------------------------------+
| SharedDataType | Description |
| Value | |
+----------------+---------------------------------------------+
| 0 | undefined |
+----------------+---------------------------------------------+
| 1 | JBIG2 Shared Data (i.e. JBIG2 symbol |
| | dictionaries, pattern dictionaries, Huffman |
| | tables, etc) |
+----------------+---------------------------------------------+
Shared Data ID:
The reference to a shared data entry SHALL be by a unique ID, which
SHALL be the offset of the entry in the list described by the Shared
Data Tables; the first shared data entry SHALL have ID 0. Note that
the "list" of shared data entries is what the series of Shared Data
Tables SHALL contain, when collected together. The order of the
shared data tables SHALL determine the order of the shared data IDs.
For example, if the first three tables (A, B and C) have 3, 1 and 2
shared data respectively; then table A will contain shared data with
IDs 0, 1, and 2; table B will contain the shared data with ID 3; and
table C will contain shared data with IDs 4 and 5. Note that if
copying shared data from one file to another, the shared data ID will
likely need revision to be brought in alignment with the destination
table; additionally, any copied data that refers to the copied shared
data will require a change in the reference to the new ID.
E1.5.4.1 SharedDataList
The data stream that requires inclusion of one or more Shared Data
(i.e. the reference data stream) may include a list of IDs in a
SharedDataList. For instance, an image strip that requires a shared
data in order to be a complete compressed data stream, will include a
SharedDataList. It is up to the interpretation of the reference data
type (i.e. Compression type) as to how the shared data will be used.
A SharedDataList, located at file offset P, in bytes, from the
beginning of the file, SHALL contain a 2-byte count of the number of
IDs (i) in the list, followed by i 4-byte IDs.
SharedDataList Structure
+-----+---------------+-----+---------------------------------------+
|Bytes| Byte offsets |Type | Description |
+-----+---------------+-----+---------------------------------------+
| 2 | P - P+1 |SHORT| The number of shared data IDs (i) |
+-----+---------------+-----+---------------------------------------+
| 4 | P+2 - P+5 |LONG | First shared data ID |
+-----+---------------+-----+---------------------------------------+
McIntyre et al. Expires May 2001 [Page 26]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+-----+---------------+-----+---------------------------------------+
| 4 | ... |LONG | ... |
+-----+---------------+-----+---------------------------------------+
| 4 | P+2+(i-1)*4 - |LONG | i-th shared data ID |
| | P+5+(i-1)*4 | | |
+-----+---------------+-----+---------------------------------------+
E1.5.4.2 Representation of Shared Data in TIFF
The representation of Shared Data in a TIFF file is shown below:
+------+----------------------+---------------------------------+
| | | "II" or "MM" |
| | +---------------------------------+
| | TIFF Header | 42 |
| | +---------------------------------+
| | | FirstIFD offset (IFD0) |---:
| +----------------------+---------------------------------+ |
| | ... | |
| :---|---------------------------<----------------------------|---:
| | | ... |
| v +----------------------+---------------------------------+
| | | | ... |
| | | +---------------------------------+
| :-->| IFD0 | GlobalParametersIFD offset |---:
| | +---------------------------------+ |
| | | ... | |
| +----------------------+---------------------------------+ v
| | ... | |
| :---|---------------------------<----------------------------|---:
| | | ... |
| v +----------------------+---------------------------------+
| | | | ... |
| | | +---------------------------------+
| :-->| GlobalParametersIFD | SharedData offset (1st Shared |---:
| | | Data Table offset) | |
| | +---------------------------------+ |
| TIFF | | ... | v
| file +----------------------+---------------------------------+ |
| | ... | |
| :---|---------------------------<----------------------------|---:
| | | ... |
| | +----------------------+---------------------------------+
McIntyre et al. Expires May 2001 [Page 27]
Internet Draft TIFF-FX Extensions 1.0 November 2000
| | +----------------------+---------------------------------+
| | | | Number of items in table |
| | | +-----------------+---------------+
| | | | | Byte count |
| v | | +---------------+
| | | | | File offset |
| | | | +---------------+
| | | | Shared Data 0 | SharedDataType|
| | | | +---------------+
| :-->| Shared Data Table 0 | | Last page used|
| | | +---------------+
| | | | SharedData |
| | | | Memory |
| | +-----------------+---------------+
| | | Shared Data 1 | ... |
| | +-----------------+---------------+
| | | ... | ... |
| | +-----------------+---------------+
| | | Next Shared Data Table offset |
| +----------------------+---------------------------------+
| | ... |
+------+--------------------------------------------------------+
E1.6. TIFF-FX Extension 4 (E4): 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 the term token-based
compression. It must be noted that there are modes of JBIG2 that do
not make use of repeating shapes, such as generic region coding.
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 JBIG2 encoded black-and-white
constrained profile of Profile M plus the Profile M Shared Data
extension. The MRC 3-layer model and TIFF representation, defined in
McIntyre et al. Expires May 2001 [Page 28]
Internet Draft TIFF-FX Extensions 1.0 November 2000
Section 8.1 and constrained to a single image layer (i.e. only one
layer with image data), SHALL be used.
The behavior and structure of this profile is that of a
plain single-layer image, similar to that of Profiles S, F and J,
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 with multiple layers. It must be
noted, however, that the SubIFDs SHOULD consist of only even-numbered
layers. In other words, only even-numbered values of the
ImageLayer[0] field, representing mask layers, SHOULD be present.
Additionally the SharedData field SHALL be used to store JBIG2 Shared
Data, such as symbol or pattern 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 [T.44 Ammd1].
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
images 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 other pages as well. JBIG2 compression is
improved 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 shared
data list, which identifies which "JBIG2 Shared Data" are used, and
a "JBIG2-coded position block". A JBIG2 Shared Data is used to
represent a variety of JBIG2 shared entities (i.e. JBIG2 resources)
such as symbol dictionaries, pattern dictionaries, which are used in
McIntyre et al. Expires May 2001 [Page 29]
Internet Draft TIFF-FX Extensions 1.0 November 2000
halftone coding, and Huffman tables. The symbol dictionaries are
typically contained within one or more JBIG2 Shared Data, represented
within the Shared Data provisions of the Shared Data Extension of
Profile M. The JBIG2-coded position block consists 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.
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 for multi-page files. 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 Data 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
could benefit from inclusion of these odd-numbered layers and setting
the associated StripByteCounts to 0. This may be true when an
application wishes to represent a reverse video image (i.e. a white
image on a black background). Under these conditions the list of
required fields and/or values will be modified per the
StripByteCounts field below.
McIntyre et al. Expires May 2001 [Page 30]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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.
SamplesPerPixel (277) = 1. SHORT
Constraint is consistent with the black-and-white constraint.
Compression(259) = 12. SHORT
[[The compression value of 12 is subject to change]]
12 = JBIG2 coding, ITU-T Rec. T.88 / ISO-IEC 14492 (Lossy/Lossless
coding of Bi-level 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
The '0' constraint is consistent with the black-and-white constraint
of Section E1.6.1 and the MRC mask layer PhotometricInterpretation
constraint defined in Section 8.2.1.
ResolutionUnit (296) = 2. SHORT
See Section 8.2.1.
StripByteCounts(279) SHORT or LONG
In the event that SubIFDs consists of odd-numbered layers, then the
value of the StripByteCounts for all odd-numbered values of the
ImageLayer[0] field SHALL be fixed to zero "0". In Profile M, it is
permissible for the StripByteCounts value for a given odd-numbered
layer 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
colors are white for the Background layer and black for the
Foreground layer(s).
McIntyre et al. Expires May 2001 [Page 31]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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: image height
ImageWidth: specified value, often the Primary IFD
width
BitsPerSample: 8
PhotometricInterpretation: 10
SamplesPerPixel: 3
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, no other colors SHALL 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.
McIntyre et al. Expires May 2001 [Page 32]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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).
E1.6.2.3. New Fields
These Section 8.2.3 fields SHALL NOT be present:
Decode(433).
T82Options(435)
This Section 8.2.3 field SHOULD NOT be present:
ImageBaseColor(434). The field SHOULD be omitted and the default
color of black and white SHALL be applied to foreground and
background layers respectively. When present, the default
Background or Foreground colors are typicallytypicallyty revised to
black or white respectively, see StripByteCounts above.
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)
SharedData (437)
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
[[The 436 tag value is subject to change]]
McIntyre et al. Expires May 2001 [Page 33]
Internet Draft TIFF-FX Extensions 1.0 November 2000
The T88Options field contains one or 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 field is equal to 12 (JBIG2). The content
provides an aid to TIFF readers, in that they describe JBIG2 options
that may or may not be handled by a specific JBIG2 decoder. None of
the values in the field are required for correct decoding, and the
field may be ignored. In the event that this field 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").
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 SHALL contain a|
| | JBIG2 Position Block that has only one JBIG2 stripe|
| | (not the same as a TIFF strip). |
| | Note: There is a limit of 32767 lines per JBIG2 |
| | stripe in the event that multi-stripe mode is used.|
+--------------+----------------------------------------------------+
McIntyre et al. Expires May 2001 [Page 34]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+--------------+----------------------------------------------------+
| 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 be 0 within Profile T, which is constrained
to black-and-white images.
T88Options[1] = 0x00000101, 0x00000102, 0x00000103.
This value represents the JBIG2 profile identification number. This
value may be omitted.
Default = 0x00000101.
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. None of the
values of the T88Options field is required for correct decoding of a
JBIG2 coded data stream and may be ignored. It allows a decoder to
find out quickly which of the set of JBIG2 parameters and parameter
values may be required to 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 documented in ITU-T Rec. T.89, while
interpretation of profiles 0x00000000 through 0x000000FF is
documented in ISO/IEC 14492 | ITU-T T.88.
McIntyre et al. Expires May 2001 [Page 35]
Internet Draft TIFF-FX Extensions 1.0 November 2000
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 Shared Data
For JBIG2 Shared Data, the SharedDataType value in the Shared Data
Entry SHALL have a value of 1.
E1.6.4.1 The JBIG2 Shared Data
The JBIG2 Shared Data stored in a TIFF file contains three pieces:
1. A JBIG2 Shared Data version
2. A JBIG2-coded shared data block
3. Extensions to the JBIG2 Shared Data (these extensions contain
data that are outside the scope of T.88-JBIG2)
The JBIG2-coded shared data 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 shared data 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).
McIntyre et al. Expires May 2001 [Page 36]
Internet Draft TIFF-FX Extensions 1.0 November 2000
To put it into perspective, when sharing data is required, a file
contains one SharedData field, which is located in the
GlobalParametersIFD. The SharedData field contains the file offset of
the first Shared Data Table. Each Shared Data Table contains a count
of the number of Shared Data Entries (i.e. JBIG2 Shared Data) that
physically exist in the table , the location and size of the JBIG2
Shared Data themselves, and the file location of the next Shared Data
Table (if any). There can be as many Shared Data Tables as necessary
to describe the number of JBIG2 Shared Data items.
The JBIG2 image strip (i.e. the reference data stream), described in
the next section, that requires inclusion of one or more JBIG2 Shared
Data SHALL include a list of JBIG2 Shared Data IDs in a
SharedDataList.
E1.6.4.1.1 JBIG2 Shared Data Format
The JBIG2 Shared Data format consists of a version number, which
identifies the version of the format that follows, followed by the
size of the JBIG2 data block, then the data block itself, followed
by any extensions. The start of the JBIG2 Shared Data is located at
file offset T, in bytes, from the beginning of the file.
The JBIG2 Shared Data has the following format:
+-----+--------------+-----+----------------------------------------+
|Bytes| Byte offsets | Type| Description |
+-----+--------------+-----+----------------------------------------+
| 1 | T |BYTE | The JBIG2 Shared Data version number, |
| | | | which is currently 0. |
+-----+--------------+-----+----------------------------------------+
| 4 | T+1 - T+4 |LONG | Size of JBIG2-coded shared data block |
| | | | (not including extensions) = Y. |
+-----+--------------+-----+----------------------------------------+
| Y | T+5 - T+4+Y |BYTE | The JBIG2-coded shared data 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 | . . . . |BYTE | Data for first extension |
+-----+--------------+-----+----------------------------------------+
| 2 | . . . . |SHORT| Extension type for second extension |
+-----+--------------+-----+----------------------------------------+
| 4 | . . . . |LONG | Size of second extension=Z2 |
+-----+--------------+-----+----------------------------------------+
| Z2 | . . . . |BYTE | Data for second extension |
+-----+--------------+-----+----------------------------------------+
McIntyre et al. Expires May 2001 [Page 37]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+-----+--------------+-----+----------------------------------------+
| ....| . . . . | ....| Further extensions |
+-----+--------------+-----+----------------------------------------+
E1.6.4.2 JBIG2 SharedDataMemory
For JBIG2 dictionary Shared Data the SharedDataMemory requirement is
represented by the total amount of decoded symbol dictionary
information a decoder will accommodate in memory at one time to
decode a file. This SharedDataMemory requirement is referenced as the
decoder memory. If decoder memory is specified (non-zero value), then
it follows the formula described in [T.89]. Namely, the decoder
memory, composed of two components (a fixed and per-symbol
component), is a measure of how much memory is required to hold a
decoded dictionary. The fixed component does not depend on the number
of symbols, while the per-symbol component does depend on the number
of symbols. The decoder memory algorithm does have dependence on
whether Huffman (see note 1) or Arithmetic (see note 2) coding is
used and whether the dictionaries contain symbols or halftone
patterns (see note 3).
decoder memory = fixed component + per-symbol component
fixed component = 2^{direct coding template size}
+ 2^{refinement coding template size} + 8K
per-symbol component = 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:
1) For Huffman coding there are no templates, so the fixed component
is about 8K bytes. The fixed component can in fact be zero if
McIntyre et al. Expires May 2001 [Page 38]
Internet Draft TIFF-FX Extensions 1.0 November 2000
custom Huffman tables are not used.
2) For Arithmetic coding the per-symbol component is the same. The
amount of memory needed to store the decoded dictionary bitmaps
(that's the (round32(Wi) * Hi) / 8 component) is unchanged.
Differences occur in the 32 bytes per-symbol overhead component.
The width, height and pointer fractions of the overhead still
apply, however the Huffman code parts do not apply. There are,
however, context tables for symbol ID probability modeling that
take the place of the Huffman code parts. Bottom line, 32 bytes is
also a reasonable per-symbol overhead for Arithmetic coding.
The template options documented in [T.89] range from a 10 pixels
direct bitmap template with no refinement bitmap coding to a 16
pixels direct bitmap template with a 13 pixels refinement bitmap
template. Given this range of templates, the fixed component will
range from 9K to 80K bytes.
3) The same expression holds for pattern dictionaries of halftone
image regions, since pattern dictionaries are similar to
symbol dictionaries but contain halftone patterns. In this
context, the references to symbol above should be taken to include
patterns stored in pattern dictionaries. The pattern dictionaries,
however, tend to be small relative to symbol dictionaries, since
the pattern count is frequently low. This isThis only a few K of
memory. It is the space required by a decoder to hold the halftone
bit-planes that is of significance and determines the
SharedDataMemory. This memory requirement is document in [T.89] to
be typically 110% of the resolution dependent page buffer size
(i.e. 1.0 Mbytes at 300 dpi and 2.0 Mbytes at 400 dpi).
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 strip 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 shared data IDs in the
SharedDataList section of each image strip. The concatenation of the
shared data and the JBIG2 position block will comprise a decodable
JBIG2 stream for the image described by the IFD for that strip.
A position block is the JBIG2 encoding of the binary image code
stream. Included in the position block are the encoded positions and
McIntyre et al. Expires May 2001 [Page 39]
Internet Draft TIFF-FX Extensions 1.0 November 2000
IDs of the symbols within the dictionaries, which may lie within the
position block, and/or outside of it (as JBIG2 Shared Data). 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. Generic refinement region segment
8. Text region segment
9. Halftone region segment
10. Extension segment (future extensions to be defined within the
T.88 JBIG2 standard)
11. Supported profiles segment
12. Table segment.
Each segment in a JBIG2-coded position block SHALL be associated with
the page defined by the page information segment.
The TIFF JBIG2 Image Strip SHALL consist of four pieces:
1. A JBIG2 Image Strip version
2. A SharedDataList: list of JBIG2 Shared Data 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 possibly be
stored in an extension includes ASCII text, hyperlinks, and so on.
The current image strip extensions and the data that may be stored in
them are defined in Section E1.6.5.1. 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 data IDs from the SharedDataList.
2. Search the collection of JBIG2 Shared Data for all the JBIG2
Shared Data, such as dictionaries, whose IDs are given in the
SharedDataList.
From each one, extract its JBIG2-coded shared data block.
McIntyre et al. Expires May 2001 [Page 40]
Internet Draft TIFF-FX Extensions 1.0 November 2000
3. Concatenate those JBIG2-coded shared data blocks, in the order
in which their IDs are given in the SharedDataList, followed
by the JBIG2-coded position block.
4. This concatenated data stream can then be decoded 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.
As an optimization, you won't actually concatenate and decode the
JBIG2-coded shared data block(s) for every position block that uses
them, as that is quite inefficient. Instead, the JBIG2-coded shared
data block(s) can be decoded and kept in an intermediate format,
designed so that the effect of logical concatenation can be
simulated.
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 |
| | | | Shared Data) |
+-----+--------------+-----+----------------------------------------+
| X*4 | P+3 - P+2 |LONG | The sequence of shared data IDs of the |
| | +(X*4) | | JBIG2 Shared Data required by this |
| | | | JBIG2-coded position block. The JBIG2 |
| | | | Shared Data (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 May 2001 [Page 41]
Internet Draft TIFF-FX Extensions 1.0 November 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 | . . . . |BYTE | Data for second extension |
+-----+--------------+-----+----------------------------------------+
| ... | . . . . |.... | Further extensions |
+-----+--------------+-----+----------------------------------------+
Current JBIG2 Image Strip Extension Types:
+----------------+--------------------------------------------------+
| Extension Type | Meaning |
+----------------+--------------------------------------------------+
| 0 | Undefined |
+----------------+--------------------------------------------------+
| 1 | Colour tags |
| | This extension contains colour tag data, T.45 |
| | encoded. |
| | 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 May 2001 [Page 42]
Internet Draft TIFF-FX Extensions 1.0 November 2000
| | +-----------------+---------------------------------------+
| | | | ... |
| | | +---------------------------------------+
| v | | Next IFD offset (IFD 1) |----:
| | | +---------------------------------------+ |
| | | | ... | |
| | | +---------------------------------------+ |
| :-->| IFD0 | GlobalParametersIFD |--: |
| | +---------------------------------------+ | v
| | | StripOffsets/StripByteCounts | | |
| | +---------------------------------------+ v |
| | | ... | | |
| +-----------------+---------------------------------------+ | |
| | ... | | |
| :---|-----------------------------<---------------------------|--: |
| | | ... | |
| v +-----------------+---------------------------------------+ v
| | | | ... | |
| | | +---------------------------------------+ |
| :-->| GlobalParameters| SharedData offset (1st Shared |--: |
| | IFD | Data Table offset) | | |
| | +---------------------------------------+ | |
| TIFF | | ... | v |
| file +-----------------+---------------------------------------+ | |
| | ... | | v
| :---|-----------------------------<---------------------------|--: |
| | | ... | |
| | +-----------------+---------------------------------------+ |
| | | | Number of items in table | |
| | | +----------------+----------------------+ |
| | | | | Byte count (of JBIG2 | |
| | | | | Shared Data 0) | |
| v | | +----------------------+ v
| | | | | File offset (to |--: |
| | | | | JBIG2 Shared Data 0) | | |
| | | | +----------------------+ | |
| | | | Shared Data 0 | SharedDataType (1) | | |
| | | | +----------------------+ v |
| :-->| Shared Data | | Last page used | | |
| | Table 0 | +----------------------+ | |
| | | | SharedDataMemory | | |
| | +----------------+----------------------+ | v
| TIFF | | Shared Data 1 | ... | | |
| file | +----------------+----------------------+ v |
| | | ... | ... | | |
| | +----------------+----------------------+ | |
| | | Next Shared Data Table offset | | |
| +-----------------+---------------------------------------+ | |
McIntyre et al. Expires May 2001 [Page 43]
Internet Draft TIFF-FX Extensions 1.0 November 2000
| +-----------------+---------------------------------------+ | |
| | ... | | v
| :---|-----------------------------<---------------------------|--: |
| | | ... | |
| v +-----------------+---------------------------------------+ |
| | | | 0 (version) | |
| | | +---------------------------------------+ |
| | | | <byte count of JBIG2-coded shared data| |
| | | | block> | |
| v | +---------------------------------------+ |
| | | | JBIG2-coded block> block (may contain | v
| | | | multiple JBIG2 segments) | |
| :-->| JBIG2 Shared +---------------------------------------+ |
| | Data 0 | Extension type for first extension | |
| | | (data that are outside the scope of | |
| | | T.88-JBIG2) | |
| | +---------------------------------------+ |
| | | <byte count of first extension> | |
| TIFF | +---------------------------------------+ |
| file | | Data for first Extension | |
| | +---------------------------------------+ v
| | | ... | |
| +-----------------+---------------------------------------+ |
| | ... | |
| :---|-----------------------------<---------------------------|----:
| | | ... |
| v +-----------------+---------------------------------------+
| | | | ... |
| | | +---------------------------------------+
| :-->| IFD1(page 0) | StripOffset (strip 0) |---:
| | +---------------------------------------+ |
| | | ... | |
| +-----------------+---------------------------------------+ |
| | ... | |
| :---|-----------------------------<---------------------------|---:
| | | ... |
| | +-----------------+---------------------------------------+
| | | | Strip format version |
| | | +---------------------------------------+
| | | | SharedDataList |
| | | Strip 0 +---------------------------------------+
| :-->| | JBIG2-coded position block |
| | +---------------------------------------+
| | | Extensions |
| TIFF +-----------------+---------------------------------------+
| file | |
| | ... |
+------+---------------------------------------------------------+
McIntyre et al. Expires May 2001 [Page 44]
Internet Draft TIFF-FX Extensions 1.0 November 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. Typically, only ONE layer with image data SHALL exist and it SHALL
be the binary Mask layer, which SHALL be the 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 present. If present, then only
black and white colors SHALL be used. The Foreground and
Background defaults for ImageBaseColor SHALL be black and
white respectively.
3. The Primary IFD defines and extends to the entire page boundary;
all attached SubIFD 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 SHALL 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 SHALL 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 SHALL 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. Should Foreground
/Background layers be present, the StripByteCounts SHALL be set to
"0". Each strip of the Foreground/Background layers SHALL be
stored in one IFD, 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 rendered. The TIFF XPosition and YPosition fields
McIntyre et al. Expires May 2001 [Page 45]
Internet Draft TIFF-FX Extensions 1.0 November 2000
are used to indicate the placement of these images with respect to
the primary image.
9. If Background and/or Foreground images are present, their
resolution SHALL be that of the Primary Mask image.
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 May 2001 [Page 46]
Internet Draft TIFF-FX Extensions 1.0 November 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**| <n>: number or bytes in each strip, |
| | fixed to "0" for FG/BG (when present) |
+------------------+-----------------------------------------+
| StripOffsets** | <n>: 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 | <IFD>: 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 | <n>: 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 May 2001 [Page 47]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+------------------+-----------------------------------------+
| FaxProfile* | n: ITU-T compatible fax profile |
+------------------+-----------------------------------------+
| CodingMethods* | n: compression algorithms used in file |
+------------------+-----------------------------------------+
| VersionYear* | byte sequence: year of ITU-T standard |
+------------------+-----------------------------------------+
| ModeNumber* | n: mode (i.e. functional level) of T.44 |
| | standard |
+------------------+-----------------------------------------+
| TIFF-FXExtensions| n: extension(s) identification number, |
| ** | bits 2 and 3 for SharedData and |
| | Profile T SHALL be among the set bits |
+------------------+-----------------------------------------+
| T88Options* | n, m: option numbers, profile number |
+------------------+-----------------------------------------+
| SharedData** | <n>: offset from beginning of file to |
| | the first Shared Data |
+------------------+-----------------------------------------+
E1.7. TIFF-FX Extension 5 (E5): JBIG2 Color 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 color. The JBIG2, ITU-
T Rec. T.88 / ISO-IEC 14492, bi-level 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-color images, such as colored text. The T.44 defined
mechanism, referenced as "colour tag" encoding, is only available for
use in foreground layers that are associated with JBIG2 coded mask
layers. The more conventional multi-level color coders, such JPEG,
are also available for use in the encoding of foreground layer colors
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 (i.e. if present
StripByteCounts = 0). This translates to augmenting the MRC 3-layer
model and TIFF representation, defined in Profile M, with the Shared
Data extension E1 (Extension 1), and using JBIG2 coding (i.e.
Compression =12) in the mask layer. The N-layer model and TIFF
representation, defined in extension E2 (Section E1.4) MAY also be
used if the corresponding TIFF-FXExtensions bit is set.
McIntyre et al. Expires May 2001 [Page 48]
Internet Draft TIFF-FX Extensions 1.0 November 2000
Use of JBIG2 and "colour tagging" to encode the colors of the
foreground layer(s) translates to attaching discrete color 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 color for a layer SHALL
not have any encoded image data associated with it, i.e., the
StripByteCounts field SHALL contain a 0. Since no image data exists
in the IFD, the Compression field SHALL be set to 1 indicating no
compression. A Compression field value of 1 is not allowed for any
other IFDs.
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) for Profile T 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
- Generic refinement region segment
McIntyre et al. Expires May 2001 [Page 49]
Internet Draft TIFF-FX Extensions 1.0 November 2000
E1.7.4 JBIG2 Shared Data
See Section E1.6.4.
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 (Color 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 colored text. In
most cases, if a document contains text, each individual text
character is a single, flat, color (e.g., black or red), and the
number of such colors is limited. The foreground layer in this case
looks like a number of colored 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
(XPosition, 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 color 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 colors. The total space taken by the foreground layer
can be small in comparison to an encoded contone image.
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). 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 (bi-level data) and foreground (color data) layer pairs, we
arrive at the following terms of use to be applied when colour
tagging is used in foreground representation:
1. the (JBIG2-compressed) bi-level 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, as
McIntyre et al. Expires May 2001 [Page 50]
Internet Draft TIFF-FX Extensions 1.0 November 2000
defined in Section E1.6.5.1). The colour tags SHALL be
compressed using ITU-T Rec. T.45.
2. the mask IFD points to the start of the bi-level data, and the
associated byte count SHALL include ONLY the bi-level data (the
position block, but not the colour tags). The IFD's Compression
field SHALL be set to 12 (JBIG2). If present, the T88Options[0]
field SHOULD have bit 5 set to 1 (ColourTagsFollow).
3. the foreground IFD points to the bi-level data, and the
associated byte count SHALL include BOTH the bi-level data and
the colour tag extension. The IFD's Compression field SHALL be
set to 12 (JBIG2). The IFD's PhotometricInterpretation SHALL
indicate the color 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 (ColourTagsPresent).
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 color, 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 colored image that contains the right
color 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 not be able
to decode the JBIG2 data anyway. The shared pointers occur only in a
restricted case.
The nature of the two pointers is illustrated below:
McIntyre et al. Expires May 2001 [Page 51]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+----------------------------+
| |
| |
| |
| |
+----------------------------+
| ... |
| SubIFD 0 StripOffsets |--:
| StripByteCounts|--|-:
| ... | | | mask IFD's
+----------------------------+ | | StripByteCounts
| | | | includes only
:---|------------<---------------|--: | bi-level data
| | | |
mask and | +----------------------------+<---:<--:
foreground :-->| JBIG2 Symbols & | | | foreground IFD's
IFD both | | data positions | | | StripByteCounts
point to | | _______________ |<---: | includes both
bi-level | | Colour Tag extension | | bi-level 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 SHALL be 0. If only one layer exists,
then the image corresponding to that layer is the primary
image.
McIntyre et al. Expires May 2001 [Page 52]
Internet Draft TIFF-FX Extensions 1.0 November 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 for FG/BG |
| | 9-16: optional 12 bits/sample |
+------------------+-----------------------------------------+
| Compression | 1: None (ImageBaseColor IFD only) |
| | 3**: Modified Huffman and Modified Read |
| | (mask layer) |
| | 4: Modified Modified Read |
| | 7**: JPEG (FG/BG layers) |
| | 9: JBIG, per T.85 |
| | 10: JBIG, per T.43 |
| | 12**: JBIG2, per T.88 (Note that T.45 |
| | Run-length Colour Encoding is also|
| | required for FG/BG layers) |
+------------------+-----------------------------------------+
| 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 May 2001 [Page 53]
Internet Draft TIFF-FX Extensions 1.0 November 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 (FG/BG layers) |
+------------------+-----------------------------------------+
| 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**| <n>: number or bytes in each strip |
+------------------+-----------------------------------------+
| StripOffsets** | <n>: offset from beginning of file to |
| | each TIFF strip |
+------------------+-----------------------------------------+
| XResolution | 100, 200**, 300, 400 (written in |
| | pixels/inch) |
+------------------+-----------------------------------------+
| YResolution | equal to XResolution (pixels SHALL 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 May 2001 [Page 54]
Internet Draft TIFF-FX Extensions 1.0 November 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 | <IFD>: 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 | <n>: 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-T compatible fax profile |
+------------------+-----------------------------------------+
| CodingMethods* | n: compression algorithms used in file |
+------------------+-----------------------------------------+
McIntyre et al. Expires May 2001 [Page 55]
Internet Draft TIFF-FX Extensions 1.0 November 2000
+------------------+-----------------------------------------+
| VersionYear* | byte sequence: year of ITU-T standard |
+------------------+-----------------------------------------+
| ModeNumber* | n: mode of T.44 standard |
+------------------+-----------------------------------------+
| TIFF-FXExtensions| n: extension(s) identification number, |
| ** | bits 2 and 4 for SharedData 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 |
+------------------+-----------------------------------------+
| SharedData** | <n>: offset from beginning of file to |
| | the first Shared Data |
+------------------+-----------------------------------------+
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 is 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 May 2001 [Page 56]
Internet Draft TIFF-FX Extensions 1.0 November 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, Application Profiles for
Recommendation T.88 - Lossy/Lossless Coding of Bi-level Images
(JBIG2) for Facsimile, November 2000.
E1.10 Authors' Addresses
Dave Abercrombie Robert Buckley
Xerox Corporation Xerox Corporation
Mailstop PAHV-121 Mailstop 0128-30E
3400 Hillview Ave 800 Phillips Road
Palo Alto, CA 94304, USA Webster, NY 14580, USA
Voice: +1-650-813-6811 Voice: +1-716-422-1282
Fax: +1-650-813-6860 Fax: +1-716-265-8871
Email: aber@pahv.xerox.com Email:rbuckley@crt.xerox.com
Lloyd McIntyre William Rucklidge
Xerox Corporation Intelligent Markets
Mailstop PAHV-121 410 Jessie St., Suite 602
3400 Hillview Ave San Francisco, 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 May 2001 [Page 57]
Internet Draft TIFF-FX Extensions 1.0 November 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 May 2001 [Page 58]
