Previous Next
TIFF 6.0 Specification Final—June 3, 1992
Cr = ( R - Y ) / ( 2 - 2 * LumaRed )
R, G, and B may be computed from YCbCr as follows:
R = Cr * ( 2 - 2 * LumaRed ) + Y
G = ( Y - LumaBlue * B - LumaRed * R ) / LumaGreen
B = Cb * ( 2 - 2 * LumaBlue ) + Y
In disciplines such as printing, film, and video, there are practical reasons to pro-
vide footroom codes below the ReferenceBlack code and headroom codes above
ReferenceWhite code. In such cases the values of the transformation matrix used
to convert from YCbCr to RGB must be multiplied by a scale factor to produce
full-range RGB values. These scale factors depend on the reference ranges speci-
fied by the ReferenceBlackWhite field. See the ReferenceBlackWhite and
TransferFunction fields for more details.
The values coded by this field will typically reflect the transformation specified
by a standard for YCbC r encoding. The following table contains examples of com-
monly used values.
Standard LumaRed LumaGreen LumaBlue
CCIR Recommendation 601-1 299 / 1000 587 / 1000 114 / 1000
CCIR Recommendation 709 2125 / 10000 7154 / 10000 721 / 10000
The default values for this field are those defined by CCIR Recommendation 601-
1: 299/1000, 587/1000 and 114/1000, for LumaRed, LumaGreen and LumaBlue,
respectively.
YCbCrSubSampling
Tag = 530 (212.H)
Type = SHORT
N =2
Specifies the subsampling factors used for the chrominance components of a
YCbCr image. The two fields of this field, YCbCrSubsampleHoriz and
YCbCrSubsampleVert, specify the horizontal and vertical subsampling factors
respectively.
The two fields of this field are defined as follows:
Short 0: YCbCrSubsampleHoriz:
1 = ImageWidth of this chroma image is equal to the ImageWidth of the associated
luma image.
2 = ImageWidth of this chroma image is halfthe ImageWidth of the associated luma
image.
4 = ImageWidth of this chroma image is one-quarter the ImageWidth of the associ-
ated luma image.
Short 1: YCbCrSubsampleVert:
1 = ImageLength (height) of this chroma image is equal to the ImageLength of the
associated luma image.
91
TIFF 6.0 Specification Final—June 3, 1992
2 = ImageLength (height) of this chroma image is half the ImageLength of the associ-
ated luma image.
4 = ImageLength (height) of this chroma image is one-quarter the ImageLength of the
associated luma image.
Both Cb and Cr have the same subsampling ratio. Also, YCbC rSubsampleVert shall
always be less than or equal to YCbC rSubsampleHoriz.
ImageWidth and ImageLength are constrained to be integer multiples of
YCbCrSubsampleHoriz and YCbCrSubsampleVert respectively. TileWidth and
TileLength have the same constraints. RowsPerStrip must be an integer multiple
of YCbCrSubsampleVert.
The default values of this field are [ 2, 2 ].
YCbCrPositioning
Tag = 531 (213.H)
Type = SHORT
N =1
Specifies the positioning of subsampled chrominance components relative to
luminance samples.
Specification of the spatial positioning of pixel samples relative to the other
samples is necessary for proper image post processing and accurate image presen-
tation. In Class Y files, the position of the subsampled chrominance components
are defined with respect to the luminance component. Because components must
be sampled orthogonally (along rows and columns), the spatial position of the
samples in a given subsampled component may be determined by specifying the
horizontal and vertical offsets of the first sample (i.e. the sample in the upper-left
corner) with respect to the luminance component. The horizontal and vertical
offsets of the first chrominance sample are denoted Xoffset[0,0] and Yoffset[0,0]
respectively. Xoffset[0,0] and Yoffset[0,0] are defined in terms of the number of
samples in the luminance component.
The values for this field are defined as follows:
Tag value YC bCr Positioning X and Y offsets of first chrominance sample
1 centered Xoffset[0,0] = ChromaSubsampleHoriz / 2 - 0.5
Yoffset[0,0] = ChromaSubsampleVert / 2 - 0.5
2 cosited Xoffset[0,0] = 0
Yoffset[0,0] = 0
Field value 1 (centered) must be specified for compatibility with industry stan-
dards such as PostScript Level 2 and QuickTime. Field value 2 (cosited) must be
specified for compatibility with most digital video standards, such as CCIR Rec-
ommendation 601-1.
As an example, for ChromaSubsampleHoriz = 4 and ChromaSubsampleVert = 2,
the centers of the samples are positioned as illustrated below:
92
TIFF 6.0 Specification Final—June 3, 1992
YCbCrPositioning = 1 YCbCrPositioning = 2
Luminance samples
Chrominance samples
Proper subsampling of the chrominance components incorporates an anti-aliasing
filter that reduces the spectral bandwidth of the full-resolution samples. The type
of filter used for subsampling determines the value of the YCbCrPositioning field.
For YCbCrPositioning = 1 (centered), subsampling of the chrominance compo-
nents can easily be accomplished using a symmetrical digital filter with an even
number of taps (coefficients). A commonly used filter for 2:1 subsampling utilizes
two taps (1/2,1/2).
For YCbCrPositioning = 2 (cosited), subsampling of the chrominance components
can easily be accomplished using a symmetrical digital filter with an odd number
of taps. A commonly used filter for 2:1 subsampling utilizes three taps (1/4,1/2,1/4).
The default value of this field is 1.
Ordering of Component Samples
This section defines the ordering convention used for Y, Cb, and Cr component
samples when the PlanarConfiguration field value = 1 (interleaving). For
PlanarConfiguration = 2, component samples are stored as 3 separate planes, and
the ordering is the same as that used for other PhotometricInterpretation field
values.
For PlanarConfiguration = 1, the component sample order is based on the subsam-
pling factors, ChromaSubsampleHoriz and ChromaSubsampleVert, defined by
the YCbCrSubSampling field. The image data within a TIFF file is comprised of
one or more “data units”, where a data unit is defined to be a sequence of samples:
• one or more Y samples
• a Cb sample
• a Cr sample
The Y samples within a data unit are specified as a two-dimensional array having
ChromaSubsampleVert rows of ChromaSubsampleHoriz samples.
93
TIFF 6.0 Specification Final—June 3, 1992
Expanding on the example in the previous section, consider a YCbCr image having
ChromaSubsampleHoriz = 4 and ChromaSubsampleVert = 2:
Y component Cb component Cr component
Y00 Y01 Y02 Y03 Y04 Y05 Cb00 Cr00
Y10 Y11 Y12 Y13
For PlanarConfiguration = 1, the sample order is:
Y00, Y01, Y02, Y03, Y10, Y11, Y12, Y 13, Cb00, Cr00, Y04, Y 05 ...
Minimum Requirements for YCbCr Images
In addition to satisfying the general Baseline TIFF requirements, a YCbCr file
must have the following characteristics:
• SamplesPerPixel = 3. SHORT. Three components representing Y, Cb and Cr.
• BitsPerSample = 8,8,8. SHORT.
• Compression = none (1), LZW (5) or JPEG (6). SHORT.
• PhotometricInterpretation = YCbCr (6). SHORT.
• ReferenceBlackWhite = 6 RATIONALS. Specify the reference values for
black and white.
If the conversion from RGB is not according to CCIR Recommendation 601-1,
code YCbCrCoefficients.
94
TIFF 6.0 Specification Final—June 3, 1992
Section 22: JPEG Compression
Introduction
Image compression reduces the storage requirements of pictorial data. In addition,
it reduces the time required for access to, communication with, and display of
images. To address the standardization of compression techniques an international
standards group was formed: the Joint Photographic Experts Group (JPEG). JPEG
has as its objective to create a joint ISO/CCITT standard for continuous tone
image compression (color and grayscale).
JPEG decided that because of the broad scope of the standard, no one algorithmic
procedure was able to satisfy the requirements of all applications. It was decided
to specify different algorithmic processes, where each process is targeted to sat-
isfy the requirements of a class of applications. Thus, the JPEG standard became a
“toolkit” whereby the particular algorithmic “tools” are selected according to the
needs of the application environment.
The algorithmic processes fall into two classes: lossy and lossless. Those based on
the Discrete Cosine Transform (DCT) are lossy and typically provide for substan-
tial compression without significant degradation of the reconstructed image with
respect to the source image.
The simplest DCT-based coding process is the baseline process. It provides a
capability that is sufficient for most applications. There are additional DCT-based
processes that extend the baseline process to a broader range of applications.
The second class of coding processes is targeted for those applications requiring
lossless compression. The lossless processes are not DCT-based and are utilized
independently of any of the DCT-based processes.
This Section describes the JPEG baseline, the JPEG lossless processes, and the
extensions to TIFF defined to support JPEG compression.
JPEG Baseline Process
The baseline process is a DCT-based algorithm that compresses images having 8
bits per component. The baseline process operates only in sequential mode. In
sequential mode, the image is processed from left to right and top to bottom in a
single pass by compressing the first row of data, followed by the second row, and
continuing until the end of image is reached. Sequential operation has minimal
buffering requirements and thus permits inexpensive implementations.
The JPEG baseline process is an algorithm which inherently introduces error into
the reconstructed image and cannot be utilized for lossless compression. The
algorithm accepts as input only those images having 8 bits per component. Images
with fewer than 8 bits per component may be compressed using the baseline pro-
cess algorithm by left justifying each input component within a byte before com-
pression.
95
TIFF 6.0 Specification Final—June 3, 1992
Input Picture Output Picture
Forward Transform Inverse Transform
8x8 2-D DCT 8x8 2-D IDCT
Uniform Quantization Inverse Quantization
Up to 4 Quant. Tables Receives 4 Tables
1-D DC Prediction 1-D DC Prediction
Entropy Coding Entropy Decoding
2 DC and AC Tables Receives 2+2 Tables
Figure 1. Baseline Process Encoder and Decoder
A functional block diagram of the Baseline encoding and decoding processes is
contained in Figure 1. Encoder operation consists of dividing each component of
the input image into 8x8 blocks, performing the two-dimensional DCT on each
block, quantizing each DCT coefficient uniformly, subtracting the quantized DC
coefficient from the corresponding term in the previous block, and then entropy
coding the quantized coefficients using variable length codes (VLCs). Decoding
is performed by inverting each of the encoder operations in the reverse order.
The DCT
Before performing the foward DCT, input pixels are level-shifted so that they
range from -128 to +127. Blocks of 8x8 pixels are transformed with the two-
dimensional 8x8 DCT:
1 π(2x+1)u π(2y+1)v
F(u,v) = 4 C(u)C(v) ∑∑ f(x,y) cos cos
16 16
and blocks are inverse transformed by the decoder with the Inverse DCT:
1 π(2x+1)u π(2y+1)v
f(x,y) = 4 ∑ ∑ C(u)C(v) F(u,v) cos cos
16 16
with u, v, x, y = 0, 1, 2, ... 7
where x, y = spatial coordinates in the pel domain
u, v = coordinates in the transform domain
C(u), C(v) = 1 / sqrt(2) for u, v = 0
1 otherwise
96
TIFF 6.0 Specification Final—June 3, 1992
Although the exact method for computation of the DCT and IDCT is not subject
to standardization and will not be specified by JPEG, it is probable that JPEG will
adopt DCT-conformance specifications that designate the accuracy to which the
DCT must be computed. The DCT-conformance specifications will assure that
any two JPEG implementations will produce visually-similar reconstructed im-
ages.
Quantization
The coefficients of the DCT are quantized to reduce their magnitude and increase
the number of zero-value coefficients. The DCT coefficients are independently
quantized by uniform quantizers. A uniform quantizer divides the real number
line into steps of equal size, as shown in Figure 2. The quantization step-size
applied to each coefficient is determined from the contents of a 64-element quan-
tization table.
C (u,v)
3
2
1
F (u,v)
-3 Q -2 Q -1 Q 1Q 2Q 3Q
-1
-2
-3
Figure 2. Uniform Quantization
The baseline process provides for up to 4 different quantization tables to be de-
fined and assigned to separate interleaved components within a single scan of the
input image. Although the values of each quantization table should ideally be
determined through rigorous subjective testing which estimates the human
psycho-visual thresholds for each DCT coefficient and for each color component
of the input image, JPEG has developed quantization tables which work well for
CCIR 601 resolution images and has published these in the informational section
of the proposed standard.
DC Prediction
The DCT coefficient located in the upper-left corner of the transformed block
represents the average spatial intensity of the block and is referred to as the “DC
coefficient”. After the DCT coefficients are quantized, but before they are entropy
coded, DC prediction is performed. DC prediction simply means that the DC term
of the previous block is subtracted from the DC term of the current block prior to
encoding.
97
TIFF 6.0 Specification Final—June 3, 1992
Zig-Zag Scan
Prior to entropy coding, the DCT coefficients are ordered into a one-dimensional
sequence according to a “zig-zag” scan. The DC coefficient is coded first, fol-
lowed by AC coefficient coding, proceeding in the order illustrated in Figure 3.
Figure 3. Zig-Zag Scan of DCT Coefficients
Entropy Coding
The quantized DCT coefficients are further compressed using entropy coding.
The baseline process performs entropy coding using variable length codes (VLCs)
and variable length integers (VLIs).
VLCs, commonly known as Huffman codes, compress data symbols by creating
shorter codes to represent frequently-occurring symbols and longer codes for
occasionally-occurring symbols. One reason for using VLCs is that they are easily
implemented by means of lookup tables.
Separate code tables are provided for the coding of DC and AC coefficients. The
following paragraphs describe the respective coding methods used for coding DC
and AC coefficients.
DC Coefficient Coding
DC prediction produces a “differential DC coefficient” that is typically small in
magnitude due to the high correlation of neighboring DC coefficients. Each dif-
ferential DC coefficient is encoded by a VLC which represents the number of
significant bits in the DC term followed by a VLI representing the value itself.
The VLC is coded by first determining the number of significant bits, SSSS, in the
differential DC coefficient through the following table:
SSSS Differential DC Value
0 0
1 -1, 1
2 -3,-2, 2,3
3 -7..-4, 4..7
4 -15..-8, 8..15
5 -31..-16, 16..31
98
TIFF 6.0 Specification Final—June 3, 1992
6 -63..-32, 32..63
7 -127..-64, 64..127
8 -255..-128, 128..255
9 -511..-256, 256..511
10 -1023..-512, 512..1023
11 -2047..-1024, 1024..2047
12 -4095..-2048, 2048..4095
SSSS is then coded from the selected DC VLC table. The VLC is followed by a
VLI having SSSS bits that represents the value of the differential DC coefficient
itself. If the coefficient is positive, the VLI is simply the low-order bits of the
coefficient. If the coefficient is negative, then the VLI is the low-order bits of the
coefficient-1.
AC Coefficient Coding
In a similar fashion, AC coefficients are coded with alternating VLC and VLI
codes. The VLC table, however, is a two-dimensional table that is indexed by a
composite 8-bit value. The lower 4 bits of the 8-bit value, i.e. the column index, is
the number of significant bits, SSSS, of a non-zero AC coefficient. SSSS is com-
puted through the same table as that used for coding the DC coefficient. The
higher-order 4 bits, the row index, is the number of zero coefficients, NNNN, that
precede the non-zero AC coefficient. The first column of the two-dimensional
coding table contains codes that represent control functions. Figure 4 illustrates
the general structure of the AC coding table.
SSSS - Size of Non-Zero AC Coefs
01 2… 10 11…15
0 EOB
NNNN
Length .
of .
Zero .
Run
15 ZRL
Figure 4. 2-D Run-Size Value Array for AC Coefs
The shaded portions are undefined in the baseline process
The flow chart in Figure 5 specifies the AC coefficient coding procedure. AC
coefficients are coded by traversing the block in the zig-zag sequence and count-
99
TIFF 6.0 Specification Final—June 3, 1992
ing the number of zero coefficients until a non-zero AC coefficient is encountered.
If the count of consecutive zero coefficients exceeds 15, then a ZRL code is coded
and the zero run-length count is reset. When a non-zero AC coefficient is found,
the number of significant bits in the non-zero coefficient, SSSS, is combined with
the zero run-length that precedes the coefficient, NNNN, to form an index into the
two-dimensional VLC table. The selected VLC is then coded. The VLC is fol-
lowed by a VLI that represents the value of the AC coefficient. This process is
repeated until the end of the block is reached. If the last AC coefficient is zero,
then an End of Block (EOB) VLC is encoded.
Start
K=0
R=0
K= K+1 R= R+1
N
Y
Coef(K) = 0? K = 63 ?
N Y
Code (ZRL)
R = R - 16
Y
R > 15 ?
N
Code R,Coef (K)
R=0 Code (EOB)
N Y
K = 63 ?
Done
Figure 5. Encoding Procedure for AC Coefs
JPEG Lossless Processes
The JPEG lossless coding processes utilize a spatial-prediction algorithm based
upon a two-dimensional Differential Pulse Code Modulation (DPCM) technique.
They are compatible with a wider range of input pixel precision than the DCT-
based algorithms (2 to 16 bits per component). Although the primary motivation
for specifying a spatial algorithm is to provide a method for lossless compression,
JPEG allows for quantization of the input data, resulting in lossy compression and
higher compression rates.
Although JPEG provides for use of either the Huffman or Arithmetic entropy-
coding models by the processes for lossless coding, only the Huffman coding
model is supported by this version of TIFF. The following is a brief overview of
the lossless process with Huffman coding.
100
Previous Next