Клинический случай

[atutubalin]

Ответ: Клинический случай

Не вижу особого смысла: ради чего? Чтобы получить колориметрическую копию самого слайда или паче отпечатка?

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

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

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

Некоторый смысл вижу вот в этом.. Некоторая экономия времени. Но не более.

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

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

 

[atutubalin]

Ответ: Клинический случай

Зачем поворачивать RAW-данные в XYZ? Чтобы делать дальнейшую коррекцию в XYZ-пространстве?

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

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

Тут смешиваются несколько практических (для разработчика RAW-конвертора) проблем
1) Вообще, преобразование из RAW в XYZ (или неважно что, главное что в "цветовые" данные) лучше делать готовой машинкой (CMS), а не убивать годы, программируя свою.

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

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

 

[Alexey Shadrin]

Ответ: Клинический случай

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

Это не предложение, а рассказ об опыте

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

Имхо, не нужно -- соотношения при этом не сильно пострадали.

Или не фильтр, а осознанно дожидаюсь теплого закатного освещения....

Ну, а это вообще никакой характеризации не требует, наоборот, она окажется даже вредной.

 

[Alexey Shadrin]

Ответ: Клинический случай

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

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

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

 

[Nikolay_Po]

Ответ: Клинический случай

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

Тут согласен, но предпочёл бы оставить RAW-данные. Я вижу более эффективным расчёт той же дебайеризации в родных RAW-значениях, но на основе масок, рассчитанных по XYZ. То есть, берём RAW, преобразовываем в XYZ (временно), преобразовываем в Lab (временно), по Lab находим границы, градиенты, линии. Строим маски и по полученным маскам делаем дебайеризацию в RAW-представлении. Получаем превосходные дебайеризованные аппаратные данные, которые не переводились никуда, соответственно, имеют минимум погрешностей. Простите, если что - сам программных реализаций не писал...

Тут смешиваются несколько практических (для разработчика RAW-конвертора) проблем
1) Вообще, преобразование из RAW в XYZ (или неважно что, главное что в "цветовые" данные) лучше делать готовой машинкой (CMS), а не убивать годы, программируя свою.

Есть принципиальные препятствия использовать ArgyllCMS? Лицензия не позволяет? К стати, отрицательные XYZ ArgyllCMS "кушает":

0.000000 0.500000 0.000000 [RGB] -> MatrixFwd -> 0.209996 0.646268 -0.072114 [XYZ]
0.000000 0.000000 0.500000 [RGB] -> MatrixFwd -> 0.035136 -0.105088 0.688395 [XYZ]

Это из профиля моей камеры.

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

Посмотрите, всё же Argyll. В последние дни были существенные доработки профилировщика дивайс-линков, сделана оптимизация поканальных кривых перед\после LUT. Почитайте.
Что такое "Bradford adaptation matrix" (я не знаю, но Грэм Гилл упомянул её в контексте ICC и баланса белого). Можно ли без неё обойтись, преобразуя ББ на уровне XYZ?

 

[atutubalin]

Ответ: Клинический случай

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

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

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

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

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

 

[atutubalin]

Ответ: Клинический случай

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

Дебайеризацию гораздо эффективнее (удобнее, меньше ошибок) вести в терминах, когда яркость отделена от цветовой составляющей.
И если вы рассчитали (интерполировали) L или Y, то вам в любом случае нужно от этой координаты перейти обратно (или туда) в RGB - а это и есть пересчет из RAW RGB в PCS и обратно.

Посмотрите, всё же Argyll.

Я его посмотрел еще в серии моих упражнений с точностью CMM 2.5 года назад, отношусь к нему очень хорошо и вообще там все очень интересно происходит, как бы его Sabos не ругал....

 

[Alexey Shadrin]

Ответ: Клинический случай

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

Необязательно: в файле изображения [в каком-то из стандартных представлений (например в фунтах стерлингов -- sRGB)] находятся данные о воздействиях объектов сцены на зрение потенциального наблюдателя; выполнив матричный пересчет по профайлу монитора, мы пересчитаем воздействия в воздействия -- например, фунты в рубли (профайл монитора). Монитор окажет расчетные воздействия на зрение фактического наблюдателя. А уж под этими фактическими (а не виртуальными воздействиями) и возникнет психофизическая реакция -- цветовое ощущение.

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

 

[atutubalin]

Ответ: Клинический случай

Необязательно: в файле изображения [в каком-то из стандартных представлений (например в фунтах стерлингов -- sRGB)]

Такое впечатление, что мы вообще говорим на разных языках.
Цифровые данные о цвете, так или иначе привязаны к цветовым координатам. Либо явно (например своим форматом: Lab/XYZ, или описанием /псевдо/устройства ), либо неявно (RGB без указания цветового пространства)

Понятно, что эту привязку можно игнорировать: отключить color management и работать как-то. Тогда привязкой будет заниматься устройство отображения. Само, без ансамбля.

Либо же я вас просто не понял - тогда выражайтесь яснее.

 

[pell]

Ответ: Клинический случай

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

Нет, в #51 и #52 приведено формальное доказательство. По модулю точности используемой аппаратуры захват любого электро-магнитного излучения всегда даёт положительные XYZ значения.

 

[Nikolay_Po]

Ответ: Клинический случай

Нет, в #51 и #52 приведено формальное доказательство. По модулю точности используемой аппаратуры захват любого электро-магнитного излучения всегда даёт положительные XYZ значения.

Это то, к чему нужно стремиться, так и получается у зрения человека. Но в камере стоят датчики, чувствительные к ИК и УФ. По этому, при попытке простого матричного пересчёта данных датчиков камеры в XYZ человека, могут возникать отрицательные значения XYZ. Вопрос: "Как корректно обеспечить положительные XYZ при матричном пересчёте из аппаратных данных"?

 

[sabos]

Ответ: Клинический случай

Но в камере стоят датчики, чувствительные к ИК и УФ. По этому, при попытке простого матричного пересчёта данных датчиков камеры в XYZ человека, могут возникать отрицательные значения XYZ.

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

Если спектральная чувствительность сенсоров есть CMF (строже - любая линейная комбинация от LMS) - ИК и УФ игнорируются, если же нет (и мы говорим "нарушен Luther-Ives"), то ИК и УФ забивает соответствующие каналы, добавляет положительные значения (!) к их ответам. Что приводит к изменению метамерности (мы говорим "метамеризм камеры"), к тому, что идентичные для зрения предметы будут разными для камеры (см. аттач).

Такие явления могут обмануть профилировщик, и он начнет с упорством стального идиота делать матрицу преобразования с отрицательными XYZ. Это не значит, что в отрицательных XYZ возник смысл, это значит, что ошибся профилировщик.

 

[sabos]

Ответ: Клинический случай

детекторы моделируются векторным же пространством сопряжённым к пр-ву, моделирующему стимулы

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

 

[sabos]

Ответ: Клинический случай

Что такое "Bradford adaptation matrix"

Как уже упоминалось в #45 - ББ нельзя делать в XYZ. Он неточен в любом xRGB (в т.ч. linRGB), в Lab/LCH и даже в мега-JCH. Наилучшую точность дает ББ по методу von Kries, масштабирование в пространстве LMS (колбочковых чувствительностей). Пространство LMS также энергетически линейно, поэтому переход в него из другого linear energy(любого lin RGB, в т.ч. XYZ) простое линейное (мы говорим linear transform или matrix). Bradford adaptation matrix - это матрица такого перехода, разработанная в университете Bradford, она, в отличие от физиологически точной матрицы HPE, снимает проблему "синего" феномена (синей нелинейности). Настолько удачно снимает, что ICC рекомендовало для ББ-алгоритмов именно её.

 

[Alexey Shadrin]

Ответ: Клинический случай

XYZ есть энергетические величины.

Исключительно точно сказано: не собственно физические (спектр) и не собственно физиологические (LAB). Именно что энергетические.

 

[sabos]

Ответ: Клинический случай

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

Мы с вами никак не можем договорится о пространстве, в котором все эти треугольники и квадранты имеют смысл. Я настаиваю на том, что пространство типичной камеры несколько не совпадает с HVS. Пространство не "больше" и не "меньше". Просто два разных пространства. Бутылка объемом 1 литр "больше" канистры объемом 1 литр?

Собственно pell говорит о том же - камера и HVS есть разные пространства, их нужно сопрягать. Не проецировать camera space (это и вправду может не вписаться в положительный квадрант), а сопрягать его с HVS. При аккуратном алгоритме мы локусом камеры обязаны сесть в локус human'a. Даже навскидку видно, что такое сопряжение не есть простая (линейная) проекция.

А интерполяция яркости по координате - хорошая, годная или плохая, негодная?

