Previous Next
TIFF 6.0 Specification Final—June 3, 1992
Currently defined values are:
1 = full-resolution image data
2 = reduced-resolution image data
3 = a single page of a multi-page image (see the PageNumber field description).
Note that several image types may be found in a single TIFF file, with each subfile
described by its own IFD.
No default.
This field is deprecated. The NewSubfileType field should be used instead.
Threshholding
For black and white TIFF files that represent shades of gray, the technique used to
convert from gray to black and white pixels.
Tag = 263 (107.H)
Type = SHORT
N =1
1 = No dithering or halftoning has been applied to the image data.
2 = An ordered dither or halftone technique has been applied to the image data.
3 = A randomized process such as error diffusion has been applied to the image data.
Default is Threshholding = 1. See also CellWidth, CellLength.
XResolution
The number of pixels per ResolutionUnit in the ImageWidth direction.
Tag = 282 (11A.H)
Type = RATIONAL
N =1
It is not mandatory that the image be actually displayed or printed at the size implied
by this parameter. It is up to the application to use this information as it wishes.
No default. See also YResolution, ResolutionUnit.
YResolution
The number of pixels per ResolutionUnit in the ImageLength direction.
Tag = 283 (11B.H)
Type = RATIONAL
N =1
No default. See also XResolution, ResolutionUnit.
41
TIFF 6.0 Specification Final—June 3, 1992
Section 9: PackBits Compression
This section describes TIFF compression type 32773, a simple byte-oriented run-
length scheme.
Description
In choosing a simple byte-oriented run-length compression scheme, we arbitrarily
chose the Apple Macintosh PackBits scheme. It has a good worst case behavior
(at most 1 extra byte for every 128 input bytes). For Macintosh users, the toolbox
utilities PackBits and UnPackBits will do the work for you, but it is easy to imple-
ment your own routines.
A pseudo code fragment to unpack might look like this:
Loop until you get the number of unpacked bytes you are expecting:
Read the next source byte into n.
If n is between 0 and 127 inclusive, copy the next n+1 bytes literally.
Else if n is between -127 and -1 inclusive, copy the next byte -n+1
times.
Else if n is -128, noop.
Endloop
In the inverse routine, it is best to encode a 2-byte repeat run as a replicate run
except when preceded and followed by a literal run. In that case, it is best to merge
the three runs into one literal run. Always encode 3-byte repeats as replicate runs.
That is the essence of the algorithm. Here are some additional rules:
• Pack each row separately. Do not compress across row boundaries.
• The number of uncompressed bytes per row is defined to be (ImageWidth + 7)
/ 8. If the uncompressed bitmap is required to have an even number of bytes per
row, decompress into word-aligned buffers.
• If a run is larger than 128 bytes, encode the remainder of the run as one or more
additional replicate runs.
When PackBits data is decompressed, the result should be interpreted as per com-
pression type 1 (no compression).
42
TIFF 6.0 Specification Final—June 3, 1992
Section 10: Modified Huffman Compression
This section describes TIFF compression scheme 2, a method for compressing
bilevel data based on the CCITT Group 3 1D facsimile compression scheme.
References
• “Standardization of Group 3 facsimile apparatus for document transmission,”
Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and
Protocols for Telematic Services, The International Telegraph and Telephone
Consultative Committee (CCITT), Geneva, 1985, pages 16 through 31.
• “Facsimile Coding Schemes and Coding Control Functions for Group 4 Fac-
simile Apparatus,” Recommendation T.6, Volume VII, Fascicle VII.3, Termi-
nal Equipment and Protocols for Telematic Services, The International
Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985,
pages 40 through 48.
We do not believe that these documents are necessary in order to implement Com-
pression=2. We have included (verbatim in most places) all the pertinent informa-
tion in this section. However, if you wish to order the documents, you can write to
ANSI, Attention: Sales, 1430 Broadway, New York, N.Y., 10018. Ask for the
publication listed above—it contains both Recommendation T.4 and T.6.
Relationship to the CCITT Specifications
The CCITT Group 3 and Group 4 specifications describe communications proto-
cols for a particular class of devices. They are not by themselves sufficient to
describe a disk data format. Fortunately, however, the CCITT coding schemes can
be readily adapted to this different environment. The following is one such adap-
tation. Most of the language is copied directly from the CCITT specifications.
See Section 11 for additional CCITT compression options.
Coding Scheme
A line (row) of data is composed of a series of variable length code words. Each
code word represents a run length of all white or all black. (Actually, more than
one code word may be required to code a given run, in a manner described below.)
White runs and black runs alternate.
To ensure that the receiver (decompressor) maintains color synchronization, all
data lines begin with a white run-length code word set. If the actual scan line
begins with a black run, a white run-length of zero is sent (written). Black or white
run-lengths are defined by the code words in Tables 1 and 2. The code words are
of two types: Terminating code words and Make-up code words. Each run-length
is represented by zero or more Make-up code words followed by exactly one
Terminating code word.
43
TIFF 6.0 Specification Final—June 3, 1992
Run lengths in the range of 0 to 63 pels (pixels) are encoded with their appropriate
Terminating code word. Note that there is a different list of code words for black
and white run-lengths.
Run lengths in the range of 64 to 2623 (2560+63) pels are encoded first by the
Make-up code word representing the run-length that is nearest to, not longer than,
that required. This is then followed by the Terminating code word representing
the difference between the required run-length and the run-length represented by
the Make-up code.
Run lengths in the range of lengths longer than or equal to 2624 pels are coded
first by the Make-up code of 2560. If the remaining part of the run (after the first
Make-up code of 2560) is 2560 pels or greater, additional Make-up code(s) of
2560 are issued until the remaining part of the run becomes less than 2560 pels.
Then the remaining part of the run is encoded by Terminating code or by Make-up
code plus Terminating code, according to the range mentioned above.
It is considered an unrecoverable error if the sum of the run-lengths for a line does
not equal the value of the ImageWidth field.
New rows always begin on the next available byte boundary.
No EOL code words are used. No fill bits are used, except for the ignored bits at
the end of the last byte of a row. RTC is not used.
An encoded CCITT string is self-photometric, defined in terms of white and black
runs. Yet TIFF defines a tag called PhotometricInterpretation that also purports
to define what is white and what is black. Somewhat arbitrarily, we adopt the
following convention:
The “normal” PhotometricInterpretation for bilevel CCITT compressed data is
WhiteIsZero. In this case, the CCITT “white” runs are to be interpretated as
white, and the CCITT “black” runs are to be interpreted as black. However, if the
PhotometricInterpretation is BlackIsZero, the TIFF reader must reverse the
meaning of white and black when displaying and printing the image.
44
TIFF 6.0 Specification Final—June 3, 1992
Table 1/T.4 Terminating codes
White Black
run Code run Code
length word length word
0 00110101 0 0000110111
1 000111 1 010
2 0111 2 11
3 1000 3 10
4 1011 4 011
5 1100 5 0011
6 1110 6 0010
7 1111 7 00011
8 10011 8 000101
9 10100 9 000100
10 00111 10 0000100
11 01000 11 0000101
12 001000 12 0000111
13 000011 13 00000100
14 110100 14 00000111
15 110101 15 000011000
16 101010 16 0000010111
17 101011 17 0000011000
18 0100111 18 0000001000
19 0001100 19 00001100111
20 0001000 20 00001101000
21 0010111 21 00001101100
22 0000011 22 00000110111
23 0000100 23 00000101000
24 0101000 24 00000010111
25 0101011 25 00000011000
26 0010011 26 000011001010
27 0100100 27 000011001011
28 0011000 28 000011001100
29 00000010 29 000011001101
30 00000011 30 000001101000
31 00011010 31 000001101001
32 00011011 32 000001101010
33 00010010 33 000001101011
34 00010011 34 000011010010
35 00010100 35 000011010011
36 00010101 36 000011010100
37 00010110 37 000011010101
38 00010111 38 000011010110
39 00101000 39 000011010111
40 00101001 40 000001101100
41 00101010 41 000001101101
42 00101011 42 000011011010
43 00101100 43 000011011011
44 00101101 44 000001010100
45 00000100 45 000001010101
46 00000101 46 000001010110
47 00001010 47 000001010111
48 00001011 48 000001100100
49 01010010 49 000001100101
50 01010011 50 000001010010
51 01010100 51 000001010011
45
TIFF 6.0 Specification Final—June 3, 1992
White Black
run Code run Code
length word length word
52 01010101 52 000000100100
53 00100100 53 000000110111
54 00100101 54 000000111000
55 01011000 55 000000100111
56 01011001 56 000000101000
57 01011010 57 000001011000
58 01011011 58 000001011001
59 01001010 59 000000101011
60 01001011 60 000000101100
61 00110010 61 000001011010
62 00110011 62 000001100110
63 00110100 63 000001100111
Table 2/T.4 Make-up codes
White Black
run Code run Code
length word length word
64 11011 64 0000001111
128 10010 128 000011001000
192 010111 192 000011001001
256 0110111 256 000001011011
320 00110110 320 000000110011
384 00110111 384 000000110100
448 01100100 448 000000110101
512 01100101 512 0000001101100
576 01101000 576 0000001101101
640 01100111 640 0000001001010
704 011001100 704 0000001001011
768 011001101 768 0000001001100
832 011010010 832 0000001001101
896 011010011 896 0000001110010
960 011010100 960 0000001110011
1024 011010101 1024 0000001110100
1088 011010110 1088 0000001110101
1152 011010111 1152 0000001110110
1216 011011000 1216 0000001110111
1280 011011001 1280 0000001010010
1344 011011010 1344 0000001010011
1408 011011011 1408 0000001010100
1472 010011000 1472 0000001010101
1536 010011001 1536 0000001011010
1600 010011010 1600 0000001011011
1664 011000 1664 0000001100100
1728 010011011 1728 0000001100101
EOL 000000000001 EOL 00000000000
46
TIFF 6.0 Specification Final—June 3, 1992
Additional make-up codes
White
and
Black Make-up
run code
length word
1792 00000001000
1856 00000001100
1920 00000001101
1984 000000010010
2048 000000010011
2112 000000010100
2176 000000010101
2240 000000010110
2304 000000010111
2368 000000011100
2432 000000011101
2496 000000011110
2560 000000011111
47
TIFF 6.0 Specification Final—June 3, 1992
Part 2: TIFF Extensions
Part 2 contains extensions to Baseline TIFF. TIFF Extensions are TIFF features
that may not be supported by all TIFF readers. TIFF creators who use these fea-
tures will have to work closely with TIFF readers in their part of the industry to
ensure successful interchange.
The features described in this part were either contained in earlier versions of the
specification, or have been approved by the TIFF Advisory Committee.
48
TIFF 6.0 Specification Final—June 3, 1992
Section 11: CCITT Bilevel Encodings
The following fields are used when storing binary pixel arrays using one of the
encodings adopted for raster-graphic interchange in numerous CCITT and ISO
(International Organization for Standards) recommendations and standards. These
encodings are often spoken of as “Group III compression” and “Group IV com-
pression” because their application in facsimile transmission is the most widely
known.
For the specialized use of these encodings in storing facsimile-transmission images,
further guidelines can be obtained from the TIFF Class F document, available on-line
in the same locations as this specification. This document is administered by another
organization; paper copies are not available from Adobe.
Compression
Tag = 259 (103.H)
Type = SHORT
N =1
3 = T4-encoding: CCITT T.4 bi-level encoding as specified in section 4, Coding, of
CCITT Recommendation T.4: “Standardization of Group 3 Facsimile apparatus
for document transmission.” International Telephone and Telegraph Consultative
Committee (CCITT, Geneva: 1988).
See the T4Options field for T4-encoding options such as 1D vs 2D coding.
4 = T6-encoding: CCITT T.6 bi-level encoding as specified in section 2 of CCITT
Recommendation T.6: “Facsimile coding schemes and coding control functions
for Group 4 facsimile apparatus.” International Telephone and Telegraph Consul-
tative Committee (CCITT, Geneva: 1988).
See the T6Options field for T6-encoding options such as escape into
uncompressed mode to avoid negative-compression cases.
Application in Image Interchange
CCITT Recommendations T.4 and T.6 are specified in terms of the serial bit-by-
bit creation and processing of a variable-length binary string that encodes bi-level
(black and white) pixels of a rectangular image array. Generally, the encoding
schemes are described in terms of bit-serial communication procedures and the
end-to-end coordination that is required to gain reliable delivery over inherently
unreliable data links. The Group 4 procedures, with their T6-encoding, represent a
significant simplification because it is assumed that a reliable communication
medium is employed, whether ISDN or X.25 or some other trustworthy transport
vehicle. Because image-storage systems and computers achieve data integrity and
communication reliability in other ways, the T6-encoding tends to be prefered for
imaging applications. When computer storage and retrieval and interchange of
facsimile material are of interest, the T4-encodings provide a better match to the
49
TIFF 6.0 Specification Final—June 3, 1992
current generation of Group 3 facsimile products and their defenses against data
corruption as the result of transmission defects.
Whichever form of encoding is preferable for a given application, there are a
number of adjustments that need to be made to account for the capture of the
CCITT binary-encoding strings as part of electronically-stored material and digi-
tal-image interchange.
PhotometricInterpretation. An encoded CCITT string is self-photometric, de-
fined in terms of white and black runs. Yet TIFF defines a tag called
PhotometricInterpretation that also purports to define what is white and what is
black. Somewhat arbitrarily, we adopt the following convention:
The “normal” PhotometricInterpretation for bilevel CCITT compressed data is
WhiteIsZero. In this case, the CCITT “white” runs are to be interpretated as white,
and the CCITT “black” runs are to be interpreted as black. However, if the
PhotometricInterpretation is BlackIsZero, the TIFF reader must reverse the mean-
ing of white and black when displaying and printing the image.
FillOrder. When CCITT encodings are used directly over a typical serial commu-
nication link, the order of the bits in the encoded string is the sequential order of
the string, bit-by-bit, from beginning to end. This poses the following question: In
which order should consecutive blocks of eight bits be assembled into octets
(standard data bytes) for use within a computer system? The answer differs de-
pending on whether we are concerned about preserving the serial-transmission
sequence or preserving only the format of byte-organized sequences in memory
and in stored files.
From the perspective of electronic interchange, as long as a receiver’s reassembly
of bits into bytes properly mirrors the way in which the bytes were disassembled
by the transmitter, no one cares which order is seen on the transmission link be-
cause each multiple of 8 bits is transparently transmitted.
Common practice is to record arbitrary binary strings into storage sequences such
that the first sequential bit of the string is found in the high-order bit of the first
octet of the stored byte sequence. This is the standard case specified by TIFF
FillOrder = 1, used in most bitmap interchange and the only case required in
Baseline TIFF. This is also the approach used for the octets of standard 8-bit char-
acter data, with little attention paid to the fact that the most common forms of data
communication transmit and reassemble individual 8-bit frames with the low-
order-bit first!
For bit-serial transmission to a distant unit whose approach to assembling bits into
bytes is unknown and supposed to be irrelevant, it is necessary to satisfy the ex-
pected sequencing of bits over the transmission link. This is the normal case for
communication between facsimile units and also for computers and modems
emulating standard Group 3 facsimile units. In this case, if the CCITT encoding is
captured directly off of the link via standard communication adapters, TIFF
FillOrder = 2 will usually apply to that stored data form.
Consequently, different TIFF FillOrder cases may arise when CCITT encodings
are obtained by synthesis within a computer (including Group 4 transmission,
which is treated more like computer data) instead of by capture from a Group 3
facsimile unit.
Because this is such a subtle situation, with surprisingly disruptive consequences
for FillOrder mismatches, the following practice is urged whenever CCITT bi-
level encodings are used:
50
Previous Next