and so TIFF for facsimile uses Compression=3 instead. See Sections
4.4.4, 4.5.1, and 4.5.2 for more information 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 first.
ImageWidth(256)
SHORT or LONG
RequiredByTIFFBaseline
This profile supports the following fixed page widths: 1728, 2592,
3456 (corresponding to North American Letter and Legal and 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 specified.
NOTE: Historical TIFF-F did not include support for the following
widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096,
and 4864. Historical TIFF-F documents also included the following
values related to A5 and A6 widths: 816 and 1216. Per the most
recent version of [T.4], A5 and A6 documents are no longer supported
in Group 3 facsimile, so the related width values are now obsolete.
See section 4.5.2 for more information on 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).
NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page
of a multi-page image. The same bit settings are used when TIFF-F is
used for a one-page fax image. See Section 4.4.3 for 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 specified.
ResolutionUnit(296) = 2, 3.
SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch, 3 = centimeter; =
TIFF-F has traditionally used inch-based measurement.
Default = 2 (field may be omitted if this is the value).
SamplesPerPixel(277) = 1.
SHORT
RequiredByTIFFBaseline
1 = monochrome, bi-level in this case (see BitsPerSample).
Default = 1 (field may be omitted if this is the value).
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 specified.
NOTE: The values of 200 and 408 have been added to the historical
TIFF-F values, for consistency with [T.30]. Some existing TIFF-F
implementations may also support values of 80 pixels/cm, which is
equivalent to 204 pixels per inch. See section 4.5.2 for information
on 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 specified
NOTE: The values of 100, 200, and 391 have been added to the
historical TIFF-F values, for consistency with [T.30]. Some existing
TIFF-F implementations may also support values of 77 and 38.5 (cm),
which are equivalent to 196 and 98 pixels per inch, respectively. See
section 4.5.2 for more information on implementation details.
NOTE: Not all combinations of XResolution, YResolution, and
ImageWidth are legal. The following table gives the legal
combinations and corresponding 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 compression, = 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 MH compression is used and
EOLs are not 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 compression 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.
T6Options(293) = (Bit 0 = 0, Bit 1 = 0).
LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified READ
(MMR) 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 that 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.
NOTE: MMR compressed data is two-dimensional and does not use EOLs.
Each MMR encoded image MUST include an "end-of-facsimile-block"
(EOFB) code at the end of each coded strip; see Section 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
See Section 2.2.4 and optional fields below.
Three new, optional fields, used in the original TIFF-F description
to describe page quality, are defined in this specification. The
information contained in these fields is usually obtained from
receiving facsimile hardware (if applicable). They SHOULD NOT be
used in writing TIFF-F files for facsimile image data that is error
corrected or otherwise guaranteed not to have coding errors. Some
applications need to understand exactly the error content of the
data. For example, a CAD program might wish to verify that a file
has a low error level before importing it into a high-accuracy
document. Because Group 3 facsimile devices do not necessarily
perform error correction on the image data, the quality of a received
page must be inferred from the pixel count of decoded scanlines. A
"good" scan line is defined as a line that, when decoded, contains
the correct number of pixels. Conversely, a "bad" scanline is
defined as a line that, when decoded, contains an incorrect number of
pixels.
BadFaxLines(326)
SHORT or LONG
The number of "bad" scanlines 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.
CleanFaxData(327) = 0, 1, 2.
SHORT
Indicates whether "bad" lines encountered during reception are
stored in the data, or whether "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.
NOTE: Many facsimile devices do not actually output bad lines.
Instead, the previous good line is repeated in place of a bad line.
Although this substitution, known as line regeneration, results in a
visual improvement to the image, the data is nevertheless corrupted.
The CleanFaxData field describes the error content of the data. That
is, when the BadFaxLines and ImageLength fields indicate that the
facsimile device encountered lines with an incorrect number of pixels
during reception, the CleanFaxData field indicates whether these bad
lines are actually still in the data or whether the receiving
facsimile device replaced them with regenerated lines.
ConsecutiveBadFaxLines(328)
LONG or SHORT
Maximum number of consecutive "bad" scanlines received. The
BadFaxLines field indicates only the quantity of bad lines.
No Default.
NOTE: The BadFaxLines and ImageLength data indicate only the quantity
of bad lines. The ConsecutiveBadFaxLines field is an indicator of
the distribution of bad lines and may therefore be a better general
indicator of perceived image quality. See Section 4.4.5 for examples
of the use of these fields.
4.4. Technical Implementation Issues
4.4.1. Strips
In general, TIFF files divide an image into "strips", also known as
"bands". Each strip contains a few scanlines of the image. By using
strips, a TIFF reader need not load the entire image into memory,
enabling it to fetch and decompress small random portions of the
image as necessary.
The number of scanlines in a strip is described by the RowsPerStrip
value and the number of bytes in the strip after compression by the
StripByteCount value. The location in the TIFF file of each strip 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 specification [TIFF] does not require a Baseline
TIFF reader to support FillOrder=2, i.e., lowest numbered 1-bit pixel
in the least significant bit of a byte. It further recommends that
FillOrder=2 be used only in special purpose applications.
Facsimile data appears on the phone line in bit-reversed order
relative to its description in ITU-T Recommendation T.4. Therefore,
most facsimile applications choose 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
Many existing applications already read TIFF-F-like files but do not
support the multi-page field. Since a multi-page format greatly
simplifies file management in fax application software, 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 have attempted to produce individual single-page TIFF-F files
with modified NewSubFileType and PageNumber (page one-of-one) values
for export purposes. However, there is no easy way to link such
multiple single-page files together into a logical multiple-page
document, so this practice is not recommended.
4.4.4. Compression
In Group 3 facsimile, there are three compression methods which 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 that this compression method has been commonly called
Group 4 compression. In 1991, the MMR method was approved for use in
Group 3 facsimile and has since been widely utilized.
TIFF-F supports these three compression methods. The most commonly
used is the one-dimensional Modified Huffman (MH) compression 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 much less
frequently used in historical TIFF-F implementations, may 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 upon 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 information to aid the implementor in making a compression
selection is contained 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:
1. Facsimile hardware does not provide page-quality information: MUST
NOT write page-quality fields.
2. Facsimile hardware provides page-quality information, but reports
no bad lines. Write only BadFaxLines = 0.
3. Facsimile hardware provides page-quality information and reports
bad lines. Write both BadFaxLines and ConsecutiveBadFaxLines.
Also write CleanFaxData = 1 or 2 if the hardware’s regeneration
capability is known.
4. 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, TIFF-F has required readers and writers to be able to
handle multi-page TIFF-F files. The experience of various TIFF-F
implementors has shown that implementing TIFF-F can be greatly
simplified if certain practical guidelines are followed when writing
multi-page TIFF-F files.
The structure for a multi-page TIFF-F file will include one IFD per
document page. In this case, this IFD will define 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. (The pages are numbered within TIFF-F beginning
with page 0 as the first page and then ascending (i.e., 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 offsets for each image strip are defined from within
each IFD. Where possible, another guideline for TIFF-F writers is
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).
A single image strip per page further simplifies TIFF-F file writing
for applications such as store and forward messaging, where the file
is usually prepared in advance of the transmission, but other
assumptions may apply for the size of the image strip for
applications that require "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 immediately be evident from the values/offsets of the
fields related to strips.
Another simplifying guideline is that each IFD SHOULD be placed in
the TIFF-F file structure at a point preceding the image that the IFD
describes.
In addition, placing the image data in a physical order within the
TIFF file structure which is consistent with the logical page order
simplifies TIFF-F file writing and reading. 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 is 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 from the top of the
page.
TIFF-F writers MAY follow another simplifying guideline, in which the
IFD, the value data and the image data to which the IFD has offsets
precede the next image IFD. However, this guideline has been relaxed
compared to the others given here.
In the case of the minimal profile, which is also the minimal subset
of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs
(see Section 3.5).
A TIFF-F file structured using the guidelines of this section will
essentially consist of a linked list of IFDs, presented in ascending
page order, each pointing to a single page of image data
(one strip per page), where the pages of image data are also placed
in a logical page order sequence within the TIFF-F file structure.
(The pages of image data may themselves be stored in a contiguous
manner, 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 such as store and forward messaging, where the entire
size of the file is known in advance. Although TIFF-F may also be
used as a file format for cases such as streaming applications,
assumptions differing from those provided in this section (e.g., the
entire size and number of pages within the image are not known in
advance) may be required. 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. The "Uncompressed" bit in T4Options or T6Options must
be set to 0.
4.5.2. Encoding and Resolution
Since two-dimensional encoding is not required for Group 3
compatibility, some historic TIFF-F readers have not been able to
read such 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 who wish to have the maximum flexibility in reading
TIFF-F files should support all three of these compression methods
(MH, MR, and MMR).
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 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 are supported in the TIFF-F
writer, as 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 not to support these
higher resolutions.
Per [T.4], it is permissible for applications to treat the following
XResolution values as equivalent: <204,200> and <400,408>.
Similarly, the following YResolution values may also be treated as
equivalent: <98, 100>, <196, 200>, and <391, 400>. These
equivalencies were allowed by [T.4] to permit conversions between
inch- and metric-based facsimile terminals.
The optional support of metric-based resolutions in the TIFF-F reader
(i.e., 77 x 38.5 cm) is included for completeness, as they are 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 must be byte-aligned.
However, Baseline TIFF has permitted use of non byte-aligned EOLs by
default, so that 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, thus ensuring an EOL sequence of a one byte preceded by a
zero nibble: xxxx0000 00000001.
Modified Huffman compression encodes bits, not bytes. This means
that the end-of-line token may 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 relieves application software of the burden of bit-shifting
every byte while parsing scan-lines for line-oriented image
manipulation (such as writing a TIFF file).
For Modified READ compression, 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], MH-encoded facsimile
documents begin with an EOL, which in TIFF-F may be byte-aligned.
The last line of the image is not terminated by an EOL. Similarly,
respect, images encoded with Modified READ two-dimensional
compression 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