view Side-By-Side changes
Network Working Group Glenn Parsons
Internet Draft James Rafferty
Expires in six months March 26, May 30, 1997
Tag Image File Format (TIFF) - Class Application F
<draft-ietf-fax-tiff-01.txt>
<draft-ietf-fax-tiff-02.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 TIFF-F that is
used to store facsimile images and also describes the registration
refinement of the MIME sub-type image/tiff. image/tiff for Application F. The Class F tag
TIFF-F encoding has been folklore with no specific 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 March 26, May 30, 1997
1. Abstract
This document formalizes the reference for the Tag Image File
Format (TIFF) and formally defines TIFF Class F TIFF-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,
345 Park Avenue
San Jose, CA 94039-7900 95110-2704
Phone: +1-408-536-6000
Fax: +1-408-537-6000
A copy of this specification can also be found in:
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/
tiff6.pdf
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/ti
ff6.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.
Parsons, Rafferty Expires 11/30/97 [Page 2]
Internet Draft TIFF-F May 30, 1997
- 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 TIFF-F Definition
Though it has been in common usage for many years, TIFF Class F (or
TIFF-F) 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 TIFF-F for Internet applications.
3.1 The Spirit of TIFF-F
Up until TIFF 6.0, TIFF supported various "Classes" which defined
the use of TIFF for various applications. The intent of Classes
had been to reduce the information burden on TIFF readers and
writers that wish wished 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 this
spirit, TIFF-F has been known historically as "TIFF Class to give up
if the characteristic tags F" 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
previous informal TIFF-F documents without the NewSubFileType and PageNumber tags.
Not so for a Class F file, where used this terminology.
In the multi-page tag is required even
for a single page. context of TIFF Classes, TIFF Class F is had been a sub-class
of TIFF Class B (Bilevel) [TIFFB]. (Bilevel). That is, all tags fields that are were required
in Class B are were also required in Class F. For some common tags, fields,
however, Class F limits TIFF-F has historically limited the range of acceptable
values. The YResolution tag,
values, based on requirements for example, is a Class B tag, but
within the facsimile application and the
need to stay aligned with ITU-T recommendations.
As of TIFF 6.0 [TIFF], the TIFF Class F only a limited set concept has been eliminated
in favor of the concept of Baseline TIFF. Therefore, this
document will update the definition of TIFF-F based on the
conventions used in TIFF 6.0. In almost all cases, the resulting
definition of TIFF-F fields and values is permitted. Such tags
are listed will be consistent with
those used historically in section 3.2
Section 3.3 discusses other earlier definitions of TIFF Class B tags that F.
Where some of the values for fields have a specific meaning
when applied been updated to provide
more precise conformance with the ITU-T [T.30] fax protocol, these
differences will be noted. The intent of this specification will
be to clearly document:
1) A minimum set of TIFF-F fields and values which should be able
to interwork with virtually all historic TIFF-F readers.
2) A broader range of values for the traditional TIFF-F fields
that will provide support for the most widely used facsimile images.
compressions, page sizes and resolutions, consistent with the
ITU-T [T.30] recommendation.
Parsons, Rafferty Expires 11/30/97 [Page 3]
Internet Draft TIFF-F May 30, 1997
The structure of the TIFF-F definition will be as follows. A
review of the structure of TIFF files and practical guidelines for
TIFF-F files in particular is provided in sections 3.1.1 and 3.1.2
The 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 new Class F tags
fields that are
discussed specific extensions for TIFF-F are reviewed in
section 3.4. There are also tags fields that may be helpful helpful, but are
not required. These recommended tags 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 TIFF-F tags and recommended fields for each of these implementations a TIFF-F Reader is summarized.
provided, along with details on the minimum and permitted set of
values for TIFF-F purposes.
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), etc.), a count
(which indicates the number of values/offsets) and a value/offset.
However, the actual value for the
tag 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
tag. 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.
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 will generally have 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
Parsons, Rafferty Expires 11/30/97 [Page 4]
Internet Draft TIFF-F May 30, 1997
each IFD, the location of the related image data is defined by
using tags fields that are associated with strips. These tags 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 on structuring a multi-page TIFF-F file may
yield benefits for implementers, especially for application applications 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 TIFF-
F beginning with page 0 as the first page and then ascending (i.e.
0, 1, 2, _).
Per [TIFF], the exact ...). However, as noted in 3.1.1, any field values over
4 bytes will be stored separately from the IFD.
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 fields that are related
to strips. From an
implementer's implementor'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 structure. (The pages of image data may themselves
be stored in a contiguous manner, at the option of the
implementer).
3.2 Class F Baseline TIFF Required Tags
FillOrder = 1, 2. SHORT. Fields for BiLevel Images
Baseline TIFF Class F readers must per [TIFF] requires that the following fields be able to read data in both bit orders,
present for all BiLevel Images: ImageWidth, ImageLength,
Parsons, Rafferty Expires 11/30/97 [Page 5]
Internet Draft TIFF-F May 30, 1997
Compression, Photometric Interpretation, StripOffsets,
RowsPerStrip, StripByteCounts, Xresolution, YResolution and
ResolutionUnit. TIFF-F uses all of these fields, but the vast majority in some
cases specifies a different range of facsimile products store data LSB first,
exactly as it appears on acceptable values than
Baseline TIFF. Per [TIFF], if fields are omitted, the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first. Baseline
TIFF default value(if specified) will apply.
A brief summary of these fields and their use in TIFF-F follows:
ImageWidth = 1728, 2048, 2482, 2432, 2592, 3072, 3723, 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 Table 2 of [T.4].
NewSubFileType = 2. LONG.
The value sections 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 and 3 of measure [T.4] and reproduced here for resolution:
2 = Inch
3 = Centimeter
convenience:
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 = x Yresolution | ImageWidth
-------------------------------------------|------------------
204 x 98, 204 x 196, 100, 200, 300, 200 x 100, 200 x 200 | 1728, 2048, 2432
300 x 300 | 2592, 3072, 3648
406 x 392, 400 (inches). RATIONAL.
The vertical resolution of x 400 | 3456, 4096, 4864
-------------------------------------------|------------------
Historical TIFF-F did not include support for the image expressed in pixels per
resolution unit. Some existing following
widths related to higher resolutions: 2592, 3072, 3648, 3456,
4096 and 4864. Historical TIFF-F implementations may documents also support included the
following values related to A5 and A6 widths: 816 and 1216.
Per the most recent version of 77, 38.5 (cm).
3.2.1
In [T.4], A5 and A6 documents are
no longer supported in Group 3 facsimile, there so the related width
values are three compression methods which had
been standardized as of 1994 now obsolete. See section 3.8.2 for more
information on inch/metric equivalencies and are in common use. other
implementation details.
ImageLength. SHORT or LONG. LONG recommended.
The ITU-T T.4
recommendation defines total number of scan lines in the image.
Compression = 3,4. SHORT.
This is a one-dimensional compression method known as
Parsons, Rafferty Expires 9/26/97 [Page 5]
Internet Draft required TIFF-F March 26, 1997
Modified Huffman (MH) field. The permitted values for TIFF-
F purposes are 3 and a two-dimensional method known 4 as Modified
READ (MR) (READ shown. The default value per
Baseline TIFF is short 1 (Uncompressed), but this value is invalid
for Relative Addressing). In 1984, facsimile images. Baseline TIFF also permits use of
value 2 (Modified Huffman encoding), but the data is presented
in a
somewhat more efficient compression method known as 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 (MMR) was defined in the T.6 recommendation. It was originally
defined data. The detailed settings
which apply for T.4 encoded data are specified using the
T4Options field. TIFF-F also permits use with Group of the value 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
the compression methods. By default, field, which indicates that the one-dimensional data is coded
using a [T.6] compression method is used. Optionally, depending
upon the application, (i.e the more efficient Modified Modified
READ two-dimensional compression
method from method). The detailed settings which apply
for T.6 (i.e. MMR or "Group 4 compression") may be selected.
More information encoded data are specified using the T6Options field.
Please refer to aid the implementor in making this selection is
contained definitions of the T4Options and T6Options
fields in section 3.3, and section 3.8 for more information on Implementation Warnings.
The tags used to specify
the compression are shown below:
Compression encoding of images and conventions used within TIFF-F.
Parsons, Rafferty Expires 11/30/97 [Page 6]
Internet Draft TIFF-F May 30, 1997
PhotometricInterpretation = 3,4. 0,1. 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 field allows notation of a an inverted ("negative") image:
0 = normal
1
byte preceded by a zero nibble: xxxx0000 00000001. = inverted
StripOffsets. SHORT or LONG.
For each strip, the offset of that strip. The data in a
Class F image offset is not terminated with an RTC (see sections 3.8.4
and 3.8.5). For two-dimensional encoding, set
measured from the value beginning of the
compression tag to 4 (see section 3.8.2).
T4Options = 4,5. LONG.
This tag file. If a page 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 expressed
as one large strip, there 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 one such entry per page.
RowsPerStrip. SHORT or LONG.
This tag LONG recommended.
The number of scan lines per strip. When a page is required for TIFF Class F if the two-dimensional
compression method expressed
as one large strip, this is specified (i.e. by setting the value of same as the
Compression tag to 4). Data is two-dimensional and there is no
use ImageLength field.
StripByteCounts. LONG or SHORT. LONG recommended.
For each strip, the number of EOLs. Uncompressed data bytes in that strip. If a page is not allowed. In earlier versions
of TIFF,
expressed as one large strip, this tag was named Group4Options. The significance has
not changed and the present definition is compatible. This field is made up the total number of a set bytes
in the page after compression. Note that the choice of 32 flag bits. Unused bits must be set to 0.
Bit 0 is LONG or
SHORT depends upon the low-order bit. The default value is 0 (all bits 0).
bit 0 = 0 for 2-Dimensional
bit 1 size of the strip.
ResolutionUnit = 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 2,3. SHORT.
The units of their usage measure for facsimile images may be helpful. 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, 392, 400 (inches). RATIONAL.
The vertical resolution of the TIFF-F image expressed in pixels
per resolution unit. The values of 100, 200, and 392 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:
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 6] 7]
Internet Draft TIFF-F March 26, May 30, 1997
BitsPerSample = 1. SHORT.
Since facsimile TIFF-F is a only used for black-and-white medium, this must be facsimile
images, the value is 1 (the default) for all files.
ImageLength. SHORT or LONG. LONG recommended.
The total number of scan lines in the image.
PhotometricInterp
FillOrder = 0,1. 1, 2. SHORT.
This tag allows notation
TIFF F readers must be able to read data in both bit orders,
but the vast majority of an inverted ("negative") image:
0 = normal facsimile products store data LSB
first, exactly as it appears on the telephone line.
1 = inverted
Software. ASCII.
The optional name and release number 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 software package that
created the image.
RowsPerStrip. SHORT or LONG. LONG recommended.
The number 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 scan lines per strip. When a multi-page 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 is expressed as
one large strip, this numbers in the fax document. The
field comprises two SHORT values: the first value is the same as page
number, the ImageLength tag. second is the total number of pages. Single-page
documents therefore use 00000001 hex.
SamplesPerPixel = 1. SHORT.
The value of 1 denotes a bi-level, grayscale, or palette color
image.
StripByteCounts. SHORT or
T4Options = 4,5. LONG. SHORT recommended.
For each strip, the number of bytes in that strip. If a page is
expressed as one large strip, this
This field is required if the total number of bytes in
the page after compression.
StripOffsets. SHORT or LONG.
For each strip, value for the offset of that strip. compression field
has been set to 3. 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 values are only three new tags set as shown below for Class TIFF-
F. All three tags describe
page quality. The information contained in these tags For TIFF-F, uncompressed data is usually
obtained from the receiving facsimile hardware, but since not all
devices are capable of reporting this information, the tags allowed and EOLs are
optional.
Some applications need to understand exactly the error content of
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
data. For example, a CAD program might wish to verify that a file has
a low error level before importing it into order bit. Please note that T4Options was
known as G3Options in earlier versions of TIFF and TIFF-F.
The data in a high-accuracy document.
Because Group 3 facsimile devices do not necessarily perform error
correction on the TIFF-F image data, the quality encoded using one of a received page must be
inferred from the pixel count of decoded scan lines. A "good" scan
line T.4 methods
is defined as a line that, when decoded, contains not terminated with an RTC (see 3.8.5).
T6Options = 0 LONG.
This field is required for TIFF F if value of the correct
number compression
field has been set to 4. The value for this field is made up of pixels. Conversely,
a "bad" scan line set of 32 flag bits. Setting bit 0 to 0 indicates that the
data is defined as a line
that, when decoded, comprises 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 incorrect number "end-of-facsimile-block" (EOFB) code at the
end of pixels. each coded strip (see 3.8.6). Uncompressed data is not
applicable for bi-level facsimile images, so that bit 1 must be
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 7] 8]
Internet Draft TIFF-F March 26, May 30, 1997
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).
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 tag 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)
Many facsimile devices do not actually output bad lines.
Instead, the previous good line is repeated in place of a bad
Parsons, Rafferty Expires 11/30/97 [Page 9]
Internet Draft TIFF-F May 30, 1997
line. Although this substitution, known as line regeneration,
results in a visual improvement to the image, the data is
nevertheless corrupted. The CleanFaxData tag field describes the
error content of the data. That is, when the BadFaxLines and
ImageLength tags fields indicate that the facsimile device
encountered lines with an incorrect number of pixels during
reception, the CleanFaxData tag 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 tag 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 tag field 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 Fields
These are fields that may be used in encoding TIFF-F March 26, 1997 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 tag 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.
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.
Parsons, Rafferty Expires 11/30/97 [Page 10]
Internet Draft TIFF-F May 30, 1997
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 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 tags 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 tags. fields. The location in the TIFF file of each strip
is contained in the StripOffsets tag. field.
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 field in
the category "No Longer Recommended," Class F resurrects TIFF-F utilizes 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 TIFF-F readers must be
able to read data in both bit orders.
Parsons, Rafferty Expires 11/30/97 [Page 11]
Internet Draft TIFF-F May 30, 1997
3.6.3. Multi-Page
Many existing applications already read Class F-like TIFF-F like files, but do
not support the multi- page tag. field. Since a multi-page format
greatly simplifies file management in fax application software, Class F
TIFF-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 Compression
In Group 3 facsimile, there are three compression methods which had
been standardized as of Page-quality Tags
Here 1994 and are examples for writing the CleanFaxData, BadFaxLines, in common use. The ITU-T T.4
recommendation defines a one-dimensional compression method known
as Modified Huffman (MH) and
ConsecutiveBadFaxLines tags:
1. Facsimile hardware does not provide page quality information:
write no tags.
2. Facsimile hardware provides 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.
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.
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 10] 12]
Internet Draft TIFF-F March 26, May 30, 1997
3.7 TIFF Class F TIFF-F Conformance
Fax applications that do not wish to embrace TIFF Class F support TIFF-F as a native
format may elect to support it as import/export medium.
Export
The simplest form of support
It is a Class F writer recommended that produces applications export multiple page TIFF-F
files without manipulating fields and values. Historically, some
TIFF-F writers have attempted to produce individual single-page Class F
TIFF-F files with the proper modified NewSubFile
tag and the PageNumber (page one-of-one) tag. one-of-
one) values for export purposes. However, there is no way to link
such multiple single page files together into a logical multiple
page document, so that this practice is not recommended.
Import
A Class F TIFF-F reader must be able to handle a Class F TIFF-F file containing
multiple pages.
3.8 Implementation Warnings
3.8.1 Uncompressed data
Class F
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.
3.8.2 Encoding and Resolution
Since two-dimensional encoding is not required for Group 3
compatibility, some historic Class F 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 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: 392v x 203h and 392v x 406h. Therefore, the full set
of inch-based equivalents of the new resolutions are supported in
the TIFF 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.
Parsons, Rafferty Expires 11/30/97 [Page 13]
Internet Draft TIFF-F May 30, 1997
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
<392, 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 supported in recommended for the creation of
TIFF-F files by a 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, 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 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 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 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 Class F TIFF-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 In a similar respect, images encoded with the T.6 Modified Modified READ
compression method should include two
dimensional encoding begin with an "end-of-facsimile-block" (EOFB)
code at the end of each coded strip. Per [TIFF], the EOFB code is EOL, 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 bit. The
EOL/tag bit combination is per inch
| 200,300,392,| |
| 400 | |
| 77,38.5 | | If unit 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 per cm
------------------|-------------|--------------|----------------------
Other tags may be present, but they should be specifically excluded.
3.8.6 Use of an informational
nature, so that a reader can elect to ignore them.
Informational tags EOFB for T.6 Compressed Images
TIFF-F pages which are often present in TIFF-F images are:
Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines encoded with the T.6 Modified Modified READ
compression method should include an "end-of-facsimile-block"
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 14]
Internet Draft TIFF-F March 26, May 30, 1997
3.9.2 TIFF Writer
For
(EOFB) code at the case end of writing (creating) 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 file format from 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
data bit stream or other raster data, implementations 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 use the TIFF-
F tags provide maximum portability with historical
TIFF-F readers. If required fields are omitted in the following table as a default. All tags should be
included so as to minimize dependencies on TIFF-F file,
the Baseline TIFF default values. 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 Writer, Reader, the legal value is: values are:
ByteOrder: II (least significant MM,II (Either byte to the most significant
byte)
3.9.2.1 order is allowed)
Parsons, Rafferty Expires 11/30/97 [Page 15]
Internet Draft TIFF-F Writer Tags
Tag May 30, 1997
3.9.1.1 Fields for TIFF-F Reader
Field | Legal Value Values | Minimum | Comment
------------------|-------------|--------------------------------
------------------|-------------|--------------|----------------------
BitsPerSample | 1 | one 1 |one bit per sample
Compression | 3 3,4 | 3 |3 for T.4 bi-level encoding, MH (MH, MR)
| | |4 for T.6 - MMR
FillOrder | 2 2,1 | LSB 2 |LSB first or MSB first
ImageWidth | 1728, 2048, | depends 1728, 2048 |depends on XResolution
| 2482, 2432, 2592, | |
| 3072, 3723, 3648, | |
| 3456, 4096, | |
| 4864 | |
ImageLength | > 0 >0 | |required
NewSubFileType | 2 | single 2 |single page of multi-page
| | |multipage file
Orientation * | 1 | 1 |1st row=top left,
| | | 1st col=top
PageNumber | X/X | pg/tot, 0/1 |pg/tot, 0 base,
| | | tot in 1st IFD
PhotometricInterp | 0 0,1 | 0 |0 is white
ResolutionUnit | 2 2,3 | inches 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |
| or other | >0 | must be same as ImageLength
SamplesPerPixel | 1 | one 1 |one sample per pixel
StripByteCounts | >0 | as appropriate |required
StripOffsets | >0 | as appropriate |required
T4Options | 4,5 | 4 |MH,MR(incl if not MMR)
T6Options | MH, byte aligned EOL 0 | |MMR (incl only if MMR)
Xresolution | 204,200, 204,200,300,| 204 | If unit is per inch
| 400,406 | | If unit is per inch
| 77 | 300,400,406 | If unit is per cm
Yresolution | 196,98,100, | 196,98 | If unit is per inch
| 200,300,392,| | 200,300, If unit is per inch
| 400 | 392,400 |
------------------|-------------|--------------------------------
For many applications, it If unit is per inch
| 77,38.5 | | If unit is preferable per cm
------------------|-------------|--------------|--------------------
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 use T.6 compression ignore them.
Informational fields which are often present in
place of one-dimensional T.4 compression. TIFF-F images
are:
Software, Datetime, BadFaxLines, CleanFaxData and
ConsecutiveBadFaxLines.
3.9.2 TIFF-F Writer
For this case, the defaults
are revised 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 specified defined in section 3.9.2.3.
3.9.1. It is recommended that all fields from the table in 3.9.1.1
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 15] 16]
Internet Draft TIFF-F March 26, May 30, 1997
3.9.2.2 Optional
should be included when writing TIFF-F Writer Tags
The following tags are optional. If they are present, they files in order to minimize
dependencies on default values. Image data 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
------------------|-------------|----------------------------------- not have any coding
errors.
Other tags fields may be present, but they should be of an informational
nature, so that a Reader may elect to ignore them.
Informational tags fields that may be useful are:
Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines
TIFF Writers should only generate tags 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 tags fields 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, [TIFFREG] 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, In addition,
an optional "class" "application" parameter is defined for image/TIFF to
identify the TIFF Class application of the encoded image data, if it is known.
Parsons, Rafferty Expires 9/26/97 [Page 16]
Internet Draft TIFF-F March 26, 1997 it is
known.
Example:
Content-type: image/TIFF; application=F
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 application F parameter (i.e. TIFF-F 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 11/30/97 [Page 17]
Internet Draft TIFF-F March 26, May 30, 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 Security Consideration
This document describes the encoded TIFF
image is unknown or unnecessary to be known. The onus encoding for TIFF-F, which 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 an
application of implementations to handle all the defined
classes of TIFF may not be ubiquitous. encoding. 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 such, it could actually be viewed.
Published specification: does not create any
security issues not already existing in TIFF (Tag Image File Format) and most of (though, none have
been identified).
Further, 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 encoding specified in this document does not in section 3
Applications which any
way preclude the 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 of any Internet security protocol 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 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
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.
[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-00.txt>, May 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] Greg G. Vaudreuil and Glenn G. Parsons, "Voice Profile for Internet
Mail - version 2", Work In Progress, <draft-ema-vpim-05.txt>, March
May 1997.
Parsons, Rafferty Expires 9/26/97 11/30/97 [Page 20] 18]
----