Einen beschädigten PNG-Screenshot reparieren

Jedes PNG beginnt mit derselben 8-Byte-Signatur — 89 50 4E 47 0D 0A 1A 0A — einem Fingerabdruck, der bewusst mit Stolperdrähten gespickt ist: Das Byte mit gesetztem höchsten Bit 0x89 entlarvt auf 7 Bit beschnittene Kanäle, das 0D 0A und das einzelne 0A fangen eine Zeilenende-Umwandlung ab, und das 1A (DOS-Dateiende) hindert ein unbedachtes type daran, den Rest auszugeben. Danach folgt eine Reihe von Chunks, jeder ein sauberes Paket: eine 4-Byte-Länge in Big-Endian, ein 4-Byte-ASCII-Typ, die Daten und ein 4-Byte-CRC-32, berechnet über Typ und Daten (nie über die Länge) mit dem üblichen reflektierten Polynom 0xEDB88320.

Drei Chunks tragen das Bild. IHDR steht an erster Stelle und ist immer 13 Bytes lang: Breite (u32), Höhe (u32), dann einzelne Bytes für Bittiefe, Farbtyp, Kompressionsverfahren, Filterverfahren und Interlace-Verfahren. Ein Screenshot eines modernen Betriebssystems ist fast immer 8-Bit, nicht interlaced, Farbtyp 2 (Truecolor) oder 6 (Truecolor mit Alpha). IDAT enthält das Bild, mitunter auf mehrere aufeinanderfolgende IDAT-Chunks verteilt; darin steckt ein zlib-Stream (Header-Byte 0x78) aus DEFLATE-komprimierten gefilterten Bildzeilen — jede Zeile mit einem Filter-Byte 0–4 (None, Sub, Up, Average, Paeth) vorangestellt, von oben nach unten geschrieben. IEND ist die leere Endmarkierung mit einem festen CRC von AE 42 60 82.

Screenshots führen außerdem erkennbare Zusatz-Chunks mit sich — der kleingeschriebene erste Buchstabe kennzeichnet sie als optional — etwa pHYs (Pixeldichte, damit eine Retina-Aufnahme ihren Maßstab angibt), iCCP oder sRGB (Farbprofil), tEXt/eXIf (Metadaten, die das Aufnahme-Tool einstempelt). Diese können beschädigt werden oder verlorengehen, ohne dass ein einziger Pixel verloren geht, denn ein Decoder darf jeden Zusatz-Chunk überspringen, den er nicht versteht.

Weil sich jeder Chunk selbst prüft, hat eine ganze Klasse von PNG-Schäden eine berechenbare Antwort statt einer Vermutung:

• Falsche Prüfsumme, richtige Daten. Der häufigste Fehlalarm: Die Bytes eines Chunks sind unversehrt, aber sein gespeichertes CRC passt nicht mehr, sodass strenge Decoder (und pngcheck) die Datei mit CRC error in chunk IDAT ablehnen. Das CRC-32 aus den Daten neu zu berechnen und zurückzuschreiben macht die Datei mit null Verlust wieder gültig — die Prüfsumme war das Einzige, das nicht stimmte.
• Auf null gesetzte oder verwürfelte Dimensionen. Ist die Breite oder Höhe im IHDR auf null gesetzt, kann kein Decoder eine Leinwand anlegen und die Datei öffnet nicht. Doch IHDR trägt sein eigenes CRC, berechnet zu der Zeit, als die Zahlen noch stimmten. Das erlaubt der Reparatur, die Geometrie per Brute Force zu ermitteln: Kandidatenwerte für Breite/Höhe durchprobieren, für jeden das Chunk-CRC neu berechnen und anhalten, sobald es zum gespeicherten Wert passt. Die ursprünglichen Abmessungen fallen direkt aus der Rechnung — ohne Raten.
• Verstümmelung durch Zeilenumbrüche / Textmodus. Ein Screenshot, der durch einen FTP-Client im ASCII-Modus, eine Chat-Brücke oder ein Skript geschickt wurde, das ihn als Text neu geschrieben hat, ersetzt jedes 0D 0A durch ein einzelnes 0A (oder umgekehrt) und beschädigt so Bytes im gesamten Dokument. Die Signatur ist genau dafür ausgelegt, dies zu erkennen, und wenn die Ersetzung konsistent ist, lässt sie sich Byte für Byte rückgängig machen.
• Fehlendes oder defektes IEND. Eine ansonsten vollständige Datei, die ihre abschließende Endmarkierung verloren hat, löst Warnungen wegen "unvollständiger Datei" aus; ein gültiges IEND neu zu schreiben, lässt einen strengen Decoder das Bild akzeptieren, das bereits vollständig da ist.

Die ehrlichen Grenzen beginnen dort, wo die Pixeldaten selbst weg sind, und Screenshots erwischt es auf beide Arten.

Abschneiden — der obere Teil kommt zurück. Das ist die häufigste Art, wie ein Screenshot kaputtgeht: ein Speichervorgang, der durch eine volle Platte unterbrochen wurde, eine Kopie, die beim Abziehen eines Telefons abbrach, eine Cloud-Synchronisierung, die bei 80 Prozent stehen blieb. Der vordere Teil der Datei ist unversehrt, und das Ende — normalerweise samt IEND — fehlt schlicht. Weil die Bildzeilen von oben nach unten geschrieben werden, lässt sich ein abgeschnittenes PNG in seinen oberen Bildteil retten: echte Pixel bis zu der Stelle, an der die Daten enden. Die Reparatur schreibt einen gültigen Abschluss neu, damit ein Decoder die Datei akzeptiert und das zeichnet, was überlebt hat. Die Zeilen unterhalb des Schnitts sind nicht beschädigt, sie sind nicht vorhanden, also kann kein Tool sie zurückbringen — das Ergebnis ist ein ehrliches Teilbild.

IDAT-Schaden mitten im Stream — der untere Teil ist Rauschen. Landet die Beschädigung innerhalb des DEFLATE-Streams statt am Ende, liegt der Grund für die Unwiederbringlichkeit im DEFLATE selbst: Es ist ein einziger fortlaufender Stream, in dem jeder Teil vom Vorangegangenen abhängt, ohne regelmäßige Markierungen zum Resynchronisieren. Sobald der Decoder auf das fehlerhafte Byte trifft, verliert er den Faden (zlib meldet incorrect data check / invalid distance too far back), und alles danach wird als Rauschen decodiert. Ein einziges gekipptes Byte auf halber Höhe kann dich jede Zeile darunter kosten, nicht nur eine — das Bild ist oberhalb des Treffers sauber und unterhalb Müll. Deshalb öffnet sich ein Screenshot mit scharfem oberen Teil und einer verschmierten oder grauen unteren Hälfte — dieselbe Ergebnisform, die ein abgeschnittenes JPEG liefert.

Vergleiche das mit Formaten, die einen Index getrennt von ihren Daten führen — das moov eines QuickTime-Videos, ein SQLite-B-Baum —, bei denen der Wiederaufbau der Karte die ganze Datei rettet. PNG hält seine Pixel in einem einzigen unteilbaren DEFLATE-Stream, deshalb ist eine Wunde mitten im Stream unterhalb des Schnitts dauerhaft.