• Die Entwicklung von PNG
  • Geschichte der Kompressionsverfahren und Patente
  • Geschichte der PNG-Spezifikation
• Ein neues Grafikformat
  • Wofür ist PNG gedacht?
  • Welche Eigenschaften hat PNG?
  • Welche Eigenschaften hat PNG nicht? Warum?
• Entworfen für das "World Wide Web"
  • Paletten- und Echtfarbbilder in PNG
  • Transparenz: Echte Alphakanäle
  Erste Schicht: Bildpunkte werden als PNG-Pixel kodiert
  • progressive Anzeige durch Verschachtelung
  Zweite Schicht: PNG-Pixel werden in Bildzeilen gepackt
• Kompression
  • Der "Deflate"-Algorithmus
  • Filter verbessern die Kompression
  Dritte Schicht: Bildzeilen werden als "zlib"-Strom komprimiert
  • Fehlererkennung und Fehlerkorrektur
• Aufbau einer PNG-Datei
  • Dateiaufbau
  • Signatur
  • Typen von Blöcken
  • Blockgrundaufbau
  • Übersicht über alle Blocktypen
• Kritische Blöcke
  • IHDR - der Startblock
  • PLTE - der Palettenblock
  • IDAT - der Pixeldatenblock
  Vierte Schicht: "zlib"-Strom wird in IDAT-Blöcke geschrieben
  • IEND - der Ende-Block
• Zusatzblöcke
• Namenskonvention
• Sicherheitsaspekte
• eigene PNG-Tests
• Stand der Dinge
• Zusammenfassung
• Literatur

Die Entwicklung von PNG [4],[5]

Dieses Patent führte über 10 Jahre nach seiner Einreichung zur Entwicklung eines neuen Grafikformats.

Geschichte der Kompressionsverfahren und Patente

Geschichte der PNG-Spezifikation [4]

Ein neues Grafikformat

Wofür ist PNG gedacht?

Welche Eigenschaften hat PNG?

Portabilität

Erweiterbarkeit

Optimiert für Netzwerk-Anwendungen

Welche Eigenschaften hat PNG nicht? Warum?

CMYK?

Index-Bilder?

Mehrere Bilder in ein PNG?

Verlustbehaftete Kompression?

Paletten- und Echtfarbbilder in PNG

Transparenz: Echte Alphakanäle

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

..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.
 
 

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

progressive Anzeige durch Verschachtelung

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.
 
 

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

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.
 
 

---

Zweite Schicht: PNG-Pixel werden in Bildzeilen gepackt

Kompression

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]

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

Filter verbessern die Kompression

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

Hier nun die Filter im Detail:

0 = "None"

1 = "Sub"

2 = "Up"

3 = "Average"

4 = "Paeth"

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

Beispiel

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

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

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

Fehlererkennung und Fehlerkorrektur

---

Aufbau einer PNG-Datei

Dateiaufbau

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

Signatur

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

Blockgrundaufbau

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:

   x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1

Übersicht über alle Blocktypen

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

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

IHDR - der Startblock

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.

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

  0 = Filterset nach Spezifikation verwendet

  0 = keine

  1 = Adam-7-Verschachtelung

PLTE - der Palettenblock

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

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

IEND - der Ende-Block

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

sBIT Significant bits

gAMA Image gamma

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

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

hIST Image histogram

bKGD Background color

tRNS Transparency

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

oFFs Image offset

pCAL Calibration of pixel

pHYS Physical pixel dimensions

sCAL Physical scale of image subject

    Blöcke, die überall stehen dürfen

tIME Image last-modification time

tEXt Textual data

zTXt Compressed textual data

gIFg GIF Graphic Control Extension

gIFx GIF Application Extension

Namenskonvention

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

   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

eigene PNG-Tests

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;

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

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

Stand der Dinge

Zusammenfassung

Literatur

verwendet: