Нотатки від команди про майстерність, формати та невеликі рішення, що стоять за добрим результатом.
Чому WebP не має універсальної підтримки в настільних програмах
WebP випустила Google у 2010 році, але засвоєння настільним програмним забезпеченням відставало від браузерів на роки. Браузери засвоїли WebP рано, бо керують власними рушіями відтворення, а Google активно оптимізувала підтримку WebP у Chrome як конкурентну перевагу. Настільним програмам потрібно більше часу, щоб засвоїти новий формат зображення, адже кожна програма містить власний стек декодування, а підтримка нового формату вимагає тестування на довгому хвості граничних випадків. Adobe Photoshop, яким користується більшість професійних фотографів і дизайнерів, отримав вбудовану підтримку WebP лише у версії 23.2 наприкінці 2022 року. Програми Microsoft Office досі обробляють WebP неоднорідно на різних платформах станом на 2026 рік. Програмне забезпечення RIP для друку та більшість застарілих інструментів архівації так і не засвоїли WebP. Практичний наслідок у тому, що файл, який бездоганно показується в браузері, може бути цілком відхилений програмою, яка потрібна користувачеві, і конвертація у PNG це надійний обхідний шлях.
Як WebP досягає переваги стиснення над PNG
PNG використовує стиснення DEFLATE, універсальний алгоритм без втрат від 1996 року. Перед стисненням він застосовує набір оборотних порядкових фільтрів і кодує результат потоком zlib. Це дієво, але спроектовано до того, як дослідження машинного навчання та відеокодеків дали кращі методи. Режим із втратами WebP використовує блокове перетворення, успадковане від відеостиснення VP8, застосовуючи внутрішньокадрове передбачення та дискретне косинусне перетворення до макроблоків 16x16. Режим без втрат WebP використовує просторове передбачення, перетворення кольору і ступінь кодування LZ77, яка структурно ефективніша за DEFLATE для типового вмісту зображень. Опубліковані тести Google показують WebP без втрат приблизно на 26 відсотків менший за PNG на наборі стандартних тестових зображень, а WebP із втратами та альфою приблизно втричі менший за PNG за зіставної візуальної якості. Напрямок від PNG до WebP використовує цей виграш, напрямок від WebP до PNG його обертає, звідси й більший результат.
Виміряні приклади зростання розміру файлу
Виміряно в Chrome 148, настільний Linux, з використанням платформного шляху запису PNG, застосованого до декодованих вхідних даних WebP. Невелика графіка у векторному стилі розміром 400x300 пікселів, збережена як WebP із якістю 80, декодується й перезаписується як PNG приблизно за 15 - 25 мс із типовим зростанням розміру на 20 - 30 відсотків. Фотографічний WebP 1024x768, близько 100 - 200 КБ, декодується й перезаписується як PNG менш ніж за 100 мс із типовим зростанням у 3 - 5 разів. Великий фотографічний WebP 3840x2160, близько 1 - великого розміру, записується як PNG приблизно за 1,2 секунди зі зростанням у 5 - 10 разів залежно від складності сцени. Практична верхня межа це приблизно фотографія WebP на великого розміру, що стає PNG на в кілька разів більшого розміру. Ці числа відображають різницю в ефективності стиснення між двома форматами і зростають лінійно з кількістю пікселів.
Альфа-прозорість при перетворенні туди й назад
8-бітний альфа-канал у WebP і PNG використовує той самий діапазон значень, де 0 це повна прозорість, а 255 це повна непрозорість. Коли браузер декодує WebP з альфою, він створює буфер пікселів зі значеннями RGBA, де складова A відображає початкові дані альфи. Коли цей буфер перезаписується як PNG, запис PNG поміщає значення A прямо в альфа-канал PNG. Жодного кроку компонування не відбувається, колір тла не накладається, а попереднє множення не вносить побічних змін у значення пікселів. Результат це передавання альфа-каналу без втрат, де значення непрозорості кожного пікселя в PNG збігається з тим, що зберігав WebP. Для зображень із тонким згладжуванням по краях кожне проміжне значення альфи, наприклад піксель із непрозорістю 40 відсотків біля краю тексту, проходить перетворення цілим. Саме ця точність робить PNG правильним вибором замість JPG, коли програмі-отримувачу потрібно показувати зображення на кількох тлах.
Поведінка EXIF і метаданих
Процес перезапису знімає метадані EXIF, IPTC і XMP з результату PNG. Файли WebP можуть нести дані EXIF, вбудовані в їхній блок метаданих, і ці дані губляться, коли браузер декодує й перезаписує зображення. Колірні профілі ICC ідуть іншим шляхом, де Chrome і Safari зберігають мітку профілю ICC sRGB у результаті PNG після декодування WebP, а Firefox знімає всі метадані разом із профілем ICC. Практичний наслідок це результат, безпечний для sRGB в усіх браузерах, але будь-який широкий колірний профіль, вбудований у початковий WebP, не переживе Firefox. Для професійних фотографічних процесів, що спираються на перетворення з міткою ICC, скористайтеся інструментом конвертації, який зважає на метадані. Для стандартної обробки вебзображень вилучення метаданих зазвичай прийнятне і має невелику перевагу, трохи зменшуючи розмір підсумкового файлу.
Перевірка приватності на практиці
Твердження, що жодні дані файлу не залишають браузер, можна перевірити без жодних спеціальних засобів. Відкрийте браузер, перейдіть на сторінку webp у png, потім відкрийте інструменти розробника браузера клавішею F12 або через меню правого клацання. Перейдіть на вкладку Мережа, очистіть наявні запити і запустіть конвертацію, перетягнувши файл WebP. Відфільтруйте список запитів за Fetch, XHR або Усі. Список показує нуль вихідних запитів із даними зображення під час запису. Єдині наявні мережеві запити це ресурси початкового завантаження сторінки і стандартні пінги аналітики, які фіксують лише перегляди сторінок і показники продуктивності Core Web Vitals, без жодного вмісту зображення. Кожен великий віддалений конвертер WebP у PNG створює щонайменше POST вивантаження і GET завантаження на конвертацію, обидва пишуться в журнал сервера. Архітектура на пристрої означає, що таких записів у журналі просто немає, що є вагомою різницею для користувачів, які конвертують файли з конфіденційним вмістом.
