Матрицы RGB/XYZ (XYZ/RGB)

[atutubalin]

Нет. Там процессинг такой: CAMRGB -> XYZCAM, XYZCAM ->XYZD50, XYZD50 -> OUTRGB.

"Классические" Deivice-link профили работают без участия PCS (Profile Connection Space). Поэтому тут я Вас не понимаю.

В dcraw собственно процессинг прост как правда: rgb-данные камеры (после баланса белого и демозаики) умножаются на матрицу rgb_cam[][] (для простоты, давайте рассматривать только случай работы с встроенным в dcraw профилем, который совпадает с адобовским ColorMatrix2). Без участия PCS. То есть rgb_cam[][] является именно что device link. Матричным.

С участием PCS, по описанной вами процедуре, строится этот самый rgb_cam[][] из Адобовского профиля. Ну да. Из XYZ2Camera и стандартных констант строим RGB(camera)->sRGB.

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

 

[TRANTOR]

Без участия PCS

Нельзя без участия PCS.

Вижу, что настаиваете на цитатах. Извольте:

http://lclevy.free.fr/cr2/

In Dcraw, the function adobe_coeff() is filling this cam_xyz matrix.

The values are coming from tags in DNG images procuded by DNG converter from CR2 files. See DNG specification.he values are coming from tags in DNG images procuded by DNG converter from CR2 files. See DNG specification.

6.1.2 sRGB: the constant xyz_rgb matrix and D65 definitions

the xyz_rgb matrix is defined in the sRGB standard definition. See International Color Consortium (ICC), A Standard Default Color Space for the Internet: sRGB, equation 1.8.

6.1.3 Camera color space to CIE XYZ conversion
In Dcraw, the processing is:
cam_xyz[3][3] initialisation, in adobe_coeff()
in cam_xyz_coeff()
cam_rgb[3][3] = cam_xyz[3][3] * xyz_rgb[3][3]
normalization of cam_rgb[3][3]
rgb_cam[3][3] = pseudoinverse(cam_rgb[3][3])

6.2 XYZ to RGB conversion

The convert_to_RGB() function in Dcraw is creating an ICC color profile.
The image/color data in Dcraw are in the XYZ color space with the D65 white point as reference. The ICC profile standard requires a D50 white point as reference and Dcraw output files are created using the RGB color space, the most common one.

