RFC 2301
File Format for Internet Fax
Hiii bestie 💖 Okay, so this is RFC 2301, and it's giving fax machine 📠 but make it the internet 🦋
File Format for Internet Fax ✨
Okay so the basic tea 🫖: this RFC is a Standards Track doc from the Network Working Group, dated March 1998. The authors are L. McIntyre (Xerox Corporation), S. Zilles (Adobe Systems, Inc.), R. Buckley (Xerox Corporation), D. Venable (Xerox Corporation), G. Parsons (Northern Telecom), and J. Rafferty (Human Communications). 👑 It's the RFC number 2301, and the title block doesn't list anything it obsoletes or updates, so no drama there 🙈
Status of this Memo 📜
Okay so this doc is an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 💅 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice 🎀
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
Abstract 🦋
Okay so this doc describes the TIFF (Tag Image File Format) representation of image data, as specified by the ITU-T Recommendations for black-and-white and color facsimile. 📠 This file format spec is commonly known as TIFF-FX ✨ It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax. It also defines base JPEG, lossless JBIG and Mixed Raster Content modes (Profiles C, L, M) for color and grayscale fax 🌈 These modes or profiles line up with the content of the applicable ITU-T Recommendations. Files formatted under this spec use the image/tiff MIME Content Type 💅
Table of Contents 🧚
1. INTRODUCTION........................................................4
1.1. Scope..........................................................5
1.2. Approach.......................................................5
1.3. Overview of this draft.........................................5
2. TIFF and Fax........................................................7
2.1. TIFF Overview..................................................7
2.1.1. File Structure.............................................7
2.1.2. Image Structure............................................9
2.1.3. TIFF File Structure for Fax Applications..................10
2.2 TIFF Fields for All Fax Applications...........................11
2.2.1. TIFF Fields required for all fax modes....................12
2.2.2. Additional TIFF Fields required for all fax modes.........13
2.2.3. TIFF Fields recommended for all fax modes.................15
2.2.4. New TIFF Fields recommended for fax modes.................16
3. Minimal Black-and-White Fax Mode...................................18
3.1. Overview......................................................18
3.2. Required TIFF Fields..........................................18
3.2.1 Baseline Fields............................................18
3.2.2 Extension Fields...........................................20
3.2.3 New Fields.................................................20
3.3. Recommended TIFF Fields.......................................20
3.4. End of Line (EOL) and Return to Control (RTC).................20
3.4.1 RTC Exclusion..............................................21
3.5. File Structure................................................22
3.6. Minimal Black-and-White Mode Summary..........................23
4. Extended Black-and-White Fax Mode..................................24
4.1. TIFF-F Overview...............................................25
4.2. Required TIFF Fields..........................................26
4.2.1. Baseline Fields...........................................26
4.2.2. Extension Fields..........................................28
4.2.3. New Fields................................................29
4.3. Recommended TIFF Fields.......................................29
4.3.1. Baseline Fields...........................................29
4.3.2. Extension Fields..........................................29
4.3.3. New Fields................................................29
4.4. Technical Implementation Issues...............................30
4.4.1. Strips....................................................30
4.4.2. Bit Order.................................................31
4.4.3. Multi-Page................................................31
4.4.4. Compression...............................................31
4.4.5. Example Use of Page-quality Fields........................32
4.4.6. Practical Guidelines for Writing and Reading Multi-Page
TIFF-F Files..............................................33
4.4.7. Use of TIFF-F for Streaming Applications..................34
4.5. Implementation Warnings.......................................34
4.5.1. Uncompressed Data.........................................34
4.5.2. Encoding and Resolution...................................35
4.5.3. EOL byte-aligned..........................................35
4.5.4. EOL.......................................................36
4.5.5. RTC Exclusion.............................................36
4.5.6. Use of EOFB for T.6 Compressed Images.....................37
4.6. Example Use of TIFF-F.........................................37
4.7. Extended Black-and-white Fax Mode Summary.....................37
5. Lossless JBIG Black-and-White Fax Mode.............................39
5.1. Overview......................................................40
5.2. Required TIFF Fields..........................................40
5.2.1. Baseline Fields...........................................40
5.2.2. Extension Fields..........................................40
5.2.3. New Fields................................................41
5.3. Recommended TIFF Fields.......................................41
5.4. Lossless JBIG Black-and-White Mode Summary....................41
6. Base Color Fax Mode................................................43
6.1. Overview......................................................43
6.2. Required TIFF Fields..........................................43
6.2.1. Baseline Fields...........................................43
6.2.2. Extension Fields..........................................45
6.2.3. New Fields................................................46
6.3. Recommended TIFF Fields.......................................47
6.4. Base Color Fax Mode Summary...................................47
7. Lossless Color Mode................................................49
7.1. Overview......................................................50
7.1.1. Color Encoding............................................50
7.1.2. JBIG Encoding.............................................50
7.2. Required TIFF Fields..........................................51
7.2.1. Baseline Fields...........................................51
7.2.2. Extension Fields..........................................52
7.2.3. New Fields................................................53
7.3. Recommended TIFF Fields.......................................53
7.4. Lossless Color Fax Mode Summary...............................53
8. Mixed Raster Content Mode..........................................55
8.1 Overview.......................................................55
8.1.1. MRC 3-layer model.........................................55
8.1.2. A TIFF Representation for the MRC 3-layer model...........56
8.2. Required TIFF Fields..........................................58
8.2.1. Baseline Fields...........................................58
8.2.2. Extension Fields..........................................59
8.2.3. New Fields................................................60
8.3. Recommended TIFF Fields.......................................62
8.4. Rules and Requirements for Images.............................62
8.5. MRC Fax Mode Summary..........................................63
9. MIME content-type image/tiff.......................................66
9.1 Refinement of MIME content-type image/tiff for Facsimile
Applications...................................................66
10. Security Considerations...........................................67
11. References........................................................67
12. Authors' Addresses................................................69
Annex A: Summary of TIFF Fields for Internet Fax .....................70
Annex B. IANA Registration for image/tiff Application Parameter
Values used for facsimile....................................75
Full Copyright Statement..............................................771. Introduction ✨
Okay so this doc describes how to use TIFF (Tag Image File Format) to represent the data content and structure made by the current suite of ITU-T Recommendations for Group 3 facsimile 📠 These Recommendations and the TIFF fields described here support the following facsimile modes or profiles:
S: minimal black-and-white mode, using binary MH compression
[T.4]
F: extended black-and-white mode, using binary MH, MR and MMR
compression [T.4, T.6]
J: lossless JBIG black-and-white mode, with JBIG compression
[T.85, T.82]
C: lossy color and grayscale mode, using JPEG compression
[T.42, T.81]
L: lossless color and grayscale mode, using JBIG compression
[T.43, T.82]
M: mixed raster content mode [T.44], using a combination of
existing compression methodsEach profile lines up with the content of the ITU-T Recommendations shown, and each one is a subset of the full TIFF for facsimile spec 🧚
Profile S is the minimal interchange set of fields 💖 It guarantees that, at the very least, binary black-and-white images will be supported. Implementations are required to support this minimal interchange set of fields 🫶
Heads up bestie: this is the baseline. If you're building a fax implementation, S is the floor, not the ceiling 🔥
With the goal of specifying a file format for Internet Fax, this draft does three things 💅
- specifies the structure of TIFF files for facsimile data,
- defines ITU fax-compatible values for existing TIFF fields,
- defines new TIFF fields and values required for compatibility with ITU color fax.
This specification of TIFF for facsimile is known as TIFF-FX. 🌸✨
Part 1 of 20 done, bestie 🌈 more parts are coming, so stay tuned 🦋💖
1.1 Scope ✨
Okay so this doc is literally the rulebook for sending fax over the Internet inside a TIFF file 📠💖. It lists the TIFF fields and field values you need so everything lines up with the existing ITU-T Recommendations for Group 3 black-and-white, grayscale and color fax 🖤🩶🌈. TIFF has historically been the go-to for fax image files in store-and-forward messaging 📨. If your app supports this format for import/export, it can totally make it a native format too 💅. And this doc recommends a TIFF file structure that works with low-memory and page-level streaming implementations 🦋.
Unless otherwise noted, the current TIFF specification [TIFF] and selected TIFF Technical Notes [TTN1, TTN2] are the primary references for describing TIFF and defining TIFF fields. This document is the primary reference for defining TIFF field values for fax applications 🧚.
1.2 Approach
The plan is giving simple: stick the compressed fax image data inside a TIFF file, then use TIFF fields to describe the image data's parameters 🎀. Those fields get values that follow the ITU-T Recommendations 📋. The MIME content type of the result is image/tiff, with an optional Application parameter [TIFF-REG]; see Section 9 🌸.
This is main character energy 🌉. TIFF pages, images, and strips let a TIFF file keep the fax data stream structure AND the performance perks that come with it, so both legacy fax machines and host-based fax apps are happy 🫶. Building on TIFF also means there's an established base of users and implementors, plus backward compatibility with existing TIFF-based IETF proposals and work in progress for Internet fax 👑.
1.3 Overview of this draft
Okay, the roadmap 🗺️. Section 2 gives an overview of TIFF. Section 2.1 covers the structure of TIFF files, including general guidelines for structuring multi-page TIFF files 📖. Section 2.2 lists the TIFF fields that are required or recommended for all fax modes. The TIFF fields used only by specific fax modes are described in Sections 3-8, which also specify the ITU-compatible field values (image parameters) for each mode 🧁.
The full set of permitted TIFF fields for facsimile lives in the current TIFF specification, Section 2 of this document, and the sections on specific fax modes. This document defines profiles of TIFF for facsimile, where a profile is a subset of the full set of permitted fields and field values 💜.
Section 3 defines the minimal black-and-white facsimile mode (Profile S), which is required in all implementations 🥹. Section 4 defines the extended black-and-white fax mode (Profile F), which provides a standard definition of TIFF-F ✨. Section 5 describes the lossless black-and-white mode using JBIG compression (Profile J) 🖤. Section 6 defines the base color mode, required in all color implementations, for the lossy JPEG representation of color and grayscale facsimile data (Profile C) 🌈. Section 7 defines the lossless JBIG color and grayscale facsimile mode (Profile L), and Section 8 defines the Mixed Raster Content facsimile mode (Profile M) 🔥. Each of these sections wraps up with a table summarizing the required and recommended fields for that mode and the values they can have 📊.
Section 9 describes the MIME content type image/tiff and the use of the optional Application parameter with TIFF for facsimile 💌. Sections 10, 11, 12 and 13 give Security Considerations, the ISOC Copyright Notice, References and Authors' Addresses 🫶. Annex A gives a summary of the TIFF fields used or defined in this document, basically a cheat sheet for implementors 🍓.
To implement only the minimal interchange black-and-white set of fields and values (Profile S), you need only read Sections 1, 2, 3, 9 and 10 🎀.
The following tree diagram shows how the profiles relate to each other and how they relate to coding methods 🌳.
S (MH)
/ \
B&W / \ Color
------------ ----------
/ \ \
/ F (MMR, MR) C (JPEG)
/ / \
J (JBIG) ---- \
/ \
L (JBIG) \
\
M (MRC)A profile is based on a collection of ITU-T facsimile coding methods 🧚.
For example, Profile S, the minimal mode, is based on Modified Huffman (MH) compression, which is defined in ITU-T Rec. T.4 🐣. Profile F specifies Modified Read (MR) and Modified Modified Read (MMR) compressions, which are defined in ITU-T Rec. T.4 and T.6 💖.
All implementations of TIFF for facsimile MUST implement Profile S, which is the root node of the tree 🌸. All color implementations of TIFF for facsimile MUST implement Profile C 🌈. The implementation of a particular profile MUST also implement those profiles on the path that connect it to the root node, and MAY optionally implement profiles not on the path connecting it to the root node 🫶. For example, an implementation of Profile M must also implement Profiles C and S, and may optionally implement Profile F, J or L 👑. For another example, an implementation of Profile C must also implement Profile S, and may optionally implement Profile F or J 💅.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ] 📚🔥.
2. TIFF and Fax ✨
2.1. TIFF Overview
TIFF provides a means for describing, storing and interchanging raster image data 🖼️. A primary goal of TIFF is to provide a rich environment within which applications can exchange image data 💖. The current TIFF specification [TIFF] defines a commonly used, core set of TIFF fields known as Baseline TIFF 🎀. The current specification and TIFF Technical Notes 1 and 2 [TTN1, TTN2] define several TIFF extensions 🦋. The TIFF-based specification for fax applications uses a subset of Baseline TIFF fields, with selected extensions, as described in this document 🌷. In a few cases, this document defines new TIFF fields specifically for fax applications 🧚✨.
2.1.1. File Structure
okay so TIFF is built for raster images 🖼️, which makes it a total match for fax docs, because those are basically multi-page raster images 📄✨. Each raster image is a stack of rows (scanlines), and every row has the same number of pixels (the unit of sampling). Each pixel has at least one sample or component (exactly one for black-and-white images) 🖤
A TIFF file starts with an 8-byte image file header 🎀. The first two bytes tell you the byte order. II (0x4949) means the bytes go least to most significant (little-endian), and MM (0x4D4D) means most to least significant (big-endian), within a 16- or 32-bit integer. Either byte order works, EXCEPT for minimal black-and-white mode, which SHALL use II 💅. Next up are two bytes holding the value 42, which says "yep, this is a TIFF file," ordered according to those first two bytes. The last four bytes hold the offset that points to the first image file directory (IFD) 🧚. Every offset in a TIFF file is measured from the very start of the file. An IFD can live anywhere after the header, but it has to start on a word boundary.
An IFD is a list of tagged fields, sorted in ascending order by tag value 🌸. It's made of a 2-byte count of how many fields there are, the field entries themselves, and a 4-byte offset to the next IFD. The fields hold info about the image and pointers to the image data. Each separate raster image in the file gets its own IFD 💜.
Each field entry is 12 bytes long: a 2-byte Tag, 2 bytes for the field type (like short, long, rational, or ASCII), 4 bytes for the count (number of values or offsets), and 4 bytes that either hold an offset to a field value stored outside the IFD or, depending on the type and count, the field value itself 🦋. Stuff like resolution, dates, names and descriptions are "long" field values that don't fit in 4 bytes, so they use offsets in the field entry. The details are in the TIFF specification [TIFF] 📚.
A TIFF file can hold more than one IFD, and each IFD is a subfile whose type is given in the NewSubfileType field 🍓. You can organize multiple IFDs as a linked list, where the last entry in each IFD points to the next one (the pointer in the last IFD is 0), or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The SubIFDs field is an array of pointers to the child IFDs of the primary IFD 🌳.
Child IFDs describe related images, like reduced-resolution versions of the primary IFD image 🔍. The same IFD can point to a next IFD and to child IFDs, and child IFDs can point to other IFDs too. the tea is that it's very flexible 🫶.
All fax modes represent a multi-page fax image as a linked list of IFDs 📑. Each IFD has a NewSubfileType field with a bit that marks it as one page of a multi-page document. Each IFD also has a PageNumber field, numbered in ascending order starting at 0 for the first page 🔢. A Baseline TIFF reader isn't required to read any IFDs past the first one, but an implementation that reads files complying with this specification SHALL read multiple IFDs 👑. Only the Mixed Raster Content fax mode (Section 8) needs child IFDs 🙌.
Here's the structure of a multi-page TIFF file, bestie 👀:
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 0 | | |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 1) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 1 | | |
+-----------------------+ | |
| strip 2 page 1 |<-+ |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 2) |<-----------+ Offset
| : |2.1.2 Image Structure
okay so an IFD stores an image as one or more strips, like in that figure up there 🧩. A strip is 1 or more scanlines (rows) of raster image data in compressed form. An image can live in a single strip, or it can be split into several strips, which takes less memory to buffer 🧠. (Baseline TIFF recommends about 8k bytes per strip, but existing fax usage is usually one strip per image 📏.)
Every IFD needs three strip-related fields: StripOffsets, RowsPerStrip and StripByteCounts 🎯. StripOffsets is an array of pointers to the strip or strips that hold the actual image data. StripByteCounts gives the number of bytes in each strip after compression. TIFF requires that every strip, except the last, has the same number of scanlines, and that number goes in the RowsPerStrip field 📐. This document introduces a new StripRowCounts field that allows a variable number of scanlines per strip, which the Mixed Raster Content fax mode (Section 8) requires 🆕.
Image data is stored as uninterpreted, compressed image data streams inside a strip 🗜️. The formats of those streams follow the ITU-T Recommendations. The Compression field in the IFD says which compression type is used, and other TIFF fields in the IFD describe image attributes like color encoding and spatial resolution 🌈. Compression parameters live inside the compressed data stream instead of in TIFF fields. That keeps the TIFF representation and the compressed data format spec independent of each other 🙅♀️. This approach, modeled on [TTN2], lets TIFF gracefully add new compression schemes as they show up ✨.
Some attributes can be specified both in the compressed data stream and in a TIFF field, and the two values might not match 🤔. When that happens for values needed to interpret the data stream, the values in the data stream win. For informational values that aren't needed to interpret the stream, like author name, the TIFF field value wins 🏆.
2.1.3 TIFF File Structure for Fax Applications
the TIFF spec is super flexible about file structure, and it doesn't dictate the order of IFDs, field values and image data in a file 🌀. Individual applications might require or recommend a particular ordering.
This specification recommends that, when a TIFF file is used for facsimile, a multi-page fax document SHOULD be represented as a linked list of IFDs 📜. It also recommends that a TIFF file for facsimile SHOULD order pages the same way they're ordered in a fax data stream 🗂️. In a TIFF file, a page is made of several elements: one or more IFDs (including subIFDs), long field values stored outside the IFDs, and image data (in one or more strips) 🧩.
The minimal black-and-white mode (Profile S) specifies a required ordering of pages and of elements within a page (Section 3.5) 🔒. The extended black-and-white mode (Profile F) gives guidelines for ordering pages and page elements (Section 4.4.6) 🗺️. Other profiles SHOULD follow these guidelines. The point is to make it easier to implement TIFF writers and readers for fax apps, and to convert between TIFF files and fax data stream representations 🤝. Still, for interchange robustness, readers SHOULD be prepared to read TIFF files whose structure is consistent with [TIFF], which supports a more flexible file structure than what's recommended here 💪.
This specification introduces an optional new GlobalParametersIFD field, defined in Section 2.2.4 📋. The field has type IFD and points to parameters describing the fax session. You can often get these by scanning the file, but it's convenient to have them all in one place for fast, easy access ⚡. If a GlobalParametersIFD occurs in a TIFF file, it SHOULD be located in the first IFD, right after the 8-byte image file header 🥰.
2.2 TIFF Fields for All Fax Applications
The TIFF specification [TIFF] is organized as a baseline set plus several extensions, including technical notes [TTN1, TTN2] that will be folded into the next TIFF release 📖. The baseline and the extensions both have required and optional fields.
Facsimile apps need (and recommend) a mix of baseline and extension fields, plus some new fields that aren't part of the TIFF spec and are defined in this document 🧁. This subsection lists the fields that are required or recommended for all modes. Section 2.2.1 lists the fields required by all modes whose values don't depend on the mode. Section 2.2.2 lists the fields required by all modes whose values do depend on the mode. Section 2.2.3 lists the fields recommended for all modes. Fields required or recommended by only some modes are covered in the section (Sections 3-8) describing that mode. Each fax mode section has subsections for required and recommended fields, and each one sorts the fields into baseline, extension or new 🗃️.
The fields required for facsimile only have a few legal values, specified in the ITU-T Recommendations 🎀. Some of those values are required and some are optional, just like in fax implementations that conform to the ITU-T Recommendations (where they're mandatory or optional). The required and optional values are noted in the sections on the different fax modes 🏷️.
This section describes the fields required or recommended by all fax modes. The pattern for describing TIFF fields in this draft is 👇:
FieldName(TagValueInDecimal) = allowable values. TYPE
WhetherRequiredByTIFForTIFFforFAX
Count = (omitted if =1) = (if not in current spec but available)
Explanation of the field, how it's used, and the values it can have.
Default value, if any, as specified in [TIFF]When a field's default value is the value you want, that field may be omitted from the relevant IFD, unless the text of this specification specifically requires it 💖.
2.2.1. TIFF fields required for all fax modes ✨
Okay so this is the "must-have everywhere" squad 💖. The fields in this section SHALL be used by every fax mode, but their values aren't set by the ITU standards, so they stay the same no matter which mode you're in 🎀. The next subsection covers fields that SHALL also be used by every fax mode, except these ones DO have values set by the ITU or by each mode. Fields that only some modes use are described in Sections 3-8, inside the mode sections that use them 🦋.
ImageLength(257) · SHORT or LONG RequiredByTIFFBaseline This is the total number of scanlines in the image, so basically how many rows the whole picture has 📏. No default, must be specified
PageNumber(297) · SHORT RequiredByTIFFforFAX, TIFFExtension Count = 2 This field holds two numbers 🌸. The first is the page number, where 0 means the first page. The second is the total number of pages in the document. If that second value is 0, the total page count isn't available. No default, must be specified
RowsPerStrip(278) · SHORT or LONG RequiredByTIFFBaseline This is how many scanlines go in each TIFF strip, except the last one. For a single-strip image, it's the same as the ImageLength value 🧚 Default = 2**32 - 1 (meaning all scanlines in one strip)
StripByteCounts(279) · SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, this is how many bytes that strip takes up after compression 💾 No default, must be specified
StripOffsets(273) · SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, this is the byte offset from the very beginning of the file to where that strip starts 🗺️ No default, must be specified
2.2.2. Additional TIFF fields required for all fax modes 💅
These fields SHALL be used by every fax mode too, but the values depend on the mode you're describing and its ITU Recommendations 🌈. So this section only defines the fields themselves. The values for each particular mode show up in Sections 3-8. Fields that only some modes use are described in the section (3-8) for the mode that uses them.
BitsPerSample(258) · SHORT RequiredByTIFFBaseline This is the number of bits per image sample. Default = 1 (field may be omitted if this is the value)
Compression(259) · SHORT RequiredByTIFFBaseline This is the compression method used for the image data. Default = 1 (no compression, so may not be omitted for FAX) 🙈
FillOrder(266) · SHORT RequiredByTIFFforFax Baseline TIFF's default bit order, per [TIFF], is FillOrder=1, where bits aren't reversed before storage. TIFF for Fax usually goes with FillOrder=2 instead, where the bit order inside each byte gets reversed before storage (so bits are stored Least Significant Bit first) 🔄. Default = 1 (field may be omitted if this is the value)
Here's the tea ☕: fax data shows up on the phone line in bit-reversed order compared to how the relevant ITU compression Recommendation describes it. That's why most fax implementations pick this natural order for storage. Still, all readers that conform to this specification must be able to read data in both bit orders 🫶.
ImageWidth(256) · SHORT or LONG RequiredByTIFFBaseline This is the number of pixels (columns) in each scanline (row) of the image. No default, must be specified
NewSubFileType(254) · LONG RequiredByTIFFforFAX This is a general hint about what kind of data is in this IFD 👑. Bit 1 is 1 if the image is a single page of a multi-page document. Default = 0 (no subfile bits on, so may not be omitted for FAX)
PhotometricInterpretation(262) · SHORT RequiredByTIFFBaseline This is the color space of the image data. No default, must be specified
ResolutionUnit(296) · SHORT RequiredByTIFFBaseline This is the unit of measure for resolution, where 2 means inch and 3 means centimeter 📐. Default = 2 (field may be omitted if this is the value)
SamplesPerPixel(277) · SHORT RequiredByTIFFBaseline This is the number of color components per pixel. SamplesPerPixel is 1 for a black-and-white, grayscale or indexed (palette) image 🎨. Default =1 (field may be omitted if this is the value)
XResolution(282) · RATIONAL RequiredByTIFFBaseline This is the horizontal resolution of the image, in pixels per resolution unit ↔️. The ITU-T facsimile Recommendations only specify a small handful of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per inch). The allowed XResolution values for each mode are listed in that mode's section. Per [T.4], applications are allowed to treat these XResolution values as equivalent: <204, 200> and <400,408> in pixels/inch. [T.4] allowed these equivalences so inch-based and metric-based fax terminals could convert between each other 🌸.
TIFF for Facsimile Writers SHOULD express XResolution in inch-based units. That keeps things consistent with historical practice and gives the best interoperability ✨. The table below shows how to convert an ITU-T metric value into its inch-based equivalent resolution. No default, must be specified
YResolution(283) · RATIONAL RequiredByTIFFBaseline This is the vertical resolution of the image, in pixels per resolution unit 📏. The ITU-T facsimile Recommendations only specify a small number of vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The allowed YResolution values for each mode are in that mode's section. Per [T.4], applications are allowed to treat these YResolution values as equivalent: <98, 100>, <196, 200>, and <391, 400> in pixels/inch. [T.4] allowed these equivalences so inch-based and metric-based fax terminals could convert between each other 🦋. TIFF for Facsimile Writers SHOULD express YResolution in inch-based units too, for consistency with historical practice and to maximize interoperability. The table below shows how to convert an ITU-T metric value into its inch-based equivalent resolution. No default, must be specified
+-----------------------------+-----------------------------+
| XResolution | YResolution |
+--------------+--------------+--------------+--------------+
|ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit|
| =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) |
+--------------+--------------+--------------+--------------+
| 100 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 98 | 38.5 |
| 200 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 196 | 77 |
| 200 | | 200 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 391 | 154 |
+--------------+--------------+--------------+--------------+
| 300 | | 300 | |
+--------------+--------------+--------------+--------------+
| 408 | 160 | 391 | 154 |
| 400 | | 400 | |
+--------------+--------------+--------------+--------------+2.2.3. TIFF fields recommended for all fax modes 🌟
The fields in this section MAY be used by every fax mode 💜. But Profile S writers (the minimal fax mode described in Section 3) SHOULD NOT use these fields 🙅♀️. Recommended fields that are specific to a mode are described in Sections 3-8.
DateTime(306) · ASCII OptionalInTIFFBaseline This is the date and time the image was created, in 24-hour format "YYYY:MM:DD HH:MM:SS" 🕰️ No default.
DocumentName(269) · ASCII OptionalInTIFFExtension(DocumentStorageAndRetrieval) This is the name of the scanned document. It's a TIFF extension field, not a Baseline TIFF field 📄 No default.
ImageDescription(270) · ASCII OptionalInTIFFBaseline This is a string describing what's in the image 🖼️ No default.
Orientation(274) = 1-8. · SHORT OptionalinTIFFBaseline With 1, the 0th row is the visual top of the image and the 0th column is the visual left side 🧭. See the current TIFF spec [TIFF] for the other values. Baseline TIFF only requires value=1. Default = 1.
Note: It is recommended that a writer who knows the orientation includes this field to give a positive indication of it, even if the value is the default. If the Orientation field is omitted, the reader SHALL assume a value of 1. 🚨
Software(305) · ASCII OptionalInTIFFBaseline This is the optional name and release number of the software package that created the image 💻 No default.
That's the end of this part's fields, bestie! 🌈
2.2.4 New TIFF fields recommended for fax modes ✨
okay bestie, the new TIFF fields in this section MAY be used by all fax modes 🎀, but nobody's expecting them in the minimal fax mode from Section 3 💅. Historical TIFF-F readers from Section 4 and [TIFF- F] don't support these new fields either 🙈. They describe "global" parameters of the fax session that created the image data 🌸. They're optional, they're not part of the current TIFF specification, and they're defined right here in this document 💜.
The first new field is GlobalParametersIFD (400) 🧚. It's an IFD that holds global parameters, and it lives in a Primary IFD. Its type is IFD.
This is an IFD containing global parameters. It is recommended that a TIFF writer place this field in the first IFD, where a TIFF reader would find it quickly ⭐.
Every field inside the GlobalParametersIFD is a TIFF field that's legal in any IFD 🌈. Required baseline fields should not be located in the GlobalParametersIFD, though. They belong in each image IFD 🫶. If there's a conflict between a field in the GlobalParametersIFD and the same field in an image IFD, the data in the image IFD shall prevail 👑.
Also in the GlobalParametersIFD is the new ProfileType field (401, type LONG), which generally describes the information in this IFD and in the TIFF file 🍓. It describes the type of image data stored in this IFD, with these values:
0 = Unspecified
1 = Group 3 fax
No defaultNext up are the new global fields defined in this document as IFD entries for fax applications 🦋.
FaxProfile (402, type BYTE) is the profile that applies to the file. A profile is a subset of the full set of permitted fields and field values of TIFF for facsimile 💖. The currently defined values, with the value range 0 - 6, are:
0: does not conform to a profile defined for TIFF for facsimile
1: minimal black & white lossless, Profile S
2: extended black & white lossless, Profile F
3: lossless JBIG black & white, Profile J
4: lossy color and grayscale, Profile C
5: lossless color and grayscale, Profile L
6: Mixed Raster Content, Profile MCodingMethods (403, type LONG) tells you which coding methods are used in the file 🔥. Each bit with a value of 1 means one of the following coding methods is used:
Bit 0: unspecified compression,
Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman),
Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read),
Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR),
Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG),
Bit 5: ITU-T Rec. T.81 (Baseline JPEG),
Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color),
Bits 7-31: reserved for future useNote: there's a limit of 32 compression types for identifying standard compression methods 🙈.
VersionYear (404, type BYTE) is the year of the standard specified by the FaxProfile field 📅. It's given as 4 characters, like '1997', and it's used in lossy and lossless color modes 🌸. Its count is 4.
ModeNumber (405, type BYTE) is the mode of the standard specified by the FaxProfile field 🧚. A value of 0 indicates Mode 1.0 💅. It's used in Mixed Raster Content mode.
3. Minimal Black-and-White Fax Mode 🎀
This section defines the minimal black-and-white subset of TIFF for facsimile 🌈. That subset is designated Profile S ✨. All implementations of TIFF for facsimile SHALL support the minimal subset 👑.
Black-and-white mode is the binary fax application most people know today 📠. It's perfect for black-and-white text and line art 🖤. Black-and-white mode comes in two levels of capability ⭐. This section covers the minimal interchange set of TIFF fields that every implementation must support, so that some form of image, even if it's just black-and-white, can be swapped around 🫶. This minimum set is a strict subset of the fields and values defined for the extended black-and-white mode (TIFF-F or Profile F) in Section 4 💜. Section 4 is the extension that adds the richer black-and-white stuff on top of this minimal set 💅.
3.1. Overview
The minimal interchange part of black-and-white fax supports 1-dimensional Modified Huffman (MH) compression 🍓. It works at the original Group 3 fax resolutions, usually called "standard" and "fine" 🦋.
To keep things interoperable, this mode uses a minimal set of fields with a minimal set of values 🌸. There are no recommended fields in this mode 🙈. The TIFF file is required to be "little endian", which means the byte order value in the TIFF header is II 💖. This mode also sets a required ordering for the pages in a fax document, and for the IFDs and image data of each page 🔥. It also requires that a single strip hold the image data for each page, see Section 3.5 🧚. The image data may contain RTC sequences, as described in Section 3.4 ✨.
3.2. Required TIFF Fields
Besides the fields listed in Section 2.2.1, the minimal black-and-white fax mode requires the following fields 💅. The fields listed in Section 2.2.1, plus the fields and fax-specific values specified in this sub- section, must be supported by all implementations 🎀.
3.2.1 Baseline fields
BitsPerSample (258) = 1, type SHORT, and it's RequiredByTIFFBaseline 🌈. It's binary data only. The default is 1, so the field may be left out if that's the value 💜.
Compression (259) = 3, type SHORT, also RequiredByTIFFBaseline 🍓. A value of 3 means 1- or 2-dimensional coding 🦋. The value 3 is a TIFF extension value [TIFF] 🌸. The T4Options field must be specified, and its value says the data is encoded using the Modified Huffman (MH) encoding of [T.4] ✨.
FillOrder (266) = 2, type SHORT, RequiredByTIFFBaseline 🔥. A value of 2 means Least Significant Bit first 🧚.
NOTE: Baseline TIFF readers are only required to support FillOrder = 1, where the lowest numbered pixel is stored in the MSB of the byte 🙈. But lots of devices, like modems, send the LSB first when they turn the data into serial form, so black-and-white fax products commonly use the second value, FillOrder = 2, where the lowest numbered pixel is stored in the LSB 💅. That's why this value is specified in the minimal black-and-white mode 💖.
ImageWidth (256) = 1728, type SHORT or LONG, RequiredByTIFFBaseline 📏. This mode only supports a page width of 1728 pixels 🌸. That width lines up with North American Letter and Legal, and with ISO A4 size pages 🫶. There's no default, so it must be specified 👑.
NewSubFileType (254) = (Bit 1=1), type LONG, RequiredByTIFFforFAX 🎀. Bit 1 is 1 if the image is a single page of a multi-page document 🌈. The default is 0 (no subfile bits on), so this field may not be omitted for fax 💜.
PhotometricInterpretation (262) = 0, type SHORT, RequiredByTIFFBaseline 🦋. A value of 0 means pixel value 1 means black 🖤. There's no default, so it must be specified ⭐.
ResolutionUnit (296) = 2, type SHORT, RequiredByTIFFBaseline 📐. This is the unit of measure for resolution, and 2 means inch 🍓. The default is 2, so the field may be omitted if that's the value ✨.
SamplesPerPixel (277) = 1, type SHORT, RequiredByTIFFBaseline 🌸. This is the number of components per pixel, and it's 1 for black-and-white 🧚. The default is 1, so the field may be omitted if that's the value 💅.
XResolution (282) = 200, 204, type RATIONAL, RequiredByTIFFBaseline 📏. This is the horizontal resolution, expressed in pixels per resolution unit 🔥. In pixels/inch, the allowed values are 200 and 204, and they may be treated as equivalent 💖. See Section 2.2.2 for inch-metric equivalency 🫶. There's no default, so it must be specified 👑.
YResolution (283) = 98, 100, 196, 200, type RATIONAL, RequiredByTIFFBaseline 🌈. This is the vertical resolution, expressed in pixels per resolution unit 🦋. In pixels/inch, the allowed values are 98, 100, 196 and 200 💜. 98 and 100 may be treated as equivalent, and 196 and 200 may be treated as equivalent 🍓. See Section 2.2.2 for inch-metric equivalency 🌸. There's no default, so it must be specified ✨.
3.2.2 Extension fields
T4Options (292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1), type LONG, RequiredTIFFExtension (when Compression = 3) 🧚. Bit 0 = 0 means MH encoding 🙈. Bit 1 must be 0 💅. Bit 2 = 1 means the EOLs are byte aligned, and = 0 means they're not byte aligned 💖. The default is all bits 0, which applies when EOLs are not byte aligned 🔥.
Note: the T4Options field is required when the Compression field has a value of 3 🫶. Bit 0 of this field says which encoding is used (MH only in this mode), and Bit 2 says whether the EOL codes are byte-aligned 👑. If they are byte aligned, fill bits have been added as needed so the End of Line (EOL) codes always end on byte boundaries 🌈. See Section 3.4 for the details 🦋.
3.2.3. New Fields
None. 💜
3.3. Recommended TIFF Fields
None. 🍓
3.4. End of Line (EOL) and Return to Control (RTC)
This is where the differences show up between conventional fax, which is bit and stream oriented, and TIFF, which is byte and file oriented 🌸. Conventional fax, Baseline TIFF, and TIFF extensions for fax all handle EOLs and RTCs differently ✨. It's giving "two different worlds" 🧚.
In conventional fax, an MH-compressed fax data stream for a page looks like this 📠:
EOL, compressed data (first line), EOL, compressed data, ... ,
EOL, compressed data (last line), RTC (6 consecutive EOL codes)Baseline TIFF doesn't use EOL codes or Return to Control (RTC) sequences for MH-compressed data 🙈. But the TIFF extension field T4Options, used in this spec for MH compression (Compression = 3), does require EOLs 💅.
Bit 2 in the T4Options field tells you whether the EOL codes are byte aligned 🎀. If Bit 2 = 1, the EOL codes are byte aligned, so fill bits have been added before each EOL code where needed 🦋. That way an EOL code always ends on a byte boundary, and the first bit of data after an EOL begins on a byte boundary 💖. Without fill bits, an EOL code can end in the middle of a byte 🌈. Byte alignment saves application software from bit-shifting every byte while parsing scan lines for line-oriented image manipulation, like writing a TIFF file 🫶. Not every TIFF reader historically used for fax can handle non-byte aligned data 😭.
TIFF extensions require EOL codes, but TIFF in fax applications has traditionally prohibited RTC sequences 🙈. Implementations that want common processing and interfaces for fax data streams and Internet fax files would prefer that the TIFF data include RTC sequences 💜.
To reconcile all this, RTCs are allowed when the EOL codes are not byte aligned and no fill bits have been added to the data 🧚. That's the situation where fax data is simply inserted in a strip without being processed or interpreted 🌸. RTCs should not occur in the data when EOLs have been byte aligned 👑. This is formally specified in the next sub-section 💅.
3.4.1. RTC Exclusion 💅
okay bestie, if you want to be strict about TIFF conformance and keep things compatible with how TIFF has historically been used for fax, you should NOT include the RTC sequence when writing TIFF files 🙅♀️. but if you need "transparency" of T.4-generated image data, you MAY include RTCs when writing TIFF files, as long as the T4Options flags are set for non-byte aligned data, i.e. Bit 2 is 0 ✨. also, TIFF reader devs, heads up: some existing fax TIFF implementations put the RTC sequence inside MH image data 👀. so minimal set readers MUST be able to handle files without RTCs, and SHOULD be able to handle files that do have them. no drama, just be ready 🫶.
3.5. File Structure 🧚
the TIFF header (the one from Section 2.1.1) has two bytes that tell you the byte order of the file. for the minimal black-and-white mode, those bytes SHALL be "II" (0x4949), which means the bytes are LSByte-first (little-endian) 💜. the first (0th) IFD comes right after the header, so the offset to the first IFD is 8 🍓. here's the header table:
+--------+-------------------+--------+-----------+
| Offset | Description | Value |
+--------+-------------------+--------+-----------+
| 0 | Byte Order | 0x4949 (II) |
+--------+-------------------+--------+-----------+
| 2 | Identifier | 42 decimal |
+--------+-------------------+--------+-----------+
| 4 | Offset of 0th IFD | 0x 0000 0008 |
+--------+-------------------+--------+-----------+the minimal black-and-white mode SHALL order IFDs and image data in a file like this, no exceptions 🎀:
- there SHALL be an IFD for each page in a multi-page fax document;
- the IFDs SHALL appear in the same order as the pages in the document;
- the IFD SHALL come before the image data it has offsets to;
- the image data SHALL appear in the same order as the pages in the document;
- the IFD, the value data, and the image data it has offsets to SHALL all come before the next image IFD; and
- the image data for each page SHALL be contained within a single strip.
because of (6), the StripOffsets field will hold the pointer to the image data 🌸. there are two exceptions to the rule that field entries in the IFD hold the actual values instead of offsets: XResolution and YResolution. both are type RATIONAL and need 2 4-byte numbers, so these "long" field values SHALL be placed right after the IFD that has the offsets to them, and before the image data those offsets point to 🦋.
so the end result is: the IFD for the first page SHALL come first after the TIFF header, then the long field values for XResolution and YResolution, then the first page's image data, then the IFD for the second page, and so on. here's the picture 📸. every IFD is required to have a PageNumber field, which is 0 for the first page, 1 for the second, and so on 💖.
+-----------------------+
| 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
+-----------------------+
| : |this layout can cut down on memory requirements in implementations 🧠. it also gives some support for streaming, where a file can be processed as it arrives, before the whole file has been received 🌊.
3.6 Minimal Black-and-white Mode Summary 📋
this table sums up the TIFF fields that make up the minimal interchange set for black-and-white fax 🍰. the Baseline and Extension fields and field values MUST be supported by all implementations, no skipping 💅. for convenience, some fields have values that are sequences of flag bits, so the table shows integer values matching the flags that are set. but an implementation should test the relevant flag bits one at a time, so that extensions to the flag sequence can be ignored properly. (see T4Options below for an example 👀.)
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1 |
+---------------------------+--------------------------------+
| Compression | 3: 1D Modified Huffman coding |
| | set T4Options = 0 or 4 |
+------------------------------------------------------------+
+---------------------------+--------------------------------+
| FillOrder | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageWidth | 1728 |
+---------------------------+--------------------------------+
| ImageLength | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType | 2: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| PageNumber | n,m: page number n followed by |
| | total page count m |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
+---------------------------+--------------------------------+
| ResolutionUnit | 2: inch |
+---------------------------+--------------------------------+
| RowsPerStrip | number of scanlines per strip |
| | = ImageLength, with one strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1 |
+---------------------------+--------------------------------+
| StripByteCounts | number of bytes in TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets | offset from beginning of |
| | file to single TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 204, 200 (pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98, 196, 100, 200 (pixels/inch)|
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 0: MH coding, EOLs not byte |
| | aligned |
| | 4: MH coding, EOLs byte aligned|
+---------------------------+--------------------------------+4. Extended Black-and-White fax mode 🎀
this section defines the extended black-and-white mode, aka Profile F of TIFF for facsimile 🦋. it's the standard definition of what used to be called TIFF Class F and is now TIFF-F 💜. this makes the mode line up with current ITU-T Recommendations for black-and-white fax and with existing industry practice ✨. implementations of this profile also include implementations of Profile S 🫶.
this section extends the minimal interchange set of fields (Profile S) with a richer set of black-and-white capabilities 🌈. the fields and values here are a superset of the ones defined for the minimal interchange set in Section 3. on top of MH encoding, Modified READ (MR) and Modified Modified READ (MMR) encoding, as described in [T.4] and [T.6], are supported 🔥.
Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the TIFF fields that SHALL be used in this mode. Section 4.3 describes the fields that MAY be used in this mode. in the spirit of the original TIFF-F spec, Sections 4.4 and 4.5 discuss technical implementation issues and warnings 🙈. Section 4.6 gives an example use of TIFF-F, and Section 4.7 summarises the required and recommended fields and their values 📚.
4.1 TIFF-F Overview 🧚♀️
TIFF-F has been around in common use for years, but it was never written down as a standard 😭. an informal TIFF-F document was first created by a small group of fax experts led by Joe Campbell 👑. the existence of TIFF-F is noted in [TIFF], but it isn't defined there. this document is the formal definition of the F application of [TIFF] for Internet applications 💖. for ease of reference, "TIFF-F" is used throughout this document as shorthand for the extended black-and-white mode, or profile, of TIFF for facsimile 🍓.
Up until the TIFF 6.0 specification, TIFF supported various "Classes" that defined how TIFF was used for different applications. Classes existed to support specific applications, and in that spirit TIFF-F was historically known as "TIFF Class F" 💅. earlier informal TIFF-F documents [TIFF-F0] used the "Class F" terminology. as of TIFF 6.0 [TIFF], the 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, starting from Baseline TIFF as defined in [TIFF] and then adding the TIFF extensions that apply to TIFF-F ✨. in almost all cases, the resulting TIFF-F fields and values stay consistent with what was used historically in earlier TIFF Class F definitions 🥹. where some field values have been updated for more precise conformance with the ITU-T [T.4] and [T.30] fax recommendations, those differences are noted 🎀.
4.2. Required TIFF Fields ✨
Okay bestie, this is the must-have checklist 💅 Besides the fields in Section 2.2.1, the extended black-and-white fax mode SHALL use the following fields.
4.2.1. Baseline fields 🎀
BitsPerSample(258) = 1. SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)BitsPerSample is always 1 because the data is binary only 🙈 If the value is the default of 1, you can leave the field out.
Compression(259) = 3, 4. SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding, must have T4Options field This is
a TIFF Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
Read, must have T6Options field)) This is a TIFF Extension value.
Default = 1 (and is not applicable; field must be specified)So Compression is either 3 (1- or 2-dimensional coding, which has to come with a T4Options field) or 4 (2-dimensional MMR coding from ITU-T Rec. T.6, which has to come with a T6Options field). Both are TIFF Extension values [TIFF]. The default of 1 doesn't apply here, so you have to specify the field 💖
NOTE: Baseline TIFF allows value 2 for Modified Huffman encoding. But that data doesn't use EOLs, so TIFF for facsimile uses Compression=3 instead. Check out Sections 4.4.4, 4.5.1 and 4.5.2 for more on compression and encoding.
FillOrder(266) = 1 , 2. SHORT
RequiredByTIFFBaseline
Profile 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 firstProfile F readers have to handle both bit orders, but most fax products store data LSB first, which is exactly how it shows up on the telephone line 📞 FillOrder 1 means MSB first, and 2 means LSB first.
ImageWidth(256) SHORT or LONG
RequiredByTIFFBaseline
This mode supports the following fixed page widths: 1728, 2592, 3456
(corresponding to North American Letter and Legal, ISO A4 paper
sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size), and
2432, 3648, 4864 (corresponding to ISO A3 paper size).
No default; must be specifiedThis mode only supports a handful of fixed page widths: 1728, 2592, and 3456 for North American Letter and Legal and ISO A4, 2048, 3072, and 4096 for ISO B4, and 2432, 3648, and 4864 for ISO A3. No default here, so you have to set it 🍓
NOTE: Historical TIFF-F didn't support these widths tied to higher resolutions: 2592, 3072, 3648, 3456, 4096 and 4864. Old TIFF-F docs also had 816 and 1216 for A5 and A6 widths. Under the latest [T.4], A5 and A6 documents aren't supported in Group 3 facsimile anymore, so those width values are obsolete now. See section 4.5.2 for inch/metric equivalencies and other implementation details.
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax)Bit 1 is set to 1 when the image is one page out of a multi-page document. The default is 0 with no subfile bits on, so for fax you can't leave it out 🙅♀️
NOTE: Bit 1 is always 1 for TIFF-F, which means a single page of a multi-page image. The same bit settings show up when TIFF-F is used for a one-page fax image. See Section 4.4.3 for the details on multi-page files.
PhotometricInterpretation(262) = 0, 1. SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black, 1 = pixel value 1 means white.
This field allows notation of an inverted or negative image.
No default, must be specifiedThis one tells you which pixel value means black and which means white. A 0 means pixel value 1 is black, and a 1 means pixel value 1 is white. It's how you note an inverted or negative image ✨ There's no default, so it has to be specified.
ResolutionUnit(296) = 2, 3. SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-F
has traditionally used inch-based measures.
Default = 2 (field may be omitted if this is the value)ResolutionUnit is 2 for inches or 3 for centimeters. TIFF-F has always been inch-based, and the default of 2 means you can skip it.
SamplesPerPixel(277) = 1. SHORT
RequiredByTIFFBaseline
1 = monochrome, bilevel in this case (see BitsPerSample)
Default =1 (field may be omitted if this is the value)SamplesPerPixel is 1, which means monochrome and bilevel here (check out BitsPerSample). The default is 1, so it can be left out 🌈
XResolution(282) = 200, 204, 300, 400, 408 RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are: 200, 204,
300, 400, and 408. See Section 2.2.2 for inch-metric equivalency.
No default, must be specifiedXResolution is the horizontal resolution in pixels per resolution unit. In pixels per inch, the allowed values are 200, 204, 300, 400, and 408. Check Section 2.2.2 for the inch-to-metric conversion. There's no default, so you have to set it.
NOTE: The values 200 and 408 were added to the historical TIFF-F list so things line up with [T.30]. Some older TIFF-F implementations might also support 80 pixels/cm, which is the same as 204 pixels per inch. See section 4.5.2 for the implementation details.
YResolution(283) = 98, 100, 196, 200, 300, 391, and 400 RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are: 98, 100,
196, 200, 300, 391, and 400 pixels/inch.
See Section 2.2.2 for inch-metric equivalency.
No default, must be specifiedYResolution is the vertical version. In pixels per inch, the allowed values are 98, 100, 196, 200, 300, 391, and 400. Same deal: check Section 2.2.2 for the conversions, and there's no default so it has to be set 🦋
NOTE: The values 100, 200, and 391 were added to the historical TIFF-F list to match [T.30]. Some existing TIFF-F implementations might also support 77 and 38.5 (cm), which equal 196 and 98 pixels per inch. See section 4.5.2 for more on implementation details.
NOTE: Not every combination of XResolution, YResolution, and ImageWidth is legal. The table below shows the legal combinations and the matching paper sizes [T.30].
+--------------+-----------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------+-----------------+---------+--------+--------+
| 200x100, 204x98 | | | |
| 200x200, 204x196 | 1728 | 2048 | 2432 |
| 204x391 | | | |
+--------------+-----------------+---------+--------+--------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------+-----------------+---------+--------+--------+
| 408 x 391, 400 x 400 | 3456 | 4096 | 4864 |
+--------------+-----------------+---------+--------+--------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+4.2.2. Extension fields 🧚
T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1) LONG
RequiredTIFFExtension (when Compression = 3)
T4Options was also known as Group3Options in a prior version of
[TIFF].
Bit 0 = 1 indicates MR encoding, = 0 indicates MH encoding.
Bit 1 must be 0
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned
Default is all bits are 0 (applies when MH encoding is used and EOLs
are not byte aligned EOLs) (See Section 3.2.2.)T4Options is required whenever Compression is 3. It tells you which encoding is in use (MH or MR) and whether the EOL codes are byte-aligned. Bit 0 set to 1 means MR, and 0 means MH. Bit 1 has to be 0. Bit 2 set to 1 means the EOLs are byte aligned, and 0 means they aren't. The default is all bits 0, which covers MH encoding with EOLs that aren't byte aligned (see Section 3.2.2).
The T4Options field is required when the Compression field has a
value of 3. This field specifies the encoding used (MH or MR) and
whether the EOL codes are byte-aligned or not. If they are byte
aligned, then fill bits have been added as necessary so that the End
of Line (EOL) codes always end on byte boundaries See Sections 3.4,
4.5.3 and 4.5.4 for details.When the codes are byte aligned, fill bits get added as needed so the End of Line (EOL) codes always finish on byte boundaries. For the details, check Sections 3.4, 4.5.3 and 4.5.4 🫶
T6Options(293) = (Bit 0 = 0, Bit 1 = 0). LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified Read
compression. T6Options was also known as Group4Options in a prior
version of [TIFF].
Bit 0 must be 0.
Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
indicates uncompressed data is allowed (see [TIFF]).
Default is all bits 0. For FAX, the field must be present and have
the value 0. The use of uncompressed data where compression would
expand the data size is not allowed for FAX.T6Options is for the 2D MMR compression setup, and it used to be called Group4Options in an older [TIFF]. Bit 0 has to be 0. Bit 1 set to 0 means uncompressed data mode isn't allowed, and 1 means it is (see [TIFF]). The default is all bits 0. For FAX the field has to show up and be 0, and uncompressed data isn't allowed for FAX anywhere it would make the data bigger 💀
NOTE: MMR compressed data is two-dimensional and doesn't use EOLs. Every MMR encoded image MUST include an "end-of-facsimile-block" (EOFB) code at the end of each coded strip. See Section 4.5.6.
4.2.3. New fields 🌸
None.
4.3. Recommended TIFF fields 💜
4.3.1. Baseline fields
See Section 2.2.3.
4.3.2. Extension fields
See Section 2.2.3.
4.3.3. New fields 🔥
There are three new optional fields that the original TIFF-F description used to describe page quality, and they're defined in this spec too. The info in them usually comes from the receiving fax hardware, when that applies. They SHOULD NOT be used in TIFF-F files for fax image data that's error corrected or guaranteed to have no coding errors. Some apps really need to know the exact error content of the data. For example, a CAD program might want to confirm a file has a low error level before it gets imported into a high-accuracy document 🧐 Group 3 fax devices don't always do error correction on the image data, so the quality of a received page has to be inferred from the pixel count of decoded scan lines. A "good" scan line is one that, once decoded, has the correct number of pixels. A "bad" scan line is one that, once decoded, has an incorrect number of pixels.
BadFaxLines(326) SHORT or LONG
The number of "bad" scan lines encountered by the facsimile device
during reception. A "bad" scanline is defined as a scanline that,
when decoded, comprises an incorrect number of pixels. Note that
PercentBad = (BadFaxLines/ImageLength) * 100
No default.BadFaxLines is how many "bad" scan lines the fax device ran into while receiving. A bad scan line is one that, when decoded, has the wrong number of pixels. Note that PercentBad = (BadFaxLines/ImageLength) * 100. No default.
CleanFaxData(327) = 0, 1, 2. SHORT
Indicates if "bad" lines encountered during reception are stored in
the data, or if "bad" lines have been replaced by the receiver.
0 = No "bad" lines
1 = "bad" lines exist, but were regenerated by the receiver,
2 = "bad" lines exist, but have not been regenerated.
No default.CleanFaxData tells you whether the "bad" lines from reception are still in the data or whether the receiver swapped them out. 0 means there are no bad lines. 1 means bad lines existed but the receiver regenerated them. 2 means bad lines existed and haven't been regenerated. No default.
NOTE: Lots of fax devices don't actually output bad lines. They just repeat the previous good line in place of a bad one. This is called line regeneration, and it makes the image look better, but the data is still corrupted 😭 CleanFaxData tells you the error content. So if BadFaxLines and ImageLength show the device hit lines with the wrong pixel count, CleanFaxData tells you whether those bad lines are still in the data or were replaced with regenerated ones.
ConsecutiveBadFaxLines(328) LONG or SHORT
Maximum number of consecutive "bad" scanlines received. The
BadFaxLines field indicates only the quantity of bad lines.
No Default.ConsecutiveBadFaxLines is the longest run of "bad" scanlines received in a row. BadFaxLines only tells you how many bad lines there were, not how they're spread out. No default.
NOTE: BadFaxLines and ImageLength only give you the quantity of bad lines. ConsecutiveBadFaxLines shows how the bad lines are distributed, so it can be a better overall signal of how the image looks to a person. See Section 4.4.5 for examples of using these fields.
4.4. Technical Implementation Issues 🔥
4.4.1. Strips ✨
okay so, TIFF files usually chop an image into "strips," which people also call "bands" 🎀. Each strip holds a few scanlines of the image. Because of that, a TIFF reader doesn't have to load the entire image into memory. It can fetch and decompress just the small random bits it needs 💖.
The number of scanlines in a strip is described by the RowsPerStrip value, and the number of bytes in the strip after compression is described by the StripByteCount value. The location of each strip in the TIFF file is given by the StripOffsets values 🧚.
Strip size is application dependent 💅. The recommended approach for multi-page TIFF-F images is to represent each page as a single strip. Existing TIFF-F usage is typically one strip per page in multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3 🦋.
4.4.2. Bit Order 🌈
the current TIFF spec [TIFF] does not require a Baseline TIFF reader to support FillOrder=2, which means the lowest numbered 1-bit pixel sits in the least significant bit of a byte. It also recommends that FillOrder=2 only be used in special purpose applications 🙈.
Here's the tea: facsimile data shows up on the phone line in bit-reversed order compared to how ITU-T Recommendation T.4 describes it. So a wide majority of facsimile apps pick this natural order for data in a file 📠. Nevertheless, TIFF-F readers must be able to read data in both bit orders and support FillOrder values of 1 and 2 💜.
4.4.3. Multi-Page 📄
Lots of existing apps already read TIFF-F-like files, but they don't support the multi-page field. A multi-page format makes file management in fax software so much easier, so TIFF-F specifies multi-page documents (NewSubfileType = 2) as the standard case 👑.
It is recommended that applications export multiple page TIFF-F files without manipulating fields and values. Historically, some TIFF-F writers tried to make individual single-page TIFF-F files with modified NewSubFileType and PageNumber (page one-of-one) values for export. However, there is no easy way to link those multiple single-page files back together into one logical multiple-page document, so this practice is not recommended 😭.
4.4.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 [T.4] defines a one-dimensional compression method known as Modified Huffman (MH), and a two-dimensional method known as Modified READ (MR). (READ is short for Relative Element Address Designate.) In 1984, a somewhat more efficient compression method known as Modified Modified READ (MMR) was defined in the ITU-T T.6 Recommendation [T.6]. MMR was originally defined for use with Group 4 facsimile, so this compression method has commonly been called Group 4 compression. In 1991, the MMR method was approved for use in Group 3 facsimile, and it has been widely used ever since ✨.
TIFF-F supports these three compression methods. The most common practice is the one-dimensional Modified Huffman (MH) method 💖. This is specified by setting the Compression field value to 3 and then setting bit 0 of the T4Options field to 0. Alternatively, the two-dimensional Modified READ (MR) method, which is way less common in historical TIFF-F implementations, can be selected by setting bit 0 of the T4Options field to 1. The value of Bit 2 in this field is determined by the use of fill bits 🧠.
Depending on the application, the more efficient two-dimensional Modified Modified READ (MMR) compression method from T.6 may be selected by setting the Compression field value to 4 and then setting the first two bits (and all unused bits) of the T6Options field to 0 🔥. More info to help the implementor pick a compression method is in Section 4.5.2 🫶.
Baseline TIFF also permits use of Compression=2 to specify Modified Huffman compression, but the data does not use EOLs. As a result, TIFF-F uses Compression=3 instead of Compression=2 to specify Modified Huffman compression 🙅♀️.
4.4.5. Example Use of Page-quality Fields 📊
Here are examples for writing the CleanFaxData, BadFaxLines, and ConsecutiveBadFaxLines fields 🍓:
- Facsimile hardware does not provide 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
BadFaxLinesandConsecutiveBadFaxLines. Also writeCleanFaxData = 1or2if the hardware's regeneration capability is known. - Source image data stream is error-corrected or otherwise guaranteed to be error-free, such as for a computer generated file: SHOULD NOT write page-quality fields.
TIFF Writers SHOULD only generate these fields when the image has been generated from a fax image data stream where error correction (e.g. Group 3 Error Correction Mode) was not used. 🚨
4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F Files 📚
Traditionally, historical TIFF-F has required readers and writers to be able to handle multi-page TIFF-F files. Based on the experience of various TIFF-F implementors, it's been seen that implementing TIFF-F can get way simpler if certain practical guidelines are followed when writing multi-page TIFF-F files 🧃.
The structure for a multi-page TIFF-F file includes one IFD per page of the document. In this case, that IFD defines the attributes for a single page. A second simplifying guideline is that the writer of TIFF-F files SHOULD present IFDs in the same order as the actual sequence of pages. (Pages are numbered within TIFF-F starting with page 0 as the first page, then ascending: 0, 1, 2,....) However, any field values over 4 bytes will be stored separately from the IFD. TIFF-F readers SHOULD expect IFDs to be presented in page order, but be able to handle exceptions 🎀.
Per [TIFF], the exact placement of image data is not specified. However, the strip offsets for each strip of image are defined from within each IFD. Where possible, another simplifying guideline for writing TIFF-F files is to specify that the image data for each page of a multi-page document SHOULD be contained within a single strip (i.e. one image strip per fax page). Using one image strip per page is super useful for things like store and forward messaging, where the file is usually prepared before transmission. Other assumptions may apply to the size of the image strip for applications that need "streaming" techniques (see section 4.4.7). If a different image strip size guideline has been used (e.g. constant size for image strips that may be less than the page size), this will be immediately obvious from the values/offsets of the strip-related fields 👀.
A third simplifying guideline is that each IFD SHOULD be placed in the TIFF-F file structure at a point that precedes the image the IFD describes 🧚♀️.
In addition, a fourth simplifying guideline for TIFF-F writers and readers is to place the actual image data in a physical order within the TIFF file structure that is consistent with the logical page order. In practice, 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 presented in logical page order 💅.
If the image data is stored in multiple strips, then the strips SHOULD occur in the file in the same order that the data they contain occurs in the facsimile transmission, starting at the top of the page 🌸.
TIFF-F writers MAY make a fifth simplifying guideline, in which the IFD, the value data, and the image data that the IFD has offsets to all precede the next image IFD. However, this guideline has been relaxed (writers MAY rather than SHOULD use it) compared to the other guidelines given here, to reflect past practices for TIFF-F ⭐.
In the case of the minimal mode, which is also the minimal subset of Profile S, the SHOULD's and MAY's of these guidelines become SHALL's (see Section 3.5). Yep, the vibe shifts there 💀.
So, a TIFF-F file structured using the guidelines in this section will essentially be a linked list of IFDs, presented in ascending page order, each of which points to a single page of image data (one strip per page). The pages of image data are also placed in a logical page order within the TIFF-F file structure. (The pages of image data may themselves be stored contiguously, at the option of the implementor 🧩.)
4.4.7. Use of TIFF-F for Streaming Applications 🌊
TIFF-F has historically been used for handling fax image files in applications like store and forward messaging, where the entire size of the file is known in advance. TIFF-F may also possibly be used as a file format for streaming applications. However, assumptions may be required that differ from those provided in this section (e.g., the entire size and number of pages within the image are not known in advance). As a result, a definition for the streaming application of TIFF-F is beyond the scope of this document 🙃.
4.5. Implementation Warnings ⚠️
4.5.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. This means that the "Uncompressed" bit in T4Options or T6Options must be set to 0. Don't skip this one, bestie 💖.
4.5.2. Encoding and Resolution
okay so two-dimensional encoding isn't needed for Group 3 compatibility 💅, which means some historic TIFF-F readers couldn't read those files 😭. The minimum subset of TIFF-F REQUIRES support for one dimensional (Modified Huffman) files, so this choice maximizes portability ✨. However, implementors seeking greater efficiency SHOULD use T.6 MMR compression when writing TIFF-F files. Some TIFF-F readers will also support two-dimensional Modified READ files. Implementors that wish to have the maximum flexibility in reading TIFF-F files should support all three of these compression methods (MH, MR and MMR) 🦋.
For resolution, almost all facsimile products support both standard (98 dpi) vertical resolution and "fine" (196 dpi) resolution 🌸. Therefore, fine-resolution files are quite portable in the real world 💖.
In 1993, the ITU-T added support for higher resolutions in the T.30 recommendation, including 200 x 200, 300 x 300 and 400 x 400 in dots per inch based units 🧚. At the same time, support was added for metric dimensions that are equivalent to the following inch based resolutions: 391v x 204h and 391v x 408h 📏. Therefore, the full set of inch-based equivalents of the new resolutions is supported in the TIFF-F writer, since they may appear in some image data streams received from Group 3 facsimile devices. However, many facsimile terminals and older versions of TIFF-F readers are likely to not support the use of these higher resolutions 🙈.
Per [T.4], it's permissible for applications to treat the following XResolution values as being equivalent: <204,200> and <400,408> 🎀. In a similar respect, the following YResolution values may also be treated as being equivalent: <98, 100>, <196, 200> and <391, 400> ✨. These equivalencies were allowed by [T.4] so that conversions between inch and metric based facsimile terminals could happen 💜.
In a similar respect, the optional support of metric based resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for completeness, since they're used in some legacy TIFF-F applications 🍓. But this use is not recommended for the creation of TIFF-F files by a writer 🥺.
4.5.3. EOL byte-aligned
the historical convention for TIFF-F has been that all EOLs in Modified Huffman or Modified READ data have to be byte-aligned 🌈. Baseline TIFF has allowed non-byte-aligned EOLs by default, though, so a large percentage of TIFF-F reader implementations support both conventions 🙌. Therefore, the minimum subset of TIFF-F, or Profile S, as defined in Section 3, includes support for both byte-aligned and non-byte-aligned EOLs; see Section 3.2.2 💅.
An EOL is said to be byte-aligned when Fill bits have been added as necessary before EOL codes, so that EOL always ends on a byte boundary. This gives you an EOL-sequence of a one byte preceded by a zero nibble: xxxx0000 00000001 ✨.
Modified Huffman encoding encodes bits, not bytes 🧠. This means the end-of-line token can end in the middle of a byte. In byte alignment, extra zero bits (Fill) are added so that the first bit of data following an EOL begins on a byte boundary. In effect, byte alignment saves application software from having to bit-shift every byte while parsing scan lines for line-oriented image manipulation (such as writing a TIFF file) 🫶.
For Modified READ encoding, each line is terminated by an EOL and a one bit tag bit 🦋. Per [T.4], the value of the tag bit is 0 if the next line contains two dimensional data, and 1 if the next line is a reference line 👑. To maintain byte alignment, fill bits are added before the EOL/tag bit sequence, so that the first bit of data following an MR tag bit begins on a byte boundary ⭐.
4.5.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 💀. In a similar respect, images encoded with Modified READ two-dimensional encoding begin with an EOL, followed by a tag bit 🌸.
4.5.5. RTC Exclusion
aside from EOLs, TIFF-F files have historically only contained image data 📸. This means applications that want strict conformance with the rules in [TIFF], and compatibility with historical TIFF-F, SHOULD NOT include the Return To Control sequence (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files 🙅♀️. However, applications that need to support "transparency" of [T.4] image data MAY include RTCs if the flag settings of the T4Options field are set for non-byte aligned MH or MR image data 🔥. Implementors of TIFF readers should also be aware that some existing TIFF-F implementations include the RTC sequence in MH/MR image data 👀. Therefore, TIFF-F readers MUST be able to process files that do not include RTCs, and SHOULD be able to process files that do include RTCs 💅.
Heads up bestie: the RTC is 6 consecutive EOLs, so readers have to handle both files that have it and files that don't 🫣.
4.5.6 Use of EOFB for T.6 Compressed Images
TIFF-F pages that are 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 🧹.
4.6. Example Use of TIFF-F
the Profile F of TIFF (i.e. TIFF-F content) is a secondary component of the VPIM Message, as defined in [VPIM2] 📬. Voice messaging systems can often handle fax store-and-forward capabilities in addition to traditional voice message store-and-forward functions 🎙️. As a result, TIFF-F fax messages can optionally be sent between compliant VPIM systems, and may be rejected if the recipient system can't deal with fax 📠.
Refer to the VPIM Specification for proper usage of this content 🌈.
4.7. Extended Black-and-white Fax Mode Summary ✨
okay so this is the cheat sheet, bestie 📋💖 anything with a single asterisk * is recommended, so you should totally do it 🫶
the double asterisk ** marks the stuff that's required. if the ** is on the field name, then every listed value is required for implementations 💅 if the ** is in the Values column instead, only the values with a ** next to them are required, and everything else is optional vibes 🦋
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 3**: 1D Modified Huffman and |
| | 2D Modified Read coding |
| | 4: 2D Modified Modified Read |
| | coding |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+------------------------------------------------------------+
+------------------------------------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image. |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048, 2432, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType | 2**: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1** |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+
| T4Options | 0**: required if Compression |
| | is Modified Huffman, EOLs are |
| | not byte aligned |
| | 1: required if Compression is |
| | 2D Modified Read, EOLs are |
| | not byte aligned |
| | 4**: required if Compression |
| | is Modified Huffman, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| T4Options (continued) | 5: required if Compression |
| | is 2D Modified Read, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| T6Options | 0: required if Compression is |
| | 2D Modified Modified Read |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| BadFaxLines* | number of "bad" scanlines |
| | encountered during reception |
+---------------------------+--------------------------------+
| CleanFaxData* | 0: no "bad" lines |
| | 1: "bad" lines exist, but were |
| | regenerated by receiver |
| | 2: "bad" lines exist, but have |
| | not been regenerated |
+---------------------------+--------------------------------+
| ConsecutiveBadFaxLines* | Max number of consecutive |
| | "bad" lines received |
+---------------------------+--------------------------------+5. Lossless JBIG Black-and-white Fax Mode 🎀
okay this section is all about Profile J of TIFF for facsimile 📠✨ it's the lossless JBIG black-and-white mode, and if you're implementing it, you also have to implement Profile S 💅 that's the rule, no cap
the last section covered the extended interchange set for black-and-white fax, which gave us MH, MR and MMR compression 🧚 this one adds a new mode with JBIG compression, so it's like a glow-up 🌸
5.1. Overview
this section describes a black-and-white mode that uses JBIG compression 🦋 the ITU-T approved the single-progression sequential mode of JBIG [T.82] for Group 3 facsimile, and JBIG coding is lowkey amazing for halftoned originals 🔥 JBIG compression gets used following the application rules in ITU-T Rec. T.85 [T.85] 💜
basically this mode is the extended black-and-white mode, but with JBIG compression swapped in for MH, MR or MMR 🫶
5.2. Required TIFF Fields
this part lists the required fields and the values they must have to be ITU-compatible 💖 on top of the fields from Section 2.2.1, the extended black-and-white fax mode needs the following fields 🎀
5.2.1. Baseline fields
the TIFF fields that SHALL be used in this mode are the same ones described in Section 4.2.1 for the extended black-and-white mode 💅 there are two exceptions though: the text below replaces what Section 4.2.1 says for the Compression and FillOrder fields 👑
Compression(259) = 9. SHORT
RequiredByTIFFBaseline
9 = ITU-T Rec. T.82 coding, applying ITU-T Rec. T.85 (JBIG). This is
a TIFF extension value.
Default = 1 (and is not applicable; field must be specified).
FillOrder(266) = 2. SHORT
RequiredByTIFFBaseline
2 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the lower-order bits of the bytes, i.e.,
least significant bit first (LSB).NOTE: the JBIG coding of black-and-white image data in Profile J follows ITU-T Rec. T.85 [T.85], and that spec says LSB first ordering within a byte 🙈 also, Baseline TIFF readers are only required to support MSB first ordering or FillOrder = 1, so keep that in mind, bestie ✨
5.2.2. Extension fields
same fields as the ones in Section 2.2.1 🍓
5.2.3. New fields
none 🌈
5.3. Recommended TIFF Fields
check out Section 2.2.3 and 2.2.4 for these 🦋💜
5.4. Lossless JBIG Black-and-white Fax Mode Summary
Okay bestie, here's the cheat sheet 🧚 Fields with a * next to them are recommended ✨. Fields with a ** are required 💅. If the ** is on the field name, then every listed value is required of implementations. If the ** is in the Values column, only the values with a ** after them are required.
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 9**: JBIG coding |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image. |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048, 2432, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+------------------------------------------------------------+
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 1 |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number of bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of document |
| | scanned |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | IFD: global parameters IFD |
+---------------------------+--------------------------------+
| ProfileType* | n: type of data stored in file |
+---------------------------+--------------------------------+
| FaxProfile* | n: ITU-compatible fax mode |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used |
| | in file |
+---------------------------+--------------------------------+6. Base Color Fax Mode 🌈
6.1. Overview
This section is all about the lossy color mode, also known as Profile C of TIFF for facsimile 🎀 Implementations of this profile are required to also implement Profile S.
This is the base mode for color and grayscale fax, so every app that does color fax has to support it 💖 The core idea is lossy JPEG compression [T.4, Annex E; T.81] applied to L*a*b* color data [T.42]. Grayscale apps only need the L* lightness component, while color apps use L*, a* and b* together 🦋
This mode uses a brand new PhotometricInterpretation field value to describe the L*a*b* encoding in [T.42] ✨ It's different from the other L*a*b* encodings used in TIFF [TIFF, TTN1] in two ways. First, it uses a different default range for the a* and b* components, based on a big evaluation of existing hardcopy output. Second, it optionally lets you pick a selectable range for the L*, a* and b* components 🧚
6.2. Required TIFF Fields
This section lists the required fields, which are on top of the ones in Section 2.2.1, plus the values they must support so they're compatible with ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4 💅
6.2.1. Baseline Fields
ImageWidth(256). SHORT or LONGThis mode supports these fixed page widths: 864, 1024, 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864 📏
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAXBit 1 is 1 if the image is a single page of a multi-page document 📄 The default is 0, which means no subfile bits are on, so you can't leave this field out for fax 🙈
BitsPerSample(258) = 8, 12. SHORT
Count = SamplesPerPixelBase color fax mode requires 8 bits per sample, and 12 is an option 🌸 Just know that 12 bits per sample is not baseline TIFF, so keep that in mind 👀
Compression(259) = 7. SHORTBase color fax uses Baseline JPEG compression. The value 7 stands for JPEG compression as specified in [TTN2] 🫶
FillOrder(266) = 1 , 2. SHORT
RequiredByTIFFBaselineProfile C readers must be able to read data in both bit orders 🔄 But honestly? Most fax products store data LSB first, which is exactly how it shows up on the telephone line 📞
1= Most Significant Bit first.2= Least Significant Bit first.
PhotometricInterpretation(262) = 10. SHORTBase color fax mode requires pixel values to be stored using the CIE L*a*b* encoding defined in ITU-T Rec. T.42 🌈 This encoding is marked by PhotometricInterpretation value 10, which people call ITULAB. With this encoding, the minimum sample value maps to 0, and the maximum sample value maps to (2^n - 1), which is the maximum value, where n is the BitsPerSample value 💜 The conversion from unsigned ITULAB-encoded sample values to signed CIE L*a*b* values is decided by the Decode field, so check Sec. 6.2.3 for that 🧩
NOTE: PhotometricInterpretation values 8 and 9 are encodings for 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1] data. They're fixed encodings, though, and they use different minimum and maximum samples than the T.42 default encoding. As currently defined, they can't represent fax-encoded L*a*b* data 🙅♀️
ResolutionUnit(296) = 2, 3. SHORTThis is the unit of measure for resolution. 2 means inch and 3 means centimeter. The default is 2, and the field can be omitted if that's the value 📐
SamplesPerPixel(277) = 1, 3. SHORT1: L* component only, required in base color mode.3: L*, a*, b* components.- Encoded according to the PhotometricInterpretation field.
XResolution(282) = 100, 200, 300, 400. RATIONAL
YResolution(283) = 100, 200, 300, 400. RATIONALThe image resolution is written as pixels per resolution unit. In pixels per inch, the allowed XResolution values are 100, 200, 300, and 400 ✨ Base color fax mode needs the pixels to be square, so YResolution has to equal XResolution 🔲 The base resolution is 200 pixels per inch, and it SHALL be supported by every implementation of this mode 🎯 Check Section 2.2.2 for the inch-metric equivalency 🔍
NOTE: Not every combination of XResolution, YResolution and ImageWidth is legal 🙃 The table below shows the legal combos for inch-based resolutions, plus the paper sizes they match up with [T.30] 📄
+--------------------------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------------------------+---------------------------+
| 100 x 100 | 864 | 1024 | 1216 |
+--------------------------------+---------------------------+
| 200 x 200 | 1728 | 2048 | 2432 |
+--------------------------------+---------------------------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------------------------+---------------------------+
| 400 x 400 | 3456 | 4096 | 4864 |
+--------------------------------+---------------------------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------------------------+
| Paper Size |
+---------------------------+6.2.2 Extension Fields
The JPEG compression standard lets the a*b* chroma components of an image get subsampled relative to the L* lightness component 🍑 The extension fields ChromaSubSampling and ChromaPositioning define that subsampling 🎀 They match YCbCrSubSampling and YCbCrPositioning in [TIFF], but they got renamed so they fit other color setups too 💖
ChromaSubSampling is field 530, and it's a SHORT with Count = 2 🧚 This is the one that controls how much chroma gets subsampled for an L*a*b* image 🎀 It has two subfields, ChromaSubsampleHoriz and ChromaSubsampleVert, which hold the horizontal and vertical subsampling factors.
ChromaSubSampling(530). SHORT
Count = 2Here are the values for each subfield, bestie 💅
SHORT 0: ChromaSubsampleHoriz = 1, 2.
1: equal numbers of lightness and chroma samples horizontally,
2: twice as many lightness samples as chroma samples horizontally,
SHORT 1: ChromaSubsampleVert = 1, 2.
1: equal numbers of lightness and chroma samples vertically,
2: twice as many lightness samples as chroma samples vertically,The default is (2,2), which is the same chroma subsampling default used for color fax [T.4, Annex E] 🌸 Not subsampling at all, ChromaSubSampling = (1,1), is also an option for color fax 🦋
ChromaPositioning is field 531 and it's a SHORT set to = 1 ✨ It tells you where the chroma components sit spatially compared to the lightness component. Only one value is defined here:
1: centered,A value of 1 means the chrominance samples are spatially offset and centered with respect to the luminance samples. For more info, check the current TIFF spec under YcbCr positioning 🧚 The default is Default = 1, which is exactly what ITU-T T.4, Annex E specifies. Literally iconic 👑
6.2.3. New Fields ✨
Decode is field 433, it's an SRATIONAL, and its Count = 2 * SamplesPerPixel 💜 It describes how to map image sample values into the range of values that fits the current color space. The values come in pairs, and each pair gives the minimum and maximum output value for one color component. For the base color fax mode, Decode has a count of 6 values. It maps the unsigned ITULAB-encoded sample values (Lsample, asample, bsample) to signed L*a*b* values, like this:.
L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)So Decode[0], Decode[2] and Decode[4] are the minimums for L*, a* and b*, and Decode[1], Decode[3] and Decode[5] are the maximums. The n here is BitsPerSample, which is either 8 or 12 🎀 For example, when n=8, L* equals Decode[0] when Lsample=0, and L* equals Decode[1] when Lsample=255 🙈
ITU-T Rec. T.42 describes the ITULAB encoding using a range and an offset for each component. Those are related to the minimum and maximum values like this:
minimum = - (range x offset) / 2^n - 1
maximum = minimum + rangeThe Decode default values depend on the color space ✨ For the ITULAB color space encoding, the defaults match the base range and offset from ITU-T Rec. T.42 [T.42]. The table below shows those base values for BitsPerSample=8 and 12, along with the matching default minimum and maximum Decode values, calculated with the equations above when PhotometricInterpetation=10 💖
+-----------------------------------------------+
| ITU-T Rec. T.42 | Decode |
+---------+-----------| base values | default values |
| BitsPer + Component +------------------+----------------------------+
| -Sample | | Range | Offset | Min | Max |
+---------+-----------+--------+---------+--------------+-------------+
| 8 | L* | 100 | 0 | 0 | 100 |
| +-----------+--------+---------+--------------+-------------+
| | a* | 170 | 128 | -21760/255 | 21590/255 |
| +-----------+--------+---------+--------------+-------------+
| | b* | 200 | 96 | -19200/255 | 31800/255 |
+---------+-----------+--------+---------+--------------+-------------+
| 12 | L* | 100 | 0 | 0 | 100 |
| +-----------+--------+---------+--------------+-------------+
| | a* | 170 | 2048 | -348160/4095 | 347990/4095 |
| +-----------+--------+---------+--------------+-------------+
| | b* | 200 | 1536 | -307200/4095 | 511800/4095 |
+---------+-----------+--------+---------+--------------+-------------+For example, when PhotometricInterpretation=10 and BitsPerSample=8, the default value for Decode is (0, 100, -21760/255, 21590/255, -19200/255, 31800/255) 🦋
6.3. Recommended TIFF Fields
Go check out Sections 2.2.3. and 2.2.4. 🌈
6.4 Base Color Fax Mode Summary
Fields marked as recommended get an asterisk *. Required fields or values get a double asterisk **. If the double asterisk sits on the field name, then every listed value is required of implementations 💅 If the double asterisks are in the Values column, then only the values with a double asterisk after them are required of implementations 🫶
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 8**: 8 bits per color sample |
| | 12: optional 12 bits/sample |
+---------------------------+--------------------------------+
| Compression** | 7: JPEG |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
+------------------------------------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image. |
+---------------------------+--------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048 |
| | 2432, 2592, 3072, 3456, 3648 |
| | 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single page|
| | of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 10**: ITULAB |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: LAB |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release number |
| | of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or bytes in |
| | TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning |
| | of file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 100, 200**, 300, 400 (written |
| | in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 100, 200**, 300, 400 |
| | (must equal XResolution) |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| ChromaSubSampling | (1,1), (2, 2)** |
| | (1, 1): equal numbers of |
| | lightness and chroma samples |
| | horizontally and vertically |
| | (2, 2): twice as many lightness|
| | samples as chroma samples |
| | horizontally and vertically |
+---------------------------+--------------------------------+
| ChromaPositioning | 1**: centered |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| Decode** | minL, maxL, mina, maxa, minb, |
| | maxb: minimum and maximum |
| | values for L*a*b* |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | IFD: IFD containing |
| | global parameters |
+---------------------------+--------------------------------+
| ProfileType* | n: type of data stored in |
| | TIFF file |
+---------------------------+--------------------------------+
| FaxProfile* | n: ITU-compatible fax mode |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms |
| | used in file |
+---------------------------+--------------------------------+
| VersionYear* | byte sequence: year of ITU std |
+---------------------------+--------------------------------+7. Lossless Color Mode
This section defines the lossless color mode, also called Profile L of TIFF for facsimile 🦋 Implementations of this profile are required to also implement Profiles S and C 👑
7.1. Overview
Okay bestie, this mode is defined in [T.43], and it uses JBIG to losslessly code three kinds of images 🌈: one-bit-per-color CMY, CMYK and RGB images, palettized (mapped) color images, and continuous tone color and grayscale images. The last two are multi-level and use the L*a*b* encoding from [T.42] ✨
7.1.1. Color Encoding
So this mode was called T.Palette while it was being developed, because one of its big upgrades was palette (mapped) color images 💅 Baseline TIFF only allows RGB color maps 🙈 but ITU-T Rec. T.43 requires L*a*b* color maps, using the encoding in ITU-T Rec. T.42. Palette color images use indices (bits per sample) of 12 bits or less, or optionally 13 to 16 bits, per [T.43].
Enabling T.43 color maps in TIFF needs the Indexed extension field from [TTN1] and PhotometricInterpretation value 10, which is defined in Section 6.2.1. Check out this table for the matching PhotometricInterpretation, SamplesPerPixel, BitsPerSample and Indexed values for each T.43 image type 🍓
+----------------------------------------------------------+
| Image Type |PhotometricIn| Samples | Bits Per | Indexed |
| |-terpretation| PerPixel | Sample | |
|------------+-------------+----------+----------+---------|
| RGB | 2=RGB | 3 | 1 | 0 |
+----------------------------------------------------------+
| CMY | 5=CMYK | 3 | 1 | 0 |
+------------+-------------+----------+----------+---------+
| CMYK | 5=CMYK | 4 | 1 | 0 |
+------------+-------------+----------+----------+---------+
| Palette | 10=ITULAB | 1 | n | 1 |
+------------+-------------+----------+----------+---------+
| Grayscale | 10=ITULAB | 1 | 8, 12 | 0 |
+------------+-------------+----------+----------+---------+
| Color | 10=ITULAB | 3 | 8, 12 | 0 |
+------------+-------------+----------+----------+---------+7.1.2. JBIG Encoding
T.43 uses the single-progression sequential mode of JBIG, which is defined in ITU-T Rec. T.82 🦋 JBIG is a bi-level compression method, so for multi-level images you break the image into a set of bit-planes and then JBIG-compress each bit-plane. For continuous tone color and grayscale images, Gray code conversion gets used too. That conversion is part of the data stream encoding, which means TIFF never sees it. Totally invisible to TIFF, iconic 👑
7.2. Required TIFF Fields
This section lists the required fields, on top of the ones in Section 2.2.1, along with the values they must have to be compatible with ITU-T Rec. T.43 💖
7.2.1. Baseline Fields
Here are the baseline fields you need to know about 🎀
ImageWidth(256). SHORT or LONG
Same page widths as the base color mode; see Section 6.2.1.
NewSubFileType(254) = (Bit 1=1). LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax)
BitsPerSample(258) = 1, 2-8, 9-16. SHORT
Count = SamplesPerPixel
RGB, CMY, CMYK: 1 bit per sample
Continuous tone (L*a*b*): 2-8 bits per sample, 9-12 bits optional
Palette color: 12 or fewer bits per sample, 13-16 bits optional
Note: More than 8 bits per sample is not baseline TIFF.ImageWidth uses the same page widths as the base color mode, so flip to Section 6.2.1 for those 📏 NewSubFileType is required by TIFF for fax, and bit 1 gets set to 1 when the image is one page out of a multi-page document. Its default is 0, which means no subfile bits are on, so you can't leave it out for fax 🙅♀️ BitsPerSample's count has to equal SamplesPerPixel. Anything above 8 bits per sample isn't baseline TIFF, so it's a whole different vibe 😭
ColorMap(320). SHORT
Count = 3 * number of sample valuesLossless color fax mode supports palette-color (indexed) images, where the single component value works as an index into a full color lookup table stored in the ColorMap field 🌸 The sample value gets encoded with however many bits the BitsPerSample value says. Per [T.43], the number of sample values can be less than 2*BitsPerSample, so the lookup table only needs as many entries as there are sample values. For palette-color images in this mode, the ITULAB encoding is supported with 8 bits per color map value, or optionally 12 bits 🧚 To use a color map, the TIFF Indexed field has to be present. TIFF orders the color map values so all the L values come first, then all the a* values, then all the b* values. T.43 does it differently, though, with a "chunky" ordering where the L*a*b* components of the first value come first, then those of the second value, and so on. So if you're pulling color map values out of a fax data stream into a TIFF file, you have to reorder them 🔥
Compression(259) = 10. SHORT
10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG)
codingCompression value 10 means the T.43 representation, coded with JBIG from ITU-T Rec. T.82 ✨
FillOrder(266) = 1 , 2. SHORT
RequiredByTIFFBaseline
Profile 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 firstProfile F readers have to handle data in both bit orders 💜 Still, most fax products store data LSB first, which is exactly how it shows up on the telephone line 📞
PhotometricInterpretation(262) = 2, 5, 10. SHORT
2: RGB
5: CMYK, including CMY
10: ITULABImage data can also be stored as palette color images, where each pixel value is one component that indexes into a color map that uses the ITULAB encoding 🌈 That color map lives in the ColorMap field. To use palette color, set PhotometricInterpretation to 10, SamplesPerPixel to 1, and Indexed to 1. See Section 7.1.1 for more on the color encoding 🦋
ResolutionUnit(296) = 2, 3. SHORT
The unit of measure for resolution. 2 = inch, 3 = centimeter;
Default = 2 (field may be omitted if this is the value)ResolutionUnit is the unit of measure for resolution. It's 2 for inch or 3 for centimeter, and the default is 2, so you can skip the field if that's the value 📐
SamplesPerPixel(277) = 1, 3, 4. SHORT
1: Palette color image, or L*-only if Indexed = 0 and
PhotometricInterpretation is 10 (ITULAB).
3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5 (CMYK).
4: CMYK.SamplesPerPixel can be 1 for a palette color image, or for L*-only when Indexed is 0 and PhotometricInterpretation is 10 (ITULAB). It's 3 for RGB, for L*a*b*, or for CMY when PhotometricInterpretation is 5 (CMYK). And it's 4 for CMYK 🍓
XResolution(282) = 100, 200, 300, 400. RATIONAL
YResolution(283) = 100, 200, 300, 400. RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values are: 100, 200,
300, and 400. The lossless color fax mode requires the pixels to be
square, hence YResolution must equal XResolution. Base resolution is
200 pixels per inch. See Section 2.2.2 for inch-metric equivalency.Resolution is expressed in pixels per resolution unit. In pixels per inch, XResolution can be 100, 200, 300, or 400 💖 This mode needs square pixels, so YResolution has to match XResolution. The base resolution is 200 pixels per inch, and Section 2.2.2 has the inch-to-metric conversion if you need it 📏
7.2.2. Extension Fields
Indexed(364) = 0, 1. SHORT
0: not a palette-color image
1: palette-color image
This field is used to indicate that each sample value is an index
into an array of color values specified in the ColorMap field.
Lossless color fax mode supports palette-color images with the
ITULAB encoding. The SamplesPerPixel value must be 1.Indexed is the flag that says whether each sample value is an index into an array of color values stored in ColorMap 🎀 A 0 means it's not a palette-color image, and a 1 means it is. This mode supports palette-color images with ITULAB encoding, and when it does, SamplesPerPixel has to be 1 🌸
7.2.3. New Fields
Decode(433) SRATIONALDecode goes along with ITULAB encoding of image data and color map values. Check Section 6.2.3 for the details 🧚
7.3. Recommended TIFF Fields
Just look at Sections 2.2.3. and 2.2.4. for the recommended fields 💅
7.4. Lossless Color Fax Mode Summary 🎀
okay so here's the cheat sheet for lossless color fax mode 💅 the recommended fields have an asterisk * next to them, so look for those first bestie ✨
+--------------------+--------------------------------------+
| Baseline Fields | Values |
+--------------------+--------------------------------------+
| BitsPerSample | 1: Binary RGB, CMY(K) |
| | 8: 8 bits per color sample |
| | 9-16: optional |
+--------------------+--------------------------------------+
| ColorMap | n: LAB color map |
+--------------------+--------------------------------------+
| Compression | 10: JBIG, per T.43 |
+--------------------+--------------------------------------+
| DateTime* | {ASCII}: date/time in the 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+--------------------+--------------------------------------+
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+--------------------+--------------------------------------+
| ImageDescription* | {ASCII}: A string describing the |
| | contents of the image. |
+--------------------+--------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+--------------------+--------------------------------------+
| ImageLength** | n: total number of scanlines in image|
+--------------------+--------------------------------------+
| NewSubFileType | 2: Bit 1 identifies single page of a |
| | multi-page document |
+--------------------+--------------------------------------+
| Orientation | 1**-8, Default 1 |
+--------------------+--------------------------------------+
| PhotometricInter- | 2: RGB |
| pretation | 5: CMYK |
| | 10: ITULAB |
+--------------------+--------------------------------------+
+--------------------+--------------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+--------------------+--------------------------------------+
| RowsPerStrip | n: number of scanlines per TIFF strip|
+--------------------+--------------------------------------+
| SamplesPerPixel | 1: L* (lightness) |
| | 3: LAB, RGB, CMY |
| | 4: CMYK |
+--------------------+--------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+--------------------+--------------------------------------+
| StripByteCounts | <n>: number or bytes in TIFF strip |
+--------------------+--------------------------------------+
| StripOffsets | <n>: offset from beginning of file to|
| | each TIFF strip |
+--------------------+--------------------------------------+
| XResolution | 100, 200, 300, 400 (written in |
| | pixels/inch) |
+--------------------+--------------------------------------+
| YResolution | equal to XResolution (pixels must be |
| | square) |
+--------------------+--------------------------------------+
| Extension Fields |
+--------------------+--------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+--------------------+--------------------------------------+
| PageNumber | n,m: page number followed by total |
| | page count |
+--------------------+--------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+--------------------+--------------------------------------+
| New Fields |
+--------------------+--------------------------------------|
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| |minimum and maximum values for L*a*b* |
+--------------------+--------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD* | |
+-----------------------------------------------------------+
+--------------------+--------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+--------------------+--------------------------------------+
| FaxProfile* | n: ITU-compatible fax mode |
+--------------------+--------------------------------------+
| CodingMethods* | n:compression algorithms used in |
| | file |
+--------------------+--------------------------------------+
| VersionYear* | byte sequence: year of ITU fax std |
+--------------------+--------------------------------------+8. Mixed Raster Content Mode 🌈
this section is all about the Mixed Raster Content mode, aka Profile M of TIFF for facsimile 🦋 implementations of this profile are required to implement Profiles S and C, and they may optionally implement Profiles F, J and L ✨
8.1. Overview 💖
okay so, unlike the older fax modes that use one coding method and one spatial resolution for a whole fax page, the Mixed Raster Content mode [T.44] lets you mix different coding methods and resolutions on the same page 🧚 like, imagine a page with black-and-white text (best coded with MMR or JBIG), a color bar chart (best coded with JBIG), and a scanned color photo (best coded with JPEG). and the resolution glow-up is real too: 400 pixels per inch might be best for the black-and-white text, but 200 pixels per inch is usually enough for a color image 🍓
MRC doesn't invent any new coding methods or resolutions, fr fr 💅 instead it gives you a 3-layer image model for structuring and combining the scanned image data. the MRC 3-layer model is applied here using the TIFF format, so the data structure is different from [T.44], even though it uses the same coding methods, the same compressed image data stream, and it still follows the TIFF rule of a single IFD per image 🫶
8.1.1. MRC 3-layer model 🔥
the 3 layers are Foreground and Background (both multi-level) and Mask (bi-level) 👑 each layer may appear only once on a page, and each one is coded independently of the other two. so in our earlier example, the black-and-white text could live in the Mask layer, the color chart in the Foreground layer, and the color image in the Background layer 🎀
each layer is an image, and when it's present it's represented by at least one IFD in a TIFF file 💜 this matches TIFF, which has fields for attributes like resolution, image size, bits per sample, etc. for a single image or layer. the writer decides how content gets split among the layers, and also picks the coding method, color encoding and spatial resolution for each layer ✨
the final image is made by using the Mask layer to pick pixels from the other two layers. when a Mask pixel value is 1, the matching pixel from the Foreground layer gets selected; when it's 0, the matching pixel from the Background layer gets selected 🦋 the details are in the Introduction of [T.44].
not every page, or every part of a page, needs all 3 layers 🌸 if only one layer is present, that layer is the primary image or IFD. if there's more than one layer, the Mask must be one of them, and in that case it's the primary image and it must be page size.
MRC lets a page be split into strips, and each strip can have a variable number of scanlines 😭 a strip can have 1, 2 or 3 layers. a single, stripped layer can be stored as one stripped image in one IFD, so all the strips for the Background layer can be treated as a single image. or, each strip for a layer can be stored as its own separate image or IFD, like when the Background is made of several images offset vertically on the page. in that case there can be no overlap between images belonging to the same layer. according to [T.4] Annex G, strips with more than 1 layer SHOULD NOT be more than 256 lines long unless the ability to receive longer strips has been negotiated 💀
and one more thing, bestie: color fax also needs the spatial resolutions of the Background and Foreground images to be legal fax values that are integer factors of the Mask image resolution 🙈 for example, if the Mask is at 400 pixels per inch, the Foreground and Background can be 100, 200 or 400 pixels per inch. if the Mask is at 300 pixels per inch, then only 100 and 300 are allowed. the Foreground and Background resolutions can be set independently of each other 👑🌈
8.1.2. A TIFF Representation for the MRC 3-layer model ✨
okay so in the TIFF version of the 3-layer MRC model, every page gets one IFD called the Primary IFD 🎀 It represents the Mask layer (unless the Foreground or Background is the only layer there). Then there's a set of child IFDs that hang off it through the SubIFDs extension field [TTN1]. To tell the MRC SubIFDs apart from regular SubIFDs, the NewSubFileType field MUST have Bit 4 ON 🦋 A brand-new ImageLayer field also shows up, with two values: one says which layer it is (Foreground, Background, or Mask), and the other says its order within that layer (first, second, ... image of the layer). See Section 8.2.3 for the details 💖
MRC allows strips with a variable number of scanlines, so a reader MUST support the StripRowCounts field 🫶 A writer might use it instead of RowsPerStrip in this mode. StripRowCounts lets each layer, with a different number of scanlines in each strip, be stored in a single IFD, as long as the coding parameters are the same for every strip in that layer. The MRC standard [T.44] lets the Foreground and Background layers have strips with different coding parameters. When that happens, a separate IFD is required for the strips that use different coding parameters. The next paragraph explains that more. Either way, the Mask layer is required to be stored in a single IFD with a single set of coding parameters 🌸
The SubIFDs approach is described in [TTN1], and here's how it looks in the example below 🧚 The Primary IFD for page 1 (PrimaryIFD 0) points to page 2 (PrimaryIFD 1) using the nextIFD offset. The Primary IFD for the Mask layer (ImageLayer=[2,1]) has a SubIFDs field that points to a list of child IFDs. The first child IFD is one image of the Background layer, ImageLayer=[1,1]. It points to the second child with the nextIFD offset, and that one is the second Background image, ImageLayer=[1,2]. The second child then points to the third child, which is the single Foreground image, ImageLayer=[3,1]. The nextIFD offset on that Foreground image is 0, which means there are no more child IFDs 💅 Every primary IFD has NewSubFileType set to 18. That means it's MRC-specific (bit 4) and it's a single page of a multi-page document (bit 1). Every child IFD has NewSubFileType set to 16, which means it's MRC-specific. The 'V' character should be read as a down-pointing arrow ⭐
(nextIFD)
PRIMARY IFD 0 ------------> PRIMARY IFD 1--> ...
ImageLayer = [2,1]
NewSubFileType = 18
SubIFDs
|
V
Child IFD
ImageLayer = [1,1]
NewSubFileType = 16
|
|(nextIFD)
|
V
Child IFD
ImageLayer = [1,2]
NewSubFileType = 16
|
|(nextIFD)
|
V
Child IFD
ImageLayer = [3,1]
NewSubFileType = 16
|
|(nextIFD)
V
0In that example, the SubIFDs field of the Primary IFD points to the first IFD in a list of child IFDs. TIFF lets the SubIFDs field point to an array of IFDs, and each of those can be the start of its own list of IFDs 🍓 An MRC-enabled TIFF reader must scan all the available child IFDs to find and identify the IFDs that belong to MRC layers. It's a whole detective situation 🕵️♀️
If the Background or Foreground layers are described with multiple IFDs, the XPosition and YPosition TIFF fields give the offset of each IFD's upper-left corner relative to the Mask layer. See Section 8.2.2 for those 🦋 When there's only one layer (Mask, Foreground, or Background), it gets stored as the Primary IFD 🌈
8.2. Required TIFF Fields
okay this section covers the TIFF fields needed on top of the ones in Section 2.2.1 to represent MRC mode fax images 💖 MRC mode stores fax data as a bunch of images, one for each layer or part of a layer. So the coding methods, color encodings, and spatial resolutions from the earlier modes all apply to MRC too. That's why the descriptions here will usually point back to the earlier section. Anything specific to MRC mode gets called out 🎀
8.2.1. Baseline Fields 🌸
ImageWidth(256).SHORT or LONG- Same page widths as the base color mode. See Section 6.2.1. In MRC mode, the width of a Foreground or Background image in the coded data stream may be less than the page width. When that happens, the image width in the coded data stream is used to interpret the coded data, and the value of this field is used as the page width.
NewSubFileType(254) = 16, 18.LONG- For MRC fax mode, NewSubFileType has two bits that are required 🔥
- Bit 1 indicates a single page of a multi-page document, and it must be set for the Primary IFD.
- Bit 4 indicates the MRC imaging model described in ITU-T Recommendation T.44 [T.44], and it must be set for Primary IFDs and all MRC-specific child IFDs.
- For MRC fax mode, NewSubFileType has two bits that are required 🔥
BitsPerSample(258) = 1, 2-8, 9-16SHORTCompression(259) = 3, 4, 7, 9, 10.SHORTSamplesPerPixel(277) = 1, 3, 4.SHORTFillOrder(266) = 1 , 2.SHORT- RequiredByTIFFBaseline
- Profile 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
ResolutionUnit(296) = 2, 3.SHORTPhotometricInterpretation(262) = 0, 1, 2, 5, 10.SHORT- For the Mask layer, see Sections 4.2.1 and 5.2.1.
- For the Foreground and Background layers, see Sections 6.2.1 and 7.2.1.
ColorMap(320).SHORTCount = 3 * (2**BitsPerSample)- Used when the Foreground or Background layer is a palette-color image. See Section 7.2.1.
XResolution(282) = 100, 200, 300, 400.RATIONALYResolution(283) = 100, 200, 300, 400.RATIONAL- The resolution of the image is expressed in pixels per resolution unit. In pixels per inch, the allowed XResolution values for all layers are 100, 200, 300, and 400 ✨
- MRC color fax mode requires the pixels to be square, so YResolution must equal XResolution for all layers 📐
- The resolution of the Background and Foreground layers must each be an integer factor of the Primary image, which is the Mask layer, when it's present. See Section 8.4.
- See Section 2.2.2 for the inch-metric equivalency 🍓
8.2.2. Extension Fields 🧚
ChromaSubSampling(530).SHORTChromaPositioning(531).SHORT- For the Foreground and Background layers, see Section 6.2.2.
Indexed(346) = 0, 1.SHORT- For the Foreground and Background layers: 1 indicates a palette-color image. See Section 7.2.2.
T4Options(292) = 0, 1, 4, 5.SHORTT6Options(293) = 0.SHORT- For the Mask layer, see Section 4.2.2.
SubIFDs(330).IFDCount = number of child IFDs- Each value is an offset from the beginning of the TIFF file to a child IFD [TTN1] 🌈
XPosition(286).RATIONALYPosition(287).RATIONAL- Specifies the horizontal and vertical offsets of the top-left of the IFD from the top-left of the Primary IFD, in page resolution units. For example, say the Primary IFD is at 400 pixels per inch, and a foreground layer IFD is at 200 pixels per inch and sits at pixel coordinate (345, 678) relative to the Primary IFD. Then the XPosition value is 345/400 and the YPosition value is 678/400 👑
- Color fax does not currently allow overlap of any component images within a single layer 🙈
- The default values for XPosition and YPosition are 0.
8.2.3. New Fields ✨
okay bestie, new fields unlocked 🎀 let's gooo.
Decode(433). SRATIONAL
For Foreground and Background layers, see Section 6.2.3. 🦋
DefaultImageColor(434). SHORT
Count = SamplesPerPixel
So like, in areas where there's no image data, you still need a default color so there's a color value to use 💅 If the StripByteCounts value for a strip is 0, then the color for that strip must be defined by a default image color. no cap, that's the main character moment for this field 👑
The DefaultImageColor field uses the same encoding as the image data, so its value gets read through the PhotometricInterpretation, SamplesPerPixel, BitsPerSample, and Indexed fields. ngl this is giving consistency 🌸 If the fax data stream needs a different encoding, then moving the default color value between a TIFF file and a fax data stream requires a color conversion. The default for the Foreground layer image is black 🖤 For other cases, including the Background layer image, the default is white ⭐
StripRowCounts(559). LONG
Count = number of strips
This one is so iconic 😭 It stores the number of scanlines in a strip. MRC lets each fax strip hold a different number of scanlines, and for strips with more than one layer there's a maximum strip size of 256 scanlines or the full page size. The 256 maximum SHOULD be used unless the capability to receive longer strips has been negotiated. This field replaces RowsPerStrip for IFDs with variable-sized strips. Only one of the two fields, StripRowCounts and RowsPerStrip, may be used in an IFD. periodt 💜
ImageLayer (34732). SHORT or LONG.
Count = 2
Okay, the layer setup is so satisfying 🧚 Layer 1 is the Background layer, layer 3 is the Foreground layer, and layer 2 is the Mask layer, which picks which pixels come from the Background and which come from the Foreground. The ImageLayer tag holds two values: which layer the image belongs to, and the order it gets imaged in.
ImageLayer[0] = 1, 2, 3.
1:Image is a Background image, i.e., the image that will appear whenever the Mask contains a value of 0. Background images typically contain low-resolution, continuous-tone imagery. 🌈2:Image is the Mask layer. In MRC, if the Mask layer is present, it must be the Primary IFD and be full page in extent (no gaps.) 🎀3:Image is a Foreground image, i.e., the image that will appear whenever the Mask contains a value of 1. The Foreground image generally defines the color of text or lines, but may also contain high-resolution imagery. 🔥
ImageLayer[1]:
1:first image to be imaged in this layer,2:second image to be imaged in this layer,3:...
This value describes the image order. In MRC, you can think of it as the strip number 💖 Since MRC mode doesn't currently allow overlap between images within a layer, the order value doesn't have any visual effect. ✨
In MRC fax mode, it's possible that only a single layer gets sent. Like, if a page only has one continuous-tone photograph, then only the Background layer may be transmitted 📸 In that case, the Background layer gets stored as the Primary IFD. ImageLayer[0] will be 1 (Background), and ImageLayer[1] will be 1 since there can't be any other IFDs tied to that layer. No Mask layer will exist. bestie, that's the whole vibe 🦋
8.3. Recommended TIFF Fields 🌸
See Sections 2.2.3. and 2.2.4.
8.4. Rules and Requirements for Images 💅
The MRC mode sets a basic set of rules for images in the 3-layer representation. These are the rules, no debate 👑
- If more than one layer exists, then the binary Mask layer SHALL be present and be the primary image. The Mask layer SHALL support the encoding defined in Section 3 and MAY support the encodings defined in Sections 4 and 5. If only one layer exists, then the image corresponding to that layer is the primary image. 🎀
- When the binary Mask layer is the Primary IFD, the Primary IFD defines and extends to the entire page boundary; all attached model images cannot extend beyond the Primary image. Resolution differences may cause some pixels to "hang over" the page boundary, but no new pixels should exist completely beyond the page extent. When the Foreground or Background layer is the Primary IFD, the Primary IFD may not be page width. 🌈
- The Background and Foreground images SHALL support the color encoding defined in Section 6 and MAY support the color encoding defined in Section 7. These images MAY optionally cover only a portion of the strip or page. 🧚
- Each Primary IFD and each MRC-specific SubIFD must have an
ImageLayerfield to specify which layer the IFD belongs to, and the imaging order of that IFD within the layer. ⭐ - Each Primary IFD must have a
NewSubFileTypefield value set to18, indicating a single page of a multi-page document (bit 1) and MRC mode (bit 4). 💜 - Each MRC-specific child IFD must have a
NewSubFileTypefield value set to16, indicating MRC mode (bit 4). 🫶 - In MRC mode, each layer is transmitted as a sequence of strips. It is possible that each strip of each layer can be stored as a separate IFD. In this case, the SubIFDs structure pointed to by the Primary IFD will contain several IFDs that have an
ImageLayerfield with the layer identified as either Background (layer 1) or Foreground (layer 3). There may be no overlap in the vertical direction between IFDs associated with a single layer, although there may be a gap from one of these images to the next. The TIFFXPositionandYPositionfields are used to indicate the placement of these images with respect to the primary image. 🦋 - When the Mask image is present, the resolution of Background and Foreground images must each be an integer factor of the Mask image. For example, if the Mask image is 400 pixels/inch, then the Background or Foreground image may be at 400 pixels/inch (400/1), 200 pixels/inch (400/2) or 100 pixels/inch (400/4). ✨
8.5. MRC Fax Mode Summary 💖
Okay bestie, here's the cheat sheet for MRC fax mode 📋 Fields marked with an asterisk * are the recommended ones, so those are the ones to prioritize 🧚
+------------------+-----------------------------------------+
| Baseline Fields | Values |
|------------------|-----------------------------------------|
| BitsPerSample | 1: binary mask |
| | 8: 8 bits per color sample |
| | 9-16: optional 12 bits/sample |
+------------------+-----------------------------------------+
| ColorMap | n: LAB color map |
+------------------+-----------------------------------------+
| Compression | 3: Modified Huffman and Modified Read |
| | 4: Modified Modified Read |
| | 7: JPEG |
| | 9: JBIG, per T.85 |
| | 10: JBIG, per T.43 |
+------------------+-----------------------------------------+
| DateTime* | {ASCII): date/time in the 24-hour format|
| | "YYYY:MM:DD HH:MM:SS" |
+------------------+-----------------------------------------|
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+------------------+-----------------------------------------|
| ImageDescription*| {ASCII}: A string describing the |
| | contents of the image. |
+------------------+-----------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+------------------+-----------------------------------------+
| ImageLength** | n: total number of scanlines in image |
+------------------+-----------------------------------------+
| NewSubFileType | 16, 18: |
| | Bit 1 indicates single page of a multi- |
| | page document on Primary IFD |
| | Bit 4 indicates MRC model |
+------------------+-----------------------------------------+
+------------------+-----------------------------------------+
| Orientation | 1**-8, Default 1 |
+------------------+-----------------------------------------+
| PhotometricInter | 0: WhiteIsZero |
| pretation | 1: BlackIsZero |
| | 2: RGB |
| | 5: CMYK |
| | 10: ITULAB |
+------------------+-----------------------------------------+
| ResolutionUnit | 2: inch |
| | 3: centimeter |
+------------------+-----------------------------------------+
| RowsPerStrip | n: number or scanlines per strip |
+------------------+-----------------------------------------+
| SamplesPerPixel | 1: L* (lightness) |
| | 3: RGB, LAB, CMY |
| | 4: CMYK |
+------------------+-----------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+------------------+-----------------------------------------+
| StripByteCounts | <n>: number or bytes in each strip |
+------------------+-----------------------------------------+
| StripOffsets | <n>: offset from beginning of file to |
| | each TIFF strip |
+------------------+-----------------------------------------|
| XResolution | 100, 200, 300, 400 (written in |
| | pixels/inch) |
+------------------+-----------------------------------------|
| YResolution | equal to XResolution (pixels must be |
| | square) |
+------------------+-----------------------------------------+
| Extension Fields |
+------------------+-----------------------------------------+
| T4Options | 0: required if Compression is Modified |
| | Huffman, EOLs not byte aligned |
| | 1: required if Compression 2D Modified |
| | Read, EOLs are not byte aligned |
| | 4: required if Compression Modified |
| | Huffman, EOLs byte aligned |
| | 5: required if Compression 2D Modified |
| | Read, EOLs are byte aligned |
+------------------+-----------------------------------------+
| T6Options | 0: required if Compression is 2D |
| | Modified Modified Read |
+------------------+-----------------------------------------+
+------------------+-----------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+------------------+-----------------------------------------+
| PageNumber | n,m: page number followed by total page |
| | count |
+------------------+-----------------------------------------+
| ChromaSubSampling| (1,1), (2, 2)** |
| | (1, 1): equal numbers of lightness and |
| | chroma samples horizontally & vertically|
| | (2, 2): twice as many lightness samples |
| | as chroma horizontally and vertically |
+------------------+-----------------------------------------+
| ChromaPositioning| 1: centered |
+------------------+-----------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+------------------+-----------------------------------------+
| SubIFDs | <IFD>: byte offset to fg/bg IFDs |
+------------------+-----------------------------------------+
| XPosition | horizontal offset in primary IFD |
| | resolution units |
+------------------+-----------------------------------------+
| YPosition | vertical offset in primary IFD |
| | resolution units |
+------------------+-----------------------------------------+
| New Fields |
+------------------+-----------------------------------------+
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| | minimum and maximum values for L*a*b* |
+------------------+-----------------------------------------+
| DefaultImageColor| <n>: background color |
+------------------+-----------------------------------------+
| StripRowCounts | <n>: number of scanlines in each strip |
+------------------+-----------------------------------------+
| ImageLayer | n, m: layer number, imaging sequence |
| | (e.g., strip number) |
+------------------+-----------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD* | |
+------------------+-----------------------------------------+
| ProfileType* | n: type of data stored in TIFF file |
+------------------+-----------------------------------------+
| FaxProfile* | n: ITU-compatible fax mode |
+------------------+-----------------------------------------+
| CodingMethods* | n: compression algorithms used in file |
+------------------+-----------------------------------------+
| ModeNumber* | n: version of ITU fax standard |
+------------------+-----------------------------------------+
+------------------------------------------------------------+
| VersionYear* | byte sequence: year of ITU fax standard |
+------------------+-----------------------------------------+9. MIME content-type image/tiff ✨
Now we're talking MIME 💌 [TIFF-REG] is the spot that registers the MIME content-type image/tiff for TIFF encoded image data 🎀 When TIFF gets sent over MIME, the TIFF content this document defines must be wrapped in an image/tiff content type 🫶 There's also an optional "application" parameter you can use with image/tiff to say which application's subset of TIFF (and TIFF extensions) the encoded image is using, but only if that's known 🧚 Usually that's there to help the recipient pick the right rendering package for displaying or processing the image file 💅
9.1. Refinement of MIME content-type image/tiff for Facsimile Applications ✨
okay so, this document defines facsimile-specific profiles of TIFF 💌 which means we need a proper application parameter for the image/tiff MIME content-type. it's giving organization 🎀
the two application parameter values defined for fax are:
faxbw, faxcolorthe faxbw parameter is for applications that can process one or more TIFF for facsimile profiles, or subsets, used to encode black and white fax data 🖤
the faxcolor parameter is for applications that can process one or more TIFF for facsimile profiles, or subsets, that can encode black and white, AND color fax data 🌈
since this document defines several fax profiles of TIFF, the following rules should be followed when setting the application parameter value 💅 the profiles that support black-and-white image data are Profiles S, F or J. if your TIFF image data is encoded for one of those, or a subset of one, set the parameter to faxbw. the profiles that support color image data, as well as black-and-white, are Profiles C, L or M. if your data is encoded for one of those, or a subset, set the parameter to faxcolor. easy peasy 🫶
here's an example of the image/tiff Content-type with faxbw set:
Content-type: image/tiff; application=faxbwwith this value, applications can tell that the content is within a fax profile or subset that's suitable for black and white image data, before they try to process the image data 🦋
and for a color profile or subset of TIFF for facsimile, here's the matching setting:
Content-type: image/tiff; application=faxcolor10. Security Considerations 🔐
okay bestie, this part is lowkey important 😭 this document describes a file format for Internet fax, which is a series of profiles of TIFF for facsimile. so it doesn't create any security issues that aren't already identified in [TIFF-REG], in its use of fields as defined in [TIFF]. there are also new TIFF fields defined in this specification, but they're purely descriptive in nature, so no new security risks are incurred 🛡️
and also, the encoding specified here does not in any way preclude the use of any Internet security protocol to encrypt, authenticate, or non-repudiate TIFF-encoded facsimile messages 🔒✨ so you can still lock it all down, periodt 💜
11. References 📚
- [REQ] Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
- [T.4] ITU-T Recommendation T.4, Standardization of group 3 facsimile apparatus for document transmission, October 1997
- [T.6] ITU-T Recommendation T.6, Facsimile coding schemes and coding control functions for group 4 facsimile apparatus, November 1988
- [T.30] ITU-T Recommendation T.30 - Procedures for Document Facsimile Transmission in the General Switched Telephone Network, June 1996
- [T.42] ITU-T Recommendation T.42, Continuous-tone colour representation method for facsimile, February 1996
- [T.43] ITU-T Recommendation T.43, Colour and gray-scale image representations using lossless coding scheme for facsimile, February 1997
- [T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC), October 1997.
- [T.81] ITU-T Recommendation T.81, Information technology - Digital compression and coding of continuous-tone still images - Requirements and guidelines, September 1992
- [T.82] ITU-T Recommendation T.82, Information technology - Coded representation of picture and audio information - Progressive bi-level image compression, March 1995
- [T.85] ITU-T Recommendation T.85, Application profile for Recommendation T.82 - Progressive bi-level image compression (JBIG coding scheme) for facsimile apparatus, August 1995
- [TIFF] Tag Image File Format, Revision 6.0, Adobe Developers Association, June 3, 1992,
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/tiff6.pdf
The TIFF 6.0 specification dated June 3, 1992 specification (c) 1986-1988, 1992 Adobe Systems Incorporated. All Rights Reserved.
- [TIFF-FY] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.
- [TIFF-F0] TIFF Class F specification, Apr 28, 1990,
ftp://ftp.faximum.com/pub/documents/tiff_f.txt - [TIFF-REG] Parsons, G., Rafferty J. and S. Zilles, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 2302, March 1998.
- [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995,
http://www.adobe.com/supportservice/devrelations/PDFS/TN/TIFFPM6.pdf - [TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG specification, March 17, 1995,
ftp://ftp.sgi.com/graphics/tiff/TTN2.draft.txt - [VPIM2] Vaudreui,l G. and G. Parsons, "Voice Profile for Internet Mail - version 2", work in progress,
<draft-ema-vpim-06.txt>
The ITU-T Recommendations are available at http://www.itu.ch.
12. Authors' Addresses 🌸
Lloyd McIntyre Stephen Zilles
Xerox Corporation Adobe Systems Inc.
Mailstop PAHV-305 Mailstop W14
3400 Hillview Ave. 345 Park Avenue
Palo Alto, CA 94304 USA San Jose, CA 95110-2704, USA
Voice: +1-650-813-6762 Voice: +1-408-536-4766
Fax: +1-650-845-2340 Fax: +1-408-536-4042
Email: lmcintyre@adoc.xerox.com Email: szilles@adobe.com
Robert Buckley Dennis Venable
Xerox Corporation Xerox Corporation
Mailstop 0128-30E Mailstop 0128-27E
800 Phillips Road 800 Phillips Road
Webster, NY 14580, USA Webster, NY 14580, USA
Voice: +1-716-422-1282 Voice: +1-716-422-8009
Fax: +1-716-422-6117 Fax: +1-716-422-6117
Email: Rob_Buckley@wb.xerox.com Email: venable@wrc.xerox.com
Glenn S. Parsons James Rafferty
Northern Telecom Human Communications
P.O. Box 3511, Station C 12 Kevin Drive
Ottawa, ON K1Y 4H7, Canada Danbury, CT 06811-2901, USA
Phone: +1-613-763-7582 Phone: +1-203-746-4367
Fax: +1-613-763-2697 Fax: +1-203-746-4367
Email: Glenn.Parsons@Nortel.ca Email: Jrafferty@worldnet.att.netAnnex A: Summary of TIFF Fields for Internet Fax 🧚
this annex includes tables that list, by mode, the TIFF fields used in the proposed fax file format 📋 the fields are organized into 3 categories:
- TIFF Baseline Fields
- TIFF Extension Fields
- New Fields.
the tables include the allowed values for each fax mode. entries other than explicit numbers are described like this 👀
n - single number
n, m - 2 numbers
a, b, c - 3 numbers
r - rational number
<n> - array of numbers
<b> - byte sequence
{ASCII} - string
IFD - IFD byte offset
<IFD> - array of IFD byte offsetsa blank entry in the table means that the field is not used by that particular fax mode 🙈
Quick tables and a sweet IANA registration to close it out, bestie 🎀
Table A.1 TIFF Baseline Fields 🍓
+---------------------------------------------------------+
| Fax Mode/Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer | 1 | 1 | 1 | 8, 12 | 1, 2-8 | 1, 2-8 |
| Sample | | | | | 9-16 | 9-16 |
+----------+---------+----------+--------+---------+--------+--------+
| ColorMap | | | | | <n> | <n> |
+----------+---------+----------+--------+---------+--------+--------+
| Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7|
| sion | | | | | | 9,10 |
+----------+---------+----------+--------+---------+--------+--------+
| DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 |
+----------+---------+----------+--------+---------+--------+--------+
+----------+---------+----------+--------+---------+--------+--------+
| ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| cription | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | n | n | n | n | n | n |
| Length | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, |
| Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, |
| | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 |
+----------+---------+----------+--------+---------+--------+--------+
| NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 |
| FileType | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 |
| tation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, 1, |
| metric- | | | | | 10 | 2, 5, |
| Interp- | | | | | | 10 |
| retation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 |
| tionUnit | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| RowsPer- | n | n | n | n | n | n |
| Strip | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4|
| PerPixel | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Byte- | | | | | | |
| Counts | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Offsets | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 |
| tion | 200 | 400, 408 | |
+----------+---------+----------+--------+---------+--------+--------+
| YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 |
| tion | 100,200 | 300, 391, 400 | |
+----------+---------+----------+--------+---------+--------+--------+Table A.2 TIFF Extension Fields ✨
+---------------------------------------------------------+
| Fax Mode/Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | 1 | | 1 |
| Position-| | | | | | |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | <1, 1> | | <1, 1> |
| SubSampl-| | | | <2, 2> | | <2, 2> |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| Name | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Indexed | | | | | 0,1 | 0,1 |
+----------+---------+----------+--------+---------+--------+--------+
| Page- | n, m | n, m | n, m | n, m | n, m | n, m |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| SubIFDs | | | | | | <IFD> |
+----------+---------+----------+--------+---------+--------+--------+
| T4Options| 0, 4 | 0, 1, | | | | 0, 1, |
| | | 4, 5 | | | | 4, 5 |
+----------+---------+----------+--------+---------+--------+--------+
| T6Options| | 0 | | | | 0 |
+----------+---------+----------+--------+---------+--------+--------+
| XPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
| YPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+Table A.3 New Fields 🧚
+---------------------------------------------------------+
| Fax Mode/Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BadFax- | | n | | | | |
| Lines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| CleanFax-| | 0, 1, 2 | | | | |
| Data | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Coding- | | | n | n | n | n |
| Method | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Consecu- | | n | | | | |
| tiveBad- | | | | | | |
| FaxLines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Decode | | | | <r> | <r> | <r> |
+----------+---------+----------+--------+---------+--------+--------+
| Default- | | | | | | <n> |
|ImageColor| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Fax- | | | n | n | n | n |
| Profile | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Global- | | IFD | IFD | IFD | IFD | IFD |
| Parame- | | | | | | |
| tersIFD | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | n, m |
| Layer | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Mode- | | | | | | n |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------|
| Profile- | | | n | n | n | n |
| Type | | | | | | |
+--------------------------------------------------------------------+
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | | | | | | <n> |
| RowCounts| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Version- | | | | <b> |<b> | |
| Year | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+Annex B. IANA Registration for image/tiff Application Parameter Values used for facsimile 🦋
Okay so this is the form you fill out to get the new image/tiff application parameter values registered with IANA, and it's giving very official but also kinda iconic 💅
To: IANA@isi.edu
Subject: Registration of new Application parameter values for
image/tiff
MIME media type name: image/tiff
Optional parameters: Application
New Value(s): faxbw, faxcolor
Description of Use:So the two new values are faxbw and faxcolor, and here's the tea on each one 🍵
faxbw is for apps that can handle one or more TIFF for facsimile profiles (or subsets of them) that encode black-and-white fax data. Its use is defined in Section 9 of this document (TIFFPLUS) 🖤
faxcolor is for apps that can handle one or more TIFF for facsimile profiles (or subsets of them) that can encode black and white AND color fax data. Its use is defined in Section 9 of this document (TIFFPLUS) 🌈
Security Considerations 🔒
okay so the security stuff for the TIFF subsets behind the faxbw and faxcolor Application parameter values? it's all in Section 10 of this document (TIFFPLUS) 💖 go read it, bestie, it's the whole main character arc for security 😭
Persons & Email Addresses to Contact for Further Information 💌
- Glenn W. Parsons (
Glenn.Parsons@Nortel.ca) - James Rafferty (
Jrafferty@worldnet.att.net) - Stephen Zilles (
szilles@adobe.com)
Change Controller 🎀
Stephen Zilles 👑
Information to the Submitter 📬
the accepted registrations get listed in the "Assigned Numbers" series of RFCs 🌸 and the info in the registration form is freely distributable, so share away 🦋
Full Copyright Statement 🌈
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is 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. 💜
📦 where this page comes from
- ietf: rfc2301 1998-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms