Judah Kleinveldt
0079 13 75 406

-----Original Message----- From: gimp-user-list-request@gnome.org Sender: "gimp-user-list" Date: Thu, 06 Nov 2014 19:58:15 To:
Reply-To: gimp-user-list@gnome.org
Subject: gimp-user-list Digest, Vol 38, Issue 10

Send gimp-user-list mailing list submissions to gimp-user-list@gnome.org

To subscribe or unsubscribe via the World Wide Web, visit https://mail.gnome.org/mailman/listinfo/gimp-user-list or, via email, send a message with subject or body 'help' to gimp-user-list-request@gnome.org

You can reach the person managing the list at gimp-user-list-owner@gnome.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of gimp-user-list digest..."

Today's Topics:

1. Re: [Gimp-developer] GIMP should fork babl and GEGL (Elle Stone) 2. Re: [Gimp-developer] GIMP should fork babl and GEGL (Gary Aitken) 3. Re: [Gimp-developer] GIMP should fork babl and GEGL (Alexandre Prokoudine)
4. Re: [Gimp-developer] GIMP should fork babl and GEGL (Gary Aitken) 5. Re: HATE the new save vs. export behavior (Richard) 6. Re: [Gimp-developer] GIMP should fork babl and GEGL (Elle Stone)

----------------------------------------------------------------------

Message: 1 Date: Thu, 06 Nov 2014 07:04:06 -0500 From: Elle Stone
Cc: "gimp-user-list@gnome.org" ,
Gimp-developer
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Message-ID:
Content-Type: text/plain; charset=utf-8; format=flowed

On 11/05/2014 09:40 AM, Jon Nordby wrote:

On 5 November 2014 14:50, Elle Stone wrote:

For the babl code that converts an sRGB image to grayscale for use as a layer mask, do you plan to add a new set of functions that convert from UserRGB to grayscale?

That code would, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images.

For the babl code that converts from color to Y for painting on a mask, that code currently is hard-coded to use sRGB Y values. Do you plan to add a new set of functions that convert from UserRGB to Y for painting on a mask? That code would also, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images.

For all the GIMP UI functions that currently use hard-coded sRGB Y values sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of alternate functions that will use Y values pulled from UserRGB? Again, that new UserRGB code will also work for sRGB images.

How is this not side-by-side implementation?

When I said "operations" I meant GEGL operations: There will be no side-by-side implementation of GEGL operations.

Will this also be true of any editing operations that remain within the GIMP code base, once GIMP is fully geglified?

A separate question - will there actually be any remaining editing operations in the GIMP code base once GIMP is fully geglified?

Yes, we will have to introduce new babl color conversion functions which handle arbitary RGB color spaces by looking up parameters from UserRGB. Both to convert from&to grayscale and between the various RGB spaces. There is no escaping that, as we don't have any code that can handle these cases right now.

OK. This makes sense.

Whether the existing conversion functions with hardcoded sRGB parameters for bablRGB will remain once general functions exists, is an open question. It could be that they will just call into the general RGB color conversion functions with the particular parameters of sRGB.

It seems to me that this might be the preferable course of action. This way there would be no reason for code to be written that tries to second-guess the user's intentions as to whether UserRGB really is the same as GIMP's built-in sRGB.

Or it could be that keeping the functions as-is has benefits that outweigh the cost of keeping the code around, like being able to do performance optimization tricks not possible in the general case.

Speaking as a developer (you all keep telling me I'm a developer), a crucially important guiding principle for writing a high end image editor is that you never mess with the user's RGB data without the user's explicit consent.

If you *ask* the user whether they want to have their data treated as "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data.

What part of the latest new plan am I missing? Could you explain the purpose that is served by having all the functions with hard-coded sRGB parameters sit side by side with equivalent functions that use UserRGB parameters?

Or are you really getting rid of *all* the hard-coded sRGB parameters? In which case, what is the new purpose for the bablRGB formats that "will not change" their meanings?

For operations which have an actual dependency on sRGB parameters, like the previously mentioned operations emulating color blindness.

Two practical problems will need solutions:

First, for code that clearly requires that the image be an sRGB image, converting the image to sRGB without the user's *explicit* consent is disrespecting the user's RGB data. If there are GIMP UI functions that only work for sRGB images, give the user a choice. Don't convert the image to sRGB without the user's explicit consent. Maybe they'd just as soon not use that editing operation.

Second, some functions currently use sRGB and NTSC *device* parameters:

* Some of the existing hard-coded sRGB *device* parameters in the code base clearly ought to be D50-adapted ICC profile parameters. That code should be generalized to use UserRGB Y and XYZ values.

* Some of the functions seem to suggest that the unadapted *device* parameters really are appropriate for the originally intended use, and that the affected functions simply aren't appropriate for use in an ICC profile *color-managed* workflow. These "device" functions should be identified in the UI so the unsuspecting user doesn't try to use these functions thinking they are appropriate for ICC profile color-managed images. I think the color-deficiency filter might actually be one of these functions.

Converting the image to the sRGB or NTSC ICC profile is inappropriate for any device-specific code that for whatever reason might need to remain within the code base. Likewise, any proposed special-case/optimized treatment for sRGB as an ICC profile won't apply to functions that need to use sRGB or NTSC device-based code.

For information about device sRGB vs ICC profile sRGB, see "The Luminance of an sRGB Color",
http://ninedegreesbelow.com/photography/srgb-luminance.html.

Or for
interacting with (sometimes broken) operating-system/library interfaces which expects sRGB. I don't expect it to be particularly common.

In this case, maybe the user should be warned in the UI to disable color management altogether in the Preferences?

Because in this (hopefully extremely uncommon) case it sounds like the user is faced with broken/inappropriate libraries that make proper ICC profile color management impossible.

The primary reason (as I see it) for not changing the semantics of existing specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP could very well be reliant on the current meaning of the bablRGB formats.

This makes perfect sense as a reason for keeping the existing babl specifiers for compatibility, and writing new specifiers for UserRGB for use with GEGL/GIMP.

It sounds like you do understand what I've been trying to explain about problems with unbounded sRGB, and no doubt I've misunderstood some of what you've been trying to say.

Assuming the other babl/GEGL/GIMP devs are on board with what you've just explained, it sounds like high bit depth GIMP really will be (maybe even in time for GIMP 2.10?) a high bit depth and properly ICC profile color-managed RGB free/libre image editor.

Best regards, Elle Stone

------------------------------

Message: 2 Date: Thu, 06 Nov 2014 09:24:08 -0700 From: Gary Aitken
To: "gimp-user-list@gnome.org"
Cc: Gimp-developer
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Message-ID:
Content-Type: text/plain; charset=windows-1252

I'd like to add my penny's worth on this discussion. My primary use of gimp involves editing photographic images, for both web and print purposes.

On 11/06/14 05:04, Elle Stone wrote:

Speaking as a developer (you all keep telling me I'm a developer), a crucially important guiding principle for writing a high end image editor is that you never mess with the user's RGB data without the user's explicit consent.

If you *ask* the user whether they want to have their data treated as "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so. Even if the result is not obvious visually, I need a heads-up so I can pay close attention to what's happening and undo the operation if appropriate.

Gary

------------------------------

Message: 3 Date: Thu, 6 Nov 2014 20:46:50 +0400 From: Alexandre Prokoudine
To: "gimp-user-list@gnome.org"
Cc: Gimp-developer
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Message-ID:

Content-Type: text/plain; charset=UTF-8

On Thu, Nov 6, 2014 at 8:24 PM, Gary Aitken wrote:

If you *ask* the user whether they want to have their data treated as "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so.

Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :)

Alex

------------------------------

Message: 4 Date: Thu, 06 Nov 2014 10:35:02 -0700 From: Gary Aitken
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Message-ID:
Content-Type: text/plain; charset=windows-1252

Hi Alex,

If you *ask* the user whether they want to have their data treated as "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data.

This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so.

Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :)

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.

Gary

------------------------------

Message: 5 Date: Thu, 6 Nov 2014 11:50:00 -0800 From: Richard
To: Patrick Shanahan ,
"gimp-user-list@gnome.org"
Subject: Re: [Gimp-user] HATE the new save vs. export behavior Message-ID:
Content-Type: text/plain; charset="iso-8859-1"

Date: Mon, 3 Nov 2014 14:47:57 -0500 From: ptilopteri@gmail.com
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] HATE the new save vs. export behavior

* Richard [11-03-14 13:27]:

> There's only one "problem" with the current model: I, for one, would love an option to suppress the unsaved changes prompt in the event that I'm working on a simple image file that is exported to a standard file format and has no XCF associated with it. Such as when I'm downscaling digital photos for uploading to the Internet.

BUT, you are using a tool which is not build nor intended for that audience, so you adjust or use a different tool. --

Workflow preferences aside, the tool in question nonetheless does a good job with what I'm trying to use it for, which saves me from having to go find another tool for the same job.

(Tangent: I have a [literal] swiss army knife and what's the function I use most from it? The scissors.)

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

------------------------------

Message: 6 Date: Thu, 06 Nov 2014 15:00:47 -0500 From: Elle Stone
To: gimp@dreamchaser.org, gimp-user-list@gnome.org, Gimp-developer
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
Message-ID:
Content-Type: text/plain; charset=windows-1252; format=flowed

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

------------------------------

Subject: Digest Footer