My way or the highway developers. How many would love to fork? LIbreoffice and
Ubuntu folks may help with funds needed to move Gimp to the next level.

>This really is my last post on unbounded sRGB unless someone has a 
>specific question to ask.
>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
>doesn't even understand, is that this is true regardless of whether
>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
>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
>of gamut channel values produce absolutely *meaningless* results is
>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
>is converted to unbounded sRGB without her consent.
>4. The list of chromaticity dependent editing operations is much
>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
>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
>         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,
>         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
>(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
>the RGB channel data is needlessly converted back and forth between
>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
>which will be done in the unbounded sRGB color space.
>This article provides an overview of problems with unbounded sRGB
>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
>that unbounded sRGB image editing is a really, really bad idea.
>Best regards,
>Elle Stone

billn (via
gimp-user-list mailing list
List address:
List membership:
List archives:

Reply via email to