[Bf-committers] Luminance patches

[Troy Sobotka]

Thanks all for the comments. I thought I'd post what I just posted via IRC
to here.

As a general summation, the larger issue here is tackling the fact that any
RGB manipulation transform must route through OCIO. If a single point
doesn't, it breaks the whole pipeline.

Of course, artistically it is also great to have the proper luminance
values for a given color space of course, as it makes matting, black and
white conversions, alpha manipulations, and many other things much more
accurate.

On Tue Feb 17 2015 at 14:24:51 Campbell Barton <ideasman42 at gmail.com> wrote:
>
> Though I'd draw the line at removing them altogether as D1082
> proposes, since not all colors in Blender go via our image/render
> pipeline. (we have code dealing with on-screen colors, themes etc).
>

As we can see from the general sprawl of code reuse and duplication of
incorrect weights etc. (specifically regarding luminance here) we can see
that we can't insulate ourselves from having a developer use the functions
in an incorrect fashion. I'd cite the incorrect weights in Freestyle and
GLSL as a case in point; we actually have _more_ color problems since the
introduction of OCIO than we did prior now due to legacy functions.

Further, even when the elements are for a user interface function, they
probably should be color managed. In addition to the rather glaring fact
that not all displays are sRGB, and many are wide gamut, we also have the
problem that within the realm of UI we have a need for color management.

The color wheels (HSV) come to mind. If the developer uses the rgb_to_bw
function, they just broke their entire color chain. Now the developer
shouldn't use the rgb_to_bw function, but how should they know that?

Finally, the function implemented perfectly implements the existing
functions, with no added complexity to the developer, nor additional
overhead. It is literally a unified and cohesive 1:1 version. Oh, and it is
a small baby step to have Blender's color management near completion.

So:
1) Not all outputs go to a platonic sRGB display (as no such display
exists), and in fact as is likely in many smaller studios, most are wider
gamut (Eizos at the BI, no?). RGB is a relative color model.
2) There would need to be a division and added complexity separating
"artistic" GUI elements and non-artistic, for no reason other than to add a
level of complexity and the potential for the entire color management chain
breakage.
3) There is no added overhead with a proper OCIO luminance function.
4) There is no added function complexity with the proper OCIO luminance
function.
5) There is no way to prevent a developer from accidentally implementing a
broken function and breaking the entire color management chain.

With respect,
TJS