GNOME.org
 

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

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]