view Side-By-Side changes
File Format for Internet Fax
<DRAFT-IETF-FAX-TIFFPLUS-01.TXT>
<draft-ietf-fax-tiffplus-02.txt>
Status
This document is an Internet Draft. 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 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 a "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This Internet Draft describes the TIFF (Tag Image File Format)
representation of the image data specified by the ITU-T Recommendations for
black-and-white and color facsimile. The document provides a standard definition It formally defines Applications W,
F, J, C, P and M of the MIME Media Type image/tiff for TIFF-F (also
known as TIFF Class F), which is used use with Internet
Fax. Applications W, F and J describe the minimal, extended and lossless
JBIG modes for a subset of black-and-white
facsimile, fax. Applications C, P and standard definitions for the TIFF representation of M describe the
ITU-T Recommendations
base JPEG, lossless JBIG and Mixed Raster Content modes for facsimile, including color facsimile. For the
most part, existing TIFF constructs and fields are used; new TIFF fields
are introduced as necessary. The document also describes the refinement
of the registration of the MIME type image/tiff.
grayscale fax.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 1]
Internet Draft File Format for Internet Fax October 10, 1997
Table of Contents
1. INTRODUCTION........................................................3 INTRODUCTION........................................................4
1.1. Scope..........................................................3 Scope..........................................................5
1.2. Approach.......................................................4 Approach.......................................................5
1.3. Organization Overview of this draft.....................................4 draft.........................................5
2. TIFF and Fax........................................................4 Fax........................................................6
2.1. TIFF Overview..................................................4 Overview..................................................6
2.1.1. File Structure.............................................5 Structure.............................................6
2.1.2. Image Structure............................................6 Structure............................................8
2.1.3. Recommended TIFF File Structure for Fax Applications.......6 Applications...................8
2.2 TIFF Fields for All Fax Applications................................7 Applications...........................10
2.2.1. TIFF Fields required for all fax modes.....................8 modes....................11
2.2.2. Additional TIFF Fields required for all fax modes..........9 modes.........12
2.2.3. TIFF Fields recommended for all fax modes..................9
McIntyre & Zilles Expires 1/30/98 [Page 1]
Internet Draft File Format for Internet Fax July 30, 1997 modes.................13
2.2.4. New TIFF Fields recommended for fax modes......................10 modes.................13
3. Minimal Black-and-white Mode.......................................11 Black-and-White Fax Mode...................................15
3.1. Overview......................................................12 Overview......................................................15
3.2. Required TIFF Fields..........................................12 Fields..........................................15
3.2.1 Baseline Fields............................................12 Fields............................................16
3.2.2 Extension Fields...........................................13 Fields...........................................17
3.2.3 New Fields.................................................14 Fields.................................................17
3.3. Recommended TIFF Fields.......................................14 Fields.......................................17
3.4. End of Line Restrictions......................................14 (EOL) and Return to Control (RTC).................18
3.5. File Structure................................................19
3.6. Minimal Black-and-White Mode Summary..........................15 Summary..........................19
4. Extended Black-and-White mode......................................16 Fax Mode..................................21
4.1. Overview......................................................16 TIFF-F Overview...............................................21
4.2. Required TIFF Fields..........................................17 Fields..........................................22
4.2.1. Baseline Fields...........................................17 Fields...........................................22
4.2.2. Extension Fields..........................................18 Fields..........................................25
4.2.3. New Fields................................................19 Fields................................................25
4.3. Recommended TIFF Fields.......................................19 Fields.......................................25
4.3.1. Baseline Fields...........................................19 Fields...........................................25
4.3.2. Extension Fields..........................................19 Fields..........................................26
4.3.3. New Fields................................................19 Fields................................................26
4.4. TIFF Class F Definition.......................................19 Technical Implementation Issues...............................27
4.4.1. Strips....................................................27
4.4.2. Bit Order.................................................27
4.4.3. Multi-Page................................................28
4.4.4. Compression...............................................28
4.4.5. Example Use of Page-quality Fields........................29
4.5. Implementation Warnings.......................................29
4.5.1. Uncompressed Data.........................................29
4.5.2. Encoding and Resolution...................................29
4.5.3. EOL byte-aligned..........................................30
4.5.4. EOL.......................................................31
4.5.5. RTC Exclusion.............................................31
4.5.6. Use of EOFB for T.6 Compressed Images.....................31
McIntyre, Zilles, et al. Expires 4/10/98 [Page 2]
Internet Draft File Format for Internet Fax October 10, 1997
4.6. Example Use of TIFF-F.........................................32
4.7. Extended Black-and-White Black-and-white Fax Mode Summary.....................19 Summary.....................32
5. Base Color Lossless JBIG Black-and-White Fax Mode................................................22 Mode.............................34
5.1. Overview......................................................22 Overview......................................................34
5.2. Required TIFF Fields..........................................22 Fields..........................................35
5.2.1. Baseline Fields...........................................22 Fields...........................................35
5.2.2. Extension Fields..........................................23 Fields..........................................35
5.2.3. New Fields................................................24 Fields................................................35
5.3. Recommended TIFF Fields.......................................24 Fields.......................................35
5.4. Base Color Fax Lossless JBIG Black-and-White Mode Summary...................................25 Summary....................35
6. Lossless Base Color Mode................................................27 Fax Mode................................................37
6.1. Overview......................................................27
6.1.1. Color Encoding............................................27
6.1.2. JBIG Encoding.............................................28 Overview......................................................37
6.2. Required TIFF Fields..........................................28 Fields..........................................37
6.2.1. Baseline Fields...........................................28 Fields...........................................38
6.2.2. Extension Fields..........................................29 Fields..........................................39
6.2.3. New Fields................................................29 Fields................................................41
6.3. Recommended TIFF Fields.......................................29 Fields.......................................41
6.4. Lossless Base Color Fax Mode Summary...............................29 Summary...................................41
7. Lossless Color Mode................................................43
7.1. Overview......................................................43
7.1.1. Color Encoding............................................43
7.1.2. JBIG Encoding.............................................44
7.2. Required TIFF Fields..........................................44
7.2.1. Baseline Fields...........................................44
7.2.2. Extension Fields..........................................46
7.2.3. New Fields................................................46
7.3. Recommended TIFF Fields.......................................46
7.4. Lossless Color Fax Mode Summary...............................46
8. Mixed Raster Content Mode..........................................31
7.1 Overview.......................................................31
7.1.1. Mode..........................................48
8.1 Overview.......................................................48
8.1.1. MRC 3-layer model.........................................32
7.1.2. model.........................................48
8.1.2. A TIFF Representation for the MRC 3-layer model...........33
7.2. model...........49
8.2. Required TIFF Fields..........................................34
7.2.1. Fields..........................................51
8.2.1. Baseline Fields...........................................34
7.2.2. Fields...........................................51
8.2.2. Extension Fields..........................................35
7.2.3. Fields..........................................52
8.2.3. New Fields................................................36
7.3. Fields................................................53
8.3. Recommended TIFF Fields.......................................37
7.4. Fields.......................................54
8.4. Rules and Requirements for Images.............................37
7.5. Images.............................54
8.5. MRC Fax Mode Summary..........................................38
McIntyre & Zilles Expires 1/30/98 [Page 2]
Internet Draft File Format for Internet Fax July 30, 1997
8. Mime Sub-Type......................................................41 Summary..........................................55
9. IANA Registration..................................................41
10. Security Considerations...........................................42 Considerations....... ....................................58
10. References........................................................58
11. References........................................................42
12. Authors' Addresses................................................44
Appendix Addresses................................................60
Annex A: Summary of TIFF Fields for Internet Fax ..................44
Appendix B: Use of TIFF-F .....................61
McIntyre, Zilles, et al. Expires 4/10/98 [Page 3]
Internet Draft File Format for Black-and-White Fax.....................49 Internet Fax October 10, 1997
1. Introduction
1.1 Scope
This document defines a TIFF-based file format specification and
corresponding MIME image/tiff content type consistent with the charter
of the IETF Internet Fax Working Group for enabling standardized
messaging-based fax over the Internet. In particular, it describes the
fields and parameters required to enable use of TIFF (Tag Image File Format) to
represent the data content and the structure generated by the current suite
of ITU-T Recommendations for Group 3 facsimile. These standards, Recommendations
and the TIFF fields described here, here support five six facsimile modes:
1. minimal black-and-white mode, using binary compression [T.4]
- Application W of image/tiff media type
2. extended black-and-white mode, using binary compression [T.6, T.82] [T.4,
T.6]
- Application F of image/tiff media type
3. lossless JBIG black-and-white mode, with JBIG compression [T.85,
T.82]
- Application J of image/tiff media type
4. lossy color and grayscale mode, using JPEG compression [T.42,
T.81]
4.
- Application C of image/tiff media type
5. lossless color and grayscale mode, using JBIG compression [T.43,
T.82]
5.
- Application P of image/tiff media type
6. mixed raster content mode [MRC], using a combination of
compression methods in 1-4
This specification defines a 1-5
- Application M of image/tiff media type
As noted, these six modes correspond to values W, F, J, C, P and M of
the Application parameter of the MIME image/tiff media type. The
Application parameter is described in the corresponding update to the
registration of the MIME Media Type image/tiff [TIFF-REG]. For
convenience, Application F, for example, of MIME Media Type image/tiff
will be referred to as TIFF-F in this document. A previous version of
this Internet Draft was known informally as TIFF-FX, where "FX" stood
for "fax extended."
The minimal interchange set of fields that (Application W) will guarantee
that, at least, binary black-and-white images will be supported.
Implementations are required to support this minimal interchange set of
fields.
This specification builds on
With the intent of specifying a previously proposed standard [RFC1314]
and on work in progress [TIFF-F] file format for black-and-white fax to provide a
standard definition Internet Fax, this
draft:
1. specifies the structure of TIFF Class F. It extends that work to make it
compatible with the relevant ITU-T Recommendations for color and
grayscale facsimile. It also proposes a modification to the image/tiff
content type that would accommodate the fax modes.
Within its defined scope of specifying a file format for Internet Fax,
this draft:
1. specifies TIFF structures files for facsimile data,
2. defines ITU fax-compatible values for existing TIFF fields,
3. defines new TIFF fields and values required for ITU-T compatibility.
McIntyre & Zilles compatibility
with ITU color fax.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 3] 4]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
1.2 Approach
1.1 Scope
This document defines a TIFF-based file format specification uses the current TIFF spec [TIFF] as the basis for
describing color and grayscale facsimile modes.
enabling standardized messaging-based fax over the Internet. It takes advantage of
TIFF features and structures that bridge
specifies the data formats and
performance requirements of both legacy fax machines and host-based fax
applications. A TIFF-based approach also builds on an established base
of users and implementors TIFF fields and ensures backward field values required for compatibility
with the existing TIFF-based IETF proposals ITU-T Recommendations for Group 3 black-and-white,
grayscale and work color facsimile. TIFF has historically been used for
handling fax image files in progress applications such as store-and-forward
messaging. Implementations that support this file format specification
for import/export may elect to support it as a native format. This
document recommends a TIFF file structure that is compatible with
low-memory and page-level streaming implementations.
Unless otherwise noted, the current TIFF specification [TIFF] and
selected TIFF Technical Notes [TTN1, TTN2] are the primary references
for defining TIFF fields. This document is the primary reference for
defining TIFF field values for Internet
fax. fax applications.
1.2 Approach
The basic approach to using TIFF for facsimile data is to insert the
compressed fax data stream in a TIFF file and to use TIFF fields to encode the
parameters that describe the properties image data. These fields will have values
that comply with the ITU-T Recommendations. The MIME media type of the data. TIFF constructs for
pages, images, and strips allow a TIFF
resulting file will be image/tiff, with an optional Application
parameter to identify the fax mode and the ITU-T Recommendations with
which the file contents are compatible.
This approach takes advantage of TIFF features and structures that
bridge the data formats and performance requirements of both legacy fax
machines and host-based fax applications. TIFF constructs for pages,
images, and strips allow a TIFF file to preserve the fax data stream structure,
structure and the performance advantages that come with it. A TIFF-based
approach also builds on an established base of users and implementors
and ensures backward compatibility with existing TIFF-based IETF
proposals and work in progress for Internet fax.
1.3 Organization Overview of this draft
Section 2 gives an overview of TIFF. Section 2.1 describes the general representation structure
of fax data and
parameters in a TIFF file, files, including practical guidelines for structuring multi-page
TIFF files. Section 2.2 lists the TIFF fields that are required or
recommended for all fax modes. The TIFF fields used in by some but not all
fax modes are described in Sections 3-8, which describe the individual
fax modes. These sections also specify the ITU-compatible field values
(image parameters) for each mode.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 5]
Internet Draft File Format for Internet Fax October 10, 1997
Section 3 defines the representation of the minimal black-
and-white black-and-white
facsimile mode required of all implementations. implementations (Application = W).
Section 4 defines the optional extended black-and-white fax capabilities,
including capabilities
and provides a standard definition for Application F of image/tiff, also
known as TIFF-F. Section 5 describes the lossless black-and-white mode
using JBIG compression (Application = J). Section 6 defines the
representation of lossy color and grayscale facsimile. facsimile (Application = C).
Section 6 7 defines the representation of lossless color and grayscale
facsimile (Application = P) and Section 7 8 defines the representation of mixed raster content facsimile.
Sections 8
Mixed Raster Content facsimile (Application =M). Each of these sections
concludes with a table summarizing the required and recommended fields
for each mode and 9 describe the MIME content type values they can have.
Sections 9, 10 and IANA registration.
The three remaining sections 11 give Security Considerations, References and
Authors' Addresses. Appendix Annex A gives a summary of the TIFF fields used or
defined in this document. Appendix B summarizes document and describes
the use of TIFF-F provides a convenient reference for storing black-and-white images from current
implementations. This profile summarizes the work
implementors.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in progress [TIFF-F]
for the minimal interchange black-and-white mode. this document are
to be interpreted as described in [REQ].
To implement only the minimal interchange black-and-white set of fields
and values, one need read only Sections 1, 2, 3 and 9. To implement
TIFF-F, the only sections needed are 1, 2, 3, 8, 9, 4 and 10. 9.
2. TIFF and Fax
2.1. TIFF Overview
This section
TIFF provides a means for describing, storing and interchanging raster
image data. A primary goal of TIFF is based on the to provide a rich environment
within which applications can exchange image data. The current TIFF
specification [TIFF] defines a commonly used, core set of TIFF fields
known as Baseline TIFF,. The current specification and
selected TIFF Technical
Notes [TTN1, TTN2]. Some features of TIFF are:
- TIFF is capable of describing bilevel, grayscale, palette-color, 1 and full-color image data in 2 [TTN1, TTN2] define several color spaces.
- TIFF includes a number of compression schemes that allow developers
to choose the best space or time tradeoff for their applications.
McIntyre & Zilles Expires 1/30/98 [Page 4]
Internet Draft File Format extensions. The TIFF-
based specification for Internet Fax July 30, 1997
- TIFF is not tied to specific scanners, printers, or computer
display hardware.
- TIFF is portable. It does not favor particular operating systems,
file systems, compilers, or processors.
- fax applications uses Baseline TIFF is designed to be extensible-to evolve gracefully fields with
selected extensions, as new needs
arise.
- TIFF allows the inclusion of an unlimited amount of private or
special-purpose information.
This specification employs these features described in using TIFF to represent
black-and-white and color facsimile data. this document. In a few cases, this
document defines new fields specifically for fax applications.
2.1.1. File Structure
TIFF is designed for scanned images, which makes it a good match for
facsimile documents, which are multi-page scanned raster images. Each
raster image consists of a number of rows or scanlines, each of which
has the same number of pixels, the unit of sampling. Each pixel has at
least one sample (exactly one for black-and-white images).
McIntyre, Zilles, et al. Expires 4/10/98 [Page 6]
Internet Draft File Format for Internet Fax October 10, 1997
A TIFF file begins with an 8-byte image file header that describes header. The first two bytes
describe the byte order used within the file, includes a value that identifies the
file as a TIFF file, and then gives an offset that points to the file. Legal values are "II"
(0x4949) when bytes are ordered from least to most significant (little-
endian), and "MM" (0x4D4D), when bytes are ordered from most to least
significant (big-endian) within a 16- or 32-bit integer. Either byte
order can be used, except in the case of the minimal black-and-white
mode, which SHALL use value "II". The next two bytes contain the value
42 that identifies the file as a TIFF file and is ordered according to
the value in the first two bytes of the header. The last four bytes give
the offset that point to the first image file directory (IFD). The This and
all other offsets in a TIFF file are with respect to the beginning of
the TIFF file. An IFD can be at any location in the file after the
header but must begin on a word boundary. Section 2.1.3 gives
requirements and practical guidelines on the location of IFDs within a
TIFF file for the fax applications described in this document.
An IFD is a sequence of tagged fields, sorted in ascending order by tag
value. An IFD consists of a 2-byte count of the number of fields, a
sequence of field entries and a 4-byte offset to the next IFD. The
fields contain information about the image and pointers to the image
data. Each separate raster image in the file is represented by an IFD.
Each IFD field entry has 12 bytes, consisting bytes and consists of a 2-byte tag, Tag, 2 bytes
identifying the field type, type (e.g. short, long, rational, ASCII), 4 bytes
giving the field count or number (number of
values, values or offsets), and the 4-byte offset of
the field value. If, based on the type and count, the value takes 4
bytes or less, then it replaces the offset in the field entry. Details
are given in the TIFF specification [TIFF].
A TIFF file can contain more than one IFD, where each IFD is a subfile
whose type is given in the NewSubfileType field. Multiple IFDs can be
organized either as a linked list, with the last entry in each IFD
pointing to the next IFD (the pointer in the last IFD is 0), or as a
tree, using the SubIFDs field in the primary IFD [TTN1]. The SubIFDs
field contains an array of pointers to child IFDs of the primary IFD.
Child IFDs describe related images, such as reduced resolution versions
of the primary IFD image. The same IFD can point both to a next IFD and
to child IFDs, and child IFDs can themselves point to other IFDs. A
Baseline TIFF reader is not required to read any IFDs beyond the first.
McIntyre & Zilles Expires 1/30/98 [Page 5]
Internet Draft File Format for Internet Fax July 30, 1997
All fax modes represent a multi-page fax image as a linked list of IFDs,
with a NewSubfileType field containing a bit that identifies the IFD as
one page of a multi-page document. Each IFD has a PageNumber field,
identifying the page number, number in ascending order, starting at 0 for the
first page. The While a Baseline TIFF reader is not required to read any
IFDs beyond the first, an implementation that reads the files that
comply with this specification SHALL read multiple IFDs. Only the Mixed
Raster Content fax mode, described in Section 7, uses requires the use of
child IFDs also. IFDs.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 7]
Internet Draft File Format for Internet Fax October 10, 1997
2.1.2 Image Structure
An IFD stores an image as one or more strips. A strip consists of 1 or
more scanlines (rows) of raster image data in compressed form. An image
may be stored in a single strip or may be divided into several strips,
which would require less memory to buffer. (Baseline TIFF [TIFF]
recommends about 8k bytes per strip, but existing FAX fax usage is typically
one strip per image.)
Each IFD requires the three strip-related fields: StripOffsets, RowsPerStrip
and StripByteCounts. The StripOffsets field, which field is an array of pointers to
the strip or strips that contain the actual image data. The
StripByteCounts field gives the number of bytes in each strip after
compression. TIFF requires that each strip, except the last, contain the
same number of scanlines, which is given in the RowsPerStrip field. This
document introduces the new StripRowCounts field that allows a variable
number of scanlines per strip, which is required by the Mixed Raster
Content fax mode. mode (Section 8).
Image data is stored as uninterpreted, compressed data streams within a
strip. The formats of these streams follow the ITU-T Recommendations.
The Compression field in the IFD indicates the type of compression, and
other TIFF fields in the IFD describe image attributes, such as color
encoding and spatial resolution. Compression parameters are stored in
the compressed data stream, rather than in TIFF fields. This makes the
TIFF representation and compressed data format specification independent
of each another. This approach, modeled on [TTN2], allows TIFF to
gracefully add new compression schemes as they become available.
Some attributes can be specified both in the compressed data stream and
within a TIFF field. It is possible that the two values will differ.
When this happens for values required to interpret the data stream, then
the values in the data stream take precedence. For informational values
that are not required to interpret the data stream, such as author name,
then the TIFF field value takes precedence.
2.1.3 Recommended TIFF File Structure for Fax Applications
The TIFF specification has a very flexible file structure, which does
not specify the ordering of IFDs, fields values and image data in a
file. It is up to individual applications to require or recommend an
ordering. In fax applications, it is recommended
This section describes a file structure for the writing of TIFF files
that is required in the minimal black-and-white mode (Section 3) and
recommended in all other modes (Sections 4-8). This file structure
orders data be
ordered in a TIFF file in the same way it is ordered in a fax
transmission.
There would Although this file structure simplifies the implementation
of TIFF writers and readers in fax applications, for interchange
robustness, readers SHOULD be prepared to read TIFF files whose
structure is consistent with [TIFF], which supports a more flexible file
structure than is described in this section.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 8]
Internet Draft File Format for Internet Fax October 10, 1997
The writing of TIFF files for fax is based on a small number of ordering
principles: (1) there SHOULD be an IFD for each page in a multi-page fax document, and
document; (2) the IFDs would SHOULD occur in the same order in the file as the
pages occur in the document. The IFD for page 1 would come first, document; (3) the IFD for page 2
next, and so on.
McIntyre & Zilles Expires 1/30/98 [Page 6]
Internet Draft File Format for Internet Fax July 30, 1997
It is also recommended that SHOULD precede the field values and image data of a given
IFD occur in the file between the offset
to the next IFD which it has offsets; and (4) the start
of the next IFD. The fields values would come first, pointed to by IFD, the value offsets of the field entries in the IFD, followed by data and the image
data, pointed
data it has offsets to by the values of the StripOffsets field. If SHOULD precede the next image
data in IFD. For minimal
black-and-white mode (Section 3.5), the SHOULDs become SHALLs.
An IFD is stored in multiple strips, then the strips would
occur in the file entry in an IFD either contains the same order value associated with that
entry or, if the data they contain occurs in value length is longer than four bytes, the facsimile transmission, starting at the top of the page.
This specification introduces an optional new GlobalParametersIFD field,
defined in Section 2.2.4. This field has type IFD and entry
contains
parameters describing an offset to the fax session. While it is often possible value stored outside the IFD. Long values are
needed for resolution and such (meta) data as dates, names and
descriptions. The long values SHOULD be ordered to
obtain these parameters by scanning follow the file, it is convenient IFD that
contains an offset to make them available together in one place for fast and easy access. If before the
GlobalParametersIFD occurs in a TIFF file, it is recommended image data for that it IFD.
In addition to the above ordering principles, minimal black-and-white
mode (Section 3) requires that image data for each page SHALL be
located in a
single strip. For the first IFD, immediately following extended black-and-white mode, the 8-byte image file
header.
2.2 TIFF Fields data for Fax Applications
The TIFF specification is organized as
each page SHOULD be contained within a baseline and several
extensions, including technical notes single strip.
If the image data in the IFD is stored in multiple strips, then the
strips SHOULD occur in the file in the same order that will be incorporated the data they
contain occurs in the
next release facsimile transmission, starting at the top of TIFF. the
page.
The baseline and extensions have required and
optional fields.
Facsimile applications require (and recommend) a mixture effect of baseline and
extensions fields, as well as new fields these ordering principles is that are not part of the TIFF
specification and that are defined in this document. Sections 3-7 for
each fax mode have sub-sections IFD for required and recommended fields;
each sub-section organizes the fields according to whether they are
baseline, extension or new fields.
The fields required for facsimile have only a few legal values,
specified in the ITU-T Recommendations. Of these legal values, some are
required and some are optional, just as they are required (mandatory) or
optional in fax implementations that conform to first
page should come first, followed by the ITU-T
Recommendations. The required and optional any data values are noted in (dates,
descriptions, ...), followed by the
sections on image data for the different fax modes.
This section describes first page, then
the fields required or recommended by more than
one fax mode. The pattern IFD for the description of TIFF fields in this
draft second page, etc. This is
FieldName(TagValueInDecimal) = values. TYPE
WhetherRequiredByTIFForTIFFforFAX
Count = (omitted if =1) = (if not shown in current spec but available)
Explanation of the field, how it's used, and the values it can have.
Default value, if any
When a field’s default value is the desired value, that field may be
omitted from the relevant following figure.
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD unless specifically required by the text
of this specification.
McIntyre & Zilles
| IFD (page 0) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 0) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 1) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 1) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 2) | <----------+ Offset
+-----------------------+
| : |
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 7] 9]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
2.2.1. TIFF Fields
Each IFD is required to have a PageNumber field, which has value 0 for all fax modes
The TIFF fields listed in this section are required by all fax modes,
but do not have mode-specific values. The next sub-section lists the
required fields common to all fax modes and which do have mode-specific
values.
ImageLength(257). SHORT or LONG
RequiredByTIFFBaseline
Total number of scanlines in image.
No default, must be specified.
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAX, RequiredByTIFFBaseline
Bit 1 is 1 if
the image is a single page of a multi-page document.
Default = 0 (no subfile bits on)
PageNumber(285) SHORT
RequiredByTIFFforFAX, TIFFExtension
Count = 2
The first number represents the page number (0 page, 1 for the first page);
the second number is the total number of pages page, and so on.
This specification introduces an optional new GlobalParametersIFD field,
defined in Section 2.2.4. This field has type IFD and indicates
parameters describing the document. If
the second value fax session. While it is 0, then often possible to
obtain these parameters by scanning the total page count file, it is not available.
ResolutionUnit(296) = 2, 3. SHORT
RequiredByTIFFBaseline
The unit of measure convenient to make
them available together in one place for resolution. 2 = inch, 3 = centimeter
Default = 2 (field may be omitted if this fast and easy access. If the
GlobalParametersIFD occurs in a TIFF file, it is recommended that it be
located in the value)
RowsPerStrip(278). SHORT or LONG
RequiredByTIFFBaseline first IFD, immediately following the 8-byte image file
header.
2.2 TIFF Fields for All Fax Applications
The number of scanlines per TIFF strip. For a single strip image,
this specification [TIFF] is the same organized as the value of the ImageLength field.
Default = 2**32 - 1 (meaning all scanlines a mandatory baseline and
several extensions, including technical notes [TTN1, TTN2] that will be
incorporated in one strip)
StripByteCounts(279). SHORT or LONG
RequiredByTIFFBaseline
Count = number of strips
For each strip, the number next release of bytes in that strip after compression.
No default, must be specified.
StripOffsets(273). SHORT or LONG
RequiredByTIFFBaseline
Count = number TIFF. The baseline and extensions
have required and optional fields.
Facsimile applications require (and recommend) a mixture of strips
For each strip, the byte offset from the beginning baseline and
extensions fields, as well as some new fields that are not part of the file to
that strip.
No default, must be specified.
McIntyre & Zilles Expires 1/30/98 [Page 8]
Internet Draft File Format for Internet Fax July 30, 1997
2.2.2 Additional
TIFF Fields required specification and that are defined in this document. Sections 3-8
for all each fax modes mode have sub-sections for required and recommended fields;
each sub-section organizes the fields according to whether they are
baseline, extension or new.
The TIFF fields listed required for facsimile have only a few legal values,
specified in this section the ITU-T Recommendations. Of these legal values, some are
required by all and some are optional, just as they are required (mandatory) or
optional in fax modes,
but implementations that conform to the ITU-T
Recommendations. The required and optional values associated with them depend are noted in the
sections on the particular different fax mode
being described. Therefore, only modes.
This section describes the fields are defined here; the values
applicable to a particular required or recommended by all fax mode are described in Sections 3-7.
BitsPerSample(258) SHORT
RequiredByTIFFBaseline
Number
modes. The pattern for the description of bits per image sample
Default = 1 (field may be omitted if TIFF fields in this draft is
FieldName(TagValueInDecimal) = values. TYPE
WhetherRequiredByTIFForTIFFforFAX
Count = (omitted if =1) = (if not in current spec but available)
Explanation of the value)
Compression(259) SHORT
RequiredByTIFFBaseline
Compression method used for strip data field, how it's used, and the values it can have.
Default = 1 (no compression, so value, if any, as specified in [TIFF]
When a field's default value is the desired value, that field may not be
omitted from the relevant IFD unless specifically required by the text
of this specification.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 10]
Internet Draft File Format for FAX)
ImageWidth(256) Internet Fax October 10, 1997
2.2.1. TIFF fields required for all fax modes
The TIFF fields listed in this section SHALL be used by all fax modes,
but do not have mode-specific values. The next sub-section lists the
common fields, which all fax modes SHALL use, but which do have mode-
specific values.
ImageLength(257) SHORT or LONG
RequiredByTIFFBaseline
The
Total number of samples per scanline (row) of the image scanlines in image.
No default, must be specified.
PhotometricInterpretation(262) SHORT
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAX, RequiredByTIFFBaseline
The color space of
Bit 1 is 1 if the image data
No default, must be specified
SamplesPerPixel(277) is a single page of a multi-page document.
Default = 0 (no subfile bits on)
Orientation(274) = 1-8. SHORT
RequiredByTIFFBaseline
The number
1: 0th row represents the visual top of components per pixel the image; the 0th column
represents the visual left side of the image. See the current TIFF
specification [TIFF] for further values. Baseline TIFF only requires
value = 1.
Default =1 = 1 (field may be omitted if this is the value)
XResolution(282) RATIONAL
RequiredByTIFFBaseline
PageNumber(285) SHORT
RequiredByTIFFforFAX, TIFFExtension
Count = 2
The horizontal resolution of first number represents the image page number (0 for the first page);
the second number is expressed the total number of pages in pixels the document. If
the second value is 0, then the total page count is not available.
ResolutionUnit(296) = 2, 3. SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch, 3 = centimeter;
Default = 2 (field may be omitted if this is the value)
Note: TIFF-F (Section 4) has traditionally used inch-based measures.
RowsPerStrip(278) SHORT or LONG
RequiredByTIFFBaseline
The number of scanlines per
resolution unit. TIFF strip. For a single strip image,
this is the same as the value of the ImageLength field.
Default = 2**32 - 1 (meaning all scanlines in one strip)
StripByteCounts(279) SHORT or LONG
RequiredByTIFFBaseline
Count = number of strips
For each strip, the number of bytes in that strip after compression.
No default, must be specified
YResolution(283) RATIONAL specified.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 11]
Internet Draft File Format for Internet Fax October 10, 1997
StripOffsets(273) SHORT or LONG
RequiredByTIFFBaseline
The vertical resolution
Count = number of strips
For each strip, the byte offset from the beginning of the image is expressed in pixels per
resolution unit. file to
that strip.
No default, must be specified
2.2.3 specified.
2.2.2 Additional TIFF Fields recommended fields required for all fax modes
The TIFF fields listed in this section are recommended, but not
required, for use with SHALL be used by all fax modes. Recommended modes,
but the values associated with them depend on the mode being described.
Therefore, only the fields that are mode-
specific defined here; the values applicable to a
particular fax mode are described in Section 3-7.
McIntyre & Zilles Expires 1/30/98 [Page 9]
Internet Draft File Format for Internet Fax July 30, 1997
DateTime(306) ASCII
OptionalInTIFFBaseline
Date/time in the format "YYYY:MM:DD Sections 3-8.
BitsPerSample(258) SHORT
RequiredByTIFFBaseline
Number of bits per image sample
Default = 1 (field may be omitted if this is the value)
Compression(259) SHORT
RequiredByTIFFBaseline
Compression method used for strip data
Default = 1 (no compression, so may not be omitted for FAX)
ImageWidth(256) SHORT or LONG
RequiredByTIFFBaseline
The number of samples per scanline (row) of the image
No default, must be specified.
PhotometricInterpretation(262) SHORT
RequiredByTIFFBaseline
The color space of the image data
No default, must be specified
SamplesPerPixel(277) SHORT
RequiredByTIFFBaseline
The number of components per pixel
Default =1 (field may be omitted if this is the value)
XResolution(282) RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit.
No default, must be specified
YResolution(283) RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image is expressed in pixels per
resolution unit.
No default, must be specified
McIntyre, Zilles, et al. Expires 4/10/98 [Page 12]
Internet Draft File Format for Internet Fax October 10, 1997
2.2.3 TIFF fields recommended for all fax modes
The TIFF fields listed in this section MAY be used by all fax modes.
Recommended fields that are mode-specific are described in Section 3-8.
DateTime(306) ASCII
OptionalInTIFFBaseline
Date/time in the format "YYYY:MM:DD HH:MM:SS" in 24-hour format.
No default.
DocumentName(269) ASCII
OptionalInTIFFExtension
OptionalInTIFFExtension(DocumentStorageAndRetrieval)
The name of the scanned document. This is a TIFF extension field,
not a Baseline TIFF field.
No default.
ImageDescription(270) ASCII
OptionalInTIFFBaseline
A string describing the contents of the image.
No default.
Orientation(274) = 1-8 SHORT
RequiredByTIFFBaseline
1: 0th row represents the visual top of the image; the 0th column
represents the visual left side of the image. See the current TIFF
specification [TIFF] for further values.
Default = 1 (field may be omitted if this is the value)
Software(305) ASCII
OptionalInTIFFBaseline
The optional name and release number of the software package that
created the image.
No default.
2.2.4 New TIFF Fields fields recommended for fax modes
The new TIFF fields listed in this section are recommended for MAY be used by all fax modes,
but their support is not expected for the minimal black-and-white fax
mode described in Section 3. These fields describe "global" parameters
of the fax session that created the image data. They are optional, not
part of the current TIFF specification, and are defined in this
document.
The first new field, GlobalParametersIFD, is an IFD that contains global
parameters and is located in a Primary IFD.
GlobalParametersIFD(TagToBeAssigned).
GlobalParametersIFD. IFD
An IFD containing global parameters. It is recommended that a TIFF
writer place this field in the first IFD, where a TIFF reader would
find it quickly.
Each field in the GlobalParametersIFD is a TIFF field that is legal in
any IFD. Required baseline fields should not be located in the
GlobalParametersIFD, but should be in each image IFD. If a conflict
exists between fields in the GlobalParametersIFD and the image IFDs,
then the data in the image IFD shall prevail.
McIntyre & Zilles
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 10] 13]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
Among the GlobalParametersIFD entries is a new ProfileType field which
generally describes information in this IFD and in the TIFF file.
ProfileType(TagToBeAssigned) LONG
The type of image data stored in this IFD:
0 = Unspecified
1 = Group 3 fax
Other
other values for further study
The following new global fields are defined in this document as IFD
entries for use with fax applications.
ITUFaxMode(TagToBeAssigned) = 0 - 4. 5. BYTE
The currently defined values are:
0: does not conform to ITU-T Recommendations for facsimile,
1: minimal black & white lossless (ITU-T Rec. T.4),
2: extended black & white lossless (ITU-T Rec. T.6, T.85), T.4, T.6),
3: lossless JBIG black & white (ITU-T Rec. T.85)
4: lossy color and grayscale (ITU-T Rec. T.42),
4:
5: lossless color and grayscale (ITU-T Rec. T.43),
5:
6: Mixed Raster Content (ITU-T Draft Rec. T.44).
Notes: In a A file that uses can use an ITU encoding with non-ITU parameters,
e.g such as
using JPEG compression of to compress a CMYK data, image. In this case, ITUFaxMode is 0.
CodingMethods(TagToBeAssigned).
CodingMethods(TagToBeAssigned) LONG
This field indicates which coding methods are used in the file. A
bit value of 1 indicates:
Bit 0: unspecified compression,
Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman),
Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read),
Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR), Modified
Read),
Bit 4: ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG),
Bit 5: ITU-T Rec. T.81 (Baseline JPEG),
Bits 6-31: reserved for future use
Notes:
Note: There is a limit of 32 coding compression types to identify standard
compression methods.
VersionYear(TagToBeAssigned) BYTE
Count: 4
The year of the standard specified by the ITUFaxMode field, given as
4 characters, e.g. '1997'; used in lossy and lossless color modes.
VersionNumber(TagToBeAssigned)
ModeNumber (TagToBeAssigned) BYTE
The version mode of the standard specified by the ITUFaxMode field. A
value of 0 indicates Version Mode 1.0; used in Mixed Raster Content mixed raster content mode.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 14]
Internet Draft File Format for Internet Fax October 10, 1997
3. Minimal Black-and-White Fax Mode
This section defines Application W of MIME Media Type image/tiff, which
is the minimal black-and-white mode.
Black-and-white mode is the binary fax application most users are
familiar with today. This mode is appropriate for black-and-white text
and line art. Black-and-white mode is divided into two levels of
capability. This section describes the minimal interchange set of TIFF
McIntyre & Zilles Expires 1/30/98 [Page 11]
Internet Draft File Format for Internet Fax July 30, 1997
fields that must be supported by all implementations in order to assure
that some form of image, albeit black-and-white, can be interchanged.
Section 4 describes extensions to the minimal interchange set of fields
that provide a richer set of black-and-white capabilities.
3.1. Overview
The minimal interchange portion of the black-and-white facsimile mode
supports the original Group 3 fax resolutions, commonly called
"standard" and "fine," and two compression methods: 1-dimensional Modified Huffman (MH) and 2-dimensional Modified READ (MR) lossless
bilevel image coding [T.4]. (READ is an acronym for Relative Element
Address Designate.)
The
compression.
To assure interchange, this mode uses the minimal black-and-white set of fields, with a
minimal set of values. There are no recommended fields in this mode.
Further, the TIFF file is required to be "little endian," which means
that the byte order value in the TIFF header is "II". This mode corresponds is
required to follow the original guidelines laid out in Section 2.1.3 for TIFF Class
F specification [TIFF-F0].
file structure, with the added requirement that a single strip contain
the image data for each page; see Section 3.5. The image data may
contain RTC sequences, as specified in Section 3.4.
3.2. Required TIFF Fields
Besides the fields listed in Section 2.2.1, the minimal black-and-white
fax mode requires the following fields. The fields listed in Section
2.2.1 and the fields and fax-specific values specified in this sub-
section must be supported by all implementations.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 15]
Internet Draft File Format for Internet Fax October 10, 1997
3.2.1 Baseline Fields fields
BitsPerSample(258) = 1. SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)
Compression(259) = 3. SHORT
RequiredByTIFFBaseline
The value 3 is not a TIFF Baseline value [TIFF]; it is an extended
value. The T4Options field must be specified and its value
determines whether specifies
that the data is encoded using the MH or MR encoding of [T.4].
FillOrder(266) = 1, 2. SHORT
RequiredByTIFFBaseline
1 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the higher-order bits of the bytes,
i.e., most significant bit first (MSB).
2 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the lower-order bits of the bytes, i.e.,
least significant bit first (LSB).
The FillOrder field is used to describe how 1 bit pixels are stored
within a byte of compressed image data. There are two possible
FillOrders for each byte: 1) the pixels are stored with the lowest
numbered pixel in the byte in the Most Significant Bit (MSB) of the
byte, or 2) the pixels are stored with the lowest numbered pixel in
the byte in the Least Significant Bit (LSB) of the byte.
McIntyre & Zilles Expires 1/30/98 [Page 12]
Internet Draft File Format for Internet Fax July 30, 1997
NOTE: Baseline TIFF readers are only required to support the first FillOrder = 1,
where the lowest numbered pixel is stored in the MSB of the byte.
However, because many devices, such as modems, transmit the LSB first
when converting the data to serial form, it is common for black-
and-white black-and-
white FAX products to use the second FillOrder =2, where the lowest
numbered pixel is stored in the LSB. Therefore, this value is specified
in the minimal black-and-white mode.
ImageWidth(256) = 1728, 2048, 2432. 1728. SHORT or LONG
RequiredByTIFFBaseline
This mode only supports the fixed a page widths: 1728, 2048, 2432. width of 1728 pixels. This width
corresponds to North American Letter and Legal and to ISO A4 size
pages. No default, must be specified.
PhotometricInterpretation(262) = 0, 1. 0. SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black, 1 = pixel value 1 means white black
No default, must be specified
ResolutionUnit(296) = 2. SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch.
Default = 2 (field may be omitted if this is the value)
McIntyre, Zilles, et al. Expires 4/10/98 [Page 16]
Internet Draft File Format for Internet Fax October 10, 1997
SamplesPerPixel(277) = 1. SHORT
RequiredByTIFFBaseline
The number of components per pixel; 1 for black-and-white
Default =1 (field may be omitted if this is the value)
XResolution(282).
XResolution(282) = 204. RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed value is 204.
No default, must be specified
YResolution(283).
YResolution(283) = 98. 196. RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 98 and 196.
No default, must be specified
3.2.2 Extension Fields fields
T4Options(292) = (Bit 0 = 0 or 1, 0, Bit 1 = 0, Bit 2 = 0, 1) LONG
RequiredTIFFExtension (when Compression = 3)
Bit 0 = 1 indicates MR encoding, = 0 indicates MH encoding.
Bit 1 must be 0
Bit 2 = 1 indicates that fill bits EOLs are required, byte aligned, = 0 no fill bits EOLs not byte
aligned
Default is all bits are 0 (therefore field must be specified) (applies when EOLs are not byte aligned)
Note: The T4Options field is required if when the Compression field has a
value of 3. The T4Options Bit 0 of this field specifies which the encoding (MH or MR) is used (MH only in
this mode) and Bit 2 indicates whether fill bits the EOL codes are required. Fill bits byte-aligned or
not. If they are required in byte aligned, then fill bits have been added as
necessary so that the minimal interchange set. (See End of Line (EOL) codes always end on byte
boundaries. See Section 3.4).
McIntyre & Zilles 3.4 for details.
3.2.3. New Fields
None.
3.3. Recommended TIFF Fields
None.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 13] 17]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
3.2.3 New Fields
None.
3.3 Recommended TIFF Fields
There are three new optional fields for describing black & white fax
page quality. They are not defined in the current TIFF specification
[TIFF].
BadFaxLines(326). SHORT or LONG
The number
3.4. End of "bad" scan lines encountered by Line (EOL) and Return to Control (RTC)
The handling of End of Line (EOL) codes and Return to Control (RTC)
sequences illustrate the facsimile device
during reception. A "bad" scanline differences between conventional fax, which is defined as a scanline that,
when decoded, comprises
bit and stream oriented, and TIFF, which is byte and file oriented.
Conventional fax, Baseline TIFF and TIFF extensions for fax all handle
EOLs and RTCs differently.
In conventional fax, an incorrect number MH-compressed fax data stream for a page
consists of pixels.
No default.
CleanFaxData(327) = 0, 1, 2. SHORT
Indicates if "bad" lines encountered during reception are stored in the following sequence:
EOL, compressed data (first line), EOL, compressed data, or if "bad" lines have been replaced by the receiver.
0 = No "bad" lines
1 = "bad" lines exist, but were regenerated by the receiver,
2 = "bad" lines exist, but have ... ,
EOL, compressed data (last line), RTC (6 consecutive EOL codes)
Baseline TIFF does not been regenerated.
No default.
NOTE: Many facsimile devices do use EOL codes or Return to Control (RTC)
sequences for MH-compressed data, and does not actually output bad lines. Instead, use fill bits to byte
align EOL codes. However, the previous good line is repeated TIFF extension field T4Options used in place of a bad line. Although
this
substitution, known as line regeneration, results specification for MH compression (Compression = 3) allows EOLs.
Furthermore, Bit 2 in a visual
improvement to the image, the data is nevertheless corrupted. The
CleanFaxData field describes the error content of the data. That is,
when the BadFaxLines and ImageLength fields indicate that the facsimile
device encountered lines with an incorrect number of pixels during
reception, the CleanFaxData T4Options field indicates whether these lines are
actually in the data or if not the receiving facsimile device replaced them
with regenerated lines.
ConsecutiveBadFaxLines(328). SHORT or LONG
Maximum number of consecutive "bad" scanlines received. The
BadFaxLines field indicates only the quantity of bad lines. The
ConsecutiveBadFaxLines field is an indicator of
EOL codes are byte aligned. If Bit 2 = 1, indicating the distribution of
bad lines and may therefore be a better general indicator of
perceived image quality.
No Default.
3.4 End of Line Restrictions
The minimal interchange set of fields and values for black-and-white fax
requires all EOLs in compressed image data must be byte-aligned. An EOL
is said to be byte-aligned when codes are
byte aligned, then fill bits have been added as necessary before EOL
codes such so that an EOL code always ends on a byte boundary, thus
ensuring an EOL-sequence of a one byte preceded by a zero nibble:
xxxx0000 00000001.
McIntyre & Zilles Expires 1/30/98 [Page 14]
Internet Draft File Format for Internet Fax July 30, 1997
Recall that Huffman encoding encodes bits, not bytes. This means that
the end-of-line token may end in the middle of a byte. In byte
alignment, extra zero bits (Fill) are added so that and the first
bit of data following an EOL begins on a byte boundary. In effect, byte Without fill
bits, an EOL code may end in the middle of a byte. Byte alignment
relieves application software of the burden of bit-shifting every byte
while parsing scan lines for line-oriented image manipulation (such as
writing a TIFF file).
3.5 Minimal Black-and-White Fax Mode Summary
The table below summarizes the Not all TIFF fields readers historically used for fax are
able to deal with non-byte aligned data.
While TIFF extension allows EOL codes, TIFF in fax applications has
traditionally excluded RTC sequences. Implementations that comprise the minimal
interchange set want common
processing and interfaces for black-and-white facsimile. The Baseline fax data streams and
Extension fields must be supported by all implementations. For
convenience in the table, certain fields which have a value Internet fax files
would prefer that is a
sequence of flag bits the TIFF data include RTC sequences.
To reconcile these differences, RTCs are shown taking integer values that correspond allowed in cases where EOL
codes are not byte aligned and no fill bits have been added to the flags that are set. An implementation data.
This corresponds to situations where the fax data is simply inserted in
a strip without being processed or interpreted. RTCs should test not occur in
the setting of data when EOLs have been byte aligned. This is formally specified in
the
relevant flag bits individually, however, to allow extensions next sub-section.
3.4.1. RTC Exclusion
Implementations which wish to maintain strict conformance with TIFF and
compatibility with the
sequence historical use of flag bits to be appropriately ignored. (See, TIFF for example, fax SHOULD NOT include
the RTC sequence when writing TIFF files. However, implementations which
need to support T.4-generated data transparently MAY include RTCs if Bit
2 in the T4Options below.)
Fields suffixed with an asterisk, "*", are optional fields field is 0, indicating that no fill bits have been
added and need that EOL codes are not
be specified.
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1 |
+---------------------------+--------------------------------+
| Compression | 3: 1D Modified Huffman coding |
| | set T4Options = 4 |
| | 3: 2D Modified Read coding |
| | set T4Options = 5 |
+---------------------------+--------------------------------+
| FillOrder | 1: most significant bit first |
| | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageWidth | 1728, 2048, 2432 |
+---------------------------+--------------------------------+
| ImageLength | n: total number byte aligned. Implementors of scanlines |
| | TIFF
readers should be aware that there are some existing TIFF
implementations for fax that include the RTC sequence in MH image |
+---------------------------+--------------------------------+
| NewSubFileType | 2: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| PageNumber | n,m: page number n followed by |
| | total page count m |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
McIntyre & Zilles data.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 15] 18]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+---------------------------+--------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip | n: number of scanlines per |
| |
3.5. File Structure
The TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1 |
+---------------------------+--------------------------------+
| StripByteCounts | <n>: number or header, described in Section 2.1.1, contains two bytes which
describe the byte order used within the file. For the minimal black-and-
white mode, these bytes SHALL have the value "II" (0x4949), denoting
that the bytes in the TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets | <n>: offset from beginning of |
| | file are in LSByte-first order (little-
endian). The first or 0th IFD immediately follows the header, so that offset to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 204 (pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98, 196 (pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 4: Modified Huffman, fill bits the first IFD is 8. The headers values are shown in the
following table, based on [WIDE]
+--------+-------------------+--------+-----------+
| Offset | Description | required Value |
+--------+-------------------+--------+-----------+
| 0 | 5: 2D Modified Read, fill bits Byte Order | 0x4949 (II) |
+--------+-------------------+--------+-----------+
| required 2 |
+---------------------------+--------------------------------+ Identifier | New Fields 0x0042 |
+---------------------------+--------------------------------+
+--------+-------------------+--------+-----------+
| BadFaxLines* 4 | number Offset of "bad" scanlines |
| | encountered during reception |
+---------------------------+--------------------------------+
| CleanFaxData* | 0: no "bad" lines | 0th IFD | 0x 0000 0008 | 1: "bad" lines exist, but were |
| | regenerated by receiver |
| | 2: "bad" lines exist, but have |
| | not been regenerated |
+---------------------------+--------------------------------+
| ConsecutiveBadFaxLines* | Max number of consecutive |
| | "bad" lines received |
+---------------------------+--------------------------------+
4. Extended Black-and-white fax mode
4.1 Overview
+--------+-------------------+--------+-----------+
The previous section described the minimal interchange set of TIFF
fields that must be supported by all implementations in black-and-white SHALL order to assure
that some form of image, albeit black-and-white, can be interchanged.
McIntyre & Zilles Expires 1/30/98 [Page 16]
Internet Draft File Format for Internet Fax July 30, 1997
This section describes extensions to the minimal interchange set of
fields that provide IFDs and image data within a richer set of black-and-white capabilities. In
addition
file according to the MH and MR encodings, Modified Modified READ (MMR) as file structure described in [T.6] is supported. Also available is the single-
progression sequential mode of JBIG [T.82], used in accordance with Section 2.1.3.
Furthermore, the
application rules given in ITU-T Rec. T.85 [T.85]. JBIG coding offers
improved compression image data for halftoned originals.
This section also provides each page SHALL be contained within a standard, updated definition of TIFF-F,
also known as TIFF Class F,equivalent to that found in [TIFF-F]. It has
been proposed to make [TIFF-F] an informational RFC.
4.2. Required TIFF Fields
single strip. This section lists means that the required fields and StripOffsets field will contain the values they must have
pointer to
be ITU-compatible. Besides the fields listed image data. With two exceptions, the field entries in Section 2.2.1, the
extended black-and-white fax mode requires
IFD contain the following fields.
4.2.1. Baseline Fields
BitsPerSample(258) = 1. SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may field values instead of offsets to field values located
outside the IFD. The two exceptions are the values for the XResolution
and YResolution fields, both of which are type RATIONAL and require 2 4-
byte numbers. They are placed immediately after the IFD which contains
the offsets to them, as shown in Section 2.1.3, and before the image
data pointed to by that IFD.
Using the file structure in Section 2.1.3 can reduce the memory
requirements in implementations. It is also provides some support for
streaming, in which a file can be omitted if this processed as it is received and before
the value)
Compression(259) = 3, 4, 9. SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding, must have T4Options field This entire file is
a received.
3.6 Minimal Black-and-white Mode Summary
The table below summarizes the TIFF fields that comprise the minimal
interchange set for black-and-white facsimile. The Baseline and
Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
Read, fields must be supported by all implementations. For
convenience in the table, certain fields which have T6Options field)) This is a TIFF Extension value.
9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG) This value that is a TIFF Extension value.
Default = 1 (and is not applicable; field must be specified)
ImageWidth(256) SHORT or LONG
RequiredByTIFFBaseline
This mode supports
sequence of flag bits are shown taking integer values that correspond to the following fixed page widths: 1728, 2048,
2432, 2592, 3072, 3456, 3648, 4096, 4864.
No default; must be specified
PhotometricInterpretation(262) = 0, 1. SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black 1 = pixel value 1 means white
No default, must be specified
SamplesPerPixel(277) = 1. SHORT
RequiredByTIFFBaseline
1 = monochrome, bilevel in this case (see BitsPerSample)
Default =1 (field may be omitted if this is flags that are set. An implementation should test the value)
McIntyre & Zilles setting of the
relevant flag bits individually, however, to allow extensions to the
sequence of flag bits to be appropriately ignored. (See, for example,
T4Options below.)
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 17] 19]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
XResolution(282) RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are: 200, 204,
300, 400, and 406.
No default, must be specified
YResolution(283) RATIONAL
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, 392, and 400 pixels/inch
No default, must be specified
NOTE: Not all combinations of XResolution, YResolution and ImageWidth
are legal. The following table gives the legal combinations for inch-
based resolutions and corresponding paper sizes [T.30].
+--------------+-----------------+---------------------------+
+---------------------------+--------------------------------+
| XResolution x YResolution Baseline Fields | ImageWidth Values |
+--------------+-----------------+---------------------------+
+---------------------------+--------------------------------+
| 200x100,200x200,200x400 BitsPerSample | 1728 1 | 2048
+---------------------------+--------------------------------+
| 2432 Compression |
+--------------+-----------------+---------------------------+ 3: 1D Modified Huffman coding | 300 x 300
| 2592 | 3072 set T4Options = 0 or 4 | 3648
+---------------------------+--------------------------------+
|
+--------------+-----------------+---------------------------+ FillOrder | 400 x 400 2: least significant bit first | 3456
+---------------------------+--------------------------------+
| 4096 ImageWidth | 4864 1728 |
+--------------+-----------------+---------------------------+
|Letter,A4| B4
+---------------------------+--------------------------------+
| A3 ImageLength |
+---------+--------+--------+ n: total number of scanlines | Paper Size
|
+---------------------------+
FillOrder(266) = 1, 2. SHORT
See 3.2.1 above
4.2.2. Extension Fields
T4Options(292) = (Bit 0 = 0 or 1, | in image |
+---------------------------+--------------------------------+
| NewSubFileType | 2: Bit 1 = 0, Bit 2 = 0 or 1) LONG
RequiredTIFFExtension (when Compression = 3)
T4Options was known as Group3Options in identifies single |
| | page of a prior version multi-page document |
+---------------------------+--------------------------------+
| PageNumber | n,m: page number n followed by |
| | total page count m |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
+---------------------------+--------------------------------+
| ResolutionUnit | 2: inch |
+---------------------------+--------------------------------+
| RowsPerStrip | number of [TIFF].
Bit 0 scanlines per strip |
| | = ImageLength, with one strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1 indicates MR encoding, = 0 indicates |
+---------------------------+--------------------------------+
| StripByteCounts | number or bytes in TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets | offset from beginning of |
| | file to single TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 204 (pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98, 196 (pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 0: MH encoding.
Bit 1 must be 0
Bit 2 = 1 indicates that fill bits are required, = 0 no fill bits
Default is all bits are 0 (field must be specified for fax,see
3.2.2.)
McIntyre & Zilles coding, EOLs not byte |
| | aligned |
| | 4: MH coding, EOLs byte aligned|
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 18] 20]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization
4. Extended Black-and-White fax mode
This section defines Application F of 2D Modified Modified Read
compression.
Bit 0 must be 0.
Bit 1 = 0 indicates uncompressed data mode is not allow; = 1
indicates uncompressed data is allowed (see [TIFF]).
Default MIME Media Type image/tiff, which
is all bits 0. For FAX, the field extended black-and-white mode.
The previous section described the minimal interchange set of TIFF
fields that must be present and have supported by all implementations in order to assure
that some form of image, albeit black-and-white, can be interchanged.
This section describes extensions to the value 0. The use minimal interchange set of uncompressed data where compression would
expand
fields that provide a richer set of black-and-white capabilities. In
addition to the data size is not allowed for FAX.
4.2.3. New Fields
None.
4.3. Recommended TIFF Fields
4.3.1. Baseline Fields
See Section 2.2.3.
4.3.2. Extension Fields
See Section 2.2.3.
4.3.3. New Fields
See Sections 2.2.4 MH encoding, Modified READ (MR) and 3.3.
4.4. TIFF-F Definition
TIFF-F, also known Modified Modified
READ (MMR) encoding as TIFF Class F, was originally defined described in 1989
[TIFF-F0]. Recent discussions and work have proposed updating it to
include MMR compression and higher resolutions, which the ITU-T has
approved for use with Group 3 facsimile. If JBIG compression
(Compression=9) [T.4] and the global parameters [T.6] are excluded, then the
extended black-and-white mode described in this section corresponds to
the most recent proposal for TIFF-F [TIFF-F]. Therefore, this supported.
This section provides a standard definition of what has historically
been known as TIFF Class F, now known as Application F of MIME Media
Type image/tiff, or TIFF-F.
4.5. Extended Black-and-white Fax Mode Summary
Recommended fields are shown In doing so, it aligns this mode with
current ITU-T Recommendations and with current industry practice.
Section 4.1 gives an asterisk *.
Required overview of TIFF-F. Section 4.2 describes the TIFF
fields or values are shown with that SHALL be used in this mode. Section 4.3 describes the fields
that MAY be used in this mode. In the spirit of the original TIFF-F
specification, Sections 4.4 and 4.5 discuss technical implementation
issues and warnings. Section 4.6 gives an example use of TIFF-F. Section
4.7 gives a double asterisk **. If summary of the
double asterisk required and recommended fields and their
values.
4.1 TIFF-F Overview
Though it has been in common usage for many years, TIFF-F has previously
never been documented in the form of a standard. An informal TIFF-F
document was originally created by a small group of fax experts led by
Joe Campbell. The existence of TIFF-F is on noted in [TIFF] but it is not
defined. This document serves as the field name, then all formal definition of the listed values are
required F
application of implementations; if [TIFF] for Internet applications. For ease of reference,
the double asterisks are term TIFF-F will be used throughout this document as a shorthand for
"Application F of TIFF".
Up until the TIFF 6.0 specification, TIFF supported various "Classes"
which defined the use of TIFF for various applications. Classes were
used to support specific applications. In this spirit, TIFF-F has been
known historically as "TIFF Class F". Previous informal TIFF-F
documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0
[TIFF], the TIFF Class concept has been eliminated in favor of the Values
column, then only
concept of Baseline TIFF. Therefore, this document updates the values suffixed with a double asterisk are
required
definition of implementations.
McIntyre & Zilles TIFF-F as the F application of TIFF, by using Baseline
TIFF as defined in [TIFF] as the starting point and then adding the TIFF
extensions to Baseline TIFF which apply for TIFF-F. In almost all
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 19] 21]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 3**: 1D Modified Huffman
cases, the resulting definition of TIFF-F fields and |
| | 2D Modified Read coding |
| | 4: 2D Modified Modified Read |
| | coding |
| | 9: JBIG |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time values remains
consistent with those used historically in earlier definitions of TIFF
Class F. Where some of 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 |
| | values for fields have been updated to
provide more precise conformance with the contents of ITU-T [T.4] and [T.30] fax
recommendations, these differences are noted.
4.2. Required TIFF Fields
This section lists the image. |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048**, 2432**, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | required fields and the values they must have to
be ITU-compatible. Besides the fields listed in image |
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| Orientation* | 1-8, Section 2.2.1, the
extended black-and-white fax mode SHALL use the following fields.
4.2.1. Baseline fields
BitsPerSample(258) = 1. SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 1 |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number (field may be omitted if this is the value)
Compression(259) = 3, 4. SHORT
RequiredByTIFFBaseline
3 = 1- or bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
McIntyre & Zilles Expires 1/30/98 [Page 20]
Internet Draft File Format for Internet Fax July 30, 1997
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 406 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 392, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| 2- dimensional coding, must have T4Options | 0: required if Compression field This is |
| |
a TIFF Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Huffman, no fill bits |
| | 1: required if Compression is |
| | 2D Modified
Read, no fill bits |
| | 4**: required if Compression |
| | must have T6Options field)) This is Modified Huffman, fill bits |
| | 5**: required if Compression |
| | a TIFF Extension value.
Default = 1 (and is 2D not applicable; field must be specified)
NOTE: Baseline TIFF permits use of value 2 for Modified Read, fill bits |
+---------------------------+--------------------------------+
| T6Options | 0: required if Compression is |
| | 2D Modified Modified Read |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| BadFaxLines* | number of "bad" scanlines |
| | encountered during reception |
+---------------------------+--------------------------------+
| CleanFaxData* | 0: no "bad" lines |
| | 1: "bad" lines exist, but were |
| | regenerated by receiver |
| | 2: "bad" lines exist, Huffman
encoding, but have |
| | not been regenerated |
+---------------------------+--------------------------------+
| ConsecutiveBadFaxLines* | Max number of consecutive |
| | "bad" lines received |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | <IFD>: global parameters IFD |
+---------------------------+--------------------------------+
| ProfileType* | n: type of the data stored in |
| | TIFF file |
+---------------------------+--------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used |
| | is presented in file |
+---------------------------+--------------------------------+
McIntyre & Zilles Expires 1/30/98 [Page 21]
Internet Draft File Format for Internet Fax July 30, 1997
5. Base Color Fax Mode
5.1. Overview
This a form which is the base mode for color not byte aligned
and grayscale facsimile, which means
that all applications that support color fax must support so this mode. The
basic approach value is the lossy JPEG not specified for fax applications.
See Sections 4.4.4, 4.5.1 and 4.5.2 for more information on compression [T.81] of L*a*b* color data
[T.42]. Grayscale applications use the L* lightness component; color
applications use the L*, a*
and b* components.
This mode uses a new PhotometricInterpretation encoding.
FillOrder(266) = 1 , 2. SHORT
RequiredByTIFFBaseline
1 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the higher-order bits of the bytes,
i.e., most significant bit first (MSB).
2 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the lower-order bits of the bytes, i.e.,
least significant bit first (LSB).
The FillOrder field value is used to describe how 1 bit pixels are stored
within a byte of compressed image data. There are two possible
FillOrders for each byte: 1) the L*a*b* encoding specified in [T.42]. This encoding differs pixels are stored with the lowest
numbered pixel in two
ways from the other L*a*b* encodings used byte in TIFF [TIFF, TTN1]: it
specifies a different default range for the a* and b* components, based
on a comprehensive evaluation Most Significant Bit (MSB) of existing hardcopy output, and it
optionally allows selectable range for the L*, a* and b* components.
5.2. Required TIFF Fields
This section lists
byte, or 2) the required fields, pixels are stored with the lowest numbered pixel in addition to those given
the byte in
Section 2.2.1, and the values they must support Least Significant Bit (LSB) of the byte.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 22]
Internet Draft File Format for Internet Fax October 10, 1997
NOTE: Baseline TIFF readers are only required to be compatible with
ITU-T Rec. T.42 and Annex E support the first
FillOrder (value = 1) where the lowest numbered pixel is stored in ITU-T Rec. T.4.
5.2.1. Baseline Fields
ImageWidth(256). SHORT or LONG
This mode supports the following fixed page widths: 864, 1024, 1216,
MSB of the byte. However, because many devices, such as modems, transmit
the LSB first when converting the data to serial form, it is common for
black-and-white FAX products to use the second FillOrder (value =2)
where the lowest numbered pixel is stored in the LSB. Therefore, this
value is specified in the minimal black-and-white mode. However, TIFF-F
is required to support both bit orders.
See Section 4.4.2 for more information on bit order.
ImageWidth(256)= : 1728, 2048, 2432, 2592, 3072, SHORT or LONG
3456, 3648, 4096, 4864.
BitsPerSample(258) = 8, 12. SHORT
Count = SamplesPerPixel
The base color fax mode requires 8 bits per sample, with 12 as an
option. 12 bits per sample is not baseline TIFF.
Compression(259) = 7. SHORT
Base color fax mode uses Baseline JPEG compression. Value 7
represents JPEG compression as specified in [TTN2].
PhotometricInterpretation(262) = 10. SHORT
Base color fax mode requires pixel values to be stored using the CIE
L*a*b* encoding defined in ITU-T Rec. T.42. 4864
RequiredByTIFFBaseline
This encoding is
indicated by mode supports the PhotometricInterpretation value 10, referred following fixed page widths: 1728, 2592, 3456
(corresponding to as
ITULAB. With this encoding, the minimum sample value is
mapped North American Letter and Legal, ISO A4 paper
sizes), 2048, 3072, 4096 (corresponding to 0 ISO B4 paper size), and the maximum sample value is mapped
2432, 3648, 4864 (corresponding to (2^n - 1),
i.e. ISO A3 paper size).
No default; must be specified
NOTE: Historical TIFF-F did not include support for the maximum value, where n is following widths
related to higher resolutions: 2592, 3072, 3648, 3456, 4096 and 4864.
Historical TIFF-F documents also included the BitsPerSample value.
The conversion from unsigned ITULAB-encoded samples following values related
to signed
CIE L*a*b* values is determined by the Decode field; see Sec. 5.2.2
Note: PhotometricInterpretation values 8 A5 and 9 specify encodings for
CIE L*a*b* [TIFF] A6 widths: 816 and ICC L*a*b* [TTN1], but they are fixed
encodings, which use different minimum 1216. Per the most recent version of [T.4],
A5 and maximum samples than A6 documents are no longer supported in Group 3 facsimile, so the
T.42 default encoding. As currently defined, they
related width values are not able now obsolete. See section 4.5.2 for more
information on inch/metric equivalencies and other implementation
details.
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAX, RequiredByTIFFBaseline
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on)
NOTE: Bit 1 is always set to
represent fax-encoded L*a*b* data.
McIntyre & Zilles 1 for TIFF-F, indicating a single page of a
multi-page image. The same bit settings are used when TIFF-F is used for
a one page fax image.
See Section 4.4.3 for more details on multi-page files.
PhotometricInterpretation(262) = 0, 1. SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black, 1 = pixel value 1 means white.
This field allows notation of an inverted or negative image.
No default, must be specified
ResolutionUnit(296) = 2, 3. SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F
has traditionally used inch-based measures.
Default = 2 (field may be omitted if this is the value)
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 22] 23]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
SamplesPerPixel(277) = 1, 3. 1. SHORT
1: L* component only
3: L*, a*, b* components
Encoded according to PhotometricInterpretation field
XResolution(282). RATIONAL
YResolution(283). RATIONAL
The resolution of the image is expressed
RequiredByTIFFBaseline
1 = monochrome, bilevel in this case (see BitsPerSample)
Default =1 (field may be omitted if this is the value)
XResolution(282) = 200, 204, 300, 400, 406 RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels per inch, pixels/inch, the allowed XResolution values are: 100, 200, 204,
300, 400, and 400. The base color fax mode requires the pixels to be
square, hence YResolution 406.
No default, must equal XResolution.
5.2.2 Extension Fields be specified
NOTE: The JPEG compression standard allows for the a*b* chroma components values of
an image to be subsampled relative 200 and 406 have been added to the L* lightness component. The
extension fields ChromaSubSampling historical TIFF-F
values, for consistency with [T.30]. Some existing TIFF-F
implementations may also support values of 77 pixels/cm. See section
4.5.2 for more information on inch/metric equivalencies and ChromaPositioning define other
implementation details.
YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the
subsampling. They are image is expressed in pixels per
resolution unit. In pixels/inch, the same as YCbCrSubSampling allowed values are: 98, 100,
196, 200, 300, 391, and YCbCrPositioning,
which 400 pixels/inch
No default, must be specified
Note: The values of 100, 200, and 391 have been renamed to reflect their applicability added to other color
spaces.
ChromaSubSampling(530). SHORT
Count = 2
Specifies the subsampling factors historical
TIFF-F values, for the chroma components of a
L*a*b* image. The two subfields consistency with [T.30]. Some existing TIFF-F
implementations may also support values of this field, ChromaSubsampleHoriz 77 and ChromaSubsampleVert, specify the horizontal 38.5 (cm). See section
4.5.2 for more information on inch/metric equivalencies and vertical
subsampling factors respectively.
SHORT 0: ChromaSubsampleHoriz = 1, 2, 4.
1: equal numbers other
implementation details.
Not all combinations of lightness XResolution, YResolution and chroma samples horizontally,
2: twice as many lightness samples as chroma samples horizontally,
4: four times as many lightness samples as chroma samples
horizontally.
SHORT 1: ChromaSubsampleVert = 1, 2, 4.
1: equal numbers of lightness and chroma samples vertically,
2: twice as many lightness samples as chroma samples vertically,
4: four times as many lightness samples as chroma samples
vertically. ImageWidth are
legal. The default value for ChromaSubSampling is (2,2), which is the
default for chroma subsampling in color fax [T.42]. T.42 supports no
chroma subsampling, i.e. ChromaSubSampling = (1,1), as an option.
ChromaPositioning(531) = 1, 2. SHORT
Specifies the spatial positioning of chroma components relative to
the lightness component. See following table gives the current TIFF specification under
YCbCrPositioning for further information.
1: centered,
2: cosited.
Default = 1, which is what ITU-T T.4, Annex E specifies.
McIntyre & Zilles legal combinations and
corresponding paper size [T.30].
+--------------+-----------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------+-----------------+---------------------------+
| 200x100,200x200,204x98,204x196 | 1728 | 2048 | 2432 |
+--------------+-----------------+---------------------------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------+-----------------+---------------------------+
| 406 x 391, 400 x 400 | 3456 | 4096 | 4864 |
+--------------+-----------------+---------------------------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 23] 24]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
Decode(TagToBeAssigned). SHORT
Count
4.2.2. Extension fields
T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 * SamplesPerPixel
Describes how to map image sample values into the range of values
appropriate for the current color space. In general, the values are
taken in pairs and specify the minimum and maximum output value for
each color component. For the base color fax mode, Decode maps from
the ITULAB encoding to L*a*b* and has = 0 or 1) LONG
RequiredTIFFExtension (when Compression = 3)
T4Options was also known as Group3Options in a count prior version of 6 values. In this
case, the input is an unsigned ITULAB-encoded value and the output
is a signed L*a*b* value.
L*
[TIFF].
Bit 0 = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
a* 1 indicates MR encoding, = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
b* 0 indicates MH encoding.
Bit 1 must be 0
Bit 2 = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)
where Decode[0] 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned
Default is the minimum value for L*, Decode[1] all bits are 0 (applies when MH encoding is the
maximum value, etc. used and n EOLs
are not byte aligned EOLs) (See Section 3.2.2.)
The T4Options field is required when the BitsPerSample Compression field has a
value of 3. This field value, either 8
or 12. ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a
range used (MH or MR) and offset for each component, which are related to
whether the Decode
field values EOL codes are byte-aligned or not. If they are byte
aligned, then fill bits have been added as follows:
Decode[0] = - (Lrange x Loffset) / 2^n
Decode[1] = Decode[0] + Lrange
NOTE: The following table gives necessary so that the default range End
of Line (EOL) codes always end on byte boundaries See Sections 3.4,
4.5.3 and offsets, as
specified 4.5.4 for details.
NOTE: The data in ITU-T Rec. T.42, and the corresponding minimum and maximum
L*a*b* component and ITULAB encoded values.
+-----------------------------------------------------------+
| Component | Rec. T.42 | L*a*b* | ITULAB |
| | defaults | values | a TIFF-F image using a T.4 encoding |
+-----------+------------------+------------+---------------+
| | Range | Offset | Min | Max | Min | Max |
+-----------+--------+---------+------+-----+-----+---------+
| L* | 100 | 0 | 0 | 100 | is not terminated
with an RTC; see Section 4.5.5.
T6Options(293) = (Bit 0 | 2^n - = 0, Bit 1 |
+-----------+--------+---------+------+-----+-----+---------+
| a* | 170 | 128 | -85 | 85 | = 0). LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified Read
compression. T6Options was also known as Group4Options in a prior
version of [TIFF].
Bit 0 | 2^n - must be 0.
Bit 1 |
+-----------+--------+---------+------+-----+-----+---------+
| b* | 200 | 96 | -75 | 125 | = 0 | 2^n - indicates uncompressed data mode is not allowed; = 1 |
+-----------+--------+---------+------+-----+-----+---------+
The default value for Decode
indicates uncompressed data is (0, 100, -85, 85, -75, 125), which allowed (see [TIFF]).
Default is
based on all bits 0. For FAX, the ITULAB encoding, with PhotometricInterpretation 10,
SamplesPerPixel 3, field must be present and BitsPerSample 8.
5.2.3. have
the value 0. The use of uncompressed data where compression would
expand the data size is not allowed for FAX.
NOTE: MMR compressed data is two-dimensional and does not use EOLs. Each
MMR encoded image MUST include an "end-of-facsimile-block" (EOFB) code
at the end of each coded strip; see Section 4.5.6.
4.2.3. New Fields fields
None.
5.3.
4.3. Recommended TIFF Fields fields
4.3.1. Baseline fields
See Sections Section 2.2.3. and 2.2.4.
McIntyre & Zilles
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 24] 25]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
5.4 Base Color Fax Mode Summary
Recommended
4.3.2. Extension fields are shown with an asterisk *
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 8: 8 bits per color sample |
| | 12:
See Section 2.2.3.
4.3.3. New fields
Three new, optional 12 bits/sample |
+---------------------------+--------------------------------+
| Compression | 7: JPEG |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time fields, used in the |
| | 24-hour format |
| | "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | original TIFF-F description to
describe page quality, are defined in this specification. The
information contained in these fields is usually obtained from receiving
facsimile hardware (if applicable). They SHOULD NOT be used in writing
TIFF-F files for facsimile image data that is error corrected or
otherwise guaranteed not to have coding errors. Some applications need
to understand exactly the contents error content of the image. |
+---------------------------+--------------------------------+
| ImageWidth | 864, 1024, 1216, 1728, 2048, |
| | 2432, 2592, 3072, 3456, 3648, |
| | 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength | n: total number of scanlines |
| | in data. For example, a CAD
program might wish to verify that a file has a low error level before
importing it into a high-accuracy document. Because Group 3 facsimile
devices do not necessarily perform error correction on the image |
+---------------------------+--------------------------------+
| NewSubFileType | 2: Bit 1 identifies single page|
| | data,
the quality of a multi-page document |
+---------------------------+--------------------------------+
| Orientation* | 1-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 10: ITULAB |
+---------------------------+--------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1: L* (lightness) |
| | 3: LAB |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release number |
| | of creator software |
+---------------------------+--------------------------------+
| StripByteCounts | <n>: number or bytes in |
| | TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets | <n>: offset from beginning |
| | of file to each TIFF strip |
+---------------------------+--------------------------------+
McIntyre & Zilles Expires 1/30/98 [Page 25]
Internet Draft File Format for Internet Fax July 30, 1997
+---------------------------+--------------------------------+
| XResolution | 100, 200, 300, 400 (written |
| | in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | equal to XResolution (pixels |
| | received page must be square) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name inferred from the pixel count of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber | n,m: page
decoded scan lines. A "good" scan line is defined as a line that, when
decoded, contains the correct number followed by |
| | total page count |
+---------------------------+--------------------------------+
| Decode | minL, maxL, mina, maxa, minb, |
| | maxb: minimum and maximum |
| | values for L*a*b* |
+---------------------------+--------------------------------+
| ChromaSubSampling | ChromaSubsampleHoriz: |
| | 1: equal numbers of lightness |
| | and chroma samples |
| | 2: twice pixels. Conversely, a "bad" scan
line is defined as many lightness |
| | samples a line that, when decoded, comprises an incorrect
number of pixels.
BadFaxLines(326) SHORT or LONG
The number of "bad" scan lines encountered by the facsimile device
during reception. A "bad" scanline is defined as chroma samples |
| | 4: four times as many |
| | lightness samples as chroma |
| | samples |
| | ChromaSubsampleVert: |
| | 1: equal numbers of lightness |
| | and chroma samples |
| | 2: twice as many lightness |
| | samples as chroma samples |
| | 4: four times as many lightness|
| | samples as chroma samples |
+---------------------------+--------------------------------+
| ChromaPositioning | 1: centered |
| | 2: cosited |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | <IFD>: IFD containing |
| | global parameters |
+---------------------------+--------------------------------+
| ProfileType* | n: type a scanline that,
when decoded, comprises an incorrect number of data pixels. Note that
PercentBad = (BadFaxLines/ImageLength) * 100
No default.
CleanFaxData(327) = 0, 1, 2. SHORT
Indicates if "bad" lines encountered during reception are stored in |
| | TIFF file |
+---------------------------+--------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms |
| | used
the data, or if "bad" lines have been replaced by the receiver.
0 = No "bad" lines
1 = "bad" lines exist, but were regenerated by the receiver,
2 = "bad" lines exist, but have not been regenerated.
No default.
NOTE: Many facsimile devices do not actually output bad lines. Instead,
the previous good line is repeated in file |
+---------------------------+--------------------------------+
McIntyre & Zilles Expires 1/30/98 [Page 26]
Internet Draft File Format for Internet Fax July 30, 1997
+---------------------------+--------------------------------+
| VersionNumber* | n: version place of ITU fax standard |
+---------------------------+--------------------------------+
| VersionYear* | byte sequence with year of |
| | ITU fax standard |
+---------------------------+--------------------------------+
6. Lossless Color Mode
6.1. Overview
This mode, defined a bad line. Although this
substitution, known as line regeneration, results in [T.43], uses JBIG to losslessly code three types
of color and grayscale images: one bit per color CMY, CMYK and RGB
images; a palettized (i.e. mapped) color image; and continuous tone
color and grayscale images. visual
improvement to the image, the data is nevertheless corrupted. The last two are multi-level and use
CleanFaxData field describes the
L*a*b* encoding specified in [T.42].
6.1.1. Color Encoding
While under development, this mode was called T.Palette, as one error content of its
major additions was palette or mapped color images. Baseline TIFF only
allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* color maps,
using the encoding specified in ITU-T Rec. T.42. Palette color images
are expressed data. That is,
when the BadFaxLines and ImageLength fields indicate that the facsimile
device encountered lines with indices (bits per sample) an incorrect number of 12 bits or less, or
optionally 13 to 16 bits.
Enabling T.43 color maps in TIFF requires pixels during
reception, the extension CleanFaxData field Indexed,
defined indicates whether these bad lines are
actually still in [TTN1], and the PhotometricInterpretation field value data or if the receiving facsimile device replaced
them with regenerated lines.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 26]
Internet Draft File Format for Internet Fax October 10,
defined in Section 5.2.1. 1997
ConsecutiveBadFaxLines(328) LONG or SHORT
Maximum number of consecutive "bad" scanlines received. The following table shows how T.43 image data
is interpreted, using
BadFaxLines field indicates only the PhotometricInterpretation, SamplesPerPixel,
BitsPerSample and Indexed fields.
+----------------------------------------------------------+
| Image Type | PhotoInter- | Samples | Bits Per | Indexed |
| | pretation | PerPixel | Sample | |
|------------+-------------+----------+----------+---------|
| RGB | 2=RGB | 3 | 1 | 0 |
+----------------------------------------------------------+
| CMY | 5=CMYK | 3 | 1 | 0 |
+------------+-------------+----------+----------+---------+
| CMYK | 5=CMYK | 4 | 1 | 0 |
+------------+-------------+----------+----------+---------+
| Palette | 10=ITULAB | 1 | n | 1 |
+------------+-------------+----------+----------+---------+
| Grayscale | 10=ITULAB | 1 | 8, 12 | 0 |
+------------+-------------+----------+----------+---------+
| Color | 10=ITULAB | 3 | 8, 12 | 0 |
+------------+-------------+----------+----------+---------+
McIntyre & Zilles Expires 1/30/98 [Page 27]
Internet Draft File Format for Internet Fax July 30, 1997
6.1.2. JBIG Encoding
T.43 uses the single-progression sequential mode quantity of JBIG, defined in
ITU-T Rec. T.82, in accordance with the application rules described in
ITU-T Rec. T.85. To code multi-level images using JBIG, which bad lines. The
consecutiveBadFaxLines field is a
bi-level compression method, an image is resolved into indicator of the distribution of
bad lines and may therefore be a set better general indicator of
bit-planes using Gray code conversion,
perceived image quality.
No Default.
NOTE: The BadFaxLines and each bit-plane is then JBIG
compressed. ImageLength data indicate only the quantity of
such lines. The Gray code conversion ConsecutiveBadFaxLines field is part an indicator of the data stream
encoding, their
distribution and is may therefore invisible to TIFF.
6.2. Required TIFF Fields
This section lists the required fields, in addition to those in be a better general indicator of
perceived image quality. See Section
2.2.1, and 4.4.5 for examples of the values they must have to be compatible with ITU-T Rec.
T.43.
6.2.1. Baseline Fields
ImageWidth(256). SHORT or LONG
Same page widths as use of
these fields.
While the base color mode; see Section 5.2.1.
BitsPerSample(258) = 1, 8, 9-16. SHORT
Count = SamplesPerPixel
RGB, CMY, CMYK: 1 bit per sample
Continuous tone (L*a*b*): 8 bits per sample, 12 bits optional
Palette color: 12 or fewer bits per sample, 13-16 bits optional
Note: More than 8 bits per sample GlobalParameters IFD is not baseline TIFF.
ColorMap(320). SHORT
Count = 3 * (2**BitsPerSample)
Lossless color recommended for use by all fax mode supports palette-color (indexed) images
where modes,
except the single component value minimal black-and-white mode, it use is used as an index into a full
color lookup table stored optional in the ColorMap field. With lossless color extended black-and-white fax mode, only the ITULAB encoding with 8 bits per sample is
supported for palette-color images. To utilize mode.
4.4. Technical Implementation Issues
4.4.1 Strips
In general, TIFF files divide an image into "strips," also known as
"bands." Each strip contains a color map, few scanlines of the image. By using
strips, a TIFF
Indexed field must be present. TIFF orders reader need not load the color map values so
that all entire image into memory, thus
enabling it to fetch and decompress small random portions of the L* values come first, followed image
as necessary.
The number of scanlines in a strip is described by all the a* values RowsPerStrip
value and
then all the b* values. Because ITU-T Rec. T.43 specifies a "chunky"
ordering with the L*a*b*components number of bytes in the first value, followed strip after compression by
those of the second value, and so on, transferring color map values
between a
StripByteCount value. The location in the TIFF file and fax data stream requires reordering of each strip is
given by the StripOffsets values.
Compression(259) = 9. SHORT
9: ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG)
FillOrder(266) = 1, 2. SHORT
This field
Strip size is only relevant application dependent. The recommended approach for 1 bit multi-
page TIFF-F images is to represent each page as a single strip. Existing
TIFF-F usage is typically one strip per sample color (RGB, CMY,
CMYK); see Section 3.2.1 for page in multi-page TIFF-F files.
See Sections 2.1.2 and 2.1.3.
4.4.2 Bit Order
The current TIFF specification [TIFF] does not require a Baseline TIFF
reader to support FillOrder=2, i.e. lowest numbered 1-bit pixel in the
least significant bit of a byte. It further information.
PhotometricInterpretation(262) = 2, 5, 10. SHORT
2: RGB
5: CMYK, including CMY
McIntyre & Zilles recommends that FillOrder=2
be used only in special purpose applications.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 28] 27]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
10: ITULAB
Image
Facsimile data may also be stored as palette color images, where pixel
values are represented by a single component that is an index into a
color map using the ITULAB encoding. This color map is specified by
the ColorMap field. To use palette color images, set appears on the
PhotometricInterpretation to 10,SamplesPerPixel to 1, and Indexed phone line in bit-reversed order relative
to
1. The color map is stored its description in the ColorMap field. See Section 6.1.1 ITU-T Recommendation T.4. Therefore, a wide
majority of facsimile applications choose this natural order for further discussion on the color encoding.
SamplesPerPixel(277) = 1, 3, 4. SHORT
1: Palette color image, or L*-only if Indexed = 0 data in
a file. Nevertheless, TIFF F readers must be able to read data in both
bit orders and
PhotometricInterpretation is 10 (ITULAB).
3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK).
4: CMYK.
XResolution(282). RATIONAL
YResolution(283). RATIONAL
The resolution support FillOrder values of 1 and 2.
4.4.3. Multi-Page
Many existing applications already read TIFF-F-like files, but do not
support the image is expressed multi-page field. Since a multi-page format greatly
simplifies file management in pixels per resolution
unit. In pixels per inch, allowed XResolution values are: 100, 200,
300, and 400. The lossless color fax mode requires application software, TIFF-F specifies
multi-page documents (NewSubfileType = 2) as the pixels standard case.
It is recommended that applications export multiple page TIFF-F files
without manipulating fields and values. Historically, some TIFF-F
writers have attempted to be
square, hence YResolution must equal XResolution.
6.2.2. Extension Fields
Indexed(364) = 0, 1. SHORT
0: not a palette-color image
1: palette-color image
This field produce individual single-page TIFF-F files
with modified NewSubFileType and PageNumber (page one-of-one) values for
export purposes. However, there is used no easy way to indicate link such multiple
single page files together into a logical multiple page document, so
that the sample values this practice is not recommended.
4.4.4. Compression
In Group 3 facsimile, there are an index
into an array three compression methods which had been
standardized as of color values specified 1994 and are in the ColorMap field.
Lossless color fax mode supports palette-color images with the
ITULAB encoding. common use. The SamplesPerPixel value must be 1.
Decode(TagToBeAssigned) SHORT
Decode is used in connection with the ITULAB encoding of image data;
see Section 5.2.2.
6.2.3. New Fields
None.
6.3. Recommended TIFF Fields
See Sections 2.2.3. ITU-T T.4
Recommendation [T.4] defines a one-dimensional compression method known
as Modified Huffman (MH) and 2.2.4.
6.4. Lossless Color Fax Mode Summary
Recommended fields are shown a two-dimensional method known as Modified
READ (MR) (READ is short for Relative Element Address Designate). In
1984, a somewhat more efficient compression method known as Modified
Modified READ (MMR) was defined in the ITU-T T.6 Recommendation [T.6].
MMR was originally defined for use with an asterisk *
McIntyre & Zilles Group 4 facsimile, so that this
compression method has been commonly called Group 4 compression. In
1991, the MMR method was approved for use in Group 3 facsimile and has
since been widely utilized.
TIFF-F supports these three compression methods. The most common
practice is the one-dimensional Modified Huffman (MH) compression
method. This is specified by setting the Compression field value to 3
and then setting bit 0 of the T4Options field to 0. Alternatively, the
two dimensional Modified READ (MR) method, which is much less frequently
used in historical TIFF-F implementations, may be selected by setting
bit 0 of the T4Options field to 1. The value of Bit 2 in this field is
determined by the use of fill bits.
Depending upon the application, the more efficient two-dimensional
Modified Modified Read (MMR)compression method from T.6 may be selected
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 29] 28]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+--------------------|--------------------------------------+
| Baseline Fields | Values |
+--------------------+--------------------------------------+
| BitsPerSample | 1: Binary RGB, CMY(K) |
| | 8: 8 bits per color sample |
| | 9-16: optional |
+--------------------+--------------------------------------+
| ColorMap | n: LAB color map |
+--------------------+--------------------------------------+
| Compression | 9: JBIG |
+--------------------+--------------------------------------+
| DateTime* | {ASCII}: date/time in
by setting the 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+--------------------+--------------------------------------+
| FillOrder | Applies only Compression field value to 1 bit/sample |
| | encodings |
| | 1: Most significant bit first |
| | 2: Least significant bit first |
+--------------------+--------------------------------------+
| ImageDescription* | {ASCII}: A string describing 4 and then setting the |
| | contents first
two bits (and all unused bits) of the image. |
+--------------------+--------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+--------------------+--------------------------------------+
| ImageLength | n: total number of scanlines T6Options field to 0. More
information to aid the implementer in image|
+--------------------+--------------------------------------+
| NewSubFileType | 2: Bit 1 identifies single page of making a |
| | multi-page document |
+--------------------+--------------------------------------+
| Orientation* | 1-8, Default 1 |
+--------------------+--------------------------------------+
| PhotometricInter- | 2: RGB |
| pretation | 5: CMYK |
| | 10: ITULAB |
+--------------------+--------------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+--------------------+--------------------------------------+
| RowsPerStrip | n: number of scanlines per TIFF strip|
+--------------------+--------------------------------------+
| SamplesPerPixel | 1: L* (lightness) |
| | 3: LAB, RGB, CMY |
| | 4: CMYK |
+--------------------+--------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+--------------------+--------------------------------------+
| StripByteCounts | <n>: number or bytes compression selection is
contained in Section 4.5.2.
Baseline TIFF strip |
+--------------------+--------------------------------------+
| StripOffsets | <n>: offset from beginning also permits use of file to|
| | each Compression=2 to specify Modified
Huffman compression, but the data is presented in a form that is not
byte aligned. As a result, TIFF-F uses Compression=3 instead of
Compression=2 to specify Modified Huffman compression.
4.4.5. Example Use of Page-quality Fields
Here are examples for writing the CleanFaxData, BadFaxLines, and
ConsecutiveBadFaxLines fields:
1. Facsimile hardware does not provide page quality
information: MUST NOT write page-quality fields.
2. Facsimile hardware provides page quality information, but
reports no bad lines. Write only BadFaxLines = 0.
3. Facsimile hardware provides page quality information, and
reports bad lines. Write both BadFaxLines and
ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or 2 if
the hardware's regeneration capability is known.
4. Source image data stream is error-corrected or otherwise
guaranteed to be error-free such as for a computer generated
file: SHOULD NOT write page-quality fields.
TIFF strip |
+--------------------+--------------------------------------+
McIntyre & Zilles Writers SHOULD only generate these fields when the image has been
generated from a fax image data stream where error correction, e.g.
Group 3 Error Correction Mode, was not used.
4.5. Implementation Warnings
4.5.1 Uncompressed data
TIFF-F requires the ability to read and write at least one-dimensional
T.4 Huffman ("compressed") data. Uncompressed data is not allowed.
This means that the "Uncompressed" bit in T4Options or T6Options must be
set to 0.
4.5.2. Encoding and Resolution
Since two-dimensional encoding is not required for Group 3
compatibility, some historic TIFF-F readers have not been able to read
such files. The minimum subset of TIFF-F REQUIRES support for one
dimensional (Modified Huffman) files, so this choice maximizes
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 30] 29]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+--------------------+--------------------------------------+
| XResolution | 100, 200, 300, 400 (written in |
| | pixels/inch) |
| YResolution | equal
portability. However, implementers seeking greater efficiency SHOULD
use T.6 MMR compression when writing TIFF-F files. Some TIFF-F readers
will also support two-dimensional Modified READ files. Implementers
that wish to XResolution (pixels must be |
| | square) |
+--------------------+--------------------------------------+
| Extension Fields |
+--------------------+--------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| |minimum and have the maximum values for L*a*b* |
+--------------------+--------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+--------------------+--------------------------------------+
| PageNumber | n,m: page number followed by total |
| | page count |
+--------------------+--------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+--------------------+--------------------------------------+
| New Fields |
+--------------------+--------------------------------------|
| GlobalParameters | <IFD>: global parameters IFD |
| IFD* | |
+--------------------+--------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+--------------------+--------------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode |
+--------------------+--------------------------------------+
| CodingMethods* | n:compression algorithms used flexibility in |
| | file |
+--------------------+--------------------------------------+
| VersionNumber* | n: version reading TIFF-F files SHOULD
support all three of ITU fax standard |
+--------------------+--------------------------------------+
| VersionYear* | byte sequence with year these compression methods (MH, MR and MMR).
For the case of ITU fax |
| | resolution, almost all facsimile products support both
standard |
+--------------------+--------------------------------------+
7. Mixed Raster Content Mode
7.1. Overview
Unlike previous fax modes, which use a single coding method and spatial (98 dpi) vertical resolution and "fine" (196 dpi) resolution.
Therefore, fine-resolution files are quite portable in the real world.
In 1993, the ITU-T added support for an entire fax page, higher resolutions in the Mixed Raster Content mode [MRC]
enables different coding methods and resolutions within a single page.
For example, consider a page that contains black-and-white text, which
is best coded with MMR or JBIG, a color bar chart, best coded with JBIG,
and a scanned color image, best coded with JPEG. Similarly, while
spatial resolution of T.30
recommendation including 200 x 200, 300 x 300, 400 pixels x 400 in dots per
inch may be best for based units. At the black-and-
white text, 200 pixel per inch is usually sufficient for a color image.
McIntyre & Zilles Expires 1/30/98 [Page 31]
Internet Draft File Format same time, support was added for Internet Fax July 30, 1997
Rather than applying one coding method and resolution metric
dimensions which are equivalent to all elements,
MRC allows multiple coders and resolutions within a page. By itself, MRC
does not define any new coding methods or resolutions. Instead it
defines a 3-layer model for structuring and combining the scanned image
data.
The ITU MRC document is currently a draft. However, its technical
content is stable, and editorial changes only are permitted between now following inch based resolutions:
391v x 203h and its scheduled approval in October 1997. Upon approval, 391v x 406h. Therefore, the MRC
document will become ITU-T Recommendation T.44.
7.1.1. MRC 3-layer model
The 3 layers full set of inch-based
equivalents of the MRC model are Foreground and Background, which new resolutions are
both multi-level, and Mask, which is bi-level. Each layer supported in the TIFF-F writer,
since they may appear
only once on a page in some image data streams received from Group 3
facsimile devices. However, many facsimile terminals and is coded independently older versions
of TIFF-F readers are likely to not support the other two. In our
earlier example, the black-and-white text could be in the Mask layer,
the color chart in the Foreground layer, and the color image in the
Background layer. The distribution use of content among layers these higher
resolutions.
Per [T.4], it is determined
by permissible for applications to treat the writer, following
XResolution values as is the choice of compression method, color encoding being equivalent: <204,200> and spatial resolution for <400,406>. In a layer.
The final image is obtained by using
similar respect, the Mask layer following YResolution values may also be treated as
being equivalent: <98, 100>, <196, 200>, and <391, 400>. These
equivalencies were allowed by [T.4] to select pixels
from the other two layers. When the Mask layer pixel value is 1, the
corresponding pixel from the Foreground layer is selected; when it is 0, permit conversions between inch
and metric based facsimile terminals.
In a similar respect, the corresponding pixel from optional support of metric based resolutions
in the Background layer TIFF-F reader (i.e. 77 x 38.5 cm) is selected. Details included for completeness,
since they are given used in Appendix 1 of [MRC].
Not all pages, and some legacy TIFF-F applications, but this use is
not all parts recommended for the creation of TIFF-F files by a page, require 3 layers. If there
is only one layer present, then writer.
4.5.3. EOL byte-aligned
The historical convention for TIFF-F has been that layer is the primary image and must
be page size. If there is more than one layer, then the Mask all EOLs in Modified
Huffman or Modified READ data must be one
of the layers, in which case it is byte-aligned. However, Baseline
TIFF has permitted use of non-byte-aligned EOLs by default, so that a
large percentage of TIFF-F reader implementations support both
conventions. Therefore, the primary image minimum subset of TIFF-F as defined in
this document includes support for both byte-aligned and must be page
size.
MRC allows a page non-byte-
aligned EOLs; see Section 3.2.2.
An EOL is said to be split into strips, with a variable number of
scanlines in a strip. A strip can byte-aligned when Fill bits have 1, 2 or 3 layers. A single,
stripped layer may be stored been added as
necessary before EOL codes such that EOL always ends on a single, stripped image in byte boundary,
thus ensuring an IFD,
e.g., all strips associated with the Background layer may be treated as
a single image. Alternatively, each strip associated with a layer may be
stored as a separate image or IFD, e.g., the Background layer can be
composed EOL-sequence of several images that are offset vertically with respect to
the page. In this case, there can be no overlap between images
associated with a single layer.
Furthermore, color fax also requires the spatial resolutions of
Background and Foreground images to be integer factors of the Mask image
resolution. For example, if the Mask Layer is 400 pixels per inch, then
the Background layer can be 100, 200 or 400 pixels per inch.
McIntyre & Zilles one byte preceded by a zero nibble:
xxxx0000 00000001.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 32] 30]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
7.1.2. A TIFF Representation for the MRC 3-layer model
In
Modified Huffman encoding encodes bits, not bytes. This means that the TIFF representation of
end-of-line token may end in the 3-layer MRC model, each page is
represented by middle of a single IFD, called the Primary IFD, byte. In byte alignment,
extra zero bits (Fill) are added so that represents the
Mask layer (unless first bit of data following
an EOL begins on a byte boundary. In effect, byte alignment relieves
application software of the Foreground or Background burden of bit- shifting every byte while
parsing scan lines for line-oriented image manipulation (such as writing
a TIFF file).
For Modified READ encoding, each line is the single layer
present), terminated by an EOL and a set of child IFDs that are referenced through one
bit tag bit. Per [T.4], the
SubIFDs extension field. The structure value of SubIFDs is described in
[TTN1]. To distinguish MRC-specific SubIFDs from other SubIFDs, the
NewSubFileType field will have Bit 4 ON, indicating an MRC-related IFD.
A new ImageLayer field tag bit is also introduced that consists of two values
which identify 0 if the layer (Foreground, Background, or Mask) next line
contains two dimensional data and 1 if the order
within next line is a reference
line. To maintain byte alignment, fill bits are added before the layer (first, second, ... image of
EOL/tag bit sequence, so that the layer); see Section
7.2.3.
Because MRC allows strips with variable numbers first bit of scanlines, data following an MR tag
bit begins on a new
StripRowCounts field is introduced to replace the RowsPerStrip field byte boundary.
4.5.4. EOL
As illustrated in
this mode. The StripRowCounts field allows each layer, FIGURE 1/T.4 in [T.4], facsimile documents encoded
with a variable
number of scanlines Modified Huffman begin with an EOL, which in each strip, to be represented by a single IFD.
Alternatively, each strip in the Foreground and Background layers can be
represented by a single IFD at the option TIFF-F is byte-
aligned. The last line of the writer. In all cases,
the Mask layer image is required to be represented not terminated by an EOL. In a single IFD.
The use of SubIFDs to store child IFDs is described in [TTN1]. An
example is shown graphically below. The Primary IFD associated
similar respect, images encoded with page
1 (PrimaryIFD 0) points to page 2 (PrimaryIFD 1) Modified READ two-dimensional
encoding begin with the nextIFD
offset. The Primary IFD, corresponding to the Mask layer
(ImageLayer=[2,1]), contains a SubIFDs field that points to an EOL, followed by a list of
child IFDs. The first child IFD represents one tag bit.
4.5.5. RTC Exclusion
Aside from EOLs, TIFF-F files have historically only contained image of the Background
layer, i.e., ImageLayer=[1,1]. This child IFD points to the second child
IFD via the nextIFD offset.
data. This child represents the second Background
layer image, ImageLayer=[1,2]. Finally, the second child points to the
third child, means that applications which corresponds wish to maintain strict
conformance with the single Foreground layer image,
ImageLayer=[3,1]. The next IFD offset associated rules in [TIFF] and compatibility with this Foreground
image is 0, indicating no more child IFDs exist. Each primary IFD has historical
TIFF-F, SHOULD NOT include the NewSubFileType set Return To Control sequence (RTC)
(consisting of 6 consecutive EOLs) when writing TIFF- F files.
However, applications which need to 18, indicating support "transparency" of [T.4]
image data MAY include RTCs if the IFD is MRC-specific (bit 4)
and that it is a single page flag settings of a multi-page document (bit 1). Each
child IFD has the NewSubFileType T4Options field
are set to 16, indicating the IFD is
MRC-specific. Note: the 'V' character for non-byte aligned MH or MR image data. Implementors of TIFF
readers should also be read aware that there are some existing TIFF-F
implementations which include the RTC sequence in MH/MR image data.
4.5.6 Use of EOFB for T.6 Compressed Images
TIFF-F pages which are encoded with the T.6 Modified Modified READ
compression method MUST include an "end-of-facsimile-block" (EOFB) code
at the end of each coded strip. Per [TIFF], the EOFB code is followed by
pad bits as needed to align on a down-pointing
arrow.
(nextIFD)
PRIMARY IFD 0 ------------> PRIMARY IFD 1--> ...
ImageLayer = [2,1]
NewSubFileType = 18
SubIFDs
|
V
Child IFD
ImageLayer = [1,1]
McIntyre & Zilles byte boundary. TIFF readers SHOULD
ignore any bits other than pad bits beyond the EOFB.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 33] 31]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
NewSubFileType = 16
|
|(nextIFD)
|
V
Child IFD
ImageLayer = [1,2]
NewSubFileType = 16
|
|(nextIFD)
|
V
Child IFD
ImageLayer = [3,1]
NewSubFileType = 16
|
|(nextIFD)
|
V
0
In the example above, the SubIFDs field
4.6. Example Use of the Primary IFD points to the
first IFD in a list TIFF-F
The application F of child IFDs. TIFF allows (i.e. TIFF-F content) is a secondary component
of the SubIFDs field to
point VPIM Message, as defined in [VPIM2]. Voice messaging systems can
often handle fax store-and-forward capabilities in addition to an array of IFDs, each of which
traditional voice message store-and-forward functions. As a result,
TIFF-F fax messages can optionally be sent between compliant VPIM
systems, and may be rejected if the first of a list recipient system cannot deal with
fax.
Refer to the VPIM Specification for proper usage of
IFDs. An MRC-enabled TIFF reader must scan all available child IFDs to
locate and identify IFDs associated this content.
4.7. Extended Black-and-white Fax Mode Summary
Recommended fields are shown with MRC layers.
In the case where the Background an asterisk *.
Required fields or Foreground layers values are described shown with
multiple IFDs, a double asterisk **. If the XPosition and YPosition TIFF fields specify
double asterisk is on the
offset to field name, then all the upper-left corner listed values are
required of implementations; if the IFD with respect to double asterisks are in the Mask
layer; see Section 7.2.2. When there is Values
column, then only a single layer (Mask,
Foreground, or Background), it is stored as the Primary IFD.
7.2. Required TIFF values suffixed with a double asterisk are
required of implementations.
+---------------------------+--------------------------------+
| Baseline Fields
This section describes the TIFF fields required, in addition to those | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 3**: 1D Modified Huffman and |
| | 2D Modified Read coding |
| | 4: 2D Modified Modified Read |
| | coding |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in
Section 2.2.1, to store MRC mode fax images. Since MRC mode stores 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
fax data as a collection of images corresponding to layers or parts contents of
layers, the compression mechanisms, color encodings and spatial
resolutions used by previous modes apply to MRC. Therefore, the
descriptions here will typically reference the appropriate earlier
section. Fields and values specific to MRC mode are pointed out.
7.2.1. Baseline Fields
ImageWidth(256). SHORT or LONG
Same page widths as the base color mode; see Section 5.2.1.
BitsPerSample(258) = 1, 8, 9-16 SHORT
Compression(259) = 3, 4, 7, 9. SHORT
SamplesPerPixel(277) = 1, 3, 4. SHORT
FillOrder(266) = 1, 2. SHORT
McIntyre & Zilles image. |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048, 2432, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 34] 32]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
PhotometricInterpretation(262) = 0, 1, 2, 5, 10. SHORT
For Mask layer, see Section 3.2.1.
For Foreground and Background layers, see Sections 5.2.1 and 6.2.1.
ColorMap(320). SHORT
Count = 3 * (2**BitsPerSample)
Used when Foreground or Background layer is a palette-color image;
see Section 6.2.1.
NewSubFileType(254) = 16, 18. LONG
For MRC fax mode, the NewSubFileType field has two bits that are
required.
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 indicates a identifies single |
| | page of a multi-page document and must be
set for the Primary IFDs;
Bit 4 indicates MRC imaging model as described in ITU-T
Recommendation Draft T.44 [MRC], and must be set for Primary IFDs
and all MRC-specific child IFDs.
StripRowCounts(559). LONG
Count = number of strips
The |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines stored in a strip. MRC allows each fax per |
| | TIFF strip
to store a different |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 1 |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of scanlines, up to a specified maximum
strip size, which is either 256 scanlines creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or the page length in
scanlines, depending on the implementation. This field replaces
RowsPerStrip for IFDs with variable-sized strips. Only one of the
two fields, StripRowCounts and RowsPerStrip, may be used bytes in an IFD.
XResolution(282). RATIONAL
YResolution(283). RATIONAL
The resolution TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution values are: 100, | 200, 204**, 300, and 400. MRC color fax mode requires the pixels to be square,
hence 400, 406 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution must equal XResolution.
7.2.2. | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields
ChromaSubSampling(530). SHORT
ChromaPositioning(531). SHORT
Decode(TagToBeAssigned). SHORT
For Foreground and Background layers, see Section 5.2.2.
Indexed(346) = 0, 1. SHORT
For Foreground and Background layers: 1 indicates a palette-color
image, see Section 6.2.2.
T4Options(292) = 0, 1, 4, 5. SHORT
T6Options(293) = 0. SHORT
For Mask layer, see Section 4.2.2.
McIntyre & Zilles Expires 1/30/98 [Page 35]
Internet Draft File Format for Internet Fax July 30, 1997
DefaultImageColor(TagToBeAssigned). SHORT or LONG
Count = SamplesPerPixel
In areas where no image data |
+---------------------------+--------------------------------+
| T4Options | 0**: required if Compression |
| | is available, a default color Modified Huffman, EOLs are |
| | not byte aligned |
| | 1: required if Compression is needed
to specify the color value. If the StripByteCounts value for a strip |
| | 2D Modified Read, EOLs are |
| | byte aligned |
| | 4**: required if Compression |
| | is 0, then the color for that strip must be defined by a default
image color.
The DefaultImageColor field uses the same encoding as the image
data, and its value Modified Huffman, EOLs are |
| | not byte aligned |
| | 5: required if Compression |
| | is therefore interpreted using the
PhotometricInterpretation, SamplesPerPixel, BitsPerSample, and
Indexed fields. If the fax data stream requires a different
encoding, then transferring the default color value between a TIFF
file and fax data stream requires a color conversion.
The default value 2D Modified Read, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 33]
Internet Draft File Format for the DefaultImageColor field Internet Fax October 10, 1997
+---------------------------+--------------------------------+
| T6Options | 0: required if Compression is white.
SubIFDs(330). IFD
Count = |
| | 2D Modified Modified Read |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| BadFaxLines* | number of child IFDs
Each value is an offset from the beginning of the TIFF file to a
child IFD [TTN1].
XPosition(286). RATIONAL
YPosition(287). RATIONAL
Specifies the horizontal and vertical offsets "bad" scanlines |
| | encountered during reception |
+---------------------------+--------------------------------+
| CleanFaxData* | 0: no "bad" lines |
| | 1: "bad" lines exist, but were |
| | regenerated by receiver |
| | 2: "bad" lines exist, but have |
| | not been regenerated |
+---------------------------+--------------------------------+
| ConsecutiveBadFaxLines* | Max number of the top-left consecutive |
| | "bad" lines received |
+---------------------------+--------------------------------+
5. Lossless JBIG Black-and-White Fax Mode
This section defines Application J of MIME Media Type image/tiff, which
is the
IFD from lossless JBIG black-and-white mode.
The previous section described the top-left extended interchange set of TIFF
fields for black-and-white fax, which provided support for the Primary IFD in page resolution units.
For example, if the Primary IFD is at 400 pixels per inch, MH, MR
and MMR compression of black-and-white images. This section adds a
foreground layer IFD is at 200 pixels per inch and located at pixel
coordinate (345, 678) mode
with respect to the Primary IFD, JBIG compression capability.
5.1. Overview
This section describes a black-and-white mode that uses JBIG
compression. The ITU-T has approved the XPosition
value single-progression sequential
mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers improved
compression for halftoned originals. JBIG compression is 345/400 and used in
accordance with the YPosition value application rules given in ITU-T Rec. T.85 [T.85].
This mode is 678/400.
Color fax does not currently allow overlap essentially the extended black-and-white mode with JBIG
compression used instead of any component images
within a single layer.
Default values for XPosition and YPosition are 0.
7.2.3. New Fields
The Mixed Raster Content mode requires one new field: ImageLayer.
ImageLayer (34732). SHORT MH, MR or LONG.
Count = 2
Image layers are defined such that layer 1 is the Background layer,
layer 3 is the Foreground layer, and layer 2 is the Mask layer that
selects pixels from the Background and Foreground layers. The
ImageLayer tag contains two values, describing the layer to which
the image belongs and the order in which it is imaged.
ImageLayer[0]: 1, 2, 3.
1: Image is a Background image, i.e., the image that will appear
whenever the Mask contains a value of 0. Background images
typically contain low-resolution, continuous-tone imagery.
2: Image is the Mask layer. In MRC, if the Mask layer is present, it
must be the Primary IFD and be full page in extent (no gaps.)
McIntyre & Zilles MMR.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 36] 34]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
3: Image is a Foreground image, i.e., the image that will appear
whenever
5.2. Required TIFF Fields
This section lists the Mask contains a value of 1. The Foreground image
generally defines required fields and the color of text or lines, but may also
contain high-resolution imagery.
ImageLayer[1]:
1: first image values they must have to
be imaged ITU-compatible. Besides the fields listed in this layer (e.g., first Section 2.2.1, the
extended black-and-white fax strip),
2: second image to mode requires the following fields.
5.2.1. Baseline fields
The TIFF fields that SHALL be imaged used in this layer (e.g., second fax strip),
3: ...
Value describing mode are the image order. In MRC, this may be considered the
strip number. Since MRC mode currently does not allow overlap
between images within a layer, same as those
described in Section 4.2.1 for the order value does not have any
visual effect.
In MRC fax extended black-and-white mode, it is possible that only a single layer is transmitted.
For example, if a page contains only a single continuous-tone
photograph, then only with
one exception: the Background layer may be transmitted. In this
case, following text is used for the Background layer will be full page and stored as Compression field in
place of the Primary
IFD. ImageLayer[0] will be 1 indicating Background; ImageLayer[1] will
be Compression field text given in Section. 4.2.1.
Compression(259) = 9. SHORT
RequiredByTIFFBaseline
9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG). This is
a TIFF extension value.
Default = 1 since the layer (and is not applicable; field must be full page and there can be no other IFDs
associated with that layer. No Mask layer will exist.
7.3. specified).
5.2.2. Extension fields
None beyond those listed in Section 2.2.1.
5.2.3. New fields
None.
5.3. Recommended TIFF Fields
See Sections 2.2.3. Section 2.2.3 and 2.2.4.
7.4. Rules and Requirements for Images
The MRC mode defines
5.4. Lossless JBIG Black-and-white Fax Mode Summary
Recommended fields are shown with an asterisk *.
Required fields or values are shown with a fundamental set of rules for images in the
3-layer representation.
1. double asterisk **. If more than one layer exists, then the binary Mask layer must be
present and it
double asterisk is on the primary image. If only one layer exists, field name, then all the image corresponding to that layer is the primary image.
2. The Primary image defines and extends to the entire page boundary;
all attached model images cannot extend beyond the Primary image.
Resolution differences may cause some pixels to "hang over" the page
boundary, but no new pixels should exist completely beyond the page
extent
3. The Background and Foreground images may use any color encoding
defined in Sections 5 and 6, and may optionally cover only a portion
of the region defined by the Primary image, unless one listed values are
required of them is implementations; if the
primary image.
4. Each Primary IFD and each MRC-specific SubIFD must have an ImageLayer
field to specify which layer double asterisks are in the IFD belongs to, and Values
column, then only the imaging
order values suffixed with a double asterisk are
required of that IFD within the layer.
McIntyre & Zilles implementations.
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 9**: JBIG coding |
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 37] 35]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
5. Each Primary IFD must have a NewSubFileType field value set to 18,
indicating a single page of a multi-page document (bit 1) and MRC
mode (bit 4).
6. Each MRC-specific child IFD must have a NewSubFileType field value
set to 16, indicating MRC mode (bit 4).
7. In MRC mode, each layer is transmitted as a sequence of strips. It is
possible that each strip of each layer can be stored as a separate
IFD. In this case, the SubIFDs structure pointed to by the Primary
IFD will contain several IFDs that have an ImageLayer field with the
layer identified as either Background (layer 1) or Foreground (layer
3). There may be no overlap in the vertical direction between IFDs
associated with a single layer, although there may be a gap from one
of these images to the next. The TIFF XPosition and YPosition fields
are used to indicate the placement of these images with respect to
the primary image.
8. The resolution of Background and Foreground images must each be an
integer factor
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 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 Primary image. For example, if the Primary
image is 400 pixels/inch, then the model images may be at 400
pixels/inch (400 / 1), 200 pixels/inch (400 / 2), 100 pixels/inch
(400 / 4), etc.
7.5. MRC Fax Mode Summary
Recommended fields are shown with an asterisk *
+------------------+-----------------------------------------+ | Baseline Fields
+---------------------------+--------------------------------+
| Values ImageWidth** |
|------------------|-----------------------------------------| 1728, 2048, 2432, 2592, | BitsPerSample
| 1: binary mask | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| 8: 8 bits per color sample ImageLength** | n: total number of scanlines |
| 9-16: optional 12 bits/sample |
+------------------+-----------------------------------------+ in image | ColorMap
+---------------------------+--------------------------------+
| n: LAB color map NewSubFileType** |
+------------------+-----------------------------------------+ 2: Bit 1 identifies single | Compression
| 3: Modified Huffman and Modified Read | page of a multi-page document |
+---------------------------+--------------------------------+
| 4: Modified Modified Read Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| 7: JPEG PhotometricInterpretation | 0: pixel value 1 means black |
| 9: JBIG |
+------------------+-----------------------------------------+
| DateTime* | {ASCII): date/time in the 24-hour format|
| | "YYYY:MM:DD HH:MM:SS" |
+------------------+-----------------------------------------|
| FillOrder | Applies only to 1 bit/sample encodings |
| ** | 1: Most significant bit first |
| | 2: Least significant bit first |
+------------------+-----------------------------------------+
McIntyre & Zilles Expires 1/30/98 [Page 38]
Internet Draft File Format for Internet Fax July 30, 1997
+------------------+-----------------------------------------|
| 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 |
+------------------+-----------------------------------------|
| 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 pixel value 1 means white |
+------------------+-----------------------------------------+
| PhotometricInter | 0: WhiteIsZero |
| pretation | 1: BlackIsZero |
| | 2: RGB |
| | 5: CMYK |
| | 10: ITULAB |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| ResolutionUnit ResolutionUnit** | 2: inch |
| | 3: centimeter |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| RowsPerStrip RowsPerStrip** | n: number of scanlines in each strip |
+------------------+-----------------------------------------+
| SamplesPerPixel | 1: L* (lightness) per |
| | 3: RGB, LAB, CMY TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 4: CMYK 1 |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release number of |
| | number of creator software |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| StripByteCounts StripByteCounts** | <n>: number or bytes in TIFF |
| | strip |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| StripOffsets StripOffsets** | <n>: offset from beginning of file to |
| | file to each TIFF strip |
+------------------+-----------------------------------------|
+---------------------------+--------------------------------+
| XResolution | 100, 200, 204**, 300, 400 (written in 400, 406 |
| | (written in pixels/inch) |
+------------------+-----------------------------------------|
+---------------------------+--------------------------------+
| YResolution | equal to XResolution (pixels must be 98**, 196**, 100, |
| | square) 200, 300, 391, 400 |
+------------------+-----------------------------------------+
| Extension Fields |
+------------------+-----------------------------------------+
McIntyre & Zilles (written in pixels/inch) |
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 39] 36]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+------------------+-----------------------------------------+
| T4Options | 0: required if Compression is |
| | Modified Huffman, no fill bits |
| | 1: required if Compression is 2D |
| | Modified Read, no fill bits |
| | 4: required if Compression is Modified |
| | Huffman, fill bits |
| | 5: required if Compression is 2D |
| | Modified Read, fill bits |
+------------------+-----------------------------------------+
| T6Options | 0: required if Compression is 2D |
|
+---------------------------+--------------------------------+
| Modified Modified Read Extension Fields |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+------------------+-----------------------------------------+
+---------------------------+--------------------------------+
| PageNumber PageNumber** | n,m: page number followed by total page |
| | total page count |
+------------------+-----------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
+---------------------------+--------------------------------+
| New Fields | minimum and maximum values for L*a*b*
+---------------------------+--------------------------------+
|
+------------------+-----------------------------------------+ GlobalParametersIFD* | ChromaSubSampling| ChromaSubsampleHoriz: <IFD>: global parameters IFD |
+---------------------------+--------------------------------+
| ProfileType* | 0: equal numbers n: type of lightness and chroma|
| | samples |
| | 1: twice as many lightness samples as |
| data stored in | chroma samples
| | TIFF file | 2: four times as many lightness samples
+---------------------------+--------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode | as chroma samples
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used | ChromaSubsampleVert:
| | in file | 0: equal numbers
+---------------------------+--------------------------------+
6. Base Color Fax Mode
6.1. Overview
This section defines Application C of lightness MIME media type image/tiff.
This is the base mode for color and chroma|
| | samples |
| | 1: twice as many lightness samples as |
| | chroma samples |
| | 2: four times as many lightness samples |
| | as chroma samples |
+------------------+-----------------------------------------+
| ChromaPositioning| 1: centered |
| | 2: cosited |
+------------------+-----------------------------------------+
| DefaultImageColor| <n>: background grayscale facsimile, which means
that all applications that support color |
+------------------+-----------------------------------------+
| Indexed | 0: not fax must support this mode. The
basic approach is the lossy JPEG compression [T.81] of L*a*b* color data
[T.42]. Grayscale applications use the L* lightness component; color
applications use the L*, a* and b* components.
This mode uses a palette-color image |
| | 1: palette-color image |
+------------------+-----------------------------------------+
| SubIFDs | <IFD>: byte offset new PhotometricInterpretation field value to fg/bg IFDs |
+------------------+-----------------------------------------+
| XPosition | horizontal offset describe
the L*a*b* encoding specified in primary IFD |
| | coordinates |
+------------------+-----------------------------------------+
| YPosition | vertical offset [T.42]. This encoding differs in primary IFD |
| | coordinates |
+------------------+-----------------------------------------+
McIntyre & Zilles two
ways from the other L*a*b* encodings used in TIFF [TIFF, TTN1]: it
specifies a different default range for the a* and b* components, based
on a comprehensive evaluation of existing hardcopy output, and it
optionally allows selectable range for the L*, a* and b* components.
6.2. Required TIFF Fields
This section lists the required fields, in addition to those given in
Section 2.2.1, and the values they must support to be compatible with
ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 40] 37]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+------------------+-----------------------------------------+
| New
6.2.1. Baseline Fields |
+------------------+-----------------------------------------+
| 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 |
+------------------+-----------------------------------------+
| ITUFaxMode* | n: ITU-compatible
ImageWidth(256). SHORT or LONG
This mode supports the following fixed page widths: 864, 1024, 1216,
1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.
BitsPerSample(258) = 8, 12. SHORT
Count = SamplesPerPixel
The base color fax mode |
+------------------+-----------------------------------------+
| CodingMethods* | n: requires 8 bits per sample, with 12 as an
option. 12 bits per sample is not baseline TIFF.
Compression(259) = 7. SHORT
Base color fax mode uses Baseline JPEG compression. Value 7
represents JPEG compression algorithms used as specified in file |
+------------------+-----------------------------------------+
| VersionNumber* | n: version of ITU fax standard |
+------------------+-----------------------------------------+
| VersionYear* | byte sequence with year of ITU [TTN2].
PhotometricInterpretation(262) = 10. SHORT
Base color fax |
| | standard |
+------------------+-----------------------------------------+
8. MIME sub-type
The draft proposes to redefine the image/tiff sub-type to correspond mode requires pixel values to be stored using the current TIFF specification, Revision 6.0, dated June 3, 1992, with
the addition of the new fields CIE
L*a*b* encoding defined here. Further, an optional
application parameter in ITU-T Rec. T.42. This encoding is proposed that would distinguish subsets of
indicated by the
image/tiff subtype corresponding PhotometricInterpretation value 10, referred to as
ITULAB. With this encoding, the TIFF representation of minimum sample value is
mapped to 0 and the fax
modes defined in this document.
9. IANA Registration
To: ietf-types@iana.org
Subject: Registration of Standard
MIME media type image/tiff
MIME media type name: image
MIME subtype name: tiff
Required parameters: none
Optional parameters: application
The maximum sample value of is mapped to (2^n - 1),
i.e. the application parameter of image/tiff maximum value, where n is denoted by a
single letter. Six the BitsPerSample value.
The conversion from unsigned ITULAB-encoded samples values to signed
CIE L*a*b* values is determined by the Decode field; see Sec. 6.2.2
Note: PhotometricInterpretation values 8 and 9 specify encodings for
CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1], but they are proposed.
McIntyre & Zilles fixed
encodings, which use different minimum and maximum samples than the
T.42 default encoding. As currently defined, they are not able to
represent fax-encoded L*a*b* data.
SamplesPerPixel(277) = 1, 3. SHORT
1: L* component only
3: L*, a*, b* components
Encoded according to PhotometricInterpretation field
XResolution(282) = 100, 200, 300, 400. RATIONAL
YResolution(283) = 100, 200, 300, 400. RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values are: 100, 200,
300, and 400. The base color fax mode requires the pixels to be
square, hence YResolution must equal XResolution. Base resolution is
200 pixels per inch and SHALL be supported by all implementations of
this mode.
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].
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 41] 38]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
B - minimal black-and-white fax mode (defined in Section 3).
F - extended black-and-white fax mode (defined in Section 4,
excluding Compression=9)
J - extended black-and-white fax mode (defined in Section 4,
including Compression=9)
C - lossy color mode (defined in Section 5)
P - lossless color mode (defined in Section 6)
M - Mixed Raster Content mode (defined in Section 7)
There is no default value for application, and in the absence of the
application parameter, the user should assume baseline TIFF.
Encoding considerations: binary or base64 generally preferred
Security considerations:
+--------------------------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------------------------+---------------------------+
| 100 x 100 | 864 | 1024 | 1216 |
+--------------------------------+---------------------------+
| 200 x 200 | 1728 | 2048 | 2432 |
+--------------------------------+---------------------------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------------------------+---------------------------+
| 400 x 400 | 3456 | 4096 | 4864 |
+--------------------------------+---------------------------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------------------------+
| Paper Size |
+---------------------------+
6.2.2 Extension Fields
The security issues associated with this type
have not been assessed.
Interoperability considerations: These application parameter values JPEG compression standard allows for
image/tiff the a*b* chroma components of
an image to be subsampled relative to the L* lightness component. The
extension fields ChromaSubSampling and ChromaPositioning define the
subsampling. They are intended for interoperability between ITU the same as YCbCrSubSampling and Internet
fax data formats.
Published specification: TIFF Revision 6.0 is available at: ftp://
ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/tiff6.pdf,
http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFF6.pdf
Person & e-mail address to contact for further information:
Lloyd McIntyre: lmcintyre@adoc.xerox.com
Steve Zilles: szilles@adobe.com
Intended usage: Common
10. Security Considerations
Security issues YCbCrPositioning
in [TIFF], but have not been assessed in this document.
11. References
[MRC] TD1018, "Revision of D25, forming renamed to reflect their applicability to other
color spaces.
ChromaSubSampling(530). SHORT
Count = 2
Specifies the basis for Draft Rec. T.44
(MRC-Colour)", ITU-T Study Group 8, February 1997 currently available at
http://www.xerox.com/xis/mrc/
[RFC1314] Katz, A., and Cohen, D., "A File Format subsampling factors for the Exchange of
Images in the Internet", RFC 1314, USC Information Sciences Institute,
April 1992
McIntyre & Zilles Expires 1/30/98 [Page 42]
Internet Draft File Format for Internet Fax July 30, 1997
[RFC1528] Malamud, C., and Rose, M., Principles of Operation for the
TPC.INT Subdomain: Remote Printing -- Technical Procedures, RFC 1528,
October 1993; also Rose, M., Registration chroma components of new MIME content-
type/subtype, July 31, 1993, ftp://ftp.isi.edu/in-notes/iana/
assignments/media-types/image/tiff
[T.4] ITU-T Recommendation T.4, Standardization a
L*a*b* image. The two subfields of group 3 facsimile
apparatus for document transmission, July 1996
[T.6] ITU-T Recommendation T.6, Facsimile coding schemes this field, ChromaSubsampleHoriz
and coding
control functions for group 4 facsimile apparatus, November 1988
[T.42] ITU-T Recommendation T.42, Continuous-tone colour representation
method for facsimile, February 1996
[T.43] ITU-T Recommendation T.43, Colour and gray-scale image
representations using lossless coding scheme for facsimile, February
1997
[T.81] ITU-T Recommendation T.81, Information technology - Digital
compression ChromaSubsampleVert, specify the horizontal and coding vertical
subsampling factors respectively.
SHORT 0: ChromaSubsampleHoriz = 1, 2, 4.
1: equal numbers of continuous-tone still images - Requirements lightness and guidelines, September 1992
[T.82] ITU-T Recommendation T.82, Information technology - Coded
representation chroma samples horizontally,
2: twice as many lightness samples as chroma samples horizontally,
4: four times as many lightness samples as chroma samples
horizontally.
SHORT 1: ChromaSubsampleVert = 1, 2, 4.
1: equal numbers of picture lightness and audio information - Progressive bi-level
image compression, March 1995
[T.85] ITU-T Recommendation T.85, Application profile chroma samples vertically,
2: twice as many lightness samples as chroma samples vertically,
4: four times as many lightness samples as chroma samples
vertically.
The default value for Recommendation
T.82 - Progressive bi-level image compression (JBIG coding scheme) ChromaSubSampling is (2,2), which is the
default for
facsimile apparatus, August 1995
[TIFF] Tag Image File Format, Revision 6.0, Adobe Developers
Association, June 3, 1992, ftp://ftp.adobe.com/pub/adobe/devrelations/
devtechnotes/pdffiles/tiff6.pdf
[TIFF-F] work chroma subsampling in progress, Tag Image color fax [T.42]. No chroma
subsampling, i.e. ChromaSubSampling = (1,1), is a T.42 option.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 39]
Internet Draft File Format (TIFF) - Class F, May
30, 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-tiff-02.txt
[TIFF-F0] for Internet Fax October 10, 1997
ChromaPositioning(531) = 1, 2. SHORT
Specifies the spatial positioning of chroma components relative to
the lightness component. See the current TIFF Class F specification, Apr 28, 1990,
ftp://ftp.faximum.com/pub/documents/tiff_f.txt
[TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995,
http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf
[TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG specification,
March 17, 1995, ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt
The ITU-T Recommendations are available at http://www.itu.ch.
[MRC] is currently available at http://www.xerox.com/xis/mrc/
McIntyre & Zilles Expires 1/30/98 [Page 43]
Internet Draft File Format specification under
YCbCrPositioning for Internet Fax July 30, 1997
12. Authors' Addresses
Lloyd McIntyre
Xerox Corporation
Mailstop PAHV-305
3400 Hillview Ave.
Palo Alto, CA 94304 USA
Voice: +1-415-813-6762 Fax: +1-415-813-6792
Email: lmcintyre@adoc.xerox.com
Stephen Zilles
Adobe Systems Inc.
Mailstop W14
345 Park Avenue
San Jose, CA 95110-2704
Voice: +1-408-536-4766
Fax: +1-408-536-4042
Email: szilles@adobe.com
Appendix A: Summary further information.
1: centered,
2: cosited.
Default = 1, which is what ITU-T T.4, Annex E specifies.
Decode(TagToBeAssigned). SHORT
Count = 2 * SamplesPerPixel
Describes how to map image sample values into the range of TIFF Fields values
appropriate for Internet Fax
This annex includes tables which list by mode the TIFF fields used in current color space. In general, the proposed fax file format. The fields values are organized into 3
categories:
1) TIFF Baseline Fields
2) TIFF Extension Fields
3) New Fields.
The tables include
taken in pairs and specify the allowed values minimum and maximum output value for
each color component. For the base color fax mode.
Entries other than explicit numbers are described by:
n - single number
n, m - 2 numbers
a, b, c - 3 numbers
r - rational number
<n> - array of numbers
<b> - byte sequence
{ASCII} - string
<IFD> - array of IFD byte offsets
A blank entry in mode, Decode maps the table indicates
ITULAB encoding to L*a*b* and has a count of 6 values. In this case,
the field input is not used by that
particular fax mode.
McIntyre & Zilles Expires 1/30/98 [Page 44]
Internet Draft File Format an unsigned ITULAB-encoded value (Lsample, asample,
(bsample) and the output is a signed L*a*b* value.
L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)
where Decode[0] is the minimum value for Internet Fax July 30, 1997
Table A.1 TIFF Baseline Fields
+----------------------------------------------------------+ L*, Decode[1] is the
maximum value, etc. and n is the BitsPerSample field value, either 8
or 12. ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a
range and offset for each component, which are related to the Decode
field values as follows:
Decode[0] = - (Lrange x Loffset) / 2^n
Decode[1] = Decode[0] + Lrange
NOTE: The following table gives the default range and offsets, as
specified in ITU-T Rec. T.42, and the corresponding minimum and maximum
L*a*b* component and ITULAB encoded values.
+-----------------------------------------------------------+
| Fax Mode Component |
+----------+----------------------------------------------------------| Rec. T.42 | Field L*a*b* | B&W ITULAB | B&W
| Color | Color defaults | Mixed Raster| values | encoding | Minimal
+-----------+------------------+------------+---------------+
| Extended | Lossy Range | Lossless Offset | Content Min |
+----------+---------------------+----------+-----------+-------------+ Max | BitsPer Min | Max |
+-----------+--------+---------+------+-----+-----+---------+
| L* | 100 | 0 | 0 | Sample 100 | 1 0 | 2^n - 1 | 8, 12 | 1, 8, 9-16| 1, 8, 9-16 |
+----------+---------------------+----------+-----------|-------------|
| ColorMap | |
+-----------+--------+---------+------+-----+-----+---------+
| a* | <n> 170 | <n> 128 |
+----------+---------------------+----------+-----------|-------------| -85 | Compres- 85 | 0 | 2^n - 1 |
+-----------+--------+---------+------+-----+-----+---------+
| b* | 200 | 96 | sion -75 | 3 125 | 3, 4 0 | 7 | 9 2^n - 1 |
+-----------+--------+---------+------+-----+-----+---------+
The default value for Decode is (0, 100, -85, 85, -75, 125), which is
based on the ITULAB encoding, with PhotometricInterpretation 10,
SamplesPerPixel 3, 4, 7, 9 |
+----------+---------------------+----------+-----------+-------------+
| DateTime and BitsPerSample 8.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 40]
Internet Draft File Format for Internet Fax October 10, 1997
6.2.3. New Fields
None.
6.3. Recommended TIFF Fields
See Sections 2.2.3. and 2.2.4.
6.4 Base Color Fax Mode 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.
+---------------------------+--------------------------------+
| {ASCII} Baseline Fields | {ASCII} Values | {ASCII}
+---------------------------+--------------------------------+
| {ASCII} |{ASCII} BitsPerSample |
+----------+---------------------+--------- +-----------|-------------| 8**: 8 bits per color sample | FillOrder| 1, 2
| 1, 2 | 12: optional 12 bits/sample | 1, 2
+---------------------------+--------------------------------+
| 1, 2 Compression** |
+----------+---------------------+----------+-----------+-------------+ 7: JPEG | ImageDes-| {ASCII}
+---------------------------+--------------------------------+
| {ASCII} DateTime* | {ASCII} {ASCII}: date/time in 24-hour | {ASCII}
| {ASCII} | format "YYYY:MM:DD HH:MM:SS" | cription
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image. |
+----------+---------------------+----------+-----------+-------------|
+---------------------------+--------------------------------+
| Image- ImageWidth | 1728, |1728, 2048 |864, 1024 |864, 1024 |864, 1024 864, 1024, 1216, 1728**, 2048**|
| | Width 2432**, 2592, 3072, 3456, 3648 | 2048, |2432, 2592 |1216, 1728|1216, 1728 |1216, 1728
| | 4096, 4864 | 2432 |3072, 3456 |2048, 2432|2048, 2432 |2048, 2432
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines | |3648, 4096 |2592, 3072|2592, 3072 |2592, 3072
| | in image | |4864 |3456, 3648|3456, 3648 |3456, 3648
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single page|
| | |4096, 4864|4096, 4864 |4096, 4864 of a multi-page document |
+----------+---------------------+----------+-----------+-------------+
+---------------------------+--------------------------------+
| Image- Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 10**: ITULAB |
+---------------------------+--------------------------------+
| ResolutionUnit** | Length 2: inch | n
| n | n 3: centimeter | n | n |
+----------+---------------------+----------+-----------+-------------+
| NewSub- | | | | | |
| FileType | 2 | 2
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 41]
Internet Draft File Format for Internet Fax October 10, 1997
+---------------------------+--------------------------------+
| 2 RowsPerStrip** | 2 n: number of scanlines per | 16, 18
|
+----------+---------------------+----------+-----------+-------------+ | Orien- TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 1: L* (lightness) |
| | 3: LAB | tation
+---------------------------+--------------------------------+
| 1 Software* | 1 {ASCII}: name & release number | 1 |1
| 1 |
+----------+---------------------+----------+-----------+-------------+ of creator software | Photo-
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or bytes in |
| | TIFF strip |
+---------------------------+--------------------------------+
| metric- StripOffsets** | <n>: offset from beginning |
| | of file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | Interp- 100, 200**, 300, 400 (written |
| | in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 100, 200**, 300, 400 | retation
| 0, 1 | 0, 1 (must equal XResolution) | 10
+---------------------------+--------------------------------+
| 2, 5, 10 Extension Fields | 0,1,2,5,10
+---------------------------+--------------------------------+
|
+----------+---------------------+----------+-----------+-------------+ DocumentName* | Resolu- {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by | tionUnit
| 2, 3 | 2, 3 total page count | 2, 3
+---------------------------+--------------------------------+
| 2, 3 Decode** | 2, 3 minL, maxL, mina, maxa, minb, |
+----------+---------------------+----------+-----------+-------------+
| RowsPer- | maxb: minimum and maximum |
| | values for L*a*b* |
+---------------------------+--------------------------------+
| ChromaSubSampling | Strip ChromaSubsampleHoriz: | n
| n | n 1: equal numbers of lightness | n
| |
+----------+---------------------+----------+-----------+-------------+
McIntyre & Zilles Expires 1/30/98 [Page 45]
Internet Draft File Format for Internet Fax July 30, 1997
+----------+---------------------+----------+-----------+-------------+ and chroma samples | Samples-
| | 2**: twice as many lightness |
| | samples as chroma samples |
| PerPixel | 1 4: four times as many | 1
| 1, 3 | 1, 3, 4 lightness samples as chroma | 1, 3, 4
|
+----------+---------------------+----------+-----------+-------------+ | Software samples | {ASCII}
| {ASCII} | {ASCII} ChromaSubsampleVert: | {ASCII}
| {ASCII} |
+----------+---------------------+----------+-----------+-------------+ 1: equal numbers of lightness | Strip-
| | and chroma samples |
| | 2**: twice as many lightness |
| Byte- | samples as chroma samples |
| | 4: four times as many lightness|
| | samples as chroma samples | Counts | <n> | <n> | <n> | <n> | <n> |
+----------+---------------------+----------+-----------+-------------+
| Strip- | | | | | |
| Offsets | <n> | <n> | <n> | <n> | <n> |
+----------+---------------------+----------+-----------+-------------+
| XResolu- | 204 | 200, 204, | 100, 200,| 100, 200, | 100, 200, |
| tion | | 300, 400, | 300, 400 | 300, 400 | 300, 400 |
| | | 406 | | | |
+----------+---------------------+----------+-----------+-------------+
| YResolu-
+---------------------------+--------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 42]
Internet Draft File Format for Internet Fax October 10, 1997
+---------------------------+--------------------------------+
| 98, 196 ChromaPositioning | 98, 196, 1**: centered | 100, 200,| 100, 200,
| 100, 200, | 2: cosited | tion
+---------------------------+--------------------------------+
| New Fields | 100, 200,
+---------------------------+--------------------------------+
| 300, 400 GlobalParametersIFD* | 300, 400 <IFD>: IFD containing | 300, 400
| | global parameters |
+---------------------------+--------------------------------+
| 300, 392, ProfileType* | n: type of data stored in |
| | TIFF file |
+---------------------------+--------------------------------+
| ITUFaxMode* | 400 n: ITU-compatible fax mode |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms |
+----------+---------------------+----------+-----------+-------------+
Table A.2 TIFF Extension Fields
+---------------------------------------------------------+
| Fax Mode |
+-----------+---------------------------------------------------------| used in file | Field
+---------------------------+--------------------------------+
| B&W VersionYear* | B&W byte sequence: year of ITU std |
+---------------------------+--------------------------------+
7. Lossless Color | Mode
This section defines Application P of MIME media type image/tiff.
7.1. Overview
This mode, defined in [T.43], uses JBIG to losslessly code three types
of color and grayscale images: one bit per color CMY, CMYK and RGB
images; a palettized (i.e. mapped) color image; and continuous tone
color and grayscale images. The last two are multi-level and use the
L*a*b* encoding specified in [T.42].
7.1.1. Color |Mixed Raster|
| | Minimal| Extended | Lossy | Lossless | Content |
+-----------+--------+-----------+----------+----- ------+------------+
| T4Options | 4, 5 | 0, 1, 4, 5| | | 0, 1, 4, 5 |
+-----------+--------+-----------+----------+------------+------------+
| T6Options | | 0 | | | 0 |
+-----------+--------+-----------+----------+------------+------------+
| Document- | | | | | |
| Name | {ASCII}| {ASCII} | {ASCII} | {ASCII} | {ASCII} |
+-----------+--------+-----------+----------+------------+------------+
| Page- | | | | | |
| Number | n, m | n, m | n, m | n, m | n, m |
+-----------+--------+-----------+----------+------------+------------+
| XPosition | | | | | r |
+-----------+--------+-----------+----------+------------+------------+
| YPosition | | | | | r |
+-----------+--------+-----------+----------+------------+------------+
| SubIFDs | | | | | <IFD> |
+-----------+--------+-----------+----------+------------+------------+
| Encoding
While under development, this mode was called T.Palette, as one of its
major additions was palette or mapped color images. Baseline TIFF only
allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* color maps,
using the encoding specified in ITU-T Rec. T.42. Palette color images
are expressed with indices (bits per sample) of 12 bits or less, or
optionally 13 to 16 bits, per {T.43].
Enabling T.43 color maps in TIFF requires the extension field Indexed,
defined in [TTN1], and the PhotometricInterpretation field value 10,
defined in Section 6.2.1. The following table shows the corresponding
PhotometricInterpretation, SamplesPerPixel, BitsPerSample and Indexed | | | | 0, 1 | 0, 1 |
+-----------+--------+-----------+----------+------------+------------+
McIntyre & Zilles
field values for the different T.43 image types.
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 46] 43]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
+-----------+--------+-----------+----------+------------+------------+
+----------------------------------------------------------+
| Chroma- Image Type |PhotometricIn| Samples | Bits Per | Indexed |
| |-terpretation| PerPixel | Sample | | SubSampl-
|------------+-------------+----------+----------+---------|
| RGB | 2=RGB | 3 | 1 | 0 |
+----------------------------------------------------------+
| ing CMY | 5=CMYK | 3 | n, m 1 | 0 | n, m
+------------+-------------+----------+----------+---------+
|
+-----------+--------+-----------+----------+------------+------------+ CMYK | Chroma- 5=CMYK | 4 | 1 | 0 |
+------------+-------------+----------+----------+---------+
| Palette | 10=ITULAB | Position- 1 | n | 1 |
+------------+-------------+----------+----------+---------+
| Grayscale | 10=ITULAB | 1 | ing | | | 1, 2 | | 1,2 |
+-----------+--------+-----------+----------+------------+------------+
| Decode | | | <n> | <n> | <n> |
+-----------+--------+-----------+----------+------------+------------+
| Default- | | | | | |
| ImageColor| | | | | <n> |
+-----------+--------+-----------+----------+------------+------------+
| Strip- | | | | | 8, 12 | 0 | RowCounts
+------------+-------------+----------+----------+---------+
| Color | 10=ITULAB | 3 | 8, 12 | <n> 0 |
+-----------+--------+-----------+----------+------------+------------+
Table A.3 New
+------------+-------------+----------+----------+---------+
7.1.2. JBIG Encoding
T.43 uses the single-progression sequential mode of JBIG, defined in
ITU-T Rec. T.82, in accordance with the application rules described in
ITU-T Rec. T.85. To code multi-level images using JBIG, which is a
bi-level compression method, an image is resolved into a set of
bit-planes using Gray code conversion, and each bit-plane is then JBIG
compressed. The Gray code conversion is part of the data stream
encoding, and is therefore invisible to TIFF.
7.2. Required TIFF Fields
+---------------------------------------------------------+
|
This section lists the required fields, in addition to those in Section
2.2.1, and the values they must have to be compatible with ITU-T Rec.
T.43.
7.2.1. Baseline Fields
ImageWidth(256). SHORT or LONG
Same page widths as the base color mode; see Section 6.2.1.
BitsPerSample(258) = 1, 8, 9-16. SHORT
Count = SamplesPerPixel
RGB, CMY, CMYK: 1 bit per sample
Continuous tone (L*a*b*): 8 bits per sample, 12 bits optional
Palette color: 12 or fewer bits per sample, 13-16 bits optional
Note: More than 8 bits per sample is not baseline TIFF.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 44]
Internet Draft File Format for Internet Fax Mode |
+-----------+---------------------------------------------------------|
| Field | B&W | B&W | Color | Color |Mixed Raster|
| | Minimal| Extended | Lossy | October 10, 1997
ColorMap(320). SHORT
Count = 3 * (2**BitsPerSample)
Lossless | Content |
+-----------+--------+-----------+----------+----- ------+------------+
| BadFax- | | | | | |
| Lines | n | n | | | |
+-----------+--------+-----------+----------+------------+------------+
| CleanFax- | | | | | |
| Data | 0,1,2 | 0,1,2 | | | |
+-----------+--------+-----------+----------+------------+------------+
| Consecu- | | | | | |
| tiveBad- | | | | | |
| FaxLines | n | n | | | |
+-----------+--------+-----------+----------+------------+------------+
| Image- | | | | | |
| Layer | | | | | n, m |
+-----------+--------+-----------+----------+------------+------------+
| Global- | | | | | |
| Parame- | | | | | |
| tersIFD | | <IFD> | <IFD> | <IFD> | <IFD> |
+-----------+--------+-----------+----------+------------+------------+
| Profile- | | | | | |
| Type | | n | n | n | n |
+-----------+--------+-----------+----------+------------+------------+
| ITUFax- | | | | | |
| Mode | | n | n | n | n |
+-----------+--------+-----------+----------+------------+------------+
McIntyre & Zilles Expires 1/30/98 [Page 47]
Internet Draft File Format color fax mode supports palette-color (indexed) images
where the single component value is used as an index into a full
color lookup table stored in the ColorMap field. With lossless color
fax mode, only the ITULAB encoding with 8 bits per sample is
supported for Internet Fax July 30, 1997
+-----------+--------+-----------+----------+------------+------------+
| Coding- | | | | | |
| Method | | n | n | n | n |
+-----------+--------+-----------+----------+------------+------------+
| Version- | | | | | |
| Number | | n | n | n | n |
+-----------+--------+-----------+----------+------------+------------+
| Version- | | | | | |
| Year | | <b> | <b> | <b> | <b> |
+-----------+--------+-----------+----------+------------+------------+
McIntyre & Zilles Expires 1/30/98 [Page 48]
Internet Draft File Format for Internet Fax July 30, 1997
Appendix B: Use of TIFF-F for Black-and-White Fax
B.1 Overview
Section 4 provides palette-color images. To utilize a color map, the standard definition of image/tiff, application=F,
known commonly as TIFF-F and historically as TIFF Class F (see Section
4.4). Although Section 4 is a necessary and sufficient definition of
TIFF-F, there is much lore associated with TIFF-F. This appendix, based
on [TIFF-F], captures this lore and provides background information for
implementors.
B.2 TIFF-F Fields
The following table summarizes
Indexed field must be present. TIFF orders the required and optional (or
recommended) fields for TIFF-F (See Section 4.). The optional fields are
shown with an asterisk * For convenience, a minimum subset of color map values is
also shown; these so
that all the L* values should provide maximum portability come first, followed by all the a* values and
then all the b* values. Because ITU-T Rec. T.43 specifies a "chunky"
ordering with
historical TIFF-F readers.
Field | Values | Minimum | Comment
------------------|-------------|--------------|----------------------
BadFaxLines* |>=0 | |number the L*a*b*components of bad the first value, followed by
those of the second value, and so on, transferring color map values
between a TIFF file and fax lines
BitsPerSample | 1 | data stream requires reordering values.
Compression(259) = 9. SHORT
9: ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG)
FillOrder(266) = 1, 2. SHORT
This field is only relevant for 1 |one bit per sample
CleanFaxData* | 0,1,2 | 0,1,2 |status of bad lines
Compression | 3,4 | 3 |3 color (RGB, CMY,
CMYK); see Section 4.2.1 for T.4 (MH, MR)
| | |4 for T.6 (MMR)
ConsecutiveBad- |>=0 | |max number of bad lines
Lines* | | |
DateTime* | ASCII | |"YYYY:MM:DD:HH:MM:SS"
DocumentName* | ASCII | |informational field
FillOrder | 2,1 | 2 |LSB first or MSB first
ImageDescription* | ASCII | |informational field
ImageWidth | 1728, 2048, | 1728, 2048 |depends on XResolution
| 2432, 2592, | |
| 3072, 3648, | |
| 3456, 4096, | |
| 4864 | |
ImageLength | >0 | |required
NewSubFileType | 2 | 2 |single page of
| | |multipage file
Orientation* | 1 | 1 |1st row=top left,
| | | 1st col=top
PageNumber | X/X | 0/1 |pg/tot, 0 base,
| | | tot in 1st IFD
PhotometricInterp | 0,1 | 0 |0 is white
ResolutionUnit | 2,3 | 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |required
| or other | |
McIntyre & Zilles Expires 1/30/98 [Page 49]
Internet Draft File Format for Internet Fax July 30, 1997
SamplesPerPixel | 1 | 1 |one sample per further information.
PhotometricInterpretation(262) = 2, 5, 10. SHORT
2: RGB
5: CMYK, including CMY
10: ITULAB
Image data may also be stored as palette color images, where pixel
Software* | ASCII | |informational field
StripByteCounts | >0 | |required
StripOffsets | >0 | |required
T4Options | 4,5 | 4 |MH, MR: incl. if not MMR
T6Options | 0 | |MMR: incl. only if MMR
XResolution | 204,200,300 | 204 |If unit is per inch
| 400,406 | |
| 77 | | If unit is per cm
YResolution | 196,98,100, | 196,98 |If unit is per inch
| 200,300,392,| |
| 400 | |
| 77,38.5 | | If unit
values are represented by a single component that is per cm
------------------|-------------|--------------|--------------------
B.3 Implementation Notes
B.3.1 Strips
In general, TIFF files divide an image index into "strips," also known as
"bands." Each strip contains a few scanlines of the image. By
color map using
strips, a TIFF reader need not load the entire image into memory, thus
enabling it to fetch and decompress small random portions of the image
as necessary.
The number of scanlines in a strip ITULAB encoding. This color map is described specified by
the RowsPerStrip
value and ColorMap field. To use palette color images, set the number of bytes
PhotometricInterpretation to 10,SamplesPerPixel to 1, and Indexed to
1. The color map is stored in the strip after compression by ColorMap field. See Section 7.1.1
for further discussion on the
StripByteCount value. color encoding.
SamplesPerPixel(277) = 1, 3, 4. SHORT
1: Palette color image, or L*-only if Indexed = 0 and
PhotometricInterpretation is 10 (ITULAB).
3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK).
4: CMYK.
XResolution(282) = 100, 200, 300, 400. RATIONAL
YResolution(283) = 100, 200, 300, 400. RATIONAL
The location in the TIFF file resolution of each strip is
given by the StripOffsets values.
Strip size is application dependent. Existing TIFF-F usage image is typically
one strip per page expressed in multi-page TIFF-F. See Sections 2.1.2 pixels per resolution
unit. In pixels per inch, allowed XResolution values are: 100, 200,
300, and 2.1.3.
B.3.2 Bit Order 400. The current TIFF specification [TIFF] does lossless color fax mode requires the pixels to be
square, hence YResolution must equal XResolution. Base resolution is
200 pixels per inch.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 45]
Internet Draft File Format for Internet Fax October 10, 1997
7.2.2. Extension Fields
Indexed(364) = 0, 1. SHORT
0: not require a Baseline TIFF
reader palette-color image
1: palette-color image
This field is used to support FillOrder=2, i.e. lowest numbered 1-bit pixel in indicate that the
least significant bit sample values are an index
into an array of a byte. It further recommends that FillOrder=2 color values specified in the ColorMap field.
Lossless color fax mode supports palette-color images with the
ITULAB encoding. The SamplesPerPixel value must be 1.
Decode(TagToBeAssigned) SHORT
Decode is used only in special purpose applications.
Facsimile data appears on connection with the phone line in bit-reversed order relative
to its description in ITU-T Recommendation T.4. Therefore, a wide
majority ITULAB encoding of facsimile applications choose this natural order for data in
a file. Nevertheless, image data;
see Section 6.2.2.
7.2.3. New Fields
None.
7.3. Recommended TIFF F readers must be able to read data in both
bit orders Fields
See Sections 2.2.3. and support 2.2.4.
7.4. Lossless Color Fax Mode Summary
Recommended fields are shown with an asterisk *
+--------------------|--------------------------------------+
| Baseline Fields | Values |
+--------------------+--------------------------------------+
| BitsPerSample | 1: Binary RGB, CMY(K) |
| | 8: 8 bits per color sample |
| | 9-16: optional |
+--------------------+--------------------------------------+
| ColorMap | n: LAB color map |
+--------------------+--------------------------------------+
| Compression | 9: JBIG |
+--------------------+--------------------------------------+
| DateTime* | {ASCII}: date/time in the 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+--------------------+--------------------------------------+
| FillOrder values of | Applies only to 1 and 2. See Section 3.2.1.
McIntyre & Zilles bit/sample |
| | encodings |
| | 1: Most significant bit first |
| | 2: Least significant bit first |
+--------------------+--------------------------------------+
| ImageDescription* | {ASCII}: A string describing the |
| | contents of the image. |
+--------------------+--------------------------------------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 50] 46]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
B.3.3. Multi-Page Files
Many existing applications already read TIFF-F-like files, but do not
support multiples pages using a linked list
+--------------------+--------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+--------------------+--------------------------------------+
| ImageLength | n: total number of scanlines in image|
+--------------------+--------------------------------------+
| NewSubFileType | 2: Bit 1 identifies single page of IFDs. A Baseline TIFF
reader is not required to read any IFDs beyond the first one. Since a |
| | multi-page format greatly simplifies document |
+--------------------+--------------------------------------+
| Orientation | 1**-8, Default 1 |
+--------------------+--------------------------------------+
| PhotometricInter- | 2: RGB |
| pretation | 5: CMYK |
| | 10: ITULAB |
+--------------------+--------------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+--------------------+--------------------------------------+
| RowsPerStrip | n: number of scanlines per TIFF strip|
+--------------------+--------------------------------------+
| SamplesPerPixel | 1: L* (lightness) |
| | 3: LAB, RGB, CMY |
| | 4: CMYK |
+--------------------+--------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+--------------------+--------------------------------------+
| StripByteCounts | <n>: number or bytes in TIFF strip |
+--------------------+--------------------------------------+
| StripOffsets | <n>: offset from beginning of file management to|
| | each TIFF strip |
+--------------------+--------------------------------------+
| XResolution | 100, 200, 300, 400 (written in fax application
software, TIFF-F specifies multi-page documents |
| | pixels/inch) |
| YResolution | equal to XResolution (pixels must be |
| | square) |
+--------------------+--------------------------------------+
| Extension Fields |
+--------------------+--------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| |minimum and uses NewSubfileType
= 2.
B.3.4. Compression
Group 3 facsimile uses three compression methods. The ITU-T T.4
Recommendation [T.4] maximum values for L*a*b* |
+--------------------+--------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+--------------------+--------------------------------------+
| PageNumber | n,m: page number followed by total |
| | page count |
+--------------------+--------------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 47]
Internet Draft File Format for Internet Fax October 10, 1997
+--------------------+--------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+--------------------+--------------------------------------+
| New Fields |
+--------------------+--------------------------------------|
| GlobalParameters | <IFD>: global parameters IFD |
| IFD* | |
+--------------------+--------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+--------------------+--------------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode |
+--------------------+--------------------------------------+
| CodingMethods* | n:compression algorithms used in |
| | file |
+--------------------+--------------------------------------+
| VersionYear* | byte sequence: year of ITU fax std |
+--------------------+--------------------------------------+
8. Mixed Raster Content Mode
This section defines Application M of MIME media type image/tiff.
8.1. Overview
Unlike previous fax modes, which use a one-dimensional compression single coding method known
as Modified Huffman (MH) and a two-dimensional method known as Modified
READ (MR) (READ is short spatial
resolution for Relative Element Address Designate). In
1984, a somewhat more efficient compression method known as Modified
Modified READ (MMR) was defined in an entire fax page, the ITU-T T.6 Recommendation [T.6].
MMR was originally defined for use with Group 4 facsimile, so Mixed Raster Content mode [MRC]
enables different coding methods and resolutions within a single page.
For example, consider a page that this
compression method has been commonly called Group 4 compression. In
1991, the contains black-and-white text, which
is best coded with MMR method was approved for use in Group 3 facsimile or JBIG, a color bar chart, best coded with JBIG,
and has
since been widely utilized.
TIFF-F supports these three compression methods. The most common
practice is a scanned color image, best coded with JPEG. Similarly, while
spatial resolution of 400 pixels per inch may be best for the one-dimensional Modified Huffman (MH) compression
method. This black-and-
white text, 200 pixel per inch is specified by setting the Compression field value usually sufficient for a color image.
Rather than applying one coding method and resolution to 3 all elements,
MRC allows multiple coders and then setting bit 0 of resolutions within a page. By itself, MRC
does not define any new coding methods or resolutions. Instead it
defines a 3-layer model for structuring and combining the T4Options field to 0. Alternatively, scanned image
data.
The ITU MRC document [MRC] is scheduled ITU-T approval in October 1997.
Upon approval, it will become ITU-T Recommendation T.44.
8.1.1. MRC 3-layer model
The 3 layers of the
two dimensional Modified READ (MR) method, MRC model are Foreground and Background, which are
both multi-level, and Mask, which is much less frequently
used in historical TIFF-F implementations, bi-level. Each layer may be selected by setting
bit 0 appear
only once on a page and is coded independently of the T4Options field to 1. The value of Bit 2 other two. In our
McIntyre, Zilles, et al. Expires 4/10/98 [Page 48]
Internet Draft File Format for Internet Fax October 10, 1997
earlier example, the black-and-white text could be in this field is
determined by the use of fill bits.
Depending upon Mask layer,
the application, color chart in the more efficient two-dimensional
Modified Modified Read (MMR)compression method from T.6 may be selected
by setting the Compression field value to 4 Foreground layer, and then setting the
first two bits (and all unused bits) color image in the
Background layer. The distribution of content among layers is determined
by the T6Options field to 0.
Baseline TIFF also permits use writer, as is the choice of Compression=2 compression method, color encoding
and spatial resolution for a layer.
The final image is obtained by using the Mask layer to specify Modified
Huffman compression, but select pixels
from the data other two layers. When the Mask layer pixel value is presented in a form that 1, the
corresponding pixel from the Foreground layer is selected; when it is 0,
the corresponding pixel from the Background layer is selected. Details
are given in the Introduction of [MRC].
Not all pages, and not
byte aligned. As a result, TIFF-F uses Compression=3 instead all parts of
Compression=2 to specify Modified Huffman compression.
Uncompressed data a page, require 3 layers. If there
is only one layer present, then that layer is not supported in TIFF-F. Therefore, Bit 1 in both the T4Options primary image and T6Options fields must always
be 0.
Since two-dimensional encoding page size. If there is not required for Group 3
compatibility, some historic TIFF F readers have not been able to read
such files. However, for maximum efficiency, images should more than one layer, then the Mask must be
compressed using T.6 MMR compression when possible. For maximum
portability, applications also need to one
of the layers, in which case it is the primary image and must be able to read and write one-
dimensional (Modified Huffman) files. Some TIFF-F readers will also
support two-dimensional Modified READ files. Applications that wish page
size.
MRC allows a page to be split into strips, with a variable number of
scanlines in a strip. A strip can have the maximum flexibility 1, 2 or 3 layers. A single,
stripped layer may be stored as a single, stripped image in reading TIFF F files should support an IFD,
e.g., all
three of strips associated with the supported compression methods.
McIntyre & Zilles Expires 1/30/98 [Page 51]
Internet Draft File Format for Internet Fax July 30, 1997
B.3.5. Example Use Background layer may be treated as
a single image. Alternatively, each strip associated with a layer may be
stored as a separate image or IFD, e.g., the Background layer can be
composed of Page-quality Fields
Here several images that are examples for writing offset vertically with respect to
the CleanFaxData, BadFaxLines, and
ConsecutiveBadFaxLines fields:
1. Facsimile hardware does not provide page quality information: Do not
write page-quality fields.
2. Facsimile hardware provides page quality information, but reports page. In this case, there can be no
bad lines. Write only BadFaxLines = 0.
3. Facsimile hardware provides page quality information, and reports
bad lines. Write both BadFaxLines overlap between images
associated with a single layer.
Furthermore, color fax also requires the spatial resolutions of
Background and ConsecutiveBadFaxLines. Also
write CleanFaxData = 1 or 2 Foreground images to be legal fax values that are also
integer
factors of the Mask image resolution. For example, if the hardware's regeneration
capability Mask Layer
resolution is known.
4. Computer generated file: write CleanFaxData = 0.
5. Source image data stream is error-corrected or otherwise guaranteed
to be error-free: Do not write page-quality fields.
B.3.6 Resolution
Almost all facsimile products support both "standard" (98 dpi)
resolution and "fine" (196 dpi) vertical resolution. Therefore, fine-
resolution files are quite portable in the real world.
In 1993, the ITU-T added support for higher 400 pixels per inch, then allowed resolutions in for the T.30
Recommendation, including
Foreground and Background layers are 100, 200 x 200, 300 x 300, 400 x or 400 in dots pixels per
inch based units. At inch; if
the same time, support was added for metric
dimensions which Mask is at 300 pixels per inch, then allowed values are equivalent to the following inch based resolutions:
392v x 203h 100 and 392v x 406h. Therefore, 300.
The Foregound and Background layer resolutions can be independently set.
8.1.2. A TIFF Representation for the full set of inch-based
equivalents MRC 3-layer model
In the TIFF representation of the new resolutions are supported in 3-layer MRC model, each page is
represented by a single IFD, called the TIFF-F, since
they may appear in some image data streams received from Group 3
facsimile devices. However, many facsimile terminals and older versions
of TIFF-F readers are likely to not support Primary IFD, that represents the use of these higher
resolutions.
It
Mask layer (unless the Foreground or Background is permissible for applications to treat the following XResolution
values as being equivalent: <204,200> single layer
present), and <400,406>. In a similar
respect, set of child IFDs that are referenced through the following YResolution values may also be treated as being
equivalent: <98, 100>, <196, 200>, and <392, 400>. These equivalencies
were allowed by [T.30] to permit conversions between inch and metric
based facsimile terminals.
In a similar respect,
SubIFDs extension field [TTN1]. To distinguish MRC-specific SubIFDs from
other SubIFDs, the optional support NewSubFileType field will have Bit 4 ON, indicating
an MRC-related IFD. A new ImageLayer field is also introduced that
consists of metric based resolutions
in two values which identify the TIFF-F reader (i.e. 77 x 38.5 cm) is included layer (Foreground, Background,
or Mask) and the order within the layer (first, second, ... image of the
layer); see Section 8.2.3.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 49]
Internet Draft File Format for completeness,
since they are Internet Fax October 10, 1997
Because MRC allows strips with variable numbers of scanlines, the
StripRowCounts field is used in some legacy TIFF-F applications, but this use is
not recommended for place of the creation RowsPerStrip field in
this mode. The StripRowCounts field allows each layer, with a variable
number of TIFF-F files scanlines in each strip, to be represented by a writer.
Historical TIFF-F documents also included single IFD.
Alternatively, each strip in the following values related
to A5 and A6 widths: 816 Foreground and 1216. Per Background layers can be
represented by a single IFD at the most recent version option of
[T.4], A5 and A6 documents are no longer supported the writer. In all cases,
the Mask layer is required to be represented by a single IFD.
The use of SubIFDs to store child IFDs is described in Group 3 facsimile,
so [TTN1]. An
example is shown graphically below. The Primary IFD associated with page
1 (PrimaryIFD 0) points to page 2 (PrimaryIFD 1) with the related width values are now obsolete.
McIntyre & Zilles nextIFD
offset. The Primary IFD, corresponding to the Mask layer
(ImageLayer=[2,1]), contains a SubIFDs field that points to a list of
child IFDs. The first child IFD represents one image of the Background
layer, i.e., ImageLayer=[1,1]. This child IFD points to the second child
IFD via the nextIFD offset. This child represents the second Background
layer image, ImageLayer=[1,2]. Finally, the second child points to the
third child, which corresponds to the single Foreground layer image,
ImageLayer=[3,1]. The next IFD offset associated with this Foreground
image is 0, indicating no more child IFDs exist. Each primary IFD has
the NewSubFileType set to 18, indicating the IFD is MRC-specific (bit 4)
and that it is a single page of a multi-page document (bit 1). Each
child IFD has the NewSubFileType set to 16, indicating the IFD is
MRC-specific. Note: the 'V' character should be read as a down-pointing
arrow.
(nextIFD)
PRIMARY IFD 0 ------------> PRIMARY IFD 1--> ...
ImageLayer = [2,1]
NewSubFileType = 18
SubIFDs
|
V
Child IFD
ImageLayer = [1,1]
NewSubFileType = 16
|
|(nextIFD)
|
V
Child IFD
ImageLayer = [1,2]
NewSubFileType = 16
|
|(nextIFD)
|
V
McIntyre, Zilles, et al. Expires 4/10/98 [Page 50]
Internet Draft File Format for Internet Fax October 10, 1997
Child IFD
ImageLayer = [3,1]
NewSubFileType = 16
|
|(nextIFD)
|
V
0
In the example above, the SubIFDs field of the Primary IFD points to the
first IFD in a list of child IFDs. TIFF allows the SubIFDs field to
point to an array of IFDs, each of which can be the first of a list of
IFDs. An MRC-enabled TIFF reader must scan all available child IFDs to
locate and identify IFDs associated with MRC layers.
In the case where the Background or Foreground layers are described with
multiple IFDs, the XPosition and YPosition TIFF fields specify the
offset to the upper-left corner of the IFD with respect to the Mask
layer; see Section 8.2.2. When there is only a single layer (Mask,
Foreground, or Background), it is stored as the Primary IFD.
8.2. Required TIFF Fields
This section describes the TIFF fields required, in addition to those in
Section 2.2.1, to represent MRC mode fax images. Since MRC mode stores
fax data as a collection of images corresponding to layers or parts of
layers, the compression mechanisms, color encodings and spatial
resolutions used by previous modes apply to MRC. Therefore, the
descriptions here will typically reference the appropriate earlier
section. Fields and values specific to MRC mode are pointed out.
8.2.1. Baseline Fields
ImageWidth(256). SHORT or LONG
Same page widths as the base color mode; see Section 6.2.1.
BitsPerSample(258) = 1, 8, 9-16 SHORT
Compression(259) = 3, 4, 7, 9. SHORT
SamplesPerPixel(277) = 1, 3, 4. SHORT
FillOrder(266) = 1, 2. SHORT
PhotometricInterpretation(262) = 0, 1, 2, 5, 10. SHORT
For Mask layer, see Section 4.2.1.
For Foreground and Background layers, see Sections 6.2.1 and 7.2.1.
ColorMap(320). SHORT
Count = 3 * (2**BitsPerSample)
Used when Foreground or Background layer is a palette-color image;
see Section 7.2.1.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 51]
Internet Draft File Format for Internet Fax October 10, 1997
NewSubFileType(254) = 16, 18. LONG
For MRC fax mode, the NewSubFileType field has two bits that are
required.
Bit 1 indicates a single page of a multi-page document and must be
set for the Primary IFDs;
Bit 4 indicates MRC imaging model as described in ITU-T
Recommendation Draft T.44 [MRC], and must be set for Primary IFDs
and all MRC-specific child IFDs.
StripRowCounts(559). LONG
Count = number of strips
The number of scanlines stored in a strip. MRC allows each fax strip
to store a different number of scanlines, up to a specified maximum
strip size, which is either 256 scanlines or the page length in
scanlines, depending on the implementation. This field replaces
RowsPerStrip for IFDs with variable-sized strips. Only one of the
two fields, StripRowCounts and RowsPerStrip, may be used in an IFD.
XResolution(282) = 100, 200, 300, 400. RATIONAL
YResolution(283) = 100, 200, 300, 400. RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values are: 100, 200,
300, and 400. MRC color fax mode requires the pixels to be square,
hence YResolution must equal XResolution for all layers.
8.2.2. Extension Fields
ChromaSubSampling(530). SHORT
ChromaPositioning(531). SHORT
Decode(TagToBeAssigned). SHORT
For Foreground and Background layers, see Section 6.2.2.
Indexed(346) = 0, 1. SHORT
For Foreground and Background layers: 1 indicates a palette-color
image, see Section 7.2.2.
T4Options(292) = 0, 1, 4, 5. SHORT
T6Options(293) = 0. SHORT
For Mask layer, see Section 4.2.2.
DefaultImageColor(TagToBeAssigned). SHORT or LONG
Count = SamplesPerPixel
In areas where no image data is available, a default color is needed
to specify the color value. If the StripByteCounts value for a strip
is 0, then the color for that strip must be defined by a default
image color.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 52]
Internet Draft File Format for Internet Fax October 10, 1997
The DefaultImageColor field uses the same encoding as the image
data, and its value is therefore interpreted using the
PhotometricInterpretation, SamplesPerPixel, BitsPerSample, and
Indexed fields. If the fax data stream requires a different
encoding, then transferring the default color value between a TIFF
file and fax data stream requires a color conversion.
The default value for the DefaultImageColor field is white.
SubIFDs(330). IFD
Count = number of child IFDs
Each value is an offset from the beginning of the TIFF file to a
child IFD [TTN1].
XPosition(286). RATIONAL
YPosition(287). RATIONAL
Specifies the horizontal and vertical offsets of the top-left of the
IFD from the top-left of the Primary IFD in page resolution units.
For example, if the Primary IFD is at 400 pixels per inch, and a
foreground layer IFD is at 200 pixels per inch and located at pixel
coordinate (345, 678) with respect to the Primary IFD, the XPosition
value is 345/400 and the YPosition value is 678/400.
Color fax does not currently allow overlap of any component images
within a single layer.
Default values for XPosition and YPosition are 0.
8.2.3. New Fields
The Mixed Raster Content mode requires one new field: ImageLayer.
ImageLayer (34732). SHORT or LONG.
Count = 2
Image layers are defined such that layer 1 is the Background layer,
layer 3 is the Foreground layer, and layer 2 is the Mask layer that
selects pixels from the Background and Foreground layers. The
ImageLayer tag contains two values, describing the layer to which
the image belongs and the order in which it is imaged.
ImageLayer[0]: 1, 2, 3.
1: Image is a Background image, i.e., the image that will appear
whenever the Mask contains a value of 0. Background images
typically contain low-resolution, continuous-tone imagery.
2: Image is the Mask layer. In MRC, if the Mask layer is present, it
must be the Primary IFD and be full page in extent (no gaps.)
3: Image is a Foreground image, i.e., the image that will appear
whenever the Mask contains a value of 1. The Foreground image
generally defines the color of text or lines, but may also
contain high-resolution imagery.
ImageLayer[1]:
1: first image to be imaged in this layer (e.g., first fax strip),
2: second image to be imaged in this layer (e.g., second fax strip),
3: ...
McIntyre, Zilles, et al. Expires 4/10/98 [Page 53]
Internet Draft File Format for Internet Fax October 10, 1997
Value describing the image order. In MRC, this may be considered the
strip number. Since MRC mode currently does not allow overlap
between images within a layer, the order value does not have any
visual effect.
In MRC fax mode, it is possible that only a single layer is transmitted.
For example, if a page contains only a single continuous-tone
photograph, then only the Background layer may be transmitted. In this
case, the Background layer will be full page and stored as the Primary
IFD. ImageLayer[0] will be 1 indicating Background; ImageLayer[1] will
be 1 since the layer must be full page and there can be no other IFDs
associated with that layer. No Mask layer will exist.
8.3. Recommended TIFF Fields
See Sections 2.2.3. and 2.2.4.
8.4. Rules and Requirements for Images
The MRC mode defines a fundamental set of rules for images in the
3-layer representation.
1. If more than one layer exists, then the binary Mask layer must be
present and it is the primary image. If only one layer exists, then
the image corresponding to that layer is the primary image.
2. The Primary image defines and extends to the entire page boundary;
all attached model images cannot extend beyond the Primary image.
Resolution differences may cause some pixels to "hang over" the page
boundary, but no new pixels should exist completely beyond the page
extent
3. The Background and Foreground images may use any color encoding
defined in Sections 5 and 6, and may optionally cover only a portion
of the region defined by the Primary image, unless one of them is the
primary image.
4. Each Primary IFD and each MRC-specific SubIFD must have an ImageLayer
field to specify which layer the IFD belongs to, and the imaging
order of that IFD within the layer.
5. Each Primary IFD must have a NewSubFileType field value set to 18,
indicating a single page of a multi-page document (bit 1) and MRC
mode (bit 4).
6. Each MRC-specific child IFD must have a NewSubFileType field value
set to 16, indicating MRC mode (bit 4).
McIntyre, Zilles, et al. Expires 4/10/98 [Page 54]
Internet Draft File Format for Internet Fax October 10, 1997
7. In MRC mode, each layer is transmitted as a sequence of strips. It is
possible that each strip of each layer can be stored as a separate
IFD. In this case, the SubIFDs structure pointed to by the Primary
IFD will contain several IFDs that have an ImageLayer field with the
layer identified as either Background (layer 1) or Foreground (layer
3). There may be no overlap in the vertical direction between IFDs
associated with a single layer, although there may be a gap from one
of these images to the next. The TIFF XPosition and YPosition fields
are used to indicate the placement of these images with respect to
the primary image.
8. The resolution of Background and Foreground images must each be an
integer factor of the Primary image. For example, if the Primary
image is 400 pixels/inch, then the model images may be at 400
pixels/inch (400 / 1), 200 pixels/inch (400 / 2), 100 pixels/inch
(400 / 4), etc.
8.5. MRC Fax Mode Summary
Recommended fields are shown with an asterisk *
+------------------+-----------------------------------------+
| Baseline Fields | Values |
|------------------|-----------------------------------------|
| BitsPerSample | 1: binary mask |
| | 8: 8 bits per color sample |
| | 9-16: optional 12 bits/sample |
+------------------+-----------------------------------------+
| ColorMap | n: LAB color map |
+------------------+-----------------------------------------+
| Compression | 3: Modified Huffman and Modified Read |
| | 4: Modified Modified Read |
| | 7: JPEG |
| | 9: JBIG |
+------------------+-----------------------------------------+
| DateTime* | {ASCII): date/time in the 24-hour format|
| | "YYYY:MM:DD HH:MM:SS" |
+------------------+-----------------------------------------|
| FillOrder | Applies only to 1 bit/sample encodings |
| | 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 |
+------------------+-----------------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 55]
Internet Draft File Format for Internet Fax October 10, 1997
+------------------+-----------------------------------------+
| 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 |
| pretation | 1: BlackIsZero |
| | 2: RGB |
| | 5: CMYK |
| | 10: ITULAB |
+------------------+-----------------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+------------------+-----------------------------------------+
| RowsPerStrip | n: number of scanlines in each 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 TIFF 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 must be |
| | square) |
+------------------+-----------------------------------------+
| Extension Fields |
+------------------+-----------------------------------------+
| T4Options | 0: required if Compression is Modified |
| | Huffman, EOLs not byte aligned |
| | 1: required if Compression 2D Modified |
| | Read, EOLs are byte aligned |
| | 4: required if Compression Modified |
| | Huffman, EOLs not byte aligned |
| | 5: required if Compression 2D Modified |
| | Read, EOLs are byte aligned |
+------------------+-----------------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 56]
Internet Draft File Format for Internet Fax October 10, 1997
+------------------+-----------------------------------------+
| T6Options | 0: required if Compression is 2D |
| | Modified Modified Read |
+------------------+-----------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+------------------+-----------------------------------------+
| PageNumber | n,m: page number followed by total page |
| | count |
+------------------+-----------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| | minimum and maximum values for L*a*b* |
+------------------+-----------------------------------------+
| ChromaSubSampling| ChromaSubsampleHoriz: |
| | 0: equal numbers of lightness and chroma|
| | samples |
| | 1: twice as many lightness samples as |
| | chroma samples |
| | 2: four times as many lightness samples |
| | as chroma samples |
| | ChromaSubsampleVert: |
| | 0: equal numbers of lightness and chroma|
| | samples |
| | 1: twice as many lightness samples as |
| | chroma samples |
| | 2: four times as many lightness samples |
| | as chroma samples |
+------------------+-----------------------------------------+
| ChromaPositioning| 1: centered |
| | 2: cosited |
+------------------+-----------------------------------------+
| DefaultImageColor| <n>: background color |
+------------------+-----------------------------------------+
| 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 |
| | coordinates |
+------------------+-----------------------------------------+
| YPosition | vertical offset in primary IFD |
| | coordinates |
+------------------+-----------------------------------------+
| New Fields |
+------------------+-----------------------------------------+
| ImageLayer | n, m: layer number, imaging sequence |
| | (e.g., strip number) |
+------------------+-----------------------------------------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 57]
Internet Draft File Format for Internet Fax October 10, 1997
+------------------+-----------------------------------------+
| GlobalParameters | <IFD>: global parameters IFD |
| IFD* | |
+------------------+-----------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+------------------+-----------------------------------------+
| ITUFaxMode* | n: ITU-compatible fax mode |
+------------------+-----------------------------------------+
| CodingMethods* | n: compression algorithms used in file |
+------------------+-----------------------------------------+
| ModeNumber* | n: version of ITU fax standard |
+------------------+-----------------------------------------+
| VersionYear* | byte sequence with year of ITU fax |
| | standard |
+------------------+-----------------------------------------+
9. Security Considerations
This document describes a file format for Internet fax, which is an
application of the TIFF encoding. As such, it does not create any
security issues not already existing in TIFF (though, none have been
identified).
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.
10. References
[MRC] COM8-21, Draft Recommendation on T.44 - Mixed Raster Content
(MRC), ITU-T Study Group 8, May 1997.
[REQ] S. Bradner, Key words for use in RFCs to Indicate Requirement
Levels, RFC 2119, March 1997.
[T.4] ITU-T Recommendation T.4, Standardization of group 3 facsimile
apparatus for document transmission, July 1996
[T.6] ITU-T Recommendation T.6, Facsimile coding schemes and coding
control functions for group 4 facsimile apparatus, November 1988
[T.30] ITU-T Recommendation T.30 - Procedures for Document Facsimile
Transmission in the General Switched Telephone Network, June, 1996
[T.42] ITU-T Recommendation T.42, Continuous-tone colour representation
method for facsimile, February 1996
McIntyre, Zilles, et al. Expires 4/10/98 [Page 58]
Internet Draft File Format for Internet Fax October 10, 1997
[T.43] ITU-T Recommendation T.43, Colour and gray-scale image
representations using lossless coding scheme for facsimile, February
1997
[T.81] ITU-T Recommendation T.81, Information technology - Digital
compression and coding of continuous-tone still images - Requirements
and guidelines, September 1992
[T.82] ITU-T Recommendation T.82, Information technology - Coded
representation of picture and audio information - Progressive bi-level
image compression, March 1995
[T.85] ITU-T Recommendation T.85, Application profile for Recommendation
T.82 - Progressive bi-level image compression (JBIG coding scheme) for
facsimile apparatus, August 1995
[TIFF] Tag Image File Format, Revision 6.0, Adobe Developers
Association, June 3, 1992, ftp://ftp.adobe.com/pub/adobe/devrelations/
devtechnotes/pdffiles/tiff6.pdf
The TIFF 6.0 specification dated June 3, 1992 specification © 1986-
1988, 1992 Adobe Systems Incorporated. All Rights Reserved.
[TIFF-F] G. Parsons and J. Rafferty, Tag Image File Format (TIFF) -
Application F, Sept. 22, 1997, work in progress,
ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-tiff-04.txt
[TIFF-F0] TIFF Class F specification, Apr 28, 1990,
ftp://ftp.faximum.com/pub/documents/tiff_f.txt
[TIFF-REG] G. Parsons, J. Rafferty and S. Zilles, Tag Image File Format
(TIFF) - image/tiff MIME Sub-type Registration, Sept. 22, 1997, work in
progress, ftp://ftp.ietf.org/internet-drafts/draft-ietf-fax-reg-02.txt
[TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995,
http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf
[TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG specification,
March 17, 1995, ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt
[VPIM2] G. Vaudreuil and G. Parsons, Voice Profile for Internet Mail -
version 2, July 1997, work in progress, <draft-ema-vpim-06.txt>
[WIDE] K. Toyoda, H. Ohno and J. Murai, WDIE Message-based Fax over the
Internet, July 29, 1997, work in progress, ftp://ftp.ietf.org/internet-
drafts/draft-ietf-fax-wide-00.txt
The ITU-T Recommendations are available at http://www.itu.ch.
McIntyre, Zilles, et al. Expires 4/10/98 [Page 59]
Internet Draft File Format for Internet Fax October 10, 1997
11. Authors' Addresses
Lloyd McIntyre
Xerox Corporation
Mailstop PAHV-305
3400 Hillview Ave.
Palo Alto, CA 94304 USA
Voice: +1-415-813-6762
Fax: +1-415-845-2340
Email: lmcintyre@adoc.xerox.com
Stephen Zilles
Adobe Systems Inc.
Mailstop W14
345 Park Avenue
San Jose, CA 95110-2704, USA
Voice: +1-408-536-4766
Fax: +1-408-536-4042
Email: szilles@adobe.com
Robert Buckley
Xerox Corporation
Mailstop 0128-27E
800 Phillips Road
Webster, NY 14580, USA
Voice: +1-716-422-1282
Fax: +1-716-422-6117
Email: Rob_Buckley@wb.xerox.com
Dennis Venable
Xerox Corporation
Mailstop 0128-27E
800 Phillips Road
Webster, NY 14580, USA
Voice: +1-716-422-8009
Fax: +1-716-422-6117
Email: venable@wrc.xerox.com
McIntyre, Zilles, et al. Expires 4/10/98 [Page 60]
Internet Draft File Format for Internet Fax October 10, 1997
Annex A: Summary of TIFF Fields for Internet Fax
This annex includes tables which list by mode the TIFF fields used in
the proposed fax file format. The fields are organized into 3
categories:
1) TIFF Baseline Fields
2) TIFF Extension Fields
3) New Fields.
The tables include the allowed values for each fax mode.
Entries other than explicit numbers are described by:
n - single number
n, m - 2 numbers
a, b, c - 3 numbers
r - rational number
<n> - array of numbers
<b> - byte sequence
{ASCII} - string
<IFD> - array of IFD byte offsets
A blank entry in the table indicates the field is not used by that
particular fax mode.
Table A.1 TIFF Baseline Fields
+---------------------------------------------------------+
| Fax Mode/Application |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
| B&W | B&W | B&W | Color | Color | Raster |
+----------| | | | | | Content|
| Field | W | F | J | C | P | M |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer | 1 | 1 | 1 | 8, 12 | 1, 8 | 1, 8 |
| Sample | | | | | 9-16 | 9-16 |
+----------+---------+----------+--------+---------+--------+--------+
| ColorMap | | | | | <n> | <n> |
+----------+---------+----------+--------+---------+--------+--------+
| Compres- | 3 | 3, 4 | 9 | 7 | 9 | 3, 4, |
| sion | | | | | | 7, 9 |
+----------+---------+----------+--------+---------+--------+--------+
| DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| FillOrder| 2 | 1, 2 | 1, 2 | | 1, 2 | 1,2 |
+----------+---------+----------+--------+---------+--------+--------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 61]
Internet Draft File Format for Internet Fax October 10, 1997
+----------+---------+----------+--------+---------+--------+--------+
| ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| cription | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, |
| Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, |
| | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | n | n | n | n | n | n |
| Length | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer | 1 | 1 | 1 | 8, 12 | 1 | 1 |
| Sample | | | | | 8, 9-16| 8, 9-16|
+----------+---------+----------+--------+---------+--------+--------+
| ColorMap | | | | | <n> | <n> |
+----------+---------+----------+--------+---------+--------+--------+
| NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 |
| FileType | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Orien- | 1 | 1 | 1 | 1 | 1 | 1 |
| tation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, 1, |
| metric- | | | | | | 2, 5, |
| Interp- | | | | | | 10 |
| retation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 |
| tionUnit | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| RowsPer- | n | n | n | n | n | |
| Strip | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4|
| PerPixel | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Byte- | | | | | | |
| Counts | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Offsets | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 |
| tion | | 400, 406 | |
+----------+---------+----------+--------+---------+--------+--------+
| YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 |
| tion | | 300, 391, 400 | |
+----------+---------+----------+--------+---------+--------+--------+
McIntyre, Zilles, et al. Expires 4/10/98 [Page 62]
Internet Draft File Format for Internet Fax October 10, 1997
Table A.2 TIFF Extension Fields
+---------------------------------------------------------+
| Fax Mode/Application |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
| B&W | B&W | B&W | Color | Color | Raster |
+----------| | | | | | Content|
| Field | W | F | J | C | P | M |
+----------+---------+----------+--------+---------+--------+--------+
| T4Options| 0, 4 | 0, 1, | | | | 0, 1, |
| | | 4, 5 | | | | 4, 5 |
+----------+---------+----------+--------+---------+--------+--------+
| T6Options| | 0 | | | | 0 |
+----------+---------+----------+--------+---------+--------+--------+
| Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| Name | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Page- | n, m | n, m | n, m | n, m | n, m | n, m |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| XPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
| YPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
| SubIFDs | | | | | | <IFD> |
+----------+---------+----------+--------+---------+--------+--------+
| Indexed | | | | | 0,1 | 0,1 |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | n, m | | n, m |
| SubSampl-| | | | | | |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | 1, 2 | | 1,2 |
| Position-| | | | | | |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Decode | | | | <n> | <n> | <n> |
+----------+---------+----------+--------+---------+--------+--------+
| Default- | | | | | | <n> |
|ImageColor| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | | | | | | <n> |
| RowCounts| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 52] 63]
Internet Draft File Format for Internet Fax July 30, October 10, 1997
B.3.7. EOL
As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
with Modified Huffman begin with an EOL, which in TIFF-F is byte-
aligned. The last line of the image is not terminated by an EOL. In a
similar respect, images encoded with Modified READ two dimensional
encoding begin with an EOL, followed by a tag bit. The EOL/tag bit
combination is byte aligned in TIFF-F. See Section 3.4.
B.3.8. RTC Exclusion
Aside from EOLs, TIFF F files contain only image data. This means that
the Return To Control sequence (RTC) is specifically excluded.
B.3.9. Use of EOFB for T.6 Compressed Images
TIFF-F pages which are encoded with the T.6 Modified Modified READ
compression method should include an "end-of-facsimile-block" (EOFB)
code at the end of each coded strip. Per [TIFF], the EOFB code is
followed by pad bits as needed to align on a byte boundary. TIFF
readers should ignore any bits other than pad bits beyond the EOFB.
McIntyre & Zilles
Table A.3 New Fields
+---------------------------------------------------------+
| Fax Mode/Application |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
| B&W | B&W | B&W | Color | Color | Raster |
+----------| | | | | | Content|
| Field | W | F | J | C | P | M |
+----------+---------+----------+--------+---------+--------+--------+
| BadFax- | | n | | | | |
| Lines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| CleanFax-| | 0, 1, 2 | | | | |
| Data | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Consecu- | | n | | | | |
| tiveBad- | | | | | | |
| FaxLines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | n, m |
| Layer | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Global- | | | <IFD> | <IFD> | <IFD> | <IFD> |
| Parame- | | | | | | |
| tersIFD | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Profile- | | | n | n | n | n |
| Type | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| ITUFax- | | | n | n | n | n |
| Mode | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Coding- | | | n | n | n | n |
| Method | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Mode- | | | | | | n |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------|
| Version- | | | | <b> |<b> | |
| Year | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
McIntyre, Zilles, et al. Expires 1/30/98 4/10/98 [Page 53] 64]
----