On Sun, Jun 5, 2016 at 1:16 AM, 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, > > 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 _______________________________________________ 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
