Luminance HDR

Luminance HDR — настольная программа с открытым исходным кодом для полного HDR-процесса: она объединяет несколько кадров одной сцены с разной экспозицией в изображение с высоким динамическим диапазоном, открывает готовые HDR-файлы, выполняет тональное отображение для обычного экрана или печати и сохраняет результат в распространённых растровых форматах. Программа рассчитана прежде всего на фотографов, которым нужен локальный инструмент без обязательной подписки и облачного проекта, а также на пользователей, которым важно выбирать алгоритм слияния, выравнивание, подавление «призраков» и конкретный оператор tone mapping, а не только применять готовый визуальный пресет.

Что представляет собой Luminance HDR

Точное название проекта — Luminance HDR. Ранее программа развивалась под именем Qtpfsgui; смена названия не означает появление отдельного продукта. Кодовая база и история проекта продолжают одну линию: ранние годы связаны с Giuseppe Rota, а в более поздних выпусках в авторских данных указаны Davide Anastasia, Franco Comida, Daniel Kaneider и многочисленные участники и переводчики. Интерфейс построен на Qt5, а сам проект распространяется на условиях GNU General Public License version 2.0. Поэтому Luminance HDR не относится к условно-бесплатным редакторам с водяным знаком или ограниченным сроком работы: функции приложения определяются конкретной сборкой, а не оплаченной редакцией.

Главная специализация программы — HDR imaging workflow. Она принимает серию JPEG, TIFF 8/16 бит или RAW одного сюжета, снятую с разной экспозицией, строит единый HDR-кадр, а затем преобразует его в LDR-изображение средствами нескольких алгоритмов тонального отображения. Помимо этого, приложение умеет открывать уже готовые HDR-файлы, сохранять их, вращать и масштабировать изображение, кадрировать выбранную область, выполнять проективные преобразования и переносить EXIF между наборами файлов. Эти функции связаны с одной задачей — подготовкой HDR и его дальнейшим отображением, а не с полноценным слоёвым ретушированием или каталогизацией фототеки.

Программа поддерживает два взаимосвязанных, но самостоятельных этапа. На первом строится HDR: снимки должны описывать одну сцену и различаться экспозицией; при необходимости они выравниваются и очищаются от участков с движением. На втором HDR переводится в LDR посредством оператора tone mapping. Такое разделение важно: неудачное совмещение исходников нельзя исправить выбором другого оператора, а слишком агрессивный tone mapping не означает, что сам HDR-файл построен неверно. Проверять качество поэтому нужно отдельно после слияния и отдельно после тональной обработки.

Luminance HDR подходит как для интерактивной работы через графический интерфейс, так и для автоматизации. В составе проекта предусмотрена отдельная командная утилита luminance-hdr-cli, а в GUI имеются Batch HDR и Batch Tonemapping. Это отличает программу от редакторов, где HDR доступен только как один интерактивный фильтр. Для повторяющихся серий можно сохранить настройки tone mapping, применить их к нескольким HDR-файлам и вывести результаты без ручного повторения каждого шага.

Для читателя, который выбирает инструмент именно для HDR, полезно сразу обозначить границу: Luminance HDR не заменяет RAW-каталогизатор, пиксельный редактор со слоями или специализированный ретушёр. Его сильная сторона — доступ к этапам HDR-сборки и набору тональных алгоритмов, включая ручное выравнивание, автоматическое и ручное подавление ghosting, работу с HDR TIFF/OpenEXR/Radiance и цветоуправляемый вывод. Если после tone mapping нужна сложная локальная ретушь, многослойный монтаж или управление большой библиотекой, результат передают в отдельный графический редактор.

Модель распространения, лицензия и актуальные сборки

Проект Luminance HDR лицензирован по GNU GPL v2. Исходный код открыт, а Windows-инсталлятор 2.6.0 распространяется как готовый 64-битный исполняемый файл. Для этой сборки опубликован установщик размером 49,6 МБ; рядом с ним доступны ZIP-пакет Windows и две DMG-сборки для macOS. Более поздняя ветка 2.6.1.1 существует в виде исходного пакета и используется современными Linux-пакетами, но готовый Windows-инсталлятор в основном публичном каталоге проекта остался на версии 2.6.0. Поэтому номер версии нужно всегда связывать с конкретным каналом установки, а не смешивать исходный релиз и Windows binary в одну запись.

Для Windows практический вариант — 64-битный установщик 2.6.0. Для Linux ситуация иная: дистрибутивы продолжают собирать 2.6.1.1 со своими ревизиями. В Fedora эта версия присутствует в актуальных ветках пакетов, а во Flathub доступна community-сборка 2.6.1.1 для x86_64 и aarch64. Номер вида 2.6.1.1-96.fc45 означает пакетную ревизию Fedora, а не новую upstream-версию Luminance HDR. Это различие существенно при чтении отчётов об ошибках: поведение конкретного дистрибутивного пакета может включать патчи, которых нет в старом Windows binary.

Во Flathub приложение помечено как community built и unverified. У этого пакета заявлены доступ на чтение и запись в домашнюю папку и использование legacy windowing system. Эти разрешения относятся именно к Flatpak-пакету и не описывают модель безопасности Windows-инсталлятора или сборки из репозитория дистрибутива. Пользователю Linux стоит учитывать их при выборе изоляции, особенно если в домашнем каталоге хранятся материалы, которые не должны быть доступны графическим приложениям без необходимости.

В поставке нет коммерческих уровней Home, Pro или Studio, которые разблокировали бы разные операторы. Лицензия GPL определяет права на использование и распространение кода, а не платный функциональный набор. При этом отсутствие подписки не означает регулярные крупные обновления: последний публичный upstream-апдейт в каталоге проекта датирован январём 2021 года. Современная доступность в Linux во многом обеспечивается сопровождающими дистрибутивов, которые пересобирают и патчат ветку 2.6.1.1 под новые библиотеки.

Для долгосрочного рабочего процесса это даёт понятный компромисс. Форматы HDR и основные алгоритмы остаются воспроизводимыми, сохранённые settings-файлы позволяют повторять обработку, а открытый код облегчает поддержку в Linux. Одновременно нельзя рассчитывать на темп интерфейсных и интеграционных обновлений, характерный для активно развиваемых коммерческих редакторов. Перед внедрением в постоянный производственный процесс нужно проверить на собственной системе импорт RAW конкретной камеры, выравнивание большой серии и экспорт нужной разрядности TIFF.

Интерфейс и расположение основных инструментов

Главное окно построено вокруг рабочей области с вкладками открытых HDR-изображений, верхнего меню и панели инструментов. В меню доступны разделы File, Edit, View, Tools, Windows и Help. Команды создания и открытия HDR находятся в File; геометрические операции сгруппированы в Edit; синхронизация просмотра и инструменты отображения — в View; настройки и перенос EXIF — в Tools. При открытом HDR рядом с изображением используется панель tone mapping, где выбирается Operator, настраиваются параметры выбранного алгоритма, размер результата и Pre-gamma.

Вкладка изображения показывает собственный HDR-документ. Над областью просмотра расположены средства отображения HDR, включая выбор Mapping/Gamma и гистограмму. Гистограмма используется не как декоративный график: команды просмотра позволяют подогнать отображаемый диапазон, сузить или расширить его и изменить экспозицию визуализации. Эти операции помогают рассмотреть тени и света исходного HDR до tone mapping, не смешивая просмотр динамического диапазона с окончательным LDR-экспортом.

На панели tone mapping сверху находится список Operator. Ниже появляются параметры, характерные для выбранного алгоритма. Для Mantiuk ’06 интерфейс показывает Contrast Factor, Saturation Factor, Detail Factor и флажок Contrast Equalization. Под блоком оператора расположены Restore, Previous и Next, секция Tone Mapping Settings с кнопками сохранения и загрузки настроек, секция Export с Fast export и Open, а также Process с Result Size, Pre-gamma, Update preview, Update current LDR и Auto Levels. Такой интерфейс ориентирован на сравнение вариантов: пользователь меняет конкретный алгоритм, обновляет предварительный результат и только после этого выводит полноразмерный файл.

Предварительный просмотр следует обновлять явно командой Update preview. Это особенно важно после изменения параметров: приложение не пересчитывает весь результат автоматически при каждом движении ползунка. Для тяжёлых операторов такой подход снижает число ненужных пересчётов, но требует дисциплины — после изменения значения нужно обновить preview и только затем судить о результате. Флажок Update current LDR связан с обновлением текущего LDR-представления, а Auto Levels выполняет автоматическую коррекцию уровней в LDR.

В Preferences настройки разделены по вкладкам Interface, Fast export, Tone Mapping, RAW Conversion, Color Management и External Tools. В Interface выбираются язык, тема, ширина preview, показ панели предварительного просмотра и Portable mode. Русский язык входит в набор переводов проекта, поэтому работа не ограничивается английским интерфейсом. Portable mode хранит настройки рядом с приложением, что удобно для переносной конфигурации, но пользователь должен контролировать права доступа к каталогу, где находятся эти настройки.

При геометрическом редактировании меню Edit показывает реальные команды Rotate counter-clockwise, Rotate clockwise, Crop to Selection, Remove Selection, Resize… и Projective Transformation…. Это не набор неразрушающих корректирующих слоёв: операции применяются к HDR-документу и могут создавать изменённый вариант, который затем нужно сохранить отдельно. Поэтому перед обрезкой или проективным преобразованием полезно сохранить исходный HDR в собственном файле, если он понадобится для другой композиции.

Установка и первый запуск

На Windows готовая сборка 2.6.0 рассчитана на 64-битную систему и поставляется как обычный инсталлятор. Размер файла — 49,6 МБ; отдельно существует ZIP-пакет той же версии. Инсталлятор относится к ветке 2.6.0, поэтому после установки строка версии не становится 2.6.1.1: более поздний номер относится к исходной ветке и пакетам Linux. Для воспроизводимости при разборе проблем полезно записать не только номер Luminance HDR, но и источник пакета — Windows setup, Flatpak, Fedora/Debian package или собственная сборка.

На macOS для 2.6.0 публиковались DMG-сборки на Qt 5.9 и Qt 5.13; страница проекта указывает поддержку Mac OS X 10.9 и новее для этой линии. Поздняя 2.6.1 была опубликована без одновременно готовых Windows- и macOS-бинарников. Поэтому сравнивать номера между платформами нужно осторожно: наличие исходного тега не гарантирует наличие собранного приложения для той же ОС. На современном macOS ключевой вопрос — фактический запуск конкретного старого DMG на текущей версии системы, а не только исторически заявленный минимум 10.9.

На Linux предпочтительнее пакет дистрибутива или Flatpak, потому что они собираются с актуальными системными библиотеками. Во Flathub версия 2.6.1.1 доступна для x86_64 и aarch64. В Fedora ветка 2.6.1.1 также продолжает пересобираться. При использовании пакетного менеджера обновления зависимостей и патчи совместимости идут через сопровождающих дистрибутива; это отдельный жизненный цикл от upstream-каталога, где новой номерной версии после 2021 года нет.

После первого запуска первым полезным действием является Tools > Preferences. В Interface нужно проверить язык, тему и размер preview; в RAW Conversion — метод демозаики и баланс белого для RAW; в Color Management — профиль монитора и, при необходимости, камеры или принтера; в Fast export — каталог и формат быстрого экспорта; в Tone Mapping — временную рабочую папку и число потоков для пакетной тональной обработки. Такая настройка заранее предотвращает ситуации, когда полноразмерные файлы уходят в неожиданную папку, а preview оценивается без корректного профиля дисплея.

Если требуется переносная конфигурация, в Interface предусмотрен Portable mode. Его смысл — хранить настройки вместе с приложением, в том числе на съёмном носителе, вместо стандартного пользовательского каталога. Это удобно для одинаковых параметров на нескольких машинах, но не делает программу полностью независимой от системных компонентов: готовая сборка всё равно использует собственные и системные библиотеки, а пакет Linux зависит от окружения дистрибутива. Portable mode следует понимать именно как способ размещения настроек.

Для проверки установки не нужно сразу собирать сложную пятикадровую серию. Достаточно открыть один поддерживаемый HDR-файл или RAW и убедиться, что изображение появляется во вкладке, панель tone mapping доступна, Update preview создаёт LDR-предпросмотр, а Save/Fast export сохраняет файл в выбранный каталог. Затем уже стоит тестировать многокадровое выравнивание и anti-ghosting, потому что эти этапы добавляют внешние инструменты и больше переменных.

Базовый рабочий процесс: от брекетинга до готового изображения

Стандартная работа начинается с серии одной сцены, снятой с различной экспозицией. Для неё используется File > New HDR image…. На первом шаге добавляются JPEG, RAW либо TIFF 8/16 bit. Программа читает сведения об экспозиции из метаданных; если необходимого значения нет, EV можно задать вручную. Это снимает жёсткую зависимость от корректного EXIF, но ручные значения должны отражать реальную разницу между кадрами — ошибочная шкала экспозиции меняет расчёт HDR.

1. Добавьте исходники. Выберите кадры одного сюжета и проверьте, что их порядок и экспозиции распознаны корректно. Для серии без EXIF введите EV вручную.
2. Выберите выравнивание. Доступны align_image_stack и MTB. Первый умеет учитывать геометрию кадра, второй рассчитан на LDR и не моделирует вращение.
3. Откройте Advanced Editing Tools при необходимости. Здесь можно вручную подправить совмещение, оценить Difference (E-P), обрезать согласованную область и перейти к anti-ghosting.
4. Устраните движение между кадрами. Автоматический режим ищет проблемные участки по порогу; ручной режим позволяет назначить опорный кадр и маской указать движущиеся области.
5. Создайте HDR. После слияния оцените корректность границ, движущихся объектов и диапазона самого HDR, не смешивая эту проверку с художественным tone mapping.
6. Перейдите к tone mapping. Выберите оператор, размер preview и Pre-gamma, затем нажмите Update preview. Сравнивайте варианты при одинаковом Result Size, если оцениваете влияние только оператора.
7. Экспортируйте полноразмерный LDR. Fast export использует отдельные настройки каталога и формата; для дальнейшей глубокой обработки выбирайте формат и разрядность, которые сохраняют нужный запас данных.

Выравнивание выполняется до построения HDR. Небольшой сдвиг камеры создаёт двойные контуры, которые после tone mapping становятся заметнее из-за локального усиления контраста. align_image_stack относится к инструментам Hugin и оптимизирует ориентацию кадров и геометрию объектива. MTB — другой метод, рассчитанный на сопоставление экспозиций LDR; документация отдельно отмечает, что он не моделирует вращение. Для штативной серии без поворота MTB может быть достаточным, но при заметном геометрическом расхождении функционально богаче align_image_stack.

В Advanced Editing Tools ручное совмещение выполняется стрелками. Модификаторы ускоряют перемещение: Shift сдвигает на 10 пикселей, Ctrl — на 50, Shift+Ctrl — на 100. Режим Difference (E-P) полезен для контроля: хорошо совмещённые неподвижные детали дают минимальную разницу, а смещение видно как контуры. После выравнивания можно обрезать область, где из-за сдвига появились пустые края, и сохранить согласованные LDR-файлы с относящимися к ним EXIF-данными.

Ghosting возникает, когда между экспозициями движутся люди, машины, ветви, вода или другие объекты. Автоматический anti-ghosting работает с порогом: после пересчёта приложение показывает найденные patches, а пользователь может изменить threshold и пересчитать их, а также вручную добавить или удалить участки. Ручной режим предлагает lasso или brush, выбор размера кисти, силы маски и опорного изображения. Практически важно маскировать именно движущийся объект, сохраняя неподвижный фон из согласованной серии.

После создания HDR его следует сохранить отдельно до экспериментальной тональной обработки. Это позволяет менять операторы и параметры без повторного слияния исходников. Формат для HDR выбирают исходя из последующего процесса: OpenEXR и Radiance RGBE предназначены для высокодинамических данных; TIFF может хранить 16-bit, 32-bit float или LogLuv; PFS используется как собственный формат семейства инструментов. Сохранение master HDR особенно полезно, когда из одной серии нужны несколько интерпретаций — нейтральная, контрастная и вариант для дальнейшей ретуши.

Выравнивание и подавление «призраков» подробнее

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

align_image_stack интегрирован как внешний инструмент. В настройках External Tools для него предусмотрены параметры, а в командной части проекта используются его стандартные возможности. Само приложение запускает выравнивание как отдельный шаг перед HDR-сборкой. Это важно при диагностике: ошибка запуска align_image_stack и ошибка tone mapping — разные классы проблемы. Если сборка HDR работает без выравнивания, но завершается ошибкой при включении alignment, проверять нужно доступность и параметры внешнего выравнивателя, а не оператор tone mapping.

MTB полезен там, где требуется сопоставить LDR-кадры по яркостной структуре, но его геометрическая модель ограниченнее: вращение не учитывается. Поэтому при серии с заметным наклоном камеры предпочтительнее align_image_stack. Для полностью неподвижной съёмки со штатива можно сначала проверить результат без alignment: лишняя трансформация не нужна, если пиксельная геометрия уже совпадает. Решение принимают по фактическим границам в HDR, а не по одному факту наличия функции выравнивания.

Автоматическое deghosting требует осмысленного threshold. Низкий порог увеличивает число отмеченных областей и может затрагивать детали, которые стабильны; высокий оставляет часть движения нераспознанной. Интерфейс позволяет пересчитывать patches после изменения порога, поэтому проверка должна идти итеративно: просмотреть карту проблем, сопоставить её с движущимися объектами, затем скорректировать threshold. Окончательный контроль выполняется уже на созданном HDR и на tone-mapped LDR, где остаточные артефакты видны сильнее.

Ручная маска нужна, когда автоматический анализ смешивает движение и изменение яркости либо когда пользователь хочет жёстко выбрать конкретный кадр для объекта. Опорный кадр должен содержать приемлемое состояние движущегося элемента; затем маской отмечают область, которую следует взять из него. Brush подходит для сложных форм и локальных деталей, lasso — для крупных компактных объектов. Сила маски управляет переходом. После применения нужно проверить не только сам объект, но и его границу: именно там чаще остаётся смесь нескольких экспозиций.

Для архитектуры и интерьеров основная проблема часто не движение объекта, а микросмещение камеры. Для уличной сцены геометрия может быть стабильной, но между кадрами меняются автомобили и люди. В пейзаже критичны листья, ветви и волны. Эти сценарии требуют разных приоритетов: alignment отвечает за неподвижную структуру сцены, anti-ghosting — за временные изменения. Использование обоих инструментов в одной серии оправдано только тогда, когда присутствуют обе проблемы.

Tone mapping: операторы, предварительный просмотр и контроль результата

HDR-файл содержит диапазон яркости, который обычный дисплей или стандартный JPEG напрямую не показывает. Tone mapping переводит этот диапазон в LDR, сохраняя выбранный баланс глобального контраста, локальных деталей и яркости. В Luminance HDR пользователь явно выбирает Operator и его параметры. Набор включает классические алгоритмы, документированные в GUI/CLI, а версия 2.6.0 добавила Ferwerda, KimKautz, Lischinski и VanHateren. В предыдущих ветках присутствуют Mantiuk, Fattal, Drago, Durand, Reinhard, Pattanaik, Ashikhmin, Mai и Ferradans.

Универсального набора ползунков нет: каждый оператор реализует собственную математическую модель и поэтому показывает свои параметры. Это принципиальное отличие от интерфейса, где один и тот же набор Exposure/Contrast/Highlights просто меняет пресет. Например, Mantiuk ’06 в панели 2.6.x использует Contrast Factor, Saturation Factor, Detail Factor и Contrast Equalization. Настройка, удачная для Mantiuk, не переносится как эквивалентная в Fattal или Reinhard — сравнивать следует итоговую визуальную задачу, а не числовые значения ползунков.

Предварительный просмотр в gradient-domain операторах может зависеть от размера результата. Документация отдельно предупреждает, что Fattal и Mantiuk могут давать различия между маленьким preview и полноразмерным изображением. Поэтому для окончательной оценки нельзя опираться только на миниатюру. Полезный приём — выделить прямоугольную область с критичными деталями и считать preview по ней: это даёт более репрезентативный масштаб при меньшем времени расчёта. Затем перед экспортом обязательно выполнить полноразмерный рендер.

Команда View > Lock Viewers синхронизирует перемещение между несколькими открытыми изображениями. Она удобна при сравнении нескольких LDR-версий: можно держать одинаковую область кадра в одном масштабе и оценивать ореолы, микроконтраст и провалы в тенях. Такой способ точнее, чем переключение между файлами с разной позицией просмотра. Для финальной проверки полезно сравнить минимум два варианта — более нейтральный и более выраженный — на деталях неба, тонких контрастных границах и естественных текстурах.

Auto Levels и Adjust Levels относятся к LDR-этапу. Автоматическая коррекция способна заметно изменить итог после оператора, поэтому при анализе результата нужно разделять влияние tone mapping и уровней. Сначала оцените оператор без Auto Levels, затем включите автоматическую коррекцию и сравните. Если итоговая задача требует строго повторяемого результата для серии, лучше сохранить settings и зафиксировать состояние Auto Levels, чем каждый раз подбирать его вручную.

Начиная с 2.6.0 в цепочку добавлены post-processing gamma и saturation. Это позволяет корректировать общую гамму и насыщенность после основного tone mapping без перехода в другой редактор. Эти коррекции не заменяют локальную ретушь, маски или выборочную цветокоррекцию, но помогают довести базовый LDR до нейтрального вида. При подготовке файла для последующего редактора чрезмерное усиление насыщенности на этом этапе нежелательно: лучше сохранить запас для дальнейшей обработки, чем необратимо ограничить цвета в 8-bit JPEG.

Редактирование HDR: кадрирование, размер, поворот и проекции

