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
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
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",
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
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.
gimp-user-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list