Laßt Bilder sprechen, lautet die Devise, schließlich ist ein Sachverhalt durch nichts so effektiv zu klären wie durch eine gute Anschauung. Und tatsächlich war der Stellenwert visueller Kommunikation nie höher. Entsprechend groß ist der Anteil grafischer sowie bildlicher Information in Multimedia-Anwendungen und im World Wide Web. Daß ein Großteil der im WWW kursierenden Bilddaten weniger der Informierung und Orientierung dient, sondern eher in die Kategorie "visuelles Marketing" -- um nicht zu sagen "Marktgeschrei" -- gehört, ändert daran nichts.
Ein Format zur Speicherung und Übertragung von Bildinformationen muß in erster Linie möglichst kompakt sein. Verlustfreie Kompressionsalgorithmen und die noch stärker komprimierenden verlustbehafteten Verfahren sollen diesem Anspruch gerecht werden. Strenggenommen gehört auch GIF zu den verlustbehafteten, da es ein Farbbild auf 256 verschiedene Farbtöne reduziert. Die Computerdisplays der anvisierten Benutzerkreise konnten lange Zeit nicht mehr als 256 verschiedene Farben darstellen; eine größere Farbtreue hätte daher die Datenmenge erhöht, ohne von Nutzen zu sein.
Netze und andere langsame Übertragungsmedien stellen weitere, ebenfalls in GIF realisierte Anforderungen: Das Bild sollte sich schon während der Übertragung dekodieren (Streamability) und so anzeigen lassen, daß sein ungefährer Inhalt möglichst früh erkennbar wird (progressive Display). Die Übertragung kann dann gegebenenfalls nach der Hälfte oder früher abgebrochen werden. Wie jeder Web-Surfer weiß, realisiert GIF dies, indem es die Bildzeilen nicht in ihrer originalen Abfolge, sondern nach einem 4stufigen Interlace-Schema überträgt.
In der Folge wurde GIF zum wichtigsten Format für Bilddaten im World Wide Web. Jeder Button, jedes Logo, Skizzen, Abbildungen und Fotos wanderten als GIFs durch die Netze. Entsprechend groß war die Entrüstung im WWW und im Usenet, als der GIF-Urheber CompuServe Ende 1994 darauf hinwies, daß GIF-Implementierungen nicht frei von Rechten Dritter seien ("horror ... outrage ... indignation ..."). CompuServe unternahm diesen Schritt nach Diskussionen mit Unisys, von dem das in GIF eingesetzte LZW-Kompressionsverfahren stammt.
Bereits zwei Monate später stellte Thomas Boutell ein Format vor, das zum einen frei von Besitzrechten und geschützten Algorithmen ist und zum anderen den gestiegenen technischen Anforderungen gerecht wird. Das "Portable Network Graphics"-Format (PNG, gesprochen "ping") war geboren. CompuServes Versuch, diese Initiative zu vereinnahmen und PNG-Bestandteile in ein eigenes Format namens GIF24 zu übernehmen, ist bis heute ohne Resultat geblieben. Inzwischen hat man PNG in die CompuServe-Software (WinCIM V 2.0.1) eingebaut. Einen Einblick in den Working Draft der PNG-Spezifikation gibt das W3-Konsortium.
Heute stellen Grafikdisplays vor allem auf dem PC-Sektor mit ihren 65 000 oder mehr darstellbaren Farben größere Anforderungen an ein Grafikformat. Als wesentliche Neuerung kennt PNG neben dem 256farbigen Palettenmodell (indexed-mapped Images) verschiedene Graustufen- und Echtfarbformate mit 5 bis 16 Bit Auflösung pro Farbkomponente (Sample). Auch eine optionale Transparenzkomponente (Alpha-Kanal) ist vorgesehen. Mit der Möglichkeit, PNG-Dateien mit Angaben zum Gamma-Faktor (Abweichung bezüglich des Helligkeitswertes) und zur Farbtemperatur (das Verhältnis von Blau zu Rot) zu versehen, kommt man professionellen Ansprüchen entgegen. Diese Werte versetzen den Empfänger in die Lage, seine Displayhardware -- vorausgesetzt, sie ist kalibrierbar -- an die Gegebenheit des Urhebers anzupassen, so daß das Bild mit identischem Kontrast-/Helligkeitswert und Farbverlauf erscheint. Die GIF-Features, mehrere Bilder oder Animations-Sequenzen speichern zu können, sind in der aktuellen Version**1.0 von PNG nicht realisiert.
Eine PNG-Datei beginnt immer mit einer Signatur, der eine Anzahl von Blöcken (Chunks) fester und variabler Länge folgen. Obligatorisch sind der Header-, der Daten- und der End-Chunk, bei indizierten Formaten natürlich auch der Paletten-Chunk. Letzterer muß hinter dem Header- und vor dem Daten-Chunk angeordnet sein. Jeder Block beginnt mit einer Längenangabe, gefolgt vom Typ-Identifier, den eigentlichen Daten und einem abschließenden CRC (Cyclic Redundancy Check) über das Typ- und Datenfeld.
Der Header-Chunk enthält die wesentlichen Bildparameter wie Breite und Höhe, die Bits pro Pixel oder pro Sample (beziehungsweise Farbkomponente) sowie Angaben zum Farbtyp, der verwendeten Kompression, des eingesetzten Filters und des Interlace-Schemas. Aus den Paletteneinträgen in Form von RGB-Tripeln besteht das Datenfeld des Paletten-Chunk; es kann jede Länge von 3 bis 768 (256 x 3) Byte annehmen. Die eigentlichen Bildinformationen sind entweder zeilenweise, mit dem ersten Bildpunkt oben links beginnend, abgelegt oder nach dem bislang einzigen festgelegten Interlace-Schema Adam7 [#Adam7 (siehe weiter unten)] organisiert. Schließlich markiert der End-Chunk das Ende der Datei, weitere Daten enthält er nicht.
Diese drei beziehungsweise vier Datenblöcke sind "Critical Chunks", die jeder PNG-Reader auswerten muß. Nicht obligatorisch sind die "Ancillary Chunks" mit Zusatzinformationen, die in einer PNG-Datei auftauchen könnnen und nicht notwendigerweise ausgewertet werden müssen. PNG V1.0 definiert 10 Typen von Hilfs-Chunks, die Angaben machen wie Hintergrundfarbe, überdeckter Bereich im Farbraum und Farbtemperatur (nach 1931 CIE), Gamma-Wert, Histogramm, ursprüngliche Auflösung, globaler Transparenzwert, Zeitpunkt der letzten Änderung und Anzahl der signifikanten Bits. Außerdem können sie unkomprimierten oder komprimierten Text enthalten. Neben diesen "special-purpose Public Chunks" sind auch "Private Chunks" möglich, die nur von speziellen Anwendungen erzeugt und ausgewertet werden.
Alle festgelegten Chunk-Typen sind eindeutig über ihre "32bittige" Typkennung zu identifizieren, die die Form einer lesbaren ASCII-Vierergruppe hat. Die nicht definierten privaten Chunks müssen natürlich abweichende Kennungen erhalten. Eine schnelle Identifizierung der zugehörigen Chunk-Gruppe erlaubt Bit 5 der ersten beiden Bytes, das in ASCII zwischen Groß- und Kleinbuchstaben unterscheidet. Ist das fünfte Bit des ersten Bytes gleich Null (Upper Case Letter), handelt es sich um einen der vier "Critical Chunks", ist es gleich 1 (Lower Case Letter) um ein "Ancillary Chunk". Letztere unterscheiden sich wiederum im fünften Bit des zweiten Bytes: bit5 = 0 bedeutet "public" und bit5 = 1 bedeutet "private". Das fünfte Bit des dritten Bytes ist reserviert, das des vierten Bytes ist das Safe-to-Copy-Bit.
PNG sieht einen linearen oder einen progressiven Bildaufbau vor. Letzterer basiert auf einem zweidimensionalem Interlace-Schema mit sieben Durchgängen. Nach seinem Autor Adam M. Costello heißt es Adam7. Kleine Schriften sind bei Adam7 doppelt so schnell lesbar wie bei GIF, das heißt häufig bereits nach den ersten 25 Prozent der Bilddaten gegenüber 50 Prozent bei GIF. Der erste Durchlauf überträgt lediglich ein 64stel des gesamten Bildes. Dabei kommt nicht etwa jede 64ste Zeile zum Zuge, sondern jeder Bildpunkt oben-links innerhalb eines Rasters aus quadratischen Feldern mit 8 x 8 Bildpunkten. Im zweiten Durchlauf kommt ein weiteres 64stel an die Reihe, beim dritten ein 32stel und so weiter. Nach dem sechsten Durchgang sind alle geraden Zeilen komplett übertragen. Der letzte und siebte Pass ergänzt alle ungeraden Zeilen.
Das bislang einzige in PNG vorgesehene Kompressionsschema arbeitet in zwei Schritten. Als Kompensation für den Verzicht auf den von GIF verwendeten effizienteren Algorithmus kann im ersten Schritt eine Filterung vorgenommen werden, die absolute Pixelwerte durch ihre Differenz zum Vorgänger innerhalb derselben Bildzeile oder zu Nachbarn in anderen Bildzeilen ersetzt. Der zweite Schritt ist immer der auch in PKZIP verwendete, von Phil Katz entwickelte Deflate-Algorithmus, eine Variation von LZ77, den Lempel, Ziv, Cohen und Eastman 1981 patentierten. Dieser verwendet ein variables Gleitfenster und sortierte Hash-Tabellen, um Datenmuster zu identifzieren und nach dem Huffman-Verfahren zu kodieren. In PNG kommt eine Variante ohne sortierte Hash-Tabellen zum Einsatz, die keine Patente oder lizenzpflichtige Algorithmen berührt. Deflate-komprimierte Daten werden im Zlib-Format (siehe [#lit03 [3]]) im Datenfeld des IDAT-Chunks abgelegt. Für eine PNG-Kompression vom Typ 0 -- die einzig definierte -- muß das "Zlib Compression Method"-Feld die Methode 8, also Deflate-Kompression, spezifizieren. Das LZ77-Fenster darf nicht größer als 32 K sein (siehe [#lit02 [2]]).
Folgen mehrere IDAT-Chunks aufeinander, können die Grenzen zwischen den Chunks beliebig innerhalb des Zlib-Datenstroms liegen. Selbst die 4 Byte umfassende Zlib-Checksumme kann auf mehrere IDAT-Chunks verteilt sein. Auf der anderen Seite wirkt die Struktur des Bildes, etwa die Bildzeilen, nicht auf die Zlib-Struktur. Sämtliche Bilddaten sind in einem einzigen, durchgängigen Zlib-Datenstrom zu kodieren.
Ohne nennenswerten Rechenaufwand zu verursachen, macht die LZ77-Kompression die vorgeschaltete Filterung effizienter. Fünf verschiedene Filtern sind möglich. Der Subfilter bezieht die Differenz auf den Vorgänger links vom aktuellen Pixel. Bei Multi-Sample-Pixel, zum Beispiel bei einem RGB-Pixel, wird jede Farbkomponente auf die entsprechende des Vorgängers bezogen. Der Up-Filter bezieht die Differenz auf das in der darüberliegenden Zeile befindliche Pixel. Der Average-Filter berechnet die Differenz auf Basis des Durchschnittwertes der Pixel links und oberhalb des aktuellen Pixels. Der Paeth-Filter nutzt eine lineare Funktion und den ähnlichsten Punkt links, oberhalb oder links-oberhalb des aktuellen Pixels als Bezugswert. 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 interlaced 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 "Streamability", also die Möglichkeit der kontinuierlichen Dekodierung während der Datenübertragung.
Für Bilder vom Datentyp 3, das heißt für 256farbige Palettenbilder, ist Filterung in der Regel uneffektiv. Die Autoren empfehlen hier den Filtertyp 0. Keine Filterung empfielt sich auch bei Farbtiefen kleiner als 8 Bit. Aufgrund des kleinen Wertebereichs ist der Gewinn gering. Ein Decoder mit fest eingestelltem Filtertyp sollte den Paeth-Filter verwenden. Er ist im allgemeinen am effektivsten. Decoder, 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.
Im Verlauf der nächsten Monate dürfte die Bedeutung von PNG weiter wachsen. Bereits jetzt sind PNG-taugliche Browser und Tools für zahlreiche Betriebssysteme und Plattformen erhältlich. Spätestens dann, wenn auch die führenden Grafikprogramme PNG als Ausgabeformat aufnehmen, wird es die Rolle des plattformübergreifenden Netzwerkstandards übernehmen.
MANFRED BERTUCH
ist langjähriger Redakteur der c't und arbeitet als freier Autor für die Themengebiete Grafik und Multimedia in Berlin.
Literatur
[1] Thomas Boutell, Tom Lane (Editors); PNG (Portable Network Graphics) Specification; The World Wide Web Journal; O'Reilly & Associates; Sebastopol 1996, S. 221
[2] L. Peter Deutsch; Deflate Compressed Data Format Specification Version 1.3;
[3] L. Peter Deutsch, Jean-Loup Gailly; ZLIB Compressed Data Format Specification Version 3.3;
[4] Fred Hantelmann; Dichte Standards; Videokompression mit JPEG und MPEG; iX 3/92, S. 74 ff.
[5] Tim Kientzle; Internet-Dateiformate; Windows, DOS, UNIX & Mac, Thomson Publishing, Bonn 1996
[6] James D. Maurray, William van Ryper; Graphics File Formats; O'Reilly & Associates; Sebastopol 1996
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 09/1996 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
