Bildformat-Methodik

Der Bild-Cluster wandelt zwischen PNG, JPG und WebP mit der browsereigenen Canvas-API um. Es gibt keinen Upload-Schritt, keine serverseitige Verarbeitung und keinen Drittanbieter-Bilddienst im Pfad — was sich sowohl auf Datenschutz als auch auf Qualität auswirkt.

Die Umwandlungs-Pipeline

1. Der Nutzer wählt eine Datei per Drag-and-drop oder Dateiauswahl.
2. Die Datei wird über createImageBitmap(file) als ImageBitmap gelesen.
3. Ein Offscreen-Canvas wird in den nativen Maßen der Bitmap erstellt.
4. Die Bitmap wird auf das Canvas gezeichnet.
5. Das Canvas wird über canvas.toBlob(callback, mimeType, quality) exportiert — Qualität gilt nur für verlustbehaftete Ziele.
6. Der resultierende Blob wird als Download angeboten.

Jeder Schritt läuft im Browser. Die Datei wird nirgendwohin gesendet — es gibt kein fetch, kein FormData, keinen XHR-Upload. Dasselbe gilt für das Bild-zu-Base64-Werkzeug, das statt Canvas die FileReader-API verwendet, aber demselben Nur-im-Browser-Prinzip folgt.

Qualitätsbehandlung

Verlustfrei → verlustbehaftet (PNG/WebP → JPG)

Beim Wechsel von einem verlustfreien Format zu JPG stellen wir einen Qualitätsregler bereit (Standard 0,85), der die Quantisierungsaggressivität des JPG-Encoders steuert. Bei 0,85 ist die Datei für Fotos typischerweise 80–95 % kleiner als das Quell-PNG ohne wahrnehmbaren visuellen Unterschied. Unter 0,7 werden Artefakte sichtbar; wir begrenzen die Untergrenze bei 0,5, um versehentlich sichtbar verschlechterte Ausgaben zu verhindern.

Verlustbehaftet → verlustfrei (JPG → PNG)

Der Wechsel von JPG zu PNG stellt die Qualität nicht wieder her, die das JPG bereits verworfen hat. Die Ausgabe ist bitgenau das, was das JPG dekodiert hat, aber die Rundungsverluste des JPG sind fest eingebrannt. Das ist in der Praxis selten nützlich; der bessere Weg ist, eine Quelle höherer Qualität zu finden.

Verlustbehaftet → verlustbehaftet (JPG → WebP usw.)

Jedes verlustbehaftete Speichern führt neue Quantisierungsfehler zusätzlich zu den bestehenden der Quelle ein. Bei Dateien, die bereits mehrere Speichervorgänge durchlaufen haben, kann dies zu sichtbarer kumulativer Verschlechterung führen. Kodieren Sie immer aus der hochwertigsten Quelle, die Sie haben.

Was wir nicht behandeln

• HEIC / HEIF. Apples Standard seit iOS 11. Die Browserunterstützung ist außerhalb des Apple-Ökosystems im Wesentlichen null, sodass wir einen Decoder von 1+ MB bündeln müssten. Nicht lohnenswert.
• RAW-Formate (DNG, CR2, NEF, ARW). Dasselbe Problem — schwergewichtige Decoder für ein kleines Publikum. Verwenden Sie Lightroom / darktable / RawTherapee.
• SVG ↔ Raster. Über Canvas möglich, aber Vektor → Raster verliert Skalierbarkeit und der umgekehrte Weg verliert Detailtreue. Eine andere Diskussion.
• Massen-Stapelumwandlung. Unsere Oberfläche verarbeitet eine Datei nach der anderen. Für die Stapelverarbeitung verwenden Sie den REST-Endpunkt oder ein Desktop-Werkzeug.

Die Encoder-Pipeline, im Code

Die Umwandlung ist kurz genug, um sie auszuschreiben. Gegeben eine File aus einer Dateieingabe, läuft die gesamte Pipeline in etwa sechs Zeilen:

const bitmap = await createImageBitmap(file);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const ctx = canvas.getContext("2d");
ctx.drawImage(bitmap, 0, 0);
const blob = await canvas.convertToBlob({ type: "image/webp", quality: 0.85 });
// blob is the converted output, ready to download

Jeder Schritt ist browsereigen: createImageBitmap dekodiert das Quellformat (definiert im HTML Living Standard), OffscreenCanvas stellt eine nicht-rendernde Zeichenfläche bereit, und convertToBlob ruft den im Browser eingebauten WebP-/JPEG-/PNG-Encoder mit dem spezifikationsdefinierten Qualitätsparameter auf (0–1 für verlustbehaftete Formate, bei PNG ignoriert). Derselbe Encoder ist es, den Chrome zum Speichern von Canvases über toDataURL ausliefert; wir leiten das Ergebnis lediglich an einen Download statt an eine Zeichenkette weiter. Es gibt kein WASM, keine Drittanbieter-Bibliothek und keinen Netzwerkaufruf — die gesamte Pipeline läuft für eine 4K-Eingabe auf einem Laptop der Klasse 2023 in etwa 40–200 ms, wobei sich der Engpass zwischen Dekodierung (PNG-Quellen) und Kodierung (WebP-Ausgaben bei Qualität 0,85+) verschiebt.

Quellen & Referenzen

Das Kodierungsverhalten ist im HTML Living Standard für die Canvas-Serialisierung definiert. Der JPEG-Baseline-DCT stammt aus ITU-T T.81; PNG aus IETF RFC 2083; WebP aus RFC 9649. Die Qualitätssemantik — der quality-Parameter zwischen 0 und 1 für verlustbehaftete Encoder — ist in der HTML-Spezifikation normativ. Vollständige Quellen im Quellenblock unten.

Annahmen & Einschränkungen

• Eine Datei nach der anderen. Die Oberfläche nimmt eine einzige Datei pro Sitzung. Eine Massen-Neukodierung benötigt ein Skript gegen die REST-API oder ein Desktop-Werkzeug.
• Native Browser-Encoder.Die Ausgabequalität hängt vom Browser des Nutzers ab. Chromiums WebP-Encoder ist libwebp; Firefox verwendet einen eigenen. Subtile engine-spezifische Artefaktunterschiede existieren bei Qualität < 0,7.
• Keine HEIC-/HEIF-/RAW-Decodierung. Eingaben in diesen Formaten können in den meisten Browsern nicht übercreateImageBitmap geöffnet werden, ohne einen WASM-Shim, den wir nicht ausliefern.
• Keine AVIF-Kodierung. Das Lesen wird in modernen Browsern unterstützt; das Schreiben erfordert WASM (libaom), was das Bundle über eine akzeptable Größe hinaus treiben würde.
• Verlustfrei ↔ verlustbehaftet ist einseitig.Die Neukodierung eines JPG zu PNG stellt keine Information wieder her; das neu kodierte PNG ist bitgenau das dekodierte JPG, mit seinen eingebrannten Quantisierungsverlusten.
• ICC-Profil nur bei gleichformatigen Neuschreibungen erhalten. Eine formatübergreifende Umwandlung (PNG → JPG) kann das eingebettete ICC-Profil je nach Browser-Implementierung verwerfen.
• Speichergebunden. Sehr große Eingaben (40+ Megapixel) können auf mobilem Safari den Speicher erschöpfen.

Mindestanforderung an Browserunterstützung

Die WebP-Kodierung über canvas.toBloberfordert Chromium 23+, Firefox 65+, Safari 14+, Edge 79+. Stand 2026 sind das >97 % des weltweiten Traffics. Die AVIF-Kodierung wird in der Browser-Canvas-API nicht unterstützt; wir bräuchten einen WASM-Encoder, um dieses Ziel auszuliefern, was Roadmap-Material ist.