Свежие комментарии

Я вопроса не понял. Но что у вас там есть (пере)насыщение - ну да, понятно. Что туда рисуют не такой градиент как вам хочется - ну да, тут тоже не все так просто....

Ну мне надо было сказать "я слышал". :) А что до не читать переводов -- так жизни не хватит. Будем знать теперь.

Спасибо за разбор проблемы с четким изложением сути.

Подобные эффекты бывают и без зоны вылета.

Я их наблюл давеча, когда в ACR поставил ЦТ 2000K кадру, для которого автобаланс показывал 12500. Сам офигел.

Ай, без насыщения подумал, потом увидел "В зоне вылета"

ну вот во 2-й бете 3-го лайтрума адоба говорит что пофиксила глюки рековери.

пишут так "In the 2010 Process Version, the algorithms for Fill Light and Highlight Recovery have been changed to reduce the possibility of tone inversions."

но что значит "tone inversions", правда, не объясняют.

http://labs.adobe.com/technologies/lightroom3/releasenotes.pdf

У старого C1 (3-й версии) эта проблема была в полный рост (возможно, со своими камерами не было). 4-5-й не пользуюсь, не знаю.

Про выжигание цветов - в целом я согласен. Но возможна ситуация, когда выжжено немного. Ну вот облако в углу кадра - ну пусть оно будет белым и без деталей, но не розовым же.

Но я естественно это все смотрю и чиню по заявкам телезрителей, которые бывают дикими....

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

Это все хреновые кнопки от omron.

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

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

С насыщением части каналов - можно делать highlight recovery.

Ну, мы анализируем всю картинку и делаем некоторые предположения о камере по ней. Дальше уже можно, наверное, вернутся на уровень пикселов -- когда максимумы определены исходя из анализа областей а не отдельных независимых пикселей.
На сколько мои предположения, описанные в предыдущем комментарии, верны надо проверять по боооольшой базе файлов (с разных камер!), для которых с хорошей уверенностью известны те самые максимумы -- посчитать предложенным алгоритмом и сравнить с эталонами.
При этом, ясно что файлы должны быть и по экспозиции очень разные -- в том числе, и технические типа снятой недосвеченной очень белой бумаги, и кадры где облака очень близки к вылету но таки не выбиты, etc.
И, да, такой алгоритм, конечно вполне может вернуть ``а я вот не понял где тут максимум'' (когда его и правда нет) -- и надо понять что делать в такой ситуации.

Внезапно обнаружил, что в Win7 боковое колесо у Revolution красиво скроллит окна в 3D!

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

Ну, для начала, нам надо детектировать "вылет". Это делается путем сравнения с максимумом. Этот максимум может быть built-in в конвертор, или определен для данной конкретной камеры (и для всех ISO).
Built-in может быть посчитан усреднением по многим камерам данной модели, причем тоже разными способоами (максимум, минимум, усреднение).
Еще мы можем, кстати, посчитать по конкретному кадру, но если он недоэкспонирован?

Конкретно в dcraw/LibRaw максимумы вшиты по моделям/классам камер, что и приводит к вышеописанным эффектам. Вот LightZone (из коммерческих конверторов) должна страдать от этого в полный рост, ну и линуксячие *все*.

дальше мы обрезаем результат по уровню максимума,
Какого максимума? 14bit? А почему, кстати? Не правильней ли будет вообще отделять "вылет", обрабатывать его отдельно (не применять к нему ББ, а только масшатбировать до полного 16bit-диапазона, на выходе то мы хотим 16bit Получить), а остальное обрабатываеть как всегда? Какие тут получаются подводные камни?