Isn't that expected? You don't change color space, for it to have the same results. You choose best color space for the job and use it from beginning to the end, or if you know what you are doing convert it in middle of work to do the thing you want to do. If all color spaces look the same whats the point of using them. 2014-04-10 21:50 GMT+02:00 Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx>: > On 04/09/2014 06:36 PM, Elle Stone wrote: > >> For Lighten only, Darken only, Multiply, Divide, and some of the other >> blend modes, results are *highly dependent* on the color space in which >> the blending is done. Removing clipping code doesn't fix the problem. >> >> If the artist uses any of the color-space dependent blend modes: >> >> * Editing an image in a large gamut color space such as ProPhotoRGB >> produces one set of colors. >> >> * Converting the image to unbounded mode sRGB before editing it >> necessarily produces different colors - sometimes very different colors. >> >> For concrete examples showing how Lighten only and Darken only are >> color-space dependent, see >> http://ninedegreesbelow.com/gimpgit/unbounded-srgb-lighten-darken.html >> >> Can this problem be fixed? Is there a workaround such that an image can >> be converted from its source color space to unbounded mode sRGB, and >> then use the color-space dependent blend modes to produce the same >> colors that would have been produced if the image had been edited in the >> source color space instead of in unbounded mode sRGB? >> >> > I put up two more examples - not blend mode examples, rather channel > mixing and blending examples: > > > 1. Channel blending when converting to black and white > http://ninedegreesbelow.com/gimpgit/unbounded-srgb- > channel-blend-convert-black-white.html > > The example concludes: > > My envisioned conversion to black and white was simple to achieve in my > custom RGB working space: make a luminance-based conversion to black and > white, pull over the blue channel and set it to multiply blend mode, season > to taste. > > Converting the image to unbounded mode sRGB made my envisioned conversion > to black and white completely impossible. > > Worse, if I hadn't examined the blue channel data before the conversion to > the unbounded mode sRGB color space, I never would have seen the original > blue channel data. As the original blue channel contained all the > interesting information in this particular image, I would not have been > inspired to convert the image to black and white. No doubt no loss to art! > but that is not the point. The point is that a conversion to unbounded mode > sRGB radically rearranges channel data, which in turn radically alters the > information the artist has to work with. > > > 2. Using Channel Mixer to decrease saturation > http://ninedegreesbelow.com/gimpgit/unbounded-srgb-channel-mixer-decrease- > saturation.html > > The example concludes: > > Channel data is radically rearranged when a saturated image is converted > from a wider gamut color space to the unbounded mode sRGB color space. A > consequence is that many crucially important editing tools no longer > function properly. Channel mixing is one such tool. > > In the custom RGB color space using Channel Mixer to desaturate the yellow > cone flower worked exactly as expected. > > In the unbounded mode sRGB color space using Channel Mixer to desaturate > the yellow cone flower failed completely. The flower wasn't actually > desaturated, and excessive amounts of the blue channel polluted the image's > original colors. > > > Thanks in advance for looking at the examples. > > Elle > > > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: https://mail.gnome.org/mailman/listinfo/gimp- > developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
