Scribd
Upload
31 views

CPS 296.3:algorithms in The Real World: Data Compression: Lecture 2.5

The document discusses data compression techniques using probability coding models. It describes how probability models generate probabilities that coders use to assign optimal prefix codes. Context can help skew probabilities to improve compression by lowering entropy. Huffman and arithmetic codes are discussed as optimal prefix codes that can adapt to changing message probabilities. The document then provides examples of specific compression algorithms like run length coding, move-to-front coding, and prediction by partial matching (PPM) that apply probability coding techniques.

Uploaded by

Rakesh Inani
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
31 views

CPS 296.3:algorithms in The Real World: Data Compression: Lecture 2.5

The document discusses data compression techniques using probability coding models. It describes how probability models generate probabilities that coders use to assign optimal prefix codes. Context can help skew probabilities to improve compression by lowering entropy. Huffman and arithmetic codes are discussed as optimal prefix codes that can adapt to changing message probabilities. The document then provides examples of specific compression algorithms like run length coding, move-to-front coding, and prediction by partial matching (PPM) that apply probability coding techniques.

Uploaded by

Rakesh Inani
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

CPS 296.

3:Algorithms in the Real World


Data Compression: Lecture 2.5

296.3

Page 1

Summary so far
Model generates probabilities, Coder uses them
Probabilities are related to information. The more
you know, the less info a message will give.
More skew in probabilities gives lower Entropy H
and therefore better compression
Context can help skew probabilities (lower H)
Average length la for optimal prefix code bound by

H la H 1

Huffman codes are optimal prefix codes


Arithmetic codes allow blending among messages
296.3

Page 2

Encoding: Model and Coder


Model
Static Part

Compress
{p(s) | s S}
Coder

Dynamic
Part

Codeword
|w| iM(s)
= -log p(s)

Message
s S
The Static part of the model is fixed
The Dynamic part is based on previous messages allows
probability distribution to change
The optimality of the code is relative to the probabilities.
If they are not accurate, the code is not going to be efficient

296.3

Page 3

Decoding: Model and Decoder


Uncompress
{p(s) | s S}
Codeword

Decoder

Model
Static Part
Dynamic
Part
Message
s S

The probabilities {p(s) | s S} generated by the model need to


be the same as generated in the encoder.
Note: consecutive messages can be from different message
sets, and the probability distribution can change

296.3

Page 4

Codes with Dynamic Probabilities


Huffman codes:
Need to generate a new tree for new probabilities.
Small changes in probability typically make small
changes to the Huffman tree.
Adaptive Huffman codes update the tree without
having to completely recalculate it.
Used frequently in practice
Arithmetic codes:
Need to recalculate the f(m) values based on current
probabilities.
Can be done with a balanced tree.

296.3

Page 5

Compression Outline
Introduction: Lossy vs. Lossless, Benchmarks,
Information Theory: Entropy, etc.
Probability Coding: Huffman + Arithmetic Coding
Applications of Probability Coding: PPM + others
Transform coding: move to front, run-length,
Context coding: fixed context, partial matching
Lempel-Ziv Algorithms: LZ77, gzip, compress, ...
Other Lossless Algorithms: Burrows-Wheeler
Lossy algorithms for images: JPEG, MPEG, ...
Compressing graphs and meshes: BBK
296.3

Page 6

Applications of Probability Coding


How do we generate the probabilities?
Using character frequencies directly does not work
very well (e.g. 4.5 bits/char for text).
Technique 1: transforming the data
Run length coding (ITU Fax standard)
Move-to-front coding (Used in Burrows-Wheeler)
Residual coding (JPEG LS)
Technique 2: using conditional probabilities
Fixed context (JBIGalmost)
Partial pattern matching (PPM)
296.3

Page 7

Run Length Coding


Code by specifying message value followed by the
number of repeated values:
e.g. abbbaacccca => (a,1),(b,3),(a,2),(c,4),(a,1)
The characters and counts can be coded based on
frequency, ensures only a few bits of overhead for
low counts such as 1.
Run length coding exploits context to skew
probabilities.

296.3

Page 8

Facsimile ITU T4 (Group 3)


Standard used by all home Fax Machines
ITU = International Telecommunications standards body
Run length encodes sequences of black+white pixels
Fixed Huffman Code for all documents. e.g.
Run length
1
2
10

White
Black
000111 010
0111
11
00111
0000100

Since alternate black and white, no need to specify but


use different codewords anyway. Why?
296.3

Page 9

Facsimile ITU T4 (Group 3)


Transform: (run length)
input : binary string
output : interleaving of run lengths of black and
white pixels
Probabilities: (on the output of the transform)
Static probabilities of each run length based on
large set of test documents.
Coding: Huffman coding

296.3

Page 10

Move to Front Coding


Transforms message sequence into sequence of integers, that
can then be probability coded
Like run-length, takes advantage of temporal locality
Probability distribution is dynamic
Start with values in a total order: e.g.: [a,b,c,d,]
For each message
output the position in the order
move to the front of the order.
e.g.: c => output: 3, new order: [c,a,b,d,e,]
a => output: 2, new order: [a,c,b,d,e,]
Probability code the output, assuming a bias for small numbers.

296.3

Page 11

BZIP
Transform 0: Embedded run length: AAAAAAA AAAA\3
Transform 1: (Burrows Wheeler) covered later
input : character string (block) 100KBto 900KB
output : reordered character string
Transform 2: (move to front)
input : character string
output : MTF numbering
Transform 3: (run length)
input : MTF numbering
output : sequence of run lengths
Probabilities: (on run lengths)
Dynamic based on counts for each block.
Coding: Originally arithmetic, but changed to Huffman in bzip2
due to patent concerns

296.3

Page 12

Residual Coding
Typically used for message values that represent
some sort of amplitude:
e.g., gray-level in an image, or amplitude in audio.
Basic Idea: guess next value based on current
context. Output difference between guess and
actual value. Use probability code on the output.
Consider compressing a stock value over time.

296.3

Page 13

JPEG-LS
JPEG Lossless (not to be confused with lossless JPEG)
Recently completed standardization process.
Codes in Raster Order. Uses 4 pixels as context:
NW N NE
W *
Tries to guess value of * based on W, NW, N and NE.
Works in two stages

296.3

Page 14

JPEG LS: Stage 1


Uses the following equation:

min( N , W )

P max( N , W )
N W NW

if NW max( N , W )
if NW min( N , W )
otherwise

Averages neighbors and captures edges. e.g.

40

40

30 40
20

40
296.3

Page 15

JPEG LS: Stage 2


Uses 3 gradients (differences): NE-N, N-NW, and
NW-W
Classifies each into one of 9 roughly equiprobable
regions.
This gives 93=729 contexts, of which only 365 are
needed because of symmetry.
Each context has a bias term that is used to adjust
the previous prediction
After correction, the residual between guessed and
actual value is found and coded using a Golomb-like
code. (Golomb codes are similar to Gamma codes.
Small values have shorter codes.)
296.3

Page 16

JPEG LS
Transform: (residual)
input : gray-level image (8 bits/pixel)
output : difference from guess at each pixel
Probabilities: (on the differences)
Static probabilities based on golomb code --something like p(n) = c/n2.
Coding: Golomb code

296.3

Page 17

Using Conditional Probabilities: PPM


Use previous k characters as the context.
Makes use of conditional probabilities
Base probabilities on counts:
e.g., if seen th 12 times followed by e 7 times, then
the conditional probability p(e|th) = 7/12.
Need to keep k small so that dictionary does not get
too large (typically less than 8).
Note that 8-gram Entropy of English is about
2.3bits/char while PPM does as well as 1.7bits/char

296.3

Page 18

PPM: Prediction by Partial Matching


Problem: What do we do if we have not seen the
context followed by the character before?
Cannot code 0 probabilities!
The key idea of PPM is to reduce context size if
previous match has not been seen.
If character has not been seen before with
current context of size 3, try context of size
2, and then context of size 1, and then no
context
Keep statistics for each context size < k

296.3

Page 19

PPM: Changing between context


How do we tell the decoder to use a smaller context?
Send an escape message. Each escape tells the
decoder to reduce the size of the context by 1.
The escape can be viewed as special character, but
needs to be assigned a probability.
Different variants of PPM use different
heuristics for the probability.

296.3

Page 20

PPM: Example Contexts


Context
Empty

Counts
A = 4
B = 2
C = 5
$ = 3

Context
A
B
C

k=2 String = ACCBACCACBA

Counts
C = 3
$ = 1
A = 2
$ = 1
A = 1
B = 2
C = 2
$ = 3

Context
AC
B
C
$
BA
C
$
CA
C
$
CB
A
$
CC
A
B
$

Counts
= 1
= 2
= 2
= 1
= 1
= 1
= 1
= 2
= 1
= 1
= 1
= 2

$ means escape, values from PPMC

296.3

Page 21

PPM: Other important optimizations


If context has not been seen before, automatically
escape (no need for an escape symbol since
decoder knows previous contexts)
Also, can exclude certain possibilities when switching
down a context. This can save 20% in final length!
For example, to code an A, send two escapes $,
then exclude possibility that character is C in zero
context list (use a count of 0 for C.)
It is critical to use arithmetic codes since the
probabilities are small.
296.3

Page 22

You might also like