GNOME.org
 

Re: [Gimp-user] Time to fork BABL and GEGL

On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:

This really is my last post on unbounded sRGB unless someone has a specific
question to ask.

On 11/14/2014 11:47 AM, Øyvind Kolås wrote:


I ask for an assumption of good faith, that the babl/GEGL developers
know what they are doing and have incorporated your input from April
on out how multiply and gamma produce undesirable results for values
outside the 0.0-1.0 range working with unbounded sRGB. That we want to
and will incorporate that in the color management model of GEGL. A
model that differs from how traditional ICC based photo editors
traditionally work, GEGL has both internal (babl) and external (ICC)
color management; and you have correctly pointed out that the internal
color management is lacking and needs to take more RGB spaces into
account.


I think it's important to clarify some of Pippin's misunderstandings that
are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity
dependent editing operations. What Kolås fails to acknowledge, and maybe
doesn't even understand, is that this is true regardless of whether the RGB
channel values are *in* or *out* of gamut with respect to the bounded sRGB
color space.


The multiply compositing op; doesn't really have any sliders, and
gamma adjustments are among the things that definetely would not end
up using bablRGB; regardless of how far we get in specifying other
working spaces.


2. Given that multiply and gamma slider adjustments produce different
results in different RGB working spaces, only the *artist* has the right to
decide which results are better. Developers aren't in a position to make
this decision on behalf of users.

3. The fact that multiplying and making gamma slider adjustments on out of
gamut channel values produce absolutely *meaningless* results is just icing
on the badly baked cake that is unbounded sRGB. The artist's control over
her own RGB data is already removed as soon as her RGB data is converted to
unbounded sRGB without her consent.

4. The list of chromaticity dependent editing operations is much longer than
just multiply and gamma slider adjustments:

    * For editing performed on more or less perceptually uniform RGB data,
the list includes essentially *all* editing operations.

    * For editing performed on linear gamma RGB data, the list includes at
least the following operations (I haven't checked every single editing
operation made available through the GIMP UI):

        Channel data used as a blending layer
        Channel data used for making selections
        Colors/Alien Map HSL
        Colors/Alien Map RGB
        Colors/Auto stretch contrast
        Colors/Auto stretch contrast HSV
        Colors/Channel Mixer (try Margulis' "enhance green" formula)
        Colors/Desaturate average
        Colors/Desaturate lightness
        Colors/Mono Mixer (except straight Luminosity-based B&W conversion)
        Colors/Posterize
        Colors/Threshold
        Colors/Levels Gamma slider operations
        Colors/Levels Red, Green, and Blue Input/Output sliders
        Colors/Levels "Auto Pick" (used for white balancing images)
        Filters/Artistic/Cartoon (this uses hard-coded Y values)
        Filters/Edge Detect/Sobel
        Filters/Enhance/Red Eye Removal
        Filters/Noise/HSV Noise
        Filters/Noise/RGB Noise
        Filters/Artistic/Soft glow
        Filters/Artistic/Vignette (any color except gray, white, black)
        Layer blend Mode/Burn
        Layer blend Mode/Color
        Layer blend Mode/Darken only
        Layer blend Mode/Difference
        Layer blend Mode/Divide
        Layer blend Mode/Dodge
        Layer blend Mode/Hard light
        Layer blend Mode/Hue
        Layer blend Mode/Lighten only
        Layer blend Mode/Multiply
        Layer blend Mode/Overlay
        Layer blend Mode/Screen
        Layer blend Mode/Saturation
        Layer blend Mode/Value
        Paint tools depend on the working space chromaticities when using
the following blend Modes: Burn, Color, Darken only, Difference, Divide,
Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen,
Soft light, Value.

In other words, *most* editing operations are chromaticity dependent. This
means the *artist*, not the developer, is the only person who should choose
the RGB working space.

5. Putting aside color gamut limitations, the editing operations that are
chromaticity *in*dependent already produce exactly the same results (same
XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent
editing operations, there is no point whatsoever in forcing these operations
to be performed in the unbounded sRGB color space. But there are two serious
*dis*advantages:

   1. Conversions between color spaces necessarily involve floating point
rounding errors, and rounding errors will accumulate over time as the RGB
channel data is needlessly converted back and forth between the user's
chosen RGB working space and unbounded sRGB.

   2. The user is entirely at the mercy of developer decisions as to which
operations will be done in the user's chosen RGB working space and which
will be done in the unbounded sRGB color space.

This article provides an overview of problems with unbounded sRGB image
editing: Using unbounded sRGB as a universal color space for image editing
is a really bad idea
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html)

If you find the article to be too technical, looking at the pictures should
be enough to let you see what the problems with unbounded sRGB really are.
If you follow the links in the article, again you don't really need to read
the text, just look at the pictures and you will see that unbounded sRGB
image editing is a really, really bad idea.

Best regards,
Elle Stone


Is there anything above that hasn't already been stated a couple of times?

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