Verlustbehaftet vs. verlustfrei: Warum Bildformate absichtlich vergessen

Nimm dasselbe 12-MP-Foto (4000 x 3000 Pixel) und speichere es zweimal. Einmal als PNG: 24 MB. Einmal als JPEG in Qualität 90: 3,4 MB. Leg beide Versionen nebeneinander auf den Bildschirm: Du wirst keinen Unterschied sehen. Erst bei 400%-Zoom zeigen sie sich: eine leichte Weichzeichnung in Haaren und Gras, schwache Höfe entlang der schärfsten Kanten.

Zwei Dateien, ein Bild, ein Größenfaktor von 7. Keine der beiden Dateien ist kaputt. Sie machen nur unterschiedliche Versprechen. PNG verspricht, jedes Bit zu bewahren. JPEG verspricht, alles zu behalten, was dir auffallen würde. Fast alles, was es über Bildformate zu wissen gibt, folgt daraus, für welches dieser beiden Versprechen sich ein Format entscheidet.

Warum sich die Komprimierung in zwei Lager spaltete

1948 veröffentlichte Claude Shannon "A Mathematical Theory of Communication" und gab der Komprimierung eine harte Untergrenze. Sein Quellenkodierungstheorem besagt, dass sich Daten verlustfrei nicht unter ihre Entropie darstellen lassen, den durchschnittlichen Informationsgehalt pro Symbol. Ein rein zufälliges Bild komprimiert überhaupt nicht. Ein einfarbig weißes komprimiert auf fast nichts. Jedes echte Bild liegt irgendwo auf dieser Skala, und kein verlustfreier Algorithmus kann diese Grenze unterbieten.

Verlustbehaftete Komprimierung nutzt eine Lücke in dieser Logik. Die Entropie-Untergrenze gilt für die Daten, die du hast, nicht für die Daten, die du behältst. Ersetzt du das Bild zuerst durch eine leicht veränderte Version mit niedrigerer Entropie, sinkt die Untergrenze gleich mit. Das ist der ganze Trick: Erst die Daten ändern, dann packen. Die technische Frage ist nur, welche Änderungen akzeptabel sind.

Die Antwort hängt von zwei Dingen ab: dem Inhalt und dem Empfänger. Ein Screenshot eines Einstellungsdialogs besteht größtenteils aus einheitlichen Farbflächen und wiederholten Formen: niedrige Entropie, leicht vorhersagbar. Ein Waldfoto dagegen ist auf Pixelebene eine Mischung aus Photonenrauschen und Sensorausleserauschen: hohe Entropie, kaum vorhersagbar. Und beim Empfänger macht es einen Unterschied, ob ein Programm die Datei liest, das exakte Bits braucht, oder ein Mensch, der eine eingebaute Fehlertoleranz mitbringt: begrenzte räumliche Farbauflösung, geringe Empfindlichkeit für feine hochfrequente Texturen und eine Helligkeitswahrnehmung, die Verhältnissen statt Absolutwerten folgt (Webersches Gesetz, grob 1 bis 2% Luminanzschritte).

Also spalteten sich die Formate. Ist der Inhalt vorhersagbar und der Empfänger eine Maschine oder ein Mensch, der jedes Pixel prüft, ist verlustfrei die richtige Wahl. Ist der Inhalt verrauscht und der Betrachter ein Mensch in normalem Abstand, darfst du getrost vergessen.

Wie verlustbehaftete Komprimierung funktioniert

Über verlustbehaftete Codecs heißt es oft, sie würden "Daten wegwerfen". Stimmt, ist aber ungenau: Sie werfen gezielt bestimmte Daten weg, ausgewählt nach einem Modell des menschlichen Sehens. Die Pipeline:

1. RGB in einen Luma-Chroma-Farbraum umrechnen (YCbCr bei JPEG, ähnliche Aufteilungen bei anderen). Dein Auge löst Helligkeitsdetails deutlich besser auf als Farbdetails, also dürfen die Chromakanäle mit einem Viertel der Auflösung gespeichert werden (4:2:0-Subsampling). Allein dieser Schritt halbiert die Rohdaten grob, ohne dass es in den meisten Fotos auffällt.

2. Jeden Block in Frequenzen zerlegen. JPEG nutzt die diskrete Kosinustransformation auf 8 x 8-Blöcken, JPEG 2000 Wavelets, AV1 und HEVC größere Transformationen mit variabler Blockgröße. Das Ergebnis sieht immer gleich aus: wenige große Koeffizienten für die groben Formen, viele kleine für die feinen Texturen.

3. Quantisieren. Jeder Koeffizient wird durch eine Schrittweite geteilt und auf eine ganze Zahl gerundet. Kleine Koeffizienten werden zu null. Das ist der einzige verlustbehaftete Schritt in der ganzen Pipeline, und der Qualitätsregler deines Encoders ist nichts weiter als ein Multiplikator für diese Schrittweiten. Qualität 95 nimmt kleine Schritte und behält fast alles, Qualität 30 nimmt große Schritte und setzt den Großteil der feinen Textur auf null.

4. Den Rest entropiekodieren. Zickzack-Scan, Lauflängenkodierung, Huffman- oder arithmetische Kodierung. Diese Stufe ist verlustfrei; sie packt nur die bereits quantisierten Zahlen.

Lies die Liste ruhig noch einmal: Die Schritte 1, 2 und 4 sind reversible Buchführung. Erst Schritt 3 zerstört das Bild wirklich, absichtlich, ein Rundungsfehler nach dem anderen.

Diese Zerstörung hinterlässt eine unverwechselbare Handschrift. Drückst du die Qualität zu weit, bekommst du Blocking (sichtbare 8 x 8-Gitterkanten in Himmeln und Wänden), Ringing (Höfe um Text und hochkontrastige Kanten) und Banding (weiche Verläufe, die zu sichtbaren Stufen zerfallen). Beim erneuten Speichern läuft die Pipeline über bereits beschädigte Daten, deshalb summiert sich der Generationsverlust: Beim zehnten Speichern sieht ein JPEG aus wie ein Aquarell des ersten.

Wie verlustfreie Komprimierung funktioniert

Verlustfreie Codecs erlauben sich solche Freiheiten nicht. Die dekodierte Datei muss Bit für Bit dem Original entsprechen, also bleibt nur Modellieren und Packen. Das Standardrezept hat zwei Stufen.

Stufe eins: Dekorrelation. PNG filtert jede Bildzeile vor dem Komprimieren. Für jede Zeile wählt der Encoder einen von fünf Prädiktoren (None, Sub, Up, Average, Paeth) und speichert die Differenz zwischen dem tatsächlichen Pixel und der Vorhersage. Aus einer einfarbig weißen Zeile wird so ein einziges weißes Pixel gefolgt von Tausenden Nullen, aus einem sanften Verlauf kleine, langsam schwankende Residuen. In beiden Fällen werden die Zahlen klein und ballen sich nahe null, genau das, was die nächste Stufe braucht.

Stufe zwei: Entropiekodierung. PNG verwendet DEFLATE, denselben Algorithmus hinter gzip und zip, gebaut aus zwei Ideen aus den 1970ern. LZ77 sucht nach wiederholten Bytefolgen und ersetzt jede Wiederholung durch einen (Distanz, Länge)-Zeiger in die vorherigen 32 KB Daten. Die Huffman-Kodierung weist dann häufigen Werten kurze Bitcodes zu und seltenen lange. Keiner der beiden Schritte verliert etwas: Aus dem gepackten Strom lassen sich die ursprünglichen Bytes jederzeit exakt rekonstruieren.

Deshalb ist PNG bei Screenshots brillant und bei Fotos chancenlos. Interface-Grafiken wiederholen sich ständig: identische Zeilen, gleiche Icons, lange Flächen einheitlicher Farbe. LZ77 findet überall Treffer, und die Filter verwandeln den Rest in Residuen nahe null. In einem Foto wiederholt sich dagegen nichts: Schrotrauschen macht jedes Pixel ein wenig anders als seine Nachbarn, die Prädiktoren liegen daneben, die Residuen bleiben groß und zufällig, und LZ77 findet nichts, auf das es verweisen könnte. PNG schafft bei einem 12-MP-Foto typischerweise 1,3:1 bis 1,6:1 gegenüber den Rohpixeln. JPEG erreicht bei sichtbar ähnlicher Qualität 10:1.

Der Gegenwert für die größeren Dateien ist eine absolute Garantie: Dekodierst du ein PNG und hashst die Pixel, stimmt der Hash jedes Mal mit dem der Quelle überein. Für Screenshots, die durch eine OCR laufen, Scans, die noch nachbearbeitet werden, oder medizinische und wissenschaftliche Bilder, die in einer Veröffentlichung oder vor Gericht landen können, ist genau diese Garantie der Punkt.

Warum JPEG 1992 auf verlustbehaftet setzte

Die Joint Photographic Experts Group nahm 1986 ihre Arbeit auf, und die Zwänge jener Zeit erklären jede Designentscheidung. Eine 20-MB-Festplatte kostete Hunderte Dollar. Die 1,44-MB-Diskette war das Standard-Austauschmedium. Modems liefen mit 14,4 kbps, wenn man Glück hatte: Der Download eines einzelnen unkomprimierten 921-KB-VGA-Fotos dauerte damit grob neun Minuten. Die verlustbehaftete 10:1-Version ist in unter einer Minute da, die verlustfreie 2:1-Version braucht immer noch über vier.

Die eigenen Tests des Komitees zeigten, dass verlustfrei hier nicht weit tragen würde: Fotografischer Inhalt, das erklärte Ziel ("continuous-tone images"), enthält schlicht nicht genug Redundanz. Also bauten sie den Standard um den einzigen Faktor herum, der noch Spielraum ließ: den Betrachter.

Weniger bekannt ist, dass der 1992 veröffentlichte Standard (ISO/IEC 10918-1) durchaus einen verlustfreien Modus enthält. Er überspringt die DCT komplett, sagt jedes Pixel aus bis zu drei Nachbarn mit einem von sieben festen Prädiktoren vorher und kodiert die Residuen entropisch, konzeptionell derselbe Trick, den PNG drei Jahre später verwenden sollte. Implementiert hat ihn trotzdem fast niemand: Decoder und Encoder ignorierten ihn gleichermaßen, und als die Medizintechnik wirklich verlustfreies JPEG brauchte, bekam sie stattdessen einen eigenen Standard (JPEG-LS, ISO/IEC 14495, 1999).

Auch vor Patenten musste das Komitee ausweichen. Die Option auf arithmetische Kodierung in JPEG war in IBMs Q-Coder-Patenten verheddert, also setzte die lizenzfreie Baseline auf Huffman, und die meisten Implementierungen rührten den arithmetischen Pfad nie an. Dass Patentsorgen Codec-Design beeinflussen, war 1992 nichts Neues. Es sollte noch deutlich schlimmer kommen.

Unterm Strich war JPEG eine psychovisuelle Wette: Die letzten 5x Komprimierung sind keine Mathematik mehr, sondern Biologie.

Warum PNG 1995 auf verlustfrei setzte

PNG begann nicht als Ingenieursprojekt. Es begann als juristischer Notfall.

Im Dezember 1994 kündigte Unisys an, künftig Lizenzgebühren für Software mit GIF-Unterstützung zu verlangen. GIFs Komprimierung beruhte nämlich auf LZW, einem Algorithmus, der unter einem 1985er-Patent lief, das Unisys geerbt hatte. CompuServe, der Schöpfer von GIF, einigte sich mit Unisys und reichte die Kosten an die Entwickler weiter. Die Usenet-Grafik-Community tobte: Sieben Jahre lang war GIF frei gewesen, und plötzlich stand ein ganzes frühes Web voller Bilder und Werkzeuge auf patentiertem Boden.

Schon Anfang Januar 1995, nur wenige Wochen später, postete Thomas Boutell den ersten Entwurf für einen Ersatz. Freiwillige zimmerten das Design in wenigen Monaten über Mailinglisten zusammen. PNG 1.0 erschien im Oktober 1996 als W3C-Empfehlung, dann als RFC 2083 im März 1997.

Zwei Anforderungen standen nie zur Debatte. Jeder Algorithmus musste patentfrei sein, was DEFLATE bedeutete (die Kombination aus LZ77 und Huffman aus Phil Katz' PKZIP, implementiert in zlib von Jean-loup Gailly und Mark Adler). Und das Format musste verlustfrei sein, Punkt. Die Community wollte GIF ersetzen, und ein Ersatz, der Bilder verschlechtert, hätte von Anfang an keine Chance gehabt. Zudem ließ die Patentprüfung ohnehin keinen Raum für die wahrnehmungsbasierten Tricks, auf denen JPEG beruhte.

Mindestens ebenso wichtig war der Inhalt. PNG wurde für das gebaut, was GIF tatsächlich transportierte: Logos, Diagramme, Strichzeichnungen, Icons, Screenshots. Scharfe Kanten und gleichmäßige Farbflächen, genau der Inhalt, bei dem JPEGs Ringing-Artefakte am sichtbarsten sind. Hätte PNG auch den Fotobereich angegriffen, wäre das gleichbedeutend gewesen mit einer Neuauflage der DCT und dem Wettbewerb gegen ein etabliertes, lizenzfreies JPEG. PNG suchte sich den Kampf aus, den es gewinnen konnte, und gewann ihn haushoch. Das GIF-Patent lief 2003 aus (2004 außerhalb der USA), aber da hatte PNG den Job längst übernommen.

Warum verlustbehaftet den Markt trotzdem gewann

PNG sicherte sich die Nische. JPEG holte sich alles andere.

Der Grund ist schlicht die Menge. Die Bilder im Web sind zum überwältigenden Teil Fotos, und für Fotos ist verlustbehaftet kein Kompromiss, sondern das richtige Werkzeug. Der Web Almanac 2025 beziffert den Anteil von JPEG an allen ausgelieferten Bildern auf rund 57%, und das nach drei Jahrzehnten. Social-Media-Feeds, Nachrichtenfotografie, Produktaufnahmen, Immobilienanzeigen: allesamt Inhalte mit kontinuierlichen Tonwerten, bei denen eine verlustbehaftete Kodierung in Qualität 75 auf den Bildschirmen, die Leute wirklich benutzen, nicht vom Original zu unterscheiden ist.

Die Kostenrechnung zeigt in dieselbe Richtung. Speicher und Bandbreite werden pro Byte abgerechnet, und 10:1 statt 2:1 ist dann kein kleiner Vorteil mehr, sondern Faktor fünf bei den Auslieferungskosten, bei akzeptabler Qualität. Seitengeschwindigkeit folgt der Dateigröße, und die Dateigröße folgt der Komprimierung. Jede Kamera und jedes Telefon liefert ab Werk verlustbehaftet komprimierte Bilder (JPEG oder HEIC). Jedes CMS erzeugt verlustbehaftete Thumbnails. Soziale Plattformen kodieren jeden Upload neu, teils wegen der Größe, teils um Metadaten und eventuell versteckten Schadcode loszuwerden. Ein Fotograf kann ein makelloses TIFF hochladen; was die Timeline ausliefert, ist ein JPEG in Qualität 85.

Verloren hat die verlustfreie Seite dabei nicht wirklich, sie hat sich nur dorthin zurückgezogen, wo ihre Garantie zählt: Screenshots und UI-Assets, wo Artefakte sofort sichtbar sind und der Inhalt ohnehin gut komprimiert; Master in einer Bearbeitungs-Pipeline, wo sich jede verlustbehaftete Generation als weiterer Schaden addiert; medizinische, juristische und wissenschaftliche Bildgebung, wo "gut genug" nicht als Beweis durchgeht. In diesen Nischen sind PNG und TIFF unangefochten. Nur liegen diese Nischen eben nicht dort, wo der Traffic ist.

Wo die Formate gelandet sind

Zwei Trends fallen auf. Neue Codecs wählen keine Seite mehr: WebP, HEIC, AVIF und JPEG XL liefern verlustbehaftete und verlustfreie Modi in einer einzigen Spezifikation, und JPEG 2000 tat das schon 2000. Die Frage verlustbehaftet gegen verlustfrei hat sich von "welches Format" zu "welcher Modus" verschoben. Und es tauchen immer neue Grenzfälle auf. JPEG XL kann ein bestehendes JPEG verlustfrei auf etwa 80% seiner Größe rekomprimieren, ein Trick, der nur funktioniert, weil beide Lager dreißig Jahre lang die Mathematik des jeweils anderen studiert haben.

Die Wahl in der Praxis

Der Entscheidungsbaum ist kurz:

• Ein Foto veröffentlichen? Verlustbehaftet. JPEG, wenn Kompatibilität zählt, WebP oder AVIF, wenn die Dateigröße zählt.
• Einen Screenshot, ein Logo oder irgendetwas mit Text und großen Farbflächen speichern? Verlustfrei. PNG.
• Bearbeiten? Das Master verlustfrei halten, verlustbehaftete Kopien exportieren und eine verlustbehaftete Datei nie im selben Format erneut speichern. Jede Generation verschärft den Schaden.
• Konvertieren? Das Ausgabeformat nach der Aufgabe wählen, nicht nach der Eingabe. Ein PNG-Screenshot, der in eine Fotogalerie soll, wird am besten zu JPEG oder WebP. Ein JPEG, das in eine Designdatei soll, wird zu PNG, nicht weil es dadurch Qualität gewinnt (das kann es nicht), sondern weil es aufhört, weitere zu verlieren.

Gerade an diesem letzten Punkt stolpern viele bei iPhone-Fotos. HEIC ist bereits verlustbehaftete HEVC-Komprimierung. Die Umwandlung nach PNG stellt nichts wieder her; sie friert den aktuellen Zustand ein und verhindert jeden weiteren Verlust. Das ist trotzdem nützlich, wenn du das Bild noch bearbeiten willst. Zum Teilen nimmst du am besten gleich JPEG. Unsere Konverter HEIC zu JPG, HEIC zu PNG und HEIC zu WebP laufen komplett lokal in deinem Browser, deine Datei verlässt das Gerät also nicht.

Der Rest der Matrix folgt derselben Logik. Ein JPEG in einen verlustfreien Workflow überführen: JPG zu PNG. Einen PNG-Screenshot fürs Web verkleinern: PNG zu JPG, oder PNG zu WebP, wenn es noch kleiner sein soll und die Transparenz erhalten bleiben muss. Umgekehrt stellen WebP zu PNG und WebP zu JPG die Kompatibilität mit älterer Software wieder her. Wenn du auf unkomprimierten BMP-Scans sitzt, geben dir BMP zu JPG, BMP zu PNG und BMP zu WebP dieselbe Wahl zwischen verlustbehaftet und verlustfrei in einem Schritt. Selbst beim Export von Dokumenten stellt sich dieselbe Frage: Eine PDF-Seite als Bild zu speichern heißt, sich zwischen PDF zu JPG für fotografische Seiten und PDF zu PNG zu entscheiden, wenn der Text gestochen scharf bleiben muss.

Dreißig Jahre später haben die Formate überlebt, die genau wussten, welche Details ihre Nutzer getrost vergessen dürfen und welche nicht.