On Sun, Nov 8, 2015 at 5:17 PM Brecht Van Lommel <brechtvanlom...@pandora.be> wrote:
> On Sun, Nov 8, 2015 at 6:42 PM, Troy Sobotka <troy.sobo...@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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers