Дмитрий Музалёв

Фокус в том, что на выходе должен получаться не JPEG, конечно, а такой специальный "RAW", не имеющий однозначного визуального отображения. Но при этом задача получения обычного снимка из такого промежуточного формата выглядит совершенно простой: выдержку можно будет устанавливать в конвертере! Единственное допущение, которое нужно принять, это то, что сигнал в пикселе накапливается линейно во времени. Эффекты HDR, разумеется, тоже можно получить. Кстати, у меня есть непроверенное пока предположение, что тот противоестественный ужас-ужас, который у нас ассоциируется со словом "HDR", является не родовой чертой этой технологии, а следствием ее бездумного употребления. Т.е. это преимущественно манифестации радостей от открывшихся возможностей. Берутся сюжеты с гигантским перепадом освещенности, и выкручиваются так, чтобы везде было всё проработно. А 8 бит на выходе никто не отменял. В результате иммеем тонально бедные картинки с неестественным распределением яркостей.

HDR в тырнет-картинках это совсем не HDR.
Такую штуку, как High Dynamic Range Image монитор отобразить не может.

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

www.fcenter.ru

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

да в общем самое главное - использовать метод по назначению и не увлекаться.

1. Использовать фото, которое действительно нуждается в обработке - яркий свет, тёмные тени
2. Не тянуть из одного кадра - детали не появятся. нужно использовать отдельные кадры с разной экспозицией
3. Подтянуть тени, приглушить свет и не раскрашивать фото в цвета детских фломастеров.

Софт - Photomatrix, Photoshop

А нет ли у Вас под рукой примеров удачного использования этой технологии в фотографии (не прикладной и без компьютерной графики)?

"не прикладной и без компьютерной графики" - это как? =)


Вот пример удачной хдр-обработки
www.viewfinder.ru
ну или вот тут тоже ничего
foto-else.livejournal.com

З.Ы.
это на мой вгляд

Господь с Вами, это ж "аткрытачки"...

ну я не выставлял претензий на художественную ценность примеров :) Это вообще вопрос при обсуждении технологии "боковой".

ну что ж поделать =)
как-то не встречал я ХДР-ные картинки, которые бы имитировали плёнку+градиентный фильтр (или полярик)

Я имел в виду, что без нарисованных объектов и планов кадре. Примеры - да, выглядят вполне человечно. Не считая ореолов на контрастных границах, но это мелкая техническая недоработка, с которой наверняка можно было побороться. Другое дело - есть ощущение, что такие результаты можно было получить и без ХДР.

Да. На плёнку =)

Ну я такую тонкость на глаз не отличу. Суть проблемы в том, как сжать до 8-битного формата картинку заведомо и существенно не помещающуюся по диапазону яркостей в стандартный RGB. И сжать так, чтобы она продолжала глазом восприниматься как естественная. Я почему так пристаю назойливо: в тексте по Вашей ссылке что-то такое явно наклевывалось там, где говорилось, что стандартный RGB в определенном диапазоне избыточен, т.к. передает больше градаций, чем способен различить глаз. Если за эту ниточку ухватиться, можно сделать вывод, за счет какого сжатия тонов в каком диапазоне можно производить преобразование без визуальных потерь. Отсюда же можно рассчитать, насколько реально может быть расширен диапазон (с учетом необходимости последующего перевода в RGB). Только у меня для таких рассчетов квалификации не хватит :(

суть хдр-ных жпегов в том, чтобы вытянуть детали из шибко тёмных или шибко светлых участков, а не в градациях яркости.
визуально не отличить цвет rgb(20,20,20) от rgb(20,20,21), так что в этом плане у мониторов ещё запас большой.

хдр в фотографии помогает в двух случаях:
1. Если динамический диапазон маловат (цифра)
2. Фотограф не умеет выставлять правильную экспозицию

Во-во, было бы интересно.

Ага. Только считывать сигнал нужно минимум 1000 раз в секунду, что даёт десятикратное увеличение результирующего файла при выдержке 1/100 с. и поток в полгигабита/секунду. Не говоря уже про то что ежели возжелать HDR из этого получить, то выдержка окажется разной для разных объектов, движущиеся объекты могут быть недовольны. Я уж не говорю, что нынешняя технология считывания такого попросту недопускает.

"нынешняя технология считывания такого попросту недопускает" - думаю, вопрос в принципе разрешим. есть же матрицы для видеосъемки. К тому же частота опроса может быть в большинстве случаев ниже: думаю, ее можно попробовать вычислять в каждом конкретном случае на основе данных мультисегментного замера. В качестве первого шага можно было бы прикрутить такую фичу для длинных выдержек.

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

"движущиеся объекты могут быть недовольны" - это хорошее замечание :) Так навскидку: если максимальная для кадра выдержка окажется короткая, то ничего страшного. А если длинная, то скорее всего они и при стандартной съемке довольны не останутся. Но некая граничная зона с неприятным эффектом, наверное, неизбежна, да.

"нынешняя технология" предполагает, грубо говоря, забрать из светочувствительного элемента заряд и посмотреть сколько там его. именно это делают и матрицы для видеосъёмки.

как Вы думаете можно ли сжать последовательность 101100111000111100001111100000...? (правильный ответ - нельзя)

по первому вопросу: этот подход не противоречит предлагаемому. Вопрос только в том, что делать, после того, как посмотрели.

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

Вспомнился мне алгоритм с переменной длинной кода. Смысл его в том, что выявляются наиболее часто встречающиеся последовательности, и кодируются самым коротким коротким кодом. Различение кодов в итоговой последовательности обеспечивается тем, что длинные коды не имеют право иметь в начале значения с использованным коротким.

В нашем случае это выглядит так.
Исходная последовательность:
101100111000111100001111100000

Таблица перекодировки:
11 - 0
10 - 10
00 - 11

Сжатая последовательность:
100110101100111100101111

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

Короче, хотел бы, чтобы Вы прокомментировали, на чем основана Ваша уверенность?