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

[sabos]

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

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

Факт, разумный подход. Но внимательно, сравниваем ли мы там объемы? Нет, у Линдблюма мы сравниваем объем HVS с кубом (с ребром, равным наибольшей стороне треугольника). Тонкий момент - берем худшую сторону и возводим её в третью степень. Это не самый оптимальный способ обеспечить coding efficiency, но самый вычислительно простой -> быстрый.

Без всяких ошибок профилировщиков и т.п.

Просмотрел лишь вскользь, но не увидел анализа вида "эта часть ошибки конечно порождается несогласованностью A2B->B2A профиля, а вот эта, негодяи, не отвертитесь, точно ваш CMM гадит".

 

[atutubalin]

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

Просмотрел лишь вскользь, но не увидел анализа вида "эта часть ошибки конечно порождается несогласованностью A2B->B2A профиля, а вот эта, негодяи, не отвертитесь, точно ваш CMM гадит".

Для матричного профиля отвертеться никому не получится.

 

[sabos]

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

Для матричного профиля отвертеться никому не получится.

Безусловно. Если отрицательных XYZ не подставлять . Но разговор был о таблицах в условиях экстремальных гамма 1. Там основная причина ошибок не в CMM, там основная причина ошибок - гладкость данных ("ум сглаживателя" у профилировщика).

Из общих соображений. Такие испытания CMM полезны, но методика imho слабенькая. Задача color management состоит не в абсолютной точности RGB->PCS->RGB, а в "бережном отношении к соотношениям" (с). Слабое место color management в гладкости преобразования, в немонотонности, в появлении лишних экстремумов в output. Недавно был пример ошибки предлинеаризатора - при таком TRC (его в принципе нельзя инвертировать без существенных ошибок) нечего ждать от matrix+CMM точности. Ни абсолютной, ни бережного отношении к соотношениям.

 

[atutubalin]

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

Безусловно. Если отрицательных XYZ не подставлять . Но разговор был о таблицах в условиях экстремальных гамма 1. Там основная причина ошибок не в CMM, там основная причина ошибок - гладкость данных ("ум сглаживателя" у профилировщика).

А выбор профилировщиков в данной постановке задачи вообще невелик (если вообще есть в правильной постановке)

А цепочка преобразований - если мы говорим о цифровых камерах - наоборот велика, накопление ошибки может быть огромным.

Задача color management состоит не в абсолютной точности RGB->PCS->RGB, а в "бережном отношении к соотношениям" (с).

Вот представим себе Адобовский конвертор (что ACR, что Лайтрум). Там цепочка преобразований такая: RAW-баланс белого - XYZ(или в чем там они интерполируют, возможно в Lab)-внутреннее пространство конвертора (ProPhoto)-редактирование (даже если все ручки стоят в нулях - оно есть) -вывод (sRGB/Adobe/ProPhoto).
Дальше редактирование в рабочем пространтстве, конверсия в принтерный профайл, печать.

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

Нравится задачка? В других конверторах общий смысл тот же.

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

 

[Nikolay_Po]

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

Вот представим себе Адобовский конвертор (что ACR, что Лайтрум). Там цепочка преобразований такая: RAW-баланс белого - XYZ(или в чем там они интерполируют, возможно в Lab)-внутреннее пространство конвертора (ProPhoto)-редактирование (даже если все ручки стоят в нулях - оно есть) -вывод (sRGB/Adobe/ProPhoto).

В моём случае цепочка много короче. Я пробовал DCRAW, без преобразований (ключи программы навскидку не вспомню, но получал линейный отклик без применения встроенных профилей). Только дебайеризация, даже без ББ, при коэффициентах усиления каналов R=G=B=G=1 (аспект качества дебайеризации без ББ пока опустим). Получал "RGB" в аппаратном пространстве сенсоров - практически чистые, в колориметрическом смысле, аппаратные данные. По таким RAW-TIFF-16bit (у матрицы было 12 родных) строил промежуточный матричный профиль по снимкам мишени Digital ColorChecker SG с добавлением искусственно рассчитанных белых плашек для ББ без нсыщения каналов. Потом под каждый снимок в "аппаратном" RGB делал 3D-LUT дивайс-линк с gamut mapping'ом для фактического охвата сразу в sRGB, AdobeRGB. Получал неплохие результаты. В принципе, снимок в "аппаратном" RGB с прикреплённым профилем, более-менее корректно отображался в Фотошопе. Однако выполнить gamut-mapping "на лету" Adobe CMM не удавалось - было видно насыщение на всех цветах вне охвата монитора. При таком подходе имеем всего одно преобразование CMM - из аппаратных данных - сразу в HVS. Минимум преобразований. По моему мнению именно такое единственное преобразование, включающее в себя gamut-mapping (разумеется, табличное) способно давать наилучший результат.
Вы ведь не надеетесь, что удастся перейти из "мнимых" XYZ сразу в любое из практических пространств (sRGB хотя бы) без табличного преобразования? Если таблицы не избежать, почему не сделать этого один раз и сразу? Зачем городить перевод в XYZ (понимаю, что есть задачи дебайеризации, но ББ можно реализовать сразу, в единственном дивайс-линке).

Нравится задачка? В других конверторах общий смысл тот же.

Но, вроде, не в моём примере.

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

Согласен. К этому стремлюсь. ArgyllCMS помогает.

 

[atutubalin]

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

В моём случае цепочка много короче.

Это иллюзия. Почитайте исходные тексты dcraw, там много удивительного.

Я пробовал DCRAW, без преобразований (ключи программы навскидку не вспомню, но получал линейный отклик без применения встроенных профилей). Только дебайеризация, даже без ББ, при коэффициентах усиления каналов R=G=B=G=1 (аспект качества дебайеризации без ББ пока опустим). Получал "RGB" в аппаратном пространстве сенсоров - практически чистые, в колориметрическом смысле, аппаратные данные.

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

Во-вторых, dcraw делает rgb scaling (document mode не рассматриваем, в этом режиме и интерполяции не делается), причем в стандартной dcraw количество вылетевших пикселов не регулируется - 1% (в LibRaw это место регулируется, а то снимки звезного неба начинают доставлять)

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

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

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

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

ArgyllCMS помогает.

Не все его серьезно воспринимают, ну да я им не судья.

 

[Alexey Shadrin]

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

и профиль камеры нужен тут и только тут.

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

 

[atutubalin]

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

Господа, тему читают не только ее участники, поэтому прошу четко договориться о том, что мы подразумеваем по словосочетанием "профиль камеры"? -- матрицу перехода от ее нативных сигналов к стандартным трихроматическим величинам или табличный ICC-профайл?

Тема началась с матричного профиля "нативные сигналы - XYZ", построенного внешним профилировщиком да так, что primaries залезают в отрицательные значения по XYZ.

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

 

[Alexey Shadrin]

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

Тема началась с матричного профиля "нативные сигналы - XYZ", построенного внешним профилировщиком да так, что primaries залезают в отрицательные значения по XYZ.

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

 

[atutubalin]

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

Поэтому предалагаю, для удобства и краткости, принять к употреблению в данном теме две аббревиатуры: "МП" и "ТП" -- и писАть недолго и сходу понятно. Ну, или что вам удобнее, господа -- главное, чтобы сходу понятно было.

Да тут как бы две проблемы:
1) Общая: существующие CMS (включая системы/программы характеризации устройств, но не ограничиваясь только ими ) плохо приспособлены к решению задач характеризации ЦФК
2) Частная: МП и ТП плохи по разным причинам. В-принципе, МП были бы разумным решением, если бы не некоторые особенности существующих CMS/CMM.

Но если влезать в детали частной проблемы, то МП/ТП ясны из контекста.

 

[Nikolay_Po]

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

2) Частная: МП и ТП плохи по разным причинам. В-принципе, МП были бы разумным решением, если бы не некоторые особенности существующих CMS/CMM.

ИМХО, матричные профили плохи до тех пор, пока они не задают только реальные цвета, пока в них есть неопределённости типа координат "XYZ" вне HVS.

 

[sabos]

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

выбор профилировщиков в данной постановке задачи вообще невелик

Здесь не всё понимаю. Знаю полдесятка программ, способных строить input LUT-profile. Хотя не знаю ни одной, дающей возможность интерактивно (на пару с "умом сглаживателя") пообрабатывать входные числа. Подготовка качественных данных пока вручную. При этом многие (разработчики в т.ч.) недооценивают важность этой подготовительной части. Зачем напрягаться, простейший алгоритм справится, ведь математически input LUT-profile несложен, здесь нет задач обратить A2B (и нет трудностей "гладкости-обратимости", с этим связанных), нет и сжатий, ведь мишень по-определению меньше HVS (вслед за pell "а откуда они, отрицательные XYZ, могут взяться?").

"Плохие" входные данные немедленно накажут при попытке посчитать matrix. Экстраполяция очень чувствительна к качеству данных. А primaries приходится считать самой капризной экстраполяцией, линейной. Что мы и видим в топикстарте - негодные входные данные плюс слабый алгоритм дают выбросы, брак. Хотя повторюсь, и в случае LUT-profile некачественные входные числа сделают профиль негодным.

Внешнему профилировщику доступен черный ящик конвертора (со всеми неявными преобразованиями)

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

Очень просто - вскрыть черный ящик.

XYZ(или в чем там они интерполируют, возможно в Lab)

Еще одна непоследовательность перфекционизма. Говоря "интерполяция", уже нельзя говорить о безупречном качестве. Это уже задача коммерческая, задача продать много "мегапикселов". Собственно, здесь видно отношение многих перфекционистов к качеству, они на самом деле не так уж его и ценят, они не готовы пожертвовать псевдоразрешалкой ради безукоризненной четкости, деталировки и микроконтраста. Как не готовы жертвовать чувствительностью камеры ради Luther-Ives, ради точной цветопередачи. Нам нужно только бесплатное "качество", мы готовы улучшать лишь виртуальную часть задачи, и мы продолжаем искать алгоритмы, что могут лепить из г... наилучшую пулю.

 

[atutubalin]

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

(вслед за pell "а откуда они, отрицательные XYZ, могут взяться?").

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

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

Также согласен с тем, что matrix удобнее и теоретически точнее. Как решить это противоречие?

Очень просто - вскрыть черный ящик.

Нет никакого противоречия.

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

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

Еще одна непоследовательность перфекционизма. Говоря "интерполяция", уже нельзя говорить о безупречном качестве. Это уже задача коммерческая, задача продать много "мегапикселов".

А что, интерполяция цвета по профилю (по LUT-таблице) - это правильная, хорошая, годная интерполяция, а интерполяция цвета (по координате) - плохая, негодная интерполяция?

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

 

[atutubalin]

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

ИМХО, матричные профили плохи до тех пор, пока они не задают только реальные цвета, пока в них есть неопределённости типа координат "XYZ" вне HVS.

Тут уж или охват широкий и координаты углов вне HVS (как это сделано во многих рабочих профилях c большим охватом) или "видимые" primaries и относительно небольшой охват.

Т.е. я понимаю претензию к отрицательным XZ, но вы же постановку еще больше сужаете...

 

[Nikolay_Po]

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

Тут уж или охват широкий и координаты углов вне HVS (как это сделано во многих рабочих профилях c большим охватом) или "видимые" primaries и относительно небольшой охват.

Т.е. я понимаю претензию к отрицательным XZ, но вы же постановку еще больше сужаете...

Ни в коем случае. Я не прошу искуственно сужать XYZ камеры до попадания в границы охвата. Да, это было бы проще. Грубо говоря, их нужно не сужать, а "мапить", сжимать, приводить в охват. Я считаю, что вне-HVS XYZ-координаты в принципе не подходят для описания цвета. В таких случаях XYZ - просто представленные через спектральную чувствительность зрения аппаратные данные камеры, ещё не цвет, так как не описано воздействие на зрение значений вне-HVS.

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

Считаю, что выводить XYZ в нестандартном виде, с отрицательными координатами, из RAW-конвертера не стоит. Если и выводить XYZ в профиль, вовне - то только после gamut-mapping'а изображения. В противном случае CMM, к которому попадёт изображение с нестандартным XYZ-профилем и вне-HVS "цветами" пикселей, просто не будет знать, как ему интерпретировать данные той или иной камеры. У каждой комбинации сенсоров и источника освещения могут быть свои особенности преобразований внеохват->охват.

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

 

[atutubalin]

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

Ни в коем случае. Я не прошу искуственно сужать XYZ камеры до попадания в границы охвата. Да, это было бы проще. Грубо говоря, их нужно не сужать, а "мапить", сжимать, приводить в охват.

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

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

