Najczęstsze pytania

Co to jest WebP? Dlaczego warto korzystać z tej funkcji?

WebP to metoda stratnej i bezstratnej kompresji wielu rodzajów obrazów fotograficznych, przezroczystych i graficznych dostępnych w internecie. Stopień kompresji stratnej można dostosować, aby użytkownik mógł wybrać kompresję między rozmiarem pliku a jakością obrazu. Kompresja WebP jest zwykle o 30% większa niż w przypadku formatów JPEG i JPEG 2000, nie tracąc jakości obrazów (patrz Badanie porównawcze).

Zasadniczo format WebP służy do tworzenia mniejszych, lepiej wyglądających obrazów, które mogą przyspieszać działanie sieci.

Które przeglądarki natywnie obsługują WebP?

Webmasterzy, którzy chcą zwiększyć wydajność witryny, mogą łatwo tworzyć zoptymalizowane alternatywne wersje WebP dla swoich obecnych obrazów i wyświetlać je na podstawie kierowania w przeglądarkach obsługujących protokół WebP.

  • Stratna obsługa WebP
    • Google Chrome (na komputery) w wersji 17 lub nowszej
    • Google Chrome na Androida w wersji 25 lub nowszej,
    • Microsoft Edge w wersji 18 lub nowszej.
    • Firefox w wersji 65 lub nowszej,
    • Opera 11.10 lub nowsza
    • Natywna przeglądarka internetowa na Androida 4.0 lub nowszego (ICS)
    • Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur+)
  • Obsługa stratnych, bezstratnych i alfa WebP
    • Google Chrome (na komputery) w wersji 23 lub nowszej
    • Google Chrome na Androida w wersji 25 lub nowszej,
    • Microsoft Edge w wersji 18 lub nowszej.
    • Firefox w wersji 65 lub nowszej,
    • Opera 12.10 lub nowsza
    • Natywna przeglądarka internetowa na Androidzie 4.2 lub nowszym (JB-MR1)
    • Blady Moon 26+
    • Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur+)
  • Obsługa animacji WebP
    • Google Chrome (na komputery i Android) w wersji 32 lub nowszej,
    • Microsoft Edge w wersji 18 lub nowszej.
    • Firefox w wersji 65 lub nowszej,
    • Opera od 19 roku życia
    • Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur+)

Zobacz także:

Jak mogę sprawdzić, czy przeglądarka obsługuje protokół WebP?

Obrazy WebP będziesz udostępniać tylko klientom, którzy mogą je prawidłowo wyświetlać, a klientom, którzy nie są w stanie ich wyświetlać, używaj starszych formatów. Na szczęście istnieje kilka technik wykrywania obsługi WebP, zarówno po stronie klienta, jak i po stronie serwera. Niektórzy dostawcy CDN w ramach swojej usługi oferują wykrywanie w technologii WebP.

Negocjowanie treści po stronie serwera za pomocą nagłówków Accept

Klienty internetowe często wysyłają nagłówek żądania „Accept” (Akceptuje) z informacją o tym, jakie formaty treści są akceptowane w odpowiedzi. Jeśli przeglądarka z wyprzedzeniem wskaże, że „akceptuje” format obraz/webp, serwer WWW wie, że może bezpiecznie wysyłać obrazy WebP, co znacznie upraszcza negocjacje treści. Więcej informacji znajdziesz pod poniższymi linkami.

Modernizator

Modernizr to biblioteka JavaScript do łatwego wykrywania funkcji HTML5 i CSS3 w przeglądarkach. Wyszukaj właściwości Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha i Modernizr.webp.animation.

Element <picture> HTML5

HTML5 obsługuje element <picture>, który umożliwia podanie wielu alternatywnych obrazów w kolejności priorytetu, tak by klient zażądał pierwszego obrazu, który może wyświetlić się prawidłowo. Zobacz tę dyskusję na temat HTML5 Rocks. Element <picture> jest stale obsługiwany przez większą liczbę przeglądarek.

We własnym kodzie JavaScript

