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 <[email protected]> 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