Я считаю, что вне-HVS XYZ-координаты в принципе не подходят для описания цвета.

Формально они и не являются цветом. В ProPhoto или EktaSpace есть несуществующие цвета, ну да. Проблема появляется только если измерения (в этих координатах) выпадают из HVS.

В противном случае CMM, к которому попадёт изображение с нестандартным XYZ-профилем и вне-HVS "цветами" пикселей, просто не будет знать, как ему интерпретировать данные той или иной камеры.

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

О чем это свидетельствует? О несовершенстве спецификаций, в частности.

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

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

Вы предлагаете, по сути, характеризовать комбинацию (объектив+)камера+конвертор(+освещение).
Это тот путь, которым сейчас от бедности все и ходят, но это тупиковый путь.
Конвертор - нелинеен, даже если ни одной ручки не трогать, в результате вместо характеризации почти линейного устройства (ЦФК) мы характеризуем нечто с "гламуризаторами", искусственным интеллектом и так далее.

Там же открытий чудных чудовищное количество. Если у вас Кэноновская камера - снимите какую-нибудь не слишком контрастную сцену на ISO 50,100,125,160,200 по экспонометру и сравните RAW-данные (их можно с помощью unprocessed_raw из LibRaw вытащить) с тем, что вам даст "настоящий конвертор" т.е. не dcraw в режиме максимальной линейности, а что-то более-менее "настоящее".

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

 

[Alexey Shadrin]

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

Формально они и не являются цветом.

И неформально тоже: XYZ-координаты характеризуют потенциальное трихроматическое воздействие стимула на орган зрения гомосапиенса (по сути являясь евровым представлением долларовой стоимости -- LMS).

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

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

В целом, озвученная мысль принадлежит Сергею Безрядину, но подтвержается данными vision science. Шварц так просто оперирует этими терминами.

 

[atutubalin]

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

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

Сканеры характеризовать тоже не будем?

 

[Nikolay_Po]

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

Есть устройство ввода (охват которого аж больше HVS), есть замеры мишени (лежащие внути HVS), есть желание описать их в рамках существующей модели (матрицей поворота из RAW-данных в XYZ-данные), с минимальной ошибкой и все такое.

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

XYZ-координаты характеризуют потенциальное трихроматическое воздействие стимула на орган зрения гомосапиенса (по сути являясь евровым представлением долларовой стоимости -- LMS).

А... Понял! Слова Алексея Шадрина прояснили мне ситуацию: перевод RAW-данных в XYZ - это простой матричный пересчёт зарегистрированных камерой воздействий в эквивалентные воздействия на орган зрения. Простите, если я слишком медленно понял то, о чём Вы говорили уже несколько страниц. В контексте не цвета, а воздействий - это логичный и элегантный переход. И не важно, какие координаты "кардиналов" получились - пусть даже и отрицательные. Главное, чтобы полезные данные изображения после технической коррекции и обработки (ещё не цвета, а энергии воздействия) попали в положительную, стандартную область XYZ.
Вопрос: Действительно ли бывают в природе снимки, в которых данные элементов изображения после корректного матричного преобразования попадают в отрицательную область? На примере своей камеры я такого не наблюдал (ИК фильтр очень хороший, чувствительность к УФ очень низкая) и при расположении xy синего в 4 квадранте, никогда не получал с реальных изображений отрицательных XYZ, так как никогда не получал "сырых" R=0 G=0 B=255. Собственно, измерив или смоделировав воздействие на реальные сенсоры УФ и ИК, можно рассчитать приводку отрицательных координат к положительным, реальным. Например, R=G=0 & B=50 соответствует X=Y=Z=0, так как зарегистрированное "синим" сенсором УФ-излучение не будет видимо глазом. Своего рода маппинг, только не "гэмут", так как охвата здесь не существует, как и не существует цвета. По-моему, это задача больше для табличного дивайс-линка (простите за навязчивую идею), чем для прстого матричного преобразования в XYZ.
Ну и ещё раз повторюсь: пока нет речи о цвете, об ощущениях, выходить с обрабатываемыми данными на уровень ICC-профилей ещё рано. И изменять спецификацию ICC незачем.

 

[Alexey Shadrin]

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

Сканеры характеризовать тоже не будем?

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