1. Ocio-Dev
  2. Topics

OCIO Configuration Reference Values

Sean Cooper <se...@...>
 

This is timely, I was going to raise the issue of whether it's appropriate for OCIO to be colorimetry intelligent or not. Where OCIO would define the chromaticites per colorspace, as Malcolm stated.

As an additional feature, here @SPI I've created a wrapper around the python api where I specify a colorspace's chromaticites (primaries and whitepoint) for the reference space and for all subsequent colorspaces. At config generation, the matrix transforms to and from the reference space are automatically generated for each colorspace. Additionally there is the option to perform chromatic adaptation for varying whitepoints or not. This is implemented as an OCIO Matrix transform.

This isn't 100% what you're talking about Troy, but I think it follows in the same line of discussion. Though I do see how even a simple chromaticity flag in the colorspace would prove useful.

On Wed, Sep 28, 2016 at 2:00 PM, Troy Sobotka <troy.s...@...> wrote:


On Wed, Sep 28, 2016 at 1:54 PM Malcolm Humphreys <malcolmh...@...> wrote:

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

I loved this idea when Mark originally hinted at it at SIGGRAPH, but frankly, it would probably require some deeper sculpting unless someone can figure out an elegant solution for the parser on each transform.

Part of the problem here though is that I'm pretty sure this begins to deviate quite a bit from the transform oriented nature of OCIO. It's also compounded by the fact that it isn't terribly clean as some transforms (say OETF / EOTF or other transfer curves) would not have definitions. So again, it feels deeper perhaps? 

Question would be would this just be metadata or actually used to create extra ops.

I am approaching this from the aspect of designing UIs that are properly colour managed, and it's darn tricky currently. It's also darn tricky to design say, shaders or algorithms that require XYZ in a colour agnostic way without such metadata (such as black body or Kelvin formulas).

This almost trivial solution would certainly repair all of those cases instantly, at a low cost of code overhead / change.

What do you think?

I'm very curious to hear what other folks with much larger brains than mine have to say?

With respect,
TJS

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

1 - 1 of 1