Re: OCIO Configuration Reference Values

Malcolm Humphreys <malcolmh...@...>


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:

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


On 25 Oct 2016, at 9:32 pm, Troy Sobotka <troy.s...@...> wrote:

On Tue, Oct 25, 2016, 11:54 AM Joseph Slomka <joseph...@...> 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.


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,

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

Join to automatically receive all group messages.