Network Working Group Glenn Parsons
Internet Draft James Rafferty
Expires in six months July 29, 1997
Tag Image File Format (TIFF) - Application F
<draft-ietf-fax-tiff-03.txt>
Status of this Memo
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet Drafts as reference material or to
cite them other than as a "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Overview
This document describes in detail the definition of TIFF-F that is
used to store facsimile images and also describes the registration
refinement of the MIME sub-type image/tiff for Application F. The
TIFF-F encoding has been folklore with no standard reference
definition before this document.
Internet Fax Working Group
This document is a product of the IETF Internet Fax Working Group.
All comments on this document should be forwarded to the email
distribution list at <ietf-fax@imc.org>.
Internet Draft TIFF-F July 29, 1997
1. Abstract
This document references the Tag Image File Format (TIFF) to formally
define the application F of TIFF as a file format that may be used to
store facsimile images.
2. TIFF Definition
TIFF (Tag Image File Format) Revision 6.0 is defined in detail within
[TIFF]. The related MIME content type registration information for
image/tiff is defined in [TIFFREG].
A brief review of concepts used in TIFF is included in this document
as background information, but the reader is directed to the original
TIFF specification [TIFF] to obtain specific technical details.
2.1 Baseline TIFF and Applications
TIFF provides a method to describe and store raster image data. A
primary goal of TIFF is to provide a rich environment within which
applications can exchange image data. [TIFF] also defines a commonly
used, default subset of TIFF that is known as Baseline TIFF.
Applications of TIFF are defined by using Baseline TIFF as a starting
point and then defining "extensions" to TIFF that are used for the
specific "application", as well as specifying any other differences
from Baseline TIFF.
3. TIFF-F Definition
3.1 Introduction
Though it has been in common usage for many years, TIFF-F has
previously never been documented in the form of a standard. An
informal TIFF-F document was originally created by a small group of
fax experts led by Joe Campbell. The existence of TIFF-F is 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 "Application F of TIFF".
3.1.1 TIFF-F Historical Background
Up until TIFF 6.0, TIFF supported various "Classes" which defined the
use of TIFF for various applications. Classes were used to support
specific applications and in this spirit, TIFF-F has been known
historically as "TIFF Class F". Previous informal TIFF-F documents
used the "Class F" terminology.
Parsons, Rafferty Expires 01/29/98 [Page 2]
Internet Draft TIFF-F July 29, 1997
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 application of TIFF, by
using Baseline TIFF as defined in [TIFF] as the starting point and
then defining the differences from Baseline TIFF which 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.
3.1.2 Overview
The intent of this specification is be to document:
1) The fields and values which are applicable for the application F
of TIFF.
2) A minimum set of TIFF-F fields and values which should be able
to interwork with virtually all historic TIFF-F readers.
3) A broader range of values for the traditional TIFF-F fields that
will provide support for the most widely used facsimile
compressions, page sizes and resolutions, consistent with the
ITU-T [T.4] and [T.30] recommendations.
The structure of the TIFF-F definition will be as follows. A brief
review of the structure of TIFF files and practical guidelines for
the writing and reading of multi-page TIFF-F files is provided in
sections 3.1.3 and 3.1.4
A review of TIFF-F fields follows. Section 3.2 reviews
the fields from Baseline TIFF that are applicable for black and white
(bi-level) images and are also used by TIFF-F.
Section 3.3 reviews the other required TIFF-F fields. Several fields
that are specific extensions for TIFF-F are reviewed in section
3.4. There are also fields that may be helpful, but are not
required. These recommended fields are listed in the section 3.5.
Several technical topics, including implementation issues, warnings
and conformance are discussed in subsequent sections. Finally,
section 3.9 introduces the TIFF-F Reader and Writer. A table of the
required and recommended fields for a TIFF-F Reader is provided,
along with details on the minimum and permitted set of values for
TIFF-F purposes.
3.1.3 Structure of TIFF Files
The structure of TIFF files is specified within [TIFF]. In this
section, a short summary of the TIFF structure is included for the
informational purposes. In addition, some practical guidelines for
the use of this structure in reading and writing TIFF-F files are
addressed in the following section 3.1.4.
Parsons, Rafferty Expires 01/29/98 [Page 3]
Internet Draft TIFF-F July 29, 1997
A TIFF file begins with an 8-byte image file header that defines the
byte order used within a file (see 3.9.1), includes a magic number
sequence that identifies the content as a TIFF file, and then uses an
offset to point to the first Image File Directory (IFD). An IFD is a
sequence of tagged fields, sorted in ascending order (by tag value),
that contains attributes of an image and pointers to the image data.
TIFF fields (also called entries) contain a tag, its type (e.g.
short, long, rational, etc.), a count (which indicates the number of
values/offsets) and a value/offset. However, the actual value for
the field will only be present if it fits into 4 bytes; otherwise, an
offset will be used to point to the location of the data associated
with the field. In turn, this offset may itself be used to point to
an array of offsets.
For the case of facsimile data, many documents consist of a series of
multiple pages. Within TIFF, these may be represented using more
than one IFD within the TIFF file. Each IFD defines a subfile whose
type is given in the NewSubfileType field. For the case of facsimile
data that is placed in a TIFF-F file, each facsimile page in a multi-
page document has its own IFD. For bi-level facsimile files,
multiple IFDs are organized as a linked list, with the last entry in
each IFD pointing to the next IFD (the pointer in the last IFD is 0).
(There is also another technique for organizing multiple IFDs as a
tree, that uses the SubIFDs field, but this technique is not
applicable for TIFF-F images.) Within each IFD, the location of the
related image data is defined by using fields that are associated
with strips. These fields identify the size of strips (in rows),
the number of bytes per strip after compression and a strip offset,
which is used to point to the actual location of the image strip.
TIFF has a very flexible file structure, but the use of some
practical guidelines for implementors when writing multi-page TIFF-F
files can produce TIFF structures which are easier for readers to
process. This is especially for applications in environments such
as facsimile terminals where a complex file structure is difficult to
support.
3.1.4 Practical Guidelines for Writing and Reading Multi-Page TIFF-F
Files
Traditionally, historical TIFF-F has required readers and writers to
be able to handle multi-page TIFF-F files. Based on the experience
of various TIFF-F implementors, it has been seen that the
implementation of 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
page of the document. Therefore, each IFD will define the
attributes for a single page. For simplicity, 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
Parsons, Rafferty Expires 01/29/98 [Page 4]
Internet Draft TIFF-F July 29, 1997
as the first page and then ascending (i.e. 0, 1, 2, ...). However,
as noted in 3.1.1, 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 strip offsets for each strip of image are defined from
within each IFD. Where possible, a second simplifying assumption
for the writing of TIFF-F files is to specify 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). The use of a
single image strip per page is very useful 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 which require the use of
ÒstreamingÓ techniques. (see section 3.6.6) In the event a
different image strip size assumption has been used (e.g. constant
size for image strips which may be less than the page size), this
will immediately be evident from the values/offsets of the fields
that are related to strips. From the TIFF-F reader standpoint, one
image strip per page permits the image data to be found through
reference via a single offset, resulting in a much simplified image
structure and faster processing.
In addition, a third simplifying assumption for TIFF-F writers and
readers is to place the actual image data in a physical order within
the TIFF file structure which is consistent with the logical page
order. 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.
So, a TIFF-F file which is structured using the guidelines of this
section will essentially be composed of a linked list of IFDs,
presented in ascending page order, which in turn each point to a
single page of image data (one strip per page), where the pages of
image data are also placed in a logical page order within the TIFF-F
file structure. (The pages of image data may themselves be stored in
a contiguous manner, at the option of the implementer).
3.2 Baseline TIFF Required Fields for BiLevel Images
Baseline TIFF per [TIFF] requires that the following fields be
present for all BiLevel Images: ImageWidth, ImageLength,
Compression, Photometric Interpretation, StripOffsets, RowsPerStrip,
StripByteCounts, Xresolution, YResolution and ResolutionUnit. TIFF-
F uses all of these fields, but in some cases specifies a different
range of acceptable values than Baseline TIFF. Per [TIFF], if
fields are omitted, the Baseline TIFF default value (if specified)
will apply.
A brief summary of these fields and their use in TIFF-F follows:
Parsons, Rafferty Expires 01/29/98 [Page 5]
Internet Draft TIFF-F July 29, 1997
ImageWidth = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096, 4864.
SHORT or LONG. These are the fixed page widths in pixels. The
permissible values are dependent upon X and Y resolutions as
shown in sections 2 and 3 of [T.4] and reproduced here for
convenience:
XResolution x Yresolution | ImageWidth
-------------------------------------------|------------------
204 x 98, 204 x 196, 200 x 100, 200 x 200 | 1728, 2048, 2432
300 x 300 | 2592, 3072, 3648
406 x 391, 400 x 400 | 3456, 4096, 4864
-------------------------------------------|------------------
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 3.8.2 for more information
on inch/metric equivalencies and other implementation details.
ImageLength. SHORT or LONG. LONG recommended.
The total number of scan lines in the image.
Compression = 3,4. SHORT.
This is a required TIFF-F field. The permitted values for TIFF-F
purposes are 3 and 4 as shown. The default value per Baseline
TIFF is 1 (Uncompressed), but this value is invalid for facsimile
images. Baseline TIFF also permits use of value 2 (Modified
Huffman encoding), but the data is presented in a form which is
not byte aligned. Instead, TIFF-F specifies the value 3 for
encoding one-dimensional T.4 Modified Huffman or 2-dimensional
Modified READ data. The detailed settings which apply for T.4
encoded data are specified using the T4Options field. TIFF-F
also permits use of the value 4 for the compression field, which
indicates that the data is coded using a [T.6] compression method
(i.e the Modified Modified READ two-dimensional method). The
detailed settings which apply for T.6 encoded data are specified
using the T6Options field.
Please refer to the definitions of the T4Options and T6Options
fields in section 3.3, and section 3.8 for more information on
the encoding of images and conventions used within TIFF-F.
PhotometricInterpretation = 0,1. SHORT.
This field allows notation of an inverted ("negative") image:
0 = normal
1 = inverted
Parsons, Rafferty Expires 01/29/98 [Page 6]
Internet Draft TIFF-F July 29, 1997
StripOffsets. SHORT or LONG.
For each strip, the offset of that strip. The offset is measured
from the beginning of the file. If a page is expressed as one
large strip, there is one such entry per page.
RowsPerStrip. SHORT or LONG. LONG recommended.
The number of scan lines per strip. When a page is expressed as
one large strip, this is the same as the ImageLength field.
StripByteCounts. LONG or SHORT. LONG recommended.
For each strip, the number of bytes in that strip. If a page is
expressed as one large strip, this is the total number of bytes
in the page after compression. Note that the choice of LONG or
SHORT depends upon the size of the strip.
ResolutionUnit = 2,3. SHORT.
The units of measure for resolution:
2 = Inch
3 = Centimeter
TIFF-F has traditionally used inch based measures.
XResolution = 204, 200, 300, 400, 406 (inches). RATIONAL.
The horizontal resolution of the TIFF-F image expressed in pixels
per resolution unit. The values of 200 and 406 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
(cm). See section 3.8.2 for more information on inch/metric
equivalencies and other implementation details.
YResolution = 98, 196, 100, 200, 300, 391, 400 (inches). RATIONAL.
The vertical resolution of the TIFF-F image expressed in pixels
per resolution unit. 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, 38.5 (cm). See section 3.8.2 for more information
on inch/metric equivalencies and other implementation details.
3.3 TIFF-F Required Fields
In addition to the Baseline TIFF fields, there are additional
required fields for TIFF-F. There is also a requirement to include
either the T4Options or the T6Options field, depending upon the
setting of the compression field. A review of the additional
required fields for TIFF-F follows:
BitsPerSample = 1. SHORT.
Since TIFF-F is only used for black-and-white facsimile images,
the value is 1 (the default) for all files.
Parsons, Rafferty Expires 01/29/98 [Page 7]
Internet Draft TIFF-F July 29, 1997
FillOrder = 1, 2. SHORT.
TIFF 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.
NewSubFileType = 2. LONG.
This field is made up of 32 flag bits. Unused bits are expected
to be 0 and bit 0 is the low order bit. Bit 0 is set to 0 for
TIFF-F. 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 sections 3.1.1
and 3.1.2 for more details on the structure of multi-page TIFF-F
image files.
PageNumber. SHORT/SHORT.
This field specifies the page numbers in the fax document. The
field comprises two SHORT values: the first value is the page
number, the second is the total number of pages. Single-page
documents therefore use 00000001 hex. If PageNumber[1] is 0, the
total number of pages in the document is not available.
SamplesPerPixel = 1. SHORT.
The value of 1 denotes a bi-level, grayscale, or palette color
image.
T4Options = 4,5. LONG.
This field is required if the value for the compression field has
been set to 3. The values are set as shown below for TIFF-F.
For TIFF-F, uncompressed data is not allowed and EOLs are byte
aligned.
bit 0 = 0 for 1-Dimensional, 1 for 2-Dimensional (MR)
bit 1 = must be 0 (uncompressed data not allowed)
bit 2 = 1 for byte-aligned EOLs
Bit 0 is the low order bit. Please note that T4Options was known
as G3Options in earlier versions of TIFF and TIFF-F.
The data in a TIFF-F image encoded using one of the T.4 methods
is not terminated with an RTC (see 3.8.5).
T6Options = 0 LONG.
This field is required for TIFF F if value of the compression
field has been set to 4. The value for this field is made up of a
set of 32 flag bits. Setting bit 0 to 0 indicates that the data
is compressed using the Modified Modified READ (MMR) two-
dimensional compression method. MMR compressed Data is two-
dimensional and does not use EOLs. Each MMR encoded image should
include an "end-of-facsimile-block" (EOFB) code at the end of
each coded strip (see 3.8.6). Uncompressed data is not applicable
for bi-level facsimile images, so that bit 1 must be set to 0.
Unused bits must be set to 0. Bit 0 is the low-order bit. The
default value is 0 (all bits 0).
Parsons, Rafferty Expires 01/29/98 [Page 8]
Internet Draft TIFF-F July 29, 1997
bit 0 = 0 for 2-Dimensional
bit 1 = must be 0 (uncompressed data not allowed)
In earlier versions of TIFF, this field was named Group4Options.
The significance has not changed and the present definition is
compatible.
3.4 TIFF-F Extensions
There are only three new fields defined as TIFF-F extensions. All
three fields describe page quality. The information contained in
these fields is usually obtained from receiving facsimile hardware
(if applicable). These fields are optional. They should not be
used 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 scan lines. A
"good" scan line is defined as a line that, when decoded, contains
the correct number of pixels. Conversely, a "bad" scan line is
defined as a line that, when decoded, comprises an incorrect number
of pixels.
BadFaxLines
Tag = 326 (146 hex)
Type = SHORT or LONG
This field reports the number of scan lines with an incorrect
number of pixels encountered by the facsimile during reception
(but not necessarily in the file).
Note: PercentBad = (BadFaxLines/ImageLength) * 100
CleanFaxData
Tag = 327 (147 hex)
Type = SHORT
N = 0
0 = Data contains no lines with incorrect pixel counts or
regenerated lines (i.e., computer generated)
1 = Lines with an incorrect pixel count were regenerated by
receiving device
2 = Lines with an incorrect pixel count are in the data and
were not regenerated by receiving device (i.e. data
contains bad scan lines)
Parsons, Rafferty Expires 01/29/98 [Page 9]
Internet Draft TIFF-F July 29, 1997
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 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 if the receiving facsimile device replaced them with
regenerated lines.
ConsecutiveBadFaxLines
Tag = 328 (148 hex)
Type = LONG or SHORT
This field reports the maximum number of consecutive lines
containing an incorrect number of pixels encountered by the
facsimile device during reception (but not necessarily in the
file).
The BadFaxLines and ImageLength data indicate only the quantity
of such lines. The ConsecutiveBadFaxLines field is an indicator
of their distribution and may therefore be a better general
indicator of perceived image quality.
3.5 Recommended Fields
These are fields that may be used in encoding TIFF-F files, but are
optional in nature and may be ignored by many TIFF readers. These
fields are called recommended consistent with historical TIFF-F
practice.
BadFaxLines. LONG.
The number of "bad" scan lines encountered by the facsimile
during reception.
CleanFaxData = 0, 1, 2. BYTE.
This field indicates whether lines with incorrect pixel count are
actually in the data or if the receiving facsimile device
replaced them with regenerated lines.
0 = Data contains no lines with incorrect pixel counts or
regenerated lines (i.e., computer generated)
1 = Lines with an incorrect pixel count were regenerated by
receiving device
2 = Lines with an incorrect pixel count are in the data and
were not regenerated by receiving device (i.e. data
contains bad scan lines)
ConsecutiveBadFaxLines. LONG or SHORT.
The maximum number of consecutive scan lines with incorrect pixel
count encountered by the facsimile device reception.
Parsons, Rafferty Expires 01/29/98 [Page 10]
Internet Draft TIFF-F July 29, 1997
DateTime. ASCII.
Date and time in the format YYYY:MM:DD HH:MM:SS, in 24-hour
format. String length including NUL byte is 20 bytes. Space
between DD and HH.
DocumentName. ASCII.
This is the name of the document from which the document was
scanned.
ImageDescription. ASCII.
This is an ASCII string describing the contents of the image.
Orientation. SHORT.
This field might be useful for displayers that always want to
show the same orientation, regardless of the image. The default
value of 1 is "0th row is visual top of image, and 0th column is
the visual left." An 180-degree rotation is 3. See [TIFF] for
an explanation of other values.
Software. ASCII.
The optional name and release number of the software package that
created the image.
3.6 Technical Implementation Issues
3.6.1 Strips
Those new to TIFF may not be familiar with the concept of "strips"
embodied in the three fields RowsPerStrip, StripByteCount,
StripOffsets.
In general, third-party applications that read and write TIFF files
expect the image to be divided into "strips," also known as "bands."
Each strip contains a few lines of the image. By using strips, a TIFF
reader need not load the entire image into memory, thus enabling it
to fetch and decompress small random portions of the image as
necessary.
The dimensions of a strip are described by the RowsPerStrip and
StripByteCount fields. The location in the TIFF file of each strip
is contained in the StripOffsets field.
The size of TIFF-F strips is application dependent. The recommended
approach for multi-page TIFF-F images is to represent each page as a
single strip.
3.6.2 Bit Order
Although the TIFF 6.0 documentation lists the FillOrder field in the
category "No Longer Recommended," TIFF-F utilizes it.
Parsons, Rafferty Expires 01/29/98 [Page 11]
Internet Draft TIFF-F July 29, 1997
Facsimile data appears on the phone line in bit-reversed order
relative to its description in CCITT Recommendation T.4. Therefore,
a wide majority of facsimile applications choose this natural order
for storage. Nevertheless, TIFF-F readers must be able to read data
in both bit orders.
3.6.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.
3.6.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 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 Addressing). In 1984, a
somewhat more efficient compression method known as Modified Modified
READ (MMR) was defined in the T.6 recommendation. It 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 permits three different compression methods. In the most
common practice, the one-dimensional compression method (Modified
Huffman) has used. This is specified by setting the value of the
Compression field to 3 and then setting bit 0 of the T4Options field.
Alternatively, the two dimensional Modified READ method (which is
much less frequently used in historical TIFF-F implementations) may
be selected by setting bit 0 to a value of 1.
Optionally, depending upon the application, the more efficient two-
dimensional compression method from T.6 (i.e. MMR or "Group 4
compression") may be selected. This method is selected by setting
the value of the Compression field to 4 and then setting the value of
the first two bits (and all unused bits) of T6options to 0. More
information to aid the implementer in making a compression selection
is contained in section 3.8 on Implementation Warnings.
3.6.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:
Do not write page-quality fields.
Parsons, Rafferty Expires 01/29/98 [Page 12]
Internet Draft TIFF-F July 29, 1997
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. Computer generated file: write CleanFaxData = 0.
5. Source image data stream is error-corrected or otherwise
guaranteed to be error-free: Do not write page-quality
fields.
3.6.6 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. While TIFF-F may also possibly
be used as a file format for cases such as streaming applications,
different assumptions may be required than those provided in this
document (e.g., the entire size and number of pages within the image
are not known in advance). As a result, a definition for the
streaming application of TIFF-F is beyond the scope of this document.
3.7 TIFF-F Conformance
Fax applications that do not wish to support TIFF-F as a native
format may elect to support it as import/export medium.
Export
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 that this practice is not recommended.
Import
A TIFF-F reader must be able to handle a TIFF-F file containing
multiple pages.
3.8 Implementation Warnings
3.8.1 Uncompressed data
TIFF-F requires the ability to read and write at least one-
dimensional T.4 Huffman ("compressed") data. Uncompressed data is
not allowed. This means that the "Uncompressed" bit in T4Options or
T6Options must be set to 0.
Parsons, Rafferty Expires 01/29/98 [Page 13]
Internet Draft TIFF-F July 29, 1997
3.8.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. However, for maximum efficiency, images should be
compressed using T.6 MMR compression when possible. For maximum
portability, applications also need to be able to read and write one-
dimensional (Modified Huffman) files. Some TIFF-F readers will also
support two-dimensional Modified READ files. Applications that wish
to have the maximum flexibility in reading TIFF-F files should
support all three of the supported compression methods.
For the case of resolution, 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, 400 x 400 in dots per
inch based units. At the same time, support was added for metric
dimensions which are equivalent to the following inch based
resolutions: 391v x 203h and 391v x 406h. Therefore, the full set of
inch-based equivalents of the new resolutions are supported in the
TIFF-F writer, since they may appear in some image data streams
received from Group 3 facsimile devices. However, many facsimile
terminals and older versions of TIFF-F readers are likely to not
support the use of these higher resolutions.
Per [T.4], it is permissible for applications to treat the following
XResolution values as being equivalent: <204,200> and <400,406>. In
a similar respect, the following YResolution values may also be
treated as being equivalent: <98, 100>, <196, 200>, and <391, 400>.
These equivalencies were allowed by [T.4] to permit conversions
between inch and metric based facsimile terminals.
In a similar respect, the optional support of metric based
resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for
completeness, since 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.
3.8.3 EOL byte-aligned
In the spirit of TIFF-F, all EOLs in Modified Huffman or Modified
READ data must be byte- aligned. An EOL is said to be byte-aligned
when Fill bits have been added as necessary before EOL codes such
that EOL always ends on a byte boundary, thus ensuring an EOL-
sequence of a one byte preceded by a zero nibble: xxxx0000 00000001.
Recall that Modified Huffman encoding encodes bits, not bytes. This
means that the end-of-line token may end in the middle of a byte. In
byte alignment, extra zero bits (Fill) are added so that the first
Parsons, Rafferty Expires 01/29/98 [Page 14]
Internet Draft TIFF-F July 29, 1997
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 encoding, 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, so that the first bit of data following an MR
tag bit begins on a byte boundary.
3.8.4 EOL
As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
with Modified Huffman begin with an EOL (which in TIFF-F is byte-
aligned). The last line of the image is not terminated by an EOL. In
a similar respect, images encoded with Modified READ two dimensional
encoding begin with an EOL, followed by a tag bit. The EOL/tag bit
combination is byte aligned in TIFF-F.
3.8.5 RTC Exclusion
Aside from EOLs, TIFF-F files contain only image data. This means
that the Return To Control sequence (RTC) is specifically excluded.
3.8.6 Use of EOFB for T.6 Compressed Images
TIFF-F pages which are encoded with the T.6 Modified Modified READ
compression method should include an "end-of-facsimile-block" (EOFB)
code at the end of each coded strip. Per [TIFF], the EOFB code is
followed by pad bits as needed to align on a byte boundary. TIFF
readers should ignore any bits other than pad bits beyond the EOFB.
3.9 TIFF-F Fields Summary
Implementations may choose to implement a TIFF-F Reader, TIFF-F
Writer or both, depending upon application requirements. The TIFF-F
Reader is typically used to read an existing TIFF-F file which
resides on a computer or peripheral device. The TIFF-F Writer is
typically used to convert a bi-level image bit stream into a TIFF-F
compliant file. For many Internet applications, only the Reader needs
to be implemented. The specific field support required for TIFF-F
Readers and Writers is summarized below.
3.9.1 TIFF Reader
The fields in following table are specified for a TIFF-F Reader. The
range of values for required and recommended fields are as shown. A
minimum subset of values is also shown, denoting those values which
should provide maximum portability with historical TIFF-F readers.
If required fields are omitted in a TIFF-F file, the Baseline TIFF
Parsons, Rafferty Expires 01/29/98 [Page 15]
Internet Draft TIFF-F July 29, 1997
default value will apply. Image data must not have any coding
errors.
As noted within [TIFF], a TIFF file begins with an 8-byte image file
header, of which the first two bytes (0-1) contain the byte order
within the file. The permissible values are:
II- Byte order from least significant byte to the most
significant byte (little-endian)
MM - byte order is always from most significant to least
significant (big-endian)
For a TIFF-F Reader, the legal values are:
ByteOrder: MM,II (Either byte order is allowed)
3.9.1.1 Fields for TIFF-F Reader
Field | Values | Minimum | Comment
------------------|-------------|--------------|----------------------
BitsPerSample | 1 | 1 |one bit per sample
Compression | 3,4 | 3 |3 for T.4 (MH, MR)
| | |4 for T.6 - MMR
FillOrder | 2,1 | 2 |LSB first or MSB first
ImageWidth | 1728, 2048, | 1728, 2048 |depends on XResolution
| 2432, 2592, | |
| 3072, 3648, | |
| 3456, 4096, | |
| 4864 | |
ImageLength | >0 | |required
NewSubFileType | 2 | 2 |single page of
| | |multipage file
Orientation * | 1 | 1 |1st row=top left,
| | | 1st col=top
PageNumber | X/X | 0/1 |pg/tot, 0 base,
| | | tot in 1st IFD
PhotometricInterp | 0,1 | 0 |0 is white
ResolutionUnit | 2,3 | 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |
| or other | |
SamplesPerPixel | 1 | 1 |one sample per pixel
StripByteCounts | >0 | |required
StripOffsets | >0 | |required
T4Options | 4,5 | 4 |MH,MR(incl if not MMR)
T6Options | 0 | |MMR (incl only if MMR)
Xresolution | 204,200,300,| 204 | If unit is per inch
| 400,406 | |
| 77 | | If unit is per cm
Yresolution | 196,98,100, | 196,98 | If unit is per inch
| 200,300,391,| |
| 400 | |
| 77,38.5 | | If unit is per cm
------------------|-------------|--------------|--------------------
Parsons, Rafferty Expires 01/29/98 [Page 16]
Internet Draft TIFF-F July 29, 1997
Recommended Fields are shown with an *
Other fields may be present, but they should be of an
informational nature, so that a reader can elect to ignore them.
Informational fields which are often present in TIFF-F images are:
Software, Datetime, BadFaxLines, CleanFaxData and
ConsecutiveBadFaxLines.
3.9.2 TIFF-F Writer
For the case of writing (creating) a TIFF-F file format from an image
data stream or other raster data, implementations should write files
which can be read by a TIFF-F Reader as defined in 3.9.1. It is
recommended that all fields from the table in 3.9.1.1 should be
included when writing TIFF-F files in order to minimize dependencies
on default values. Image data must not have any coding errors.
Other fields may be present, but they should be of an informational
nature, so that a Reader may elect to ignore them.
Informational fields that may be useful are:
Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines
TIFF Writers should only generate the fields that describe facsimile
image quality 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. These fields are: CleanFaxData, BadFaxLines and
ConsecutiveBadFaxLines.
4. MIME sub-type image/tiff
[TIFFREG] contains the registration of the MIME sub-type image/tiff.
In addition, an optional "application" parameter is defined for
image/tiff to identify the TIFF application of the encoded image
data, if it is known.
4.1 Refinement of MIME sub-type image/tiff for Application F
When transported by MIME, the TIFF-F content (i.e. the Application F
of TIFF) defined by this document must be encoded within an
image/tiff content type. Since this document defines a facsimile
specific application of TIFF, it is useful to note this in the
application parameter of the image/tiff MIME content type.
Implementations which intend to use the Application F of image/tiff
should use a MIME Content-type with the application parameter set to
the value ÔFÕ as follows:
Example:
Content-type: image/tiff; application=F
Parsons, Rafferty Expires 01/29/98 [Page 17]
Internet Draft TIFF-F July 29, 1997
Use of this parameter will enable implementations to identify the
content as being TIFF-F before attempting to process the image data.
5. Implementation Usage
5.1 Internet Fax Usage
The usage of TIFF-F is envisioned as a component of Internet Fax. It
is anticipated that Internet Fax may use both a TIFF-F Reader and
TIFF-F Writer. The details of the Internet Fax applications and their
use of TIFF-F will be specified in other documents.
5.2 VPIM Usage
The image/tiff sub-type with the application F parameter (i.e. TIFF-F
content) is a secondary component of the VPIM Message as defined in
[VPIM2]. Voice messaging systems can often handle fax store-and-
forward capabilities in addition to traditional voice message store-
and-forward functions. As a result, this sub-type is used to hold
fax messages within the multipart/voice-message content that is sent
between compliant VPIM systems. In this context, the fax content is
optional and may be rejected if the recipient system cannot deal with
fax. VPIM implementations must at least implement and support the
TIFF-F Reader.
Refer to the VPIM Specification for proper usage of this content.
6. Security Consideration
This document describes the encoding for TIFF-F, which is an
application of the TIFF encoding. As such, it does not create any
security issues not already existing in TIFF (though, none have been
identified).
Further, the encoding specified in this document does not in any way
preclude the use of any Internet security protocol to encrypt,
authenticate, or non-repudiate TIFF-F encoded facsimile messages.
7. Authors' Addresses
Glenn W. Parsons
Nortel Technology
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-763-7582
Fax: +1-613-763-8385
Email: Glenn.Parsons@Nortel.ca
Parsons, Rafferty Expires 01/29/98 [Page 18]
Internet Draft TIFF-F July 29, 1997
James Rafferty
Human Communications
12 Kevin Drive
Danbury, CT 06811-2901
USA
Phone: +1-203-746-4367
Fax: +1-203-746-4367
Email: Jrafferty@worldnet.att.net
8. References
[MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft, First Virtual, Nov 1996
[MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
Innosoft, First Virtual, Nov 1996.
[T.30] ITU-T Recommendation T.30 - "Procedures for Document Facsimile
Transmission in the General Switched Telephone Network", June,
1996
[T.4] ITU-T Recommendation T.4 - "Standardization of Group 3
Facsimile Apparatus for Document Transmission", June, 1996
[T.6] ITU-T Recommendation T.6 - "Facsimile Coding Schemes and Coding
Control Functions for Group 4 Facsimile Apparatus", March, 1993
[TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final,
June 3, 1992.
[TIFFREG] G. Parsons and J. Rafferty, "Tag Image File Format (TIFF) -
image/tiff: MIME Sub-type Registration ", Work In Progress,
<draft-ietf-fax-tiff-reg-01.txt>, July 1997.
[TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the
TPC.INT Subdomain: Remote Printing -- Technical Procedures",
RFC 1528, 10/06/1993
[VPIM2] G. Vaudreuil and G. Parsons, "Voice Profile for Internet Mail
- version 2", Work In Progress, <draft-ema-vpim-06.txt>, July
1997.
Parsons, Rafferty Expires 01/29/98 [Page 19]
