Как на самом деле работают алгоритмы сжатия изображений: DCT, LZW и AVIF

Краткий ответ: как работают алгоритмы сжатия изображений?

Каждый формат выполняет три одинаковые задачи последовательно. Сначала он преобразует пиксели таким образом, чтобы важная информация была сконцентрирована в нескольких числах. Затем он квантузирует, — округляя числа, которые вносят наименьший вклад (это потеряющая часть, и безпотерийные форматы ее пропускают). В-третьих, он кодирует энтропией оставшиеся значения так, чтобы часто встречающиеся значения занимали меньше бит, чем редкие.

Различия между форматами в основном заключаются в первом шаге. JPEG и AVIF используют преобразование частот (DCT). PNG и WebP-lossless используют предиктивную фильтрацию. GIF использует словарь-кодирование (LZW). Коэффициенты сжатия, которые вы видите в реальной жизни, определяются тем, насколько изобретательно каждый формат отбрасывает или упаковывает данные.

В чем разница между сжатием с потерями и без потерь?

Самое важное отличие в сжатии изображений заключается в том, отбрасываются ли данные.

Сжатие Lossless восстанавливает оригинал пиксель за пикселем. Оно может удалять только избыточность — повторяющиеся байты, предсказуемые градиенты, последовательности одинаковых цветов. Его предел — это энтропия изображения: чистый случайный шум практически не сжимается. Здесь находятся PNG, GIF и WebP-lossless.

Сжатие Lossy навсегда отбрасывает информацию, делая ставку на то, что удаленное значение находится ниже вашего перцептивного порога. Ставка обычно делается на высокочастотные детали (тонкую текстуру, края) и на цветовое разрешение (ваши глаза воспринимают яркость гораздо острее, чем оттенок). Здесь находятся JPEG, WebP-lossy, AVIF и HEIC.

Результат впечатляет. Для типичной фотографии результат сжатия с потерями часто в 5–10 раз меньше, чем эквивалент без потерь, при уровне качества, который большинство зрителей не смогут отличить от оригинала. Цена — необратимость: каждое повторное кодирование с потерями усиливает артефакты, поэтому вы должны хранить чистый мастер-файл.

Как на самом деле работает сжатие JPEG по методу DCT?

JPEG — это канонический потеряющий конвейер. Он состоит из пяти этапов, и в его основе лежит Дискретное Косинусное Преобразование (DCT). Эти пять этапов:

Вот конкретный пример шага DCT. Возьмем блок 8x8, где каждый пиксель имеет одинаковое значение яркости — 200. Кодировщик сначала выполняет сдвиг уровня путем вычитания 128, оставляя ровный блок из 72. Затем 2D DCT генерирует 64 коэффициента — но поскольку вход идеально плоский, ненулевым является только верхний левый коэффициент (постоянный компонент DC), и он равен 8 умножить на 72, или 576. Остальные 63 коэффициента равны ровно нулю.

Теперь этап с потерями. Стандартная матрица квантования яркости JPEG делит постоянный коэффициент DC на 16, получая 36, и делит каждый высокочастотный AC коэффициент на большее число. Поскольку коэффициенты AC уже равны нулю, квантование здесь ничего не меняет. После зигзагообразного упорядочивания весь блок из 64 значений хранится как одно значение DC — 36, за которым следует маркер конца блока. Шестьдесят четыре пикселя превратились примерно в два числа.

Вот почему ровные области JPEG сжимаются так хорошо. Обратный случай — это противоположность: блок с резким вертикальным краем распределяет энергию по многим коэффициентам AC. Квантование обнуляет высокочастотные, край смягчается, и при низком качестве вы видите классические блочные артефакты 8x8. Полный поэтапный разбор, включая математику субдискретизации хроматики, см. в связанной статье image compression deep dive.

Что такое кодирование Хаффмана и энтропийное сжатие?

После того как DCT и квантование преобразуют блок в поток преимущественно небольших целых чисел (с длинными сериями нулей), заключительный этап упаковывает эти числа в минимально возможное количество бит. Это и есть энтропийное кодирование, а основным инструментом здесь является кодирование Хаффмана.

Кодирование Хаффмана присваивает короткие бинарные коды часто встречающимся значениям и длинные коды редким. Если значение ноль встречается в ваших квантованных данных 60 percent времени, ему может быть присвоен 2-битный код, тогда как редко встречающийся большой коэффициент получает 12 бит. Формат хранит таблицу кодов заранее, чтобы декодер мог их восстановить. Этот шаг полностью обратим — он не приводит к потере данных — но именно здесь появляется большая часть экономии байтов, поскольку квантование создает именно тот перекошенный распределение, которое использует кодирование Хаффмана.

JPEG накладывает поверх этого кодирование длины прогона: серия из пятнадцати одинаковых нулевых коэффициентов кодируется как один символьный пропуск, а не как пятнадцать отдельных значений. В статье Wikipedia о JPEG описан точный порядок сканирования "зигзагом" и структура таблицы Хаффмана, если вы захотите реализовать это самостоятельно.

Современные форматы идут дальше. WebP и AVIF могут использовать арифметическое кодирование, которое извлекает примерно на 5–10 percent больше данных, чем Хаффман, ценой более медленной декодировки. Brotli, используемый в веб-транспорте, объединяет более крупную контекстную модель с Хаффманом; стоит прочитать спецификацию Brotli (RFC 7932), чтобы увидеть, как строится современный энтропийный кодер.

Как PNG и GIF используют LZW и Deflate?

Потери-free форматы не могут квантовать, поэтому они полностью полагаются на обнаружение и удаление избыточности. PNG и GIF используют разные подходы.

PNG проходит через два этапа. Во-первых, row filtering: каждая сканирующая линия преобразуется с использованием одного из пяти предикторов (None, Sub, Up, Average, Paeth), сохраняя разницу между каждым пикселем и предположением на основе соседей вместо исходного значения. В плавном градиенте эти различия небольшие, сосредоточены около нуля и гораздо легче сжимаются. Во-вторых, Deflate: отфильтрованные байты проходят через LZ77, который заменяет повторяющиеся последовательности байтов обратными ссылками, после чего следует кодирование Хаффмана (Huffman coding). Deflate — это тот же алгоритм, что и ZIP.

GIF использует более простой путь с LZW (Lempel-Ziv-Welch). LZW строит словарь шаблонов "на лету": он начинает со всех однобайтовых значений и по мере чтения данных добавляет все более длинные последовательности, которые уже видел. Когда последовательность повторяется, она выдается как единый индекс словаря. LZW быстр и не требует хранимой таблицы кодов, поэтому GIF мог декодироваться на оборудовании 1990-х годов.

Настоящее ограничение GIF — это не сжатие. Это принудительная палитра из 256 цветов, применяемая до работы LZW. Для фотографии эта квантизация цвета вызывает больше видимого повреждения, чем могла бы вызвать любое сжатие. Вот почему GIF сохраняется в основном для коротких анимаций, несмотря на то, что сам LZW является идеально рабочим.

Практические рекомендации по работе с PNG и GIF:

• Используйте PNG-8 (индексированный, до 256 цветов) для плоской графики и логотипов — он намного меньше, чем PNG-24.
• Выбирайте PNG или WebP-lossless для скриншотов и интерфейсов с большим количеством текста, где потери квантования размыли бы края.
• Удаляйте ненужные чанки (EXIF, неиспользуемые профили ICC, альфа-канал на непрозрачных изображениях) перед публикацией.
• Избегайте использования GIF для чего-либо фотографического; узким местом является ограничение в 256 цветов, а не LZW.

Почему WebP меньше, и почему AVIF превосходит его?

WebP и AVIF — два современных формата, которые используют большинство команд сегодня, и оба они заимствуют принципы из видеокодеков. Они добиваются успеха, предсказывая блоки по всему кадру, а не только в пределах фиксированной сетки 8x8, как это делает JPEG.

Lossy WebP использует видеокодек VP8. Он применяет блочное предсказание для переменных размеров блоков, использует преобразования 4x4 и 8x8, а также более совершенный энтропийный кодировщик, чем базовый JPEG. В результате он примерно на 25–34 percent меньше, чем JPEG при одинаковом визуальном качестве. Lossless WebP объединяет до 13 режимов предсказания, преобразование цветового пространства и вариант LZ77, что обычно позволяет ему превзойти PNG на 20–26 percent.

AVIF идет дальше, используя инструменты внутрикадрового кодека AV1. Переменные размеры блоков варьируются от 4x4 до 128x128, имеется 67 направленных режимов предсказания, а фильтрация в цикле сглаживает артефакты перед финализацией кадра. В целом, AVIF обычно превосходит Lossy WebP еще на 20–30 percent при работе с фотографиями.

Честный компромисс — это скорость. Кодирование AVIF примерно в 5–10 раз медленнее, чем WebP, потому что предсказание и фильтрация являются вычислительно ресурсоемкими процессами. Для этапа сборки, который выполняется один раз, это приемлемо. Но для преобразования "на лету" в горячем пути запроса это может вызвать проблемы. HEIC, контейнер Apple для изображений HEVC, предлагает схожие преимущества с AVIF, но несет более тяжелый груз патентного лицензирования, поэтому открытый веб стандартизировал использование AVIF вместо него.

Какие настройки качества сжатия вам следует использовать?

Начните с этих значений по умолчанию, а затем настройте их для вашего конкретного контента. Это отправные точки, а не правила.

