Новости · Форматы изображений

OpenEXR 3.5.0 добавил сжатие Zstandard и кодек LJ2K для профессиональных изображений

21 сентября 2026 года вышел OpenEXR 3.5.0 — первый мажорный релиз формата после версии 3.4.0 (сентябрь 2025). Обновление добавляет два новых метода сжатия: лossless Zstandard, сокращающий размер Deep-файлов на 20–30% по сравнению с ZIPS, и lossy-кодек LJ2K на базе High-Throughput JPEG 2000 как альтернативу DWA. Дополнительно расширена поддержка метаданных colorInteropID и закрыто четыре уязвимости OSS-Fuzz.

24 сентября 2026 Редакция LoadFile Чтение 6 мин
Многоканальные слои HDR-изображения в формате EXR с визуализацией сжатия Zstandard

Коротко: OpenEXR 3.5.0 вышел 21 сентября 2026. Два главных нововведения: лossless Zstandard (Deep-изображения на 20–30% меньше, чем при ZIPS; flat-файлы сопоставимы по размеру) и lossy-кодек LJ2K на базе HTJ2K (компактнее и быстрее DWA). Улучшена работа с метаданными цвета colorInteropID. Устранены четыре уязвимости из OSS-Fuzz.

Содержание
  1. Что такое OpenEXR и зачем его обновляют
  2. Zstandard: насколько меньше EXR-файлы
  3. Кодек LJ2K — lossy HDR на базе HTJ2K
  4. Метаданные цвета и улучшения Python API
  5. Уязвимости OSS-Fuzz и общие изменения
  6. Как обновиться до OpenEXR 3.5.0
  7. Источники

Что такое OpenEXR и зачем его обновляют

OpenEXR — профессиональный формат изображений с поддержкой HDR, разработанный Industrial Light & Magic и переданный под управление Academy Software Foundation (ASWF). Формат является отраслевым стандартом в VFX и анимации: его используют Blender, Nuke, DaVinci Resolve, Houdini и большинство рендереров промышленного уровня.

Файл .exr хранит многоканальные изображения с плавающей точкой (16-бит HALF, 32-бит FLOAT, 32-бит UINT), включая так называемые Deep-изображения — пиксели с несколькими значениями глубины. Это позволяет хранить в одном файле информацию о перекрывающихся объектах, что важно при компоузинге и эффектах.

До версии 3.5.0 OpenEXR поддерживал несколько схем сжатия: ZIPS (построчный zlib), ZIP, PIZ (вейвлет), PXR24, B44, DWA/DWAB (lossy, используемый в кино). В 3.5.0 добавлены ещё два варианта — Zstandard и LJ2K.

Zstandard: насколько меньше EXR-файлы

Zstandard (zstd) — алгоритм сжатия с открытым исходным кодом от Facebook, ставший стандартом de facto в системном ПО (применяется в ядре Linux, BSD, npm, Arch Linux). В OpenEXR 3.5.0 поддержка Zstandard доступна через новый идентификатор ZSTD_COMPRESSION (он же EXR_COMPRESSION_ZSTD в C API).

Перед передачей данных в compressor работает собственный конвейер подготовки данных: сначала ByteShuffle перегруппирует байты каналов по типу, затем, по желанию, применяется Delta Encoding, затем — перестановка каналов в оптимальном порядке. Только после этого данные попадают в Zstandard. Такой пайплайн увеличивает эффективность сжатия для типичных EXR-данных с плавающей точкой.

Flat-изображения (обычные многослойные рендеры) при Zstandard показывают сопоставимый с ZIPS размер файла — незначительно меньше или больше в зависимости от содержимого. Скорость сжатия и декомпрессии несколько выше, чем у ZIPS.

Deep-изображения выигрывают существенно. По данным команды OpenEXR, в ходе тестирования Deep-секвенций Deep Alpha и Deep ID Zstandard обеспечивает размер на 20–30% меньше, чем ZIPS. Deep-файлы используются для хранения данных о просвечивающихся объектах (дым, стекло, волосы) — при большом числе кадров экономия заметна на практике.

Новая зависимость: zstd library. В составе репозитория поставляется вендорная копия zstd версии 1.5.7 на случай, если в системе не установлена совместимая версия библиотеки. Если zstd найдена системой — используется она.

Кодек LJ2K — lossy HDR на базе HTJ2K

Второе нововведение версии 3.5.0 — lossy-компрессор LJ2K, построенный на стандарте High-Throughput JPEG 2000 (HTJ2K). Кодек использует ту же библиотеку OpenJPH (минимальная версия 0.32.0) и те же параметры JPEG 2000, что и уже существующий HTJ2K256, но с важным отличием: HTJ2K256 — лossless, LJ2K — lossy.

Согласно релизным заметкам OpenEXR, LJ2K в большинстве сценариев даёт меньшие файлы и более высокую пропускную способность, чем DWA — основной lossy-кодек EXR, применяемый в кинопроизводстве. Это делает LJ2K потенциально привлекательным для рабочих процессов, где нужен компактный lossy без значительных потерь.

Технические ограничения LJ2K в 3.5.0:

  • Поддерживаемые типы пикселей: 16-бит HALF, 32-бит FLOAT, 32-бит UINT.
  • Lossy-кодирование применяется только к RGB-каналам; все остальные каналы (альфа, Z-глубина, ID и т. д.) сжимаются лossless-путём.
  • Степень искажений задаётся параметром quality в диапазоне от 1 до 150.
  • Перед кодированием RGB проходят перцептуальное преобразование: log-функция для значений больше 1, степенной закон для меньших значений — аналогично тому, как это устроено в DWA.

Важно: файлы, сжатые LJ2K, читаются только начиная с OpenEXR 3.5.0 — более старые версии библиотеки такой формат не поддерживают. Это нужно учитывать при выборе формата сохранения в пайплайнах, где задействованы разные версии инструментов. Blender 5.2 LTS также переходит на обновлённую версию OpenEXR — обновление зависимости до 3.5.0 ожидается в плановых обновлениях.

Метаданные цвета и улучшения Python API

OpenEXR 3.5.0 существенно расширяет работу с атрибутом colorInteropID — механизмом идентификации цветового пространства RGB-изображений, разработанным Academy Software Foundation в рамках проекта ColorInterop.

Конкретные изменения по colorInteropID:

  • Утилита командной строки exrstdattr теперь умеет читать и записывать атрибут colorInteropID.
  • В C++ и core API добавлены функции валидации цветовых метаданных заголовка файла.
  • Инструмент exrinfo выводит предупреждения при несоответствии метаданных цвета.
  • Добавлены вспомогательные функции для конвертации между хроматичностями (chromaticities) и colorInteropID.
  • Все новые функции получили привязки в Python-модуле OpenEXR.

Python-модуль в 3.5.0 получил несколько других улучшений:

  • Поддержка атрибута и объекта idManifest для Deep-файлов.
  • Многопоточное чтение и запись (numThreads).
  • Поддержка чтения/записи через объект BytesIO — без создания временного файла на диске.
  • Функции setMaxImageSize и setMaxTileSize для ограничения памяти при открытии ненадёжных файлов.

Помимо этого, классы AcesInputFile, AcesOutputFile и утилита exr2aces помечены как deprecated и будут удалены в одном из следующих релизов. Также исправлен давний баг в DWA-компрессоре, который мог молча создавать повреждённые файлы при определённых условиях.

Уязвимости OSS-Fuzz и общие изменения

Версия 3.5.0 закрывает четыре уязвимости, обнаруженные через проект OSS-Fuzz (непрерывный фаззинг с открытым исходным кодом):

  • OSS-Fuzz 514487287 — исключение с плавающей точкой (floating-point exception) в функции part_exceeds_memory_limits.
  • OSS-Fuzz 514423826 — деление на ноль (divide-by-zero) в той же функции.
  • OSS-Fuzz 513282267 — тайм-аут при обработке специально сконструированного EXR-файла в фаззере openexr_exrgaps_fuzzer.
  • OSS-Fuzz 512988066 — исчерпание памяти (OOM) при обработке аномального EXR через тот же фаззер.

Все четыре проблемы характерны для сценариев обработки недоверенных EXR-файлов. Если ваш сервис или приложение принимает EXR от внешних пользователей — обновление приоритетно. Схожие задачи по безопасности при работе с пользовательскими файлами решают и другие форматы: например, открытый кодек AV2/dav2d тоже регулярно получает исправления безопасности через программы фаззинга.

Как обновиться до OpenEXR 3.5.0

  1. Проверьте текущую версию: exrinfo --version в терминале или через заголовочные файлы (OPENEXR_VERSION_STRING).
  2. Linux (Fedora/RHEL 10+): sudo dnf upgrade openexr — пакет 3.5.0 ожидается в стандартных репозиториях в течение нескольких недель после релиза.
  3. macOS (Homebrew): brew upgrade openexr.
  4. vcpkg: vcpkg upgrade openexr.
  5. Из исходников: загрузите тег v3.5.0 с GitHub (AcademySoftwareFoundation/openexr), соберите через CMake. При отсутствии системной libzstd — vendored-версия 1.5.7 подключится автоматически через CMake-опцию.
  6. Если вы используете OpenEXR через Blender, Houdini или Nuke — ждите обновления зависимостей в очередных патчах этих приложений; самостоятельно заменять библиотеку в бандле не рекомендуется.

Источники

Читайте также