Diese Seite wurde von der Cloud Translation API übersetzt.

Häufig gestellte Fragen

Was ist WebP? Warum sollte ich die Funktion verwenden?

WebP ist eine Methode zur verlustbehafteten und verlustfreien Komprimierung, die für eine Vielzahl von Fotos, transparenten Bildern und Grafiken im Web verwendet werden kann. Der Grad der verlustbehafteten Komprimierung ist anpassbar, sodass ein Nutzer den Kompromiss zwischen Dateigröße und Bildqualität wählen kann. WebP bietet in der Regel eine durchschnittlich 30% höhere Komprimierung als JPEG und JPEG 2000, ohne dass die Bildqualität darunter leidet (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 Leistung ihrer Website verbessern möchten, können ganz einfach optimierte WebP-Alternativen für ihre aktuellen Bilder erstellen und sie gezielt für Browser bereitstellen, die WebP unterstützen.

Unterstützung für verlustbehaftete WebP-Bilder
- Google Chrome (Desktop) 17+
- Google Chrome für Android ab Version 25
- Microsoft Edge (ab 18 Jahren)
- Firefox (ab Version 65)
- Opera 11.10+
- Nativer Webbrowser, Android 4.0+ (ICS)
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur und höher)
WebP-Unterstützung für verlustbehaftete und verlustfreie Komprimierung sowie Alphatransparenz
- Google Chrome (Desktop) 23+
- Google Chrome für Android ab Version 25
- Microsoft Edge (ab 18 Jahren)
- Firefox (ab Version 65)
- Opera 12.10 und höher
- Nativer Webbrowser, Android 4.2+ (JB-MR1)
- Pale Moon 26+
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur und höher)
Unterstützung von WebP-Animationen
- Google Chrome (Desktop und Android) 32+
- Microsoft Edge (ab 18 Jahren)
- Firefox (ab Version 65)
- Opera 19+
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur und höher)

Siehe auch:

Wie kann ich die Browserunterstützung für WebP erkennen?

WebP-Bilder sollten nur für Clients bereitgestellt werden, die sie richtig anzeigen können. Für Clients, die das nicht können, sollten Sie auf Legacy-Formate zurückgreifen. Glücklicherweise gibt es mehrere Techniken zum Erkennen der WebP-Unterstützung, sowohl auf Client- als auch auf Serverseite. Einige CDN-Anbieter bieten die Erkennung der WebP-Unterstützung als Teil ihres Dienstes an.

Serverseitige Inhaltsaushandlung über Accept-Header

Webclients senden häufig einen „Accept“-Anfrageheader, der angibt, welche Inhaltsformate sie in der 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. Das vereinfacht die Inhaltsaushandlung erheblich. Weitere Informationen finden Sie unter den folgenden Links.

Modernizr

Modernizr ist eine JavaScript-Bibliothek, mit der sich die Unterstützung von HTML5- und CSS3-Funktionen in Webbrowsern bequem erkennen lässt. Suchen Sie nach den Eigenschaften Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha und Modernizr.webp.animation.

HTML5-Element `<picture>`

HTML5 unterstützt das <picture>-Element, mit dem Sie mehrere alternative Bildziele in Prioritätsreihenfolge auflisten können. Ein Client fordert dann das erste Kandidatenbild an, das er richtig darstellen kann. Weitere Informationen Das <picture>-Element wird von immer mehr Browsern unterstützt.

In Ihrem eigenen JavaScript

Eine weitere Erkennungsmethode besteht darin, ein sehr kleines WebP-Bild zu dekodieren, das eine bestimmte Funktion verwendet, und zu prüfen, ob dies erfolgreich war. 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 erfolgt nicht blockierend und asynchron. Das bedeutet, dass jeder Code, der von der WebP-Unterstützung abhängt, vorzugsweise in die Callback-Funktion eingefügt werden sollte.

Warum hat Google WebP als Open Source veröffentlicht?

Wir sind von der Bedeutung des Open-Source-Modells überzeugt. Da WebP Open Source ist, kann jeder mit dem Format arbeiten und Verbesserungen vorschlagen. Wir sind davon überzeugt, dass WebP durch Ihr Feedback und Ihre Vorschläge im Laufe der Zeit noch nützlicher als Grafikformat werden wird.

Wie kann ich meine persönlichen Bilddateien in WebP konvertieren?

Mit dem WebP-Befehlszeilenprogramm können Sie Ihre persönlichen Bilddateien in das WebP-Format konvertieren. Weitere Informationen finden Sie unter WebP verwenden.

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

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 von WebP-Bildern selbst beurteilen?

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

Wie erhalte ich den Quellcode?

Der Konvertercode ist auf der Seite des WebP-Open-Source-Projekts im Downloadbereich verfügbar. Der Code für den Lightweight-Decoder und die VP8-Spezifikation sind auf der WebM-Website verfügbar. 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 Bits für Breite und Höhe. Die maximalen Pixelabmessungen eines WebP-Bildes betragen 16.383 × 16.383.

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

Wie der VP8-Bitstream funktioniert WebP mit Verlust ausschließlich mit einem 8‑Bit-Y'CbCr-4:2:0-Bildformat (oft als YUV420 bezeichnet). Weitere Informationen finden Sie in Abschnitt 2, Format Overview, von RFC 6386, VP8 Data Format and Decoding Guide.

Lossless WebP funktioniert ausschließlich mit dem RGBA-Format. Weitere Informationen finden Sie in der WebP Lossless Bitstream-Spezifikation.

Warum unterscheidet sich meine verlustfreie WebP-Datei vom Original?

Die Funktionen der Simple Encoding API (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) verwenden die Standardeinstellungen der Bibliothek. Bei verlustfreier Komprimierung ist „Exakt“ deaktiviert. RGB-Werte in vollständig transparenten Bereichen (d. h. Bereichen mit Alphawerten gleich 0) werden zur Verbesserung der Komprimierung geändert. Um dies zu vermeiden, verwenden Sie WebPEncode() und setzen Sie WebPConfig::exact auf 1. Weitere Informationen finden Sie in der Dokumentation zur Advanced Encoding API.

Kann ein WebP-Bild größer als das zugehörige Quellbild sein?

Ja, in der Regel bei der Konvertierung von einem verlustbehafteten Format in WebP Lossless oder umgekehrt. Das liegt hauptsächlich am Unterschied zwischen den Farbräumen (YUV420 und ARGB) und der Konvertierung zwischen ihnen.

Es gibt drei typische Situationen:

Wenn das Quellbild im verlustfreien ARGB-Format vorliegt, werden durch das räumliche Downsampling auf YUV420 neue Farben eingeführt, die sich schwieriger komprimieren lassen als die ursprünglichen. Das kann passieren, wenn die Quelle im PNG-Format mit wenigen Farben vorliegt: Die Konvertierung in das verlustbehaftete WebP-Format (oder in ein verlustbehaftetes JPEG) kann zu einer größeren Dateigröße führen.
Wenn die Quelle in einem verlustbehafteten Format vorliegt, führt die Verwendung der verlustfreien WebP-Komprimierung zur Erfassung der verlustbehafteten Natur der Quelle in der Regel zu einer größeren Datei. Das ist nicht spezifisch für WebP, sondern kann beispielsweise auch beim Konvertieren einer JPEG-Quelle in verlustfreies WebP oder PNG auftreten.
Wenn die Quelle in einem verlustbehafteten Format vorliegt und Sie versuchen, sie als verlustbehaftetes WebP mit einer höheren Qualitätseinstellung zu komprimieren. Wenn Sie beispielsweise versuchen, eine JPEG-Datei mit der Qualitätsstufe 80 in eine WebP-Datei mit der Qualitätsstufe 95 zu konvertieren, ist die resultierende Datei in der Regel größer, auch wenn beide Formate verlustbehaftet sind. Die Qualität der Quelle lässt sich oft nicht beurteilen. Daher empfiehlt es sich, die WebP-Zielqualität zu verringern, wenn die Dateigröße durchgehend größer ist. Eine weitere Möglichkeit besteht darin, die Qualitätseinstellung zu vermeiden und stattdessen mit der Option -size im cwebp-Tool oder der entsprechenden API auf eine bestimmte Dateigröße auszurichten. Eine Zielgröße von 80% der ursprünglichen Dateigröße kann beispielsweise robuster sein.

Wenn Sie eine JPEG-Quelle in verlustbehaftetes WebP oder eine PNG-Quelle in verlustfreies WebP konvertieren, ist die Dateigröße in der Regel nicht überraschend.

Unterstützt WebP die progressive oder Interlaced-Anzeige?

WebP bietet keine progressive oder verschachtelte Dekodierungsaktualisierung wie JPEG oder PNG. Dies führt wahrscheinlich zu einer zu hohen Belastung der CPU und des Arbeitsspeichers des Decodierungsclients, da bei jedem Aktualisierungsereignis ein vollständiger Durchlauf des Dekompressionssystems erfolgt.

Im Durchschnitt entspricht das Decodieren eines progressiven JPEG-Bildes dem dreimaligen Decodieren des Baseline-Bildes.

Alternativ bietet WebP die inkrementelle Decodierung, bei der alle verfügbaren eingehenden Bytes des Bitstreams verwendet werden, um so schnell wie möglich eine darstellbare Beispielzeile zu erzeugen. Das spart Arbeitsspeicher, CPU und Aufwand für das erneute Rendern auf dem Client und bietet gleichzeitig visuelle Hinweise zum Downloadstatus. Die Funktion für inkrementelles Decodieren ist über die Advanced Decoding API verfügbar.

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

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

Bibliothek in Eclipse erstellen:

Achten Sie darauf, dass das ADT-Plug-in zusammen mit den NDK-Tools installiert ist und der NDK-Pfad korrekt festgelegt ist (Einstellungen > Android > NDK).
Erstellen Sie ein neues Projekt: File > New > Project > Android Application Project (Datei > Neu > Projekt > Android-Anwendungsprojekt).
Klonen Sie libwebp oder entpacken Sie es in einem Ordner namens jni im neuen Projekt.
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 Unterstützung hinzufügen…) aus, um die Bibliothek in Ihren Build einzuschließen.
Öffnen Sie die Projekteigenschaften und rufen Sie C/C++ Build > Behaviour auf. Fügen Sie ENABLE_SHARED=1 dem Abschnitt Build (Incremental build) hinzu, um libwebp als gemeinsam genutzte Bibliothek zu erstellen.

Hinweis: Das Festlegen von NDK_TOOLCHAIN_VERSION=4.8 verbessert im Allgemeinen die Leistung von 32-Bit-Builds.
Fügen Sie swig/libwebp.jar dem 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. Einige der oben beschriebenen Schritte können in diesem Fall 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.

