Co to jest WebP? Dlaczego warto z niej korzystać?
WebP to metoda stratnej i bezstratnej kompresji, której można używać w przypadku wielu różnych zdjęć, obrazów przezroczystych i graficznych w internecie. Stopień kompresji stratnej można dostosować, dzięki czemu użytkownik może wybrać kompromis między rozmiarem pliku a jakością obrazu. Format WebP zapewnia zwykle o 30% lepszą kompresję niż JPEG i JPEG 2000 bez utraty jakości obrazu (patrz badanie porównawcze).
Format WebP ma na celu tworzenie mniejszych i lepiej wyglądających obrazów, które mogą przyspieszyć działanie internetu.
Które przeglądarki obsługują format WebP?
Webmasterzy, którzy chcą poprawić wydajność witryny, mogą łatwo tworzyć zoptymalizowane alternatywy WebP dla obecnych obrazów i wyświetlać je w sposób ukierunkowany w przeglądarkach obsługujących ten format.
- Obsługa stratnej kompresji WebP
- Google Chrome (na komputerze) w wersji 17 lub nowszej
- Google Chrome na Androida w wersji 25 lub nowszej
- Microsoft Edge 18+
- Firefox w wersji 65 lub nowszej,
- Opera 11.10 lub nowsza
- Natywna przeglądarka internetowa, Android 4.0 lub nowszy (ICS)
- Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur lub nowszy)
- Obsługa formatu WebP z kompresją stratną i bezstratną oraz kanału alfa
- Google Chrome (na komputer) w wersji 23 lub nowszej
- Google Chrome na Androida w wersji 25 lub nowszej
- Microsoft Edge 18+
- Firefox w wersji 65 lub nowszej,
- Opera 12.10 lub nowsza
- Natywna przeglądarka internetowa, Android 4.2 lub nowszy (JB-MR1)
- Pale Moon 26+
- Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur lub nowszy)
- Obsługa animacji WebP
- Google Chrome (na komputery i Androida) w wersji 32 lub nowszej
- Microsoft Edge 18+
- Firefox w wersji 65 lub nowszej,
- Opera 19+
- Safari 14 lub nowsza (iOS 14 lub nowszy, macOS Big Sur lub nowszy)
Zobacz także:
Jak sprawdzić, czy przeglądarka obsługuje format WebP?
Obrazy WebP powinny być wyświetlane tylko klientom, którzy mogą je prawidłowo wyświetlić, a w przypadku klientów, którzy nie mogą tego zrobić, należy używać starszych formatów. Na szczęście istnieje kilka technik wykrywania obsługi formatu WebP zarówno po stronie klienta, jak i po stronie serwera. Niektórzy dostawcy sieci CDN oferują wykrywanie obsługi formatu WebP w ramach swoich usług.
Negocjacja treści po stronie serwera za pomocą nagłówków Accept
Klienci internetowi często wysyłają nagłówek żądania „Accept”, który wskazuje formaty treści, jakie są gotowi zaakceptować w odpowiedzi. Jeśli przeglądarka z wyprzedzeniem poinformuje, że „akceptuje” format image/webp, serwer WWW będzie wiedzieć, że może bezpiecznie wysyłać obrazy WebP, co znacznie uprości negocjacje treści. Więcej informacji znajdziesz pod tymi linkami.
- Wdrażanie nowych formatów obrazów w internecie
- Wyświetlanie obrazów WebP użytkownikom za pomocą elementów HTML
Modernizr
Modernizr to biblioteka JavaScript, która ułatwia wykrywanie obsługi funkcji HTML5 i CSS3 w przeglądarkach internetowych. Poszukaj właściwości Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha i Modernizr.webp.animation.
Element HTML5 <picture>
HTML5 obsługuje element <picture>, który umożliwia wyświetlanie wielu alternatywnych miejsc docelowych obrazu w kolejności priorytetowej, tak aby klient żądał pierwszego obrazu kandydata, który może wyświetlić prawidłowo. Zobacz tę dyskusję na stronie HTML5 Rocks. Element <picture> jest obsługiwany przez coraz więcej przeglądarek.
W własnym kodzie JavaScript
Inną metodą wykrywania jest próba dekodowania bardzo małego obrazu WebP, który korzysta z określonej funkcji, i sprawdzenie, czy się to 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 innych działań i jest asynchroniczne. Oznacza to, że każdy kod, który zależy od obsługi formatu WebP, powinien być umieszczony w funkcji wywołania zwrotnego.
Dlaczego Google udostępniło format WebP jako open source?
Bardzo cenimy model open source. WebP to format open source, więc każdy może z niego korzystać i proponować ulepszenia. Wierzymy, że dzięki Twoim opiniom i sugestiom format WebP z czasem stanie się jeszcze bardziej przydatny.
Jak mogę przekonwertować osobiste pliki obrazów na format WebP?
Za pomocą narzędzia wiersza poleceń WebP możesz przekonwertować osobiste pliki obrazów na format WebP. Więcej informacji znajdziesz w artykule Korzystanie z formatu WebP.
Jeśli masz wiele obrazów do przekonwertowania, możesz użyć powłoki platformy, aby uprościć tę operację. Aby na przykład przekonwertować wszystkie pliki JPEG w folderze, spróbuj wykonać to działanie:
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 na popularny format, który korzysta z kompresji bezstratnej, np. PNG, a następnie wyświetlając pliki PNG w dowolnej przeglądarce lub przeglądarce obrazów. Aby szybko sprawdzić jakość WebP, zobacz galerię na tej stronie, gdzie znajdziesz porównania zdjęć obok siebie.
Jak uzyskać kod źródłowy?
Kod konwertera jest dostępny w sekcji pobierania na stronie projektu open source WebP. Kod lekkiego dekodera i specyfikacja VP8 znajdują się na stronie WebM. Specyfikację kontenera znajdziesz na stronie Kontener RIFF.
Jaki jest maksymalny rozmiar obrazu WebP?
Format WebP jest zgodny z VP8 na poziomie strumienia bitów i używa 14 bitów na szerokość i wysokość. Maksymalne wymiary obrazu WebP to 16383 x 16383 pikseli.
Jakie przestrzenie kolorów obsługuje format WebP?
Zgodnie ze strumieniem bitów VP8 stratny format 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 „Format Overview” standardu RFC 6386, VP8 Data Format and Decoding Guide.
Bezstratny format WebP działa wyłącznie z formatem RGBA. Zobacz specyfikację bezstratnego strumienia bitów WebP.
Dlaczego mój plik WebP bez utraty jakości różni się od oryginału?
Funkcje Simple Encoding API (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) korzystają z ustawień domyślnych biblioteki. W przypadku kompresji bezstratnej oznacza to, że opcja „dokładnie” jest wyłączona. Wartości RGB w całkowicie przezroczystych obszarach (czyli w obszarach o wartościach alfa równych 0) zostaną zmodyfikowane w celu poprawy kompresji. Aby tego uniknąć, użyj zasady WebPEncode() i ustaw WebPConfig::exact na 1. Zapoznaj się z dokumentacją interfejsu Advanced Encoding API.
Czy obraz WebP może być większy niż obraz źródłowy?
Tak, zwykle podczas konwertowania z formatu stratnego na bezstratny WebP lub odwrotnie. Wynika to głównie z różnicy w przestrzeni kolorów (YUV420 a ARGB) i konwersji między nimi.
Wyróżniamy 3 typowych sytuacji:
- Jeśli obraz źródłowy jest w bezstratnym formacie ARGB, przestrzenne próbkowanie w dół do formatu YUV420 wprowadzi nowe kolory, które są trudniejsze do skompresowania niż oryginalne. Zwykle dzieje się tak, gdy źródło jest w formacie PNG z niewielką liczbą kolorów: konwersja na stratny format WebP (lub podobnie na stratny format JPEG) może spowodować zwiększenie rozmiaru pliku.
- Jeśli źródło jest w formacie stratnym, użycie bezstratnej kompresji WebP do zachowania stratnego charakteru źródła zwykle spowoduje powstanie większego pliku. Nie dotyczy to tylko formatu WebP. Może się zdarzyć na przykład podczas konwertowania źródła JPEG na bezstratny format WebP lub PNG.
- Jeśli źródło jest w formacie stratnym i próbujesz skompresować je jako stratny plik WebP z wyższym ustawieniem jakości. Na przykład próba przekonwertowania pliku JPEG zapisanego w jakości 80 na plik WebP w jakości 95 zwykle spowoduje utworzenie większego pliku, nawet jeśli oba formaty są stratne.
Ocena jakości źródła jest często niemożliwa, dlatego w przypadku, gdy rozmiar pliku jest stale większy, zaleca się obniżenie docelowej jakości WebP.
Inną możliwością jest uniknięcie używania ustawienia jakości i zamiast tego określenie docelowego rozmiaru pliku za pomocą opcji
-sizew narzędziucwebplub równoważnego interfejsu API. Na przykład kierowanie na 80% rozmiaru oryginalnego pliku może okazać się bardziej niezawodne.
Pamiętaj, że konwersja źródła JPEG na stratny format WebP lub źródła PNG na bezstratny format WebP nie powoduje takich niespodzianek związanych z rozmiarem pliku.
Czy format WebP obsługuje wyświetlanie progresywne lub z przeplotem?
Format WebP nie oferuje progresywnego ani przeplatanego odświeżania dekodowania w sposób znany z formatów JPEG i PNG. Prawdopodobnie spowoduje to zbyt duże obciążenie procesora i pamięci klienta dekodującego, ponieważ każde zdarzenie odświeżania wymaga pełnego przejścia przez system dekompresji.
Dekodowanie progresywnego obrazu JPEG jest średnio równoważne 3-krotnemu dekodowaniu obrazu podstawowego.
WebP oferuje też przyrostowe dekodowanie, w którym wszystkie dostępne przychodzące bajty strumienia bitów są używane do jak najszybszego wygenerowania wiersza próbki, który można wyświetlić. Pozwala to zaoszczędzić pamięć i procesor oraz zmniejszyć wysiłek związany z ponownym rysowaniem po stronie klienta, a jednocześnie zapewnia wizualne wskazówki dotyczące stanu pobierania. Funkcja dekodowania przyrostowego jest dostępna w ramach interfejsu Advanced Decoding API.
Jak używać powiązań libwebp Java w projekcie na Androida?
WebP obsługuje powiązania JNI z prostymi interfejsami kodera i dekodera w katalogu swig/.
Tworzenie biblioteki w Eclipse:
- Sprawdź, czy masz zainstalowaną wtyczkę ADT oraz narzędzia NDK i czy ścieżka NDK jest prawidłowo ustawiona (Ustawienia > Android > NDK).
- Utwórz nowy projekt: Plik > Nowy > Projekt > Projekt aplikacji na Androida.
- Sklonuj lub rozpakuj libwebp do folderu o nazwie
jniw nowym projekcie. - Dodaj
swig/libwebp_java_wrap.cdo listyLOCAL_SRC_FILES. - Kliknij prawym przyciskiem myszy nowy projekt i wybierz Narzędzia Androida > Dodaj obsługę natywną…, aby uwzględnić bibliotekę w kompilacji.
Otwórz właściwości projektu i kliknij C/C++ Build (Kompilacja C/C++) > Behaviour (Zachowanie). Dodaj
ENABLE_SHARED=1do sekcjiBuild (Incremental build), aby utworzyć libwebp jako bibliotekę współdzieloną.Uwaga: ustawienie
NDK_TOOLCHAIN_VERSION=4.8zwykle zwiększa wydajność kompilacji 32-bitowych.Dodaj
swig/libwebp.jardo folderu projektulibs/.Utwórz projekt. Spowoduje to utworzenie
libs/<target-arch>/libwebp.so.Użyj
System.loadLibrary("webp"), aby wczytać bibliotekę w czasie działania programu.
Pamiętaj, że bibliotekę można utworzyć ręcznie za pomocą ndk-build i dołączonego Android.mk. W takim przypadku możesz ponownie wykonać niektóre z opisanych powyżej czynności.
Jak używać biblioteki libwebp w C#?
WebP można utworzyć jako bibliotekę DLL, która eksportuje interfejs libwebp API. Te funkcje można następnie zaimportować w języku C#.
Utwórz plik libwebp.dll. Ustawia to prawidłowo WEBP_EXTERN, aby wyeksportować funkcje interfejsu API.
libwebp> nmake /f Makefile.vc CFG=release-dynamicDodaj do projektu plik libwebp.dll i zaimportuj wybrane funkcje. Jeśli używasz prostego interfejsu API, wywołaj funkcję
WebPFree(), aby zwolnić 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ć animowanych plików WebP?
Zalety animowanego formatu WebP w porównaniu z animowanym GIF-em
Format WebP obsługuje 24-bitowy kolor RGB z 8-bitowym kanałem alfa, w porównaniu z 8-bitowym kolorem i 1-bitowym kanałem alfa w formacie GIF.
Format WebP obsługuje kompresję stratną i bezstratną. Jedna animacja może łączyć klatki skompresowane stratnie i bezstratnie. Format GIF obsługuje tylko kompresję bezstratną. Techniki kompresji stratnej WebP dobrze sprawdzają się w przypadku animowanych obrazów utworzonych z filmów z życia codziennego, które są coraz popularniejszym źródłem animowanych obrazów.
Format WebP wymaga mniejszej liczby bajtów niż GIF1. Animowane pliki GIF przekonwertowane na stratne pliki WebP są o 64% mniejsze, a bezstratne pliki WebP są o 19% mniejsze. Jest to szczególnie ważne w przypadku sieci komórkowych.
Dekodowanie formatu WebP w przypadku przewijania zajmuje mniej czasu. W Blinku przewijanie lub przełączanie kart może powodować ukrywanie i wyświetlanie obrazów, co skutkuje wstrzymywaniem animacji, a następnie przewijaniem ich do innego punktu. Nadmierne wykorzystanie procesora, które powoduje utratę klatek animacji, może również wymagać od dekodera przewijania animacji do przodu. W takich przypadkach animowany format WebP wymaga 0, 57 raza dłuższego czasu dekodowania2 niż GIF, co skutkuje mniejszym zacinaniem się podczas przewijania i szybszym powrotem do normy po skokach wykorzystania procesora. Wynika to z 2 zalet formatu WebP w porównaniu z GIF-em:
Obrazy WebP przechowują metadane informujące, czy każda klatka zawiera kanał alfa, co eliminuje konieczność dekodowania klatki w celu ustalenia tego faktu. Prowadzi to do dokładniejszego wnioskowania, od których poprzednich klatek zależy dana klatka, co zmniejsza niepotrzebne dekodowanie poprzednich klatek.
Podobnie jak nowoczesny koder wideo, koder WebP heurystycznie dodaje klatki kluczowe w regularnych odstępach czasu (czego nie robi większość koderów GIF). Znacznie ułatwia to przewijanie długich animacji. Aby ułatwić wstawianie takich klatek bez znacznego zwiększania rozmiaru obrazu, format WebP dodaje flagę „metody mieszania” dla każdej klatki oprócz metody usuwania klatek, której używa format GIF. Dzięki temu klatka kluczowa może być rysowana tak, jakby cały obraz został wyczyszczony do koloru tła, bez konieczności powiększania poprzedniej klatki do pełnego rozmiaru.
Wady animowanego formatu WebP w porównaniu z animowanym GIF-em
W przypadku braku wyszukiwania dekodowanie WebP w linii prostej jest bardziej obciążające dla procesora niż GIF. Stratny format WebP wymaga 2,2 raza więcej czasu na dekodowanie niż GIF, a bezstratny format WebP – 1,5 raza więcej.
Obsługa formatu WebP nie jest tak powszechna jak obsługa formatu GIF, która jest praktycznie uniwersalna.
Dodanie obsługi formatu WebP w przeglądarkach zwiększa rozmiar kodu i powierzchnię ataku. W Blinku jest to około 1500 dodatkowych wierszy kodu (w tym biblioteka demux WebP i dekoder obrazów WebP po stronie Blink). Pamiętaj, że ten problem może zostać w przyszłości ograniczony, jeśli formaty WebP i WebM będą miały więcej wspólnego kodu dekodowania lub jeśli możliwości formatu WebP zostaną włączone do formatu WebM.
Dlaczego nie obsługiwać po prostu formatu WebM w <img>?
W dłuższej perspektywie może mieć sens obsługa formatów wideo w tagu <img>. Jednak zrobienie tego teraz z założeniem, że WebM w <img> może pełnić proponowaną rolę animowanego formatu WebP, jest problematyczne:
Podczas dekodowania klatki, która zależy od poprzednich klatek, format WebM wymaga o 50% więcej pamięci niż animowany format WebP, aby przechowywać minimalną liczbę poprzednich klatek3.
Obsługa kodeków wideo i kontenerów różni się w zależności od przeglądarki i urządzenia. Aby ułatwić automatyczne transkodowanie treści (np. w przypadku serwerów proxy oszczędzających przepustowość), przeglądarki musiałyby dodawać nagłówki Accept wskazujące, jakie formaty obsługują ich tagi obrazów. Nawet to może być niewystarczające, ponieważ typy MIME, takie jak „video/webm” lub „video/mpeg”, nadal nie wskazują obsługi kodeka (np. VP8 vs. VP9). Z drugiej strony format WebP jest w zasadzie zamrożony, a jeśli dostawcy, którzy go udostępniają, zgodzą się na udostępnianie animowanego formatu WebP, zachowanie tego formatu we wszystkich UA powinno być spójne. Ponieważ nagłówek „image/webp” jest już używany do wskazywania obsługi formatu WebP, nie są konieczne żadne nowe zmiany nagłówka accept.
Stos wideo Chromium jest zoptymalizowany pod kątem płynnego odtwarzania i zakłada, że w danym momencie odtwarzane są tylko 1 lub 2 filmy. W rezultacie implementacja agresywnie wykorzystuje zasoby systemowe (wątki, pamięć itp.), aby zmaksymalizować jakość odtwarzania. Takie wdrożenie nie sprawdza się w przypadku wielu filmów odtwarzanych jednocześnie i wymagałoby przeprojektowania, aby można było go używać na stronach internetowych z dużą liczbą obrazów.
Format WebM nie zawiera obecnie wszystkich technik kompresji z formatu WebP. W rezultacie ten obraz jest znacznie lepiej kompresowany w formacie WebP niż w przypadku alternatywnych formatów:
1 Wszystkie porównania animowanych GIF-ów z animowanymi plikami WebP przeprowadziliśmy na korpusie około 7000 animowanych GIF-ów pobranych losowo z internetu. Te obrazy zostały przekonwertowane na animowane pliki WebP za pomocą narzędzia „gif2webp” z ustawieniami domyślnymi (utworzonego na podstawie najnowszego drzewa źródłowego libwebp z 8 października 2013 r.). Liczby porównawcze to średnie wartości z tych obrazów.
2 Czasy dekodowania zostały obliczone przy użyciu najnowszej wersji biblioteki libwebp i ToT Blink z dnia 8 października 2013 r. przy użyciu narzędzia do testów porównawczych. „Czas dekodowania z przeszukiwaniem” jest obliczany jako „Zdekoduj pierwsze 5 klatek, wyczyść pamięć podręczną bufora klatek, zdekoduj kolejne 5 klatek itd.”.
3 WebM przechowuje w pamięci 4 klatki referencyjne YUV, a każda z nich zawiera (szerokość+96)*(wysokość+96) pikseli. W przypadku YUV 4:2:0 potrzebujemy 4 bajtów na 6 pikseli (czyli 3/2 bajta na piksel). Te ramki odniesienia używają więc 4*3/2*(width+96)*(height+96) bajtów pamięci. WebP potrzebuje tylko poprzedniej klatki (w formacie RGBA), która zajmuje 4*width*height bajtów pamięci.
4 Renderowanie animowanych plików WebP wymaga Google Chrome w wersji 32 lub nowszej.