Network Working Group Glenn Parsons
Internet Draft James Rafferty
Expires in six months March 26, 1997
Tag Image File Format (TIFF) - Class F
<draft-ietf-fax-tiff-01.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Overview
This document describes in detail the definition of TIFF Class F that
is used to store facsimile images and also describes the registration
refinement of the MIME sub-type image/tiff. The Class F tag encoding
has been folklore with no specific 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 March 26, 1997
1. Abstract
This document formalizes the reference for the Tag Image File Format
(TIFF) and formally defines TIFF Class F that is used to store
facsimile images. As well, the original registration for image/TIFF
from RFC 1528 is refined by this document.
2. TIFF Definition
TIFF (Tag Image File Format) Revision 6.0 is defined in detail by
Adobe in [TIFF]. The documentation can be obtained from Adobe at:
Adobe Developers Association
Adobe Systems Incorporated
1585 Charleston Road
P.O. Box 7900 Mountain View, CA 94039-7900
A copy of this specification can also be found in:
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/
tiff6.pdf
Only an introduction to the baseline TIFF is included in this
document. The reader is directed to the original TIFF specification
[TIFF] to obtain specific technical details.
2.1 TIFF Scope
TIFF describes image data that typically comes from scanners, frame
grabbers, and paint- and photo-retouching programs. TIFF is not a
printer language or page description language. The purpose of TIFF
is 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. This richness is required to take advantage of the varying
capabilities of scanners and other imaging devices. Though TIFF is a
rich format, it can easily be used for simple scanners and
applications as well because the number of required fields is small.
2.2 TIFF Features
- TIFF is capable of describing bilevel, grayscale, palette-color,
and full-color image data in several color spaces.
- TIFF includes a number of compression schemes that allow developers
to choose the best space or time tradeoff for their applications.
- TIFF is not tied to specific scanners, printers, or computer
display hardware.
- TIFF is portable. It does not favor particular operating systems,
file systems, compilers, or processors.
- TIFF is designed to be extensible and to evolve gracefully as new
needs arise.
Parsons, Rafferty Expires 9/26/97 [Page 2]
Internet Draft TIFF-F March 26, 1997
- TIFF allows the inclusion of an unlimited amount of private or
special-purpose information.
3. TIFF Class F Definition
Though it has been in common usage for many years, TIFF Class F (or
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 for TIFF Class F for Internet applications.
3.1
TIFF Classes reduce the information burden on TIFF readers and writers
that wish to support narrow applications. For example, Appendix G-1 of
TIFF 5.0 stated that classes enable TIFF readers "to know when they
can stop adding TIFF features." In other words, defining a Class
enables applications interested only in reading that Class to give up
if the characteristic tags and values are not present. Therefore,
TIFF Class F insists on a rather narrow definition of tags. In a
general TIFF file, for example, the writer would be free to create
single-page documents without the NewSubFileType and PageNumber tags.
Not so for a Class F file, where the multi-page tag is required even
for a single page.
TIFF Class F is a sub-class of Class B (Bilevel) [TIFFB]. That is,
all tags that are required in Class B are also required in Class F.
For some common tags, however, Class F limits the range of acceptable
values. The YResolution tag, for example, is a Class B tag, but
within Class F only a limited set of values is permitted. Such tags
are listed in section 3.2
Section 3.3 discusses other Class B tags that have a specific meaning
when applied to facsimile images. Several new Class F tags are
discussed in section 3.4. There are also tags that may be helpful but
are not required. These recommended tags 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 TIFF-F tags for each of these implementations is summarized.
3.1.1 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 writing multi-page TIFF-F files are also
addressed here.
Parsons, Rafferty Expires 9/26/97 [Page 3]
Internet Draft TIFF-F March 26, 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
tag 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
tag. 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. For
the case of facsimile data that is placed in a TIFF-F file, each
facsimile page in a multi-page document will generally have its own
IFD. Within each IFD, the location of the related image data is
defined by using tags that are associated with strips. These tags
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 on structuring a multi-page TIFF-F file may yield benefits
for implementers, especially for application in environments such as
facsimile terminals where a complex file structure is not practical.
3.1.2 Practical Guidelines for Structuring TIFF-F Files
The implementation of TIFF-F can be greatly simplified if certain
practical guidelines are kept in mind when writing TIFF-F files. In
general, 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, it is advisable that
the writer of TIFF-F files 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,
2, _).
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 will be contained within a single strip
(i.e. one image strip per fax page). In the event a different
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 tags that are related to strips. From an
implementer's standpoint, one image strip per page will permit the
image data to be found through reference via a single offset,
resulting in a much simplified image structure.
Parsons, Rafferty Expires 9/26/97 [Page 4]
Internet Draft TIFF-F March 26, 1997
In addition, a third simplifying assumption for TIFF-F writers will be
to place the actual image data in a physical order within the TIFF
file structure which is consistent with the 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 Class F Required Tags
FillOrder = 1, 2. SHORT.
TIFF Class 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 = 1728, 2048, 2482, 2592, 3072, 3723, 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 Table 2 of [T.4].
NewSubFileType = 2. LONG.
The value 2 identifies a single page of a multi-page image.
PageNumber. SHORT/SHORT.
This tag specifies the page numbers in the fax document. The tag
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.
ResolutionUnit = 2,3. SHORT.
The units of measure for resolution:
2 = Inch
3 = Centimeter
XResolution = 204, 200, 300, 400, 406 (inches). RATIONAL.
The horizontal resolution of the image expressed in pixels per
resolution unit. Some existing TIFF-F implementations may also
support values of 77 (cm).
YResolution = 98, 196, 100, 200, 300, 392, 400 (inches). RATIONAL.
The vertical resolution of the image expressed in pixels per
resolution unit. Some existing TIFF-F implementations may also support
values of 77, 38.5 (cm).
3.2.1
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
Parsons, Rafferty Expires 9/26/97 [Page 5]
Internet Draft TIFF-F March 26, 1997
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 Class F permits two different compression methods. By default,
the one-dimensional compression method is used. 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.
More information to aid the implementor in making this selection is
contained in section 3.8 on Implementation Warnings.
The tags used to specify the compression are shown below:
Compression = 3,4. SHORT.
This is a required Class F tag. Modified Huffman, one-
dimensional encoding with "byte-aligned" EOLs is selected by
setting 3. 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 1
byte preceded by a zero nibble: xxxx0000 00000001. The data in a
Class F image is not terminated with an RTC (see sections 3.8.4
and 3.8.5). For two-dimensional encoding, set the value of the
compression tag to 4 (see section 3.8.2).
T4Options = 4,5. LONG.
This tag is required for TIFF Class-F if the one-dimensional
compression method has been specified (i.e. by setting the value
of the Compression tag to 3). Data is one-dimensional and EOLs
must be byte-aligned. Uncompressed data is not allowed.
bit 0 = 0 for 1-Dimensional
bit 1 = must be 0 (uncompressed data not allowed)
bit 2 = 1 for byte-aligned EOLs
T6Options = 0 LONG.
This tag is required for TIFF Class F if the two-dimensional
compression method is specified (i.e. by setting the value of the
Compression tag to 4). Data is two-dimensional and there is no
use of EOLs. Uncompressed data is not allowed. In earlier versions
of TIFF, this tag was named Group4Options. The significance has
not changed and the present definition is compatible. This field
is made up of a set of 32 flag bits. Unused bits must be set to 0.
Bit 0 is the low-order bit. The default value is 0 (all bits 0).
bit 0 = 0 for 2-Dimensional
bit 1 = must be 0 (uncompressed data not allowed)
3.3 Class B (Bilevel) Required Tags
Although these tags are already required in Class B (Bi-Level) files,
an explanation of their usage for facsimile images may be helpful.
Parsons, Rafferty Expires 9/26/97 [Page 6]
Internet Draft TIFF-F March 26, 1997
BitsPerSample = 1. SHORT.
Since facsimile is a black-and-white medium, this must be 1 (the
default) for all files.
ImageLength. SHORT or LONG. LONG recommended.
The total number of scan lines in the image.
PhotometricInterp = 0,1. SHORT.
This tag allows notation of an inverted ("negative") image:
0 = normal
1 = inverted
Software. ASCII.
The optional name and release number of the software package that
created the image.
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 tag.
SamplesPerPixel = 1. SHORT.
The value of 1 denotes a bi-level, grayscale, or palette color
image.
StripByteCounts. SHORT or LONG. SHORT 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.
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.
3.4 New Class F Tags
There are only three new tags for Class F. All three tags describe
page quality. The information contained in these tags is usually
obtained from the receiving facsimile hardware, but since not all
devices are capable of reporting this information, the tags are
optional.
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.
Parsons, Rafferty Expires 9/26/97 [Page 7]
Internet Draft TIFF-F March 26, 1997
BadFaxLines
Tag = 326 (146 hex)
Type = SHORT or LONG
This tag 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)
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 tag describes the error content of
the data. That is, when the BadFaxLines and ImageLength tags
indicate that the facsimile device encountered lines with an
incorrect number of pixels during reception, the CleanFaxData tag
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 tag 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 tag is an indicator of
their distribution and may therefore be a better general indicator
of perceived image quality.
3.5 Recommended Tags
BadFaxLines. LONG.
The number of "bad" scan lines encountered by the facsimile during
reception.
Parsons, Rafferty Expires 9/26/97 [Page 8]
Internet Draft TIFF-F March 26, 1997
CleanFaxData = 0, 1, 2. BYTE.
This tag 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.
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 tag 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.
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 tags 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 tags. The location in the TIFF file of each strip is
contained in the StripOffsets tag.
The TIFF documentation suggests using strips of an arbitrary size of
about 8K. Although various application programs assert that they
Parsons, Rafferty Expires 9/26/97 [Page 9]
Internet Draft TIFF-F March 26, 1997
"prefer" banded images, research failed to uncover a single existing
application that could not read a single-strip page where they could
read the same file in a multi-strip format. Indeed, applications seem
to be more sensitive to the total size of the decoded image and are
not particularly fussy about banding. This result is not surprising,
considering that most desktop publishing programs are prepared to deal
with massively larger images than those one finds in facsimile. In
short, the size of strips is application dependent. However, a
practical 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 tag in the
category "No Longer Recommended," Class F resurrects it.
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 Class F readers must be able to read data
in both bit orders.
3.6.3. Multi-Page
Many existing applications already read Class F-like files, but do not
support the multi- page tag. Since a multi-page format greatly
simplifies file management in fax application software, Class F
specifies multi-page documents (NewSubfileType = 2).
3.6.4. Two-dimensional Encoding
PC Fax applications that wish to support two-dimensional encoding may
do so by setting Bit 0 in the Group3Options tag. Please see section
3.8.2.
3.6.5. Example Use of Page-quality Tags
Here are examples for writing the CleanFaxData, BadFaxLines, and
ConsecutiveBadFaxLines tags:
1. Facsimile hardware does not provide page quality information:
write no tags.
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.
Parsons, Rafferty Expires 9/26/97 [Page 10]
Internet Draft TIFF-F March 26, 1997
3.7 TIFF Class F Conformance
Fax applications that do not wish to embrace TIFF Class F as a native
format may elect to support it as import/export medium.
Export
The simplest form of support is a Class F writer that produces
individual single-page Class F files with the proper NewSubFile
tag and the PageNumber (page one-of-one) tag.
Import
A Class F reader must be able to handle a Class F file containing
multiple pages.
3.8
3.8.1 Uncompressed data
Class 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.
3.8.2 Encoding and Resolution
Since two-dimensional encoding is not required for Group 3
compatibility, some historic Class 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 to read and write
one-dimensional (Modified Huffman) files.
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: 392v x 203h and 392v x 406h. Therefore, the inch-based
equivalents of the new resolutions are supported in the TIFF 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. 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 supported in the TIFF-F writer.
Parsons, Rafferty Expires 9/26/97 [Page 11]
Internet Draft TIFF-F March 26, 1997
3.8.3 EOL byte-aligned
In the spirit of TIFF, all EOLs in 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 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 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).
3.8.4. EOL
As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents begin
with an EOL (which in Class F is byte-aligned). The last line of the
image is not terminated by an EOL.
3.8.5 RTC Exclusion
Aside from EOLs, TIFF Class F files contain only image data. This
means that the Return To Control sequence (RTC) is specifically
prohibited. Exclusion of RTCs not only makes possible the simple
concatenation of images, it eliminates the mischief--failed
communications and unreadable images--that their mistreatment
inevitably produces.
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 Tags 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.
There are only minor semantic differences between the Reader and the
Writer. As a general rule, applications should be flexible in the
TIFF-F files that they are able to read and strict in the writing of
new TIFF-F files. For many Internet applications, only the Reader
needs to be implemented. The specific tag support required for each of
these variations is summarized below.
Parsons, Rafferty Expires 9/26/97 [Page 12]
Internet Draft TIFF-F March 26, 1997
3.9.1 TIFF Reader
The tags in following table are specified for a TIFF Reader. Legal
values are as shown. If required tags are omitted, the 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)
Parsons, Rafferty Expires 9/26/97 [Page 13]
Internet Draft TIFF-F March 26, 1997
3.9.1.1 Tags for TIFF-F Reader
Tag | Legal | Default | Comment
------------------|-------------|--------------|----------------------
BitsPerSample | 1 | 1 |one bit per sample
CleanFaxData | 0 | 0 |data has no errors
Compression | 3,4 | 3 |T.4 bi-level encoding,
| | | MH or T.6, MMR
FillOrder | 2,1 | 2 |LSB first or MSB first
ImageWidth | 1728, 2048, | 1728 |depends on XResolution
| 2482, 2592, | |
| 3072, 3723, | |
| 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 | 0 |0 is white
ResolutionUnit | 2,3 | 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |
SamplesPerPixel | 1 | 1 |one sample per pixel
StripByteCounts | >0 | |required
StripOffsets | >0 | |required
T4Options | 4 | 4 |MH (incl. if not MMR)
T6Options | 0 | 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 | If unit is per inch
| 200,300,392,| |
| 400 | |
| 77,38.5 | | If unit is per cm
------------------|-------------|--------------|----------------------
Other tags may be present, but they should be of an informational
nature, so that a reader can elect to ignore them.
Informational tags which are often present in TIFF-F images are:
Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines
Parsons, Rafferty Expires 9/26/97 [Page 14]
Internet Draft TIFF-F March 26, 1997
3.9.2 TIFF Writer
For the case of writing (creating) a TIFF-F file format from an image
data stream or other raster data, implementations should use the TIFF-
F tags in the following table as a default. All tags should be
included so as to minimize dependencies on default values. 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.
For a TIFF-F Writer, the legal value is:
ByteOrder: II (least significant byte to the most significant
byte)
3.9.2.1 TIFF-F Writer Tags
Tag | Legal Value | Comment
------------------|-------------|--------------------------------
BitsPerSample | 1 | one bit per sample
Compression | 3 | T.4 bi-level encoding, MH
FillOrder | 2 | LSB first
ImageWidth | 1728, 2048, | depends on XResolution
| 2482, 2592, |
| 3072, 3723, |
| 3456, 4096, |
| 4864 |
ImageLength | > 0 |
NewSubFileType | 2 | single page of multi-page file
PageNumber | X/X | pg/tot, 0 base, tot in 1st IFD
PhotometricInterp | 0 | 0 is white
ResolutionUnit | 2 | inches
RowsPerStrip | >0 | must be same as ImageLength
SamplesPerPixel | 1 | one sample per pixel
StripByteCounts | >0 | as appropriate
StripOffsets | >0 | as appropriate
T4Options | 4 | MH, byte aligned EOL
Xresolution | 204,200, |
| 300,400,406 |
Yresolution | 196,98,100, |
| 200,300, |
| 392,400 |
------------------|-------------|--------------------------------
For many applications, it is preferable to use T.6 compression in
place of one-dimensional T.4 compression. For this case, the defaults
are revised as specified in section 3.9.2.3.
Parsons, Rafferty Expires 9/26/97 [Page 15]
Internet Draft TIFF-F March 26, 1997
3.9.2.2 Optional TIFF-F Writer Tags
The following tags are optional. If they are present, they must
contain the values as shown:
Tag | Legal Value | Comment
------------------|-------------|-----------------------------------
CleanFaxData | 0 |data doesn't contain bad scan lines
Orientation | 1 |1st row = top left, 1st col = top
------------------|-------------|-----------------------------------
Other tags may be present, but they should be of an informational
nature, so that a Reader may elect to ignore them.
Informational tags that may be useful are:
Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines
TIFF Writers should only generate tags 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 tags are: CleanFaxData, BadFaxLines and
ConsecutiveBadFaxLines.
3.9.2.3 TIFF-F Writer Tags for T.6 Compression Option
For many applications, a TIFF-F writer may choose to use the T.6
compression option in place of the one-dimensional Modified Huffman
standardized in [T.4]. In this case, the rules for the TIFF-F Writer
tags and values apply, but the except as specified below:
Tag | Legal Value | Comment
------------------|-------------|-----------------------------------
Compression | 4 | ITU-T T.6 encoding, MMR
T6Options | 0 | Replaces T4Options Tag
------------------|-------------|-----------------------------------
Other tags may be present, but must be of the sort that can be ignored
safely by applications (i.e. purely for information).
4. MIME sub-type image/TIFF
The image/TIFF sub-type was originally defined in RFC 1528 as
containing TIFF 5.0 encoded image data.
This document, in section 6, re-defines the original image/TIFF
definition to refer to TIFF 6.0 encoded image data. The TIFF 6.0
specification is a cleaner document and is compatible with previous
TIFF 5.0 encoded image data. Further, an optional "class" parameter
is defined for image/TIFF to identify the TIFF Class of the encoded
image data, if it is known.
Parsons, Rafferty Expires 9/26/97 [Page 16]
Internet Draft TIFF-F March 26, 1997
5. Implementation Usage
5.1 Internet Fax Usage
The usage of TIFF-F is envisaged to be a primary component of Internet
Fax. It is anticipated that Internet Fax will make use of both a
TIFF-F Reader and TIFF-F Writer. The details of these applications
will be specified in other documents.
5.2 VPIM Usage
The image/TIFF sub-type with the Class 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.
Parsons, Rafferty Expires 9/26/97 [Page 17]
Internet Draft TIFF-F March 26, 1997
6. IANA Registration
To: ietf-types@iana.org
Subject: Registration of Standard MIME media type image/TIFF
MIME media type name: image
MIME subtype name: TIFF
Required parameters: none
Optional parameters: class
The Classes of TIFF are denoted by letters. There are
currently five valid values of class:
B - Bilevel
G - Grayscale
P - Palette
R - RGB, and
F - Bi-Level Facsimile
There is no default value for class, as the absence of the
class parameter indicates that the class of the encoded TIFF
image is unknown or unnecessary to be known. The onus is on
the displaying software to determine the class (if necessary)
and present the image to the user.
Encoding considerations: Binary or Base-64 generally preferred
Security considerations: none
Interoperability considerations:
The ability of implementations to handle all the defined
classes of TIFF may not be ubiquitous. As a result, the
absence of the class parameter would force implementations to
decode and attempt to display the encoded TIFF image data in
order to determine if it could actually be viewed.
Published specification:
TIFF (Tag Image File Format) and most of the classes are
defined in:
TIFF (TM) Revision 6.0 - Final _ June 3, 1992
Adobe Developers Association
Adobe Systems Incorporated
1585 Charleston Road
P.O. Box 7900 Mountain View, CA 94039-7900
A copy of this specification can be found in:
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/
pdffiles/tiff6.pdf
Parsons, Rafferty Expires 9/26/97 [Page 18]
Internet Draft TIFF-F March 26, 1997
TIFF Class F is defined in this document in section 3
Applications which use this media type:
primarily fax and voice messaging
Additional information:
Magic number(s):
II (little-endian): 49 49 42 00 hex
MM (big-endian): 4D 4D 00 42 hex
File extension(s): .TIF
Macintosh File Type Code(s): TIFF
Person & email address to contact for further information:
Glenn W. Parsons
Glenn.Parsons@Nortel.ca
James Rafferty
Jrafferty@worldnet.att.net
Intended usage: COMMON
Author/Change controller:
James Rafferty
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
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
Parsons, Rafferty Expires 9/26/97 [Page 19]
Internet Draft TIFF-F March 26, 1997
8. References
[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
[TIFFB] D. Cohen, A. Katz, "A File Format for the Exchange of Images
in the Internet", RFC 1314, 04/10/1992.
[TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final,
June 3, 1992.
[TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the
TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
1528, 10/06/1993
[VPIM2] Greg Vaudreuil and Glenn Parsons, "Voice Profile for Internet
Mail - version 2", <draft-ema-vpim-05.txt>, March 1997.
Parsons, Rafferty Expires 9/26/97 [Page 20]
