2. Text Compression 강강 강강 (2 강 )
Jan 12, 2016
2. Text Compression
강의 노트 (2 주 )
2
압축이 필요한 이유• 이유
– 컴퓨터 하드웨어 발전 필요한 자료의 양의 증가 속도 ( 통신 , 저장 ) ::: 따라잡을 수 없음 : Parkinson’s Law
– 인터넷 홈페이지 – 새로운 응용 멀티미디어 , Genome, 전자도서관 ,
전자상거래 , 인트라넷 – 압축이 되면 처리 속도도 빨라진다 !!!!
• 하드디스크 접근• 통신속도
• 예부터– Morse 코드 , Braille 코드 , 속기용 자판
3
최근 • 흐름
– PC 클러스터 , RAID 일반화– 주기억장치 DB 활용– 통신속도 향상 ( 인터넷 , 내부통신 )– Network is computing!!!
• 하지만– 멀티미디어 자료 , 대용량 자료는 압축이 필요– 상대적으로 대용량 역파일의 압축 중요성은
줄었지만 , 때에 따라서는 필요
4
종류• Text compression 완벽한 원상복귀• Multi-media ::: 약간의 변화나 잡음은
허용함
5
역사 • 1950’s : Huffman coding• 1970’s Ziv Lempel(Lampel-Ziv-Welch(gif)), Arithmetic coding• English Text
– Huffman (5bits/character) – adaptive
• Ziv-Lempel (4bits/character) : 70 년대• Arithmetic coding (2bits/character)
• PPM ::: Prediction by Partial Matching– 80 년대 초– Slow and require large amount of memory– 이 후 더 효과적인 방법은 나오지 않고 속도나 MEMORY 를 줄이면서 약간
압축률은 손해보는 형태만 나옴– 0.5~1Mbytes, 0.1Mbytes 아래에서는 Ziv Lempel 이 효과적
• 영어 text 압축은 1 비트로 보며 , 그 이상은 의미적 관계나 다른 외부적 지식을 이용해야 할 것으로 봄– 문법 이용 , space 복원
6
강의 내용 Models Adaptive models Coding Symbolwise models Dictionary models Synchronization Performance comparison
7
크게 분류• 방법
– Symbol-wise method– Dictionary method
• 압축– Models
• static adaptive
– Coding
8
Symbol-wise methods
– Estimating the probabilities of symbols• Statistical methods
– Huffman coding or arithmetic coding– Modeling : estimating probabilities – Coding: converting the probabilities into bits
treams
9
Dictionary methods
• Code references to entries in the dictionary• Several symbols as one output codeword • Group symbols dictionary • Ziv-Lempel coding by referencing (pointing) pre
vious occurrence of strings adaptive
• Hybrid schemes 효율은 symbol-wise schemes 보다 좋지 않으나 속도 증가
10
Models prediction
- To predict symbols, which amounts to providing a probability distribution for the next symbol to be coded
- 모델의 역할 : coding & decoding Information Content
I(s) = -log Pr[s] (bits) 확률분포의 entropy: Claude Shannon
H = Pr[s]·I(s) = - Pr[s]·logPr[s](a lower bound on compression)
Entropy 가 0 에 수렴하면 압축 가능성은 극대화 됨 Huffman coding 은 성능이 나빠진다 !!! 이유 ???
Zero probability, Entropy 가 극단적으로 크면 ( 확률이 0 이면 ), 코드로 표현이 불가능해 진다 .
11
Pr[]
• 확률이 ‘ 1’ 이면 전송이 필요 없다• 확률이 ‘ 0’ 이면 coding 될 수 없다 • ‘u’ 의 확률이 2% 이면 5.6bits 필요• ‘q’ 다음에 ‘ u’ 가 95% 확률로 나오면
0.074bits 필요 잘못 예측하면 추가의 bit 가 소요 !!!
12
Model 의 표현finite-context model of order m
- 앞에 나온 m 개의 symbol 을 이용하여 예측 finite-state model
- [Figure 2.2]The decoder works with an identical
probability distribution- synchronization- On error, synchronization would be lost
Formal languages as C, Java- grammars, …
13
Estimation of probabilities in a Model
static modeling- 텍스트의 내용에 관계없이 항상 같은 모델 사용- 영어문서 문자가 많은 문서 , 문자가 많은 문서 모스부호 - 같은 문서 내에서도 다른 형태가 ???
semi-static (semi-adaptive) modeling- 각각의 파일마다 새로운 모델을 encoding 하는 곳에서 만들어 전송- 사전에 모델을 전송하는 비용이 모델이 복잡하면 심각할 수 있음
adaptive modeling- 좋지 않는 model 에서 시작하여 전송되어 오는 내용을 보고 model
을 바꿈- 새로운 symbol 을 만날 때마다 확률 분포가 변화
14
Adaptive models zero-order model character by character zero frequency problem
- 어떤 character( 예 , ‘z’) 가 지금까지 한 번도 나타나지 않았을 때- 128 개 ASCII 중 82 개 문자가 나오고 , 46 개가 안 나왔을 때
- 1/(46*(768,078+1)) 25.07bits- 1/(768,078+128) 19.6bits
- 큰 문서에서는 중요하지 않으나 작거나 다양한 문자를 사용 또는 문맥이 바뀔 때는 중요
higher-order model- 0-probability 는 일단 고려하지 않음- first-order model ::: 37,526(‘h’) 1,139(‘t’) 1,139/37,526 9.302%
5.05bits (0-order 보다 못함 ) 이유는 ???- second-order model ::: ‘gh’ ‘t’ (64%, 0.636bits)
다양한 형태로 변경 가능 : encoding 과 decoding 부분이 같은 모델을 쓰는 한 (synchronization)
15
adaptive modeling
• 장점• Robust, Reliable, Flexible
• 단점 • Random access is impossible • fragile on communication errors
• Good for general compression utilities but not good for full-text retrieval
16
Coding coding 의 기능
- model 에 의해 제공된 확률 분포를 바탕으로 symbol 을 어떻게 나타낼지를 결정
coding 시 주의점- 코드길이
- short codewords for likely symbols- long codewords for rare symbols- 확률분포에 따라 최저평균길이는 정해지며 , 여기에 가깝게 함
- 속도- 속도가 중요한 요소면 압축률을 어느 정도 희생
symbolwise scheme 은 coder 에 의존 사전적 방법과 다름- Huffman coding : 속도가 빠름- Arithmetic coding : 압축률이 이론적 한계에 가까움
17
Huffman Coding
static model 을 사용할 때 encoding 과 decoding 속도가 빠름
adaptive Huffman coding - memory 나 시간이 많이 필요
full-text retrieval application 에 유용- random access 가 용이
18
Examples
• a 0000 0.05
b 0001 0.005 c 001 0.1 d 01 0.2 e 10 0.3 f 110 0.2 g 111 0.1
• Eefggfed• 10101101111111101001• Prefix-(free) code
19
Huffman coding: Algorithm
• Fig. 2.6 설명
• Fast for both encoding and decoding• Adaptive Huffman coding 도 있으나
arithmetic coding 이 오히려 나음– 궁극적으로 random access 가 불가능– 기억용량 , 속도 등에서 유리하지 않음
• Words-based approach 와 결합하면 좋은 결과를 줌
20
Canonical Huffman Coding I
a static zero-order word-level Canonical Huffman Coding : 표 2.2
Huffman code 와 같은 길이의 codeword 사용- codeword 의 길이가 긴 것부터 저장- 같은 빈도로 나타나는 단어인 단어는 자모순 - encoding 은 쉽게 코드의 길이와 같은 길이의 첫 번째 코드에서
상대적 위치와 첫번째 코드만 알면 가능- 예 ::: Table 2.2 에서 ‘ said’ 는 7bit 짜리 중에서 10 번째 ,
첫번째 코드 ‘ 1010100’ ‘1010100’+’1001’ = ‘1011101`
21
Canonical Huffman Coding II
Decoding : 심벌을 Codeword 의 순서대로 저장 + 코드길이에 따른 첫번 째 코드1100000101… 7bits(‘1010100), 6bits(11000
1) … 7bits 에서 12 번째 뒤 (with) decoding tree 를 사용하지 않음
22
Canonical Huffman Coding III
• Word와 확률만 정해지면 유일함• 표 2.3 참고• Canonical Huffman code 는 Huffman algorithm 에 의해 만들어
지지 않을 수 있다 !!!!!!! any prefix-free assignment of codewords where the length of ea
ch code is equal to the depth of that symbol in a Huffman tree
• Huffman 이 말한 바에 따르면 알고리즘이 바뀌어야 한다 !!!! 코드 길이를 계산하는 것으로 !!! – n 개 symbol 에 대해 2n-1 – 그 중 한 개가 canonical Huffman code
23
Canonical Huffman code IV
• 장점– Tree 를 만들 필요가 없으므로 memory 절약– Tree 를 찾을 필요가 없으므로 시간 절약
• 코드길이를 먼저 알고 , 위치를 계산하여 코드 값을 부여한다… 방법 설명 – – 긴 것 부터 !!! 1씩 더하면 !!!! 길이에 맞게 자르면 !!!! – [ 바로 큰 길이 첫 번째 코드 + 동일 코드 개수 ] 를 길이만큼 잘라 +1] 을 하면 됨
– ( 예 ) 5bits 4, 3bits 1, 2bits 3 00000, 00001,00010, 001, 01, 10, 11
24
알고리즘 • 단순히 tree 를 만들면 24n bytes
– 값 , pointer (2 개 )– Intermediate node + leaf node 2n
• 8n bytes 알고리즘– Heap 의 사용– 2n 개 정수 array– 알고리즘은 직접 쓰면서 설명
• 코드길이 계산
25
Arithmetic Coding
평균적으로 엔트로피보다 짧게 압축하기는 불가능 복잡한 model 을 사용하여 높은 압축률 얻음
- entropy 에 근접한 길이로 coding 한 symbol 을 1bit 이하로 표현 가능 특히 한 sy
mbol 이 높은 확률로 나타날 때 유리 tree 를 저장하지 않기 때문에 적은 메모리 필요 static 이나 semi-static application 에서는 Huffman c
oding 보다 느림 random access 어려움
26
Huffman Code 와 Arithmetic Code
Huffman Coding Arithmetic Coding Static model에 유리 Adaptive model 에 유리 아무리 높은 확률의 symbol 이라도 최소 한 bit 이하로 압축할 수 없다. – 해결책 : blocking 구현이 어렵다.
확률이 높은 symbol 을 적은 bit로 표현 가능하다.
많은 메모리 필요 : decoding tree를 저장
적은 메모리 필요 : tree 를 저장하지 않음
빠른 속도 : 미리 계산된 확률, 미리 정해진 codeword
느린 속도 : 실시간 확률과 range 계산
Random access 가능 Random access 어려움 full-text retrieval에서 text 압축에 사용됨
full-text retrieval 에서 image 압축에 사용됨
27
실제 예• 0.99, 0.01 의 확률로 두 심볼이 나올 때
– Arithmetic coding: 0.015bit– Huffman coding: (symbol 당 inefficiency)
Pr(s1)+log(2log2/e) ~ Pr[s1]+0.086 ( 여기서 s1 은 가장 빈도가 높은 심볼 ) : 1.076bits
• 영어문서 entropy : 5bits per character (0-order character level)– 공백문자 비중 : 0.18 0.266– 0.266/5bits 5.3% 의 inefficiency
• 이미지 : 주로 2 가지 symbol arithmetic coding
28
Transmission of output
• low = 0.6334 high = 0.6667– ‘6’, 0.334 0.667
• 32bit precession 으로 크게 압축률 감소는 없음
29
Arithmetic Coding (Static Model)
{ a, b, EO F } set 로 이 루 어 진 에 서 "bbaa" .를 압 축 한 다 Pr[ a] = 0.4, Pr[ b] = 0.5, Pr[ EO F] = 0.1
EO F
1.0
ba
0.4 0.90.0
EO F
0.9
ba
0.6 0.850.4
EO F
0.4
ba
0.16 0.360.0
EO F
0.7
ba
0.64 0.690.6
EO F
0.85
ba
0.7 0.8250.6
b : low = 0.4 high = 0.9입 력 Prefix =
b : low = 0.6 high = 0.85입 력 Prefix =
EO F : low = 0.36 high = 0.4입 력 Prefix =
a : low = 0.6 high = 0.64입 력 Prefix = 6
a : low = 0.6 high = 0.7입 력 Prefix =
O utput : 6
O utput : 36
30
Decoding(Static Model)
EO F
1.0
ba
0.4 0.90.0
EO F
0.9
ba
0.6 0.850.4
EO F
0.4
ba
0.16 0.360.0
EO F
0.7
ba
0.64 0.690.6
EO F
0.85
ba
0.7 0.8250.6
6 입 력
O utput : b
O utput : a
O utput : b
O utput : a
36 입 력
31
Arithmetic Coding (Adaptive Model)
{ a, b, EO F } set 로 이 루 어 진 에 서 "bbaa" . .를 압 축 한 다 초 기 확 률 은 다 음 과 같 다 Pr[ a] = 0.333, Pr[ b] = 0.333, Pr[ EO F] = 0.333
EO F
1.0
a
0.333 0.6660.0
EO F
0.666
a
0.4165 0.58320.333
EO F
0.2959
ba
0.2211 0.27720.165
EO F
0.498
b
0.2959 0.44250.165
EO F
0.5832
b
0.4498 0.54980.4165
b : Pr[ a] = 입 력1/ 4, Pr[ b] =2/ 4, Pr[ EO F] = 1/ 4
O utput : 4
O utput : 28
b
b
a
a
a : Pr[ a] = 입 력3/ 7, Pr[ b] =3/ 7, Pr[ EO F] = 1/ 7
a : Pr[ a] = 입 력2/ 6, Pr[ b] =3/ 6, Pr[ EO F] = 1/ 6
b : Pr[ a] = 1/ 5, Pr[ b] = 3/ 5, 입 력 Pr[ EO F] = 1/ 5
EO F입 력
32
Decoding(Adaptive Model)
EO F
1.0
a
0.333 0.6660.0
EO F
0.666
a
0.4165 0.58320.333
EO F
0.2959
ba
0.2211 0.27720.165
EO F
0.498
b
0.2959 0.44250.165
EO F
0.5832
b
0.4498 0.54980.4165
b
b
a
a
4 입 력
28입 력
O utput : b
O utput : a
O utput : b
O utput : a
O utput : EO F
33
Cumulative Count Calculation
• 방법 설명 – Heap – Encoding 101101 101101, 1011,
101, 1– 규칙 설명
34
Symbolwise models
Symbolwise model + coder( arithmatic, huffman )
Three Approaches
- PPM( Prediction by Partial Matching )
- DMC(Dynamic Markov Compression )
- Word-based compression
35
PPM ( Prediction by Partial Matching )
finite-context models of characters
variable-length code 이전의 code 화 된 text 와 partial matching zero-frequency problem
- Escape symbol
- PPMA: escape method A: escape symbol 을 1로
36
Escape method
• Escape method A (PPMA) count 1• Exclusion 중복되지만 사용되지 않는 것은 제외 ,
예 ) lie+s (201, 22), ?lie+s 에서 처리 179 번 lie, lie+r 19회 … 19/202 19/180
• Method C :: r/(n+r) total n, distinct symbols r, ci/(n+r) 2.5bits per character for Hardy’s book.
• Method D :: r/(2n)• Method X :: symbols of frequency 1 t1, (t1+1)/(n+t
1+1) • PPMZ, Swiss Army Knife Data Compression (SAKDC) 1991 년 , 1197 년 박사학위 논문
• 그림 2,24
37
Block-sorting compression
• 1994 년에 도입• 문서를 압축이 쉽게 변환 • Image compression discrete cosine tr
ansformation, Fourier transformation 과 비슷
• Input 이 block 단위로 나뉘어 있어야 !!!
38
DMC ( Dynamic Markov Compression )
finite state model
adaptive model - Probabilties and the structure of the finite state machine Figure 2.13
avoid zero-frequency problem
Figure 2.14
Cloning - heuristic - the adaptation of the structure of a DMC
39
Word-based Compression
parse a document into “words” and “nonwords”
Textual/Non-Textual 구분 압축 - Textual : zero-order model
suitable for large full-text database
Low Frequency Word - 비효율적 - 예 ) 연속된 Digit, Page Number
40
Dictionary Models
Principle of replacing substrings in a text with codeword
Adaptive dictionary compression model : LZ77, LZ78
Approaches
- LZ77
- Gzip
- LZ78
- LZW
41
Dictionary Model - LZ77
adaptive dictionary model
characteristic - easy to implement - quick decoding - using small amount of memory
Figure 2.16
Triples
< offset, length of phrase, character >
42
Dictionary Model - LZ77(continue)
Improve
- offset : shorter codewords for recent matches
- match length : variable length code
- character : 필요시에만 포함 (raw data 전송 )
Figure 2.17
43
Dictionary Model - Gzip
based on LZ77
hash table
Tuples
< offset, matched length >
Using Huffman code
- semi-static / canonical Huffman code
- 64K Blocks
- Code Table : Block 시작 위치
44
Dictionary Model - LZ78
adaptive dictionary model
parsed phrase reference
Tuples
- < phrase number, character >
- phrase 0 : empty string
Figure 2.19
Figure 2.18
45
Dictionary Model - LZ78(continue)
characteristic
- hash table : simple, fast
- encoding : fast
- decoding : slow
- trie : memory 사용 많음
46
Dictionary Model - LZW
variant of LZ78
encode only the phrase number
does not have explicit characters in the output
appending the fast character of the next phrase
Figure 2.20
characteristic
- good compression
- easy to implement
47
Synchronization
random access
- variable-length code
- adaptive model
synchronization point
synchronization with adaptive model
- large file -> break into small sections
impossible random access
48
Creating synchronization point
main text : consist of a number of documents
- 문서의 시작 / 끝에 추가 bit 로 길이 표시 bit offset
byte offset
- end of document symbol
- length of each document at its beginning
- end of file
49
Self-synchronizing codes
not useful or full-text retrieval
- compressed text 의 중간에서 decoding synchronizing cycle 을 찾아 decoding
- part of corrupteed, beginning is missing
motivation
fixed-length code : self-synchronizing 불가 Table 2.3
Figure 2.22
50
Performance comparisons
consideration
- compression speed
- compression performance
- computing resource
Table 2.4
51
Compression Performance
Calgary corpus
- English text, program source code, bilevel fascimile image
- geological data, program object code
Figure 2.24
Bits per character
52
Compression speed
speed dependency
- method of implementation
- architecure of machine
- compiler
Better compression, Slower program run
Ziv-Lempel based method : decoding > encoding
Table 2.6
53
Other Performance considerations
memory usage
- adaptive model : 많은 memory 사용
- Ziv-Lempel << Symbolwise model
Random access
- synchronization point