Re: [Gimp-developer] Overlay Mode - fix.

Hi Elle,

Am 16.11.2012 20:33, schrieb Elle Stone:
> An implicit assumption seems to be that linear light blending is
> *always* more correct than blending in the regular sRGB color space.
> While Normal blending requires linear light to be radiometrically
> correct (to work like real light works), I'm not so sure about the
> Overlay blend mode.

I'd rather like to put it like that:

Normal mode blending has proven to better suit artistic needs when
applied in a linear light color space. For other blend mode formulas,
like overlay, this may not be the case. Some may 'shine' in linear light,
others may become pretty useless. It's a matter of experimentation to find
that out.

GIMP's focus is on artistic needs. Whether a blend mode is useful or not,
can only a judged from an artistical point of view. If you want to model
physical reality with GIMP means, be careful to check whether the actually
implemented math is suitable for your case.

Of course, it is not by accident that certain formulas which model the physics
of light do turn out to be useful in GIMP. But i believe it is misleading to
think of blend modes in terms of correct or incorrect.

> Overlay doesn't really have a physical counterpart, does it? And
> doesn't the Overlay blend mode have a mathematically built-in
> assumption that the color space being used is reasonably close to
> being perceptually uniform? 

No physical counterpart, no built-in assumptions. From looking at the
formula, i suppose it is simply the result of an experiment like
    "Can we combine multiply and screen in one blend mode?"

Overlay turned out to to have some useful characteristics for image
manipulation, which is why it 'survived'.

> The Overlay blend mode has an inflection point at 0.50 on a scale from
> 0 to 1, where you switch from Multiply to Screen. People refer to the
> the Overlay inflection point as "50% gray". But the phrase "50% gray"
> is misleading. It sounds like "middle gray" but it isn't. "50% gray"
> is always R=G=B=127, regardless of the gamma/tone rsponse curve of the
> RGB color space in which the blending is being done.
> In the sRGB color space, "50% gray" is very close to "middle gray",
> but only because sRGB is almost perceptually uniform. "Middle gray"
> itself is an ambiguous phrase, 

Within the context of separable blendmodes *), i suggest to use the
range 0 to 1 and simply look at the RGB triples. It is clear that
R=G=B=0.5 in sRGB results in a different gray than R=G=B=0.5 in geglRGB.

Blend mode formulas will produce the same numbers regardless of the
color space. But these numbers will be interpreted differently depending
on the color space. In turn, the perceived characterics of a blend
mode will change with the color space.

This effect is neither good nor bad per se -- we need to find out what
is useful and what is not.

Some blend modes like overlay and soft light have a neutral value when
the top layer is at R=G=B=0.5. If i got you right, you are putting your
finger on the fact that this neutral value will look different in geglRGB
than it did in sRGB.

> Four uses for Overlay blend mode (any other uses?):
a) Painting with overlay mode can be useful for cleaning up masks. For example,
painting with black turns the darker half of the tone range into pitch black
while preserving the highlights. On a mask, this means cleaning up the outside
range without touching the borders too much.

b) blending two images

> 1. To increase mid-tone contrast while compressing shadows and highlights.
> 2. When creating a gaussian glow
> 3. When doing high pass sharpening.
> 4. When using a "50% gray" layer for dodging/burning
> Focusing on the first use, when an image is overlayed over itself in
> the regular sRGB color space, the effect is *exactly* the same as
> applying a more or less symetric S-curve which increases mid-tone
> contrast and compresses shadows and highlights. This is usually what
> people want to have happen. I can provide the curves values if anyone
> is interested.

yep, duplicating a layer and using any of the separable blend modes is
equivalent to appling a curve. I consider this technique by far inferior
to curves, because it
  a) bloats the layer dialog
  b) does not allow fine-tuning of the effect

> But because the Overlay inflection point is defined as 0.5, or
> R=G=B=127 (regardless of the color space gamma/tone response curve),
> in a *linear light* color space Overlay blending an image with itself
> produces a very different outcome. In a linear light color space the
> shadows are crushed to 0, the midtones are shifted down toward the
> shadows, and the highlights aren't compressed much at all. This not
> particularly useful result is at odds with probably all the reasons
> why we might want to use Overlay blend mode.

Actually, the 'overlay over itself' technique is equivalent to applying an
S-curve regardless of the color space. It is just that in linear light, such
an S-curve does not result in the same effect as perceived in the sRGB case.

This will, of course, also surface when using the curves tool. A possible remedy
might be to use logarithmic scales there. It has also been suggested to use
Lab color space as default for curves.

> It seems to me that instead of "50% gray" a more reasonable inflection
> point for the overlay mode in digital image editing (at least in
> linear light) would be Lab (50,0,0) to preserve the effect of
> stretching midtones and compressing shadows and highlights. I suspect
> the formulas for Multiply and Screen could use some tweaking, too, to
> accomodate linear light blending.

A good reason to tweak the layer modes (or to keep the compatiblity modes
around) would be if they perform badly when blending two *different* layers.

As said, the 'blend by itself' technique is more of an oddity, which is
completely superseeded by the curves tool.

best regads,

*) 'Separable blendmodes' include overlay, dodge and burn etc, but exclude dissolve, color, hue.
The term nicely describes that the blend mode formula is applied separately to each of R,G,B.
It is taken from

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]