Expose to the Right? Expose Right!

lexa - 26/Фев/2010 18:05

Понятие об ETTR (Expose to the Right) было вброшено в фотографические массы Рейхманом в 2003-м году. Возможно, идея и не его, но популярен этот прием стал после его статьи.

Однако время идет, шум в современных камерах стал значительно меньше, битность АЦП - больше, поэтому польза ETTR уже не столь очевидна, а про вред говорить не принято. Кроме того, полезно помнить, что камерная гистограмма камеры показывает непонятно что (и даже UniWB не решает полностью проблемы т.к. остается еще контраст/насыщенность и прочие тоновые кривые, применяемые к JPEG-представлению, по которому строится гистограмма), поэтому оценить по камерной гистограмме, попали ли мы "вправо" нормально или пересветили (или недостветили) - непростая и в общем случае нерешаемая задача.

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

Приехавший ColorChecker Passport дал легкий способ как проиллюстрировать проблему, так и просто оценить порядок бедствия.

Методика

  1. Берем ColorChecker, снятый по экспонометру (в RAW), конвертируем его из RAW своим любимым конвертором, баланс белого ставим по серому полю колорчекера.

    Для эксперимента я взял Adobe Camera Raw 5.6, в качестве профиля камеры (Canon 5D mk II) - камерный профиль из поставки ACR, при конвертации "стандартно экспонированной" мишени - "все движки по нулям".

    Полученный рендеринг назовем стандартным. Нам не очень важно, какие получились цвета, это в любом случае некий эталон в нашем workflow.

    Запоминаем (записываем) RGB-значения для шести полей серой шкалы.

  2. Берем ColorChecker экспонированный как-то иначе (с передержкой, например, мы же про ETTR) но при том же освещении, баланс белого ставим по тому же серому полю.

    Движками Exposure, Brightness, Contrast, Fill, Black выводим серую шкалу в те же значения, что были на стандартном рендеринге.

    Сохраняем результат в файл.

  3. Сравниваем Lab-значения полей двух рендерингов, считая два варианта отклонения цвета:
    • расстояние в пространстве Lab;
    • расстояние на плоскости ab
    Первое расстояние - это классическое dE, второе - оно же, но очищенное от яркостной компоненты.

Естественно, в данной постановке мы сравниваем комбинацию камера+конвертор, для разных конверторов результаты будут разными. Адобовский конвертор использовался как наиболее массовый.

Результаты

  • Переэкспонирование на стоп: яркостная шкала пришла в соответствие с помощью только движка Exposure, отклонение по яркости по всем полям шкалы в пределах двух единиц L, для серой части шкалы - в пределах одной единицы.

    Максимальное отклонение по цвету (без учета яркостной компоненты) - 4.4 единицы 'Lab' (точнее, 'ab'), поле D3 (ярко желтое), второе желто-оранжевое поле (F2) имеет отклонение 4.1 единицы, еще три поля - отклонение в пределах 3-4 единиц, у остальных 19 - меньше трех.

  • Переэкспонирование на 1.67 стопа (при этой экспозиции каналы еще не выбиты, при дальнейшей передержке зеленый начинает вылетать на белом поле): для уравнивания яркостной компоненты пришлось использовать не только Exposure, но и яркость-контраст, точность уравнивания - в пределах единицы по L.

    Отклонения по цвету в "желтом-оранжевом" (поля A2, F2) - более 9 единиц, в поле D3 (желтое) - 6.7, еще 6 полей имеют отклонение более 3 единиц "цветности". Отклонение по яркости для трех самых вылетевших полей (A2, F2, D3) нулевое, поэтому "отклонения по цвету" в точности равны delta-E в классическом (Lab-овском) понимании.

    Два рендеринга поля F2, стандартный и переэкспонированный-поправленный показаны в заголовке данной статьи.

Анализ Lab-значений показал, что наибольшие потери - в канале а, все поля шкалы потеряли контраст в этом канале. Однако поправить это несчастье кривыми в Lab невозможно: желтое поле F2 потеряло 9 единиц красного, а относительно близкое (по значению канала a) поле А1 - только три единицы. Вполне возможно, что наиболее вопиющие проблемы с желтым можно поправить RGB-кривыми.

Заключение

  1. Эксперимент простой - и я рекомендую проделать его для вашей камеры и вашего конвертора самостоятельно. Возможно, ваш конвертор лучше и проблемы у вас нет.
  2. Лично же я - как не использовал ETTR без особой нужды, так и не буду: повторяемость результата по цвету по мне куда важнее, чем (практически несущественный на моей камере при низких ISO) шум в тенях.
  3. По всей видимости, проблема может быть исправлена и специальными ETTR-профилями, но их нужно строить для каждой ступеньки по переэкспонированию ("то что станет полутонами - экспонировано как +1")

Comments

wrest (not verified) - 26/Фев/2010 18:52

так как линейность матриц вроде не подвергается сомнению, остается следующее:

-- модель Lab неправильная
-- реализация модели Lab в программах adobe неправильная
-- яркостные алгоритмы, отрабатывающие движки в программах adobe неправильные

думаю что истина в комбинации всех трех вышеозначенных неправильностей

создатели РВК Photostudio, например, особо обращают внимание на то, что их программа использует свою цветомодель, и их яркостные алгоритмы не трогают цветовые тоны, а цветовые алгоритмы не меняют яркость.

wrest (not verified) - 26/Фев/2010 18:55

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

lexa - 26/Фев/2010 19:09

По идее, кстати, если движок Exposure применять к raw-данным (линейным) то проблем не будет.....

pavel_burov (not verified) - 26/Фев/2010 19:53

> -- модель Lab неправильная

Я бы переформулировал: модель Lab не очень хорошо подходит для решения нашей задачи .

(логико-общефилософское) К понятию модель не применимы категории правильно/неправильно , модель бывает противоречивая или не противоречивая.

> создатели РВК Photostudio, например, особо обращают внимание на то, что их программа использует свою цветомодель, и их яркостные алгоритмы не трогают цветовые тоны, а цветовые алгоритмы не меняют яркость.

Наши яркостные алгоритмы гарантируют сохранение соотношений между, например, X/Y и Y/Z. Иными словами, сохраняются CIE xy-chromaticites.

Например, наш движок exposure эмулирует простую штуку больше света/меньше света без изменения этого самого света спектрального состава. Иными словами, умножение линейных цветовых координат на постоянный множитель.

lexa - 26/Фев/2010 19:08

Тут вот какое дело:
1) Adobe работает вроде как в ProPhoto (внутреннее представление)
2) С яркостью проблем нет, яркостный канал выводится очень хорошо и яркость цветных патчей тоже на месте, ошибка по L-каналу в сравнении с 'a' - невелика.

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

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

wrest (not verified) - 26/Фев/2010 19:23

>1) Adobe работает вроде как в ProPhoto (внутреннее представление)
доподлинно ж неизвестно, а adobe не колется. но тут, в общем, если и в ProPhoto - что это меняет? Значит, adobe невправильно работает с цветом при операциях с яркостью, но не в Lab а в RGB

> 2) С яркостью проблем нет, яркостный канал выводится очень хорошо и яркость цветных патчей тоже на месте, ошибка по L-каналу в сравнении с 'a' - невелика.

Опять же, я писал о том, что у adobe ошибочные алгоритмы пересчета при яркостных операциях (exposure, brightness, contrast, fill light и т.п.), т.к. меняется цветовой тон который (по идее) меняться не должен. Либо в adobe считают что все нормально, и при изменении яркости должен изменяться и цветовой тон и тогда это такаяя фича.

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

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

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

lexa - 26/Фев/2010 20:17

У меня и в мыслях не было исследовать корни явления (тем паче у Адобы, что мне до нее).

Это, на самом деле, ответ на часто задаваемый вопрос "а что вы думаете про ETTR?"
Я вот думаю, что две T там лишние....

wrest (not verified) - 26/Фев/2010 20:38

да но не потому, что ETTR имеет принципиальные изъяны, а потому, что изъяны имеются у обрабатывающих программ. на что пользователю конечно наплевать, где там какие проблемы у адобы или ещё у кого, ему главное что так цветопроблемы есть, а эдак - нет. тут я согласен.

lexa - 26/Фев/2010 20:39

Если в тенях есть нелинейность (а она есть) - это принципиальный изъян?

wrest (not verified) - 26/Фев/2010 20:54

>Если в тенях есть нелинейность (а она есть) - это принципиальный изъян?

если нет "ETTR-профиля", корректирующего эту нелинейность, то да.

lexa - 26/Фев/2010 21:04

Про ETTR заговорили 7 лет назад, когда про профили почти и не думали (в Адобе)

Ib (not verified) - 26/Фев/2010 21:09

У этого ETTR-профиля тоже есть своя цена. Широта материала ограничена, и вполне невелика.

wrest (not verified) - 26/Фев/2010 20:43

>Наши яркостные алгоритмы гарантируют сохранение соотношений между, например, X/Y и Y/Z. Иными словами, сохраняются CIE xy-chromaticites.

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

elektraua (not verified) - 01/Мар/2010 23:57

А я бы пошел еще дальше. Модель LAB имеет не только практические значения, но и больше теоретические и математически последовательные. А матрица цифрового аппарата - устройство реальное, на котором сказываются изменения условий съемки и все не так идеально, как в модели цветового представления.

Ib (not verified) - 26/Фев/2010 20:58

Матрица (сенсор) нелинейна на краях диапазона, а для желтого, например, синий именно на краю диапазона. Ваши замечания также справедливы, разумеется. Однако "правильной" цветовой модели в смысле полной независимости цветности и яркости в диапазоне +/- 5 EV сегодня не существует.

Pasch (not verified) - 28/Фев/2010 22:33

Проделал эксперимент. Сфотографировал эту мишень (с экрана) с E0, E+1, E+2.
На последнем снимке уже появился клиппинг в светлых плашках.

Сконвертировал с помошью ACR, и с помощью RPP. (привел к одной яркости по серым полям, ББ по ним же).
ACR дает заметную ошибку между снимками E0 и E+2 - разница есть во всех плашках, разброс по каналу L достигает 3, по каналам a, b - 5 единиц.

Для RPP значения плашек практически совпадают! По отдельным позициям есть отклонения, но не более 1 (в общем-то ,в пределах погрешности измерения).

Так что, получается, не все так плохо с ETTR :)

pavel_burov (not verified) - 26/Фев/2010 19:56

А Вы экспериментировали с Untwisted DNG Profile'ами? Может быть, дело в подшаманивании цветовых тона/насыщенности в зависимости от яркости?

> расстояние на плоскости ab

Контрольное напоминание. Равенства a,b1=a,b2 не означает постоянство цветовых тона и насыщенности. Линия равных цветовых тона и насыщенности в CIE L*a*b* зело кривая есмь.

lexa - 26/Фев/2010 20:15

Я экспериментировал ровно с тем, что дает Adobe в виде профиля камеры. Т.е. эмулировал ситуацию "обычного потребителя"

Равенства a,b1=a,b2 не означает постоянство цветовых тона и насыщенности.
L практически одинакова, в пределах 1, максимум 2 единичек. Поэтому моя "цветовая разница" - это практически классический Lab-овский dE. Не самая лучшая метрика, зато простая.

pavel_burov (not verified) - 26/Фев/2010 21:05

> L практически одинакова, в пределах 1, максимум 2 единичек.

Ай, на это не обратил внимания, пардон.

Повторил эксперимент, получил в жёлтом поле (yellow, 16):
а) DNG-profile Camera Neutral L=91/92, a=-14/-14, b=78/79;
б) DNG-profile Camera Neutral Untwisted L=84/84, a=-11/-12, b=63/63;
в) в инструкции написано: L=81.733, a=4.039, b=79.819.

Прочие установки RAW-конвертации всё в ноль , линейная тоновая кривая.

pavel_burov (not verified) - 26/Фев/2010 21:07

> Повторил эксперимент

upd. Разница между снимками недодержка на два стопа в камере и +2 EV ползунком при конвертации.

По остальным полям разницы тоже не заметно.

lexa - 26/Фев/2010 21:19

Передержку надо :)

Но в пределах headroom.

lexa - 26/Фев/2010 21:25

Ага, понял про что вы в смысле untwisted.

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

lexa - 26/Фев/2010 21:21

Пардон, не понял.

А отчего у вас L разный настолько? +2EV - неточная коррекция, надо тоновую кривую полностью на место вернуть.

pavel_burov (not verified) - 26/Фев/2010 22:44

> Ага, понял про что вы в смысле untwisted.

Да, у меня каждый RAW двумя способами (профали Camera Neutral и Camera Neutral Untwisted) конвертирован. Для каждого расхождения слабые, между сильные.

> Не, задача была - именно сферический в вакууме пользователь Адобы.

К сожалению, я уже так не смогу. Перенастроил ACR, а default'ные настройки Adobe не сохранил. Единственный шанс скачать где-нибудь RAW от камеры, которую ещё мой ACR не знает, и срисовать на бумажку все ползунки.

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

Ib (not verified) - 26/Фев/2010 21:15

> установки RAW-конвертации всё в ноль , линейная тоновая кривая.

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

pavel_kosenko (not verified) - 26/Фев/2010 23:49

Алексей, а у Вас есть задача как можно точнее передать цвет на фотографиях? При творческом подходе цвет обычно формируется в процессе рав-конвертации и обработки, и очень часто осознанно приводится не к честным цветам, а к красивым (ну по крайней мере есть такие попытки).

photo_vs (not verified) - 27/Фев/2010 00:57

>>При творческом подходе цвет обычно формируется в процессе рав-конвертации и обработки

при творческом подходе цвет обычно формируется в еще ДО съемки, на это и уходит основное время фотографа. А выгонка из рава, сканирование, постпродакшн - это лишь более или менее успешная попытка приблизиться к тому что было.

pavel_kosenko (not verified) - 27/Фев/2010 01:14

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

photo_vs (not verified) - 27/Фев/2010 01:40

>>Мы сейчас говорим про цветопередачу в моменте "фиксация - конертация"

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

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

pavel_kosenko (not verified) - 27/Фев/2010 01:55

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

photo_vs (not verified) - 27/Фев/2010 02:01

ровно ни с кем не путаю.
т.к не я говорю о цвете после конвертации.

pavel_kosenko (not verified) - 27/Фев/2010 02:14

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

photo_vs (not verified) - 27/Фев/2010 02:28

>>с RAW-файлом, который не является графическим
в каком месте не графический?

вот я кстати как самый юный комью-пионер начал осваивать графику с PC-XT с 4 цветами, а полноценное экранное разрешение было вообще только в BW, а графика уже была. в BMP :)

lexa - 27/Фев/2010 07:54

до момента конвертации мы имеем дело с RAW-файлом, который не является графическим и, как следствие, не обладает таким понятием, как цвет.

Ой!

А куды же он денется то? Это сигнал с колориметра (кривого, косого, но колориметра).

pavel_kosenko (not verified) - 27/Фев/2010 09:28

Сигнал с колориметра - конечно, но сам RAW-файл не графический формат. В момент конвертации мы превращаем сигналы с цвет, с учетом контрастных установок, баланса белого, цветового пространства назначения и других факторов. Разве нет?

lexa - 27/Фев/2010 09:35

Что значит "не графический формат", что это за догматизм и начетничество?

acdsee показывает? значит графический.

pavel_kosenko (not verified) - 27/Фев/2010 09:39

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

lexa - 27/Фев/2010 09:53

Вы прекратите этот догматизм, натурально.

Вот возьмем .DNG для простоты - это же такая разновидность Tagged *Image File* Format (да и .CR2 - тоже)
Да, там собственная модель описания того, как интерпретировать цветовую-яркостную информацию (т.е. "свой формат профилей"), но оно не перестает от этого быть разновидностью TIFF.

pavel_kosenko (not verified) - 27/Фев/2010 10:08

Возможно, я употребил некорректно формулировку. Но факт остается фактом - raw требует интерпретации (которая определяет итоговые цвета), а тот же tiff в совокупности с цветовым профилем (которого нет у сырого формата) задает цвета однозначно. Я не прав?

lexa - 27/Фев/2010 10:15

RAW в режиме половинного разрешения (т.е. без интерполяции) и с наложенным цветовым профилем ничем не отличается от "того же" TIFF. Да, цветовой профиль немного другой (но в DNG Color Model принципы те же).

Не говоря о том, что подавляющее количество RAW-форматов и являются "тем же TIFF"

pavel_kosenko (not verified) - 27/Фев/2010 10:28

А что такое половинное разрешение без интерполяции?

lexa - 27/Фев/2010 10:46

Четверку пикселей (G-R-G-B, 2x2) вполне можно "сложить" в один пиксель, обладающий полной (и даже несколько избыточной) информацией о цвете.

Без всяких этих AHD, VCD и прочих VNG.

И так много кто делает, как при показе на экран, так и (некоторые) при финальном рендеринге.

pavel_kosenko (not verified) - 27/Фев/2010 12:40

В этом случае информация о цвете будет однозначной?

lexa - 27/Фев/2010 12:56

Это вы на баланс белого намекаете?

Да, однозначной (включая в метаданные о цвете еще и то, что камера написала в метаданные о балансе белого).

pavel_kosenko (not verified) - 27/Фев/2010 14:40

Хорошо, попробую осознать сказанное :)

q_w_z (not verified) - 28/Фев/2010 12:56

любой по-вашему "графический" тоже требует как минимум компьютера с современной ОС для "интерпретации", а так это набор байтов;-]

pavel_kosenko (not verified) - 28/Фев/2010 14:31

Любой графический формат содержит точные координаты цвета и профиль для их однозначной интерпретации. Чего не скажешь о RAW.

q_w_z (not verified) - 28/Фев/2010 14:45

тогда и говорите "любой графический формат, содержащий профиль"

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

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

просто RAW требуют большей работы при интерпретации
(также как например PostScript и "векторные" форматы)

pavel_kosenko (not verified) - 28/Фев/2010 14:49

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

И все-таки, расскажите вот вы мне с Алексеем :) Каким образом интерпретируется RAW до графического формата - ну ББ положим As Shot, а профиль и контрастные установки?

lexa - 28/Фев/2010 15:23

существуют вроде бы даже международные какие-то стандарты, согласно которым файл без профиля считается sRGB-шным

Получается, до 96-го года графических форматов и не существовало? А что же я ел в троллейбусе А с чем я работал за 10 лет до этого?

Каким образом интерпретируется RAW до графического формата - ну ББ положим As Shot, а профиль и контрастные установки?

Ну так и профиль - по метаданным и контраст - оттуда же. Тот факт, что камера их, допустим, не сохраняет (хотя часть камер пишет тоновую кривую, а не просто "контраст +5", а часть камер пишет и профиль тоже) не означает что взять их неоткуда: метаданных в RAW-формате достаточно.

pavel_kosenko (not verified) - 28/Фев/2010 16:00

Видимо надо хорошо знать формат метаданных, чтобы понять как сформировать кривую если камера ее не записала :)

lexa - 28/Фев/2010 16:09

Да, RAW - это семейство плохо описанных графических форматов

Формат метаданных не проблема, проблема есть в интерпретации значений.

pavel_kosenko (not verified) - 28/Фев/2010 17:27

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

lexa - 28/Фев/2010 17:32

Вам про WIC-кодек уже написали. Он интерпретирует RAW вполне однозначно, там просто нет места для ввода параметров.

pavel_kosenko (not verified) - 28/Фев/2010 17:36

А как именно он интерпретирует, если Вы сами говорите, что проблема в интерпретации метаданных.

lexa - 28/Фев/2010 17:43

А у него нет таких проблем.

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

Adobe CameraRaw/Lightroom вам же показывают некий рендеринг при нажатии на кнопку 'Default', ну так считайте что она все время нажата, например.

pavel_kosenko (not verified) - 28/Фев/2010 17:55

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

Но ведь дело в том, что параметры Default - это всего лишь некие параметры, которые по умолчанию предлагает LR, и они, в частности, практически всегда (по моим наблюдениям) отличаются от параметров, с которыми делает внутрикамерный джипег сама камера. То есть LR интерпретирует одним образом, камера другим, другие программы третьим могут интерпретировать и т.д. В итоге мы видим не сам RAW файл, а версии его интерпретации, причем разные. Соответственно, и контраст, и цвета у разных интерпретаций будут разные. Вот что я имею в виду, когда говорю про неоднозначность интерпретации и про "неграфияческий формат" (уже выяснили, что эта фрпмулировка упореблена некорректно мною).

lexa - 28/Фев/2010 18:03

Ну так если я в фотошопе или еще где подвигаю ручки - картинка тоже изменится?

pavel_kosenko (not verified) - 28/Фев/2010 18:12

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

lexa - 28/Фев/2010 18:23

Да тоже не факт:
Раз: http://blog.lexa.ru/2010/01/29/tsvetovaya_govorite_nauka.html
Два: http://www.color.org/version4html.xalter

pavel_kosenko (not verified) - 28/Фев/2010 18:26

Ну с точки зрения исключений-артефактов, свойственных CMS да, в принципе любой формат можно считать графическим, например, txt :)

lexa - 28/Фев/2010 18:42

А что TXT? У PPM заголовок текстовый, ничего? Да и вообще вопрос представления, есть же data-URI, тоже текстовый формат, а описывает изображение.

Если наши данные описывают изображение (т.е. pixel map, для простоты включаем сюда рендеринг векторных форматов в конкретное разрешение-размер) - значит графический формат.

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

pavel_kosenko (not verified) - 28/Фев/2010 18:48

Я не считаю, что это притягивание за уши. Неоднозначность интерпретации RAW формата куда более значительная, чем некоторые огрехи CMS. От формы кривой буквально зависит, будет ли картинка темной или светлой, а приведенные примеры лишь в некоторой степени смещают некоторые оттенки, причем это скорее исключения из правил. Поэтому я с Вашего позволения пока остаюсь при своем мнении - RAW может быть сколько угодно графическим форматом, но не приспособлен для передачи собственно графики. Лишь для передачи сырых данных о графике. Не убедили в общем :)

lexa - 28/Фев/2010 19:09

А если я, извиняюсь, XMP-даные "внедрю" (в смысл embed) в DNG, то оно вдруг, внезапно, станет "графическим форматом" в вашем понимании? Что изменилось?

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

pavel_kosenko (not verified) - 28/Фев/2010 19:19

Да, в моем понимании DNG с внедренными xmp-данными файл будет однозначным графическим. Сканы TIFF с профилем, это тоже однозначная графическая информация. Обработка - способ ее изменить, а не интерпретировать исходные данные. Уточню: любую графическую информацию можно авторски инерпретировать. Но одно дело, отталкиваться от однозначной картинки, другое дело от картинки, которой по сути еще нет и которая может появится в зависимости от того, как её "проявить". В этом плане сырой RAW скорее сродни непроявленной пленке.

lexa - 28/Фев/2010 19:28

Сырой RAW - конечно допускает вариации при проявке, равно как и скан с пленки. И оба в сыром виде к употреблению непригодны.

Что касается XMP - невнедренный XMP - это тоже такой XMP, аналог кнопки defaults. В чем отличие?

pavel_kosenko (not verified) - 28/Фев/2010 19:45

Отличий в общем-то нет, кроме того, что в первом случае XMP может быть задано производителем камеры, а во втором "придумано" RAW-конветором (и придумано по-разному). Вместе с тем, если бы мы имели дело с сырыми данными + заданным XMP (не важно кем создан), то тогда можно было бы говорить об однозначности формата. Без XMP, на мой взгляд, не можем.

scutfromhare (not verified) - 02/Мар/2010 11:34

Поправка. Придумана сторонними РАВ конверторами. Ибо все данные камера пишет в РАВ. Любая камера наверное, но Кэнон и Никон точно пишут. А вот большенство сторонних конверторов либо игнорируют эти данные, либо производитель не дает ими пользоваться. Поэтому если говорить о РАВ и родном софте, то РАВ вполне себе графичесикй формат (в понимании Павла :) Потому как родные конверторы показывают обсалютно ту-же картинку что и камера на экранчике, потому как полностью учитывают все параметры сьемки и внутрекамерные аджастмент параметры.
И Этим мы приходим не к проблеме наличия и интерпритации внеренных профилей, параметров и кривых, а к проблеме понимания внедренных данных сторонним софтом :)

Кстати, Адоб очень долго сопростивлялся. Они считали, что их РАВ конвертор должен выдавать средне условно серую картинку независимо от того чем она снята. А уж потом в шопе эту картинку надо точить до нужного состояния. И при таком подходе это в принципе оправдывается. Ибо усреденно не контрастная картинка больше всего потдается последующим модификациям.
Однако и Адоб не устоял, совсем недавно они наконец добавили профили камер в свой конвертор, а еще чуть раньше можно было рукчами калибровать в специальной закладке конвертора.

lexa - 02/Мар/2010 23:26

"Без XMP", оно же "пустой XMP" - это же тоже вариация на тему XMP?

Открываю файл в ACR и тут же закрываю - образуется XMP с умолчательными значениями, интерпретация файла не меняется. Что изменилось?

pavel_kosenko (not verified) - 02/Мар/2010 23:39

А разве с появлением XMP не появляется интерпретация файла?

lexa - 03/Мар/2010 08:30

Да нет, сначала интерпретация, а потом ее запись в XMP.
При этом, если никакие ручки не трогались, то интерпретация без XMP и с оным - не отличается. Что говорит нам о наличии первородного, подразумеваемого XMP.

Ну и про родные конверторы вам выше пишут - у них никаких проблем с интерпретацией без XMP не возникает, метаданных в файле достаточно.

pavel_kosenko (not verified) - 03/Мар/2010 10:59

С родными конверторами - да, согласен. Достаточно однозначно. Но это не помогает большинству пользователей передавать друг другу более-менее однозначную картинку через RAW. А первородный XMP - у меня, например, по умолчанию все в ноль стоит для всех камер, с которыми доводилось иметь дело. Алексей, я уже принял, что RAW - это графический формат, но его однозначность принять пока не могу :)

lexa - 03/Мар/2010 11:32

Ну так путаница связана не с тем, что информации о цвете нет (так или иначе, но в метаданных файла /+, возможно, внешние источники, но довольно однозначные/ - эта информация есть).

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

В пленочном мире эта кривая накладывалась слайдом или комбинацией негатив-бумага, а в цифровом - да, принято что нужна обработка, ради возможностей этой обработки и снимаем в raw

pavel_kosenko (not verified) - 03/Мар/2010 11:44

Согласен. Вот это вот отсутствие однозначности тоновой кривой меня и смущает :) Ну точнее как смущает. С творческой точки зрения не смущает ни капельки и наоборот. С технической точки зрения, с т.з. формата для передачи картинки смущает. Хотя в общем такой цели и нет.

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

lamantyn (not verified) - 28/Фев/2010 21:18

тестовый файл с "закрасить лист цветом PANTONE 19-1764" - графический файл? :-)

pavel_kosenko (not verified) - 28/Фев/2010 22:09

С точки зрения того, что можно каждой букве/цифре сопоставить некие координаты цвета, запросто :)

q_w_z (not verified) - 28/Фев/2010 15:29

во-первых sRGB это такая температура по больнице
во-вторых кк раз почти всё, умеет только напрямую
(кроме софта для работы с графикой и далеко не всякого)
в-третьих корректность-не корректность это очень оценочный критерий, к сожалению (кому-то всё, кроме CMYK tiff 300 dpi без сжатия - некорректное)

бррр. что значит "до графического формата"?
до BMP который MS Paint должен открывать или до чего?

тогда видео тоже можно считать "видео-форматов" только в виде секвенции TGA (так уж сложилось исторически, что не BMP), да и то понадобится понять в каком формате альфа-канал записывать (позитив-негатив) и в сколько бит на канал и т.п.

в конце-концов, поставив, кодек для RAW, я в ОС, ползая по папкам смотрю RAW и меня малоинтересует встроеный это JPEG или сами данные т.к. для контроля интерпретации в Windows Explorer ничего нет, а если будет - это будет MS Lightroom;-]

и это что, "не графический формат" теперь?
(по критерию, что jpeg может быть "подменён" и не "соответствовать" сырым данным разве)

lexa - 28/Фев/2010 15:08

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

Это описание может содержаться в файле (embedded profile), может содержаться в стандарте на формат файла, может быть зашит в интерпретирующую программу (но нигде про это явно не будет написано), а может быть что вообще никто об этом не подумал (но описание цвета при этом откуда-то берется, например из primaries монитора).

RAW ничем не отличается, ну кроме того, что стандартное (по ICC) цветовое описание к этим данным подходит плохо.

kotjara_zone (not verified) - 02/Мар/2010 20:17

необработанный raw-файл является набором сигналов ЯРКОСТИ с фотодатчиков матрицы. т.е. по сути это мало того что черно-белое изображение, но в добавок это не изображение даже вовсе, поскольку имеет точечную структуру. полноценное цветное изображение из рава получается только после того, как данные по яркости каждого пиксела сопоставляются с известным заранее трафаретом Байера и далее апроксимируются для всех промежуточных пикселов. в случае записи в jpg все это проделывает непосредственно камера. в случае рав - камера сохраняет только яркостный слепок. а сопоставление с шаблоном и апроксимация выполняется уже на внешней программе-конверторе.
именно поэтому рав файл, имея наиболее полную информацию по цветам, имеет значительно меньший вес, чем тот же tiff например. и именно поэтому рав-файл сам по себе не является сколь-нибудь полезным файлом без привязки к профилю конкретной марки камеры.
можно ли назвать рав-файл Неграфическим - это может быть и вопрос. но что данный файл не обладает понятием цвета - так это верно подмечено.

lexa - 02/Мар/2010 20:26

понимаете, если "понятием цвета" исходные данные не обладают, то откуда оный цфет потом берется?

Это же обычный такой колориметр, фотоэлементы за светофильтрами. Почему у колориметра нет понятия цвета? Да, байер портит, ну давайте foveon обсудимю

kotjara_zone (not verified) - 02/Мар/2010 20:54

>если "понятием цвета" исходные данные не обладают, то откуда оный цфет потом берется?
не данные, а конкретно рав-файл. в "данных" как раз цвет "содержится", если мы будем рассматривать именно всю СИСТЕМУ данных.
Вы путаете СИСТЕМУ данных при обработке файла и данные конкретного файла.
информация о цвете содержится в Вашем конверторе в виде информации о расположении красного, зеленого и синего пикселей на трафарете конкретной модели камеры. но непосредственно в рав-ФАЙЛЕ, который записывает камера, - этой информации нет. собственно самому рав-файлу абсолютно по барабану, каким пикселам Вы в дальнейшем какие цвета назначите (при сопоставлении с трафаретом). рав-файл оперирует только величиной ЯРКОСТИ этого пиксела. ЦВЕТ же назначется программно, на компьютере. Вашем компьютере и в Вашем конкретном конвертере. При помощи того самого файла поддержки, который производитель ПО вынужден выпускать к выходу новой модели камеры.

>фотоэлементы за светофильтрами. Почему у колориметра нет понятия цвета?
вот именно потому что это "фотоэлементы за светофильтрами". фотоэлемент не имеет представления о ЦВЕТЕ света. он меряет только его яркость. а светофильтр - это просто кусок пластика, который пропускает к фотоэлементу лишь ту часть спектра, которую нам надо. и сам по себе кусок пластика никакую информацию о своем цвете в процессор не передает. мы САМИ запоминаем, что в ЭТУ позицию мы положили красный светофильтр. значит ЭТОТ фотоэлемент нам будет показывать яркость в красном канале. но если мы по каким-то причинам забудем, КАКОЙ светофильтр мы положили в ЭТУ позицию - то восстановить данные о цвете ЭТОГО пикселя мы уже никогда не сможем.

байер не просто "портит". он позволяет в несколько раз сжать поток данных, которые необходимо запомнить. а формат РАВ позволяет еще больше (раза в 3 минимум) сократить этот поток, вынеся за пределы камеры те данные, которые являются константами для конкретной модели фотоаппарата.

lexa - 02/Мар/2010 21:06

Догматизм до добра не доводит.

Допустим, у нас есть TIFF-файл, но нет описания этого формата (или есть устаревшее описание). Проинтерпретировать этот поток бит мы не сможем. А с описанием формата, написав по нему программу декодирования - сможем.

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

В случае RAW эти данные просто хуже описаны, чем в случае TIFF с embedded-профилем, но принципиальной разницы никакой нет ("если в EXIF написано то-то - порядок такой-то, а цветовые координаты - такие-то").

Помимо того, говоря 'RAW' мы на самом деле подразумеваем десятки-сотни разных форматов. Там есть такой частный случай, как DNG, где и описание порядка следования фильтров в файле имеется и матрица преобразования в XYZ тоже в наличии.

kotjara_zone (not verified) - 02/Мар/2010 22:08

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

вот вроде бы человек не чуждий программированию, а такие коры выдает..
вы понимаете принципиальное различие между описанием ФОРМАТА и интерпретированием полученных в файле данных? если я вам скажу что буква X записана латинским символом - это еще не значит, что вы будете знать, что под этой переменной я сохранил значение 10.

lexa - 02/Мар/2010 22:43

Вот именно, не чуждый.

Вот варианты:
TIFF-файл с embedded-профилем (в формате спецификаций TIFF т.е. матричный)
TIFF-файл с embedded-профилем в формате DNG Color model, расширение DNG
TIFF-файл с embedded LUT-профилем в формате ICC (расширение, в Tiff6 не описанное)
TIFF-файл без embedded профиля, RGB-формат
TIFF-файл без профиля, Lab-формат
TIFF-файл без профиля, в метаданных написано, что снято Canon model такая-то, расширение .CR2

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

kotjara_zone (not verified) - 02/Мар/2010 23:36

здесь нечего обосновывать. рав и тиф - разные вещи и хранят они разную информацию. в формате тиф изначально хранятся данные о цвете. повторяю. в теле файла, записанного как tiff, хранится информация о цвете изображения. как эта информация ПОТОМ обрабатывается цветовыми профилями и цветовыми пространствами - вопрос отдельный и к теме не относится.
в формате raw (в большинстве из его разновидностей) информация о цвете не хранится. более того, информация о цвете не хранится вообще нигде. есть только информация о расположении каналов фильтра. вы должны прекрасно понимать как работает фильтр байера и как на его основании строится изображение. (опять же: вопрос о том, какими методами это изображение ЗАТЕМ ужимается в какой-то программе, - к теме не относится)

если вы знаете КАК читать, это еще не значит, что вы поймете ЧТО прочитали. описание формата tif - это азбука.
и описание формата cr2 - это тоже азбука (возможно даже такая же).
СОДЕРЖИМОЕ формата тиф - это текст на русском языке (вы его поймете, и при желании можете пересказать своими словами).
а СОДЕРЖИМОЕ формата cr2 - это текст на болгарском. букве те же, а смысла нет. пока словарь не возьмете и не узнаете смысл каждого слова. и ТОЛЬКО ПОСЛЕ ЭТОГО вы сможете, при желании, пересказать текст своими словами (читай: ужать, пересчитать цвета под нужную цветовую модель, сохранить, изменить - что угодно)

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

lexa - 03/Мар/2010 08:44

Я не пытаюсь доказать что "рав и тиф - одно и то же", тут нечего доказывать, большинство RAW-форматов - это TIFF/EP, формат данных такой.

Я просто пытаюсь показать на примерах, что далеко не всегда информация о цвете содержится в самих данных
- RGB-TIFF без профиля - цветовые данные (согласимся что это sRGB) содержатся во внешнем мире, зачастую hardcoded в программу показа
- TIFF/EP с EXIF в котором написано Maker=Canon Model=30D - дает достаточно данных, чтобы взять цветовые данные откуда-то, скажем из библиотеки профилей внутри программы.

Вот этих самых Maker/Model/прочих метаданных содержащихся в файле - достаточно для интерпретации той "азбуки", которая содержится в данных.

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

kotjara_zone (not verified) - 03/Мар/2010 15:49

омг. мне надоело с вами спорить. объясняю последний раз. в случае рав файла цвет создается с нуля на основании данных о яркости и расположении всего ТРЕХ цветовых сенсоров на шаблоне (которые, опять же, никакого цвета не передают).
в случае с тиф или любым другим форматом - информация об уже расчитанном ранее цвете восстанавливается из сжатого состояния согласно таблице цветов (читай: согласно координатам цвета в любой из существующих цветовых моделей. и в большинстве случаев таких цветов НЕ три).
даже если бы данные о шаблоне байера хранились внутри самого рав-файла в камере - это нельзя бы было назвать наличием данных о цвете. максимум - это наличие данных, позволяющих РАССЧИТАТЬ цвет. в тифе же имеются данные, позволяющие ВОССТАНОВИТЬ цвет. никаким РАСЧЕТОМ в тиф файле заниматься не нужно.

когда вы говорите, что большинство RAW-форматов - это TIFF/EP, формат данных такой. возникает собсно два вопроса: 1) "большинство РАВ-форматов" не открыты для свободного доступа. откуда в таком случае, у вас информация об их внутреннем строении? 2) меня вообще сейчас мало интересует СТРОЕНИЕ рав-файла. возможно по синтаксису это действительно похоже на тиф. речь как бы не об этом. знаете ли, на XML тоже можно написать и сайт, и программу управления роботом. это же не значит, что сайт и ПО робота - одно и то же.

на этом предлагаю закончить эти "религиозные" рассуждения. ибо на догматизм больше смахивают ВАШИ слова.

lexa - 03/Мар/2010 16:12

Ну вы почитайте про, например, DNG COlor Model - ничем оно не отличается *принципиально* от TIFF с embedded профилем. Некоторая разница есть, но не в основных принципах. Да и конверторы делают ровно то же самое, разница только в том, что профиль находится по метаданным файла, а не содержится в самом файле.

Что же касается форматов RAW, то да, делая LibRaw пришлось с ними разобраться, грешен. С EXIF вообще проблем нет никаких, впрочем, считайте что все документировано.

kotjara_zone (not verified) - 02/Мар/2010 23:51

ну и еще по примерам:

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

последнее как я уже сказал - не тиф вообще.

что касается остальных вариантов - цветовые модели роли не играют. они опять-таки хранятся в тифе, но в раве отсутствуют. а профили (LUT или нет - не важно) применяются к уже существующему изображению. если профиль отсутствует, то применяется sRGB. следовательно профиль применяется ВСЕГДА. но это лишь ПЕРЕСЧЕТ цветов, а не ИНФОРМАЦИЯ о них. профиль содержит исходные координаты цвета и целевые координаты цвета. т.е. переводит уже СУЩЕСТВУЮЩИЙ цвет в какой-то другой.
если же вы хотите провести здесь аналогию с конвертацией рава, то там совершенно другие операции происходят. в раве нет исходного цвета. есть только данные, на основании которых этот цвет можно "угадать", создать с нуля. в тифе же хранится информация об уже существующем цвете данного пикселя. да, она (информация) сжата. но собственно на то оно и сжатие БЕЗ ПОТЕРЬ, чтобы исходный цвет всегда можно было однозначно восстановить.

lexa - 03/Мар/2010 08:58

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

Давайте возьмем какой-нибудь хороший случай. Ну вот задник PhaseOne с известным сенсором. К этому сенсору производителем опубликованы кривые спектральной чувствительности, а значит мы можем цветовой отклик камеры заранее рассчитать и получив данные реального снимка - цвета восстановить. Вас смущает то, что нужных данных нет в самом RAW-файле? Это неважно, в RAW-файле есть достаточно данных для однозначной идентификации порядка пикселов и цветовых характеристик светофильтров.

Вас, по всей видимости, вводит в заблуждение тот факт, что прямое восстановление цвета с RAW-данных дает плохую фотографию? И требуется редактирование (в конверторе или еще где), чтобы получить нормально выглядящий снимок?
Ну так причина тут не в том, что в RAW нет информации о цвете, а в том, что у нас там - линейный отклик. А для красивого снимка нужна S-образная тоновая кривая (условия просмотра другие, надо поднимать контраст). В пленочной фотографии эта кривая накладывалась слайдом или комплексом пленка-бумага, а в цифровой - камерой (получается Jpeg) или RAW-конвертором.

kotjara_zone (not verified) - 03/Мар/2010 16:22

>и получив данные реального снимка - цвета восстановить
не восстановить - а именно расчитать. вы сначала правильно написали: цветовой отклик камеры заранее рассчитать. вот именно этого действия и не нужно делать в случае тиф. нам не нужно ничего РАСЧИТЫВАТЬ.
каждый пиксель файла тиф содержит информацию о цвете в виде сразу НЕСКОЛЬКИХ координат в цветовом пространстве. (например координаты L, a, b или R,G,B). файл рав, даже после сопоставления с шаблоном, содержит максимум ДВЕ координаты: яркость и всего ОДИН из трех возможных цветов шаблона - R,G,B. и если яркостные данные еще можно назвать координатой будущего цвета - то информация о цвете фильтра в шаблоне над конкретно этим пикселом ну никак не является координатой пикселя в цветовом пространстве. даже если мы рассмотрим простарнство RGB. чтобы это были координаты - мы должны получить координаты по ВСЕМ ТРЕМ осям - зеленой, красной, синей. в рав мы не имеем ни трех координат, ни даже каких-то конкретных чисел хотя бы одной из этих осей.
фактически, в формате тиф цвет каждого пикселя никак не зависит от цвета его соседей. в рав (после декомпрессии, но до апроксимации) во-первых нету как таковых пикселей (точнее, их меньше чем в результирующем файле), во-вторых цвет будущего пикселя после апроксимации будет зависеть не только от цвета и яркости данного элемента матрицы, но и от данных с соседних элементов.
формат тиф вам говорит: вы сейчас находитесь на высоте 300 метров, в 55° с. ш. 37° в. д. формат рав вам говорит: вы находитесь в 40 км от пункта А, ваш брат - в 300м от пункта В, а ваша мама - в 100км от пункта С. если вы считаете, что такие данные содержат информацию о вашем (и только вашем, но не мамы) расположении - это ваше право. тогда нам спорить не о чем. меня же учили (и я с этим полностью согласен), что такие данные не являются моими координатами (по крайней мере в общем случае). это не более чем вводные. при чем ТОЛЬКО на основании этих данных я НЕ смогу расчитать свое местоположение (если у меня не будет данных о координатах пунктов А, В и С и моем расстонии до "брата" и "мамы").

