Как Голливуд хранит свои пиксели и почему OpenEXR до сих пор вне конкуренции

Вы когда-нибудь задумывались, как в кино совмещают реальные съемки с компьютерным драконом так, что освещение на чешуе идеально совпадает с закатным солнцем в кадре? Обычного JPEG или даже 16-битного TIFF для этого не хватит. В индустрии визуальных эффектов (VFX) есть свой стандарт де-факто, который когда-то создали в Industrial Light & Magic (той самой студии Джорджа Лукаса), а потом отдали в опенсорс. Речь об OpenEXR.

Зачем нам еще один формат изображений

Если вы работаете с вебом, вам хватает 8 бит на канал. Если занимаетесь фотографией — 14 или 16 бит в RAW кажутся пределом мечтаний. Но в графике для кино этого мало. Там нужно хранить «свет» как он есть — в физических величинах, с огромным динамическим диапазоном.

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

Что умеет этот формат

Проект OpenEXR — это не просто спецификация, а эталонная реализация на C++, которую поддерживает Academy Software Foundation.

Многоканальность без границ

В обычном фото у нас три канала: RGB. В EXR их может быть сколько угодно. Рендер-движки записывают в один файл не только картинку, но и глубину сцены (Z-depth), векторы движения пикселей, нормали поверхностей и даже то, какие объекты находятся за другими (так называемый deep compositing). Композер потом открывает такой файл и может менять фокус или перекрашивать отдельные предметы, не перерендеривая всю сцену.

Гибкое сжатие

Формат поддерживает кучу алгоритмов: от обычного ZIP до специфических для графики PIZ и DWAA/DWAB. Последние два умеют сжимать данные с потерями, но делают это так хитро, что глаз не замечает артефактов даже при сильной цветокоррекции. Это критично, когда один кадр в 4K может весить сотни мегабайт в несжатом виде.

Обратная совместимость

Разработчики очень консервативны в хорошем смысле. Главные приоритеты проекта — чтобы файлы, записанные 20 лет назад, открывались сегодня, а софт работал стабильно. Это не тот случай, когда каждый месяц ломают API ради модных фич.

Как это выглядит в коде

Для работы с EXR часто используют вспомогательную библиотеку Imath (она идет в комплекте). Вот классический пример того, как создать простейший файл с градиентом на C++:

#include <ImfRgbaFile.h>
#include <ImfArray.h>
#include <iostream>

using namespace OPENEXR_IMF_NAMESPACE;

int main() {
    int width = 100;
    int height = 50;

    // Создаем буфер для пикселей
    Array2D<Rgba> pixels(height, width);
    for (int y = 0; y < height; y++) {
        float c = (y / 5 % 2 == 0) ? (y / (float)height) : 0.0;
        for (int x = 0; x < width; x++)
            pixels[y][x] = Rgba(c, c, c);
    }

    try {
        RgbaOutputFile file("stripes.exr", width, height, WRITE_RGBA);
        file.setFrameBuffer(&pixels[0][0], 1, width);
        file.writePixels(height);
    } catch (const std::exception &e) {
        std::cerr << "Ошибка записи: " << e.what() << std::endl;
        return 1;
    }
    return 0;
}

На выходе получится вот такая картинка с полосками разной интенсивности:

Кстати, обратите внимание на структуру: pixel[0][0] здесь — это верхний левый угол. В графических API это часто вызывает путаницу, но здесь всё стандартно.

Техническая сторона вопроса

OpenEXR написан на C, но основной интерфейс для разработчиков — C++. Библиотека спроектирована так, чтобы максимально быстро читать и писать данные, используя многопоточность.

Интересная деталь: формат поддерживает «тайловое» хранение (tiles). Это когда изображение разбито на небольшие квадраты. Если вам нужно прочитать только кусок огромной текстуры размером 32k на 32k пикселей, вам не придется грузить в память весь файл. Это спасает жизнь при текстурировании сложных 3D-моделей.

Кому стоит заглянуть в репозиторий

Если вы пишете свой рендер-движок, инструмент для обработки фото или просто интересуетесь тем, как устроены профессиональные форматы данных — OpenEXR обязателен к изучению.

Проект живет под крылом Linux Foundation, и в него контрибьютят инженеры из Disney, NVIDIA, Intel и других гигантов. Это отличный пример того, как индустриальный стандарт может быть открытым, понятным и при этом невероятно мощным.

С чего начать? Я бы советовал склонировать репозиторий и посмотреть папку src/examples. Там много практических примеров того, как работать с метаданными и кастомными каналами. Документация у проекта довольно подробная, хотя местами и суховата, но для библиотеки такого уровня это скорее норма.

Если ваша задача — просто хранить картинки для сайта, EXR вам не нужен. Но если вы работаете с HDR, научными данными или компьютерным зрением, где точность важнее веса файла, то ничего лучше пока не придумали.