haffman coding DCT transform

522 IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 14, NO. 4, APRIL 2004

Optimal Huffman Coding of DCT Blocks
Gopal Lakhani, Senior Member, IEEE

Abstract—It is a well-observed characteristic that, when a dis- A. Adaptive Huffman Coding
crete cosine transform block is traversed in the zigzag order, ac co-
efficients generally decrease in size and the runs of zero coefficients There are several ways to develop adaptive coding to improve
increase in length. This paper presents a minor modification to the the compression efficiency of JPEG Huffman coding and still
Huffman coding of the JPEG baseline compression algorithm to use a single, fixed code table for all ac coefficients. Clearly, the
exploit this characteristic. During the run-length coding, instead easiest choice is to first develop a custom code table for the given
of pairing a nonzero ac coefficient with the run-length of the pre- image and then use it to code the image; JPEG provides this
ceding zero coefficients, our encoder pairs it with the run-length of
subsequent zeros. This small change makes it possible for our codec as an option. Table I presents experimental results, which show
to code a pair using a separate Huffman code table optimized for that use of the custom code table reduces1 the code size further,
the position of the nonzero coefficient denoted by the pair. These but only by 1.38%. If the size of the custom table is taken into
position-dependent code tables can be encoded efficiently without account, because the encoder must include the code table with
incurring a sizable overhead. Experimental results show that our the image code, there may not be any reduction. Another choice
encoder produces a further reduction in the ac coefficient Huffman
code size by about 10%–15%. is to follow dynamic Huffman coding, [5], proposed for gen-
eral file compression. In this method, the encoder updates the
Index Terms—Discrete cosine transform (DCT), Huffman code table after coding each symbol to model any changes in
coding, JPEG image compression.
the distribution of source symbols. Table I also contains exper-
imental results, which show that this method obtains a further
I. INTRODUCTION reduction of about 1% only; it is hardly appealing knowing that
dynamic Huffman coding is highly computational. The reason
D ISCRETE cosine transform (DCT)-based compression al-
gorithms have been proposed for image and video com-
pression and conferencing systems such as JPEG, MPEG, and
for dynamic Huffman coding not achieving any further com-
pression in our experiments is that there is hardly any change in
H.263. The JPEG baseline compression system [1] is perhaps the global distribution of ac coefficients; all changes are local
the most widely used DCT-based system. In this system, the and confined within each DCT block.
input image is partitioned into blocks of 8 8 pixels first and Literature on adaptive Huffman coding of image and/or video
then each block is transformed using the forward DCT. Next, data is limited. An interesting variation of Huffman coding is
DCT coefficients are normalized using a preset quantization given in [6]; it assigns code words dynamically, i.e., given the
table and, finally, the normalized coefficients are entropy encode table, symbols are assigned different codes from the same
coded. JPEG provides two entropy coding methods—arithmetic table as their frequency change; however, the table remains the
and Huffman coding. This paper deals with the Huffman coding same. A study to resolve mismatches between statistical charac-
of ac coefficients. A complete description of the baseline algo- teristics and variable-length code tables for H.263L is given in
rithm is given in [2] and details of the Huffman coding are given [7]. JPEG, MPEG, and H.263 also allow some sort of adaptive
in [3, Sect. F.1.2]. coding. For example, the JPEG sequential-mode encoder can
The biggest advantage of using the DCT is that it packs use up to four ac code tables, but only one table can be used for
the image data of a block into an almost optimal number of a block. MPEG and H.263 provide separate tables for intramode
decorrelated coefficients, resulting in significant compression. and intermode coding.
Nonzero DCT coefficients are generally located close to the
top/left corner of the transformed block. Further, the nonzero B. Using Multiple Code Tables
ac coefficients along the zigzag order [4, Fig. 9.3] decrease in Use of multiple code tables for DCT coding has been sug-
size and runs of zero coefficients increase in length. Thus, DCT gested in the past. For example, the author of [8] categorizes
blocks possess a different kind of statistical redundancy not DCT blocks on the basis of their ac coefficients and then uses
present in image blocks. The purpose of this paper is to exploit a different code table for each category, but still uses one table
this redundancy for further compression by modifying the per block. Our objective is different; we want to code each
Huffman coding of the JPEG baseline algorithm. Our goal is to block using multiple ac code tables, because an adaptive coding
use multiple code tables, possibly one for each ac coefficient strategy alone cannot exploit the redundancy confined within
position. each DCT block. We present the reason for using multiple
tables using a figure (Fig. 1). This figure plots the probability
of occurrences of pairs (1,1) at different positions of a DCT
Manuscript received July 19, 2002; revised October 1, 2003. This paper was block; (1,1) denotes an ac coefficient of magnitude 1 that
recommended by Associate Editor O. K. Al-Shaykh.
The author is with Texas Tech University, Lubbock, TX 79409-3104 USA
(e-mail: lakhani@cs.ttu.edu). 1Throughout this paper, reduction is measured in terms of the ac Huffman
Digital Object Identifier 10.1109/TCSVT.2004.825565 code size.

1051-8215/04$20.00 © 2004 IEEE

IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, VOL. 14, NO. 4, APRIL 2004 523

TABLE I
COMPARING JPEG CODING WITH PROPOSED CODING

0.04. The binary logarithm of the two numbers differ by
about 1/3; it means that use of table 9 in place of table 10
may increase the code size by 1/3 bit. This suboptimality
can be avoided using the following solution.
2) Change the order of and , i.e., pair a nonzero ac co-
efficient with the run-length of subsequent zero coeffi-
cients. For example, for the above sequence, the encoder
will code pairs . Clearly, after de-
coding (0,1), the decoder would have no difficulty using
the correct table for the pair (2,2).
This paper presents an implementation of the second solution.
Fig. 1. Distribution of the ac coefficient (1,1).
This solution requires developing a coding procedure, which
should also handle the following two special situations not en-
precedes exactly one zero coefficient. This pair is assigned a countered in JPEG coding: 1) coding of initial run-length of
code of length four in the default JPEG ac code table. Assuming zeros without pairing it with any nonzero coefficient, in case
optimality of Huffman code tables, the probability of this pair the block begins with zeros, and 2) coding of the last nonzero
should be , i.e., 0.0625. Fig. 1 shows that the probability coefficient of a block without pairing it with trailing zeros. The
of (1,1) varies widely and, hence, use of a single code table for next section describes this procedure. There are two advantages
all ac positions is suboptimal. of the second solution: 1) a major advantage is that the codec
Fig. 1 suggests that we should use a separate code table for can use a custom code table for each coefficient position and 2)
each position to realize optimal coding. However, it creates a a minor advantage, which is not immediately obvious, is that no
problem for the decoder, because a nonzero ac coefficient end-of-block (EOB) marker is needed to separate the code of a
is paired first with , a run of zero coefficients and then the DCT block from the next block.
pair ( ) is coded as a unit. The problem is that, without any To put the prospect of savings due to use of multiple ac code
knowledge of and hence, the position of the coefficient tables in perspective, we estimated sizes of different segments
in the DCT block, the decoder would be unable to select the of the Huffman code by compressing several continuous-toned,
code table to decode the pair correctly. To make this point photographic images of different characteristics at the default
clear, let denote ac coefficients of a block in the quality level. As per these experiments, on the average, 10.5%
zigzag order or let be the sequence of ( ) of the image code represents dc coefficients and 89.5% repre-
pairs. If the pair (1,2) is coded using code table 2, the position sent ac coefficients and EOB marker. Furthermore: 1) 34.8% of
of coefficient 2 in the DCT sequence, the decoder would fail to the ac code represents the sign/offset component and 2) 65.2%
select code table 2. There are two solutions to this problem: represents the Huffman table code. Since there is no correlation
1) Code a pair using the table that corresponds to the posi- between the sign/offset of any two coefficients, there is no scope
tion of the first zero coefficient represented by the pair. of reduction in portion 1), and any further reduction in 2) can be
If this solution is followed, the encoder will code the two obtained only by revising the ac code tables or by improving the
nonzero coefficients occurring in positions 2 and 5 in the coding procedure; both are objectives of this paper. This is also
above sequence using the tables for positions 1 and 3, re- the reason that we report only the ac Huffman table code bits
spectively, i.e., it will use nearby tables. While this solu- and not the total image code bits in this paper.
tion may be satisfactory, it is clearly suboptimal. To illus- This paper is organized as follows. Section II presents our
trate this point, consider positions 9 and 10 in Fig. 1; the DCT coding algorithm; it gives a detailed description of our
corresponding probabilities are approximately 0.05 and code tables and how they are different from the JPEG code table.


Section III presents our method of coding position-dependent It generates only if to denote the initial
code tables, which is very different from the JPEG method. To zero run-length. If , this pair is split into two or
reduce the table coding cost, it is possible not to code all tables; more pairs such as (15, 0). Likewise, if
Section III also explores this possibility. Section IV presents the , is split into multiple pairs
results of several experiments to compare the proposed coding such as (15, 0). The last pair
method with JPEG Huffman coding. denotes the last nonzero coefficient and all trailing zeros
of the block.
II. DCT COEFFICIENT CODING ALGORITHM Example 1: Let be the ac
sequence of a block. For this block, the JPEG encoder will
A. Code Table Organization
generate pairs {(0,2) (1,2) (2,1) (0,1) (0,0)}, and our encoder
We follow the Huffman coding algorithm of ac coefficients will generate {(1,2) (2,2) (0,1) (1,0)}. Thus, we generate one
[3, Annex F.1.2.2]. This algorithm can be divided in two phases: less pair if the block begins with a nonzero ac coefficient,
1) run-length coding and 2) code bit generation. We present here which is typical.
only the differences in the run-length coding phase. We repre- Example 2: Let be the ac sequence. JPEG
sent a nonzero ac coefficient followed by zeros by a pair will generate {(2, 2) (0, 0)}, and we will generate {(2,0) (2, 0)}.
( ) directly, where is the ac level of . We generate the same number of pairs, if the first ac coefficient
For 8-b images, ac coefficients are confined to [ , 1023] is zero.
and, hence, . If , we split a pair into Example 3: Let be the ac se-
multiple pairs. The net result is that our ac code tables as well quence, where denotes a run of zeros. JPEG will output
as the JPEG ac code table [3, Table K.5] can be expressed as {(15,2) (15,2) (15,0) (0,1) (13,1)}, and we will output {(15,0)
two-dimensional (2-D) matrices with representing the rows (15,2) (1,2) (15,0) (13,1) (1,0)}. Here, we generate an extra pair,
and representing the columns, and . but this happens only when a block contains a run of exactly 15
However, there are 162 entries, zeros, a rare situation.
in Table K.5, whereas our code tables
contain 176 entries, . If C. Run-Length Decoder
is nonzero, all tables are used the same way. All differences This section presents pseudocode of our decoder program and
exist in the use of column 0 entries. These are as follows: the JPEG decoder given as a flow chart in [3, Fig. F. 13]. The
1) (0,0) is a frequently used entry in Table K.5, since JPEG intent is to show that: 1) our Huffman encoder also runs in one
uses it as the EOB marker at the end of each block; we do pass like the JPEG encoder and 2) our decoder incurs no extra
not need any EOB marker. In our code table for position run-time complexity. To follow the pseudocode, let CT denote
1, (0,0) is an infrequently used entry, and it is not an entry the index of the next code table and let Decode() decode the
in other tables. next pair from the input code stream. If CT is 0, it decodes the
2) JPEG uses (15,0) to indicate a run of 16 zeros; we use the dc coefficient.
same to denote a run of 15 zeros.
3) There are no other entries of the form ( ,0) in Table K.5,
.
where ; we use them to code either the
while (not end of input)
run-length of beginning zeros, or the last nonzero ac co-
{
efficient of a block.
Decode(CT).
The examples given at the end of the next subsection show use . . .
of these entries; they are also sufficient to develop our encoder. if ( ) is (0,0) { .
. .}
B. Run-Length Coding else
Let denote the ac coefficient sequence of while ( )
a block in the zigzag order. For simplicity, let denote the {
ac level of the coefficient; therefore, . Let if
denote the positions of nonzero ac coefficients if ( or ) .
in the sequence. Our run-length encoder considers various cases else { . .}
and generates one or more pairs per nonzero ac coefficient as else { . (mod
follows. 64).}
1) If is 0, i.e., the block contains no nonzero ac coefficient, if ( ) .
it generates {(0,0), (0,0)}. }
2) If and , i.e., the only nonzero ac coefficient }
is at position 1, it generates .
3) In general, it generates The JPEG decoder program is as follows.

. . .
while ( )


TABLE II
CODE WORD SIZE TABLES FOR TWO SUCCESSIVE AC POSITIONS

{ TABLE III
if DIFFERENCE OF CODE WORDS SIZES
if ( ) .
else .
else { . (mod
64).}
if ( ) .
}

III. CODING OF HUFFMAN AC CODE TABLES To code a difference matrix, we code its columns in order
A. Differential Coding with the column first. For each column, we code first the
number of entries to be encoded from the column and then code
Our encoder should attach 63 code tables, one for each ac po-
the entries. Since most nonzero entries are located in the top/left
sition, as a part of the input to the decoder. The problem is that,
part of a difference matrix, not all columns need to be coded. The
if we code each table individually using the JPEG table coding
position of the last coded column is specified by coding a 0. For
method [3, Sect. K.3.3.2], it will cause a big overhead. There-
this reason, we encode at least one entry from each previous
fore, we developed a new method which exploits characteristics
column, even if they contain no nonzero entry.
of ac code tables for 8-b images and relationship that exists be-
Thus, for Table III, our encoder will generate the following:
tween the code tables for two successive ac positions.
We divide the Huffman code table generation procedure into
two phases: 1) computation of the code word size and 2) assign-
ment of bit sequences so that the code words form a prefix set. where denotes the Huffman code of its argument. The first
We assume that the encoder and decoder follow the same pro- four items denote that the number of entries coded from the first
cedure for phase 2 and therefore, our encoder needs to provide four columns are 3, 2, 1, and 1, respectively. The next item
only the output of the phase 1 to the decoder, i.e., the tables of denotes that no entries are coded from the remaining columns.
code word sizes of pairs ( ). The remaining items denote column entries. The argument to
For each ac position, given the frequency of pairs ( ) as is actually an unsigned integer; a signed argument simply
input, our encoder runs the Huffman code tree algorithm and denotes that the code is followed by a sign bit, e.g., is
computes the set of code word size of all pairs; the set satis- followed by bit 0. The encoder provides the code table
fies Kraft’s inequality [4]. It stores this set as a matrix of size to the decoder by encoding the corresponding code word set.
16 11. Since the maximum code word size in Table K.5 is Since the maximum number of entries in a column is 16 and an
16, we also impose this restriction and modify the code word entry of a difference matrix is an integer between and 15,
size set so that all words of size greater than 16 are set to 16 we can realize the code word set of using an array of size
and Kraft’s inequality is still satisfied. In practice, this modifi- 17. Therefore, 17 bytes is also added to the overhead cost of our
cation has virtually no effect on the optimality of the Huffman tables.
code tables. The code word size matrices posses certain charac-
teristics, which are very useful for table coding. These are: 1) B. Reduction of the Number of Code Tables
each entry is less than or equal to 16; 2) Since the frequency of Since there is an overhead cost associated with each ac code
( ) is higher for smaller and , smaller entries (i.e., more table, a goal of our encoder should be to not use a separate table
significant code words) are located in the top/left part of each for each ac position. We formulate next a minimization problem
matrix; 3) the frequency of ( ) changes very gradually with to address this issue.
the ac position, which means that entry ( ) in the matrix for Let denote the count coded at position for the
the position can be specified by coding the difference whole input image, where , , and
with the same entry of the matrix for the position, where . Let denote the code word size of in
. the code table for position . Let denote the number
To illustrate above, Table II shows sample matrices for some of bits needed to code the difference matrix for position , where
two successive ac positions. Table III is the difference matrix; the difference is taken with the code size matrix for position ,
most of its entries are zeros, which are denoted using *. . Let be an increasing sequence of integers in the


tion. The objective of the first set, given in columns 2–5 of
Table I, is to show that Table K.5 is indeed very efficient. Hence,
first we compare results of JPEG coding with some adaptive as
well as nonadaptive Huffman coding methods that also use only
one ac code table. Column 2 gives the ac table code size (in
bits) obtained by using Table K.5. Column 3 presents reduc-
tion in terms of percentage of the code size obtained by using
a custom ac code table for each image over column 2. Column
4 gives reductions obtained by dynamic Huffman coding pro-
gram of [10]. Column 5 presents results of a nonadaptive, char-
Fig. 2. AC code size and table cost. acter-mode arithmetic encoder [11], which encodes each pair
( ) as a single source symbol.
interval [1,63], which also denotes the positions of code tables The average of each column 3–5 is in the range of 1%–2%.
used by the encoder. In this situation, given an ac coefficient at The closeness of these results are sufficient to conclude that
position so that , the encoder would use the code JPEG Table K.5 is quite efficient and that the column 2 numbers
table for position , . Clearly, , , and are near minimum, provided that images are coded using only
. Let and . Given the sequence , one ac code table.
the total code size including the overhead cost of code tables can The second set of results, given in columns 6–8, is to mea-
be expressed as follows: sure the performance of the proposed coding method. Column
6 gives the ac table code size, and column 7 gives the overhead
cost in bits of all ac code tables coded by our method. Column
8 gives the percentage reduction over column 2.
Before comparing the JPEG Huffman coding with our
Since the purpose of reducing the number of code tables is to method (i.e., columns 2 or 3 with columns 6–7), we should
reduce the overhead cost, perhaps at the expense of increased point out that columns 2–3 do not include the overhead cost
ac code size, it is important that we compare the overhead cost of the code table. The number of bits needed to code the code
of the code tables with the ac code size generated at different word size set of Table K.5 as per [3, Sect. K.3.3.2] is 1432.
positions. For this purpose, in Fig. 2, we show three plots: We expect this number to be close to 1432 for a custom-code
1) ac code size generated at position by using the code table table also. Therefore, first we compare column 6 with 2 and 3
for position ; it is directly; on average, column 6 is 14.62% smaller than column
and it is labeled, CT (current table). 2 and 13.0% smaller than column 3. To consider the overhead
2) ac code size generated at position but by using the code cost as well, we add 1432 to column 2 and then compare
table for position ; in this case, the code table for with columns 6 and 7 together. In this case, the average ac
position is not coded, and the code size is computed as code reduction due to use of position-dependent code tables is
; 12.02%.
this is labeled PT (previous table). Comparing columns 7 with 6, we find that the overhead of all
3) the overhead of the table for position coded by taking 63 code tables is only 3.30% of the total ac table code size. This
the difference with the table for position ; it is means that, if we code larger images, say of size 2K 2K, this
. ratio should drop to one fourth.
These plots are given for the Lena image.
Table I presents results of high bit-rate image coding (the
Fig. 2 shows that Tcost is very small for all ac positions. It
quality level of [9] was set to 75). To compute similar results
also shows that PT is above CT at most positions. Further, for
for medium and low bit-rate coding, we compressed images by
high-frequency coefficient positions, PT and CT are near zero,
setting to 50 and 30, respectively. Since Table K.5 is known
i.e., any ac code reduction, which is obtained due to the use of
to perform poorly at lower bit rates, it was not used. Instead,
PT in the place of CT for a position, is miniscule, and it is likely
a single custom code table and position-dependent tables were
to happen for high-frequency positions only. Experimental re-
derived for each image. Results are not given for individual im-
sults given in the next section show that the overhead cost of all
ages; only the average of JPEG custom code (column 3), code
code tables constitutes only about 3.3% of the ac code size. For
using our tables (column 6), and the overhead cost (column 7)
this reason and the fact that if our encoder uses the same code
are reported here. For , these are 167423, 144359, and
table for two consecutive ac positions, this information can be
5200, respectively, and for , these are 104184, 91574,
provided to the decoder by using alone, we decided not to
and 3846. As before, we assume that it takes 1432 bits to code
develop any heuristics to solve the minimization problem stated
a single JPEG ac table. Thus, the reduction due to use of posi-
above.
tion-dependent code tables is 10.48% and 8.94% when is set
to 50 and 30, respectively. Comparing the results for
IV. EXPERIMENTAL RESULTS and , we find that the overhead cost does not drop by
To compare results of our encoder with the JPEG Huffman the same proportion as the drop in the ac code size. The reason
encoder, we present two sets of experimental results in this sec- is that it takes more bits to code tables for low-frequency posi-