Я не противник интерполяции (как и других коммерческих задач), я лишь прошу честно разделять задачи. Справедливости ради нужно отметить, что классический шаблон Байера благодаря удвоению зеленого дает несколько повышенную пространственную по яркостному каналу. Прием, хорошо знакомый по chroma subsampling (часто называют 4:2:2). Поэтому не стану настаивать на том, что интерполяция яркости - маркетинговый обман. Но в контексте профилестроения я этих продвинутых демозаиков опасаюсь, они лишь шумов добавляют. Одновременно, если стремиться к наилучшему профилю, то мегапиксели и не нужны, там вместо демозаика аккуратное усреднение уместнее.

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

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

Здесь не понимаю. Мой опыт говорит обратное, нет никаких шансов описать нелинейную систему линейной моделью. Самый известный пример - воспроизведение. Попытайтесь построить принтеру (пусть RGB-драйверу) matrix и оцените ошибку. Они будут огромны. Аналогично и с мониторами/проекторами. Если их не привести к линейному (пусть к гамма-линейному) виду, то matrix даст неприемлемую ошибку.

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

 

[Dresden]

Ответ: Клинический случай

камера и HVS есть разные пространства, их нужно сопрягать.

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

 

[sabos]

Ответ: Клинический случай

Слона едят постепенно (с). Чем проще мы формулируем вопросы, тем легче искать ответы. Поэтому первым вопросом будет переход с минимальной ошибкой от пространства спектральных чувствительностей сенсора камеры (суммы всех фильтров+кремния) к пространству спектральных чувствительностей сенсоров (колбочек) человека. В такой постановке не обсуждаются ни встроенные алгоритмы камеры, ни RAW-конвертера, ни профилировщика, ни CMM. Сперва математика.

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

2 pell
Как видишь, снова в метрику упираемся.

 

[atutubalin]

Ответ: Клинический случай

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

Речь шла об отрицательных значениях XZ, я об этом пространстве и говорю.

Я настаиваю на том, что пространство типичной камеры несколько не совпадает с HVS. Пространство не "больше" и не "меньше". Просто два разных пространства. Бутылка объемом 1 литр "больше" канистры объемом 1 литр?

Для большинства типичных камер оно именно что "больше" в широком смысле этого слова - отклик есть для всех сигналов к которым чувствителен Human и для некоторых сигналов к коим он нечувствителен.

Собственно pell говорит о том же - камера и HVS есть разные пространства, их нужно сопрягать. Не проецировать camera space (это и вправду может не вписаться в положительный квадрант), а сопрягать его с HVS. При аккуратном алгоритме мы локусом камеры обязаны сесть в локус human'a. Даже навскидку видно, что такое сопряжение не есть простая (линейная) проекция.

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

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

Поэтому я и написал отдельный вопрос про яркость.

Здесь не понимаю. Мой опыт говорит обратное, нет никаких шансов описать нелинейную систему линейной моделью. Самый известный пример - воспроизведение. Попытайтесь построить принтеру (пусть RGB-драйверу) matrix и оцените ошибку. Они будут огромны. Аналогично и с мониторами/проекторами. Если их не привести к линейному (пусть к гамма-линейному) виду, то matrix даст неприемлемую ошибку.

(многие) Камеры достаточно линейны (после вычитания dark current, конечно), чтобы это было неплохим стартовым приближением.

Есть же три варианта
1) Мы имеем доступ к потрохам черного ящика (есть режим "raw", как у RPP или мы просто сами его делаем). В этом случае мы всю нелинейность можем там повыключить и отпрофилировать.
2) Мы не имеем вышеуказанного доступа, но имеем довольно точное понимание внутренностей оного ящика. В этой ситуации мы должны строить профиль после результата работы "гламуризаторов" (и прочих прикольных фенечек), а работать он будет до них.
Матричный профиль в этом смысле безопаснее, даже в таком ужасном виде, как он у Адоба в DNG Processing model

3) Мы даже примерно не представляем, как устроен черный ящик. Тогда остается только молиться об отсутствии у него искусственного интеллекта (вроде нормализации гистограммы) и профилировать не просто "камера+ящик", а прямо таки "камера+ящик+положение ручек ящика".

Вот для случаев 2-3 матричный профиль (который сделает поворот камерным данным) - безопаснее по очевидным причинам.

 

[atutubalin]

Ответ: Клинический случай

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

А как вы провернете фарш назад? Если камера что наделала (черный вычла, света пожала), то как вернуть как было?

Тема больная, если помнить (в частности) про света у Nikon..