OCIO Configuration Reference Values

[Troy Sobotka]

Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.

* Greyscale conversions. Again, missing metadata on Y weights.

* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.

* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.

https://github.com/sobotka/OpenColorIO/tree/reference-values

Feedback appreciated.

With respect,

TJS

[Malcolm Humphreys]

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

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

What do you think?

.malcolm

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

[Troy Sobotka]

On Wed, Sep 28, 2016 at 1:54 PM Malcolm Humphreys <malcolmh...@gmail.com> 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

[Sean Cooper]

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.

--

[Thomas Mansencal]

Hi,

I came across this thread.

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.

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.

Cheers,

Thomas

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.

[Troy Sobotka]

On Mon, Oct 24, 2016, 6:55 AM Thomas Mansencal <thomas.m...@gmail.com> 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,

TJS

[Andy Jones]

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.

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.

[Joseph Slomka]

Andy,

The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created.

As for the second suggestion I think it is part of a bigger  problem. There needs to be metadata management to really address the issues that are popping up. OCIO describes color transformations, but not image states. OCIO can describe what to do with a Rec709 tagged image, but not tell you if an image is actually Rec709.  The idea would be that there should be some kind of mechanism to track and create the appropriate metadata for a given image state.

The idea of creating application specific keywords and application specific color data sounds like it could lead to situations where different applications could get mismatched information for the same image state. So perhaps and tone mapping,chromaticity and other metadata data could be added as tags to describe the inputs and outputs of each OCIO transform. That data can then be passed to the system that is used to track image state and metadata. That system  could then create application specific metadata from a more general image state description.

It's a lot more work but it could prevent issues down the line with inconsistent metadata. 

-Joseph

[Troy Sobotka]

On Mon, Oct 24, 2016, 6:18 PM Joseph Slomka <joseph...@gmail.com> wrote:

The XYZ role solution is a good compromise. It would be a good recommended practice when .ocio profiles are created. 

My issue with best practices is that they will fail where not implemented, which means an entire user interface stack or potentially shaders, algorithms, and a whole slew of other things fall apart and suddenly break.

I am wondering:

1) What is the shortest path to a workable solution for OCIO in the near term that works.

2) Whether such a solution can make it into trunk and become reference.

Happy to see longer term goals here, but given that OCIO appeared to have been taken off of life support, only to resume critical condition weeks later, perhaps our goals should be modest at this juncture.

Implementing a mandatory XYZ set of values for reference, with applicable warnings or failure would at least be an entry point?

With respect,

TJS

[Joseph Slomka]

Troy,

The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing.


The next shortest is making it a requirement, and having it fail a sanity check and throw a flag if not implemented.

If it's agreed to then it should make it to the trunk. It sounds like OCIO needs more builds and more feedback to get user input and involvement. I am not a fan of a required role, but if it is a choice between that and dealing with dozens of VFX houses each with their own color management tools I'd much rather have required roles.

The slightly longer path is to make a metadata component to OCIO that provides some minimal API to manage color state of images.

Ideally OCIO would be the part of a project that manages color. It sounds like there is a need for a color management framework that track image state,executes logic and interacts with other color management systems.

-Joseph

With respect,

TJS

--

[Troy Sobotka]

On Tue, Oct 25, 2016, 11:54 AM Joseph Slomka <joseph...@gmail.com> wrote:

The shortest path is going to be an RP of having an CIE1931XYZ named space. There is a certain bit of manual glue required, as OCIO only manages image transforms and standardize the processing.

Agree.

The question then is, how to specify the XYZ transform.

I added it in the above patch in a manner much like the luma tag.

Is this a workable step forward? It would seem that we could depreciate the luma tag and replace it with a mandatory XYZ tag with values.

Is this reasonable as a toe-in-water step?

With respect,

TJS

[Malcolm Humphreys]

Hi,

Sorry I have been a bit busy getting up to speed with a job.

I have been musing some ideas with Robert Molholm about this separately and wanted to mention it to see what you think.

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

Then add a CATTransform which can read this metadata.

I would also like to add a find colorspace by chromaticities to help support image files that have this metadata.

The main advantages to this are you have control on where chromaticities are used within the transform list per colorspace and it also allows you to have ColorSpaces with chromaticities metadata but are just extra descriptive data (so you don’t have to have messy flags to respect them or not).

For example it could look something like this in a profile:
…
reference_chromaticities:
red: [0.6400, 0.3300]
green: [0.2100, 0.7100]
blue: [0.1500, 0.0600]
white: [0.3127, 0.3290]
…
- !<ColorSpace>
name: AdobeRGB
bitdepth: 8ui
metadata:
chromaticties:
red: [0.6400, 0.3300]
green: [0.2100, 0.7100]
blue: [0.1500, 0.0600]
white: [0.3127, 0.3290]
luminance_max: [160]
luminance_min: [0.5557]
description: |
AdobeRGB blah
allocation: uniform
allocationvars: [-0.125, 1.125]
to_reference:
- !<ExponentTransform> {value: [2.2, 2.2, 2.2, 1]}
- !<CATTransform> {method: “bradford”}
…

Things I am still pondering are about the goal of having a plugin support in terms of what the api and format looks like. ie. to support plugins the Ops would need to be exposed and the Transform interface needs to be generalised so a plugin could expose it’s paramaters (ie. you wouldn’t have a explicit interface CDLTransform.setSlope(foo) vs Transform(“CDL”).set(“slope”, foo)).

If this was done to expose Op and Transform parameters it would make sense to do this for ColorSpace as well to make the api consistent.

That is not likely to happen anytime soon but it begs the question should chromaticties and luminance be either:

(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now.

or instead

(b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields.

.malcolm

> --
> 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...@googlegroups.com.

[Andy Jones]

(a) like in the example above metadata.chromaticties.red and start to add the set()/get() interface now.
or instead
(b) put the chromaticties and luminance on the ColorSpace as first class citizens with explicit interfaces to be consistent but add a special case internally for getting these explicit fields.

I like option A.

I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility.  Personally, I'd rather see OCIO remain an open-ended color transform framework that supports the kinds of metadata users need for interoperability with other color frameworks, but doesn't limit it to specific metadata tags, or specific interpretations of those tags.  That's not to say I'm against encouraging more robust color management, but I think OCIO should draw a line in the sand and stick to facilitating, rather than enforcing the use of colorimetric relationships, and only move that line forward very carefully--if at all.  Otherwise, it would be easy to end up simply duplicating the efforts of ICC and/or ACES.

I think the metadata structure in Malcolm's example is immediately useful in its own right, and that's pretty much what I was imagining.  I also think there is room for a global metadata structure, which could allow the config to define values like the "reference_chromaticities" in Malcolm's example, without having to add a new first class tag at the root.  The significance of a token being defined in a metadata map would simply be that OCIO itself will not interpret the data, but will make it available as-is.

Since the files are yaml-based, it might also be interesting to allow for the use of yaml anchors during parsing.  That would allow for explicit use of values defined as metadata elsewhere in the file. For example, you could de-reference the colorspace chromaticities, and the reference chromaticities in a "CATTransform" plugin without having to define them twice, and without relying on any behind-the-scenes metadata query, or brittle reliance on naming conventions for the metadata tags.

Lastly, although it wouldn't be required for adding arbitrary metadata tags, I do also support the idea of transform operator plugins and generalizing the API access for operator attributes as a longer term goal.  That seems like it just makes sense.

[Thomas Mansencal]

> I worry that trying to interleave color math into OCIO as a first class feature will a) open up a can of worms and b) actually limit OCIO's flexibility.

Yes, this is exactly my concern and the reason why I joined the conversation. I quite like the minimalistic, almost agnostic approach of OCIO so far and if you introduce primaries, whitepoint, CAT support, the question of performing colour math is to be brought on the table. You might end up with some interesting issues to ensure consistency between your primaries, whitepoint, CAT specification and the matrices you define in the ColorMatrixTransform if no math is to be involved. We have been there with Colour and it has required a bit of work. Discrepancies might not be a big problem for OCIO, but it is something to be aware of.

Cheers,

Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ocio-dev/1gAf2Xwlu1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ocio-dev+u...@googlegroups.com.

[Troy Sobotka]

On Tue, Oct 25, 2016 at 3:25 PM Malcolm Humphreys <malcolmh...@gmail.com> 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.

Thoughts?

TJS