Инструменты Edit работают непосредственно с HDR-документом. Для кадрирования пользователь выделяет прямоугольник на изображении; границы и углы рамки можно перетаскивать, после чего применяется Edit > Crop to Selection. Команда создаёт новый несохранённый HDR с выбранной областью. Это полезно после автоматического выравнивания, когда по краям появляются пустые или несовпадающие зоны. Исходный открытый HDR при этом не нужно уничтожать: новый вариант следует сохранить под отдельным именем.

Edit > Remove Selection снимает текущее выделение без кадрирования. Эта команда важна при проверке tone mapping по выбранной области: выделение может влиять на то, какая часть изображения используется для ускоренного preview, поэтому перед финальным сравнением нужно понимать, осталась ли активная область. Если требуется оценить весь кадр, выделение следует удалить и пересчитать preview в нужном размере.

Edit > Resize… открывает Scale Image. В диалоге задаются Width и Height, а единицы можно выбрать как Pixels или процент. Reset возвращает исходные значения, Scale выполняет масштабирование. Изменение размера применяется к HDR до дальнейшего tone mapping, поэтому оно отличается от выбора Result Size на панели Tonemap. Resize меняет сам HDR-документ; Result Size определяет размер создаваемого LDR для конкретного расчёта.

Поворот выполняется командами Edit > Rotate Counter-Clockwise и Edit > Rotate Clockwise; каждый шаг составляет 90 градусов. В документации также указаны клавиши [и]. Это физическое изменение ориентации HDR, а не только поворот отображения. Если исходный кадр уже правильно ориентирован через метаданные, лишний поворот не нужен; команда полезна для файлов, у которых ориентация не была применена при импорте.

Edit > Projective Transformation… предназначен для преобразования между проекциями и коррекции ориентации. В диалоге доступны Source Projection, Destination Projection, Angles, Bilinear Interpolation, Oversample factor и вращения Yaw, Pitch, Roll. Инструмент может использоваться, например, для преобразования полярного представления или переназначения панорамной проекции. Он не является автоматическим исправителем перспективы архитектуры: пользователь явно задаёт типы проекции и углы.

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

Форматы, импорт, экспорт и метаданные

В HDR-контуре поддерживаются OpenEXR с расширением .exr, Radiance RGBE .hdr, TIFF 16-bit, 32-bit float и LogLuv, RAW различных камер и собственный PFS. В LDR-контуре проект работает с JPEG, PNG, PPM, PBM, TIFF и FITS; документация отдельно описывает чтение и запись основных HDR-форматов и сохранение обычных изображений. RAW обрабатывается через LibRaw. Поэтому фактический список камер определяется не только версией Luminance HDR, но и версией LibRaw, с которой собран конкретный пакет.

Для TIFF в Preferences > HDR Options выбирается формат HDR TIFF по умолчанию: LogLuv TIFF с float 16-bit per color channel либо Float TIFF с 32-bit per color channel. В этом же разделе задаются цвета, которыми интерфейс отображает отрицательные значения и NaN/±Inf. Эти диагностические настройки важны при работе с вычислительными HDR-данными: необычные числовые значения не должны маскироваться под обычные цвета кадра. Если после слияния появляются такие зоны, нужно проверить исходники и параметры HDR-построения.

Fast export отделён от обычного сохранения HDR. Во вкладке Preferences > Fast export задаются Export directory и Format. Кнопка Fast export на панели Tonemap затем выводит текущий полноразмерный LDR без повторного выбора папки и формата. Это удобно для серии сравнительных вариантов, но повышает риск спутать файлы, если имя и каталог заранее не организованы. Для постоянной работы целесообразно выделить отдельные папки для master HDR, previews и финальных LDR.

Инструмент Tools > Copy Exif Data… переносит EXIF между двумя списками файлов. Соответствие строится по порядку: элементы From и To сопоставляются попарно. По умолчанию включено Keep existing Exif tags in destination file, потому что Luminance HDR хранит сведения о tone mapping в EXIF comment destination-файла. Перед запуском необходимо проверить порядок обеих колонок; ошибочная сортировка перенесёт метаданные не к тем изображениям.

Перенос EXIF полезен, когда финальный LDR должен сохранить информацию о камере, выдержке или других исходных параметрах, но он имеет и приватностное следствие: EXIF может содержать данные, которые пользователь не хочет публиковать. Перед передачей файла в публичную галерею нужно отдельно проверить метаданные результата и удалить ненужные поля подходящим инструментом. Luminance HDR предназначен для копирования EXIF, а не для гарантированной анонимизации фотографий.

Формат master-файла следует выбирать по дальнейшей цепочке. OpenEXR и 32-bit float TIFF сохраняют высокодинамические данные для совместимых приложений; Radiance RGBE удобен в HDR-ориентированных конвейерах; LogLuv TIFF представляет HDR внутри контейнера TIFF. Если задача закончена на tone mapping, LDR TIFF или JPEG проще для обмена. Не стоит путать 16-bit TIFF как HDR-вариант в одном контексте и 16-bit LDR TIFF для последующего редактирования в другом: смысл определяется стадией процесса и содержимым файла.

При экспорте в JPEG имеет значение финальная стадия: JPEG — LDR и не хранит исходный расширенный диапазон так, как OpenEXR или float TIFF. Поэтому удалять master HDR сразу после получения JPEG нерационально, если кадр может понадобиться для другого отображения. Сохранённый HDR и settings-файл позволяют пересчитать изображение в другом размере, с другим оператором или без Auto Levels без повторной сборки экспозиций.

RAW Conversion и работа с одним RAW-файлом

Luminance HDR умеет открывать один RAW как HDR/LDR-источник, поэтому программа применима не только к брекетинговой серии. В таком сценарии RAW загружается в рабочую область, после чего можно выполнить tone mapping и экспорт. Однако один RAW не превращается в многокадровый HDR с дополнительной информацией из разных экспозиций: динамический диапазон ограничен данными самого RAW. Практическая ценность режима — возможность использовать те же tone-mapping operators для одного высокоразрядного исходника.

Во вкладке Preferences > RAW Conversion доступны параметры демозаики. Документация перечисляет Bilinear, VNG, PPG и AHD, а также Four color RGB и опцию, связанную с сохранением геометрии без автоматического растяжения или поворота. Выбор метода влияет на детализацию и артефакты ещё до tone mapping. Если серия снята в RAW, все кадры нужно обрабатывать согласованно; различающиеся настройки демозаики между экспозициями затруднят чистое слияние.

Баланс белого можно задать как Default D65, Camera, Automatic или Manual. В ручном режиме доступны Temperature и Green. Для брекетинга логично сохранять единый баланс белого по серии, потому что разный цветовой сдвиг между кадрами не является информацией о динамическом диапазоне и может проявиться после слияния. Если камера записала корректный WB, Camera обеспечивает согласованный старт; Manual нужен для контролируемой установки температуры и зелёной компоненты.

Обработка светов включает Solid white, Unclip, Blend и Rebuild. Также имеются Brightness, black/white points, шумоподавление через threshold и коррекция хроматической аберрации с отдельными множителями red и blue. Эти параметры относятся к RAW-декодированию, то есть меняют данные до построения или отображения HDR. Их нужно настраивать до оценки tone mapping: иначе пользователь рискует компенсировать ошибку RAW-конвертации ползунками другого этапа.

Для обмена с внешним RAW-редактором можно сначала проявить исходники одинаково и сохранить 16-bit TIFF, а затем собрать HDR из TIFF. Такой путь полезен, когда камера новее библиотеки LibRaw в используемой сборке или требуется специфическая коррекция объектива до Luminance HDR. Принципиально важно экспортировать все кадры серии с одинаковыми параметрами и без автоматического выравнивания экспозиции, которое уничтожит исходные различия EV.

Чтобы проверить поддержку конкретной камеры, ориентируются на фактическую LibRaw внутри сборки, а не на общий список расширений RAW. Версия 2.5.0 добавила отображение списка поддерживаемых камер и информации LibRaw, но сами камеры со временем меняются. Если новый RAW не открывается, надёжный обходной путь — конвертировать серию внешним актуальным RAW-конвертером в одинаковые 16-bit TIFF, сохраняя разницу экспозиций и геометрию кадров.

Согласованная RAW-подготовка особенно важна для шума. Недоэкспонированный кадр брекетинга содержит больше шума в тенях, а агрессивное локальное tone mapping делает его заметнее. Если применять noise reduction до HDR creation, параметры должны быть одинаковыми или логически согласованными по серии. Иначе текстуры между кадрами будут различаться и алгоритм слияния получит не только разную экспозицию, но и разную степень детализации.

Коррекция хроматической аберрации до выравнивания полезна, потому что цветные края на контрастных границах могут усиливаться после tone mapping. Luminance HDR предоставляет красный и синий множители в RAW Conversion. Если используются внешние TIFF, коррекцию объектива нужно применять ко всем исходникам одинаково. После геометрического исправления следует проверить, что размеры кадров остались идентичными; иначе HDR Wizard потребует дополнительного согласования.

Управление цветом и подготовка результата к просмотру или печати

Цветоуправляемый workflow — одна из заявленных функций Luminance HDR. При импорте встроенный профиль RAW/JPEG учитывается, а внутренний процесс использует sRGB как рабочее представление. В Preferences > Color Management задаются профили монитора, камеры и принтера. Для камеры предусмотрен режим Built-in, который использует встроенный профиль изображения. Корректный профиль монитора особенно важен при сравнении насыщенности и тонов после tone mapping: без него визуальная оценка на экране не привязана к реальному поведению дисплея.

Soft Proofing предназначен для имитации вывода через профиль принтера. Gamut Check показывает цвета вне охвата специальным цветом, в документации — зелёным. Это не исправляет цвета автоматически: функция помогает обнаружить участки, которые выбранное устройство вывода не воспроизводит. После обнаружения пользователь корректирует изображение или выбирает другой способ вывода. Для печати нужен профиль конкретной комбинации принтер/бумага, а не произвольный ICC.

При сохранении TIFF/JPEG приложение встраивает стандартный sRGB-профиль. Это делает обычный LDR более предсказуемым в программах, которые соблюдают управление цветом. Если дальнейший профессиональный редактор ожидает другую рабочую среду, важно учитывать этот этап конвертации и не считать, что HDR master и LDR export находятся в одном и том же цветовом пространстве. HDR-файл служит носителем расширенного диапазона, а LDR — уже отображённый результат для конкретной дальнейшей задачи.

Цветовое управление не отменяет проверку clipping. После агрессивного tone mapping часть локальных деталей может сохраняться визуально, но последующая Auto Levels или сильная насыщенность способна привести каналы к пределам. Перед JPEG-экспортом полезно сравнить TIFF-версию и JPEG при 100% масштабе, особенно на плавных градиентах неба и насыщенных световых источниках. Если файл идёт в дальнейшую обработку, 16-bit TIFF даёт больше запаса, чем 8-bit JPEG.

Для серии кадров единообразие профилей важнее, чем индивидуальная коррекция каждого исходника. Если один кадр брекетинга переведён в другое пространство или имеет отличный баланс белого, HDR-сборка объединяет не только разную экспозицию, но и различающиеся цветовые преобразования. Поэтому при внешнем RAW-проявлении перед Luminance HDR следует синхронизировать профиль, WB, геометрические коррекции и размер всех кадров.

При сравнении двух operators через Lock Viewers следует использовать одинаковые условия цветового просмотра. Если один файл открыт в другом приложении с отличающимся управлением ICC, визуальное различие нельзя целиком приписывать tone mapping. Надёжнее сначала сравнить варианты внутри Luminance HDR, затем открыть экспорт в целевом редакторе и убедиться, что встроенный sRGB распознан. Для печати следующий контроль выполняется уже через профиль устройства вывода.

Gamut Check полезен после увеличения насыщенности: яркий цвет может выглядеть эффектно на широком дисплее, но выйти за охват принтера. Зелёная индикация показывает проблемные области, после чего корректируются насыщенность или тональность. Проверка должна относиться к финальному LDR, потому что именно он будет печататься; master HDR остаётся источником и не является непосредственным печатным файлом.

Пакетная обработка и командная строка

Batch HDR автоматизирует создание нескольких HDR-серий. Исходные фотографии должны быть организованы так, чтобы программа могла разбить последовательность на брекетинги; документация отмечает алфавитный порядок файлов. Пользователь задаёт число фотографий в одном bracket, профиль HDR creation, при необходимости auto-alignment, формат выходного HDR и входной/выходной каталоги. Панель прогресса показывает выполнение задач. Ошибка в числе кадров на bracket сдвигает всю группировку, поэтому перед запуском большой партии нужно проверить первые две серии вручную.

Batch Tonemapping строит сочетание входов и наборов настроек: M HDR-файлов и N settings-файлов дают M×N LDR-результатов. Это удобно для систематического сравнения операторов или нескольких проверенных пресетов на серии. Пользователь добавляет список HDR, список файлов настроек и выходной каталог; Log показывает сообщения и поддерживает фильтрацию. Чтобы результаты не смешивались, settings-файлы стоит называть по оператору и назначению, например нейтральный и контрастный вариант, а не использовать безымянные последовательные номера.

Число потоков пакетного tone mapping настраивается в Preferences. Это позволяет согласовать вычислительную нагрузку с количеством CPU cores. Интерфейс не предлагает отдельного пользовательского переключателя GPU-ускорения, поэтому основная настройка параллельности для batch относится к потокам процессора. На рабочей станции, где параллельно выполняются другие задачи, максимальное число потоков не всегда рационально: ограничение оставляет ресурсы системе и уменьшает конкуренцию за память.

Командная утилита luminance-hdr-cli позволяет строить тот же процесс без GUI. В ней доступны проверка версии, список камер, выбор выравнивания AIS или MTB, ручное задание EV, сохранение выровненных файлов, загрузка и сохранение HDR, gamma, resize, LDR output, auto anti-ghosting threshold, autolevels и создание web-страницы с HDR viewer. Для скрипта это означает, что серия может проходить от исходников до LDR без ручных кликов, если параметры известны заранее.

CLI также предоставляет параметры HDR creation: веса triangular, gaussian, plateau или flat; response curve from_file, linear, gamma, log или srgb; модель robertson, robertsonauto или debevec. В документации default для weight — triangular, для response — linear, для model — debevec. Эти параметры следует хранить вместе со скриптом, если нужна воспроизводимость: изменение модели слияния меняет HDR ещё до tone mapping, а значит результат нельзя считать тем же процессом только потому, что финальный оператор одинаков.

Для LDR из CLI задаётся качество 1–100, а TIFF имеет варианты 8b, 16b, 32b и logluv; доступно deflate-сжатие. Такие параметры позволяют использовать Luminance HDR в автоматической цепочке подготовки нескольких форматов: сохранить master HDR, вывести 16-bit TIFF для редактора и JPEG для быстрой проверки. Именование файлов и контроль перезаписи остаются задачей скрипта — GUI не управляет каталогом пользовательской автоматизации.

Создание HTML с embedded HDR viewer появилось в 2.5.0 и доступно через соответствующую функцию CLI. Это отдельный формат представления результата, а не облачный сервис Luminance HDR. Содержимое генерируется из локальных данных, после чего пользователь сам решает, где хранить или публиковать HTML. Для обычной галереи такой вывод не заменяет статический JPEG, но позволяет подготовить интерактивное представление расширенного диапазона.

В batch-процессе настройки HDR creation и tone mapping нужно разделять. Первый settings/profile определяет, как из экспозиций строится HDR; второй определяет отображение уже готового HDR в LDR. Если один и тот же LDR выглядит по-разному в двух партиях, сначала сравнивают master HDR. Если master совпадает, причина находится в operator/settings/Auto Levels; если master различается, искать нужно в alignment, EV, response curve, weight или модели HDR creation.

Лог пакетной обработки нужен не только при полном сбое. Предупреждения о проблемном входном файле, ошибке записи или пропущенной серии могут затронуть один результат из сотен. После batch следует проверить число созданных файлов: оно должно соответствовать числу входных серий для Batch HDR и произведению M×N для Batch Tonemapping. Несовпадение количества — повод просмотреть Log до визуальной проверки изображений.

Для повторяемого CLI-процесса полезно сохранять рядом с результатом текст запуска или конфигурацию. В ней фиксируются EV, alignment, model, weight, response curve, operator и размер. Сам LDR не содержит все эти параметры в гарантированно машиночитаемом виде для повторного запуска. Конфигурация делает автоматизацию проверяемой и позволяет менять один параметр за раз, не восстанавливая команду по памяти.

Производительность и работа с крупными файлами

HDR-сборка и tone mapping требуют заметно больше вычислений и памяти, чем обычный просмотр JPEG: программа одновременно оперирует несколькими экспозициями и высокоразрядным HDR. В 2.6.0 разработчики отдельно оптимизировали все tone-mapping operators по скорости и потреблению памяти, а также ускорили HDR creation. Это одно из ключевых изменений ветки 2.6.x. Тем не менее время расчёта зависит от разрешения, числа исходников, выбранного оператора и этапов alignment/deghosting.

Главный способ ускорить настройку без потери полноразмерного master — работать с меньшим Result Size на preview. После выбора параметров выполняется финальный рендер нужного размера. Для operators, чувствительных к размеру, маленький preview нельзя считать точным финальным эталоном, поэтому полезен второй метод — выделение репрезентативной области изображения и расчёт её в более близком к финальному масштабе. Он особенно полезен на небе, тонких фактурах, краях зданий и местах возможных ореолов.

Временная рабочая папка задаётся в Preferences > Tone Mapping. На диске должно быть достаточно свободного места для промежуточных данных; числовой минимум не опубликован, потому что объём зависит от разрешения и количества файлов. Для больших RAW-серий лучше размещать temp directory на быстром локальном диске, а не на медленном сетевом ресурсе. После завершения чувствительного проекта эту папку нужно проверить и очистить по обычным правилам работы с временными файлами.

Batch Tonemapping использует настраиваемое число потоков. Увеличение числа потоков повышает параллелизм, но несколько полноразмерных HDR одновременно увеличивают нагрузку на RAM. Если система начинает активно обращаться к swap/pagefile, снижение числа параллельных задач полезнее, чем формальное использование всех cores. В документации нет универсальной нормы RAM на один мегапиксель, поэтому ресурсное потребление измеряют на типичной серии конкретной камеры.

При самостоятельной сборке важно использовать Release-конфигурацию. Инструкция сборки отмечает, что оптимизированная Release-версия работает в несколько раз быстрее Debug. Debug предназначена для диагностики и не отражает производительность готового пакета. Это особенно заметно на повторяющихся вычислительных циклах tone mapping. Если самосборная версия неожиданно медленнее пакетной из дистрибутива, сначала проверяют тип сборки и оптимизации компилятора.

Старый upstream не означает, что любой современный Linux-пакет идентичен бинарнику 2019 года. Fedora продолжает применять совместимые с новыми библиотеками патчи и регулярно пересобивает 2.6.1.1. Поэтому производительность и стабильность могут различаться между Windows 2.6.0 и Linux 2.6.1.1 с дистрибутивными исправлениями. Сравнивать их корректно на одном наборе RAW, одинаковом операторе, одном Result Size и одинаковом числе потоков.

Выравнивание и deghosting добавляют отдельные вычислительные стадии. Если нужно оценить чистую скорость tone mapping, тест следует проводить на заранее сохранённом master HDR, исключив HDR Wizard. Если нужно измерить полный цикл, наоборот, включают alignment, deghosting и сохранение. Смешение этих двух тестов даёт мало полезной информации: медленный align_image_stack нельзя приписывать конкретному operator, а тяжёлый operator не характеризует скорость HDR merge.

Скорость preview нельзя оценивать отдельно от размера. Result Size уменьшает число пикселей, а выделенная область дополнительно сокращает обрабатываемый фрагмент. Поэтому быстрый preview — инструмент настройки, а не доказательство скорости полноразмерного экспорта. Для регулярной работы полезно один раз измерить время full-size render каждого реально используемого operator на типичном 24/40/60-мегапиксельном файле своей камеры и выбрать приемлемые схемы batch.

При длинной серии рост потребления памяти связан не только с числом кадров, но и с промежуточным HDR. RAW сначала декодируется, затем данные используются в merge, после чего создаётся высокоразрядное представление. Если ресурс ограничен, практичнее обрабатывать серии последовательно и уменьшать число batch threads, а не предварительно уменьшать все исходники и терять разрешение master-файла.

Для сетевых рабочих каталогов отдельное значение имеет temp directory. Исходники могут храниться на NAS, но временные вычислительные файлы быстрее обрабатывать локально. После завершения финальный HDR/LDR можно переместить обратно в сетевое хранилище. Такой порядок не меняет алгоритмы Luminance HDR, но уменьшает зависимость интерактивного preview от задержек сети и не оставляет временную папку в общем каталоге.

Системные требования

Для опубликованного Windows binary в карточке программы корректно указывать 64-битную Windows-сборку 2.6.0 размером 49,6 МБ. Проектная страница для линии 2.6.0 перечисляет Microsoft Windows, Mac OS X 10.9 и новее и Unix-подобные системы, включая Linux. Готовые macOS DMG также относятся к 2.6.0. Для Linux актуальнее пакеты дистрибутивов и Flatpak 2.6.1.1, чем старый универсальный upstream binary.

Для сборки из исходного кода требуется Qt5 и ряд библиотек обработки изображений. В INSTALL перечислены Exiv2, LCMS2, libjpeg-turbo или libjpeg, LibTIFF, libpng, LibRaw и OpenEXR. В зависимости от функций используются CFITSIO для FITS, FFTW3f, Boost, GNU Scientific Library для Mantiuk08 и Eigen3 для Lischinski. Наличие этих зависимостей объясняет, почему современный Linux-пакет удобнее ручной сборки: сопровождающий уже согласовывает версии библиотек и патчи совместимости.

На Linux набор зависимостей меняется вслед за API библиотек. Fedora продолжает поддерживать 2.6.1.1 отдельными пакетными ревизиями. Это не новая функциональная ветка Luminance HDR, а адаптация к окружению дистрибутива. При самостоятельной сборке на новом Linux практический набор зависимостей лучше сверять со спецификацией пакета своей системы, не пытаясь буквально воспроизвести библиотечный стек 2019 года.

Числовых требований вида «4 ГБ RAM» или «процессор не ниже X» в проектной документации нет, поэтому такие значения нельзя добавлять в карточку. Проверка совместимости для рабочей станции выполняется на реальном материале: открыть типичный RAW, собрать обычную серию, выполнить самый тяжёлый используемый operator в полном разрешении и посмотреть пик памяти и время. Эта методика даёт рабочий предел для конкретной камеры и задач.

На современном Linux Flatpak сообщает download size около 89,74 MiB и installed size около 211,21 MiB. Эти числа нельзя смешивать с 49,6 МБ Windows EXE: разные пакеты включают разный набор runtime-компонентов. Размер в паспортной строке этой карточки относится именно к проверенному Windows-инсталлятору 2.6.0, а не к установленному приложению на всех платформах.

Flathub 2.6.1.1 доступен в архитектурах x86_64 и aarch64. Это важно для Linux на ARM: наличие Flatpak-пакета подтверждает отдельную актуальную сборку этой архитектуры, тогда как Windows direct binary в карточке — 64-битный x86-вариант. Архитектуру пакета нельзя переносить между платформами только по слову «64-bit»: формат и зависимости Windows и Linux различаются.

Для macOS опубликованные DMG 2.6.0 различаются не только размером, но и версией Qt: одна сборка основана на Qt 5.9, другая на Qt 5.13. Обе относятся к 2019 году. Это означает, что при проблеме запуска на новой macOS полезно знать конкретный DMG, а не только номер Luminance HDR. Более поздняя исходная 2.6.1.1 не сопровождается в том же публичном каталоге новым готовым DMG.

В историческом описании проекта упоминаются Unix-flavors, включая FreeBSD, но практическая доступность конкретных портов зависит от их текущего сопровождения. Для 2026 года надёжными готовыми путями остаются Windows 2.6.0, старые macOS DMG и современные Linux packages. Если требуется другая Unix-система, задача фактически переходит к сборке из исходников и совместимости зависимостей, а не к готовому установщику.

Требования к монитору не задаются разрешением или диагональю, однако интерфейс 2.5.0 получил улучшения HiDPI, а Preferences позволяет менять Default Previews Width. Для работы с большим количеством ползунков и сравнением нескольких viewers полезен экран, на котором одновременно помещаются панель tone mapping и достаточная область изображения. Это не системный минимум, а практическое следствие компоновки интерфейса.

Практические сценарии использования

Архитектура и интерьер с яркими окнами

В интерьере HDR нужен, когда один кадр не удерживает одновременно детали внутри помещения и вид за ярким окном. Рабочий процесс в Luminance HDR начинается со штативной брекетинговой серии, затем проверяется alignment по прямым линиям рам и мебели, после чего создаётся master HDR. На tone mapping следует отдельно контролировать ореолы вокруг оконных рам и не подменять проблему совмещения увеличением локального контраста. 16-bit TIFF удобен как промежуточный LDR, если дальше требуется локальная коррекция в другом редакторе.

Для серии недвижимости особенно важно единообразие WB. Смешение кадров с автоматически меняющимся балансом белого создаёт цветовые переходы, которые не связаны с HDR. Если используются RAW, в Preferences > RAW Conversion выбирают один метод white balance для всей серии; если исходники проявлены заранее, синхронизируют настройки во внешнем конвертере. После merge проверяют нейтральные стены и границу окна, затем сохраняют master до художественного tone mapping.

Пейзаж с движущейся листвой

Пейзажная серия часто сочетает стабильную геометрию камеры и движение растительности. Здесь ключевым становится anti-ghosting. Автоматические patches нужно сравнить с фактическими участками движения; если ветви распознаются неточно, ручная маска с опорным кадром даёт больше контроля. После слияния полезно открыть tone-mapped вариант с заметным микроконтрастом: он быстро проявляет остаточные двойные края. Только после устранения ghosting имеет смысл подбирать финальную насыщенность и гамму.

На небе проверяют не только ghosting, но и плавность градиента. Сильный local contrast и последующее сохранение в 8-bit JPEG способны сделать переходы грубее. Для последующей цветокоррекции лучше вывести 16-bit TIFF, а JPEG создать после окончательного этапа. При soft proofing перед печатью дополнительно проверяют насыщенные участки через Gamut Check.

Городская сцена с людьми и транспортом

Для улицы автоматическое deghosting может затронуть несколько независимых объектов. Вместо одного большого масочного пятна лучше контролировать отдельные движущиеся зоны, выбирая опорный кадр, где объект расположен наиболее приемлемо. Если человек появился только на одной экспозиции, задача состоит не в усреднении его по серии, а в использовании согласованной области из выбранного кадра. После этого проверяют границы на фоне архитектуры, где смешение кадров особенно заметно.

Автомобиль с бликами может одновременно двигаться и резко менять яркость относительно окружающей сцены. В таком месте автоматический threshold иногда выделяет и соседние отражения. Ручная маска позволяет ограничить заменяемую область. После HDR creation нужно сравнить контур автомобиля, отражения на стекле и неподвижный фон. Если фон двоится, это уже вопрос alignment, а не deghosting.

Один RAW как источник для tone mapping

Один RAW можно открыть без построения многокадрового HDR. Этот сценарий подходит для эксперимента с operators на высокоразрядном исходнике. Сначала настраиваются RAW Conversion и white balance, затем выбирается operator и Pre-gamma. Поскольку дополнительной информации от других экспозиций нет, результат ограничен диапазоном RAW; сильное вытягивание глубоких теней не создаёт отсутствующие детали. Такой режим полезнее рассматривать как специальную тональную обработку RAW, а не как замену брекетингу в экстремально контрастной сцене.

Один RAW также удобен как диагностический тест новой сборки. Если файл открывается, RAW Conversion работает, а Update preview и экспорт проходят успешно, базовый путь LibRaw → HDR/LDR → tone mapping исправен. После этого добавляют брекетинг и alignment. Такой порядок помогает быстро отделить проблему декодирования RAW от проблемы многоэкспозиционного merge.

Повторяющиеся серии недвижимости

Если съёмка состоит из многих комнат с одинаковой схемой брекетинга, Batch HDR и Batch Tonemapping сокращают ручные операции. Сначала вручную отлаживают одну типичную серию: число кадров, alignment, профиль HDR creation и один-два settings-файла tone mapping. После этого Batch HDR группирует файлы, а Batch Tonemapping применяет сохранённые параметры. Контроль качества всё равно нужен: помещение с движущимся человеком или другим световым сценарием требует отдельного deghosting или иной настройки.

Структура имён исходников критична, потому что Batch HDR использует алфавитный порядок. Перед запуском стоит отсортировать каталог тем же способом и убедиться, что каждые N файлов действительно образуют одну экспозиционную группу. После обработки число HDR должно равняться числу серий. Затем несколько HDR из начала, середины и конца партии открывают вручную и проверяют геометрию.

Астрономические и специализированные изображения

В ветке 2.4.0 был добавлен FITS importer, поэтому Luminance HDR умеет работать с FITS в поддерживаемом файловом контуре. Это позволяет открыть специализированные изображения и применить HDR/tone mapping инструменты, но программа не становится научным пакетом фотометрии или калибровки телескопа. Для научной воспроизводимости нужно отделять визуальное tone mapping от измерительных данных: обработанный LDR предназначен для отображения, а исходный FITS сохраняется отдельно.

Проективные преобразования могут быть полезны для изображений в необычных проекциях, поскольку диалог Projective Transformation предлагает Source Projection, Destination Projection и углы Yaw/Pitch/Roll. Но эти операции меняют геометрию изображения. Если файл используется не только для визуализации, оригинальные данные необходимо сохранять отдельно и фиксировать факт преобразования.

Ограничения и ситуации, где нужен другой инструмент

Самое заметное ограничение в 2026 году — возраст upstream-кода. Последняя опубликованная ветка 2.6.1.1 относится к январю 2021 года, а Windows binary — к 2.6.0 2019 года. Linux-дистрибутивы продолжают поддерживать пакет, но это не равно развитию новых пользовательских функций. Если рабочий процесс зависит от поддержки самых новых RAW-камер, свежих API macOS или глубокой интеграции с современными менеджерами фотографий, совместимость нужно проверить до миграции на Luminance HDR.

Интерфейс ориентирован на алгоритмический HDR, а не на массовые готовые стили. Пользователь видит названия operators и специфические параметры, которым нужно научиться. Для новичка это сложнее, чем выбор визуального preset с мгновенным live preview. С другой стороны, такой интерфейс позволяет явно понимать, какой operator создаёт результат. Если приоритет — минимальное количество настроек и максимально предсказуемая автоматическая обработка, коммерческие HDR-редакторы с более современным preset workflow удобнее.

В программе нет полноценной системы слоёв и локальных масок для общего редактирования изображения, сопоставимой с универсальными фоторедакторами. Маски здесь относятся прежде всего к deghosting. После tone mapping локальная ретушь, сложное удаление объектов, композитинг или выборочная цветокоррекция по слоям выполняются в другом редакторе. Поэтому Luminance HDR логично ставить в начале или середине цепочки, а не считать финальным инструментом для любой постобработки.

Preview не всегда равен финальному render. Для некоторых gradient-domain operators результат зависит от размера. Кроме того, изменения параметров требуют Update preview, поэтому можно ошибочно оценить старое изображение, если забыть пересчёт. Это не неисправность, а особенность workflow. Перед сохранением важного результата следует проверить полноразмерный вывод на 100% масштабе и сравнить критичные области с master HDR.

Автоматический anti-ghosting не гарантирует идеальное восстановление сложного движения. Вода, листва, полупрозрачные объекты и большие перемещения требуют ручного контроля. Алгоритм работает с patches и threshold, а пользователь отвечает за выбор опорного кадра и исправление маски. Если серия снята с сильным движением между экспозициями, один RAW иногда даёт более чистую основу, чем попытка объединить несовместимые моменты.

Текущий Flatpak не является verified-пакетом от команды проекта и имеет read/write к home folder. Для пользователя, которому важна строгая sandbox-изоляция, это ограничение конкретного канала распространения. Пакет дистрибутива устанавливается по другой модели, а Windows setup — по третьей. Выбор способа установки должен учитывать не только удобство обновления, но и модель доступа к файлам.

RAW-поддержка наследует ограничения LibRaw. Если камера появилась после библиотечной версии, использованной в старом Windows 2.6.0, программа не обязана распознать её собственный RAW. Linux-пакет с более новой библиотекой может вести себя иначе. Универсальный обходной путь — внешняя проявка в одинаковые 16-bit TIFF, но она добавляет ещё один этап и требует строго синхронизировать WB, профиль и коррекцию объектива.

