LZ77

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

LZ77 (Lempel-Ziv 77)[1] ist ein verlustloses Verfahren zur Datenkompression, das 1977 von Abraham Lempel und Jacob Ziv veröffentlicht wurde. Es ist ein wörterbuchbasiertes Verfahren, das sich erstmals zunutze macht, dass ganze Sequenzen von Daten mehrfach in einem Datensatz vorkommen. In früher entwickelten Verfahren (z. B. Huffman-Kodierung bzw. Shannon-Fano-Kodierung) wurde ausschließlich die Häufigkeit einzelner Zeichen ausgenutzt (siehe auch Entropiekodierung). LZ77 wird als erstes LZ-Verfahren auch LZ1 genannt.

Die LZ77-Faktorisierung einer Zeichenkette ist eine Zerlegung in nicht-leere Zeichenketten , sodass[2]

  • und
  • für jedes mit gilt:
    • ist ein neuer Buchstabe , der nicht in auftaucht oder
    • ist die längste Zeichenkette, die mindestens zweimal in auftaucht.

Die einzelnen Zeichenketten werden als Faktoren oder Phrasen bezeichnet.

Aus der Definition ist direkt ableitbar, dass ist. Dabei bezeichnet die Zeichenkette , die von der Position an alle Zeichen aus bis einschließlich zur Position enthält. ist die abkürzende Schreibweise für die Zeichenkette .

Die Idee des Algorithmus zur Berechnung der LZ77-Kompression besteht darin, den bereits verarbeiteten Präfix der Zeichenkette als Wörterbuch zu verwenden. Aus implementierungstechnischen Gründen ist die Größe dieses Wörterbuchs in der Praxis beschränkt, um die Dauer der Suche zu beschränken. Es wird deshalb in der Regel ein gleitendes Fenster (engl. sliding window) verwendet, welches sowohl das Wörterbuch als auch den zu betrachtenden Textausschnitt (Vorschaupuffer) begrenzt. Komprimierte Zeichen werden so nach und nach vom Vorschaupuffer in das Wörterbuch verschoben. In der Praxis enthält der Puffer für das Wörterbuch mehrere tausend Zeichen und der Vorschaupuffer für den zu codierenden Ausschnitt der Zeichenkette in etwa 100 Zeichen (teilweise auch weniger).

Der Algorithmus erzeugt als Ausgabe eine Sequenz von Tripeln, mit denen der ursprüngliche Text zurückgewonnen werden kann. Ein Tripel für einen Faktor hat die Form , wobei

  • die Position des vorherigen Vorkommens von in angibt (bzw. , falls kein vorheriges Vorkommen in existiert),
  • die Länge des vorherigen Vorkommens von ist (bzw. 0, falls ein neues Zeichen ist)
  • und der Mismatch-Buchstabe ist, d. h. für ist .

Dabei ist zu beachten, dass bei Verwendung eines Puffers für das Wörterbuch die Position einer Zeichenkette relativ zum linken oder rechten Rand des Puffers zu verstehen ist (dies kann je nach Implementierung variieren), neue Zeichen müssen dann mit eingeführt werden. Durch das Ausgabeformat der Kompression ist die Rekonstruktion des Textes ohne explizites Abspeichern des Wörterbuches möglich.

Der Pseudocode ist eine Wiedergabe des LZ77-Kompressionsalgorithmus mit gleitendem Fenster:

 while Der Vorschaupuffer nicht leer ist; do
     Durchsuche rückwärts das Wörterbuch nach der längsten übereinstimmenden
                                         Zeichenkette mit dem Vorschaupuffer;
     if Eine Übereinstimmung wurde gefunden; then
         Gib das Tripel (Versatz zum Rand des Wörterbuch,
                         Länge der gefundenen Zeichenkette,
                         erstes nicht übereinstimmendes Zeichen aus dem Vorschaupuffer) aus;
         Verschiebe das Fenster um die Länge+1;
     else
         Gib das Tripel (0, 0, erstes Zeichen im Vorschaupuffer) aus;
         Verschiebe das Fenster um 1;
     end if
 end while

Die Berechnung der LZ77-Faktorisierung wird anhand der Zeichenkette aacaacabcabaaac veranschaulicht.

Die Tabelle zeigt die Berechnung der LZ77-Faktorisierung unter Verwendung eines Wörterbuchs der Länge 12 und einem Vorschaupuffer der Länge 10 (Index von 0 bis 9). In der ganz rechten Spalte findet sich von oben nach unten gelesen die Ausgabe des Algorithmus (0, 0, a ), (1, 1, c ), (3, 4, b ), (3, 3, a ) und (12, 3, Ende). Die Position ist relativ zum rechten Rand des Wörterbuchs angegeben, dies muss bei der Decodierung genauso geschehen.

Die Puffer funktionieren nach dem Prinzip des gleitenden Fensters (engl.: sliding window), d. h. der zu komprimierende Datenstrom wird von rechts in die Puffer hineingeschoben. Wie im Algorithmus vermerkt, erfolgt die Verschiebung um die Länge der gefundenen Übereinstimmung im Wörterbuch und eine weitere Position. Dies führt dazu, dass redundante Tripel vermieden werden, da neue Zeichen sonst immer einzeln in das Wörterbuch übernommen werden. Im Beispiel müsste so das dritte Tripel (0, 0, c ) mit aufgenommen werden, was die Kompressionsrate allerdings deutlich verschlechtert. Dabei sind die Übereinstimmungen grün und die zu verschiebende Zeichenkette in rot gekennzeichnet. Dabei gilt zu beachten, dass immer ein Zeichen mehr verschoben wird, als in der Übereinstimmung gefunden wurde, um neue Zeichen nicht doppelt codieren zu müssen.

Beispiel für eine LZ77-Kompression mit gleitendem Fenster
Zeile 12 11 10  9  8  7  6  5  4  3  2  1  0  1  2  3  4  5  6  7  8  9 Ausgabe
1 leer a a c a a c a b c a   (0, 0, a )
2 leer a a c a a c a b c a b   (1, 1, c )
3 leer a a c a a c a b c a b a a   (3, 4, b )
4 leer a a c a a c a b c a b a a a c Ende   (3, 3, a )
5 a a c a a c a b c a b a a a c Ende   (12, 3, Ende)
fertig

Das erste gesehene Zeichen ist unbekannt, sodass das erste a mit (0, 0, a ) aufgenommen wird. In der 2. Zeile kann das a bereits aus dem Wörterbuch gelesen werden (grün markiert), sodass c als neues Zeichen übernommen wird. In der 3. Zeile ist ein Sonderfall des LZ77-Algorithmus zu sehen, da die übereinstimmende Zeichenkette bis in das Vorschaufenster hineinragt, dies ist im Beispiel durch die grün-rote Zellfärbung dargestellt. Zeile 4 und 5 sind äquivalent zu den ersten beiden zu behandeln, mit der Ausnahme, dass im letzten Tripel ein Ende-Marker als nächstes Zeichen eingeführt wird, da der Text vollständig komprimiert wurde und es kein nächstes Zeichen gibt.

Laufzeitanalyse

[Bearbeiten | Quelltext bearbeiten]

Die Laufzeit des Algorithmus wird mit angegeben, da der Text bei der Kompression nur einmal durchlaufen wird. Dies ist möglich, wenn der Vorschau- und Wörterbuchpuffer eine konstante Größe hat und die Suche nach einer übereinstimmenden Zeichenkette bei großen Texten nicht ins Gewicht fällt. In der praktischen Anwendung ist die Implementierung mit einer normalen Suche (ohne zusätzliche Datenstrukturen) eher langsam.

Vor- und Nachteile

[Bearbeiten | Quelltext bearbeiten]

Ein großer Vorteil des LZ77 ist, dass er ohne jegliche Kenntnis des Textes komprimieren kann und des Weiteren nicht mit einem Patent belegt ist. Der LZ78 (der direkte Nachfolger des LZ77) benötigt für die Rekonstruktion des Textes das initiale Wörterbuch (was aber meist das triviale Wörterbuch ist, in dem jedes Einzeichen-Symbol sortiert einmal vorkommt) und war bis ins Jahr 2004 teilweise durch Patente geschützt. Ein großer Nachteil des LZ77 ist jedoch, dass er allein insbesondere bei kleinen oder nicht natürlichsprachlichen Texten wenig komprimiert oder gar die Datenmenge vergrößert. Dies wird im angegebenen Beispiel deutlich, da der originale Text 16 Zeichen beinhaltet und die Komprimierung 15 Zeichen benötigt, was nur 1 Zeichen Ersparnis bedeutet. Er eignet sich ähnlich wie die Burrows-Wheeler-Transformation oder Move-to-front-Coder sehr gut als Präprozessor, um mittels anderen Kompressionsverfahren wie z. B. einer Huffman-Kodierung Daten effektiv zu komprimieren.

Die Dekompression von LZ77 komprimierten Dateien ist deutlich einfacher als die Kompression, da keine Suche nach übereinstimmenden Zeichenketten stattfinden muss. Die Laufzeit ist linear und hat genau so viele Schritte wie der Originaltext lang ist, also .

Der Pseudocode ist eine Wiedergabe des LZ77 Dekompressionsalgorithmus mit gleitendem Fenster:

 for Jedes Tripel (offset, length, symbol)
     if length > 0; then
         Durchlaufe Rückwärts die bisherige Ausgabe und gib solange Zeichen aus
                 bis eine Länge von length erreicht ist,
                 bei einem Überlauf beginne erneut bei Offset;
     end if
     Gib Symbol aus;
 end for

Die Dekompression von LZ77-Codierungen benötigt kein zusätzliches Wörterbuch, die ausgegebenen Tripel sind eindeutig, um den Text zu rekonstruieren. Die rot hinterlegten Zellen sind Zellen, die für die Rekonstruktion in der darauffolgenden Zeile verwendet werden.

Beispiel für eine LZ77-Dekompression mit gleitendem Fenster
Zeile Eingabe 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
1   (0, 0, a ) leer a
2   (1, 1, c ) leer a a c
3   (3, 4, b ) leer a a c a a c a b
4   (3, 3, a ) leer a a c a a c a b c a b a
5   (12, 3, Ende) a a c a a c a b c a b a a a c Ende
fertig

Ist der erste Eintrag eines Tripels gleich 0, wird der letzte Eintrag im Tripel an den Text angehängt (siehe Zeile 1). In Zeile 2 mit der Eingabe (1, 1, c ), wird bereits der erste Eintrag des rekonstruierten Textes aus Zeile 1 (erste Eintrag des Tripels für Position 1 und die zweite Eintrag des Tripels für die Länge 1) wieder verwendet und anschließend das Zeichen c hinten angehängt. In Zeile 3 ist die Länge der wieder verwendeten Zeichenkette länger als die gespeicherten Daten im Wörterbuch (Länge 4, aber ab Speicherzelle 3 sind nur 3 Zellen verfügbar), es wird deshalb wieder bei der Startposition (Speicherzelle 3) mit der Ausgabe fortgefahren und ein zusätzliches a ausgegeben. Anschließend wird das b als letzter Eintrag des zu verarbeitenden Tripels angehängt. Die Zeilen 4 und 5 sind analog zu verstehen. Das Ende-Zeichen wird bei Rekonstruktion ignoriert, da es global als Ende des Textes zu verstehen ist. Der vollständig rekonstruierte Text lautet aacaacabcabaaac.

Effiziente Konstruktion

[Bearbeiten | Quelltext bearbeiten]

Für eine Laufzeit-effizientere Berechnung der LZ77-Faktorisierung einer Zeichenkette wird im Folgenden die Faktorisierung auf der kompletten Zeichenkette berechnet und das Prinzip des gleitenden Fensters aufgegeben. Schließlich wird in mehreren Anwendungen (siehe Abschnitt Verwendung) auch die LZ77-Kompression auf der gesamten Zeichenkette verwendet.

Eine bezüglich der Laufzeit effiziente Berechnung der LZ77-Faktorisierung für eine Zeichenkette ist mit Hilfe von zusätzlichen Datenstrukturen möglich. Für eine Zeichenkette bezeichne das Suffixarray und das inverse Suffixarray von , d. h. es ist genau dann, wenn . Zudem bezeichne die Länge des längsten gemeinsamen Präfixes der Zeichenketten und , wobei ist.

Die Berechnung nutzt aus, dass für einen Faktor von mit für die Bestimmung der Position des Tupels nur die Textpositionen und betrachtet werden müssen. Dabei ist (NSV steht für next smaller value) und (PSV steht für previous smaller value).[3]

Der Algorithmus LZ_Factor(i, psv, nsv) liefert als Rückgabe die Startposition des nächstens Faktors

 Algorithmus LZ_Factor(i, psv, nsv):
     if lcp(i, psv) > lcp(i, nsv); then
         (pos, len) <- (psv, lcp(i, psv))
     else
         (pos, len) <- (nsv, lcp(i, nsv))
     end if
     if len = 0; then
         pos <- i
     end if
     if i + len > n; then
         print factor(pos, len, 'Ende')
     else
         print factor(pos, len, x[i+len])
     end if
     return i + max(len, 1)

Die beiden Arrays und können aus dem Suffixarray in Linearzeit berechnet werden:

 for i <- 2 to n+1; do
     j <- i-1
     while defined(j) and SA[i] < SA[j]; do
         NSV[j] <- i
         j <- PSV[j]
     end while
     PSV[i] <- j
 end for

Abschließend folgt der Algorithmus zur Berechnung der LZ77-Faktorisierung für die Zeichenkette

 Berechne SA, ISA, NSV und PSV für x
 k <- 1
 while k <= n; do
     psv <- SA[PSV[ISA[k]]]
     nsv <- SA[NSV[ISA[k]]]
     k <- LZ_Factor(k, psv, nsv)
 end while

Laufzeitanalyse

[Bearbeiten | Quelltext bearbeiten]

Die Berechnung der LZ77-Faktorisierung eines Strings ist mit dem Algorithmus in Zeit möglich, wobei die Länge der Eingabezeichenkette ist. Die Methode LZ_Factor benötigt Zeit, wenn die Berechnung von über Range Minimum Queries realisiert wird. Die Berechnung der Arrays und ist in Zeit möglich, sodass der gesamte Algorithmus zur Berechnung Zeit benötigt (dies setzt eine Linearzeitkonstruktion des Suffixarrays voraus).[3]

Vergleich verschiedener Implementierungen

[Bearbeiten | Quelltext bearbeiten]

Zur Berechnung der LZ77-Kompression einer Zeichenkette gibt es verschiedene Implementierungen, die sich in der Laufzeit und im Speicherbedarf unterscheiden. Für den Vergleich wird die LZ-Faktorisierung auf der kompletten Zeichenkette mit der Länge betrachtet. Die Analyse des Speicherbedarfs orientiert sich an der Speicherung in 32- oder 64-Bit-Worten. Dabei belege ein Buchstabe des Alphabets ein Viertel eines Speicherwortes und ein Integer ein ganzes Speicherwort.[2]

In der folgenden Tabelle sind einige Implementierungen zur Berechnung der LZ77-Faktorisierung mit ihrer Laufzeit, ihrem Speicherbedarf und den verwendeten Datenstrukturen aufgelistet.

Algorithmus
von
Worst-Case-
Laufzeit
Speicherbedarf
in Wörtern
Verwendete
Datenstrukturen
Bemerkungen
Abouelhoda et al.[4] Suffixarray, LCP-Array
Chen et al.[5][6] Suffixarray, LCP-Array
Chen et al.[5][6] Suffixarray, LCP-Array Positions-Array überschreibt Suffix-Array
Chen et al.[5][6]    Suffixarray, LCP-Array Positions-Array überschreibt Suffix-Array
Crochemore
und Ilie[7]
   Suffixarray, LCP-Array, LPF-Array LZ77-Ausgabe erfordert keinen zusätzlichen Platz
Crochemore
und Ilie[7]
Suffixarray, LCP-Array, LPF-Array LZ77-Ausgabe erfordert keinen zusätzlichen Platz, kein Zugriff auf die Zeichenkette für die LZ77-Kompression notwendig

Einige der in der Tabelle aufgeführten Algorithmen verwenden das LPF-Array (LPF steht für Longest Previous Factor). Das LPF-Array ist wie folgt definiert:[2] Für jede Position der Zeichenkette ist definiert als Länge des längsten Faktors von , der an der Position beginnt und vor der Position in auftaucht, d. h. . Aus dem LPF-Array kann die LZ77-Faktorisierung einer Zeichenkette in linearer Zeit berechnet werden. Das LPF-Array kann unter anderem mit den oben aufgeführten NSV und PSV-Arrays berechnet werden, denn es gilt:[3]

Für die Implementierung einiger der in der Tabelle aufgeführten Algorithmen wird ein Stapelspeicher verwendet, welcher zusätzlichen Speicher benötigt. In der Tabelle ist die Verwendung eines Stacks durch ein an den Speicherbedarf angehängtes dargestellt. Die Größe des Stapelspeichers ist begrenzt durch - dies ist der Fall, wenn die Zeichenkette die Form mit aufweist. Erwartet ist .[2]

Heute wird die LZ77-Kompression u. a. noch auf dem Game Boy Advance, dem AutoCAD DWG Format und weiteren eingebetteten Systemen verwendet. Mit der Huffman-Kodierung kombiniert wird LZ77 in dem vielbenutzten Deflate-Algorithmus verwendet, welcher wiederum von sehr bekannten Komprimierungsprogrammen sowie dem Grafikformat PNG genutzt wird. Dass LZ77 mit keinerlei Patenten belegt ist, dürfte wohl der Grund sein, dass das Verfahren heute immer noch dem ein Jahr später veröffentlichten Nachfolger LZ78 vorgezogen wird, der bis ins Jahr 2004 mancherorts in Teilen patentiert war.

In der algorithmischen Verarbeitung von Zeichenketten wird die LZ77-Faktorisierung für die Berechnung von Regelmäßigkeiten in Strings eingesetzt. Dabei wird stets die Faktorisierung auf dem gesamten String betrachtet und nicht nur innerhalb des gleitenden Fensters. Zudem kann die Ausgabe vereinfacht werden, da der ursprüngliche String in den Anwendungen vorliegt und nicht rekonstruiert werden muss. Eine Auswahl von Problemstellungen, bei denen die LZ77-Faktorisierung verwendet werden kann, findet sich in der folgenden Auflistung:

  • Bestimmung von Wiederholungen in Zeichenketten[8][9] In einer Zeichenkette wird nach nicht-leeren Teilzeichenketten der Form (im engl. als tandem repeat oder square bezeichnet) gesucht.
  • Zeichenketten mit Wiederholungen mit Lücken (engl.: gaps) fester Größe:[10] In einer Zeichenkette werden alle nicht-leeren Teilzeichenketten der Form mit und für ein gegebenes gesucht.
  • Maximale Periodizitäten in Zeichenketten:[11] In einer Zeichenkette wird eine maximale Periodizität gesucht.
    • Eine Periodizität in einer Zeichenkette ist eine nicht-leere Zeichenkette der Form , wobei und ein Präfix von ist. Dabei ist die Periodenlänge.
    • Ein Vorkommen der Periodizität mit einer Periodenlänge ist maximal, wenn
      1. ist oder keine Periodizität mit Periodenlänge ist und
      2. ist oder keine Periodizität mit Periodenlänge ist.

Die Kompressionsgüte ist direkt von der Größe des Lexikons abhängig. Um gute Kompressionsraten zu erhalten, muss das gleitende Fenster daher eine gewisse Mindestgröße erreichen. Da im Algorithmus der zu komprimierende Text mit jedem Eintrag im Lexikon verglichen werden muss (siehe Abschnitt Algorithmus), steigt die zum Komprimieren benötigte Zeit mit der Größe des Fensters linear an. Der LZ77-Algorithmus in Reinform fand daher zunächst wenig Beachtung. James Storer und Thomas Szymanski verbesserten 1982 einige Probleme in dem nun Lempel-Ziv-Storer-Szymanski (LZSS) genannten Algorithmus, der auch von Phil Katz für den weit verbreiteten Deflate-Algorithmus verwertet wurde. Der Vergleich des zu komprimierenden Textes mit allen Einträgen im Lexikon entfällt bei einer effizienten Implementierung wie im Abschnitt zur effizienten Konstruktion, wo immer nur der Vergleich mit maximal zwei Einträgen aus dem Lexikon notwendig ist.

In Reduced Offset Lempel Ziv (ROLZ, auch Lempel Ziv Ross Williams, von Ross Williams, 1991) und dem Lempel-Ziv-Markow-Algorithmus (LZMA, von Igor Pavlov, 1998) fand er bekanntere, moderne Nachfolger.

Verwandte Algorithmen

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Jacob Ziv, Abraham Lempel: A Universal Algorithm for Sequential Data Compression. In: IEEE Transactions on Information Theory, Nr. 3, Volume 23, 1977, S. 337–343 cs.duke.edu (PDF; 481 kB)
  2. a b c d Anisa Al-Hafeedh et al.: A Comparison of Index-based Lempel-Ziv LZ77 Factorization Algorithms. In: ACM Computing Surveys, Nr. 1, Volume 45, 2012, S. 5:1–5:17
  3. a b c Juha Kärkkäinen, Dominik Kempa, Simon J. Puglisi: Linear Time Lempel-Ziv Factorization: Simple, Fast, Small. In: CPM 2013, Lecture Notes in Computer Science, Volume 7922, Springer, 2013, ISBN 978-3-642-38904-7
  4. Mohamed I. Abouelhoda, Stefan Kurtz, Enno Ohlebusch: Replacing suffix trees with enhanced suffix arrays. In: Journal of Discrete Algorithms, Nr. 1, Volume 2, 2004, S. 53–86
  5. a b c Gang Chen, Simon J. Puglisi, William F. Smyth: Fast and Practical Algorithms for Computing All the Runs in a String. In: Combinatorial Pattern Matching, 18th Annual Symposium, CPM 2007, London, Canada, July 9-11, 2007, Proceedings, S. 307–315
  6. a b c Gang Chen, Simon J. Puglisi, William F. Smyth: Lempel-Ziv Factorization Using Less Time and Space. In: Mathematics in Computer Science, Nr. 4, Volume 1, 2008, S. 605–623
  7. a b Maxime Crochemore, Lucian Ilie: Computing Longest Previous Factor in linear time and applications. In: Information Processing Letters, Nr. 2, Volume 106, 2008, S. 75–80
  8. Maxime Crochemore: Transducers and repititions. In: Theoretical Computer Science, Nr. 1, Volume 45, 1986, S. 63–86
  9. Jens Stoye, Dan Gusfield: Simple and flexible detection of contiguous repeats using a suffix tree. In: Theoretical Computer Science, Nr. 1–2, Volume 270, 2002, S. 843–856
  10. Roman M. Kolpakov, Gregory Kucherov: Finding Repeats with Fixed Gap. In: Proceedings of the 7th International Symposium on String Processing and Information Retrieval (SPIRE), 2000, IEEE Computer Society, S. 162–168
  11. Michael G. Main: Detecting leftmost maximal periodicities. In: Discrete Applied Mathematics, Nr. 1–2, Volume 25, 1989, S. 145–153