>Вас смущает то, что нужных данных нет в самом RAW-файле?
смотрите предыдущий ответ.

>Вас, по всей видимости, вводит в заблуждение тот факт, что прямое восстановление цвета с RAW-данных дает плохую фотографию?
нисколько.

lexa - 03/Мар/2010 16:38

Не, я натурально не понимаю. Вот есть TIFF с профилем вроде ProPhoto. Для показа мы делаем пересчет в PCS, из PCS в пространство показа.

Вот есть RAW-TIFF/EP мы наморщили один раз ум и по спектральным данным (или по измерениям) строим матричный профиль для данных Maker/Model.

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

kotjara_zone (not verified) - 03/Мар/2010 17:09

>Вот есть TIFF с профилем вроде ProPhoto. Для показа мы делаем пересчет в PCS, из PCS в пространство показа.
есть координаты точки в декартовой СК. пересчитали в цилиндрическую, затем в сферическую/инопланетянско-галактическую.

>Вот есть RAW-TIFF/EP мы наморщили один раз ум
есть история с "мамой-братом-мной". мы один раз наморщили ум и допуситм запомнили, что "мама" отвечает за координату X, а "брат" - за координату Z. и может быть даже запомнили координаты пунктов А,В и С (хотя не уверен что в этой аналогии такое "запоминание" просиходило бы).

по-прежнему нет никаких отличий?
как вы не поймете, вам, в любом случае, одной только информации "вы находитесь в 40 км от пункта А, ваш брат - в 300м от пункта В, а ваша мама - в 100км от пункта С" будет мало для получения конкретно ваших координат. результат расчета ВАШИХ координат в глобальной СК зависит от координат "мамы" и "брата". а вот в какую СК вы в дальнейшем будете переводить свои высчитанные координаты - нас не сильно волнует. хоть в сферическую, хоть в любую другую.
если вернуться от аналогии к нашим баранам файлам - то давайте вспомним, что все преобразования профилей из одного в другой происходят уже после генерации тиф-файла (или jpg) из рав. следовательно, все пространства показа нас начинают интересовать только ПОСЛЕ генерации tif/jpg из рав. другими словами, если цветовое пространство sRGB или ProPhoto является пространством координат, то фильтр байера координатной плоскостью никак не является. следовательно, назвать данные из рав координатами цвета мы не можем. пересчет ProPhoto -> PCS является пересчетом из одного координатного пространства в другое (есть как исходное, так и целевое пространство). в случае рав у нас есть только целевое координатное пространство.

lexa - 03/Мар/2010 18:27

Давайте по пунктам
1) Байеровский (или фовеоновский) сенсор дает уникальные отклики для каждого "цвета" входного сигнала. Со всякими особенностями вроде метамеризма (отличающегося от метамеризма человека в общем случае), но не об этих особенностях сейчас речь.
2) Таким образом, мы имеем дело с колориметром, кривым, косым, но колориметром.
3) Пересчет данных из такого кривого колориметра в PCS ничем принципиальным не отличается от пересчета из, скажем, идеального ProPhoto-колориметра. Математика та же самая, данные для пересчета (матрица поворота для матричного профиля) - другая.

Разница только в том, что сами данные для пересчета принято не таскать с собой в файле (да и то, DNG - таскает, тот же PhaseOne - таскает, фуджи - таскает, т.е. у многих - принято), а определять по Make/Model

давайте вспомним, что все преобразования профилей из одного в другой происходят уже после генерации тиф-файла (или jpg) из рав. следовательно, все пространства показа нас начинают интересовать только ПОСЛЕ генерации tif/jpg из рав.
Да ладно, когда мне RAW-конвертор или там WIC-кодек показывает файл на экране - никакого tif/jpg нет.

kotjara_zone (not verified) - 03/Мар/2010 20:20

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

>тот же PhaseOne - таскает
не понял. P1 - это софт. а мы говорим о файле из камеры.

>Да ладно, когда мне RAW-конвертор или там WIC-кодек показывает файл на экране - никакого tif/jpg нет.
для показа картинки пересчет сохраняется ну,.. вероятно, в кэше. по крайней мере, непосредственно данные в файле этот пересчет не затрагивает (не перезаписывает) - следовательно нам не интересен. фактически мы виртуально создаем jpg и его просматриваем.

lexa - 03/Мар/2010 21:20

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

Я вижу разницу только в источнике цветового профиля, в RAW-файле он не всегда есть (да и когда есть - его не всегда используют) и в этих случаях его носят снаружи. Ну да.


>тот же PhaseOne - таскает
не понял. P1 - это софт. а мы говорим о файле из камеры.

Ну вот вы вписались с шашкой защищать свои религиозные догмы, а о предмете разговора имеете лишь примерное представление (DNG, PhaseOne, форматы RAW).

PhaseOne - это компания такая. Выпускает софт Camera One (он же C1) и цифровые задники для среднего формата (и цифровые камеры, по меньшей мере формально, по факту это совместно с мамией). В RAW-данных с этих задников - есть цветовой профиль, его вставляет прямо камера/задник.

Кривость же колориметра - дело такое, да primaries там получаются странные, если к ним формально подходить, ну так не дал нам ICC нормальной модели для ЦФК, обходимся чем есть, в существующей модели камеры действительно выглядят странновато (что не мешает для показа данных оттуда использовать стандартную color engine, если там нет ошибок/ненужных ограничений).

kotjara_zone (not verified) - 03/Мар/2010 22:09

>чем это отличается от ситуации, когда Adobe Photoshop делает совершенно аналогичный пересчет для TIFF-файла (и показывает его же на экране)

да ничем не отличается. только при чем здесь это? мы говорим о ФАЙЛЕ, а не о том, что с ним делает СОФТ. а если софт будет принтскринить doc файлы и сохранять в jpg - вы скажете, что doc и jpg одно и то же?

> и цифровые задники для среднего формата
ок, буду знать. кстати софтина зовется Capture One, а не Camera One.

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

lexa - 03/Мар/2010 22:26

да ничем не отличается. только при чем здесь это?

Да как-бы притом, что вы писали длинные простыни про то, что разница есть, что-то РАССЧИТЫВАЕТСЯ, а где-то, наоборот ВОССТАНАВЛИВАЕТСЯ. По одним и тем же формулам из довольно близких данных, да.

Вопрос то не такой теоретический, как может показаться, он определяет подход к обработке (да и съемке): если в исходном RAW "цвета нет", а потом какой хотим, такой и нарисуем - это один подход. Если "цвет есть", обязательной коррекции (в силу особенностей восприятия) требует только тоновая кривая, а остальное - опционально, то это совсем другой подход.

kotjara_zone (not verified) - 04/Мар/2010 00:08

вы меня не совсем поняли. из чего скалывадется обработка файла: сначала мы каким-то образом получаем данные о цвете пикселя, затем эти данные переводим в нужное цветовое пространство, затем отображаем на экране или на печати. так вот не знаю как вы, но я говорил исключительно о первом этапе обработки. и если в случае рав нам на этом этапе необходимо сопоставить имеющийся у нас сигнал с каждого фотосенсора (а больше ничего нет) с его расположением в шаблоне, то для тиф нам этого делать УЖЕ не надо (это сделано раньше), а достаточно провести операции декомпрессии имеющихся данных - и согласитесь, это совершенно разные вещи. при чем заметьте, операция сопоставления все-равно ВСЕГДА происходит. только при съемке в tif или jpg она происходит внутри камеры во время записи файла. а в случае с рав мы отадем это действие более мощному, чем процессор фотоаппарата, ядру компьютера. другими словами, как вы ни крутите, но тот же самый тиф - это уже пережеванный полуфабрикат, выданный камерой ПОСЛЕ операции сопоставления. а полуфабрикат никак не может быть одинаков со свежим мясом.
а о том, что происходит в дальнейшем - говорить смысла не имеет. если на то пошло, то в случае jpg будут происходить ровно те же операции - перевод цветов в целевое пространство и отображение на экране.

>если в исходном RAW "цвета нет", а потом какой хотим, такой и нарисуем
по сути так оно и есть. другое дело, что это "хотим" запрятано достаточно глубоко. если вы рассматриваете этот вопрос с позиции "а можем ли мы залезть и простым движением получить НЕ ТЕ цвета" - то действительно разница не большая. что там, что там - изменить итоговые цвета можно только кривыми или вмешательством в программные файлы. только это совсем другая песня и совсем другие пляски.

похоже вы все-таки путаете СОДЕРЖАНИЕ ФАЙЛА с СОДЕРЖАНИЕМ СИСТЕМЫ, в которую входит не только рав-файл, но и компилятор с его библиотеками для камеры. другими словами, вы путаете техническое содержание полей данных файла с тем результатом, который вам выдает софт на экран. формат тиф технически содержит в себе поля, описывающие ВСЕ ЦВЕТА присутствующие в картинке - таблицу цветов. формат рав содержит только таблицу яркостей и в некоторых случаях - данные о расположении всего трех цветов шаблона. таблицы всех цветов изображения он не содержит. именно в этом и заключается разница, именно это и позволяет мне сказать, что рав не содержит информацию о ЦВЕТЕ в картинке.
а если рассуждать именно внутри СИСТЕМЫ, то в принципе можно сказать, что рав-формат вы вообще никогда не видите. вы видите всегда только слепок с него, полученный каки-либо способом. точно также никогда вы не увидите и настоящий файл формата hdr.

lexa - 04/Мар/2010 09:12

Вы совершенно зря пытаетесь объяснить мне разницу между "СОДЕРЖАНИЕМ ФАЙЛА" и "СОДЕРЖАНИЕМ СИСТЕМЫ".

У нас две системы:
1) TIFF-файл + вложенный профиль - Color Management System - программа показа (+ куча бумаг от ICC и Adobe, где написано как TIFF раскодировать и как работать с профилем, причем и в работе с профилем многое отдано на откуп реализатору CMS)

2) RAW-TIFF-файл + вложенные метаданные - Color Management System - программа показа (+гораздо меньше бумаг, многие тонкости в метаданных приходится с кровью выцарапывать не в смысле раскодирования, а в смысле интерпретации)

Не вижу принципиальной разницы.

kotjara_zone (not verified) - 04/Мар/2010 14:04

я уже объяснил разницу, вы меня не слышите.
вы пытаетесь найти разницу в работе СИСТЕМЫ. а я говорю о разнице ФАЙЛОВ. какой смысл обсуждать всю систему в целом, если отображение любого изображения использует ровно те же принципы? для JPG эта система тоже ничем не будет отличаться.

lexa - 04/Мар/2010 14:58

В таком случае мы должны делить RAW на две группы
1) с embedded профилем: DNG, PhaseOne, Fuji (я на самом деле на эту деталь не смотрел - может и еще где есть)
2) без такого профиля, только с метаданными позволяющими профиль однозначно идентифицировать.

