On 06/04/2016 05:37 PM, Øyvind Kolås wrote:
On Sat, Jun 4, 2016 at 11:13 PM, Elle Stone
If GIMP is being developed for high end workflows as specified in the Vision
statement, then it's important to get input from people who actually use
high end workflows. Gez is exactly such a person. I think I qualify, though
I'm not a professional.
High-end workflows doesn't have to mean that the user understands all
details about things like color-management,
Practical, applied color management is not that complicated. Neither is
understanding the basics of radiometrically correct editing.
A professional high end workflow by definition implies that the user
understands the nature of the provided tools, what the tools can do and
what the limitations are.
some things can be handled
automatically - note that this is not about making it impossible to do
things; but harder to do the wrong thing.
As an experiment, I tried using default babl/GEGL/GIMP patched to use
Rec.2020 Y and XYZ, but with the babl flips intact and using an ICC
profile with the Rec20202 primaries and the sRGB TRC.
I had no way to know, short of looking in the code, which operations
were being done on linearized RGB, and which on perceptually uniform RGB.
Well, sometimes it was obvious. For example GIMP by default uses
perceptually uniform RGB for Curves and Levels, and this is
radiometrically incorrect and produces all kinds of obvious gamma artifacts.
I know exactly when I want to use linear RGB and exactly when I want to
use perceptually uniform RGB, as do other high end/professional users.
The babl flips take that critically important freedom of choice away
I've had a small number of high end users including two bonified
professionals from very different fields look at both default GIMP and my
patched GIMP which has the babl flips disabled. Unanimously these people say
that there is no way they would use default GIMP because the babl flips
interfere with their workflow. Plus they need the option to work in wider
color spaces than sRGB. But they liked using my patched GIMP.
Let's be completely clear about this: These high end users and professionals
aren't praising *my* coding ability or *my* vision for GIMP. I'm a terrible
coder and all I've done in my patched GIMP is disable the babl flips, add a
few extra LCH functionalities, and recently added "anyrgb".
One of the important features of the "babl flips" is that they make
gamma erros as they apply to scaling and blurring, and more go away
see http://www.4p8.com/eric.brasseur/gamma.html GEGL code in general
prefers using linear variants of the used RGB color-space for
processing (and compositing).
One of the professionals who has used my patched GIMP (actually there
were three professional that I know of, I don't usually ask people who
send me emails what they do for a living, but sometimes they tell me
anyway) has specifically noted that for scaling an image to a larger
size, scaling perceptually uniform RGB can provide a smoother result.
And the babl flips take this option away from users of default GIMP.
This points to a shortcoming in the "make all the decisions for the
user" approach to coding: It assumes the devs know better than the users
what is the right thing to do.
One major short-coming of babl/GEGL
color handling currently - as elle has pointed out, is for operations
that multiply pixels values - like the multiply layer mode - most
editing features in GIMP do not rely on multiplication of color
Well, actually many editing operations in GIMP are
chromaticity-dependent, producing different results in different RGB
working spaces, precisely because multiply itself is chromaticity-dependent.
For a list see Section B of this article:
For editing examples, see Section C of the same article.
For a more technical discussion, see these three articles:
Multiplying out of gamut colors in the unbounded sRGB color space
produces meaningless results
Color correction fails in unbounded sRGB
About RGB Colourspace Models Performance
And this thread: https://www.freelists.org/post/argyllcms/White-Point,45
At the moment things are a mix of constraints of 8bit like GIMP-2.8
had and how closely workflows from 2.8 are reproducible in the
development version, some features and menu options in GIMP-2.9 are
not desirable as a finished streamlined GEGL based editing experience.
This is exactly what Gez was saying: there are constraints on GIMP 2.10
for legacy/backward-compatibility reasons.
After GIMP-2.10 and GIMP-3.0 get released; I hope we can see a
significant trimming down of the UI for instance the precision menu in
GIMP, defaulting to 32bit floating point with linear TRC (maybe with
precision over-ridable per layer - to save memory) in addition to
It would be excellent to have default 32f *linear* *gamma* processing
(no babl flips to perceptually uniform RGB behind the user's back and
without their consent), preferably coupled with a "per layer/layer
group" user option to choose a perceptually uniform TRC. Otherwise the
user needs the option to convert to a profile with a user-chosen TRC,
and of course the user needs this option anyway, and again with *no*
If the babl flips are flipping the RGB channels back and forth between
linear and perceptually uniform RGB without the *user* being able to
control the encoding, this is a design decision that precludes using
high bit depth GIMP for high end/professional workflows.
other improvements that might break more GIMP-2.8 era assumptions and
constraints. This is also when experimenting with filters embedded in
the layer stack similar to adjustment layers/effect layers and more is
on the roadmap.
Elles simplified babl/GEGL with removed the TRC to/from linear
conversions or as she calls it "babl flips" will make GIMP produce
wrong results for scaling, blurring and more - *unless* the user has
specifically chosen to edit in a linear RGB space; only then will
scaling or blurring and other resampling produce correct results.
Exactly and by design. The user needs control over their RGB data.
Another issue not dealt with by Elles approach to patching babl/GEGL
is juggling multiple immutable different RGB formats in one process.
GIMP can open multiple images with different ICC profiles - and we
want users to be able to predictably view and copy/paste between
multiple images with different profiles. How this is dealt with isn't
certain - some ideas have gone into a babl roadmap, but the needs are
summed up in this email.
Well, let's see how this might be handled:
First the user picks the color space for compositing the image layers
Then the user drags the layers over from other image layer stacks, and
if the source and destination layer stacks are in different ICC profile
color spaces, a conversion is done during the drag and drop operation
(which Mitch already added code to make happen).
Oh, if "predicatably view" means "always get the same result from all
compositing operations", then the developer must command and enforce
that the user can only composite in a working space that the developer
has a priori chosen, precisely because multiply is a
chromaticity-dependent editing operation that affects a multitude of
editing operations and blend modes.
High end work flows absolutely require that the user be in control of
the compositing color space.
If the consensus among the devs (the devs that control the overall
course of GIMP development) is that GIMP is for "don't know and don't
want to know" users, then please revise the Vision statement
accordingly, and feel free to keep those babl flips.
Revising the Vision statement would clarify the nature of the project on
which we are all working as a team, and perhaps some of us would choose
to not continue participating in GIMP development. I believe this is one
of the points that Gez was making when he said:
And if things keep going in this direction, GIMP will end up losing the
handful of people actually using it seriously and caring about it.
Instead of focusing on imagers devs seem to be focusing on eventual
users who only use the tool once a month for scaling some photos and
remove red eyes or making banners for online forums.
If that's the audience you care about, please amend the product vision
so people like me can move on, since there is no future for us with
GIMP. Eventual users and clueless people can learn. It only takes
Aiming low with features like this only makes us, the real audience,
want to run in the opposite direction.
gimp-developer-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list