Про HEVC/HEIC

(скопирую из фейсбука, чуть расширив, может и пригодится кому)

Довелось тут залезть в потроха формату HEIC/HEIF, не могу не высказать к нему свое отношение, хоть никто вроде и не спрашивал.

Summary: хороший формат, с потенциалом.

Что там хорошего:

• есть 8 и 10 бит (может быть и больше, но в дикой природе никто не видел)
• Сжатие H.265 гораздо лучше (старого) JPEG при том же/сравнимом качестве.
• Контейнер (MP4/ISO BMFF) тоже удобный, удобно разбирать, можно что хочешь положить (стандартно кладут EXIF и XMP, но нет причин не класть туда вообще что угодно). Уж всяко лучше "контейнеров" JPEG и (тем более) PNG.
• Можно разместить что уже угодно: отдельную картинку, сборную картинку (grid), последовательность, "анимированный гиф", превьюшки любых размеров, многослойную (оверлей) картинку.
• На практике (Apple Canon) картинки больших размеров порезаны на тайлы (grid), что позволяет параллельное декодирование. У Canon порезано крупновато, у Apple (IMHO) мелковато, но на современных многоядерных компьютерах и телефонах - это позволяет декодировать во все ядра (в отличие от тех же JPEG и PNG, да и от TIFF: параллельных распаковщиков тайловых TIFF практически же и нет, хотя казалось бы).
• Кодировать, естественно, тоже можно параллельно.
• Кодировать-декодировать можно и аппаратно, благо H.265 кодек влепили уже много где. Это не очень нужно для фото (45-мегапиксельный файл от EOS R5 распаковывается на 16 ядрах за ~200 миллисекунд, считая YCC-RGB конверсию), но если вы лепите какую-то потоковую обработку тысяч файлов, или же кодирование....

Что там плохого:

• Cложная и очень большая спецификация
• Нет (ну или я не нашел) указания на приоритет метаданных:
  К примеру, если в irot-box (часть формата) указан один поворот, а в EXIF - другой, то у какого будет приоритет? Ну вроде бы у irot. А если какой-то "редактор" решил, что вот lossless rotation будем делать заданием тега в EXIF и сам так работает....? Этот трюк работал в JPEG (потому что EXIF - часть спецификации JPEG по сути) и я уже предвижу как он откочует в HEIC.
• Есть некоторая недоделка в части цвета, а именно
  • Цвет задается
    • или тройкой полей, задающих конверсию YCC-RGB, RGB Color Primaries для получившегося RGB и тоновой кривой (это именно единичные поля, задающие "номер строчки в стандартной таблице")
    • или вложенным ICC профилем (причем есть два типа записей для профиля, но неясно в чем отличие)
  • Если цвет задан таблицами - нет профиля и наоборот.
  • Соответственно, если вы цепляете профиль, то конверсия YCC-RGB идет со стандартными коэффициентами (номер два), а задать свою нельзя.  JPEG в этом месте был гибче, хотя никто YCC-RGB коэффициенты на практике нестандартные не использовал.
  Понятно почему так сделано: аппаратные кодеки (скорее всего) имеют внутри готовые таблицы коэффициентов, но вот странность есть.

Для разработчика:

• Если вам нужно поддержать "еще один формат" как-то, берите libheif и все будет.
• Но libheif очень медленная, особенно для тайловых изображений (а это основной массив HEIF/HEIC файлов на сегодня)
  • Конверсия цвета из, к примеру, 10-bit YCC (planar) в 8-bit RGB interleaved - будет делаться в три стадии (в 16-бит RGB planar, потом в 8 бит planar, потом в interleaved).
  • Для тайловых изображений полностью избавиться от конверсии не получится, тайлы склеиваются внутри в формате RGB-planar.
  • Декодирование тайлов делается последовательно, хотя backend (libde265) умеет параллельно.
• Поэтому, если интересует результат (в смысле скорости), писать по хорошему придется самому:
  • Параллельное декодирование
  • YCC-RGB-конверсию
  • совокупление какого-то разбора ISO BMFF с декодером.
• Если вы вдруг хотите прославиться на ниве опенсорца - истину говорю вам, готового приличного решения для HEIC/HEIF нет, можно вот прямо начинать делать (я - не буду :).
  В принципе, можно и libheif довести до ума, не знаю примут ли такой патч в апстрим.