[Bf-committers] Updating Colour Configurations

Troy Sobotka troy.sobotka at gmail.com
Sun Nov 8 18:42:15 CET 2015


Greets Brecht.

On Nov 8, 2015 4:00 AM, "Brecht Van Lommel" <brechtvanlommel at pandora.be>
wrote:
> > 2) To add in the proper transforms for the default iMac P3 displays.
>
> If this is just adding the P3 color space for reading images and
> display that seems reasonable. If it's more then please explain what
> that is.

It isn't. It would mean an output view transform.

The new P3 displays aren't P3, but close. It would be an output transform
probably labeled under a vendor family for something like “iMac P3.”

> > 3) To revisit the idea that we should be colour managing the entire UI,
as
> > icons and other bits now will look odder.
>
> I think it's inevitable if you want to display wide gamut images while
> still displaying the rest of the UI correctly. It's a huge task and
> needs a good design though, since it's easy to make a mess if it's not
> done properly, it affects a lot of code.
>
> > 4) Revisit the hard coded Cycles sRGB muckery and focus on fixing it.
>
> I think everyone agrees that this needs to be improved.
>
> Are you volunteering to actually implement 3) and 4), or just update
> the configuration for 1) and 2)?

Campbell is probably the most well equipped for (3), but it overlaps into
some of the mainstream UI elements such as color pickers and color ramps,
so it would be something to discuss.

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

With respect,
TJS


More information about the Bf-committers mailing list