Warum eliminiert die Huffman-Codierung die Entropie, die Lempel-Ziv nicht hat?

13

Der beliebte DEFLATE-Algorithmus verwendet Huffman-Codierung über Lempel-Ziv.

Wenn wir eine zufällige Datenquelle haben (= 1-Bit-Entropie / Bit), ist es im Allgemeinen wahrscheinlich , dass keine Codierung, einschließlich Huffman, diese im Durchschnitt komprimiert. Wenn Lempel-Ziv "perfekt" wäre (was sich für die meisten Klassen von Quellen annähert, da die Länge unendlich ist), würde das Nachkodieren mit Huffman nicht helfen. Natürlich ist Lempel-Ziv nicht perfekt, zumindest nicht mit begrenzter Länge, und daher bleibt eine gewisse Redundanz bestehen.

Diese verbleibende Redundanz beseitigt die Huffman-Codierung teilweise und verbessert dadurch die Komprimierung.

Meine Frage ist: Warum wird diese verbleibende Redundanz durch Huffman-Codierung und nicht durch LZ erfolgreich beseitigt? Welche Eigenschaften von Huffman versus LZ machen dies möglich? Würde ein erneutes Ausführen von LZ (dh ein zweites Codieren der komprimierten LZ-Daten mit LZ) etwas Ähnliches bewirken? Wenn nein, warum nicht? Ebenso würde das Komprimieren zuerst mit Huffman und anschließend mit LZ funktionieren, und wenn nicht, warum?

UPDATE: Es ist klar, dass auch nach LZ eine gewisse Redundanz bestehen bleibt. Mehrere Leute haben darauf hingewiesen. Was nicht klar ist: Warum wird die verbleibende Redundanz von Huffman besser angegangen als von LZ? Was ist daran einzigartig im Gegensatz zur ursprünglichen Quellenredundanz, bei der LZ besser funktioniert als Huffman?

— SRobertJames
quelle

13

Dies war ursprünglich ein Kommentar, aber es wurde zu lang.

Wenn Sie sich DEFLATE ansehen, komprimiert Huffman die Ausgabe von LZ77. LZ77 sendet (wenn dies weniger Bits als die Rohdaten erfordert) einen Zeiger früher in die zu komprimierende Zeichenfolge und eine Übereinstimmungslänge, die angibt, wie viele Symbole nach dem Zeiger verwendet werden sollen. Die Theorie zeigt, dass diese Technik auch ohne zusätzliche Komprimierung schließlich zur Quellenentropie konvergiert. Bei der Datenkomprimierung können Sie jedoch jederzeit eine nicht zufällige Verteilung komprimieren. Es gibt keinen Grund zu der Annahme, dass die Ausgabe von LZ77 - die Zeiger und die Übereinstimmungslängen - völlig zufällig ist. Sie müssen konvergieren, um die Zufälligkeit in der asymptotischen Grenze zu vervollständigen, da LZ77 asymptotisch optimal ist, aber in der Praxis nur ein endliches Wörterbuch verwendet wird. Vermutlich bleiben sie also weit genug vom Zufall entfernt, dass Sie gewinnen, wenn Sie sie weiter komprimieren. Natürlich verwenden Sie einen Huffman-Code für die Zeiger und einen anderen für die Übereinstimmungslängen, da diese beiden Prozesse unterschiedliche Statistiken haben.

Warum Huffman anstelle von LZ für die zweite Komprimierungsrunde verwenden? Der große Vorteil von LZ gegenüber Huffman besteht in der Behandlung von Abhängigkeiten zwischen Symbolen. Wenn auf Englisch ein Buchstabe ein "q" ist, ist der nächste höchstwahrscheinlich ein "u" und so weiter. Handelt es sich bei den Symbolen um unabhängige Ereignisse, ist Huffman einfacher und eignet sich genauso gut oder besser für kurze Zeichenfolgen. Für die Ausgabe von LZ77 ist meine Intuition, dass die Symbole ziemlich unabhängig sein sollten, sodass Huffman besser funktionieren sollte.

— Peter Shor
quelle

Ich bin mit Ihnen in Ihrem ersten Absatz: LZ lässt noch etwas Redundanz übrig, um weiter zu komprimieren. Aber Ihr zweiter Absatz scheint immer noch zu springen, wenn Sie nicht mit der Hand winken. Es gibt zwei Aussagen: 1. Die nach LZ verbleibende Redundanz ist nullter Ordnung (dh p (X_n) ist ungefähr unabhängig von x_n-1; ich verwende den Begriff nullter Ordnung wie im Modell nullter Ordnung, z data-compression.com/theory.shtml ) und 2. Bei Redundanz nullter Ordnung arbeitet Huffman besser als LZ; Bei Redundanz höherer Ordnung arbeitet LZ besser. Vielleicht sind diese Behauptungen beide wahr, aber Sie haben es auch nicht gerechtfertigt

— SRobertJames

2

@Robert: Korrelationen höherer Ordnung haben keinerlei Einfluss auf die Huffman-Codierung. LZ arbeitet asymptotisch optimal für Redundanz höherer Ordnung, aber der zusätzliche Aufwand bedeutet, dass es bei Quellen endlicher Länge nullter Ordnung nicht so gut funktioniert. Dies muss irgendwo in der Literatur experimentell untersucht worden sein; Vielleicht kann jemand anderes einen Hinweis auf eine Referenz geben. Für Punkt 1 ist meine Intuition, dass jede Redundanz höherer Ordnung, die nach LZ verbleibt, zu kompliziert ist, um in einem einfachen Codierungsschema verwendet zu werden, aber ich habe keine gute Möglichkeit, dies zu rechtfertigen.

— Peter Shor

10

Bei der Datenkomprimierung geht es in Wirklichkeit um zwei Dinge: Modellierung und Codierung. Algorithmen der LZ-Familie modellieren den Text als Verkettung exakter Wiederholungen, was für viele Zufallsquellen asymptotisch optimal und für viele reale Texte einigermaßen gut ist. Für einige Eingaben kann dieses Modell jedoch ziemlich schlecht sein. Beispielsweise können Sie LZ nicht verwenden, um ein Suffix-Array direkt zu komprimieren, obwohl das Suffix-Array genauso komprimierbar ist wie der ursprüngliche Text.

$(p, \ell, c)$ $p$ $\ell$ $c$

$\log n$ $n$

Kurz gesagt, Huffman schlägt LZ bei der Komprimierung der Tupel, da sein Modell (feste Verteilung im Vergleich zu exakten Wiederholungen) besser zu den Daten passt.

— Jouni Sirén
quelle

Vielen Dank, Jouni. Es hört sich so an, als ob die verbleibende Hauptredundanz darin besteht, dass die Wiederholungslängen in der Regel eher kleiner als größer sind (nicht gleichmäßig über [0,2 ^ n] verteilt). Huffman kann diese Asymmetrie nullter Ordnung gut bewältigen, wohingegen LZ größere Features benötigt, um gut zu funktionieren. Ist das korrekt? Und warum nicht gleich mit Huffman anfangen - warum überhaupt mit LZ?

— SRobertJames

3

Wenn wir den Text direkt mit Huffman komprimieren, können wir keine bessere Komprimierung als Entropie nullter Ordnung erzielen. Die meisten realen Texte weisen jedoch signifikante Redundanzquellen auf, die mit Entropie nullter Ordnung nicht angemessen modelliert werden können. In vielen Fällen können wir diese Redundanz durch die Verwendung von LZ vor Huffman komprimieren.

— Jouni Sirén

2

Ich glaube, die Antwort liegt in der Größe des Nachschlagewörterbuchs.

Daten haben ein Gefühl von Lokalität (das heißt, wenn ein Datenelement verwendet wurde, wird es wahrscheinlich bald wieder verwendet), und der LZ-Algorithmus nutzt dies bei der Konstruktion des Nachschlagewörterbuchs aus. Es wird ein Versuch mit einer begrenzten Anzahl möglicher Knoten generiert, um die Suche schnell zu halten . Wenn es die Größenbeschränkung erreicht, wird ein weiterer Versuch unternommen, den vorherigen zu "vergessen". Daher muss die Nachschlagetabelle für die einfacheren Zeichen erneut erstellt werden. Werden jedoch einige Wörter nicht mehr verwendet, werden sie nicht mehr im Speicher gespeichert, sodass eine kleinere Codierung verwendet werden kann.

