GNOME.org
 

Re: [Gimp-user] gimp-user-list Digest, Vol 38, Issue 10

 
Judah Kleinveldt
0079 13 75 406

-----Original Message-----
From: gimp-user-list-request gnome org
Sender: "gimp-user-list" <gimp-user-list-bounces gnome org>Date: Thu, 06 Nov 2014 19:58:15 
To: <gimp-user-list gnome org>
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 <ellestone ninedegreesbelow com>
Cc: "gimp-user-list gnome org" <gimp-user-list gnome org>,
        Gimp-developer <gimp-developer-list gnome org>
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and
        GEGL
Message-ID: <545B63B6 1080600 ninedegreesbelow com>
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 <gimp dreamchaser org>
To: "gimp-user-list gnome org" <gimp-user-list gnome org>
Cc: Gimp-developer <gimp-developer-list gnome org>
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and
        GEGL
Message-ID: <545BA0A8 10806 dreamchaser org>
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 <alexandre prokoudine gmail com>
To: "gimp-user-list gnome org" <gimp-user-list gnome org>
Cc: Gimp-developer <gimp-developer-list gnome org>
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and
        GEGL
Message-ID:
        <CAFjkzc1SVHr-30XQbXXdC=k4wM=UvenquiE5TA8yYSJeOsF1VA mail gmail com>
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 <gimp dreamchaser org>
To: gimp-user-list gnome org
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and
        GEGL
Message-ID: <545BB146 20402 dreamchaser org>
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 <strata_ranger hotmail com>
To: Patrick Shanahan <ptilopteri gmail com>,
        "gimp-user-list gnome org"      <gimp-user-list gnome org>
Subject: Re: [Gimp-user] HATE the new save vs. export behavior
Message-ID: <BAY172-W1956DDD4035639E40C09BE9C840 phx gbl>
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 <strata_ranger hotmail com> [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 <ellestone ninedegreesbelow com>
To: gimp dreamchaser org, gimp-user-list gnome org,     Gimp-developer
        <gimp-developer-list gnome org>
Subject: Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and
        GEGL
Message-ID: <545BD36F 4040005 ninedegreesbelow com>
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

_______________________________________________
gimp-user-list mailing list
gimp-user-list gnome org
https://mail.gnome.org/mailman/listinfo/gimp-user-list


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

End of gimp-user-list Digest, Vol 38, Issue 10
**********************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]