 Unser nächster Talk dreht sich um ein besonderes Hobby. Manche Leute sammeln Briefmarken, manche Leute haben es mit Zierfischen, manche fliegen Hubschrauber, manche programmieren, manche machen Elektrotechnik. Kai, der vor sechs Jahren seine Doktorarbeit geschrieben hat in Mathematik, beschäftigt sich seit ungefähr 15 Jahren mit verlustfreien Kompressionsalgorithmen. Es ist ein zugegebener aus meiner Sicht etwas helles Hobby. Und nicht einziges. Aber es sammeln ja auch Leute Briefmarken. Kai hat am KIT seine Doktorarbeit gemacht, er hat in Kaiseslautern Mathematik studiert und heißt ihn willkommen zu seinem Talk über verlustfreie Datenkompression. Es wird kein explizites Q&A geben oder es ist die Möglichkeit, zwischen drin Fragen zu stellen, so dass vielleicht kein explizites Q&A anschließend nötig ist. Habt Spaß. Ja, schönen Dank für die Anmoderation. Ich darf euch auch herzlich willkommen heißen zu meinem Vortrag hier über verlustfreie Datenkompression. Ich beabsichtige, das ein bisschen interaktiv zu gestalten. Ich werde Fragen stellen. Ich werde ein bisschen nach euren Erfahrungen fragen. Und wenn eine Wortmeldung gewünscht ist, dann findet sich vielleicht jemand, der das Mikro herumreicht. Andernfalls bitte einfach ein bisschen lauter sprechen. Und ich werde die Frage oder den Kommentar dann hier im Mikro wiederholen. Ja, zur kleinen Auflockerung möchte ich mit einem lustigen Zitat starten. Das müsst ihr euch durchlesen. Das ist dieses hier. Kennt das jemand? Okay, ich dachte, ich erzähle euch was Neues hier. Gut. Ja, worum soll es in meinem Vortrag gehen? Es ist ein Übersichtsvortrag, der einen Überblick vermitteln soll über die Verfahren zur verlustfreien Datenkompression. Ich werde kürzlich entwickelte neue Methoden und Forschungsanstrengungen etwas beleuchten. Und im Anschluss daran auf moderne Anwendungen eingehen dieser Verfahren, die nicht immer wirklich offensichtlich sind. Also es steckt Datenkompression in Anwendungen und in Themenbereichen drin, die vielleicht nicht jedem bekannt sind. Was ich definitiv und explizit in diesem Vortrag nicht behandle, sind Details, Implementierungsdetails, technische Interner. Ich werde die bisweilen sehr anstrengende und für einige sehr unvorteilhafte Patent-Situationen nicht beleuchten. Das ist ein Themenkomplex für sich. Und ja, wie ist der Vortragstitel schon darstellt? Ich werde mich insbesondere nicht mit verlustbehafteter Kompression beschäftigen. Das involviert Themen und Technologien, die alle zu komplex sind jetzt auch in der Darstellung. Und das soll also hier nicht Thema sein. Gut, zur Struktur meines Vortrags. Ich werde zunächst eine grobe Einführung geben. Anschließend soll es um die grundlegenden Techniken gehen zur verlustfreien Datenkompression. Die beiden Unterpunkte stellen so die Hauptzweige, Haupttechnologiezweige dar. Das erste ist die Entropäkodierung. Das zweite sind die Wörterbuchverfahren. Und dann habe ich eine Referenzfolie, wo ich ein paar weitere leistungsfähige Technologien zusammengetragen habe. Das handle ich aber dann in einer Folie ab. Gut, anschließend soll es um konkrete Methoden gehen. Ich werde mich zunächst auf die sogenannten Lämpel-Zif-Verfahren stürzen. Das sind Wörterbuchverfahren, die sehr prominent vertreten sind in zahlreichen Anwendungen. Anschließend bekommt eine Methode, eine Folie für sich. Ich habe sie The Famous Classic getauft. Sie alle haben mit dieser Methode schon zu tun gehabt. Ich gehe dann später darauf ein. Und als drittes soll es um kürzlich entwickelte, in den letzten 5, 6 Jahren entwickelte Methoden gehen. Ich habe hier sehr viel Recherche betrieben. Ich habe mir die Mühe gemacht, verschiedene Paper zu lesen und habe für euch mal zusammengefasst, was diese Methoden sind und welche Eigenschaften sie haben. Gut, dann soll es um den Wirkungsbereich, Verlustfreie Datenkompression gehen und die Anwendungen. Und zum Abschluss werde ich dann noch eine Prognose wagen, die so ein bisschen den Input aufnimmt oder verwertet, den ich aus der Literatur gewonnen habe. Aber auch so ein bisschen meine eigene Einschätzung wieder gibt, wo denn da die Reise hingehen wird. Gut, zur Einführung. Ich beginne mit ein bisschen Geschichte. Das soll darstellen, wie sich so der Schwerpunkt der Anwendung Verlustfreier Datenkompression verlagert hat im Laufe der letzten 3, 4 Dekaden. Ich beginne mit den 80er-Jahren und dem Beginn der 90er-Jahre. Dort war es so, dass also Speicherplatz wie auch Bandbreite sehr limitiert waren und sehr teuer im Vergleich zu dann der kommenden Dekade. Es hat moderat dimensionierten Datentransfer gegeben, soweit das im Konsumentensektor sich abgespielt hat, hat man dort also sehr viel Floppy-Discs ausgetauscht. Ich bin ein Kind der 80er-Jahre, ich habe das noch viele Jahre miterlebt und ich gehe davon aus, sehr viele von Ihnen wissen, von was ich rede. Der Hauptschwerpunkt der Anwendung war da schlicht und ergreifend Speicherplatz zu sparen. Man hatte im Wesentlichen Festplatten und Floppy-Discs und beides war relativ teuer oder sehr limitiert in der Datenkapazität. Dann von Mitte der 90er-Jahre bis Mitte der Nullerjahre hat sich schon einiges getan. Der Speicherplatz wurde immer reichhaltiger, immer günstiger. Zu den Floppy-Discs, die so langsam verdrängt wurden, diese wurden ersetzt durch CD-ROM und DVD, also optische Speichermedien, die eine deutlich höhere Datenkapazität schon geboten haben. Mitte der 90er kam dann auch so langsam das World Wide Web ins Leben, was, wie wir alle wissen, sich explosionsartig weiterentwickelt hat. Im Zusammenhang damit kam dann auch neue Datentypen in unser Leben, Bilder, Sounddateien, Videodateien, die gab es selbstverständlich auch davor schon, aber bei Weitem nicht in diesem Ausmaß und vor allem waren sie in der Regel auch noch zu teuer zur Weiterverarbeitung und zur Massennutzung. Der Datentransfer hat im Zuge der Entstehung und der Entwicklung des World Wide Web natürlich massiv zugenommen. Hier war ein großer Schwerpunkt der Anwendung verlustfreier Datenkompression. Dann diese neuen Datentypen und Volumina irgendwie unter Kontrolle zu bringen. Gut, und als letzten Abschnitt habe ich die Zeitspanne gewählt von Mitte der Nullerjahre und später, also bis in Grunde zur heutigen Zeit. Ich stehe auf dem Standpunkt, dass man heute als Privatperson nicht wirklich mehr Speicherplatz sorgen hat, wenn man ein bisschen haushält oder pragmatisch seine Datenspeicherung auslegt. Wir haben unzählige Möglichkeiten, Daten zu speichern. Ich habe die, also ein bisschen aufgeführt, die wesentlichen. Ein Punkt, der da wesentlich ist, ist eine Festplattentechnologie mit dem Kürzel PMR steht für Perpendicular Magnetic Recording. Das ist eine Technologie, die Mitte der Nullerjahre, also gegen 2005, in die, ja, also in die kommerzielle Nutzung gekommen ist und eine mehr oder minder schlagartige Verdreifachung der Datenkapazität erlaubt hat. Also möglicherweise erinnern sich noch einige von Ihnen, dass es relativ abrupt Festplatten gegeben hat, die 2 GB Kapazität und mehr geboten haben. Ja, wir haben in der letzten Dekade eine Explosion von Daten erzeugenden Geräten erlebt. Kameras, Mikrofone, Sensoren verschiedenster Color. Diese Devices erzeugen einen massiven und sich exponentiell steigerten Daten, ein Datenmenge und auch ein Datentransfer. Und hier sind jetzt die Hauptanwendungspunkte, verlustfreie Datenkompression, die Reduktion der Übertragungskosten und ein ganz wesentlicher Punkt, die Infrastruktur zur Datenübermittlung wächst bei Weite nicht so rasant wie die Menge der erzeugten Daten. Wir erleben, dass Multimedia-Dateien immer höhere Auflösung mitbringen, immer höhere Klangtreue bei Audio-Dateien oder einen immer höheren Dynamikbereich. Und damit potenzieren sich die Datenmengen. Und hier muss man dann komprimieren, um das noch unter Kontrolle zu halten. Ja, und ein dritter Anwendungspunkt ist das sogenannte Cold Archiving. Da geht es also darum, in Grunde Daten weg zu archivieren. Die archiviert werden müssen aber nur selten gelesen werden. Hier spielt dann die Performance der Kompressionsmethode nicht die große Rolle. Gut, ich komme zu den Basics. Was ist der Ausgangspunkt verlustfreie Datenkompression? Der Ausgangspunkt ist der, dass nicht zufällige und bedeutungsbehaftete Daten Redundanz aufweisen, redundante Informationen. Wirklich perfekter Zufall, perfekt zufällige Daten sind einerseits selten und andererseits bedeutungslos in aller Regel. Es geht also bei Datenkompression verlustloser Datenkompression um die Identifikation von Mustern und von Struktur und deren Ausnutzung. Dann möchte ich dies nochmal betonen. Es gibt keinen Algorithmus, der alle Daten einer vorgegebenen Größe komprimieren kann. Es gibt noch nicht mal ein Algorithmus, der nur 1 % der Daten mit einer vorgegebenen Größe komprimieren kann, noch nicht mal um ein Beid. Wenn wir Daten komprimieren, bewegen wir uns in dem sehr kleinen, strukturierten und bedeutungsvollen Teil von den möglichen Daten. Ich will das an dieser Stelle betonen, weil es in der Vergangenheit die Firmen gegeben hat, die strikt und fest behauptet haben, sie hätten neue Algorithmen entwickelt, die alles komprimieren und das auch noch mehrfach hintereinander. Das ist Unfug und das hat sich dann auch später immer geklärt. Als Letztes sei darauf hingewiesen, dass je kleiner die Datenmenge ist, desto schwieriger ist es, diese zu komprimieren. Wir werden gleich ein Beispiel betrachten. Ich habe versucht, die Kompressionsmethoden mal alle in ein allgemeines Schema zu fassen. Ich bin bei diesem Schema gelandet. Das Schema besteht aus drei Stufen. Die erste Stufe ist die, dass ich Statistik betreibe und Informationen sammle über die Daten, die ich bereits gelesen habe, also die bereits bekannt sind. Und aus diesen Daten wird dann ein wie auch immer geartetes Modell gebaut. Der zweite Teil ist der wesentliche Teil. Ich habe diesen Teil kreativ past to present Mapping genannt. Hier geht es also darum, aus den bereits gelesenen Daten eine Vorhersage abzuleiten, die es gestartet, die neuen frisch gelesenen Daten zu komprimieren. Und da gibt es im Grunde zwei verschiedene Techniken. Die erste Technik generiert ein Wahrscheinlichkeitsmodell basierend auf, oder einer Wahrscheinlichkeitsverteilung, Entschuldigung, basierend auf dem Modell, was ich bereits generiert habe aus den vergangenen Daten und sagt dann aus, mit welcher Wahrscheinlichkeit welche Daten folgen. Die zweite Technik sind die Match and Reuse Verfahren, wie ich sie getauft habe. Da geht es also darum, Daten, die neu gelesen werden, zu matchen mit Daten, die ich bereits in der Vergangenheit gelesen habe. Also ich suche einfach nach Korrespondenzen. Ich lese zum Beispiel einen neuen Buchstaben oder einen neuen String. Und schaue, ob ich diese Daten nicht schon mal in der Vergangenheit gelesen habe und erzeuge dann eine Referenz auf die bereits gelesenen Daten, die wiederum dann deutlich einfacher und platzsparener zu kodieren ist, wie die eigentlich sich wiederholenden Daten. Und die dritte Stufe ist die Kodierungsstufe. Da geht es darum, für die Daten, die ich dann im Laufe dieses Prozesses angesammelt habe, entweder die Codes für die tatsächlichen Symbole, die gelesen werden, oder eben die Referenzdaten, dann Binärcodes zu erzeugen und diese zu schreiben. Ja, und die dritte Stufe hat man im Grunde theoretisch zu Ende gedacht. Und praktisch implementiert und insofern ist die Schlussfolgerung hier, die leistungsfähiger, die Modellierungs- und die Mappingstufe sind, desto besser wird die Kompressionsperformance sein. Gut, ich komme zu den Technologien. Da habe ich zum ersten die schon erwähnte Entropie-Kodierung. Um was geht es da? Es geht darum, ein Wahrscheinlichkeitsmodell zu erzeugen für die folgenden noch nicht gelesenen Daten basierend auf den bereits gelesenen Daten. Und meistens wird ein Wahrscheinlichkeitsmodell oder eine Wahrscheinlichkeitsverteilung generiert für nur das nächste Symbol. Also man schaut nur auf das nächste Symbol und nicht irgendwie weiter in die Zukunft für größere Strings von Symbolen. Basierend auf der Wahrscheinlichkeitsverteilung, die dort berechnet wird, generiere ich dann sogenannte Variable-Length-Codes. Hier passiert die eigentliche Kompression. Die Symbole, für die ich Wahrscheinlichkeiten berechnet habe, sollen kürzere Codes erhalten, wenn sie mit höherer Wahrscheinlichkeit auftreten. Somit habe ich dann im Durchschnitt dann eine Datenkompression erreicht. Also kürzere Codes für sehr wahrscheinlich folgende Symbole und längere Codes, die dürfen dann auch länger sein, wie die eigentlich ursprünglich gewählten Codes dann für selten oder mit geringer Wahrscheinlichkeit folgende Daten. Entropieverfahren sind in der Regel ja relativ langsam gestatten, aber eine hohe Kompression. Und dieser Typus von Verfahren ist empfohlen für schwach strukturierte Daten. Was soll das hier heißen? Der Punkt ist der, dass ich eine Wahrscheinlichkeitsverteilung berechne für die folgenden Symbole. Und für weniger wahrscheinliche Symbole, die folgen, habe ich also kürzere Codes. Wenn und diese Wahrscheinlichkeitsverteilung trifft also keine explizite, keine konkrete Vorhersage, was folgen wird, sondern eben gibt das in Form einer Wahrscheinlichkeit wieder. Die werden dann auch Daten effektiv komprimiert, die nicht perfekt zu der jeweils berechneten höchsten Wahrscheinlichkeit passen, sondern das Wahrscheinlichkeitsmodell muss einfach nur hinreichend gut sein, um dort eine Kompression zu erzielen. Und das unterscheidet diese Verfahren von den zunächst dann im weiteren diskutierten Wörterbuchverfahren. Eine ganz wesentliche Eigenschaft dieser Entropie-Verfahren wird abgebildet in diesem Motto, auch bekannt unter Orcams Rasiermesser. Ich darf mal kurz in die Menge fragen, wem sagt dieser Abkürzung was oder dieses Konzept den Allermeisten. Bedeutet die einfachste Theorie, die die Vergangenheit erklärt, ist in der Regel auch die beste Vorhersage für die Zukunft. Heißt übersetzt für Datenkompressionen, es ist in der Regel nicht vorteilhaft, ein übermäßig komplexes Modell zu wählen. Also das Modellrauschen, wenn man so will, bringt an der Stelle nichts. Also in der Kürze liegt die Würze und die Leistungsfähigkeit ist da auch in der Einfachheit begründet. Gut, begonnen hat die Geschichte der Entropie-Verfahren in Grunde mit einem Herrn Hafmen, der das nach ihm bekannte Kodierungsverfahren entwickelt hat, das war Anfang der 50er Jahre. Da geht es darum, Codes für Symbole zu berechnen, die die Eigenschaft haben, dass sie präfixfrei sind. Was heißt präfixfrei? Heißt, wenn ich zwei verschiedene Symbole habe und ich habe zwei Codes, zwei korrespondierende Codes für diese Symbole, dann kann ich diese Codes hintereinander schreiben, ohne Trendzeichen und ohne weitere Informationen und kann sie eindeutig dekodieren. Das heißt also, es wird dort bekannt sein, wo ein Code endet und der nächste anfängt. Und das erlaubt uns eben diese Codes einfach hintereinander zu reihen und da keine weiteren Metadaten oder so mit abzulegen. Und diese präfixfreien Codes, die werden berechnet anhand der Wahrscheinlichkeiten der Symbole. Und das führt dazu, dass ich dann für jeden Code eine ganzzahlige Anzahl von Bits habe. Und darin liegt auch so ein bisschen die Schwäche dieses Hafmenverfahrens, denn eine ganzzahlige Bittanzahl pro Symbol ist nicht immer optimal. Entschuldigung. Also da bezahle ich so ein bisschen den Preis. Ja, 27 Jahre später, ein langer Zeitraum, wurde die arithmetische Kodierung entwickelt. Hier wird anstatt eines Symbols direkt ein String von Symbolen kodiert, und zwar in einer einzigen rationalen Zahl in diesem Zahlenintervall 01. Und ich gelange zu dieser repräsentierenden Zahl über eine Intervallschachtelung. Und diese Intervallschachtelung wird getrieben durch die Wahrscheinlichkeitsverteilung der folgenden Symbole. Was ich damit erreiche, ist jetzt eine nicht ganzzahlige Anzahl von Bits pro Symbol. Und diese arithmetische Kodierung erlaubt es tatsächlich in Grunde die optimale, die theoretisch optimale Code Länge für ein Symbol auch in der Praxis zu erreichen. Ich kann hier an dieser Stelle natürlich, oder ich kodiere an dieser Stelle nicht mehr jedes Symbol einzeln. Also es gibt keine nicht ganzzahlige Anzahl von Bits für ein Symbol in der Praxis. Aber das ist das Ergebnis, wenn ich also mehrere Symbole dann in einer gewissen Anzahl von Bits speichere. Dann kann man das dort runterbrechen auf ein Symbol und hat eine nicht ganzzahlige Anzahl. Noch mal 25 Jahre später, und da sind wir jetzt in der, ja, in der fast Gegenwart vor nur drei Jahren, hat sich jemand dann mal hingesetzt und hat sich das genauer angeschaut, was dort getrieben wird. Und hat ein neues Verfahren entwickelt mit dem leicht kryptischen Namen asymetrische, numerische Systeme. Der ganz große Vorteil dieses neuen Verfahrens liegt darin, dass es die Kompressionsstärke der arithmetischen Kodierung verknüpft mit der Geschwindigkeit und den Kosten der Hafmen Kodierung. Das hat es über, ja, 25 plus 27, also habe ich jetzt richtig gerechnet, das sind 35 Jahre, übrigens, zwischen der arithmetischen Kodierung und diesem ANS-Verfahren. Also über 60 Jahre, über 60 Jahre lang hat sich da sehr wenig getan. Und jetzt hat man dieses neue Verfahren und das kombiniert eben die Stärken der beiden bisherigen Verfahren. Und das ist eingeschlagen in der Community. Große IT-Firmen implementieren dieses Verfahren alle für sich in neuen Codecs. Dazu gehören Facebook, Apple, Google und auch die sogenannte Alliance for Open Media. Hier nochmal die Frage, sagt Alliance for Open Media jemandem was? Okay, das ist also ein Konsortium von Firmen, dass ein neues Videokompressionsverfahren entwickeln möchte und damit die teils horrenden Lizenzgebühren der anderen Kodek-Konsortien zu meiden. Und ich sagte jetzt gerade Videokodek, also hier kann ich auch betonen, dass solche verlustfreien Verfahren durchaus auch Anwendung finden in verlustbehafteten Verfahren, eben nur als ein Baustein dieser Verfahren. Gut, ich möchte kurz illustrieren, wie das funktioniert, Haffmann-Kodierung. Dazu nehme ich mir ein Beispiel-String, hier in diesem Fall ist es der String-Lossless Compression. Als Alphabet wähle ich meinen ASCII-Zeichensatz, hier sei betont der eigentliche ASCII-Zeichensatz, sieht sieben Bit für ein Symbol vor, das, was wir kennen mit 256 möglichen Zeichen, ist der erweiterte ASCII-Zeichensatz. Ich möchte jetzt an dieser Stelle mich auf den 7-Bittigen beschränken. Ich habe 20 Buchstaben, also eine Gesamtlänge dieses Beispiels, Drinks in der naiven ASCII-Darstellung von 140 Bit. So, was mache ich jetzt in dem Haffmann-Verfahren? Ich schaue zunächst, welche Symbole werden tatsächlich verwendet. Die sind in dieser Tabelle aufgeführt und sortiert nach deren Häufigkeit in dem zukodierenden String. Mittels dieses Haffmann-Verfahrens, was ich jetzt wie angekündigt nicht im Detail erläutern möchte, kann ich dann Codes erzeugen für diese Symbole. Und wir sehen, dass am häufigsten auftretende Symbol S bekommt hier den kürzesten Code und hier im konkreten Fall ist dieser Code nur zwei Bit lang, im Gegensatz zu dem ursprünglichen Code von 7-Bitt. So, jetzt hatte ich bereits gesagt, dass diese Haffmann-Codes präfixfrei sind. Man kann das sich auch mal anschauen hier in dieser Tabelle, wenn ich zwei Codes mir rausnehme und die aneinander hänge, dann kann ich die immer eindeutig dekodieren anhand dieser Tabelle. Also, kein Code ist ein präfix, also eine Untermenge eines anderen Codes, an dessen begehen. Gut, wenn ich jetzt also diese Codes wähle und einfach aneinander hänge und schaue, wie viele Bits habe ich denn jetzt hier verwendet, dann lande ich auf 63 Bit. So, bis hierhin ist das noch eine Milchmädchenrechnung. Und jetzt möchte ich Sie fragen, wer sieht das? Warum ist das noch eine Milchmädchenrechnung? Warum reicht das noch nicht aus? Gut, bitte einfach Sie vielleicht und ich wiederhole dann, was Sie gesagt haben. Genau das, das ist der Punkt. Also, ich brauche, ich muss noch in dem Datenstrom, in dem Ausgabe Datenstrom diese Korrespondenzen hinterlegen zwischen den Symbolen und den errechneten Codes. Das sind also hier für die Hofmann-Kodierung meine Modell- und Mapping-Daten. Jetzt gesprochen basierend auf dem allgemeinen Schema, was ich vorhin vorgestellt habe. Ja, was ich jetzt dann für diesen Beispiel dringend sagen kann, wir werden keine wirkliche Kompressionen erreichen, wenn wir diese Modell- und Mapping-Daten hinzurechnen. Aber was ich dort also zusätzlich hinterlegen muss, diese Symbol-Code-Tabelle, diese Tabelle stellt Fixkosten dar. Das heißt, ich muss die einmal hinterlegen zu Beginn meines Datenstroms für alles, was folgt. Diese Tabelle hat eine beschränkte kontrollierte Größe und die muss ich nur einmal ablegen. Und für längere Strings amortisieren sich diese Fixkosten sehr schnell. Ich hatte zu Beginn ja schon gesagt, dass Daten je effektiver komprimiert werden können, je größer die Datenmenge ist. Unser Beispiels dringend besteht nur aus 20 Buchstaben. Das ist sehr schwer, da irgendeine Kompression zu erreichen. Aber wir sehen die eigentlichen Nutzdaten, wie der Teilnehmer hier schon gesagt hat, kodiere ich jetzt tatsächlich schon in 63-Bit im Vergleich zu 140-Bit. Gut, ich komme jetzt zu der zweiten Kategorie. Das sind die sogenannten Wörterbuchverfahren. Darum in diesen Verfahren geht es darum, einen Wörterbuch zu erzeugen und zu pflegen im Laufe des Lesens der weiteren Daten. Hier hinterlege ich einfach in Form von Symbolen und Unterstrings das, was ich bereits gesichtet habe in dem Datenstrom. Dieses Wörterbuch wird angelegt entweder für einen kleinen Puffer, den ich also immer hinter dem aktuellen Symbol hinterherziehe oder tatsächlich für die gesamten Daten. Dieser Puffer, den ich hinter dem aktuellen Symbol hinter mir herziehe, wird auch als Sliding Window bezeichnet. Und in diesen Verfahren geht es also darum, später auftretende gleiche Strings jetzt zu kodieren mittels einer Referenz auf die bereits bekannten Daten in dem Puffer. Und diese Referenz besteht schlicht aus einer Position in diesem Wörterbuch und der Länge des gefundenen gemetschten Strings. Diese Verfahren haben den Vorteil, dass sie eine hohe bis extrem hohe, wir werden das gleich sehen, Geschwindigkeit gestatten, die Kompressionsrate ist schlechter als für die Entropie Verfahren, aber immer noch ansehnlich, immer noch brauchbar. Ja, und diese Wörterbuchverfahren eignen sich insbesondere für Daten, die Grammatik oder Regel basiert sind, also insbesondere Text. Text besteht aus in der Regel uns geläufigen Worten. Da kann man also sehr viele Matches finden und dann sehr effizient diese auch kodieren. Ja, und es gibt zwei Verfahren, im Grunde ist es ein Duo von zwei Herren, die ein Verfahren sich überlegt haben, 1977 und das leicht erweitert haben dann im Folgejahr. Das sind die beiden Herren Lempel und Ziff und die Verfahren kursieren unter den kürzenden LZ77 und LZ78. Wie funktioniert ein Wörterbuchverfahren? Hier habe ich mir viel Mühe gegeben. Ich hoffe, ich kann das ganz brauchbar darstellen. Ich wähle wieder meinen Ausgangsstring, diesen String lossless compression. Ich wähle einen Puffer, den ich also hinter dem aktuellen Zeichen hinterherziehe von 15 Buchstaben. Das heißt also, ich habe eine Länge, die ich in vier Bit kodieren kann und entsprechend ist auch der maximale Match, die Länge des, die maximale Länge des gefundenen Stringmatches dann auf 15 Buchstaben beschränkt. Gut, ich starte mit meinem Ausgangsstring. Hier ist also noch nichts in meinem Puffer gelegen. Ich kann noch nichts ausnutzen. Das kodiere ich in einer Adresse und einer Länge mit dem Wert Null. Will heißen, ich gehe nicht in meinen Puffer. Ich habe da noch nichts, was ich ausnutzen kann und kodiere jetzt zunächst das erste Trendzeichen, das ist das erste nicht weiter kodierte Zeichen und das ist in diesem Fall eben das L. Dann gehe ich weiter. Das L ist jetzt eingerahmt, das liegt jetzt in unserem Puffer. Es folgt das O, hier kann ich auch noch nichts ausnutzen. Mein Puffer ist noch sehr übersichtlich. Sprich, ich kodiere es wieder mit zwei Nullen und dem, das Trendsymbol muss ich explizit dann ablegen, das O. Das geht so weiter. In der vierten Stufe habe ich dann tatsächlich meinen ersten Match. Ich habe also das erste S gelesen, das liegt in meinem Sliding Window drin und ich kann jetzt das zweite folgende S kodieren, indem ich eine Referenz erzeuge auf das zuerst gelesen S. Das heißt also, ich gehe einen Schritt zurück in meinen Sliding Window, entspricht einer Adresse mit dem Wert 1 und die Länge des gefundenen Matches ist jetzt hier eben auch nur eins. Und dann habe ich also dieses zweite S kodiert und muss nur wieder das nächste, mir noch unbekannte Zeichen kodieren. Das ist dann das L. Ich überspringe ein paar Stufen. Das kann wer mag sich dann mal im Detail anschauen. Wir sehen aber schon im weiteren Verlauf, dass durchaus auch größere Matches dort auftreten. Hier in diesem Beispiel ist das jetzt noch beschränkt. Aber ich habe tatsächlich auch schon in diesem sehr kurzen Beispiels dringend einen Match, der aus drei Buchstaben besteht. Das ist dann dieses E und das Doppel S. Und in der letzten Stufe passiert dann etwas Wesentliches. Und zwar, wenn ich so circa das Ende dieses Beispiels dringens erreicht habe, dann passiert es erstmals, dass mich mein Sliding Window, mein Puffer limitiert. Bisher in den vorigen Stufen war es so, dass das alles, was ich vorher gelesen habe, in mein Wörterbuch in meinen Puffer aufgenommen werden konnte, weil der Puffer groß genug ist. An dieser Stelle jetzt ist das nicht mehr möglich. Der Puffer ist, wie wir festgelegt haben, auf 15 Zeichen beschränkt und ich verliere somit die ersten drei Buchstaben. Jetzt passiert hier noch etwas Besonderes. Ich habe also als nächsten Match den Buchstaben O. In dem, was ich vorher schon gelesen habe, treten zwei O auf. Das erste O kann ich oder verwende ich nicht für meine Referenz aus zwei Gründen. Erstens mal sehe ich dieses erste O nicht mehr. Es liegt nicht mehr in meinem Puffer drin. Es hat aber noch einen zweiten wesentlichen Grund, warum ich das auch nicht wählen würde, wenn es mir noch bekannt wäre. Denn wenn ich Daten komprimieren möchte, dann ist es immer empfehlenswert, kleine Zahlen zu wählen, kleine Codes, kleine Zahlen. Insofern suche ich mir zunächst den String mit der maximalen Größe. Das ist jetzt an dieser Stelle nur dieser einzelne Buchstabe. Wenn ich das gefunden habe, dann wähle ich den Match dieser Größe, das am nächsten Gelegen ist, weil der es erlaubt, die Adresse und die Länge mit kleinen Zahlen zu codieren. Gut, so, und dann habe ich, wenn ich als letztes den Buchstaben encodiert habe, dann tatsächlich meinen gesamten Beispielstring codiert. Mancher einer mag es schon erinnern, was hier passiert. Ich habe also jetzt eine recht reichhaltig gefüllte Tabelle mit Daten für meine Modellierungs- und meine Mappingstufe. Und wenn ich das einfach mal aufsummiere, dann lande ich auf 180 Bit. Es ist jetzt schade, mein Ausgangstring hatte nur 140. Hier ist also einfach die Menge der Daten, die ich komprimieren will, einfach zu klein, um effektiv zu komprimieren. Aber ich kann etwas tun an dieser Stelle. Ich frage mal ins Auditorium, hat jemand von Ihnen eine Idee, was ich jetzt noch tun kann, zusätzlich zu dem dargestellten? Denken Sie mal an das, was ich bereits erzählt habe. Ja, Sie bitte. Sie beziehen sich jetzt auf ein anderes Verfahren, richtig? Darum soll es jetzt an dieser Stelle nicht gehen. Es gibt natürlich noch bessere Verfahren, auch als jetzt 77. Das ist also an dieser Stelle nicht wesentlich. Ja, Sie bitte. Richtig, genau. Also der Teilnehmer sagte, man kann es jetzt verknüpfen mit den Verfahren, die ich bereits dargestellt habe, nämlich den Entropie-Verfahren. Und genau das ist hier sehr nützlich. Schauen wir nochmal in die Tabelle rein. Wir haben auf einmal durchaus Redundanz in dieser Tabelle. Ich habe recht viele Vorkommen des Wertes Null. Und die Werte, die ich in dieser Tabelle drinstehen habe, die sind alle kleiner als 15. Eine Folge meiner Wahl der Größe des Sliding-Windows. Und das kann ich ausnutzen, indem ich dann diese Tabelle wiederum entropiekodiere. Und wenn man das macht, in einer Kombination von LZ 77 und in diesem Beispiel der Entropie-Verfahren der Hafmen-Kodierung, Entschuldigung, dann lande ich in der Summe auf einmal bei 120 Bit für die Nutzdaten und noch Fixkosten. In der Summe wird das auch hier mehr werden als der naive ASCII-Daten-Strom. Aber wie ich schon sagte, die Fixkosten amortisieren sich sehr zügig für größere Strings. Also hier kodiere ich meine Nutzdaten, mein eigentlichen String in 120 Bit anstatt 140. Gut, das ist die schon erwähnte Referenzfolie. Ich habe mal ein paar weitere Verfahren zusammengetragen zur verlustfreien Datenkompression. Ich will hier nicht mehr auf die einzelnen Verfahren eingehen. Wer mag, kann sich das dann mal anschauen. Ich werde die Vortragsfolien zur Verfügung stellen anschließend. Ich möchte nur kurz auf die beiden letzten Verfahren eingehen. Die Burrows-Whealot-Transformation, die 1994 entwickelt wurde, ist ein sehr interessantes Beispiel. Diese Transformation nimmt zunächst keinerlei verlustfreie Datenkompressionen vor. Aber man kann mit Hilfe dieses Verfahrens die Daten zunächst transformieren in eine neue Darstellung, die ich dann wesentlich effizienter kodieren kann. Es ist also insofern ein Verfahren zur Vorverarbeitung, dass es mir gestattet, im Anschluss wesentlich effizienter zu kodieren. Es ist eine sehr interessante Transformation, auch recht einfach, und ich möchte sie genial nennen. Diese Transformation haben die meisten von Ihnen sicher auch schon mal verwendet, und zwar in Form des recht bekannten Packers BSIB II. Gut, und zuletzt sei ein Satz gesagt zu dieser PAQ-Familie, die nicht wirklich bekannt ist. Aber wenn der Fokus auf der Kompressionsrate liegt, also auf der Stärke der Kompression, dann kommt man an derzeit an PAQ nicht vorbei. Ich habe sie The Bosses in Town genannt. Diese Verfahren sind sehr, sehr langsam. Also die können sich an ein paar wenigen Megabyte durchaus mal eine halbe Stunde abarbeiten. Aber was da an Kompressionsrate rauskommt, ist derzeit eigentlich nicht zu überbieten. Gut, ich komme zu den Methoden. Die Lämpel-ZIF-Verfahren verdienen eine weitere Folie, denn diese Lämpel-ZIF-Familie hat einen Strauß von Verfahren her vorgebracht, die hier etwas in einer Hierarchie abgebildet sind. Man sieht als Ausgangspunkt diese beiden Verfahren LZ 77 und LZ 78. Die meisten heutzutage verwendeten Verfahren entstanden diesem Unterbaum LZ 77. Hat Patentgründe dieser LZ 78 Unterbaum, ist von einer Firma leider durchpatentiert worden. Das hat für Verzweiflung gesorgt bei einigen Algorithmen-Entwicklern. Und man hat sich irgendwann dort weitestgehend zurückgezogen aus diesen Algorithmen-Familie. Und die heute üblichen Verfahren sind LZ 77 die Rivate. Und ich habe hier jetzt vier Verfahren mal hervorgehoben. Und ich möchte jetzt Sie mal in die Menge fragen, hat jemand von Ihnen eine Assoziation mit mindestens einen dieser rot markierten Verfahren? Ja, bitte hier vorne rechts. Ja, gut, vielleicht noch Ihr Kollege. Das ist nicht richtig, aber die Richtung ist jetzt richtig. Ja, es geht jetzt an dieser Stelle um das Verfahren Deflate. Deflate kennt jeder von Ihnen, zumindest seitens der Nutzung. Und zwar ist Deflate der Kernbestandteil hinter SIP. Ich möchte betonen, Deflate wurde Anfang der 90er Jahre entwickelt, 1993. Es ist jetzt 24 Jahre später und wir packen immer noch das Allermeiste mit diesem Verfahren. LZMA, wie der Kollege hier gerade erwähnte, hat man schon mal gehört. Ja, viele verwenden vielleicht das Programm 7-SIP. Und dieses LZMA Verfahren wurde entwickelt für diese Software. Gut, jetzt habe ich einige Recherche betrieben und mal geschaut, wie diese Verfahren verwendet werden in verschiedenen Kompressionsformaten. LZSS, was hier auch mit rot markiert war, dieses erste, findet immer noch Verwendung und ist ein Hauptbestandteil des Kompressionsformates RA. Und wer in etwa meines Alters ist, erinnert sich auch noch an den Packer LHA. In Japan verwendet man den heute immer noch sehr rege. Es hat damit zu tun, dass LHA von einem Japaner entwickelt wurde. Aber es wird deutlich weniger in Europa verwendet, also deutlich weniger als RA und SIP. Ja, deflate gilt als die Königin der Kompressionsverfahren. Bisher ist der Hauptzutat hinter SIP und wird insofern extrem häufig verwendet. Des weitere Verfahren LZX ist schon dann etwas später entwickelt worden. Das findet Verwendung in dem sogenannten Cabinet-Format. Haben sicher die meisten von Ihnen auch schon gesehen. Wenn man also irgendwie ein Installationspaket von Microsoft hat, dann liegen die allermeisten Daten in Dateien mit der Endung CAP. Das sind diese Cabinet-Archive. Ja, und wie gerade schon erwähnt, LZMA wurde für 7-SIP verwendet. Dann gibt es noch ein paar weitere recht bekannte Verwendungen von LZ-Dirivaten in Anwendungen und Formaten von Microsoft. Es gibt zum Beispiel diese CHM-Dateien. Sind Hilfe-Dateien, die auch eine Suchfunktion und ein Index mitbringen. Man kann Bilder einbetten, man kann Code einbetten. Viele von Ihnen haben mit diesen Dateien schon gearbeitet. Und das kleine C in dieser Extension steht ursprünglich für Compiled, wird aber auch häufig für Compressed verwendet. Denn diese Dateien sind in der Tat Archive und verwenden dieses LZX-Verfahren. Windows Imaging mit WIM-Dateien haben vielleicht noch nicht so viele von Ihnen gearbeitet. Die verwenden dieses Verfahren ebenfalls. Dann habe ich in den Tiefen der MSDN-Dokumentation gewühlt und habe herausgefunden, dass das NTFS-Datei-System ein nicht wirklich bekanntes Verfahren mit dem Namen LZNT1 verwendet. Das wiederum ist eine Variante auch dieses LZSS-Verfahrens. Also NTFS gestartet auch eine selektive optionale Dateikompression. Etwas, womit wir deutlich mehr zu tun haben, meistens nicht freiwillig ist dieser Windows Update Mechanismus und Gott sei Dank gehen da die Updates aber zumindest komprimiert über den Kanal. Man möchte sich gar nicht ausmalen, was dafür Datenmengen zusammenkommen, wenn die nicht komprimiert würden. Dieses Verfahren Deflate hat eine eigene Folie bekommen. Deflate ist, wie schon gesagt, der Kernbestandteil hinter SIP, findet aber noch in unzähligen weiteren Formaten prominente Verwendungen. Zum Beispiel PDF verwendet dieses Verfahren. OpenOffice verwendet dieses Verfahren. OpenOffice-Documents haben die Extension-ODF. Und wenn Sie sich das mal anschauen wollen, benennen Sie eine ODF-Datei, einfach mal Spaßeshalber in eine SIP-Datei um. Und Sie werden merken, Sie können diese Datei öffnen. ODF-Dateien sind nichts anderes als unbenanntes SIP-Dateien, in denen wiederum XML-Dateien liegen, die dann den Inhalt und die Formatierung separat beinhalten. Wav steht für WebOpenFontFormat. Damit werden also Font-Dateien für die Internetnutzung gespeichert. Ja, dieses Deflate-Verfahren hat den Vorteil, dass es eine doch sehr ansehnliche Kompressionsrate erzielt, und zwar auf den verschiedensten Datentypen. Und Deflate ist nichts anderes als eine Kombination, von dem jetzt schon mehrfach erwähnten LZ-LSS-Verfahren und der Huffman-Codierung. Ja, und wenn man über Deflate spricht, dann kann man im Grunde gleichwertig über Setlib sprechen. Setlib ist eine Routine-Bibliothek, die im Grunde die nötigen Routinen für Deflate implementiert. Also wenn immer man mit Deflate in der Praxis handiert, dann programmiert man in der Regel diese Setlib-Bibliothek. Ich komme jetzt zu den neueren Methoden, die allesamt sind vier an der Zahl, die ich mir rausgepickt habe, für sie in den letzten sechs Jahren entstanden sind. Ich möchte noch mal betonen, Huffman-Codierung wurde 1952 entwickelt. Die arithmetische Codierung 1979, also 27 Jahre später, dann ist 35 Jahre lang nichts passiert, und dann kamen die Asymetric Numerical Systems. Eine enorme Zeitspanne, wenn man sich das mal im IT-Ramen vorstellt. Und jetzt in den letzten sechs Jahren sind alleine vier neue Verfahren entstanden. Und das ist etwas, wo ich in meinem Vortrag, dass ich in meinem Vortrag besonders betonen möchte. In den letzten Jahren ist in diesem Bereich Forschungstechnisch und Implementierungstechnisch sehr viel geschehen. Und ein zentraler Treiber dahinter war eben dieses ANS Entropie-Verfahren. Aber zunächst zu diesem ersten neueren Verfahren LZ4. Es ist ein recht schlichter Algorithmus, der im Wesentlichen LZ77 darstellt, der sich auf eine Byte-Codierung festlegt, im Gegensatz zu einer bitweise getriebenen Komprimierung. Das hat einfach den Grund, dass Beiz deutlich fixer zu handhaben sind. Also wenn ich Beiz runterbreche und mir einzelne bits da rausholen, dann kann die Geschwindigkeit sehr schnell um 30 % einbrechen. Also es ist ein pragmatischer und Geschwindigkeitsgrund, warum LZ4 sich auf Beidgrenzen berücksichtigt. LZ4 beinhaltet keine Entropie-Codierung. Es ist also ein reines Wörterbuchverfahren. Aber es erlaubt demzufolge eine sehr schnelle Kompression und eine extrem schnelle De-Kompression. Was das genau in Zahlen ausgedrückt heißt, werden wir jetzt gleich sehen. Die Kompressionsrate ist als Folge davon schlechter als bei Deflate, aber für vieler Anwendung ausreichend. Als nächstes kommt die sogenannte Schweizer Serie von Google auf den Bildschirm. Google hat in den letzten fünf Jahren drei verschiedene Kompressionsverfahren entwickelt. Allesamt wurden entwickelt von Mitarbeitern des Engineering-Zentrums in Zürich. Und die haben demzufolge allesamt Schweizer Namen bekommen. Da geht es jetzt in den Nerd-Faktor rein. Wenn ich ein Verfahren entwickle, dann nenne ich das eigentlich, würde ich das nicht Gipfelie nennen, aber sei es drum, das sind alles Schweizer Ausdrücke für Backwaren. Gipfelie, Zopflie und Broodlie. Man könnte meinen, das sind alles so Verfahren, die irgendwie in ihrer Nische leben und dort Verwendung finden. Ich will nur sagen, man täuscht sich da. Ich will hier mich beschränken auf das Broodlie-Verfahren, das jüngste dieser drei. Broodlie ist eine moderne Variante von LZ77, kombiniert mit Huffman-Kodierung und einer komplexerer Methode, nämlich der Second-Order-Context-Modellierung. Die sei jetzt an dieser Stelle mal nicht weiter erläutert. Zusätzlich erzielt Broodlie eine Kompression dadurch, dass es onboard schon ein vorgefülltes Wörterbuch mitbringt, mit der Größe 120 Kilobyte. Darin hinterlegt sind sehr häufig auftretende Strings, wie man sie in HTML und Javascript braucht. Es hat damit zu tun, dass Broodlie darauf ausgelegt ist, Webseiten und Javascript zu komprimieren, weil das eben die Datentypen sind, die über die Internetleitung gehen. Broodlie gestartet damit eine um fast 25 % bessere Kompressionsrate und ist jetzt im Moment im Spezifikationsstadium als HTTP-Kompressionsschema. Broodlie hat jeder von ihnen auf dem Rechner, die meisten wahrscheinlich ohne es zu wissen. Broodlie ist in allen modernen oder in allen jüngeren Versionen von Web-Brosern implementiert, inzwischen sogar Apple-Safari. Das will das heißen. Das hat einfach damit zu tun, dass diese Browser allesamt in die Lage versetzt werden sollen, jetzt sehr kurzfristig diese komprimierten Datenströme zu handeln. Und damit wird einfach der Internet-Traffic dann schon deutlich entlastet. Ein drittes Verfahren, Z-Standard ist, ich nenne es mal die neue Königin, ist ein Verfahren, was von Facebook entwickelt wurde, genauer von jemandem, der jetzt für Facebook arbeitet, ist eine Kombination von LZ 77 der Huffman-Kodierung und dieser besagten ANS-Kodierung. Diese Verfahren Huffman und ANS sind beide implementiert, und zwar in extrem effizientem Code in diesen beiden Codecs. Ich habe diesen Vortrag sehr dicht geteckt mit Internet-Adressen, wer also da an Details interessiert ist, kann sich durch den Vortrag klicken und auf diese farblich hinterlegten Bezeichner klicken und landet dann an den Quellen. Z-Standard ist designt für Geschwindigkeit und Parallelausführung und hat ein paar weitere Vorteile, ein zentraler Vorteil ist, dass Z-Standard es erlaubt, trainiert zu werden für spezifische Datentypen. Ich kann nämlich Z-Standard dazu bringen, für einen spezifischen Datentyp, an dem ich primär interessiert bin, selber ein Wörterbuch zu erzeugen. Und dieses Wörterbuch kann ich dann für alle weiteren Dateien, die diesen Typ haben, verwenden und damit dann eine bessere Kompressionsrate erzielen. Z-Standard erlaubt es sozusagen, angelernt zu werden für spezifische Datentypen. Gut, ich habe ein paar Performance-Daten zusammengetragen, das möchte ich jetzt relativ zügig durchgehen. Ich habe im ersten Plot verglichen das Verfahren Broodly mit dem bisherigen Standard Deflate. Und wenn man sich das zweite und das dritte Set von Balken mal anschaut, wenn ich dafür sorge, dass Broodly in etwa die Kompressionsrate von Deflate reproduziert, hier mit dem Faktor 3,381, heißt, es erzeugt für den gewählten Testdatensatz eine Datei, die um Faktor 3,381 kleiner ist. Wenn ich das also synchronisiere mit Deflate, dann sehe ich, Broodly ist um den Faktor 6 grob schneller als Deflate für diesen gewählten Datensatz. So, das waren die Kompressionsrate und die Kompressionsgeschwindigkeit. Hier sind jetzt die Dekompressionsgeschwindigkeiten nochmal aufgetragen und wir sehen, diese LZ-Verfahren Broodly und Deflate tummeln sich alle in der Dekompremierung bei so circa 340 Megabyte in der Sekunde. Da geht es also um Daten, die im Rahmen hinterlegt sind. So, dann habe ich die vier großen aktuellen Verfahren oder aktuell wesentlichen Verfahren noch miteinander verglichen. Set Standard, Deflate, Broodly und LZ4. Ich mag darauf nicht gesondert eingehen oder detailliert eingehen, nur sei betont LZ4 erlaubt es also mit 720 Megabyte in der Sekunde zu komprimieren. Eine riesige Geschwindigkeit und wie wir sehen, lässt es die anderen Verfahren weit hinter sich zu Kosten der Kompressionsrate, die hier natürlich auch signifikant schlechter ist, aber immerhin noch für viele Anwendungen durchaus brauchbar. Ja, und nicht zuletzt in Punkto D Kompressionsgeschwindigkeit ist LZ4 kaum zu toppen. Es dekomprimiert mit fast dreieinhalb Gigabyte in der Sekunde im Arbeitsspeicher. Das ist die Größenordnung, die eine reine Datenverschiebung innerhalb des Rams darstellt. Also die Daten, die fliegen durch den Algorithmus im Grunde durch, so effizient ist dieses Verfahren. Gut, und zuletzt möchte ich eingehen, sehr kurz noch auf ein weiteres aktuelles Verfahren. Ich habe mich also für diesen Vortrag heran recherchiert an wirklich das Ofenfrischezeug, ein Codec mit dem Namen Malin, der einen fantastischen Kompromiss findet zwischen Geschwindigkeit und Kompressionsrate. Der ist hier federführend auch am KIT entwickelt worden und erst im April 2017 vorgestellt worden auf der wichtigsten Konferenz in diesem Themengebiet der Data Compression Conference. Und man hat dieses Verfahren, ein General Purpose Verfahren ist es, mal angewendet auf eine Domäne, für die es eigentlich nicht speziell entwickelt wurde, nämlich verlustfreier Kompression von Bildern. Und was man sieht, als Vergleichsbasis dient dieser Codec JPEG LS. Vielleicht haben manche von Ihnen auch noch nicht gewusst, dass JPEG tatsächlich auch ein Algorithmus zur verlustfreien Kompression mitbringt. Und dieser Codec dient so als Vergleichsbasis, wenn immer man Bilderverlust los komprimieren möchte. Und was wir sehen ist, malien, obwohl nicht speziell dafür entwickelt für diese Domäne, gestattet eine Kompressionsrate, die doch sehr nah heran reicht an JPEG LS, aber um Faktor 80 schneller ist als JPEG LS. Also immerhin noch mit ca. 2,5 Gigabyte geht es da zur Sache. Das ist der erste, malien gilt als der erste Hochgeschwindigkeitscodec, der tatsächlich auch schwach strukturierte Daten einer nicht speziellen Domäne komprimieren kann, also einen General Purpose Codec darstellt. Und General Purpose Kompression geht in der Regel mit guter Kompressionsrate eigentlich nur mit Moderatergeschwindigkeit, der hier erlaubt ist mit Hochgeschwindigkeit. Gut, ich komme zu den Anwendungen. Ja, hier muss ich jetzt leider etwas auf die Tube drücken. Der moderne Scope verlustfreie Datenkompression hat die folgenden Anwendungen. Es geht um die Reduktion des Datentreffigs, das habe ich schon etwas näher beleuchtet, die für den Kunden wesentliche Reduktion der Übertragungskosten, insbesondere wenn man da an Kontingente mit mobilen Geräten denkt, es erweitert oder verlängert gleichzeitig auch noch die Lebenslauer der Batterie von mobilen Geräten. Denn Datenhändling geht immer zulasten der Batterie, also zu einem großen Maß. Gleichzeitig werden auch neuere Anwendungen beschleunigt. Ich denke da nicht nur an Webseiten und Daten von Apps, die man auf seinem Smartphone hat, sondern auch an Streamed Games. Im Spielesektor ist das heutzutage schon fast üblich, dass Spiele gestreamt werden von Servern ihrer Hersteller. Und eine neuere Anwendung sind auch die 3D-Geometri-Daten. Ich denke da zum Beispiel an Kinect von Microsoft, an das neue Creators Update für Windows 10. Das zum Beispiel dieses neue Paint 3D mitbringt, ein Bildbearbeitungsprogramm, das es gestattet 3D-Modelle zu bearbeiten, zu erzeugen. Und 3D-Geometri-Daten werden sehr schnell recht groß in der Datenmenge. Und auch hierfür hat Google kürzlich ein Codec entwickelt. Das ist der Draco-Kodec für 3D-Geometri-Daten. Und auch dieser Codec verwendet dieses ANS-Verfahren. Nicht zuletzt gestattet Verlustfreie Datenkompression, auch die Reduktion der Kosten von Cloud-Infrastruktur. Und was wir jetzt, was allen diesen Punkten in dieser Liste gemein ist, es sind wirklich businessrelevante Kriterien, businessrelevante Faktoren. Es geht also bei Verlustfreie Datenkompression nicht zuletzt um Zeit und Geld. Ja, hier habe ich noch weitere Applikationwendungen zusammengetragen. Man kann sehen, das reicht von Datei-System wie OpenZFS. In der letztjährigen Gulasch-Programmiernacht, wie auch in der diesjährigen, gab es auch Vortrage zu diesem Datei-System. Und das geht hin bis zu Verarbeitungspipelines bei Facebook und der englischen Zeitung The Guardian. Und geht weiter bis zu Dropbox. Und all diese doch recht großen Firmen und recht großen Applikationen wählen aus diesem kleinen Fundus von diesen jüngeren Kompressionsverfahren. Ja, dann gibt es noch spezielle Applikationen, die diesen Baustein des Past to Present Mappings, wie ich Ihnen in dem allgemeinen Schema für Kompressionsverfahren dargestellt habe, ausnutzen und diese speziellen Applikationen reichen von Molekularbiologie. Hier geht es also um Faltungsanalyse von Proteinen. Proteine-Familien mit einer vorgegebenen Faltung haben verschiedene funktionale Eigenschaften. Hier geht es also um Proteinanalyse. Und man kann tatsächlich hier diese Match-and-Reuse unter Routinen von Kompressionsverfahren tatsächlich gewinnbringend ausnutzen. Ein zweiter Applikation, auf die ich noch kurz eingehen möchte, der Rest sei Ihnen zur Nachlese empfohlen, ist dieser zweite Punkt Smartphone Typing Assistance. Wenn Sie auf Ihrem Smartphone eine SMS tippen, dann haben wahrscheinlich die meisten von Ihnen eine App zur Assistenz, die Ihnen das nächste Wort vorschlägt. Basierend auf dem, was Ihr Smartphone schon aus Ihrem ehemaligen SMS über Ihre Wortwahl, über Ihren Satzbau, über Ihre Grammatik gelernt hat, und an dieser Stelle bei diesen Assistenz-Apps kommen tatsächlich dieselben Verfahren zum Tragen, die mir gewährleisten, dass ich ein gutes Wörterbuch zur Verfügung habe für die Verlustfreie Datenkompression oder ein gutes Wahrscheinlichkeitsmodell für Entropie-Verfahren. Gut, ich möchte mich hier beschränken auf diesen zweiten Teil Future, bildet meine eigene Einschätzung ab, was denn da in der näheren Zukunft wohlkommen mag. Ich bin überzeugt davon, dass Kompression weitaus natürlicher und transparenter eingebettet wird in die Anwendungen. Heutzutage öffnet man häufig noch eine Applikation wie 7SIP und komprimiert seine Dateien. Ich denke, das wird sich mit und mit in den Hintergrund bewegen und dort als ganz natürliche Informationsverarbeitung stattfinden. Genauso spannend finde ich, oder schätze ich ein, die Synergie mit Verfahren zum Maschinen lernen. Maschinen lernen ist nach wie vor ein Hype-Thema. Hier passiert unheimlich viel, viele von Ihnen verfolgen das sicher auch. Und ich denke, Kompression wird hier auch von dem sehr abstrakten Modell wissen, was diese Verfahren zum Maschinen lernen generieren, durchaus nutzen ziehen können. Aber diese Brücke herzustellen, das wirklich miteinander zu verheiraten und dort für Synergie, dort Synergie zu erzielen, das ist halt noch nicht gemacht. Aber ich denke, das wird in den nächsten Jahren kommen. Und im Gegenzug denke ich, das große neuronale Netze, ein großes Hype-Thema in diesem Bereich Maschinen lernen, auch möglicherweise effizienter trainiert werden können in Zukunft, indem sie nur noch mit wesentlichen Daten gefüttert werden. Heutzutage steckt man da eben alles an Daten rein, was man hat und das neuronale Netze wird sicher das Richtige tun. Aber das ist alles noch sehr rechenaufwendig. Und ich denke, man kann das ein bisschen konsolidieren, wenn man dort nur noch, und sei es jetzt nur grob gesprochen, wesentliche Daten reinfüttert. Ja, ich komme zum Abschluss meines Vortrags. Es tut mir leid, ich habe etwas überzogen. Es geht bei verlustfreier Datenkompressionen um etwas sehr Wesentliches in Zeiten, wo die Datenmenge nach wie vor exponentiell steigt. Die Bandbreiten für Netzkommunikation, aber auch innerhalb eines PCs, bleiben die Flaschenhälse und solange das Tatbestand ist, wird verlustfreie Datenkompressionen auch wesentlich bleiben. Jetzt habe ich schon ausreichend oder recht breit dargestellt, dieses Thema bekommt neue Aufmerksamkeit und neue Forschungsanstrengungen seitens von wirklich großen IT Firmen, Google, Facebook, Microsoft auch, Dropbox, wie sie nicht alle heißen, Apple. Und ich denke, dass dieses Thema auch neue Bedeutung, spannende Bedeutung beginnen wird in diesen Folgejahren von Getrieben, von Maschinen lernen und diesem neuen Thema IoT, diesen verbundenen Geräten im Internet of Things. Ja, hier sind noch ein paar Quellen, die Sie sich anschauen können, wenn Sie sich für das Thema interessieren, wenn Sie sich für das Thema interessieren wollen, seien auch hier die verlinkten Videolectors. Google hat sogar eine eigene, kleine und lustig gehaltene Videoserie zur Datenkompression ins Läden gerufen, Compressorhead heißt die. Ja, und damit beende ich meinen Vortrag. Schönen Dank für Ihre Aufmerksamkeit. Wenn jetzt doch noch Fragen sind oder auch Einzelkonversationen gewünscht sind, noch jemand eine Frage. Ja, also die Frage bezog sich auf Verfahren, die Fraktale verwenden. Also viele von Ihnen haben sicher schon mal Fraktale gesehen. Ein bekanntes ist das Apfelmännchen. Man kann tatsächlich Fraktale zur Datenkompression nutzen. Das ist, um Ihre Frage zu beantworten, mehr im Bereich der Verlustfreien Kompression, tatsächlich auch angesiedelt. Aber dieser Typ von Verfahren ist im Grunde wieder eingeschlafen. Also man hat da nicht so die Kompressionsrate mit erzielen können und diese Verfahren sind auch relativ teuer. Ja, zweite Frage. Sehr gerne, aber dann bitte im Einzelgespräch. Das ist ein bisschen schwierig zu erläutern. Weitere Fragen. Ja, bitte. Sehr gute Frage. Die Frage war, wie schneidet dieser neue Codec Malin für stark strukturierte Daten ab, wie beispielsweise HTML? Kurze Antwort, ich weiß es nicht. Ich habe damit noch nicht experimentiert. Das sind wirklich Daten, die ich noch aus dem Fundus gefischt habe und aufbereitet habe für den Vortrag. Ich habe mir diesen Codec noch nicht näher angeschaut. Er ist aber auch erst im letzten Monat, wie wir sehen können, vorgestellt worden. Hier werden jetzt in den nächsten Monaten sicher noch viele weitere Evaluationen folgen. Ich schreibe Ihnen gerne eine E-Mail, wenn ich darüber sichte. Ja, richtig. Also die Anmerkung war, oder die Frage und Anmerkung war, wie ich die Bedeutung einschätze von verlustbehafteten Verfahren im Vergleich mit diesen verlustfreien Verfahren, über die ich berichtet habe, verfahren in diesem oder verlustbehaftete Verfahren, wie sie für Videokompression beispielsweise eingesetzt werden, H264 oder H265, komprimieren natürlich den Löwenanteil der Daten, die übers Netz gehen. Also vieles davon oder der große Anteil von Daten übers Internet sind Videoströme und Bildströme. Ja, das ist richtig. Es gibt eine Besonderheit, die mit ein Grund ist, warum ich mich an dieser Stelle auf verlustfreie Verfahren beschränkt habe. Und die besteht darin in verlustbehafteten Verfahren. Gibt es eigentlich immer eine Kodierungsstufe, die verlustfrei ist. Und die basiert auf diesen Verfahren, wie ich es dargestellt habe. Andersrum ist das nicht der Fall. Also ich kann natürlich in einem verlustfreien Kodeck nichts verwenden, was mit einem Verlust einhergeht. Also insofern sind diese verlustfreien Verfahren sehr signifikant und finden auch Anwendungen in verlustbehafteten Verfahren. Und verlustbehaftete Verfahren, wie eingangs erwähnt, involvieren noch Techniken, die den Rahmen gesprengt hätten jetzt für diese Veranstaltung. Gleich noch eine Abschlussfrage. Dann haben wir doch noch so eine leichte Q&A gehabt, die so ein bisschen mein Überziehen kompensiert. Vielen Dank. Ich versuche es zu wiederholen, wie ich das verstanden habe. Die Frage war, ob es Arbeiten gibt zur Kombination von verlustbehafteten Verfahren und drahtlosen Übertragungstechniken. Dazu kann ich nicht in Detail etwas sagen, aber vielleicht ein Aspekt kurz ansprechen, der bei verlustbehafteten Verfahren eine wesentliche Rolle spielt. Das ist die Theorie der Rate Distortion. Da geht es darum, die Datenrate, mit der ich kodiere, adaptiv zu wählen, basierend auf den Übertragungsumständen, die ich vorfinde. Da könnte ich mir vorstellen, gibt es Arbeiten, die also darlegen, wie die Datenrate möglichst effizient, möglichst mit wenig Verlustbehaftung gewählt werden kann, wenn die Übertragungsumstände schlecht sind. Also, wenn die Übertragungsqualität einbricht. Wenn keine weiteren Fragen sind, dann danke ich Ihnen, dass Sie so zahlreich erschienen sind. Ich bin für jeglichen Austausch gerne bereit. Danke.