Diese Seite wurde von der Cloud Translation API übersetzt.

Häufig gestellte Fragen

Was ist WebP? Warum sollte ich dieses Tool verwenden?

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

Ziel des WebP-Formats ist die Erstellung kleinerer, besser aussehender Bilder, die dazu beitragen können, das Web schneller zu machen.

Welche Webbrowser unterstützen WebP nativ?

Webmaster, die an der Verbesserung der Websiteleistung interessiert sind, können für ihre aktuellen Bilder ganz einfach optimierte WebP-Alternativen erstellen und diese gezielt für Browser bereitstellen, die WebP unterstützen.

Verlustbehafteter WebP-Support
- Google Chrome (Desktop) 17+
- Google Chrome für Android ab Version 25
- Microsoft Edge (ab Version 18)
- Firefox (ab Version 65)
- 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 und höher)
Unterstützung für verlustbehaftete, verlustfreie und Alphaversionen von WebP
- Google Chrome (Desktop) 23 oder höher
- Google Chrome für Android ab Version 25
- Microsoft Edge (ab Version 18)
- Firefox (ab Version 65)
- 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 und höher)
Unterstützung für WebP-Animationen
- Google Chrome (Desktop und Android) 32 oder höher
- Microsoft Edge (ab Version 18)
- Firefox (ab Version 65)
- Opera ab 19
- Safari 14 und höher (iOS 14 und höher, macOS Big Sur und höher)

Weitere Informationen

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

Sie sollten WebP-Bilder nur für Clients bereitstellen, die sie ordnungsgemäß anzeigen können, und bei Clients, die dies nicht können, auf Legacy-Formate zurückgreifen. Glücklicherweise gibt es mehrere Techniken, um die WebP-Unterstützung zu ermitteln, sowohl auf Client- als auch auf Serverseite. Einige CDN-Anbieter bieten die Erkennung mit WebP-Unterstützung als Teil ihres Dienstes an.

Serverseitige Inhaltsverhandlung über „Accept-Header“-Header

Es ist üblich, dass Webclients einen "Accept"-Anfrageheader senden, der angibt, welche Inhaltsformate sie als Antwort akzeptieren möchten. Wenn ein Browser im Voraus anzeigt, dass er das image/webp-Format akzeptiert, weiß der Webserver, dass er WebP-Bilder sicher senden kann, was die Verhandlung von Inhalten erheblich vereinfacht. Weitere Informationen finden Sie unter den folgenden Links.

Modernisierung

Modernizr ist eine JavaScript-Bibliothek, mit der Sie die Unterstützung von HTML5- und CSS3-Funktionen in Webbrowsern bequem ermitteln können. Suchen Sie die Properties Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha und Modernizr.webp.animation.

HTML5-`<picture>`-Element

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

Im eigenen JavaScript-Code

Eine weitere Erkennungsmethode besteht darin, ein sehr kleines WebP-Bild zu decodieren, das eine bestimmte Funktion verwendet, und zu prüfen, ob der Vorgang 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];
}

Beachten Sie, dass Bilder nicht blockierend und asynchron geladen werden. Das bedeutet, dass jeder Code, der von der WebP-Unterstützung abhängig ist, vorzugsweise in die Callback-Funktion eingefügt werden sollte.

Warum hat Google WebP als Open Source veröffentlicht?

Wir sind fest davon überzeugt, dass das Open-Source-Modell so wichtig ist. Mit WebP als Open Source kann jeder mit dem Format arbeiten und Verbesserungen vorschlagen. Wir sind davon überzeugt, dass WebP aufgrund Ihrer Eingaben und 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 Befehlszeilendienstprogramm WebP können Sie Ihre persönlichen Bilddateien in das WebP-Format konvertieren. Weitere Informationen finden Sie unter WebP verwenden.

Wenn Sie viele Images konvertieren möchten, können Sie die Shell Ihrer 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 WebP-Bildqualität selbst beurteilen?

Derzeit können Sie WebP-Dateien ansehen, indem Sie sie in ein gängiges Format mit verlustfreier Komprimierung (z. B. PNG) konvertieren. Anschließend können Sie die PNG-Dateien in einem beliebigen Browser oder Bildbetrachter ansehen. Einen kurzen Eindruck von der WebP-Qualität erhalten Sie in der Galerie auf dieser Website mit Fotovergleichen.

Wie erhalte ich den Quellcode?

Der Converter-Code ist im Downloadbereich der Open-Source-Projektseite von WebP 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.

Welche Größe darf ein WebP-Bild maximal haben?

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

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

In Übereinstimmung mit dem VP8-Bitstream funktioniert lossy WebP ausschließlich mit einem 8-Bit-Y'CbCr-4:2:0-Bildformat (oft als YUV420 bezeichnet). Weitere Informationen finden Sie in Abschnitt 2, Formatübersicht von RFC 6386, im VP8-Leitfaden zum Datenformat und zur Decodierung.

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

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

Ja, in der Regel bei der Konvertierung von einem verlustbehafteten Format in ein verlustfreies WebP-Format oder umgekehrt. Dies liegt hauptsächlich am Farbraumunterschied (YUV420 vs. ARGB) und der Umwandlung zwischen diesen beiden Werten.

Es gibt drei typische Situationen:

Wenn das Quellbild im verlustfreien ARGB-Format vorliegt, führt das räumliche Heruntersampling auf YUV420 zu neuen Farben, die sich schwieriger komprimieren lassen als die ursprünglichen Farben. Diese Situation kann in der Regel auftreten, 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 unter Umständen zu einer größeren Dateigröße.
Wenn die Quelle in einem verlustbehafteten Format vorliegt, führt die verlustfreie WebP-Komprimierung zum Erfassen der verlustbehafteten Natur der Quelle in der Regel zu einer größeren Datei. Dies gilt nicht speziell für WebP und kann beispielsweise bei der Konvertierung einer JPEG-Quelle in ein verlustfreies WebP- oder PNG-Format auftreten.
Die Quelle liegt in einem verlustbehafteten Format vor und Sie versuchen, sie als verlustbehaftetes WebP mit einer höheren Qualität zu komprimieren. Wenn du beispielsweise eine JPEG-Datei mit einer Qualität von 80 in eine WebP-Datei mit einer Qualität von 95 konvertieren möchtest, ist die Datei in der Regel größer, auch wenn beide Formate verlustbehaftet sind. Die Qualität der Quelle kann häufig nicht beurteilt werden. Daher wird empfohlen, die Ziel-WebP-Qualität herabzusetzen, wenn die Dateigröße konstant größer ist. Eine weitere Möglichkeit besteht darin, die Qualitätseinstellung zu vermeiden und stattdessen eine Ausrichtung auf eine bestimmte Dateigröße mithilfe der Option -size im cwebp-Tool oder der entsprechenden API vorzunehmen. Ein Targeting auf 80% der ursprünglichen Dateigröße könnte sich beispielsweise als robuster erweisen.

Das Konvertieren einer JPEG-Quelle in eine verlustbehaftete WebP- oder einer PNG-Quelle in ein verlustfreies WebP ist nicht anfällig für Überraschungen bei der Dateigröße.

Unterstützt WebP die Progressive- oder Zeilensprungdarstellung?

WebP bietet keine progressive oder verschachtelte Decodierungsaktualisierung im JPEG- oder PNG-Sinne. Dies kann CPU und Arbeitsspeicher des Decodierungsclients zu stark belasten, da jedes Aktualisierungsereignis das Dekomprimierungssystem vollständig durchlaufen muss.

Im Durchschnitt entspricht die Decodierung eines progressiven JPEG-Bildes der dreimaligen Decodierung 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 Stichprobenzeile zu erzeugen. Dies spart dem Client den Aufwand für Arbeitsspeicher, CPU-Leistung und Neuerstellung bei und stellt gleichzeitig visuelle Hinweise zum Downloadstatus bereit. 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/.

Bibliothek in Eclipse erstellen:

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

Hinweis: Durch die Einstellung NDK_TOOLCHAIN_VERSION=4.8 wird im Allgemeinen die Leistung des 32-Bit-Builds verbessert.
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. 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.

Erstellen Sie libwebp.dll. Damit wird WEBP_EXTERN für den korrekten Export der API-Funktionen eingerichtet.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Fügen Sie Ihrem Projekt libwebp.dll hinzu und importieren Sie die gewünschten Funktionen. Hinweis: 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 animiertes WebP verwenden?

Vorteile von animiertem WebP im Vergleich zu animierten GIFs

WebP unterstützt 24-Bit-RGB-Farben mit einem 8-Bit-Alphakanal, verglichen mit der 8-Bit-Farbe von GIF und der 1-Bit-Alphaversion.
WebP unterstützt sowohl verlustbehaftete als auch verlustfreie Komprimierung. In einer einzelnen Animation können verlustbehaftete und verlustfreie Frames kombiniert werden. GIF unterstützt nur eine verlustfreie Komprimierung. Die verlustbehafteten Komprimierungstechniken von WebP eignen sich gut für animierte Bilder, die aus realen Videos erstellt werden. Animierte Bilder werden immer beliebter.
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. Dies ist in Mobilfunknetzen besonders wichtig.
Die Decodierung nimmt bei WebP weniger Zeit in Anspruch, wenn eine Suche vorhanden ist. In Blink können Bilder beim Scrollen oder Wechseln von Tabs ein- oder ausgeblendet werden, was dazu führt, dass Animationen angehalten und dann an eine andere Stelle gespult werden. Eine übermäßige CPU-Auslastung, die dazu führt, dass die Frames von Animationen gelöscht werden, erfordern unter Umständen auch, dass der Decoder in der Animation vorwärts springt. In diesen Szenarien benötigt animiertes WebP 0, 57-mal so viel Gesamtdecodierungszeit² wie im GIF-Format, was zu weniger Verzögerungen beim Scrollen und einer schnelleren Wiederherstellung nach Spitzen der CPU-Auslastung führt. Dies hat zwei Vorteile von WebP gegenüber GIF:
- WebP-Bilder speichern Metadaten darüber, ob jeder Frame Alpha enthält, sodass der Frame für diese Feststellung nicht decodiert werden muss. Dies führt zu einer genaueren Rückschlüsse darauf, von welchen vorherigen Frames ein bestimmter Frame abhängt, und verringert so die unnötige Decodierung vorheriger Frames.
- Ähnlich wie bei einem modernen Video-Encoder fügt der WebP-Encoder heuristisch in regelmäßigen Intervallen Keyframes hinzu. Dies ist bei den meisten GIF-Encodern nicht der Fall. Dies verbessert die Suche in langen Animationen erheblich. Um das Einfügen solcher Frames zu erleichtern, ohne die Bildgröße erheblich zu erhöhen, fügt WebP zusätzlich zur Frame-Entfernungsmethode, die von GIF verwendet wird, für jeden Frame das Flag „blending method“ hinzu. Dadurch kann ein Keyframe so zeichnen, als wäre das gesamte Bild auf der Hintergrundfarbe gelöscht worden, ohne dass der vorherige Frame in voller Größe angezeigt würde.

Nachteile von animiertem WebP im Vergleich zu animierten GIFs

