On 11/06/2014 12:35 PM, Gary Aitken wrote:
Maybe I'm misunderstanding the discussion. Gimp asks when one opens an
image what one wants as the working colorspace. But we're talking
about operations *after* the image has been opened and the working
colorspace has been established.
Once I establish the colorspace, I expect all operations to be performed
in a manner which is consistent with and preserves that colorspace. If
some operation deals in some other space without my knowledge, that's
My apologies if I'm misunderstanding the discussion.
You aren't misunderstanding the discussion.
The current proposed solution to the current hard-coded Y and XYZ sRGB
parameters is to generalize all editing operations to use UserRGB Y and
But there are a handful of editing operations that can't be generalized,
that only work properly when done on actual sRGB images.
One proposed solution to the "only works in sRGB" problem is to convert
the image to sRGB for those few editing operations. That would be OK as
an *option*. Even just a UI notification would be sufficient and then
the user could choose to convert to sRGB or to simply not use that
particular editing operation.
Previously (back in April) the plan was to convert all images to
unbounded sRGB before editing would begin, and the user wouldn't have a
choice in the matter.
More recently the plan was to convert to unbounded sRGB for just some
editing operations and use UserRGB for other editing operations, and
again the user wouldn't have a choice in the matter.
At this point we hopefully are down to "only convert to sRGB for those
very few editing operations that really only work in the sRGB color space".
I'm saying "and make sure you still give the user a choice." There
should never, ever be a forced conversion to sRGB. The only correct
thing to do is tell the user what the problem is and let the user decide
what to do, either convert to sRGB or else don't use the affected
In addition to trying to avert any forced ICC profile conversions, I'm
also concerned about special "sRGB only optimized code".
Personally I would prefer that sRGB be treated just like any other RGB
working space, with no special "sRGB only optimized code paths", partly
because there are too many sRGB profile variants (Will the Real sRGB
Profile Please Stand Up?
Giving the user a choice whether to use or not use "optimized sRGB only
code paths" would be OK. Not telling the user that sRGB images might be
handled differently is not OK.
I don't want the devs to decide for me that "this profile is close
enough to sRGB that we'll just assume it really is the same as GIMP's
sRGB and then we'll use different code paths."
Even if the image profile really is the GIMP sRGB profile, I still think
the user should have a choice of whether to use "optimized sRGB only"
Given the previously planned forced conversions to unbounded sRGB, I
think it's important to stress that the user really does need to have
complete control over when and whether:
* an image is converted from UserRGB to sRGB.
* the GIMP sRGB profile is assumed to be "close enough" to some other
sRGB profile variant.
* special optimized sRGB only code is used.
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