Re: Reference !<Colorspace>

Joseph Slomka <jsl...@...>


This is my partial follow-up to Jeremy's response.

A reference space is a useful concept and Imageworks will use them for AMPAS IIF implementation. The colorimetry will match the specification but how that will be arrived at will be subject to show requirements. . It is going to be a colorspace that will be tailored per production.

OCIO is being cast in ICC like terms that aren't fully relevant. OCIO lacks a color management module portion to handle the gamut mapping and other conversions done in an ICC CMM. OCIO has a different design. It is a framework. Pieces of management can be bolted together without anything 'to clever' happening. OCIO does not specify colorimetry; It is necessary to explicitly document the colorimetric meaning of your transformations. This makes OCIO simplistic and gives the control needed to create any case. OCIO provides the flexibility to implement reference spaces as colorspaces. It also leaves you fully free to define that role as you see fit allowing many individual color pipeline to exist.


-----Original Message-----
From: ocio...@... [mailto:ocio...@...] On Behalf Of Rod Bogart
Sent: Tuesday, October 26, 2010 5:14 PM
To: ocio...@...
Subject: Re: RE: [ocio-dev] Reference !<Colorspace>

My concern is when/where we want to have different primaries on different shows. So the reference space is probably a particular RGB space (rather than XYZ), and it is not obvious what that is by examining a to_linear function.

In the SPI examples, there was never more than one set of primaries in use, but that seems unrealistic for the future. Right?


On Mon, Oct 25, 2010 at 10:17 PM, Jeremy Selan<jeremy...@...> wrote:

I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).


In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.

-- Jeremy

Join { to automatically receive all group messages.