Настоящие HDR фото — от съемки до просмотра

Всем привет! Это моя первая статья на Хабре. Я постарался максимально понятно изложить проблематику получения HDR изображений на современных мониторах и операционных системах. Но сильно прошу не пенять, чукча не писатель, а больше исследователь.

Давайте сразу проясним, что подразумевается под HDR фото, а что нет. В начале двухтысячных было модное занятие сначала фоткать высококонтрастный объект с разными экспозициями, проводить так называемый  брекетинг экспозиции, а затем с помощью софта склеивать все в одно изображение. Изначальный огромный перепад яркостей сужался до обычного JPG и демонстрировался как достижение. Да, достижение было в виде сохранённых деталей в светах и тенях, но минимальный  и, что самое важное, максимальный уровень яркости был далек от натуры. К тому же неизбежным следствием являлось падение общего контраста. Так вот, это не HDR. Это, назовем его, прокрустово ложе, куда надо впихнуть невпихуемое, и на выходе получить псевдо-HDR. Данная статья просвещена получению настоящего HDR, где узость диапазона уже не мешает делать высококонтрастные снимки. И не только делать, но и увидеть.

Все, кто занимался самостоятельной обработкой фотографий, наверняка сталкивался с невозможностью в итоговое фото уместить весь диапазон яркостей, который дает RAW.  А если и удается уместить, то или с потерей контраста в тенях или светах, или, просто, ограничением динамического диапазона с урезанием в светах. Небо не такое яркое, как было, фасады освещенных зданий без деталей, снег, блики и многое другое уходили из крутой характеристики тоновой кривой в пологую, с ограничением контраста. Давайте разбираться что мешало сделать изображение ярче и что изменилось к сегодняшнему дню.  Наконец, можно констатировать, что настоящее HDR изображение уже доступно каждому.

Аппаратные проблемы и софт

Мониторы

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

Тут и аппаратные ограничения самих ЭЛТ (максимальная яркость профессиональных кинескопных мониторов тех лет физически упиралась в предел 100–120 нит, а попытки выкрутить ее выше приводили к потере резкости и искажениям), и целевое назначение: печать на бумаге. Хотя строгий полиграфический стандарт (ISO 3664) требует критически оценивать оттиски в специальных просмотровых кабинах при мощной освещенности в 2000 люкс, в обычных бытовых или офисных условиях, где люди обычно и смотрят печатную продукцию (при освещенности около 300–400 люкс), идеально белая бумага отражает свет так, что ее максимальная яркость составляет как раз те самые 100 нит. И поэтому верстальщики и приближали яркость экрана к яркости листа бумаги.

Да и сам стандарт sRGB был жестко привязан к этой потолочной цифре. Переход на массовые ЖК-панели на первых порах тоже мало что изменил: стандартная яркость SDR (Standard Dynamic Range) долгие годы болталась в районе 200–300 нит. Весь пайплайн обработки изображений был заточен под эти ограничения. Если вы пытались «вытянуть» солнце или яркий блик на фото, они неизбежно упирались в этот потолок дисплея, превращаясь в плоское белое пятно, не имеющее ничего общего с реальностью.

Чтобы увидеть настоящий HDR, нужно железо, способное физически отобразить этот перепад яркостей без уловок с локальным контрастом. Современные OLED и Mini-LED дисплеи с пиковой яркостью от 1000 нит и выше перевернули игру. Теперь мы можем заставить пиксель светиться настолько ярко, что блик на хромированном бампере или пробивающееся сквозь облака солнце реально заставят зрителя щуриться.

Кроме максимальной яркости, критически важна и минимальная — тот самый уровень черного, который способен обеспечить монитор. Отношение между минимальной и максимальной возможной яркостью и составляет статическую контрастность дисплея.

Долгие годы на стандартных IPS и TN матрицах мы мирились с серьезным компромиссом. Классический контраст 1000:1 означает, что «черный» цвет на экране — это на самом деле темно-серый. Подсветка матрицы работает постоянно, и часть света неминуемо пробивается сквозь закрытые жидкие кристаллы (всем знакомый IPS-glow). Если на таком SDR-мониторе попытаться программно «вытянуть» яркость светов, вместе с ними неизбежно «взлетят» и тени. Изображение станет блеклым, выцветшим и потеряет объем.

Именно поэтому настоящий прорыв в HDR-фотографии случился лишь с массовым приходом OLED и продвинутых Mini-LED панелей. В OLED каждый пиксель светится сам по себе и умеет полностью отключаться. Его минимальная яркость равна абсолютному физическому нулю. Контрастность становится математически бесконечной. В случае с Mini-LED алгоритмы локального затемнения (Local Dimming) на сотни и тысячи зон позволяют полностью гасить подсветку именно там, где на фото лежат глубокие тени.

Что это дает нам на практике? Абсолютную свободу при обработке RAW. Нам больше не нужно искусственно «заваливать» точку черного с помощью тоновой кривой, чтобы визуально сымитировать высокий контраст и объем. Когда мы открываем исходник в современной проявочной среде — например, в свежих релизах Lightroom вроде версии 14.2, где работа с HDR-пространством наконец-то стала полноценной, — мы можем оставить тени глубокими и детализированными, а блики сделать ослепительно яркими.

Мы впервые получили возможность перенести на экран именно тот колоссальный перепад освещенности, который зафиксировала матрица камеры, без необходимости сплющивать его до серых полутонов.

Софт и узкое горлышко в 8 бит

Итак, железо готово. Мы получили в свое распоряжение дисплеи, способные выдавать колоссальный перепад яркостей — от абсолютного черного до слепящего белого. Но на программном уровне мы с размаху упираемся в наследие старых стандартов кодирования цвета. А именно — в классические 8 бит на цветовой канал.

Что такое 8 бит? Это всего 256 (от 0 до 255) возможных градаций яркости для каждого из базовых цветов (RGB). В эпоху SDR, когда мы «размазывали» эти 256 ступенек по скромному диапазону от 0 до 100 нит, шаг между значениями был достаточно мелким. Человеческий глаз не замечал подвоха и воспринимал градиенты как плавные.

Но физику не обманешь: если попытаться натянуть те же самые жалкие 256 значений на рабочий диапазон от 0 до 1000 нит и выше, «расстояние» между соседними ступенями яркости становится слишком большим. Плавные переходы безвозвратно ломаются. Визуально это приводит к сильному бандингу (постеризации) — появлению грубой, отчетливо видимой «лесенки» из цветовых полос. Особенно жестоко это проявляется на плавных участках: чистом небе, мягких тенях или в ореолах вокруг ярких бликов.

Чтобы скормить современному монитору правильную картинку без артефактов квантования, нам необходимо кратно увеличить количество градаций. Переход на 10-битный цвет дает нам уже 1024 шага на канал (что в сумме составляет более миллиарда цветовых оттенков), возвращая градиентам в расширенном диапазоне яркостей идеальную гладкость. А современные движки проявки RAW-файлов при внутренних расчетах и вовсе оперируют 16-битной или 32-битной математикой (с плавающей запятой), чтобы не потерять ни малейшей детали в светах и тенях.

Но мало просто высчитать этот огромный массив данных в оперативной памяти графического редактора. Эту «многобитную» красоту нужно еще без потерь протащить через недра операционной системы прямиком на монитор. И вот тут пути Windows и Linux расходятся.

По состоянию на 2026 год Windows и Linux уже позволяют протащить HDR изображение от файла до монитора. Но давайте о всем по порядку.

От съемки до просмотра

Съемка: один RAW вместо тысячи брекетингов

Если оставить за скобками творческие задачи и композицию, то технически со съемкой под настоящий HDR сегодня проблем почти нет. Берем любую современную камеру, снимаем контрастную сцену в 14-битный RAW — и этого, как правило, достаточно.

Да, можно по привычке лупить серии с брекетингом экспозиции, как в старые добрые времена. Но, по моему опыту, это излишне. Современные матрицы в связке с 14-битным RAW обладают запасом, чтобы за один кадр запечатлеть в одном кадре и залитую солнцем поляну, и глубокие тени темного леса.

Единственное, за чем нужно пристально следить при съемке под HDR — это пограничные случаи пересвета. И здесь кроется интересная деталь. Иногда матрицу перегружает не общая яркость сцены, а избыток света в отдельном цветовом канале.

Самый частый пример — сочная листва под прямыми солнечными лучами. Из-за переизбытка света зеленый канал уходит в жесткий клиппинг (достигает своего потолка), в то время как красный и синий еще продолжают фиксировать данные. В результате математика цвета ломается, и при проявке мы с удивлением обнаруживаем, что листья стали не зелеными, а грязно-желтыми. То же самое регулярно происходит с небом, когда мы ловим перегрузку по синему каналу.

Чтобы избежать такой деградации цвета, в сложных контрастных сценах я просто корректирую экспозицию в минус — примерно на 1–1.5 ступени. Принципы экспонирования для HDR немного отличаются: здесь критически важно защитить света любой ценой. Для современных сенсоров вытянуть потом тени на стоп-полтора вообще не проблема (ни по шумам, ни по детализации), а вот «сгоревшие» блики восстановить уже невозможно.

Как показывает практика, отрицательной коррекции в одну ступень практически всегда хватает, чтобы спасти детали в светах и сохранить правильную цветопередачу. В любом случае, тут нужен небольшой эксперимент, чтобы понять пределы и поведение сенсора конкретно вашей камеры. Моя Sony A6500 прекрасно справляется со всеми сценами при ISO 100 и коррекции на -1 ступень.

Пару слов про съемку в темное время суток в городе. Чем меньше ISO тем лучше. Этим вы сохраните динамический диапазон для последующей обработки.

И про смартфоны. Куда ж без них. Если ваш смартфон выдает RAW, то вполне есть возможность поэкспериментировать с ним. Да, значительно меньше динамический диапазон. Но не катастрофично. Можно вполне добиться приемлемого результата, если конечно вы не снимаете при совсем плохом освещении.

Обработка и магия трансферных функций

Тут всё так же просто, но с важным техническим нюансом. Если говорить о полноценном, удобном и предсказуемом пайплайне для фотографа, то Adobe Lightroom Classic на данный момент практически не имеет альтернатив.

Если вы уже пользовались этой замечательной программой, то всё привычно. Только теперь надо нажать на кнопку HDR при редактировании на панели Basic. На гистограмме сразу появится то, ради чего всё и затевается — «территория HDR». Ваша задача — как раз на эту территорию «увести» небо, блики, источники света, снег и так далее. Можно с облегчением вздохнуть: больше не надо впихивать огромный диапазон яркостей в прокрустово ложе обычного SDR. Пусть всё самое яркое по-настоящему сияет!

Долгое время мы жили в парадигме относительной яркости. Классическая гамма-кривая в SDR-файлах говорит монитору примерно следующее: «вот это значение (0) — твой самый темный цвет, а вот это (255) — твой самый светлый, как бы тускло или ярко ты ни светил». Именно поэтому простой экспорт в 16 или даже 32 бита на канал сам по себе ничего не даст. Да, вы получите математически плавные градиенты, но операционная система и дисплей всё равно не поймут, с какой физической интенсивностью эти пиксели нужно отображать. Без правильных инструкций дисплей просто попытается уместить эти данные в свои стандартные рамки, и вся магия HDR схлопнется, так как процесс передачи итоговых яркостей нелинеен.

Чтобы настоящий HDR заработал, нам нужна абсолютная привязка к уровням яркости. И здесь на сцену выходит широкое цветовое пространство REC 2020 (BT.2020) в связке с передаточной функцией PQ (Perceptual Quantizer, она же SMPTE ST 2084). В отличие от старой гаммы, PQ-квантование жестко привязывает цифровое значение пикселя к конкретным физическим показателям светимости. Функция говорит монитору предельно точно: «этот пиксель должен светиться ровно на 800 нит, а этот — на 0,005 нит».

Заслуга свежих версий Lightroom в том, что программа умеет делать две важнейшие вещи. Во-первых, она включает внутреннюю 32-битную математику с плавающей запятой для правильного отображения бликов прямо во время проявки. Во-вторых, и это самое главное — Lightroom корректно встраивает правильный цветовой профиль и PQ-кривые в метаданные итогового файла на этапе экспорта. Только благодаря этому «паспорту» ваш плеер, браузер и операционная система поймут, что перед ними не просто картинка, а карта реальной светимости.

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

Формат: JPEG XL, качество 85-90;
HDR Output: ставим галочку;
Максимальная совместимость: убираем галочку;
Цветовое пространство: тут всё зависит от цветового охвата монитора и камеры. Это отдельная глубокая тема, и я не буду углубляться в нее в рамках этой статьи. Ставьте HDR P3 или REC 2020. На практике это не принципиально, так как оба цветовых профиля по ширине с запасом перекрывают и вашу камеру, и монитор.

На выходе вы получите JXL-файл. Это новый перспективный формат, который создавался на замену устаревшему JPG. Про форматы можно писать очень долго, но для нашей задачи главное знать: JXL поддерживает тоновые HDR-кривые и обладает очень качественными алгоритмами сжатия. Итоговые фото в настоящем HDR, сохраненные в формате JXL, получаются меньше по размеру, но при этом гораздо детализированнее и с меньшим количеством артефактов, чем привычный JPG. Согласитесь, это приятно, особенно когда счет обработанных файлов в фотоархиве переваливает за десятки тысяч — экономия дискового пространства получается колоссальной, а качество остается лучше и в плане детализации и в плане яркостного диапазона.

Просмотр: Главная головная боль

А вот этот этап на практике оказался самым сложным и болезненным. Парадокс: можно купить великолепный Mini-LED или OLED-монитор, снять безупречный 14-битный RAW, филигранно проявить его на «территории HDR» в Lightroom… и обнаружить, что вам банально нечем показать итоговый результат.

В Windows долгое время не было вообще никакой адекватной возможности просто открыть и посмотреть готовый HDR-файл в обычном режиме. Да, можно было извращаться: перетаскивать файлы в окна современных браузеров или пытаться скормить их продвинутым видеоплеерам. Но согласитесь, использовать Chrome или медиаплеер в качестве повседневного просмотрщика фотоархива — затея сомнительная.

Ситуация начала меняться только с выходом обновления Windows 11 24H2. Встроенное приложение «Фотографии» (Photos) наконец-то научилось правильно интерпретировать встроенную передаточную кривую PQ — ровно то, что экспортирует Lightroom. Но тут фотографов ждал очередной нюанс: на этапе 24H2 эта магия работала только для формата AVIF. JXL-файлы операционная система в упор не замечала.

Я намеренно подробно не останавливаюсь на AVIF прямо сейчас — у этого формата есть свои подводные камни, о которых я расскажу ближе к концу статьи, хотя для хранения HDR-изображений он вполне жизнеспособен. Моим же осознанным выбором в итоге стал JXL (JPEG XL), так как при аналогичном или даже лучшем качестве картинки он обеспечивает меньший размер файлов. Полноценный же праздник пришел чуть позже: начиная с версии Windows 11 25H2 система «из коробки» стала корректно отображать JXL-файлы наравне с AVIF.

Если резюмировать ситуацию с софтом для просмотра в Windows, то долго расписывать нечего. Весь рабочий процесс сейчас укладывается в лаконичную связку: редактирование — в Lightroom, просмотр — во встроенном приложении «Фотографии». Все! Больше ни одна программа из категории классических просмотрщиков не способна отобразить настоящий HDR верно. Ни одна! Вместо сочной контрастной картинки вы получите либо блеклую, выцветшую «кашу», либо намертво выбитые вбелую света.

Такой застой вполне объясним. Тут замешана и затянувшаяся «война форматов», и колоссальный пласт устаревшего кода в классическом софте, который создавался десятилетия назад и намертво привязан к старой парадигме SDR. Но лед тронулся, и дело, я верю, обязательно сдвинется с мертвой точки. Как оно, к слову, уже вовсю сдвинулось в мире Linux.

Linux и прорыв в KDE Plasma 6

Как давний пользователь Linux, я просто не мог обойти эту систему стороной. Примерно раз в полгода я стабильно накатывал свежие апдейты на «посмотреть, как там дела с HDR». Эволюция шла буквально на глазах: сначала в настройках дисплея просто появилась заветная, но пустая галочка включения расширенного динамического диапазона. Но настоящий, фундаментальный прорыв случился с выходом KDE Plasma 6.

Именно в этой версии разработчики проделали титаническую работу по интеграции протоколов управления цветом (Color Management) внутри сессии Wayland. И сегодня можно констатировать факт: я наконец-то смог добиться полноценного и правильного отображения HDR-фотографий прямо в Kubuntu!

Да, признаю, здесь всё еще далеко не так гладко и бесшовно, как в коммерческих ОС. Но в самой архитектуре реализации под Linux есть моменты, которые сделаны тоньше, гибче и, если хотите, правильнее, чем в той же Windows с её порой топорным глобальным переключателем. Впрочем, Linux есть Linux: из коробки всё идеально не заработает, и без понимания процессов тут не обойтись.

Сразу сделаю важную оговорку касательно этапа «проявки». Как получить полноценный HDR-снимок из исходного 14-битного RAW в программе, полностью аналогичной Lightroom, но работающей нативно под Linux, я на данный момент не знаю. Теоретически, для этих целей можно глубоко расковырять Darktable — там авторы активно экспериментируют с HDR-пайплайном. Но я этого не делал, в свой рабочий процесс не внедрял и гарантировать стабильный результат не могу. Мой сценарий гораздо прозаичнее и ближе к реальности: у меня есть готовый структурированный архив с уже экспортированными из Lightroom JXL-файлами, и моя задача — комфортно смотреть их в Linux-сессии на своем OLED или Mini-LED мониторе.

И вот тут классический софт пасует. Нативный просмотрщик Okular сразу отпадает — в честный HDR он не умеет, разделяя судьбу большинства старых просмотрщиков под Windows. Продвинутый каталогизатор digiKam тоже мимо: файлы он открывает, но встроенную расширенную тоновую кривую PQ полностью игнорирует, безжалостно сплющивая картинку до стандартного SDR-диапазона. Картинка выводится на экран, но пиковая яркость монитора при этом просто спит.

Казалось бы, тупик? Но выход нашелся, и он оказался монументальным. Спасением из этой ситуации стал замечательный, гибкий и продвинутый настолько, насколько это вообще возможно, медиаплеер MPV.

Из коробки он прямо показывать HDR не будет. Но нам понадобится всего две опции и один маленький скрипт на LUA.

Настраиваем MPV: от установки до удобной галереи

Все настройки будем прописывать локально, применительно к текущему пользователю. Вы же уже установили MPV? Если нет, то открываем терминал:

sudo apt update

sudo apt install mpv

Далее добавляем файл конфигурации и вписываем туда нужные параметры. Все команды выполняем от имени текущего пользователя. На всякий случай создадим саму директорию (если вы еще ни разу не запускали плеер, ее может не быть) и откроем конфиг в текстовом редакторе:

mkdir -p ~/.config/mpv

nano ~/.config/mpv/mpv.conf

Вписываем в него следующие строки:

vo=gpu-next
gpu-api=vulkan
hwdec=auto
target-colorspace-hint=yes
# --- Спец-профиль для бесконечного показа фотографий ---
[extension.jxl]
profile-desc=«Profile for JPEG XL photos»
image-display-duration=inf
loop-file=inf

Сохраняем файл (Ctrl+O, Enter, Ctrl+X). С этих пор файл JXL, открытый в плеере MPV, будет отображаться корректно в HDR-диапазоне и не будет закрываться через секунду. Можно смело назначить MPV программой по умолчанию для файлов JXL в вашей системе.

Но, согласитесь, открывать файлы строго по одному из файлового менеджера довольно неудобно. Хочется привычного поведения: открыл одну фотографию, а дальше листаешь папку стрелочками вправо-влево.

Чтобы это реализовать, нам понадобятся два небольших скрипта. Первый — это официальный скрипт от разработчиков MPV, который при открытии файла автоматически создает «на лету» плейлист из всех соседних файлов в этой же директории. А второй — наш собственный скрипт, который «научит» стрелки на клавиатуре листать этот плейлист, если открыто фото, но сохранит привычную перемотку на 5 секунд, если мы смотрим видео.

