W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: Brightness filter in CSS Filters spec is wrong?

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 26 Jan 2012 09:25:39 -0800
Message-ID: <CAGN7qDDGUM7PPxuReK2=0z9LBVrzzYa4KVz7pSoBzc+bNOTx2Q@mail.gmail.com>
To: Chris Marrin <cmarrin@apple.com>
Cc: public-fx@w3.org
Hi Chris,

I got a reply from the Photoshop team:

Photoshop has two algorithms for brightness / contrast, depending on
whether you turn on the "legacy" checkbox. The legacy approach is the old
nave version of just sliding the histogram right and left or spreading it
out linearly, per channel.

In legacy mode,

Brightness n adds or subtracts n to / from each channel, clamping at 0 or

Contrast spreads or compresses the histogram linearly for each channel.
Contrast +100 makes all channel values 0 or 255. Contrast 100 makes all
channel values 127. Contrast 100 and Brightness +100 makes all channels

These operations can be useful for steps in analysis of images, or for
manipulating masks or in some cases for manipulating graphics, but they
tend to be horrible for photographic images, and so the first advice in
every Photoshop book for adjusting brightness and contrast on photographs
used to be "never use brightness and contrast".

The non-legacy B&C adjustments copied Lightroom (camera raw)'s original
process version. They're curve-based and produce much better results on
photographic images.

It sounds like 'legacy' mode in Photoshop matches the filters spec but it
doesn't produce good results.
I think we know have 3 options:
- use the current spec. Output is not very good + Brighten doesn't go to
- use the flash approach. Output is not very good but brighten goes to
- get an improved algorithm, possibly based on what existing editing
software does.


On Wed, Jan 25, 2012 at 1:42 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> On Tue, Jan 24, 2012 at 4:12 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> On Jan 24, 2012, at 11:05 AM, Rik Cabanier wrote:
>> Not sure I follow.
>> so instead of brightness:
>> -1 < brightness < 0 -> color.rgb * (1-brightness)
>> 0 < brightness < 1 -> color.rgb * (1-brightness) + vec3(brightness)
>> it would be:
>> -1 < darken < 1 -> color.rgb * (1-darken)
>> -1 < lighten < 1 -> color.rgb + vec3(lighten)
>> Yes, that would give us a nice single filter for both brightening and
>> darkening. But it's still a multiplicative (non-linear) operation which
>> affects pixels differently based on their original value. A pixel value of
>> 2 changes a lot less than a pixel value of 200. That's often useful,
>> because it can make the light parts darker without affecting the dark parts
>> as much. That's why brighten and darken exist. But it's not an additive
>> (linear) approach, which brightens all pixels equally.
>> I don't know which is better. But I have done the additive approach in
>> WebKit and it is much more intuitive than the original, purely
>> multiplicative approach.
>> Your approach is much better since it allows brightening all the way to
>> white, which the original approach didn't. But I'm not sure whether its
>> better to be linear or non-linear in this case. One thing is that we
>> already have a multiplicative filter, in contrast(). So maybe a
>> multiplicative contrast filter and additive brightness filter is the best
>> combination?
> Technically, I agree that that would be best since you can combine them
> but I'm not sure if this is very intuitive.
> I wonder how common it is to just use the additive brightness filter.
> I think this is where an expert comes in. I'll ask some people from the
> Lightroom and Photoshop team for their input...
> Rik
Received on Thursday, 26 January 2012 17:26:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC