Diese Seite wurde von der Cloud Translation API übersetzt.

Häufig gestellte Fragen

Was ist WebP? Warum sollte ich dieses Format verwenden?

WebP ist eine Methode für verlustbehaftete und verlustfreie Kompression, die für eine Vielzahl von fotografischen, durchscheinenden und grafischen Bildern im Web verwendet werden kann. Der Grad der verlustbehafteten Kompression lässt sich anpassen, sodass der Nutzer einen Kompromiss zwischen Dateigröße und Bildqualität auswählen kann. WebP erreicht in der Regel eine durchschnittlich 30% höhere Komprimierung als JPEG und JPEG 2000 ohne Bildqualität (siehe Vergleichsstudie).

Das WebP-Format zielt im Wesentlichen darauf ab, kleinere, besser aussehende Bilder zu erstellen, die dazu beitragen können, das Web schneller zu machen.

Welche Webbrowser unterstützen WebP nativ?

Webmaster, die die Websiteleistung verbessern möchten, können ganz einfach optimierte WebP-Alternativen für ihre aktuellen Bilder erstellen und sie gezielt an Browser liefern, die WebP unterstützen.

Verlustfreier WebP-Support
- Google Chrome (Desktop) 17+
- Google Chrome für Android ab Version 25
- Microsoft Edge 18 und höher
- Firefox 65 oder höher
- Opera 11.10 oder höher
- Nativer Webbrowser, Android 4.0 und höher (ICS)
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur+)
WebP-Verlust, verlustfreie und Alpha-Unterstützung
- Google Chrome (Desktop) 23 und höher
- Google Chrome für Android ab Version 25
- Microsoft Edge 18 und höher
- Firefox 65 oder höher
- Opera 12.10 oder höher
- Nativer Webbrowser, Android 4.2 und höher (JB-MR1)
- Blasser Mond 26+
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur+)
Unterstützung von WebP Animation
- Google Chrome (Desktop und Android) 32+
- Microsoft Edge 18 und höher
- Firefox 65 oder höher
- Opera 19 oder höher
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur+)

Weitere Informationen

Wie erkenne ich die Browserunterstützung für WebP?

Sie sollten WebP-Bilder nur für Clients bereitstellen, die sie richtig anzeigen können, und für ältere Clients ein Legacy-Format verwenden. Glücklicherweise gibt es mehrere Methoden, um die WebP-Unterstützung sowohl auf der Client- als auch auf der Serverseite zu erkennen. Einige CDN-Anbieter bieten die Unterstützung der WebP-Unterstützung als Teil ihres Dienstes an.

Verhandlung von serverseitigen Inhalten über „Accept“-Header

Webclients senden normalerweise einen „Accept“-Anfrageheader, mit dem angegeben wird, welche Inhaltsformate sie als Antwort akzeptieren. Wenn ein Browser im Voraus angibt, dass er das Format image/webp akzeptiert, weiß der Webserver, dass er WebP-Bilder sicher senden kann. Dies vereinfacht die Inhaltsverhandlung. Weitere Informationen finden Sie unter den folgenden Links.

Modernisierer

Modernizr ist eine JavaScript-Bibliothek zur bequemen Erkennung von HTML5- und CSS3-Features in Webbrowsern. Suchen Sie die Attribute Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha und Modernizr.webp.animation.

HTML5-Element `<picture>`

HTML5 unterstützt ein <picture>-Element, mit dem Sie mehrere alternative Bildziele in der Reihenfolge ihrer Priorität auflisten können. Ein Client fordert dann das erste mögliche Bild an, das korrekt angezeigt werden kann. Weitere Informationen finden Sie in dieser Diskussion zu HTML5-Rocks. Das Element <picture> wird von immer mehr Browsern unterstützt.

Im eigenen JavaScript

Eine weitere Erkennungsmethode besteht darin, ein sehr kleines WebP-Bild, das eine bestimmte Funktion verwendet, zu decodieren und auf Erfolg zu prüfen. Beispiel:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Das Laden von Bildern ist nicht blockierend und asynchron. Das bedeutet, dass Code, der von der WebP-Unterstützung abhängt, vorzugsweise in die Callback-Funktion gesetzt werden sollte.

Warum hat Google WebP als Open Source veröffentlicht?

Wir sind von der Bedeutung des Open-Source-Modells überzeugt. Mit WebP im Open-Source-Format kann jeder mit dem Format arbeiten und Verbesserungsvorschläge machen. Wir sind der Meinung, dass WebP mit Ihren Eingaben und Vorschlägen als Grafikformat im Laufe der Zeit noch nützlicher wird.

Wie konvertiere ich meine persönlichen Bilddateien in WebP?

Sie können das WebP-Befehlszeilentool verwenden, um Ihre persönlichen Bilddateien in das WebP-Format zu konvertieren. Weitere Informationen finden Sie unter WebP verwenden.

Wenn Sie viele Bilder konvertieren müssen, können Sie die Shell der Plattform verwenden, um den Vorgang zu vereinfachen. So können Sie beispielsweise alle JPEG-Dateien in einem Ordner konvertieren:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Wie kann ich die Bildqualität für WebP selbst beurteilen?

Derzeit können Sie WebP-Dateien ansehen. Dazu konvertieren Sie sie in ein gängiges Format mit verlustfreier Komprimierung wie PNG und können die PNG-Dateien dann in einem beliebigen Browser oder Bildbetrachter ansehen. Einen Überblick über die Qualität von WebP erhalten Sie in der Galerie auf dieser Website.

Wie erhalte ich den Quellcode?

Der Konvertierungscode ist im Downloadbereich der WebP-Open-Source-Projektseite verfügbar. Den Code für den einfachen Decoder und die VP8-Spezifikation finden Sie auf der WebM-Website. Die Containerspezifikation finden Sie auf der Seite RIFF-Container.

Wie groß darf ein WebP-Bild maximal sein?

WebP ist Bitstream-kompatibel mit VP8 und verwendet 14 Bit für Breite und Höhe. Die maximale Pixelgröße eines WebP-Bilds beträgt 16383 x 16383.

Welche Farbräume werden vom WebP-Format unterstützt?

In Übereinstimmung mit dem VP8-Bitstream funktioniert verlustbehaftetes WebP ausschließlich mit einem 8-Bit-Bildformat Y'CbCr 4:2:0 (häufig als YUV420 bezeichnet). Weitere Informationen finden Sie in Abschnitt 2, Formatübersicht von RFC 6386, VP8-Datenformat und Decodierungsleitfaden.

Verlustloses WebP funktioniert ausschließlich im RGBA-Format. Weitere Informationen finden Sie in der verlustfreien Bitstream-Spezifikation von WebP.

Kann ein WebP-Bild größer werden als sein Quell-Image?

Ja, in der Regel bei der Umwandlung von einem verlustbehafteten Format in WebP-verlustfrei oder umgekehrt. Das liegt vor allem an dem Unterschied zwischen Farbräumen (YUV420 und ARGB) und der Konvertierung zwischen diesen.

Es gibt drei typische Situationen:

Wenn das Quellbild im verlustfreien ARGB-Format vorliegt, führt das räumliche Downsampling in YUV420 zu neuen Farben, die schwerer zu komprimieren sind als die ursprünglichen. Das kann in der Regel passieren, wenn die Quelle im PNG-Format mit wenigen Farben vorliegt. Die Konvertierung in eine verlustbehaftete WebP-Datei (oder ähnlich wie eine verlustbehaftete JPEG-Datei) führt möglicherweise zu einer größeren Dateigröße.
Wenn die Quelle im verlustbehafteten Format vorliegt, führt die Verwendung einer verlustfreien WebP-Komprimierung zum Erfassen der verlustbehafteten Art der Quelle in der Regel zu einer größeren Datei. Dies ist nicht nur für WebP relevant und kann auftreten, wenn beispielsweise eine JPEG-Quelle in verlustfreie WebP- oder PNG-Formate konvertiert wird.
Wenn die Quelle im verlustbehafteten Format vorliegt und Sie versuchen, sie als verlustbehaftetes WebP mit höherer Qualität zu komprimieren. Beispielsweise wird bei der Konvertierung einer JPEG-Datei mit der Qualität 80 in eine WebP-Datei mit der Qualität 95 normalerweise eine größere Datei erstellt, selbst wenn beide Formate verlustbehaftet sind. Es ist oft nicht möglich, die Qualität der Quelle zu beurteilen. Wenn die Dateigröße konstant größer ist, wird daher empfohlen, die WebP-Zielqualität zu senken. Eine weitere Möglichkeit besteht darin, die Qualitätseinstellung zu vermeiden und stattdessen eine bestimmte Dateigröße mit der Option -size im cwebp-Tool oder der entsprechenden API festzulegen. Beispielsweise kann die Ausrichtung auf 80% der Originaldatei robuster sein.

Beachten Sie, dass die Konvertierung einer JPEG-Quelle in eine verlustbehaftete WebP- oder eine PNG-Quelle in eine verlustfreie WebP-Datei nicht anfällig für derartige Dateigrößenüberraschungen ist.

Unterstützt WebP die progressive Anzeige oder die Zeilensprungdarstellung?

WebP bietet keine progressive oder verschachtelte Decodierungsaktualisierung im JPEG- oder PNG- Sinne. Dadurch wird die CPU und der Arbeitsspeicher des Decodierungsclients zu stark beansprucht, da jedes Aktualisierungsereignis einen vollständigen Durchlauf des Dekomprimierungssystems erfordert.

Das Decodieren eines progressiven JPEG-Bildes entspricht im Durchschnitt dem dreimaligen Decodieren der baseline.

Alternativ bietet WebP eine inkrementelle Decodierung, bei der alle verfügbaren eingehenden Byte des Bitstreams verwendet werden, um so schnell wie möglich eine anzeigbare Beispielzeile zu erstellen. Dies spart sowohl Arbeitsspeicher- als auch CPU- und Maleraufwand auf dem Client und bietet visuelle Hinweise auf den Downloadstatus. Die inkrementelle Decodierungsfunktion ist über die Advanced Decoding API verfügbar.

Wie verwende ich die libwebp-Java-Bindungen in meinem Android-Projekt?

WebP unterstützt JNI-Bindungen an die einfachen Encoder- und Decoder-Schnittstellen im Verzeichnis swig/.

Erstellen der Bibliothek in Eclipse:

Achte darauf, dass das ADT-Plug-in zusammen mit den NDK-Tools installiert und der NDK-Pfad korrekt festgelegt ist (Einstellungen > Android > NDK).
Erstellen Sie ein neues Projekt: Datei > Neu > Projekt > Android-Anwendungsprojekt.
Klonen Sie im neuen Projekt in einen Ordner namens jni oder entpacken Sie libwebp.
Fügen Sie swig/libwebp_java_wrap.c zur Liste LOCAL_SRC_FILES hinzu.
Klicken Sie mit der rechten Maustaste auf das neue Projekt und wählen Sie Android Tools > Add Native Support ... (Native Tools hinzufügen) aus, um die Bibliothek in Ihren Build aufzunehmen.
Öffnen Sie die Projekteigenschaften und wählen Sie C/C++ Build > Verhalten aus. Fügen Sie dem Abschnitt Build (Incremental build) ENABLE_SHARED=1 hinzu, um libwebp als freigegebene Bibliothek zu erstellen.

Hinweis: Wenn Sie NDK_TOOLCHAIN_VERSION=4.8 festlegen, wird die 32-Bit-Build-Leistung im Allgemeinen verbessert.
Fügen Sie swig/libwebp.jar zum Projektordner libs/ hinzu.
Erstellen Sie Ihr Projekt. Dadurch wird libs/<target-arch>/libwebp.so erstellt.
Verwenden Sie System.loadLibrary("webp"), um die Bibliothek zur Laufzeit zu laden.

Die Bibliothek kann manuell mit ndk-build und dem enthaltenen Android.mk erstellt werden. In diesem Fall können einige der oben beschriebenen Schritte wiederverwendet werden.

Wie verwende ich libwebp mit C#?

WebP kann als DLL erstellt werden, die die libwebp API exportiert. Diese Funktionen können dann in C# importiert werden.

libwebp.dll erstellen Dadurch wird WEBP_EXTERN korrekt für das Exportieren der API-Funktionen festgelegt.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Fügen Sie Ihrem Projekt libwebp.dll hinzu und importieren Sie die gewünschten Funktionen. Wenn Sie die einfache API verwenden, sollten Sie WebPFree() aufrufen, um zurückgegebene Puffer freizugeben.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Warum sollte ich die animierte WebP-Funktion verwenden?

Vorteile von animiertem WebP im Vergleich zu animierten GIFs

WebP unterstützt die 24-Bit-RGB-Farbe mit einem 8-Bit-Alphakanal im Vergleich zu der 8-Bit-Alpha- und 1-Bit-Alpha-Version von GIF.
WebP unterstützt sowohl verlustbehaftete als auch verlustfreie Komprimierung. Tatsächlich kann eine einzelne Animation verlustbehaftete und verlustfreie Frames kombinieren. GIF unterstützt nur verlustfreie Komprimierung. Die verlustbehafteten Kompressionstechniken von WebP eignen sich gut für animierte Bilder, die aus realen Videos erstellt werden, einer immer beliebteren Quelle für animierte Bilder.
WebP erfordert weniger Byte als GIF¹. Animierte GIFs, die in verlustbehaftete WebPs umgewandelt wurden, sind um 64% kleiner und verlustfreie WebPs um 19% kleiner. Das ist insbesondere in Mobilfunknetzen wichtig.
WebP entschlüsselt bei einer Suche weniger Zeit. In Blinken können durch Scrollen oder Wechseln von Tabs Bilder ein- und ausgeblendet werden. Dabei werden die Animationen pausiert und dann an einem anderen Punkt fortgesetzt. Bei einer übermäßigen CPU-Nutzung, die dazu führt, dass Animationen Frames verlieren, kann der Decoder auch in der Animation zum Vorwärtsspringen springen. In diesen Szenarien benötigt der animierte WebP insgesamt eine 0, 57-mal höhere Dekodierungszeit² als GIF, was zu weniger Verzögerungen beim Scrollen und einer schnelleren Wiederherstellung bei Spitzen bei der CPU-Auslastung führt. Dies liegt an zwei Vorteilen von WebP gegenüber GIF:
- WebP-Bilder speichern Metadaten darüber, ob jeder Frame Alpha enthält. Dadurch ist es nicht mehr erforderlich, den Frame zu decodieren, um diese Bestimmung zu treffen. Dies führt zu einer genaueren Inferenz, von der vorherige Frames eines bestimmten Frames abhängen, wodurch eine unnötige Decodierung vorheriger Frames reduziert wird.
- Ähnlich wie bei einem modernen Video-Encoder fügt der WebP-Encoder Keyframes in regelmäßigen Abständen hinzu (was bei den meisten GIF-Encodern nicht der Fall ist). Dadurch wird die Suche bei langen Animationen erheblich verbessert. Damit das Einfügen solcher Frames ohne signifikante Bildgröße möglich ist, fügt WebP zusätzlich zu dem von GIF verwendeten Frame-Entsorgungsverfahren das Flag blend method für jeden Frame hinzu. Dadurch kann ein Keyframe so gezeichnet werden, als ob das gesamte Bild in die Hintergrundfarbe umgewandelt worden wäre, ohne dass der vorherige Frame in Originalgröße dargestellt wird.

Nachteile von animiertem WebP im Vergleich zu animierten GIFs

Wenn keine Suche erfolgt, ist die direkte Decodierung von WebP CPU-intensiver als GIF-Dateien. Der verlustbehaftete WebP benötigt 2,2-mal mehr Decodierungszeit als GIF, der verlustfreie WebP 1,5-mal so viel.
Die WebP-Unterstützung ist nicht annähernd so groß wie die Unterstützung für GIFs, die praktisch universell ist.
Durch die Einbindung der WebP-Unterstützung zu Browsern erhöht sich der Codebedarf und die Angriffsfläche. In Blink sind dies ca. 1.500 zusätzliche Codezeilen (einschließlich der WebP-Demux-Bibliothek und des Blink-WebP-Bild-Decodierers). Beachten Sie, dass dieses Problem in Zukunft verringert werden kann, wenn WebP und WebM einen gemeinsamen Decodierungscode verwenden oder wenn die Funktionen von WebP in den WebM-Funktionen zusammengefasst werden.

Warum wird WebM in <img> nicht einfach unterstützt?

Es kann sinnvoll sein, Videoformate innerhalb des <img>-Tags langfristig zu unterstützen. Dies ist jetzt jedoch problematisch, da WebM in <img> die vorgeschlagene Rolle des animierten WebP übernehmen kann:

Beim Decodieren eines Frames, der auf vorherigen Frames basiert, benötigt WebM 50% mehr Arbeitsspeicher als animiertes WebP, um die Mindestanzahl von vorherigen Frames zu speichern.³
Die Unterstützung von Video-Codec und -Container variiert je nach Browser und Gerät erheblich. Um die automatische Transcodierung von Inhalten zu ermöglichen (z.B. für Proxys, die Bandbreite sparen), müssen Browser Header hinzufügen, die angeben, welche Formate ihre Bild-Tags unterstützen. Auch das kann unter Umständen nicht ausreichend sein, da MIME-Typen wie "video/webm" oder "video/mpeg" immer noch nicht auf die Codec-Unterstützung hinweisen (z.B. VP8 vs. VP9). Andererseits ist das WebP-Format effektiv eingefroren. Wenn Anbieter, die es anbieten, dem animierten WebP zustimmen, sollte das Verhalten von WebP in allen UAs konsistent sein. Da der „image/webp“-Annahmeheader bereits verwendet wird, um die WebP-Unterstützung anzugeben, sind keine neuen Änderungen am Header erforderlich.
Der Chromium-Videostack ist für eine reibungslose Wiedergabe optimiert und es wird davon ausgegangen, dass nur ein oder zwei Videos gleichzeitig wiedergegeben werden. Die Implementierung von Systemressourcen (Threads, Arbeitsspeicher usw.) zur Steigerung der Wiedergabequalität ist daher sehr aufwendig. Eine solche Implementierung lässt sich nicht auf viele Videos gleichzeitig skalieren und muss neu gestaltet werden, damit sie für Webseiten mit vielen Bildern geeignet ist.
WebM umfasst derzeit nicht alle Komprimierungstechniken von WebP. Deshalb wird dieses Bild mit WebP erheblich besser komprimiert als mit den Alternativen:

¹ Für alle Vergleiche zwischen animierten GIFs und animierten WebPs haben wir einen Korpus von etwa 7.000 animierten GIFs nach dem Zufallsprinzip aus dem Web verwendet. Diese Bilder wurden mit dem Tool „gif2webp“ unter Verwendung der Standardeinstellungen in eine animierte WebP-Datei konvertiert. Diese wurde aus der neuesten libwebp-Quellstruktur vom 08.10.2013 erstellt. Die Vergleichszahlen sind die Durchschnittswerte für diese Bilder.

² Die Decodierungszeiten wurden mit dem neuesten libwebp + ToT Blink mit dem Benchmark-Tool vom 08.10.2013 berechnet. „Zeit zum Suchen decodieren“ wird berechnet als „Decodieren der ersten fünf Frames“, Leeren des Frame-Zwischenspeichercaches, Decodieren der nächsten fünf Frames usw.

³ WebM speichert 4 YUV-Referenzframes im Arbeitsspeicher, wobei jeder Frame (Breite + 96) × (Höhe + 96) Pixel gespeichert wird. Für YUV 4:2:0 benötigen wir 4 Byte pro 6 Pixel (oder 3/2 Byte pro Pixel). Diese Referenzframes verwenden also 4*3/2*(width+96)*(height+96) Byte Arbeitsspeicher. WebP muss hingegen nur den vorherigen Frame (in RGBA) haben, also 4*width*height Byte an Arbeitsspeicher.

⁴ Für das animierte WebP-Rendering ist Google Chrome 32 oder höher erforderlich.