Провел эксперимент со своим epson stylus r1900. Привык печатать на нем на 300 ppi. Оказалось, что данное разрешение выдает крайне неприглядный результат. Понравились результаты на 240 и на 250. В первом случае получал выбитые светлые полосы, во втором выбитые темные полосы. Решил подобрать удачное промежуточное значение, в результате разрешение 246 оказалось идеальным. Ни намека на полосы, высокая четкость. Неожиданное число.
Точно "долгим" способом и не получить пожалуй. У меня в итоге вышло 1.054688 1.000000 1.069336 1.000000. Не знаю насколько допустимо, но тоже доволен хотя бы таким результатом.
для 400D была та же ерунда
в итоге приблизительно установил "долгим" способом (на самом деле от силы на 5 мин делов). не точно 1.000, но мне пока и полученного результата хватит
dcrawMS -w -v -h IMG_2619.CR2
Loading Canon EOS 450D image from IMG_2619.CR2 ...
Scaling with darkness 1023, saturation 14605, and
multipliers 2.137695 1.000000 1.393555 1.000000
Converting to sRGB colorspace...
Writing data to IMG_2619.ppm ...
Хорошо, можно рассматривать зелёные каналы как два, но с меньшей плотностью и худшим разрешением каждый. В этом случае они вообще не отличаются от красного и синего. Понятно, что сигналы в каналах разного цвета разные. Тогда естественно, что в разных каналах будут разные отношения сигнала в канале к шуму в канале. Это банально и обсуждать тут нечего. Если дело только в этом, то отношение общего сигнала к шуму в одном канале должно быть одинаково для всех каналов. Так и абсолютное значение шумов во всех каналах должно быть одинаковым. Дробовых шумов в полупроводниках не видно, это не ФЭУ, значит и электрические шумы в каналах не различаются и не зависят от фильтров перед ними.
Вы сами привели случай (лампы накаливания), когда сигнал в красном канале больше сигнала в зелёном. Это значит, что применение пурпурного фильтра ограничено только случаями, когда зелёный сигнал превалирует и над красным и над синим. Т.е. для каждого спектрального распределения излучения освещения желателен свой выравнивающий фильтр, а создатели матрицы ориентируются на некоторое статистическое спектральное распределение или те распределения, которые могут встречаться. Я часто снимаю закаты и восходы, особенно в горах. Для них характерны как раз пурпурные оттенки (комбинация красных солнечных лучей прошедших толстый слой атмосферы и синего света рассеянного чистым небом).
Зеленых каналов два - и они рассматриваются по отдельности, тем более что в некоторых камерах два разных зеленых канала.
А разный уровень сигнал/шум по той тривиальной причине, что разный уровень сигнала. А разный уровень сигнала - по той причине, что
а) плотность красного фильтра большая, иначе будут проблемы при искусственном освещении, где красной составляющей очень много.
б) чувствительность кремния к синему - маленькая.
Со второй проблемой можно бороться, уменьшая чувствительность (повышая плотность фильтров) красного и зеленого каналов, но это ведет к общему уменьшению сигнала (т.е. росту шумов), что тоже ничего хорошего.
А почему разные каналы шумят пo-разному? Ведь электрически они не отличаются. Различаются числом пикселей (плотность зелёных в 2 раза выше). Значит, физическое разрешение в подрешётке красных и синих - ниже. Дальше всё определяется механизмом интерполяции. Если он вытягивает разрешение красного и синего, то вытягивает и их шумы. В телевидении разделены яркостный канал и цветностные. Причём, яркостный значительно шире по частотной полосе, т.е. все мелкие детали там, а цвета они не имеют. Ничего, глаз глотает.
Есть случаи, когда пурпурный фильтр не годится. Так на закате ограничение может наступить в красных лучах раньше, чем в зелёных. А если в кадре синее небо, но нет облаков или снега, то ограничение может быть и в синем. При передержке неба оно частенько "зеленеет" (синий обрезан), прежде чем совсем обесцветиться.
Спасибо. Немного странно, что процессор более сложную операцию делает быстрее, чем простую. Но вполне может быть, они заточены на вполне определённый набор операций. Если доберусь когда-нибудь в программировании до этого места, то объясню точно. :)
1.) У фильтров тоже есть недостатки. Они редко имеют то же оптическое качество, что и хороший объектив. 3 фильтра это уже 6 новых оптических поверхностей. Если это исключительно шнайдеровские (B&W) фильтры с наилучшим многослойным просветлением, то их отрицательное влияние будет меньше, но суммарная цена приблизится к стоимости объектива.
2.) Полярик искажает цвет неба, причём только перпендикулярно солнечным лучам (по лучам и против небо не меняется). Пятнистость неба сильно заметна на широком угле и панорамах. Исправлять потом трудно.
3.) Вместо бленды лучше поставить камеру на штатив и автоспуск, а самому стать в паре метров от неё, закрыв солнце рукой (тень от руки ложится на переднюю линзу). Так можно поступать даже когда солнце в кадре. Но тогда придётся комбинировать 2 кадра - с рукой и без.
4.) Два кадра с эксповилкой можно объединять не только маской прозрачности. Чтобы избежать каши в движущейся листве, можно воспользоваться функцией Blending, которую фотошоп использует для объединения кадров панорам. Там очень умно проводится граница между кадрами, так, что важные предметы не разрезаются.
Увы, там ничего лучше не стало. Цветовые профили не используются при отображении рабочего стола, окошек и иконок на нём. Некоторые инструменты, вроде встроенного просмотрщика изображений, вроде, пытается использовать цветовой менеджмент, но криво. Из браузеров прекрасно поддерживает профили Огнелис. Там я использую для этого специальный плагин.
Ну смотрите что получается:
- 16-битных целых, в-общем, маловато, не хватает точности при многостадийной обработке. 16-битных плавающих хватило бы (при логарифмическом кодировании), но процессор такие данные не поддерживает, а софтверная поддержка будет медленной.
- 24-битных целых процессор не поддерживает, см. выше про библиотеки.
- 32-битных целых и 32-битных float - достаточно по точности.
Только вот с 32-битными float современный процессор (если его правильно использовать) работает быстрее, чем с 32-битными целыми.
Вывод: надо работать в плавучке. Никакого выигрыша по скорости/памяти от 32-битных целых нет, а проигрыш (в виде большой относительной ошибки в районе нуля) - есть.
ACR и Bridge очень удобны, когда надо перелопатить кучу фотографий с одного события, свадьбы например. Делать все очень "правильно" смысла нет, тот набор, что предлагает ACR сейчас очень неплох и почти что достаточен. Да, это поток, но за правильную красоту никто не будет платить. Для единичных файлов, вроде пейзажа -- да, тут можно себе позволить потратить время.
Линейные, это полученные аффинным преобразованием исходной системы координат. В данном случае, помножением на матрицу. То что зрение не линейно, не мешает производить колориметрические вычисления и получать точные результаты. В колориметрических системах RGB и XYZ сигналы складываются линейно. Собственно говоря, колориметрия основана на кривых сложения стандартного колориметрического наблюдателя.
А знаете, возразить я сейчас не сумею. Вы ссылаетесь на код на С, а как раз его синтаксисом я не владею. Быстрые вещи писал на Паскале, используя ассемблерные вставки для часто исполняемых функций. В принципе, это проверяется. В код можно поставить таймер, а проблемные участки для большей точности ещё и в цикл загнать. Обычно оптимизировал скорость так.
Отвлекаясь от возможностей конкретных процессоров, существует оптимальная разрядность для любых вычислений. Избыточная точность - это лишние вычисления. Плавающая точка это и есть избыточное решение на все случаи жизни. Хотя, кажется и в С есть выбор разрядности для плавающей точки. Но малые разрядности всё равно обрабатываются в то же число тактов, что и большие, естественные для процессора.
Недавно меня попросили рассказать про две вещи - Adobe Bridge и Adobe Camera RAW. А я не пользуюсь ни тем ни другим. Ну не нравятся они мне, конкретные причины перечислять долго. Если конвертером пользовался, то Бриджем - никогда. Почитал книжку Скотта Келби справочник по фотошопу. Написано очень живо и интересно, но чем дольше читал, тем больше приходил в недоумение. Выходит, что конвертер пытается подменить собой фотошоп, но делает это непрофессионально, на уровне, который не требует от пользователя серьёзных знаний. Вот как в предыдущем сообщении - мечта подвигать движки и получить "красиво". Получится субъективность. Маргулис с другого полюса. Чтобы он поменял хоть что-то, он должен точно знать, что и зачем он делает. Его позиция мне импонирует. А его классификация назначения конвертеров более чем актуальна.
Интересно пожелание редактирования яркости отдельно от цветности. Разумеется, демозаику придётся делать в цветах сенсоров, а вот всё остальное можно делать и в других цветовых пространствах. В принципе, яркость и цветность разделены в системе LAB. Но для обработки она не очень удобна. Получается довольно странная ситуация - обработка ведётся либо в аппаратных цветах RGB, (все привыкли, а ведь это страшно неестественно), либо в LAB (довольно сложна для расчётов). А, что, в промежутке ничего нет? Выводить на экран надо RGB в соответствии с профилем монитора, печатать с профилем принтера и чернил, а сохранять в sRGB или Адобе RGB. Раз так часто надо пересчитывать цвет, то почему бы не обрабатывать в пространстве, где светлота отложена только по одной из осей координат. Годится и колориметрическая система XYZ (светлота по Y), но цветность можно сделать и более интуитивно понятной. При этом система получается линейной относительно RGB, и не такой сложной и неестественной как LAB. Надо подумать.
Canon 7D, установка по белому кадру:
multipliers 1.000000 1.000978 1.000978 1.000978
Спасибо , посмотрел , думаю Вы правы - фильтр показал свою эффективность в практических тестах .
Благодарю за статью , все доходчиво и понятно .
У меня на D700 не получается.
Кто подскажет что сделать?
И что значит "вычитание нейтральной точки"
Заранее благодарю и с Наступающим всех)
Провел эксперимент со своим epson stylus r1900. Привык печатать на нем на 300 ppi. Оказалось, что данное разрешение выдает крайне неприглядный результат. Понравились результаты на 240 и на 250. В первом случае получал выбитые светлые полосы, во втором выбитые темные полосы. Решил подобрать удачное промежуточное значение, в результате разрешение 246 оказалось идеальным. Ни намека на полосы, высокая четкость. Неожиданное число.
Точно "долгим" способом и не получить пожалуй. У меня в итоге вышло 1.054688 1.000000 1.069336 1.000000. Не знаю насколько допустимо, но тоже доволен хотя бы таким результатом.
для 400D была та же ерунда
в итоге приблизительно установил "долгим" способом (на самом деле от силы на 5 мин делов). не точно 1.000, но мне пока и полученного результата хватит
dcrawMS -w -v -h IMG_2619.CR2
Loading Canon EOS 450D image from IMG_2619.CR2 ...
Scaling with darkness 1023, saturation 14605, and
multipliers 2.137695 1.000000 1.393555 1.000000
Converting to sRGB colorspace...
Writing data to IMG_2619.ppm ...
Во как
Спасибо, поправил.
Там вроде вторая редакция выложена, вполне возможно, что и часть моих замечаний тоже устарела.
Ссылочки устарели на сайте Шадрина: http://shadrin.rudtp.ru/Personal/Shadrin_Margulis_my.htm
Камера (для которой работает крышечка или засветка) - смотрит в значения в файле, а не в метаданные.
а нельзя просто поправить коэффициенты в raw файле 1 1 1 1 и скормить его камере?
- 5D MarkII, дневной свет
- он же, лампы накаливания
А шумовая составляющая (кроме "фотонного" пуассоновского шума) - примерно одинаковая.Хорошо, можно рассматривать зелёные каналы как два, но с меньшей плотностью и худшим разрешением каждый. В этом случае они вообще не отличаются от красного и синего. Понятно, что сигналы в каналах разного цвета разные. Тогда естественно, что в разных каналах будут разные отношения сигнала в канале к шуму в канале. Это банально и обсуждать тут нечего. Если дело только в этом, то отношение общего сигнала к шуму в одном канале должно быть одинаково для всех каналов. Так и абсолютное значение шумов во всех каналах должно быть одинаковым. Дробовых шумов в полупроводниках не видно, это не ФЭУ, значит и электрические шумы в каналах не различаются и не зависят от фильтров перед ними.
Вы сами привели случай (лампы накаливания), когда сигнал в красном канале больше сигнала в зелёном. Это значит, что применение пурпурного фильтра ограничено только случаями, когда зелёный сигнал превалирует и над красным и над синим. Т.е. для каждого спектрального распределения излучения освещения желателен свой выравнивающий фильтр, а создатели матрицы ориентируются на некоторое статистическое спектральное распределение или те распределения, которые могут встречаться. Я часто снимаю закаты и восходы, особенно в горах. Для них характерны как раз пурпурные оттенки (комбинация красных солнечных лучей прошедших толстый слой атмосферы и синего света рассеянного чистым небом).
Зеленых каналов два - и они рассматриваются по отдельности, тем более что в некоторых камерах два разных зеленых канала.
А разный уровень сигнал/шум по той тривиальной причине, что разный уровень сигнала. А разный уровень сигнала - по той причине, что
а) плотность красного фильтра большая, иначе будут проблемы при искусственном освещении, где красной составляющей очень много.
б) чувствительность кремния к синему - маленькая.
Со второй проблемой можно бороться, уменьшая чувствительность (повышая плотность фильтров) красного и зеленого каналов, но это ведет к общему уменьшению сигнала (т.е. росту шумов), что тоже ничего хорошего.
А почему разные каналы шумят пo-разному? Ведь электрически они не отличаются. Различаются числом пикселей (плотность зелёных в 2 раза выше). Значит, физическое разрешение в подрешётке красных и синих - ниже. Дальше всё определяется механизмом интерполяции. Если он вытягивает разрешение красного и синего, то вытягивает и их шумы. В телевидении разделены яркостный канал и цветностные. Причём, яркостный значительно шире по частотной полосе, т.е. все мелкие детали там, а цвета они не имеют. Ничего, глаз глотает.
Есть случаи, когда пурпурный фильтр не годится. Так на закате ограничение может наступить в красных лучах раньше, чем в зелёных. А если в кадре синее небо, но нет облаков или снега, то ограничение может быть и в синем. При передержке неба оно частенько "зеленеет" (синий обрезан), прежде чем совсем обесцветиться.
Спасибо. Немного странно, что процессор более сложную операцию делает быстрее, чем простую. Но вполне может быть, они заточены на вполне определённый набор операций. Если доберусь когда-нибудь в программировании до этого места, то объясню точно. :)
1.) У фильтров тоже есть недостатки. Они редко имеют то же оптическое качество, что и хороший объектив. 3 фильтра это уже 6 новых оптических поверхностей. Если это исключительно шнайдеровские (B&W) фильтры с наилучшим многослойным просветлением, то их отрицательное влияние будет меньше, но суммарная цена приблизится к стоимости объектива.
2.) Полярик искажает цвет неба, причём только перпендикулярно солнечным лучам (по лучам и против небо не меняется). Пятнистость неба сильно заметна на широком угле и панорамах. Исправлять потом трудно.
3.) Вместо бленды лучше поставить камеру на штатив и автоспуск, а самому стать в паре метров от неё, закрыв солнце рукой (тень от руки ложится на переднюю линзу). Так можно поступать даже когда солнце в кадре. Но тогда придётся комбинировать 2 кадра - с рукой и без.
4.) Два кадра с эксповилкой можно объединять не только маской прозрачности. Чтобы избежать каши в движущейся листве, можно воспользоваться функцией Blending, которую фотошоп использует для объединения кадров панорам. Там очень умно проводится граница между кадрами, так, что важные предметы не разрезаются.
Увы, там ничего лучше не стало. Цветовые профили не используются при отображении рабочего стола, окошек и иконок на нём. Некоторые инструменты, вроде встроенного просмотрщика изображений, вроде, пытается использовать цветовой менеджмент, но криво. Из браузеров прекрасно поддерживает профили Огнелис. Там я использую для этого специальный плагин.
Ну смотрите что получается:
- 16-битных целых, в-общем, маловато, не хватает точности при многостадийной обработке. 16-битных плавающих хватило бы (при логарифмическом кодировании), но процессор такие данные не поддерживает, а софтверная поддержка будет медленной.
- 24-битных целых процессор не поддерживает, см. выше про библиотеки.
- 32-битных целых и 32-битных float - достаточно по точности.
Только вот с 32-битными float современный процессор (если его правильно использовать) работает быстрее, чем с 32-битными целыми.
Вывод: надо работать в плавучке. Никакого выигрыша по скорости/памяти от 32-битных целых нет, а проигрыш (в виде большой относительной ошибки в районе нуля) - есть.
Вычислять - можно. Редактировать неудобно, вспомните о кривых в RGB - ужас же.
ACR и Bridge очень удобны, когда надо перелопатить кучу фотографий с одного события, свадьбы например. Делать все очень "правильно" смысла нет, тот набор, что предлагает ACR сейчас очень неплох и почти что достаточен. Да, это поток, но за правильную красоту никто не будет платить. Для единичных файлов, вроде пейзажа -- да, тут можно себе позволить потратить время.
Линейные, это полученные аффинным преобразованием исходной системы координат. В данном случае, помножением на матрицу. То что зрение не линейно, не мешает производить колориметрические вычисления и получать точные результаты. В колориметрических системах RGB и XYZ сигналы складываются линейно. Собственно говоря, колориметрия основана на кривых сложения стандартного колориметрического наблюдателя.
А знаете, возразить я сейчас не сумею. Вы ссылаетесь на код на С, а как раз его синтаксисом я не владею. Быстрые вещи писал на Паскале, используя ассемблерные вставки для часто исполняемых функций. В принципе, это проверяется. В код можно поставить таймер, а проблемные участки для большей точности ещё и в цикл загнать. Обычно оптимизировал скорость так.
Отвлекаясь от возможностей конкретных процессоров, существует оптимальная разрядность для любых вычислений. Избыточная точность - это лишние вычисления. Плавающая точка это и есть избыточное решение на все случаи жизни. Хотя, кажется и в С есть выбор разрядности для плавающей точки. Но малые разрядности всё равно обрабатываются в то же число тактов, что и большие, естественные для процессора.
Системы, линейные относительно RGB - будут нелинейными относительно зрения.
В чем и проблема.
Недавно меня попросили рассказать про две вещи - Adobe Bridge и Adobe Camera RAW. А я не пользуюсь ни тем ни другим. Ну не нравятся они мне, конкретные причины перечислять долго. Если конвертером пользовался, то Бриджем - никогда. Почитал книжку Скотта Келби справочник по фотошопу. Написано очень живо и интересно, но чем дольше читал, тем больше приходил в недоумение. Выходит, что конвертер пытается подменить собой фотошоп, но делает это непрофессионально, на уровне, который не требует от пользователя серьёзных знаний. Вот как в предыдущем сообщении - мечта подвигать движки и получить "красиво". Получится субъективность. Маргулис с другого полюса. Чтобы он поменял хоть что-то, он должен точно знать, что и зачем он делает. Его позиция мне импонирует. А его классификация назначения конвертеров более чем актуальна.
Интересно пожелание редактирования яркости отдельно от цветности. Разумеется, демозаику придётся делать в цветах сенсоров, а вот всё остальное можно делать и в других цветовых пространствах. В принципе, яркость и цветность разделены в системе LAB. Но для обработки она не очень удобна. Получается довольно странная ситуация - обработка ведётся либо в аппаратных цветах RGB, (все привыкли, а ведь это страшно неестественно), либо в LAB (довольно сложна для расчётов). А, что, в промежутке ничего нет? Выводить на экран надо RGB в соответствии с профилем монитора, печатать с профилем принтера и чернил, а сохранять в sRGB или Адобе RGB. Раз так часто надо пересчитывать цвет, то почему бы не обрабатывать в пространстве, где светлота отложена только по одной из осей координат. Годится и колориметрическая система XYZ (светлота по Y), но цветность можно сделать и более интуитивно понятной. При этом система получается линейной относительно RGB, и не такой сложной и неестественной как LAB. Надо подумать.