Dmitry Kazakov <dimu...@...>
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?
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:
Requirements:
1) We have an image that may have a arbitrary color space. For example, scRGB 16bit float, which is linear. 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.
3) The color selectors are effectively simple gradients generated in HSV or HSL color spaces [0]. Implementation: 1) We have image colorspace managed by lcms2 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
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). That means that the color goes through the following chains:
When we generate the color: HSV->sRGB->scRGB When we display the color in image color space on the monitor using lcms2: scRGB->monitor_sRGB 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 [1].
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 :)
[0] - 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...
[1] - 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:
Hi!
A bit more info to add to the conversation. Apologies for now chiming in sooner...
As folks have noted, in many real-world color configurations the viewing transform is includes a 3D-LUT in the chain. While 1-D LUTs, matrices, and a few other analytical operators in OCIO are automatically inverted, OCIO does not attempt to do auto-calculate the inverse of 3D-LUTs as this is non-trivial, often ambiguous (in the case of many -> one color mappings, and low-fidelity / error prone).
In the applications I've had a change to integrate with OCIO, this assumption (the non invertibility of the display transform) makes creating a color picker more challenging. As others have noted, one implementation which avoids this issue is to not generate the pure color gradient in 'display-space', but instead to apply generate color ramps in some intermediate space, and then to apply the display transform to the color picker display itself.
This begs the question of what intermediate space to use for color ramp / color picker math. In our experience using linear tends not to work very well, but any modestly perceptually uniform space looks pretty good. The critical part is that this intermediate space must be an invertible conversion away from linear (1D lots work great for this), and that 0.0 maps to black. So you synthesize the gradient assuming its natively in this intermediate space. apply the forwards 3d viewing transform for display, and then back project (which you can do as it's invertible) into scene-linear.
In spi profiles, this 'color picker' role is a 1d approximation of the viewing transform, except with black pinned at 0.0 in both color spaces to make sure hsv math works out.
Sorry if this is confusing! :)
-- Jeremy
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
-- Dmitry Kazakov
|
