Что такое HDR

stas27>> Естественно. Нам же надо 12 бит ужать в 8.
Кот_да_Винчи> хм... а как она жмет - линейно (т.е. просто уменьшая средний наклон кривой)? Дык тогда это не хдр а тупо уменьшение общего контраста, нет?
Ну вот не понял. Что значит "не ХДР"? В смысле рав не ХДР? В моём понимании - нет, он по определению остаётся в пределах ДД сенсора.
А преобразование может быть линейным, для тех, кто хочет, чтобы камерная гистограмма хоть как-то была похожа на то, что есть в раве. Но обычно тональная кривая, ну, как бы это помягче сказать, вполне себе кривая . Иначе результирующий ДЖПеГ получится тёмным и неконтрастным.
Кот_да_Винчи> PS Я к чему спрашиваю - HDR в моем понимании это такой способ преобразования изображения с высоким ДД в изображение с меньшим ДД, при котором детали исходного изображения, находящиеся вне ДД выходного изображения, сохраняют яркостный и/или цветовой контраст, т.е. проще говоря, видимость.
Ну это, повторяю, тональная компрессия. Если её делать грамотно, то так оно и будет (за исключением, конечно, неизбежной некоторой постеризации из-за загрубления шкалы отсчёта, которую и пытаются свести к минимуму, подбирая параметры и алгоритмы в идеале для каждой такой конвертации).

Ответил Рав против ДЖпега.

stas27> Ну вот не понял. Что значит "не ХДР"? В смысле рав не ХДР? В моём понимании - нет, он по определению остаётся в пределах ДД сенсора.

И в моем. Ибо рав мы полностью не увидим - нет таких девайсов под руками.

stas27> А преобразование может быть линейным, для тех, кто хочет, чтобы камерная гистограмма хоть как-то была похожа на то, что есть в раве. Но обычно тональная кривая, ну, как бы это помягче сказать, вполне себе кривая . Иначе результирующий ДЖПеГ получится тёмным и неконтрастным.

Да как бы тут дело не в кривой... я рассуждаю в данном случае как электронщик. Ну например, рассмотрим нижней конец - в тенях. Пусть, для простоты, шумы сенсора ниже младшего разряда сетки квантования. То есть ДД сенсора юзается по полной. Теперь берем приращение яркости на выходе АЦП ровно на один разряд в 12 битном квантовании. МЫ НЕ МОЖЕМ сопоставить в 8-битном представлении каждому такому приращению адекватное приращение яркости. А это не что иное как потеря контраста. Отсюда, манипулируя ТОЛЬКО кривыми мы будем терять детали из-за снижения этого самого локального контраста. Иными словами, для сохранения деталей нужен алгоритм, ИСКУССТВЕННО создающий локальный контраст. То есть, заведомо некую неестественность типа постеризации.

stas27> Ну это, повторяю, тональная компрессия.

Отнюдь не только. Вот по твоей ссылке есть не что иное как композитинг трех брекетов с помощью масок. А такой алгоритм только манипуляцией с кривыми ну никак не опишешь.



ps если я не прав и ТОЛЬКО манипуляциями с кривыми можно уложить 12 бит в 8, не потеряв детали, пусть объяснит мне, глупому, физику процесса. Буду весьма признателен.

....
stas27>> А преобразование может быть линейным, для тех, кто хочет, чтобы камерная гистограмма хоть как-то была похожа на то, что есть в раве. Но обычно тональная кривая, ну, как бы это помягче сказать, вполне себе кривая . Иначе результирующий ДЖПеГ получится тёмным и неконтрастным.
Кот_да_Винчи> Да как бы тут дело не в кривой... ... Теперь берем приращение яркости на выходе АЦП ровно на один разряд в 12 битном квантовании. МЫ НЕ МОЖЕМ сопоставить в 8-битном представлении каждому такому приращению адекватное приращение яркости.
Тут ответ на двух уровнях. Во-первых, в данном конкретном примере теоретически можем - растянув до безобразия кривую внизу . Но при этом неизбежно потеряем где-то ещё - физику и математику, увы, не обманешь.
Во-вторых, обмануть можно (и нужно в этом случае) потребителя - т.е. того, кто будет фотографию рассматривать. Глаз наш наиболее чувствителен к контрасту в средней части яркостей (вот если выучу зонную теорию Адамса, буду с распальцовкой говорить что-то типа "с Зоны 3 по 6" или где-то так. Только римскими цифрами, конечно ). Т.е обязанность фотографа остаётся той же, как во времена Ле Грея - подобрать фототехнику, композицию, экспозицию и послесъёмочную обработку изображения так, чтобы важные для эстетического восприятия детали оказались в тех самых благословенных зонах. И по-другому никак...
Поэтому Ансель Адамс месяцами торчал в лабораториях Кодака - ему нужно было точно знать, как экспонировать и проявлять плёнку, чтобы делать свои шедевры. Чтобы все тональные переходы, на важных для композиции объектах играли, а те части снимка, которыми он должен был пожертвовать, попали туда, где на них никто не обратит внимания. И сейчас народ внимательно изучает, как работают сенсоры - я давал ссылки на ДПРевью, где люди считают кривые сигнал/шум по всему мыслимому диапазону яркостей, поэтому пишут статьи, на которые я кидал ссылки о том, как в домашних условиях определить, сколько стопов есть у ВАШЕЙ камеры от средне-серого, померянного системой экспозамера, до полного насыщения (пересвета). Всё именно для того - чтобы иметь возможность точно знать, что вылетит в чёрное при снимки и ПП (постпроцессинге), что вылетит в белое, что будет хорошим.

stas27>> Ну вот не понял. Что значит "не ХДР"? В смысле рав не ХДР? В моём понимании - нет, он по определению остаётся в пределах ДД сенсора.
Кот_да_Винчи> И в моем. Ибо рав мы полностью не увидим - нет таких девайсов под руками.

А мне только остаётся в очередной раз повторить, что понятие HDR на ПК никак не связано не только с сенсорами, но даже с фотографией вообще. Какой ДД сенсора в 3D-рендеринге, например? Вся тема HDR крутится только вокруг устройств воспроизведения.

Но я так понял, что пытаться объяснить некоторым это уже бесполезно.

Как и вопросы локальных/нелокальных кривых.

stas27> Чтобы все тональные переходы, на важных для композиции объектах играли, а те части снимка, которыми он должен был пожертвовать, попали туда, где на них никто не обратит внимания.

Ну в общем при простом тонмаппинге как ни крути а часть картинки потеряется. Важно чтобы эта потерянная часть пришлась на сюжетно неважные части снимка...

Balancer> понятие HDR на ПК никак не связано не только с сенсорами, но даже с фотографией вообще. Какой ДД сенсора в 3D-рендеринге, например?

Я так понял, что минусующему на вопрос про HDR в 3D-рендеринге относительно «ДД сенсора» ответить нечего?

• Современная терминология 3D графики
• 3D-графика в играх: развитие и перспективы
• images://hdr site:render.ru

и т.д., и т.п.

Рома, спасибо. Процесс я себе, в общем, представляю, но ты расписал его ясно и подробно.

Balancer> 3.1 Получение HDR-изображения. ...

Т.е. в твоё определение "HDR — это изображение с более чем 8 битами на канал" надо добавить слово "значащими". Ну или какое там выражение будет правильное.

Balancer> под «HDR» сегодня «в быту» понимается ...

Ну да. Ещё одно определение. Ясности в диалогах это не добавляет

Кот_да_Винчи>я рассуждаю в данном случае как электронщик.

Старое доброе компандирование

Клапауций> Т.е. в твоё определение "HDR — это изображение с более чем 8 битами на канал" надо добавить слово "значащими".

Ну да, подразумевается.

Клапауций> Ну да. Ещё одно определение. Ясности в диалогах это не добавляет

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

Когда люди говорят про «HDR» они имеют в виду что-то такое:


И показывают при этом LDR (JPEG), а не собственно, HDR (EXR, RAW, FITS, TIFF/PNG 16/32), из которого он был получен.

Клапауций> Старое доброе компандирование

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

wetware gluck (mine)

stas27>> Чтобы все тональные переходы....
Кот_да_Винчи> Ну в общем при простом тонмаппинге как ни крути а часть картинки потеряется. Важно чтобы эта потерянная часть пришлась на сюжетно неважные части снимка...
Кот_да_Винчи>

А потери будут при любом способе тональной компрессии. Я уже говорил, что математику с физикой не обманешь. И вопрос стоит только в том, где, чем и как ты жертвуешь.

stas27> А потери будут при любом способе тональной компрессии. Я уже говорил, что математику с физикой не обманешь. И вопрос стоит только в том, где, чем и как ты жертвуешь.

Они могут быть меньше. Скажем даже - много меньше. Скажем, если стоит задача минимизировать потери в локальном контрасте, то таки при правильной организации они будут меньше, чем в исходном изображении.

Скажем, определим такую целевую функцию:

d(x,y,a,r) = 1/r**2 * ( diff(x,y,a,r))

где x,y - координаты точки, a, r - полярные координаты другой точки относительно первой, diff(x,y,a,r) - разность между цветовыми значениями первой и второй точки.

Интегрируя по a от 0 до 2*pi и по r от 0 до бесконечности, получаем "локальноквадратичный" контраст по данной точке. Задача - сохранить максимум этого локальноквадратичного контраста, изменяя значения цвета таким образом, чтобы из начальной области определения значений цветности R получить некоторое подмножество R1.

stas27>> А потери будут при любом способе тональной компрессии. Я уже говорил, что математику с физикой не обманешь. И вопрос стоит только в том, где, чем и как ты жертвуешь.
Сергей-4030> Они могут быть меньше. Скажем даже - много меньше. Скажем, если стоит задача минимизировать потери в локальном контрасте, то таки при правильной организации они будут меньше, чем в исходном изображении.
Конечно, так. Тут я полностью согласен с тем же командором - правильный выбор параметров/алгоритмов чрезвычайно важен и определяет результат. Как и с тем, что алгоритмы локальной адаптации тоже сделали не от безделья, а потому, что упёрлись в ограничения алгоритмов глобальных.
Я не согласен с огульным утверждением "без алгоритмов локальной адаптации невозможно конвертировать ХДР в ЛДР и получить приемлемый результат" (по крайней я так понял вышеуказанного собеседника). Можно. И результат часто получится вполне приличным, так что на "эстетическом уровне" будет вопрос - что лучше.

stas27> Я не согласен с огульным утверждением "без алгоритмов локальной адаптации невозможно конвертировать ХДР в ЛДР и получить приемлемый результат" (по крайней я так понял вышеуказанного собеседника). Можно. И результат часто получится вполне приличным

Можно. И результат будет приличным. Только это будет не «HDR» (не будем придираться к терминам — конечно, имеется в виду LDR и так далее), а обычное цифровое фото Которые мы делаем в любой мыльнице.

Или, соответственно, в случае игр или 3D-моделирования — обычный рендеринг. Там тоже расчёты всегда ведутся более чем в 8 бит на канал и всегда есть та или иная (да ещё и настраиваемая обычно) кривая преобразования в экранный LDR.

stas27>> Я не согласен с огульным утверждением ...
Balancer> Можно. ... Только это будет не «HDR» ...

В этом вопросе каждый из нас, как уже ясно, останется при своём мнении . Как и с тем, что разработки из процитированных тобою источники про ХДР, 3-Д и ПиСи никак не связаны с работами типа RADIANCE WWW server (по крайней мере, что они эти наработки не учитывали), что Грег Ворд ничего не знал об Анселе Адамсе, что WIDE DYNAMIC RANGE CAMERA ( Espacenet - An error has occurred ) и последующие работы от VISL не имеют к HDR никакого отношения и по многим другим вопросам

Balancer>> понятие HDR на ПК никак не связано не только с сенсорами, но даже с фотографией вообще. Какой ДД сенсора в 3D-рендеринге, например?
Balancer> Я так понял, что минусующему на вопрос про HDR в 3D-рендеринге относительно «ДД сенсора» ответить нечего?
Balancer> * Современная терминология 3D графики

