Vortrag 12: Das Grafikdateiformat PNG

Nachdem 1981 in den USA das Patentieren von Software erlaubt wird, kommt es zu einer Welle von Patentanmeldungen, darunter auch zahlreiche Kompressionsalgorithmen in allen Varianten. Unisys erhält 1983 ein Patent für LZW-Kompression, die ohne ihr Wissen im Grafikformat GIF (Graphics Interchange Format, siehe Vortrag 10) verwendet wird. Erst 1994 wird Unisys darauf aufmerksam und erhebt Gebührenforderungen.
Fünf Tage später stellt Thomas Boutell das neue Grafikformat PNG vor.

1977	Abraham Lempel und Jakob Ziv erfinden eine neue Familie von Kompressionsalgorithmen. Die erste Variante wird LZ77 genannt und noch heute in "compress", "zoo", "lha", "pkzip" und "arj" benutzt. Ein Jahr später wird die zweite Variante namens LZ78 erfunden.
1981	die USA erlauben das Patentieren von Software.
10. August	Lempel, Ziv, Cohn und Eastman patentieren den LZ78-Algorithmus (US patent 4,464,650).
1983
1. Juni	IBM reicht ein Patent für LZW-Kompression ein (US 4,814,746)
20 Juni	Terry A. Welch patentiert für die Sperry Corporation (später von Unisys aufgekauft) als "High speed data compression and decompression apparatus and method" den LZW-Algorithmus (eine modifizierte Variante des LZ78) noch einmal in spezieller Form (siehe Bild). Aber das Patentamt erkennt die Überschneidung nicht und vergibt ein weiteres Patent (US patent 4,558,302, EP 0,129,439).
1984	der erste Artikel über LZW erscheint in einer Fachzeitschrift. Es gibt in den USA keine Veröffentlichungspflicht für Patente.
1987	CompuServe veröffentlicht GIF als freie und offene Spezifikation.
1987-1994	GIF wird rasch ein sehr beliebtes Dateiformat um Bilder zu speichern und auszutauschen.
1990	E. Fiala und D. Greene erhalten das Patent Nr. US 4,906,991 für eine Variante von LZ77 mit einem Wörterbuch in Baumstruktur.
1991	IBM erhält Patent Nr. US 5,001,478 für einen Algorithmus, der die "LZ77-history" mit dem "LZ78-lexicon buffer" kombiniert.
	Phil Katz (Programmierer von "pkzip") erhält Patent US 5,051,745 für eine LZ77-Variante, die mit sortierten Streutabellen arbeitet, wenn die Tabellen kleiner als die Fenstergrösse sind.
	Weitere Patente für LZ77-Varianten mit Streutabellen gingen an Robert Jung (Programmierer von "arj") (Patent 5,140,321), Chambers (Patent 5,155,484) und Stac, Inc. (Patent 5,016,009).
	Weitere Varianten von LZ77 und LZW wurden entwickelt, aber nicht patentiert.
1993	Unisys merkt, daß GIF ihr LZW-Patent berührt und informiert CompuServe.
1994, 29. Dezember	Unisys tritt mit Gebührenforderungen an die Öffentlichkeit. Bis dahin beschränkte sich Unisys auf Hardware, die den LZW-Algorithmus verwendet, z.B. Modems mit V.42.
1995, 4. Januar	Thomas Boutell sendet die Spezifikation für ein "Portable Bitmap Format" (PBF) in zahlreiche Diskussionsforen im globalen Datennetz ("news-groups"). Eine bunte Schar Entwickler aus der ganzen Welt bildet per Epost und Diskussionsforen die PNG-Gruppe. Ihr Ziel: Ein neues Grafikformat, frei von geschützten Algorithmen und den besonderen Anforderungen der Datennetze gewachsen. Nach kurzer Diskussion steht fest, das die Zeit reif ist für ein komplett neues Format und daß Erweiterungen bestehender Formate, etwa GIF24, transparente JPEG (Joint Photographic Expert Group, siehe Vortrag 11), TIFF-Untermengen (Tagged Image File Format) oder ähnliches nicht allen Anforderungen gerecht werden würden.

Geschichte der PNG-Spezifikation [4]

Per Epost und Diskussionsforen im globalen Datennetz entsteht in internationaler Zusammenarbeit nach nur zwei Monaten PNG (Portable Network Graphics). Alle weiteren Versionen der PNG-Spezifikation sind kompatibel zu dieser Version. Parallel arbeiten andere an einer freien PNG-Bibliothek in C, der "pnglib". Nach ca. 3 Jahren wird die Spezifikation eingefroren und beginnt ihren Marsch durch die Institutionen. Es fehlt nur noch die Anerkennung als ISO-Standard (International Organization for Standardization).

1995
6. Januar	Oliver Fromme erfindet den Name "PNG". Intern steht es für "PiNG is Not GIF". Die Aussprache von PNG als "ping" steht jetzt sogar in der offiziellen Spezifikation. [5]
15. Januar	Die dritte Version der PNG-Spezifikation wird veröffentlicht. Deflate-Kompression, Gamma-Information, zyklische Prüfsummen, 16 Bit Farbtiefe und Alpha-Kanal sind bereits enthalten. Erste Implementierungen zeigen eine 10% bessere Kompression gegenüber GIF.
16. Januar	CompuServe kündigt das GIF24-Projekt an. Weitere PNG-Spezifikationen erscheinen in rascher Folge.
7. Februar	CompuServe kündigt volle Unterstützung für PNG an.
7. März	Die allerersten PNG-Bilder werden ins Netz gestellt.
24. März	Die allererste Version 0.1alpha der "pnglib" erscheint.
1. Mai	Zusammen mit "pnglib" 0.6beta erscheint die erste "zlib" 0.9beta. Die "zlib" ist eine freie, portable Bibliothek für den Umgang mit dem "zlib"-Format. Diese beiden Bibliotheken sind gerade stabil genug um benutzt zu werden. Mit ihrer Hilfe gibt es kurz darauf bereits die ersten PNG-Implementierungen.
13. Juni	Eine PNG Heimatseite wird ins Netz gestellt.
25. Juni	Glenn Randers-Pehrson veröffentlicht Version 1 der PNF ("Portable Network Frame")-Spezifikation als Ergänzung zu PNG. Der Aufbau ist stark an PNG angelehnt, speichert jedoch mehrere Bilder in einer Datei. Die integrierten Animationsfähigkeiten gehen weit über die von GIF hinaus (z.B. "Sprite"-Animationen). Später wird das Format in MNG ("Multiple Network Graphics") umbenannt.
Oktober	Die ersten Betaversionen von Netscapes Navigator erscheinen zur Bestürzung der PNG-Gruppe mit Unterstützung von animierten GIFs.
8. Dezember	Das World Wide Web Consortium (W3C) veröffentlicht die PNG-Spezifikation 0.92 als offizielles Arbeitsdokument.
1996
23. Februar	Die PNG-Spezifikation 0.95 wird als "Internet Draft" von der Internet Engineering Task Force (IETF, siehe: http://www.ietf.org/ ) vorgestellt.
21. Mai	"zlib" 1.0.1, die erste nicht-beta erscheint
22. Mai	Die Spezifikationen der zlib, des "Deflate"-Algorithmus und von "gzip" erscheinen als offizielles RFC ("request for comments") unter den Nummern 1950 [9], 1951 [10] und 1952.
30. Mai	Tom Lane, der letzte Überarbeiter den PNG Spezifikation, erklärt PNG für abgeschlossen und die Version 0.98 als offizielle 1.0 unter dem Vorbehalt der media/png-Registratur.
1. Juli	Das W3C stellt die PNG-Spezifikation auf offiziellen "Proposed Recommendation"-Status.
11. Juli	Die Internet Engineering Steering Group (IESG) akzeptiert die PNG Spezifikation 1.0 als offizielles Informational RFC
4. August	Die Virtual Reality Modeling Language (VRML) 2.0 Spezifikation wird veröffentlicht. PNG und JPG sind die beiden internen Bildformate, die unterstützt werden müssen.
1. Oktober	PNG wird vom W3C offiziell als "Recommendation" in einer Presseerklärung genannt.
14. Oktober	Die Internet Assigned Numbers Authority (IANA, http://www.iana.org/ ) akzeptiert image/png formal als "Internet Media Type".
31. Dezember	Die MNG Spezifikation erscheint in der 30. Version.
1997
15. Januar	Die IETF veröffentlicht die PNG Spezifikation 1.0 als offizielles RFC 2083 (siehe: ftp://ftp.isi.edu/in-notes/rfc2083.txt )
3. April	Xara Inc. veröffentlicht die Flare 1.0 Spezifikation. Die ist ein Vektorgrafikformat, ähnlich PNG. Es kann Bitmaps als PNG enthalten.
14. März	Die National Gallery of Art in Washington D.C. stellt ihre Heimatseite komplett auf PNG um.
11. November	"Netscape 4.04" wird mit PNG-Fähigkeiten (alllerdings ohne Alpha-Kanal) veröffentlicht. Zusammen mit dem wenige Wochen vorher veröffentlichten "Internet Explorer 4.0" sind jetzt 90% aller benutzen Stöberer PNG-fähig.
31. Dezember	Die MNG Spezifikation erscheint in der 42. Version.
1998
7. März	"libpng" 1.00 erscheint fast auf die Minute genau drei Jahre nachdem die PNG Spezifikation, 9. Version veröffentlicht wurde.
8. April	Netscape entfernt den PNG-schreibenden Code aus Mozilla. Stac Inc. hatte Patentansprüche auf den "Deflate"-Algorithmus beansprucht unter Berufung auf die Patente (US 4,701,745 und US 5,016,009). Die Free Software Foundation hatte bei Patentrecherchen nichts gefunden. Mitglieder der PNG-Gruppe halten diesen Vorfall für ein Mißverständnis zwischen Netscape und Stac Inc. bei Patentproblemen bei SSL-Verschlüsselung.
9. Juli	"zlib" 1.1.3 erscheint
23. August	Eine MNG-Heimatseite wird ins Netz gestellt (siehe: http://www.cdrom.com/pub/mng/ ) Technische Informationen (siehe: http://www.cdrom.com/pub/mng/mngdocs.html )
31. Dezember	PNG Spezifikation 1.1 erscheint. Zusätzlich erscheint ein eigenes Dokument, welches die Erweiterungsblöcke näher beschreibt. Überarbeitet wurden die Blöcke sRGB (standard sRGB color space) [16], iCCP (International Color Consortium profile) [15], sPLT (suggested palette and histogram).
1999
9. Januar	Ein ISO PNG Treffen findet in San Jose statt. Zu Beginn des Jahres könnte die jetzige Spezifikation 1.1. zum offiziellen Standard ISO/IEC (International Electrotechnical Commission) 15948 werden.
14. Januar	"pnglib" 1.0.3 erscheint.
2003	Das GIF-Patent von Unisys läuft aus... :-)

Ein neues Grafikformat

Wofür ist PNG gedacht?

PNG ist als Ersatz für GIF hauptsächlich für die Nutzung in Datennetzen konzipiert. Es kann aber Bilder bis zu einer Farbtiefe von 16 Bit pro Komponente (= 48 Bit RGB, ermöglicht Speichern von 281.474.976.710.656 Farben plus Alpha-Kanal) speichern und besitzt derart viele mögliche Zusatzparamter, daß es durchaus auch in anderen Computergrafikbereichen breite Akzeptanz finden wird. Es ist zudem flexibel erweiterbar und leicht zu implementieren.

Welche Eigenschaften hat PNG?

Portabilität

Gammaparameter und Parameter für die Definition des gewählten Farbraumes sorgen für hardwareunabhängige Darstellung der Bilder, sofern die Enkoder (z.B. Bildbearbeitungsprogramme, Bildkonverter) und Dekoder (z.B. Bildbetrachtungsprogramme, Stöberer) diese nicht ganz einfachen Transformationen durchführen können.

Erweiterbarkeit

Das Bild kann in einem PNG in verschiedenen Kompressionsverfahren gespeichert werden. En- und Dekoder müssen laut Spezifikation lediglich den "Inflate/Deflate"-Algorihmus beherrschen. Jegliche zusätzlichen Daten können in private Zusatzblöcke geschrieben werden. Dekoder können das Bild trotzdem stets korrekt anzeigen.

Optimiert für Netzwerk-Anwendungen

Durch Prüfsummen und eine sich selbst verfeinernde Anzeige ("progressive display") während des Ladens des Bildes aus dem Netz ist PNG besonders für den Einsatz in Datennetzen geeignet. Zudem unterstützt PNG Transparenz in Form von Alpha-Kanälen und die Möglichkeit Meta-Informationen in Form von Textblöcken mitzuspeichern.

Welche Eigenschaften hat PNG nicht? Warum?

Prinzipiell wurden alle Eigenschaften weggelassen die nicht unbedingt nötig sind. So sind Enkoder und Dekoder leichter zu schreiben, was zu einer stärkeren Verbreitung von PNG führen wird. Durch die Erweiterbarkeit von PNG können diese und andere Eigenschaften nach Belieben hinzugefügt werden. Sie sind für En- und Dekoder jedoch nicht verpflichtend, um den PNG-Standard zu erfüllen.

CMYK?

Es können keine Bilder im CMYK-Farbmodell (Cyan, Magenta, Yellow, Black) gespeichert werden. Dieses Format ist in der Druck-Branche sehr beliebt, da beim Drucken genau die Farben Cyan, Mangenta, Gelb und Schwarz verwendet werden. Da PNG aber für die Verwendung im Internet gedacht ist und CMYK sehr geräteabhängig ist, hat sich die PNG-Gruppe dagegen entscheiden.

Index-Bilder?

Die PNG-Gruppe hat sich gegen festgelegte Index-Bildchen ("Thumbnail pictures") entschieden, da nach Gesprächen mit Softwareherstellern klar wurde, daß jeder eine eigene Vorstellung von solchen Bildern hat, die sich nicht vereinen ließen.

Mehrere Bilder in ein PNG?

Auch diese Eigenschaften schien der PNG-Gruppe nicht wichtig genug. Animierte GIF-Bilder gab es zu dieser Zeit kaum. Als diese aufkamen war die PNG-Gruppe schon dabei ein neues Format, genannt MNG (Multiple Network Graphics) auf den Weg zu bringen, dessen Fähigkeiten weit über die animierte GIF-Bilder hinaus gehen werden.

Verlustbehaftete Kompression?

Die nötigen Algorithmen sind zum einen durch Patente von IBM nicht frei, zum anderen sehr kompliziert zu implementieren. Werden die Kompressionsparameter nicht sorgfältig gewählt ist das komprimierte Bild zudem stark verschieden vom Original. Zudem wollte die PNG-Gruppe die Spezifikation möglichst einfach halten - zudem ist verlustbehaftete Kompression schon durch JPG gut vertreten.

Entworfen für das "World Wide Web"

Paletten- und Echtfarbbilder in PNG

PNG erlaubt sowohl palettenbasierte Bilder mit bis zu 256 Farben als auch Echtfarbbilder im RGB-Farmodell. Dabei werden für Rot- Grün- und Blauanteil jeweils ein Wert gespeichert. Auch Graustufenbilder sind zulässig. Alle Typen dürfen einen Alpha-Kanal enthalten. Farbwerte dürfen bis zu 16 Bit Genauigkeit gespeichert werden, was über die Fähigkeiten der meisten Formate hinausgeht (JPG kann nur 8 Bit).
Nicht alle Kombinationen von Bildtypen und Bittiefen sind direkt erlaubt, mehr dazu im Start-Block, wo diese Parameter gespeichert werden.

Transparenz: Echte Alphakanäle

Ein Alpha-Kanal definiert für jeden Bildpunkt einen Wert, der definiert wie transparent er dargestellt werden soll. Im Extremfall ist ein Pixel dabei entweder komplett deckend oder komplett durchsichtig. Alle PNG-Typen (Grau, Farbe, Palette) können Alpha-Informationen enthalten. Ein großes Problem der Grafiker für Datennetze ist nun behoben: Trotz der geringen Größe kleiner Logos und Knöpfe können nun die Ränder verwischt werden, was treppenförmige Kanteneffekte vermindert, ohne von einer bestimmten Hintergrundfarbe abhängig zu sein.

Beispiel:
Dieses Bild hat starke Treppentstufen-Effekte...

Bild 2: Ohne Kantenglättung

..also wird es auf weißem Hintergrund verwischt...

Bild 3: Mit Kantenglättung

...was zu häßlichen weißen Rändern führt, wenn das Bild auf einem anderen Hintergrund dargestellt wird. Das Problem liegt in der binären Transparenz von GIF. Einzige Abhilfe: Echte Alphakanäle, wie sie PNG bietet. Damit wird kein Verlauf mehr von der Bildfarbe zum Hintergrund erzeugt, sondern ein Verlauf von der Bildfarbe zu immer höherer Transparenz. Das PNG mit Alpha-Kanal sieht dann weich aus wie Bild 3, nur eben vor jeder Hintergrundfarbe.

Bild 4: störende weiße Ränder

Für Alphakanäle gibt es zwei Verfahren. Bei "vorabmultipliziertem Alpha-Kanal" ("premultiplied alpha") wird jeder Pixel mit seiner Transparenz vor einem schwarzen Hintergrund verrechnet. Ist der Alpha-Wert jedoch null, also voll transparent, gehen die Farbinformationen des Pixels verloren, da sich diese nun ebenfalls zu null ergeben.
Bei "nichtverknüpften" ("unassociated") Alpha-Werten werden die Alpha-Werte erst beim dekodierendes Bildes eingerechnet. Diese etwas flexiblere Methode erlaubt eine von den Pixelfarben unabhängige Bearbeitung der Alpha-Maske ohne Verlust von Bildinformationen. Daher hat sich die PNG-Gruppe für diese Variante entschieden. [11]

Ein Test mit PNG-Bildern, die Alpha-Kanal-Informationen enthalten, ist zu finden unter:
http://www.w3.org/Graphics/PNG/inline-alpha.html

Erste Schicht: Bildpunkte werden als PNG-Pixel kodiert

PNG kodiert Pixel entweder mit einer mitgeschickten Palette oder direkt mit Graustufen- bzw. Farbwerten. Farbwerte bestehen aus drei Werten für Rot, Grün und Blau. Zu jedem Pixel kann ein Alpha-Wert gehören, der seine Transparenz beschreibt. Ein Pixel hat also ein Länge zwischen 1 Bit (Graustufenbild mit Bittiefe 1) und 64 Bit (RGBA = 16 Bit pro Farbe + 16 Bit für den Alpha-Kanal). Nicht alle Farbtypen erlauben alle Bittiefen, dazu müssen u.U. höhere PNG-Bittiefen verwendet werden, als das zu speichernde Bild eigentlich besaß.

progressive Anzeige durch Verschachtelung

Die Pixeldaten sind im "zlib"-Datenstrom auf folgende Weise verschachtelt. Das Bild wird dazu in Blöcke zu 64x64 Pixel aufgeteilt. Im Datenstrom kommen nun zuerst die oberen linken Ecken dieser gedachten Blöcke. Der Dekoder kann dann während des Ladevorgangs bereits eine grobe Vorschau für das Bild anzeigen, indem er die übertragenen Pixel auf 64x64-Blöcke der angegebenen Farbe erweitert.
PNG überträgt eine grobe Vorschau acht mal schneller als GIF. Das ist insbesondere bei großen anklickbaren Bildern ("ImageMaps") sehr hilfreich, da der Benutzer, sofern er dieses Bild wiedererkennt, schon weiß, wo er hin klicken muß.
Wenn im Bild Text abgebildet ist, z.B. auf Werbetafeln, so ist dieser, im Vergleich zu GIF, schon nach der halben übertragenen Datenmenge lesbar.

Bild 5: Adam7, erster Durchgang

Im nächsten Schritt wird das Bild in gedachte 32 x 64 - Blöcke aufgeteilt. Jede zweite linke obere Ecke wurde schon übertragen, die jeweils fehlende wird nun im Datenstrom übertragen. Diese Iteration erfolgt jetzt nicht nur von links nach rechts, sondern auch in der anderen Bilddimension, von oben nach unten. Nun ist die Symmetrie wieder hergestellt und von jedem 32x32-Block die linke obere Ecke übertragen worden.

Bild 6 & 7: Adam7, zweiter und dritter Durchgang

Die Iteration läuft ein weiteres Mal ab. Jetzt sind erst 25% der Bildinformationen übertragen worden.

Bild 7 & 8: Adam7, vierter und fünfter Durchgang

Nach dem siebten Schritt ist das Bild vollständig übertragen worden. Nach seinem Erfinder Adam M. Costello heißt es Adam7. Herr Costello hat dieses Verschachtelungsschema nicht patentieren lassen, dieses aber nach eigenen Angaben auch nicht vor.

Bild 9 & 10: Adam7, sechster und siebter Durchgang

Zweite Schicht: PNG-Pixel werden in Bildzeilen gepackt

Die PNG-Pixel werden immer in Bildzeilen übertragen. Jeder Bildzeile geht ein Filtertyp-Byte voran. PNG-Bilder können nach dem Adam7-Schema verschachtelt werden. Dann werden logisch sieben Bilder übertragen, von denen das erste die Dimension Breite/64 x Höhe/64 hat usw. Jedes dieser logischen Bilder besteht wiederum aus Bildzeilen mit Filtertyp-Byte.

Kompression

Das Speichern eines Bildes als PNG läuft in drei Schritten ab.

Im ersten Schritt werden die Bildpunkte nach dem gewählten Verschachtelungsschema vertauscht. Wird die Adam7-Verschachtelung gewählt, so führt dies zu etwa 20% größeren Bildern (eigene Berechnungen).

Im zweiten Schritt werden verschiedene verlustfreie Filter angewandt um die Daten besser komprimierbar zu machen.

Im dritten Schritt wird der verschachtelte, gefilterte und komprimierte Datenstrom in einen oder mehrere Datenblöcke geschrieben.

Der "Deflate"-Algorithmus [10]

"zlib" [3] verwendet den von Phil Katz entwickelten "Deflate"-Algorithmus, eine Variation von LZ77. Der patentierte LZ77-Algorithmus verwendet ein variables Gleitfenster und sortierte Streutabellen, um Datenmuster zu identifizieren und nach dem Huffman-Verfahren zu kodieren. In PNG kommt eine Variante ohne sortierte Streutabellen zum Einsatz, die keine Patente oder lizenzpflichtige Algorithmen berührt. Portable C-Implementationen sind frei verfügbar.

Der zlib-Datenstrom hat folgenden Aufbau [9]:

    Kompressionsmethode: 1 Byte

    zusätzliche Steuerbits, Prüfbits: 1 Byte

    komprimierte Datenblöcke: n Bytes

    Prüfsumme: 4 Bytes

Für Verwendung in PNG muß die einzig spezifizierte Kompressionsmethode 0 ("zlib"-Format) gewählt werden. Im "zlib"-Datenstrom muss als Subformat Methode 8 ("Deflate"-Kompression) gewählt werden. Außerdem darf das Schiebefenster nicht größer als 32 KB sein. Auch ein vorab gesetztes Wörterbuch darf nach PNG-Spezifikation nicht definiert werden.
Genaueres spezifiziert die zlib-Spezifikation [RFC-1950]. Die "zlib" selbst kann gezwungen werden "schneller und schlechter" zu komprimieren als die Standardeinstellung "optimiert aber langsamer".
Die komprimierten Blöcke können in drei Varianten gespeichert werden: Unkomprimiert, LZ77-komprimiert mit fester Huffman-Kodierung und LZ77-komprimiert mit spezifischen Huffman-Kodes. Im letzten Block ist ein Marker-Bit gesetzt, an dem der Dekompressor das Ende des "zlib"-Datenstrom erkennt. Details der "Deflate"-Spezifikation stehen im RFC-1951. Die verwendete Prüfsumme dient dazu, die korrekte Implementierung der "Deflate/Inflate"-Spezifikation zu erkennen. Zum Erkennen von Übertragungsfehlern reicht die CRC-32 (cyclic redundancy check) Prüfsumme der PNG-Blöcke völlig aus. Daher wurde für die zlib-Prüfsumme auch die schnellere Adler-32-Prüfsumme gewählt.

Filter verbessern die Kompression

Filter ersetzen die Werte der Pixel durch ihre Differenz zu einem ähnlichen Wert, z.B. der Wert des Vorgänger oder der Mittelwert der umgebenden Pixel. Diesen ähnlichen Wert nenne ich im folgenden Prognose. Alle Filter arbeiten verlustfrei auf Byte-Ebene. Dadurch, daß Werte geringer Differenz miteinander verrechnet werden, entsteht ein Datenstrom der sehr viele ähnliche Werte enthält. Dieser Datenstrom kann sehr viel besser komprimiert werden.

Die Filtermethode kann von Zeile zu Zeile wechseln. Ein jeder Zeile vorangestellter Filtertypindikator, ein Byte mit einem Wert zwischen 0 und 4, zeigt die für diese Zeile gültige Art der Filterung an. Sind die Daten verschachtelt angeordnet, ist jeder Durchgang wie ein unabhängiges Bild zu behandeln. Die Vorgängerzeile ist in jedem Fall die zuvor übertragene Zeile, also nicht notwendigerweise die im Bild benachbarte. Dieses Vorgehen gewährleistet die Möglichkeit der kontinuierlichen Dekodierung während der Datenübertragung. Zu beachten ist, das Filter immer auf den Bytes der Bildzeilen arbeiten, egal welche Informationen diese gerade tragen. So werden beispielsweise Alpha-Werte einfach mitgefiltert.

Für Bilder vom Datentyp 3, das heißt für 256farbige Palettenbilder, ist Filterung in der Regel ineffektiv. Die Autoren empfehlen hier den Filtertyp 0. Keine Filterung empfiehlt sich auch bei Farbtiefen kleiner als 8 Bit. Aufgrund des kleinen Wertebereichs ist der Gewinn gering. Ein Dekoder mit fest eingestelltem Filtertyp sollte den Paeth-Filter (nach Alan W. Paeth) verwenden. Er ist im allgemeinen am effektivsten. Dekoder, die den Filtertyp von Zeile zu Zeile wechseln, können folgendes Verfahren für die Auswahl des effizientesten Filters wählen: Jede Zeile wird auf alle fünf Arten gefiltert. Als günstigste Filterung gilt diejenige, bei der die Summe aller Werte in der Ausgabezeile am kleinsten ist. Die Kombination von Filterung und LZ77 führt gegenüber GIF zu 10 bis 30 Prozent besseren Kompressionsergebnissen. [7]

Allgemein sieht ein Filter so aus:

Filter(x) = Ungefiltert(x) - Prognose(x) vorzeichenlos arithmetisch modulo 256

das bedeutet nichts anderes, als daß das Ergebnis durch Addition/Subtraktion in den Bereich von 0-255 verschoben wird.

Hier nun die Filter im Detail:

`0 = "None"`

Hier wird die Bildzeile ungefiltert übertragen.

`1 = "Sub"`

Der Subfilter bezieht die Differenz auf den Vorgänger links vom aktuellen Pixel. Bei "multi-sample"-Pixeln, zum Beispiel bei einem RGB-Pixel, wird jede Farbkomponente auf die entsprechende des Vorgängers bezogen.

Bild 11: Der "Sub"-Filter

`2 = "Up"`

Der Up-Filter bezieht die Differenz auf das in der darüberliegenden Zeile befindliche Pixel.

Bild 12: Der "Up"-Filter

`3 = "Average"`

Der Average-Filter berechnet die Differenz auf Basis des Durchschnittwertes der Pixel links und oberhalb des aktuellen Pixels.

Bild 13: Der "Average"-Filter

`4 = "Paeth"`

Der Paeth-Filter nutzt eine lineare Funktion und den ähnlichsten Punkt links, oberhalb oder links-oberhalb des aktuellen Pixels als Bezugswert.

Bild 14: Der "Paeth"-Filter

Filter die sich auf Bytes links von der aktuellen Position beziehen müssen diese als null ansehen. Anlog für Reihen.

Beispiel

Nehmen wir an, ein Farbverlauf in einem Graustufenbild soll komprimiert werden.
Die Bilddaten könnten so aussehen:

    255 253 250 247 244 240 237 233 230 227 223 220 etc.

der Sub-Filter würde daraus folgendes machen:

    255   2   3   3   3   4   3   4   3   3   4   3 etc.

Diese Bytes wurden ohne Datenverlust erzeugt und können wesentlich besser komprimiert werden, da weniger verschiedene Werte vorkommen.

Filteralgorithmen zur Kompression sind noch nicht gut erforscht worden, es ist also gut möglich das noch bessere Filter gefunden werden, welche die Kompression weiter verbessern. Diese werden unter einer anderen Filtersetnummer spezifiziert werden, so daß es nicht passieren kann, daß ein Dekoder ein Bild entpackt und dann merkt, daß es ihm unbekannte Filter enthält.

Dritte Schicht: Bildzeilen werden als zlib-Strom komprimiert

Die gefilterten Bildzeilen werden als zlib-Datenstrom komprimiert. Dabei kommt der von Patenten freie "Deflate"-Algorithmus zum Einsatz, der eine LZ77-Kompression mit 32KB Gleitfenster spezifiziert.

Fehlererkennung und Fehlerkorrektur

PNG unterstützt drei Arten von Integritätsprüfungen, die helfen Übertragungsfehler zu erkennen. Die erste und einfachste Methode ist die acht Byte lange Signatur. Mit ihrer Hilfe werden falsche Konvertierungen beim Übertragen im Datennetz sichtbar gemacht.
Die zweite Methode ist eine CRC-32-Prüfsumme für jeden Block. Bereits während des Ladens aus einem Datennetz kann diese Prüfsumme mitgerechnet und am Ende jedes Blocks mit der übermittelten Prüfsumme verglichen werden. So werden verrauschte Leitungen erkannt.
Zum Dritten gibt es noch eine Adler-32 Prüfsumme die auf den ganzen unkomprimierten Datenstrom gerechnet wird, egal auf wie viele Bilddaten-Blöcke er sich verteilt. [13]

Aufbau einer PNG-Datei

Dateiaufbau

PNG-Datei
Signatur	Blöcke

Jede PNG-Datei beginnt mit einer kurzen Signatur gefolgt von Datenblöcken. Die Dateierweiterung lautet stets ".PNG".

Signatur

Signatur, 8 Bytes
BYTE	BYTE	BYTE	BYTE	BYTE	BYTE	BYTE	BYTE
89h	50h	4Eh	47h	0Dh	0Ah	1Ah	0Ah
Test auf 8-Bit-Transfer	"P"	"N"	"G"	Carriage Return (CR) = Wagenrücklaufsymbol	Line Feed (LF) = Zeilenvorschubsymbol	Ctrl-Z, stoppt Ausgabe unter DOS	Line Feed

Die "magische" Signatur besteht aus acht Bytes. Das erste Byte prüft, ob das PNG durch ein 8-Bit-fähiges Datennetz geschickt wurde. Wenn nicht, so ist dieses Byte bereits falsch. Die nächsten drei Bytes kennzeichnen den Dateityp "PNG". Das fünfte und sechste Byte prüfen ob beim Übertragen eines der beteiligten Betriebssysteme die Sequenz "CR LF" interpretiert und verändert hat, das könnte zum Beispiel der Fall sein, wenn das PNG als Text oder ASCII verschickt wurde. In diesem Fall ist ein Fehler zu melden, da diese Bytes durchaus in anderen Blöcken als Datenbytes vorkommen können und keinesfalls verändert werden dürfen. Sollte die PNG-Datei versehentlich in eine DOS-Ausgabe (z.B. "type xyz.png") geraten sein, so stoppt Byte 7 diese Ausgabe. Das letzte Byte testet analog zum vierten/fünften ob auch einzelne LF-Zeichen ohne Veränderungen verschickt werden.

Typen von Blöcken

Es gibt zwei Sorten von Blöcken: Kritische Blöcke, die jeder Dekoder auswerten muss und Zusatzblöcke, die die Anzeige optimieren.

Start

Zusatz-
blöcke,
evtl. Palette

Bilddaten

...

Bilddaten

Zusatz-
blöcke

Ende

Blockgrundaufbau

Blockgrundaufbau
DWORD	DWORD	BYTE	BYTE	...	BYTE	DWORD
DataLength	Type	Data[0]	Data[1]	...	Data[n]	Crc
Längen- angabe	Block-Typ	Block-Daten	Block-Daten	...	Block-Daten	CRC-32 über Typ und Daten

Jeder Block beginnt mit einer Angabe der Anzahl der Datenbytes, Längenangabe, Blocktyp und CRC-32 nicht mitgerechnet. Obwohl dieser Wert einen vorzeichenlosen Integer darstellt, sollten En-/Dekoder keine Werte größer als (2³¹)-1 Bytes zulassen, da viele Programmiersprachen so große vorzeichenlose Integer nicht bereitstellen und PNG-Programme daher unnötig schwer zu implementieren wären.
Als nächstes folgt die vier Byte lange Typkennung. Durch die Längenangabe können unbekannte Blöcke gezielt übersprungen werden.
Jetzt folgen die eigentlichen Datenbytes, gefolgt von einer Prüfsumme, die sich über Typkennung und Datenbytes erstreckt. Die Länge wird nicht mit in die CRC-Berechnung einbezogen, damit ein Durchgang (Erzeugen der Datenbytes und berechnen der Prüfsumme) ausreicht.

Das verwendete CRC-Polynom lautet:

   x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1

(siehe Vortrag 4)

Übersicht über alle Blocktypen

Blocktypen mit Position nach PNG-Spezifikation 1.1

Kürzel	Name, Position	Daten- bytes	Bedeutung	Vorteil
`IHDR`	Image header, Anfang	13	Start-Block, elementare Bildparameter	Größe beim Laden sofort bekannt
`sBIT`	Significant bits, IHDR-PLTE	1 - 4	Bittiefe des Bildes vor dem Speichern als PNG	Bessere Darstellung falls nur geringe Bittiefe auf Plattform
`gAMA`	Image gamma, IHDR-PLTE	4	Helligkeitswerte beim Erstellen: Beleuchtung, Bildschrim, usw..	Plattformunabhängige Darstellung, Helligkeit wird viel exakter angezeigt
`cHRM`	Primary chromaticities and white point, IHDR-PLTE	32	Spezifiziert die RGB-Grundfarben nach 1931 CIE x,y - Standard	Plattformunabhängige Darstellung, Farben werden exakter angezeigt
`PLTE`	Palette, IHDR-IDAT	3 - 768	RGB - Palette, benötigt und erlaubt je nach Farbtyp	GIF kann leicht als PNG konvertiert werden
`hIST`*	Image histogram, PLTE-IDAT *nur wenn `PLTE`-Block	2 - 512	Häufigkeit der vorkommenden Farben, 2 Byte pro Paletteneintrag	optimierte Darstellung falls weniger Farben darstellbar als im Bild
`bKGD`	Background color, PLTE-IDAT	1 - 6	Hintergrundfarbe: Paletteneintrag, Graustufenwert oder RGB-Definition	spart Platz, schnell sehr gute Vorschau
`tRNS`	Transparency, PLTE-IDAT	1 - 256	Alphawerte anlog GIF: für einzelne Farben/Paletteneinträge	GIF kann besser konvertiert werden, geringer Platzbedarf
`pHYS`	Physical pixel dimensions, IHDR-IDAT	9	Physikalische Grösse der Pixel und/oder Länge/Breite-Verhältnis	korrekte Geometrie auch bei Anzeige mit rechteckigen Pixeln
`oFFs`	Image offset, IHDR-IDAT	9	Position beim Drucken oder auf grossem Bildschirm
`pCAL`	Calibration of pixel values, IHDR-IDAT	16 -max	Relation zwischen Pixelwerten und physikalischen Messwerten	Kalibrierungsbalken kann angezeigt werden
`sCAL`	Physical scale of image subject, IHDR-IDAT	4 - max	Grösse des abgebildeten Objekts für Berechnungen	Verwendung bei Strassenkarten, Astronomie, Medizin
`tIME`	Image last-modification time, IHDR-IEND	7	Zeitmarke der letzten Bearbeitung	Jahr-2000-fähig
`tEXt`	Textual data, IHDR-IEND	3 - max	unkomprimierter Text: (Schlüsselwort, 00-Byte, Text)	Informationen über: Autor, Software, rechtliche Hinweise...	*
`zTXt`	Compressed textual data, IHDR-IEND	3 - max	komprimierter Text analog tEXT, verwenden ab 1KB	lange Texte werden komprimiert übertragen	*
`gIFg`	GIF Graphic Control Extension, IHDR-IEND	4	GIF-Kontrollwerte	alle GIF-Informationen können im PNG gespeichert werden	*
`gIFx`	GIF Application Extension, IHDR-IEND	4 - max	GIF-Erweiterungsblöcke	alle GIF-Informationen können im PNG gespeichert werden	*
`IDAT`	Image data, IDHR-IEND	0 - max	nach Vorgaben angeordneter und komprimierter Datenstrom	klein, schnelle Vorschau	*
`IDAT`*	*folgende IDAT-Blöcke müssen aufeindander ohne Unterbrechung folgen



`IDAT`
`IEND`	Image trailer, Ende	0	End-Block, Dateiende-Markierung

Lesart:
Fettgedruckte Blöcke sind "kritische Blöcke", Dekoder und Enkoder müssen sie beherrschen. Blöcke mit * hinten dürfen beliebig oft vorkommen. Die Länge der Balken gibt optisch an, wo sich die Blöcke befinden dürfen (wird beim Ausdrucken dieses Dokuments leider oft abgeschnitten). Der gAMA-Block z.B. kann nicht vor den Anfang, aber auch nicht hinter den PLTE-Block rutschen. Ob erst gAMA dann cHRM oder umgekehrt kommt, ist jedoch egal. Die maximale Länge eines Blocks ist 2³¹-1.

Kritische Blöcke

Diese drei beziehungsweise vier Datenblöcke sind "Kritische Blöcke" (Critical Chunks), die jeder PNG-Dekoder auswerten muß. Nicht obligatorisch sind die Zusatzblöcke ("Ancillary Chunks") mit Zusatzinformationen, die in einer PNG-Datei auftauchen können und nicht notwendigerweise ausgewertet werden müssen. PNG V1.0 definiert 10 Typen von Zusatzblöcken, die Angaben machen wie Hintergrundfarbe, überdeckter Bereich im Farbraum und Farbtemperatur (nach 1931 CIE), Gamma-Wert, Histogramm, ursprüngliche Farbtiefe, globaler Transparenzwert, Zeitpunkt der letzten Änderung und Anzahl der signifikanten Bits. Außerdem können sie unkomprimierten oder komprimierten Text enthalten. Neben diesen sind auch private Blöcke möglich, die nur von speziellen Anwendungen erzeugt und ausgewertet werden. [7]

Ein gutes Beispiel ist die Anwendung von PNG im medizinischen Bereich, z.B. in einem Krankenhaus. Hier könnte zu jeder Röntgenaufnahme ein Block definiert werden, der Angaben über

die verwendeten Aufnahmegeräte
die Strahlendosis
den Befund
die Krankenversicherungsnummer des Patienten
und ähnliches

in einem eigens dafür spezifizierten Block speichert. Werden nun solche Bilder verschickt kann jeder sie mit jedem PNG-Dekoder anzeigen, aber nicht unbedingt die Zusatzinformationen lesen. Diese könnten sogar noch verschlüsselt sein...

`IHDR` - der Startblock

Start-Block, IHDR (Image Header)

DWORD DWORD DWORD DWORD BYTE BYTE BYTE BYTE BYTE DWORD

DataLength

Type

Crc

Längen-
angabe Block-
Typ Breite Höhe Bit-
Tiefe Farb-
typ Kompres-
sion Filter Verschach-
telung CRC-32 über
Typ und Daten

Dieser Block muß am Anfang (nach der Signatur) stehen und darf nur einmal vorkommen. Hier werden elementare Bildparameter angegeben.
Breite und Höhe werden in Pixeln angegeben. Die Bittiefe gibt die Länge der Bitmuster im IDAT-Block an. Bitmuster können sowohl Farbwerte (RGB), Graustufen, Alpha-Werte als auch Paletteneinträge bedeuten je nach Farbtyp. Des weiteren enthält der Start-Block Angaben über die verwendete Kompression, benutzte Filter sowie das Verschachtelungs-Schema.

Farbtyp, gesetzte Bits bezeichen:

Bit 1    Bild mit Palette

Bit 2    Farbe wird statt Graustufen benutzt

Bit 3    Alpha-Kanal wird benutzt.

Desweiteren wird im Start-Block ein Byte für die Länge jedes Bitmusters übertragen. Diese Muster, welche entweder einen Graustufenwert, einen Rot-, Grün-, Blauwert oder einen Paletteneintrag bezeichnen, dürfen 1, 2, 4, 8 und 16 Bit lang sein. So können bei kleinen Bitlängen immer mehrere Muster in einem Byte übertragen werden, ohne komplizierte Umrechnungen zu erfordern, da Muster nie über Bytegrenzen hinaus ragen können.

Farbtyp	Palette?	Farbe?	Alpha- Kanal?	erlaubte Bittiefen	Jedes Bitmuster ist...
0	-	-	-	1, 2, 4, 8, 16	...ein Graustufenwert
2	-	ja	-	8 oder 16	...ein RGB-Triplett
3	ja	ja	-	1, 2, 4 oder 8	...ein Paletteneintrag. Ein `PLTE`-Block wird erwartet. Die Bittiefe gibt hierbei nicht die Genauigkeit der Farben an, nur die Länge eines Paletteneintragwertes.
4	-	-	ja	8 oder 16	...ein Graustufenwert gefolgt von einem Alpha-Wert
6	-	ja	ja	8 oder 16	...ein RGB-Triplett, gefolgt von einem Alpha-Wert

Paletteneinträge sind immer entweder 8-Bit-Graustufen oder 24-Bit RGB-Triple.

Enkoder müssen Bilder mit Bittiefen die im gewählten Farbtyp nicht erlaubt sind in eine erlaubte Bittiefe umrechnen. Üblicherweise werden die Muster dafür in der nächsthöheren erlaubten Bitlänge gespeichert. Dabei werden die originalen Bits als höherwertige Bits gespeichert. Die niederwertigen Bits können mit verschiedenen Methoden aufgefüllt werden. Die originale Bittiefe sollte in einem sBIT-Block gespeichert werden.

Die Spezifikation definiert dabei für Kompression

  0 = "Deflate"-Algortihmus

Filter

  0 = Filterset nach Spezifikation verwendet

Verschachtelung

  0 = keine

  1 = Adam-7-Verschachtelung

`PLTE` - der Palettenblock

Paletten-Block, `PLTE` (Palette) 1 bis 256 Einträge....
DWORD	DWORD	BYTE	BYTE	BYTE	...				DWORD
DataLength	Type	Red	Green	Blue		R	G	B	Crc
		0 = Schwarz	0 = Schwarz	0 = Schwarz
Längen- angabe	Block-Typ	255 = Rot	255 = Grün	255 = Blau					CRC-32

Bei indizierten Bildern (Farbtyp 3) muß ein Palettenblock vorkommen. Die Längenangabe muß durch 3 teilbar sein (es gibt keine Graustufenpaletten), sonst muß ein Fehler gemeldet werden. Die Daten des Palettenblocks kennzeichnen als RGB-Tupel die Farbwerte für die einzelnen Palettenfarbe, beginnen bei Farbe 0. Es müssen alle im Bild vorkommenden Farben definiert werden, es dürfen auch noch weitere, unbenutzte Farben definiert werden.
Bei Bildern anderer Farbtypen gibt die Palette laut Spezifikation an, auf welche Farben das Bild reduziert werden soll, falls die anzeigenden Systeme nicht alle Farben darstellen können. Es darf nur ein Palettenblock vorkommen.

`IDAT` - der Pixeldatenblock

Daten-Block, `IDAT` (Image Data)
DWORD	DWORD	BYTE	BYTE	BYTE	...	BYTE	DWORD
DataLength	Type	verschachtelter und komprimierter Datenstrom der Bildpunkte...					Crc
Längen- angabe	Block-Typ						CRC-32 über Typ und Daten

Der Bilddatenblock ist der Kern der PNG-Spezifikation. Hier werden nun die wirklichen Pixel übertragen.
Vom Konzept her ist ein PNG Bild immer ein rechteckiges Pixel-Datenfeld. Pixel werden in Bildzeilen von links nach rechts übertragen, Bildzeilen von oben nach unten. Die Größe jedes Pixels ist durch die Bittiefe im Startblock angegeben.
Bei indizierten Bildern ist jeder Pixel der Verweis auf einen Paletteneintrag der vorab mitgeschickten Palette. Die Bittiefe gibt hier die maximale Farbanzahl der Palette, nicht die Farbtiefe innerhalb der Palette an.
Graustufenbilder bestehen nur aus einem Wert pro Pixel. Null steht für Schwarz und der größte Wert der gegeben Bittiefe repräsentiert Weiß.
Ein "Truecolor" Pixel besteht aus drei Werten: Rot, Grün und Blau. Null ist jeweils schwarz, der größte Wert die angegebene Farbe. Die Bittiefe bestimmt die Genauigkeit der Komponenten, nicht des gesamten Pixels. Graustufen- und Farbpixel können zusätzlich noch einen Alpha-Wert der gleichen Bittiefe enthalten.
Pixel werden immer in Bildzeilen gepackt, ohne Pixel zu verschwenden. Bei Bittiefe 2 etwa werden je 4 Pixel in einem Byte übertragen. Pixel mit einer kürzeren Bittiefe als acht ragen nie über die Bytegrenzen hinaus. Die Pixel, die am weitesten links stehen kommen in die höchstwertigsten Bits des Trägerbytes. Die Länge der Bildzeilen steht wegen Wahl der Bilddimensionen und des Verschachtelungs-Schema vorab fest.
Sollen z.B. 11 4-Bit-Pixel übertragen werden, so werden die ersten 10 Pixel in 5 Bytes übertragen, der letzte Pixel wird in den höchstwertigsten Bits des sechsten Bytes übertragen. Die niederwertigen Bits werden verschwendet und bleiben unspezifiziert.
Beim Komprimieren wird vor jeder Bildzeile ein Byte für den Filtertyp gehängt. Dieser Datenstrom wird im "zlib"-Format auf einen oder mehrere IDAT-Blöcke verteilt. IDAT-Blöcke müssen ohne Unterbrechung durch andere Blocktypen aufeinander folgen. Selbst Prüfsummen oder andere Steuerdaten können auf mehrere IDAT-Blöcke verteilt sein. Der verwendete Kompressionsalgorithmus wird im Start-Block angegeben werden. PNG spezifiziert derzeit nur den Wert 0 für "zlib"-Kompression.

Vierte Schicht: zlib-Strom wird in `IDAT`-Blöcke geschrieben

Der zlib-Datenstrom wird in einen oder mehrere IDAT-Blöcke geschrieben. Es gibt dabei weder einen Zusammenhang zwischen dem Bild und der Aufteilung in IDAT-Blöcke, noch zwischen dem zlib-Datenstrom und der Verteilung auf IDAT-Blöcke. Selbst zlib-Prüfsummen können auf mehrere IDAT-Blöcke verteilt werden.

`IEND` - der Ende-Block

Ende-Block, `IEND` (Image trailer)
DWORD	DWORD	DWORD
DataLength	Type	Crc
Längen- angabe	Block-Typ	CRC-32 über Typ und Daten

Der Ende-Block darf nur einmal vorkommen und enthält keine Daten. Er muß am Ende der PNG-Datei stehen. Alle weiteren Daten werden ignoriert.

Zusatzblöcke

Blöcke, die vor der Palette stehen müssen, falls eine vorhanden ist.

`sBIT` Significant bits

Wird z.B. ein Bild mit 5 Bit Auflösung als PNG gespeichert, so muß es in eine PNG-kompatible Bittiefe umgerechnet werden. Um keine Informationen zu verlieren, werden diese 5-Bit-Werte als 8-Bit-Werte gespeichert. Dabei werden die höchstwertigsten 5 Bits mit den Bilddaten gefüllt, die letzten drei Bits werden mit verschiedenen Verfahren gefüllt.
Setzt man die letzten drei Bits einfach auf Null, wird das Bild etwas zu dunkel angezeigt. Rechnet man alle Werte linear in 8-Bit-Werte um, so dauert dies ziemlich Lange. Ein recht guter Mittelweg ist das auffüllen der letzten k Bits mit den ersten k Bits des Original-Bitmusters. Das geht recht schnell und die Abweichung von linearer Skalierung ist nie größer als eins.
Dekoder können diesen sBIT-Block nun auswerten, um durch Verschieben der Bitmuster wieder die ursprünglichen Farbtiefe zurückzurechnen.

`gAMA` Image gamma

Beim Erzeugen eines Bildes, sei es am Bildschirm oder eingescannt, spielt die Beleuchtungssituation eine große Rolle für die Helligkeit und den Kontrast im Bild. In diesem Gamma-Block sollten nun diese Parameter in der Farbtheorie als Gamma-Wert bekannt gespeichert werden.
Dekoder sollten diesen Wert auswerten und mit dem Gamma-Wert der verwendeten Plattform verrechnen um die Helligkeit und den Kontrast wieder exakt wie beim Erstellen anzuzeigen. [12]

Ein Test mit PNG-Bildern, die Gamma-Informationen enthalten, ist zu finden unter:
http://www.w3.org/Graphics/PNG/all_seven.html

`cHRM` Primary chromaticities

Mit diesem Block kann der Enkoder, quasi als Ergänzung zum Gamma-Block auch noch die Farbtemperatur der verwendeten Rot- Grün- und Blautöne der Grundfarben definieren und zwar nach "1931 CIE x,y "- Standard. [15]

Blöcke, die nach der Palette stehen müssen, falls eine vorhanden ist.

`hIST` Image histogram

Dieser Block darf nur vorkommen, wenn ein Palettenblock vorkommt. Für jeden Paletteneintrag spezifiziert er dabei mit zwei Bytes die Häufigkeit mit der die Palettenfarbe im Bild vorkommt. Ein Dekoder könnte dies zwar "auszählen" jedoch sahen die Autoren des PNG-Formats es als sinnvoller an, diese Verteilung nur einmal auszuzählen und dann für alle immer mitzuschicken, um Rechenzeit zu sparen.
Mit Hilfe dieser Farbverteilung kann nun ein Dekoder auf einer Plattform mit weniger darstellbaren Farben als den in der Palette angegebenen, das Bild auf die am häufigsten vorkommenden Farben reduzieren ("dithern").

`bKGD` Background color

Hiermit kann eine Hintergrundfarbe für das Bild angegeben werden.

`tRNS` Transparency

Analog zum GIF-Format können hier für beliebig viele Palettenwerte oder einen RGB-Farbton Alpha-Werte angegeben werden. So können GIF-Bilder oder andere Bilder mit nur sehr wenigen transparenten Farben platzsparender gespeichert werden.

Blöcke, die vor den IDAT-Blöcken stehen müssen

`oFFs` Image offset

Soll das Bild gedruckt werden, kann dieser Block eine Position auf dem Blatt angeben oder bei großen Monitoren die Position auf dem Bildschirm. Angaben erfolgen wahlweise in Pixel oder Mikrometern mit je vier Bytes Auflösung für X- und Y-Koordinate.

`pCAL` Calibration of pixel

Werden physikalische Meßwerte als zweidimensionales Bild gespeichert, so wäre es wünschenswert, die Relation zwischen Farbwert und Meßwert zu kennen. Dieser Block speichert genau diese Relation ab. Dabei stehen verschiedene vordefinierte Gleichung wie lineare Skalierung oder exponentielle Umwandlung zur Verfügung, um aus Pixelwerten wieder physikalische Meßwerte zu machen.

`pHYS` Physical pixel dimensions

Dieser Block gibt die physikalische Größe der Pixel an. Ein Quadrat von 10 cm Kantenlänge auf dem BIldschirm des Erstellers hat dann auch auf jedem Bildschirm, auf dem es betrachtet wird, wieder 10 cm Kantenlänge, vorausgesetzt der Bildschirm ist groß genug und der Dekoder wertet diese Information aus.

`sCAL` Physical scale of image subject

Bei Stadtplänen, astronomischen Karten oder Aufnahmen aus dem medizinischen Bereich ist es oft nötig, die Größe des vermessenen oder fotographierten Objekts zu kennen, beispielsweise um den Maßstab der Straßenkarte zu errechnen (mit Hilfe des pHYS-Blocks).

Blöcke, die überall stehen dürfen

`tIME` Image last-modification time

Enkoder sollten diese Zeitmarke als Zeit der letzten Bearbeitung verwenden. Da das Jahr mit zwei Bytes gespeichert wird, ist dieser Block voll Jahr-2000-kompatibel.

`tEXt` Textual data

Hier stehen nun unkomprimiert ein Schlüsselwort, ein 00-Byte sowie eine Zeichenkette. Diese benötigt kein 00-Byte, da die Länge sich aus der Blocklänge bestimmt. Schlüsselwörter sind im PNG-Standard spezifiziert. tEXt-Blöcke enthalten Informationen über den Autor des Bildes, verwendete Software, rechtliche Hinweise...

`zTXt` Compressed textual data

Texte ab 1KB, speziell längere rechtliche Hinweise sollten komprimiert als zTXt übertragen werden. Auch hier werden Schlüsselwörter, 00-Byte und Zeichenkette gespeichert. Allerdings ist das Datenfeld jedes zTXt-Blocks in einen eigenen zlib-Datenstrom verpackt.

`gIFg` GIF Graphic Control Extension

GIF-Dateien können Kontrollwerte enthalten die PNG aus Kompatibilitätsgründen in diesem Block mitspeichern kann. Sie steuern das Verhalten des Dekoders nach dem Anzeigen des Bildes: Auf Benutzereingabe oder eine bestimmte Zeit lang warten.

`gIFx` GIF Application Extension

Hier können die GIF-Erweiterungsblöcke eingelagert werden. So geht keine Information verloren.
gIFg und gIFx dienen wohl hauptsächlich dazu, Anwendern die Benutzung von PNG schmackhaft zu machen, da sie die Bilder ja ohne ein einziges Bit zu verlieren wieder als GIF zurückkonvertieren könnten.

Namenskonvention

Alle festgelegten Block-Typen sind eindeutig über ihre "32bittige" Typkennung zu identifizieren, die die Form einer lesbaren ASCII-Vierergruppe hat. Dabei wird für jeden Buchstaben das fünfte Bit für spezielle Markierungen benutzt. Dieses Bit wiederum entscheidet über Groß- und Kleinbuchstaben im ASCII-Standard, so daß sogar Menschen leicht diese Bits "auswerten" können.
Diese vier Bits haben folgende Bedeutung:

Zusatz-Bit (Bit 5 des ersten Bytes)
0 (Großbuchstabe) = kritischer Block
1 (Kleinbuchstabe) = zusätzlicher Block
Zusätzliche Blöcke können ohne weiteres ignoriert werden. Einfache Dekoder können so jedes Bild korrekt anzeigen, ohne viele Blöcke zu kennen.

Privates Bit (Bit 5 des zweiten Bytes)
0 (Großbuchstabe) = öffentlicher Block nach PNG-Spezifikation
1 (Kleinbuchstabe) = privater Block
Dieses Bit muß nicht abgefragt werden, verhindert aber, daß private Blöcke den gleichen Namen wie aktuelle oder zukünftige öffentliche Blöcke erhalten können.

Reserviertes Bit (Bit 5 des dritten Bytes)
0 (Großbuchstabe) = konform zur PNG-Spezifikation
Dieses Bit hat noch keine spezielle Funktion, bleibt aber für Erweiterungen nutzbar. Dekoder müssen auch PNGs mit gesetztem "Reservierten Bit" anzeigen können, da zukünftige PNG-Erweiterungen dies evtl. spezifizieren.

"Kopieren erlaubt"-Bit (Bit 5 des vierten Bytes)
0 (Großbuchstabe) = Block darf nicht einfach kopiert werden, er hängt von kritischen Blöcken ab, z.B. hIST
1 (Kleinbuchstabe) = Block darf einfach kopiert werden, z.B. tEXt
Dieses Bit ist für PNG-Editoren gedacht: Sie können so jede PNG-Datei lesen und pro Block entscheiden was zu tun ist: Ist das "Kopieren erlaubt"-Bit gesetzt, so kann der Block in jedem Fall einfach ohne Veränderungen in die Zieldatei geschrieben werden. Ist das Bit nicht gesetzt, so hängt der Inhalt von den Bilddaten (kritischen Blöcken) ab. Entweder der Editor errechnet diesen Block korrekt, da er ihn erkannt hat, oder er läßt ihn ganz aus.
Dieses Bit sollte für kritische Blöcke immer ungesetzt sein.

Beispiel

Angenommen, es gäbe einen Block namens "bLOb".

   bLOb <-- 32 Bit Block-Typkode als ASCII-Text
   ||||
   |||+- "Kopieren-Erlaubt"-Bit gesetzt   (Kleinbuchstabe; Bit 5 = 1)
   ||+-- Reserviertes Bit nicht gesetzt   (Großbuchstabe; Bit 5 = 0)
   |+--- Privates Bit nicht gesetzt       (Großbuchstabe; Bit 5 = 0)
   +---- Zusatz-Bit gesetzt               (Kleinbuchstabe; Bit 5 = 1)

Dieser Block wäre demnach ein PNG-spezifizierter Zusatz-Block der einfach kopiert werden darf.

Die Block-Namens-Konvention erlaubt eine flexible Erweiterung des PNG-Formats. Selbst die wildesten Erweiterungen führen nur dazu, daß sich im schlimmsten Fall für den En-/Dekoder unbekannte Blöcke in der Datei befinden. Sind sie als zusätzlich markiert kann das Bild trotzdem korrekt angezeigt werden. PNG verwendet keine Versionsnummern, da sie oft dazu führen, das z.B. Betrachtungsprogramme das Anzeigen einer Datei mit zu hoher Versionsnummer verweigern (z.B. bei GIF als 89a eingeführt wurde). Bei PNG müssen Dekoder nur prüfen ob sie fähig sind, alle wichtigen (kritischen) Blöcke auszuwerten. Das genügt dann völlig um das Bild rudimentär anzuzeigen.
Zusatzblöcke können nicht von anderen Zusatzblöcken sondern immer nur von kritischen Blöcken abhängen. Ist es dennoch unvermeidbar z.B. bLOb von tEXt abhängig zu machen, so speichert man einfach die CRC-Prüfsumme des tEXt-Blockes im bLOb-Block. So können Editoren auswerten, ob tEXt unverändert geblieben ist, bzw. ob bLOb noch korrekt von tEXt abhängt.

Sicherheitsaspekte

PNG hat eine sicherheitskritische Schwachstelle: Sobald Textzeichen auf die Standardausgabe übertragen werden, müssen Dekoder darauf achten keine Steuerzeichen mit auszugeben. Auch müssen Dekoder darauf achten, daß ungültige Blocklängenangaben und Berechnungen keinen Überlauf verursachen.

eigene PNG-Tests

Im folgende habe ich verschiedene Typen von Bildern zunächst als GIF optimiert und die Dateigröße gemessen. Die JPG-Bilder wurden mit Qualitätsstufe 75% erstellt. Die PNG-Bilder mit "gif2png" von der PNG-Heimatseite.

	GIF	GIF*	PNG	PNG*	JPG	JPG*
Netzgrafik	26,8%	27,8%	Bester: 25,5%	30,2%	51,7%	54,6%
s/w	2,3%	2,3%	Bester: 1,6%	2,4%	12,3%	11,7%
Grafik	2,9%	3,2%	Bester: 2,4%	3,2%	38,4%	33,5%
Foto	43,9%	45,9%	39,2%	44,8%	16,5%	Bester: 16,4%

*mit Verschachtelung

Generell komprimiert PNG etwas besser als GIF. Bei verschachtelten Bildern nimmt die Kompressionsrate stärker ab als bei GIF. JPG komprimiert verschachtelte Bilder sogar meist besser. Zu beachten ist außerdem der dramatische Unterschied zwischen Fotos und Grafiken in der Kompression. Trotz PNG stellt sich immer noch die Frage: Welches Format für welches Bild?
Faustregel: JPG nur für Fotos im Datennetz, PNG für alles andere.

	Testbilder: Originalgröße: 88x31 Originalgröße: 468x60
	Legende: GIF; GIF mit Verschachtelung; PNG; PNG mit Verschachtelung; JPG; JPG mit Verschachtelung;

Bild 15: Netzgrafik

	Testbilder: Originalgröße: 1174x888 Originalgröße: 1280x1621
	Legende: GIF; GIF mit Verschachtelung; PNG; PNG mit Verschachtelung;

Bild 16: Grafik

	Testbilder: Originalgröße: 640x480
	Legende: GIF; GIF mit Verschachtelung; PNG; PNG mit Verschachtelung; JPG; JPG mit Verschachtelung;

Bild 17: Foto

Stand der Dinge

Seit dem Erscheinen der 4.x-Versionen der beiden großen Stöberer-Hersteller besitzen jetzt 90% aller Stöberer PNG-Unterstützung, wenn auch oft nur wenige Fähigkeiten genutzt werden (fehlende Alphakanäle,...).
Zahlreiche Bildeditoren und -betrachtungsprogramme besitzen ebenfalls die Möglichkeit, PNG-Bilder zu bearbeiten oder anzuzeigen.
Microsoft Office 97 benutzt PNG als internes Grafikformat, VRML 2.0 spezifiziert JPG und PNG als verwendete Pflichtformate.
Das Mozilla-Projekt arbeitet heftig an PNG-Unterstützung. Immer mehr Editoren erlauben kein GIF mehr, wegen der zu zahlenden Lizenzgebühren.

Zusammenfassung

Mit PNG sollte ein GIF-Nachfolgeformat spezifiziert werden, um den Lizenzgebühren aus dem Weg zu gehen. Doch während der Entwicklung ist PNG weit darüber hinaus gewachsen. Mit seinem Alpha-Kanal und seinem Verschachtelungsschema bietet es sich als ideales Format für Datennetzanwendungen an. Durch die verlustfrei Kompression, die Gamma-Korrekturmöglichkeiten und die enorme Farbtiefe (bis zu 16 Bit) kann PNG nun aber auch ideal als plattformunabhängiges Format zum Archivieren von Bildern aller Art. Durch die Blockstruktur des Dateiaufbaus können zusätzliche Funktionen nach Belieben hinzugefügt werden.

Literatur

verwendet:

[1] Intellectual Property Network (Patente im Volltext) (siehe: http://patent.womplex.ibm.com/ )

[2] Heimatseite: Portable Network Graphics (siehe: http://www.cdrom.com/pub/png/ )

[3] Heimatseite: zlib (siehe: http://www.cdrom.com/pub/infozip/zlib/ )

[4] Greg Roelofs: History of the Portable Network Graphics (PNG) Format. Linux Gazette (siehe: http://www.linuxgazette.com/ ), Januar 1997

[5] Ron Baalke: a short history of LZW (siehe: http://www-cmpo.mit.edu/met_links/resources/LZW_Algorithm_Patents)

[6] World Wide Web Consortium (W3C) (siehe: http://www.w3.org/ ): PNG Specification Version 1.0 (siehe: http://www.w3.org/Graphics/PNG/), 14 October 1996

[7] Manfred Bertuch: Bits im Bilde. Heins Heise Verlag. September 1996, S. 116 ff (siehe: http://www.heise.de/ix/artikel/1996/09/116/ )

[8] Compression FAQ (siehe: http://www.faqs.org/faqs/compression-faq/ )

[9] P. Deutsch, J-L. Gailly: ZLIB Compressed Data Format Specification version 3.3 [RFC 1950] (siehe: ftp://sunsite.doc.ic.ac.uk/rfc/rfc1951.txt )

[10] P. Deutsch, J-L. Gailly: DEFLATE Compressed Data Format Specification version 1.3 [RFC 1951] (siehe: ftp://sunsite.doc.ic.ac.uk/rfc/rfc1951.txt )

[11] Chris Lilley: Not Just Decoration: Quality Graphics for the Web (siehe: http://www.w3.org/Conferences/WWW4/Papers/53/gq-trans.html )

[12] Charles Poynton: Gamma and Color FAQs (siehe: http://www.inforamp.net/~poynton/Poynton-colour.html )

weiterführende Literatur:

[13] Alles über Prüfsummen (siehe: ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt)

[14] Zahlreiche PNG- und zlib-Bibliotheken mit Quellcode (siehe: http://www.cdrom.com/pub/png/pngcode.html)

[15] International Color Consortium (siehe: http://www.color.org/ )

[16] sRGB Heimatseite (siehe: http://www.sRGB.com/ )

[17] Dateiformate (siehe: http://www.wotsit.org/)

[18] Fachbegriffe (siehe: http://wombat.doc.ic.ac.uk/foldoc/index.html)

Max Völkel, 1. Februar 1999

Proseminar: Redundanz