The following Dcraw code computes the ICC tags rXYZ, gXYZ and bXYZ (see ICC profile format, section 6.4) which is a 3x3 matrix. See the column "Stored in ICC profile" in the table below.
The exact matrix stored in the profile is 0x10000 * xyzd50_srgb[][] * inverse ( out_rgb[][] ).
Out_rgb[][] is filled either with rgb_rgb[][] (sRGB), adobe_rgb[][], wide_rgb[][], prophoto_rgb[][] or xyz_rgb[][] (See column#2, Dcraw matrix in the table).

Надеюсь, что этого достаточно.

Из всего этого видно, что PCS тут имеется. И без него никак.

device link. Матричным.

Мтаричный Device-link? Не, не слышал.

яркости нейтральных полей не совпадают

Тем не менее, нейтрали вполне в рамках. А все остальное не очень. У C1 остальное более не очень, у LR менее.

на глаз все не так плохо

На глаз смотреть нельзя. Это всего лишь скриншот.

 

[atutubalin]

Нельзя без участия PCS.
Вижу, что настаиваете на цитатах. Извольте:

Зачем мне цитаты, да еще и неизвестного возраста (в dcraw это место менялось)?
Я смотрю в исходный код dcraw.c (актуальной версии 9.19) и вижу что там происходит.
Вот, к примеру, преобразование из rgb(камеры) в rgb(выходное) прямо вот из актуальной версии, обработка одного пиксела:
FORCC {
out[0] += out_cam[0][c] * img[c];
out[1] += out_cam[1][c] * img[c];
out[2] += out_cam[2][c] * img[c];
}
(FORCC - цикл по всем цветам).
Это в чистом виде умножение вектора img[..] на матрицу out_cam[3][..] и получение out-а.
Этот самый out_cam, в случае когда выход в sRGB - в чистом виде rgb_cam[][], про который я вам изначально и писал. И по смыслу - это именно device link, из img (в camera space) в out (в output space)

Но вообще - я утомился. Вы спрашивали "что за матрицы в DNG", я вам ответил (что там ровно то, что написано в DNG spec), вопрос, как мне кажется, закрыт. Убеждать вас в чем-то не входит в мою задачу, что хотите - то и делайте.

 

[TRANTOR]

Дело Ваше, конечно, на счет определения Dive-link'ов и PCS в dcraw.

Однако, не поленился скачать последнюю версию, а там:

for (out_cam[i][j] = k=0; k < 3; k++)
      out_cam[i][j] += out_rgb[output_color-1][i][k] * rgb_cam[k][j];

  void CLASS cam_xyz_coeff (double cam_xyz[4][3])
{
  double cam_rgb[4][3], inverse[4][3], num;
  int i, j, k;
 
  for (i=0; i < colors; i++)        /* Multiply out XYZ colorspace */
    for (j=0; j < 3; j++)
      for (cam_rgb[i][j] = k=0; k < 3; k++)
    cam_rgb[i][j] += cam_xyz[i][k] * xyz_rgb[k][j];
 
  for (i=0; i < colors; i++) {        /* Normalize cam_rgb so that */
    for (num=j=0; j < 3; j++)        /* cam_rgb * (1,1,1) is (1,1,1,1) */
      num += cam_rgb[i][j];
    for (j=0; j < 3; j++)
      cam_rgb[i][j] /= num;
    pre_mul[i] = 1 / num;
  }
  pseudoinverse (cam_rgb, inverse, colors);
  for (raw_color = i=0; i < 3; i++)
    for (j=0; j < colors; j++)
      rgb_cam[i][j] = inverse[j][i];
}

Впрочем, все это отношение к теме имеет довольно боковое. Сильно отвлеклись.


Больше интересует вопрос построения хороших матриц XYZ/CAM. Адобовские как-то не очень.

 

[atutubalin]

Дело Ваше, конечно, на счет определения Dive-link'ов и PCS в dcraw.
Однако, не поленился скачать последнюю версию, а там:

for (out_cam[i][j] = k=0; k < 3; k++)
      out_cam[i][j] += out_rgb[output_color-1][i][k] * rgb_cam[k][j];

[/CODE]

Ну да. Но в out_rgb для вывода в sRGB - единичная матрица, поэтому в out_cam оказывается rgb_cam.
Каковая rgb_cam является, таким образом, девайс-линком из sensor space в sRGB, а строится в помянутой вами cam_xyz_coeff из адобовской ColorMatrix2 по вполне очевидной процедуре.

Больше интересует вопрос построения хороших матриц XYZ/CAM. Адобовские как-то не очень.

И про это я тоже писал выше: мишень по вкусу (из распространенных, наверное ColorChecker SG лучше всего), снимаете, делаете CGATS, скармливаете в ICC-профилировщик по вкусу, получаете ICC-профиль. Если строить матричный профиль, то в нем будет содержаться запрошенная вами матрица.

А адобовские, действительно, не очень.

 

[TRANTOR]

из адобовской ColorMatrix2 по вполне очевидной процедуре

Если рассматривать в таком ключе, CAM -> [что-то-там-посчитали] -> OUTRGB, то да. Однако, в [что-то-там-посчитали] и есть PCS. Он же XYZ. Эта самая процедура.

Я, пожалуй, останусь приверженцем строгого описания Device-link:

Another kind of profile is the device link profile. Instead of mapping between a device color space and a PCS, it maps between two specific device spaces. While this is less flexible, it allows for a more accurate or purposeful conversion of color between devices. For example, a conversion between two CMYK devices could ensure that colors using only black ink convert to target colors using only black ink.

в ICC-профилировщик по вкусу

Если строить матричный профиль

Не подскажете, какой профилировщик строит матричный профиль для камер?

 

[atutubalin]

Если рассматривать в таком ключе, CAM -> [что-то-там-посчитали] -> OUTRGB, то да. Однако, в [что-то-там-посчитали] и есть PCS. Он же XYZ. Эта самая процедура.

Ну так "эта самая процедура" и строит device link. Который и оказывается в rgb_cam и дальше работает вот в точности по процитированному описанию.

Не подскажете, какой профилировщик строит матричный профиль для камер?

Argyll, к примеру.

 

[TRANTOR]

Убрал из сравнения L. Сравнение dF* (только по ab, т.е.). Слева C1, справа LR:



Картина, как и ожидалось, не изменилась.

Argyll, к примеру.

Спасибо. Попробую.

 

[atutubalin]

Картина, как и ожидалось, не изменилась.

Если я правильно интерпретирую ваши графики (-1 и -2 в именах файлов не слишком информативны), у вас максимальная дельта для ACR из 17 стала 10. Ну и медиана стала заметно лучше. Что намекает на то, что dL вносила изрядный вклад. Вот я бы, для начала, разобрался - откуда берется такая dL, если по всем понятиям ее быть не должно (внутри одного конвертора).

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

 

[TRANTOR]

-1 и -2 в именах файлов не слишком информативны

"-1" это C1; "-2", соответственно, LR.

dL вносила изрядный вклад

Вносила, но первоначальная тенденция сохранилась.

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

В данном случае, это сравнение только качества хромадаптации. То есть что дает на выходе ICC и двухиллюминантный DCP.

Сравнение с рефернесом для случая с DCP-профилем было чуть ранее. Чтобы построить более нормальный DCP-профиль, нужно написать соответствующий софт (или еще что-то в этом духе).

Задачи сравнивать разные конвертеры между собой тоже не ставилось. Сравнение DCP c ICC чисто иллюстративно - сам принцип показать.

Вдруг они от референса отличаются еще больше

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

 

[atutubalin]

В данном случае, это сравнение только качества хромадаптации. То есть что дает на выходе ICC и двухиллюминантный DCP.

Ну вот у вас получилось, что "хромадаптация" меняет яркость нейтралей, причем в разных участках шкалы для двух разных конверторов.
Тогда как классика хромадаптации (Bradford, скажем) - выглядит линейным оператором в XYZ-пространстве т.е. тоновая кривая не должна искривляться (да, я оцениваю на глазок по вашим скриншотам, но для нейтралей и для сравнения - считаю что вправе, уж совпадает/не совпадает/сильно не совпадает видно и на глаз). А она искривляется. А не должна.

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

 

[mihas]

Больше интересует вопрос построения хороших матриц XYZ/CAM.

Позвольте встрять в ваш горячий диспут просто с небольшим вопросом. Вот если мы прописываем в цветовом профиле матрицу 3х3 адаптации по Брэдфорду или фон Кризу от одной белой точки к другой, то как прописать в профиле адаптацию по CIECAM CAT02? Ее же просто матрицей 3x3 не пропишешь, там посложнее алгоритм? Это похоже уже не профиль должен содержать некие сведения о хромадаптации а уже софт уметь производить такие вычисления, которые уже не описываются просто матрицей 3x3? Или я не прав? Какой-то софт кроме ColorLab уже делает хромадаптацию по алгоритму CIECAM CAT02?

 

[TRANTOR]

Или я не прав?

Совершенно правы. Толку от матрицы CIECAM02 не будет. В LR используется Брэдфорд. То есть может и будет, но не тот, который подразумевается при полном процессинге CIECAM02.

Вопрос по построению матриц хромадаптации так же интересен. Пока с ними не разобрался еще.

Что туда поставила Адоба в данный момент? Зачем? Почему? Там не стандартные Брэдфордовые A->D50 и D65->D50, а что-то другое.

Какой-то софт кроме ColorLab

Недавно наткнулся на плагин: https://sites.google.com/site/clifframes/ciecam02plugin Правда, он долько под Фотошоп x86. Еще не пробовал.

 

[mihas]

Вопрос по построению матриц хромадаптации так же интересен. Пока с ними не разобрался еще.
Что туда поставила Адоба в данный момент? Зачем? Почему? Там не стандартные Брэдфордовые A->D50 и D65->D50, а что-то другое.

К сожалению не знаю ответа, не ковырял. Да и по цветовому результату наверное матрицу-то не угадаешь. Хотя может методом ненаучного перебора? Я на всякий случай оставил возможность взглянуть на посчитанную матрицу адаптации по Брэдфорду и фон Кризу от любого спектра к любому, просто чтобы был такой инструмент, мало ли пригодится, с матрицей в профиле сравнить, может еще зачем:

 

[mihas]

Что туда поставила Адоба в данный момент? Зачем? Почему? Там не стандартные Брэдфордовые A->D50 и D65->D50, а что-то другое.

А вы про какие продукты адобы? Насколько я знаю раньше адоб всегда использовала адаптацию по Брэдфорду, под Lab имела ввиду Lab D50. Во всяком случае так у меня с фотошопом вычисленный цвет sRGB D65 сходится (но я не сравнивал с последними версиями фотошопа, я пока не работаю в последних).

 

[TRANTOR]

какие продукты адобы?

Adobe Lightroom.

всегда использовала адаптацию по Брэдфорду

Все точно так же и сейчас.

Речь идет про тег <ForwardMatrix> в DCP-профиле.

 

[TRANTOR]

Теперь здесь будет город-сад Adobe Lightroom работает так:





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

Пояснения: слева - сравнение спектралки и мишени под Illuminant'ом A, по центру - спектралка и мишень под Illuminant'ом D65, справа - сравнение мишеней под Illuminant'ами A и D65 между собой.

 

[IVX]

кстати о негативных значениях элементов матрицы, 100% поддержанных DCRAW камер, а это за 200шт, имеют негативный элемент в Z. Только ICCV4 с этим корректно работает, V2 просто клиппует. Пруф http://ninedegreesbelow.com/photography/negative-primaries.html Не знаю, как с этим в RPP, но в их Kodak DCS Pro SLR_n.icc аж -0.44536, хотя можно точку чёрного подтянуть. Попытался я как-то сделать аргайлом (ICCV2) cLUT из матрикс профайла(fakeread), получил dE=800(!) и только там, где клиппует матрикс, при прочих равных, чисто позитивные матриксы, тот же aRGB, доли dE легко.

 

[TRANTOR]

@IVX, эта дискуссия несколько из другой области. Но, тем не менее, если кратко:

1. У сенсора primaries по сути нет.
2. "Primaries" зрительной сисетмы (т.е. XYZ) выбраны за пределами локуса намеренно, для облегчения расчетов.
3. Эти "primaries" не являются реальными цветовыми стимулами. Т.е. им не соответствует никакой цвет.
4. XYZ зрительной системы не соответствует "XYZ" сенсора, это разные пространства.
5. Поскольку это разные пространства, то их придется сопрягать (трансформировать), а не приравнивать одно к другому.

Отсюда следует ряд выводов:

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



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

 

[IVX]

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

ну вот, а RPP "к успеху шёл" с матрикс профайлами, хотя, на сколько я знаю, они постулируют "красивый цвет", вместо точного. Да и в "документации" аргайла тоже рекоммендуют только матрикс для камер, поскольку "it is assumed that the camera response is completely linear".