facsimile. The currently defined values 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 M
CodingMethods(403)
LONG
This field indicates which coding methods are used in the file. A
value of 1 in a bit location indicates the corresponding coding
method is used. More than one bit set to 1 means more than one
coding method is used in the file.
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 use
Note: There is a limit of 32 compression types to identify standard
compression methods.
VersionYear(404)
BYTE
Count: 4
The year of the standard specified by the FaxProfile field, given
as 4 characters, e.g., ’1997’; used in lossy and lossless color
profiles.
ModeNumber (405)
BYTE
The mode of the standard specified by the FaxProfile field. A
value of 0 indicates Mode 1.0; used in Mixed Raster Content
profile.
3. Profile S: Minimal Black-and-White Fax Profile
This section defines the minimal black-and-white subset of TIFF for
facsimile. This 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 users are
familiar with today. This mode is appropriate for black-and-white
text and line art. Black-and-white mode is divided into two levels
of capability. This section describes the minimal interchange set of
TIFF fields that must be supported by all implementations in order to
assure that some form of image, albeit black-and-white, can be
interchanged. This minimum interchange set is a strict subset of the
fields and values defined for the extended black-and-white profile
(TIFF-F or Profile F) in Section 4, which describes extensions to the
minimal interchange set of fields that provide a richer set of
black-and-white capabilities.
3.1. Overview
The minimal interchange portion of the black-and-white facsimile mode
supports 1-dimensional Modified Huffman (MH) compression, with the
original Group 3 fax resolutions, commonly called "standard" and
"fine."
To assure interchange, this profile uses the minimal set of fields
with a minimal set of values. There are no recommended fields in
this profile. Further, the TIFF file is required to be "little-
endian", which means that the byte order value in the TIFF header is
"II". This profile defines a required ordering for the pages in a
fax document and for the IFDs and image data of a page. It also
requires
that a single strip contain the image data for each page; see Section
3.5. The image data may contain RTC sequences, as specified in
Section 3.4.
3.2. Required TIFF Fields
Besides the fields listed in Section 2.2.1, the minimal black-and-
white fax profile requires the following fields. The fields listed
in Section 2.2.1 and the fields and fax-specific values specified in
this subsection must be supported by all implementations.
3.2.1. Baseline fields
BitsPerSample(258) = 1.
SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)
Compression(259) = 3.
SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding.
The value 3 is a TIFF extension value [TIFF]. The T4Options field
must be specified, and its value specifies that the data is
encoded with the Modified Huffman (MH) compression of [T.4].
FillOrder(266) = 2.
SHORT
RequiredByTIFFBaseline
2 = 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. However, because many devices, such as modems, transmit the
LSB first when converting the data to serial form, it is common
for black-and-white fax products to use the second FillOrder = 2,
where the lowest numbered pixel is stored in the LSB. Therefore,
this value is specified in the minimal black-and-white profile.
ImageWidth(256) = 1728.
SHORT or LONG
RequiredByTIFFBaseline
This profile only supports a page width of 1728 pixels. This
width corresponds to North American Letter and Legal and to ISO A4
size pages. No default, must be specified.
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).
PhotometricInterpretation(262) = 0.
SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black.
No default, must be specified.
ResolutionUnit(296) = 2.
SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch.
Default = 2 (field may be omitted if this is the value).
SamplesPerPixel(277) = 1.
SHORT
RequiredByTIFFBaseline
The number of components per pixel; 1 for black-and-white.
Default = 1 (field may be omitted if this is the value).
XResolution(282) = 200, 204.
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 200 and
204, which may be treated as equivalent. See Section 2.2.2 for
inch metric equivalency. No default, must be specified.
YResolution(283) = 98, 100, 196, 200.
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, 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. No
default, must be specified.
3.2.2. Extension fields
T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
LONG
RequiredTIFFExtension (when Compression = 3)
Bit 0 = 0 indicates MH compression.
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 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 specifies the compression used (MH
only in this profile). MH coding requires the use of EOL (End of
Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned
or not. See Section 3.4 for details.
3.2.3. New Fields
None.
3.3. Recommended TIFF Fields
None.
3.4. End of Line (EOL) and Return to Control (RTC)
TIFF extensions for fax, used in this specification, differ from
Baseline TIFF in the following ways:
- A 12-bit EOL sequence MUST precede each line of MH-compressed
image data. (Baseline TIFF does not use these EOL sequences.)
- The EOL sequence MAY be byte-aligned, in which case fill bits are
added so that the EOL sequence ends on a byte boundary, and any
subsequent image data begins on a byte boundary.
- If the EOL codes are not byte aligned, the image data MAY be
followed by an RTC (Return to Control) sequence, consisting of 6
consecutive EOLs.
In conventional fax, an MH-compressed fax data stream for a page
consists of the following sequence:
EOL, compressed data (first line), EOL, compressed data, ... ,
EOL, compressed data (last line), RTC (6 consecutive EOL codes)
Baseline TIFF does not use EOL codes or Return to Control (RTC)
sequences for MH-compressed data. However, the TIFF extension field
T4Options used in this specification for MH compression (Compression
= 3) requires EOLs.
Furthermore, Bit 2 in the T4Options field indicates whether or not
the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL
codes are byte aligned, then fill bits have been added as necessary
before EOL codes so that an EOL code always ends on a byte boundary,
and the first bit of data following an EOL begins on a byte boundary.
Without fill bits, an EOL code may end in the middle of a byte. Byte
alignment relieves application software of the burden of bit-shifting
every byte while parsing scanlines for line-oriented image
manipulation (such as writing a TIFF file). Not all TIFF readers
historically used for fax are able to deal with non byte aligned
data.
While TIFF extension requires EOL codes, TIFF in fax applications has
traditionally prohibited RTC sequences. Implementations that seek
common processing and interfaces for fax data streams and Internet
fax files would prefer that the TIFF data include RTC sequences.
To reconcile these differences, RTCs are allowed in cases where EOL
codes are not byte aligned and no fill bits have been added to the
data. This corresponds to situations where the 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 subsection.
3.4.1. RTC Exclusion
Implementations that seek to maintain strict conformance with TIFF
and compatibility with the historical use of TIFF for fax SHOULD NOT
include the RTC sequence when writing TIFF files. However,
implementations that need to support "transparency" of T.4-generated
image data MAY include RTCs when writing TIFF files if the flag
settings of the T4Options field are set for non byte aligned data,
i.e., Bit 2 is 0. Implementors of TIFF readers should be aware that
there are some existing TIFF implementations for fax that include the
RTC sequence in MH image data. Therefore, minimal set readers MUST
be able to process files that do not include RTCs and SHOULD be able
to process files that do include RTCs.
3.5. File Structure
The TIFF header, described in Section 2.1.1, contains two bytes that
describe the byte order used within the file. For the minimal
black-and-white profile, these bytes SHALL have the value "II"
(0x4949), denoting that the bytes in the TIFF file are in LSByte-
first order (little-endian). The first or 0th IFD immediately
follows the header, so offset to the first IFD is 8. The header
values are shown in the following 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 profile SHALL order IFDs and image data
within a file as follows: (1) There SHALL be an IFD for each page in
a multi-page fax document; (2) the IFDs SHALL occur in the same order
in the file as the pages occur in the document; (3) the IFD SHALL
precede the image data to which it has offsets; (4) the image data
SHALL occur in the same order in the file as the pages occur in the
document; (5) the IFD, the value data, and the image data to which it
has offsets SHALL precede the next image IFD; and (6) the image data
for each page SHALL be contained within a single strip.
As a result of (6), the StripOffsets field will contain the pointer
to the image data. With two exceptions, the field entries in the IFD
contain the field values instead of offsets to field values located
outside the IFD. The two exceptions are the values for the
XResolution and YResolution fields, both of which are type RATIONAL
and require 2 4-byte numbers. These "long" field values SHALL be
placed immediately after the IFD which containing the offsets to
them, and before the image data pointed to by that IFD.
The effect of these requirements is that the IFD for the first page
SHALL come first in the file after the TIFF header, followed by the
long field values for XResolution and YResolution, followed by the
image data for the first page, then the IFD for second page, and so
on. This is shown in the following figure. Each IFD is required to
have a PageNumber field, which has value 0 for the first page, 1 for
the second page, 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
+-----------------------+
| : |
Using this file structure may reduce the memory requirements in
implementations. It also provides some support for streaming, in
which a file can be processed as it is received and before the entire
file is received.
3.6. Profile S: Minimal Black-and-White Profile Summary
The table below summarizes the TIFF fields that compose the minimal
interchange set for black-and-white facsimile. The Baseline and
Extension fields and field values MUST be supported by all
implementations. For convenience, certain fields that have a value
that is a sequence of flag bits are shown with integer values
corresponding to the flags that are set. An implementation should
test the setting of the relevant flag bits individually, however, to
allow extensions to the sequence of flag bits to be appropriately
ignored. (See, for example, T4Options below.)
+---------------------------+--------------------------------+
| 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. Profile F: Extended Black-and-White fax profile
This section defines the extended black-and-white profile or Profile
F of TIFF for facsimile. It provides a standard definition of what
has historically been known as TIFF Class F and now as TIFF-F. In
doing so, it aligns this profile with current ITU-T Recommendations
for black-and-white fax and with existing industry practice.
Implementations of this profile include implementations of Profile S.
This section describes extensions to the minimal interchange set of
fields (Profile S) that provide a richer set of black-and-white
capabilities. The fields and values described in this section are a
superset of the fields and values defined for the minimal interchange
set in Section 3. In addition to the MH compression, Modified READ
(MR) and Modified Modified READ (MMR) compression, 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 profile. Section 4.3
describes the fields that MAY be used in this profile. In the spirit
of the original TIFF-F specification, Sections 4.4 and 4.5 discuss
technical implementation issues and warnings. Section 4.6 gives an
example of TIFF-F use. Section 4.7 gives a summary of the required
and recommended fields and their values.
4.1. TIFF-F Overview
Though it has been in common use for many years, TIFF-F has
previously never been documented in the form of a standard. An
informal TIFF-F document was originally created by a small group of
fax experts led by Joe Campbell. The existence of TIFF-F is noted in
[TIFF], but it is not defined. This document serves as the formal
definition of the F application of [TIFF] for Internet applications.
For ease of reference, the term TIFF-F will be used throughout this
document as a shorthand for the extended black-and-white profile of
TIFF for facsimile.
Up until the TIFF 6.0 specification, TIFF supported various "Classes"
that defined the use of TIFF for various applications. Classes were
used to support specific applications. In this spirit, TIFF-F has
been known historically as "TIFF Class F". Previous informal TIFF-F
documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0
[TIFF], the TIFF Class concept has been eliminated in favor of the
concept of Baseline TIFF. Therefore, this document updates the
definition of TIFF-F as the F profile of TIFF for facsimile, by using
Baseline TIFF as defined in [TIFF] as the starting point and then
adding the TIFF extensions to Baseline TIFF that apply for TIFF-F.
In almost all cases, the resulting definition of TIFF-F fields and
values remains consistent with those used historically in earlier
definitions of TIFF Class F. Where some of the values for fields
have been updated to provide more precise conformance with the ITU-T
[T.4] and [T.30] fax recommendations, these differences are noted.
4.2. Required TIFF Fields
This section lists the required fields and the values they must have
to be ITU-compatible. Besides the fields listed in Section 2.2.1,
the extended black-and-white fax profile 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)
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)
NOTE: Baseline TIFF permits use of value 2 for Modified Huffman
compression, but data is presented in a form that does not use EOLs,