habrahabr

Почему файлы стали меньше: форматы фото и видео (JPEG, HEIC, AV1)

  • понедельник, 20 октября 2025 г. в 00:00:05
https://habr.com/ru/companies/ruvds/articles/956918/

Форматы изображений и видео вроде JPEG, HEIC и AV1 давно стали частью нашей повседневности. Мы снимаем на смартфон, пересылаем фото в мессенджерах, заливаем видео в облако — и редко задумываемся, почему одинаковый кадр может весить в три раза меньше, но выглядеть так же.

Если вы хотите разобраться, как современные кодеки экономят место, почему файлы стали компактнее и зачем это вообще понадобилось, то эта статья для вас.

Историческая справка 

Вы наверняка сталкивались с такими словами, как JPEG, PNG, может быть, даже HEIC, но вряд ли задумывались, откуда они взялись и зачем вообще нужны разные форматы изображений. Почему мы не можем просто хранить фото «как есть» — без всех этих сокращений и кодеков? Ответ прост: если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт. Интернет времён 90-х просто не справился бы с таким объёмом данных. 

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

Громкое заявление, да, но не менее громкий формат, который используется везде. Он позволял делать снимки, которые потом влезали на крошечные по современным меркам карточки памяти и при этом выглядели достаточно чётко, чтобы распечатать или отправить по email. Алгоритм сжатия был с потерями, то есть картинка режется, чтобы уменьшить объём. Формат разбивал изображение на блоки и превращал их в набор частот с помощью дискретного косинусного преобразования (DCT), а потом отбрасывал то, что человеческий глаз всё равно не заметит. 

Как результат, картинка выглядит всё так же, а файл становился +- в десять раз меньше. Ещё одна крутая фишка — режим Progressive. Изображение сначала отображается в низком качестве и постепенно дорабатывается. В эпоху dial-up-модемов это было как-то так: вы видели, что фото точно загрузится, и могли подождать, пока прогрузится лицо собеседника из ICQ.

С течением времени пользовательский аппетит рос, добавилось высокое качество цветопередачи, поддержка новых функций. Главное, возникла необходимость снизить нагрузку на ограниченные каналы связи мобильных устройств и стримингов. И технологии не стояли на месте. К середине 2010-х JPEG начал сдавать позиции — мобильные камеры снимали в десятки мегапикселей, а видео стало 4K. Apple представила HEIC, основанный на видеокодеке HEVC (H.265). Он вдвое эффективнее по сжатию, поддерживает 16-битный цвет и позволяет хранить не просто снимок, а целую сцену — с Live-эффектом или изменением освещения.

Следующим шагом стал AV1 — формат, разработанный чтобы вырваться из-под патентных ограничений альянсом AOMedia. В него входит Google, Mozilla, Microsoft и другие гиганты. AV1 сжимает данные ещё лучше — примерно на 15% эффективнее HEIC, при этом полностью бесплатен. Сегодня AV1 активно внедряют YouTube, Netflix и браузеры (от Chrome до Firefox).

Его кодирование сложнее и энерговместимее, но это уже не та проблема, что была в 1990-х. Теперь важно другое — чтобы потоковое видео грузилось мгновенно, не ело трафик и не роняло качество при плохом соединении.

Как устроено сжатие в JPEG, HEIC и в современных кодеках вроде AV1

Рассмотрим подробно, как устроено сжатие в наиболее популярных форматах JPEG, HEIC и современных кодеках, таких как AV1, чтобы понять технические принципы блочного и предсказательного сжатия, компенсации движения, трансформаций частоты, а также роль chroma subsampling и quantization. Также объясним, чем отличаются контейнеры от кодеков и почему HEIC использует контейнер HEIF, а AV1 — это преимущественно видеокодек.

Блочное сжатие в JPEG

Многие не знают, что JPEG — это не столько формат, сколько алгоритм. Большинство JPEG-изображений, которые вы видите, представлены в формате JFIF (JPEG File Interchange Format). Внутри JFIF применяется алгоритм сжатия JPEG. 

По сути, задача сводится к тому, чтобы: сохранить нужное и выбросить ненужное. Но как сделать так, чтобы глаз не замечал разницы? Сначала картинку переводят из RGB в цветовое пространство YCrCb — там яркость (Y) выделена отдельно от двух цветовых каналов (Cr, Cb), потому что человеческий глаз гораздо чувствительнее к изменениям яркости, чем к мелким цветовым деталям. От этого цветовые каналы можно хранить с большей потерей — это называется chroma subsampling.

Источник.

Дальше изображение режут на блоки 8×8 пикселей и применяют к каждому блоку дискретное косинусное преобразование (DCT). DCT переводит значения пикселей в «частоты»: в углу матрицы оказываются низкие частоты — крупные формы и фон, в другой части — высокие частоты — шум и мелкие детали. Многие высокочастотные коэффициенты оказываются малыми или близкими �� нулю, их можно отбросить практически без видимой потери качества.

Квантование — главный lossy-шаг. Каждую DCT-матрицу делят поэлементно на матрицу квантования и округляют. Чем жёстче квантование, тем больше нулей и тем сильнее сжатие, но тем заметнее артефакты. Именно при агрессивном квантовании появляются характерные квадраты 8×8 и «ореолы» у резких контуров (эффект Гиббса).

Конвейер операций, используемый в алгоритме JPEG. Источник.
Конвейер операций, используемый в алгоритме JPEG. Источник.

После квантования данные считывают «зигзагом». Сначала идут низкие частоты, затем высокие, потом применяют run-length encoding для длинных серий нулей. В конце поток кодируется Хаффманом. Фотографии сжимают в 5–15 раз без явного ухудшения восприятия. Управлять компромиссом «размер ↔ качество» удобно через матрицу квантования или параметр качества.

Сжатие HEIC

Как и JPEG, HEIC возник из практической потребности: сохранить максимум полезной информации при минимуме байтов. Но если JPEG для «отброса незаметного», то HEIC уже контейнер и набор видеотехник, которые позволяют хранить не только изображение, но и сцену, слои и метаданные — аккуратно и компактно.

Источник.

HEIC — это контейнер HEIF, в котором чаще всего используются кадры, закодированные по видеокодеку HEVC (H.265). Apple впервые сделала HEIC форматом по умолчанию в iOS 11 и macOS High Sierra в 2017 году, и с тех пор он стал массовым в мобильной фотографии. По сути, на нём та же задача — уменьшить объём файлов при сохранении качества. В этом контейнере, в одном файле можно хранить несколько кадров (burst, live photo), вспомогательные изображения (depth map, alpha-канал), слои редактирования и стандартные метаданные (EXIF/XMP). Файл может не только показывать картинку, но и передавать данные для постобработки.

Технически HEIC — это современный формат, который использует более продвинутые технологии сжатия, чем старый JPEG. Вместо фиксированных маленьких блоков HEIC работает с блоками разного размера, что позволяет точнее сохранять детали. Он также применяет разные способы прогнозирования изображения и улучшенные алгоритмы кодирования, например, энтропийное кодирование — CABAC вместо статичного Хаффмана. Благодаря этому файлы HEIC на 40–50% меньше JPEG при том же качестве. Встроенные фильтры уменьшают размытости и искажения, делая картинку чище (deblocking, SAO).

Главные плюсы

  • Поддержка глубины цвета и HDR — формально стандарт допускает до 16 бит на выборку (хотя на практике большинство устройств оперируют 8/10/12 битами).

  • Альфа, depth и мультикадры — используется для хранения обычных фотографий, Live Photo, панорам и портретных снимков с глубиной резкости.

  • Поддержка прозрачности — может хранить изображения с прозрачным фоном. Это нужно для графики, дизайна, веба и приложений с наложением элементов.

Ограничения тоже имеются. HEVC окружён патентными пулами и лицензионной историей, поэтому в некоторых экосистемах нужны или доп. кодеки/расширения, или платная установка (например, HEVC extension в Windows). Да и в реальном обмене иногда удобнее конвертировать в JPEG/PNG. 

Современный видеокодек AV1

Любите смотреть видео на YouTube? А вы знали, что скорость загрузки ваших видосиков и то, что их не дёргает каждую секунду, зависит от технологий сжатия и доставки контента? 

Один из таких оберегов — AV1. Выпущен он был в 2018 году и стал следующей ветвью после VP9 и HEVC, особенно для интернет-стриминга и высоких разрешений. 

Здесь нефиксированные блоки, множество вариантов блочной структуры и размеров трансформов для энкодера. Методы у AV1 продвинутые: он предсказывает содержимое внутри каждого кадра и между кадрами, а также позволяет разбивать видео на блоки разных размеров. Биты распределяются туда, где они важнее. А мы имеем лучшее качество при меньшем битрейте. Он поддерживает 10-битный цвет, HDR и способен передавать видео высокого качества даже при низкой скорости соединения.

Экономия трафика привела к нагрузке на процессор. Сложнее кодирование и воспроизведение → нужен более мощный CPU. Поэтому на старте его внедрение шло медленно. Буст дал рост аппаратной поддержки в GPU и SoC и теперь AV1 на устройствах и в браузерах. Для одиночных изображений используют формат AVIF. Это по сути AV1-кадры в контейнере на базе ISOBMFF, т. к. для фото AVIF даёт лучшее сжатие и расширенные возможности. 

Из интересного: AOMedia уже анонсировала следующее поколение, AV2 с датой готовности примерно до конца 2025 года. Авторы заявляют существенный прирост эффективности кодирования — порядка 30% меньшего битрейта при том же качестве по VMAF — а также улучшения для AR/VR, split-screen и работы с контентом экранного типа. Скорее всего, AV2 потребует обновлённой аппаратной поддержки, чтобы раскрыть свои преимущества в массовых сценариях. 

Особенность

HEIC (HEIF + HEVC)

JPEG (JPG)

PNG

Тип сжатия

Обычно с потерями (используется HEVC intra-кодирование), поддержка lossless в некоторых случаях

С потерями (DCT + квантование)

Без потерь (lossless)

Глубина цвета

Теоретически до 16 бит на канал

В большинстве случаев — 8 бит на канал

Поддерживает 1, 2, 4, 8 или 16 бит на канал — то есть до 48 бит на пиксель (без альфа) или до 64 бит (с альфа) 

Прозрачность (альфа-канал)

Поддерживается как дополнительный компонент внутри HEIF-контейнера

Не поддерживается

Поддерживается, включая альфа-канал

Анимация / мультиизображения

Поддерживает хранение нескольких изображений, серий и живых фото (image sequences в контейнере) 

Нет — одно изображение на файл

Поддерживается (расширение APNG)

Метаданные

Расширенная поддержка: Exif, XMP, метаданные HDR, информация об альфа, глубине, редактировании 

Поддерживает Exif, IPTC, XMP

Метаданные поддерживаются в текстовых блоках (текстовые чанки)

Совместимость / распространённость

Хорошая на современных устройствах iOS / Android; веб и Windows поддержка частичная, требует кодеков/расширений 

Максимальная совместимость — поддерживается почти повсеместно

Широко поддерживается, особенно в веб и графических инструментах

Типичное применение

Смартфон-фото, живые снимки, компактное хранение с дополнительной информацией

Универсальное фото, обмен, публикации

Графика, логотипы, интерфейсы, изображения с прозрачностью

Поддержка HDR / расширенного динамического диапазона

Возможна (зависит от реализации и метаданных) 

Ограниченная/нетипичная

Ограниченная

Размер файла при равном визуальном качестве

Как правило самый компактный, особенно для фото с деталями

Средний

Самый большой (из-за lossless-хранения)

Причины, почему файлы стали меньше


Если посмотреть на то, почему фото и видео стали занимать меньше места, то всё упирается не в одно изобретение, а в эволюцию сразу нескольких технологий. Сначала — кодеки. Старые форматы, вроде JPEG и H.264, были рассчитаны на другие реалии — тогдашние процессоры, скорости сети и сценарии хранения. Стандарты, вроде HEVC (H.265) и AV1, стали умнее: они используют предсказательное кодирование, когда часть изображения восстанавливается на основе соседних блоков или предыдущих кадров. Теперь применяются переменные размеры макроблоков, адаптивное квантование и сложные модели движения. 

Дальше — вычислительные мощности. Ростом производительности CPU и появление аппаратных ускорителей помогли тяжёлым алгоритмам. Сейчас кодирование и декодирование происходит на уровне железа — через встроенные блоки в чипсетах смартфонов и видеокарт. Это не только ускорило обработку, но и снизило энергопотребление. Может, вы не заметили, но аппаратное ускорение стало стандартом: iPhone, Android-смартфоны, YouTube, Netflix — все уже работают с HEVC или AV1 под «капотом».

Ещё одна причина — профили и пресеты кодеков. Кодек — это набор возможностей, а профиль определяет, какие из них будут использованы в конкретном случае. Пресет задаёт баланс между скоростью и качеством. Смартфоны выбирают быстрые инструменты для HEIC, чтобы снимки можно было оперативно загрузить в облако или отправить через мессенджер, без ожидания длительной обработки. Другой профиль применяется для архивных фото или профессиональной печати. Здесь HEIC с меньшей компрессией и более высоким качеством. Видеосервисы делают то же самое: выбирают пресет под конкретное устройство и канал связи, чтобы поток подстраивался под реальные условия сети.

И, наконец, экономия трафика и конкуренция за скорость загрузки сделали уменьшение размера файлов приоритетом не только для производителей, но и для платформ. Telegram, WhatsApp*, Instagram* и другие мессенджеры автоматически перекодируют файлы при отправке, уменьшая разрешение и битрейт с помощью оптимальных профилей, чтобы фото или видео открывались мгновенно и не «весили» лишнего. 

Менее популярные механизмы и альтернативы

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

Изображения

  • PNG (Portable Network Graphics): Популярен для веб-графики. Поддерживает прозрачность и сжатие без потерь (логотипы, иконки, короче там, где важна чёткость контуров).

  • GIF (Graphics Interchange Format): Используется для анимации и простых изображений с ограниченным количеством цветов до 256 (анимированные эмоции, мемы, открытки с добрым утром).

  • WebP: Формат изображений от Google. Сжимает как с потерями (аналог JPEG), так и без потерь (аналог PNG), (поддерживает анимацию и прозрачность).

  • AVIF: Новый формат, основанный на кодеке AV1. 

  • TIFF (Tagged Image File Format): Используется в полиграфии и профессиональной фотографии. Поддерживает сжатие без потерь, слои и цветовые профили, сохраняя высокое качество.

  • RAW: Необработанные данные, полученные прямо с матрицы цифровой камеры. Сохраняет максимум информации, позволяя фотографам производить гибкую обработку. Каждый производитель камер может иметь свой RAW-формат (например, CR2, NEF).

  • SVG (Scalable Vector Graphics): Векторные изображения, можно масштабировать без потери качества.

  • BMP (Bitmap): Стандартный растровый формат Windows, сохраняющий изображения без сжатия, что приводит к очень большим размерам файлов.

Видеокодеки

Источник.
  • H.265 (HEVC): Эффективнее, чем AVC, но непопулярный из-за лицензионных отчислений.

  • VP9: Кодек, который AV1 превосходит по сжатию на 30% (от Google).

  • VVC (H.266): Ещё более высокое сжатие, чем AV1, но и более требовательный.

VVC тоже требует лицензионных отчислений, так что может повторить незавидную судьбу HEVC.

Такие механизмы и форматы занимают свои ниши. Они находят себя, например, при работе с контентом в 360°, с анимированными и прозрачными изображениями или в обработке с сохранением максимума деталей.

Небольшой тест

Если провести тест на 700 JPEG-ов общим размером ≈2825 MiB (снимки примерно 4000×3000 пикселей) и пропустить их через современные программы для сжатия на обычном ноутбуке с процессором Pentium Gold, 2 ядрами и 32 ГБ RAM, запустив по два параллельных процесса и отключив многопоточность энкодеров, картина получается такая:


2m05.338s    488MiB        AVIF-AOM-s9

 6m48.650s    502MiB        WebP-m4

 8m07.813s    479MiB        AVIF-AOM-s8

12m16.149s    467MiB        WebP-m6

12m44.386s    752MiB        JXL-l0-q85-e4

13m20.361s   1054MiB        JXL-l0-q90-e4

18m08.471s    470MiB        AVIF-AOM-s7

 3m21.332s   2109MiB        JXL-l1-q__-e_

14m22.218s   1574MiB        JXL-l0-q95-e4

32m28.796s    795MiB        JXL-l0-q85-e7

39m4.986ss    695MiB        AVIF-RAV1E-s9

53m31.465s    653MiB        AVIF-SVT-s9

Кстати, забыл упомянуть, что большинство фото (что-то снятое на улице, страницы журналов и всякие предметы) снималось на средненький Android и такой же средненький фотик от Samsung.

По сочетанию скорости и итогового размера выиграли AVIF (реализация libaom) и WebP. Примеры из прогонов: AVIF-AOM s9 — ~2 мин 05 с и итог 488 MiB; WebP-m4 — ~6 мин 48 с / 502 MiB; AVIF-AOM s8 — ~8 мин 07 с / 479 MiB; при более медленных пресетах WebP (m6) можно получить ещё меньший размер (467 MiB) за счёт времени кодирования. В тех же тестах JPEG-XL чаще получался либо медленнее, либо давал большие файлы — самый быстрый JXL-прогон выглядел как простая «перезапись» без реального перекодирования, а другие конфигурации выдавали значительно большие размеры и дольше шли.

Реализации AV1-энкодеров сильно отличаются. RAV1E и SVT на этом железе кодировали заметно дольше: порядка 39–53 минут, и при этом итоговые файлы были не лучше, чем у libaom в быстрой конфигурации. То есть на практике libaom-AVIF дал лучший результат на таком железе.

Вывод простой: WebP остаётся хорошим вариантом, если важна совместимость и быстрое декодирование. JPEG-XL в этих экспериментах уступал по одной из метрик. При выборе формата в ориентируйтесь не только на цифры сжатия, но и на то, есть ли надёжные реализации энкодеров/декодеров для вашей инфраструктуры.

*Принадлежит компании Meta, которая запрещена в России как экстремистская.

© 2025 ООО «МТ ФИНАНС»