Заметки команды о мастерстве, форматах и небольших решениях, стоящих за хорошим результатом.
Почему 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 скачивания на конвертацию, оба пишутся в журнал сервера. Архитектура на устройстве означает, что таких записей в журнале просто нет, и это значимая разница для пользователей, конвертирующих файлы с конфиденциальным содержимым.