Программа не публикует точные минимумы RAM и CPU, поэтому нельзя заранее гарантировать комфортную работу по одной формальной спецификации. Большой 32-bit float HDR и несколько параллельных batch-задач могут потребовать значительно больше памяти, чем одиночный JPEG. Для рабочего места с ограниченной RAM нужно уменьшать число потоков и тестировать полноразмерный оператор на реальной серии.

Интеграция с внешними приложениями в документации ограничена файловым обменом, EXIF, внешним align_image_stack и общими форматами. Специализированный Lightroom или Capture One plugin для Luminance HDR не заявлен. Если весь производственный процесс построен вокруг round-trip через каталогизатор, ручной экспорт и повторный импорт файлов добавляют операции, которых у некоторых коммерческих аналогов нет.

Историческая кроссплатформенность не равна современной поддержке каждой ОС. Старый macOS DMG может столкнуться с требованиями подписи, архитектуры или библиотек на новых системах. Поэтому для macOS нужно тестировать конкретную машину. На Linux актуальные package maintainers снижают этот риск, а на Windows direct binary остаётся 64-битной сборкой 2019 года.

Плюсы и минусы

Плюсы

• свободная лицензия GNU GPL v2 и отсутствие платных редакций, разблокирующих HDR-функции;
• полный двухэтапный HDR-workflow: построение HDR из брекетинга и отдельное tone mapping;
• поддержка JPEG, TIFF 8/16-bit и RAW как входов для HDR-серии, а также OpenEXR, Radiance RGBE, HDR TIFF и PFS;
• два варианта автоматического выравнивания — align_image_stack и MTB — плюс ручное совмещение с Difference (E-P);
• автоматический и ручной anti-ghosting с threshold, patches, lasso/brush и выбором опорного кадра;
• набор разных tone-mapping operators и возможность сохранять и загружать параметры;
• Batch HDR, Batch Tonemapping и отдельный luminance-hdr-cli для повторяемой обработки;
• цветоуправляемый workflow с профилем монитора, soft proofing и gamut check;
• RAW Conversion с выбором демозаики, баланса белого, обработки highlights, шумоподавления и коррекции хроматической аберрации;
• инструменты crop, resize, 90-градусного поворота, Projective Transformation и копирования EXIF;
• актуальные Linux-пакеты продолжают собирать ветку 2.6.1.1, несмотря на отсутствие новых upstream-релизов.

Минусы

• готовый Windows-инсталлятор остаётся на версии 2.6.0 2019 года, а более поздняя 2.6.1.1 не представлена тем же готовым Windows binary;
• последняя upstream-ветка датируется 2021 годом, поэтому новые ОС и RAW-камеры зависят от совместимости старого кода и дистрибутивных патчей;
• интерфейс требует понимания HDR-терминов и различий между operators; он менее ориентирован на готовые визуальные presets;
• некоторые tone-mapping algorithms дают preview, зависящий от Result Size, поэтому маленькая миниатюра не всегда точно предсказывает полноразмерный результат;
• anti-ghosting требует ручной проверки и не устраняет автоматически все сложные случаи движения;
• программа не заменяет слоёвый фоторедактор для сложной локальной ретуши после HDR;
• community Flatpak помечен unverified и запрашивает read/write к home folder, что нужно учитывать при жёстких требованиях к sandbox;
• в документации нет конкретного числового минимума RAM/CPU, поэтому ресурсную пригодность приходится оценивать на собственных типичных файлах.

Частые ошибки и способы проверки результата

Главная проверка качества после HDR creation — геометрия и движение. Сначала увеличивают неподвижные контрастные границы и убеждаются, что они одинарные. Затем проверяют объекты, которые перемещались между кадрами. Только после этого оценивают динамический диапазон и tone mapping. Если перейти к operator раньше, повышенный локальный контраст делает артефакты заметнее и может скрыть их истинную причину.

После tone mapping проверяют тени, света, естественные текстуры и градиенты. Проблема не всегда выражается как явный clipping: чрезмерный локальный контраст создаёт halo вокруг контрастных объектов, а сильная насыщенность приводит отдельные каналы к пределу. Сравнение с более нейтральными настройками при одинаковом Result Size позволяет понять, связан ли дефект с tone mapping или уже присутствует в master HDR.

При пакетной работе проверка должна быть выборочной, но системной. Берут одну обычную серию, одну сцену с движением, один самый контрастный сюжет и один файл максимального разрешения. Если все четыре проходят alignment, HDR creation, tone mapping и экспорт без ошибок, запускают основную партию. После завершения просматривают Log и выборочно открывают финальные файлы, а не полагаются только на отсутствие сообщения об ошибке.

Если приложение завершается ошибкой на конкретном наборе исходников, сценарий минимизируют: сначала открывают один файл, затем создают HDR без alignment, потом включают alignment, затем deghosting. Такой порядок определяет этап сбоя. Для RAW отдельно пробуют конвертацию в 16-bit TIFF. Если TIFF проходит, а RAW нет, проблема связана с RAW-decoding/LibRaw, а не с HDR-оператором.

Перед окончательной передачей результата нужно сохранить master HDR и настройки tone mapping, если обработку требуется воспроизвести. Сам LDR не содержит всей информации о том, каким был исходный расширенный диапазон. Settings-файл фиксирует параметры operator, а EXIF comment может хранить сведения о tone mapping. Вместе с исходниками это позволяет повторить вывод в другом размере или с изменённым Auto Levels без новой HDR-сборки.

Ошибка EV требует отдельной проверки. Если EXIF отсутствует и значения введены вручную, нужно убедиться, что шаги экспозиции соответствуют фактической серии. Неверный знак или порядок меняет response модели. Перед merge удобнее отсортировать кадры от тёмного к светлому и сверить относительные EV визуально: самый тёмный кадр должен сохранять света, самый светлый — раскрывать тени.

Если после auto anti-ghosting исчезают или искажаются неподвижные детали, threshold нужно пересчитать. Карта patches должна соответствовать реальному движению, а не заполнять большую стабильную область. Когда автоматический порог не отделяет объект, переходят к manual mask. Проверять только итоговый художественный LDR недостаточно: на нём локальный contrast может скрыть тонкую границу маски.

При расхождении цветов после экспорта сначала проверяют профиль, затем Auto Levels и post-processing saturation. Эти три фактора находятся на разных уровнях. Профиль отвечает за интерпретацию цвета, Auto Levels — за тональный диапазон LDR, saturation — за насыщенность. Одновременное изменение всех трёх мешает понять причину. Для диагностики их меняют по одному.

Если полноразмерный Fattal/Mantiuk выглядит иначе, чем маленькая миниатюра, не нужно копировать параметры из preview в другой operator. Сначала рассчитывают тот же operator на выделенной области и полном масштабе. Документированная зависимость от размера объясняет различие без предположения о повреждённом файле.

Для Copy Exif Data контроль строится на количестве и порядке пар. Если в From шесть файлов, а в To пять, перенос нельзя считать безопасным до исправления списков. После операции в одном-двух итоговых файлах проверяют ключевые поля метаданных и EXIF comment, чтобы убедиться, что tone-mapping сведения не были потеряны или записаны не в тот кадр.

Безопасность, приватность и локальная обработка

Основной рабочий процесс Luminance HDR выполняется локальным настольным приложением: импорт файлов, HDR creation, tone mapping, batch и экспорт не требуют загрузки фотографий в облачный редактор или создания пользовательского проекта на сервере. В 2.5.1 появилась online documentation, но это справочная функция, а не облачная обработка изображения. Для фотографий с конфиденциальным содержимым исходники и результаты можно держать в контролируемом локальном хранилище.

Локальная обработка не равна гарантированной сетевой изоляции. Приложение включает функции справки, а пакет операционной системы может обновляться через инфраструктуру дистрибутива. Если проект требует полностью офлайн-среды, сетевые правила задаются на уровне ОС и проверяются отдельно. Сам HDR workflow не зависит от обязательной учётной записи и не требует загрузки исходников на веб-сервис.

Временные данные создаются в Temporary Working Folder, выбранной в Preferences. Для чувствительного проекта папку нужно разместить на локальном диске с подходящими правами доступа и после завершения проверить её содержимое. На общем компьютере временная папка внутри общего или синхронизируемого каталога может унаследовать нежелательные условия доступа, поэтому temp directory лучше отделить от публичных и облачно-синхронизируемых папок.

EXIF — отдельный риск приватности. Tools > Copy Exif Data… предназначен именно для переноса метаданных, и опция Keep existing Exif tags включена по умолчанию. Если результат публикуется, нужно проверить, какие поля остались в JPEG/TIFF. Программа не является специализированным инструментом очистки метаданных, поэтому удаление чувствительных EXIF-полей выполняется отдельным этапом и проверяется на финальном файле.

Для Flatpak 2.6.1.1 заявлен доступ чтения/записи к домашней папке и legacy windowing system; каталог помечает пакет как potentially unsafe по этим разрешениям и как community built. Это характеристика sandbox-профиля данного пакета, а не доказательство вредоносности Luminance HDR. При строгой модели доступа пользователь Linux может выбрать иной пакет или организовать рабочие каталоги так, чтобы лишние данные не находились в доступной области home.

Открытая лицензия позволяет проверять исходный код и собирать приложение самостоятельно, но самостоятельная сборка переносит ответственность за зависимости и цепочку поставки на пользователя. Для обычной установки рациональнее использовать публичный дистрибутив или пакет операционной системы и хранить сведения о версии. Для Windows direct binary 2.6.0 существует отдельный устойчивый файл, а для Linux актуальная поддержка идёт через сопровождающих пакетов.

Сохраняемые settings-файлы и Portable mode тоже относятся к локальным данным. Если Portable mode используется на USB-носителе, вместе с программой могут переноситься пользовательские настройки. Такой носитель следует защищать так же, как рабочий каталог, если параметры проекта или пути к файлам чувствительны. Portable mode меняет место хранения конфигурации, но не выполняет её шифрование.

Fast export требует заранее выбранного каталога. Если этот каталог находится в папке автоматической облачной синхронизации, результат будет передан соответствующим внешним клиентом после сохранения. Это поведение относится к выбранной файловой системе, а не к встроенному облаку Luminance HDR. Для локального закрытого процесса каталог экспорта следует держать вне синхронизируемых папок.

При публикации HDR-derived JPEG необходимо проверять не только EXIF, но и имя файла и структуру каталогов. Copy Exif сохраняет полезные данные о камере, но публичный сайт может отображать их автоматически. Безопасный процесс заканчивается просмотром финального файла отдельным metadata viewer: пользователь убеждается, что в нём остались только намеренно сохраняемые поля.

В открытом исходном проекте старый возраст релиза повышает значение безопасного источника пакета. Нужно избегать случайных перепакованных установщиков с неизвестными добавлениями и использовать известный публичный файл проекта или пакет дистрибутива. Паспорт этой карточки привязан к конкретному Windows EXE 2.6.0, а не к любому файлу с названием Luminance HDR, найденному в стороннем каталоге.

Отзывы пользователей и профильных изданий

Отзывы пользователей

На странице проекта SourceForge накоплено 55 пользовательских отзывов с общей оценкой 4,6 из 5. Распределение при этом полярное: 49 пятизвёздочных оценок, одна трёхзвёздочная и пять однозвёздочных; четырёх- и двухзвёздочных в отображаемой статистике нет. Подоценки заметно ниже общей звёздности: ease, features и design имеют 3/5, support — 2/5. Это показывает, что высокая общая оценка не означает единодушия по удобству и сопровождению.

Положительные отзывы чаще отмечают свободную лицензию и сам факт полноценного HDR-инструмента без оплаты. В 2020 году пользователь отдельно поблагодарил проект за free/open source модель. Более ранние авторы хвалили полезность обработки и возможность получить HDR-результат без коммерческого пакета. Эти отзывы согласуются с функциональной стороной программы: создание HDR, tone mapping и batch действительно доступны без платного уровня.

Негативные отзывы концентрируются вокруг интерфейса и стабильности отдельных сборок. В 2016 году один пользователь Windows 10 сообщал о падении при добавлении фотографий. В 2015 году другой критиковал неинтуитивный UI и расхождение результата с preview. Эти сообщения относятся к конкретным старым версиям и окружению, поэтому их нельзя переносить как характеристику любой текущей Linux-сборки. Но они объясняют, почему перед постоянной работой нужно проверить собственный тип файлов и полноразмерный render, а не только preview.

Возраст пользовательских сообщений — существенная оговорка. Основная видимая масса отзывов относится к старым веткам, а последний показанный на основной странице отзыв датирован 2020 годом. Поэтому рейтинг полезен для понимания многолетней репутации проекта, но не доказывает совместимость с конкретной Windows 11, новой камерой или текущей macOS. Для таких вопросов важнее фактический запуск нужной сборки и состояние пакета в выбранной ОС.

Оценка support 2/5 согласуется с возрастом проекта: открытый код и issue tracker не равны коммерческой службе поддержки с гарантированным SLA. Пользователь, которому нужен обязательный ответ от вендора в рабочие сроки, должен учитывать это отдельно от качества HDR-алгоритмов. Для домашней и исследовательской работы модель community support приемлема по другим критериям, но она не превращается в коммерческую поддержку.

Сами пользовательские оценки нельзя трактовать как сравнительный тест качества tone mapping. В отзывах смешаны разные версии, ОС и сценарии. Звёздный рейтинг показывает удовлетворённость конкретных авторов, а не измеряет сохранение динамического диапазона, число артефактов или точность color management. Технический выбор лучше основывать на собственной типичной серии и проверке полного workflow.

Профильные материалы

В современном обзоре SoftwareHow среди HDR-программ Luminance HDR рассматривается как бесплатный вариант с относительно чистым базовым окном, корректным чтением данных исходной серии и полезными средствами alignment/deghosting. Автор материала столкнулся с падением на одном этапе compositing и отметил, что большое число опций может запутать; повторная попытка без alignment/deghosting завершилась успешно. Такой эпизод не доказывает общую нестабильность, но показывает практическую ценность раздельной диагностики этапов.

LWN ещё в 2012 году рассматривал проект как технически сильный open-source HDR-инструмент, но отмечал сложность интерфейса и барьер освоения. Этот материал относится к значительно более старой версии, поэтому его нельзя использовать для буквальной оценки панели 2.6.x. Однако общая особенность сохранилась: Luminance HDR показывает пользователю названия и параметры алгоритмов, а не скрывает их за небольшим набором стилистических presets. Для опытного пользователя это даёт контроль, для новичка — дополнительную терминологию.

Старые профильные обзоры CHIP и Computerwoche отмечали бесплатность, кроссплатформенность и возможность создавать HDR без коммерческой лицензии. Разброс мнений об интуитивности у изданий и пользователей подтверждает, что удобство зависит от ожиданий: фотограф, знакомый с EV, response curve, deghosting и tone-mapping operators, быстрее понимает логику приложения, чем пользователь, ожидающий один автоматический HDR-фильтр.

Профессиональные материалы разных лет сходятся в одном практическом пункте: Luminance HDR даёт серьёзный набор HDR-инструментов без оплаты, но требует больше осознанных решений, чем ориентированные на presets продукты. Это не является универсальным недостатком. При пакетной работе сохранённые settings и CLI превращают сложность настройки в повторяемость, а при разовой обработке тот же объём параметров может замедлить новичка.

При чтении старых обзоров важно учитывать версии. Материал 2012 года не знает о Fast Export, новых operators 2.5/2.6, HiDPI improvements, automatic anti-ghosting поздней линии и других изменениях. Современная оценка должна опираться на 2.6.x интерфейс, но и новый обзор не заменяет тест совместимости с текущей камерой, потому что Windows binary остаётся старым.

В профильных материалах нет основания приписывать Luminance HDR универсально «лучшее качество HDR». Разные operators дают разные визуальные решения, а сравнение зависит от исходной серии и настроек. Объективно подтверждаются функциональные различия: наличие нескольких algorithms, alignment, deghosting, batch, CLI и color management. Художественное предпочтение нужно отделять от проверяемой функции.

Сравнение с аналогами

Luminance HDR уместно сравнивать с другими самостоятельными HDR-программами по одинаковым критериям: лицензия, платформы, построение HDR, deghosting, batch, RAW и интеграция с внешним фотопроцессом. В качестве ориентиров подходят Photomatix Pro и easyHDR. Сравнение не меняет предмет статьи: Luminance HDR остаётся единственным главным продуктом, а аналоги нужны для понимания компромиссов.

Photomatix Pro 7 рациональнее там, где важна коммерчески поддерживаемая связка с Lightroom или Capture One, большое число готовых настроек и специализированный фотографический workflow. Luminance HDR выигрывает у него не «качеством картинки вообще», а лицензией и прозрачностью алгоритмической части: пользователь получает открытый код, CLI и доступ к классическим tone-mapping operators без покупки лицензии. Для фотографа, который уже строит каталог и RAW-проявку в Lightroom/Capture One, интеграция Photomatix сокращает передачу файлов между программами.

easyHDR 3.17 активнее обновляется и включает не только HDR merge/tone mapping, но и дополнительные инструменты: layers/masks, 360 panorama, lens distortion correction, clone/healing, 3D LUT и Lightroom plug-in. Это более широкий законченный коммерческий редактор. Luminance HDR остаётся логичным вариантом, когда нужен именно свободный HDR-процесс и пользователь готов выполнять последующую локальную ретушь отдельно. Сравнивать их по одному количеству функций некорректно: архитектура продуктов и модель распространения различаются.

Если основное требование — Linux, Luminance HDR имеет заметное преимущество по доступности: текущие пакеты 2.6.1.1 существуют в Fedora и Flathub, тогда как сравниваемые коммерческие продукты ориентированы на Windows/macOS. Если главное — современный интерфейс, активная коммерческая поддержка и интеграция с фоторедактором, аналоги предлагают более свежий workflow. Если главное — открытая реализация HDR, локальная обработка и возможность автоматизировать CLI, Luminance HDR функционально самостоятельна.

Для выбора полезно прогнать одну и ту же сложную серию через тестируемые программы и сравнить не только внешний вид, но и время на ручной deghosting, повторяемость batch, экспорт 16-bit TIFF и сохранение нужного master HDR. Художественный tone mapping субъективен, а рабочие потери времени измеримы: если в типичном сюжете Luminance HDR требует сложной ручной маски для каждого кадра, коммерческий deghosting может оправдать затраты; если сцены в основном статичны, открытый инструмент закрывает задачу без лицензии.

С точки зрения автоматизации Luminance HDR выделяется отдельным CLI и явными параметрами HDR creation. Это удобно для скриптов, серверных очередей и воспроизводимых рабочих процессов. Photomatix и easyHDR сильнее в интеграции с привычным фотоинтерфейсом и preset-процессом. Пользователю, который ценит повторяемую командную строку, отсутствие этой разницы было бы существенным; пользователю, который работает исключительно мышью в Lightroom, наоборот, CLI не даёт практического преимущества.

С точки зрения жизненного цикла ситуация обратная: easyHDR 3.17 имеет выпуск 2025 года, Photomatix Pro 7 относится к актуальной коммерческой линии, а upstream Luminance HDR не публиковал новую номерную ветку после 2021 года. Поэтому новые камеры и системные обновления у Luminance HDR сильнее зависят от LibRaw и package maintainers. При стабильном файловом процессе с TIFF/OpenEXR это ограничение менее критично, чем при постоянной покупке новых камер.

По модели оплаты Luminance HDR не имеет trial-ограничений и водяного знака. У Photomatix trial добавляет watermark, а easyHDR продаётся как Home/Commercial license. Для учебного курса, лабораторной работы или домашнего эксперимента свободная лицензия Luminance HDR снижает барьер. Для бизнеса важнее оценить не только стоимость лицензии, но и время сопровождения старого open-source приложения в конкретной инфраструктуре.

По глубине общей ретуши easyHDR предоставляет больше встроенных инструментов, тогда как Luminance HDR сосредоточена на HDR. Это не делает её «хуже» по предметной задаче: узкая специализация помогает отделить master HDR от последующего ретуширования. Но если пользователь хочет получить готовый кадр с healing, слоями и локальными масками в одном окне, ему придётся добавить второй редактор.

Внутри каталога FreeEXE Luminance HDR логично относится к разделу HDR-редакторов и тональной обработки. Эта внутренняя классификация отражает реальное назначение программы: она не является универсальным фоторедактором, панорамным stitcher или DAM, хотя использует отдельные инструменты выравнивания и проекций.

FAQ по Luminance HDR

Почему одновременно встречаются версии 2.6.0 и 2.6.1.1?

Потому что это разные каналы поставки. Готовый 64-битный Windows EXE опубликован как 2.6.0, тогда как 2.6.1.1 — более поздняя исходная ветка, которую продолжают использовать Linux-пакеты. Номер 2.6.1.1 не означает наличие готового Windows-инсталлятора той же версии в основном каталоге проекта.

Можно ли создать HDR, если в файлах нет корректного EXIF с экспозицией?

Да. В HDR Wizard значения EV можно задать вручную. Нужно ввести реальную относительную разницу экспозиций между кадрами. Если значения неверны, программа получает ошибочную экспозиционную модель серии и качество HDR-сборки ухудшается.

Что выбрать для выравнивания: align_image_stack или MTB?

align_image_stack функционально богаче по геометрии и используется как внешний инструмент Hugin. MTB подходит для сопоставления LDR, но не моделирует вращение. Для серии с заметным поворотом или более сложным геометрическим расхождением предпочтительнее align_image_stack; для уже совпадающей штативной серии можно проверить результат и без дополнительного alignment.

Как убрать «призраков» от людей, веток или машин?

Сначала используют automatic anti-ghosting и проверяют найденные patches при выбранном threshold. Если нужная область определена неверно, переходят к manual anti-ghosting: выбирают опорный кадр и создают маску lasso или brush по движущемуся объекту. После HDR creation границы объекта проверяют в увеличении и на tone-mapped версии.

Почему маленький preview отличается от полноразмерного результата?

Некоторые gradient-domain operators, в частности Fattal и Mantiuk, чувствительны к размеру вычисления. Маленький Result Size меняет условия расчёта. Для точной проверки выделяют характерную область и рассчитывают её в близком к финальному масштабе, а перед экспортом выполняют полноразмерный render.

Есть ли русский интерфейс?

Да. Проект поддерживает международные переводы, включая русский. Язык выбирается в Preferences > Interface. Там же настраиваются тема, ширина preview, показ Preview Panel и Portable mode.

Можно ли обработать один RAW без брекетинга?

Да. Один RAW можно открыть и использовать как высокоразрядный источник для tone mapping. При этом программа не получает дополнительной информации от нескольких экспозиций: динамический диапазон ограничен содержимым исходного RAW. Настройки RAW Conversion применяются до tone mapping.

Можно ли автоматизировать сотни серий?

Да. Для графической пакетной работы есть Batch HDR и Batch Tonemapping; для скриптов — luminance-hdr-cli. Batch Tonemapping применяет каждый добавленный settings-файл к каждому HDR, поэтому M входов и N настроек создают M×N результатов. До массового запуска нужно проверить группировку bracket и имена выходных файлов на небольшой выборке.

Какой формат выбрать для дальнейшего редактирования?

Если нужен master с расширенным диапазоном, сохраняют HDR в OpenEXR, Radiance RGBE, HDR TIFF или другом поддерживаемом HDR-формате. Если HDR уже tone-mapped и файл идёт в другой редактор, 16-bit TIFF сохраняет больше градаций для дальнейших корректировок, чем 8-bit JPEG. Для веб-публикации используют LDR JPEG/PNG после финальной проверки.

Загружает ли Luminance HDR фотографии в облако?

Основные операции выполняются локально в настольном приложении: импорт, слияние, tone mapping, batch и экспорт работают с локальными файлами и не требуют облачного проекта или учётной записи. Online documentation — отдельная справочная функция. Для строгой офлайн-среды сетевой доступ приложения регулируется средствами операционной системы.

Что делать, если RAW новой камеры не открывается?

Поддержка RAW зависит от LibRaw внутри конкретной сборки. Сначала проверяют более свежий пакет Linux-системы, если работа идёт на Linux. Если формат всё равно не читается, всю брекетинговую серию проявляют во внешнем актуальном RAW-конвертере с одинаковыми настройками и сохраняют 16-bit TIFF, не выравнивая экспозицию между кадрами.

Где Luminance HDR хранит временные данные?

Temporary Working Folder задаётся в Preferences > Tone Mapping. Каталог выбирают на диске с достаточным свободным местом. Для конфиденциальных исходников используют локальную папку с контролируемыми правами и проверяют её после завершения проекта.

Можно ли сохранить настройки tone mapping и применить их позже?

Да. На панели Tone Mapping Settings есть сохранение и загрузка параметров. Сохранённые settings можно использовать повторно, в том числе в Batch Tonemapping. Параметры относятся к конкретному operator, поэтому файл настроек нужно хранить с понятным именем и не считать значения взаимозаменяемыми между разными algorithms.

Чем Resize отличается от Result Size?

Edit > Resize… меняет размер HDR-документа. Result Size на панели Tonemap задаёт размер создаваемого LDR при расчёте operator. Если нужно сохранить полноразмерный master HDR, его не следует уменьшать через Resize только ради быстрого preview; для этого используется меньший Result Size или расчёт выделенной области.

Можно ли копировать EXIF в готовые файлы?

Да. Tools > Copy Exif Data… сопоставляет списки From и To попарно. Перед Start нужно проверить одинаковый порядок файлов. Опция Keep existing Exif tags in destination file сохраняет уже имеющиеся теги; это важно, потому что Luminance HDR использует EXIF comment для сведений о tone mapping.

Есть ли встроенная пакетная конвертация с разными settings?

Да. Batch Tonemapping принимает несколько HDR и несколько settings-файлов. Каждый набор настроек применяется к каждому входному HDR, поэтому число результатов равно произведению количества входов на количество настроек. Это удобно для сравнительного рендера, но требует заранее организованных имён выходных файлов.

Что делать, если автоматическое deghosting отмечает слишком много областей?

Меняют threshold и пересчитывают patches. Цель — чтобы отмеченные зоны соответствовали фактическому движению. Если автоматический режим не отделяет движущийся объект от стабильного фона, используют manual anti-ghosting с опорным кадром и маской lasso или brush.

Поддерживает ли программа 16-bit output?

Да. Проект заявляет 16bit/channel output, а TIFF входит в поддерживаемые LDR/HDR-форматы. Для дальнейшего редактирования после tone mapping 16-bit TIFF сохраняет больше градаций, чем 8-bit JPEG. HDR TIFF дополнительно имеет собственные варианты LogLuv и float, которые выбираются в HDR Options.

Для чего нужна команда View > Lock Viewers?

Она синхронизирует просмотр нескольких открытых изображений. При сравнении разных tone-mapped версий одинаковая область остаётся под контролем, поэтому проще оценивать ореолы, резкость, тени и локальный contrast. Это полезнее последовательного открытия файлов в разных позициях и масштабах.

Как оценить, подходит ли Luminance HDR для вашей работы

Для новичка программа подходит, если есть готовность разобраться в двухэтапной логике HDR creation и tone mapping. Начинать лучше с трёх статичных JPEG/TIFF одной сцены, без движения и сложного alignment: так видно, как EV превращаются в HDR, а затем как разные operators отображают диапазон. После освоения базового процесса переходят к RAW, ручному deghosting и сохранению settings. Попытка одновременно изучать все параметры RAW, alignment и Mantiuk/Fattal усложняет диагностику.

Для опытного фотографа главная ценность — контроль и воспроизводимость. Master HDR можно хранить отдельно, operator/settings фиксировать файлом, batch запускать на серии, а CLI включать в скрипты. Цветовое управление, soft proofing и 16-bit output позволяют встроить приложение в более длинную цепочку. Ограничение заключается не в базовой HDR-функциональности, а в возрасте upstream и отсутствии глубокой современной интеграции с каталогизаторами.

Для разовой задачи Luminance HDR рациональна, если не хочется покупать отдельную HDR-лицензию. Но даже разовый проект нужно проверить на фактической ОС: старый Windows binary и macOS DMG не получают новых крупных upstream-релизов. На Linux пакетный менеджер даёт более современную совместимость зависимостей. Если приложение не открывает RAW, преобразование в 16-bit TIFF сохраняет возможность использовать HDR-сборку без смены программы.

Для регулярной коммерческой работы критерий меняется: важны не только отсутствие платы и качество одного кадра, но и скорость на сотнях серий, поддержка новых камер, стабильность alignment/deghosting и интеграция с основным DAM/RAW-редактором. Нужен контрольный прогон типичного заказа. Если Batch HDR и сохранённые settings сокращают ручной труд, Luminance HDR остаётся практичной; если основная часть времени уходит на обход старых интеграционных ограничений, активнее развиваемый коммерческий аналог уменьшает процессные издержки.

Для Linux Luminance HDR представляет отдельный интерес: версия 2.6.1.1 продолжает жить в современных пакетах, и проект остаётся доступным без слоя совместимости Windows. При этом Flatpak имеет широкие file permissions, а дистрибутивные сборки включают патчи сопровождающих. Пользователь выбирает между удобством Flatpak и нативным package manager, но в любом случае фиксирует фактическую версию при обмене настройками и отчётами об ошибках.

Для максимального контроля важна дисциплина этапов: выровнять неподвижную геометрию, устранить движение, сохранить master HDR, выбрать tone-mapping operator на корректном preview, проверить полноразмерный render и только затем экспортировать LDR. Luminance HDR даёт инструменты для каждого шага, но не скрывает их за автоматическим улучшением. Это делает программу требовательнее к пониманию процесса, зато помогает точно определить, где возникает проблема.

Для небольшого бюджета Luminance HDR особенно интересна свободной лицензией: нет обязательной покупки ради HDR merge, batch или CLI. Однако экономию на лицензии нужно сопоставить со временем пользователя. Если сложный production workflow требует постоянных обходных действий из-за старой версии и отсутствия интеграции, стоимость труда может превысить цену коммерческого приложения.

Для работы без установки на постоянную систему предусмотрен Portable mode хранения настроек, а Windows дополнительно имеет ZIP-пакет 2.6.0. Portable mode не меняет совместимость бинарника и не превращает Windows-приложение в Linux/macOS-версию. Его задача — размещение конфигурации рядом с приложением, что полезно на нескольких Windows-машинах или при переносе рабочего профиля.

Для команды важна повторяемость. Settings-файлы, фиксированный master HDR и CLI-команды проще передавать коллегам, чем объяснять визуальный набор ручных ползунков без записи параметров. Но разные package revisions могут содержать исправления библиотек, поэтому в командном регламенте нужно фиксировать версию Luminance HDR и платформу. Это особенно важно, если один сотрудник работает на Windows 2.6.0, а другой — на Linux 2.6.1.1.

Для максимальной скорости сначала оптимизируют процесс, а не художественные настройки: используют preview меньшего размера, выделенные области, разумное число batch threads и локальный Temporary Working Folder. Для максимального качества, наоборот, финальный render выполняют в полном размере и проверяют 100% view. Один и тот же workflow допускает оба режима: быстрый поиск параметров и медленный окончательный вывод.

Итог

Luminance HDR остаётся специализированным open-source инструментом для пользователей, которым нужен локальный HDR-workflow с явным выбором algorithms, поддержкой RAW/HDR-форматов, ручным контролем alignment и deghosting, batch и CLI. Наиболее существенное ограничение — разрыв между готовым Windows binary 2.6.0 и более поздней исходной линией 2.6.1.1, которую поддерживают современные Linux-пакеты. Поэтому решение о внедрении нужно принимать не по одному номеру версии, а после теста на реальной ОС, камере и типичной серии.

Для разовой или учебной HDR-работы без покупки лицензии программа закрывает весь путь от брекетинга до tone-mapped LDR. Для опытного пользователя она интересна сохранением master HDR, разнообразием operators, цветовым управлением и автоматизацией. Для производства, завязанного на самые новые камеры, современные macOS/Windows-интеграции и тесную связку с Lightroom/Capture One, перед выбором нужно сравнить затраты времени с актуальными коммерческими аналогами. Ключевой критерий — не эффектность одного preview, а повторяемость полного процесса и качество полноразмерного результата.

Если брекетинговые серии в основном статичны, форматы уже поддерживаются, а нужен открытый и воспроизводимый процесс, ограничения возраста проекта не мешают использовать его основные HDR-функции. Если каждый заказ включает сложное движение, новую RAW-камеру и тесную интеграцию с внешним каталогизатором, риски сопровождения выше. В обоих случаях правильная оценка строится на одной и той же проверке: фактический merge, deghosting, полноразмерный tone mapping, экспорт и повторение результата по сохранённым настройкам.