Previous Next
TIFF 6.0 Specification Final—June 3, 1992
a. TIFF FillOrder (tag 266) should always be explicitly specified.
b. FillOrder = 1 should be employed wherever possible in persistent material
that is intended for interchange. This is the only reliable case for widespread
interchange among computer systems, and it is important to explicitly con-
firm the honoring of standard assumptions.
c. FillOrder = 2 should occur only in highly-localized and preferably-transient
material, as in a facsimile server supporting group 3 facsimile equipment.
The tag should be present as a safeguard against the CCITT encoding “leak-
ing” into an unsuspecting application, allowing readers to detect and warn
against the occurence.
There are interchange situations where fill order is not distinguished, as when
filtering the CCITT encoding into a PostScript level 2 image operation. In this
case, as in most other cases of computer-based information interchange,
FillOrder=1 is assumed, and any padding to a multiple of 8 bits is accomplished
by adding a sufficient number of 0-bits to the end of the sequence.
Strips and Tiles. When CCITT bi-level encoding is employed, interaction with
stripping (Section 3) and tiling (Section 15) is as follows:
a. Decompose the image into segments—individual pixel arrays representing
the desired strip or tile configuration. The CCITT encoding procedures are
applied most flexibly if the segments each have a multiple of 4 lines.
b. Individually encode each segment according to the specified CCITT bi-
level encoding, as if each segment is a separate raster-graphic image.
The reason for this general rule is that CCITT bi-level encodings are generally
progressive. That is, the initial line of pixels is encoded, and then subsequent lines,
according to a variety of options, are encoded in terms of changes that need to be
made to the preceding (unencoded) line. For strips and tiles to be individually
usable, they must each start as fresh, independent encodings.
Miscellaneous features. There are provisions in CCITT encoding that are mostly
meaningful during facsimile-transmission procedures. There is generally no sig-
nificant application when storing images in TIFF or other data interchange for-
mats, although TIFF applications should be tolerant and flexible in this regard.
These features tend to have significance only when facilitating transfer between
facsimile and non-facsimile applications of the encoded raster-graphic images.
Further considerations for fill sequences, end-of-line flags, return-to-control (end-
of-block) sequences and byte padding are introduced in discussion of the indi-
vidual encoding options.
T4Options
Tag = 292 (124.H)
Type = LONG
N =1
See Compression=3. This field is made up of a set of 32 flag bits. Unused bits
must be set to 0. Bit 0 is the low-order bit.
Bit 0 is 1 for 2-dimensional coding (otherwise 1-dimensional is assumed). For
2-D coding, if more than one strip is specified, each strip must begin with a 1-
51
TIFF 6.0 Specification Final—June 3, 1992
dimensionally coded line. That is, RowsPerStrip should be a multiple of “Param-
eter K,” as documented in the CCITT specification.
Bit 1 is 1 if uncompressed mode is used.
Bit 2 is 1 if 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 1 byte
preceded by a zero nibble: xxxx-0000 0000-0001.
Default is 0, for basic 1-dimensional coding. See also Compression.
T6Options
Tag = 293 (125.H)
Type = LONG
N =1
See Compression = 4. This field is made up of a set of 32 flag bits. Unused bits
must be set to 0. Bit 0 is the low-order bit. The default value is 0 (all bits 0).
bit 0 is unused and always 0.
bit 1 is 1 if uncompressed mode is allowed in the encoding.
In earlier versions of TIFF, this tag was named Group4Options. The significance
has not changed and the present definition is compatible. The name of the tag has
been changed to be consistent with the nomenclature of other T.6-encoding appli-
cations.
Readers should honor this option tag, and only this option tag, whenever T.6-
Encoding is specified for Compression.
For T.6-Encoding, each segment (strip or tile) is encoded as if it were a separate
image. The encoded string from each segment starts a fresh byte.
There are no one-dimensional line encodings in T.6-Encoding. Instead, even the
first row of the segment’s pixel array is encoded two-dimensionally by always
assuming an invisible preceding row of all-white pixels. The 2-dimensional pro-
cedure for encoding the body of individual rows is the same as that used for 2-
dimensional T.4-encoding and is described fully in the CCITT specifications.
The beginning of the encoding for each row of a strip or tile is conducted as if
there is an imaginary preceding (0-width) white pixel, that is as if a fresh run of
white pixels has just commenced. The completion of each line is encoded as if
there are imaginary pixels beyond the end of the current line, and of the preceding
line, in effect, of colors chosen such that the line is exactly completable by a code
word, making the imaginary next pixel a changing element that’s not actually
used.
The encodings of successive lines follow contiguously in the binary T.6-Encoding
stream with no special initiation or separation codewords. There are no provisions
for fill codes or explicit end-of-line indicators. The encoding of the last line of the
pixel array is followed immediately, in place of any additional line encodings, by
a 24-bit End-of-Facsimile Block (EOFB).
000000000001000000000001.B.
52
TIFF 6.0 Specification Final—June 3, 1992
The EOFB sequence is immediately followed by enough 0-bit padding to fit the
entire stream into a sequence of 8-bit bytes.
General Application. Because of the single uniform encoding procedure, without
disruptions by end-of-line codes and shifts into one-dimensional encodings, T.6-
encoding is very popular for compression of bi-level images in document imaging
systems. T.6-encoding trades off redundancy for minimum encoded size, relying
on the underlying storage and transmission systems for reliable retention and
communication of the encoded stream.
TIFF readers will operate most smoothly by always ignoring bits beyond the
EOFB. Some writers may produce additional bytes of pad bits beyond the byte
containing the final bit of the EOFB. Robust readers will not be disturbed by this
prospect.
It is not possible to correctly decode a T.6-Encoding without knowledge of the
exact number of pixels in each line of the pixel array. ImageWidth (or TileWidth,
if used) must be stated exactly and accurately. If an image or segment is
overscanned, producing extraneous pixels at the beginning or ending of lines,
these pixels must be counted. Any cropping must be accomplished by other
means. It is not possible to recover from a pixel-count deviation, even when one is
detected. Failure of any row to be completed as expected is cause for abandoning
further decoding of the entire segment. There is no requirement that ImageWidth
be a multiple of eight, of course, and readers must be prepared to pad the final
octet bytes of decoded bitmap rows with additional bits.
If a TIFF reader encounters EOFB before the expected number of lines has been
extracted, it is appropriate to assume that the missing rows consist entirely of
white pixels. Cautious readers might produce an unobtrusive warning if such an
EOFB is followed by anything other than pad bits.
Readers that successfully decode the RowsPerStrip (or TileLength or residual
ImageLength) number of lines are not required to verify that an EOFB follows.
That is, it is generally appropriate to stop decoding when the expected lines are
decoded or the EOFB is detected, whichever occurs first. Whether error indica-
tions or warnings are also appropriate depends upon the application and whether
more precise troubleshooting of encoding deviations is important.
TIFF writers should always encode the full, prescribed number of rows, with a
proper EOFB immediately following in the encoding. Padding should be by the
least number of 0-bits needed for the T.6-encoding to exactly occupy a multiple of
8 bits. Only 0-bits should be used for padding, and StripByteCount (or
TileByteCount) should not extend to any bytes not containing properly-formed
T.6-encoding. In addition, even though not required by T.6-encoding rules, suc-
cessful interchange with a large variety of readers and applications will be en-
hanced if writers can arrange for the number of pixels per line and the number of
lines per strip to be multiples of eight.
Uncompressed Mode. Although T.6-encodings of simple bi-level images result
in data compressions of 10:1 and better, some pixel-array patterns have T.6-
encodings that require more bits than their simple bi-level bitmaps. When such
cases are detected by encoding procedures, there is an optional extension for
shifting to a form of uncompressed coding within the T.6-encoding string.
Uncompressed mode is not well-specified and many applications discourage its
usage, prefering alternatives such as different compressions on a segment-by-
segment (strip or tile) basis, or by simply leaving the image uncompressed in its
53
TIFF 6.0 Specification Final—June 3, 1992
entirety. The main complication for readers is in properly restoring T.6-encoding
after the uncompressed sequence is laid down in the current row.
Readers that have no provision for uncompressed mode will generally reject any
case in which the flag is set. Readers that are able to process uncompressed-mode
content within T.6-encoding strings can safely ignore this flag and simply process
any uncompressed-mode occurences correctly.
Writers that are unable to guarantee the absence of uncompressed-mode material
in any of the T.6-encoded segments must set the flag. The flag should be cleared
(or defaulted) only when absence of uncompressed-mode material is assured.
Writers that are able to inhibit the generation of uncompressed-mode extensions
are encouraged to do so in order to maximize the acceptability of their T.6-encod-
ing strings in interchange situations.
Because uncompressed-mode is not commonly used, the following description is
best taken as suggestive of the general machinery. Interpolation of fine details can
easily vary between implementations.
Uncompressed mode is signalled by the occurence of the 10-bit extension code
string
0000001111.B
outside of any run-length make-up code or extension. Original unencoded image
information follows. In this unencoded information, a 0-bit evidently signifies a
white pixel, a 1-bit signifies a black pixel, and the TIFF PhotometricInterpretation
will influence how these bits are mapped into any final uncompressed bitmap for
use. The only modification made to the unencoded information is insertion of a 1-
bit after every block of five consecutive 0-bits from the original image informa-
tion. This is a transparency device that allows longer sequencences of 0-bits to be
reserved for control conditions, especially ending the uncompressed-mode se-
quence. When it is time to return to compressed mode, the 8-bit exit sequence
0000001t.B
is appended to the material. The 0-bits of the exit sequence are not considered in
applying the 1-bit insertion rule; up to four information 0-bits can legally precede
the exit sequence. The trailing bit, ‘t,’ specifies the color (via 0 or 1) that is under-
stood in the next run of compressed-mode encoding. This lets a color other than
white be assumed for the 0-width pixel on the left of the edge between the last
uncompressed pixel and the resumed 2-dimensional scan.
Writers should confine uncompressed-mode sequences to the interiors of indi-
vidual rows, never attempting to “wrap” from one row to the next. Readers must
operate properly when the only encoding for a single row consists of an
uncompressed-mode escape, a complete row of (proper 1-inserted) uncompressed
information, and the extension exit. Technically, the exit pixel, ‘t,’ should prob-
ably then be the opposite color of the last true pixel of the row, but readers should
be generous in this case.
In handling these complex encodings, the encounter of material from a defective
source or a corrupted file is particularly unsettling and mysterious. Robust readers
will do well to defend against falling off the end of the world; e.g., unexpected
EOFB sequences should be handled, and attempted access to data bytes that are
not within the bounds of the present segment (or the TIFF file itself) should be
avoided.
54
TIFF 6.0 Specification Final—June 3, 1992
Section 12: Document Storage and Retrieval
These fields may be useful for document storage and retrieval applications. They
will very likely be ignored by other applications.
DocumentName
The name of the document from which this image was scanned.
Tag = 269 (10D.H)
Type = ASCII
See also PageName.
PageName
The name of the page from which this image was scanned.
Tag = 285 (11D.H)
Type = ASCII
See also DocumentName.
No default.
PageNumber
The page number of the page from which this image was scanned.
Tag = 297 (129.H)
Type = SHORT
N =2
This field is used to specify page numbers of a multiple page (e.g. facsimile) docu-
ment. PageNumber[0] is the page number; PageNumber[1] is the total number of
pages in the document. If PageNumber[1] is 0, the total number of pages in the
document is not available.
Pages need not appear in numerical order.
The first page is numbered 0 (zero).
No default.
XPosition
X position of the image.
Tag = 286 (11E.H)
Type = RATIONAL
N =1
55
TIFF 6.0 Specification Final—June 3, 1992
The X offset in ResolutionUnits of the left side of the image, with respect to the
left side of the page.
No default. See also YPosition.
YPosition
Y position of the image.
Tag = 287 (11F.H)
Type = RATIONAL
N =1
The Y offset in ResolutionUnits of the top of the image, with respect to the top of
the page. In the TIFF coordinate scheme, the positive Y direction is down, so that
YPosition is always positive.
No default. See also XPosition.
56
TIFF 6.0 Specification Final—June 3, 1992
Section 13: LZW Compression
This section describes TIFF compression scheme 5, an adaptive compression
scheme for raster images.
Restrictions
When LZW compression was added to the TIFF specification, in Revision 5.0, it
was thought to be public domain. This is, apparently, not the case.
The following paragraph has been approved by the Unisys Corporation:
“The LZW compression method is said to be the subject of United States patent
number 4,558,302 and corresponding foreign patents owned by the Unisys Cor-
poration. Software and hardware developers may be required to license this patent
in order to develop and market products using the TIFF LZW compression option.
Unisys has agreed that developers may obtain such a license on reasonable, non-
discriminatory terms and conditions. Further information can be obtained from:
Welch Licensing Department, Office of the General Counsel, M/S C1SW19,
Unisys Corporation, Blue Bell, Pennsylvania, 19424.”
Reportedly, there are also other companies with patents that may affect LZW
implementors.
Reference
Terry A. Welch, “A Technique for High Performance Data Compression”, IEEE
Computer, vol. 17 no. 6 (June 1984). Describes the basic Lempel-Ziv & Welch
(LZW) algorithm in very general terms. The author’s goal is to describe a hard-
ware-based compressor that could be built into a disk controller or database en-
gine and used on all types of data. There is no specific discussion of raster images.
This section gives sufficient information so that the article is not required reading.
Characteristics
LZW compression has the following characteristics:
• LZW works for images of various bit depths.
• LZW has a reasonable worst-case behavior.
• LZW handles a wide variety of repetitive patterns well.
• LZW is reasonably fast for both compression and decompression.
• LZW does not require floating point software or hardware.
57
TIFF 6.0 Specification Final—June 3, 1992
• LZW is lossless. All information is preserved. But if noise or information is
removed from an image, perhaps by smoothing or zeroing some low-order
bitplanes, LZW compresses images to a smaller size. Thus, 5-bit, 6-bit, or 7-bit
data masquerading as 8-bit data compresses better than true 8-bit data. Smooth
images also compress better than noisy images, and simple images compress
better than complex images.
• LZW works quite well on bilevel images, too. On our test images, it almost
always beat PackBits and generally tied CCITT 1D (Modified Huffman) com-
pression. LZW also handles halftoned data better than most bilevel compres-
sion schemes.
The Algorithm
Each strip is compressed independently. We strongly recommend that
RowsPerStrip be chosen such that each strip contains about 8K bytes before com-
pression. We want to keep the strips small enough so that the compressed and
uncompressed versions of the strip can be kept entirely in memory, even on small
machines, but are large enough to maintain nearly optimal compression ratios.
The LZW algorithm is based on a translation table, or string table, that maps
strings of input characters into codes. The TIFF implementation uses variable-
length codes, with a maximum code length of 12 bits. This string table is different
for every strip and does not need to be reatained for the decompressor. The trick is
to make the decompressor automatically build the same table as is built when the
data is compressed. We use a C-like pseudocode to describe the coding scheme:
InitializeStringTable();
WriteCode(ClearCode);
Ω = the empty string;
for each character in the strip {
K = GetNextCharacter();
if Ω+K is in the string table {
Ω = Ω+K; /* string concatenation */
} else {
WriteCode (CodeFromString(Ω));
AddTableEntry(Ω+K);
Ω = K;
}
} /* end of for loop */
WriteCode (CodeFromString(Ω));
WriteCode (EndOfInformation);
That’s it. The scheme is simple, although it is challenging to implement effi-
ciently. But we need a few explanations before we go on to decompression.
The “characters” that make up the LZW strings are bytes containing TIFF
uncompressed (Compression=1) image data, in our implementation. For example,
if BitsPerSample is 4, each 8-bit LZW character will contain two 4-bit pixels. If
BitsPerSample is 16, each 16-bit pixel will span two 8-bit LZW characters.
It is also possible to implement a version of LZW in which the LZW character
depth equals BitsPerSample, as described in Draft 2 of Revision 5.0. But there is a
major problem with this approach. If BitsPerSample is greater than 11, we can not
58
TIFF 6.0 Specification Final—June 3, 1992
use 12-bit-maximum codes and the resulting LZW table is unacceptably large.
Fortunately, due to the adaptive nature of LZW, we do not pay a significant com-
pression ratio penalty for combining several pixels into one byte before compress-
ing. For example, our 4-bit sample images compressed about 3 percent worse, and
our 1-bit images compressed about 5 percent better. And it is easier to write an
LZW compressor that always uses the same character depth than it is to write one
that handles varying depths.
We can now describe some of the routine and variable references in our
pseudocode:
InitializeStringTable() initializes the string table to contain all possible single-
character strings. There are 256 of them, numbered 0 through 255, since our char-
acters are bytes.
WriteCode() writes a code to the output stream. The first code written is a
ClearCode, which is defined to be code #256.
Ω is our “prefix string.”
GetNextCharacter() retrieves the next character value from the input stream. This
will be a number between 0 and 255 because our characters are bytes.
The “+” signs indicate string concatenation.
AddTableEntry() adds a table entry. (InitializeStringTable() has already put 256
entries in our table. Each entry consists of a single-character string, and its associ-
ated code value, which, in our application, is identical to the character itself. That
is, the 0th entry in our table consists of the string <0>, with a corresponding code
value of <0>, the 1st entry in the table consists of the string <1>, with a corre-
sponding code value of <1> and the 255th entry in our table consists of the string
<255>, with a corresponding code value of <255>.) So, the first entry that added
to our string table will be at position 256, right? Well, not quite, because we re-
serve code #256 for a special “Clear” code. We also reserve code #257 for a spe-
cial “EndOfInformation” code that we write out at the end of the strip. So the first
multiple-character entry added to the string table will be at position 258.
For example, suppose we have input data that looks like this:
Pixel 0:<7>
Pixel 1:<7>
Pixel 2:<7>
Pixel 3:<8>
Pixel 4:<8>
Pixel 5:<7>
Pixel 6:<7>
Pixel 7:<6>
Pixel 8:<6>
First, we read Pixel 0 into K. ΩK is then simply <7>, because Ω is an empty string
at this point. Is the string <7> already in the string table? Of course, because all
single character strings were put in the table by InitializeStringTable(). So set Ω
equal to <7>, and then go to the top of the loop.
59
TIFF 6.0 Specification Final—June 3, 1992
Read Pixel 1 into K. Does ΩK (<7><7>) exist in the string table? No, so we write
the code associated with Ω to output (write <7> to output) and add ΩK (<7><7>)
to the table as entry 258. Store K (<7>) into Ω. Note that although we have added
the string consisting of Pixel 0 and Pixel 1 to the table, we “re-use” Pixel 1 as the
beginning of the next string.
Back at the top of the loop, we read Pixel 2 into K. Does ΩK (<7><7>) exist in the
string table? Yes, the entry we just added, entry 258, contains exactly <7><7>. So
we add K to the end of Ω so that Ω is now <7><7>.
Back at the top of the loop, we read Pixel 3 into K. Does ΩK (<7><7><8>) exist
in the string table? No, so we write the code associated with Ω (<258>) to output
and then add ΩK to the table as entry 259. Store K (<8>) into Ω.
Back at the top of the loop, we read Pixel 4 into K. Does ΩK (<8><8>) exist in the
string table? No, so we write the code associated with Ω (<8>) to output and then
add ΩK to the table as entry 260. Store K (<8>) into Ω.
Continuing, we get the following results:
After reading: We write to output: And add table entry:
Pixel 0
Pixel 1 <7> 258: <7><7>
Pixel 2
Pixel 3 <258> 259: <7><7><8>
Pixel 4 <8> 260:<8><8>
Pixel 5 <8> 261: <8><7>
Pixel 6
Pixel 7 <258> 262: <7><7><6>
Pixel 8 <6> 263: <6><6>
WriteCode() also requires some explanation. In our example, the output code
stream, <7><258><8><8><258><6> should be written using as few bits as pos-
sible. When we are just starting out, we can use 9-bit codes, since our new string
table entries are greater than 255 but less than 512. After adding table entry 511,
switch to 10-bit codes (i.e., entry 512 should be a 10-bit code.) Likewise, switch to
11-bit codes after table entry 1023, and 12-bit codes after table entry 2047. We
will arbitrarily limit ourselves to 12-bit codes, so that our table can have at most
4096 entries. The table should not be any larger.
Whenever you add a code to the output stream, it “counts” toward the decision
about bumping the code bit length. This is important when writing the last code
word before an EOI code or ClearCode, to avoid code length errors.
What happens if we run out of room in our string table? This is where the
ClearCode comes in. As soon as we use entry 4094, we write out a (12-bit)
ClearCode. (If we wait any longer to write the ClearCode, the decompressor
might try to interpret the ClearCode as a 13-bit code.) At this point, the compres-
sor reinitializes the string table and then writes out 9-bit codes again.
Note that whenever you write a code and add a table entry, Ω is not left empty. It
contains exactly one character. Be careful not to lose it when you write an end-of-
table ClearCode. You can either write it out as a 12-bit code before writing the
ClearCode, in which case you need to do it right after adding table entry 4093, or
60
Previous Next