Re: Reversed transform for a OCIO::DisplayTransform
|
Jeremy Selan <jeremy...@...>
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 On Tue, Apr 15, 2014 at 5:59 AM, Dmitry Kazakov <dimu...@...> wrote:
|
|
|