Difference between revisions of "Information Theory/Compression According to Lempel, Ziv and Welch"

From LNTwww
 
(42 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
   
 
   
 
{{Header
 
{{Header
|Untermenü=Quellencodierung – Datenkomprimierung
+
|Untermenü=Source Coding - Data Compression
 
|Vorherige Seite=Allgemeine Beschreibung
 
|Vorherige Seite=Allgemeine Beschreibung
 
|Nächste Seite=Entropiecodierung nach Huffman
 
|Nächste Seite=Entropiecodierung nach Huffman
Line 9: Line 9:
 
==Static and dynamic dictionary techniques ==  
 
==Static and dynamic dictionary techniques ==  
 
<br>
 
<br>
Many data compression methods use dictionaries.&nbsp; the idea is the following:  
+
Many data compression methods use dictionaries.&nbsp; The idea is the following:  
 
*Construct a list of character patterns that occur in the text,  
 
*Construct a list of character patterns that occur in the text,  
 
*and encode these patterns as indices of the list.  
 
*and encode these patterns as indices of the list.  
  
  
This procedure is particularly efficient if certain patterns are repeated frequently in the text and this is also taken into account in the coding.&nbsp; A distinction is made here
+
This procedure is particularly efficient if certain patterns are repeated frequently in the text and if this is also taken into account in the coding.&nbsp; A distinction is made here between
*Procedure with static dictionary,
+
*procedures with static dictionary,
*Procedure with dynamic dictionary.
+
*procedures with dynamic dictionary.
  
  
 
<br><br>
 
<br><br>
$\text{(1) Procedure with static dictionary}$
+
$\text{(1) &nbsp; Procedures with static dictionary}$
  
 
A static dictionary is only useful for very special applications, for example for a file of the following form:
 
A static dictionary is only useful for very special applications, for example for a file of the following form:
  
[[File:P_ID2424__Inf_T_2_2_S1a.png|center|frame|File to edit in this section]]
+
[[File:EN_Inf_T_2_2_S1a.png|center|frame|Data file&nbsp; (rubrics:&nbsp; "Name",&nbsp; "Vorname" &nbsp; &rArr;  &nbsp; "first name",&nbsp; "Wohnort" &nbsp; &rArr;  &nbsp; "residence")]]
  
 
For example, the assignments result in
 
For example, the assignments result in
Line 30: Line 30:
 
:$$"\boldsymbol{\rm 0}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 000000} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm}
 
:$$"\boldsymbol{\rm 0}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 000000} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm}
 
"\boldsymbol{\rm 9}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001001} \hspace{0.05cm},
 
"\boldsymbol{\rm 9}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001001} \hspace{0.05cm},
"\hspace{-0.03cm}\_\hspace{-0.03cm}\_\hspace{0.03cm}" \hspace{0.1cm}{\rm (Blank)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001010} \hspace{0.05cm},$$
+
"\hspace{-0.03cm}\_\hspace{-0.03cm}\_\hspace{0.03cm}" \hspace{0.1cm}{\rm (blank)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001010} \hspace{0.05cm},$$
  
:$$"\hspace{-0.01cm}.\hspace{-0.01cm}" \hspace{0.1cm}{\rm (Punkt)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm},
+
:$$"\hspace{-0.01cm}.\hspace{-0.01cm}" \hspace{0.1cm}{\rm (point)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm},
"\hspace{-0.01cm},\hspace{-0.01cm}" \hspace{0.1cm}{\rm (Komma)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm},
+
"\hspace{-0.01cm},\hspace{-0.01cm}" \hspace{0.1cm}{\rm (comma)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm},
 
" {\rm end\hspace{-0.1cm}-\hspace{-0.1cm}of\hspace{-0.1cm}-\hspace{-0.1cm}line}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001101} \hspace{0.05cm},$$
 
" {\rm end\hspace{-0.1cm}-\hspace{-0.1cm}of\hspace{-0.1cm}-\hspace{-0.1cm}line}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001101} \hspace{0.05cm},$$
  
Line 74: Line 74:
 
{{BlaueBox|TEXT=
 
{{BlaueBox|TEXT=
 
$\text{Conclusion:}$&nbsp;  
 
$\text{Conclusion:}$&nbsp;  
In this specific application the first line can be displayed with&nbsp; $14 \cdot 6 = 84$&nbsp; Bit.  
+
In this specific application the first line can be displayed with&nbsp; $14 \cdot 6 = 84$&nbsp; bits. <br>
*In contrast, conventional binary coding would require&nbsp; $39 \cdot 7 = 273$&nbsp; bits since:
+
*In contrast, conventional binary coding would require&nbsp; $39 \cdot 7 = 273$&nbsp; bits <br> &nbsp; &nbsp; &nbsp; (because of the lowercase letters in the text, six bits per character are not sufficient here).  
*Because of the lowercase letters in the text, six bits per character are not sufficient here.  
+
*For the entire text, this results in&nbsp; $103 \cdot 6 = 618$&nbsp; bits versus&nbsp; $196 \cdot 7 = 1372$&nbsp; bits.  
*For the entire text, this results in&nbsp; $103 \cdot 6 = 618$&nbsp; Bit versus&nbsp; $196 \cdot 7 = 1372$&nbsp; Bit.  
 
 
*However, the code table must also be known to the recipient.}}
 
*However, the code table must also be known to the recipient.}}
  
  
 
<br><br>
 
<br><br>
$\text{(2) Procedure with dynamic dictionary}$
+
$\text{(2) &nbsp; Procedures with dynamic dictionary}$
  
Nevertheless, all relevant compression methods do not work with static dictionaries, but with ''dynamic dictionaries'', which are created successively only during the coding:
+
Nevertheless, all relevant compression methods do not work with static dictionaries, but with&nbsp; &raquo;'''dynamic dictionaries'''&laquo;, which are created successively only during the coding:
*Such procedures are flexible and do not have to be adapted to the application &nbsp; One speaks of ''universal source coding procedures''.
+
*Such procedures are flexible and do not have to be adapted to the application. &nbsp; One speaks of &raquo;'''universal source coding procedures'''&laquo;.
 
*A single pass is sufficient, whereas with a static dictionary the file must first be analyzed before the encoding process.
 
*A single pass is sufficient, whereas with a static dictionary the file must first be analyzed before the encoding process.
*At the sink, the dynamic dictionary is generated in the same way as for the source .&nbsp; this eliminates the need to transfer the dictionary.
+
*At the sink, the dynamic dictionary is generated in the same way as for the source.&nbsp; This eliminates the need to transfer the dictionary.
  
  
Line 93: Line 92:
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
 
$\text{Example 1:}$&nbsp;  
 
$\text{Example 1:}$&nbsp;  
The graphic shows a small section of&nbsp; $80$&nbsp; Byte of a&nbsp; [[Digital_Signal_Transmission/Applications for Multimedia Files#Pictures_in_BMP.E2.80.93Format_.281.29|BMP-File]]&nbsp; in hexadecimal representation.&nbsp; It is the uncompressed representation of a natural picture.
+
The graphic shows a small section of&nbsp; $80$&nbsp; byte of a&nbsp; [[Digital_Signal_Transmission/Applications_for_Multimedia_Files#Images_in_BMP_format|$\text{BMP file}$]]&nbsp; in hexadecimal format.&nbsp; It is the uncompressed representation of a natural picture.
  
*You can see that in this small section of a landscape image the bytes&nbsp; $\rm FF$,&nbsp; $\rm 55$&nbsp; and&nbsp; $\rm 47$&nbsp; occur very frequently.  
+
*You can see that in this small section of a landscape image the bytes&nbsp; $\rm FF$,&nbsp; $\rm 55$&nbsp; and&nbsp; $\rm 47$&nbsp; occur very frequently.&nbsp; Data compression is therefore promising.  
*Data compression is therefore promising.  
+
*But since other parts of the file or other byte combinations dominate in other image contents, the use of a static dictionary would not be appropriate here.}}
*But since other parts of the&nbsp; $\text{4 MByte}$ file or other byte combinations dominate in other image contents, the use of a static dictionary would not be appropriate here.}}
 
  
  
Line 105: Line 103:
 
For an artificially created graphic, for example a form, you could work with a static dictionary.  
 
For an artificially created graphic, for example a form, you could work with a static dictionary.  
  
We are looking at a b/w image with&nbsp; $27 × 27$&nbsp; pixels, where the mapping "black" &nbsp; ⇒ &nbsp; '''0'''&nbsp; and "white" &nbsp; ⇒ &nbsp; '''1'''&nbsp; has been agreed upon.
+
We are looking at a&nbsp; "black & white"&nbsp; image with&nbsp; $27 × 27$&nbsp; pixels, where the mapping "black" &nbsp; ⇒ &nbsp; '''0'''&nbsp; and "white" &nbsp; ⇒ &nbsp; '''1'''&nbsp; has been agreed upon.
  
*At the top (black marker) each line is described by&nbsp; $27$&nbsp; zeros.
+
*At the top&nbsp; (black marker),&nbsp; each line is described by&nbsp; $27$&nbsp; zeros.
*In the middle (blue marking), three zeros and three ones always alternate.
+
*In the middle&nbsp; (blue marker),&nbsp; three zeros and three ones always alternate.
*At the bottom (red mark), each line is delimited by&nbsp; $25$&nbsp; ones by two zeros.}}
+
*At the bottom&nbsp; (red marker),&nbsp; 25 ones per line are limited by two zeros.}}
  
 
 
 
 
==LZ77 - the basic form of the Lempel-Ziv-algorithms ==  
+
==LZ77 - the basic form of the Lempel-Ziv algorithms ==  
 
<br>
 
<br>
The most important procedures for data compression with a dynamic dictionary go back to&nbsp; [https://en.wikipedia.org/wiki/Abraham_Lempel Abraham Lempel]&nbsp; and&nbsp; [https://en.wikipedia.org/wiki/Jacob_Ziv Jacob Ziv]&nbsp; zurück.&nbsp; The entire Lempel-Ziv family&nbsp; (in the following we will use for this briefly: &nbsp; LZ procedure)&nbsp; can be characterized as follows
+
The most important procedures for data compression with a dynamic dictionary go back to&nbsp; [https://en.wikipedia.org/wiki/Abraham_Lempel $\text{Abraham Lempel}$]&nbsp; and&nbsp; [https://en.wikipedia.org/wiki/Jacob_Ziv $\text{Jacob Ziv}$].&nbsp; The entire Lempel-Ziv family&nbsp; (in the following we will use for this briefly: &nbsp; $\rm LZ$&nbsp; procedure)&nbsp; can be characterized as follows:
*Lempel-Ziv methods use the fact that often whole words, or at least parts of them, occur several times in a text.&nbsp; One collects all word fragments, which are also called&nbsp; ''phrases''&nbsp; in a sufficiently large dictionary.
+
*Lempel-Ziv methods use the fact that often whole words, or at least parts of them, occur several times in a text.&nbsp; One collects all word fragments, which are also called&nbsp; "phrases"&nbsp; in a sufficiently large dictionary.
*Contrary to the entropy coding developed before (by Shannon and Huffman), the frequency of single characters or character strings is not the basis of the compression here, so that the LZ procedures can be applied even without knowledge of the source statistics.
+
*Contrary to the entropy coding developed some years before (by Shannon and Huffman), the frequency of single characters or character strings is not the basis of the compression here, so that the LZ procedures can be applied even without knowledge of the source statistics.
*LZ compression accordingly manages with a single pass and also the source symbol range&nbsp; $M$&nbsp; and the symbol set&nbsp; $\{q_μ\}$&nbsp; with&nbsp; $μ = 1$, ... , $M$&nbsp; does not have to be known.&nbsp; This is called ''Universal Source Coding''.
+
*LZ compression accordingly manages with a single pass and also the source symbol set size&nbsp; $M$&nbsp; and the symbol set&nbsp; $\{q_μ\}$&nbsp; with&nbsp; $μ = 1$, ... , $M$&nbsp; does not have to be known.&nbsp; This is called&nbsp; &raquo;'''Universal Source Coding'''&laquo;.
  
  
We first look at the Lempel-Ziv algorithm in its original form from 1977, known as&nbsp; [https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77 LZ77]:  
+
We first look at the Lempel-Ziv algorithm in its original form from 1977, known as&nbsp; [https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77 $\rm LZ77$]:
*This works with a window that is successively moved over the text&nbsp; one also speaks of a&nbsp; ''sliding window''.  
+
[[File:EN_Inf_T_2_2_S2a_v3.png|right|frame|Sliding window with LZ77 compression]]
 +
 +
*This works with a window that is successively moved over the text &nbsp; &rArr; &nbsp; one also speaks of a&nbsp; "sliding window".  
 
*The window size&nbsp; $G$&nbsp; is an important parameter that decisively influences the compression result.
 
*The window size&nbsp; $G$&nbsp; is an important parameter that decisively influences the compression result.
  
  
[[File:P_ID2426__Inf_T_2_2_S2a_neu.png|center|frame|Sliding window with LZ77 compression]]
 
  
The graphic shows an example of the&nbsp; ''sliding windows''.&nbsp; This is divided into
+
The graphic shows an example of the&nbsp; sliding windows.&nbsp; This is divided into
*the preview buffer&nbsp; $($blue background),&nbsp; and
+
*the&nbsp; "preview buffer"&nbsp; $($blue background),&nbsp; and
*the search buffer&nbsp; $($red background, with the positions&nbsp; $P = 0$, ... , $7$ &nbsp; ⇒ &nbsp; window size&nbsp; $G = 8)$.
+
*the&nbsp; "search buffer"&nbsp; $($red background, with the positions&nbsp; <br>$P = 0$, ... , $7$ &nbsp; ⇒ &nbsp; window size&nbsp; $G = 8)$.
  
  
The edited text consists of the four words&nbsp; '''Miss''',&nbsp; '''Mission'''',&nbsp; '''Mississippi''''&nbsp; and&nbsp; '''Mistral'''', each separated by a hyphen.&nbsp; At the time in question the preview buffer contains&nbsp; '''Mississi'''.
+
The text consists of the words&nbsp; '''Miss''',&nbsp; '''Mission''',&nbsp; '''Mississippi'''&nbsp; and&nbsp; '''Mistral''', each separated by a hyphen.&nbsp; At the time under consideration the preview buffer contains&nbsp; '''Mississi'''.
*Search now in the search buffer for the best match &nbsp; ⇒ &nbsp; the string with the maximum match length&nbsp; $L$.&nbsp; This is the result for the position&nbsp; $P = 7$&nbsp; and the length&nbsp; $L = 5$&nbsp; to&nbsp; '''Missi'''.
+
*Search now in the search buffer for the best match &nbsp; ⇒ &nbsp; the string with the maximum match length&nbsp; $L$.&nbsp; This is the result for position&nbsp; $P = 7$&nbsp; and length&nbsp; $L = 5$&nbsp; to&nbsp; '''Missi'''.
*This step is then expressed by the ''triple''&nbsp; $(7,&nbsp; 5,&nbsp; $ '''s'''$)$&nbsp; expressed &nbsp; ⇒ &nbsp; general&nbsp; $(P, \ L, \ Z)$, where&nbsp; $Z =$&nbsp;'''s'''&nbsp; specifies the character that no longer matches the string found in the search buffer.
+
*This step is expressed by the triple&nbsp; $(7,&nbsp; 5,&nbsp; $ '''s'''$)$ &nbsp; ⇒ &nbsp; general&nbsp; $(P, \ L, \ Z)$, where&nbsp; $Z =$&nbsp;'''s'''&nbsp; specifies the character that no longer matches the string found in the search buffer.
*At the end the window is moved by&nbsp; $L + 1 = 6$&nbsp; character is moved to the right.&nbsp; In the preview buffer there is now&nbsp; '''sippi-Mi'',&nbsp; in the search buffer&nbsp; '''n-Missis'''&nbsp; and the encoding gives the triple&nbsp; $(2, 2,$&nbsp; '''p'''$)$.
+
*At the end the window is moved by&nbsp; $L + 1 = 6$&nbsp; character is moved to the right.&nbsp; In the preview buffer there is now&nbsp; '''sippi-Mi''',&nbsp; and in the search buffer&nbsp; '''n-Missis'''.&nbsp; <br>The encoding gives the triple&nbsp; $(2, 2,$&nbsp; '''p'''$)$.
  
  
In the following example the LZ77-coding algorithms are described in more detail.&nbsp; The decoding runs in a similar way.
+
In the following example the LZ77 coding algorithm  is described in more detail.&nbsp; The decoding runs in a similar way.
 
 
 
 
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
Line 145: Line 144:
  
 
Further is assumed:
 
Further is assumed:
*For the characters apply&nbsp; $Z ∈ \{$ '''A''',&nbsp; '''B''',&nbsp; '''C''',&nbsp; '''e''' $\}$,&nbsp; where&nbsp; '''e'''&nbsp; corresponds to the&nbsp; ''end-of-file''&nbsp; (end of the input string)
+
*For the characters apply&nbsp; $Z ∈ \{$ '''A''',&nbsp; '''B''',&nbsp; '''C''',&nbsp; '''e''' $\}$,&nbsp; where&nbsp; '''e'''&nbsp; corresponds to the&nbsp; "end-of-file"&nbsp; (end of the input string)
*The size of the preview and search buffer are&nbsp; $G = 4$ &nbsp; ⇒ &nbsp; Position&nbsp; $P ∈ {0, 1, 2, 3}$.
+
*The size of the preview and search buffer are&nbsp; $G = 4$ &nbsp; ⇒ &nbsp; position&nbsp; $P ∈ \{0, 1, 2, 3\}$.
  
[[File:P_ID2427__Inf_T_2_2_S2b_neu.png|frame|To illustrate the LZ77 encoding]]
+
[[File:EN_Inf_T_2_2_S2b.png|frame|To illustrate the LZ77 encoding]]
 
<br>
 
<br>
 
<u>Display of the encoding process</u>:
 
<u>Display of the encoding process</u>:
  
<u>Step 1 and 2</u>: &nbsp; The characters&nbsp; '''A'''&nbsp; and&nbsp; '''B'''&nbsp; are encoded by the triple&nbsp; $(0, 0,&nbsp; $ '''A'''$)$&nbsp; and&nbsp; $(0, 0,&nbsp; $ '''B'''$)$, because they are not yet stored in the search buffer. &nbsp; Then move the Sliding Window by 1.
+
<u>Step 1 and 2</u>: &nbsp; The characters&nbsp; '''A'''&nbsp; and&nbsp; '''B'''&nbsp; are encoded by the triple&nbsp; $(0, 0,&nbsp; $ '''A'''$)$&nbsp; and&nbsp; $(0, 0,&nbsp; $ '''B'''$)$, because they are not yet stored in the search buffer. &nbsp; Then move the sliding window by 1.
  
<u>step 3</u>: &nbsp; '''AB'''&nbsp; is masked by the search buffer and at the same time the still unknown character&nbsp; '''C'''&nbsp; is appended.&nbsp; After that the Sliding Window is moved three positions to the right.
+
<u>Step 3</u>: &nbsp; '''AB'''&nbsp; is masked by the search buffer and at the same time the still unknown character&nbsp; '''C'''&nbsp; is appended.&nbsp; After that the sliding window is moved three positions to the right.
  
 
<u>Step 4</u>: &nbsp; This shows that the search string&nbsp; '''BCB'''&nbsp; may also end in the preview buffer.&nbsp; Now the window can be moved four positions to the right.
 
<u>Step 4</u>: &nbsp; This shows that the search string&nbsp; '''BCB'''&nbsp; may also end in the preview buffer.&nbsp; Now the window can be moved four positions to the right.
  
<u>Step 5</u>: &nbsp; Only&nbsp; '''A'''&nbsp; is found in the search buffer and&nbsp; '''B'''&nbsp; is dropped.&nbsp; If the search buffer is larger, however,&nbsp; '''ABC'''&nbsp; could be masked together.&nbsp; For this purpose&nbsp; $G ≥ must be 7$&nbsp;.
+
<u>Step 5</u>: &nbsp; Only&nbsp; '''A'''&nbsp; is found in the search buffer and&nbsp; '''B'''&nbsp; is dropped.&nbsp; If the search buffer is larger, however,&nbsp; '''ABC'''&nbsp; could be masked together.&nbsp; For this purpose must be&nbsp; $G ≥ 7$.
  
<u>Step 6</u>: &nbsp; Likewise, the character&nbsp; '''C'''&nbsp; must be coded separately due to the buffer being too small.&nbsp; But since&nbsp; '''CA'''&nbsp; hasn't occurred before,&nbsp; would not improve the compression here&nbsp; $G = 7$&nbsp;
+
<u>Step 6</u>: &nbsp; Likewise, the character&nbsp; '''C'''&nbsp; must be coded separately due to the buffer being too small.&nbsp; But since&nbsp; '''CA'''&nbsp; hasn't occurred before,&nbsp; $G = 7$&nbsp; would not improve the compression here.
  
 
<u>Step 7</u>: &nbsp; With the consideration of the end-of-file&nbsp; ('''e''')&nbsp; together with&nbsp; '''AB'''&nbsp; from the search buffer, the encoding process is finished.
 
<u>Step 7</u>: &nbsp; With the consideration of the end-of-file&nbsp; ('''e''')&nbsp; together with&nbsp; '''AB'''&nbsp; from the search buffer, the encoding process is finished.
  
  
Before transmission, the specified triples must of course be binary coded.&nbsp; In this example you need
+
Before transmission, the specified triples must of course be binary coded.&nbsp; In this example  
*the position&nbsp; $P ∈ \{0, 1, 2, 3\}$&nbsp; two Bit&nbsp; (yellow background in the table above),
+
*the position&nbsp; $P ∈ \{0,\ 1,\ 2,\ 3\}$&nbsp; needs two bits&nbsp; (yellow background in the table above),
*the copy length&nbsp; $L$&nbsp; three bits&nbsp; (green background), so that one could also&nbsp; $L = 7$&nbsp; still be displayed,
+
*the copy length&nbsp; $L$&nbsp; needs three bits&nbsp; (green background), so that also&nbsp; $L = 7$&nbsp; could still be displayed,
*all characters are two bits&nbsp; (white background),&nbsp; for example&nbsp; '''A''' &#8594; '''00''',&nbsp; '''B''' &#8594; '''01''',&nbsp; '''C''' &#8594; '''10''',&nbsp; '''e''' ("end-of-file") &#8594; '''11'''.
+
*all characters need two bits&nbsp; (white background),&nbsp; for example&nbsp; '''A''' &#8594; '''00''',&nbsp; '''B''' &#8594; '''01''',&nbsp; '''C''' &#8594; '''10''',&nbsp; '''e''' ("end-of-file") &#8594; '''11'''.
  
  
Thus the LZ77 output sequence has a length of&nbsp; $7 - 7 = 49$&nbsp; bit, while the input sequence only needed&nbsp; $15 - 2 = 30$&nbsp; bit.}}
+
Thus the&nbsp; $\rm LZ77$&nbsp; output sequence has a length of&nbsp; $7 \cdot 7 = 49$&nbsp; bits, while the input sequence only needed&nbsp; $15 \cdot 2 = 30$&nbsp; bits.}}
  
  
 
{{BlaueBox|TEXT=
 
{{BlaueBox|TEXT=
$\text{Conclusion:}$&nbsp; '''A Lempel-Ziv compression only makes sense with large files !'''}}
+
$\text{Conclusion:}$&nbsp; '''Lempel-Ziv compression only makes sense with large files !'''}}
  
  
==The Lempel-Ziv-Variant LZ78 ==  
+
==The Lempel-Ziv variant LZ78 ==  
 
<br>
 
<br>
The LZ77-algorithm produces very inefficient output if more frequent strings are repeated only with a larger distance.&nbsp; Such repetitions can often not be recognized due to the limited buffer size&nbsp; $G$&nbsp; des&nbsp; ''Sliding Window''&nbsp;.
+
The LZ77 algorithm produces very inefficient output if more frequent strings are repeated only with a larger distance.&nbsp; Such repetitions can often not be recognized due to the limited buffer size&nbsp; $G$&nbsp; of the sliding window.
  
 
Lempel and Ziv corrected this shortcoming already one year after the release of the first version LZ77:  
 
Lempel and Ziv corrected this shortcoming already one year after the release of the first version LZ77:  
*The algorithm LZ78 uses a global dictionary for compression instead of the local dictionary (search buffer).  
+
*The algorithm&nbsp; $\rm LZ78$&nbsp; uses a global dictionary for compression instead of the local dictionary (search buffer).  
 
*The size of the dictionary allows efficient compression of phrases that have been used for a long time before.
 
*The size of the dictionary allows efficient compression of phrases that have been used for a long time before.
  
Line 189: Line 188:
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
 
$\text{Example 4:}$&nbsp;  
 
$\text{Example 4:}$&nbsp;  
To explain the LZ78 algorithm we consider the same sequence&nbsp; '''ABABCBCBAABCABe'''&nbsp; as for the LZ77-$\text{Example 3}$.
+
To explain the LZ78 algorithm we consider the same sequence&nbsp; '''ABABCBCBAABCABe'''&nbsp; as for the LZ77 $\text{Example 3}$.
 
 
[[File:Inf_T_2_2_S3_neu.png|frame|Generation of the dictionary and output at LZ78]]
 
 
 
*The graphic shows&nbsp; (with red background)&nbsp; the dictionary with index&nbsp; $I&nbsp;$&nbsp; (in decimal and binary representation, column 1 and 2)&nbsp; and the corresponding content (column 3), which is entered for coding step&nbsp; $i&nbsp;$&nbsp; (column 4).
 
 
 
 
*For LZ78 both encoding and decoding are always&nbsp; $i = I$.
 
  
 +
[[File:EN_Inf_T_2_2_S3.png|frame|Generation of the dictionary and output at LZ78]]
  
 +
The graphic shows&nbsp; (with red background)&nbsp; the dictionary
 +
*with index&nbsp; $I&nbsp;$&nbsp; (in decimal and binary representation, column 1 and 2)&nbsp;
 +
*and the corresponding content (column 3),
 +
*which is entered for coding step&nbsp; $i&nbsp;$&nbsp; (column 4).&nbsp; For LZ78 both encoding and decoding are always&nbsp; $i = I$.
 
*In column 5 you find the formalized code output&nbsp; $($Index&nbsp; $I$,&nbsp; new character&nbsp; $Z)$.
 
*In column 5 you find the formalized code output&nbsp; $($Index&nbsp; $I$,&nbsp; new character&nbsp; $Z)$.
 
 
 
*In column 6 the corresponding binary coding is given with four bits for the index and the same character assignment&nbsp; '''A''' &#8594; '''00''',&nbsp; '''B''' &#8594; '''01''',&nbsp; '''C''' &#8594; '''10''',&nbsp; '''e''' ("end-of-file") &#8594; '''11'''&nbsp; as in&nbsp; $\text{Example 3}$.
 
*In column 6 the corresponding binary coding is given with four bits for the index and the same character assignment&nbsp; '''A''' &#8594; '''00''',&nbsp; '''B''' &#8594; '''01''',&nbsp; '''C''' &#8594; '''10''',&nbsp; '''e''' ("end-of-file") &#8594; '''11'''&nbsp; as in&nbsp; $\text{Example 3}$.
 
<br clear=all>
 
<br clear=all>
Line 213: Line 208:
  
  
In this&nbsp; $\text{Example 4}$&nbsp; the LZ78 code symbol sequence thus consists of&nbsp; $8 - 6 = 48$&nbsp; Bit.&nbsp; The result is comparable to the LZ77-$\text{Example 3}$&nbsp; $(49$ Bit$)$.}}
+
In this&nbsp; $\text{Example 4}$&nbsp; the LZ78 encoded sequence thus consists of&nbsp; $8 - 6 = 48$&nbsp; bit.&nbsp; The result is comparable to the LZ77-$\text{Example 3}$&nbsp; $(49$ bit$)$.}}
  
  
 
