[Bf-committers] Color to greyscale conversion - confusion

[Campbell Barton]

On Mon, Jun 25, 2012 at 12:05 PM, Knapp <magick.crow at gmail.com> wrote:
> On Mon, Jun 25, 2012 at 11:02 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> On Mon, Jun 25, 2012 at 10:44 AM, Knapp <magick.crow at gmail.com> wrote:
>>> On Mon, Jun 25, 2012 at 10:19 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>> On Sat, Jun 23, 2012 at 7:39 PM, Troy Sobotka <troy.sobotka at gmail.com> wrote:
>>>>> On Jun 23, 2012 5:01 AM, "Campbell Barton" <ideasman42 at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> - Texture and shading pipeline use rgb_to_bw() which treat RGB more
>>>>>> evenly which might be better for shading when very un-even influences
>>>>>> for RGB channels could be problematic for shading with textures of
>>>>>> different colors (rgb_to_bw)
>>>>>>
>>>>>> - Where as with compositing - perceptual rgb->bw is much more
>>>>>> important (rgb_to_grayscale)
>>>>> g list
>>>>>
>>>>> Technically this is in the domain of LUTs once OCIO lands.
>>>>>
>>>>> The problem with attempting a non color aware approach is that it takes us
>>>>> directly into the hard coded color domain again, as all values are assumed
>>>>> 1:1 linear sRGB.
>>>>>
>>>>> With respect,
>>>>> TJS
>>>>
>>>> Don't think lack of OCIO is an excuse for arbitrary/different hard
>>>> coded conversions in our code.
>>>> Will add comments to these functions to say we don't know why they are
>>>> different and someone who has a clue could clear up the confusion one
>>>> of these days :S
>>>
>>> That makes no sense to me. When is this person going to show up? What
>>> makes you think he will ever come? Best to find the answer now and not
>>> incur any more debt.
>>
>> That was the purpose of this thread, since nobody knows - we better at
>> least document that this is a mystery so anyone reading the code is
>> aware,
>> this doesn't incur technical debt - it just exposes it.
>>
>> See:
>> http://projects.blender.org/scm/viewvc.php/trunk/blender/source/blender/blenlib/intern/math_color_inline.c?root=bf-blender&r1=48259&r2=48258&pathrev=48259
>>
>> --
>> - Campbell
>
> I am never against documenting but we have found a problem. Why not
> find the answer?
>
> Really I can't see any reason not to go with the visual space way and
> I would go with the GIMP way so that the users can assume a standard
> way exists and be right at least partly. I can see no reason not to go
> with one standard that looks good. I don't have a deep understanding
> of this but it would seem that there is only one reason to go from
> color to grayscale; so it looks good.

Agree - however this is decision should be made by one of the existing
maintainers of our shading/texturing code.

If this change is made, users may well report bugs that their scenes
now look different, it could even make displace modifier work
different in some cases for eg. Stuff you wouldn't necessarily expect,
so compatibility with existing scenes needs to be taken into account.
Also whats correct probably isn't clear cut. So I'll leave this one
for someone else who is responsible for this area of blender.