Notatki zespołu o rzemiośle, formatach i drobnych decyzjach stojących za dobrym wynikiem.
Dlaczego WebP nie jest powszechnie obsługiwany w programach na komputery
WebP został wydany przez Google w 2010 roku, ale przyjęcie przez oprogramowanie na komputery pozostawało daleko w tyle za obsługą w przeglądarkach. Przeglądarki przyjęły WebP wcześnie, ponieważ kontrolują własne silniki renderujące, a Google aktywnie optymalizował obsługę WebP w Chrome jako przewagę konkurencyjną. Programom na komputery zajmuje więcej czasu przyjęcie nowego formatu obrazu, ponieważ każdy program utrzymuje własny zestaw narzędzi dekodujących, a obsługa nowego formatu wymaga testów na długim ogonie przypadków brzegowych. Adobe Photoshop, używany przez większość zawodowych fotografów i projektantów, dostał natywną obsługę WebP dopiero w wersji 23.2 pod koniec 2022 roku. Programy Microsoft Office wciąż obsługują WebP niespójnie na różnych platformach według stanu na 2026 rok. Oprogramowanie RIP do druku i większość starszych narzędzi archiwizujących nigdy nie przyjęło WebP. Praktyczny skutek jest taki, że plik, który wyświetla się idealnie w przeglądarce, może być całkowicie odrzucony przez program, którego użytkownik potrzebuje, a konwersja na PNG to niezawodne obejście.
Jak WebP osiąga przewagę kompresji nad PNG
PNG korzysta z kompresji DEFLATE, uniwersalnego algorytmu bezstratnego z 1996 roku. Przed kompresją stosuje zestaw odwracalnych filtrów na każdym wierszu skanowania i koduje wynik strumieniem zlib. To skuteczne, ale zaprojektowane zanim badania nad uczeniem maszynowym i kodekami wideo dały lepsze techniki. Tryb stratny WebP korzysta z transformacji blokowej wywodzącej się z kompresji wideo VP8, stosując przewidywanie wewnątrz klatki i dyskretną transformację kosinusową do makrobloków 16x16. Tryb bezstratny WebP korzysta z przewidywania przestrzennego, transformacji koloru i etapu kodowania LZ77, który jest strukturalnie wydajniejszy od DEFLATE dla typowej treści obrazów. Opublikowane testy Google pokazują WebP bezstratny mniejszy od PNG o około 26 procent na zbiorze standardowych obrazów testowych, a WebP stratny z alfą około trzy razy mniejszy od PNG przy porównywalnej jakości wizualnej. Kierunek z PNG na WebP wykorzystuje te zyski, kierunek z WebP na PNG je odwraca, stąd większy wynik.
Zmierzone przykłady wzrostu rozmiaru pliku
Zmierzone w Chrome 148, desktopowy Linux, z użyciem platformowej ścieżki zapisu PNG zastosowanej do zdekodowanych danych wejściowych WebP. Mała grafika w stylu wektorowym o rozmiarze 400x300 pikseli, zapisana jako WebP w jakości 80, jest dekodowana i zapisywana ponownie jako PNG w mniej więcej 15 do 25 ms z typowym wzrostem rozmiaru o 20 do 30 procent. Fotograficzny WebP 1024x768, około małego rozmiaru, jest dekodowany i zapisywany ponownie jako PNG w mniej niż 100 ms z typowym wzrostem od 3 do 5 razy. Duży fotograficzny WebP 3840x2160, około większego rozmiaru, jest zapisywany jako PNG w około 1,2 sekundy ze wzrostem od 5 do 10 razy w zależności od złożoności sceny. Praktyczna górna granica to mniej więcej duże zdjęcie WebP stające się plikiem PNG o wielokrotnie większym rozmiarze. Te liczby odzwierciedlają różnicę w wydajności kompresji między tymi dwoma formatami i rosną liniowo wraz z liczbą pikseli.
Przezroczystość alfa w drodze tam i z powrotem
8-bitowy kanał przezroczystości w WebP i PNG korzysta z tego samego zakresu wartości, gdzie 0 oznacza pełną przezroczystość, a 255 pełną nieprzezroczystość. Gdy przeglądarka dekoduje WebP z alfą, tworzy bufor pikseli z wartościami RGBA, gdzie składowa A odzwierciedla pierwotne dane alfa. Gdy ten bufor jest zapisywany ponownie jako PNG, zapis PNG umieszcza wartości A bezpośrednio w kanale alfa PNG. Nie zachodzi żaden etap komponowania, nie nakłada się żaden kolor tła i premnożenie nie wprowadza ubocznych zmian w wartościach pikseli. Wynikiem jest bezstratne przeniesienie kanału alfa, gdzie wartość krycia każdego piksela w PNG odpowiada temu, co przechowywał WebP. W obrazach z delikatnym wygładzaniem na krawędziach każda pośrednia wartość alfa, na przykład piksel o kryciu 40 procent na krawędzi tekstu, przechodzi drogę w całości. Ta wierność sprawia, że PNG jest właściwym wyborem zamiast JPG, gdy program docelowy musi pokazywać obraz na wielu tłach.
Zachowanie EXIF i metadanych
Proces ponownego zapisu zdejmuje metadane EXIF, IPTC i XMP z wyniku PNG. Pliki WebP mogą nieść dane EXIF osadzone w swoim bloku metadanych, a te dane giną, gdy przeglądarka dekoduje i zapisuje obraz ponownie. Profile kolorów ICC podążają inną drogą, gdzie Chrome i Safari zachowują znacznik profilu ICC sRGB w wyniku PNG po zdekodowaniu WebP, a Firefox zdejmuje wszystkie metadane wraz z profilem ICC. Praktyczny skutek to wynik bezpieczny dla sRGB we wszystkich przeglądarkach, ale każdy szeroki profil barwny osadzony w źródłowym WebP nie przetrwa w Firefoksie. Do profesjonalnych procesów fotograficznych, które opierają się na drodze tam i z powrotem ze znacznikiem ICC, użyj narzędzia do konwersji świadomego metadanych. Do standardowej obsługi obrazów internetowych usunięcie metadanych jest zwykle akceptowalne i ma niewielką zaletę, lekko zmniejszając rozmiar wynikowego pliku.
Weryfikacja prywatności w praktyce
Twierdzenie, że żadne dane pliku nie opuszczają przeglądarki, można sprawdzić bez żadnych specjalnych narzędzi. Otwórz przeglądarkę, przejdź na stronę webp na png, a następnie otwórz narzędzia deweloperskie przeglądarki klawiszem F12 lub przez menu prawego przycisku. Przełącz się na zakładkę Sieć, wyczyść istniejące żądania i uruchom konwersję, przeciągając plik WebP. Przefiltruj listę żądań po Fetch, XHR lub Wszystkie. Lista pokazuje zero żądań wychodzących zawierających dane obrazu podczas zapisu. Jedyne obecne żądania sieciowe to zasoby początkowego ładowania strony i standardowe pingi analityczne, które rejestrują wyłącznie odsłony strony i dane wydajności Core Web Vitals, bez żadnej treści obrazu. Każdy większy zdalny konwerter WebP na PNG generuje co najmniej POST wysyłki i GET pobrania na konwersję, oba zapisane w dzienniku serwera. Architektura na urządzeniu oznacza, że takich wpisów w dzienniku po prostu nie ma, co jest znaczącą różnicą dla użytkowników konwertujących pliki z wrażliwą treścią.
