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

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/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 (

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
Color management and free/libre photography
gimp-user-list mailing list
List address:
List membership:
List archives:

Reply via email to