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

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