EENG 851: Advanced Signal Processing

1
EENG 851 Advanced Signal Processing

• Class 14 Outline
• Introduction to Image Compression
• References
• Digital Image Processing by Gonzalez and Woods,
  Addison-Wesely 1993
• A Simplified Approach to Image Processing, by
  Randy Crane, Prentice Hall, 1997

2
Introduction to Image Compression
Definitions Character- A fundamental data
element in the input stream. It may be a single
letter or a pixel in an image file. Strings-
Sequences of characters. Input Stream- The
source of the uncompressed data. It may ba a
data file or some communication medium. Code
Words- The data elements used to represent the
input characters or strings. Encoding-
Compressing. Decoding (Decompression)- The
inverse of compressing.
3
Introduction to Image Compression (Cont)
A typical data compression system.
Output Data Stream
Input Data Stream
Data Storage or Transmission
Encoder
Decoder
4
Run Length Encoding
One of the simplest data compression techniques
that takes advantage of repetitive data. E.g.,
some images have large areas of constant color.
These repeating characters are called runs. The
encoding technique is simple. A run is
represented with a count and the original
character. E.g., a source string of
AAAABBBBBCCCCCCCCDEEEE could be represented as
4A5B8C1D4E and the compression ratio is
5
Run Length Encoding (Cont)
For this hand selected ASCII string we get good
results. How about a string of English text?
My Dog Has Fleas. It would be encoded
as 1M1y1D1o1g1H1a1s1F1l1e1a1s which represents
13 characters with 26 characters for a
compression ratio of 1/2, I.e we have actually
increased our original data length by a factor of
2. We need a better method! Represent unique
strings of data with the original data and
run length encode only repetitive data. Now we
need a special prefix character to identify runs.
Runs are now represented as the
special character followed by the count followed
by the data character.
6
Run Length Encoding (Cont)
If we use as our special prefix character,
then ABCDDDDDDDDEEEEEEEEE would be encoded as
ABC8D9E achieving a CR of 20/9. Since it
takes 3 bytes to encode a run of data, it does
not make sense to encode runs of three or less.
One problem occurs if the special prefix
character appears in the text. This special case
must be encoded as a run of length 1, I.e.1.
Since this expands the data by a factor of 3,
pick a special character that is rarely used.
7
Run Length Encoding (Cont)
These examples used ASCII strings, but the same
principles apply equally well to image data. The
separate red, green and blue channels can be
encoded separately or combined as a stream of RGB
pixel values. RLE works well for images with
solid backgounds. For natural images, it
doesnt work as well. It doesnt work well
with English text since we need runs of length 4
or more to take advantage of the technique.
8
Huffman Coding

• A method that would achieve better results is
  one that
• uses fewer bits to represent the most frequently
  occurring data.
• Data that occurs less frequently would require
  more bits.
• This variable length coding is the idea behind
  Huffman Codes.
• Huffman variable length codes can achieve higher
  
• density than fixed length codes if the characters
  differ in
• frequency of occurrence. The length of the
  encoded character
• is inversely proportional to the characters
  frequency.
• Huffman codes are similar to Morse codes. Morse
• codes use few dots and dashes for the most
  frequently occurring
• letters.
• E is represented by one dot
• T by one dash.
• Q by dash dash dot dash

9
Huffman Coding (Cont)
Huffman codes are created by analyzing the data
set and assigning short bit streams to the data
occurring most frequently. The algorithm attempts
to create codes that minimize the average number
of bits per character. See Table 9.1. As
expected, E and T had the highest frequency and
the shortest Huffman Code. Encoding is simple,
e.g. the word toupee would be just a matter of
stringing together appropriate bit strings
T O U P E E
111 0100 10111 10110 100 100 One ASCII
character arequires 8 bits, the original 48 bits
have been coded with 23 bits giving a compression
ratio of
10
Huffman Coding (Cont)
Table 9.1
11
Huffman Coding (Cont)
The code creation process consists of creating a
binary tree (see figure 9.4). Start at the root
and trace the branches down to the character.
Each branch to the right represents a 1, and to
the left a 0. E.g. The code for R is found by
going left-right-right-right yielding 0111. The
binary tree approach insures that our codes have
the prefix property. This means that one code
cannot be the prefix of any other. If e was 01,
we could not encode any other character beginning
with 01, say 01001.. As soon as your decoder saw
01 it would output an e and start the next decode
with 001.. This has dire consequences. A single
bit in error to the decoder invalidates all
subsequent data. All variable length codes must
have the prefix property.
12
Huffman Coding (Cont)
Figure 9.4
13
Huffman Coding (Cont)
The first step in creating Huffman codes is to
create an array of character frequencies, I.e.
create a histogram. The binary tree can easily
be constructed by recursively grouping the lowest
frequency characters and nodes. 1. All
characters are initially considered free nodes 2.
The two free nodes with the lowest frequency are
assigned to a parent node with a weight
equal to the sum of the two free child
nodes. 3. The two child nodes are removed from
the free nodes list. The newly created
parent node is added to the list. 4. Steps 2 and
3 are repeated until there is only one free node
left. This free node is the root of the
tree.
14
Huffman Coding (Cont)
If you run into two unique characters with the
same frequency, it doesnt matter what you use
for your tie breaking scheme as long as
consistency is maintained between the encoder and
decoder. Consider the 8-by-8 pixel image, figure
9.5. Note that JPEG encoding breaks images into
8x8 subimages. The letters represent the colors
red, green, cyan, magenta, yellow, blue and
black. Before building a binary tree, the
frequency table bust be generated 19 17 16
5 4 2 1 R K G B C M
Y Step1. All the values are free nodes.
15
Huffman Coding (Cont)
Figure 9.5.
16
Huffman Coding (Cont)
Step2 The two lowest frequency nodes are assigned
to a parent node with weight equal to the sum of
the two free child nodes, I.e. 19 17 16
5 4 3 R K G B C
(MY) Step3 19 17 16 5 7 R K
G B (CMY)
17
Huffman Coding (Cont)
Step4 19 17 16 12 R K G (BCMY)
18
Huffman Coding (Cont)
Step5 19 17 28 R K (GBCMY)
19
Huffman Coding (Cont)
Step 6 19 45 R (KGBCMY)
20
Huffman Coding (Cont)
Step 7 64 (RKGBCMY) We can now generate
the code R0 K11 G100 B1011 C10100 M101010 Y
101011 Is this a good code and is there
any alternative?
21
Huffman Coding (Cont)
22
Huffman Coding (Cont)
Step 7a 64 (RKGBCMY) We can now
generate the code R00 K01 G10 B111 C1100 M1
1010 Y11011 Is this a better code?
23
Huffman Coding (Cont)
24
Huffman Coding (Cont)

• Keep in mind that variable length codes are
• More difficult to manipulate with software
• You are working at the bit level instead of the
  word level. Computer
• instructions are designed to work at the byte
  and multiple byte level.
• Objects of variable bit length increase
  complexity.
• One corrupted bit will wipe out the rest of the
  data.
• There is no way to know where the next code
  word begins.
• Huffman Codes require two passes over the data.
  The first pass to
• acquire the frequency data and generate a LUT.
  The second pass to
• compress the data.

25
Huffman Coding (Cont)
One way to eliminate a pass is to always use a
fixed table. However, this table cannot be
optimized for every data set. The Modified
Huffman Code uses fixed tables. The decoder
must use the same binary tree as the
encoder. Providing the tree to the decoder
requires using a standard treee that may not be
optimum. Another option is to store the binary
treee with the data. Or, the character frequency
could be stored and the decoder could regenerate
the tree. This would increase the decoding time
and decrease the compression ratio.
26
Modified Huffman Coding
The Modified Huffman Code has overcome the
problem of losing data when one bit gets
corrupted. It is used in FAX machines to encode
black on white images (Bitmaps) and communicates
over noisy phone lines. It has a synchronization
mechanism to minimize data loss to one scan
line. It combines the variable length codes of
Huffman with run length encoding. Since
facsimile transmissions are typically black text
or writing on white background, only one bit is
required to represent each pixel or sample. The
runs of white bits and black bits are counted and
the counts are sent as variable length bit
streams. .
27
Modified Huffman Coding (Cont)

• The encoding scheme is fairly simple.
• Each line is coded as a series of alternating
  runs of white and
• black bits.
• Runs of 63 or less are coded with a terminating
  code.
• Runs of 64 or more require that a makeup code
  prefix the
• terminating code.
• The makeup codes are used to describe runs in
  multiples of 64 from
• 64 to 2560. Note that a Huffman code would
  normally require
• encoding all2560 possibilities. This reduces
  the size of the Huffman
• code tree and accounts for the term modified.

28
Modified Huffman Coding (Cont)
Studies show that most Faxes are 85 white, so
the Huffman codes have been optimized for long
runs of white and short runs of black. The
protocol assumes the line begins with a run of
white. The encoding then alternates between
black and white bits to the end of the line.
Each scan ends with a special EOL character
consisting of eleven zeros and a 1
(000000000001). The EOL character doubles as an
errory recovery code. Since there is no other
combination of codes that has more than
seven zeros in succession. A decoder seeing
eight will recognize the EOL and continue
scanning for a 1. Upon receiving the 1, it
will then start a new line. If bits in a scan
get corrupted, the most that will be lost is the
rest of the line If the EOL code gets
corrupted, the most that will be lost is the next
line.
29
Modified Huffman Coding (Cont)
Table 9.4
30
Modified Huffman Coding (Cont)
Table 9.4 Terminating codes 0 00110101 00001101
11 32 00011011 000001101010 1 000111 010 33 00
010010 000001101011 2 0111 11 34 00010011 0000
11010010 3 1000 10 35 00010100 000011010011 4 1
011 011 36 00010101 000011010100 5 1100 0011
37 00010110 000011010101 6 1110 0010 38 0001011
1 000011010110 7 1111 00011 39 00101000 000011
010111 8 10011 000101 40 00101001 000001101100
9
31
Modified Huffman Coding (Cont)
Table 9.5
32
Modified Huffman Coding (Cont)
1275 pixel line
.
0 white 00110101 1 black 010 4 white 1011 2 black
11 1 white 0111 1 black 010 1266 white 0110110000
1010011 (121650) eol 000000000001
Figure 9.7
33
Image Example
Figure 6.2 (a) and (b) (GW)
34
Image Example(Cont)
Figure 6.2 (c) and (d) (GW)
35
Image Example(Cont)
Figure 6.2 (e) and (f) (GW)
36
Run Length Coding Example
Figure 6.3 (a) and (b) (GW)
37
Run Length Coding Example(Cont)
Figure 6.3 (c) and (d) (GW)
38
Run Length Coding Example(Cont)
Figure 6.3 (c) and (d) (GW)
39
Modified Huffman Coding (Cont)