Но обрабатывают то их одинаково, той же С1 нет никакой разницы .CR2 у меня или сделанный из него DNG.
Какая-то очень формальная разница получается, на практике совсем незначимая.

kotjara_zone (not verified) - 04/Мар/2010 23:29

можно и поделить. только вот профиль - это все-равно не таблица цветов, а всего лишь описание шаблона. поэтому действительно обрабатываются такие файлы одинаково, и действительно делить на две группы особого смысла не имеет. хотя формально - да, можно.

>Какая-то очень формальная разница получается, на практике совсем незначимая.
ну не формальная, но на практике для фотографа - действительно не сильно значимая деталь. я же написал, если вы рассматриваете этот вопрос исключительно с позиции "а можно ли поменять цвета" - то разницы между тифом и равом особой не будет.

lexa - 04/Мар/2010 23:42

профиль - это все-равно не таблица цветов, а всего лишь описание шаблона.
Временами я отчаиваюсь вас понять. Какого такого шаблона? Который рвет?

Профиль - это правила пересчета из данных файла в PCS и обратно. Не таблица цветов, но данные для ее генерации.

В JPG "с профилем" - уж точно такой же (по смыслу) профиль, как в RAW c PhaseOne.

kotjara_zone (not verified) - 05/Мар/2010 00:07

>Какого такого шаблона?
который фильтр байера

> Не таблица цветов, но данные для ее генерации
ну так это разные вещи.

>уж точно такой же (по смыслу) профиль
по какому же такому смыслу он такой же? jpg вообще является форматом сжатия с потерями. о чем тут говорить? забудьте вы про pcs. =) мы рассматриваем работу с файлом ДО его взаимодействия с pcs.

кстати, если вам нужна чисто практическая разница между тифом и равом: на сколько я знаю, 16-битные тифы камеры писать не умеют, следовательно в тифе содержится как минимум на 4 разряда меньше информации, чем в рав. а то и на все 6.

lexa - 05/Мар/2010 09:22

который фильтр байера
Ой, да наплюйте. Если интересен именно цвет, можно четверки пикселов рассматривать как один, четырехкомпонентный.

Если продолжает волновать - давайте Sinar 4-shot обсудим или фовеон.

по какому же такому смыслу он такой же?
Интерпретация этих данных Color Management System в точности такая же. Сами данные - другие, конечно.
мы рассматриваем работу с файлом ДО его взаимодействия с pcs.
Файл не "взаимодействует" с PCS, а туда преобразуется. PCS - profile connection space.
И, в первом приближении, до преобразования в PCS - только распаковка, как и в других форматах.

на сколько я знаю, 16-битные тифы камеры писать не умеют, следовательно в тифе содержится как минимум на 4 разряда меньше информации, чем в рав. а то и на все 6.
Да нет, "в тифе" содержится 24 разряда (3 канала по 8), а "в Raw" - один канал в 10-12-14-16 бит. "в тифе" - гамма 2.2 (обычно), в RAW - 1.

Так уж сравнивать "разряды информации" я бы не стал.

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

kotjara_zone (not verified) - 05/Мар/2010 21:57

>Файл не "взаимодействует" с PCS, а туда преобразуется.
хорошо. если вам так приятнее - читайте "мы рассматриваем работу с файлом ДО его преобразования в pcs."

>Интерпретация этих данных Color Management System в точности такая же.
ага. готового цвета, или каких таких данных?

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

>Да нет, "в тифе" содержится 24 разряда (3 канала по 8), а "в Raw" - один канал в 10-12-14-16 бит.
один канал в РАВ - это моощно... но комент +) O_o и при чем здесь суммарная разрядность тифа?
8 бит на каждый канал - в тиф, против 10-16 бит НА КАЖДЫЙ КАНАЛ - в рав.

lexa - 05/Мар/2010 22:41

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

Почему это "без привязки" ? Какой пиксель какого цвета (за каким фильтром) - известно для каждого файла, у многих в EXIF написано
Вот на олимпусовский ORF напустил exiftool:
CFA Pattern : [Red,Green][Green,Blue]
И там же есть цветовая информация:
Color Matrix : 362 -92 -14 -32 336 -48 -2 -76 334
ага. готового цвета, или каких таких данных?
То есть практически готовый цвет.
8 бит на каждый канал - в тиф, против 10-16 бит НА КАЖДЫЙ КАНАЛ - в рав.

Так в RAW в каждом пикселе - один канал, а в tiff - 3 канала.
Не, получается что у tiff - толще. Если вам так хочется меряться разрядностью, уж не знаю к чему вы это.

kotjara_zone (not verified) - 05/Мар/2010 23:31

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

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

>Так в RAW в каждом пикселе - один канал
не в пикселе, а в сенсоре. а таких "пикселей" 4. если уж совсем буквоедничать - в РАВ у нас 10..16 бит на красный канал, 10..16 - на синий, и 2х(10..16) бит на зеленый.

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

lexa - 06/Мар/2010 00:51

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

после операции сопоставления данных о яркости на сенсоре с его расположением в фильтре
А что там сопоставлять то, в EXIF все написано, тривиальная операция.

А вот насчет 4 сенсоров вы кажется заблуждаетесь. Вот берем 20-мегапиксельную камеру, в ней будет 10 млн. зеленых пикселов и по 5 млн красных и синих. А в "тифе" - 20 млн трехкомпонентных значений.

Т.е. даже для 14-битного сенсора - в RAW будет 280 мегабит данных, а в 8-битном тифе - 480 тех же самых мегабит.

ога. по-вашему, тиф содержит больше градаций (читай: информации), чем рав?.
Толку то с тех градаций в раве. Линейная гамма, значит 3/4 всех градаций - это верхние два стопа, где хватило бы и в 8-10 раз меньше.
А в тенях наоборот нихрена нет в смысле градаций (их и в результате обработки тоже будет не сильно больше).
Линейный сенсор - это от большой тоски, считать там градации можно, но бессмысленно.

kotjara_zone (not verified) - 06/Мар/2010 14:14

>А в "тифе" - 20 млн трехкомпонентных значений.
апроксимированных из тех самых 10лямов зеленых и 5 лямов кр и синих, ога. не смешите. погуглите хотя бы, а? http://www.nix.ru/support/faq/show_articles.php?number=609&faq_topics=JP...
впрочем.. снимайте в тиф, забудьте про рав. на здоровье. ваше право.

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

кстати последний вопрос, по поводу exif из предыдущего поста. поле Color Matrix : 362 -92 -14 -32 336 -48 -2 -76 334 содержит только приведенные 9 значений? или вы его сократили?

lexa - 06/Мар/2010 14:32

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

поле Color Matrix : 362 -92 -14 -32 336 -48 -2 -76 334 содержит только приведенные 9 значений?
А сколько вам надо? Это матрица поворота из RGB камеры в XYZ, 3-компонентный вектор (предполагая что зеленый - одинаковый) больше ни на что толком и не умножить.

kotjara_zone (not verified) - 06/Мар/2010 14:43

ок, спс

про термины уж помолчали бы.. общедоступный вы наш xD +))

lazybird_ru (not verified) - 27/Фев/2010 20:28

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

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

lexa - 27/Фев/2010 20:44

Да нет, при пейзажной съемке есть масса возможностей влиять на тон, контраст и многое. Начиная с фильтров и кончая банальным выбором "снимать"/"не снимать" (потому что свет неподходящий, например).

lazybird_ru (not verified) - 27/Фев/2010 21:21

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

photo_vs (not verified) - 27/Фев/2010 22:48

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

photo_vs (not verified) - 27/Фев/2010 21:59

>>Если же снимаете пейзаж, то стоите перед фактом,
нет.
это вы стоите перед фактом
а я снимаю пейзаж такой какой я хочу. Сколько у меня может на это уйти времени - это другой вопрос.
Но снимать пейзажи проще - потому что это лишь вопрос терпения :)

>>вот было чуть темнее на точке съемки и для глаза картинка выглядит сильно непригляднее.
Вам бы книжек бы почитать чтоли.
ну хотя бы "Экспозицию" Гонта, для азов :)

lazybird_ru (not verified) - 27/Фев/2010 22:16

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

photo_vs (not verified) - 27/Фев/2010 22:21

>>тут без готового результата спорить не о чем

без готового результата у вас?
если вы не снимаете - к чему пстые разговоры.
я лично по работе привык умудряться снимать техногенный коммерческий пейзаж типа "из говна конфетку"
собссна там иных вариантов и нет. в РФ.

lazybird_ru (not verified) - 27/Фев/2010 22:53

> я лично по работе привык умудряться снимать
> техногенный коммерческий пейзаж типа "из говна конфетку"

Плавали, примерно знаем, ничего особо сложного по сравнению с природой там нет.

> собссна там иных вариантов и нет. в РФ.

Каков фотограф, таков и зритель. В РФ. :)

lazybird_ru (not verified) - 27/Фев/2010 22:56

> я лично по работе привык умудряться снимать
> техногенный коммерческий пейзаж типа "из говна конфетку"

Плавали, примерно знаем, ничего особо сложного по сравнению с природой там нет.

> собссна там иных вариантов и нет. в РФ.

Каков фотограф, таков и зритель. В РФ. :)

lazybird_ru (not verified) - 27/Фев/2010 22:18

И снимать пейзаж тяжелее. Возможно даже тяжелее всего. Пейзаж это не фунт изюму с сиськами. :)

photo_vs (not verified) - 27/Фев/2010 22:25

>>И снимать пейзаж тяжелее. Возможно даже тяжелее всего.

нет, тяжелее всего снимать красивое ню (не порно). т.к. у природы не бывает ПМС, и она не стесняется, а просто есть сама по себе.

ну и даже по времени - пейзаж как правило длится 1-2-5 секунд, в редких случаях доли с, а в остальных случаях - это обычное явление.

lazybird_ru (not verified) - 27/Фев/2010 22:42

>>И снимать пейзаж тяжелее. Возможно даже тяжелее всего.

> нет, тяжелее всего снимать красивое ню

Ну понятно, каждый считает, что у него и работа самая трудная и т.д.

> т.к. у природы не бывает ПМС, и она не стесняется,

Ну да, не кривляется перед камерой.

> а просто есть сама по себе.

Но это не причина вовсе. В общем тут спорить не получится.

> ну и даже по времени - пейзаж как правило длится
> 1-2-5 секунд, в редких случаях доли с, а в остальных
> случаях - это обычное явление.

Это если со стороны смотреть, то да, так и кажется. Вот сидит пейзаж, пришел и снял его -- какие, казалось бы, проблемы. Только получилась фигня. :) Было бы легко, был бы выход не одно фото в месяц.

photo_vs (not verified) - 27/Фев/2010 22:46

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