Erstellen Sie libwebp.dll. Dadurch wird WEBP_EXTERN richtig festgelegt, um die API-Funktionen zu exportieren.
```
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 alle zurückgegebenen 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 animierte WebPs verwenden?

Vorteile von animierten WebP-Dateien im Vergleich zu animierten GIFs

WebP unterstützt 24‑Bit-RGB-Farben mit einem 8‑Bit-Alphakanal, während GIF nur 8‑Bit-Farben und einen 1‑Bit-Alphakanal unterstützt.
WebP unterstützt sowohl die verlustbehaftete als auch die verlustfreie Komprimierung. Tatsächlich können in einer einzelnen Animation sowohl verlustbehaftete als auch verlustfreie Frames kombiniert werden. GIF unterstützt nur verlustfreie Komprimierung. Die verlustbehafteten Komprimierungstechniken von WebP eignen sich gut für animierte Bilder, die aus Videos aus der realen Welt erstellt werden. Diese sind eine immer beliebtere Quelle für animierte Bilder.
WebP benötigt weniger Byte als GIF.¹ Animierte GIFs, die in verlustbehaftete WebPs konvertiert werden, sind 64% kleiner, während verlustfreie WebPs 19% kleiner sind. Das ist besonders in Mobilfunknetzen wichtig.
WebP lässt sich bei der Suche schneller decodieren. In Blink können Bilder durch Scrollen oder Wechseln von Tabs ein- und ausgeblendet werden. Dadurch werden Animationen pausiert und dann zu einem anderen Punkt übersprungen. Eine übermäßige CPU-Auslastung, die dazu führt, dass bei Animationen Frames verloren gehen, kann auch dazu führen, dass der Decoder in der Animation vorwärts springen muss. In diesen Szenarien ist die gesamte Decodierungszeit² für animierte WebP-Bilder 0,57-mal so lang wie für GIFs.Das führt zu weniger Ruckeln beim Scrollen und einer schnelleren Erholung von CPU-Auslastungsspitzen. Das liegt an zwei Vorteilen von WebP gegenüber GIF:
- In WebP-Bildern werden Metadaten dazu gespeichert, ob jeder Frame einen Alphakanal enthält. So muss der Frame nicht decodiert werden, um dies festzustellen. Dadurch lässt sich genauer ableiten, von welchen vorherigen Frames ein bestimmter Frame abhängt. So wird das unnötige Decodieren vorheriger Frames reduziert.
- Ähnlich wie bei einem modernen Video-Encoder fügt der WebP-Encoder heuristisch in regelmäßigen Abständen Keyframes hinzu, was bei den meisten GIF-Encodern nicht der Fall ist. Dadurch wird das Suchen in langen Animationen erheblich verbessert. Um das Einfügen solcher Frames zu erleichtern, ohne die Bildgröße wesentlich zu erhöhen, wird in WebP zusätzlich zur Frame-Entsorgungsmethode, die GIF verwendet, für jeden Frame ein Blending-Methoden-Flag hinzugefügt. So kann ein Keyframe so gezeichnet werden, als ob das gesamte Bild in der Hintergrundfarbe gelöscht worden wäre, ohne dass der vorherige Frame in voller Größe dargestellt werden muss.

Nachteile von animierten WebP-Dateien im Vergleich zu animierten GIFs

Ohne Seeking ist die geradlinige Dekodierung von WebP CPU-intensiver als bei GIF. Das Decodieren von verlustbehaftetem WebP dauert 2,2-mal so lange wie das Decodieren von GIF, das Decodieren von verlustfreiem WebP 1,5-mal so lange.
Die WebP-Unterstützung ist nicht annähernd so weit verbreitet wie die GIF-Unterstützung, die praktisch universell ist.
Durch das Hinzufügen von WebP-Unterstützung zu Browsern werden der Code-Footprint und die Angriffsfläche vergrößert. In Blink sind das etwa 1.500 zusätzliche Codezeilen (einschließlich der WebP-Demux-Bibliothek und des WebP-Bilddecoders auf Blink-Seite). Dieses Problem könnte in Zukunft reduziert werden, wenn WebP und WebM mehr gemeinsamen Decodierungscode verwenden oder wenn die Funktionen von WebP in WebM enthalten sind.

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

Langfristig kann es sinnvoll sein, Videoformate im <img>-Tag zu unterstützen. Wenn Sie dies jedoch jetzt tun, in der Absicht, dass WebM in <img> die vorgeschlagene Rolle von animiertem WebP übernehmen kann, ist das problematisch:

Beim Decodieren eines Frames, der auf vorherigen Frames basiert, benötigt WebM 50% mehr Arbeitsspeicher als animiertes WebP, um die Mindestanzahl vorheriger Frames³ zu speichern.
Die Unterstützung von Video-Codecs und ‑Containern variiert stark je nach Browser und Gerät. Um die automatische Transcodierung von Inhalten zu ermöglichen (z.B. für bandbreitensparende Proxys), müssten Browser Accept-Header hinzufügen, die angeben, welche Formate ihre Bild-Tags unterstützen. Auch das reicht möglicherweise nicht aus, da MIME-Typen wie „video/webm“ oder „video/mpeg“ immer noch nicht angeben, welcher Codec unterstützt wird (z. B. VP8 oder VP9). Andererseits ist das WebP-Format effektiv eingefroren. Wenn Anbieter, die es ausliefern, sich darauf einigen, animiertes WebP auszuliefern, sollte das Verhalten von WebP in allen UAs konsistent sein. Da der Accept-Header „image/webp“ bereits verwendet wird, um die WebP-Unterstützung anzugeben, sind keine neuen Änderungen am Accept-Header erforderlich.
Der Chromium-Videostack ist für eine reibungslose Wiedergabe optimiert und geht davon aus, dass jeweils nur ein oder zwei Videos abgespielt werden. Daher werden bei der Implementierung Systemressourcen (Threads, Arbeitsspeicher usw.) aggressiv genutzt, um die Wiedergabequalität zu maximieren. Eine solche Implementierung lässt sich nicht gut auf viele gleichzeitige Videos skalieren und müsste für die Verwendung auf bildlastigen Webseiten neu konzipiert werden.
WebM enthält derzeit nicht alle Komprimierungstechniken von WebP. Daher lässt sich dieses Bild mit WebP deutlich besser komprimieren als mit den Alternativen:

¹ Für alle Vergleiche zwischen animierten GIFs und animierten WebP-Dateien haben wir einen Korpus von etwa 7.000 animierten GIF-Bildern verwendet, die zufällig aus dem Web stammen. Diese Bilder wurden mit dem Tool „gif2webp“ und den Standardeinstellungen in animierte WebP-Bilder konvertiert (erstellt aus dem neuesten libwebp-Quellbaum vom 08.10.2013). Die Vergleichszahlen sind die Durchschnittswerte für diese Bilder.

² Die Decodierungszeiten wurden mit der neuesten Version von libwebp + ToT Blink (Stand: 08.10.2013) mit einem Benchmark-Tool berechnet. „Decodierungszeit mit Suchen“ wird so berechnet: „Decodiere die ersten fünf Frames, leere den Frame-Puffer-Cache, decodiere die nächsten fünf Frames usw.“

³ WebM speichert 4 YUV-Referenzframes im Arbeitsspeicher, wobei in jedem Frame (Breite+96)*(Höhe+96) Pixel gespeichert werden. Für YUV 4:2:0 benötigen wir 4 Byte pro 6 Pixel (oder 3/2 Byte pro Pixel). Diese Referenzframes belegen also 4*3/2*(width+96)*(height+96) Byte Speicherplatz. Für WebP ist dagegen nur der vorherige Frame (in RGBA) erforderlich, was 4*width*height Byte Speicherplatz entspricht.

⁴ Für das Rendern von animierten WebP-Dateien ist Google Chrome 32 oder höher erforderlich.

Häufig gestellte Fragen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.