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/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.
billn (via www.gimpusers.com/forums)
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list