О ДД и ББ в тенях

Предыдущая моя заметка О линейности в тенях как-то не вызвала того эффекта, который я ожидал. Давайте усугубим.

Представим себе некое серое тело разной яркости, снимаемое при некоем (примерно дневном) балансе белого на 5D Mark II.

Вот по уровню "среднесерого" имеем отклики (R-G-B) равные 435-1035-650. Применяя коэффициенты баланса белого 2.38-1-1.59 (я везде немножко округляю), получим серое в среднем тоне: 1035-1035-1035.

Теперь идем на 6 стопов в тени (у нас же камера с 12-ю стопами ДД по DXO Mark и с 9-ю стопами Tonal Range по тем же данным, можем себе позволить), снимаем то же серое тело.

За счет нелинейности стопов и разной чувствительности каналов накопленная за 6 стопов нелинейность будет разной.

Получим отсчеты R-G-B: 5.18-9.68-6.59 (это усреднено по большим плашкам).

Наложим тот же баланс белого, что и в полутонах. Получаем: 12.33-9.68-10.49. Был серый, стал "темно-розовый".

Пока этот темно-розовый остается в глубоких тенях, на 6 стопов ниже среднего тона и ~9 стопов ниже белого, хрен бы с ним. Это и на мониторе не увидишь и, тем более, не напечатаешь.

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

На картинке вверху иллюстрация, полученная следующим способом:

  • Справа: в "линейном-sRGB" пространстве (primaries от sRGB, гамма 1) нижняя половинка 9-9-9, верхняя - 12-9-10. После конверсии к обычному sRGB оно стало L=22 т.е. третьей зоной по Адамсу.
  • Копия правой половинки была поднята (в линейном же пространстве) еще на три стопа и стала L=60 т.е. чуть выше пятой зоны.
  • Дальше конвертируем в обычный sRGB и размещаем картинку в блоге.

Теперь вернемся к разговору о профилях камеры:

  • Хороший профиль должен (бы) это безобразие скомпенсировать. То есть привести серую шкалу, хоть на среднем тоне, хоть на -6eV к серому же виду.
  • Но. Разбаланс чувствительности каналов очень разный при разном освещении. При свете лампы накаливания наиболее проблемным станет синий канал, причем проблема той же силы возникнет на пару стопов раньше.
  • Кроме того, при повышении ISO проблема должна начать вылезать раньше (ближе к среднему тону). Мне так кажется, я пока не проверял.
Другими словами, если отдавать проблему на откуп профилю камеры, то профиль должен быть на каждое ISO и каждый баланс белого свой. И применяться, кстати, до баланса белого, чего ни один известный мне конвертор не делает.

Впрочем, если относиться к камере как к очень хорошему слайду: 3.5 стопа вверх от среднего, 3.5 стопа вниз и никогда не тянуть тени (а если надо снизить контраст, то снижать его при съемке), то и проблемы на низких ISO (100-400) быть не должно.

Такие дела.

Comments

Очень интересно, спасибо. То-то я заметил, что при вытягивании теней цвета всегда расползаются черти куда. Даже на ISO100. Теперь понятно почему.

Ага-ага.
И при лампах накаливания поползет в другую сторону.

А уж что проиходит при концертном свете...

При концертном (сильно цветном) свете нет баланса белого.

Т.е. если серый - покраснеет, а лица - позеленеют (в синем прожекторе) - то это так и надо.

Это-то понятно, другое дело, что после конвертера оно покраснеет-посинеет не так как было.

И что делать с этим, даже при наличии хорошей визуальной памяти -- непонятно.

Забить.

Потому что память есть на цвет лица, цвет листвы, небо и нейтраль.

Проблема применения профиля до баланса белого и при том к линейному файлу во многом упирается в точность CMM. При том, что коррекция нелинейности матричным профилем получается с достаточно большим трудом, нужен LUT. Тут в традиционных CMM начинает ползти шум. Лекарство оказывается хуже болезни. Если же прибегнуть к пред-линеаризации каналов при открытии raw-файла, дело упрощается и значительную часть линейности баланса белого удается вернуть на место - почти до точки, ниже которой нелинейность определяется шумами в raw.

В-общем, ехать надо с этим, кажется, что-то можно делать. Но что - не понимаю пока.

Да... круто.

Вот теперь всё адекватно разжёвано, спасибо :)
А то я предыдущие заметки прочитал, и до конца не просёк что к чему.

Если "никогда не тянуть тени", то как же тот факт, что "тени тянутся лучше светов" (в ситуации, когда контрастный сюжет) и как быть в ситуации, когда тени однозначно придется тянуть? (мне казалось, лучше темноватый кадр, но потом вытянуть, чем нормальный по экспозиции, но размытый из-за длинной выдержки...) Опять "из двух зол меньшее"?

Света просто "тупо обрезаются". То есть выше 14740 (к примеру) - просто ничего не бывает. Даже шума нет, ровная полка, тянуть нечего.

В тенях места гораздо больше, конечно. То есть ~3.5 стопа там просто есть без вопросов. Ну и дальше что-то есть, можно что-то доставать оттуда, но с проблемами.

По-моему не очень хорошо

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

float не избавит от проблемы. Он ее облегчит (за счет отсутствия округления).

Эти самые отрицательные числа - это такая штука странная. Вот допустим у пикселя яркость -0.8 (вклад шума отрицательный), а у другого +1.2. Как это дальше интерпретировать? Если сместить ноль (что можно и в целых сделать), там линейность порушится в другую сторону

Проблема актуальна для ночных съёмок при больших ISO.

Я делал так: добавлял постоянную составляющую в режиме 32 бита, переводил в 16, удадял шум, переводил в 32, потом вычитал постоянную составляющую.

"Удалял шум" - это шумопонижение какое-то?

Да, примерно так и надо, наверное. Можно, вероятно, просто черный не вычитать (если кэнон), но тогда шумодав должен знать, что сигнал не Ax, а Ax+b (и b - известно приблизительно и по каналам разное)

мне этот вариант нравится

Осталось сделать такой шумодав.

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

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

разбаланс вызывается нелинейностью относительно освещения, какая разница от чего освещенность прыгает?

Баланс белого достигается умножением.

Изначально каналы содержат одинаковый шум, но после умножения шум тоже увеличивается.

проблема шума -- проблема шума.
шум в тенях -- это шум в тенях.
цветной шум в тенях -- это цветной шум в тенях.

борьба с шумом -- это борьба с шумом.

ну причем тут разная нелинейность каналов?
была разная, стала одинаковая и линейная. теперь можно балансировать.

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

ну так компенсируй.

типа 10 в исходном синем это всегда 15 (или 5? лень разбираться куда загибается) в линеарезированном синем.

а 10 в красном -- это 12 (8) в линеаризированном красном.

ну а потом с линеаризированными данными уже и работать, баланс белого, шум и т.п.

Идея не так плоха, но не выйдет же.

Точнее говоря, если сначала удалить шум, потом наложить такую штуку - может помочь

А так - нет, тут никакой фильтр не восстановит линейность.

э, какой фильтр? у нас есть замеренная таблица, которая табличным преобразованием (поканальным) на raw каналы делает их (raw каналы) линейными.

после этого -- убирай шум, балансируй белое (в правильном порядке, не знаю каком)

Да, верно, но это одна таблица.

Есть подозрение, что она будет заметно плавать от ISO (что тоже можно сделать, сняв тесты), от температуры, от экземпляра камеры.

первые два предположения ты можешь сейчас проверить или опровергнуть.

второе -- сложнее, нужен еще кто-то. но разве результат этого не стоит?
ну и нам же надо не в абсольтные значения попадать, а форму компенсировать.

потому первое и последнее скорее всего рояли играть не будет.
кстати, заодно косинус можно компенсировать, или уже?

(вздыхая) я попробую объяснить.

По сути, вы прибавляете к сигналу случайную величину. Если сумма получается меньше нуля - обнуляете.

Можно посчитать, какие возникают средние искажения, если сравнивать средние значения по площадке. Но это будет верно только для средних значений.

Восстановить обратно сигнал нельзя, он и так "самый точный". Ни одно применение функции l'=f(l) по пикселям ситуацию не улучишит сильно.

причем тут точнее?
замер показал, что сенсор -- не линейный. поэтому просто востанавливаем линейность. вроде как все последующие алгоритмы расчитывают на линейные данные, а не с загибами?

Не-не.
Сенсор "сам по себе" - скорее всего достаточно линеен.

Проблема именно в сложении (точнее, последующем вычитании) темнового тока (dark current), шума и, собственно, сигнала. Да еще и в целых числах.

Во всяком случае, сочетание этих эффектов в эмуляторе (в экселе) дает очень похожую картинку. См. каменты в предыдущем посте.

сегодня голова не работает -- смотеть не буду.
ну т.е. получается, что от экземпляра это не зависит, от температуры тоже, исо можно учесть. ну и от модели камеры тоже зависимости практически нет. красота?

Шум - зависит от температуры (от экземпляра камеры - возможно тоже).
И, кстати, от длительности выдержки тоже зависит.

Dark current - зависит от ISO. И, возможно, от экземпляра камеры.

От дисперсии шума и (правильного) значения - зависит количество пикселей, которые упадут "ниже нуля"

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

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

На рамке - сумма dark current (т.е. независимой ни от чего псевдослучайной компоненты) и прочих шумов (время- и температуро- зависимой).

Но вообще, идея использовать с рамки и дисперсию тоже - мне нравится, хотя рамка бывает очень маленькая.

ну так дисперсия именно этой суммы и влияет, или я не так понял?

ну хоть маленькая, пять старушек -- рубль.

Да, конечно.

Там вопрос в том, насколько хорошо удастся оценить вклад. Но покопать в эту сторону точно можно.

У вас нелинейная, прежде всего, обработка. Из за этого все и проблемы.

Оценить размер дисперсии по черной рамке, как Слава предлагает, а потом это знание использовать для оценки "сдвига" черного - это хорошая идея.

Обработка должна быть дюже хитрой.

Скажем, отфильтровать на низкие и высокие частоты, потом низкие пропустить через f^(-1), потом обратно сложить.

Как-то так если

Я про "нелинейность относительно освещения" не понял что имелось в виду.

У тебя пара микрофонов (типа, стерео), на один надета подушка. Дальше этот разбаланс компенсируется цифровым умножением после АЦП. Если вся конструкция не вполне линейна, то будет плохо. У ежиков то же самое.

так прежде чем умножать надо значения заменить на LinLeft[ADC], LinRight[ADC].

Баланс белого достигается умножением.

Изначально каналы содержат одинаковый шум, но после умножения шум тоже увеличивается.

Add new comment