tions and these tables are still coded even if the coding bit rate ac code tables. A minor advantage of our coding method is that
is low. no EOB marker is needed to represent the end of a block.
Next, we compare savings of our method with the results
given in [12], but first we give a brief summary of its method, REFERENCES
which is an adaptation of Golomb–Rice coding for DCT co- [1] W. B. Pennebaker and J. L. Mitchell, JPEG Still Image Data Compres-
efficients. In [12], the context of a DCT block is computed sion. New York: Van Nostrand Reinhard, 1993.
based on the difference of its dc coefficient with the dc of the [2] G. K. Wallace, “The JPEG still picture compression standard,” Commun.
ACM, vol. 34, pp. 30–44, Apr. 1991.
four neighboring blocks. Further, the dc range is quantized to a [3] “Digital Compression and Coding of Continuous-Tone Still Images,”,
number of levels, resulting in a large number of block contexts. ISO DIS 10 981 part 1.
Within each context, the average of each of 63 ac coefficients is [4] J. D. Gibson, T. Berger, T. Lookabaugh, D. Lingburgh, and R. L. Baker,
Digital Compression for Multimedia. San Francisco, CA.: Morgan
kept as the image is coded and this information is used to code Kaufmann, 1998.
DCT coefficients. Thus, this method also requires maintaining [5] D. E. Knuth, “Dynamic Huffman coding,” J. Algorithms, vol. 6, pp.
a large number of tables. The advantage of [12] is that no ta- 163–180, 1985.
[6] B. Jeon, J. Park, and J. Jeong, “Huffman coding of DCT coefficients
bles need to be coded as a part of the image code, which we do, using dynamic codeword assignment and adaptive codebook selection,”
but the overhead cost of our code tables is very small. On the Signal Processing; Image Commun., vol. 12, pp. 253–262, 1998.
other hand, Golomb–Rice coding is much more complex than [7] K.-Y. Yoo, J.-D. Kim, and Y.-L. Lee, “A local statistics adaptive entropy
coding method for the improvement of H.26L VLC coding,” Proc. SPIE,
Huffman coding. The work in [12] does not give reduction to vol. 4067, pp. 56–63, 2000.
ac coefficients separately. For images compressed at , [8] W. H. Chen and W. Pratt, “Sense adaptive coder,” IEEE Trans. Comm.,
it reports a reduction of about 10%. The reduction reported in vol. COM-32, pp. 225–231, 1984.
[9] Independent JPEG’s Group JPEG Software, Release 4 (1992). [Online].
Table I is thus comparable with that in [12] Available: http://www.ijg.org/
[10] M. Nelson and J. Gailly, Data Compression Book, 2nd ed. New York:
V. SUMMARY AND CONCLUSION M&T Books, 1996.
[11] A. Moffat, R. Neal, and I. Witten, “Arithmetic coding revisited,” in Proc.
In this paper, we have focused on a statistical redundancy Data Compression Conf., Mar. 1995, pp. 202–211.
[12] N. Memon, “Adaptive coding of DCT coefficients by Golomb-Rice
present in the ac sequence of DCT blocks. It is confined within codes,” in Proc. 1998 Int. Conf. Image Proc., 1998, pp. 516–520.
DCT blocks and varies locally. As a result, adaptive coding
methods such as dynamic Huffman coding or arithmetic coding,
which consider global distribution of input symbols, do not ob-
tain much further reduction. To exploit this redundancy, we pro-
pose that instead of pairing a nonzero ac coefficient with the
run-length of preceding zeros, the run-length encoder should
pair it with the run-length of subsequent zeros. The major ad-
vantage of this change is that the encoder can now use a custom
code table optimized for each ac coefficient position. The pro-
posed modification does require that the encoder also include
position-dependent code tables with the image code. For this
reason, we also proposed an efficient method for encoding the

haffman coding DCT transform

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to haffman coding DCT transform (20)

More from aniruddh Tyagi (14)

Recently uploaded (20)

haffman coding DCT transform