Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

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
> not good.
>
> 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 
XYZ.

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 
editing operation.

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? 
http://ninedegreesbelow.com/photography/srgb-profile-comparison.html).

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" 
code paths.

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.

Best regards,
Elle