Bilder und Fotos · Bildkonverter und Kompressor
Wie canvas.toBlob PNG in Ihrem Browser in WebP konvertiert
· Wie es funktioniert
Bildformate Leinwand webp
Ein Browser-Bildkonverter besteht aus einem Decoder, einer Bitmap und einem Encoder, die miteinander verkettet sind, und die gesamte Kette ist in den Browser integriert. Dieser Beitrag folgt einem PNG über Decode, Canvas und toBlob zu einer WebP-Datei und notiert, was auf dem Weg verloren geht.
Woher kommt das WebP, wenn kein Server beteiligt ist – die konkrete Frage hinter einem Konverter, der offline funktioniert
Das WebP stammt nicht aus einer serverseitigen Konvertierungswarteschlange. Ihr Browser verfügt bereits über Bilddecoder, eine zeichnbare Pixeloberfläche und Encoder. Der ToolAcre-Konverter verbindet sie. Aus diesem Grund kann ein PNG in Ihrem Tab umgewandelt werden, nachdem die Site geladen wurde. „Kein Upload“ bezieht sich auf das Quellbild und die Konvertierungsausgabe, nicht darauf, dass die Website überhaupt keine Netzwerkaktivität aufweist.
Schritt eins: Dekodierung – wie der Browser PNG-Bytes in eine RGBA-Bitmap umwandelt und warum jedes Format am Ende das gleiche Raster hat
Zuerst wird das PNG in eine Bild-Bitmap dekodiert. PNG-Komprimierung, Palettenauswahl und Farbmetadaten bestimmen, wie seine Bytes zu Pixeln werden, aber die Leinwand funktioniert auf dem dekodierten Raster, nicht auf Teilen der PNG-Datei. Ein 1600×900-Screenshot ergibt 1.44 Millionen Pixelpositionen, selbst wenn die Datei selbst viel kleiner ist. ToolAcre verwendet createImageBitmap und erzwingt ein Pixelbudget; Ein großes dekodiertes Bild ist ein Speicherproblem, bevor es ein Upload-Problem ist.
Schritt zwei: Die Leinwand als Bereitstellungsbereich – Zeichnen der Bitmap auf eine Leinwand oder OffscreenCanvas mit passenden Abmessungen
Die Bitmap wird mit den gewünschten Ausgabeabmessungen in eine Leinwand oder OffscreenCanvas gezeichnet. Wenn diese Abmessungen mit der Quelle übereinstimmen und kein Zuschnitt ausgewählt ist, stellt drawImage die Pixel für die Kodierung bereit. Wenn sich die Abmessungen ändern, werden sie von der Leinwand neu abgetastet und die Pixelwerte können sich ändern, bevor die WebP-Kodierung beginnt. Dieselbe Renderroutine bedient die interaktive Vorschau und den Worker-Pfad und verhindert so, dass diese beiden Ausgaben unabhängigen Algorithmen folgen.
Schritt drei: toBlob mit einem MIME-Typ und einer MIME-Qualität – wie der Encoder ausgewählt wird, was die Qualitätszahl steuert und warum sie für PNG ignoriert wird
Auf einer gewöhnlichen Leinwand fordert toBlob(callback, "image/webp", quality) den Browser auf, WebP zu kodieren und ruft mit einem Blob zurück. Wenn OffscreenCanvas verfügbar ist, verwendet ToolAcre „convertToBlob({type,quality})“ für denselben Job. Die Qualität kontrolliert einen verlustbehafteten Encoder. es ist kein Versprechen einer bestimmten Byteanzahl. Der PNG-Export ist verlustfrei und sein Qualitätsparameter legt keine JPEG-ähnliche Komprimierungsstufe fest. Überprüfen Sie immer das tatsächlich zurückgegebene Format, da die Verfügbarkeit des Encoders vom Browser abhängt.
Was die Pipeline verwirft – Metadaten, Farbprofile und 16-Bit-Präzision, und warum dies eher eine Eigenschaft der Technik als ein Fehler ist
Durch die Neukodierung eines dekodierten Rasters können nicht alle Fakten im ursprünglichen PNG-Container erhalten bleiben. Textblöcke, Kamera- oder Editor-Metadaten, einige Farbprofildetails und die Bittiefe der Quelle überstehen möglicherweise einen Canvas-Roundtrip nicht; 16-Bit-Kanäle werden nicht zu einem 16-Bit-WebP, nur weil die Eingabe sie übertragen hat. WebP kann die Transparenz beibehalten, wenn der Encoder dies unterstützt, wohingegen ein JPEG-Export das Füllen transparenter Bereiche erfordert. Die Dateigröße allein kann nicht zeigen, ob bei einer Konvertierung feine Linien oder Farben erhalten geblieben sind.
Arbeitsbeispiel: ein 1.8 MB PNG-Screenshot für WebP – Verfolgen Sie die Datei durch die drei Schritte und lesen Sie das Ergebnis
Betrachten Sie einen 1.8 MB PNG-Screenshot mit Text, Farbverläufen und einer transparenten Ecke. Dekodieren Sie es, lassen Sie die Abmessungen unverändert, wählen Sie WebP aus, exportieren Sie es und vergleichen Sie die Blob-Größe und den MIME-Typ mit dem Original. Die resultierende Größe ist gemessen und nicht vorhersehbar: Saubere Screenshots lassen sich möglicherweise gut komprimieren, verrauschte Inhalte dagegen möglicherweise nicht. Zoomen Sie in kleine Glyphen und die transparente Ecke, bevor Sie die kleinere Datei akzeptieren. Wenn scharfer UI-Text unscharf wird, behalten Sie PNG bei oder passen Sie die Encoderqualität an, anstatt zu behaupten, dass WebP immer besser ist.
Was dies nicht abdeckt – animierte Bilder, Formate, die der Browser nicht dekodieren kann, und Encoder-Einstellungen, die die API nicht offenlegt
Diese Pipeline verspricht keine Animationserhaltung, HEIC-Dekodierung auf jedem Gerät oder vollständige Kontrolle über die Subsampling- und Aufwandsparameter des WebP-Encoders. Es ist auch nicht möglich, in einer JPEG-Quelle bereits verlorene Details durch Speichern als PNG oder WebP wiederherzustellen. Wiederholte Dekodier-/Neukodierungszyklen können zu Verlusten führen. Behalten Sie ein Original und verwenden Sie die unterstützten Eingabe-/Ausgabeformate, die auf der eigentlichen Tool-Seite aufgeführt sind, anstatt davon auszugehen, dass jedes Format, das Ihr Betriebssystem kennt, hier akzeptiert wird.
Fazit: Drei Schritte, keine Uploads – wie der Image Converter & Compressor diese Pipeline auf Ihrem Gerät ausführt
Der Mechanismus ist Dekodieren → Zeichnen → Kodieren, ausgeführt mit Browser-APIs und ohne Bild-Upload. ToolAcre stellt das Zielformat und die Zielabmessungen bereit, sodass Sie erkennen können, ob Sie lediglich den Container ändern oder auch die Größe der Pixel ändern. Testen Sie einen repräsentativen Screenshot im Bildkonverter und -kompressor, bevor Sie einen ganzen Stapel verarbeiten, und überprüfen Sie dann das heruntergeladene Ergebnis in der für die Leute sichtbaren Größe.