Ohne Suche ist die lineare Decodierung von WebP CPU-intensiv als GIF. Verlustbehaftetes WebP benötigt 2,2-mal so viel Decodierungszeit wie GIF, während verlustfreies WebP 1,5-mal so viel benötigt.
Die WebP-Unterstützung ist nicht annähernd so weit verbreitet wie die GIF-Unterstützung, die praktisch universell ist.
Durch die WebP-Unterstützung für Browser werden der Code-Fußabdruck und die Angriffsfläche erhöht. In Blink sind dies etwa 1.500 zusätzliche Codezeilen (einschließlich der WebP-Demux-Bibliothek und des Blink-Side-WebP-Bilddecoders). Beachten Sie, dass dieses Problem in Zukunft reduziert werden könnte, wenn WebP und WebM gemeinsamen Decodierungscode verwenden oder wenn die Funktionen von WebP mit denen von WebM zusammengefasst werden.

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

Langfristig ist es sinnvoll, Videoformate im <img>-Tag zu unterstützen. Da WebM in <img> die vorgeschlagene Rolle des animierten WebP übernehmen kann, ist dies jedoch problematisch:

Beim Decodieren eines Frames, der auf vorherigen Frames basiert, benötigt WebM 50% mehr Speicher als animiertes WebP, um die Mindestanzahl vorheriger Frames³ zu speichern.
Die Unterstützung von Video-Codecs und Containern variiert je nach Browser und Gerät erheblich. Um die automatische Inhaltstranskodierung zu erleichtern (z.B. für bandbreitensparende Proxys), müssen Browser akzeptieren Header hinzufügen, die angeben, welche Formate ihre Bild-Tags unterstützen. Auch das kann unzureichend sein, da MIME-Typen wie „video/webm“ oder „video/mpeg“ immer noch nicht Aufschluss über die Codec-Unterstützung geben (z. B. VP8 oder VP9). Das WebP-Format ist dagegen im Grunde eingefroren. Wenn Anbieter, die das WebP versenden, sich damit einig sind, animierten WebP zu liefern, sollte das Verhalten von WebP in allen UAs einheitlich sein. Da der „image/webp“-Accept-Header bereits verwendet wird, um die WebP-Unterstützung anzuzeigen, sind keine neuen Änderungen des Accept-Headers erforderlich.
Der Chromium-Videostapel ist für eine reibungslose Wiedergabe optimiert und geht davon aus, dass nur ein oder zwei Videos gleichzeitig wiedergegeben werden. Dies hat zur Folge, dass die Implementierung die Systemressourcen (Threads, Arbeitsspeicher usw.) aggressiv beansprucht, um die Wiedergabequalität zu maximieren. Eine solche Implementierung lässt sich nicht gut für viele gleichzeitige Videos skalieren und müsste neu gestaltet werden, um für Webseiten mit vielen Bildern geeignet zu sein.
WebM verwendet derzeit nicht alle Komprimierungstechniken von WebP. Daher wird dieses Image mit WebP deutlich besser komprimiert als die Alternativen:

¹ Für alle Vergleiche zwischen animierten GIFs und animierten WebPs haben wir einen Korpus von etwa 7.000 animierten GIF-Bildern verwendet, die zufällig aus dem Web entnommen wurden. Diese Bilder wurden mithilfe des Tools "gif2webp" unter Verwendung der Standardeinstellungen, die aus der neuesten libwebp-Quellstruktur vom 08.10.2013 erstellt wurden, in animiertes WebP konvertiert. Die Vergleichszahlen sind die Durchschnittswerte dieser Bilder.

² Die Decodierungszeiten wurden mit dem aktuellen libwebp + ToT Blink (Stand: 08.10.2013) mit einem Benchmark-Tool berechnet. „Zeit mit Suche decodieren“ wird wie folgt berechnet: „Die ersten fünf Frames decodieren, den Frame-Zwischenspeicher-Cache leeren, die nächsten fünf Frames decodieren usw.“.

³ WebM speichert 4 YUV-Referenzframes, 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. Bei WebP muss hingegen nur der vorherige Frame (in RGBA) mit 4*width*height Byte Arbeitsspeicher verfügbar sein.

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