О процессинге RAW: плавучка или целое

Обработка RAW в плавучке позволяет избавиться от артефактов вылета за диапазон, да и вообще получить более качественную картинку.

Тем интереснее обратные случаи.

Возьмем вот такой вот кадр:

Это D800 с его приколами в светах, вот на света и посмотрим.

Если обработать картинку dcraw (или LibRaw, которая дает побитово такой же процессинг, если автоматическое определение максимума отключить), то в светах в "середине верха кадра" мы увидим такое вот:

Розовый оттенок в светах - это вариация на тему розовых облаков: зеленый канал эта камера обрезает по уровню 15778, красный и синий - по уровню 16383, после баланса белого зеленый оказывается чуть ниже уровня насыщения.

Теперь посмотрим на то же самое, но обработанное в плавучке:

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

Гипотеза о том, что безобразие происходит там, где пересвечены несколько каналов - не проходит проверку. Вот как выглядит это в RawDigger:

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

То есть в проблемной области, и в пятне на центре и на каемках, проблема только в зеленом канале.

Стал разбираться, выяснил разницу:

  • Dcraw/LibRaw:
    1. Первым шагом: делает баланс белого и масштабирует на диапазон 0..65535. При этом, если в результате ББ канал вылетел за 65535, то его обрежут на этом уровне.
    2. Вторым шагом: делает color conversion матричным профилем (из камеры в sRGB) и результат опять обрезает, чтобы влезал в диапазон 0..65535.
  • Моя реализация в плавучке:
    1. Первым шагом: делает баланс белого и масштабирование на 0..65535. Если кто-то вылетел за диапазон - ну и хрен с ним.
    2. Вторым шагом: умножает на ту же матрицу и обрезает диапазон.
За счет разницы в первом шаге, после умножения на матрицу результат (в зеленом канале) или попадал на насыщение, или же был меньше (за счет того, что другие каналы были обрезаны - стали меньше - и при умножении дали меньший вклад). Зеленый меньше лимита - розовые каемки.

При этом, конечно же, вариант без промежуточной обрезки теоретически правильнее (потому что промежуточные результаты обрезать - очевидно что неправильно). Но дает артефакты. И, по всей видимости, артефакты в области пересветов вообще неизбежны (привет ETTR-у) и поступать с ними надо так, как ACR поступает:

1) Или резать нахрен (ACR 7.3, кнопка Default):

2) Или, если света дороги, не пытаться вытащить там какой-то цвет, если хоть один канал обрезан, ничего хорошего не будет, а тащить нейтраль (ACR 7.3, кнопка Auto):
Я не считаю ACR идеалом, но попытка вытащить цвет из областей пересвета - скорее всего бессмысленна, а нейтральные света выглядят сильно лучше разноцветных.

P.S. Цветные каемки на краях бликов во многих случаях могут быть связаны с вышеописанными эффектами, а не с пресловутыми "хроматическими аберрациями оптики".

Comments

Пересветы с ETTR возникают исключительно из-за того, что говнокамеры вместо гистограммы RAW показывают всякий бред.

Пользуйтесь экспонометром - и гистограмма не понадобится.

Зачем нужна гистограмма, которая бесполезна?

Вот и я так думаю.

Я не видел камеры, которая всегда меряет правильно. Я думал это особенности Pentax'а -- периодически на некоторых сценах недодерживать на ступень а то и полторы. Но и поснимав Canon'ом наткнулся на тоже самое. Иногда ВНЕЗАПНО, похоже, они считают что важнее всего мне детали в облаках и не дай бог хотя бы 1 пиксель там пересветить. Тогда как при +1-1.5EV я получаю 0.1% выбитого в облаках и нормальный пейзаж внизу.

А вот это вот "внезапно" оно происходит именно "внезапно" или есть какая-то общая причина (ну, к примеру, полярик)?
И второй вопрос - не было ли у сцены относительно невысокого контраста, так что это "внизу" оказывается во вполне приемлемом месте и вполне тянется, хоть и противно все это?

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

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

На первый вопрос ответа нет. Второй -- да, обычно при этом и клиппинга в тенях нет. Просто облака становятся в 5-6 зонах а всё остальное ниже. Мне как-то это не нравится. Всё же облака в солнечный день на юге -- это не основное (почти всегда) в сюжете.

А мерятся спотметром, делать поправку -- я на слайд так и снимаю. 12 кадров в пол-года, ну или 12 кадров за отпуск. Но на DSLR этой возни очень не хочется, особенно учитывая, что это надо уходить в M, крутить колёса (нельзя одной кнопкой сделать сдвиг)... Если бы был доступ к прошивке и можно было бы, скажем, на кнопку AE-L повесить такое -- "померились спотметром, сдвинулись на запрограммированное число ступеней" -- тогда да. А при текущей эргономики камеры -- это всё крайне неудобно. Быстрее таки глянуть на гистограмму и в тех РЕДКИХ случаях, когда всё плохо, крутануть колесо коррекции.

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

Как это нельзя "одной кнопкой сделать сдвиг"?

Именно ставишь экспоправку -3, меряешься по светам точкой, AEL, перекадрируешь, снимаешь.

Это недостаточно хорошо работает на 5D2 у которого headroom 3.4 ступени, но на большинстве прочих камер, у которых 2.7-3 - работает в самый раз.

А владельцам 5D2 надо просто апгрейдиться на 5D3 у которого сдвиг +-5 ступеней :)

Хм. Я тупой, да.
Надо бы померять headroom и попробовать в следующий раз так.

Проблема в том, что область точки в самих камерах - слишком широкая.

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

