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

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?

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,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]