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

[Simos Xenitellis <simos lists googlemail com>]

On Thu, Nov 6, 2014 at 10:00 PM, Elle Stone <ellestone ninedegreesbelow com>
wrote:

> 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.
Hi All,

I am a recent subscriber to the list and I have read with interest the
recent threads and I am trying to figure out the "what next?".
Developer resources in any project are generally very limited, so it's
important to get more people contributing.

Is there a test suite available that could show the expected behavior?
If not, let's try to build one, both the test-suite code plus the images
(before/after).

Regarding the color spaces and conversions, it should be easy to try to
make some of the the changes
(most of them sound like simple text substitutions),
compile the source and see how well it performs on the test-suite.
Any comments on that?

Simos