>>Только получилась фигня. :)
ну теперь понятно почему у вас получается "фигня".
Учиться не пробовали? прежде чем так тупо пиздеть?

lazybird_ru (not verified) - 27/Фев/2010 23:06

> покажите свою "трудную" работу - у вас одна болтовня в журнале

"Индастриал" что-ли? Ну вот http://www.sergeignatkin.ru/images/_others/lj/TP-7214.jpg

> ну теперь понятно почему у вас получается "фигня".
> Учиться не пробовали? прежде чем так тупо пиздеть?

Вы по своему уровню соответствуете уровню своих фотографий?

photo_vs (not verified) - 27/Фев/2010 23:11

>>Ну вот
ну вот это типичный мусор, а когда таким пытаются еще и поучать - совсем грустно.

>>Вы по своему уровню соответствуете уровню своих фотографий?
альбом подарить или календарь?
вам собссно что от меня нужно? я уже устаю :(

lexa - 27/Фев/2010 23:31

вам собссно что от меня нужно? я уже устаю :(

Я долго сдерживался, но удержаться невозможно, ничего личного.

нет, мужик, не на охоту ты сюда ходишь...

photo_vs (not verified) - 27/Фев/2010 23:40

ок, я ухожу

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

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

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

lexa - 27/Фев/2010 23:53

ок, я ухожу

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

Но если такая форма для Вас - единственно возможная, я готов ее терпеть ради интересного собеседника.

photo_vs (not verified) - 27/Фев/2010 23:56

>>зачем же Вы к ним ходите

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

я написал в личку
меня устало, жж - это пиздец.

lamantyn (not verified) - 28/Фев/2010 21:39

а если интернет засрали в конец - что вообще отсюда уходить?

Если бы только интернет ... они же и по улицам ходят ...
"Нет ли у вас другого глобуса?" (c)

photo_vs (not verified) - 28/Фев/2010 21:42

>>они же и по улицам ходят ...

по разным улицам. шансов пересекаться практически нет.

lamantyn (not verified) - 28/Фев/2010 21:56

Закрытое сообщество, прием по рекомендации - и будет вам счастье.

photo_vs (not verified) - 28/Фев/2010 22:06

>>Закрытое сообщество, прием по рекомендации - и будет вам счастье.

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

lexa - 27/Фев/2010 07:52

Нет, задачи точной цветопередачи нет (кроме скинтонов, зеленого и нейтрали)

Но есть задача повторяемости и если при ETTR цвет уезжает (а de=9 - это большой уход), то это повод задуматься "а отчего оранжевые закаты становятся желтыми"

pavel_kosenko (not verified) - 27/Фев/2010 09:26

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

lexa - 27/Фев/2010 09:38

Так и я о том - условия одни, калибровка одна (адобовская), а результат с ETTR и без - очень разный.

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

pavel_kosenko (not verified) - 27/Фев/2010 09:43

А, понял. Просто в одних условиях я бы и снимал одинаково ежели с ETTR, то уж с ним. Ежели без него, то уж без него :) Но я Вашу мысль понял, спасибо за пояснения.

lexa - 27/Фев/2010 10:00

Вот мы снимаем некий объект (не обязательно ColorChecker) "по экспонометру", получаем одни цвета.
Допустим, они нас устраивают (как начальная точка редактирования).

Теперь делаем +1.67 (никакого вылета нет на моей камере), снимаем опять, коррекция в конверторе чтобы серая шкала встала на место, опа, другие цвета, оранжевый пожелтел.

Не является ли это поводом задуматься, что для ETTR нужен "другой профиль", который приведет нам объект в тот же начальный вид.

Т.е. чтобы ETTR исполнил свою функцию снижения шумов, а функцию сдвига цветов - не исполнял бы.

pavel_kosenko (not verified) - 27/Фев/2010 10:14

Я лишь хотел сказать, что в реальной жизни вовсе не обязательно пользоваться серой картой :) Я, например никогда не пользуюсь, всегда задаю цвет согласно своему восприятию. Поэтому для меня кула важнее шумы, а цветовые смешения меня практически не волнуют. Другое дело, что те де 5д2 и д700 настолько малошумны, что не могу с вами не согласиться по сути статьи. Я просто хотел сделать пометку на полях, что это знание надо использовать с умом и примеряя к своим задачам. Я иногда довольно сурово обрабатываю картинки и мне запас на соотношение сигнал/шум в тенях важен. Это просто для примера.

lexa - 27/Фев/2010 10:20

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

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

pavel_kosenko (not verified) - 27/Фев/2010 10:34

Что Вы имеете в виду снизить контраст на этапе съемки?

lexa - 27/Фев/2010 10:50

Ну масса же способов. Возьмите камеру/оптику с большим светорассеянием, например. Хотя обычно делают фильтрами.

Помимо градиентников (применимых не всегда), есть вот такое, например: http://www.tiffen.com/contrast_filters.htm (кроме Tiffen их делает, например, Шнайдер, да и Formatt тоже кажется), снимающие на пленку киношники их очень уважают. А можно просто сетку или софт.

pavel_kosenko (not verified) - 27/Фев/2010 12:49

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

lexa - 27/Фев/2010 13:07

Обдуманно - пожалуйста. "Если вас не интересует цвет".

Я то адресуюсь скорее к тем, кто пользуется "потому что так меньше шума, мне так сказали".

Pasch (not verified) - 27/Фев/2010 15:00

Ну, не то чтобы просто сказали. Все-таки не раз была возможность убедиться, стоит только начать вытягивать тени. По крайней мере, на своем Canon 30D я не могу игнорировать увеличение шума при их вытягивании. Проще потом "перекрасить" закат :)
На аппарате класса 5D MarkII - другое дело.

lexa - 28/Фев/2010 11:07

30D - не такая уж плохая камера и рабочий диапазон там всяко не меньше чем у слайда.

А со слайдом "вытягивали тени" на этапе съемки, для цифры этот метод никуда не делся.

Pasch (not verified) - 28/Фев/2010 11:31

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

lexa - 28/Фев/2010 12:10

Мой поинт в том, что ETTR - это не бесплатно даже без вылета в силу как отеческой заботы Adobe о нас (twisted profiles), так и небольшой нелинейности камер.

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

Pasch (not verified) - 28/Фев/2010 12:57

Логично, согласен.
Пожалуй, только одно "но".
Ситуация, когда диапазон сцены небольшой и мы легко можем его укладывать в диапазон матрицы разными способами (например ,прижимая его вправо, по ETTR)- не такая частая, на самом деле.
ETTR был придуман для случаев, когда диапазон сцены заведомо больше диапазона матрицы и говорит он нам ровно об одном - постараться экспонировать так, чтобы не выбить света в ноль, при этом недодержка средних тонов и теней все равно останется. Просто мы стараемся ее минимизировать, сохранив при этом хоть какие-то света.
А если матрица у нас позволяет передать диапазон сцены без лишних ухищрений - ну и замечательно, "лучше быть здоровым и богатым ,чем бедным и больным".

lexa - 28/Фев/2010 13:33

Какая-то для меня загадочная ситуация, поправьте меня если я где-то ошибся
1) Контрастная сцена (не влезает в диапазон матрицы)
2) речь идет о ETTR т.е. о сдвиге экспозиции вправо т.е. в плюс (от того, что мы намеряли спотметром по тому объекту, который станет полутоном на отпечатке).
3) Но при этом сдвиге в плюс у нас света не выбиты т.к. реально контраст между полутонами и светами очень мал. Но при этом контрастная сцена.

Не, не могу себе представить. Обратную ситуацию, когда светов слишком много и мы вынуждены недодерживать, чтобы их не выбить - легко себе могу представить (любой контровик; источники света в кадре), а ситуацию когда от светов до полутонов меньше ~3 стопов (обычный headroom ЦФК) и контрастная сцена - представляю себе с трудом. "Сцена контрастная в тенях, а светов нет"

Поправку ошибки экспонометра (снежная баба на снегу) я не отношу к ETTR.

Pasch (not verified) - 28/Фев/2010 15:10

Все верно, вы правы.

Ib (not verified) - 27/Фев/2010 18:56

Цвет заката, который Вам нужен - это не выход, потому что это не фотография заката.

Pasch (not verified) - 27/Фев/2010 21:44

Вы имеете в виду, что такая цифровая обработка не допустима? А какая допустима?

ib (not verified) - 28/Фев/2010 02:05

Я имею в виду что:

а) заказчик не примет "нужные мне" цвета заката

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

в) живопись по фотографии - это к Глазунову с Шиловым

Pasch (not verified) - 28/Фев/2010 11:01

а) А какие цвета заката он примет? Он стоит рядом с Вами и видит этот закат?
Или он заранее знает, какой цвет там должен быть? Тогда тем более не важно, _что_ снимет камера, если на выходе от нас потребуют какого-то определенного цвета.
И какая разница этому заказчику - каким именно способом был получен требуемый ему цвет?
ИМХО, в контексте обсуждения, "отдельный заказчик" - лишняя сущность.
Представим, что фотограф и заказчик - в одном лице.

б) Ок, а за деталями в тенях мы тоже охотились? Или мы ими можем пренебречь?

в) Это красивая фраза, но критерий-то каков? Где заканчивается допустимая, "нормальная" обработка фотографии и начинается "живопись по фотографии"?

lexa - 28/Фев/2010 11:10

По пункту в) понятно что точного критерия талии нет.

Шкала большая
- холст и краски
- ч-б фотография и краски
- какая-то цветная фотография с абстрактными цветами и краски
- небольшая цветокоррекция
- сразу нужная фотография

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

Pasch (not verified) - 28/Фев/2010 11:37

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

Pasch (not verified) - 28/Фев/2010 12:19

Хотя, именно _монотоность_ трудоемкости в данной шкале нуждается в уточнении, ИМХО.
Мы оцениваем только трудоемкость обработки изображения? Тогда в последнем случае она, конечно, нулевая.
Но какова трудоемость получения сразу готовой фотографии, не нуждающейся в последующей обработке?
Полагаю, что бывает проще закрасить в фотошопе несколько бутылок-бумажек, чем ходить убирать их по берегу реки :)

lexa - 28/Фев/2010 13:12

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

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

Конечно, есть обратные ситуации, когда и штатив поставить некогда...

Ib (not verified) - 28/Фев/2010 11:18

> А какие цвета заката он примет? Он стоит рядом с Вами и видит этот закат?

Вы считаете, заказчик не знает, что он хочет? Вы думаете, что если греки мне заказывают календарь, они считают своих соплеменников слепыми идиотами, которым закат в Ялте можно выдать за закат на Кипурье?

> Представим, что фотограф и заказчик - в одном лице.

Да, снимаем "для себя".

> критерий-то каков?

