As per Relevance of the word exchange, we have this rfc below:
Network Working Group A.
Request for Comments: 1314 D.
April 1992
A File Format for the Exchange of Images in the
Status of This
This document specifies an IAB standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
This document defines a standard file format for the exchange
fax-like black and white images within the Internet. It is a
of the Network Fax Working Group of the Internet Engineering
Force (IETF).
The standard is
** The file format should be TIFF-B with multi-page
supported. Images should be encoded as one TIFF
per page
** Images should be compressed using MMR when possible.
may also be MH or MR compressed or uncompressed. If MH or
compression is used, scan lines should be "byte-aligned".
** For maximum interoperability, image resolutions
either be 600, 400, or 300 dpi; or else be one of
standard Group 3 fax resolutions (98 or 196
vertically and 204 dpi horizontally).
Note that this specification is self contained and an
should be possible without recourse to the TIFF references, and
only the specific TIFF documents cited are relevant to
specification. Updates to the TIFF documents do not change
specification
Experimentation with this file format specified here is encouraged
Katz & Cohen [Page 1]
RFC 1314 Image Exchange Format April 1992
1.
The purpose of this document is to define a standard file format
exchange of black and white images using the Internet. Since
organizations have already started to accumulate and exchange
documents it is important to reach agreement about an
file format in order to promote and facilitate the exchange
distribution of such documents. These images may originate
scanners, software, or facsimile (fax) machines. They may
manipulated by software, communicated, shared, duplicated, displayed
printed by laser printers, or faxed
This file format provides for the uniform transfer of high
images at a reasonable cost and with reasonable speed whether
files are generated by scanners, totally by software (e.g., text-to
fax, bitmap-to-fax, OCR, etc), or by fax. Also the intent of
document is to remain compatible with future moves to multi-
(i.e., gray-scale), higher resolution, or color images. The
proposed here is supported by both commercially available
and commercial and public domain software for most popular
in current use
The file format for images is a totally separate issue from how
files are to be communicated. For example, FTP or SMTP could be
to move an image file from one host to another, although there
complications in the use of SMTP as currently implemented due to
size and the need to move binary data. (There is currently
proposal for removing these limitations from SMTP and in
extending it to allow binary data. See reference [1].)
One major potential application of the communications format
here is to allow images to be sent to fax machines using
Internet. It is intended that one or more separate
documents will be formulated to address the issues of
in the areas of protocols for transmitting images through
Internet and the issues of addressing fax machines and routing faxes
Just as the exchange format is separate from the
mechanism, it is also separate from how hosts store images
This document specifies a common exchange format; it does not
a host to store images in the format specified here, only to
between the host's local image storage formats and the
format defined here for the purpose of exchanging images with
hosts across the network
This standard specifies the use of TIFF (Tagged Image File Format
see below) as a format for exchange of image files. This is not
specific image encoding, but a framework for many
Katz & Cohen [Page 2]
RFC 1314 Image Exchange Format April 1992
techniques, that can be used within the TIFF framework. For example
within TIFF it is possible to use MMR (the data encoding of
Group 4 fax, see below), MH or MR (the data encodings of CCITT
3 fax), or other encoding methods
Which encoding technique to use is not specified here. Instead,
time the encoding schemes used by most document providers will
as the de-facto standard. Therefore, we do not declare any as "
standard data encoding scheme," just as we do not declare
English is the standard publication language. (However, we
that most document providers will use MMR in the immediate
because it offers much better compression ratios than MH or MR.)
Similarly, TIFF does not require that an image be communicated at
specific resolution. Resolution is a parameter in the
descriptive header. We do suggest that images now be sent using
of a set of common resolutions in the interests of interoperability
but the format accommodates other resolutions that may be required
specialized applications or changing technologies
Occasionally, image files will have to be converted, such as in
case where a document that was scanned at 400 dpi is to be printed
a 300 dpi printer. This conversion could be performed by
document provider, by the consumer, or by a third party.
document specifies neither who performs the conversion, nor
algorithms should be used to accomplish it
Note that this standard does not attempt to define an exchange
for all image types that may be transmitted in the Internet.
in this standard precludes it from being used for other image
such as gray-scale (e.g., JPEG) or color images but, for the
of standardization, the scope of this document is restricted
monochromatic bitmapped images
The developers of this standard recognize that it may have a
lifespan as Office Document Architecture (ODA) matures and comes
use in the Internet; ultimately the class of images covered by
standard will likely be subsumed by the more general class of
supported by the ODA standards. However, at present, there does
appear to be a sufficient installed base of ODA compliant
and the ODA standards are not fully mature. This standard
intended to fill the need for a common image transfer format
ODA is ready. Finally, we believe that it should be possible
automatically map images encoded in the format specified here into
future ODA-based image interchange format, thus providing
reasonable transition path to these future standards
Katz & Cohen [Page 3]
RFC 1314 Image Exchange Format April 1992
2. Relationship to
Transmission of facsimile (fax) images over phone lines is
increasingly widespread. The standard of most fax machines in
U.S. is CCITT Group 3 (G3), specified in Recommendations T.4
T.30 [2] and in EIA Standards EIA-465 and EIA-466. G3 faxes are 204
dots per inch (dpi) horizontally and 98 dpi (196 dpi optionally,
fine-detail mode) vertically. Since G3 neither assumes error
transmission nor retransmits when errors occur, the encoding
used is differential only over small segments never exceeding 2
at standard resolution or 4 lines for fine-detail. (The
G3 encoding scheme is called two-dimensional and the number of
so encoded is specified by a parameter called k.)
CCITT Group 4 fax (G4) is defined by the T.400 and T.500 series
Recommendations as well as Recommendation T.6 [2]. It provides
400 dpi (both vertical and horizontal) and is a fully two-
encoding scheme (k is infinite) called MMR (Modified Modified READ
where READ stands for: Relative Element Address Designate). G
assumes an error free transmission medium (generally an X.25
Data Network, or PDN). Because of this, G4 is not in widespread
in the U.S. today
The traditional fax bundles together four independent issues
(1) Data presentation and compression
(2) Data transmission
(3) Image input from paper ("scanning");
(4) Image output to paper ("printing").
This bundling supports, for example, the high quality CCITT Group 4
(G4) images (400x400 dpi) but only over X.25 public data
with error correction, and similarly it supports the mid-
CCITT Group 3 (204x98 and 204x196 dpi) but only over phone
circuits (the Switched Telephone Network, or STN) without
correction. This bundling does not support the use of any other
transmission capabilities (e.g., FTP over LANs and WANs),
asynchrony between the scanning and the printing, nor image storage
nor the use of the popular laser printers for output (even
they are perfectly capable of doing so).
In conventional fax, images are never stored. In today's
network environment, a better model is
(1) Images are scanned into files or created by software
(2) These image files are stored, manipulated, or communicated
(3) Images in a file are printed or displayed
Katz & Cohen [Page 4]
RFC 1314 Image Exchange Format April 1992
The only feature of the CCITT fax that should be used is the
technique (preferably MMR, but with MR or MH allowed) which may
implemented with a variety of fax-oriented chips at low cost due
the popularity of fax
"Sending a fax" means both encoding (and decoding) the fax images
well as transmitting the data. Since the Internet ALREADY
several mechanisms for data transmission (in particular, FTP
general file transmission), it is unnecessary to use the
transmission methods specified in the CCITT standard. Within
Internet, each fax image should be stored in a file and these
could be transferred (e.g., using FTP, SMTP, RPC-based methods
etc.).
Fax machines should be considered just as scanners and printers are
as I/O devices between paper and files; but not as a
means. Higher quality Group 4 images are thus supported at low cost
while enjoying the freedom to use any computerized file transfer
duplication mechanism, standard laser printers, multiple
(possibly at multiple remote sites) of the same image without
to rescan it physically, and a variety of software for
processing of these images, such as OCR and various drawing programs
We should be able to interoperate with files created by fax machines
scanners, or software and to be able to print all of them on
machines or on laser printers
The CCITT Recommendations assume realtime communications between
machines and do not therefore specify any kind of fax file format
We propose using TIFF [3] which seems to be emerging as a standard
for encapsulation of encoded images. Because they assume
communications, the CCITT fax protocols require negotiations to
place between the sender and receiver. For example, they
whether to use two-dimensional coding (and with what k parameter)
what (if any) padding there is between scan lines
In our approach, the image in the file is already compressed in
particular manner. If it is to be sent to an ordinary fax
using a fax board/modem, that board will perform the
with the receiving fax machine. In the cases where the
cannot handle the type of compression used in the file, it will
necessary to convert the image to another compression scheme
transmission. (Most fax cards seem to either store images using
default values of the parameters which are negotiated or in a
which can quickly be converted to this. With currently
hardware and software, any necessary format conversion should be
to accomplish.)
In conventional fax, if the compression used for a particular
Katz & Cohen [Page 5]
RFC 1314 Image Exchange Format April 1992
is "negative" (i.e., the compressed form is larger than
uncompressed form, something that happens quite frequently
dithered photographic images), the larger compressed form of
image is still sent. If the images are first scanned into files
this problem could be recognized and the smaller, uncompressed
sent instead. (Also, Recommendations T.4 and T.6 [2] allow for
"uncompressed mode." Thus, lines which have negative compression
each be sent uncompressed. However, very few G3 fax machines
this mode.)
3. Image File
Image files should be in the TIFF-B format which is the bi-
subclass of TIFF. TIFF and TIFF-B are described in reference [3],
cited at the end of this document. Images should be compressed
MMR (the G4 compression scheme) because it offers
compression ratios. However, images may also be compressed using
or MR (the G3 methods). MMR offers much better compression
than these (which are used in G3 fax because of the lack of
error-free communications path).
TIFF-F, described in [4], is the proposed subclass of TIFF-B for
images. However, since TIFF-F was intended for use with G3,
recommends against certain features we recommend. Specifically,
suggests not using MMR or MR compression (we recommend MMR and
MR) and prohibits uncompressed mode (which we allow and suggest
some photographic images). Apart from these, the TIFF-F
should be followed. (Complete compatibility between the
specified here and TIFF-F can only be guaranteed for MH
images.)
[NOTE: Aldus Corp., the TIFF Developer, considers
applications to be outside the scope of mainstream
since it is not a part of general publishing which
what TIFF was originally designed for. They specify
LZW [5] compression scheme rather than MMR. We, however
are concerned with the transmission and storage of
rather than publishing. Therefore, we are more
with compression ratios and compatibility with CCITT
than Aldus is.]
TIFF itself allows for gray-scale and color images. Image
should be restricted to TIFF-B for now because most of the
available hardware is bi-level (1 bit per pixel). In the future
when gray-scale or color scanners, printers, and fax
available, the file format suggested here can already accommodate it
(For example, though JPEG is not currently a TIFF defined
type, work is currently underway for including it as such.)
Katz & Cohen [Page 6]
RFC 1314 Image Exchange Format April 1992
[NOTE: In this document, we will use the term "reader
or "TIFF reader" to refer to the process or
which reads and parses a TIFF file.]
3.A. TIFF File
Figure 1 below (reproduced here from Figure 1 of reference [3])
depicts the structure of a TIFF file
TIFF files start with a file header which specifies the byte
used in the file (i.e., Big or Little Endian), the TIFF
number, and points to the first "Image File Directory" (IFD). If
first two bytes are hex 4D4D, the byte order is from most to
significant for both 16 and 32 bit integers (Big Endian). If
first two bytes are hex 4949, the byte order is from least to
significant (Little Endian). In both formats, character strings
stored into sequential bytes and are null terminated
The next two bytes (called the TIFF Version) must be 42 (hex 002A).
This does not refer to the current TIFF revision number.
following 4 bytes contain the offset (in bytes from the beginning
the file) to the first IFD
An IFD contains a 2 byte count of the number of entries in the IFD,
sequence of 12 byte directory entries, and a 4 byte pointer to
next IFD. One of these fields (StripOffsets) points to (parts of)
image in the file. There may be more than one image in the
(e.g., a "multi-page" TIFF file) and therefore more then one IFD
IFD field entries may appear in any order
Each directory entry is 12 bytes and consists of a tag, its type,
length, and an offset to its value. If the value can fit into 4
bytes (i.e., if the type is BYTE, SHORT, or LONG), the actual
rather than an offset is given. If the value is less than 4
(i.e., if the type is BYTE or SHORT), it is left-justified within
4 byte value offset. More details about directory entries and
possible tags will be given in Section 3.C
All pointers (called offsets in the TIFF reference [3]) are
number of bytes from the beginning of the file and are 4 bytes long
The first byte of the file has an offset of 0. In the case of
one image per file, there should therefore be only one IFD. The
IFD's pointer to the next IFD is set to hex 00000000 (32 bits).
The entries in an IFD must be sorted in ascending order by Tag
Katz & Cohen [Page 7]
RFC 1314 Image Exchange Format April 1992
+--------+--------+ Directory
0 | | | Byte Order +--------+--------+
+--------+--------| X | | |
2 | | | Version(42) +--------+--------|
+--------+--------| X+2 | | |
4 | | | Offset of +--------+--------|
+- - A - -+ 0th IFD X+4 | | |
6 | | | +- -+
+--------+--------+ | | |
| +--------+--------+
| X+8 | | |
| +- - Y - -+
V | | |
+--------+--------+
+--------+--------+ |
A | - B - | Entry Count |
+--------+--------| |
| | |
A+2 Entry 0
| | | +--------+--------+
+--------+--------+ | | |
| | | Y
A+14 Entry 1 | | |
| | | +--------+--------|
+--------+--------+
| | |
A+26 Entry 2
| | |
+--------+--------+
| | | .
.
| | | .
+--------+--------+
| | |
Entry B-1
| | |
+--------+--------+
| | | Offset
A+2+B*12 - C - + Next
| | |
+--------+--------+
|
(next IFD
Figure 1: The Structure of a TIFF
Katz & Cohen [Page 8]
RFC 1314 Image Exchange Format April 1992
3.B. Image Format and Encoding
Images in TIFF files are organized as horizontal strips for
access to individual rows. One can specify how many rows there
in each strip and all of the strips are the same size (
possibly the last one). Each strip must begin on a byte boundary
successive rows are not so required. For two-dimensional G
compression (MR), each strip must begin with an "absolute" one
dimensional line. For MMR (G4) compression, each strip must
encoded as if it were a separate image
For a variety of reasons, each page must be a single strip (e.g.,
broken up into multiple strips).
One problem with multiple strips per page is that images which
from G4 fax machines as well as most scanned images will be
as a single strip per page. These would have to be decoded and re
encoded as multiple strips (remember that for MMR compression,
strip must be start with a one-dimensionally encoded line).
Another problem with multiple strips per page arises in
compression. Here, there MAY be at most k-1 two-
encoded lines following a one-dimensionally encoded line, but this
not required. It is possible to have one-dimensional lines
frequently than every k lines. However, since each strip (
possibly the last one) is required to be the same size, it may
necessary to re-encode the image to insure that each strip
with a one-dimensional line. This is not a problem if each page is
single strip
[NOTE: The TIFF document [3] suggests using strips
are about 8K bytes long. However, TIFF-F [4]
that each page be a single strip regardless of its size
The format specified in this document follows the TIFF-
recommendation.]
Also, as TIFF-F recommends, all G3 encoded images (MH and MR)
be "byte-aligned." This means that extra zero bits (fill bits)
added before each EOL (end-of-line) so that every line starts on
byte boundary
In addition, as in the TIFF-F specification, the RTC (Return
Control signal which consists of 6 continuous EOL's) of G3 shall
be included at the end of G3 encoded documents. RTC is to
considered part of the G3 transmission protocol and not part of
encoding. Most, if not all, G3 fax modems attach RTC to
images and remove it from incoming ones
Katz & Cohen [Page 9]
RFC 1314 Image Exchange Format April 1992
For MMR (G4) encoded files, readers should be able to read
with only one EOFB (End Of Facsimile Block) at the end of the
and should not assume that Facsimile Blocks are of any
size. (It has been reported that some MMR readers assume that
Facsimile Blocks are the maximum size.)
Systems may optionally choose to store the entire image
if the compression increases the size of the image file. Also
uncompressed mode (specified in Group3Options or Group4Options,
below) allows portions of the image to be uncompressed
The multi-page capability of TIFF is supported and should be used
multi-page documents. TIFF files which have multiple pages have
IFD for each page of the document each of which describes and
to a single page image. (Note: though the current TIFF
does not specifically prohibit having a single IFD point to an
which is actually multiple pages, with one strip for each page,
if not all TIFF readers would probably not be able to read such
file. Therefore, this should not be done.)
[A NOTE ON TIFF AND MULTI-PAGE DOCUMENTS
Since most publications (e.g., reports, books,
magazine articles) are composed of more than a
page, multi-page TIFF files should be used
appropriate. However, many current TIFF
now only handle single-page files
It is hoped that in the future, more TIFF
will handle multi-page files correctly. In the meantime
it would be useful to develop a utility program
could join several single-page TIFF files into a
multi-page file and also separate a multi-page TIFF
into several single page files
For example, the utility could take a single TIFF
with N pages, called doc.tif, and create the
doc.000, doc.001, doc.002, ..., doc.N. doc.000 would
an ASCII listing of the files created. This
scheme is compatible with that used by the image
we have seen which only handle single page files
In going the other way, the N+1 single page files
be combined into a single multi-page TIFF file. In
case, if the file doc.000 exists but contains
contrary to what is found in looking for the
doc.001, doc.002, ..., the program would notify the user.]
Katz & Cohen [Page 10]
RFC 1314 Image Exchange Format April 1992
3.C. TIFF
TIFF is tag or field based. The various fields and their format
listed in [3]. There are Basic Fields (common to all TIFF files),
Informational Fields (which provide useful information to a user),
Facsimile Fields (used here), and Private Fields
Each directory entry contains
The Tag for the field (2 bytes
The field Type (2 bytes
The field Length (4 bytes
(This is in terms of the data type, not in bytes.
example, a single 16-bit word or SHORT has a
of 1, not 2)
The Value Offset (4 bytes
(Pointer to the actual value, which must begin on
word boundary. Therefore, this offset will
be an even number. If the Value fits into 4 bytes,
Value Offset contains the Value instead. If the
takes less than 4 bytes, it is left justified
The allowed types and their codes are
1 = BYTE 8-bit unsigned integer (1 byte
2 = ASCII 8-bit ASCII terminated with a null (
length
3 = SHORT 16-bit unsigned integer (2 bytes
4 = LONG 32-bit unsigned integer (4 bytes
5 = RATIONAL Two LONGs (64 bits) representing
numerator and denominator of a fraction
In this document, RATIONAL's will be
as numerator/denominator. (8 bytes
For ASCII, the Length specifies the number of characters and
the null. It does not, however, include padding if such
necessary
(Note that ASCII strings of length 3 or less may be stored in
Value Offset field instead of being pointed to.)
Katz & Cohen [Page 11]
RFC 1314 Image Exchange Format April 1992
The following fields should be used in a TIFF image file. Only
Basic Fields are mandatory; the others are optional (except that
MH and MR encoded files, the Group3Options Facsimile Field
mandatory). The optional fields have default values which are
in the TIFF specification. (Note that the TIFF reference [3]
recommends not relying on the default values.)
Some fields contain one or more flag bits all stored as one value
In these cases, the bit labeled 0 is the least significant bit (i.e.,
Little Endian order). Where there is more than one suggested
for a tag, the possible values are separated by |.
Note that some fields (such as ImageLength or ImageWidth) can be
more than one type
It would be useful to develop a TIFF viewer and editor which
allow one to read, add, and edit the fields in a TIFF file. Such
editor would display fields in sorted order and force the
of all mandatory fields. Also, resolution and position should
be displayed or specified together with their units
3.C.1. Basic Fields (Mandatory
Basic Fields are those which are fundamental to the
architecture or visual characteristics of an image. The
Basic Fields should be included in a TIFF image file
FIELD
(TAG in hex, TYPE) VALUE
------------------ ----- -----------
BitsPerSample 1 Number of
(0102, SHORT) per pixel (bi-level
now, but may
more later
Compression 4 Type of
(0103, SHORT) (could also be 1 =
1 or 3) 3 = G3 (MH or MR
4 = G4 (MMR
Use 4 if
ImageLength Length of the
(0101, SHORT in scan
or LONG
ImageWidth Width of the
(0100, SHORT in
Katz & Cohen [Page 12]
RFC 1314 Image Exchange Format April 1992
or LONG
NewSubFileType 0 usually Flag bits
(00FE, LONG) bit 0: 1 if the kind of image
reduced (see the
resolution of reference [3])
another
bit 1: 1
single page of
multi-page
bit 2: 1
image defines
Photometric- 0 for
Interpretation image (0
(0106, SHORT) as white, 1
black
1 means
black and
RowsPerStrip Number of Rows
(0116, SHORT Each Strip.
or LONG) page should be
single strip
SamplesPerPixel 1 (since are Bi-
(0115, SHORT) images
StripByteCounts count1, count2... Number of Bytes
(0117, SHORTs each strip of
or LONGs) images. (The
is an offset
points to a
of counts, each
which is the
Type, LONG or SHORT
The Length is
same as the
of strips.)
StripOffsets off1, off2,... Pointers to the
(0111, SHORTs of the image (remember
or LONGs) one strip per page).
(The Value is an
which points to
series of offsets
Katz & Cohen [Page 13]
RFC 1314 Image Exchange Format April 1992
each of which
to the actual
data for the strip.)
ResolutionUnit 2 | 3 Units of
(0128, SHORT) See Below, 3.C.6 2:
3:
XResolution See Below, 3.C.6 Resolution in the
(011A, RATIONAL) direction in
per
(we suggest 400
per inch when possible
YResolution See Below, 3.C.6 Resolution in the
(011B, RATIONAL) direction in
per
(we suggest 400
per inch when possible
3.C.2. Informational Fields (Optional
The following Informational Fields are optional. They
useful information to a user. All Field values are ASCII strings
NAME (TAG in hex)
---------------- -----------
Artist (013B) Person Who Created the
DateTime (0132) Date and Time of Image
HostComputer (013C) Name of Computer Image was Created
ImageDescription A Short Text
(010E
Make (010F) Manufacturer of Hardware (Scanner)
Model (0110) Model Number of Hardware (Scanner)
Software (0131) Software Package that Created the
3.C.3. Facsimile Fields (Optional, Mandatory for G3 Compression
In addition to the above, the Facsimile Fields below should
used. The TIFF document recommends that they not be used
interchange between applications, but they are now in wide
Katz & Cohen [Page 14]
RFC 1314 Image Exchange Format April 1992
use for just that. These fields are optional and default to 0
(all bits off).
FIELD
(TAG in hex, TYPE) VALUE
------------------ ----- -----------
Group3Options bit 0: 1 for Flag bits
(0124, LONG) 2-dimensional Options for G
(i.e., MR
k > 1)
bit 1: 1
mode MAY be used
0 if
mode IS NOT used
bit 2: 1 if fill (As allowed by the G
bits have been protocol, fill
added may be added
each line of
and the EOL.
fill bits are used
"byte-align" G3
files, bit 2 should
set to 1 for
images.)
Group4Options bit 0: unused Flag bits
(0125, LONG) bit 1: 1 if Options for G
mode MAY be used
if this bit is 0
it means
uncompressed
IS NOT used
3.C.4. Storage and Retrieval Fields (Optional
The following fields are optional and may be useful for
storage and retrieval
Katz & Cohen [Page 15]
RFC 1314 Image Exchange Format April 1992
FIELD
(TAG in hex, TYPE)
------------------ -----------
DocumentName Name of the
(010D, ASCII
PageName Name of the
(011D, ASCII
PageNumber Page Number in a Multi-Page
(0129, SHORTs) Two SHORT Values are specified,
first is the page number and
second is the total number of
in the document. The first
is page 0. (NOTE: This does
necessarily correspond to
numbers which may be
in the image.)
XPosition X Offset of the Left Side
(011E, RATIONAL) the Image, in
YPosition Y Offset of the Top
(011F, RATIONAL) the Image, in
3.C.5. TIFF-F Fields (NOT Recommended
TIFF-F defines the following new fields for G3 (MH)
images. Since these fields are not defined in TIFF-B itself
their use is not recommended. However, since TIFF-F files
include these tags for image data which came from a G3
machine, readers should be prepared for them
These three fields deal with corrupted image data which is due
the fact that G3 devices may not perform error correction on
data
FIELD
(TAG in hex, TYPE)
------------------ -----------
BadFaxLines Number of Bad fax scan
(0146, SHORT or LONG) encountered during fax
(but not necessarily in the file
CleanFaxData 0 means no bad lines
(0147, SHORT) 1 means bad lines were
Katz & Cohen [Page 16]
RFC 1314 Image Exchange Format April 1992
by the receiving
2 means bad lines were
but not
ConsecutiveBadFaxLines The maximum number of
(0148, SHORT or LONG) bad fax lines (but not
in the file
3.C.6. More on Representing
The tags XResolution and YResolution are both RATIONALs, i.e.,
ratio of two LONGS. G3 fax resolutions are actually specified
dots (or lines) per mm while G4 is in dots per inch (actually
dots per 25.4 mm).
For example, G3 horizontal resolution is defined to be 1728
per 215 mm which comes out to 80.4 dots per cm or about 203
per inch. It is frequently referred to as just 200 dpi. To
any possibility of problems due to round off error, this should
represented by having XResolution = 17280/215 and ResolutionUnit =
3 (cm). However when reading, 204/1 or even 200/1
ResolutionUnit = 2 (inches) should be recognized as
the same resolution
For G4, on the other hand, the resolution 400 dots/inch should
represented by an XResolution of 400/1 and ResolutionUnit = 2.
The following table shows various ways of representing
standard resolutions in order of preference
ResolutionUnit XResolution
-------------- ----------- -----------
G3 normal 3 17280/215 3850/100
3 80/1 3850/100
3 17280/215 385/10
3 80/1 385/10
2 2042/10 9779/100
2 204/1 98/1
2 200/1 100/1
G3 fine 3 17280/215 77/1
3 80/1 77/1
2 2042/10 19558/100
2 204/1 196/1
2 200/1 200/1
Katz & Cohen [Page 17]
RFC 1314 Image Exchange Format April 1992
G4 200 dpi 2 200/1 200/1
G4 300 dpi 2 300/1 300/1
Other 300 dpi 2 300/1 300/1
G4 400 dpi 2 400/1 400/1
600 dpi 2 600/1 600/1
It is suggested that Image readers be able to handle all of
above representations
4. A Sample TIFF Image
Below is a sample of what might be in a TIFF file for an MMR (G4)
encoded single image which is about 100K bytes compressed at 400 dpi
A generic outline is given first, followed by a more detailed
listing
4.A. Sample
Comments are to the right and are preceded by a semicolon. Note
tags must be sorted in order of the tag codes
0:, IFDADDR:, and STRIP0: are addresses within the file and
the number of bytes from the beginning of the file
Header
0: Byte Order= hex 4D4D ;first bytes of the file,
;most significant bit to
;significant (big endian
Version= 42 (hex 002A) ;Must be 42
First IFD= IFDADDR ;Address of first (and only)
Image File Directory (the only one in this example):
IFDADDR
IFD Entry Count= 24 ;(NOT A TAG) Count
; Number of IFD
NewSubFileType= 0
ImageWidth= 3400 ;8.5 inches at 400
ImageLength= 4400 ;11 inches at 400
BitsPerSample= 1 ;Bi-
Katz & Cohen [Page 18]
RFC 1314 Image Exchange Format April 1992
Compression= 4 ;
Photometric
Interpretation= 0
DocumentName= "LAMap1"
ImageDescription= "A map of Los Angeles
Make= "Fujitsu
Model= "M3093E
StripOffsets= ;There is only one strip
;this example. However,
;that strips can be in
;order. (Offsets are from
;beginning of the TIFF file.)
SamplesPerPixel= 1 ;Bi-
RowsPerStrip= 4400 ;Entire image in 1
StripByteCounts= ;Byte count of
;compressed
XResolution= 400/1
YResolution= 400/1
XPosition= 0/1 ;position of left side of
YPosition= 0/1 ;position of top of
Group4Options= hex 00000002 ;bit 1 on means
;mode MAY be
ResolutionUnit= 2 ;
Software= "Xionics
DateTime= "1990:10:05 15:00:00"
Artist= "Joe Pro
HostComputer= "Tardis.Isi.Edu
Next IFD Pointer= hex 00000000 ;(NOT A TAG) Indicates
; more IFDs in this
Image Data
: compressed image data
[end of TIFF file
In this example there is only one strip. Note that if there
more than one, the TIFF specification does not require them to be
any particular order. Strips may be given in any order and
readers must use the StripOffsets to locate them
Also, the TIFF document recommends not relying on the default
of the tags
Katz & Cohen [Page 19]
RFC 1314 Image Exchange Format April 1992
4.B. Detailed Hex
All offsets and values are represented by hex except for
strings which are double quoted. Remember that Value Offsets
always be an even number since the value it points to must always
on a 16-bit word boundary
Entries in the Name column are for reference and are not actually
part of the TIFF file
Offset Name
---- ------------------- -------------------------------------
Header (first byte is Offset 0):
0000 Byte Order 4D4
0002 Version 002
0004 1st. IFD pointer 00000010
IFD (IFDADDR from above is 0010 here):
0010 Entry Count 0018
0012 NewSubFileType 00FE 0004 00000001 00000000
001E ImageWidth 0100 0004 00000001 00000D48
002A ImageLength 0101 0004 00000001 00001130
0036 BitsPerSample 0102 0003 00000001 00010000
0042 Compression 0103 0003 00000001 00040000
004E Photometric Interp. 0106 0003 00000001 00000000
005A DocumentName 010D 0002 00000007 00000136
0066 ImageDescription 010E 0002 00000015 0000013
0072 Make 010F 0002 00000008 00000154
007E Model 0110 0002 00000007 0000015
008A StripOffsets 0111 0004 00000001 000001A
0096 SamplesPerPixel 0115 0003 00000001 00010000
00A2 RowsPerStrip 0116 0004 00000001 00001130
00AE StripByteCounts 0117 0004 00000001
00BA XResolution 011A 0005 00000001 00000164
00C6 YResolution 011B 0005 00000001 00000164
00D2 XPosition 011E 0005 00000001 0000016
00DE YPosition 011F 0005 00000001 0000016
00EA Group4Options 0125 0004 00000001 00000002
00F6 ResolutionUnit 0128 0003 00000001 00020000
0102 Software 0131 0002 00000008 00000174
010E DateTime 0132 0002 00000014 0000017
011A Artist 013B 0002 00000008 00000190
0126 HostComputer 013C 0002 0000000F 00000198
0132 Next IFD Pointer 00000000
Fields Offsets Point to
0136 DocumentName "LAMap1"
013E ImageDescription "A map of Los Angeles
Katz & Cohen [Page 20]
RFC 1314 Image Exchange Format April 1992
0154 Make "Fujitsu
015C Model "M3093E
0164 X,Y Resolution 00000190 00000001
016C X,Y Position 00000000 00000001
0174 Software "Xionics
017C DateTime "1990:10:05 15:00:00"
0190 Artist "Joe Pro
0198 HostComputer "Tardis.Isi.Edu
Image Data ( from above is here 01A8)
01A8 Compressed Data for single strip, of length
[end of TIFF file
NOTE: Since in this example there is only a single strip, there is
one count for StripByteCounts and one offset for StripOffsets
Thus, each of these only takes 4 bytes and will fit in
Value Offset instead of being pointed to
5.
Bitmapped images transferred within the Internet should be in
following format
1. The file format should be TIFF-B with multi-page
supported. Images should be encoded as one TIFF
per page
2. Images should be compressed using MMR when possible.
may also be MH or MR compressed or uncompressed. If MH or
compression is used, scan lines should be "byte-aligned".
3. For maximum interoperability, image resolutions
either be 600, 400, or 300 dpi; or else be one of
standard Group 3 fax resolutions (98 or 196
vertically and 204 dpi horizontally).
Note that this specification is self contained and an
should be possible without recourse to the TIFF references, and
only the specific TIFF documents cited are relevant to
specification. Updates to the TIFF documents do not change
specification
Existing commercial off-the-shelf products are available which
handle images in the above format. ISI would be delighted to
those interested in assembling a system
Katz & Cohen [Page 21]
RFC 1314 Image Exchange Format April 1992
6.
Many contributions to this work were made by members of the
Network Fax Working Group especially by its chairman, Mark
and by Clifford Lynch of the University of California Office of
President, Library Automation. Also, Kiyo Inaba of Ricoh Co. Ltd
made a number of helpful suggestions
7.
[1] Borenstein, N., and N. Freed, "Mechanisms for Specifying
Describing the Format of Internet Message Bodies", RFC
preparation
[2] International Telegraph and Telephone Consultative
(CCITT), Red Book, October, 1984.
[3] Aldus Corp., Microsoft Corp., "Tag Image File
Specification", Revision 5.0, Final, 1988.
[4] Cygnet Corporation, "The Spirit of TIFF Class F, 1990",
from Cygnet Technologies, 2560 9th., Suite 220, Berkeley,
94710, FAX: (415) 540-5835.
[5] Welch, T., "A Technique for High Performance Data Compression",
IEEE Computer, Vol. 17, No. 6, Page 8, June 1984.
8. Security
While security issues are not directly addressed by this document,
is important to note that the file format described in this
is intended for the communications of files between systems
across networks. Thus the same precautions and cares should
applied to these files as would be to any files received from
and possibly unknown systems
Katz & Cohen [Page 22]
RFC 1314 Image Exchange Format April 1992
9. Authors'
Alan
USC Information Sciences
4676 Admiralty Way #1100
Marina Del Rey, CA 90292-6695
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Katz@ISI.
Danny
USC Information Sciences
4676 Admiralty Way #1100
Marina Del Rey, CA 90292-6695
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Cohen@ISI.
Katz & Cohen [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
