RFC 2306
Tag Image File Format (TIFF) - F Profile for Facsimile
RFC 2306: Tag Image File Format (TIFF) - F Profile for Facsimile 📠✨
Okay bestie, let's get the title block sorted first 💅
- Series: Network Working Group
- Number: RFC 2306
- Title: Tag Image File Format (TIFF) - F Profile for Facsimile
- Authors: G. Parsons (Northern Telecom) and J. Rafferty (Human Communications)
- Category: Informational 🦋
- Date: March 1998
- Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates. Section 3.1.1 does say this document updates the definition of TIFF-F, so keep that in mind 👀
Status of This Memo 🎀
okay so this memo just provides information for the Internet community. It is NOT a standard of any kind, and distribution of it is unlimited 🌸
Copyright Notice 💜
Copyright (C) The Internet Society (1998). All Rights Reserved. Classic, no notes 🫶
Overview ✨
this document goes deep on TIFF-F, the format people use to store facsimile images. Honestly it's been the folklore format for ages, with no standard reference definition until now. It's giving "finally someone wrote it down" 😭🔥
Internet Fax Working Group 🧚
this doc is a product of the IETF Internet Fax Working Group. If you have comments, send them to the email distribution list at <ietf-fax@imc.org> 💌
1. Abstract 🍓
this document uses the Tag Image File Format (TIFF) as its base and defines the F profile of TIFF for facsimile (TIFF-F). TIFF-F is a file format that can be used to store and swap facsimile images 📠💖
2. TIFF Definition 🌈
TIFF (Tag Image File Format) Revision 6.0 is defined in full in [TIFF] 📚
we include a quick review of TIFF concepts here as background, but if you want the actual technical details, go read the original TIFF specification [TIFF]. Trust me, it's the source of truth 👑
2.1. Baseline TIFF and Applications 🦋
TIFF is all about describing and storing raster image data. The big goal is a rich environment where implementations can trade image data with each other ✨
[TIFF] calls Baseline TIFF the core of TIFF, the essentials that all mainstream TIFF developers should support in their products. Applications are built by starting from Baseline TIFF and then defining "extensions" for the specific "application", plus any other differences from Baseline TIFF 💅
3. TIFF-F Definition 🔥
3.1 Introduction 💖
Okay this part is the tea ☕ TIFF-F has been used for years, but it was never written down as a standard. A small group of fax experts led by Joe Campbell made an informal TIFF-F document way back. [TIFF] mentions that TIFF-F exists, but it doesn't define it. This document defines the F application of [TIFF] 🎀
For ease of reference, we'll just say TIFF-F everywhere as shorthand for "F Profile of TIFF for Facsimile" 🧚 TIFF-F files are meant to be used with the image/tiff MIME media content-type, which supports the "application" parameter (e.g., application=faxbw) 💌
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ]. Those capitals are doing serious work, so read them carefully 🙈
3.1.1 TIFF-F Historical Background 🕰️
Up until TIFF 6.0, TIFF had various "Classes" that defined how TIFF got used for different applications. Classes were there to support specific applications, which is why TIFF-F was historically called "TIFF Class F". Earlier informal TIFF-F documents used that "Class F" terminology too 🌸
As of TIFF 6.0 [TIFF], the TIFF Class concept was eliminated in favor of Baseline TIFF. So this document updates the definition of TIFF-F as the F profile of TIFF for facsimile. It uses Baseline TIFF as defined in [TIFF] as the starting point, then defines the differences from Baseline TIFF that apply to TIFF-F 🦋 In almost all cases, the TIFF-F fields and values still match what was used in earlier TIFF Class F definitions. Where some values were updated to match the ITU-T [T.4] and [T.30] fax recommendations more precisely, those differences are called out 💜
3.1.2 Overview 🌟
this section says what the spec is trying to document:
- The fields and values that apply to this F profile of TIFF for facsimile.
- A minimum set of TIFF-F fields and values which should be able to interwork with virtually all historic TIFF-F readers.
- A broader range of values for the traditional TIFF-F fields that support the most widely used facsimile compressions, page sizes and resolutions, consistent with the ITU-T [T.4] and [T.30] recommendations 🍓
here's the layout. Sections 3.1.3 and 3.1.4 give a brief review of TIFF file structure, plus practical guidelines for writing and reading multi-page TIFF-F files 📑
Then we review the TIFF-F fields. Section 3.2 covers the fields from Baseline TIFF that apply to black and white (bi-level) images and are also used by TIFF-F. Section 3.3 covers the other required TIFF-F fields. Several fields that are specific extensions for TIFF-F are in section 3.4. There are also fields that may be helpful but aren't required, and those are listed in section 3.5 🧚
Section 3.6 defines the requirements for the minimum subset of TIFF-F fields and values, to maximize interoperability. Several technical topics, including implementation issues and warnings, get covered in the sections after that. Finally, section 3.9 introduces the TIFF-F Reader and Writer. There's a table of the required and recommended fields for a TIFF-F Reader, along with details on the permitted set of values 👑
3.1.3 Structure of TIFF Files 🎀
The structure of TIFF files is specified within [TIFF], so this section is just a short summary for informational purposes. Practical guidelines for using this structure to read and write TIFF-F files are in the next section, 3.1.4. The structure for writing "minimum subset" TIFF-F files is defined in section 3.6.2 🦋
A TIFF file starts with an 8-byte image file header. That header defines the byte order used within the file (see section 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. It holds the attributes of an image and pointers to the image data ✨ TIFF fields (also called entries) contain a tag, its type (e.g. short, long, rational, etc.), a count (which tells you how many values or offsets there are), and a value/offset. The actual value only sits in the field if it fits into 4 bytes. Otherwise, an offset points to where the field's data lives. And that offset can itself point to an array of offsets 🤯
For facsimile data, a lot of documents are multi-page. In TIFF, those can be represented with more than one IFD inside the TIFF file. Each IFD defines a subfile whose type is given in the NewSubfileType field. For facsimile data in a TIFF-F file, each facsimile page in a multi-page document gets its own IFD 📄
For bi-level facsimile files, multiple IFDs are organized as a linked list. The last entry in each IFD points to the next IFD, and the pointer in the last IFD is 0. (There's also a tree technique for organizing multiple IFDs that uses the SubIFDs field, but it doesn't apply to TIFF-F images 🙅♀️) Inside each IFD, the location of the related image data is defined using fields associated with strips. These fields identify the size of strips (in rows), the number of bytes per strip after compression, and a strip offset, which points to where the image strip actually lives 🌈
TIFF has a super flexible file structure. But if implementors follow some practical guidelines when writing multi-page TIFF-F files, they can produce TIFF structures that are way easier for readers to process. This matters a lot in environments like facsimile terminals, where a complex file structure is hard to support 🫶
3.1.4 Practical Guidelines for Writing/Reading Multi-Page TIFF-F Files ✨
Okay so, historically TIFF-F has made readers and writers handle multi-page TIFF-F files, which is a LOT 😭 Implementors have found that things get way simpler if you follow some practical guidelines when writing multi-page files. Still, for interchange robustness, TIFF-F readers SHOULD be prepared to read TIFF files whose structure is consistent with [TIFF]. That one's more flexible than what's recommended here, so it's giving "be open-minded" 🫶
The structure of a multi-page TIFF-F file has one IFD per page. Each IFD defines the attributes for a single page, bestie 🧚 For simplicity, the writer of TIFF-F files SHOULD present IFDs in the same order as the actual sequence of pages. Pages are numbered in TIFF-F starting at page 0 for the first page and then going up (0, 1, 2, ...). Also, as noted in section 3.1.3, any field values over 4 bytes get stored separately from the IFD. TIFF-F readers SHOULD expect IFDs to show up in page order, but they should be able to handle exceptions too 💅
Per [TIFF], the exact placement of image data isn't specified. The strip offsets for each strip of image are defined inside each IFD though 🌸 A second simplifying assumption is that the image data for each page of a multi-page document SHOULD be contained within a single strip, so one image strip per fax page. Where possible, this is so useful for store-and-forward messaging, where the file is usually prepared before transmission. Other assumptions may apply for the strip size in implementations that use "streaming" techniques (see section 3.7.6). If a different strip size assumption was used (for example a constant size for strips that might be smaller than the page size), it'll be super obvious from the values and offsets of the strip-related fields 👀 From the TIFF-F reader's side, one strip per page means the image data can be found through a single offset. That makes the image structure way simpler and processing faster 🔥
A third simplifying assumption is that each IFD SHOULD be placed in the TIFF-F file structure at a point before the image it describes. If any long field values are present (see section 3.1.3), they SHOULD be placed after their referencing IFD and before the image data they describe 🎀
A fourth simplifying assumption for TIFF-F writers and readers: put the actual image data in a physical order inside the TIFF file that matches the logical page order. In practice though, TIFF-F readers will need to use the strip offsets to find the exact physical location of the image data, whether or not it's in logical page order 🦋
TIFF-F writers MAY make a fifth simplifying assumption, where the IFD, the value data, and the image data that the IFD has offsets for all come before the next image IFD. These elements MUST precede the next image IFD in the minimum set of TIFF-F files (see section 3.6.2). That said, this principle has been relaxed for TIFF-F to match past practices, so it's not as strict as it sounds 🙈
So a TIFF-F file that follows the guidelines in this section is basically a linked list of IFDs, presented in ascending page order. Each one points to a single page of image data (one strip per page), and those pages of image data are also placed in logical page order inside the file. (The pages of image data can be stored contiguously if the implementor wants, totally their call ✨)
3.2 Baseline TIFF Required Fields for BiLevel Images 🍓
Baseline TIFF per [TIFF] requires these fields to be present for all BiLevel Images: ImageWidth, ImageLength, Compression, PhotometricInterpretation, StripOffsets, RowsPerStrip, StripByteCounts, XResolution, YResolution and ResolutionUnit. TIFF-F uses all of these fields, but in some cases it specifies a different range of acceptable values than Baseline TIFF does. Per [TIFF], if fields are omitted, the Baseline TIFF default value (if one is specified) applies.
In the field definitions below, each field is shown in this form:
Fieldname (tag-number) = values (if applicable). TYPE
Here's a quick rundown of the Baseline TIFF fields and how TIFF-F uses them 💜
ImageWidth(256) = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096, 4864. SHORT or LONG. These are the fixed page widths in pixels. The allowed values depend on the X and Y resolutions, as shown in sections 2 and 3 of [T.4] and copied here for convenience:
XResolution x Yresolution | ImageWidth
--------------------------------------------|------------------
204x98, 204x196, 204x391, 200x100, 200x200 | 1728, 2048, 2432
300x300 | 2592, 3072, 3648
408x391, 400x400 | 3456, 4096, 4864
--------------------------------------------|------------------Historical TIFF-F didn't support these widths linked to higher resolutions: 2592, 3072, 3648, 3456, 4096 and 4864. Historical TIFF-F documents also included these values for A5 and A6 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 documents are no longer supported in Group 3 facsimile, so those width values are now obsolete 🥀 See section 3.8.2 for more info on inch/metric equivalencies and other implementation details.
ImageLength (257). SHORT or LONG. LONG recommended. The total number of scan lines in the image 📏
Compression (259) = 3,4. SHORT. This is a required TIFF-F field. The permitted values for TIFF-F are 3 and 4, as shown. The default value per Baseline TIFF is 1 (Uncompressed), but that value is invalid for facsimile images. Baseline TIFF also allows value 2 (Modified Huffman encoding), but its data is presented in a form that doesn't contain EOLs. Instead, TIFF-F uses value 3 for encoding one-dimensional T.4 Modified Huffman or two-dimensional Modified READ data. The detailed settings for T.4 encoded data are specified using the T4Options field. TIFF-F also allows value 4 for the compression field, which means the data is coded using a [T.6] compression method (i.e. the Modified Modified READ two-dimensional method). The detailed settings for T.6 encoded data are specified using the T6Options field.
Check out the definitions of the T4Options and T6Options fields in section 3.3, and section 3.8 for more on encoding images and TIFF-F conventions 🧠
PhotometricInterpretation (260) = 0,1. SHORT. This field lets you note an inverted ("negative") image:
0 = normal
1 = invertedStripOffsets (273). SHORT or LONG. For each strip, the offset of that strip. The offset is measured from the beginning of the file. If a page is expressed as one large strip, there's one entry per page 📍
RowsPerStrip (278). SHORT or LONG. LONG recommended. The number of scan lines per strip. When a page is one large strip, this is the same as the ImageLength field 🌈
StripByteCounts (279). LONG or SHORT. LONG recommended. For each strip, the number of bytes in that strip. If a page is one large strip, this is the total number of bytes in the page after compression. Note that whether you use LONG or SHORT depends on the size of the strip 💾
ResolutionUnit (296) = 2,3. SHORT. The units of measure for resolution:
2 = Inch
3 = CentimeterTIFF-F has traditionally used inch-based measures 📐
XResolution (282) = 204, 200, 300, 400, 408 (inches). RATIONAL. The horizontal resolution of the TIFF-F image, expressed in pixels per resolution unit. The values 200 and 408 were added to the historical TIFF-F values for consistency with [T.30]. Some existing TIFF-F implementations may also support a value of 77 (cm). See section 3.8.2 for more on inch/metric equivalencies and other implementation details ✨
YResolution (283) = 98, 196, 100, 200, 300, 391, 400 (inches). RATIONAL. The vertical resolution of the TIFF-F image, expressed in pixels per resolution unit. The values 100, 200 and 391 were added to the historical TIFF-F values for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77 and 38.5 (cm). See section 3.8.2 for more on inch/metric equivalencies and other implementation details 🦋
3.3 TIFF-F Required Fields 💖
On top of the Baseline TIFF fields, TIFF-F has additional required fields. Here's a review of them 👑
BitsPerSample (258) = 1. SHORT. TIFF-F is only used for black-and-white facsimile images, so the value is 1 (the default) for all files 🖤
FillOrder (266) = 1, 2. SHORT. TIFF-F readers must be able to read data in both bit orders 🔄 But the vast majority of facsimile products store data LSB first, exactly as it appears on the telephone line 📞
1 = Most Significant Bit first.
2 = Least Significant Bit first.NewSubFileType (254) = (Bit 1 = 1). LONG. This field is made up of 32 flag bits. Unused bits are expected to be 0, and bit 0 is the low-order bit. Bit 0 is set to 0 for TIFF-F. Bit 1 is always set to 1 for TIFF-F, indicating a single page of a multi-page image. The same bit settings are used when TIFF-F is used for a one-page fax image. See sections 3.1.1 and 3.1.2 for more details on the structure of multi-page TIFF-F image files 📄
PageNumber (297). SHORT/SHORT. This field specifies the page numbers in the fax document. It has two SHORT values: the first is the page number, and the second is the total number of pages. Single-page documents therefore use 0000/0001 hex. If the second value is 0, the total number of pages in the document isn't available 🔢
SamplesPerPixel (277) = 1. SHORT. The value 1 denotes a bi-level, grayscale, or palette color image 🎨
There's also a requirement to include either the T4Options or the T6Options field in a TIFF-F IFD, depending on the setting of the Compression field. These fields are defined in the next section, on TIFF extensions 🧚
3.4. TIFF-F Extensions ✨
okay bestie, these are the fields that go beyond the required TIFF-F fields 💅 The following ones got defined as extensions in [TIFF] 🌸
T4Options 🦋 T4Options (292) (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1). LONG. This one is required once the compression field is set to 3. For TIFF-F, uncompressed data is not allowed, and EOLs MAY be byte aligned (see section 3.8.3). The bits look like this:
bit 0 = 0 for 1-Dimensional, 1 for 2-Dimensional (MR)
bit 1 = must be 0 (uncompressed data not allowed)
bit 2 = 0 for non-byte-aligned EOLs or 1 for byte-
aligned EOLsIt's a set of 32 flag bits, and unused bits must be set to 0. Bit 0 is the low order bit 🧚 Also, T4Options used to be called G3Options in earlier versions of TIFF and TIFF-F, so if you see that name somewhere, it's the same field 🫶 Data in a TIFF-F image encoded with one of the T.4 methods is not terminated with an RTC (see section 3.8.5) 💀
T6Options 🌈 T6Options (293) = (Bit 0 = 0, Bit 1 = 0) LONG. This one is required for TIFF-F if the compression field is set to 4. It's also 32 flag bits. Setting bit 0 to 0 means the data is compressed with the Modified Modified READ (MMR) two-dimensional compression method. MMR compressed data is two-dimensional and does not use EOLs. Each MMR encoded image MUST include an "end-of-facsimile-block" (EOFB) code at the end of each coded strip (see section 3.8.6). Uncompressed data isn't applicable for bi-level facsimile images, so bit 1 must be set to 0. Unused bits must be set to 0, bit 0 is the low-order bit, and 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 called Group4Options. The significance hasn't changed and the current definition is compatible, so no drama there 🌸
Now for the main event 👑 Three new fields, defined as TIFF-F extensions, describe page quality. The info in them is usually pulled from the receiving facsimile hardware (if that applies). These fields are optional, and they SHOULD NOT be used when writing TIFF-F files for facsimile image data that is error corrected or otherwise guaranteed not to have coding errors 🔥
Some implementations need to know exactly how much error is in the data. Like, a CAD program might want to check that a file has a low error level before importing it into a high-accuracy document 🧐 Group 3 facsimile devices don't necessarily do error correction on the image data, so the quality of a received page has to be inferred from the pixel count of the decoded scan lines. A "good" scan line is one that, when decoded, has the correct number of pixels. A "bad" scan line is one that, when decoded, has an incorrect number of pixels. Iconic stuff, honestly 🦋
BadFaxLines 💖 BadFaxLines (326). SHORT or LONG This field reports the number of scan lines with an incorrect number of pixels that the facsimile encountered during reception (but not necessarily in the file). The formula is:
Note: PercentBad = (BadFaxLines/ImageLength) * 100CleanFaxData 💜 CleanFaxData (327). SHORT This is where the value of N tells you what happened:
N =
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)Okay, the plot twist 🙈 Many facsimile devices don't actually output bad lines. Instead, they repeat the previous good line in place of a bad one. This substitution is called line regeneration, and it makes the image look better, but the data is still corrupted 😭 That's why CleanFaxData exists: it describes the error content of the data. When BadFaxLines and ImageLength show that the device ran into lines with an incorrect number of pixels during reception, CleanFaxData tells you whether those bad lines are actually still in the data or whether the receiving device swapped them out for regenerated lines. Main character energy for honesty ✨
ConsecutiveBadFaxLines 🧚 ConsecutiveBadFaxLines (328). LONG or SHORT. This field reports the maximum number of consecutive lines with an incorrect number of pixels that the facsimile device encountered during reception (but not necessarily in the file). BadFaxLines and ImageLength only tell you how many bad lines there were, not how they're spread out. ConsecutiveBadFaxLines shows the distribution, so it can be a better overall indicator of perceived image quality 🎀
3.5 Recommended Fields ✨
okay so these are the fields that MAY be used when you encode TIFF-F files 🎀 but they're optional vibes, and lots of TIFF readers will just ignore them. they're called "recommended" because that's how it's always been in historical TIFF-F, no cap 💅
BadFaxLines(326) [defined in section 3.4] 🫶CleanFaxData(327) [defined in section 3.4] 🫶ConsecutiveBadFaxLines(328) [defined in section 3.4] 🫶DateTime(306). ASCII. 🕰️ The date and time go in the formatYYYY:MM:DD HH:MM:SS, using 24-hour time. The string length, counting the NUL byte, is 20 bytes. There's a space between DD and HH.DocumentName(269). ASCII. 📄 This is the name of the document that got scanned.ImageDescription(270). ASCII. 🖼️ An ASCII string that describes what's in the image.Orientation(274). SHORT. 🧭 This one is labelled "Recommended" for consistency with historical TIFF-F, but it's also a Baseline TIFF field, with a default value of 1 per [TIFF]. If it's left out, the default of 1 applies, but for clarity TIFF-F writers SHOULD include it 💖 It can be handy for displayers that always want to show the same orientation no matter what the image is. The default value of 1 means "0th row is visual top of image, and 0th column is the visual left." A 180-degree rotation is 3. Check [TIFF] for what the other values mean 🌈Software(305). ASCII. 💻 The optional name and release number of the software package that made the image.
3.6 Requirements for TIFF-F Minimum Subset 👑
this section is all about the minimum subset of TIFF-F fields and values, the stuff every TIFF-F reader SHOULD support so things stay interoperable with current AND historical TIFF-F implementations 🦋 It also defines the TIFF-F structure for writing minimum subset files, so you know exactly how to build one.
3.6.1 Summary of Minimum Subset Fields and Values 📋
here's a quick table of the minimum subset fields and values 🍓 The required fields are in the column labelled "Field", and their minimum values are in the one labelled "Minimum".
Field | Minimum | Comment
------------------|--------------|-------------------------------
BitsPerSample | 1 |one bit per sample
Compression | 3 |3 for T.4 (MH)
FillOrder | 2 |LSB first
ImageWidth | 1728 |
ImageLength | |required
NewSubFileType | Bit 1 = 1 |single page of multipage file
PageNumber | X/X |pg/tot, 0 base, tot in 1st IFD
PhotometricInterp | 0 |0 is white
ResolutionUnit | 2 |inches (default)
RowsPerStrip |=ImageLength |
SamplesPerPixel | 1 |one sample per pixel
StripByteCounts | |required
StripOffsets | |required
T4Options | Bit 0 = 0 |MH
| Bit 1 = 0 |
| Bit 2 = 0,1 |Non-Byte-aligned,
| | Byte-Aligned EOLs
XResolution | 204 |Units is per inch
YResolution | 196,98 |Units is per inch
------------------|--------------|------------------------------3.6.2 TIFF-F Minimum Subset File Structure 🧱
if you need to write minimum subset TIFF-F files, the file structure in Figure 3.1 MUST be used. no skipping this one, bestie 🫶
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 0) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 1) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 1) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 2) | <----------+ Offset
+-----------------------+
| : |
| : |
Figure 3.1 TIFF-F Minimum Subset File Structureas you can see in Figure 3.1, each page's IFD comes before its Image Data 📸 If there are any long field values, they sit between the IFD and the image data for that page. For multi-page docs, each IFD/image pair is immediately followed by the next pair in logical page order inside the file, until every page has been defined 🎀
the TIFF Header format is the one defined in [TIFF]. When you write TIFF-F minimum subset files, the byte order in the Header SHOULD be II (0x4949), which means the bytes are LSB first (little-endian) 🌸
this gives you a TIFF header that looks like Figure 3.2:
| Offset | Description | Type | Value |
+--------+-------------------+--------+--------------------+
| 0 | Byte Order | Short | 0x4949 (II) |
+--------+-------------------+--------+--------------------+
| 2 | Version | Short | 42 |
+--------+-------------------+--------+--------------------+
| 4 | Offset of 0th IFD | Long | 0x 0000 0008 |
+--------+-------------------+--------+--------------------+
Figure 3.2: Image File Header for Minimum Subset TIFF-F Files3.7 Technical Implementation Issues 🔥
3.7.1 Strips 🧃
if TIFF is new to you, the idea of "strips" might feel a bit random. it's built on three fields: RowsPerStrip, StripByteCount, and StripOffsets 🙈
third-party implementations that read and write TIFF files usually expect the image to be split into "strips," also called "bands." Each strip holds a few lines of the image. Because of strips, a TIFF reader doesn't have to load the whole image into memory, so it can fetch and decompress small random bits of the image whenever it needs them. big brain stuff 🧠✨
the dimensions of a strip are described by the RowsPerStrip and StripByteCount fields. Where each strip lives in the TIFF file is recorded in the StripOffsets field 💜
the size of TIFF-F strips depends on the application. The recommended approach for multi-page TIFF-F images is to make each page a single strip 🌈
3.7.2 Bit Order 🔄
the default bit order in Baseline TIFF, per [TIFF], is FillOrder=1, where bits aren't reversed before they're stored. TIFF-F usually uses FillOrder=2 instead, where the bit order within each byte is reversed before storage (so the bits are stored with the Least Significant Bit first) 💅
here's the tea: fax data shows up on the phone line in bit-reversed order compared to how CCITT Recommendation T.4 describes it. So a huge majority of fax implementations pick this natural order for storage 🦋 That said, TIFF-F readers must be able to read data in both bit orders, no exceptions 🫶
3.7.3 Multi-Page 📚
lots of existing implementations already read TIFF-F-like files, but they don't support the multi-page field. multi-page is a total game changer for file management in fax software, so TIFF-F makes multi-page documents (NewSubfileType = 2) the standard case 👑
3.7.4 Compression 🗜️
in Group 3 facsimile, there are three compression methods that had been standardized as of 1994 and are in common use. The ITU-T T.4 recommendation defines a one-dimensional method called Modified Huffman (MH), and a two-dimensional method called Modified READ (MR), where READ is short for Relative Element Address Designate. In 1984, a somewhat more efficient method called Modified Modified READ (MMR) was defined in the T.6 recommendation. It was originally made for Group 4 facsimile, which is why it's often called Group 4 compression. In 1991, MMR got approved for use in Group 3 facsimile, and it's been widely used ever since 🌟
TIFF-F allows three different compression methods. The most common practice is the one-dimensional method (Modified Huffman). You select it by setting Compression to 3 and then setting bit 0 of T4Options to 0 ✨ The two-dimensional Modified READ method is way less common in historical TIFF-F implementations, and you can pick it by setting bit 0 to 1 🌸
depending on what the implementation needs, you can also go for the more efficient two-dimensional method from T.6 (that's MMR, or "Group 4 compression"). You select it by setting Compression to 4, then setting the first two bits (and all unused bits) of T6options to 0 💖 For more help with picking a compression method, check out section 3.8 on Implementation Warnings 🙌
3.7.5 Example Use of Page-quality Fields 📝
here are some examples for writing the CleanFaxData, BadFaxLines, and ConsecutiveBadFaxLines fields:
- Facsimile hardware doesn't provide any page quality information: MUST NOT write page-quality fields. 🚫
- Facsimile hardware provides page quality information but reports no bad lines. Write only BadFaxLines = 0. 🫧
- 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. 🧚
- The source image data stream is error-corrected or otherwise guaranteed to be error-free, like with a computer-generated file: SHOULD NOT write page-quality fields. 💀
3.7.6 Use of TIFF-F for Streaming Applications 🌊
TIFF-F has historically been used for fax image files in things like store-and-forward messaging, where the entire size of the file is known ahead of time. TIFF-F could possibly be used as a file format for streaming applications too, but different assumptions may be needed than the ones this document makes (for example, the entire size and number of pages in the image aren't known in advance). Because of that, defining TIFF-F for streaming is out of scope for this document 🫶
3.7.7. TIFF-F Export and Import ✨
okay so not every fax app has to do TIFF-F natively 💅 some can just support it as an import/export medium and call it a day 🫶
Export
it is recommended that implementations export multi-page TIFF-F files without messing with fields and values 🎀 historically some TIFF-F writers tried to make a bunch of single-page files with tweaked NewSubFileType and PageNumber values (page one-of-one) for exporting 😭 but there's no easy way to link those files back together into one logical multi-page doc, so that move is not recommended 💀
Import
A TIFF-F reader MUST be able to handle a TIFF-F file containing multiple pages 👑 non-negotiable, bestie 🔥
3.8. Implementation Warnings 🚨
3.8.1. Uncompressed data 🙈
TIFF-F requires the ability to read and write at least one-dimensional T.4 Huffman ("compressed") data. Uncompressed data is not allowed, no cap 🚫 that means the "Uncompressed" bit in T4Options or T6Options must be set to 0.
3.8.2. Encoding and Resolution 🎀
okay so two-dimensional encoding is not required for Group 3 compatibility, which means some historic TIFF-F readers literally can't read those files 😭 the minimum subset of TIFF-F REQUIRES support for one-dimensional (Modified Huffman) files, so that's the most portable choice 🫶 but if you're chasing efficiency, you SHOULD use T.6 MMR compression when writing TIFF-F files ✨ some TIFF-F readers also handle two-dimensional Modified READ files. If you want max flexibility when reading TIFF-F files, you SHOULD support all three compression methods (MH, MR and MMR) 💖
for resolution, almost all facsimile products support both standard (98 dpi) vertical resolution and "fine" (196 dpi) resolution, so fine-resolution files are super portable in the real world 🌸
in 1993 the ITU-T added higher resolutions to the T.30 recommendation, including 200 x 200, 300 x 300 and 400 x 400 in dots-per-inch based units 🤯 at the same time, metric dimensions were added that are equivalent to these inch-based resolutions: 391v x 204h and 391v x 408h. So the full set of inch-based equivalents of the new resolutions is supported in the TIFF-F writer, since they may show up in image data streams received from Group 3 facsimile devices. However, plenty of facsimile terminals and older TIFF-F readers are likely not to support these higher resolutions 😬
per [T.4], it is permissible for implementations to treat the following XResolution values as equivalent: <204,200> and <400,408>. In a similar respect, the following YResolution values may also be treated as equivalent: <98, 100>, <196, 200>, and <391, 400>. [T.4] allowed these equivalencies so conversions between inch-based and metric-based facsimile terminals could happen ✨
in a similar respect, optional support for metric-based resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for completeness 🧚 they're used in some legacy TIFF-F implementations, but this use is not recommended for a writer creating TIFF-F files.
3.8.3. EOL byte-aligned 🦋
the historical convention for TIFF-F is that all EOLs in Modified Huffman or Modified READ data must be byte-aligned. However, Baseline TIFF has permitted non-byte-aligned EOLs by default, so a large percentage of TIFF-F reader implementations support both conventions 🙌 which is why the minimum subset of TIFF-F in this document includes support for both byte-aligned and non-byte-aligned EOLs.
an EOL is said to be byte-aligned when Fill bits have been added as needed before EOL codes, so the EOL always ends on a byte boundary. That gives you an EOL-sequence of a one byte preceded by a zero nibble: xxxx0000 00000001 ✨
Modified Huffman encoding works in bits, not bytes, so the end-of-line token can end in the middle of a byte 🫠 with byte alignment, extra zero bits (Fill) are added so the first bit of data after an EOL starts on a byte boundary. Honestly that's a huge win, because application software doesn't have to bit-shift every byte while parsing scan lines for line-oriented image manipulation (like writing a TIFF file) 💅
for Modified READ encoding, each line ends with an EOL and a one-bit tag bit. Per [T.4], the tag bit is 0 if the next line contains two-dimensional data, and 1 if the next line is a reference line. To keep byte alignment, fill bits are added before the EOL/tag bit sequence, so the first bit of data after an MR tag bit starts on a byte boundary 🌈
3.8.4. EOL 🌸
as illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded with Modified Huffman begin with an EOL (which in TIFF-F may be byte-aligned). The last line of the image is not terminated by an EOL 🙅♀️ and in a similar respect, images encoded with two-dimensional Modified READ encoding begin with an EOL, followed by a tag bit.
3.8.5. RTC Exclusion 💅
aside from EOLs, TIFF-F files have historically only held image data. So if you want to stay strictly conformant with the rules in [TIFF] and stay compatible with historical TIFF-F, you SHOULD NOT include the Return To Control sequence (RTC) (6 consecutive EOLs) when writing TIFF-F files 🙅♀️
but if you need to support "transparency" of [T.4] image data, you MAY include RTCs when writing TIFF-F files, as long as the flag settings of the T4Options field are set for non-byte-aligned MH or MR image data 🧚 TIFF reader implementors should also be aware that some existing TIFF-F implementations include the RTC sequence in MH/MR image data 👀
so, TIFF-F readers MUST be able to process files that don't include RTCs, and SHOULD be able to process files that do 🫶
3.8.6. Use of EOFB for T.6 Compressed Images 🧚
any TIFF-F page encoded with the T.6 Modified Modified READ compression method MUST include an "end-of-facsimile-block" (EOFB) code at the end of each coded strip 🚨 per [TIFF], the EOFB code is followed by pad bits as needed to align on a byte boundary. TIFF readers SHOULD ignore any bits other than pad bits beyond the EOFB 🙈
3.9. TIFF-F Fields Summary 📋
implementations can implement a TIFF-F Reader, a TIFF-F Writer, or both, depending on what the application needs 💖 the TIFF-F Reader is typically used to read an existing TIFF-F file that lives on a computer or peripheral device, while the TIFF-F Writer is typically used to turn a bi-level image bit stream into a TIFF-F compliant file. For lots of 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 the following table are specified for a TIFF-F Reader. The range of values for required and recommended fields is shown, along with the minimum subset of values. If required fields are omitted in a TIFF-F file, the Baseline TIFF default value applies. Image data must not have any coding errors 🚫 also, some fields hold a sequence of flag bits (e.g. T4Options). An implementation should test the setting of the relevant flag bits individually, so extensions to the sequence of flag bits can be appropriately ignored 🧠
as noted within [TIFF], a TIFF file begins with an 8-byte image file header, and the first two bytes (0-1) hold the byte order within the file. The permissible values are:
II- Byte order from least significant byte to the most
significant byte (little-endian)
MM - byte order is always from most significant to least
significant (big-endian)for a TIFF-F Reader, the legal values are:
ByteOrder: MM,II (Either byte order is allowed)3.9.1.1. Fields for TIFF-F Reader 🎀
Recommended Fields in the table are shown with an asterisk (*) ⭐ other fields may be present, but they should be informational in nature, so a reader can choose to ignore them 🙌 informational fields that often show up in TIFF-F images are: Software, Datetime, BadFaxLines, CleanFaxData and ConsecutiveBadFaxLines.
Field | Values | Minimum | Comment
------------------|-------------|-------------|----------------------
BitsPerSample | 1 | 1 |one bit per sample
Compression | 3,4 | 3 |3 for T.4 (MH, MR)
| | |4 for T.6 - MMR
FillOrder | 2,1 | 2 |LSB first or MSB first
ImageWidth | 1728, 2048, | 1728 |depends on XResolution
| 2432, 2592, | |
| 3072, 3648, | |
| 3456, 4096, | |
| 4864 | |
ImageLength | >0 | |required
NewSubFileType | Bit 1 = 1 | Bit 1 = 1 |single page of
| | |multipage file
Orientation * | 1 | |1st row=top left,
| | | 1st col=top
PageNumber | X/X | 0/1 |pg/tot, 0 base,
| | | tot in 1st IFD
PhotometricInterp | 0,1 | 0 |0 is white
ResolutionUnit | 2,3 | 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |
| or other | |
SamplesPerPixel | 1 | 1 |one sample per pixel
StripByteCounts | >0 | |required
StripOffsets | >0 | |required
T4Options | Bit 0 = 0,1 | Bit 0 = 0 |MH,MR(incl if not MMR)
| Bit 1 = 0 | Bit 1 = 0 |
| Bit 2 = 0,1 | Bit 2 = 0,1 | Non-Byte-aligned and
| | | Byte-Aligned EOLs
T6Options | 0 | |MMR (incl only if MMR)
XResolution | 204,200,300,| 204 | If unit is per inch
| 400,408, | |
| 77 | | If unit is per cm
YResolution | 196,98,100, | 196,98 | If unit is per inch
| 200,300,391,| |
| 400, | |
| 77,38.5 | | If unit is per cm
------------------|-------------|-------------|----------------------3.9.2. TIFF-F Writer ✨
okay so this is the writing side 💅 when you're creating a TIFF-F file from an image data stream or other raster data, implementations SHOULD write files that a TIFF-F Reader (the one from 3.9.1) can read 🫶. it's recommended that all fields from the table in 3.9.1.1 SHOULD be included when you write TIFF-F files, because that keeps you from depending on default values 🧚. and image data must not have any coding errors, bestie 🙅♀️
other fields are allowed too 🎀 but they should be informational, so a Reader can just ignore them if it wants.
if you're writing "minimum subset" TIFF-F files, the rules in section 3.6 apply 🌸
the informational fields that are useful for TIFF-F files are:
SoftwareDatetimeBadFaxLinesConsecutiveBadFaxLines
TIFF Writers SHOULD only generate the fields that describe fax image quality when the image was made from a fax image data stream where error correction (like Group 3 Error Correction Mode) was NOT used 🙈 those fields are CleanFaxData, BadFaxLines and ConsecutiveBadFaxLines.
4. MIME sub-type image/tiff 💖
[TIFFREG] is the doc that registers the MIME content-type image/tiff for TIFF 6.0 encoded image data 🦋 when TIFF gets sent over MIME, the TIFF content from this document must be encoded inside an image/tiff content type. there's also an optional "application" parameter for image/tiff, which tells the recipient which application's subset of TIFF (and which TIFF extensions) was used for the encoded image data, if it's known ✨ this is mostly so the recipient can pick a good rendering package to display or process the file.
4.1 Refinement of MIME sub-type image/tiff for Application F 🔥
since this document defines a facsimile-specific profile of TIFF, it's worth knowing the right application parameter for image/tiff 👑
the "faxbw" application parameter is for black and white facsimile 🖤 it's for apps that can process one or more TIFF facsimile profiles or subsets used to encode black and white fax data.
because this document defines a TIFF profile for fax that works with black and white fax image data, apps that use this profile (or its minimum subset) should set the application parameter to "faxbw" 💅
here's an example of image/tiff with the application parameter set to "faxbw":
Example:
Content-type: image/tiff; application=faxbwwith that parameter value, apps can tell the content is a fax profile or subset of TIFF for encoding black and white image data before they try to process the image data 🦋
5. Implementation Usage 🌈
5.1 Internet Fax Usage 📠
TIFF-F is basically built to be a component of Internet Fax 💜 Internet Fax is expected to use both a TIFF-F Reader and a TIFF-F Writer. the details of the Internet Fax services and how they use TIFF-F will be specified in other documents, so stay tuned 🧚
5.2 VPIM Usage 🎀
the Application F of TIFF (aka TIFF-F content) is a secondary component of the VPIM Message defined in [VPIM2] 📞 voice messaging systems can often handle fax store-and-forward on top of their usual voice message store-and-forward stuff, so it's a natural fit 🫶
because of that, TIFF-F fax messages can optionally be sent between compliant VPIM systems, and they may get rejected if the recipient system can't deal with fax 😭
for the proper way to use this content, check the VPIM Specification 🌸
6. Security Considerations 🔐
okay this part is SO important, bestie, so read it carefully 🚨
this document describes the encoding for TIFF-F, which is a profile of the TIFF encoding for facsimile 📠 because of that, it doesn't create any security issues that aren't already identified in [TIFFREG], since it uses fields the way [TIFF] defines them 🙏 there are also new TIFF fields defined in this spec, but they're purely descriptive, so no new security risks come with them 💅
and the encoding in this document doesn't in any way stop you from using any Internet security protocol to encrypt, authenticate, or non-repudiate TIFF-F encoded facsimile messages 🔒✨ so go ahead and lock it down, periodt 👑
7. Authors' Addresses 💌
Glenn W. Parsons
Northern Telecom
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1-613-763-7582
Fax: +1-613-763-2697
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.net8. References 📚
- [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 💌
- [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. 📝
- [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 🔑
- [T.30] ITU-T Recommendation T.30 - "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", June, 1996 📠
- [T.4] ITU-T Recommendation T.4 - "Standardization of Group 3 Facsimile Apparatus for Document Transmission", June, 1996 📠
- [T.6] ITU-T Recommendation T.6 - "Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus", March, 1993 📠
- [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, June 3, 1992. 🖼️
- [TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File Format (TIFF) - image/tiff: MIME Sub-type Registration", RFC 2302, March 1998. 🦋
- [VPIM2] G. Vaudreuil and G. Parsons, "Voice Profile for Internet Mail - version 2", Work In Progress, <draft-ema-vpim-06.txt>, November 1997. 📞
9. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (1998). All Rights Reserved. 💖
this document, and translations of it, can be copied and handed out to others 🫶 you can also make derivative works that comment on or explain it, or help with implementing it, and publish and distribute those in whole or in part, with no real restrictions 🎉 the one catch is that the copyright notice and this paragraph have to be included on every copy and derivative work 📝
but the document itself can't be modified in any way 🙅♀️ that includes removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards (in which case the copyright procedures in the Internet Standards process have to be followed), or when it's translated into languages other than English 🌍
the limited permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them ♾️✨
this document and the info in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀 that's the legal boring bit, but it matters, so it's staying 🫶
📦 where this page comes from
- ietf: rfc2306 1998-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms