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

[Elle Stone <ellestone ninedegreesbelow com>]

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.

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
--
http://ninedegreesbelow.com
Color management and free/libre photography