The reference role doesn't appear to be used anywhere inside OCIO itself. The choice of a reference space is just an choice when creating all your transforms. That said, it is a good idea to specify this role for people reading the config, and some applications "could" potentially use it (but setting it to something weird like "utility - raw" would work technically fine, it is only confusing)

The suggestions in that thread of "it's the first colorspace" is probably just because the example SPI config a happen to specify their "lnf" space first. However this is mistaken - there is nothing special about the first defined space.

I would suspect whoever created the ACES config misinterpreted the "reference" role as "what space to use for reference footage"

The meaning of the default roles are defined here:

http://opencolorio.org/userguide/config_syntax.html#roles

As you say, the reference role should be set to the main ACES space, as that is what the other spaces are defined relative to

These meanings should be a bit easier to find (e.g in the C++ API docs and Python bindings too) - made ticket for this,

https://github.com/imageworks/OpenColorIO/issues/533

Sent from my phone

On 17 Apr 2018, at 17:50, Abraham Schneider <abraham....@...> wrote:

Hi there!

Thanks for your answer. The reason for a reference colourspace and the 'star topology' of the colorspaces is perspicous for me. I was just wandering, why the ACES 1.0.3 config has at least 2 colourspace that are missing all 'from' and 'to' transforms (and in this definition would both be THE reference), why the 'reference' role points to 'Utility - Raw' and not to 'ACES2065-1' and why these two spaces have different allocation vars.

And in the discussion on the ACES page now there is the uncertainty, if the reference role defines the reference space or some other logic, because there needs to be a logic which space definition will be used when there are more than one that misses all from/to definitions.

Abraham

Am Dienstag, 17. April 2018 06:17:04 UTC+2 schrieb bsloan:

Hi Abraham,

The reference colorspace is the one that every colorspace defined in the config converts from (or to). It may or may not be defined in the config. If it does, the to_reference and from_reference transforms for the reference colorspace are necessarily null.

As for the purpose of having a reference colorspace, one cannot simply take a bunch of pixel values and transform them to colorspace X without knowing the colorspace associated with the incoming pixel values -- a transformation requires well-defined source and destination colorspaces.

Within ocio, a conversion from colorspace X to colorspace Y is built by concatenating colorspace X's from_reference and colorspace Y's to_reference*.

The alternative to having a reference colorspace would be for the config to define transformations from each colorspace in the config to every other colorspace in the config, which I think is N! entities instead of N. 

The ACES 1.0.3 config uses ACES-2065 as its reference colorspace, but a custom config could as easily define all of it's colorspaces in terms of an ACEScg reference or some camera vendor's encoding and gamut.

*most ocio colorspaces are invertible so they need only provide a from_ or a to_.

Hoping this is helpful.

--
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 https://groups.google.com/d/optout.

--
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 https://groups.google.com/d/optout.