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, verliert bei jedem Durchgang ein wenig Qualität, weil JPG eine verlustbehaftete Kompression ist. 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 harten Grenzen liegen und wie groß der Qualitätsunterschied zur Neukodierung tatsächlich ist.

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, den sogenannten MCUs (Minimum Coded Units), 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, addiert Blockartefakte und verwischt feine Details. Bei oft wiederholtem Speichern wird das sichtbar.

PNG dreht Pixel. JPG muss Frequenzblöcke drehen, und ob das verlustfrei gelingt, entscheidet die Geometrie des 8x8-Rasters.

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 komprimierten Koeffizienten:

• Blöcke umordnen. Eine 90-Grad-Drehung vertauscht die Position jedes 8x8-Blocks im Gitter, so wie man Fliesen auf dem Boden neu anordnet.
• Koeffizienten transponieren. Innerhalb jedes Blocks werden die 64 DCT-Koeffizienten gespiegelt beziehungsweise transponiert, was im Frequenzraum exakt einer Drehung des Blockinhalts entspricht.
• Keine Quantisierung. Da nichts dekodiert und neu quantisiert wird, bleiben die Daten bit-identisch erhalten. 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 der Drehwinkel ein Vielfaches von 90 Grad sein. Zweitens müssen die Bildmaße zum Blockraster passen. Da Farb-Subsampling oft mit 16x16-Blöcken (MCUs) arbeitet, sollten Breite und Höhe idealerweise durch 16 teilbar sein, mindestens aber durch 8.

Situation	Verlustfrei möglich?	Was passiert
90/180/270 Grad, Maße durch 16 teilbar	ja, vollständig	Blöcke werden nur umgeordnet, bit-identisch
90/270 Grad, Maße nicht durch 8 teilbar	nur mit Trim	unvollständige Randblöcke werden verworfen (minimaler Beschnitt)
180 Grad, beliebige Maße	meist ja	180 Grad braucht keine Rand-Sonderbehandlung
Freier Winkel (z.B. 5 oder 30 Grad)	nein	volle Dekodierung, Drehung im Pixelraum, Neukodierung
horizontales/vertikales Spiegeln	ja	analog zur Rotation, blockweise

Der häufigste Stolperstein sind die Randblöcke. Hat ein Bild etwa 4001 Pixel Breite, passt die letzte Spalte nicht in ein volles 8x8-Raster. Bei 90- und 270-Grad-Drehungen liegen diese unvollständigen Randblöcke nach der Drehung an einer Kante, an der JPG keine Teilblöcke speichern kann. jpegtran bietet dafür die Option, diese Randpixel zu trimmen, also wenige Pixel am Rand zu verwerfen. Damit wird die Rotation verlustfrei, kostet aber einen schmalen Streifen Bild.

Verlustfrei gegen neu kodiert im Vergleich

Wie groß ist der Unterschied praktisch? Eine einzelne Neukodierung bei hoher Qualität ist kaum sichtbar. Das Problem ist die Kumulation: Jede weitere Generation rundet erneut. Die folgende Grafik zeigt, wie der relative Detailverlust über mehrere Speichergenerationen ansteigt, wenn jedes Mal neu kodiert wird, verglichen mit der verlustfreien Methode, die konstant bei null bleibt.

Die Zahlen sind als Größenordnung zu verstehen, nicht als exakte Messung. Entscheidend ist die Aussage: Verlustfrei bleibt bei null, egal wie oft du drehst. Neukodierung wächst monoton, besonders bei niedrigem Qualitätsfaktor wie 75.

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 oder toDataURL neu. Das ist technisch gesehen eine Neukodierung, kein blockweise verlustfreier Vorgang.

In der Praxis ist das selten ein Problem. Bei einem hohen Exportqualitätsfaktor liegt der Verlust einer einzelnen Generation deutlich unter der Sichtbarkeitsschwelle. Der große Vorteil von Canvas ist die Flexibilität: Es dreht auch freie Winkel, spiegelt, kombiniert Operationen und arbeitet komplett lokal im Browser, ohne Upload. Wer dagegen ein Bild zigmal nacheinander dreht und speichert, oder wer maximale Archivtreue braucht, greift für 90-Grad-Schritte besser zu einem echten jpegtran-Workflow.

Ein weiterer Punkt betrifft die Metadaten und das Farb-Subsampling. jpegtran kann beim verlustfreien Drehen die vorhandenen Exif-, ICC- und Kommentar-Blöcke erhalten oder gezielt entfernen, weil es die Datei auf Container-Ebene umbaut. Ein Canvas-Export verliert dagegen praktisch alle Metadaten, weil der Browser nur die reinen Pixel neu kodiert, das Exif-Profil und ein eventuell eingebettetes Farbprofil bleiben nicht erhalten. Für ein geradegedrehtes Schnappschuss-Foto ist das egal, für ein farbkritisches Druckbild mit hinterlegtem ICC-Profil kann es relevant sein. Auch das Chroma-Subsampling, also die Reduktion der Farbauflösung auf 4:2:0 oder 4:2:2, bleibt bei jpegtran exakt erhalten, während der Browser beim Export sein eigenes Subsampling wählt. Wer diese Feinheiten kontrollieren muss, führt 90-Grad-Drehungen über jpegtran aus und nutzt den Canvas-Weg für alles, was ohnehin eine Neuberechnung der Pixel erfordert.

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). Eine 90-Grad-Drehung mit jpegtran ordnet die Blöcke vollständig um, das Ergebnis 3024 x 4032 ist bit-identisch zur Quelle in jedem einzelnen DCT-Koeffizienten. Kein Pixel geht verloren, die Dateigröße bleibt nahezu gleich.

Jetzt nimm ein zugeschnittenes JPG mit 4001 x 3000 Pixeln. Die Breite 4001 ist nicht durch 8 teilbar. Eine 90-Grad-Drehung würde die unvollständige Randspalte an die obere oder untere Kante verschieben, wo JPG keine Teilblöcke ablegen kann. Ohne Trim verweigert jpegtran. Mit Trim verwirft das Werkzeug die überzählige eine Pixelspalte, das Ergebnis ist 3000 x 4000 und verlustfrei, abzüglich genau dieser einen Randspalte. Dieselbe Drehung im Browser-Canvas dagegen behält alle 4001 Pixel, kodiert aber neu und akzeptiert dafür einen minimalen, in der Regel unsichtbaren Generationsverlust.

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 erlaube das Trimmen, falls die Maße nicht ins Raster passen. 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. Für den täglichen Gebrauch überwiegt fast immer die Bequemlichkeit, weil der Qualitätsunterschied einer einzigen hochwertigen Neukodierung mit bloßem Auge nicht zu erkennen ist. Erst wer in einer Pipeline mehrfach dreht und neu speichert, sollte konsequent auf die blockweise verlustfreie Methode setzen.