Итак, создаем директорию для скриптов:

mkdir -p ~/.config/mpv/scripts

Скачиваем базовый скрипт для автозагрузки плейлиста (autoload.lua):

wget https://raw.githubusercontent.com/mpv-player/mpv/master/TOOLS/lua/autoload.lua -O ~/.config/mpv/scripts/autoload.lua

Теперь создаем наш кастомный скрипт для умных стрелок:

nano ~/.config/mpv/scripts/smart_arrows.lua

Вставляем в него следующий код:

-- Функция проверки: открыта ли сейчас фотография?local function is_image()    local filename = mp.get_property("filename")    if not filename then return false end        -- Получаем расширение файла    local ext = filename:match("^.+%.(.+)$")    if not ext then return false end        ext = string.lower(ext)    -- Список форматов, которые считаем фотографиями    return ext == "jxl" or ext == "jpg" or ext == "jpeg" or ext == "png" or ext == "avif" or ext == "heic"end– Действие для стрелки ВПРАВОmp.add_key_binding(“RIGHT”, “smart_right”, function()    if is_image() then        mp.command(“playlist-next”) – Листаем фото вперед    else        mp.commandv(“seek”, 5)      – Перематываем видео на 5 сек вперед    endend)– Действие для стрелки ВЛЕВОmp.add_key_binding(“LEFT”, “smart_left”, function()    if is_image() then        mp.command(“playlist-prev”) – Листаем фото назад    else        mp.commandv(“seek”, -5)     – Перематываем видео на 5 сек назад    endend)

Все. По клику открывается файл JXL, а срелками на клавиатуре можно путешествовать между файлами.

Вместо заключения и немного про Apple

Итак, мы прошли путь от съемки до просмотра. В этой теме пока еще много непонятного, связанного как с зоопарком форматов, так и с фрагментацией их поддержки в операционных системах. Однако хочется верить, что настоящий HDR приживется, а поддержка новых стандартов станет повсеместной.

Вы могли заметить, что я сознательно почти не упоминал экосистему Apple. Дело в том, что «яблочная» компания пошла своим, весьма специфическим путем. Вместо того чтобы сразу переводить индустрию на форматы с абсолютной привязкой к яркости (PQ) вроде JXL или AVIF, они сделали ставку на формат HEIC и технологию Gain Maps (карт усиления), которую они также научились встраивать прямо в метаданные старого доброго JPG.

Суть этого подхода (который, надо признать, работает весьма элегантно) заключается в следующем: в файл записывается обычная, «плоская» SDR-картинка, а рядом в метаданные прячется дополнительная скрытая маска — та самая карта усиления. Когда вы открываете это фото на старом или не поддерживающем HDR мониторе, он просто игнорирует маску и показывает базовую SDR-версию. Никаких тусклых цветов, всё выглядит привычно. Но если алгоритмы iOS или macOS видят родной сверхъяркий XDR-дисплей, система считывает карту усиления и аппаратно «разжигает» яркость нужных пикселей (бликов, солнца, неба) на нужную величину.

Это изящно решает проблему обратной совместимости. Тебе не нужно думать, как файл будет выглядеть у пользователя со старым монитором — он всегда будет выглядеть нормально.

Но есть и огромный минус: долгое время это делало такой HDR вещью «исключительно для своих». Шаг влево, шаг вправо за пределы экосистемы Apple — и магия пропадала, оставляя вас с обычным плоским JPG. Лишь совсем недавно крупные игроки (включая Google и Adobe) начали договариваться и приводить эти карты усиления к единому стандарту (ISO 21496-1), чтобы они читались везде.

Тем не менее, для кроссплатформенного архива, где я хочу быть на 100% уверен в бескомпромиссном качестве, математике цвета и независимости от алгоритмов конкретной корпорации, формат JXL с профилем PQ кажется мне более честным, фундаментальным и перспективным решением.

Надеюсь, мой опыт поможет вам открыть для себя настоящую, а не ограниченную тоновыми кривыми фотографию. Пусть ваши снимки сияют так, как они того заслуживают!