On Sat, Jun 4, 2016 at 11:13 PM, Elle Stone
<ellest...@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, 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.

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

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

I see it as important to get a working 2.10 released, what we
currently have in git is better than GIMP-2.8 in most ways. More
important than to perfect it so that we start the work on making a
GIMP using GTK3 in master - as well as adding more advanced
non-destructive features based on GEGL after 3.0. With GIMP 2.10 and
3.0 maybe there will be an influx of interest from developers or
sponsorship and I have the motivation to properly add such
capabilities to babl myself - for now I am the janitor/maintainer of
GEGL - making sure also not to break expectations other software have
from it - enjoy some goats https://www.youtube.com/watch?v=GJJPgLGrSgc

gimp-developer-list mailing list
List address:    gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Reply via email to