On Sat, Jun 4, 2016 at 11:13 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> 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. >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 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. 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 /pippin _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
