[Gimp-user] Time to fork BABL and GEGL

[billn <forums gimpusers com>]

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

-- 
billn (via www.gimpusers.com/forums)