Re: OCIO Configuration Reference Values
Andy Jones <andy....@...>
toggle quoted messageShow quoted text
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: