Возьмите одну и ту же фотографию на 12 МП (4000 × 3000 пикселей) и сохраните её дважды. Один раз в PNG: 24 МБ. Второй раз в JPEG с качеством 90: 3,4 МБ. Откройте оба файла рядом: разницы не видно. Увеличьте до 400%, и она наконец проявится: лёгкое смягчение в волосах и траве, слабые ореолы вдоль самых резких границ.
Два файла, одна картинка, семикратная разница в размере. Оба файла рабочие, просто каждый подписался на своё. PNG подписался хранить каждый бит. JPEG подписался сохранить всё, что вы способны заметить. Почти всё в устройстве форматов изображений вытекает из того, какое из этих двух обязательств берёт на себя формат.
Почему сжатие раскололось на два лагеря
В 1948 году Клод Шеннон опубликовал «A Mathematical Theory of Communication» и задал сжатию жёсткий нижний предел. Его теорема о кодировании источника гласит: нельзя представить данные без потерь компактнее их энтропии, то есть среднего количества информации на символ. Совершенно случайное изображение не сжимается вообще. Сплошная белая картинка сжимается практически до нуля. Любое реальное изображение лежит где-то на этой шкале, и ни один алгоритм сжатия без потерь не опустится ниже положенного ему места.
Сжатие с потерями существует благодаря лазейке. Энтропийный предел относится к данным, которые у вас есть, а не к данным, которые вы оставляете. Если сначала заменить изображение чуть другим, с более низкой энтропией, предел опустится вместе с ним. В этом весь трюк: сначала изменить данные, потом упаковать. Инженерный вопрос лишь в том, какие изменения допустимы.
Ответ зависит от двух вещей. Во-первых, от содержимого. Скриншот панели настроек состоит в основном из ровных заливок и повторяющихся форм: энтропия низкая, пиксели легко предсказываются. Фотография леса на уровне пикселей это дробовой шум фотонов и шум считывания матрицы: энтропия высокая, предсказанию почти не поддаётся. Во-вторых, от потребителя. Программе, читающей файл, нужны точные биты. А у человеческого зрения есть врождённая терпимость к неточностям: ограниченная острота зрения к цветным деталям, слабая чувствительность к мелкой высокочастотной текстуре и восприятие яркости, завязанное на отношения, а не на абсолютные значения (закон Вебера, порог заметности примерно от 1 до 2% яркости).
Так форматы и разошлись по лагерям. Если содержимое предсказуемо, а потребитель это машина или человек, разглядывающий пиксели под лупой, выбирайте сжатие без потерь. Если содержимое зашумлено, а потребитель это человек на расстоянии вытянутой руки, можно позволить себе кое-что забыть.
Как работает сжатие с потерями
Про кодеки с потерями часто говорят, что они «выбрасывают данные». Это правда, но неточная: выбрасываются конкретные данные, отобранные моделью человеческого зрения. Конвейер выглядит так:
-
Перевод RGB в яркостно-цветностное пространство (YCbCr в JPEG, похожие разбиения в других). Глаз различает детали яркости гораздо лучше, чем детали цвета, поэтому цветностные каналы можно хранить в четверть разрешения (субдискретизация 4:2:0). Один этот шаг сокращает исходные данные примерно на 50%, и в большинстве фотографий это незаметно.
-
Преобразование каждого блока в частоты. JPEG использует дискретное косинусное преобразование для блоков 8 × 8. JPEG 2000 использует вейвлеты. AV1 и HEVC используют преобразования большего, переменного размера. Результат всегда одной и той же формы: несколько крупных коэффициентов описывают общие формы, множество мелких описывает тонкую текстуру.
-
Квантование. Каждый коэффициент делится на шаг квантования и округляется до целого. Мелкие коэффициенты становятся нулями. Это единственный шаг с потерями во всём конвейере, а настройка качества в кодировщике это просто множитель к этим шагам. При качестве 95 шаги мелкие и сохраняется почти всё. При качестве 30 шаги крупные, и большая часть тонкой текстуры обнуляется.
-
Энтропийное кодирование того, что осталось. Зигзагообразный обход, кодирование длин серий, код Хаффмана или арифметическое кодирование. Этот этап уже без потерь: он только упаковывает квантованные числа.
Прочитайте этот список ещё раз. Шаги 1, 2 и 4 обратимы: это просто перекладка чисел с места на место. А на шаге 3 изображение действительно разрушается: намеренно, одна ошибка округления за другой.
У такого разрушения узнаваемый почерк. Опустите качество слишком низко, и появятся блочность (видимые границы сетки 8 × 8 в небе и на стенах), звон (ореолы вокруг текста и контрастных краёв) и бандинг (плавные градиенты, распадающиеся на ступени). Пересохраните файл с потерями, и конвейер запустится снова уже на повреждённых данных, поэтому потеря поколения накапливается: десятое пересохранение JPEG выглядит как акварель с первого.
Как работает сжатие без потерь
Кодеки без потерь не позволяют себе таких вольностей. Декодированный файл обязан совпасть с оригиналом бит в бит, поэтому всё, что им остаётся, это моделировать и упаковывать. Стандартный рецепт из двух этапов.
Этап первый: декорреляция. PNG фильтрует каждую строку пикселей перед сжатием. Для каждой строки кодировщик выбирает один из пяти предикторов (None, Sub, Up, Average, Paeth) и сохраняет разность между фактическим пикселем и предсказанием. Сплошная белая строка превращается в один белый пиксель и тысячи нулей. Плавный градиент превращается в мелкие, медленно меняющиеся остатки. В любом случае числа становятся маленькими и группируются около нуля, а именно это и нужно следующему этапу.
Этап второй: энтропийное кодирование. PNG использует DEFLATE, тот же алгоритм, что стоит за gzip и zip, собранный из двух идей 1970-х. LZ77 ищет повторяющиеся последовательности байтов и заменяет каждый повтор указателем (расстояние, длина) на предыдущие 32 КБ данных. Код Хаффмана затем назначает короткие битовые коды частым значениям и длинные редким. Ни один из шагов ничего не теряет. По упакованному потоку всегда можно в точности восстановить исходные байты.
Вот почему PNG блистателен на скриншотах и безнадёжен на фотографиях. Графика интерфейсов повторяется: одинаковые строки, повторяющиеся иконки, длинные участки ровного цвета. LZ77 находит совпадения повсюду, а фильтры превращают всё оставшееся в значения, близкие к нулю. Фотография не повторяет ничего. Шум делает каждый пиксель чуть отличным от соседей, предикторы промахиваются, остатки остаются большими и случайными, и LZ77 не находит, на что указать. PNG на фотографии 12 МП обычно выжимает от 1,3:1 до 1,6:1 относительно исходных пикселей. JPEG при визуально схожем качестве даёт 10:1.
Зато взамен вы получаете абсолютную гарантию: декодируйте PNG, посчитайте хеш пикселей, и он совпадёт с исходным каждый раз. Для скриншотов, которые пойдут через OCR, сканов, которые будут редактировать повторно, медицинских и научных изображений, которые могут оказаться в статье или в суде, эта гарантия и есть весь смысл.
Почему JPEG в 1992 году поставил на сжатие с потерями
Joint Photographic Experts Group начала работу в 1986 году, и ограничения той эпохи объясняют каждое проектное решение. Жёсткий диск на 20 МБ стоил сотни долларов. Дискета на 1,44 МБ была стандартным способом переносить файлы. Модемы работали на 14,4 кбит/с, если везло: загрузка одной несжатой фотографии VGA на 921 КБ занимала примерно девять минут. Версия с потерями 10:1 доходит меньше чем за минуту. Версия без потерь 2:1 всё равно идёт больше четырёх.
Собственные тесты комитета говорили, что без потерь дальше не продвинуться. Фотографический контент, заявленная цель («изображения с непрерывным тоном»), просто не содержит достаточной избыточности. Раз математика упёрлась, оставался единственный неиспользованный резерв: зритель. Формат спроектировали вокруг него.
Меньше известно, что опубликованный ими в 1992 году стандарт (ISO/IEC 10918-1) содержит режим без потерь. Он полностью обходится без DCT, предсказывает каждый пиксель максимум по трём соседям, используя один из семи фиксированных предикторов, и энтропийно кодирует остатки: концептуально тот же трюк, который PNG применит тремя годами позже. Его почти никто не реализовал. Декодеры его игнорировали, кодировщики тоже, а когда медицинской визуализации действительно понадобился JPEG без потерь, она получила отдельный стандарт (JPEG-LS, ISO/IEC 14495, 1999).
Комитету пришлось также обходить патенты. Вариант арифметического кодирования в JPEG был опутан патентами IBM на Q-coder, поэтому свободный от роялти базовый профиль остановился на коде Хаффмана, а большинство реализаций арифметический вариант так и не тронули. Патенты, диктующие устройство кодеков, не были новостью в 1992 году. Дальше стало только хуже.
По сути, JPEG был психовизуальной ставкой: последние 5× сжатия это не математика, а биология.
Почему PNG в 1995 году поставил на сжатие без потерь
PNG начинался не как инженерный проект. Он начинался с юридического пожара.
В декабре 1994 года Unisys объявила, что будет брать лицензионные отчисления с программ, использующих GIF, потому что сжатие GIF опиралось на алгоритм LZW, покрытый патентом 1985 года, который Unisys унаследовала. CompuServe, создатель GIF, заключила сделку и переложила расходы на разработчиков. Графические сообщества Usenet пришли в ярость: GIF был бесплатным семь лет, и целый пласт изображений и инструментов раннего веба внезапно оказался на запатентованной территории.
Через несколько недель, в начале января 1995 года, Томас Баутелл опубликовал первый черновик замены. Добровольцы выработали дизайн в списках рассылки за считаные месяцы. PNG 1.0 вышел в октябре 1996 года как рекомендация W3C, а затем как RFC 2083 в марте 1997 года.
Два требования обсуждению не подлежали. Каждый алгоритм должен был быть чист от патентов, что означало DEFLATE (сочетание LZ77 и Хаффмана из PKZIP Фила Каца, реализованное в zlib Жаном-Лу Гайи и Марком Адлером). И формат обязан был быть без потерь, точка. Сообщество заменяло GIF; замена, портящая изображения, была бы мёртворождённой, а патентный аудит всё равно не оставлял места перцептивным трюкам, на которых работал JPEG.
Содержимое имело не меньшее значение. PNG строился под то, что в GIF реально хранили: логотипы, диаграммы, штриховую графику, иконки, скриншоты. Резкие края и ровный цвет, как раз тот контент, где звон JPEG заметнее всего. Гонка за фотографиями означала бы изобретать DCT заново и соревноваться с укоренившимся, свободным от роялти JPEG. PNG выбрал бой, который был ему по силам, и победил вчистую. Патент на GIF истёк в 2003 году (в 2004-м за пределами США), но к тому времени PNG уже занял его место.
Почему сжатие с потерями всё равно победило на рынке
PNG занял свою нишу. JPEG забрал мир.
Причина в объёме. Изображения в вебе это в подавляющем большинстве фотографии, а для фотографий сжатие с потерями не компромисс, а правильный инструмент. Web Almanac 2025 оценивает долю JPEG примерно в 57% всех отдаваемых изображений, спустя три десятилетия. Социальные ленты, новостная фотография, снимки товаров, объявления о недвижимости: везде непрерывно-тоновый контент, где картинка, сжатая с потерями при качестве 75, визуально неотличима от исходника на экранах, которыми люди реально пользуются.
Экономика давит в ту же сторону. Хранение и трафик оплачиваются за байт, а 10:1 против 2:1 это не разница в процентах, это пятикратная разница в стоимости доставки при приемлемом качестве. Скорость страницы следует за размером файла, а размер файла за сжатием. Каждая камера и каждый телефон поставляются с настройкой с потерями по умолчанию (JPEG или HEIC). Каждая CMS генерирует миниатюры с потерями. Социальные платформы перекодируют каждую загрузку: отчасти ради размера, отчасти чтобы срезать метаданные и всё вредоносное, что может в них прятаться. Фотограф может загрузить безупречный TIFF; лента отдаст JPEG качества 85.
Сжатие без потерь не столько проиграло, сколько отступило туда, где его гарантия важна: скриншоты и UI-ассеты, где артефакты мгновенно видны, а контент и так хорошо сжимается; мастеры в конвейере редактирования, где каждое поколение с потерями накапливается; медицинская, юридическая и научная визуализация, где «достаточно близко» не доказательство. Внутри этих ниш PNG и TIFF вне конкуренции. Просто там нет трафика.
Где в итоге оказались форматы
| Формат | Год | Режимы | Где используется |
|---|---|---|---|
| JPEG | 1992 | С потерями (режим без потерь есть, но почти не используется) | Фотографии, универсальный запасной вариант |
| JPEG 2000 | 2000 | Оба (вейвлеты 9/7 с потерями и 5/3 без) | Цифровое кино, архивы |
| PNG | 1996 | Без потерь | Скриншоты, UI, графика |
| GIF | 1987 | Без потерь, максимум 256 цветов | Простая анимация, мемы |
| TIFF | 1986 | Контейнер: raw, LZW, ZIP или JPEG | Печать, сканирование, архивирование |
| WebP | 2010 | Оба | Веб-доставка, ~11% LCP-изображений |
| HEIC | 2015 | С потерями на практике (у HEVC есть режим без потерь) | Фото с iPhone |
| AVIF | 2019 | Оба | Лучшие коэффициенты сжатия с потерями в браузерах |
| JPEG XL | 2021 | Оба, плюс пересжатие JPEG без потерь | Safari, Chrome за флагом |
Выделяются две тенденции. Новые кодеки больше не выбирают сторону: WebP, HEIC, AVIF и JPEG XL поставляются с режимами с потерями и без в одной спецификации, а JPEG 2000 делал это ещё в 2000 году. Вопрос «с потерями или без» сместился с «какой формат» на «какой режим». И пограничные случаи продолжают появляться. JPEG XL умеет без потерь пересжимать существующий JPEG примерно до 80% его размера, а этот трюк возможен только потому, что оба лагеря тридцать лет изучали математику друг друга.
Как выбирать на практике
Дерево решений короткое:
- Публикуете фотографию? С потерями. JPEG, когда важна совместимость, WebP или AVIF, когда важен размер.
- Сохраняете скриншот, логотип или что угодно с текстом и ровным цветом? Без потерь. PNG.
- Редактируете? Держите мастер без потерь, экспортируйте копии с потерями и никогда не пересохраняйте файл с потерями в том же формате. Каждое поколение накапливает ущерб.
- Конвертируете? Подбирайте выход под задачу, а не под вход. Скриншот PNG, отправляющийся в фотогалерею, должен стать JPEG или WebP. JPEG, отправляющийся в дизайн-макет, должен стать PNG: не потому, что качество вырастет (оно не вырастет), а потому, что оно перестанет падать.
На этом пункте многие спотыкаются именно о фотографии с iPhone. HEIC это уже сжатие HEVC с потерями. Конвертация HEIC в PNG ничего не восстанавливает; она замораживает текущее состояние и гарантирует, что дальше потерь не будет, что всё равно полезно, если вы собираетесь редактировать. Для публикации самый прямой путь это конвертация сразу в JPEG. Наши конвертеры HEIC в JPG, HEIC в PNG и HEIC в WebP выполняют преобразование локально в вашем браузере, так что файл не покидает устройство.
Та же логика покрывает остальную матрицу. Перенос JPEG в рабочий процесс без потерь: JPG в PNG. Уменьшение скриншота PNG для веба: PNG в JPG или PNG в WebP, когда нужны файлы поменьше с сохранением прозрачности. В обратную сторону WebP в PNG и WebP в JPG возвращают совместимость со старым софтом. Если у вас на руках несжатые сканы BMP, BMP в JPG, BMP в PNG и BMP в WebP дают тот же выбор «с потерями или без» за один шаг. Даже рендеринг документов упирается в ту же развилку: экспорт страницы PDF как изображения означает выбор между PDF в JPG для фотографических страниц и PDF в PNG, когда текст должен остаться чётким.
Тридцать лет спустя выжили те форматы, которые точно знали, что их пользователи готовы забыть, а что нет.