Inną metodą wykrywania jest dekodowanie bardzo małego obrazu WebP, który korzysta z określonej funkcji, w celu sprawdzenia, czy się udało. Przykład:

// 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];
}

Pamiętaj, że wczytywanie obrazów nie blokuje się i jest asynchroniczne. Oznacza to, że każdy kod, który zależy od obsługi WebP, powinien zostać umieszczony w funkcji wywołania zwrotnego.

Dlaczego firma Google udostępniła WebP jako oprogramowanie open source?

Jesteśmy głęboko przekonani o znaczeniu modelu open source. Dzięki WebP w modelu open source każdy może pracować z formatem i proponować ulepszenia. Jesteśmy przekonani, że dzięki opiniom i sugestiom firmy WebP z czasem stanie się jeszcze bardziej przydatny jako format graficzny.

Jak mogę przekonwertować prywatne obrazy z obrazami na WebP?

Do przekonwertowania osobistych plików obrazów na format WebP możesz użyć narzędzia wiersza poleceń WebP. Więcej informacji znajdziesz w artykule Korzystanie z WebP.

Jeśli masz wiele obrazów do przekonwertowania, możesz uprościć tę operację, używając powłoki platformy. Aby na przykład przekonwertować wszystkie pliki jpeg w folderze, wykonaj te czynności:

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

Jak mogę samodzielnie ocenić jakość obrazu WebP?

Obecnie pliki WebP można wyświetlać, konwertując je do powszechnie stosowanego formatu korzystającego z kompresji bezstratnej, np. PNG, a następnie wyświetlając je w dowolnej przeglądarce lub przeglądarce obrazów. Aby szybko zorientować się w jakości WebP, otwórz Galerię na tej stronie, w której znajdziesz porównania zdjęć.

Jak pobrać kod źródłowy?

Kod konwertera jest dostępny w sekcji pobierania na stronie projektu open source WebP. Kod lekkiego dekodera i specyfikacja VP8 znajdziesz na stronie WebM. Specyfikację kontenera znajdziesz na stronie Kontener RIFF.

Jaki jest maksymalny rozmiar obrazu WebP?

WebP jest zgodny ze strumieniem bitowym zgodnym z VP8, a szerokość i wysokość używa 14 bitów. Maksymalne wymiary obrazu w pikselach WebP to 16383 × 16383.

Jakie przestrzenie kolorów obsługuje format WebP?

Zgodnie ze strumieniem bitowym VP8 lossy WebP działa wyłącznie z 8-bitowym formatem obrazu Y'CbCr 4:2:0 (często nazywanym YUV420). Więcej informacji znajdziesz w sekcji 2, „Przegląd formatów” standardu RFC 6386 oraz Przewodnika po formacie danych i dekodowaniu danych VP8.

Bezstratny format WebP działa tylko z formatem RGBA. Zobacz specyfikację WebP Lossless Bitstream.

Czy obraz WebP może rosnąć niż obraz źródłowy?

Tak, zwykle podczas konwersji ze stratnego formatu na bezstratny WebP lub na odwrót. Wynika to głównie z różnicy między przestrzeniami barw (YUV420 a ARGB) oraz konwersji między tymi elementami.

