[Bf-committers] Updating Colour Configurations

[Troy Sobotka]

On Sun, Nov 8, 2015 at 5:17 PM Brecht Van Lommel <brechtvanlommel at pandora.be>
wrote:

> On Sun, Nov 8, 2015 at 6:42 PM, Troy Sobotka <troy.sobotka at gmail.com>
> wrote:
> > I have only peeked at the Cycles GPU path code, but it doesn't seem like
> > there is a terrible level of chromaticity based hacks in place? I only
> saw
> > the sRGB transfer curve hard coded? Perhaps there is a bit in the SSS
> code?
> > (Being code that makes assumptions about the RGB primaries and rolls them
> > through XYZ such as the hard-coded color temperature node.)
>
> Cycles inputs and outputs are mostly scene linear colors and it
> doesn't need to know much about that color space, but there are a
> couple exceptions.
>
> The simple changes would be in the wavelength, blackbody and sky
> texture nodes, which make some assumptions about using Rec.709 scene
> linear. An extra transformation between different scene linear spaces
> should be enough to solve that. The Blender API just needs to expose
> information about the scene linear color space so that Cycles can
> construct those transformations, which I guess are just 3x3 matrices.
>
>
I chatted with Antony at length on this and I am reasonably sure that there
is a quick and easy method to solve many of the issues in Blender while we
wait for OCIO to implement chromaticity information, which is hopefully
sooner rather than later.

The basic solution is to implement an XYZ role. This is reasonably simple
to carve out, and smaller studios / artists with unique configurations
would simply have to take care to provide the XYZ role and assert that the
white points are aligned.

The colour selectors and such could also leverage this role.

Do you think it is feasible to leverage the role against Cycles for these
sorts of cases or does the GPU path provide a problem?

With respect,
TJS