Im Internet haben vor allem zwei Bildstandards Verbreitung gefunden: Das verlustfreie GIF- und das verlustbehaftete JPEG-Format. Wegen der Limitierung auf 256 Farben eignet sich GIF vor allem für schematische Darstellungen und einfache Logos. Zudem erlaubt das GIF-Format einfache Animationen. Auf Grund der verlustfreien Komprimierung bleiben harte Farbübergänge und Kontraste erhalten, so dass auch kleine Beschriftungen gut lesbar bleiben.
Das JPEG-Format eignet sich dagegen mehr zum Speichern von Fotos mit hoher Farbtiefe. Dabei akzeptiert man zu Gunsten einer hohen Kompression Abweichungen vom Originalbild. Diese treten je nach Bildtyp und Kompressionsrate mehr oder weniger stark in Erscheinung.
Das PNG-Format bietet das Beste aus beiden Welten. Es speichert Graustufenbilder mit bis zu 16 Bit und Farbbilder mit bis zu 48 Bit pro Pixel. Hinzu kommt optional noch ein Alphakanal. PNG komprimiert verlustfrei und es fallen für den Kompressionsalgorithmus, anders als bei GIF, keine Lizenzgebühren an. Last but not least unterstützen bereits alle die gängigen Browser das neue Format, wenn auch zum Teil mit Einschränkungen.
Bildformate im Internet
Die im Internet populären Bildformate GIF, PNG, JPEG und JPEG 2000 haben ihre spezifischen Vor- und Nachteile, die wir in der folgenden Tabelle zusammengefasst haben.
Die für JPEG bei der Komprimierung typische Bildung blockförmiger Artefakte hebt JPEG 2000 (*.jk2) zwar durch den Einsatz eines Wavelet-Algorithmus auf. Browser und Bildbearbeitungsprogramme unterstützen das Format allerdings noch nicht - um ein Bild als *.jk2 zu speichern beziehungsweise anzuzeigen, ist meist ein Plug-in erforderlich. Eine vollständige Liste von Browsern, die PNG unterstützen finden Sie hier.
GIF | PNG | JPEG | JPEG 2000 | |
|---|---|---|---|---|
IE=Internet Explorer ab Version 4.0; NN=Netscape Navigator an Version 4.04, Opera ab Version 3.51. Details zur Browser-Unterstützung und weiteren Browsern finden Sie unter www.libpng.org. | ||||
Farbtiefe | 8 Bit Palette | 8 Bit Palette /24-48 Bit RGB | 24 Bit RGB | 24-48 Bit RGB |
Transparenz | einfache Transparenz | einfache Transparenz / Alpha-Transparenz | nein | nein |
Animation | ja | nein | nein | nein |
Kompression | verlustfrei (LZW-Algorithmus) | verlustfrei (Deflate-Algorithmus) | verlustbehaftet (DCT) | verlustbehaftet (Wavelet-Algorithmus) |
Interlacing | ja | ja | nein | ja |
Gamma-Korrektur | nein | ja | nein | nein |
Lizenz | Ja | nein | nein | nein |
Browser-Unterstützung | ja (IE, NN, Opera) | ja (IE mit Einschränkungen, NN, Opera) | ja (IE, NN, Opera) | nein |
Verwendung | Grafiken, Schriften, Navigation | Grafiken, Schriften, Navigation, Fotos, vielfarbige Bilder | Fotos, vielfarbige Bilder | Fotos, vielfarbige Bilder |
PNG gegen GIF - die Hintergründe
Seit 1985 besitzt Unisys ein Patent für das LZW-Komprimierungsverfahren, das auch die Firma CompuServe in dem von ihr entwickelten Grafikformat GIF verwendet. Ende 1994 schlossen die beiden Unternehmen einen Lizenzvertrag, nach dem Firmen und Programmierer Gebühren für Programme, die das GIF-Format verwenden, an CompuServe abführen müssen. Als lizenzfreie Alternative konzipierte eine unabhängige Entwicklergruppe daraufhin 1995 das PNG-Format. Es sollte folgenden Kriterien genügen:
Patent- und lizenzfreier Kompressionsalgorithmus
Freie Verfügbarkeit der Quelltexte
Bessere Kompression als GIF
Interlacing und Transparenz sollen mindestens wie im GIF-Format möglich sein
Verlustfreie Konvertierung der GIF- in PNG-Bilder
Einfache und saubere Implementierung
Portabilität
Unterstützung des sequenziellen Lesens und Schreibens, damit PNGs auch dynamisch erzeugt werden können
1996 gab das W3C die Spezifikation 1.0 des PNG-Formats als offizielle Empfehlung heraus. Inzwischen findet sich PNG in der Spezifikation 1.2. Der endgültige Standard soll unter der Bezeichnung ISO/IEC 15948 noch 2002 erscheinen. Die Durchsetzung des PNG-Formats als neuer Webstandard scheint daher nur noch eine Frage der Zeit zu sein.
Zur PNG-Familie gehören auch die Formate MNG (Unterstützung von Animationen) und JNG (verlustbehaftetes Subformat von MNG). Für deren Darstellung ist allerdings ein Plug-in erforderlich.
PNG - das bessere GIF
PNG bietet nicht nur alle von GIF bekannten Features (mit Ausnahme der Animation), sondern besticht darüber hinaus durch eine effizientere Kompression, schnelles Interlacing und vielseitigere Transparenz. PNG enthält folgende GIF-Eigenschaften:
Indizierte Bilder bis zu 256 Farben
Inkrementelles Anzeigen
Einfache Transparenz
Verlustfreie Komprimierung
Streamability (Dateien können seriell geschrieben und gelesen werden)
Portabilität
Zudem verfügt PNG über einige weitere Vorteile, die es zu einem flexiblen Format im Webbereich machen:
Echtfarbbilder mit bis zu 48 Bit pro Bildpunkt (16 Bit pro Farbkanal)
Graustufenbilder mit bis zu 16 Bit pro Bildpunkt
Alpha-Transparenz
Erkennen beschädigter Dateien
Speichern der Gamma-Wert-Einstellungen
Flexible, erweiterbare Struktur
Flexibler und offener Aufbau
Eine PNG-Datei setzt sich aus einer Signatur und einer beliebigen Anzahl von Blöcken (Chunks) mit variabler oder fester Länge zusammen.
Die Signatur dient der Identifizierung einer PNG-Datei und zugleich der Erkennung falscher Konvertierungsmodi. Über diese letzte Eigenschaft verfügt PNG als einziges unter den Rasterbild-Formaten. Chunks beinhalten all die Informationen, die zur korrekten Darstellung einer Grafik erforderlich sind. Jedem Chunk entspricht eine bestimmte Informationsart.
Es gibt zwei Arten von Blöcken. Neben den obligatorischen (critical chunks), die jede Software verarbeiten können muss, kann eine PNG-Datei beliebig viele Zusatzblöcke (ancillary chunks) beinhalten.
Zusatzblöcke lassen sich wiederum in offizielle - vom W3C empfohlene - und private - etwa von einem Software Hersteller entwickelte - aufteilen. Neue Features und Funktionen, wie das Hinterlegen von Datum und Uhrzeit, lassen sich also je nach Lust und Laune problemlos integrieren.
Signatur
Die ersten acht Byte einer PNG-Datei bilden die Signatur. Diese besteht aus dem Wert 137 gefolgt von den Buchstaben PNG und vier weiteren Zeichen. Das erste Byte soll verhindern, dass die Bilddatei fälschlicherweise als Textdatei interpretiert wird.
Zusätzlich werden durch das erste Byte fehlerhafte Übertragungsmodi erkannt. In so einem Fall wird das siebte Bit dieses Bytes gelöscht oder nicht übertragen. Die Bytes zwei bis vier kennzeichnen durch das Buchstabenkürzel PNG das Format - jedoch nicht die Versionsnummer - eindeutig. Das W3C hat das PNG-Format offen halten wollen und auf die Festlegung einer Versionsnummer verzichtet: PNG arbeitet auf einer Feature-by-Feature-Basis.
Die Bytes fünf und sechs bilden eine CR-LF-Sequenz (Carriage Return - Line Feed) und dienen der Erkennung von Konvertierungsfehlern - etwa bei der FTP-Übertragung zwischen Unix und DOS. Unter MS-DOS kennzeichnet die CR-LF-Kombination das Ende einer Textzeile. Sollte die PNG-Datei fälschlicherweise als Textdatei interpretiert werden, so würden die CR-LF-Sequenzen in LF umgewandelt - wie etwa von DOS nach UNIX oder bei einer FTP-Übertragung, die nicht im binären Modus erfolgt.
Das siebte Byte entspricht einem "Control-Z" und bricht die Dateiausgabe unter DOS ab. Bei Byte acht schließlich handelt es sich um ein einfaches Line Feed, das analog zu den Bytes fünf und sechs bei einer fehlerhaften Konvertierung in CR-LF umgewandelt würde.
Chunk-Architektur
In einer PNG-Datei folgt der Signatur eine Reihe von - obligatorischen und optionalen - Blöcken (Chunks). Die Reihenfolge der Standard-Chunks ist nicht beliebig, sondern wie folgt festgelegt:
Header (obligatorisch)
Palette (optional)
Zusatz-Chunks (optional)
Daten (obligatorisch)
Image-End (obligatorisch)
Ein Chunk besteht aus vier Komponenten und beginnt mit einem 32-Bit-Wert, der die Länge des Datenfeldes angibt. Dieser Wert darf nicht über 2^31-1 hinausgehen, damit es bei der Behandlung des Vorzeichens keine Software Probleme gibt. Null kann eine gültige Zahl darstellen - beispielsweise bei einem leeren Datenfeld.
Die zweite Komponente, der Chunk-Typ, besteht aus einem vier Zeichen langen String. Dieser kennzeichnet den Block gemäß den vom W3C festgelegten Namenskonventionen eindeutig.
Die eigentlichen Daten bilden das dritte Feld. Die Interpretation des Daten-Chunk hängt vom Chunk-Typ ab. Schließlich ist in jedem Block eine 32-bittige CRC-Prüfsumme gespeichert, mit deren Hilfe die Software Übertragungsfehler feststellen kann.
Chunk-Namenskonventionen
Das W3C hat einige Regeln zur Namensgebung von Chunks festgelegt. Die Namenskonventionen beziehen sich auf die Klein- beziehungsweise Großschreibung der einzelnen Buchstaben im Feld "Typ" eines Blocks, also des 32-Bit-Strings.
Decoder interpretieren die vier Zeichen des Chunk-Typs allein durch die Klein- respektive Großschreibung. Nach der PNG-Spezifikation 1.0 kommt den einzelnen Bytes folgende Bedeutung zu:
Das erste Byte identifiziert den Chunk als unverzichtbar oder verzichtbar. Ist das erste Zeichen ein Kleinbuchstabe - wie etwa "t" im tEXt-Chunk -, handelt es sich um einen Zusatz-Chunk. Im umgekehrten Fall handelt es sich dagegen um einen unverzichtbaren Block. Decoder können unbekannte Zusatzblöcke ignorieren - die Bilddatei wird nicht falsch dargestellt.
Bei offiziellen Chunks ist das zweite Zeichen ein Großbuchstabe. Ein Kleinbuchstabe steht für einen privaten Chunk. Mit dieser Regel will das W3C verhindern, dass künftig Namenskonflikte zwischen offiziellen und privaten Chunks entstehen.
Byte drei ist per Konvention ein Großbuchstabe, in unserem Beispiel "X". Groß- oder Kleinschreibung an dieser Stelle hat derzeit keine Bedeutung und ist für künftige Erweiterungen reserviert.
Das vierte Byte ist vor allem für PNG-Editoren von Bedeutung. Es legt fest, ob ein Programm bei Modifikation eines Bildes unbekannte Chunks kopieren darf. Ist das vierte Zeichen ein Kleinbuchstabe, so darf der unbekannte Chunk kopiert werden, bei einem Großbuchstaben hingegen nicht. Während Zusatz-Chunks wahlweise einen Klein- beziehungsweise Großbuchstaben aufweisen können, erscheint bei obligatorischen Chunks ein Großbuchstabe. Wenn ein Programm einen unverzichtbaren Chunk nicht kennt, darf es diesen nicht kopieren, sondern muss eine Fehlermeldung anzeigen.
Unverzichtbare Chunks
In den obligatorischen Chunks finden sich all die Informationen, die zur korrekten Darstellung eines Bildes notwendig sind. Als unverzichtbar hat das W3C folgende Blöcke definiert: Den Image-Header- (IHDR), den Image-Data- (IDAT) und den Image-End-Chunk (IEND). Der Header kommt als erster Block direkt nach der Signatur und gibt die wesentlichen Bildparameter an:
Länge | Name | Mögliche Werte |
|---|---|---|
| ||
4 Byte | Breite | 1 bis (2^31-1) |
4 Byte | Höhe | 1 bis (2^31-1) |
1 Byte | Bit-Tiefe | 1, 2, 4, 8, 16 |
1 Byte | Farbtyp | 0, 2, 3, 4, 6 |
1 Byte | Kompressionsmethode | 0 |
1 Byte | Filtermethode | 0 |
1 Byte | Interlace-Methode | 0, 1 |
Breite und Höhe werden in Pixel angegeben. Die Bit-Tiefe gibt die Anzahl der Bits pro Farbwert an. Der Farbtyp ist eine Kombination aus den Werten 1, 2 und 4. Wert 1 bedeutet, dass eine Palette benutzt wird; die 2 verweist darauf, dass ein Bild RGB-Farben enthält. Wert 4 bezieht sich schließlich auf die Verwendung eines Alpha-Kanals. Allerdings sind für den Farbtyp nicht alle Werte zulässig. Welche Farbtypen in Kombination mit welcher Bit-Tiefe erlaubt sind, zeigt die folgende Tabelle:
Farbtyp | Gültige Bit-Tiefe | Interpretation (jeder Punkt enthält einen) |
|---|---|---|
| ||
0 | 1, 2, 4, 8, 16 | Grauwert |
2 | 8, 16 | RGB-Wert |
3 | 1, 2, 4, 8 | Palette-Index |
4 | 8, 16 | Grau-Wert+Alpha-Wert |
6 | 8, 16 | RGB-Wert+Alpha-Wert |
Bei der Kompression und Filterung ist bisher lediglich der Wert 0 erlaubt - das W3C hat bislang nur ein Kompressionsverfahren und eine Filtermethode spezifiziert. Beim Interlacing sind die Werte 0 (kein Interlace) und 1 (Adam 7 Interlace) zulässig.
Paletten-Chunk
Sind indizierte Bilder vorhanden, benötigt man auch eine Farbpalette - in dem Fall muss diese Angabe nach dem IHDR-Chunk stehen. Die Palette ist im Paletten-Chunk (PLTE) gespeichert, der optional in den Modi RGB und RGB plus Alpha (RGBA) arbeitet. Im RGB-Modus enthält die Tabelle einen bis 256 Paletteneinträge. Hierbei wird jeder Eintrag über eine 3-Byte-RGB-Folge definiert. Im RGBA-Modus bildet jeder Eintrag eine 4-Byte-Folge.
Im Image-Data-Block finden sich die gemäß den Angaben im Header gefilterten und komprimierten Bilddaten. Der Daten-Chunk speichert zudem pro Bildzeile ein so genanntes Filter-Byte, das den für die jeweilige Bildzeile geltenden Filtertyp angibt.
Eine PNG-Datei kann mehrere IDAT-Chunks enthalten. Zudem können Encoder die Bilddaten auf jeder beliebigen Stelle trennen. Größe und Anzahl der Blöcke sind beliebig. Einzige Bedingung: Die Blöcke müssen aufeinander folgen.
Der IEND-Chunk signalisiert das Ende einer PNG-Datei. Dieser enthält ein leeres Datenfeld.
Optionale Chunks
Neben den obligatorischen gibt es eine Reihe von - privaten und offiziellen - Zusatz-Chunks. Diese enthalten Informationen, die zur Darstellung des Bildes nicht unbedingt erforderlich sind. Einige der implementierten Funktionen können jedoch nützliche Dienste leisten. Zusatzblöcke müssen vor den Daten-Chunks stehen. In der PNG-Spezifikation 1.0 hat das W3C zehn optionale Chunks definiert. Die interessantesten offiziellen Zusatzblöcke finden Sie in der folgenden Tabelle:
Name | Bedeutung | Funktion |
|---|---|---|
| ||
bKGD | Background Color | enthält eine Hintergrundfarbe |
gAMA | Image gamma | enthält den Gamma-Wert eines Bildes |
gIFg | GIF Graphic Control Extensions | sichert Kompatibilität zu GIF 89a |
tEXt | Textual data | enthält textuelle Informationen |
tRNS | Transparency | enthält Informationen zur einfachen Transparenz |
zTXT | Compressed textual data | enthält komprimierte Textdaten |
Optimierte Kompression
Der eigentlichen Komprimierung ist bei PNG eine Filterung vorgeschaltet. Nach der bisherigen PNG-Spezifikation existiert derzeit nur Filtermethode 0, die fünf Stufen umfasst. Die Filter erlauben es, Bilddateien auf eine für die Kompression besser geeignete Weise vorzubereiten.
Die Filterung ersetzt absolute Pixelwerte durch ihre Differenz zu einem ähnlichen Wert. Es entsteht somit ein Datenstrom, der viele ähnliche Werte enthält und sich wesentlich dichter komprimieren lässt. Die einzelnen Filter funktionieren wie folgt:
Beim Filter 0 (None) wird die Zeile unverändert an den Kompressionsalgorithmus übergeben.
Filter 1 (Sub) bezieht die Differenz jedes Pixels auf das entsprechende Vorgängerpixel und zwar pixelweise.
Filter 2 (Up) nutzt die Differenz mit dem Pixel in der darüber liegenden Zeile als Bezugspunkt.
Filter 3 (Average) berechnet die Differenz zum Mittelwert der Pixel links und oberhalb des aktuellen Pixels.
Der Filter 4 (Paeth) nutzt die Differenz zu einem der drei Punkte links, oberhalb oder links oberhalb eines Pixels. Eine einfache lineare Funktion - nach ihrem Erfinder PaethPredictor genannt - schätzt ab, welcher der drei Nachbarpunkte verwendet werden soll. Der PaethPredictor gibt den Punkt zurück, der dem berechneten Wert am nächsten liegt.
Um die bestmöglichen Ergebnisse zu erzielen, kann eine Filtervariation pro Bildzeile angewandt werden. Ein Filterindikator gibt die für die entsprechende Zeile geltende Filtervariation an. Der Indikator ist ein Byte mit einem Wert zwischen 0 und 4 und ist im IDAT-Block gespeichert.
Grafikprogramme, die mit PNG arbeiten, suchen den für das Bild am besten geeigneten Filteralgorithmus automatisch aus.
Auf den Spuren von LZ77
Als wettbewerbsfähiger Konkurrent gegenüber dem GIF-Format sollte PNG über einen verlust- und vor allem lizenzfreien Kompressionsalgorithmus verfügen. Diesen fand man mit dem 1977 von Lempel und Ziv vorgestellten LZ77-Algorithmus, der auf Basis der Erkennung von periodischen Sequenzen arbeitet.
Für die Kompression beim GIF-Format sorgt eine vereinfachte Variante von LZ77: der von der Firma Unisys als Patent angemeldete LZW-Algorithmus. Dieser erkennt horizontale Folgen gleichfarbiger Pixel und ersetzt sie durch einen Tabelleneintrag, der Farbe und Sequenzlänge angibt. So reicht für die Wiedergabe der Zeilen vier bis sechs des folgenden Bildes der Verweis "wie Zeile drei".
Kompression bei GIF funktioniert umso effektiver, je häufiger in einer Grafik gleiche Zeilen oder Zeilenabschnitte vorkommen. Umgekehrt gilt: Je unterschiedlicher die Zeilenmuster sind, um so größer fällt die Datei aus. So vergrößert eine zusätzliche Farbe pro Zeile eine Datei nicht so stark wie schräge Linien. Denn im letzteren Fall werden die Farbblöcke durch Zwischenfarben unterbrochen, die eine effektive Kompression verhindern.
Deflate-Kompression
Für PNG wurde der Deflate/Inflate-Algorithmus von Philip Katz spezifiziert, den beispielsweise auch PKZIP verwendet. Deflate erkennt nur wiederkehrende, horizontale Muster. Dafür arbeiten aber die vorgeschalteten Filter mit Bildpunkten aus der darüber liegenden Bildzeile, so dass vertikale Bildmuster ebenfalls erkannt werden. Daher lässt sich eine bessere Komprimierung erzielen als bei GIF. Bei verschiedenen Mustern komprimiert der Deflate-Algorithmus somit besser als sein LZW-Pendant.
Nach der Deflate-Methode wird zunächst der LZ77-Algorithmus auf die zu komprimierenden Daten angewandt - allerdings ohne sortierte Hash-Tabellen. Es folgt die Kodierung nach der Huffmann-Methode (Entropie-Kodierung). Diese kommt auch in JPEG 2000 zum Einsatz - mehr über dieses Bildformat finden Sie hier.
Bei der Entropie-Kodierung werden die Zeichen nach ihrer Häufigkeit sortiert. Häufig vorkommende und lange Bitfolgen werden durch kurze Codes repräsentiert - und seltene Folgen durch längere.
Beim Aufbau des Huffman-Baums sortiert man die Werte zunächst nach Ihrer Häufigkeit. Dann weist man dem seltensten Wert die 0 zu und dem zweitseltensten Wert die 1 zu. Diese beiden fasst man zusammen, indem man die Häufigkeiten addiert und in die Liste der Häufigkeiten einsortiert. Im Folgenden verarbeitet man wieder die beiden seltensten Werte der Liste und fährt so fort, bis alle kodiert sind.
Praxisbeispiele: Kompression
Im folgenden Beispiel haben wir ein 360 x 270 Pixel großes Foto in verschiedenen Bildformaten gespeichert: GIF, PNG, JPEG und JPEG 2000. Es zeigt sich, dass JPEG 2000 - in der verlustbehafteten Version - die kleinste Datei erzeugt. Mit Blick auf die verlustfreien Formate produziert PNG 8 Bit - dicht gefolgt von GIF - die Datei mit geringster Größe. Bei diesen beiden Formaten fallen die Farbverläufe allerdings nicht sauber aus. Mit PNG 24 Bit ist das Foto einwandfrei - mit 106 KByte fällt die Datei aber mit Abstand am größten aus. Wenn Sie unser Beispiel-Foto im PNG-Format anschauen möchten, klicken Sie bitte hier.
Format | Größe in KByte |
|---|---|
| |
GIF | 72,52 |
PNG 8 Bit | 75,49 |
PNG 24 Bit | 106,0 |
JPEG (10:1) | 44,1 |
JPEG 2000 (10:1) | 28,4 |
JPEG 2000 (verlustfrei) | 135,0 |
Bei der Wiedergabe von Grafiken und Logos arbeiteten GIF und PNG 8 Bit sehr effektiv und sauber. Denn die reduzierte Palette hat keinerlei Auswirkungen auf die Darstellung einfacher Bilder. Bezüglich der Dateigröße ergaben sich zwischen diesen beiden Formaten beim Speichern unseres Beispiel-Logos keine relevanten Unterschiede.
In der Regel macht das Speichern von Logos in PNG 24 Bit oder JPEG 2000 keinen Sinn: Die Kompression arbeitet zwar verlustfrei, die Dateien fallen allerdings groß aus. Das gewählte Logo kann mit relativ unauffälligen Auswirkungen auf die Qualität auch im verlustbehafteten Modus von JPEG oder JPEG 2000 gespeichert werden. Wenn Sie unser Beispiel-Logo im PNG-Format anschauen möchten, klicken Sie bitte hier.
Format | Größe in KByte |
|---|---|
| |
GIF | 15,9 |
PNG 8 Bit | 16,9 |
PNG 24 Bit | 42,8 |
JPEG (10:1) | 14,2 |
JPEG 2000 (10:1) | 14,3 |
JPEG 2000 (verlustfrei) | 53,2 |
Interlacing
Browser bauen Bilder beim Laden Zeile für Zeile auf. Je größer die Datei, desto länger dauert es, bis man ein Bild erkennt. Durch Interlacing werden Bilder dagegen schichtweise aufgebaut. Deren Grundstruktur erscheint damit relativ schnell am Bildschirm: Der Browser baut zunächst ein Gesamtbild mit unscharfen Konturen auf, das zunehmend schärfer wird.
Sowohl GIF und JPEG2000 als auch PNG unterstützen Interlacing. Zwischen den jeweils eingesetzten Methoden - und ebenso in den Ergebnissen - gibt es jedoch erhebliche Unterschiede.
Ein im Interlace-Modus gespeichertes GIF besteht aus vier Schichten. Die erste Schicht enthält jede achte Zeile (1, 9, 17, ...). Dann folgen die Zeilen, die genau zwischen zwei bereits angezeigten Zeilen liegen (5, 13, 21, ...). Im dritten Schritt kommen alle Zeilen, die sich zwischen dem ersten übertragenen Wert und dem ersten übertragenen Mittelwert befinden (3, 7, 11, 15, ...). Der vierte und letzte Schritt enthält alle restlichen Zeilen (2, 4, 6, 8, ...).
PNG-Interlacing
Anders - und schneller - funktioniert das inkrementelle Anzeigen bei PNG. Hier kommt die nach ihrem Entwickler Adam Costello benannte Adam7-Methode zum Einsatz. Diese strukturiert die Übertragung in sieben Phasen und verdoppelt abwechselnd zunächst die horizontale und dann die vertikale Auflösung eines Bildes. Adam7 teilt Bilddateien in 8 x 8 Pixel große Blöcke auf.
Mit diesem Schema erhält man schneller einen Gesamtüberblick, da im ersten Schritt nur 1/64 des gesamten Bildes übertragen wird. Jede weitere Schicht zeigt doppelt so viel Informationen wie die vorhergehende an.
Eine PNG-Datei ist bereits nach dem fünften Durchlauf zu erkennen - das entspricht 25 Prozent der Daten. Bei GIF dauert es doppelt so lange, also bis zum Ende des dritten Durchlaufs - dies entspricht 50 Prozent der Daten. Wie die folgende Abbildung zeigt, hat PNG bereits vier Schichten abgearbeitet, wenn GIF die erste Schicht abgeschlossen hat. Der letzte Schritt ist bei beiden Formaten identisch.
Die Vorteile der Adam7-Methode werden vor allem bei der Übertragung kleiner Schriften deutlich, wie sie beispielsweise bei Logos oder Bannern häufig vorkommen.
Farbtiefe und Transparenz
PNG unterstützt wie JPEG 48-Bit-RGB, wahlweise aber auch - wie GIF - das Speichern mit indizierten Farben. Wie bei GIF-Bildern lassen sich zudem Transparenzeffekte erzeugen. Mit PNG sind jedoch deutlich vielseitigere Ergebnisse möglich als mit GIF.
Während GIF nur einfache Transparenz erlaubt - ein Farbwert lässt sich als durchsichtig festlegen - arbeitet PNG neben dieser Farbmaskierungsmethode auch mit Alpha-Kanälen. PNG kann also neben den drei Werten für RGB einen vierten Wert pro Pixel speichern, den Alpha-Wert (RGBA). Dieser gibt den Transparenzgrad eines Pixels an.
Die Bittiefe des Alpha-Kanals hängt vom Bild ab. Bei 24-Bit-RGB hat jeder Farbkanal 8 Bit, also auch der Alpha-Kanal. Bei 48-Bit-RGB sind es entsprechend 16 Bit. Alle PNG-Typen - Vollfarben-, Graustufen- und 256-Farbenpalette - können Alpha-Informationen beinhalten.
Alpha-Kanäle
Besonders nützlich ist die Möglichkeit von Alpha-Kanälen mit verschiedenen Transparenzstufen bei der Wiedergabe von Schriften oder diagonalen Linien.
Speichert man etwa eine Schrift im GIF-Format, so entstehen auffällige Treppenstufeneffekte. Solche Artefakte lassen sich zwar per Anti-Aliasing beseitigen. Wenn man allerdings die Hintergrundfarbe des Bildes ändert, entsteht das so genannte Kantenleuchten rund um die transparenten Bereiche.
Anders bei PNG: Anstelle eines Grauwertes zum Glätten der Kanten speichert das Format neben der Farbinformation eine Transparenzstufe. Die Kanten erscheinen scharf, und das bei jeder Hintergrundfarbe.
Gamma-Korrektur
Als weiteren Pluspunkt kann PNG die beabsichtigte Gamma-Einstellung einer Grafik in der Bilddatei speichern. Hierfür sorgt der vom W3C definierte Zusatz-Chunk gAMA.
Der Gamma-Wert eines Bildes bestimmt dessen Anzeigeverhalten bezüglich der Lichtintensität. Die Darstellung fällt je nach Bildschirm und Betriebssystem anders aus. So zeigt ein PC dasselbe Bild dunkler an als ein Mac. Die Unterschiede fallen vor allem im mittleren Helligkeitsbereich auf.
Um ein Bild korrekt darzustellen, muss man also zwei Parameter kennen: Den Gamma-Wert des Systems, auf dem das Bild erstellt wurde und des Systems, auf dem es angezeigt werden soll. Letzteres liefert PNG. Um die Sicherung der eigenen Gamma-Einstellungen muss sich das System selber kümmern.
Unterstützung
PNG konnte sich (noch) nicht gegenüber GIF und JPEG durchsetzen. Zu der nur relativ geringen Verbreitung des Formats dürfte dessen späte Unterstützung seitens der gängigen Browser beigetragen haben.
Der Internet Explorer zeigt PNG erst seit Version 4.0 an und bietet selbst in der aktuellen Version 6.0 keine vollständige Unterstützung der Alpha-Transparenz. Auch Netscape arbeitet seit Version 4.04 mit PNG zusammen. Über den Support für alle Funktionen inklusive Transparenz und MNG verfügt der Browser jedoch erst seit Version 6.0.
Besser schaut es bei den Bildbearbeitungsprogrammen aus. So arbeitet Macromedias Fireworks seit jeher mit PNG. Photoshop und Paint Shop Pro unterstützen dieses Format bereits seit Version 4.0 respektive 3.0.1.
Fazit
PNG vereint die Vorzüge der Grafikformate GIF und JPEG. Mit dem ersten teilt es die verlustfreie Kompression, das inkrementelle Anzeigen sowie die Unterstützung von Transparenz und indizierten Farben. PNG weist jedoch eine höhere Farbtiefe und Transparenz, schnelleres Interlacing und eine effizientere Kompressionsmethode auf als GIF. Im Gegensatz zu diesem Format ist es aber vor allem frei von Lizenzansprüchen. PNG basiert zudem auf einem flexiblen, zukunftsorientierten Konzept: Es ist offen aufgebaut und lässt sich um beliebig neue Funktionen erweitern.
Genau wie JPEG unterstützt PNG im Vergleich zu GIF mehr Farben. Anders als JPEG komprimiert es jedoch verlustfrei. Schlechte Karten gegenüber PNG hat auch JPEG 2000 - da Browser das Format derzeit noch nicht unterstützen.
PNG lässt sich universell einsetzen und deckt die Verwendungsbereiche von GIF und JPEG problemlos ab. Allerdings lohnt es sich mit Blick auf die Dateigröße nicht immer, ein Bild im PNG-Format zu speichern. Weiterer Wermutstropfen: PNG arbeitet nur mit Einzelbildern, unterstützt also keine Animation. Zu Darstellungsproblemen kann auch die teilweise eingeschränkte Unterstützung durch den Internet Explorer führen. Weitere Informationen zum Thema bietet die PNG-Webseite www.libpng.org. (bsc/tri/mha)