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:
Hi, All!

Thank you for your replies! Now I understood that not every display transform is revertible :) So I will have to refactor our color selectors code to make it work with color proof'ed colors :(


On Sat, Apr 12, 2014 at 6:06 AM, bsloan <bsl...@...> wrote:
For most workflows that use a 3D LUT to render extended dynamic range images, it is not necessary to reverse the operation on the picked color. Your application should just look up the un-transformed pixel value from the image (not the displayed frame buffer), based on the selection position.

It would be *very* handy if your application would render the various color pickers and swatches through the OCIO display transform as well. Photoshop does not do this. 




On Friday, April 11, 2014 10:24:38 AM UTC-7, Dmitry Kazakov wrote:
Hi, all!

I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able not only to display a color on screen (which we do using DisplayTransform), but also to pick an already displayed color back into app (for usage in color selectors or for drag-and-dropped colors). So, effectively, I need to get a reversed transform for a DisplayTransform. But it seems to be explicitly prohibited (it throws an exception in the case). I'm wondering, is it possible to get a reversed transform for a DisplayTransform without reimplementing it completely using GroupTransform?

Thank you in advance!

[0] - krita.org

--
Dmitry Kazakov

--
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

--
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.

Join ocio-dev@lists.aswf.io to automatically receive all group messages.