On Apr 21, 2014 1:53 PM, "Dmitry Kazakov" <dimu...@...> wrote:

> But, speaking truly, I didn't fully understand what is 1D transform... is it some term? Could you give me a link to some info or documentation?

A 1D LUT is where a basic “input in” equals “input out.” It can only be used to adjust transfer curves, and is completely invertible.

A 3D LUT is required to adjust saturation intents. Here a single input value can shift values in other channels, and as Mr. Gritz succinctly outlined in the OIIO response, one value out may have more than one entry point, and therefore this is a typically non-invertible transform.

> 3) The color selectors are effectively simple gradients generated in HSV or HSL color spaces [0].

Note here the L or V is color space relative based on the resultant luminance (Y in XYZ) of your three primaries. So L will be different across spaces with different primaries and need to be calculated differently with different weights I believe.

> 2) Right now color selectors generate HSV using QColor object. The HSV color is first converted to RGB by Qt, we assume this color being sRGB, and then convert (using lcms2) into the color space of the image. That is if we have an image in scRGB color space, then the conversions chain is the following: HSV->sRGB->scRGB

This likely means an artist can never select the gamut range that sRGB cannot reach, yet is clearly within scRGB's gamut. This cripples the wider gamut space somewhat.

> 3) Later this color (in scRGB) is converted to the monitor profile in either way: using OCIO or lcms2 with converting it to the monitor profile (say, monitor_sRGB).

Not quite that simple I believe.

To do this with OCIO, you would need to craft a 3D LUT of your display's profile with a specific destination space, and snap it into the OCIO chain _before_ the sRGB values are transfer / TRC curved. Applying the transform on transfer / TRC curved values will give incorrect results.

So linear scRGB values could go to XYZ, then through the display profile 3D LUT to get to say sRGB, then apply the sRGB 1D transfer curve.

> Obviously, we should disable the lcms color management when using OCIO, because the latter one has it's own definition of the source colorspace [1].

And this would require a bit of artist know-how, as I cannot see a way to do it automatically.

> Probably, I should generate color from HSV not using sRGB, but somehow differently?

It should be possible to create a wheel that uses the primaries of scRGB (wider gamut) and select from that. The out of gamut values would effectively be rendered as an absolute colorimetric clipped version.

Little tricky to get the value selected on a reverse transform, however. Maybe keep an off-screen buffer of the untransformed source space color picker, pre-destination transform[1]? Mr. Selan?

> The reverse gamma and exposure would then be applied to the sRGB, right before it is converted to the image color space. I guess it is correct, isn't it?

The typical order for changing color spaces is:

A) Invert any TRC / transfer curve on a source space to get to linearized values.
B) Convert the RGB primaries to XYZ.
C) Convert the XYZ primaries to RGB of the destination. This can be combined with the matrix from B.
D) Apply the destination TRC / transfer curve.

Note that in B and C your white point _must_ be aligned via adaptation matrices on the RGB spaces. Bradford or CAT02, for example.

I apologize for chiming in here, but I thought I could at least hint at some potential issues.

With respect,
TJS

[1] Where a display profile is likely an irreversible 3D LUT in most instances. Not a concern if it is purely a matrix transform for primaries.