Ну вот у меня спотметр одноградусный, а у камеры... Ой. Не нашёл процента кадра у спотметра :(

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

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

"розовые облака" - это брак исходного снимка. Я призываю не путать философии "не навреди" и "сделать из говна конфету".

P.S. "если принять, что общий оттенок серый" - это необоснованное предположение о ситуации перед камерой.

Розовые облака - это не брак снимка, а брак обработки. Ну в том смысле, что увод одного/нескольких каналов в пересвет - это не брак.
Возникает оный брак от неправильного определения максимумов (насыщения) каналов.

Потеря информации до обработки не может быть браком обработки.
Неправильное определение выдержки - это тоже не вина обработки.

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

Да, большинство камер не идут ни в какое сравнение с S5Pro :-(

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

Артефакты изначально присутствуют. Неудивительно, что честная обработка их не убирает.

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

А дальше - возникает проблема правильной обработки этого дела. Ну то есть информация (частично) утеряна, можно дальше резать и ту, что еще не утеряна (ACR, Default), можно что-то придумывать на этом месте.

Артефакты - это то, чего не было перед камерой. Они являются или браком, или творческим замыслом.
P.S. К плёночному фетишизму это тоже относится.

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

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

А с цветными светами - проблема.

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

Ну вот пишут же выше про блики на коже и пересвеченные части неба. И я их понимаю.

>> В тенях вообще все понятно что делать, наливай да пей (шум дави да обесцвечивай оставшееся). <<
вот это, кстати, совершенно не очевидно.
Никоны в с воё время (в кулпиксах) поступали иначе - задирали насыщенность в тенях, чтобы вытащить детали. В целом неплохо получалось.

По-моему, восстанавливать пересвет нужно до умножения на матрицу, и всё будет хорошо.

Как можно восстановить пересвет в зелёном канале?
(sorry, подумал было про "до дебайеризации") :)
В общем, восстановление пересветов не связано напрямую с ББ, с ним связана только конкретная область необходимого клиппинга.

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

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

Главная задача тут, видимо, избежать паразитной хроматики. Можно после шага 2 разложить картинку на яркость и хроматику, например, в YCbCr, это довольно быстро. Затем в пикселах, где хоть один канал ушел в пересвет, отказаться от собственных CbCr и взять их интерполяцией из соседних, оставить лишь собственную яркость. Затем вернуться обратно в RGB.
Но это будет прямо медленно.

Скорость - вопрос второй, пока неинтересно обсуждать.

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

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

Ну, это будет соответствовать поведению нашего зрения, которое вполне себе обесцвечивает яркие света.

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

Применить её к пересветам - другая задача. Можно попытаться восстановить цветовую информацию по значениям на границе, и дальше если есть значения хоть в одном канале, можно восстановить остальные два.

Я писал о том, что нужно сначала восстановить пересвет (не важно, каким образом, да хоть бы везде где есть клиппинг хоть одного канала в белое) и лишь потом умножать на матрицу, а не наоборот.

Тут 2 очевидных псевдонаучных варианта:
1. Посмотреть, как это "решают" различные вендоры (и выбрать то, что наиболее приемлемо для ...).
2. (и это уже БЫЛО!) Делать "предварительное экспонирование" - гарантированно без насыщения ни в одном из каналов - чтобы понять что делать с пересветами (даже во всех каналах (и это НЕ HDR!!!)).

PS. Наплевать, если картинка "уехала" между экспозициями: "II" как-нибудь сопоставит.

Многокадровая работа (включая сюда и два кадра за раз, как в S5Pro) - это отдельная история, хотя и очень интересная.

Но пока вопрос в том, что делать с одним кадром. И ничего лучшего, чем -- а) резать б) если восстанавливать - то обесцвеченное -- я пока не вижу. Экспериментировать надо, да.

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

То же угадывание тона в РПП - вполне полезно.

Разный максимум по каналам автоматически означает, что камера явяется мыльницей, потому что у неё отсуствует настоящий RAW.
(одинаковые зелёные каналы означают, что это именно пародия на фотошоп, а не разные АЦП)

Если вы обратили внимание, то зеленые каналы немножко разные (максимумы - отличаются).

Глобально же - ну домножены у никонов B и R на небольшие константы. Можно даже прикинуть на какие. Ничего хорошего в этом нет, но глобально ничего не испорчено, при желании делится обратно.

Так вроде наоборот - всё логично.

Пересвет - по умолчанию ситуация "неправдоподобия". Если пересвет усиливается в результате преобразований, можно ожидать, что правдоподобия будет ещё меньше.

Более того, подозреваю, что формулы цветовых преобразований начинают очень плохо работать при входных значениях, не попадающих в ОДЗ.

Подскажите, как подружить Sigma DP1x и lib(dc)raw. Как правильно работать с сигмовыми равами что бы на выходе не получалось зелёное нечто?

Только и исключительно - накладывая свой профиль. Самостоятельно построенный.

LibRaw::dcraw_process() вполне осознанно повторяет процессинг имени dcraw.
А dcraw с новыми фовеонами (которые после Sigma SD14 или как ее там) делает примерно ничего: т.е. даже баланс белого не накладывается, применяется некий матричный профиль /кажется, одинаковый для всех этих камер, но лень смотреть/ и куку. От применения баланса белого, впрочем, лучше не станет (проверял путем прикладывания автобаланса)

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

Очень жаль, разочаровываюсь в фовеонах все больше, только и годятся что для ч/б. Хотя и для ч/б не годятся, вот баер без цветофильтров годится. Родной SPP врет настолько, что даже смешно. При 0 значении уншарпа, оный виден невооруженным глазом, про шумодав вообще молчу, он там априори, хотя у хомячков это называется попиксельная сигмовская резкость. Силкипикс ситуацию спасает но не сильно, по шумам не врет, по уншарпу тоже, по цветам - сомнения. Рано я обрадовался либраву с поддержкой dp1x, уберу ка её назад на полку..)

Add new comment