Сами устройства отображения данных пока что серьезно улучшить нельзя, а отказаться от LDR при расчетах имеет смысл, можно использовать реальные физические величины интенсивности и цвета (или линейно пропорциональные), а на монитор выводить максимум того, что он сможет. Суть представления HDR в использовании значений интенсивности и цвета в реальных физических величинах или линейно пропорциональных и в том, чтобы использовать не целые числа, а числа с плавающей точкой с большой точностью (например, 16 или 32 бита). Это снимет ограничения модели RGB, а динамический диапазон изображения серьезно увеличится.

 

вот тебе и "сенсор"

Kuznets> вот тебе и "сенсор"

Кэп, я не понял, к чему этот очевидный текст. Где ты там увидел «сенсор с ограничениями»?

Kuznets>> вот тебе и "сенсор"
Balancer> Кэп, я не понял, к чему этот очевидный текст. Где ты там увидел «сенсор с ограничениями»?

про "с ограничениями" вопроса не было, ДД "сенсора" 3д = ДД расчетной модели 3д.
ваш КО

Kuznets> про "с ограничениями" вопроса не было, ДД "сенсора" 3д = ДД расчетной модели 3д.
Kuznets> ваш КО

А, то есть ты про то, что в терминах Стаса «HDR» в 3D — это не HDR? («Что значит "не ХДР"? В смысле рав не ХДР? В моём понимании - нет, он по определению остаётся в пределах ДД сенсора»).

А то мне показалось, что ты поддерживаешь его подход к этому вопросу.

Balancer> А, то есть ты про то, что в терминах Стаса «HDR» в 3D — это не HDR?

я не знаю как в 3д реализован этот переход. может с одного прохода, тогда модель должна иметь запас по ДД, может там делается несколько "снимков" с разной интенсивностью источников.

Kuznets> я не знаю как в 3д реализован этот переход.

Обычно просто рассчитывается освещённость каждой точки проекции сцены на экран (или иную проективную матрицу). Не важно, обратной трассировкой или как-то ещё. Освещённость каждой точки — абсолютная, в каких-либо условных единицах сцены. Либо целые числи (16..48 бит на канал), либо плавучка, опять же, не важно. Дальше нужно перевести эту сцену в ограничения цветов экрана. Помню, когда-то извращался, рассчитывая оптимальную палитру для 256 цветов VGA Потом, когда пришёл True Color, настала лафа — просто тупо нормализуешь (не обязательно линейно) каждый канал к значениям 0..255 — и готово! Но прошло ещё несколько лет (я к тому времени от 3D совсем отошёл ) и динамического диапазона для красивого рендеринга стало не хватать. И 3D стали рендерит с HDR-тонмаппингом.

Kuznets> может с одного прохода, тогда модель должна иметь запас по ДД

Да, конечно, результат расчёта модели — с большим запасом берётся. Вот только для обычной фотографии цветовая картина модели — это не данные с сенсора, а реальный мир Ну, или сенсор, но с полным ДД без потерь. Там нет промежуточного преобразования в какой-то узкий ДД, но более широкий, чем на экране.

Kuznets> может там делается несколько "снимков" с разной интенсивностью источников.

Не-а. Сам подумай, где логика? Когда на фотоаппарат делают серию с брекетингом по экспозиции, то борются с недостаточным ДД матрицы, чтобы выжать максимум и получить данные с большим ДД. А в случае 3D у нас эти данные есть изначально. А ты зачем-то предлагаешь их снова промежуточно кастрировать?

Это всё равно, что из полученного их серии снимков HDR сделать… снова серию снимков

Balancer>. Освещённость каждой точки — абсолютная, в каких-либо условных единицах сцены. Либо целые числи (16..48 бит на канал), либо плавучка, опять же, не важно.

Имхо это очень дофига. Даже если бы были такие устройства отображения у глаза все равно мгновенный дд уже, там имхо 10 максимум 12 бит хватит.
То есть без преобразования не обойтись все равно.

Kuznets> То есть без преобразования не обойтись все равно.

Ты меня каким местом читаешь? Естественно, преобразование есть, я же об этом сколько и пишу. Классика — просто полнокадровое преобразование в 8 бит на канал (в том числе с настраиваемой пользователем кривой — яркость/контрастность/гамма). HDR — неоднородный тонмапинг (в т.ч. с выбором разных алгоритмов).