On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
<ellest...@ninedegreesbelow.com> wrote:
> 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.

The multiply compositing op; doesn't really have any sliders, and
gamma adjustments are among the things that definetely would not end
up using bablRGB; regardless of how far we get in specifying other
working spaces.

> 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

Is there anything above that hasn't already been stated a couple of times?

gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Reply via email to