[Bf-committers] Color to greyscale conversion - confusion

Andrew Hunter andrew at aehunter.net
Mon Jun 25 18:02:58 CEST 2012


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


More information about the Bf-committers mailing list