Деньги, разумеется. За "раскраски" мне не заплатят.

Pasch (not verified) - 28/Фев/2010 11:49

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

>> Представим, что фотограф и заказчик - в одном лице.
>Да, снимаем "для себя"

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

>Деньги, разумеется. За "раскраски" мне не заплатят.
Вот этот тезис раскройте, пожалуйста. Какая степень обработки является "раскрасками", а какая - еще нет? И, раз уж вы сами заговорили о заказчике - как он это контролирует? Следит за вашим workflow? Или вы ему отдаете raw-файл? Или он получает готовый результат и по нему говорит: "Фу, это раскраска!"

Ib (not verified) - 28/Фев/2010 19:05

> кто ваш заказчик и чего он хочет

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

> а если заказчики а вас норвежцы?

Зарисовка южного моря, сделанная Григом в Пере, даже у норвежцев за зарисовку с натуры не проканывает. Шахрезада Римского-Корсакова не вызывает сомнений ни у южан, ни у северян.

> Какая степень обработки является "раскрасками"

Та, при которой видна раскраска.

> как он это контролирует?

Заказчик принимает работу по пробному отпечатку.

Pasch (not verified) - 28/Фев/2010 19:21

>> Какая степень обработки является "раскрасками"
>Та, при которой видна раскраска

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

>> как он это контролирует?
>Заказчик принимает работу по пробному отпечатку.

Тем более.

Ib (not verified) - 28/Фев/2010 19:44

Вы не понимаете, что за рисовку проще заплатить профессиональному художнику? И что возможности и ограничнения у жанров разные?

Я сниму на слайд и рисовать не буду, сниму на цифру - и буду? Это, простите, чудовищно странно. Тем, кто так считает, надо много думать. И снимать.

Pasch (not verified) - 28/Фев/2010 20:48

Погодите, давайте без лишнего пафоса. Помимо градаций черное-белое есть масса полутонов. Между полностью рисованным изображением и снятым с одного кадра лежит масса градаций по степени обработки (собственно, Алексей, их привел). Я несколько раз подряд пытался у вас выяснить - какая степень обработки является для вас приемлимой и почему.
В итоге вы сказали, что единственным критерием является итоговый результат.
Я ни в коей мере _не призываю_ рисовать руками то, что можно сфотографировать. Я лишь подчеркиваю, что в такой (в вашей-же) формулировке критерия - никаких ограничений на обработку нет, лишь бы на выходе была реалистичная картинка.

Ib (not verified) - 28/Фев/2010 21:44

> лишь бы на выходе была реалистичная картинка.

Фотография, не реалистичная картинка. Ограничения на обработку - оставить фотографию фотографией и не превращать в картинку. Т.е. остаться в рамках жанра.

Pasch (not verified) - 28/Фев/2010 22:16

Хорошо, давайте еще раз. В какой момент фотография перестает быть фотографией и превращается в картинку?
В момент повышения/понижения средствами фотошопа контраста, резкости, насыщенности,.... ?
Где та граница, за которой это происходит?

Ib (not verified) - 01/Мар/2010 00:08

> В какой момент фотография перестает быть фотографией и превращается в картинку?

В тот момент, когда 3 потребителя это опознают и сообщают заказчику.

Pasch (not verified) - 01/Мар/2010 00:27

Это идеальные потребители в вакууме из Парижской палаты мер и весов?

Ib (not verified) - 01/Мар/2010 01:23

Нет, они обычно несостоявшиеся фотографы.

lamantyn (not verified) - 28/Фев/2010 23:22

"всегда задаю цвет согласно своему восприятию".

Т.е. цветопередача камеры никакого значения для вас не имеет, на самом деле. Книжка-раскраска.

pavel_kosenko (not verified) - 28/Фев/2010 23:28

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

Pasch (not verified) - 27/Фев/2010 16:41

Возникает вопрос - а решается ли эта задача в принцпе профилем. Не есть ли этот уход цвета естественным, в каком-то смысле правильным и необратимым явлением?
Грубо говоря, чем больше экспонируем, тем более светлый цвет мы получаем.
Чем больше значение L, тем ближе цвет к белому, независимо от зачений a и b - информация о цветах на самом деле теряется.
Так, в пространстве Lab мы можем выдумывать любые несуществующие цвета, но при переходе в RGB они естественно искажаются, значения цвета теряются необратимо, покольку нормальному RGB-цвету можно поставить в соответствие множество несуществующих Lab-цветов.

lexa - 27/Фев/2010 17:00

Мы же снимаем не в пространстве Lab, правильно?

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

Я вполне допускаю, что уходы цвета сделаны Adobe намеренно (тем более, что в комментариях тут про twisted profiles всплыло), но тогда это повод не использовать ETTR с этими конверторами.

Pasch (not verified) - 27/Фев/2010 21:33

ИМХО, дело здесь не в Lab как таковом, а собственно в цветовом восприятии.
Ведь глубокие тени, рано как и яркие света - нейтральны в цветовом отношении.

Например, такой мысленный эксперимент:
берем полупрозрачный фон, скажем зеленый. За ним размещаем источник света регулируемой мощности.
А дальше начинаем повышать мощность от нуля (полной темноты).
Вблизи нуля мы получим вполне серый (нейтральный) цвет. Ближе к "середине" мощности - правильный яркий зеленый, как мы привыкли, а в конце - практически белый (опять нейтральный).
И вот теперь, если нам дан на входе такой вот "почти белый зеленый", без дополнительной информации - то что мы можем по нему восстановить? Практически - что угодно, в том смысле, что единственно верного варианта не будет.

lexa - 27/Фев/2010 21:37

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

Pasch (not verified) - 27/Фев/2010 23:09

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

Попробовал так:
1. вывел в фотошопе рядом 2 плашки, (L90, a-20, b10) и (L90, a-40, b20).
2. сфотографировал по ETTR, с небольшой расфокусировкой
3. В ACR сделал отрицательную экспокоррекцию, чтобы добиться исходного значения L (в данном случае движок Eхposure = -0,56)
Получаем плашки (L90, a-10, b4) и (L90, a-23, b10)
Во-первых, соотношение каналов a и b нарушено, во вторых сами цвета значительно более "серые".
Собственно, как и ожидалось.

lexa - 27/Фев/2010 23:30

У монитора очень хороший диапазон, 8-9-10 стопов, куда больше то.

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

Вообще, вот есть у нас тот же зеленый. Пока мы на линейной части отклика камеры - у нас для этого зеленого отношение R/G/B в камерном отклике будет одинаковым (а как только перестало таким быть - вот она нелинейность). Если все сделано правильно (так, как было бы разумным ожидать) то экспокоррекция в конверторе работает эквивалентно экспокоррекции в камере - это домножение откликов на константу (одинаковую по каналам). Если сделано не так и мы от линейности по какой-то причине ушли - да, цвет уйдет. Причина этой нелинейности несущественна, важно следствие: если интересует повторяемый цвет, то ETTR не надо пользоваться.

genn_b (not verified) - 27/Фев/2010 09:15

Поскольку в Вашем хозяйстве есть колорчекер и (наверное) остались фильтры с пленочной эпохи - имеет смысл попробовать проанализировать достоверность гипотезы о линейности матрицы. У меня получалось, что использование Tiffen CCM30 и выставление ББ с ним дают визуально более приемлемый результат (не требующий правки) - чем без него. Хотя 30 было много и возможно стоило ограничиться 10 или 20.

lexa - 27/Фев/2010 09:34

От камеры зависит. На предыдущих, да, CC30M-CC40M был очень в кассу, а на 5D2 смысла от него не очень много.

andy_scott (not verified) - 27/Фев/2010 11:50

Да от лукавого эти заморочки. Плевал я на шумы в тенях, мне главное, чтобы света не выбило в простыню безвозвратно.

Amidov (not verified) - 01/Мар/2010 17:18

Один из немногих действительно полезных и толковых ресурсов.

vladimirovich (not verified) - 19/Мар/2010 00:46

Алексей, я провёл эксперименты с dcraw. Вкратце, на режиме без цветокррекции описаная вами проблема не наблюдалась.

Вот картинка, она комбинирована из четырёх. На белом квадратике написано, с какой экспозицей снимался каждый кусочек, если не всматриваться в разницу цветов, то её легко и не заметить, она заметна только на "-6". Откройте её в фотошопе, по шуму можно определить, что это на самом деле четыре разных картинки.

Делалось так. Мишень colorchecker была снята в условиях электрического освещения. Потом картинки проявлены следующим скриптом:

@echo off

set common=-q 3 -6 -T -f -v -H 9 -S 14470
set outcolor=-o 0 -g 2.2 0.0

set darkframe=-K D:\Photo\#presets\5dmk2.darkframe\noise_iso_200_lined.pgm

set whitebalance=-r 1.000 1.000 1.000 1.000

echo on
dcraw %common% %whitebalance% %incolor% %darkframe% %outcolor% %cromatic% %1

Файл noise_iso_200_lined.pgm - карта средних шумов матрицы, если нужно объяснить что это такое, я объясню.

Дальше в фотошопе ко всем четырём картинкам были применены одинаковые значения levels, чтобы компенсировать баланс белого. Черная точка не трогалась, а вот белая вышла белой, а не зелёной.

Дальше вручную подобраны значения exposure.

Потом из файлов был собран один, поворот, кроп. Всё производилось в режиме 48 бит на канал, это важно. В остальном цвета "как есть".

Всё, матрица линейна, различий по цветам почти нет, exposure to the right работает отлично.

lexa - 19/Мар/2010 07:22

Я вполне осознанно использовал именно Camera Raw (в Lightroom было бы то же самое). Это мессадж не вообще, а и про этот проявитель - тоже.

skoblov (not verified) - 19/Апр/2010 14:18

И как это я не заметил раньше-то? :) Бардак.

В свете последнего коммента концептуальный вывод следующий:

1. ETTR в случае "правильного проявителя" цвет не портит. ACR "правильным проявителем" не является и вносит цветовую нелинейность, причем, судя по всему, до применения экспокоррекции. До появления профилей был вообще кошмар, с профилями - есть нехорошие случаи.

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

3. Ту же "неправильность" мы можем получить и при практически любой манипуляции с фото. Причем не факт, что искажения "неправильного проявителя" на этом этапе ухудшат картинку.

http://skoblov.livejournal.com/76291.html

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

4. Про высказанную выше идею снижения контраста путем съемки на объектив с высоким рассеиванием (или применением соответствующего фильтра) - не понял. Оно же снижает глобальный контраст путем убивания картинки. Иногда годится как художественный эффект, но очень иногда. Градиентник - да, понятная вещь, жаль что ограниченного применения.

Anonymous (not verified) - 20/Апр/2010 10:06

А вроде в лайтруме и в ACR движок одинаковый?