This is ClassF.txt in view mode; [Download] [Up]
TIFF CLASS F
March 1, 1992
TIFF Class F was defined in late 1989 by Joe Campbell of
Everex Systems, Inc. from the results of a poll of the
facsimile industry. The goal was to define a file format that
is simultaneously suitable for native use in Group 3 computer
facsimile products, and as a file interchange medium with the
outside world. Since that time, there have been only three
minor revisions, mostly editorial in nature. Those wishing
to participate in the revision and upkeep of TIFF Class F
should read the section "Revising the TIFF Class F
Specification," at the end of this document.The revision
history of the specification is at the end of this document.
TIFF Class F defines a subset (a "Class") of existing TIFF
tags, necessary to support Group 3 facsimile data. In many
cases, the values and sizes of these tags are also defined.
Three new optional tags are also defined.
TIFF Classes reduce the information burden on TIFF readers
and writers that wish to support narrow applications. For
example, Appendix G-1 of TIFF 5.0 states that classes enable
TIFF readers "to know when they can stop adding TIFF
features." In other words, defining a Class enables
applications interested only in reading that Class to give up
if the characteristic tags and values are not present.
Therefore, TIFF Class F insists on a rather narrow definition
of tags. In a general TIFF file, for example, the writer
would be free to create single-page documents without the
NewSubFileType and PageNumber tags. Not so for a Class F
file, where the multi-page tag is required even for a single
page.
TIFF Class B (Bilevel) is a sub-class of TIFF. That is, all
tags that are required in TIFF are also required in Class B.
TIFF Class F (Facsimile) is a sub-class of Class B (Bilevel).
That is, all tags that are required in Class B are also
required in Class F. For some common tags, however, Class F
limits the range of acceptable values. The YResolution tag,
for example, is a Class B tag, but its Class F value is
limited to either 98 or 196 dpi. Such tags are listed in
"Required Class F Tags."
Other Class B tags have a slightly eccentric meaning when
applied to facsimile images. These are discussed in the
section "Bilevel Required." There are also tags that may be
helpful but are not required. These are listed in the
"Recommended Tags" section. A brief list of all the tags
required by TIFF Class F, grouped by class, is in the section
"Required Facsimile Tags Grouped By Class." Finally,
technical topics are discussed in the sections "Technical
Points" and "Warnings."
REFERENCES
A machine-readable copy of this document can be downloaded
from the Aldus Forum on Compuserve. Type GO ALDUS and look
through the "Libraries" menu. (Make certain that you download
the most recent revision.) Substantive questions about TIFF
Class F can be faxed to its author: Joe Campbell, Everex
Systems, Inc: (510) 540-5835 or (510) 841-5441, or via
Compuserve Mail 71331,1237. Internet users can contact the
author through the Compuserve gateway as
71331.1237@CompuServe.COM."
Group 3 facsimile is described in the "Blue Book," Volume
VII, Fascicle VII.3, Terminal Equipment and Protocols for
Telematic Services, The International Telegraph and Telephone
Consultative Committee (CCITT), Melbourne, 1988.
CLASS F REQUIRED
Compression = 3 or 4. SHORT.
3 Group 3, one-dimensional encoding with "byte-aligned"
EOL's. An EOL is said to be byte-aligned when Fill
bits have been added as necessary before EOL codes
such that EOL always ends on a byte boundary, thus
ensuring an EOL-sequence of a 1 byte preceded by a
zero nibble: xxxx0000 00000001. The data in a Class
F image is not terminated with an RTC. Please see
items 4 and 5 in the "Warnings" section. For Group
3 two-dimensional encoding, set bit 1 in
Group3Options. Please see item 2 in the "Warnings"
section.
4 Group 4 two-dimensional encoding. MMR (Modified-
Modified READ) compression, formerly found only in
Group 4 facsimile, are now available in Group 3
devices. When this option is used, bits zero
and one in the Group3Options tag are ignored.
FillOrder = 1, 2. SHORT.
TIFF Class 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.
Group3Options = 4,5. LONG.
Data may be one- or two-dimensional, but EOL's must be
byte-aligned. Uncompressed data is not allowed. When
Group 4 compression is used, bits zero and one in the
Group3Options tag should be ignored.
bit 0 0 for 1-Dimensional, 1 for 2-Dimensional
bit 1 Must be 0 (uncompressed data not allowed)
bit 2 1 for byte-aligned EOL's
ImageWidth = 864, 1216, 1728, 2048, 2432. SHORT or LONG. LONG
recommended. These are the fixed page widths in pixels
defined in CCITT Group 3.
NewSubFileType = 2. LONG.
The value 2 identifies a single page of a multi-page image,
even if the document contains only one page.
PageNumber. SHORT/SHORT.
This tag specifies the page numbers in the fax document.
The tag comprises two SHORT values: the first value is the
page number, the second is the total number of pages. The
number of the first page is zero. Single-page documents
therefore use 00000001 hex. The total number of pages is
required only in the PageNumber tag associated with the
first IFD, and is optional in subsequent IFD's. Writers
utilizing this option should set the page count portion of
the subsequent PageNumber tags to zero. (Please remember
that the first IFD is not necessarily page one.)
ResolutionUnit = 2,3. SHORT.
The units of measure for resolution:
2 Inch
3 Centimeter
XResolution = 204, 300, 400 (inches).RATIONAL.
The horizontal resolution of the image expressed in
pixels per resolution unit. See "Technical Point #6,"
below.
YResolution = 98, 196, 300, 400 (inches).RATIONAL.
The vertical resolution of the image expressed in pixels
per resolution unit. See "Technical Point #6," below.
BILEVEL REQUIRED
Although these tags are already required in Class B (Bi-
Level) files, an explanation of their usage for facsimile
images may be helpful.
BitsPerSample = 1. SHORT.
Since facsimile is a black-and-white medium, this must be
1 (the default) for all files.
ImageLength. SHORT or LONG. LONG
Recommended. The total number of scan lines in the image.
PhotometricInterp = 0,1. SHORT.
This tag allows notation of an inverted ("negative") image:
0 Normal
1 Inverted
RowsPerStrip. SHORT or LONG. LONG
Recommended. The number of scan lines per strip. When a
page is expressed as one large strip, this is the same as
the ImageLength tag.
SamplesPerPixel = 1. SHORT.
The value of 1 denotes a bi-level, gray scale, or palette
color image.
StripByteCounts. SHORT or LONG. SHORT
Recommended. For each strip, the number of bytes in that
strip. If a page is expressed as one large strip, this is
the total number of bytes in the page after compression.
StripOffsets. SHORT or LONG.
For each strip, the offset of that strip. The offset is
measured from the beginning of the file. If a page is
expressed as one large strip, there is one such entry
per page.
NEW TAGS
There are only three new tags for Class F. All three tags
describe page quality. The information contained in these
tags is usually obtained from the receiving facsimile
hardware, but since not all devices are capable of reporting
this information, the tags are optional.
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 scan lines. A "good" scan
line is defined as a line that, when decoded, contains the
correct number of pixels. Conversely, a "bad" scan line is
defined as a line that, when decoded, comprises an incorrect
number of pixels.
BadFaxLines
Tag = 326 (146 hex)
Type = SHORT or LONG
This tag reports the number of scan lines with an incorrect
number of pixels encountered by the facsimile during
reception (but not necessarily in the file).
Note: PercentBad = (BadFaxLines/ImageLength) * 100
CleanFaxData
Tag = 327 (147 hex)
Type = SHORT
0 The data is "pure": it contains no lines with incorrect
pixel counts and no substituted lines. Computer-generated
files should always have a value of 0.
1 The receiving device substituted good lines for lines having
an incorrect pixel count.
2 Lines with an incorrect pixel count exist in the data.
Many facsimile receiving devices do not actually output bad
lines. Instead, when a bad line is encountered, the receiver
substitutes a good line. An variety of methods are employed
to derive the pixel content of the substituted line. The
most common are:
1. Fixed-pattern substitution (for example, an all-white or
all-black line).
2. Substitution of a previous good line.
3. Artificial intelligence may be employed to reconstruct the
line based upon context.
Although line substitution usually results in a visual
improvement in the image, the image data is nevertheless
corrupted. The CleanFaxData tag describes the error content
of the data. That is, when the BadFaxLines and ImageLength
tags indicate that the facsimile device encountered lines
with an incorrect number of pixels during reception, the
CleanFaxData tag indicates whether these lines are actually
in the data or if the receiving facsimile device replaced
them with substitute lines.
ConsecutiveBadFaxLines
Tag = 328 (148 hex)
Type = LONG or SHORT
This tag reports the maximum number of consecutive lines
containing an incorrect number of pixels encountered by the
facsimile device during reception (but not necessarily in the
file).
The BadFaxLines and ImageLength data indicate only the
quantity of such lines. The ConsecutiveBadFaxLines tag is an
indicator of their distribution and may therefore be a better
general indicator of perceived image quality.
RECOMMENDED TAGS
BadFaxLines. LONG.
The number of "bad" scan lines encountered by the facsimile
during reception.
ConsecutiveBadFaxLines. LONG or SHORT.
The maximum number of consecutive scan lines with incorrect
pixel count encountered by the facsimile device reception.
DateTime. ASCII.
Date and time in the format YYYY:MM:DD HH:MM:SS, in 24-hour
format. String length including NUL byte is 20 bytes. Space
between DD and HH.
DocumentName. ASCII.
This is the name of the document from which the document
was scanned.
ImageDescription. ASCII.
This is an ASCII string describing the contents of the
image.
Orientation. SHORT.
This tag might be useful for displayers that always want
to show the same orientation, regardless of the image.
The default value of 1 is "0th row is visual top of image,
and 0th column is the visual left." An 180-degree
rotation is 3. See TIFF 5.0 for an explanation of other
values.
Software. ASCII.
The optional name and release number of the software
package that created the image.
REQUIRED TAGS GROUPED CLASS
Required Tags, all TIFF:
NewSubFileType, ImageWidth, ImageLength, StripOffsets,
RowsPerStrip, StripByteCounts, XResolution, YResolution,
ResolutionUnit
Required Tags, Class B:
BitsPerSample, Compression, PhotometricInterp, SamplesPerPixel
Required Tags, Class F:
FillOrder, Group3Options, PageNumber
FILE INTERCHANGEABILITY
File portability among various TIFF F applications,
regardless of platform or operating system, is a primary goal
of TIFF Class F. The following tag values should be used to
assure maximum portability:
1. FillOrder is 2 (least-significant bit first).
2. Group3Options = 4 (one-dimensional encoding).
3. ImageWidth is 1728 (that is, an A4 page).
4. ImageLength must not exceed 1084 for 98
dpi documents and 2167 for 196 dpi documents (that is, an
A4 page). See Note 2, below.
5. PhotometricInterp is 0 (normal).
6. ResolutionUnit = 2 (inches).
7. XResolution is 204.
8. YResolution tag is 98 or 196.
TECHNICAL POINTS
1. Strips
Those new to TIFF may not be familiar with the concept
of "strips" embodied in the three tags RowsPerStrip,
StripByteCount, StripOffsets.
In general, third-party applications that read and write
TIFF files expect the image to be divided into horizontal
"strips," also known as "bands." Each strip contains a
few lines of the image. By using strips, a TIFF reader
need not load the entire image into memory, thus
enabling it to fetch and decompress small random
portions of the image as necessary.
The dimensions of a strip are described by the
RowsPerStrip and StripByteCount tags. The location in the
TIFF file of each strip is contained in the StripOffsets
tag. Is is perfectly acceptable for a Class F file to
store an entire page in a single strip.
In addition to strips, TIFF also permits image data to be
divided into rectangular tiles. Class F images may not be
organized as tiles.
2. EOL Placement in Strips
As illustrated in FIGURE 1/T.4 in Recommendation T.4 (the
"Blue Book"), facsimile documents begin with an EOL (End-
of-Line) code. The last line of the image is not
terminated by an EOL. Expressed differently, EOL's are
actually BOL's (Beginning-of-Line).
When a page is stored as a multi-strip image, one must
consider where to divide scanline data. With the RTC not
included, treating EOL codes like BOL codes permits all
strips to have a consistent format: RowsPerStrip EOL-
prefixed lines of data. Consequently, multi-strip Class F
images must break data such that each strip begins with an
EOL code. This is easily done if these codes are treated
like BOL codes.
3. Bit Order
Although the TIFF 5.0 documentation lists the FillOrder
tag in the category "No Longer Recommended," Class F
resurrects it. Facsimile data appears on the phone line in
bit-reversed order relative to its description in CCITT
Recommendation T.4. Therefore, a wide majority of
facsimile applications choose this natural order for
storage. Nevertheless, TIFF Class F readers must be able
to read data in both bit orders.
4. Multi-Page
Many existing applications already read Class F-like
files, but do not support the multi-page tag. Since a
multi-page format greatly simplifies file management in
fax application software, Class F specifies multi-page
documents (NewSubfileType = 2). A "multi-page document"
may contain only one page.
5. Two-dimensional Encoding
PC Fax applications that wish to support two-dimensional
encoding may do so by setting Bit 0 in the Group3Options
tag.
6. Two-Dimensional Encoding EOL Tag Bits
When two-dimensional encoding is used, the tag bit that
specifies whether the next line is one- or two-
dimensionally encoded is part of the byte that follows the
byte-aligned EOL code. That is, the tag bit is logically
considered to be part of the scan line that it describes.
7. Example Use of Page-quality Tags
Here are examples for writing the CleanFaxData,
BadFaxLines, and ConsecutiveBadFaxLines tags:
* Facsimile hardware does not provide page quality
information: write no tags.
* Facsimile hardware provides page quality information,
but reports no bad lines. Write only BadFaxLines = 0.
* Facsimile hardware provides page quality information,
and reports bad lines. Write both BadFaxLines and
ConsecutiveBadFaxLines. Also write CleanFaxData = 1 or
2 if you know whether the hardware can replace bad
lines.
* Computer generated file: write CleanFaxData = 0.
8. High Resolution
Although 300 and 400 dpi are, strictly speaking, Group 4
resolutions, it is virtually certain that they will soon
be added to Group 3 and, more important, are already in
common use today capabilities through Group 3's NSF
mechanism. Only the following resolutions are valid
(horizontal x vertical): 204 x 98, 204 x 196, 300 x 300,
400 x 400. Those who choose to store images at the "Group
4" resolutions risk incompatibility with other fax
applications.
9. Plain Paper Fax
Many plain-paper printing mechanisms such as those found
on laser printers are unable to print on the entire
surface of the paper. The amount of unusable space
(referred to as the "grabber") varies from device to
device, but as a general rule, allow about six-tenths of
an inch. Failure to reduce the image accordingly may cause
the receiving fax machine to shrink the image to make it
fit on one page (thus changing its scale), or to print it
on two sheets of paper.
The standard paper size for America (8.5 inches by 11.0
inches), is still not supported by CCITT specifications.
Therefore, if you wish your images to print at scale on
American plain paper fax machines, you must limit the
number of lines per page to 2050 in high resolution and
1025 in low resolution.
10. Minimum TIFF Class F Support
Fax applications that do not wish to embrace TIFF Class F
as a native format may elect to support it as
import/export medium:
* Export The simplest form of support is a Class F
writer that produces individual single-page Class F
files with the proper NewSubFile and PageNumber tags.
* Import A Class F reader must be able to handle a Class
F file containing multiple pages.
WARNINGS
1. Class F requires the ability to read and write at least
one-dimensional T.4 Huffman ("compressed") data. Due to
the disruptive effect to application software of line-
length errors and because such errors are likely in
everyday facsimile transmissions, uncompressed data is
not allowed. In other words, "Uncompressed" bit in
Group3Options must be 0.
2. Since two-dimensional encoding is not required for Group 3
compatibility, Class F readers may decline to read such
files. Therefore, for maximum portability write only one-
dimensional files. Although the same argument technically
holds for "fine" (196 dpi) vertical resolution, only a
tiny fraction of facsimile products support only 98 dpi.
Therefore, 196-dpi files are quite portable in the real
world.
3. In the spirit of TIFF, all EOL's in data must be byte-
aligned. An EOL is said to be byte-aligned when Fill bits
have been added as necessary before EOL codes such that
EOL always ends on a byte boundary, thus ensuring an EOL-
sequence of a one byte preceded by a zero nibble: xxxx0000
00000001.
Recall that Huffman encoding 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).
4. Aside from EOL's, TIFF Class F files contain only image
data. This means that the Return-to-Control sequence (RTC)
is specifically prohibited. Exclusion of RTC's not only
makes possible the simple concatenation of images, it
eliminates the mischief failed communications and
unreadable images that their mistreatment inevitably
produces.
REVISING THE TIFF CLASS F SPECIFICATION
Changes in the specification that reflect changes in the underlying
CCITT specifications as well as non-technical changes are incorporated
by editorial fiat. Before substantial modifications are allowed,
however, the author will consult members of the facsimile industry.
The main goal in revision is to retain a specification that fulfills
the original goals and serves the facsimile industry. It is
especially important that Class F not be modified to accommodate
unrelated goals. For example, there have been proposals to relax
Class F tag requirements to make it more compatible with other
flavors of TIFF. In particular, non-facsimile users seem to be vexed
by the necessity to byte-align EOL's and to support the multi-page
format. Such proposals inevitably originate with users outside the
mainstream of facsimile vendors, in whose applications both of these
features are vitally important. Non-facsimile users who find Class F
too restrictive might better be served by designing a new TIFF classes
to accomplish their ends.
MANUSCRIPT OF PROPOSED REVISION
Any person or group that wishes to propose an amendment to TIFF Class
F should prepare the following manuscript:
1. Name of the person or group making the request and their
affiliation (business, academic, etc.).
2. The revision date from which you are working.
3. The reason for the request.
4. A list of changes exactly as you propose that they appear
in the specification. Do not submit an edited version
of the entire specification. Use inserts, callouts, or
other obvious editorial techniques to indicate areas of
change and number each change.
5. Referring to each change number, discuss its potential
effect on other standards that incorporate TIFF Class F
(e.g., FaxBios).
6. A list of phone numbers of persons outside your company
who may support your position. Include their affiliation
(business, academic, etc.).
This manuscript may be faxed to Joe Campbell, Everex Systems,
Inc: (510) 540-5835 or (510) 841-5441, or via Compuserve Mail
71331,1237.
REVISION HISTORY
11/17/89: Initial Publication
4/20/90 : First Revision
PageNumber tag was incorrectly illustrated as page one. The
correct number for the first page is zero.
5/1/91: Second Revision
1. Added 300 and 400 valid values to to the XResolution and
YResolution tags.
2. Software tag moved from Bi-level Required (not
true), to Recommended.
3. ImageWidth tag values of 2482 was corrected to 2432.
4. New ImageWidth tag values added to conform to the "Blue
Book,": 864, 1216.
5. Corrected miscellaneous typographical errors.
6. Added summary of required tags.
10/1/91: Third Revision,
1. Total page count needed only in first tag after IFD.
2. Added MMR compression, modification procedure.
3/1/92: Fourth Revision: EDITORIAL
1. Bad fax lines are now said to be "substituted," instead of
"regenerated." This generalized approach accommodates techniques
besides regeneration.
2. Clarification of the encoding of EOL 2-d tag bits.
3. How to break up data in stripped images.
4. Prohibition of using TIFF tiles.
5. Deletion of discussion of minimum strip size.
6. Added suggestions for adjusting number of scan lines for
destinations that use plain-paper fax and destinations that use
U.S. letter-sized paper.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.