Bildkomprimierungstool

Die Online-Bildkomprimierung verkleinert Bilddateien, damit Webseiten schneller laden, Upload-Limits leichter eingehalten werden und geteilte Bilder weniger Bandbreite verbrauchen. Die Dateien werden auf den Konvertierungsdienst von ToolAct hochgeladen und dort von serverseitigen Bibliotheken (libvips, mozjpeg, libwebp) dekodiert und neu kodiert; das komprimierte Ergebnis wird anschließend an den Browser zurückgesendet. Nach Abschluss der Konvertierung werden die hochgeladenen Dateien sofort vom Server gelöscht, nicht archiviert und nicht für Training verwendet. Je nach Format arbeitet die Komprimierung mit Qualitätsstufen, Metadaten, Farbinformationen und internen Codierungsverfahren; dadurch kann ein Foto deutlich kleiner werden, ohne dass der sichtbare Qualitätsverlust sofort auffällt. Das Werkzeug eignet sich für Blogbilder, Produktfotos, Social-Media-Grafiken, Support-Anhänge und Entwürfe, die nicht in voller Originalgröße verschickt werden müssen. Für Druckdaten, Archivkopien oder sehr feine Bilddetails sollte man jedoch prüfen, ob die gewählte Kompression zu aggressiv ist. Vermeiden Sie es, Fotos mit persönlichen Daten, interne Dokumente oder andere sensible Inhalte hochzuladen.

Die Bildkomprimierung trennt sich sauber entlang der Grenze zwischen verlustbehaftet und verlustfrei. Verlustbehaftete Formate (JPEG, WebP verlustbehaftet) nutzen die Grenzen der menschlichen Wahrnehmung aus: Das Auge ist wesentlich weniger empfindlich für hochfrequente Farbinformationen als für Helligkeit, daher werfen Encoder winzige Farbdetails in 8x8- oder 16x16-Blöcken weg, ohne dass es die meisten Betrachter bemerken. JPEG nutzt diesen DCT-basierten Pfad seit 1992; die modernen Alternativen sind mozjpeg (etwa 5-10 % kleiner als libjpeg bei gleichem SSIM, langsamerer Encoder), libwebp (Googles VP8/VP8L-Bildcodec, 2010) und AVIF (Alliance for Open Media, AV1 Intra, 2019). Verlustfreie Formate (PNG, GIF, WebP verlustfrei) verkleinern Bytes durch Entropiekodierung – LZ77-Schiebefenster-Dictionary plus Huffman- oder arithmetische Kodierung – und verändern dabei keinen einzelnen Pixel. Die hier verwendete Pipeline läuft vollständig serverseitig. Der Browser lädt jedes Bild als signierten Multipart-Upload an den Kompressions-Endpunkt von ToolAct (/image/compress) hoch. Der Server validiert die Anfrage und übergibt die Bytes an libvips – eine leistungsstarke, speicherarme Bildverarbeitungsbibliothek mit einer streamenden, bedarfsgesteuerten Pipeline. libvips dekodiert die Quelle, skaliert bei Bedarf die längere Kante, um die Ausgabegrößen zu begrenzen, und kodiert dann mit mozjpeg für JPEG, libwebp für WebP oder libpng/oxipng für PNG neu. Die kodierten Bytes werden direkt als Download-Antwort an den Browser zurückgestreamt, und die temporäre Upload-Datei wird sofort nach dem Schreiben der Antwort von der Festplatte gelöscht. Es gibt keine Archivierung, keine Trainings-Pipeline und keine menschliche Sichtung der Inhalte. Die JPEG-Quantisierung ist das Herz des Formats: Eine Qualität von 90 behält fast alle DCT-Koeffizienten, 75 beginnt mittelfrequente Koeffizienten zu verwerfen (sichtbar bei rotem Text auf Gelb), 50 ist die offensichtliche JPEG-Zone, in der Blocking-Artefakte auf glatten Verläufen erscheinen, und 25 produziert sichtbare Posterisierung auf Gesichtern. Die PNG-Komprimierung basiert auf zlib-(DEFLATE-)Stufen 0-9; Stufe 1 ist schnell, liefert aber größere Dateien, Stufe 9 presst die letzten Bytes aus flachen Farbbannern auf Kosten der CPU. EXIF-, ICC-Profile, XMP- und IPTC-Metadaten werden bei der Neukodierung standardmäßig entfernt, weil der Encoder den Header von Grund auf neu erstellt – ein reeller Grund, warum ein 200-KB-Kamerafoto zu einem 60-KB-Upload werden kann, selbst bei gleicher Auflösung, und ein Grund, warum Bildherkunft und Farbmanagement-Metadaten separat erhalten werden sollten, wenn sie wichtig sind.

• libvips (John Cupitt, LGPL) ist die serverseitige Bildverarbeitungs-Engine: eine streamende, bedarfsgesteuerte Pipeline, die selbst bei 100-MP-Eingaben einen geringen Speicherverbrauch beibehält und Sharp, das IM7-vips-Delegate von ImageMagick sowie die Konvertierungs-Endpunkte hinter diesem Tool antreibt.
• mozjpeg (Mozilla, libjpeg-turbo-Fork mit besseren psychovisuellen Modellen) produziert 5-10 % kleinere Dateien als Standard-libjpeg bei gleichem SSIM, ist aber etwa 3-5x langsamer bei der Kodierung – der Kompromiss hinter den meisten JPEG-Qualitäts-80-85-Web-Defaults seit 2017.
• PNG ist LZ77 + Huffman: Der Encoder findet wiederkehrende Bytefolgen bis zu 32 KB zurück (Schiebefenster), gibt (Distanz, Länge)-Paare aus und huffman-kodiert das Ergebnis. WebP verlustfrei (VP8L) verwendet eine ähnliche Idee plus Local-Palette-Patches und schlägt PNG typischerweise um 20-26 % bei denselben RGBA-Pixeln.
• libwebp ist Googles Referenz-Encoder/Decoder für WebP; serverseitig wird er verwendet, um entweder verlustbehaftetes VP8 (Qualität 0-100, standardmäßig 4:2:0-Chroma) oder verlustfreies VP8L (die Qualität steuert den Komprimierungsaufwand, nie die Pixeltreue) zu schreiben. WebP-Decodierung ist weit verbreitet (Chrome 32+ ab 2014, Firefox 65+ ab 2019, Safari 14+ ab 2020), sodass ein konvertiertes WebP für nahezu jeden modernen Browser sicher ist.
• Das 4:2:0-Chroma-Subsampling-Standardverfahren in JPEG (zwei Chroma-Samples pro 4 Luma) ist der Grund, warum roter Text auf gelbem Hintergrund bei Qualität 60 unscharf aussieht – die Chroma-Details werden vor den Luma-Details verworfen. Für Screenshots und UI-Aufnahmen, bei denen Textkanten wichtig sind, auf 4:4:4 (kein Subsampling) umstellen.
• EXIF (Exchangeable Image File Format, JEITA CP-3451) und ICC-Farbprofile werden bei der Neukodierung standardmäßig entfernt, sodass ein 6,3-MB-iPhone-JPEG nach der serverseitigen Bearbeitung oft bei 1,8 MB landet. Das ist der Grund, warum Verbraucherfotografen bei jedem Durchlauf durch ein Web-Tool eine Dateigrößenreduktion feststellen. Eine praktische Stapelfalle: Wenn ein Ordner kleine Icons (unter 200x200 px, PNG mit Alpha), flache UI-Screenshots (PNG, sehr hohe Komprimierbarkeit) und Handyfotos (JPEG, überwiegend rauschartige Inhalte) mischt, ist ein einzelner Qualitätsschieberegler für alle drei falsch. Icons brauchen verlustfreies PNG oder WebP verlustfrei; Screenshots brauchen 4:4:4-JPEG bei Qualität 85-90; Fotos brauchen verlustbehaftetes WebP bei Qualität 75-80. Alle bei Qualität 60 zu komprimieren spart Bytes, führt aber zu roten Rändern bei Icons, Ringing-Artefakten bei Screenshots und Banding bei Fotos. Die intelligentere Pipeline führt jede Kategorie durch einen anderen Encoder-Pfad, weshalb die Schnittstelle eine Zielformat-Überschreibung pro Datei erlaubt, selbst wenn der Benutzer einen Standard auswählt. Zukunftsweisend ist JPEG XL (ISO/IEC 18181, 2022) das Format, das Google und Cloudflare seit 2020 als JPEG-Nachfolger vorantreiben: etwa 20 % kleiner bei gleicher Qualität, vollständiger verlustfreier Modus, kein Chroma-Subsampling und eine progressive Decodierung, die für langsame Netzwerke geeignet ist. Die Browserunterstützung ist teilweise (Chrome hat JPEG XL in 110 deaktiviert), daher ist der praktische Migrationspfad vorerst WebP bei Qualität 80, AVIF für Hero-Ressourcen, die den zusätzlichen Byteaufwand rechtfertigen, und ein JPEG-Fallback für altes Safari oder ältere E-Mail-Clients. Die Seite bietet Qualität, maximale Abmessung und Zielformat als die drei relevanten Hebel; alles andere ist Implementierungsdetail.
• Serverseitiger Konvertierungs-Lebenszyklus: Jede hochgeladene Datei wird nur so lange aufbewahrt, wie es dauert, libvips-Decodierung + Neu-Kodierung auszuführen und das Ergebnis zurückzustreamen. Die temporäre Datei wird beim Schließen der Antwort gelöscht, unabhängig davon, ob die Konvertierung erfolgreich war oder fehlgeschlagen ist. Ein 24-MP-JPEG, das den Hauptthread des Renderers 200-500 ms blockiert hätte, wird vollständig außerhalb des Geräts des Benutzers verarbeitet.
• Migration: AVIF ist das Ziel der nächsten Generation (Alliance for Open Media, AV1 Intra, unterstützt 10/12-Bit, Alpha, Animation). Serverseitige AVIF-Kodierung über libavif/aom ist immer noch 10-30x langsamer als WebP, daher bleiben die meisten Seiten bei WebP bei Qualität 80 und reservieren AVIF für Hero-Fotos, die von den zusätzlichen 15-20 % Byteeinsparung profitieren.