RFC 3949 - File Format for Internet Fax
(Formats: TXT)
Network Working Group R. Buckley
Request for Comments: 3949 D. Venable
Obsoletes: 2301 Xerox Corporation
Category: Standards Track L. McIntyre
Consultant
G. Parsons
Nortel Networks
J. Rafferty
Brooktrout
February 2005
|
File Format for Internet Fax
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is a revised version of RFC 2301. The revisions,
summarized in the list attached as Annex B, are based on discussions
and suggestions for improvements that have been made since RFC 2301
was issued in March 1998, and on the results of independent
implementations and interoperability testing.
This RFC 2301 revision describes the Tag Image File Format (TIFF)
representation of image data specified by the International
Telecommunication Union (ITU-T) Recommendations for black-and-white
and color facsimile. This file format specification is commonly
known as TIFF for Fax eXtended (TIFF-FX). It formally defines
minimal, extended, and lossless Joint Bi-level Image experts Group
(JBIG) profiles (Profiles S, F, J) for black-and-white fax and base
JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C,
L, M) for color and grayscale fax. These profiles correspond to the
content of the applicable ITU-T Recommendations.
Buckley, et al. Standards Track [Page 1]
RFC 3949 File Format for Internet Fax February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Approach. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Overview of this Document . . . . . . . . . . . . . . . . 5
2. TIFF and Fax . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. TIFF Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. File Structure . . . . . . . . . . . . . . . . . . 8
2.1.2. Image Structure. . . . . . . . . . . . . . . . . . 10
2.1.3. TIFF File Structure for Fax Applications . . . . . 11
2.2. TIFF Fields for All Fax Applications. . . . . . . . . . . 12
2.2.1. TIFF Fields required for all fax profiles. . . . . 13
2.2.2. Additional TIFF Fields required for all fax
profiles . . . . . . . . . . . . . . . . . . . . . 14
2.2.3. TIFF Fields recommended for all fax profiles . . . 17
2.2.4. New TIFF Fields recommended for fax profiles . . . 18
3. Profile S: Minimal Black-and-White Fax Profile . . . . . . . . 20
3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 21
3.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 21
3.2.2. Extension Fields . . . . . . . . . . . . . . . . . 23
3.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 23
3.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 23
3.4. End of Line (EOL) and Return to Control (RTC) . . . . . . 23
3.4.1. RTC Exclusion. . . . . . . . . . . . . . . . . . . 24
3.5. File Structure. . . . . . . . . . . . . . . . . . . . . . 24
3.6. Profile S: Minimal Black-and-White Profile Summary. . . . 26
4. Profile F: Extended Black-and-White Fax Profile. . . . . . . . 27
4.1. TIFF-F Overview . . . . . . . . . . . . . . . . . . . . . 28
4.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 29
4.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 29
4.2.2. Extension Fields . . . . . . . . . . . . . . . . . 32
4.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 32
4.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 32
4.3.1. Baseline Fields. . . . . . . . . . . . . . . . . . 32
4.3.2. Extension Fields . . . . . . . . . . . . . . . . . 33
4.3.3. New Fields . . . . . . . . . . . . . . . . . . . . 33
4.4. Technical Implementation Issues . . . . . . . . . . . . . 34
4.4.1. Strips . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2. Bit Order. . . . . . . . . . . . . . . . . . . . . 34
4.4.3. Multi-Page . . . . . . . . . . . . . . . . . . . . 35
4.4.4. Compression. . . . . . . . . . . . . . . . . . . . 35
4.4.5. Example Use of Page-quality Fields . . . . . . . . 36
4.4.6. Practical Guidelines for Writing and Reading
Multi-Page TIFF-F Files. . . . . . . . . . . . . . 36
4.4.7. Use of TIFF-F for Streaming Applications . . . . . 38
Buckley, et al. Standards Track [Page 2]
RFC 3949 File Format for Internet Fax February 2005
4.5. Implementation Warnings . . . . . . . . . . . . . . . . . 38
4.5.1. Uncompressed Data. . . . . . . . . . . . . . . . . 38
4.5.2. Encoding and Resolution. . . . . . . . . . . . . . 38
4.5.3. EOL byte-aligned . . . . . . . . . . . . . . . . . 39
4.5.4. EOL. . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.5. RTC Exclusion. . . . . . . . . . . . . . . . . . . 40
4.5.6. Use of EOFB for T.6 Compressed Images. . . . . . . 40
4.6. Example Use of TIFF-F . . . . . . . . . . . . . . . . . . 40
4.7. Profile F: Extended Black-and-white Fax Profile Summary . 41
5. Profile J: Lossless JBIG Black-and-White Fax Profile . . . . . 43
5.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 44
5.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 44
5.2.2. Extension Fields . . . . . . . . . . . . . . . . . 44
5.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 44
5.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 45
5.4. Profile J: Lossless JBIG Black-and-White Profile Summary. 45
6. Profile C: Base Color Fax Profile. . . . . . . . . . . . . . . 47
6.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 47
6.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 47
6.2.2. Extension Fields . . . . . . . . . . . . . . . . . 49
6.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 50
6.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 52
6.4. Profile C: Base Color Fax Profile Summary . . . . . . . . 52
7. Profile L: Lossless Color Profile. . . . . . . . . . . . . . . 54
7.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.1.1. Color Encoding . . . . . . . . . . . . . . . . . . 54
7.1.2. JBIG Compression . . . . . . . . . . . . . . . . . 55
7.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 55
7.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 56
7.2.2. Extension Fields . . . . . . . . . . . . . . . . . 57
7.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 57
7.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 57
7.4. Profile L: Lossless Color Fax Profile Summary . . . . . . 58
8. Profile M: Mixed Raster Content Profile. . . . . . . . . . . . 60
8.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 60
8.1.1. MRC 3-layer model. . . . . . . . . . . . . . . . . 60
8.1.2. A TIFF Representation for the MRC 3-layer model. . 62
8.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 64
8.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 64
8.2.2. Extension Fields . . . . . . . . . . . . . . . . . 66
8.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 67
8.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 69
8.4. Rules and Requirements for Images . . . . . . . . . . . . 69
8.5. Profile M: MRC Fax Profile Summary. . . . . . . . . . . . 71
9. MIME content-types image/tiff and image/tiff-fx. . . . . . . . 74
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 74
Buckley, et al. Standards Track [Page 3]
RFC 3949 File Format for Internet Fax February 2005
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11.1. Normative References . . . . . . . . . . . . . . . . . . 74
11.2. Informative References . . . . . . . . . . . . . . . . . 76
Annex A: Summary of TIFF Fields for Internet Fax . . . . . . . . . 77
Annex B: List of technical edits to RFC 2301 . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction
This document describes the use of TIFF (Tag Image File Format) to
represent the data content and structure generated by the current
suite of ITU-T Recommendations for Group 3 facsimile. These
recommendations and the TIFF fields described here support the
following facsimile profiles:
S: Minimal black-and-white profile, using binary MH compression
[T.4]
F: Extended black-and-white profile, using binary MH, MR, and MMR
compression [T.4, T.6]
J: Lossless JBIG black-and-white profile, with JBIG compression
[T.85, T.82]
C: Lossy color and grayscale profile, using JPEG compression [T.42,
T.81]
L: Lossless color and grayscale profile, using JBIG compression
[T.43, T.82]
M: Mixed raster content profile [T.44], using a combination of
existing compression methods
Each profile corresponds to the content of ITU-T Recommendations
shown and is a subset of the full TIFF for facsimile specification.
Profile S describes a minimal interchange set of fields, which will
guarantee that, at least, binary black-and-white images will be
supported. Implementations are required to support this minimal
interchange set of fields.
With the intent of specifying a file format for Internet fax, this
document
1. specifies the structure of TIFF files for facsimile data,
2. defines ITU fax-compatible values for existing TIFF fields, and
3. defines new TIFF fields and values required for compatibility with
ITU color fax.
Buckley, et al. Standards Track [Page 4]
RFC 3949 File Format for Internet Fax February 2005
This specification of TIFF for facsimile is known as TIFF-FX (TIFF
for Fax eXtended). References to the format described by this
specification should always use the term "TIFF-FX", and some profiles
in this specification may not be interpreted correctly by other TIFF
applications.
1.1. Scope
This document defines a TIFF-based file format specification for
enabling standardized messaging-based fax over the Internet. It
specifies the TIFF fields and field values required for compatibility
with the existing ITU-T Recommendations for Group 3 black-and-white,
grayscale, and color facsimile. TIFF has historically been used for
handling fax image files in 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 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 describing TIFF and defining TIFF fields. This document is the
primary reference for defining TIFF field values for fax
applications.
1.2. Approach
The basic approach to using TIFF for facsimile data is to insert the
compressed fax image data into a TIFF file and use TIFF fields to
encode the parameters that describe the image data. These fields
will have values that comply with the ITU-T Recommendations.
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 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. Overview of this Document
Section 2 gives an overview of TIFF. Section 2.1 describes the
structure of TIFF files, including general guidelines for structuring
multi-page TIFF files. Section 2.2 lists the TIFF fields that are
required or recommended for all fax profiles. The TIFF fields used
Buckley, et al. Standards Track [Page 5]
RFC 3949 File Format for Internet Fax February 2005
only by specific fax profiles are described in Sections 3 - 8, which
describe the individual fax profiles. These sections also specify
the ITU-compatible field values (image parameters) for each profile.
The full set of permitted fields of TIFF for facsimile are included
in the current TIFF specification, Section 2 of this document, and
the sections on specific profiles of facsimile operation. This
document defines profiles of TIFF for facsimile, where a profile is a
subset of the full set of permitted fields and field values of TIFF
for facsimile.
Section 3 defines the minimal black-and-white facsimile profile
(Profile S), which is required in all implementations. Section 4
defines the extended black-and-white fax profile (Profile F), which
provides a standard definition of TIFF-F. Section 5 describes the
lossless black-and-white profile using JBIG compression (Profile J).
Section 6 defines the base color profile, required in all color
implementations, for the lossy JPEG representation of color and
grayscale facsimile data (Profile C). Section 7 defines the lossless
JBIG color and grayscale facsimile profile (Profile L), and Section 8
defines the Mixed Raster Content facsimile profile (Profile M). Each
of these sections concludes with a table summarizing the required and
recommended fields for each profile and the values they can have.
Section 9 refers to the MIME content types used in connection with
TIFF for facsimile. Sections 10 and 11 give Security Considerations
and References, followed by Authors' Addresses and the Copyright
Notice. Annex A gives a summary of the TIFF fields used or defined
in this document and provides a convenient reference for
implementors.
To implement only the minimal interchange black-and-white set of
fields and values (Profile S), one need read only Sections 1, 2, 3,
9, and 10.
The following tree diagram shows the relationship among profiles and
between profiles and coding methods.
Buckley, et al. Standards Track [Page 6]
RFC 3949 File Format for Internet Fax February 2005
S (MH)
/ \
B&W / \ Color
------------ ----------
/ \ \
/ F (MH, MR, MMR) C (JPEG)
/ / \
J (JBIG) ---- \
/ \
L (JBIG) \
\
M (MRC)
A profile is based on a collection of ITU-T facsimile coding methods.
For example, Profile S, the minimal profile, is based on Modified
Huffman (MH) compression, which is defined in ITU-T Rec. T.4.
Profile F specifies Modified Huffman (MH), Modified READ (MR), and
Modified Modified READ (MMR) compressions, which are defined in ITU-T
Rec. T.4 and T.6.
All implementations of TIFF for facsimile MUST implement Profile S,
which is the root node of the tree. All color implementations of
TIFF for facsimile MUST implement Profile C. The implementation of a
particular profile MUST also implement those profiles on the path
that connect it to the root node, and MAY optionally implement
profiles not on the path connecting it to the root node. For
example, an implementation of Profile M must also implement Profiles
C and S and may optionally implement Profile F, J, or L. For another
example, an implementation of Profile C must also implement Profile S
and may optionally implement Profile F or J.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [REQ].
2. TIFF and Fax
2.1. TIFF Overview
TIFF provides a means for describing, storing, and interchanging
raster image data. A primary goal of TIFF is 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, the
set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical Note
2 [TTN2] define several TIFF extensions. The TIFF-based
specification for fax applications uses a subset of Baseline TIFF
Buckley, et al. Standards Track [Page 7]
RFC 3949 File Format for Internet Fax February 2005
fields, with selected extensions, as described in this document. In
a few cases, this document defines new TIFF fields specifically for
fax applications.
2.1.1. File Structure
TIFF is designed for raster images, which makes it a good match for
facsimile documents, which are multi-page 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 or component (exactly one for black-and-white
images).
A TIFF file begins with an 8-byte image file header. The first two
bytes describe the byte order used within 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 profile, which SHALL use value "II". The next two
bytes contain the value 42, which 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 points to the first
image file directory (IFD). 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.
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 field entry in an IFD has 12 bytes and consists of a 2-byte Tag,
2 bytes identifying the field type (e.g., short, long, rational,
ASCII), 4 bytes giving the count (number of values or offsets), and 4
bytes containing either the offset to a field value stored outside
the IFD or, based on the type and count, the field value itself.
Resolution and metadata such as dates, names, and descriptions are
examples of "long" field values that do not fit in 4 bytes and
therefore use offsets 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
Buckley, et al. Standards Track [Page 8]
RFC 3949 File Format for Internet Fax February 2005
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.
All fax profiles 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 in ascending order,
starting at 0 for the first page. Although 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 profile, described
in Section 8, requires the use of child IFDs.
Buckley, et al. Standards Track [Page 9]
RFC 3949 File Format for Internet Fax February 2005
The following figure illustrates the structure of a multi-page TIFF
file.
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 0 | | |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 1) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 1 | | |
+-----------------------+ | |
| strip 2 page 1 |<-+ |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 2) |<-----------+ Offset
| : |
2.1.2. Image Structure
An IFD stores an image as one or more strips, as shown in the
preceding figure. 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 recommends about 8k
bytes per strip, but existing fax usage is typically one strip per
image.)
Each IFD requires three strip-related fields: StripOffsets,
RowsPerStrip, and StripByteCounts. The StripOffsets 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
Buckley, et al. Standards Track [Page 10]
RFC 3949 File Format for Internet Fax February 2005
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 profile (Section 8).
Image data is stored as uninterpreted, compressed image 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 add new compression
schemes gracefully 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, 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. TIFF File Structure for Fax Applications
The TIFF specification has a very flexible file structure that does
not specify the ordering of IFDs, field values, and image data in a
file. Individual applications may require or recommend an ordering.
This specification recommends that when using a TIFF file for
facsimile, a multi-page fax document SHOULD be represented as a
linked list of IFDs. It also recommends that a TIFF file for
facsimile SHOULD order pages in a TIFF file in the same way that they
are ordered in a fax data stream. In a TIFF file, a page consists of
several elements: one or more IFDs (including subIFDs), long field
values that are stored outside the IFDs, and image data (in one or
more strips).
The minimal black-and-white profile (Profile S) specifies a required
ordering of pages and elements within a page (Section 3.5). The
extended black-and-white profile (Profile F) provides guidelines for
ordering pages and page elements (Section 4.4.6). Other profiles
SHOULD follow these guidelines. This recommendation is intended to
simplify the implementation of TIFF writers and readers in fax
applications and the conversion between TIFF file and fax data stream
representations. However, for interchange robustness, readers SHOULD
Buckley, et al. Standards Track [Page 11]
RFC 3949 File Format for Internet Fax February 2005
be prepared to read TIFF files whose structure is consistent with
[TIFF], which supports a more flexible file structure than is
recommended here.
This specification introduces an optional new GlobalParametersIFD
field, defined in Section 2.2.4. This field has type IFD and
indicates parameters describing the fax session. While it is often
possible to obtain these parameters by scanning the file, it is
convenient to make them available together in one place for fast and
easy access. If the GlobalParametersIFD occurs in a TIFF file, it
SHOULD be located in the first IFD, immediately following the 8-byte
image file header.
2.2. TIFF Fields for All Fax Applications
The TIFF specification [TIFF] is organized as a baseline set and
several extensions, including technical notes [TTN1, TTN2] that will
be incorporated in the next release of TIFF. The baseline and
extensions have required and optional fields.
Facsimile applications require (and recommend) a mixture of baseline
and extensions fields, as well as some new fields that are not part
of the TIFF specification and that are defined in this document.
This sub-section lists the fields that are required or recommended
for all profiles. In particular, Section 2.2.1 lists the fields that
are required by all profiles and that have values that do not depend
on the profile. Section 2.2.2 lists the fields that are required by
all profiles and that have values that do depend on the profile.
Section 2.2.3 lists the fields that are recommended for all profiles.
Fields required or recommended by some but not all profiles are given
in the section (Section 3 - 8) that describes that profile. The
sections for each fax profile have subsections for required and
recommended fields; each subsection organizes the fields according to
whether they are baseline, extension or new.
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 the
ITU-T Recommendations. The required and optional values are noted in
the sections on the different fax profiles.
Buckley, et al. Standards Track [Page 12]
RFC 3949 File Format for Internet Fax February 2005
This section describes the fields required or recommended by all fax
profiles. The pattern for the description of TIFF fields in this
document is as follows:
FieldName(TagValueInDecimal) = allowable values.
TYPE
WhetherRequiredByTIFForTIFFforFAX
Count = (omitted if =1) = (if not in current spec but available)
Explanation of the field, how it's used, and the values it can
have. Default value, if any, as specified in [TIFF].
When a field's default value is the desired value, that field may be
omitted from the relevant IFD unless specifically required by the
text of this specification.
2.2.1. TIFF fields required for all fax profiles
The TIFF fields listed in this section SHALL be used by all fax
profiles but have field values that are not specified by the ITU
standards, i.e., the fields do not depend on the profile. The next
subsection lists the fields that SHALL be used by all fax profiles,
but which do have values specified by the ITU-specified or profile-
specific values. Fields that SHALL be used by some but not all
profiles are given in the Sections (3 - 8) that describe the profiles
that use them.
ImageLength(257)
SHORT or LONG
RequiredByTIFFBaseline
Total number of scanlines in image.
No default, must be specified.
PageNumber(297)
SHORT
RequiredByTIFFforFAX, TIFFExtension
Count = 2
The first number represents the page number (0 for the first
page); the second number is the total number of pages in the
document. If the second value is 0, then the total page count is
not available.
No default, must be specified
Buckley, et al. Standards Track [Page 13]
RFC 3949 File Format for Internet Fax February 2005
RowsPerStrip(278)
SHORT or LONG
RequiredByTIFFBaseline
The number of scanlines per TIFF strip, except for the last 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.
StripOffsets(273)
SHORT or LONG
RequiredByTIFFBaseline
Count = number of strips
For each strip, the byte offset from the beginning of the file to
the start of that strip.
No default, must be specified.
2.2.2. Additional TIFF fields required for all fax profiles
The TIFF fields listed in this section SHALL be used by all fax
profiles, but the values associated with them depend on the profile
being described and the associated ITU Recommendations. Therefore,
only the fields are defined here; the values applicable to a
particular fax profile are described in Sections 3 - 8. Fields that
SHALL be used by some but not all profiles are given in the section
(3 - 8) describing the profile that uses them.
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 image data.
Default = 1 (no compression, so may not be omitted for FAX).
Buckley, et al. Standards Track [Page 14]
RFC 3949 File Format for Internet Fax February 2005
FillOrder(266)
SHORT
RequiredByTIFFforFax
The default bit order in Baseline TIFF per [TIFF] is indicated by
FillOrder=1, where bits are not reversed before being stored.
However, TIFF for Fax typically uses the setting of FillOrder=2,
where the bit order within bytes is reversed before storage (i.e.,
bits are stored with the Least Significant Bit first).
Default = 1 (field may be omitted if this is the value)
Facsimile data appears on the phone line in bit-reversed order
relative to its description in the relevant ITU compression
Recommendation. Therefore, a wide majority of facsimile
implementations choose this natural order for storage.
Nevertheless, all readers conforming to this specification must be
able to read data in both bit orders, except in the case of
Profile S, which only requires support for FillOrder=2 (Least
Significant Bit first).
ImageWidth(256)
SHORT or LONG
RequiredByTIFFBaseline
The number of pixels (columns) per scanline (row) of the image
No default, must be specified.
NewSubFileType(254)
LONG
RequiredByTIFFforFAX
A general indication of the kind of data contained in this IFD Bit
1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for FAX).
PhotometricInterpretation(262)
SHORT
RequiredByTIFFBaseline
The color space of the image data.
No default, must be specified.
ResolutionUnit(296)
SHORT
RequiredByTIFFBaseline The unit of measure for resolution. 2 =
inch, 3 = centimeter; Default = 2 (field may be omitted if this is
the value)
Buckley, et al. Standards Track [Page 15]
RFC 3949 File Format for Internet Fax February 2005
SamplesPerPixel(277)
SHORT
RequiredByTIFFBaseline
The number of color components per pixel; SamplesPerPixel is 1 for
a black-and-white, grayscale or indexed (palette) image. Default
= 1 (field may be omitted if this is the value).
XResolution(282)
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image in pixels per resolution
unit. The ITU-T Recommendations for facsimile specify a small
number of horizontal resolutions: 100, 200, 300, 400 pixels per
inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per
inch). The allowed XResolution values for each profile are given
in the section defining that profile. Per [T.4], it is
permissible for applications to treat the following XResolution
values as being equivalent: <204, 200> and <400,408> in
pixels/inch. These equivalencies were allowed by [T.4] to permit
conversions between inch and metric based facsimile terminals. To
ensure interoperability, if an application accepts any member of
the pairs then T.4 requires it to accept both (e.g., accept 204 if
200 pixels per inch is accepted). TIFF for Facsimile Writers
SHOULD express XResolution in inch-based units, for consistency
with historical practice and to maximize interoperability. See
the table below for information on how to convert from an ITU-T
metric value to its inch-based equivalent resolution.
No default, must be specified
YResolution(283)
RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image in pixels per resolution
unit. The ITU-T Recommendations for facsimile specify a small
number of vertical resolutions: 100, 200, 300, 400 pixels per
inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391
pixels per inch). The allowed YResolution values for each profile
are given in the section defining that profile. Per [T.4], it is
permissible for applications to treat the following YResolution
values as being equivalent: <98, 100>, <196, 200>, and <391, 400>
in pixels/inch. These equivalencies were allowed by [T.4] to
permit conversions between inch- and metric-based facsimile
terminals. To insure interoperability, if an application accepts
any member of the pairs, then T.4 requires it to accept both
(e.g., accept 98 if 100 pixels per inch is accepted). TIFF for
Facsimile Writers SHOULD express YResolution in inch-based units,
for consistency with historical practice and to maximize
Buckley, et al. Standards Track [Page 16]
RFC 3949 File Format for Internet Fax February 2005
interoperability. See the table below for information on
converting from the metric value to its inch based equivalent
resolution.
No default, must be specified.
+-----------------------------+-----------------------------+
| XResolution | YResolution |
+--------------+--------------+--------------+--------------+
|ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit|
| =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) |
+--------------+--------------+--------------+--------------+
| 100 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 98 | 38.5 |
| 200 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 196 | 77 |
| 200 | | 200 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 391 | 154 |
+--------------+--------------+--------------+--------------+
| 300 | | 300 | |
+--------------+--------------+--------------+--------------+
| 408 | 160 | 391 | 154 |
| 400 | | 400 | |
+--------------+--------------+--------------+--------------+
2.2.3. TIFF fields recommended for all fax profiles
The TIFF fields listed in this section MAY be used by all fax
profiles. However, Profile S writers (the minimal fax profile
described in Section 3) SHOULD NOT use these fields. Recommended
fields that are profile-specific are described in Sections 3 - 8.
DateTime(306)
ASCII
OptionalInTIFFBaseline
Date/time of image creation in 24-hour format
"YYYY:MM:DD HH:MM:SS". No default.
DocumentName(269)
ASCII
OptionalInTIFFExtension(DocumentStorageAndRetrieval)
The name of the scanned document. This is a TIFF extension field,
not a Baseline TIFF field. No default.
Buckley, et al. Standards Track [Page 17]
RFC 3949 File Format for Internet Fax February 2005
ImageDescription(270)
ASCII
OptionalInTIFFBaseline
A string describing the contents of the image.
No default.
Orientation(274) = 1 - 8.
SHORT
OptionalinTIFFBaseline 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 spec [TIFF] for further values;
Baseline TIFF only requires value=1. Default = 1.
Note: It is recommended that a writer that is aware of the
orientation include this field to give a positive indication of
the orientation, even if the value is the default. Writers should
not generate mirror images, because many readers will not properly
reverse the image before display or print.
Software(305)
ASCII
OptionalInTIFFBaseline
The name and release number of the software package that
created the image.
No default.
2.2.4. New TIFF fields recommended for fax profiles
The new TIFF fields listed in this section MAY be used by all fax
profiles. However, Profile S writes (the minimal fax profile
described in Section 3) SHOULD NOT use these fields. In addition,
support for these new TIFF fields has not been included in historical
TIFF-F readers described in Section 4 and [TIFF-F]. 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 (400) IFD or LONG
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
Buckley, et al. Standards Track [Page 18]
RFC 3949 File Format for Internet Fax February 2005
conflict exists between fields in the GlobalParametersIFD and in
the image IFDs, then the data in the image IFD shall prevail.
Among the GlobalParametersIFD entries is a new ProfileType field
that generally describes information in this IFD and in the TIFF
file.
ProfileType(401)
LONG
The type of image data stored in this IFD.
0 = Unspecified
1 = Group 3 fax
No default
The following new global fields are defined in this document as IFD
entries for use with fax applications.
FaxProfile(402) = 0 - 6.
BYTE
The profile that applies to this file; a profile is subset of the
full set of permitted fields and field values of TIFF for
facsimile. The currently defined values are:
0: does not conform to a profile defined for TIFF for facsimile
1: minimal black & white lossless, Profile S
2: extended black & white lossless, Profile F
3: lossless JBIG black & white, Profile J
4: lossy color and grayscale, Profile C
5: lossless color and grayscale, Profile L
6: Mixed Raster Content, Profile M
CodingMethods(403)
LONG
This field indicates which coding methods are used in the file. A
value of 1 in a bit location indicates the corresponding coding
method is used. More than one bit set to 1 means more than one
coding method is used in the file.
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)
Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG)
Bit 5: ITU-T Rec. T.81 (Baseline JPEG)
Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color)
Bits 7 - 31: reserved for future use
Buckley, et al. Standards Track [Page 19]
RFC 3949 File Format for Internet Fax February 2005
Note: There is a limit of 32 compression types to identify standard
compression methods.
VersionYear(404)
BYTE
Count: 4
The year of the standard specified by the FaxProfile field, given
as 4 characters, e.g., '1997'; used in lossy and lossless color
profiles.
ModeNumber (405)
BYTE
The mode of the standard specified by the FaxProfile field. A
value of 0 indicates Mode 1.0; used in Mixed Raster Content
profile.
3. Profile S: Minimal Black-and-White Fax Profile
This section defines the minimal black-and-white subset of TIFF for
facsimile. This subset is designated Profile S. All implementations
of TIFF for facsimile SHALL support the minimal subset.
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 fields that must be supported by all implementations in order to
assure that some form of image, albeit black-and-white, can be
interchanged. This minimum interchange set is a strict subset of the
fields and values defined for the extended black-and-white profile
(TIFF-F or Profile F) in Section 4, which 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 1-dimensional Modified Huffman (MH) compression, with the
original Group 3 fax resolutions, commonly called "standard" and
"fine."
To assure interchange, this profile uses the minimal set of fields
with a minimal set of values. There are no recommended fields in
this profile. Further, the TIFF file is required to be "little-
endian", which means that the byte order value in the TIFF header is
"II". This profile defines a required ordering for the pages in a
fax document and for the IFDs and image data of a page. It also
requires
Buckley, et al. Standards Track [Page 20]
RFC 3949 File Format for Internet Fax February 2005
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 profile requires the following fields. The fields listed
in Section 2.2.1 and the fields and fax-specific values specified in
this subsection must be supported by all implementations.
3.2.1. Baseline 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
3 = 1- or 2- dimensional coding.
The value 3 is a TIFF extension value [TIFF]. The T4Options field
must be specified, and its value specifies that the data is
encoded with the Modified Huffman (MH) compression of [T.4].
FillOrder(266) = 2.
SHORT
RequiredByTIFFBaseline
2 = Least Significant Bit first
NOTE: Baseline TIFF readers are only required to support 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 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 profile.
ImageWidth(256) = 1728.
SHORT or LONG
RequiredByTIFFBaseline
This profile only supports a page width of 1728 pixels. This
width corresponds to North American Letter and Legal and to ISO A4
size pages. No default, must be specified.
Buckley, et al. Standards Track [Page 21]
RFC 3949 File Format for Internet Fax February 2005
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
PhotometricInterpretation(262) = 0.
SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means 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).
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) = 200, 204.
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 200 and
204, which may be treated as equivalent. See Section 2.2.2 for
inch metric equivalency. No default, must be specified.
YResolution(283) = 98, 100, 196, 200.
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, and 200; 98 and 100 may be
treated as equivalent, and 196 and 200 may be treated as
equivalent. See Section 2.2.2 for inch metric equivalency. No
default, must be specified.
Buckley, et al. Standards Track [Page 22]
RFC 3949 File Format for Internet Fax February 2005
3.2.2. Extension fields
T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
LONG
RequiredTIFFExtension (when Compression = 3)
Bit 0 = 0 indicates MH compression.
Bit 1 must be 0.
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned.
Default is all bits are 0 (applies when EOLs are not byte aligned)
Note: The T4Options field is required when the Compression field has
a value of 3. Bit 0 of this field specifies the compression used (MH
only in this profile). MH coding requires the use of EOL (End of
Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned
or not. See Section 3.4 for details.
3.2.3. New Fields
None.
3.3. Recommended TIFF Fields
None.
3.4. End of Line (EOL) and Return to Control (RTC)
TIFF extensions for fax, used in this specification, differ from
Baseline TIFF in the following ways:
- A 12-bit EOL sequence MUST precede each line of MH-compressed
image data. (Baseline TIFF does not use these EOL sequences.)
- The EOL sequence MAY be byte-aligned, in which case fill bits are
added so that the EOL sequence ends on a byte boundary, and any
subsequent image data begins on a byte boundary.
- If the EOL codes are not byte aligned, the image data MAY be
followed by an RTC (Return to Control) sequence, consisting of 6
consecutive EOLs.
In conventional fax, an MH-compressed fax data stream for a page
consists of the following sequence:
EOL, compressed data (first line), EOL, compressed data, ... ,
EOL, compressed data (last line), RTC (6 consecutive EOL codes)
Baseline TIFF does not use EOL codes or Return to Control (RTC)
sequences for MH-compressed data. However, the TIFF extension field
T4Options used in this specification for MH compression (Compression
= 3) requires EOLs.
Buckley, et al. Standards Track [Page 23]
RFC 3949 File Format for Internet Fax February 2005
Furthermore, Bit 2 in the T4Options field indicates whether or not
the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL
codes are byte aligned, then fill bits have been added as necessary
before EOL codes so that an EOL code always ends on a byte boundary,
and the first bit of data following an EOL begins on a byte boundary.
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 scanlines for line-oriented image
manipulation (such as writing a TIFF file). Not all TIFF readers
historically used for fax are able to deal with non byte aligned
data.
While TIFF extension requires EOL codes, TIFF in fax applications has
traditionally prohibited RTC sequences. Implementations that seek
common processing and interfaces for fax data streams and Internet
fax files would prefer that the TIFF data include RTC sequences.
To reconcile these differences, RTCs are allowed in cases where EOL
codes are not byte aligned and no fill bits have been added to the
data. This corresponds to situations where the fax data is simply
inserted in a strip without being processed or interpreted. RTCs
should not occur in the data when EOLs have been byte aligned. This
is formally specified in the next subsection.
3.4.1. RTC Exclusion
Implementations that seek to maintain strict conformance with TIFF
and compatibility with the historical use of TIFF for fax SHOULD NOT
include the RTC sequence when writing TIFF files. However,
implementations that need to support "transparency" of T.4-generated
image data MAY include RTCs when writing TIFF files if the flag
settings of the T4Options field are set for non byte aligned data,
i.e., Bit 2 is 0. Implementors of TIFF readers should be aware that
there are some existing TIFF implementations for fax that include the
RTC sequence in MH image data. Therefore, minimal set readers MUST
be able to process files that do not include RTCs and SHOULD be able
to process files that do include RTCs.
3.5. File Structure
The TIFF header, described in Section 2.1.1, contains two bytes that
describe the byte order used within the file. For the minimal
black-and-white profile, these bytes SHALL have the value "II"
(0x4949), denoting that the bytes in the TIFF file are in LSByte-
first order (little-endian). The first or 0th IFD immediately
follows the header, so offset to the first IFD is 8. The header
values are shown in the following table:
Buckley, et al. Standards Track [Page 24]
RFC 3949 File Format for Internet Fax February 2005
+--------+-------------------+--------+-----------+
| Offset | Description | Value |
+--------+-------------------+--------+-----------+
| 0 | Byte Order | 0x4949 (II) |
+--------+-------------------+--------+-----------+
| 2 | Identifier | 42 decimal |
+--------+-------------------+--------+-----------+
| 4 | Offset of 0th IFD | 0x 0000 0008 |
+--------+-------------------+--------+-----------+
The minimal black-and-white profile SHALL order IFDs and image data
within a file as follows: (1) There SHALL be an IFD for each page in
a multi-page fax document; (2) the IFDs SHALL occur in the same order
in the file as the pages occur in the document; (3) the IFD SHALL
precede the image data to which it has offsets; (4) the image data
SHALL occur in the same order in the file as the pages occur in the
document; (5) the IFD, the value data, and the image data to which it
has offsets SHALL precede the next image IFD; and (6) the image data
for each page SHALL be contained within a single strip.
As a result of (6), the StripOffsets field will contain the pointer
to the image data. With two exceptions, the field entries in the IFD
contain the 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. These "long" field values SHALL be
placed immediately after the IFD which containing the offsets to
them, and before the image data pointed to by that IFD.
The effect of these requirements is that the IFD for the first page
SHALL come first in the file after the TIFF header, followed by the
long field values for XResolution and YResolution, followed by the
image data for the first page, then the IFD for second page, and so
on. This is shown in the following figure. Each IFD is required to
have a PageNumber field, which has value 0 for the first page, 1 for
the second page, and so on.
Buckley, et al. Standards Track [Page 25]
RFC 3949 File Format for Internet Fax February 2005
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| 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
+-----------------------+
| : |
Using this file structure may reduce the memory requirements in
implementations. It also provides some support for streaming, in
which a file can be processed as it is received and before the entire
file is received.
3.6. Profile S: Minimal Black-and-White Profile Summary
The table below summarizes the TIFF fields that compose the minimal
interchange set for black-and-white facsimile. The Baseline and
Extension fields and field values MUST be supported by all
implementations. For convenience, certain fields that have a value
that is a sequence of flag bits are shown with integer values
corresponding to the flags that are set. An implementation should
test the 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.)
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1 |
+---------------------------+--------------------------------+
| Compression | 3: 1D Modified Huffman coding |
| | set T4Options = 0 or 4 |
+------------------------------------------------------------+
Buckley, et al. Standards Track [Page 26]
RFC 3949 File Format for Internet Fax February 2005
+---------------------------+--------------------------------+
| FillOrder | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageWidth | 1728 |
+---------------------------+--------------------------------+
| ImageLength | n: total number of scanlines |
| | in 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 |
+---------------------------+--------------------------------+
| ResolutionUnit | 2: inch |
+---------------------------+--------------------------------+
| RowsPerStrip | number of scanlines per strip |
| | = ImageLength, with one strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1 |
+---------------------------+--------------------------------+
| StripByteCounts | number of bytes in TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets | offset from beginning of |
| | file to single TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 204, 200 (pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98, 196, 100, 200 (pixels/inch)|
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 0: MH coding, EOLs not byte |
| | aligned |
| | 4: MH coding, EOLs byte aligned|
+---------------------------+--------------------------------+
4. Profile F: Extended Black-and-White fax profile
This section defines the extended black-and-white profile or Profile
F of TIFF for facsimile. It provides a standard definition of what
has historically been known as TIFF Class F and now as TIFF-F. In
doing so, it aligns this profile with current ITU-T Recommendations
for black-and-white fax and with existing industry practice.
Implementations of this profile include implementations of Profile S.
Buckley, et al. Standards Track [Page 27]
RFC 3949 File Format for Internet Fax February 2005
This section describes extensions to the minimal interchange set of
fields (Profile S) that provide a richer set of black-and-white
capabilities. The fields and values described in this section are a
superset of the fields and values defined for the minimal interchange
set in Section 3. In addition to the MH compression, Modified READ
(MR) and Modified Modified READ (MMR) compression, as described in
[T.4] and [T.6] are supported.
Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the
TIFF fields that SHALL be used in this profile. Section 4.3
describes the fields that MAY be used in this profile. 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 of TIFF-F use. Section 4.7 gives a summary of the required
and recommended fields and their values.
4.1. TIFF-F Overview
Though it has been in common use 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 noted in
[TIFF], but it is not defined. This document serves as the formal
definition of the F application of [TIFF] for Internet applications.
For ease of reference, the term TIFF-F will be used throughout this
document as a shorthand for the extended black-and-white profile of
TIFF for facsimile.
Up until the TIFF 6.0 specification, TIFF supported various "Classes"
that 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
concept of Baseline TIFF. Therefore, this document updates the
definition of TIFF-F as the F profile of TIFF for facsimile, by using
Baseline TIFF as defined in [TIFF] as the starting point and then
adding the TIFF extensions to Baseline TIFF that apply for TIFF-F.
In almost all cases, the resulting definition of TIFF-F fields and
values remains consistent with those used historically in earlier
definitions of TIFF Class F. Where some of the values for fields
have been updated to provide more precise conformance with the ITU-T
[T.4] and [T.30] fax recommendations, these differences are noted.
Buckley, et al. Standards Track [Page 28]
RFC 3949 File Format for Internet Fax February 2005
4.2. Required TIFF Fields
This section lists the required fields and the values they must have
to be ITU-compatible. Besides the fields listed in Section 2.2.1,
the extended black-and-white fax profile SHALL use the following
fields.
4.2.1. Baseline fields
BitsPerSample(258) = 1.
SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)
Compression(259) = 3, 4.
SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding, must have T4Options field This is
a TIFF Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
READ, must have T6Options field)) This is a TIFF Extension value.
Default = 1 (and is not applicable; field must be specified)
NOTE: Baseline TIFF permits use of value 2 for Modified Huffman
compression, but data is presented in a form that does not use EOLs,
and so TIFF for facsimile uses Compression=3 instead. See Sections
4.4.4, 4.5.1, and 4.5.2 for more information on compression and
encoding.
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile F readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first.
ImageWidth(256)
SHORT or LONG
RequiredByTIFFBaseline
This profile supports the following fixed page widths: 1728, 2592,
3456 (corresponding to North American Letter and Legal and ISO A4
paper sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper
size), and 2432, 3648, 4864 (corresponding to ISO A3 paper size).
No default; must be specified.
Buckley, et al. Standards Track [Page 29]
RFC 3949 File Format for Internet Fax February 2005
NOTE: Historical TIFF-F did not include support for the following
widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096,
and 4864. Historical TIFF-F documents also included the following
values related to A5 and A6 widths: 816 and 1216. Per the most
recent version of [T.4], A5 and A6 documents are no longer supported
in Group 3 facsimile, so the related width values are now obsolete.
See section 4.5.2 for more information on inch/metric equivalencies
and other implementation details.
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
NOTE: Bit 1 is always set to 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 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 measurement.
Default = 2 (field may be omitted if this is the value).
SamplesPerPixel(277) = 1.
SHORT
RequiredByTIFFBaseline
1 = monochrome, bi-level in this case (see BitsPerSample).
Default = 1 (field may be omitted if this is the value).
XResolution(282) = 200, 204, 300, 400, 408
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 408. See Section 2.2.2 for inch metric equivalency.
No default, must be specified.
Buckley, et al. Standards Track [Page 30]
RFC 3949 File Format for Internet Fax February 2005
NOTE: The values of 200 and 408 have been added to the historical
TIFF-F values, for consistency with [T.30]. Some existing TIFF-F
implementations may also support values of 80 pixels/cm, which is
equivalent to 204 pixels per inch. See section 4.5.2 for information
on implementation details.
YResolution(283) = 98, 100, 196, 200, 300, 391, and 400
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, 391, and 400 pixels/inch. See Section 2.2.2 for
inch metric equivalency.
No default, must be specified
NOTE: The values of 100, 200, and 391 have been added to the
historical TIFF-F values, for consistency with [T.30]. Some existing
TIFF-F implementations may also support values of 77 and 38.5 (cm),
which are equivalent to 196 and 98 pixels per inch, respectively. See
section 4.5.2 for more information on implementation details.
NOTE: Not all combinations of XResolution, YResolution, and
ImageWidth are legal. The following table gives the legal
combinations and corresponding paper sizes [T.30].
+--------------+-----------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------+-----------------+---------+--------+--------+
| 200x100, 204x98 | | | |
| 200x200, 204x196 | 1728 | 2048 | 2432 |
| 204x391 | | | |
+--------------+-----------------+---------+--------+--------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------+-----------------+---------+--------+--------+
| 408 x 391, 400 x 400 | 3456 | 4096 | 4864 |
+--------------+-----------------+---------+--------+--------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+
Buckley, et al. Standards Track [Page 31]
RFC 3949 File Format for Internet Fax February 2005
4.2.2. Extension fields
T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1)
LONG
RequiredTIFFExtension (when Compression = 3)
T4Options was also known as Group3Options in a prior version of
[TIFF].
Bit 0 = 1 indicates MR compression, = 0 indicates MH compression.
Bit 1 must be 0.
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned.
Default is all bits are 0 (applies when MH compression is used and
EOLs are not byte aligned) (See Section 3.2.2.) The T4Options
field is required when the Compression field has a value of 3.
This field specifies the compression used (MH or MR) and whether
the EOL codes are byte aligned or not. If they are byte aligned,
then fill bits have been added as necessary so that the End of
Line (EOL) codes always end on byte boundaries. See Sections 3.4,
4.5.3, and 4.5.4 for details.
T6Options(293) = (Bit 0 = 0, Bit 1 = 0).
LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified READ
(MMR) compression. T6Options was also known as Group4Options in a
prior version of [TIFF]. Bit 0 must be 0.
Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
indicates that uncompressed data is allowed (see [TIFF]). Default
is all bits 0. For FAX, the field must be present and 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
None.
4.3. Recommended TIFF fields
4.3.1. Baseline fields
See Section 2.2.3.
Buckley, et al. Standards Track [Page 32]
RFC 3949 File Format for Internet Fax February 2005
4.3.2. Extension fields
See Section 2.2.3.
4.3.3. New fields
See Section 2.2.4 and optional fields below.
Three new, optional fields, used in the 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 error content of the
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 data, the quality of a received
page must be inferred from the pixel count of decoded scanlines. A
"good" scan line is defined as a line that, when decoded, contains
the correct number of pixels. Conversely, a "bad" scanline is
defined as a line that, when decoded, contains an incorrect number of
pixels.
BadFaxLines(326)
SHORT or LONG
The number of "bad" scanlines encountered by the facsimile device
during reception. A "bad" scanline is defined as a scanline that,
when decoded, comprises an incorrect number of pixels. Note that
PercentBad = (BadFaxLines/ImageLength) * 100.
No default.
CleanFaxData(327) = 0, 1, 2.
SHORT
Indicates whether "bad" lines encountered during reception are
stored in the data, or whether "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 place of a bad line.
Although this substitution, known as line regeneration, results in a
visual improvement to the image, the data is nevertheless corrupted.
The CleanFaxData field describes the error content of the data. That
Buckley, et al. Standards Track [Page 33]
RFC 3949 File Format for Internet Fax February 2005
is, when the BadFaxLines and ImageLength fields indicate that the
facsimile device encountered lines with an incorrect number of pixels
during reception, the CleanFaxData field indicates whether these bad
lines are actually still in the data or whether the receiving
facsimile device replaced them with regenerated lines.
ConsecutiveBadFaxLines(328)
LONG or SHORT
Maximum number of consecutive "bad" scanlines received. The
BadFaxLines field indicates only the quantity of bad lines.
No Default.
NOTE: The BadFaxLines and ImageLength data indicate only the quantity
of bad lines. The ConsecutiveBadFaxLines field is an indicator of
the distribution of bad lines and may therefore be a better general
indicator of perceived image quality. See Section 4.4.5 for examples
of the use of these fields.
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 few scanlines of the image. By using
strips, a TIFF reader need not load the entire image into memory,
enabling it to fetch and decompress small random portions of the
image as necessary.
The number of scanlines in a strip is described by the RowsPerStrip
value and the number of bytes in the strip after compression by the
StripByteCount value. The location in the TIFF file of each strip is
given by the StripOffsets values.
Strip size is application dependent. The recommended approach for
multi-page TIFF-F images is to represent each page as a single strip.
Existing TIFF-F usage is typically one strip per 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 recommends that
FillOrder=2 be used only in special purpose applications.
Buckley, et al. Standards Track [Page 34]
RFC 3949 File Format for Internet Fax February 2005
Facsimile data appears on the phone line in bit-reversed order
relative to its description in ITU-T Recommendation T.4. Therefore,
most facsimile applications choose this natural order for data in a
file. Nevertheless, TIFF-F readers must be able to read data in both
bit orders and 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 multi-page field. Since a multi-page format greatly
simplifies file management in fax application software, TIFF-F
specifies multi-page documents (NewSubfileType = 2) as the 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 produce individual single-page TIFF-F files
with modified NewSubFileType and PageNumber (page one-of-one) values
for export purposes. However, there is no easy way to link such
multiple single-page files together into a logical multiple-page
document, so this practice is not recommended.
4.4.4. Compression
In Group 3 facsimile, there are three compression methods which had
been standardized as of 1994 and are in common use. The ITU-T T.4
Recommendation [T.4] defines a one-dimensional compression method
known as Modified Huffman (MH) and 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 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 commonly
used 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 by setting the Compression field value to 4 and then setting
Buckley, et al. Standards Track [Page 35]
RFC 3949 File Format for Internet Fax February 2005
the first two bits (and all unused bits) of the T6Options field to 0.
More information to aid the implementor in making a compression
selection is contained in Section 4.5.2.
Baseline TIFF also permits use of Compression=2 to specify Modified
Huffman compression, but the data does not use EOLs. 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 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.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F
Files
Traditionally, TIFF-F has required readers and writers to be able to
handle multi-page TIFF-F files. The experience of various TIFF-F
implementors has shown that implementing TIFF-F can be greatly
simplified if certain practical guidelines are followed when writing
multi-page TIFF-F files.
The structure for a multi-page TIFF-F file will include one IFD per
document page. In this case, this IFD will define the attributes for
a single page. A second simplifying guideline is that the writer of
TIFF-F files SHOULD present IFDs in the same order as the actual
sequence of pages. (The pages are numbered within TIFF-F beginning
with page 0 as the first page and then ascending (i.e., 0, 1,
Buckley, et al. Standards Track [Page 36]
RFC 3949 File Format for Internet Fax February 2005
2, ...). However, any field values over 4 bytes will be stored
separately from the IFD. TIFF-F readers SHOULD expect IFDs to be
presented in page order but be able to handle exceptions.
Per [TIFF], the exact placement of image data is not specified.
However, the offsets for each image strip are defined from within
each IFD. Where possible, another guideline for TIFF-F writers is
that the image data for each page of a multi-page document SHOULD be
contained within a single strip (i.e., one image strip per fax page).
A single image strip per page further simplifies TIFF-F file writing
for applications such as store and forward messaging, where the file
is usually prepared in advance of the transmission, but other
assumptions may apply for the size of the image strip for
applications that require "streaming" techniques (see section 4.4.7).
If a different image strip size guideline has been used (e.g.,
constant size for image strips that may be less than the page size),
this will immediately be evident from the values/offsets of the
fields related to strips.
Another simplifying guideline is that each IFD SHOULD be placed in
the TIFF-F file structure at a point preceding the image that the IFD
describes.
In addition, placing the image data in a physical order within the
TIFF file structure which is consistent with the logical page order
simplifies TIFF-F file writing and reading. In practice, TIFF-F
readers will need to use the strip offsets to find the exact physical
location of the image data, whether or not it is presented in logical
page order.
If the image data is stored in multiple strips, then the strips
SHOULD occur in the file in the same order that the data they contain
occurs in the facsimile transmission, starting from the top of the
page.
TIFF-F writers MAY follow another simplifying guideline, in which the
IFD, the value data and the image data to which the IFD has offsets
precede the next image IFD. However, this guideline has been relaxed
compared to the others given here.
In the case of the minimal profile, which is also the minimal subset
of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs
(see Section 3.5).
A TIFF-F file structured using the guidelines of this section will
essentially consist of a linked list of IFDs, presented in ascending
page order, each pointing to a single page of image data
Buckley, et al. Standards Track [Page 37]
RFC 3949 File Format for Internet Fax February 2005
(one strip per page), where the pages of image data are also placed
in a logical page order sequence within the TIFF-F file structure.
(The pages of image data may themselves be stored in a contiguous
manner, at the option of the implementor).
4.4.7. Use of TIFF-F for Streaming Applications
TIFF-F has historically been used for handling fax image files in
applications such as store and forward messaging, where the entire
size of the file is known in advance. Although TIFF-F may also be
used as a file format for cases such as streaming applications,
assumptions differing from those provided in this section (e.g., the
entire size and number of pages within the image are not known in
advance) may be required. As a result, a definition for the
streaming application of TIFF-F is beyond the scope of this document.
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. 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
portability. However, implementors 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.
Implementors who wish to have the maximum flexibility in reading
TIFF-F files should support all three of these compression methods
(MH, MR, and MMR).
Almost all facsimile products support both standard (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 higher resolutions in the T.30
recommendation, including 200 x 200, 300 x 300, and 400 x 400 in dots
per inch-based units. At the same time, support was added for metric
dimensions equivalent to the following inch-based resolutions: 391v x
204h and 391v x 408h. Therefore, the full set of inch-based
equivalents of the new resolutions are supported in the TIFF-F
Buckley, et al. Standards Track [Page 38]
RFC 3949 File Format for Internet Fax February 2005
writer, as 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 not to support these
higher resolutions.
Per [T.4], it is permissible for applications to treat the following
XResolution values as equivalent: <204,200> and <400,408>.
Similarly, the following YResolution values may also be treated as
equivalent: <98, 100>, <196, 200>, and <391, 400>. These
equivalencies were allowed by [T.4] to permit conversions between
inch- and metric-based facsimile terminals.
The optional support of metric-based resolutions in the TIFF-F reader
(i.e., 77 x 38.5 cm) is included for completeness, as they are used
in some legacy TIFF-F applications, but this use is not recommended
for the creation of TIFF-F files by a writer.
4.5.3. EOL byte-aligned
The historical convention for TIFF-F has been that all EOLs in
Modified Huffman or Modified READ data must be 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 minimum subset of TIFF-F,
or Profile S, as defined in Section 3, includes support for both
byte-aligned and non-byte-aligned EOLs; see Section 3.2.2.
An EOL is said to be byte-aligned when Fill bits have been added as
necessary before EOL codes so that EOL always ends on a byte
boundary, thus ensuring an EOL sequence of a one byte preceded by a
zero nibble: xxxx0000 00000001.
Modified Huffman compression 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 the first bit of
data following an EOL begins on a byte boundary. In effect, 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).
For Modified READ compression, each line is terminated by an EOL and
a one-bit tag bit. Per [T.4], the value of the tag bit is 0 if the
next line contains two-dimensional data and 1 if the next line is a
reference line. To maintain byte alignment, fill bits are added
before the EOL/tag bit sequence so that the first bit of data
following an MR tag bit begins on a byte boundary.
Buckley, et al. Standards Track [Page 39]
RFC 3949 File Format for Internet Fax February 2005
4.5.4. EOL
As illustrated in FIGURE 1/T.4 in [T.4], MH-encoded facsimile
documents begin with an EOL, which in TIFF-F may be byte-aligned.
The last line of the image is not terminated by an EOL. Similarly,
respect, images encoded with Modified READ two-dimensional
compression begin with an EOL, followed by a tag bit.
4.5.5. RTC Exclusion
Aside from EOLs, TIFF-F files have historically only contained image
data. This means that applications seeking to maintain strict
conformance with the rules in [TIFF] and compatibility with
historical TIFF-F SHOULD NOT include the Return To Control sequence
(RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files.
However, applications intended to support "transparency" of [T.4]
image data MAY include RTCs if the flag settings of the T4Options
field are set for non byte aligned MH or MR image data. Implementors
of TIFF readers should also be aware that there are some existing
TIFF-F implementations that include the RTC sequence in MH/MR image
data. Therefore, TIFF-F readers MUST be able to process files that
do not include RTCs and SHOULD be able to process files that do
include RTCs.
4.5.6. Use of EOFB for T.6 Compressed Images
TIFF-F pages 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 byte boundary. TIFF readers SHOULD
ignore any bits other than pad bits beyond the EOFB.
4.6. Example Use of TIFF-F
The Profile F of TIFF (i.e., TIFF-F content) is a secondary component
of the VPIM Message, as defined in [VPIM 2]. Voice messaging systems
can often handle fax store-and-forward capabilities in addition to
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 recipient system cannot deal with
fax.
Refer to the VPIM Specification for proper usage of this content.
Buckley, et al. Standards Track [Page 40]
RFC 3949 File Format for Internet Fax February 2005
4.7. Profile F: Extended Black-and-white Fax Profile Summary
Recommended fields are shown with an asterisk (*).
Required fields or values are shown with a double asterisk (**). If
the double asterisk is on the field name, then all the listed values
are required of implementations; if the double asterisks are in the
Values column, then only the values suffixed with a double asterisk
are required of implementations.
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 3**: 1D Modified Huffman and |
| | 2D Modified READ coding |
| | 4: 2D Modified Modified READ |
| | coding |
+---------------------------+--------------------------------+
| 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 image. |
+---------------------------+--------------------------------+
| ImageWidth | 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 a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+------------------------------------------------------------+
Buckley, et al. Standards Track [Page 41]
RFC 3949 File Format for Internet Fax February 2005
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1** |
+---------------------------+--------------------------------+
| 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 | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 0**: required if Compression |
| | is Modified Huffman, EOLs are |
| | not byte aligned |
| | 1: required if Compression is |
| | 2D Modified READ, EOLs are |
| | not byte aligned |
| | 4**: required if Compression |
| | is Modified Huffman, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| T4Options (continued) | 5: required if Compression |
| | is 2D Modified READ, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| 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 |
+---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 42]
RFC 3949 File Format for Internet Fax February 2005
+---------------------------+--------------------------------+
| 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, but have |
| | not been regenerated |
+---------------------------+--------------------------------+
| ConsecutiveBadFaxLines* | Max number of consecutive |
| | "bad" lines received |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | IFD: global parameters IFD |
+---------------------------+--------------------------------+
| ProfileType* | n: type of data stored in file |
+---------------------------+--------------------------------+
| FaxProfile* | n: ITU-compatible fax profile |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used |
| | in file |
+---------------------------+--------------------------------+
5. Profile J: Lossless JBIG Black-and-White Fax profile
This section defines the lossless JBIG black-and-white profile of
TIFF for facsimile, designated Profile J. Implementations of this
profile are required to implement Profile S as well.
The previous section described the extended interchange set of TIFF
fields for black-and-white fax, which provided support for the MH,
MR, and MMR compression of black-and-white images. This section adds
a profile with JBIG compression capability.
5.1. Overview
This section describes a black-and-white profile that uses JBIG
compression. The ITU-T has approved the single-progression
sequential mode of JBIG [T.82] for Group 3 facsimile. JBIG coding
offers improved compression for halftoned originals. JBIG
compression is used in accordance with the application rules given in
ITU-T Rec. T.85 [T.85].
This profile is essentially the extended black-and-white profile with
JBIG compression used instead of MH, MR, or MMR.
Buckley, et al. Standards Track [Page 43]
RFC 3949 File Format for Internet Fax February 2005
5.2. Required TIFF Fields
This section lists the required fields and the values they must have
to be ITU-compatible. Besides the fields listed in Section 2.2.1,
the extended black-and-white fax profile requires the following
fields.
5.2.1. Baseline fields
The TIFF fields that SHALL be used in this profile are the same as
those described in Section 4.2.1 for the extended black-and-white
profile, with two exceptions: the following text replaces the text in
Section 4.2.1 for the Compression and FillOrder fields.
Compression(259) = 9.
SHORT
RequiredByTIFFBaseline
9 = JBIG coding. This is a TIFF extension value.
Default = 1 (and is not applicable; field must be specified).
Profile J uses ITU-T T.85 profile of T.82; see T82Options field.
FillOrder(266) = 1, 2.
SHORT
RequiredByTIFFBaseline
1 = Pixels are arranged within a byte such that pixels with lower
values are stored in the higher-order bits of the byte, 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).
Profile J readers must be able to read data in both bit orders.
5.2.2. Extension fields
Same fields as those in Section 2.2.1.
5.2.3. New fields
T82Options(435) = 0
LONG
Required when Compression = 9
Individual bits are set to indicate the applicable profile of JBIG
coding; all bits set to 0 indicates ITU-T T.85 profile of T.82;
Other values are for further study.
Default is all bits 0, and field may be omitted if this is the
value. (Field may be omitted in Profile J files.)
Buckley, et al. Standards Track [Page 44]
RFC 3949 File Format for Internet Fax February 2005
Note: A T.82 decoder can decode a T.85-encoded image when it handles
the NEWLE marker code as described Corrigendum 1 in [T.85].
5.3. Recommended TIFF Fields
See Sections 2.2.3 and 2.2.4.
5.4. Profile J: Lossless JBIG Black-and-white Fax Profile Summary
Recommended fields are shown with an asterisk (*).
Required fields or values are shown with a double asterisk (**). If
the double asterisk is on the field name, then all the listed values
are required of implementations; if the double asterisks are in the
Values column, then only the values suffixed with a double asterisk
are required of implementations.
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 9**: JBIG coding |
+---------------------------+--------------------------------+
| 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 image |
+---------------------------+--------------------------------+
| ImageWidth | 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 a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 45]
RFC 3949 File Format for Internet Fax February 2005
+---------------------------+--------------------------------+
| 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 of bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of document |
| | scanned |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | IFD: global parameters IFD |
+---------------------------+--------------------------------+
| T82Options** | 0: T.85 profile of T.82 |
+---------------------------+--------------------------------+
| ProfileType* | n: type of data stored in file |
+---------------------------+--------------------------------+
| FaxProfile* | n: ITU-compatible fax profile |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used |
| | in file |
+---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 46]
RFC 3949 File Format for Internet Fax February 2005
6. Profile C: Base Color Fax profile
6.1. Overview
This section defines the lossy color profile of TIFF for facsimile,
designated Profile C. Implementations of this profile are required
to also implement Profile S as well.
This is the base profile for color and grayscale facsimile, which
means that all applications that support color fax must support this
profile. The basic approach is the lossy JPEG compression [T.4,
Annex E; 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 profile uses a new PhotometricInterpretation field value to
describe the L*a*b* encoding specified in [T.42]. This encoding
differs in 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.
6.2.1. Baseline Fields
ImageWidth(256).
SHORT or LONG
This profile supports the following fixed page widths: 864, 1024,
1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
BitsPerSample(258) = 8.
SHORT
Count = SamplesPerPixel
The base color fax profile requires 8 bits per sample.
Buckley, et al. Standards Track [Page 47]
RFC 3949 File Format for Internet Fax February 2005
Compression(259) = 7.
SHORT
Base color fax profile uses Baseline JPEG compression. Value 7
represents JPEG compression as specified in [TTN2].
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile C readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first.
PhotometricInterpretation(262) = 10.
SHORT
Base color fax profile requires pixel values to be stored with the
CIE L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is
indicated by the PhotometricInterpretation value 10, referred to
as ITULAB. With this encoding, the minimum sample value is
mapped to 0, and the maximum sample value is mapped to (2^n - 1),
i.e., the maximum value, where n is 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 Section
6.2.3.
NOTE: PhotometricInterpretation values 8 and 9 specify encodings for
use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1]
data, but they are 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.
ResolutionUnit(296) = 2.
SHORT
The unit of measure for resolution. 2 = inch.
ITU-T standards only specify inch-based resolutions for color fax.
Default = 2 (field may be omitted if this is the value).
SamplesPerPixel(277) = 1, 3.
SHORT
1: L* component only, required in base color profile
3: L*, a*, b* components
Encoded according to PhotometricInterpretation field
Buckley, et al. Standards Track [Page 48]
RFC 3949 File Format for Internet Fax February 2005
XResolution(282) = 100, 200, 300, 400.
RATIONAL
YResolution(283) = 100, 200, 300, 40 |