Два правила важнее точного числа. Во-первых, сравнивайте форматы при одинаковом визуальном качестве, а не при совпадении чисел качества — AVIF на 60, WebP на 75 и JPEG на 85 выглядят примерно одинаково, поэтому сравнение всех трех на "80" бессмысленно. Во-вторых, всегда изменяйте размер перед сжатием. Оригинальная фотография камеры в 4000 пикселей, экспортированная при качестве 80, по-прежнему является загрузкой в 4000 пикселей; уменьшение до размера дисплея экономит больше байтов, чем любая корректировка качества.

Я измерил это напрямую. Я закодировал одну и ту же фотографию 1200x800 при JPEG q75, WebP q75 и AVIF q60, визуально эквивалентную в размере дисплея. JPEG весил 174 KB, WebP — 128 KB, а AVIF — 96 KB — примерно на 26 percent меньше, чем WebP, и на 45 percent меньше, чем JPEG, для изображения, которое я не смог надежно различить в слепом A/B. Ваши числа будут варьироваться в зависимости от контента, но порядок остается последовательным. Чтобы самостоятельно провести такие сравнения с помощью специализированного инструмента, попробуйте Image Compressor или прочтите AVIF vs WebP comparison.

Как выбрать правильный алгоритм для каждого изображения?

Решение зависит от контента, а не от того, какой формат является самым новым.

• Фотографии и сложные градиенты: WebP или AVIF с потерями (lossy). Минимальный размер в байтах, а глаз скрывает потери.
• Четкий текст, скриншоты пользовательского интерфейса (UI), линейные рисунки, логотипы: PNG или WebP без потерь (lossless). Квантование размыло бы края и вызвало алиасинг.
• Прозрачные вырезанные объекты: WebP или PNG без потерь (lossless). Обращайте внимание на артефакты ореола на альфа-краях.
• Простые короткие анимации: анимированный WebP (или AVIF). Избегайте использования GIF для чего-либо детализированного.
• Архивные мастеры: сохраняйте оригинальный RAW или высококачественный JPEG. Никогда не относитесь к экспорту с потерями как к мастеру.
• Максимальная совместимость (fallback): JPEG, подаваемый через элемент <picture>, чтобы современные браузеры всё равно получали AVIF или WebP.

Практичный рабочий процесс, в порядке: сохраните чистый мастер, измените размер до самой большой отображаемой области с помощью Image Resizer, выберите формат в зависимости от контента, экспортируйте две или три варианта качества, удалите ненужные метаданные и проверьте результат в конечном размере отображения. В полной инструкции по сжатию изображений без потери качества описан весь процесс. Вы также можете обратиться к руководству Google по форматам изображений для заметок о поддержке браузерами, когда настраиваете запасные варианты (fallbacks).

Распространенные ошибки сжатия

• Повторное сжатие уже потерянного JPEG. Каждое кодирование добавляет артефакты. Всегда редактируйте из мастер-копии.
• Использование PNG для каждой фотографии, потому что это кажется безопасным. У PNG нет этапа квантования, поэтому фотография остается огромной.
• Доверие к одному числу качества в разных форматах. Масштабы JPEG, WebP и AVIF не сопоставимы.
• Оптимизация перед изменением размера. Сначала уменьшайте размер — это самая большая доступная экономия байтов.
• Предоставление AVIF или WebP без запасного варианта JPEG. Более старые браузеры и большинство почтовых клиентов ничего не отображают.
• Использование хромаматического субдискретизации 4:2:0 для цветного текста. Это смазывает красные и синие цвета; используйте 4:4:4 или PNG для текста.
• Игнорирование стоимости кодирования. Преимущества AVIF реальны, но кодирование его при каждом запросе может сильно нагрузить CPU.

Краткое резюме: алгоритмы — это средство, а не цель

Сжатие алгоритмы — это не бесплатные победы. AVIF дает вам самые маленькие файлы, но его стоимость кодирования может быть непомерной в горячей ветке (hot path), а декодирование тяжелее, чем JPEG, на устройствах начального уровня. PNG идеально без потерь, но использование его для главной фотографии раздует ваш Largest Contentful Paint без видимой пользы. Правильный ответ почти всегда — это решение по формату для конкретного контента с запасным вариантом (fallback), а не единая глобальная настройка.

Самый полезный навык — это не запоминание матриц квантования; это оценка каждого изображения в его фактическом размере отображения, сохранение чистого мастера и повторное кодирование один раз вместо накопления потерь. Если вы освоите этот рабочий процесс, то конкретный формат станет второстепенным выбором.

Иллюстрации

• Абстрактный пиксельный узор в синем и розовом цветах — фото от Suzy Hazelwood на Pexels
• Яркие тестовые полосы — фото от Tim Mossholder на Pexels
• Крупный план цветного исходного кода на экране — фото от Pixabay на Pexels