{{BlaueBox|TEXT=
 
{{BlaueBox|TEXT=
$\text{Conclusion:}$&nbsp; Details and improvements of LZ78 will be omitted here.&nbsp; Here we refer to the&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#The_Lempel. E2.80.93Ziv.E2.80.93Welch.E2.80.93Algorithm|LZW-Algorithm]], which will be described on the following pages.&nbsp; Only this much will be said now:
+
$\text{Conclusion:}$&nbsp; Details and improvements of LZ78 will be omitted here.&nbsp; Here we refer to the&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#The_Lempel-Ziv-Welch_algorithm|$\text{LZW algorithm}$]], which will be described in the following sections.&nbsp; Only this much will be said now:
*The index&nbsp; $I$&nbsp; is uniformly represented here with four bits, whereby the dictionary is limited to&nbsp; $16$&nbsp; entries.&nbsp; By a ''variable number of bits''&nbsp; for the index one can bypass this limitation.&nbsp; At the same time one gets a better compression factor.
+
*The index&nbsp; $I$&nbsp; is uniformly represented here with four bits, whereby the dictionary is limited to&nbsp; $16$&nbsp; entries.&nbsp; By a&nbsp; "variable number of bits"&nbsp; for the index one can bypass this limitation.&nbsp; At the same time one gets a better compression factor.
*The dictionary does not have to be transmitted with all LZ variants, but is generated with the decoder in exactly the same way as on the coder side.&nbsp; The decoding is also done with LZ78, but not with LZW, in the same way as the coding.
+
*The dictionary does not have to be transmitted with all LZ variants, but is generated with the decoder in exactly the same way as on the encoder side.&nbsp; The decoding is also done with LZ78, but not with LZW, in the same way as the encoding.
*All LZ procedures are asymptotically optimal, i.e., for infinitely long sequences the mean code word length&nbsp; $L_{\rm M}$&nbsp; per source symbol is equal to the source entropy&nbsp; $H$&nbsp;.  
+
*All LZ procedures are asymptotically optimal, i.e., for infinitely long sequences the mean code word length&nbsp; $L_{\rm M}$&nbsp; per source symbol is equal to the source entropy&nbsp; $H$.  
*For short sequences, however, the deviation is considerable.&nbsp; More about this at&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#Quantitative statements on asymptotic optimality|end of chapter]].}}
+
*For short sequences, however, the deviation is considerable.&nbsp; More about this at the&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#Quantitative statements on asymptotic optimality|"end of chapter"]].}}
  
  
 
==The Lempel-Ziv-Welch algorithm ==  
 
==The Lempel-Ziv-Welch algorithm ==  
 
<br>
 
<br>
The most common variant of Lempel-Ziv compression used today was designed by&nbsp; [https://en.wikipedia.org/wiki/Terry_Welch Terry Welch]&nbsp; and published in 1983.&nbsp; In the following we refer to it as the&nbsp; ''Lempel-Ziv-Welch-Algorithm'', abbreviated as "LZW". &nbsp; Just as LZ78 has slight advantages over LZ77&nbsp; (as expected, why else would the algorithm have been modified?),&nbsp; LZW also has more advantages than disadvantages compared to LZ78.
+
The most common variant of Lempel-Ziv compression used today was designed by&nbsp; [https://en.wikipedia.org/wiki/Terry_Welch $\text{Terry Welch}$]&nbsp; and published in 1983.&nbsp; In the following we refer to it as the&nbsp; "Lempel-Ziv-Welch-Algorithm", abbreviated as&nbsp; $\rm LZW$. &nbsp; Just as LZ78 has slight advantages over LZ77&nbsp; (as expected, why else would the algorithm have been modified?),&nbsp; LZW also has more advantages than disadvantages compared to LZ78.
  
[[File:P_ID2430__Inf_T_2_2_S4_neu.png|center|frame|LZW encoding of the sequence&nbsp; '''ABABCBCBAABCABe'']]
+
[[File:EN_Inf_T_2_2_S4_v2.png|right|frame|LZW encoding of the sequence&nbsp; '''ABABCBCBAABCABe''']]
  
The graphic shows the coder output for the exemplary input sequence&nbsp; '''ABABCBCBAABCABe'''.&nbsp; On the right is the dictionary (highlighted in red), which is successively generated during LZW encoding.&nbsp; The differences to LZ78 can be seen in comparison to the graphic on the last page, namely
+
The graphic shows the coder output for the exemplary input sequence&nbsp; '''ABABCBCBAABCABe'''.&nbsp; On the right you can see the dictionary&nbsp; (highlighted in red), which is successively generated during LZW encoding.&nbsp; The differences to LZ78 can be seen in comparison to the graphic in the last section, namely:
*For LZW, all characters occurring in the text are already entered at the beginning of&nbsp; $(i = 0)$&nbsp; and assigned to a binary sequence, in the example with the indices&nbsp; $I = 0$, ... ,&nbsp; $I = 3$.&nbsp; This also means that LZW requires some knowledge of the message source, whereas LZ78 is a "true universal encoding".
+
*For LZW, all characters occurring in the text are already entered at the beginning&nbsp; $(i = 0)$&nbsp; and assigned to a binary sequence, in the example with the indices&nbsp; $I = 0$, ... ,&nbsp; $I = 3$.&nbsp;  
*For LZW, only the dictionary index&nbsp; $I$&nbsp; is transmitted for each encoding step&nbsp; $i$&nbsp; while for LZ78 the output is the combination&nbsp; $(I$,&nbsp; $Z)$,&nbsp;where $Z$&nbsp; denotes the current new character. &nbsp; Due to the absence of&nbsp; $Z$&nbsp; in the code output, LZW decoding is more complicated than with LZ78, as described on page&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#Decoding_of_LZW.E2.80.93Algorithm|Decoding of LZW&ndash;Algorithm]]&nbsp;.  
+
*This also means that LZW requires some knowledge of the message source, whereas LZ78 is a&nbsp; "true universal encoding".
+
*For LZW, only the dictionary index&nbsp; $I$&nbsp; is transmitted for each encoding step&nbsp; $i$&nbsp; while for LZ78 the output is the combination&nbsp; $(I$,&nbsp; $Z)$,&nbsp;where $Z$&nbsp; denotes the current new character. &nbsp;  
 +
*Due to the absence of&nbsp; $Z$&nbsp; in the encoder output, LZW decoding is more complicated than with LZ78, as described in section&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#Decoding_of_the_LZW_algorithm|"Decoding of the LZW algorithm"]].  
 +
<br clear=all>
  
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
$\text{Example 5:}$&nbsp; For this exemplary LZW encoding, as with "LZ77" and "LZ78" again the input sequence&nbsp; '''ABABCBCBAABCABe'''&nbsp; is assumed.&nbsp; So the following description refers to the above graphic.
+
$\text{Example 5:}$&nbsp; For this exemplary&nbsp; $\rm LZW$&nbsp; encoding, again the input sequence&nbsp; '''ABABCBCBAABCABe'''&nbsp; is assumed as with "LZ77" and "LZ78".&nbsp; So the following description refers to the above graphic.
  
<u>Step i = 0</u> (default): &nbsp; The allowed characters&nbsp; '''A''',&nbsp; '''B''',&nbsp; '''C'''&nbsp; and&nbsp; '''e'''&nbsp; ("end-of-file") are entered into the dictionary and assigned to the indices&nbsp; $I = 0$, ... , $I = 3$&nbsp;.
+
<u>Step i = 0</u>&nbsp; (default): &nbsp; The allowed characters&nbsp; '''A''',&nbsp; '''B''',&nbsp; '''C'''&nbsp; and&nbsp; '''e'''&nbsp; ("end-of-file") are entered into the dictionary and assigned to the indices&nbsp; $I = 0$, ... , $I = 3$&nbsp;.
  
<u>Step i = 1</u>: &nbsp; '''A'''&nbsp; is coded by the decimal index&nbsp; $I = 0$&nbsp; and its binary representation&nbsp; '''0000'''&nbsp; is transmitted. &nbsp; Then the combination of the current character&nbsp; '''A'''&nbsp; and the following character&nbsp; '''B'''&nbsp; of the input sequence is stored in the dictionary under the index&nbsp; $I = 4$&nbsp;.
+
<u>Step i = 1</u>: &nbsp; The character&nbsp; '''A'''&nbsp; is encoded by the decimal index&nbsp; $I = 0$&nbsp; and its binary representation&nbsp; '''0000'''&nbsp; is transmitted. &nbsp; <br>Then the combination of the current character&nbsp; '''A'''&nbsp; and the following character&nbsp; '''B'''&nbsp; of the input sequence is stored in the dictionary under the index&nbsp; $I = 4$&nbsp;.
  
<u>step i = 2</u>: &nbsp; representation of&nbsp; '''B'''&nbsp; by index&nbsp; $I = 1$&nbsp; or.&nbsp; '''0001'''&nbsp; (binary) as well as dictionary entry of&nbsp; '''BA'''&nbsp; placed under index&nbsp; $I = 5$.
+
<u>step i = 2</u>: &nbsp; Representation of&nbsp; '''B'''&nbsp; by index&nbsp; $I = 1$&nbsp; or&nbsp; '''0001'''&nbsp; (binary)&nbsp; as well as dictionary entry of&nbsp; '''BA'''&nbsp; placed under index&nbsp; $I = 5$.
  
<u>Step i = 3</u>: &nbsp; Because of the entry&nbsp; '''AB'''&nbsp; at time&nbsp; $i = 1$&nbsp; the index to be transmitted is&nbsp; $I = 4$&nbsp; (binary: '''0100''').&nbsp; New dictionary entry of&nbsp; '''ABC'''&nbsp; under&nbsp; $I = 6$.
+
<u>Step i = 3</u>: &nbsp; Because of the entry&nbsp; '''AB'''&nbsp; at time&nbsp; $i = 1$&nbsp; the index to be transmitted is&nbsp; $I = 4$&nbsp; (binary:&nbsp; '''0100''').&nbsp; New dictionary entry of&nbsp; '''ABC'''&nbsp; under&nbsp; $I = 6$.
  
<u>Step i = 8</u>: &nbsp; Here the characters&nbsp; '''ABC'''&nbsp; are represented together by the index&nbsp; $I = 6$&nbsp; (binary: '''0110''')&nbsp; and the entry for&nbsp; '''ABCA'''&nbsp; is made.
+
<u>Step i = 8</u>: &nbsp; Here the characters&nbsp; '''ABC'''&nbsp; are represented together by the index&nbsp; $I = 6$&nbsp; (binary:&nbsp; '''0110''')&nbsp; and the entry for&nbsp; '''ABCA'''&nbsp; is made.
  
 
With the encoding of&nbsp; '''e'''&nbsp; (EOF mark) the encoding process is finished after ten steps.&nbsp; With LZ78 only eight steps were needed.&nbsp; But it has to be considered:
 
With the encoding of&nbsp; '''e'''&nbsp; (EOF mark) the encoding process is finished after ten steps.&nbsp; With LZ78 only eight steps were needed.&nbsp; But it has to be considered:
*The LZW algorithm needs only&nbsp; $10 \cdot 4 = 40$&nbsp; Bit versus the&nbsp; $8 \cdot 6 = 48$&nbsp; Bit for LZ78.&nbsp; Provided that for this simple calculation, four bits each are needed for index representation.
+
*The LZW algorithm needs only&nbsp; $10 \cdot 4 = 40$&nbsp; bit versus the&nbsp; $8 \cdot 6 = 48$&nbsp; bit for LZ78.&nbsp; Provided that for this simple calculation, four bits each are needed for index representation.
*LZW as well as LZ78 require less bits&nbsp; $($namely &nbsp; $34$&nbsp; or &nbsp; $42)$, if one considers that for the step&nbsp; $i = 1$&nbsp; the index has to be coded with two bits only&nbsp; $(I ≤ 3)$&nbsp; and for&nbsp; $2 ≤ i ≤ 5$&nbsp; three bits are sufficient&nbsp; $(I ≤ 7)$.}}
+
*LZW as well as LZ78 require less bits&nbsp; $($namely &nbsp; $34$&nbsp; or &nbsp; $42)$, if one considers that for the step&nbsp; $i = 1$&nbsp; the index has to be encoded with two bits only&nbsp; $(I ≤ 3)$&nbsp; and for&nbsp; $2 ≤ i ≤ 5$&nbsp; three bits are sufficient&nbsp; $(I ≤ 7)$.}}
  
  
The following pages describe in detail the variable bit count for index representation and the decoding of LZ78- and LZW-encoded binary sequences.
+
==Lempel-Ziv coding with variable index bit length ==  
 
 
 
 
==Lempel-Ziv-Coding with variable index bit length ==  
 
 
<br>
 
<br>
For reasons of a most compact representation, we now consider only binary sources with the value set&nbsp; $\{$'''A''', '''B'''$\}$.&nbsp; The terminating character&nbsp; '''end-of-file'''&nbsp; is also not considered.  
+
For reasons of a most compact representation, we now consider only binary sources with symbol set&nbsp; $\{$'''A''', '''B'''$\}$.&nbsp; The terminating character&nbsp; &raquo;'''end-of-file'''&laquo;&nbsp; is not considered, too.  
  
[[File:P_ID2432__Inf_T_2_2_S5_neu.png|center|frame|LZW-Coding of a binary input sequence]]
+
[[File:EN_Inf_T_2_2_S5_vers2.png|right|frame|LZW encoding of a binary input sequence]]
  
We demonstrate the LZW coding by means of a screenshot of our interactive Flash module&nbsp; [[Applets:Lempel-Ziv-Welch|Lempel-Ziv-Welch&ndash;Algorithms]].  
+
We demonstrate the LZW encoding by means of a screenshot of our interactive SWF module&nbsp; [[Applets:Lempel-Ziv-Welch|"Lempel-Ziv-Welch algorithms"]].  
  
*In the first coding step&nbsp; $(i = 1)$&nbsp;  '''A'''&nbsp; &nbsp;⇒&nbsp; '''0'''.&nbsp; Afterwards the entry with index&nbsp; $I = 2$&nbsp; and&nbsp; content&nbsp; '''AB'''.
+
*In the first encoding  step&nbsp; $(i = 1)$:&nbsp;  '''A'''&nbsp; &nbsp;⇒&nbsp; '''0'''.&nbsp; Afterwards the entry with index&nbsp; $I = 2$&nbsp; and&nbsp; content&nbsp; '''AB'''.
*As there are only two entries in step&nbsp; $i = 1$&nbsp; in the dictionary (&nbsp; '''A'''&nbsp; and&nbsp; '''B'''&nbsp;) one bit is sufficient. &nbsp; On the other hand, for step&nbsp; $i = 2$&nbsp; and&nbsp; $i = 3$&nbsp; for&nbsp; '''B''' &nbsp;⇒&nbsp; '''01'''&nbsp; and &nbsp; '''A''' &nbsp;⇒&nbsp; '''00'''&nbsp; two bits are needed in each case.
+
*As there are only two dictionary entries in step&nbsp; $i = 1$&nbsp; (for&nbsp; '''A'''&nbsp; and&nbsp; '''B'''&nbsp;) one bit is sufficient. &nbsp; For step&nbsp; $i = 2$&nbsp; and&nbsp; $i = 3$&nbsp; $($'''B''' &nbsp;⇒&nbsp; '''01'''&nbsp; and &nbsp; '''A''' &nbsp;⇒&nbsp; '''00'''$)$&nbsp; two bits are needed in each case.
 
*Starting on &nbsp;$i = 4$&nbsp;, the index representation is done with three bits, then from &nbsp; $i = 8$&nbsp; with four bits and from&nbsp; $i = 16$&nbsp; with five bits.&nbsp; A simple algorithm for the respective index bit number&nbsp; $L(i)$&nbsp; can be derived.
 
*Starting on &nbsp;$i = 4$&nbsp;, the index representation is done with three bits, then from &nbsp; $i = 8$&nbsp; with four bits and from&nbsp; $i = 16$&nbsp; with five bits.&nbsp; A simple algorithm for the respective index bit number&nbsp; $L(i)$&nbsp; can be derived.
*Let's finally consider the coding step&nbsp; $i = 18$.&nbsp; Here, the sequence&nbsp; '''ABABB''' marked in red, which was entered into the dictionary at time&nbsp; $i = 11$&nbsp; at time&nbsp; $($Index&nbsp; $I = 13$ ⇒ '''1101'''$)$&nbsp; is edited. &nbsp; However, the coder output is now&nbsp; '''01101'''&nbsp;because of&nbsp; $i ≥ 16$&nbsp;  (green mark at the coder output).
+
*Let's finally consider the encoding step&nbsp; $i = 18$.&nbsp; Here, the sequence&nbsp; '''ABABB'''&nbsp; marked in red, which was entered into the dictionary at time&nbsp; $i = 12$&nbsp; at time&nbsp; $($Index&nbsp; $I = 13$ ⇒ '''1101'''$)$&nbsp; is edited. &nbsp; However, the encoder output is now&nbsp; '''01101'''&nbsp;because of&nbsp; $i ≥ 16$&nbsp;  (green mark at the encoder output).
  
  
The statements also apply to&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#The_Lempel.E2.80.93Ziv.E2.80.93Variant_LZ78|LZ78]].&nbsp; That is: &nbsp; With the LZ78 a variable index bit length results in the same improvement as with the LZW.
+
The statements also apply to&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#The_Lempel-Ziv_variant_LZ78|$\text{LZ78}$]].&nbsp; That is: &nbsp; '''With LZ78 a variable index bit length results in the same improvement as with LZW'''.
  
 
 
 
 
 
==Decoding of the LZW algorithm ==
 
==Decoding of the LZW algorithm ==
 
<br>
 
<br>
The decoder now displays the decoded output on the&nbsp; [[Information_Theory/Compression_by_Lempel,_Ziv_and_Welch#Lempel-Ziv-Coding with variable index bit length|last page]]&nbsp; as input sequence.&nbsp; The graphic shows that it is possible to uniquely decode this sequence even with variable index bit lengths. Please note:
+
The decoder now displays the decoded output in the&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#Lempel-Ziv_coding_with_variable_index_bit_length|"last section"]]&nbsp; as input sequence.&nbsp; The graphic shows that it is possible to uniquely decode this sequence even with variable index bit lengths. Please note:
  
*The decoder knows that in the first coding step&nbsp; $(i = 1)$&nbsp; the index&nbsp; $I&nbsp;$ was coded with only one bit, in the steps&nbsp; $i = 2$&nbsp; and&nbsp; $i = 3$&nbsp; with two bit, from &nbsp; $i = 4$&nbsp; with three bit, from&nbsp; $i = 8$&nbsp; with four bit, and so on.
+
#&nbsp;The decoder knows that in the first encoding step&nbsp; $(i = 1)$&nbsp; the index&nbsp; $I&nbsp;$ was encoded with only one bit, in the steps&nbsp; $i = 2$&nbsp; and&nbsp; $i = 3$&nbsp; with two bit, from &nbsp; $i = 4$&nbsp; with three bit, from&nbsp; $i = 8$&nbsp; with four bit, and so on.
*The decoder generates the same dictionary as the coder, but the dictionary entries are made one time step later.  
+
#&nbsp;The decoder generates the same dictionary as the encoder, but the dictionary entries are made one time step later.  
  
 
+
[[File:EN_Inf_T_2_2_S6.png|right|frame|LZW decoding of a binary input sequence]]
[[File:P_ID2433__Inf_T_2_2_S6_neu.png|center|frame|LZW-Decoding of a binary input sequence]]
+
<br>
 
+
*At step&nbsp; $\underline{i = 1}$&nbsp; the adjacent symbol&nbsp; '''0'''&nbsp; is decoded as&nbsp; '''A'''. &nbsp; Likewise, the following results for step&nbsp; $\underline{i = 2}$&nbsp; from the preassignment of the dictionary and the two-bit representation agreed upon for this: &nbsp; '''01''' &nbsp; ⇒ &nbsp; '''B'''.
*At step&nbsp; $\underline{i = 1}$&nbsp; the adjacent symbol&nbsp; '''0'''&nbsp; is decoded as&nbsp; '''A'''&nbsp;. &nbsp; Likewise, the following results for step&nbsp; $\underline{i = 2}$&nbsp; from the preassignment of the dictionary and the two-bit representation agreed upon for this: &nbsp; '''01''' &nbsp; ⇒ &nbsp; '''B'''.
+
*The entry of the line&nbsp; $\underline{I = 2}$&nbsp; $($content: &nbsp; '''AB'''$)$&nbsp; of the dictionary is therefore only made at the step&nbsp; $\underline{i = 2}$, while at the&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#Lempel-Ziv_coding_with_variable_index_bit_length|$\text{encoding process}$]]&nbsp; this could already be done at the end of step&nbsp; $i = 1$.
*The entry of the line&nbsp; $\underline{I = 2}$&nbsp; $($content: &nbsp; '''AB'''$)$&nbsp; of the dictionary is therefore only made at the step&nbsp; $\underline{i = 2}$, while at the&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#Lempel-Ziv-Coding with variable index bit length|Coding process]]&nbsp; this could already be done at the end of step&nbsp; $i = 1$&nbsp;.
+
*Let us now consider the decoding for&nbsp; $\underline{i = 4}$. &nbsp; The index&nbsp; $\underline{I = 2}$&nbsp; returns the decoding result&nbsp; '''010''' &nbsp; ⇒ &nbsp; '''AB'''&nbsp; and in the next step&nbsp; $(\underline{i = 5})$&nbsp; the dictionary line&nbsp; $\underline{I = 5}$&nbsp; will be filled with&nbsp; '''ABA'''.&nbsp;
*Let us now consider the decoding for&nbsp; $\underline{i = 4}$. &nbsp; The index&nbsp; $\underline{I = 2}$&nbsp; returns the decoding result&nbsp; '''010''' &nbsp; ⇒ &nbsp; '''AB'''&nbsp; and in the next step&nbsp; $(\underline{i = 5})$&nbsp; the dictionary line&nbsp; $\underline{I = 5}$&nbsp; will be filled with&nbsp; '''ABA'''&nbsp;.
 
 
*This time difference with respect to the dictionary entries can lead to decoding problems.&nbsp; For example, for step&nbsp; $\underline{i = 7}$&nbsp; there is no dictionary entry with index&nbsp; $\underline{I= 7}$.
 
*This time difference with respect to the dictionary entries can lead to decoding problems.&nbsp; For example, for step&nbsp; $\underline{i = 7}$&nbsp; there is no dictionary entry with index&nbsp; $\underline{I= 7}$.
 
*What is to do in such a case as&nbsp; $(\underline{I = i})$?&nbsp; In this case you take the result of the previous decoding step&nbsp; $($here: &nbsp; '''BA'''&nbsp; for&nbsp; $\underline{i = 6})$&nbsp; and append the first character of this sequence at the end again. &nbsp; This gives the decoding result for&nbsp; $\underline{i = 7}$&nbsp; to&nbsp; '''111''' &nbsp; ⇒ &nbsp; '''BAB'''.
 
*What is to do in such a case as&nbsp; $(\underline{I = i})$?&nbsp; In this case you take the result of the previous decoding step&nbsp; $($here: &nbsp; '''BA'''&nbsp; for&nbsp; $\underline{i = 6})$&nbsp; and append the first character of this sequence at the end again. &nbsp; This gives the decoding result for&nbsp; $\underline{i = 7}$&nbsp; to&nbsp; '''111''' &nbsp; ⇒ &nbsp; '''BAB'''.
*Naturally, it is unsatisfactory to specify only one recipe.&nbsp; In the&nbsp; [[Aufgaben:Aufgabe_2.4Z:_Nochmals_LZW-Codierung_und_-Decodierung|Exercise 2.4Z]]&nbsp; you should justify the procedure demonstrated here.&nbsp; We refer to the sample solution for this exercise.
+
*Naturally, it is unsatisfactory to specify only one recipe.&nbsp; In the&nbsp; [[Aufgaben:Aufgabe_2.4Z:_Nochmals_LZW-Codierung_und_-Decodierung|"Exercise 2.4Z"]]&nbsp; you should justify the procedure demonstrated here.&nbsp; We refer to the sample solution for this exercise.
  
  
With LZ78 decoding, the problem described here does not occur because not only the index&nbsp; $I&nbsp;$ but also the current character&nbsp; $Z$&nbsp; is included in the encoding result and is transmitted.
+
With LZ78 decoding, the problem described here does not occur because not only the index&nbsp; $I&nbsp;$&nbsp; but also the current character&nbsp; $Z$&nbsp; is included in the encoding result and is transmitted.
 
 
 
 
 
   
 
   
==Remaining redundancy as a measure for the efficiency of encoding methods==
+
==Remaining redundancy as a measure for the efficiency of coding methods==
 
<br>
 
<br>
 
For the rest of this chapter we assume the following prerequisites:
 
For the rest of this chapter we assume the following prerequisites:
*The&nbsp; ''symbol range''&nbsp; the source&nbsp; $($or in the transmission sense: &nbsp; the number of stages)&nbsp; sei&nbsp; $M$, where&nbsp; $M$&nbsp; represents a power of two &nbsp; ⇒ &nbsp; $M = 2, \ 4, \ 8, \ 16$, ....
+
*The source symbol set size&nbsp; $($or in the transmission sense: &nbsp; the number of levels )&nbsp; is&nbsp; $M$, where&nbsp; $M$&nbsp; represents a power of two &nbsp; ⇒ &nbsp; $M = 2, \ 4, \ 8, \ 16$, ....
*The source entropy is&nbsp; $H$.&nbsp; If there are no statistical bonds between the symbols and if they are equally probable, then&nbsp; $H = H_0$, where&nbsp; $H_0 = \log_2 \ M$&nbsp; indicates the decision content.&nbsp; Otherwise, $H < H_0$ applies.
+
*The source entropy is&nbsp; $H$.&nbsp; If there are no correlations between the symbols and if they are equally probable, then&nbsp; $H = H_0 = \log_2 \ M$.&nbsp; Otherwise, $H < H_0$ applies.
*A symbol sequence of length&nbsp; $N$&nbsp; is source-coded and returns a binary code sequence of length&nbsp; $L$.&nbsp; For the time being we do not make any statement about the type of source coding.
+
*A symbol sequence of length&nbsp; $N$&nbsp; is source-coded and returns a binary encoded sequence of length&nbsp; $L$.&nbsp;  
 +
*For the time being we do not make any statement about the type of source coding.
  
  
 
+
According to the&nbsp; [[Information_Theory/General_Description#Source_coding_theorem|$\text{Source Coding Theorem}$]]&nbsp; the average code word length&nbsp; $L_{\rm M}$&nbsp; must be greater than or equal to the source entropy&nbsp; $H$&nbsp; (in bit/source symbol).&nbsp; This means
According to the&nbsp; [[Information_Theory/General_Description#Source Encoding Theorem|Source Encoding Theorem]]&nbsp; the mean code word length&nbsp; $L_{\rm M}$&nbsp; must be greater than or equal to the source entropy&nbsp; $H$&nbsp; (in bit/source symbol).&nbsp; This means
+
*for the total length of the source-coded binary sequence:
*for the total length of the source-encoded binary sequence:
 
 
:$$L \ge N \cdot H \hspace{0.05cm},$$  
 
:$$L \ge N \cdot H \hspace{0.05cm},$$  
*for the relative redundancy of the code sequence, in the following called&nbsp; '''Rest Redundancy''':
+
*for the relative redundancy of the coded sequence, in the following called&nbsp; &raquo;'''residual redundancy'''&laquo;:
 
:$$r = \frac{L - N \cdot H}{L} \hspace{0.05cm}.$$
 
:$$r = \frac{L - N \cdot H}{L} \hspace{0.05cm}.$$
  
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
$\text{Example 6:}$&nbsp; If there were a&nbsp; ''perfect source encoding'' for a redundancy-free binary source symbol sequence&nbsp; $(M = 2,\ p_{\rm A} = p_{\rm B} = 0.5$,&nbsp; without statistical bonds$)$&nbsp; of length&nbsp; $N = 10000$, the code sequence would have length&nbsp; $L = 10000$.  
+
$\text{Example 6:}$&nbsp; If there were a&nbsp; "perfect source coding"&nbsp; for a redundancy-free binary source sequence&nbsp; $(M = 2,\ p_{\rm A} = p_{\rm B} = 0.5$,&nbsp; without memory$)$&nbsp; of length&nbsp; $N = 10000$, the encoder sequence would have also the length&nbsp; $L = 10000$.  
  
<u>Consequence:</u> &nbsp; If in a code the result&nbsp; $L = N$&nbsp; is never possible, then this code is called&nbsp; ''not&ndash;perfect''.
+
<u>Consequence:</u> &nbsp; If in a code the result&nbsp; $L = N$&nbsp; is never possible, then this code is called&nbsp; "not&ndash;perfect".
*Lempel-Ziv is not suitable for this redundancy-free message source.&nbsp; It will always be&nbsp; $L > N$&nbsp; &nbsp; You can also put it quite succinctly like this: &nbsp; The perfect source encoding here is "no encoding at all".
+
*Lempel-Ziv is not suitable for this redundancy-free message source.&nbsp; It will always be&nbsp; $L > N$.&nbsp; You can also put it quite succinctly like this: &nbsp; The perfect source coding here is "no coding at all".
*A redundant binary source with &nbsp;$p_{\rm A} = 0.89$,&nbsp; $p_{\rm B} = 0.11$ &nbsp; ⇒ &nbsp; $H = 0.5$&nbsp; could be represented with a perfect source encoding with&nbsp;$L = 5000$&nbsp; bit, without being able to say what this perfect source encoding looks like.
+
*A redundant binary source with &nbsp;$p_{\rm A} = 0.89$,&nbsp; $p_{\rm B} = 0.11$ &nbsp; ⇒ &nbsp; $H = 0.5$&nbsp; could be represented with a perfect source coding with&nbsp;$L = 5000$,&nbsp; without being able to say what this perfect source coding looks like.
*For a quaternary source,&nbsp; $H > 1 \ \rm (bit/source symbol)$&nbsp; is possible, so that even with perfect source encoding there will always be&nbsp; $L > N$&nbsp;.&nbsp; If the source is redundancy-free&nbsp; (no bonds, all&nbsp; $M$&nbsp; symbols equally probable), it has entropy&nbsp; $H= 2 \ \rm (bit/source symbol)$.
+
*For a quaternary source,&nbsp; $H > 1 \ \rm (bit/source\ symbol)$&nbsp; is possible, so that even with perfect source coding there will always be&nbsp; $L > N$.&nbsp; If the source is redundancy-free&nbsp; (no memory, all&nbsp; $M$&nbsp; symbols equally probable), it has the entropy&nbsp; $H= 2 \ \rm (bit/source\ symbol)$.
  
  
For all these examples of perfect source encoding, the relative redundancy of the code sequence (residual redundancy) is&nbsp; $r = 0$. That is: &nbsp; The zeros and ones are equally probable and there are no statistical bonds between the individual binary symbols.
+
For all these examples of perfect source coding, the relative redundancy of the encoded sequence&nbsp; ("residual redundancy")&nbsp; is&nbsp; $r = 0$.&nbsp; That is: &nbsp; The zeros and ones are equally probable and there are no correlations between the individual binary symbols.
 
<br>
 
<br>
  
Line 324: Line 317:
  
  
==Efficiency of Lempel-Ziv encoding ==
+
==Efficiency of Lempel-Ziv coding ==
 
<br>
 
<br>
From the Lempel-Ziv algorithms we know (and can even prove this statement) that they are&nbsp; '''asymptotically optimal''' &nbsp; This means that the relative redundancy of the code symbol sequence&nbsp; (here written as a function of the source symbol sequence length&nbsp; $N$&nbsp;)
+
From the Lempel-Ziv algorithms we know&nbsp; (and can even prove this statement)&nbsp; that they are&nbsp; &raquo;'''asymptotically optimal'''&laquo;. &nbsp;  
 +
*This means that the relative redundancy of the encoded sequence&nbsp; (here written as a function of the source symbol sequence length&nbsp; $N$
 
   
 
   
:$$r(N) = \frac{L(N) - N \cdot H}{L(N)}= 1 - \frac{ N \cdot H}{L(N)}\hspace{0.05cm}$$
+
:$$r(N) = \frac{L(N) - N \cdot H}{L(N)}= 1 - \frac{ N \cdot H}{L(N)}\hspace{0.05cm}.$$
  
for large&nbsp; $N$&nbsp; returns the limit value "zero":
+
*For large&nbsp; $N$&nbsp; the limit value returns  "zero":
 
   
 
   
 
:$$\lim_{N \rightarrow \infty}r(N) = 0 \hspace{0.05cm}.$$
 
:$$\lim_{N \rightarrow \infty}r(N) = 0 \hspace{0.05cm}.$$
  
But what does the property&nbsp; "asymptotically optimal"&nbsp; say for practical sequence lengths?&nbsp; Not too much, as the following screenshot of our simulation tool&nbsp; [[Applets:Lempel-Ziv-Welch|Lempel-Ziv-Algorithms]]&nbsp; shows. All curves apply exactly only to the [[Information_Theory/Compression According to Lempel, Ziv and Welch#The Lempel-Ziv-Welch algorithm|LZW-Algorithm]]].&nbsp; However, the results for&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#LZ77 - the basic form of the Lempel-Ziv-algorithms|LZ77]]&nbsp; and&nbsp; [[Information_Theory/Compression According to Lempel, Ziv and Welch#The Lempel-Ziv-Variant LZ78|LZ78]]&nbsp; are only slightly worse.
+
But what does the property&nbsp; "asymptotically optimal"&nbsp; say for practical sequence lengths?&nbsp; Not too much, as the following screenshot of our simulation tool&nbsp; [[Applets:Lempel-Ziv-Welch|"Lempel-Ziv algorithms"]]&nbsp; shows. &nbsp; All curves apply exactly only to the [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#The_Lempel-Ziv-Welch_algorithm|$\text{LZW algorithm}$]].&nbsp; However, the results for&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#LZ77_-_the_basic_form_of_the_Lempel-Ziv_algorithms|$\text{LZ77}$]]&nbsp; and&nbsp; [[Information_Theory/Compression_According_to_Lempel,_Ziv_and_Welch#The_Lempel-Ziv_variant_LZ78|$\text{LZ78}$]]&nbsp; are only slightly worse.
 
 
  
 
The three graphs show for different message sources the dependence of the following sizes on the source symbol sequence length&nbsp; $N$:
 
The three graphs show for different message sources the dependence of the following sizes on the source symbol sequence length&nbsp; $N$:
*the required number of bits&nbsp; $N \cdot \log_2 M$&nbsp; without source coding&nbsp; (black curves),
+
*the required number&nbsp; $N \cdot \log_2 M$&nbsp; of bits without source coding&nbsp; (black curves),
*the required number of bits&nbsp; $H$ \cdot $N$&nbsp; with perfect source encoding&nbsp; (gray dashed),
+
*the required number&nbsp; $H \cdot N$&nbsp; of bits with perfect source coding&nbsp; (gray dashed),
*the required number of bits&nbsp; $L(N)$&nbsp; for LZW coding&nbsp; (red curves after averaging),
+
*the required number&nbsp; $L(N)$&nbsp; of bits for LZW coding&nbsp; (red curves after averaging),
 
*the relative redundancy &nbsp; &rArr; &nbsp; residual redundancy &nbsp;$r(N)$&nbsp; in case of LZW coding (green curves).
 
*the relative redundancy &nbsp; &rArr; &nbsp; residual redundancy &nbsp;$r(N)$&nbsp; in case of LZW coding (green curves).
  
  
[[File:P_ID2450__Inf_T_2_2_S7b_neu.png|frame|Example curves of&nbsp; $L(N)$&nbsp; and&nbsp; $r(N)$]].
+
[[File:EN_Inf_T_2_2_S7b.png|frame|Example curves of&nbsp; $L(N)$&nbsp; and&nbsp; $r(N)$]]
  
 
$\underline{\text{Redundant binary source (upper graphic)} }$  
 
$\underline{\text{Redundant binary source (upper graphic)} }$  
 
:$$M = 2, \hspace{0.1cm}p_{\rm A} = 0.89,\hspace{0.1cm} p_{\rm B} = 0.11$$
 
:$$M = 2, \hspace{0.1cm}p_{\rm A} = 0.89,\hspace{0.1cm} p_{\rm B} = 0.11$$
:$$\Rightarrow \hspace{0.15cm} H = 0.5 \ \rm bit/source symbol\text{:}$$  
+
:$$\Rightarrow \hspace{0.15cm} H = 0.5 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$  
*The black and grey curves are true straight lines (not only for this parameter set).
+
*The black and gray curves are true straight lines (not only for this parameter set).
 
*The red curve&nbsp; $L(N)$&nbsp; is slightly curved&nbsp; (difficult to see with the naked eye).
 
*The red curve&nbsp; $L(N)$&nbsp; is slightly curved&nbsp; (difficult to see with the naked eye).
 
*Because of this curvature of&nbsp; $L(N)$&nbsp; the residual redundancy (green curve) drops slightly.
 
*Because of this curvature of&nbsp; $L(N)$&nbsp; the residual redundancy (green curve) drops slightly.
 
:$$r(N) = 1 - 0.5 \cdot N/L(N).$$  
 
:$$r(N) = 1 - 0.5 \cdot N/L(N).$$  
*The numerical values can be read  
+
*The numerical values can be read:
 
:$$L(N = 10000) = 6800,\hspace{0.5cm}
 
:$$L(N = 10000) = 6800,\hspace{0.5cm}
 
r(N = 10000) = 26.5\%.$$
 
r(N = 10000) = 26.5\%.$$
Line 360: Line 353:
 
$\underline{\text{Redundancy-free binary source (middle graphic)} }$  
 
$\underline{\text{Redundancy-free binary source (middle graphic)} }$  
 
:$$M = 2,\hspace{0.1cm} p_{\rm A} = p_{\rm B} = 0.5$$  
 
:$$M = 2,\hspace{0.1cm} p_{\rm A} = p_{\rm B} = 0.5$$  
:$$\Rightarrow \hspace{0.15cm} H = 1 \ \rm bit/source symbol\text{:}$$
+
:$$\Rightarrow \hspace{0.15cm} H = 1 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$
* Here the grey and the black straight line coincide and the slightly curved red curve lies above it, as expected.  
+
* Here the gray and the black straight line coincide and the slightly curved red curve lies above it, as expected.  
*Although the LZW coding brings a deterioration here, recognizable from the indication&nbsp; $L(N = 10000) = 12330$, the relative redundancy is smaller than in the upper graph:  
+
*Although the LZW coding brings a deterioration here, recognizable from the indication&nbsp; $L(N = 10000) = 12330$, the residual redundancy is smaller than in the upper graph:  
 
:$$r(N = 10000) = 18.9\%.$$
 
:$$r(N = 10000) = 18.9\%.$$
  
Line 369: Line 362:
 
$\underline{\text{Redundant quaternary source (lower graphic)} }$
 
$\underline{\text{Redundant quaternary source (lower graphic)} }$
 
:$$M = 4,\hspace{0.1cm}p_{\rm A} = 0.7,\hspace{0.1cm} p_{\rm B} = p_{\rm C} = p_{\rm D} = 0.1$$
 
:$$M = 4,\hspace{0.1cm}p_{\rm A} = 0.7,\hspace{0.1cm} p_{\rm B} = p_{\rm C} = p_{\rm D} = 0.1$$
:$$ \Rightarrow \hspace{0.15cm} H \approx 1.357 \ \rm bit/source symbol\text{:}$$
+
:$$ \Rightarrow \hspace{0.15cm} H \approx 1.357 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$
* Without source coding, for&nbsp; $N = 10000$&nbsp; Quaternary symbols&nbsp; $20000$&nbsp; binary symbols (bit) would be required (black curve).
+
* Without source coding, for&nbsp; $N = 10000$&nbsp; quaternary symbols&nbsp; $20000$&nbsp; binary symbols (bits) would be required (black curve).
* If source encoding was perfect, this would result in&nbsp; $N \cdot H= 13570$&nbsp; Bit&nbsp; (grey curve).
+
* If source encoding was perfect, this would result in&nbsp; $N \cdot H= 13570$&nbsp; bits&nbsp; (gray curve).
* With (imperfect) LZW encoding you need&nbsp; $L(N = 10000) ≈ 16485$&nbsp; Bit&nbsp; (red curve).  
+
* With (imperfect) LZW encoding you need&nbsp; $L(N = 10000) ≈ 16485$&nbsp; bits&nbsp; (red curve).  
*The relative redundancy here is&nbsp; $r(N = 10000) ≈17.7\%$&nbsp; (green curve).
+
*The residual redundancy here is&nbsp; $r(N = 10000) ≈17.7\%$&nbsp; (green curve).
  
  
 
==Quantitative statements on asymptotic optimality== 
 
==Quantitative statements on asymptotic optimality== 
 
<br>
 
<br>
The results on the last page have shown that the relative residual redundancy&nbsp; $r(N = 10000)$&nbsp; is significantly greater than the theoretically promised value&nbsp; $r(N \to \infty) = 0$.  
+
The results in the last section have shown that the residual redundancy&nbsp; $r(N = 10000)$&nbsp; is significantly greater than the theoretically promised value&nbsp; $r(N \to \infty) = 0$.  
  
This practically relevant result shall now be clarified using the example of the redundant binary source with&nbsp; $H = 0.5 \ \rm bit/source symbol$&nbsp; according to the middle graphic on the last page. However, we now consider values between&nbsp; $N=10^3$&nbsp; and&nbsp; $N=10^{12}$&nbsp; for the source symbol sequence length.
+
This practically relevant result shall now be clarified using the example of the redundant binary source with&nbsp; $H = 0.5 \ \rm bit/source\hspace{0.15cm} symbol$&nbsp; according to the middle graphic in the last section. However, we now consider for the source symbol sequence length values between&nbsp; $N=10^3$&nbsp; and&nbsp; $N=10^{12}$.
  
[[File:P_ID2443__Inf_T_2_2_S8_neu.png|frame|LZW-Rest redundancy&nbsp; $r(N)$&nbsp; with redundant binary source&nbsp; $(H = 0.5)$ ]].
+
[[File:EN_Inf_T_2_2_S8.png|frame|LZW residual redundancy&nbsp; $r(N)$&nbsp; with redundant binary source&nbsp; $(H = 0.5)$ ]]
 
{{GraueBox|TEXT=
 
{{GraueBox|TEXT=
$\text{Example 7:}$&nbsp; The graphic shows simulations with&nbsp; $N = 1000$&nbsp; binary symbols.  
+
$\text{Example 7:}$&nbsp; The graphic on the right shows simulation results with only &nbsp; $N = 1000$&nbsp; binary symbols.  
 
*After averaging over ten series of experiments the result is&nbsp; $r(N = 1000) ≈35.2\%$.  
 
*After averaging over ten series of experiments the result is&nbsp; $r(N = 1000) ≈35.2\%$.  
*below the yellow dot&nbsp; $($in the example with&nbsp; $N ≈ 150)$&nbsp; the LZW algorithm even brings a deterioration.  
+
*Below the yellow dot&nbsp; $($in the example with&nbsp; $N ≈ 150)$&nbsp; the LZW algorithm even brings a deterioration.  
*In this range, namely&nbsp; $L > N$, that is: &nbsp; <br>The red curve is above the black one.
+
*In this range, namely&nbsp; $L > N$, that is:&nbsp; "Red"&nbsp; is above&nbsp; "black".
  
  
 
In the table below, the results for this redundant binary source&nbsp; $(H = 0.5)$&nbsp; are summarized
 
In the table below, the results for this redundant binary source&nbsp; $(H = 0.5)$&nbsp; are summarized
  
[[File:Inf_T_2_2_S8b_neu.png|right|frame|Some numerical values for the efficiency of LZW coding]]
+
[[File:EN_Inf_T_2_2_S8c.png|right|frame|Some numerical values for the efficiency of LZW coding]]
  
*The compression factor&nbsp; $K(n)= L(n)/N$&nbsp; decreases with increasing&nbsp; $N$&nbsp; only very slowly&nbsp; (line 3).
+
*The compression factor&nbsp; $K(N)= L(N)/N$&nbsp; decreases with increasing&nbsp; $N$&nbsp; only very slowly&nbsp; (line 3).
*In line 4 the rest redundancy&nbsp; $r(N)$&nbsp; is given for different lengths between&nbsp; $N =1000$&nbsp; and&nbsp; $N =50000$&nbsp;;
+
*In line 4 the residual redundancy&nbsp; $r(N)$&nbsp; is given for different lengths between&nbsp; $N =1000$&nbsp; and&nbsp; $N =50000$.
*According to relevant literature this residual redundancy decreases proportionally to&nbsp; $\big[\hspace{0.05cm}\lg(N)\hspace{0.05cm}\big]^{-1}$&nbsp;.  
+
*According to relevant literature this residual redundancy decreases proportionally to&nbsp; $\big[\hspace{0.05cm}\lg(N)\hspace{0.05cm}\big]^{-1}$.  
 
*In line 5 the results of an empirical formula are entered $($adaptation for $N = 10000)$:
 
*In line 5 the results of an empirical formula are entered $($adaptation for $N = 10000)$:
 
   
 
   
Line 402: Line 395:
 
:$$ A = {r(N = 10000)} \cdot { {\rm lg}\hspace{0.1cm}10000} = 0.265 \cdot 4 = 1.06
 
:$$ A = {r(N = 10000)} \cdot { {\rm lg}\hspace{0.1cm}10000} = 0.265 \cdot 4 = 1.06
 
\hspace{0.05cm}.$$
 
\hspace{0.05cm}.$$
*You can see the good agreement between our simulation results&nbsp; $r(N)$&nbsp; and the rule of thumb&nbsp; $r\hspace{0.05cm}′(N)$.  
+
*You can see the good agreement between our simulation results&nbsp; $r(N)$&nbsp; and the rule of the thumb&nbsp; $r\hspace{0.05cm}′(N)$.  
 
*You can also see that the residual redundancy of the LZW algorithm for&nbsp; $N = 10^{12}$&nbsp; is still&nbsp; $8.8\%$&nbsp;.
 
*You can also see that the residual redundancy of the LZW algorithm for&nbsp; $N = 10^{12}$&nbsp; is still&nbsp; $8.8\%$&nbsp;.
*For other sources, with other&nbsp; $A$&ndash;values you will get similar results.&nbsp; The principle process remains the same.&nbsp; See also&nbsp; [[Aufgaben:Aufgabe_2.5:_Restredundanz_bei_LZW-Codierung|Exercise 2.5]]&nbsp; and&nbsp; [[Aufgaben:Aufgabe_2.5Z:_Komprimierungsfaktor_vs._Restredundanz|Task 2.5Z]].}}
+
*For other sources, with other&nbsp; $A$&ndash;values you will get similar results.&nbsp; The principle process remains the same.&nbsp; See also&nbsp; [[Aufgaben:Exercise_2.5:_Residual_Redundancy_with_LZW_Coding|"Exercise 2.5"]]&nbsp; and&nbsp; [[Aufgaben:Aufgabe_2.5Z:_Komprimierungsfaktor_vs._Restredundanz|"Exercise 2.5Z"]].}}
  
 
 
 
 
==Exercises to chapter ==    
+
==Exercises for the chapter ==    
 
<br>
 
<br>
[[Aufgaben:2.3 Zur LZ78-Komprimierung|Aufgabe 2.3: Zur LZ78-Komprimierung]]
+
[[Aufgaben:Exercise_2.3:_About_the_LZ78_Compression|Exercise 2.3: About the LZ78 Compression]]
  
[[Aufgaben:2.3Z Zur LZ77-Codierung|Aufgabe 2.3Z: Zur LZ77-Codierung]]
+
[[Aufgaben:Exercise_2.3Z:_To_the_LZ77_Coding|Exercise 2.3Z: To the LZ77 Coding]]
  
[[Aufgaben:2.4 Zum LZW-Algorithmus|Aufgabe 2.4: Zum LZW-Algorithmus]]
+
[[Aufgaben:Exercise_2.4:_About_the_LZW_algorithm|Exercise 2.4: About the LZW algorithm]]
  
[[Aufgaben:2.4Z Nochmals LZW-Codierung und -Decodierung|Aufgabe 2.4Z: Nochmals LZW-Codierung und -Decodierung]]
+
[[Aufgaben:Exercise_2.4Z:_LZW_Coding_and_Decoding_again|Exercise 2.4Z: LZW Coding and Decoding again]]
  
[[Aufgaben:Aufgabe_2.5:_Restredundanz_bei_LZW-Codierung|Aufgabe 2.5: Relative Restredundanz bei LZW-Codierung]]
+
[[Aufgaben:Exercise_2.5:_Residual_Redundancy_with_LZW_Coding|Exercise 2.5: Residual Redundancy with LZW Coding]]
  
[[Aufgaben:Aufgabe_2.5Z:_Komprimierungsfaktor_vs._Restredundanz|Aufgabe 2.5Z: Komprimierungsfaktor vs. Restredundanz]]
+
[[Aufgaben:Exercise_2.5Z:_Compression_Factor_vs._Residual_Redundancy|Exercise_2.5Z: Compression Factor vs. Residual Redundancy]]
  
  
 
{{Display}}
 
{{Display}}

Latest revision as of 19:05, 20 February 2023


Static and dynamic dictionary techniques


Many data compression methods use dictionaries.  The idea is the following:

  • Construct a list of character patterns that occur in the text,
  • and encode these patterns as indices of the list.


This procedure is particularly efficient if certain patterns are repeated frequently in the text and if this is also taken into account in the coding.  A distinction is made here between

  • procedures with static dictionary,
  • procedures with dynamic dictionary.




$\text{(1)   Procedures with static dictionary}$

A static dictionary is only useful for very special applications, for example for a file of the following form:

Data file  (rubrics:  "Name",  "Vorname"   ⇒   "first name",  "Wohnort"   ⇒   "residence")

For example, the assignments result in

$$"\boldsymbol{\rm 0}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 000000} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm} "\boldsymbol{\rm 9}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001001} \hspace{0.05cm}, "\hspace{-0.03cm}\_\hspace{-0.03cm}\_\hspace{0.03cm}" \hspace{0.1cm}{\rm (blank)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001010} \hspace{0.05cm},$$
$$"\hspace{-0.01cm}.\hspace{-0.01cm}" \hspace{0.1cm}{\rm (point)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm}, "\hspace{-0.01cm},\hspace{-0.01cm}" \hspace{0.1cm}{\rm (comma)}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001011} \hspace{0.05cm}, " {\rm end\hspace{-0.1cm}-\hspace{-0.1cm}of\hspace{-0.1cm}-\hspace{-0.1cm}line}\hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 001101} \hspace{0.05cm},$$
$$"\boldsymbol{\rm A}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 100000} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm} "\boldsymbol{\rm E}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 100100} \hspace{0.05cm}, \hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm} "\boldsymbol{\rm L}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 101011} \hspace{0.05cm},\hspace{0.15cm}"\boldsymbol{\rm M}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 101100} \hspace{0.05cm},$$
$$"\boldsymbol{\rm O}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 101110} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm},\hspace{0.05cm} "\boldsymbol{\rm U}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 110100} \hspace{0.05cm}, "\boldsymbol{\rm Name\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 010000} \hspace{0.05cm},\hspace{0.05cm}$$
$$"\boldsymbol{\rm ,\_\hspace{-0.03cm}\_Vorname\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 010001} \hspace{0.05cm},\hspace{0.05cm} "\boldsymbol{\rm ,\_\hspace{-0.03cm}\_Wohnort\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_}" \hspace{0.05cm} \mapsto \hspace{0.05cm} \boldsymbol{\rm 010010} \hspace{0.05cm},\hspace{0.15cm} ... \hspace{0.15cm}$$

for the first line of the above text, binary source coded with six bits per character:

$$\boldsymbol{010000} \hspace{0.15cm}\boldsymbol{100000} \hspace{0.15cm}\boldsymbol{100001} \hspace{0.15cm}\boldsymbol{100100} \hspace{0.15cm}\boldsymbol{101011} \hspace{0.3cm} \Rightarrow \hspace{0.3cm} \boldsymbol{(\rm Name\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_) \hspace{0.05cm}(A)\hspace{0.05cm}(B)\hspace{0.05cm}(E)\hspace{0.05cm}(L)}$$
$$\boldsymbol{010001} \hspace{0.15cm}\boldsymbol{101011}\hspace{0.15cm} \boldsymbol{100100} \hspace{0.15cm}\boldsymbol{101110} \hspace{0.3cm} \Rightarrow \hspace{0.3cm} \boldsymbol{(,\hspace{-0.05cm}\_\hspace{-0.03cm}\_\rm Vorname\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_) \hspace{0.05cm}(L)\hspace{0.05cm}(E)\hspace{0.05cm}(O)}$$
$$\boldsymbol{010010} \hspace{0.15cm}\boldsymbol{110100} \hspace{0.15cm}\boldsymbol{101011} \hspace{0.15cm}\boldsymbol{101100} \hspace{0.3cm}\Rightarrow \hspace{0.3cm} \boldsymbol{(,\hspace{-0.05cm}\_\hspace{-0.03cm}\_\rm Wohnort\hspace{-0.1cm}:\hspace{-0.05cm}\_\hspace{-0.03cm}\_) \hspace{0.05cm}(U)\hspace{0.05cm}(L)\hspace{0.05cm}(M)} \hspace{0.05cm} $$
$$\boldsymbol{001101} \hspace{0.3cm}\Rightarrow \hspace{0.3cm} ({\rm end\hspace{-0.1cm}-\hspace{-0.1cm}of\hspace{-0.1cm}-\hspace{-0.1cm}line}) \hspace{0.05cm}$$

$\text{Conclusion:}$  In this specific application the first line can be displayed with  $14 \cdot 6 = 84$  bits.

  • In contrast, conventional binary coding would require  $39 \cdot 7 = 273$  bits
          (because of the lowercase letters in the text, six bits per character are not sufficient here).
  • For the entire text, this results in  $103 \cdot 6 = 618$  bits versus  $196 \cdot 7 = 1372$  bits.
  • However, the code table must also be known to the recipient.




$\text{(2)   Procedures with dynamic dictionary}$

Nevertheless, all relevant compression methods do not work with static dictionaries, but with  »dynamic dictionaries«, which are created successively only during the coding:

  • Such procedures are flexible and do not have to be adapted to the application.   One speaks of »universal source coding procedures«.
  • A single pass is sufficient, whereas with a static dictionary the file must first be analyzed before the encoding process.
  • At the sink, the dynamic dictionary is generated in the same way as for the source.  This eliminates the need to transfer the dictionary.


Extract from the hexdump of a natural image in BMP format

$\text{Example 1:}$  The graphic shows a small section of  $80$  byte of a  $\text{BMP file}$  in hexadecimal format.  It is the uncompressed representation of a natural picture.

  • You can see that in this small section of a landscape image the bytes  $\rm FF$,  $\rm 55$  and  $\rm 47$  occur very frequently.  Data compression is therefore promising.
  • But since other parts of the file or other byte combinations dominate in other image contents, the use of a static dictionary would not be appropriate here.


Possible encoding of a simple graphic

$\text{Example 2:}$  For an artificially created graphic, for example a form, you could work with a static dictionary.

We are looking at a  "black & white"  image with  $27 × 27$  pixels, where the mapping "black"   ⇒   0  and "white"   ⇒   1  has been agreed upon.

  • At the top  (black marker),  each line is described by  $27$  zeros.
  • In the middle  (blue marker),  three zeros and three ones always alternate.
  • At the bottom  (red marker),  25 ones per line are limited by two zeros.


LZ77 - the basic form of the Lempel-Ziv algorithms


The most important procedures for data compression with a dynamic dictionary go back to  $\text{Abraham Lempel}$  and  $\text{Jacob Ziv}$.  The entire Lempel-Ziv family  (in the following we will use for this briefly:   $\rm LZ$  procedure)  can be characterized as follows:

  • Lempel-Ziv methods use the fact that often whole words, or at least parts of them, occur several times in a text.  One collects all word fragments, which are also called  "phrases"  in a sufficiently large dictionary.
  • Contrary to the entropy coding developed some years before (by Shannon and Huffman), the frequency of single characters or character strings is not the basis of the compression here, so that the LZ procedures can be applied even without knowledge of the source statistics.
  • LZ compression accordingly manages with a single pass and also the source symbol set size  $M$  and the symbol set  $\{q_μ\}$  with  $μ = 1$, ... , $M$  does not have to be known.  This is called  »Universal Source Coding«.


We first look at the Lempel-Ziv algorithm in its original form from 1977, known as  $\rm LZ77$:

Sliding window with LZ77 compression
  • This works with a window that is successively moved over the text   ⇒   one also speaks of a  "sliding window".
  • The window size  $G$  is an important parameter that decisively influences the compression result.


The graphic shows an example of the  sliding windows.  This is divided into

  • the  "preview buffer"  $($blue background),  and
  • the  "search buffer"  $($red background, with the positions 
    $P = 0$, ... , $7$   ⇒   window size  $G = 8)$.


The text consists of the words  MissMissionMississippi  and  Mistral, each separated by a hyphen.  At the time under consideration the preview buffer contains  Mississi.

  • Search now in the search buffer for the best match   ⇒   the string with the maximum match length  $L$.  This is the result for position  $P = 7$  and length  $L = 5$  to  Missi.
  • This step is expressed by the triple  $(7,  5,  $ s$)$   ⇒   general  $(P, \ L, \ Z)$, where  $Z =$ s  specifies the character that no longer matches the string found in the search buffer.
  • At the end the window is moved by  $L + 1 = 6$  character is moved to the right.  In the preview buffer there is now  sippi-Mi,  and in the search buffer  n-Missis
    The encoding gives the triple  $(2, 2,$  p$)$.


In the following example the LZ77 coding algorithm is described in more detail.  The decoding runs in a similar way.

$\text{Example 3:}$  We consider the LZ77 encoding of the string  ABABCBCBAABCABe  according to the following graphic.  The input sequence has the length $N = 15$. 

Further is assumed:

  • For the characters apply  $Z ∈ \{$ ABCe $\}$,  where  e  corresponds to the  "end-of-file"  (end of the input string)
  • The size of the preview and search buffer are  $G = 4$   ⇒   position  $P ∈ \{0, 1, 2, 3\}$.
To illustrate the LZ77 encoding


Display of the encoding process:

Step 1 and 2:   The characters  A  and  B  are encoded by the triple  $(0, 0,  $ A$)$  and  $(0, 0,  $ B$)$, because they are not yet stored in the search buffer.   Then move the sliding window by 1.

Step 3:   AB  is masked by the search buffer and at the same time the still unknown character  C  is appended.  After that the sliding window is moved three positions to the right.

Step 4:   This shows that the search string  BCB  may also end in the preview buffer.  Now the window can be moved four positions to the right.

Step 5:   Only  A  is found in the search buffer and  B  is dropped.  If the search buffer is larger, however,  ABC  could be masked together.  For this purpose must be  $G ≥ 7$.

Step 6:   Likewise, the character  C  must be coded separately due to the buffer being too small.  But since  CA  hasn't occurred before,  $G = 7$  would not improve the compression here.

Step 7:   With the consideration of the end-of-file  (e)  together with  AB  from the search buffer, the encoding process is finished.


Before transmission, the specified triples must of course be binary coded.  In this example

  • the position  $P ∈ \{0,\ 1,\ 2,\ 3\}$  needs two bits  (yellow background in the table above),
  • the copy length  $L$  needs three bits  (green background), so that also  $L = 7$  could still be displayed,
  • all characters need two bits  (white background),  for example  A00B01C10e ("end-of-file") → 11.


Thus the  $\rm LZ77$  output sequence has a length of  $7 \cdot 7 = 49$  bits, while the input sequence only needed  $15 \cdot 2 = 30$  bits.


$\text{Conclusion:}$  Lempel-Ziv compression only makes sense with large files !


The Lempel-Ziv variant LZ78


The LZ77 algorithm produces very inefficient output if more frequent strings are repeated only with a larger distance.  Such repetitions can often not be recognized due to the limited buffer size  $G$  of the sliding window.

Lempel and Ziv corrected this shortcoming already one year after the release of the first version LZ77:

  • The algorithm  $\rm LZ78$  uses a global dictionary for compression instead of the local dictionary (search buffer).
  • The size of the dictionary allows efficient compression of phrases that have been used for a long time before.


$\text{Example 4:}$  To explain the LZ78 algorithm we consider the same sequence  ABABCBCBAABCABe  as for the LZ77 $\text{Example 3}$.

Generation of the dictionary and output at LZ78

The graphic shows  (with red background)  the dictionary

  • with index  $I $  (in decimal and binary representation, column 1 and 2) 
  • and the corresponding content (column 3),
  • which is entered for coding step  $i $  (column 4).  For LZ78 both encoding and decoding are always  $i = I$.
  • In column 5 you find the formalized code output  $($Index  $I$,  new character  $Z)$.
  • In column 6 the corresponding binary coding is given with four bits for the index and the same character assignment  A00B01C10e ("end-of-file") → 11  as in  $\text{Example 3}$.


  • At the beginning  (step $\underline{i = 0}$)  the dictionary is  (WB)  empty except for the entry  ε  $($empty character, not to be confused with the space character, which is not used here$)$  with index  $I = 0$.
  • In the step  $\underline{i = 1}$  there is no usable entry in the dictionary yet, and it becomes  (0,  A)  output  (A  follows  ε).   In the dictionary, the entry  A  follows in line  $I = 1$  (abbreviated  1: A).
  • The procedure in the second step  ($\underline{i = 2}$).  The output is  (0,  B)  and the dictionary entry is  2: B .
  • As the entry  $\underline{i = 3}$  is already found in step  1: A , the characters  AB  can be coded together by  (1, B)  and the new dictionary entry  3: AB  is made.
  • After coding and insertion of the new character  C  in step  $\underline{i = 4}$  the pair of characters  BC  is coded together   ⇒   (2, C) and entered into the dictionary  5: BC  in step  $\underline{i = 5}$ .
  • In step  $\underline{i = 6}$  two characters are treated together with  '6: BA  and in the last two steps three each, namely  7: ABC  and  8: ABe.
  • The output  (3, C)  in step  $\underline{i = 7}$  stands for  "WB(3) + C = ABC   and the output  (3, e)  in step  $\underline{i = 8}$  for  ABe.


In this  $\text{Example 4}$  the LZ78 encoded sequence thus consists of  $8 - 6 = 48$  bit.  The result is comparable to the LZ77-$\text{Example 3}$  $(49$ bit$)$.


$\text{Conclusion:}$  Details and improvements of LZ78 will be omitted here.  Here we refer to the  $\text{LZW algorithm}$, which will be described in the following sections.  Only this much will be said now:

  • The index  $I$  is uniformly represented here with four bits, whereby the dictionary is limited to  $16$  entries.  By a  "variable number of bits"  for the index one can bypass this limitation.  At the same time one gets a better compression factor.
  • The dictionary does not have to be transmitted with all LZ variants, but is generated with the decoder in exactly the same way as on the encoder side.  The decoding is also done with LZ78, but not with LZW, in the same way as the encoding.
  • All LZ procedures are asymptotically optimal, i.e., for infinitely long sequences the mean code word length  $L_{\rm M}$  per source symbol is equal to the source entropy  $H$.
  • For short sequences, however, the deviation is considerable.  More about this at the  "end of chapter".


The Lempel-Ziv-Welch algorithm


The most common variant of Lempel-Ziv compression used today was designed by  $\text{Terry Welch}$  and published in 1983.  In the following we refer to it as the  "Lempel-Ziv-Welch-Algorithm", abbreviated as  $\rm LZW$.   Just as LZ78 has slight advantages over LZ77  (as expected, why else would the algorithm have been modified?),  LZW also has more advantages than disadvantages compared to LZ78.

LZW encoding of the sequence  ABABCBCBAABCABe

The graphic shows the coder output for the exemplary input sequence  ABABCBCBAABCABe.  On the right you can see the dictionary  (highlighted in red), which is successively generated during LZW encoding.  The differences to LZ78 can be seen in comparison to the graphic in the last section, namely:

  • For LZW, all characters occurring in the text are already entered at the beginning  $(i = 0)$  and assigned to a binary sequence, in the example with the indices  $I = 0$, ... ,  $I = 3$. 
  • This also means that LZW requires some knowledge of the message source, whereas LZ78 is a  "true universal encoding".
  • For LZW, only the dictionary index  $I$  is transmitted for each encoding step  $i$  while for LZ78 the output is the combination  $(I$,  $Z)$, where $Z$  denotes the current new character.  
  • Due to the absence of  $Z$  in the encoder output, LZW decoding is more complicated than with LZ78, as described in section  "Decoding of the LZW algorithm".


$\text{Example 5:}$  For this exemplary  $\rm LZW$  encoding, again the input sequence  ABABCBCBAABCABe  is assumed as with "LZ77" and "LZ78".  So the following description refers to the above graphic.

Step i = 0  (default):   The allowed characters  ABC  and  e  ("end-of-file") are entered into the dictionary and assigned to the indices  $I = 0$, ... , $I = 3$ .

Step i = 1:   The character  A  is encoded by the decimal index  $I = 0$  and its binary representation  0000  is transmitted.  
Then the combination of the current character  A  and the following character  B  of the input sequence is stored in the dictionary under the index  $I = 4$ .

step i = 2:   Representation of  B  by index  $I = 1$  or  0001  (binary)  as well as dictionary entry of  BA  placed under index  $I = 5$.

Step i = 3:   Because of the entry  AB  at time  $i = 1$  the index to be transmitted is  $I = 4$  (binary:  0100).  New dictionary entry of  ABC  under  $I = 6$.

Step i = 8:   Here the characters  ABC  are represented together by the index  $I = 6$  (binary:  0110)  and the entry for  ABCA  is made.

With the encoding of  e  (EOF mark) the encoding process is finished after ten steps.  With LZ78 only eight steps were needed.  But it has to be considered:

  • The LZW algorithm needs only  $10 \cdot 4 = 40$  bit versus the  $8 \cdot 6 = 48$  bit for LZ78.  Provided that for this simple calculation, four bits each are needed for index representation.
  • LZW as well as LZ78 require less bits  $($namely   $34$  or   $42)$, if one considers that for the step  $i = 1$  the index has to be encoded with two bits only  $(I ≤ 3)$  and for  $2 ≤ i ≤ 5$  three bits are sufficient  $(I ≤ 7)$.


Lempel-Ziv coding with variable index bit length


For reasons of a most compact representation, we now consider only binary sources with symbol set  $\{$A, B$\}$.  The terminating character  »end-of-file«  is not considered, too.

LZW encoding of a binary input sequence

We demonstrate the LZW encoding by means of a screenshot of our interactive SWF module  "Lempel-Ziv-Welch algorithms".

  • In the first encoding step  $(i = 1)$:  A   ⇒  0.  Afterwards the entry with index  $I = 2$  and  content  AB.
  • As there are only two dictionary entries in step  $i = 1$  (for  A  and  B ) one bit is sufficient.   For step  $i = 2$  and  $i = 3$  $($B  ⇒  01  and   A  ⇒  00$)$  two bits are needed in each case.
  • Starting on  $i = 4$ , the index representation is done with three bits, then from   $i = 8$  with four bits and from  $i = 16$  with five bits.  A simple algorithm for the respective index bit number  $L(i)$  can be derived.
  • Let's finally consider the encoding step  $i = 18$.  Here, the sequence  ABABB  marked in red, which was entered into the dictionary at time  $i = 12$  at time  $($Index  $I = 13$ ⇒ 1101$)$  is edited.   However, the encoder output is now  01101 because of  $i ≥ 16$  (green mark at the encoder output).


The statements also apply to  $\text{LZ78}$.  That is:   With LZ78 a variable index bit length results in the same improvement as with LZW.


Decoding of the LZW algorithm


The decoder now displays the decoded output in the  "last section"  as input sequence.  The graphic shows that it is possible to uniquely decode this sequence even with variable index bit lengths. Please note:

  1.  The decoder knows that in the first encoding step  $(i = 1)$  the index  $I $ was encoded with only one bit, in the steps  $i = 2$  and  $i = 3$  with two bit, from   $i = 4$  with three bit, from  $i = 8$  with four bit, and so on.
  2.  The decoder generates the same dictionary as the encoder, but the dictionary entries are made one time step later.
LZW decoding of a binary input sequence


  • At step  $\underline{i = 1}$  the adjacent symbol  0  is decoded as  A.   Likewise, the following results for step  $\underline{i = 2}$  from the preassignment of the dictionary and the two-bit representation agreed upon for this:   01   ⇒   B.
  • The entry of the line  $\underline{I = 2}$  $($content:   AB$)$  of the dictionary is therefore only made at the step  $\underline{i = 2}$, while at the  $\text{encoding process}$  this could already be done at the end of step  $i = 1$.
  • Let us now consider the decoding for  $\underline{i = 4}$.   The index  $\underline{I = 2}$  returns the decoding result  010   ⇒   AB  and in the next step  $(\underline{i = 5})$  the dictionary line  $\underline{I = 5}$  will be filled with  ABA
  • This time difference with respect to the dictionary entries can lead to decoding problems.  For example, for step  $\underline{i = 7}$  there is no dictionary entry with index  $\underline{I= 7}$.
  • What is to do in such a case as  $(\underline{I = i})$?  In this case you take the result of the previous decoding step  $($here:   BA  for  $\underline{i = 6})$  and append the first character of this sequence at the end again.   This gives the decoding result for  $\underline{i = 7}$  to  111   ⇒   BAB.
  • Naturally, it is unsatisfactory to specify only one recipe.  In the  "Exercise 2.4Z"  you should justify the procedure demonstrated here.  We refer to the sample solution for this exercise.


With LZ78 decoding, the problem described here does not occur because not only the index  $I $  but also the current character  $Z$  is included in the encoding result and is transmitted.


Remaining redundancy as a measure for the efficiency of coding methods


For the rest of this chapter we assume the following prerequisites:

  • The source symbol set size  $($or in the transmission sense:   the number of levels )  is  $M$, where  $M$  represents a power of two   ⇒   $M = 2, \ 4, \ 8, \ 16$, ....
  • The source entropy is  $H$.  If there are no correlations between the symbols and if they are equally probable, then  $H = H_0 = \log_2 \ M$.  Otherwise, $H < H_0$ applies.
  • A symbol sequence of length  $N$  is source-coded and returns a binary encoded sequence of length  $L$. 
  • For the time being we do not make any statement about the type of source coding.


According to the  $\text{Source Coding Theorem}$  the average code word length  $L_{\rm M}$  must be greater than or equal to the source entropy  $H$  (in bit/source symbol).  This means

  • for the total length of the source-coded binary sequence:
$$L \ge N \cdot H \hspace{0.05cm},$$
  • for the relative redundancy of the coded sequence, in the following called  »residual redundancy«:
$$r = \frac{L - N \cdot H}{L} \hspace{0.05cm}.$$

$\text{Example 6:}$  If there were a  "perfect source coding"  for a redundancy-free binary source sequence  $(M = 2,\ p_{\rm A} = p_{\rm B} = 0.5$,  without memory$)$  of length  $N = 10000$, the encoder sequence would have also the length  $L = 10000$.

Consequence:   If in a code the result  $L = N$  is never possible, then this code is called  "not–perfect".

  • Lempel-Ziv is not suitable for this redundancy-free message source.  It will always be  $L > N$.  You can also put it quite succinctly like this:   The perfect source coding here is "no coding at all".
  • A redundant binary source with  $p_{\rm A} = 0.89$,  $p_{\rm B} = 0.11$   ⇒   $H = 0.5$  could be represented with a perfect source coding with $L = 5000$,  without being able to say what this perfect source coding looks like.
  • For a quaternary source,  $H > 1 \ \rm (bit/source\ symbol)$  is possible, so that even with perfect source coding there will always be  $L > N$.  If the source is redundancy-free  (no memory, all  $M$  symbols equally probable), it has the entropy  $H= 2 \ \rm (bit/source\ symbol)$.


For all these examples of perfect source coding, the relative redundancy of the encoded sequence  ("residual redundancy")  is  $r = 0$.  That is:   The zeros and ones are equally probable and there are no correlations between the individual binary symbols.

The problem is:   At finite sequence length  $N$  there is no perfect source code !


Efficiency of Lempel-Ziv coding


From the Lempel-Ziv algorithms we know  (and can even prove this statement)  that they are  »asymptotically optimal«.  

  • This means that the relative redundancy of the encoded sequence  (here written as a function of the source symbol sequence length  $N$:
$$r(N) = \frac{L(N) - N \cdot H}{L(N)}= 1 - \frac{ N \cdot H}{L(N)}\hspace{0.05cm}.$$
  • For large  $N$  the limit value returns "zero":
$$\lim_{N \rightarrow \infty}r(N) = 0 \hspace{0.05cm}.$$

But what does the property  "asymptotically optimal"  say for practical sequence lengths?  Not too much, as the following screenshot of our simulation tool  "Lempel-Ziv algorithms"  shows.   All curves apply exactly only to the $\text{LZW algorithm}$.  However, the results for  $\text{LZ77}$  and  $\text{LZ78}$  are only slightly worse.

The three graphs show for different message sources the dependence of the following sizes on the source symbol sequence length  $N$:

  • the required number  $N \cdot \log_2 M$  of bits without source coding  (black curves),
  • the required number  $H \cdot N$  of bits with perfect source coding  (gray dashed),
  • the required number  $L(N)$  of bits for LZW coding  (red curves after averaging),
  • the relative redundancy   ⇒   residual redundancy  $r(N)$  in case of LZW coding (green curves).


Example curves of  $L(N)$  and  $r(N)$

$\underline{\text{Redundant binary source (upper graphic)} }$

$$M = 2, \hspace{0.1cm}p_{\rm A} = 0.89,\hspace{0.1cm} p_{\rm B} = 0.11$$
$$\Rightarrow \hspace{0.15cm} H = 0.5 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$
  • The black and gray curves are true straight lines (not only for this parameter set).
  • The red curve  $L(N)$  is slightly curved  (difficult to see with the naked eye).
  • Because of this curvature of  $L(N)$  the residual redundancy (green curve) drops slightly.
$$r(N) = 1 - 0.5 \cdot N/L(N).$$
  • The numerical values can be read:
$$L(N = 10000) = 6800,\hspace{0.5cm} r(N = 10000) = 26.5\%.$$


$\underline{\text{Redundancy-free binary source (middle graphic)} }$

$$M = 2,\hspace{0.1cm} p_{\rm A} = p_{\rm B} = 0.5$$
$$\Rightarrow \hspace{0.15cm} H = 1 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$
  • Here the gray and the black straight line coincide and the slightly curved red curve lies above it, as expected.
  • Although the LZW coding brings a deterioration here, recognizable from the indication  $L(N = 10000) = 12330$, the residual redundancy is smaller than in the upper graph:
$$r(N = 10000) = 18.9\%.$$


$\underline{\text{Redundant quaternary source (lower graphic)} }$

$$M = 4,\hspace{0.1cm}p_{\rm A} = 0.7,\hspace{0.1cm} p_{\rm B} = p_{\rm C} = p_{\rm D} = 0.1$$
$$ \Rightarrow \hspace{0.15cm} H \approx 1.357 \ \rm bit/source\hspace{0.15cm} symbol\text{:}$$
  • Without source coding, for  $N = 10000$  quaternary symbols  $20000$  binary symbols (bits) would be required (black curve).
  • If source encoding was perfect, this would result in  $N \cdot H= 13570$  bits  (gray curve).
  • With (imperfect) LZW encoding you need  $L(N = 10000) ≈ 16485$  bits  (red curve).
  • The residual redundancy here is  $r(N = 10000) ≈17.7\%$  (green curve).


Quantitative statements on asymptotic optimality


The results in the last section have shown that the residual redundancy  $r(N = 10000)$  is significantly greater than the theoretically promised value  $r(N \to \infty) = 0$.

This practically relevant result shall now be clarified using the example of the redundant binary source with  $H = 0.5 \ \rm bit/source\hspace{0.15cm} symbol$  according to the middle graphic in the last section. However, we now consider for the source symbol sequence length values between  $N=10^3$  and  $N=10^{12}$.

LZW residual redundancy  $r(N)$  with redundant binary source  $(H = 0.5)$

$\text{Example 7:}$  The graphic on the right shows simulation results with only   $N = 1000$  binary symbols.

  • After averaging over ten series of experiments the result is  $r(N = 1000) ≈35.2\%$.
  • Below the yellow dot  $($in the example with  $N ≈ 150)$  the LZW algorithm even brings a deterioration.
  • In this range, namely  $L > N$, that is:  "Red"  is above  "black".


In the table below, the results for this redundant binary source  $(H = 0.5)$  are summarized

Some numerical values for the efficiency of LZW coding
  • The compression factor  $K(N)= L(N)/N$  decreases with increasing  $N$  only very slowly  (line 3).
  • In line 4 the residual redundancy  $r(N)$  is given for different lengths between  $N =1000$  and  $N =50000$.
  • According to relevant literature this residual redundancy decreases proportionally to  $\big[\hspace{0.05cm}\lg(N)\hspace{0.05cm}\big]^{-1}$.
  • In line 5 the results of an empirical formula are entered $($adaptation for $N = 10000)$:
$$r\hspace{0.05cm}'(N) = \frac{A}{ {\rm lg}\hspace{0.1cm}(N)}\hspace{0.5cm}{\rm with}$$
$$ A = {r(N = 10000)} \cdot { {\rm lg}\hspace{0.1cm}10000} = 0.265 \cdot 4 = 1.06 \hspace{0.05cm}.$$
  • You can see the good agreement between our simulation results  $r(N)$  and the rule of the thumb  $r\hspace{0.05cm}′(N)$.
  • You can also see that the residual redundancy of the LZW algorithm for  $N = 10^{12}$  is still  $8.8\%$ .
  • For other sources, with other  $A$–values you will get similar results.  The principle process remains the same.  See also  "Exercise 2.5"  and  "Exercise 2.5Z".


Exercises for the chapter


Exercise 2.3: About the LZ78 Compression

Exercise 2.3Z: To the LZ77 Coding

Exercise 2.4: About the LZW algorithm

Exercise 2.4Z: LZW Coding and Decoding again

Exercise 2.5: Residual Redundancy with LZW Coding

Exercise_2.5Z: Compression Factor vs. Residual Redundancy