Oto 3 typowe sytuacje:

  1. Jeśli obraz źródłowy jest w bezstratnym formacie ARGB, w przypadku YUV420 próbkowanie przestrzenne do YUV420 wprowadza nowe kolory, które są trudniejsze do skompresowania niż oryginalne. Do takiej sytuacji może dojść zwykle wtedy, gdy źródło jest w formacie PNG i ma kilka kolorów: konwersja do stratnego formatu WebP (lub podobnie do stratnego pliku JPEG) może znacznie zwiększyć rozmiar pliku.
  2. Jeśli źródło jest w formacie stratnym, użycie bezstratnej kompresji WebP w celu uchwycenia stratnego źródła pliku zazwyczaj skutkuje większym rozmiarem pliku. Nie dotyczy to tylko formatu WebP i może wystąpić na przykład podczas konwersji źródła JPEG na bezstratne formaty WebP lub PNG.
  3. Jeśli źródło jest w formacie stratnym i próbujesz skompresować je do stratnego formatu WebP z ustawieniem wyższej jakości. Na przykład próba przekonwertowania pliku JPEG zapisanego w jakości 80 na plik WebP o jakości 95 zwykle skutkuje większym rozmiarem pliku, nawet jeśli oba formaty są stratne. Ocena jakości źródła jest często niemożliwa, dlatego jeśli rozmiar pliku jest stale większy, zalecamy obniżenie docelowej jakości WebP. Innym sposobem jest unikanie ustawienia jakości i kierowanie pliku na dany rozmiar za pomocą opcji -size w narzędziu cwebp lub równoważnego interfejsie API. Na przykład kierowanie do 80% rozmiaru pierwotnego pliku może okazać się bardziej niezawodne.

Pamiętaj, że podczas konwersji źródła JPEG na stratny format WebP lub PNG na bezstratny format WebP nie występują takie niespodzianki w przypadku plików.

Czy WebP obsługuje wyświetlacz progresywny lub z przeplotem?

WebP nie oferuje odświeżania progresywnego ani z przeplotem w przypadku plików JPEG i PNG. Może to spowodować zbyt duże obciążenie procesora i pamięci klienta dekodowania, ponieważ każde zdarzenie odświeżania wiąże się z pełnym przejściem przez system dekompresji.

Dekodowanie progresywnego obrazu JPEG jest równoważne z dekodowaniem elementu bazowego 1 razy.

WebP oferuje też dekodowanie przyrostowe, w którym wszystkie dostępne przychodzące bajty strumienia bitowego są wykorzystywane do jak najszybszego utworzenia wyświetlanego wiersza przykładowego. Oszczędza to pamięć, procesor i ponowne renderowanie po stronie klienta, a jednocześnie zapewnia wizualne wskazówki dotyczące stanu pobierania. Funkcja dekodowania przyrostowego jest dostępna za pomocą interfejsu Advanced Decoding API.

Jak używać powiązań libwebp w Javie w projekcie Androida?

WebP zapewnia obsługę powiązań JNI z prostym interfejsem kodera i dekodera w katalogu swig/.

Tworzenie biblioteki w Eclipse:

  1. Sprawdź, czy wraz z narzędziami NDK masz zainstalowaną wtyczkę ADT i czy ścieżka NDK jest prawidłowo skonfigurowana (Preferencje > Android > NDK).
  2. Utwórz nowy projekt: Plik > Nowy > Projekt > Projekt aplikacji na Androida.
  3. W nowym projekcie sklonuj lub rozpakuj libwebp do folderu o nazwie jni.
  4. Dodaj swig/libwebp_java_wrap.c do listy LOCAL_SRC_FILES.
  5. Kliknij nowy projekt prawym przyciskiem myszy i wybierz Narzędzia na Androida > Dodaj obsługę natywną ..., by uwzględnić bibliotekę w kompilacji.
  6. Otwórz właściwości projektu i kliknij Kompilacja C/C++ > Zachowanie. Dodaj ENABLE_SHARED=1 do sekcji Build (Incremental build), aby utworzyć libwebp jako bibliotekę współdzieloną.

    Uwaga: ustawienie NDK_TOOLCHAIN_VERSION=4.8 zasadniczo poprawi wydajność kompilacji 32-bitowej.

  7. Dodaj plik swig/libwebp.jar do folderu projektu libs/.

  8. Utwórz projekt. Spowoduje to utworzenie libs/<target-arch>/libwebp.so.

  9. Aby wczytywać bibliotekę w czasie działania, użyj polecenia System.loadLibrary("webp").

Pamiętaj, że bibliotekę można utworzyć ręcznie za pomocą funkcji ndk-build i zawartych w niej Android.mk. W takim przypadku można ponownie wykorzystać niektóre z opisanych wyżej czynności.

Jak używać libwebp w języku C#?

WebP można utworzyć jako bibliotekę DLL, która eksportuje interfejs libwebp API. Funkcje te można zaimportować do języka C#.

  1. Kompilacja pliku libwebp.dll. Spowoduje to prawidłowe ustawienie WEBP_EXTERN na potrzeby eksportowania funkcji interfejsu API.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic
    
  2. Dodaj plik libwebp.dll do projektu i zaimportuj odpowiednie funkcje. Uwaga: jeśli używasz prostego interfejsu API, musisz wywołać WebPFree(), aby zwolnić wszystkie zwrócone bufory.

    [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);
    }
    

Dlaczego warto używać animowanego WebP?

Zalety animowanych WebP w porównaniu z animowanymi GIF-ami

  1. WebP obsługuje 24-bitowe kolory RGB z 8-bitowym kanałem alfa. W porównaniu z 8-bitowym kolorem i 1-bitową wersją alfa pliku GIF.

  2. WebP obsługuje zarówno kompresję stratną, jak i bezstratną. Pojedyncza animacja może łączyć klatki bezstratne i stratne. GIF obsługuje tylko kompresję bezstratną. Stosowane przez WebP techniki kompresowania stratne doskonale nadają się do animowanych obrazów tworzonych z rzeczywistych filmów, które stają się coraz bardziej popularnym źródłem animowanych obrazów.

  3. WebP wymaga mniej bajtów niż GIF1. Animowane GIF-y przekonwertowane na stratne pliki WebP są o 64% mniejsze, a te bezstratne o 19% mniejsze. Jest to szczególnie ważne w przypadku sieci komórkowych.

  4. Dekodowanie WebP w przypadku wyszukiwania trwa krócej. W funkcji Mrugnięcie przewijanie lub zmienianie kart może ukrywać i wyświetlać obrazy, co z kolei powoduje wstrzymanie animacji i przesunięcie do innego punktu. Nadmierne wykorzystanie procesora, które powoduje, że animacje są pomijane, również mogą wymagać przewinięcia animacji do przodu przez dekodera. W takich sytuacjach animowany WebP zajmuje 0, 57 raza dłuższy łączny czas dekodowania2 niż GIF, co zapewnia mniej zacięć podczas przewijania i szybsze przywracanie po gwałtownym wzroście wykorzystania procesora. Wynika to z 2 zalet WebP w porównaniu z GIF-ami:

    • Obrazy WebP przechowują metadane o tym, czy każda ramka zawiera wersję alfa, co eliminuje potrzebę dekodowania ramki, aby takie określenie zostało określone. Daje to dokładniejsze wnioskowanie o tym, od których poprzednich klatek zależy dana ramka, co ogranicza niepotrzebne ich dekodowanie.

    • Podobnie jak nowoczesny koder wideo, koder WebP heurystycznie dodaje klatki kluczowe w regularnych odstępach czasu (czego nie robi większość koderów do obsługi GIF-ów). Znacznie poprawia to przewijanie w długich animacjach. Aby ułatwić wstawianie takich ramek bez znacznego zwiększania rozmiaru obrazu, WebP dodaje do każdej klatki flagę metody mieszania, a nie tylko metodę usuwania ramek, z której korzysta GIF. Dzięki temu klatki kluczowej można rysować tak, jakby cały obraz został przywrócony do koloru tła, bez wymuszania pełnego rozmiaru poprzedniej klatki.

Wady animowanego WebP w porównaniu z animowanym GIF-em

  1. Przy braku wyszukiwania liniowe dekodowanie WebP obciąża procesor bardziej niż GIF. Lossy WebP zajmuje 2,2 raza więcej czasu dekodowania niż GIF, a bezstratny WebP – 1,5 raza więcej.

  2. Obsługa WebP nie jest tak powszechna jak GIF-y, co w rzeczywistości jest uniwersalne.

  3. Dodanie do przeglądarek obsługi WebP zwiększa ilość kodu i powierzchnię ataku. W Blink jest to około 1500 dodatkowych wierszy kodu (w tym biblioteka demuxowa WebP i dekoder obrazów WebP po stronie Blink). Pamiętaj, że ten problem można ograniczyć w przyszłości, jeśli WebP i WebM współdzielą bardziej wspólny kod dekodowania lub jeśli możliwości WebP zostaną uwzględnione w komponentach WebM.

