JPG verlustfrei drehen: Wann es geht und wann nicht

JPG drehen klingt trivial, ist aber der wohl missverstandenste Vorgang der Bildbearbeitung. Wer ein JPG öffnet, dreht und neu speichert, kodiert es in aller Regel neu, und weil JPG eine verlustbehaftete Kompression ist, kann dabei jedes Mal ein wenig Qualität verloren gehen. Es geht aber auch anders: Eine Rotation um 90, 180 oder 270 Grad lässt sich blockweise direkt auf den komprimierten Daten ausführen, ganz ohne Dekodieren und Neukomprimieren. Dieser Ratgeber erklärt, wie diese verlustfreie JPG-Rotation funktioniert, wo ihre Grenzen liegen und was bilddrehen.de im Vergleich dazu macht.

Warum JPG anders ist als PNG

Bei einem PNG ist das Drehen einfach: Die Pixel werden verlustfrei umsortiert, fertig. JPG dagegen speichert keine einzelnen Pixel, sondern transformierte Blöcke. Der Encoder zerlegt das Bild in ein Gitter aus 8x8-Pixel-Kacheln und wandelt jede Kachel mit einer diskreten Kosinustransformation (DCT) in 64 Frequenzkoeffizienten um. Diese Koeffizienten werden quantisiert, also gerundet, und das ist der eigentliche verlustbehaftete Schritt. Genau hier geht Information unwiederbringlich verloren.

Wer ein JPG dekodiert, dreht und neu kodiert, durchläuft die Quantisierung ein zweites Mal. Jede Generation rundet erneut und kann Blockartefakte verstärken und feine Details verwischen. Bei oft wiederholtem Speichern wird das sichtbar.

Wie verlustfreie Rotation technisch funktioniert

Der Trick der verlustfreien Rotation, wie sie das Werkzeug jpegtran aus der libjpeg-Familie umsetzt, besteht darin, die DCT-Blöcke gar nicht erst zu Pixeln zu dekodieren. Stattdessen arbeitet das Verfahren direkt auf der Ebene der Koeffizienten:

• Blöcke umordnen. Eine 90-Grad-Drehung vertauscht die Position jedes Blocks im Gitter, so wie man Fliesen auf dem Boden neu anordnet.
• Koeffizienten transformieren. Innerhalb jedes Blocks werden die 64 DCT-Koeffizienten transponiert beziehungsweise ihre Vorzeichen passend umgekehrt, was im Frequenzraum exakt einer Drehung des Blockinhalts entspricht.
• Keine neue Quantisierung. Da nichts dekodiert und neu quantisiert wird, bleiben die Koeffizientenwerte unverändert. Es gibt schlicht keinen Rundungsschritt, an dem Information verloren gehen könnte.

Wann verlustfreies Drehen klappt und wann nicht

Die verlustfreie Methode hat zwei Bedingungen. Erstens muss die Transformation blockweise möglich sein, also ein Vielfaches von 90 Grad, ein Spiegeln oder ein Transponieren. Zweitens müssen die Bildmaße zur kleinsten Einheit passen, die jpegtran transformieren kann, der iMCU (interleaved Minimum Coded Unit). Ihre Kantenlänge hängt vom Farb-Subsampling ab: Bei Graustufen und 4:4:4 sind es 8 Pixel, bei 4:2:0 meist 16 mal 16 Pixel. Ein Block aus 8x8 Pixeln ist also nicht automatisch die MCU.

Welche Maße passen müssen, hängt von der Transformation ab. Die Tabelle nennt die Maße des Ausgangsbildes, so wie die libjpeg-turbo-Quelle (transupp.c) sie prüft.

Der häufigste Stolperstein sind diese Randblöcke. Ein Bild mit 4001 Pixeln Breite lässt in der letzten Spalte keinen vollständigen Block zu. jpegtran geht damit nach seiner Dokumentation so um: Standardmäßig bleiben die nicht transformierbaren Randblöcke unverändert an ihrer Stelle, am Rand entsteht dadurch ein seltsam aussehender Streifen. Wer das nicht will, hat zwei Optionen. Mit -trim werden die nicht transformierbaren Randblöcke verworfen, das Bild verliert am betroffenen Rand bis zur Größe einer iMCU an Breite oder Höhe, ist aber sauber. Mit -perfect bricht jpegtran stattdessen mit einem Fehler ab, wenn die Transformation nicht perfekt möglich ist. Die Dokumentation weist außerdem darauf hin, dass ein Vorgang mit -trim streng genommen nicht mehr verlustfrei ist, weil er sich nicht umkehren lässt.

Was Neukodierung kostet

Eine einzelne Neukodierung bei hoher Qualität ist meist kaum sichtbar. Das Problem ist die Kumulation: Jede weitere Generation quantisiert erneut. Wie stark sich das auswirkt, hängt vom Bild, vom Qualitätsfaktor und vom Encoder ab, deshalb nennt dieser Ratgeber keine allgemeingültigen Prozentwerte. Sicher ist nur die Gegenrichtung: Die blockweise Rotation ohne Neuquantisierung verändert die Koeffizientenwerte nicht, egal wie oft du sie wiederholst, solange die Maße perfekt passen.

Was Canvas-basierte Browser-Tools tun

Tools, die im Browser über das Canvas-Element arbeiten, also auch bilddrehen.de, gehen einen anderen Weg. Canvas kennt keine DCT-Blöcke. Der Browser dekodiert das JPG vollständig zu Rohpixeln, zeichnet sie gedreht in den Canvas-Kontext und kodiert beim Export per toBlob neu.

Bei bilddrehen.de ist die Drehung selbst exakt: Rechte Winkel werden pixelgenau umgesetzt, die Ausgabegröße ist genau Breite und Höhe getauscht beziehungsweise gleich, es gibt keine Neuabtastung. Ausgegeben als PNG bleibt das Ergebnis deshalb verlustfrei. Bei JPG oder WebP als Ausgabe wird das Bild dagegen neu komprimiert, standardmäßig mit 95 Prozent Qualität, per Regler von 1 bis 100 Prozent einstellbar. Das ist technisch eine Neukodierung, kein blockweise verlustfreier Vorgang. Eine verlustfreie JPEG-Drehung mit jpegtran bietet bilddrehen.de nicht.

Der Vorteil von Canvas ist die Flexibilität: Es dreht auch freie Winkel, spiegelt und arbeitet komplett lokal im Browser, ohne Upload. Bei freien Winkeln entsteht eine größere Leinwand, die das gedrehte Bild vollständig umschließt. Die Ecken sind bei PNG und WebP transparent, bei JPG weiß. Ein Zuschnitt gehört nicht zum Funktionsumfang.

Ein weiterer Punkt betrifft die Metadaten. jpegtran kopiert standardmäßig nur Kommentare. Mit der Option -copy all bleiben auch Exif-Daten und andere Zusatzmarker erhalten, mit -copy none verschwinden sie. Ein Canvas-Export schreibt dagegen keine Metadaten: Exif einschließlich GPS-Angaben sowie ein eingebettetes Farbprofil gehen verloren, weil der Browser nur die reinen Pixel neu kodiert. Das gilt auch für bilddrehen.de. Das Tool wendet die EXIF-Ausrichtung beim Laden an, das exportierte Bild liegt also bereits richtig herum und enthält keinen Orientation-Eintrag mehr. Für ein geradegedrehtes Schnappschuss-Foto ist das oft sogar erwünscht, für ein farbkritisches Druckbild mit hinterlegtem ICC-Profil kann es relevant sein.

Ein konkretes Rechenbeispiel

Nimm ein JPG mit 4032 x 3024 Pixeln. Beide Maße sind durch 16 teilbar (4032 = 252 mal 16, 3024 = 189 mal 16), passen also auch zu einer 16x16-iMCU bei 4:2:0. Eine 90-Grad-Drehung mit jpegtran ordnet die Blöcke vollständig um, das Ergebnis ist 3024 x 4032 Pixel groß, und kein Koeffizient wird neu quantisiert. Kein Pixel geht verloren.

Jetzt nimm ein JPG mit 4000 x 3001 Pixeln und 4:2:0-Subsampling. Für eine 90-Grad-Drehung muss die Höhe ein Vielfaches der iMCU-Höhe sein. 3001 ist weder durch 16 noch durch 8 teilbar: 3001 = 187 mal 16 plus 9. Die letzten 9 Pixelzeilen bilden einen unvollständigen Randblock. Ohne weitere Option dreht jpegtran, lässt diesen Randblock aber unverändert, am Rand der Ausgabe entsteht ein Streifen. Mit -trim werden die 9 Zeilen verworfen, das Ergebnis ist 2992 x 4000 Pixel groß (187 mal 16 = 2992). Mit -perfect gibt jpegtran einen Fehler aus und erzeugt keine Datei. Dieselbe Drehung im Browser-Canvas behält dagegen alle Pixel, kodiert aber neu, wenn du JPG als Ausgabe wählst.

So wählst du die passende Methode

Die Entscheidung folgt einer einfachen Logik. Geht es um eine reine 90-, 180- oder 270-Grad-Drehung eines Archivbilds, bei dem jedes Bit zählt, nimm jpegtran und entscheide je nach Bildmaßen zwischen -perfect und -trim. Geht es um einen freien Winkel, einen schiefen Horizont oder eine Kombination aus Drehen und Spiegeln, führt ohnehin kein Weg an einer Neukodierung vorbei, und der Canvas-Workflow von bilddrehen.de ist dann die schnellste, lokal laufende Lösung ohne Upload. Willst du dabei nichts mehr verlieren, speichere als PNG. Für den täglichen Gebrauch überwiegt meist die Bequemlichkeit, weil eine einzelne Neukodierung bei hoher Qualität mit bloßem Auge selten zu erkennen ist. Erst wer in einer Pipeline mehrfach dreht und neu speichert, sollte konsequent auf die blockweise verlustfreie Methode setzen.