RFC 1314
A File Format for the Exchange of Images in the Internet
Status of This Memo 🎀
okay bestie, first things first: this doc is an IAB standards track protocol for the Internet community 📋. It's also asking people to discuss it and send in suggestions for making it better 💬. For the current standardization state and status, check the current edition of the "IAB Official Protocol Standards" 🔍. And distribution of this memo is unlimited, so share it with whoever 💌
Title Block 📇
so the title block is giving: this is RFC 1314, titled "A File Format for the Exchange of Images in the Internet" 🖼️. It was written by A. Katz and D. Cohen, both from ISI 🧑💻👩💻. It came out in April 1992 🌸. It's an IAB standards track protocol. The original title block doesn't list anything it obsoletes or updates, so there's nothing to report there ✨
Abstract ✨
this doc defines a standard file format for swapping fax-like black and white images across the Internet 📠🖤. It's a product of the Network Fax Working Group of the Internet Engineering Task Force (IETF) 🧚
here's the vibe check, the actual standard:
- the file format should be
TIFF-B, with multi-page files supported 📄📄. Images should be encoded as one TIFF strip per page 🎀 - images should be compressed using
MMRwhen possible 🗜️. Images may also beMHorMRcompressed, or uncompressed 💅. IfMHorMRcompression is used, scan lines should be "byte-aligned" 📏 - for max interoperability, image resolutions should either be 600, 400, or 300 dpi, or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally) 🌈
Note: this spec is self contained 🫶. You should be able to implement it without going to the TIFF references, and only the specific TIFF documents cited are relevant here 📚. Updates to the TIFF documents do not change this spec 🔒
Experimentation with this file format is encouraged! 🧪💖
1. Introduction ✨
okay so the whole point of this doc is to define a standard file format for swapping black and white images over the Internet 🖤🤍. Lots of organizations have already started piling up and trading scanned documents 📚, so it's super important to agree on an interchange file format now. That makes sharing and distributing these docs way smoother 🫧. The images can come from scanners, software, or fax machines 📠, and then people manipulate them, share them, duplicate them, display them, print them on laser printers, or fax them 🖨️
this format is all about uniform transfer of high quality images at a reasonable cost and speed 💸⚡. That's true whether the files come from scanners, get made totally by software (text-to-fax, bitmap-to-fax, OCR, etc.), or come from fax 📠🫶. It's also meant to stay compatible with future moves to multi-level (gray-scale), higher resolution, or color images 🌈. And it's already supported by commercially available hardware and by both commercial and public domain software on most popular platforms in use right now 💻🎀
Here's a key distinction: the file format for images is a totally separate issue from how the files get communicated 📬. FTP or SMTP could move an image file from one host to another 🚚, but SMTP has complications as it's implemented today because of file size and the need to move binary data 😬. (There's a proposal to remove these limitations from SMTP and extend it to allow binary data. See reference [1] 🔗.)
one major potential application of the communications format here is letting people send images to fax machines over the Internet 📠✨. It's intended that one or more separate companion documents get written to cover standardizing protocols for transmitting images through the Internet, addressing fax machines, and routing faxes 🗺️. Just like the exchange format is separate from the transmission mechanism, it's also separate from how hosts store images 🗄️
this doc specifies a common exchange format 🤝. It does NOT require a host to store images in this format, it only requires converting between the host's local image storage formats and the exchange format for swapping images with other hosts across the network 🔄. (Lowercase "requires" here is just plain English, not a BCP 14 keyword, bestie 💅)
this standard uses TIFF (Tagged Image File Format, see below) as the format for exchanging image files 🏷️. TIFF isn't one specific image encoding, it's more of a framework for lots of encoding techniques that can be used inside it 🧩. For example, inside TIFF you can use MMR (the data encoding of CCITT Group 4 fax, see below), MH or MR (the data encodings of CCITT Group 3 fax), or other encoding methods 🪄
which encoding technique to use isn't specified here 🤷♀️. Instead, over time the encoding schemes most document providers use will emerge as the de facto standard 🏆. So this doc doesn't declare any of them "the standard data encoding scheme," the same way we don't declare English the standard publication language 🇬🇧. (That said, we expect most document providers will use MMR in the immediate future, because it offers much better compression ratios than MH or MR 🗜️🔥.)
TIFF also doesn't require an image to be communicated at a specific resolution 📐. Resolution is a parameter in the TIFF descriptive header 🎀. We do suggest sending images at one of a set of common resolutions for interoperability's sake 🫶, but the format accommodates other resolutions that specialized applications or changing technologies might need 🦋
sometimes image files have to be converted 🔁, like when a doc scanned at 400 dpi needs to print on a 300 dpi printer 🖨️. That conversion could be done by the document provider, the consumer, or a third party 👀. This doc specifies neither who does the conversion nor which algorithms should be used to do it 🤐
note that this standard doesn't try to define an exchange format for every image type that might move over the Internet 🌍. Nothing in this standard stops it from being used for other image types, like gray-scale (e.g., JPEG) or color images 🌈. But for standardization purposes, the scope of this doc is restricted to monochromatic bitmapped images ⬛⬜
real talk, though: the devs recognize this standard may have a limited lifespan 🥲. As Office Document Architecture (ODA) matures and comes into use on the Internet, the class of images covered here will likely get absorbed into the more general class of images ODA supports 🌊. But right now there isn't a big enough installed base of ODA-compliant software, and the ODA standards aren't fully mature yet 🚧. So this standard is meant to fill the need for a common image transfer format until ODA is ready 💜. Finally, the devs believe images encoded in this format should be mappable automatically into a future ODA-based image interchange format 🦋, which gives a smooth transition path to those future standards ✨
2. Relationship to Fax 📠✨
Okay so faxing over phone lines is getting more and more popular, bestie 💅. The standard on most fax machines in the U.S. is CCITT Group 3 (G3), specified in Recommendations T.4 and T.30 [2] and in EIA Standards EIA-465 and EIA-466. G3 faxes are 204 dots per inch (dpi) horizontally and 98 dpi vertically (or 196 dpi vertically in fine-detail mode) 🦋. G3 doesn't assume error free transmission and doesn't retransmit when errors happen, so the encoding is only differential over small segments that never go past 2 lines at standard resolution or 4 lines for fine-detail. (The incremental G3 encoding scheme is called two-dimensional, and the number of lines encoded that way is set by a parameter called k.) 🌸
CCITT Group 4 fax (G4) is defined by the T.400 and T.500 series of Recommendations, plus Recommendation T.6 [2]. It gives you 400 dpi both vertically and horizontally, and it's a fully two-dimensional encoding scheme (k is infinite) called MMR (Modified Modified READ, where READ stands for: Relative Element Address Designate) 👑. G4 assumes an error free transmission medium (generally an X.25 Public Data Network, or PDN). Because of this, G4 isn't in widespread use in the U.S. today 💀.
The traditional fax bundles together four independent issues:
- Data presentation and compression;
- Data transmission;
- Image input from paper ("scanning"); and
- Image output to paper ("printing").
Lowkey this bundling is why things get messy 🙈. It supports the high quality CCITT Group 4 (G4) images (400x400 dpi), but only over X.25 public data networks with error correction. It also supports the mid-quality CCITT Group 3 images (204x98 and 204x196 dpi), but only over phone voice circuits (the Switched Telephone Network, or STN) without error correction. It doesn't support any other data transmission capabilities (e.g., FTP over LANs and WANs), and it doesn't support asynchrony between the scanning and the printing, image storage, or the use of popular laser printers for output (even though they are perfectly capable of doing so) 😭.
In conventional fax, images are never stored. In today's computer network environment, a better model is:
- Images are scanned into files or created by software;
- These image files are stored, manipulated, or communicated;
- Images in a file are printed or displayed.
The only feature of the CCITT fax that should be used is the encoding technique (preferably MMR, but with MR or MH allowed). Thanks to how popular fax is, it can be built into a variety of fax-oriented chips at low cost 🔥.
"Sending a fax" means both encoding (and decoding) the fax images and transmitting the data. The Internet ALREADY provides several mechanisms for data transmission (in particular, FTP for general file transmission), so it's unnecessary to use the data transmission methods in the CCITT standard. Within the Internet, each fax image should be stored in a file, and these files could be transferred (e.g., using FTP, SMTP, RPC-based methods, etc.) 💖.
Fax machines should be treated just like scanners and printers, as I/O devices between paper and files, and not as a transmission means 🧚. That way, Group 4 images are supported at low cost while you get the freedom to use any computerized file transfer and duplication mechanism, standard laser printers, multiple printing (possibly at multiple remote sites) of the same image without rescanning it physically, and a variety of software for processing 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 be able to print all of them on fax machines or on laser printers 🎀.
The CCITT Recommendations assume realtime communications between fax machines, so they don't specify any kind of fax file format. We propose using TIFF [3], which seems to be emerging as a standard, for encapsulating encoded images 🌈. Because they assume realtime communications, the CCITT fax protocols require negotiations between the sender and receiver. For example, they negotiate whether to use two-dimensional coding (and with what k parameter) and what (if any) padding there is between scan lines 🤓.
In our approach, the image in the file is already compressed in a particular manner. If it's going to an ordinary fax machine through a fax board/modem, that board performs the negotiations with the receiving fax machine. If the receiver can't handle the compression used in the file, the image has to be converted to another compression scheme before transmission. (Most fax cards seem to either store images using the default values of the negotiated parameters, or in a format that can quickly be converted to those. With currently available hardware and software, any necessary format conversion should be easy to accomplish.) 💅
In conventional fax, if the compression used for a particular image is "negative" (i.e., the compressed form is larger than the uncompressed form, which happens quite often with dithered photographic images), the larger compressed form is still sent. If images are first scanned into files, this problem can be recognized, and the smaller, uncompressed file can be sent instead. (Also, Recommendations T.4 and T.6 [2] allow for an "uncompressed mode." So lines with negative compression may each be sent uncompressed. However, very few G3 fax machines support this mode.) 🙃
3. Image File Format 🖼️💜
Image files should be in the TIFF-B format, which is the bi-level subclass of TIFF. TIFF and TIFF-B are described in reference [3], cited at the end of this document 📚. Images should be compressed using MMR (the G4 compression scheme) because it offers superior compression ratios. Images may also be compressed using MH or MR (the G3 methods), but MMR offers much better compression ratios than these, which are used in G3 fax because there's no error-free communications path 🔥.
TIFF-F, described in [4], is the proposed subclass of TIFF-B for fax images. Since TIFF-F was meant for G3, it recommends against some features we recommend. Specifically, it suggests not using MMR or MR compression (we recommend MMR and allow MR), and it prohibits uncompressed mode (which we allow and suggest for some photographic images) 🙈. Apart from these, the TIFF-F restrictions should be followed. (Complete compatibility between the format specified here and TIFF-F can only be guaranteed for MH compressed images.) 🫶
[NOTE: Aldus Corp., the TIFF Developer, considers fax applications to be outside the scope of mainstream TIFF since it is not a part of general publishing, which is what TIFF was originally designed for. They specify the LZW [5] compression scheme rather than MMR. We, however, are concerned with the transmission and storage of images rather than publishing. Therefore, we are more concerned with compression ratios and compatibility with CCITT fax than Aldus is.] 🦋
TIFF itself allows for gray-scale and color images. Image files should be restricted to TIFF-B for now because most of the currently available hardware is bi-level (1 bit per pixel). In the future, when gray-scale or color scanners, printers, and fax become available, the file format suggested here can already accommodate them. (For example, though JPEG isn't currently a TIFF defined compression type, work is underway to include it as one.) 🌟
[NOTE: In this document, we will use the term "reader" or "TIFF reader" to refer to the process or device which reads and parses a TIFF file.] 🧐
3.A. TIFF File Format ✨
okay so Figure 1 below is reproduced from Figure 1 of reference [3], and it shows you the whole layout of a TIFF file 🎀
TIFF files start with a file header. This header tells you the byte order used in the file (Big or Little Endian), the TIFF version number, and where to find the first "Image File Directory" (IFD) 💖 If the first two bytes are hex 4D4D, the byte order goes from most to least significant for both 16 and 32 bit integers (Big Endian). If the first two bytes are hex 4949, it goes from least to most significant (Little Endian) 🦋 In both formats, character strings are stored in 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, so don't mix them up bestie 🙈 The following 4 bytes contain the offset (in bytes from the beginning of the file) to the first IFD.
An IFD contains a 2 byte count of the number of entries in the IFD, a sequence of 12 byte directory entries, and a 4 byte pointer to the next IFD 🌸 One of these fields (StripOffsets) points to (parts of) an image in the file. There may be more than one image in the file (e.g., a "multi-page" TIFF file) and therefore more then one IFD. IFD field entries may appear in any order, which is very chill of them 🫶
Each directory entry is 12 bytes and consists of a tag, its type, a 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 value rather than an offset is given. If the value is less than 4 bytes (i.e., if the type is BYTE or SHORT), it is left-justified within the 4 byte value offset. More details about directory entries and the possible tags will be given in Section 3.C 🧚
All pointers (called offsets in the TIFF reference [3]) are the 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 only one image per file, there should therefore be only one IFD. The last 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 👑
Header
+--------+--------+ Directory Entry
0 | | | Byte Order +--------+--------+
+--------+--------| X | | | Tag
2 | | | Version(42) +--------+--------|
+--------+--------| X+2 | | | Type
4 | | | Offset of +--------+--------|
+- - A - -+ 0th IFD X+4 | | |
6 | | | +- -+ Length
+--------+--------+ | | |
| +--------+--------+
| X+8 | | | Value
| +- - Y - -+ or
V | | | Value
+--------+--------+ Offset
IFD
+--------+--------+ |
A | - B - | Entry Count |
+--------+--------| |
| | | V
A+2 Entry 0
| | | +--------+--------+
+--------+--------+ | | |
| | | Y Value
A+14 Entry 1 | | |
| | | +--------+--------|
+--------+--------+
| | |
A+26 Entry 2
| | |
+--------+--------+
| | | .
.
| | | .
+--------+--------+
| | |
Entry B-1
| | |
+--------+--------+
| | | Offset of
A+2+B*12 - C - + Next IFD
| | |
+--------+--------+
|
V
(next IFD)
Figure 1: The Structure of a TIFF File3.B. Image Format and Encoding Issues 🍓
Images in TIFF files are organized as horizontal strips for fast access to individual rows 🌈 You can specify how many rows there are in each strip, and all of the strips are the same size (except possibly the last one). Each strip must begin on a byte boundary, but successive rows are not so required. For two-dimensional G3 compression (MR), each strip must begin with an "absolute" one-dimensional line. For MMR (G4) compression, each strip must be encoded as if it were a separate image.
For a variety of reasons, each page must be a single strip (e.g., not broken up into multiple strips) 💜
One problem with multiple strips per page is that images which come from G4 fax machines, as well as most scanned images, will be generated as a single strip per page. These would have to be decoded and re-encoded as multiple strips (remember that for MMR compression, each strip must start with a one-dimensionally encoded line) 🙈
Another problem with multiple strips per page arises in MR compression. Here, there MAY be at most k-1 two-dimensionally encoded lines following a one-dimensionally encoded line, but this is not required. It is possible to have one-dimensional lines more frequently than every k lines. However, since each strip (except possibly the last one) is required to be the same size, it may be necessary to re-encode the image to insure that each strip starts with a one-dimensional line. This is not a problem if each page is a single strip 🦋
[NOTE: The TIFF document [3] suggests using strips which are about 8K bytes long. However, TIFF-F [4] recommends that each page be a single strip regardless of its size. The format specified in this document follows the TIFF-F recommendation.]
Also, as TIFF-F recommends, all G3 encoded images (MH and MR) should be "byte-aligned." This means that extra zero bits (fill bits) are added before each EOL (end-of-line) so that every line starts on a byte boundary 🌸
In addition, as in the TIFF-F specification, the RTC (Return to Control signal, which consists of 6 continuous EOL's) of G3 shall not be included at the end of G3 encoded documents. RTC is to be considered part of the G3 transmission protocol and not part of the encoding. Most, if not all, G3 fax modems attach RTC to outgoing images and remove it from incoming ones 📠
For MMR (G4) encoded files, readers should be able to read images with only one EOFB (End Of Facsimile Block) at the end of the page, and should not assume that Facsimile Blocks are of any particular size. (It has been reported that some MMR readers assume that all Facsimile Blocks are the maximum size.) 😭
Systems may optionally choose to store the entire image uncompressed if the compression increases the size of the image file. Also, uncompressed mode (specified in Group3Options or Group4Options, see below) allows portions of the image to be uncompressed ✨
The multi-page capability of TIFF is supported and should be used for multi-page documents. TIFF files which have multiple pages have an IFD for each page of the document, each of which describes and points to a single page image. (Note: though the current TIFF specification does not specifically prohibit having a single IFD point to an image which is actually multiple pages, with one strip for each page, most if not all TIFF readers would probably not be able to read such a file. Therefore, this should not be done.) 💀
[A NOTE ON TIFF AND MULTI-PAGE DOCUMENTS: Since most publications (e.g., reports, books, and magazine articles) are composed of more than a single page, multi-page TIFF files should be used where appropriate. However, many current TIFF implementations now only handle single-page files. It is hoped that in the future, more TIFF implementations will handle multi-page files correctly. In the meantime, it would be useful to develop a utility program which could join several single-page TIFF files into a single multi-page file and also separate a multi-page TIFF file into several single page files. For example, the utility could take a single TIFF file with N pages, calleddoc.tif, and create the filesdoc.000,doc.001,doc.002, ...,doc.N.doc.000would be an ASCII listing of the files created. This naming scheme is compatible with that used by the image systems we have seen which only handle single page files. In going the other way, the N+1 single page files could be combined into a single multi-page TIFF file. In this case, if the filedoc.000exists but contains information contrary to what is found in looking for the filesdoc.001,doc.002, ..., the program would notify the user.]
3.C. TIFF Fields 💅
TIFF is tag or field based. The various fields and their format are 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. For example, a single 16-bit word or SHORT has a Length of 1, not 2)
- The Value Offset (4 bytes) (Pointer to the actual value, which must begin on a word boundary. Therefore, this offset will always be an even number. If the Value fits into 4 bytes, the Value Offset contains the Value instead. If the Value 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 (variable
length)
3 = SHORT 16-bit unsigned integer (2 bytes)
4 = LONG 32-bit unsigned integer (4 bytes)
5 = RATIONAL Two LONGs (64 bits) representing the
numerator and denominator of a fraction.
In this document, RATIONAL's will be written
as numerator/denominator. (8 bytes)For ASCII, the Length specifies the number of characters and includes the null. It does not, however, include padding if such is necessary 🌈
(Note that ASCII strings of length 3 or less may be stored in the Value Offset field instead of being pointed to.)
The following fields should be used in a TIFF image file. Only the Basic Fields are mandatory; the others are optional (except that for MH and MR encoded files, the Group3Options Facsimile Field is mandatory). The optional fields have default values which are given 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 value for a tag, the possible values are separated by |. 🫶
Okay so, some fields (like ImageLength or ImageWidth) can be more than one type, so keep that in mind 👀✨
A TIFF viewer and editor would be SO useful 🎀 You could read, add, and edit the fields in a TIFF file. The editor would show fields in sorted order and make sure every mandatory field is included 💅 Also, resolution and position should always be shown or set together with their units 📏🌸
3.C.1. Basic Fields (Mandatory) 🍓
Basic Fields are the core stuff: the pixel architecture and visual look of an image. These are the ones a TIFF image file should include:
FIELD NAME
(TAG in hex, TYPE) VALUE DESCRIPTION
------------------ ----- -----------
BitsPerSample 1 Number of bits
(0102, SHORT) per pixel (bi-level for
now, but may allow
more later)
Compression 4 Type of Compression
(0103, SHORT) (could also be 1 = Uncompressed
1 or 3) 3 = G3 (MH or MR)
4 = G4 (MMR)
Use 4 if possible
ImageLength <image's length> Length of the Image
(0101, SHORT in scan lines
or LONG)
ImageWidth <image's width> Width of the Image
(0100, SHORT in pixels
or LONG)
NewSubFileType 0 usually Flag bits indicating
(00FE, LONG) bit 0: 1 if the kind of image.
reduced (see the TIFF
resolution of reference [3])
another image
bit 1: 1 if
single page of a
multi-page image
bit 2: 1 if
image defines a
transparency
mask
Photometric- 0 for positive
Interpretation image (0 imaged
(0106, SHORT) as white, 1 as
black)
1 means reverse
black and white
RowsPerStrip <Number of Rows> Number of Rows in
(0116, SHORT Each Strip. Each
or LONG) page should be a
single strip.
SamplesPerPixel 1 (since are Bi-level
(0115, SHORT) images)
StripByteCounts count1, count2... Number of Bytes in
(0117, SHORTs each strip of the
or LONGs) images. (The Value
is an offset which
points to a series
of counts, each of
which is the same
Type, LONG or SHORT.
The Length is the
same as the number
of strips.)
StripOffsets off1, off2,... Pointers to the strips
(0111, SHORTs of the image (remember,
or LONGs) one strip per page).
(The Value is an offset
which points to a
series of offsets,
each of which points
to the actual image
data for the strip.)
ResolutionUnit 2 | 3 Units of Resolution
(0128, SHORT) See Below, 3.C.6 2: Inches
3: Centimeters
XResolution See Below, 3.C.6 Resolution in the X
(011A, RATIONAL) direction in pixels
per ResolutionUnit
(we suggest 400 dots
per inch when possible)
YResolution See Below, 3.C.6 Resolution in the Y
(011B, RATIONAL) direction in pixels
per ResolutionUnit
(we suggest 400 dots
per inch when possible)3.C.2. Informational Fields (Optional) 💖
These Informational Fields are optional, but they're super handy for users 🫶 Every Field value here is an ASCII string.
NAME (TAG in hex) DESCRIPTION
---------------- -----------
Artist (013B) Person Who Created the Image
DateTime (0132) Date and Time of Image Creation
HostComputer (013C) Name of Computer Image was Created On
ImageDescription A Short Text Description
(010E)
Make (010F) Manufacturer of Hardware (Scanner) Used
Model (0110) Model Number of Hardware (Scanner) Used
Software (0131) Software Package that Created the Image3.C.3. Facsimile Fields (Optional, Mandatory for G3 Compression) 📠
On top of all that, the Facsimile Fields below should be used. The TIFF document recommends that they not be used for interchange between applications, but they're now used widely enough that people do exactly that 🙈 These fields are optional and default to 0 (all bits off).
FIELD NAME
(TAG in hex, TYPE) VALUE DESCRIPTION
------------------ ----- -----------
Group3Options bit 0: 1 for Flag bits indicating
(0124, LONG) 2-dimensional Options for G3
coding
(i.e., MR with
k > 1)
bit 1: 1 if
uncompressed
mode MAY be used,
0 if uncompressed
mode IS NOT used.
bit 2: 1 if fill (As allowed by the G3
bits have been protocol, fill bits
added may be added between
each line of data
and the EOL. Since
fill bits are used to
"byte-align" G3 image
files, bit 2 should be
set to 1 for these
images.)
Group4Options bit 0: unused Flag bits indicating
(0125, LONG) bit 1: 1 if Options for G4
uncompressed
mode MAY be used,
if this bit is 0
it means that
uncompressed mode
IS NOT used.3.C.4. Storage and Retrieval Fields (Optional) 🗂️
These fields are optional, but they can be super useful for storing and finding documents 🔍✨
FIELD NAME
(TAG in hex, TYPE) DESCRIPTION
------------------ -----------
DocumentName Name of the Document
(010D, ASCII)
PageName Name of the Page
(011D, ASCII)
PageNumber Page Number in a Multi-Page Document
(0129, SHORTs) Two SHORT Values are specified, the
first is the page number and the
second is the total number of pages
in the document. The first page
is page 0. (NOTE: This does not
necessarily correspond to page
numbers which may be printed
in the image.)
XPosition X Offset of the Left Side of
(011E, RATIONAL) the Image, in ResolutionUnits
YPosition Y Offset of the Top of
(011F, RATIONAL) the Image, in ResolutionUnits3.C.5. TIFF-F Fields (NOT Recommended) 🚫
TIFF-F defines these new fields for G3 (MH) encoded images. They aren't defined in TIFF-B itself, so using them isn't recommended. BUT, since TIFF-F files might include these tags for image data that came from a G3 fax machine, readers should be prepared for them 🫠
These three fields deal with corrupted image data. That happens because G3 devices may not do error correction on bad data 😬
FIELD NAME
(TAG in hex, TYPE) DESCRIPTION
------------------ -----------
BadFaxLines Number of Bad fax scan lines
(0146, SHORT or LONG) encountered during fax reception
(but not necessarily in the file)
CleanFaxData 0 means no bad lines received
(0147, SHORT) 1 means bad lines were regenerated
by the receiving device
2 means bad lines were detected
but not regenerated
ConsecutiveBadFaxLines The maximum number of consecutive
(0148, SHORT or LONG) bad fax lines (but not necessarily
in the file)3.C.6. More on Representing Resolutions 📐🦋
The tags XResolution and YResolution are both RATIONALs, which means a ratio of two LONGs. G3 fax resolutions are actually given in dots (or lines) per mm, while G4 uses dots per inch (well, dots per 25.4 mm).
Here's an example: G3 horizontal resolution is defined as 1728 dots per 215 mm, which works out to 80.4 dots per cm or about 203 dots per inch. People often just call it 200 dpi. To dodge any round-off trouble, this should be represented with XResolution = 17280/215 and ResolutionUnit = 3 (cm). When reading, though, 204/1 or even 200/1 with ResolutionUnit = 2 (inches) should be recognized as the same resolution 🧚
For G4, the resolution 400 dots/inch should be represented with an XResolution of 400/1 and ResolutionUnit = 2 💜
Here's the table showing the standard resolutions and ways to represent them, in order of preference:
ResolutionUnit XResolution YResolution
-------------- ----------- -----------
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
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/1Okay so this table is giving us every combo we can use, bestie 📊 It's a whole buffet of resolution settings. The vibe is simple: image readers should be able to handle all of these representations, so nobody gets left on read 🙈✨
4. A Sample TIFF Image File ✨
Okay, time for the sample! 🎀 This shows what might be inside a TIFF file for a single image encoded with MMR (G4), which is about 100K bytes compressed at 400 dpi. We get a generic outline first, then a super detailed hex listing for the nerds 🤓💕
4.A. Sample File
Comments sit to the right and start with a semicolon, and tags have to be sorted in order of their tag codes 📋 Also, 0:, IFDADDR:, and STRIP0: are addresses inside the file, counting bytes from the very start of the file 🧚
Header:
0: Byte Order= hex 4D4D ;first bytes of the file, from
;most significant bit to least
;significant (big endian)
Version= 42 (hex 002A) ;Must be 42
First IFD= IFDADDR ;Address of first (and only) IFD
Image File Directory (the only one in this example):
IFDADDR:
IFD Entry Count= 24 ;(NOT A TAG) Count of
; Number of IFD Entries
NewSubFileType= 0
ImageWidth= 3400 ;8.5 inches at 400 dpi
ImageLength= 4400 ;11 inches at 400 dpi
BitsPerSample= 1 ;Bi-Level
Compression= 4 ;MMR
Photometric-
Interpretation= 0
DocumentName= "LAMap1"
ImageDescription= "A map of Los Angeles"
Make= "Fujitsu"
Model= "M3093E"
StripOffsets= <STRIP0> ;There is only one strip in
;this example. However, note
;that strips can be in any
;order. (Offsets are from the
;beginning of the TIFF file.)
SamplesPerPixel= 1 ;Bi-Level
RowsPerStrip= 4400 ;Entire image in 1 strip
StripByteCounts= <COUNT0> ;Byte count of entire
;compressed image
XResolution= 400/1
YResolution= 400/1
XPosition= 0/1 ;position of left side of image
YPosition= 0/1 ;position of top of image
Group4Options= hex 00000002 ;bit 1 on means uncompressed
;mode MAY be used
ResolutionUnit= 2 ;Inches
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 no
; more IFDs in this file
Image Data:
<STRIP0>: <actual compressed image data>
[end of TIFF file]Only one strip in this example, bestie 💅 But if there were more than one, the TIFF specification doesn't require them to be in any particular order. Strips can show up in any order, and TIFF readers must use the StripOffsets to find them 🗺️
Also, the TIFF document recommends not relying on the default values of the tags 💭 Don't just vibe on defaults, be explicit!
4.B. Detailed Hex Listing
Everything here is in hex except the ASCII strings, which are wrapped in double quotes 🌸 Quick reminder: Value Offsets must always be an even number, because the value they point to has to sit on a 16-bit word boundary. Very important, very picky, very iconic 👑
Entries in the Name column are just for reference and aren't actually part of the TIFF file, so don't go looking for them in the bytes 🙈
Offset Name Value
---- ------------------- -------------------------------------
Header (first byte is Offset 0):
0000 Byte Order 4D4D
0002 Version 002A
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 0000013E
0072 Make 010F 0002 00000008 00000154
007E Model 0110 0002 00000007 0000015C
008A StripOffsets 0111 0004 00000001 000001A8
0096 SamplesPerPixel 0115 0003 00000001 00010000
00A2 RowsPerStrip 0116 0004 00000001 00001130
00AE StripByteCounts 0117 0004 00000001 <COUNT0>
00BA XResolution 011A 0005 00000001 00000164
00C6 YResolution 011B 0005 00000001 00000164
00D2 XPosition 011E 0005 00000001 0000016C
00DE YPosition 011F 0005 00000001 0000016C
00EA Group4Options 0125 0004 00000001 00000002
00F6 ResolutionUnit 0128 0003 00000001 00020000
0102 Software 0131 0002 00000008 00000174
010E DateTime 0132 0002 00000014 0000017C
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"
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 (<STRIP0> from above is here 01A8)
01A8 Compressed Data for single strip, of length <COUNT0> bytes
[end of TIFF file]NOTE: Since this example has only a single strip, there is only one count for StripByteCounts and one offset for StripOffsets. So each of these takes only 4 bytes and fits right in the Value Offset instead of being pointed to. Iconic efficiency 🧚✨
5. Conclusions ✨
Okay, the big takeaway! 🦋 Bitmapped images moving around the Internet should be in the following format:
- The file format should be TIFF-B with multi-page files supported. Images should be encoded as one TIFF strip per page.
- Images should be compressed using MMR when possible. Images may also be MH or MR compressed or uncompressed. If MH or MR compression is used, scan lines should be "byte-aligned".
- For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally).
Also, this spec is self contained 🫶 You should be able to implement it without going down the TIFF rabbit hole, and only the specific TIFF documents cited here matter for it. Updates to the TIFF documents do not change this specification, so it's stable and not gonna randomly break on you 💅
Existing commercial off-the-shelf products can already handle images in the format above, and ISI would be delighted to help anyone who wants to assemble a system 🌈
6. Acknowledgments 🫶
Big thanks to the members of the IETF Network Fax Working Group, who made many contributions to this work, especially their chairman, Mark Needleman 💜 Clifford Lynch of the University of California Office of the President, Library Automation also helped out, and Kiyo Inaba of Ricoh Co. Ltd. made a number of helpful suggestions 🌸
7. References 📚
- [1] Borenstein, N., and N. Freed, "Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC in preparation.
- [2] International Telegraph and Telephone Consultative Committee (CCITT), Red Book, October, 1984.
- [3] Aldus Corp., Microsoft Corp., "Tag Image File Format Specification", Revision 5.0, Final, 1988.
- [4] Cygnet Corporation, "The Spirit of TIFF Class F, 1990", available from Cygnet Technologies, 2560 9th., Suite 220, Berkeley, CA 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 Considerations 🔒
Okay, bestie, listen up. 🚨 While security issues are not directly addressed by this document, it is important to note that the file format described here is intended for communicating files between systems and across networks. Thus the same precautions and cares should be applied to these files as would be applied to any files received from remote and possibly unknown systems. Treat every incoming file like it's a stranger in a DM 💀
9. Authors' Addresses 🎀
Alan Katz
USC Information Sciences Institute
4676 Admiralty Way #1100
Marina Del Rey, CA 90292-6695
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Katz@ISI.Edu
Danny Cohen
USC Information Sciences Institute
4676 Admiralty Way #1100
Marina Del Rey, CA 90292-6695
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Cohen@ISI.EduThat's the whole thing, bestie! 🌈💖 Two legends, one fax-to-TIFF masterpiece 👑
📦 where this page comes from
- ietf: rfc1314 1992-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms