On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone <[email protected]> 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? /pippin _______________________________________________ gimp-user-list mailing list List address: [email protected] List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
