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

On Thu, Nov 6, 2014 at 10:00 PM, 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

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

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

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?


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