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