Dlaczego nie obsługujemy po prostu WebM w usłudze <img>?

W dłuższej perspektywie warto zastosować formaty wideo w tagu <img>. Jednak teraz, ponieważ WebM w <img> może wypełnić proponowaną rolę animowanego WebP, jest to problem:

  1. Podczas dekodowania ramki, która bazuje na poprzednich klatkach, WebM wymaga o 50% więcej pamięci niż animowany WebP, aby pomieścić minimalną liczbę poprzednich klatek3.

  2. Obsługa kodeków wideo i kontenerów znacznie różni się w zależności od przeglądarki i urządzenia. Aby usprawnić automatyczne transkodowanie treści (np. w przypadku serwerów proxy oszczędzających przepustowość), przeglądarki muszą dodać nagłówki akceptacji wskazujące, jakie formaty obsługują ich tagi graficzne. Nawet to może być niewystarczające, ponieważ typy MIME, takie jak „video/webm” lub „video/mpeg”, nadal nie wskazują na obsługę kodeka (np. VP8 a VP9). Z drugiej strony format WebP zostaje skutecznie zamrożony, a jeśli dostawcy, którzy go wysyłają, zgodzą się na przesyłanie animowanego WebP, działanie WebP we wszystkich UA powinno być spójne, a nagłówek akceptacji „image/webp” sygnalizuje już obsługę WebP, więc nie trzeba wprowadzać żadnych nowych zmian w nagłówku akceptowania.

  3. Stos filmów Chromium jest zoptymalizowany pod kątem płynnego odtwarzania i zakłada, że w danym momencie odtwarzany jest tylko 1 lub 2 filmy. W związku z tym implementacja intensywnie zużywa zasoby systemowe (wątki, pamięć itp.), aby zmaksymalizować jakość odtwarzania. Taka implementacja nie jest skalowana dobrze do wielu jednoczesnych filmów i trzeba ją przeprojektować, aby pasowała do stron z dużą ilością obrazów.

  4. WebM nie uwzględnia obecnie wszystkich technik kompresji z WebP. W związku z tym ten obraz kompresuje się znacznie lepiej w formacie WebP niż w innych rozwiązaniach:


1 Podczas wszystkich porównań animowanych GIF-ów z animowanymi plikami WebP wykorzystaliśmy korpus z około 7000 animowanych GIF-ów pobranych losowo z internetu. Te obrazy zostały przekonwertowane do formatu animowanego WebP za pomocą narzędzia „gif2webp” z użyciem ustawień domyślnych (utworzonego na podstawie najnowszego drzewa źródłowego libwebp z dnia 08.10.2013 r.). Liczby porównawcze to średnie wartości tych obrazów.

2 Czasy dekodowania zostały obliczone z wykorzystaniem najnowszych bibliotek libwebp + ToT Blink na dzień 08.10.2013 przy użyciu narzędzia porównawczego. „Czas dekodowania przy użyciu przewijania” to „Dekodowanie pierwszych 5 klatek, czyszczenie pamięci podręcznej bufora ramek”, dekodowanie pięciu kolejnych klatek itd.

3 WebM przechowuje w pamięci 4 klatki referencyjne YUV, z których każda jest zapisywana (szerokość+96)*(wysokość+96) pikseli. W przypadku formatu YUV 4:2:0 potrzebne są 4 bajty na 6 pikseli (czyli 3/2 bajtów na piksel). Zatem te ramki referencyjne wykorzystują 4*3/2*(width+96)*(height+96) B pamięci. WebP wymaga natomiast dostępności tylko poprzedniej klatki (w RGBA), czyli 4*width*height B pamięci.

4 Renderowanie animowane w technologii WebP wymaga Google Chrome w wersji 32 lub nowszej