Re: Reversed transform for a OCIO::DisplayTransform
Dmitry Kazakov <dimu...@...>
toggle quoted message Show quoted text
When we display the color in image color space on the monitor using lcms2: scRGB->monitor_sRGB
When we generate the color: HSV->sRGB->scRGB
That means that the color goes through the following chains:
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).
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
1) We have image colorspace managed by lcms2
3) The color selectors are effectively simple gradients generated in HSV or HSL color spaces .
2) We also have color selectors, which are gui elements for choosing the color by the painter. Obviously, the chosen color should coincide with the one that produced when painted on the image.
Well, I also did some refactoring to the Krita's code so I can state the problem a bit more clearly. I will try to explain the problem again more detailed, if you catch where I am wrong, please tell me:
Hi, Jeremy!Thank you for clarifications about 3D-lut! I google'd for it and now I think I understand why the reverse transformation is not possible. 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?
1) We have an image that may have a arbitrary color space. For example, scRGB 16bit float, which is linear.
When we display the color in image color space on the monitor using OCIO: scRGB->OCIO
Obviously, we should disable the lcms color management when using OCIO, because the latter one has it's own definition of the source colorspace .
So, this is what I have now. Such approach seems to be logical, but I'm not sure it is totally correct. If you see any issue in it (especially, in this HSV part), please tell me :) Probably, I should generate color from HSV not using sRGB, but somehow differently?
The next step for me would be to implement support for OCIO-based reverse exposure and gamma thing for the selectors themselves. I'm going to put it into the first conversion chain (which converts HSV to sRGB and then to the image color space). 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?
If you are still reading this mail, thank you! :) I would really appreciate your comments and feedback :)
 - could anyone suggest me something to read about HSV/HSL color spaces? It seems lcms2 doesn't have built-in implementation of them so we should generate it somehow using Lab or something...
 - Am I right in this assumption? I guess, yes, but I'm not totally sure. How the OCIO-enabled software is expected to behave in the case?
On Sat, Apr 19, 2014 at 8:29 AM, Jeremy Selan <jeremy...@...> wrote: