Саму бленду надо проверять, вполне возможно что на открытой диафрагме и 16-мм универсальная будет виньетировать. У меня 16-35 сейчас нету, посмотреть не могу.
Для объектива 16-35/2.8L II универсальная бленда LEE подходит, или лучше взять широкоугольную? Хочется иметь возможность работать без виньотирования на широком угле с поляриком и 2-мя градиентниками. Какой вариант посоветуете?
Ну, если вас не интересует интерполяция и достаточно половинного разрешения (четвертинного, если считать по пикселям) и два зеленых канала - одинаковые, то да, вполне можно.
Matrica cam_xyz preobrazuet iz CIE XYZ 1931 (naschet white point ne uveren!) v RGB sensorov kamery!!! rgb_cam mozhet byt i ne sovsem matricei balansa belogo, ona preobrazuet iz RGB sensorov kamery v normalnyi RGB (profil). Voobshe sintaxis matematicheskii po pravilam svertki, za chto afftoru spasibo. Naschet pre_mul i cam_mul ne uveren. cam_mul soderzhyt znacheniya garazdo bolshye 1.0 i o ego naznachenii ya dezhe ne dogadyvaus. Tak zhe pri konvertirovanii iz camernogo RGB v drugie cvetovye prostranstva voznikaet problema s gammoi RGB sensorov. Naprimer na kamerah Leica pri golom izvlechenii dannyh po ::unpack() potom metodom half i nalozheniem rgb_cam kartinka poluchaetsa daleko ne s lineinoi gammoi!!!! Hotya v sootvetstvueshem pole libraw_colordata_t lezhyt pryamaya :-(
Пробовал на 40D сделать - не работает на моей фирмваре, коэффициэнты разные получаются. У кого-то на 40D получилось. Не могли бы скинуть RAW файл на почту murz2007@gmail.com? Был бы премного благодарен.
Получил прекрасные результаты, используя данный метод при подводной съемке. Дело в том, что при этом очень критичен красный канал: в воде он очень быстро исчезает, буквально на 2-3 стопа за метр. При конвертации с raw снятого по автобалансу с хорошим красным я часто дополнительно вытягивал ББ на 10000К чтобы получить нужные цвета. Но в реальности красный был паршивым, и только автобаланс вытягивал его наверх. Что получалось - на гистограмме все ок, на превью все ок - а на компе куча шумов в этом канале. С UniWB видя реальную поканальную диаграмму стал более сильно экспонировать, что существенно улучшило картинку - при этом никаких пересветов не возникло.
Драйвер действительно масштабирует не очень.
Поэтому, файл под печать желательно готовить сразу с оптимальным разрешением.
Ну, либо можно печатать не через драйвер.
И, кстати, раз уж речь зашла о печати не через драйвер. Я не нашел в тесте, а кто управляет цветом в Ваших экспериментах - драйвер или внешняя CMS (тот же Фотошоп)?
Если я возьму что-то "в пределе", то задача драйвера - смасштабировать его правильно. Если смасштабирует - проблем не будет.
Вообще, исследование довольно сильно мутировало в процессе его выполнения. Я в страшном сне не мог себе представить, что при масштабировании цвет может кардинально уехать.
Соответственно, рекомендации тоже изменились, я предполагал вывод вроде "720 лучше/не лучше 360", а получилось "категорически не доверяйте масштабирование драйверу, никакой печати в размер...".
-Я говорю о том, что для картинки в сильно различающимися по цвету пикселями, есть риск потери качества цветопередачи при увеличении разрешения исходника. Возьмите в пределе цветной исходник 2880*1440 dpi и попробуйте напечатать 1:1.
-Возможно, мы немного разошлись в терминологии. Есть пиксель исходного изображения, цветной. Есть одноцветная капля, которую ставит принтер, отрисовывая цветной пиксель. Размер капли принтер варьирует, размеры всех цветных пикселей - одинаковы.
-Разрешение, в котором печатает струйный принтер, определяется, по сути, двумя параметрами - разрешением печатающей головы и её шагом.
-Я полагаю, разрешение входного изображения определяется минимальной матрицей одноцветных капель, которой принтер может пиксель растеризовать.
Как раз для монотонно залитых областей никакой видимой разницы не будет (ну, если мы не наткнулись на особенности драйвера по ресайзу, см. статью).
Считая вариативность, не забывайте про разный размер пикселов.
Что касается координации пикселов с соседями - интересно было бы это подтвердить в эксперименте. Особенности ресамплера драйвера заставляют меня предполагать, что там и все остальное столь же прямолинейное.
Драйвер сообщает приложению разрешение печати (в Windows, API позволяет). И это не 180dpi.
Ммм, dcraw вполне поддерживает выдачу цвета в родном цвете камеры, и с интерполяцией.
Интерполяция, насколько мне известно, вообще проводится до цветовой коррекции.
В общем, сейчас я не знаю только ответ на один вопрос - чем лучше построить хороший табличный профиль.
Полярик-градиентники от бленды не зависят.
Саму бленду надо проверять, вполне возможно что на открытой диафрагме и 16-мм универсальная будет виньетировать. У меня 16-35 сейчас нету, посмотреть не могу.
Для объектива 16-35/2.8L II универсальная бленда LEE подходит, или лучше взять широкоугольную? Хочется иметь возможность работать без виньотирования на широком угле с поляриком и 2-мя градиентниками. Какой вариант посоветуете?
Ну, если вас не интересует интерполяция и достаточно половинного разрешения (четвертинного, если считать по пикселям) и два зеленых канала - одинаковые, то да, вполне можно.
Я не вижу, чтобы в семерке были заметные изменения. Может что-то не понимаю....
Хорошо бы увидеть статью с учетом нововведений в современных ОС(Windows 7)..
Razlichnye variacii Tone Mapping'a.
No pri Tone Mappinge nuzhno byt kraine ostrozhnym, tak kak vse suchestvuushie algoritmy tone mapping'a menyaut chromaticheskei koordinaty!
Matrica cam_xyz preobrazuet iz CIE XYZ 1931 (naschet white point ne uveren!) v RGB sensorov kamery!!! rgb_cam mozhet byt i ne sovsem matricei balansa belogo, ona preobrazuet iz RGB sensorov kamery v normalnyi RGB (profil). Voobshe sintaxis matematicheskii po pravilam svertki, za chto afftoru spasibo. Naschet pre_mul i cam_mul ne uveren. cam_mul soderzhyt znacheniya garazdo bolshye 1.0 i o ego naznachenii ya dezhe ne dogadyvaus. Tak zhe pri konvertirovanii iz camernogo RGB v drugie cvetovye prostranstva voznikaet problema s gammoi RGB sensorov. Naprimer na kamerah Leica pri golom izvlechenii dannyh po ::unpack() potom metodom half i nalozheniem rgb_cam kartinka poluchaetsa daleko ne s lineinoi gammoi!!!! Hotya v sootvetstvueshem pole libraw_colordata_t lezhyt pryamaya :-(
Случаи бывают разные.
Фатальные ошибки правятся сразу после обнаружения, все остальное - по наличию времени.
странно, у меня все нормально получалось.
У меня последняя прошивка. С ней и пробовал на темном кадре.
получилось сделать вычитанием нейтральной точки.
multipliers 1.000000 1.011858 1.051383 1.011858
не идеально, но на глаз разницы не заметно.
это не решение проблемы.
лучше прошивку обновить до последней.
http://web.canon.jp/imaging/eosd/eos40d/eos40d-firmware-e.html
Пробовал на 40D сделать - не работает на моей фирмваре, коэффициэнты разные получаются. У кого-то на 40D получилось. Не могли бы скинуть RAW файл на почту murz2007@gmail.com? Был бы премного благодарен.
Получил прекрасные результаты, используя данный метод при подводной съемке. Дело в том, что при этом очень критичен красный канал: в воде он очень быстро исчезает, буквально на 2-3 стопа за метр. При конвертации с raw снятого по автобалансу с хорошим красным я часто дополнительно вытягивал ББ на 10000К чтобы получить нужные цвета. Но в реальности красный был паршивым, и только автобаланс вытягивал его наверх. Что получалось - на гистограмме все ок, на превью все ок - а на компе куча шумов в этом канале. С UniWB видя реальную поканальную диаграмму стал более сильно экспонировать, что существенно улучшило картинку - при этом никаких пересветов не возникло.
на никоне д90, приобретенном после кенона 40д, унивб не получается. ни по черному кадру, ни по белому.
прошивка 1.0.0
Тут же целая масса выводов, например что нужно выключать увеличение размера при печати без полей, а то будут эффекты....
Что касается управления цветом - его просто нет, выключено везде (ну, исходному файлу я сделал convert to profile принтера, но однократно).
Драйвер действительно масштабирует не очень.
Поэтому, файл под печать желательно готовить сразу с оптимальным разрешением.
Ну, либо можно печатать не через драйвер.
И, кстати, раз уж речь зашла о печати не через драйвер. Я не нашел в тесте, а кто управляет цветом в Ваших экспериментах - драйвер или внешняя CMS (тот же Фотошоп)?
Если я возьму что-то "в пределе", то задача драйвера - смасштабировать его правильно. Если смасштабирует - проблем не будет.
Вообще, исследование довольно сильно мутировало в процессе его выполнения. Я в страшном сне не мог себе представить, что при масштабировании цвет может кардинально уехать.
Соответственно, рекомендации тоже изменились, я предполагал вывод вроде "720 лучше/не лучше 360", а получилось "категорически не доверяйте масштабирование драйверу, никакой печати в размер...".
-Я говорю о том, что для картинки в сильно различающимися по цвету пикселями, есть риск потери качества цветопередачи при увеличении разрешения исходника. Возьмите в пределе цветной исходник 2880*1440 dpi и попробуйте напечатать 1:1.
-Возможно, мы немного разошлись в терминологии. Есть пиксель исходного изображения, цветной. Есть одноцветная капля, которую ставит принтер, отрисовывая цветной пиксель. Размер капли принтер варьирует, размеры всех цветных пикселей - одинаковы.
-Разрешение, в котором печатает струйный принтер, определяется, по сути, двумя параметрами - разрешением печатающей головы и её шагом.
-Я полагаю, разрешение входного изображения определяется минимальной матрицей одноцветных капель, которой принтер может пиксель растеризовать.
Сейчас ответить на этот вопрос не смогу.
У меня есть одно предположение, и, скорее всего, оно верно.
Но я проверю сначала, ок?
А почему ваш, эпсоновский, драйвер говорит Windows про 720dpi?
Вот и встретились два производителя :)
Я в Epson работаю :)
В случае Canon, авторы матрицы и авторы камеры - одна компания.
Вообще, спросить производителя - не всегда лучшая идея, как производитель вам говорю.
Как раз для монотонно залитых областей никакой видимой разницы не будет (ну, если мы не наткнулись на особенности драйвера по ресайзу, см. статью).
Считая вариативность, не забывайте про разный размер пикселов.
Что касается координации пикселов с соседями - интересно было бы это подтвердить в эксперименте. Особенности ресамплера драйвера заставляют меня предполагать, что там и все остальное столь же прямолинейное.
Драйвер сообщает приложению разрешение печати (в Windows, API позволяет). И это не 180dpi.