Re: OCIO Configuration Reference Values

Andy Jones <andy....@...>

I'd like to see two things added, which I feel represent a conservative take on how to add chromaticity data without going "too far."

1) An XYZ role.  This won't solve all the problems, but it does provide a black-box way to get to a known colorspace, regardless of the transforms used, without creating an alternate pathway.  (It's also just a role, so it's hard to imagine it doing much harm, assuming care is taken to designate it in a reasonable way.)

2) User-specified key/value pairs, with some recommended "common" tags.  The recommendations would be to help achieve consistent names, but would not provide OOTB behavior.  In that sense, it would be similar to the role system.

The reason I advocate for item 2 is that in order to interact with other color frameworks like ICC, color pickers, renderers, there is actually a wide variety of information that might be desirable.  For example, when tagging exported images, it may be preferable to provide a path to an existing icc profile, rather than generate a new one. And in a spectral renderer, one may want to define functions for converting from rgb to spd in the context of texturing.  When necessary, named eotfs could be provided, but these would be unofficial, and would correspond to individual applications, with no functionality provided by OCIO.  For example, a texture colorspace could specify a gamma function, or other named encoding curve.

In the case of an RGB renderer or an exported EXR, chromaticity values could be provided directly, without an expectation that those values will be used by OCIO to perform calculations.  I actually think this is preferable, as the transforms in the OCIO profile may not make sense as matrix/encoding type transforms.  For example, a colorspace that transitions from scene-referred to display-referred may benefit from a matrix for interoperability with other display-referred colorspaces.  However, this behavior is decidedly different from what the to_reference transform provides.

I would also advocate recommending that any applications always look for application-scoped keys before general keys in both roles, or this sort of per-colorspace metadata map.  For example, Maya should look for "maya_chromaticities" before falling back to "chromaticities."  By doing this, users can benefit from simple configs (no application scoping) whenever possible, but will never be faced with incompatible colorspace definitions due to varying application interpretations of the same keys.  This could be very important for things like specifying eotfs, as different applications could have slightly different names for the same curves, or slightly different curves that using the same name.

On Mon, Oct 24, 2016 at 7:39 AM, Troy Sobotka <troy.s...@...> wrote:
On Mon, Oct 24, 2016, 6:55 AM Thomas Mansencal <thomas.m...@...> wrote:

Quick question: assuming you had primaries / whitepoint stored on a per colourspace basis, wouldn't that be competing with the OCIO MatrixTransform if not metadata? I can see a danger of disconnection between the primaries / whitepoint fields and the MatrixTransform if both are present at same time, precision issues induced by the rounding would be enough to break that relationship for example.

I tend to agree on the per-colourspace concept, given that OCIO cannot deduce between a well-defined colourspace and an EOTF etc.

What *is* required is a method to query metadata about the reference, in an absolute colour encoding model / space such as XYZ, given that OCIO is blind to the hard data on a space.

So what *might* be a solution is to provide a "one way" set of data as per specification or particular reference setup. Of course this could lead to minor discrepancies between say, white point via specification and white point via mathematical matrix calculation, but I suspect in this case the specification would be ideal?

Consider the currently, *all* OCIO UI is broken in terms of pickers and like details given that no existing method to formally query the reference metadata exists. Also consider that all CGI with regards to shaders / algorithms that require Kelvin, wavelength, etc. cannot work correctly without bending OCIO.

It should be noted that while a huge chunk of applications fail miserably that are within an ICC system, the methods exist for developers to "do the right thing" and glean information from the ICCs.

This is also required in OCIO, and should be a much more pressing subject given that *every single new Apple product* is using alternate primaries in their displays. Sure, we can hack around this by providing a reference role that takes things to XYZ etc., but a more official method would be preferred.

You would also likely need to support a field for the chromatic adaptation transform being used to convert from the given colourspace to the reference colourspace.

Probably going to be handy to have at least WVK, VK, and B, indeed. Is there any data out there on CAT02 and such regarding suitability for CGI / VFx work?

Can we see some motion on this?

With respect,

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
For more options, visit

Join to automatically receive all group messages.