Re: OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>

On Tue, Oct 25, 2016 at 3:25 PM Malcolm Humphreys <malcolmh...@...> wrote:
The basic idea would be to add a header chromaticities field and retire the luma field along with adding metadata fields per ColorSpace for both chromaticities and luminance (as cd/m^2).

This strikes me as clean, sensible, and very viable in short term.

I also believe that this discussion could wander off into colour quackery and OCIO bloatification without keeping a guiding bit of design question in front of us. Namely:

Q: "What is the design problem we are seeking to solve?"

This is why I originally asked the question, and I can give a pretty clear answer:

A:"How to make user interface elements and algorithms perform and display colour correct and accurate output?"

If we take a simple HSV wheel, we can see that the values will not be aligned with the reference space without some problems. If we lay out the UI element, we could assume the values are in reference, scene referred, and roll it to the view chosen. The only problem with this is that the imager gets a particular transfer baked version of it, albeit properly transformed to the view from the reference in terms of chromaticities.

If an imager tries to flip to a linearized transfer version of HSV, or a log encoded transfer, or another particular transfer, etc., the problem becomes much more complex. I see the following problems:

*) How can we strip off the transfer function from a view and apply the image's desired transfer function to the UI element?
*) How can an application / OCIO deduce what is a transfer function versus any other transform so that an application can present a sane list of options for the transfer options?
*) How can an application apply a display correction to a view, after the above concerns? (IE Keep display corrections completely isolated from the view transform knot.)

Extending this to the views, or per set of views under a display, is a halfway solution to solving the UI element issue.

The transfer function problem isn't an easy one to solve, and as such I'd be interested to hear wise minds on how to tackle it with a shortest-path solution. I was thinking that the basis of the look modifiers on the views (+ and - to add or remove looks) could be useful to perhaps extend to transforms and get transfer function versus scene / display linear versions?

Malcolm's reference metadata certainly solves the algorithm-dependent problems immediately, and is not terribly invasive. It should likely also be *mandatory* that trunk forward versions of OCIO force this definition such that an application and lean on the metadata to be present. A *huge* plus one to see this land as soon as possible.


Join to automatically receive all group messages.