Daher kann mit der Huffman-Codierung eine LZ-Ausgabe weiter reduziert werden, da durch statistische Analyse diese Redundanz bei der Erstellung der Nachschlageversuche erkannt werden kann.

— Manuel Ferreria
quelle

Ich akzeptiere den ersten Absatz: Sie erklären, warum LZ die Redundanz verlässt. Aber der zweite Absatz scheint ein ziemlicher Sprung zu sein: Warum fängt Huffman diese Redundanz auf? Warum nicht nochmal LZ? Und wenn Huffman umfassender ist, warum nicht gleich?

— SRobertJames

2

Vielleicht bin ich hier nicht auf dem richtigen Weg, aber die Huffman-Codierung untersucht die gesamte Eingabe, um die Codierungstabelle (Baum) zu erstellen, während Lempel-Ziv im weiteren Verlauf codiert. Dies ist sowohl ein Vorteil als auch ein Nachteil für Huffman. Der Nachteil liegt auf der Hand, dass wir den gesamten Input sehen müssen, bevor wir beginnen können. Der Vorteil ist, dass Huffman Statistiken berücksichtigt, die an einer beliebigen Stelle in der Eingabe auftreten, während Lempel-Ziv schrittweise darauf aufbauen muss. Oder anders ausgedrückt, Lempel-Ziv hat eine "Richtung", die Huffman nicht hat.

Aber all dies ist nur meine naive Art, mir vorzustellen, wie die Dinge sind. Wir würden hier einen echten Beweis brauchen, um zu sehen, wie genau Huffman Lempel-Ziv übertrifft.

— Andrej Bauer
quelle

2

Die Leute haben eine adaptive Huffman-Codierung definiert, die die Eingabe nur einmal betrachtet. Für die Zwecke dieser Diskussion verhält sich die adaptive und die nicht adaptive Huffman-Codierung ziemlich ähnlich.

— Peter Shor

2

Die kurze Antwort lautet: LZ ist ein "universeller" Algorithmus, bei dem die genaue Verteilung der Quelle nicht bekannt sein muss (nur die Annahme, dass die Quelle stationär und ergodisch ist erforderlich). Aber Huffman ist nicht; es muss die genaue Verteilung kennen, von der die Quelle abgetastet wird (um den Huffman-Baum zu erstellen). Durch diese zusätzlichen Informationen erreicht Huffman enge Kompressionsgarantien. Für praktische Dateikomprimierungsalgorithmen kann Huffman jedoch ungünstiger sein, da zunächst empirische Statistiken der Datei gesammelt und dann in einer zweiten Hälfte die eigentliche Komprimierung durchgeführt werden müssen, während LZ online implementiert werden kann.

Weitere Details finden Sie in Standardtexten zur Informationstheorie, z. B. Elements of Information Theory von Cover und Thomas.

— MCH
quelle

Ich denke, dass die stationäre ergodische Quelle nur eine Annahme ist, die die Analyse von LZ erleichtert. Schließlich basiert die Komprimierung auf kombinatorischen Eigenschaften der Eingabe, die in vielen Fällen nur gut mit den statistischen Eigenschaften übereinstimmen. Betrachten Sie beispielsweise eine Sammlung von Texten in englischer Sprache im Nur-Text-Format, gefolgt von denselben Texten im HTML-Format. LZ komprimiert diese Sammlung sehr gut, obwohl sie nicht wie eine stationäre Ergodensammlung aussieht.

— Jouni Sirén

@Jouni: Ich würde diesem Kommentar nicht zustimmen. Ich denke, dass die englische Sprache im Klartext in gewissem Sinne einer stationären ergodischen Quelle ähnelt, und diese Ähnlichkeit ist genau das, was LZ ausnutzt.

— Peter Shor

@Peter: Aber in diesem Fall generiert die Quelle zuerst einige Texte im Nur-Text-Format und dann genau dieselben Texte im HTML-Format. Diese Änderung von Klartext zu HTML an einem beliebigen Punkt scheint die ergodische stationäre Eigenschaft zu brechen. Auf der anderen Seite sind die Komprimierungsergebnisse viel besser als beim separaten Komprimieren von Nur-Text und HTML-Texten, da zwischen einem Text im Nur-Text-Format und demselben Text im HTML-Format viele gegenseitige Informationen bestehen.

— Jouni Sirén