[Bf-committers] Color to greyscale conversion - confusion

Mon Jun 25 18:37:19 CEST 2012

I've read Charles Poynton's stuff backwards and forwards and I felt
like I could contribute to this thread, but it can get so confusing
that I actually cannot think of what to say.

Although there is "no correct answer", these coefficients do usually
come from a standard.  There are coefficients for NTSC (SDTV) and ATSC
(HDTV).  If you want to name them, I would match them to the proper
standard.  If they don't match anything then good luck ;-)

I might add that this kind of conversion is a perceptual value for
human use.  If the resulting values are not seen by humans then there
is no need to adhere to any standard except the one that helps
downstream computation do its job better.

I actually may have introduced one of the conversions myself, if it is
in a part of Blender that converts images into sculpting brushes
(either that or I left it as what it was before).

On Mon, Jun 25, 2012 at 11:02 AM, Andrew Hunter <andrew at aehunter.net> wrote:
> Hey Cambell,
>
> I'd like offer my understanding and opinion on this subject and
> hopefully it might clear some things up.
>
> First I would suggest that like anything to do with color, there isn't
> a simple way to do an operation without greatly simplifying your input
> assumptions and focusing around one use case.
>
> I would propose that the RGB->Greyscale conversion be separated into
> two use cases: technically correct transforms and creative or
> aesthetic transforms.
>
> On Sat, Jun 23, 2012 at 3:05 AM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
>> "A full discussion of which formula is “better” is beyond the scope of
>> this article. For further reading, I strongly suggest the work of
>> Charles Poynton <http://poynton.com/>. For 99% of programmers, the
>> difference between these two formulas is irrelevant."
>> - But we are the 1% right :) -
>
> I would strongly agree with you there, as 99% of programmers only have
> to ever deal with an (implied) sRGB pipeline. Blender has stepped out
> of that box :)
>
> The luminance method that Jeron links to falls under what I consider
> to be technical transforms, that is to say that the values of the
> co-efficiently are tied to the colour primaries of their space.
> Unfortunately, even when dealing with a greyscale image, you are not
> free from the burden of color management. Because of differences in
> color spaces, what constitutes pure luminance differs wildly and can
> only be correct if you know where your coming from and going to.
>
> As a side note, saturation operations are also extremely dependant on
> the luma coefficients. The ASC-CDL spec use the Rec709 coefficients as
> the basis for it's saturation op.
>
> "Saturation provides a weighted average of the normal color
> (saturation 1.0) and all gray (fully
> de-saturated, saturation 0.0) images. The saturation operation
> modifies all color components.
> Color components are weighted by the values most commonly used in Rec.
> 709 implementations
> of saturation. Saturation values > 1.0 are supported. Values > 4 or so
> will probably only be used
> for special purposes. [...] luma is the fully
> desaturated gray value, based on the color component weightings."
> -- ASC-CDL_Release1.2
>
> Charles Poynton makes a detailed explaination in his book: Digital
> Video and HD: Algorithms and Interfaces [1]
>
> Just as before with the ACES discussion, the way around this
> uncertainty is to pick a single well defined working space, such as
> ACES, and to convert everything to and from that space. This would let
> you hard code one function that does the ACES RGB values to lumanance
> (or desaturated) RGB values. The example OCIO configs also include a
> no-op data color space for situations, like normal maps etc, where
> color space is irrelevant.
>
> On to aethetic transforms, as Jeron mentioned, many photography
> applications provide a method of converting to greyscale that afford
> the user control over this conversion. Photoshop and gimp refer to it
> as a monochrome channel mixer.
>
> This is something that output is a combination of a technical
> transform (as above the conversion to Rec709 luma) plus the ability
> for the use to change those co-efficents.  This is mimics the way that
> a photographer would use color filters to modify the response of
> panchromatic film (B&W) to the light. An example of this would be dark
> skys in which the white clouds contrast greatly.
>
>> 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.
>
> It's always tricky to handle fixing a bug that might change users
> aesthetic decisions.
>
> To summarize, depending on the problem that you are tackling.
> Hopefully, I've been able to make myself clear and add to the
> discussion.
>
> Sincerely,
>
> Andrew
>
> [1] Digital Video and HD: Algorithms and Interfaces
> http://books.google.ca/books?id=dSCEGFt47NkC&pg=PR32&lpg=PR32&dq=luma+coefficients+of+aces&source=bl&ots=OL4tbGeQFm&sig=oYK6PZtRDNerMFflfCW0kEMgSig&hl=en&sa=X&ei=xYfoT9f3GM7k6QHyzf3gDg&ved=0CFgQ6AEwAg#v=onepage&q=luma%20coefficients%20of%20aces&f=false
>
> On Sat, Jun 23, 2012 at 7:01 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> Some interesting replies though it looks like we are no closer to an
>> answer, of course there is no right way - but I was hoping the
>> different ways blender does rgb->bw conversion could be named and
>> commented so developers know which to use and why.
>>
>> At the moment my impression is early on developers just put in
>> whatever they read would work, or copied and pasted from existing
>> code.
>>
>> Speculation from looking at the usages...
>>
>> - 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)
>>
>>
>> On Sat, Jun 23, 2012 at 9:05 AM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
>>> Hi
>>>
>>> Well as already said, there is no correct formula. Also if you think
>>> about what the method does it is basically two things:
>>>
>>> 1. mimic black and white conversion by multiplying the color channels
>>> with a certain value. Enhancing a light-channel to influence the BW more.
>>> nR = nG = nB = 0.2126 R + 0.7152 G + 0.0722 B
>>> 2. do a conversion to an undefined color space. (if you may call it a
>>> color space)
>>> Value = (nR+nG+nB)/3 // as nR NG & nB are same, we can optimize to value=nR
>>>
>>> There are many aperature plugins only to mimic black and white
>>> conversion (silver efex pro) in case for the compositor. But Campbell
>>> has a point that we don't have a clue when to use which and why. There
>>> are to many assumptions that is not clear in the method name.
>>>
>>> Luminance is chosen as it works best in most cases.
>>> see here comparison between the different algoritms
>>> http://www.tannerhelland.com/3643/grayscale-image-algorithm-vb6/
>>>
>>> "A full discussion of which formula is “better” is beyond the scope of
>>> this article. For further reading, I strongly suggest the work of
>>> Charles Poynton <http://poynton.com/>. For 99% of programmers, the
>>> difference between these two formulas is irrelevant."
>>> - But we are the 1% right :) -
>>> Jeroen.
>>>
>>>
>>> On 06/23/2012 04:27 AM, Troy Sobotka wrote:
>>>> On Jun 22, 2012 11:56 AM, "CoDEmanX" <codemanx
>>>> <codemanx at gmx.de>@<codemanx at gmx.de>
>>>> gmx.de <codemanx at gmx.de>> wrote:
>>>>> but correct seems to be:
>>>>>
>>>>> Y = 0.2126 R + 0.7152 G + 0.0722 B
>>>> Again, there is no singular "correct".
>>>>
>>>> I believe the above is a luminance based conversion from linearized sRGB.
>>>>
>>>> With respect,
>>>> TJS
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>>>
>>> --
>>>
>>> Met vriendelijke groet,
>>>
>>> Jeroen Bakker
>>>
>>> *At Mind BV
>>> *
>>>
>>> Telefoon: 06 50 611 262
>>> E-mail: j.bakker at atmind.nl <mailto:j.bakker at atmind.nl>
>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers