GNOME.org
 

Re: [Gimp-developer] New Image/Color Management option

On Sun, Jun 5, 2016 at 1:16 AM, Elle Stone
<ellestone ninedegreesbelow com> wrote:

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.


Most people - including people doing photography and graphic design
work for a living - prefer not to. I used to teach people becoming
such professionals at a university level. It should also be possible
to use GIMP for color scientists and color science geeks that care
more about color accuracy control than image composition.


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.


Or the tools provide professional level outputs; tools for digital
media manipulation are abstractions - and a professional should be
able to use tools without knowing how to reimplement the tools.


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.


These are bugs.


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.


Maybe not, professional photographers might not know that they want
pre-multiplied alpha, linear light data for doing resampling, nor what
goes wrong if the pixel data for some reason isn't pre-multiplied or
linearized, providing constraints that makes such misconfiguration
hard is a service to novice and professional user alike.


The babl flips take that critically important freedom of choice away from
me.




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.




snip<




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.


We make decisions for the user, in what capabilities are included, and
where menu items are. To return to the topic of this thread; the
decision to make it easy to "assume all settings as sRGB" temporarily,
and then flip back to the custom perhaps misconfigured settings is
another such service realising that not all operators of the software
know or care as deeply about ICC workflows as you 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
components.



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:
http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html#chromaticities-matter.

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
(http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html)

Color correction fails in unbounded sRGB
(http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html)

About RGB Colourspace Models Performance
(http://colour-science.org/posts/about-rgb-colourspace-models-performance/)

And this thread: https://www.freelists.org/post/argyllcms/White-Point,45



Why did you "well actually me" and repeat all of the above? I
acknowledge this short-coming, and that it is something we want to
work on and that you are the one that have convinced me and other
developers of this need. I am not re-starting or reiterating this
argument, I am, as I have repeatedly done - acknowledge that this is a
short coming of the current architecture that needs remedying, but
your way of remedying it break other expectations of software using
GEGL.


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* *babl* *flips*.

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.


There is also flipping to/from formats with alpha. Pre-multiplied and
non-premultiplied alpha. As well as flips to/from higher and lower
bit-depths as well as to/from CIE Lab. By necessity of the operations
involved, working on linear data is another one of these constraints
that should be fulfilled. Whenever possible the developer/designer of
image processing algorithms should be burdened with reducing the
number of parameters, as well as sticking with good defaults - making
efficient work-flows possible. If you continue calling it "babl flips"
I will start calling your non-flipping-babl a lobotomized babl - you
could also collapse "RaGaBaA float" into "RGBA float" along with
"R'G'B'A float" to make babl even less capable of providing internal
color / pixel-representation management for GEGL and thus GIMP and
other applications using GEGL. Before scaling or blurring an image a
user would then have to run a pre-multiply filter and after-wards
un-premultiply filter.


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
together.

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).

Problem solved.

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
education.
Aiming low with features like this only makes us, the real audience,
want to run in the opposite direction.


Some of the developers do care about on-boarding of new users and
making the experience of using the tool that GIMP is fluid for both
novices that haven't done any image manipulation before as well as
experts; all operators have to start somewhere; this means being
thoughtful of both defaults and automatic behaviour.

These email threads makes me want to stop volunteering my time, I am
sad that over the last couple of years the many hundreds of hours I
have spent on babl/GEGL/GIMP - a too large portion of them have been
in anger dealing with long email tirades spat out at an alarming rate.
You have repeatedly been invited to turn up at libre graphics meeting;
our annual in person meet-up - with travel expenses covered, where
both professional users are present, and more GIMP developers can
participate without having to read books worth of email (as well as
additional books to understand the disagreements in those email
threads.).

I consider babl/GEGL feature complete for a 2.10 release of GIMP, and
am only intending to incorporate small patches and do semi-periodic
snapshot releases for the benefit of GIMP / GNOME photos / imgflo /
gedl / gnome-scan until after GIMP-3.2 development starts. If I had
more time or energy; I would've focused on improving the mipmap
preview code in GEGL/GIMP, so that the on-canvas preview of both
layers composition and live filters on huge images would be faster -
but those are things that maybe can be picked up on in GIMP-3.0 as
well.

/pippin - maintainer of babl/GEGL
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]