Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 12:40 -0400, Elle Stone escribió: > Well, you might be able to answer that question. I'm not qualified. > Personally I don't use alpha channels except in the extremely rare > instance when I'm exporting a png with a transparent background for use > on a website. See, this is exactly what I intended to discuss. You know a lot about linear and perceptual gamma, so in your opinion everything has to be tailored to allow you to play as you wish with gamma. For you it is essential. Now, you think you don't use alpha channels, so you don't care much about the options provided. But you actually use alpha channels a lot: every time you create a layer mask you're creating an alpha channel for that layer, and if that alpha is associated or unassociated makes a big difference. AFAIK, most of the time alpha channel is unassociated in GIMP, but when you have to apply any convolution you have to "pre-multiply" it. And what about alpha channels being linear or perceptual? Why don't you care? In that case, developers chose for you, and you don't seem to feel too bad about it. And believe me, when it comes to alpha channel THERE IS right and wrong, no matter what the artist says. Blending modes and other operations have been designed to work in certain way. They have an intended result. Unfortunately limitations in the available technology in the past forced programs to do things as alpha compositing in 8 bit gamma. It looks like shit but users got used to that appearance. That doesn't mean that alpha compositing in gamma space is ok and it is a valid option so programs SHOULD allow it. It's an infortunate legacy that could be corrected by making the tool work as it should work, as it is intended to work. Some people may want having the uglyness back, so a special (optional) tool to override the proper behavior with that crap could be used. Personally, I'd love to see all the operations work on linear data only. If a mechanism for overrides is in place, getting legacy support would be probably just matter of setting a global override making everything work in gamma. In both cases an extra tool could allow flipping stuff to the other "mode" temporarily. In the case of gamma we've been discussing it is something that seems to be just one "gamma node" away. Actually, you don't even need that. with enough bit depth the levels tool alone is good for making gamma stuff more or less linear and linear more or less perceptually uniform, for artistic purposes. And since you don't seem to worry about "right" or "wrong" results, that should suffice. Gez. ___ 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
[Gimp-developer] GIMP needs a new color management person, take 2
You all have created an amazing RGB image editor. But proper color management has always taken a back seat. GIMP users have requested better color management and CMYK support for a long time now. You could have taken full working color management code from Cinepaint or Krita years ago, but you didn't. Instead you tried to reinvent the color management wheel with unbounded sRGB as a universal RGB working space, which apparently nobody bothered to test to see if it actually worked (it doesn't: http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html). Not too long ago one of the devs stated on IRC that GIMP 2.10 would use unbounded sRGB, leaving me with the impression that the several months of hard work that I spent documenting problems with unbounded sRGB as a universal working space were completely wasted. The GIMP devs need to rid the babl/GEGL/GIMP code of all traces of "only sRGB" coding (http://ninedegreesbelow.com/bug-reports/gimp-hard-coded-sRGB.html). But other software that uses GEGL needs babl to only use the sRGB primaries and TRC until someone finds the time to write new code to exist alongside the "sRGB only" babl code. So GIMP color management is taking a backseat to other software that uses babl/GEGL. A long time ago I wrote code for the LCMS plugin that enables GIMP to do RGB/grayscale conversions, as a preliminary step towards figuring out how to do RGB/CMYK conversions (not saying I would have succeeded, good CMYK code probably needs to be written by someone who actually uses CMYK). But then the developers announced that the LCMS code was going to be moved to GEGL (still hasn't happened, thankfully) and I lost interest in working on the LCMS code. GIMP should not let GEGL handle color management as GEGL is used in other programs and GIMP would always have to compete with the color management needs of those other programs. A Google summer of code student wrote fourier code for GEGL, and it can't be used because of GEGL license issues. This is just wrong. GIMP needs fourier code for proper lens blur (http://ninedegreesbelow.com/bug-reports/camera-fourier-gaussian-blurs-compared.html; Krita has proper lens blur; GIMP does not). GIMP shouldn't be hampered by GEGL licensing. Right now for OpenEXR images, the image is opened, it's assumed to be a linear gamma sRGB image (really bad assumption), the sRGB TRC is applied, and the GIMP built-in sRGB profile is assigned (https://bugzilla.gnome.org/show_bug.cgi?id=316646). This is laughably wrong. Instead of removing the coding step that applies the sRGB TRC and giving the user a chance to *assign* the right ICC profile (I supplied a patch to do just that), the plan as discussed on IRC and in the bug report seems to be to extend the "auto sRGB TRC" assumption right into the LCMS plugin itself, which is a mind-boggling wrong thing to do. My apologies for double-posting. I didn't mean this to be a reply to the thread on user options to choose linear vs perceptual RGB. So I'm posting again as a separate thread. Maybe it's against protocol, but I find I don't care much. I use hacked versions of high bit depth GIMP for image editing - four of them, one for each color space that I use - and I'm very much enjoying finally being able to edit high bit depth images with masks and layers using free/libre software (other than having excellent color management, Cinepaint turned out to be a joke; Krita is aimed at digital artists and until recently flat-out wouldn't run on my system, but now runs just fine, thank you Krita devs!). In my hacked versions of babl/GEGL/GIMP the babl flips are disabled, with LCH blend modes patched in (http://ninedegreesbelow.com/photography/gimp-lch-blend-modes.html), and with all the hard-coded sRGB values replaced by the Y and XYZ values that are appropriate to my preferred RGB working spaces (http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#wider-gamut-working-space-workarounds). I wish that having proper GIMP RGB color management didn't mean hacking the code for each and every color space I want to use, but that's the current situation. I wish I had the coding skills to recode babl/GEGL/GIMP color management to give the user control over her RGB data and to not use hard-coded sRGB, but I don't. I wish the babl/GEGL/GIMP devs could be persuaded to use the babl flips to empower GIMP users than to limit what users are allowed to do with their own RGB data, but I don't have much hope for that happening. I wish I were rich and could hire developers to fork GIMP and do color management the right way, but I'm not. I'm very glad to have had the chance to work with you all for the last couple of years. For various reasons I've decided to bow out from further active participation in GIMP development, though I still plan to make bug reports and submit the occasional patch. If anyone has a color mana
[Gimp-developer] GIMP needs a new color management person
You all have created an amazing RGB image editor. But proper color management has always taken a back seat. GIMP users have requested better color management and CMYK support for a long time now. You could have taken full working color management code from Cinepaint or Krita years ago, but you didn't. Instead you tried to reinvent the color management wheel with unbounded sRGB as a universal RGB working space, which apparently nobody bothered to test to see if it actually worked (it doesn't: http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html). Not too long ago one of the devs stated on IRC that GIMP 2.10 would use unbounded sRGB, leaving me with the impression that the several months of hard work that I spent documenting problems with unbounded sRGB as a universal working space were completely wasted. The GIMP devs need to rid the babl/GEGL/GIMP code of all traces of "only sRGB" coding (http://ninedegreesbelow.com/bug-reports/gimp-hard-coded-sRGB.html). But other software that uses GEGL needs babl to only use the sRGB primaries and TRC until someone finds the time to write new code to exist alongside the "sRGB only" babl code. So GIMP color management is taking a backseat to other software that uses babl/GEGL. A long time ago I wrote code for the LCMS plugin that enables GIMP to do RGB/grayscale conversions, as a preliminary step towards figuring out how to do RGB/CMYK conversions (not saying I would have succeeded, good CMYK code probably needs to be written by someone who actually uses CMYK). But then the developers announced that the LCMS code was going to be moved to GEGL (still hasn't happened, thankfully) and I lost interest in working on the LCMS code. GIMP should not let GEGL handle color management as GEGL is used in other programs and GIMP would always have to compete with the color management needs of those other programs. A Google summer of code student wrote fourier code for GEGL, and it can't be used because of GEGL license issues. This is just wrong. GIMP needs fourier code for proper lens blur (http://ninedegreesbelow.com/bug-reports/camera-fourier-gaussian-blurs-compared.html; Krita has proper lens blur; GIMP does not). GIMP shouldn't be hampered by GEGL licensing. Right now for OpenEXR images, the image is opened, it's assumed to be a linear gamma sRGB image (really bad assumption), the sRGB TRC is applied, and the GIMP built-in sRGB profile is assigned (https://bugzilla.gnome.org/show_bug.cgi?id=316646). This is laughably wrong. Instead of removing the coding step that applies the sRGB TRC and giving the user a chance to *assign* the right ICC profile (I supplied a patch to do just that), the plan as discussed on IRC and in the bug report seems to be to extend the "auto sRGB TRC" assumption right into the LCMS plugin itself, which is a mind-boggling wrong thing to do. I use hacked versions of high bit depth GIMP for image editing - four of them, one for each color space that I use - and I'm very much enjoying finally being able to edit high bit depth images with masks and layers using free/libre software (other than having excellent color management, Cinepaint turned out to be a joke; Krita is aimed at digital artists and until recently flat-out wouldn't run on my system, but now runs just fine, thank you Krita devs!). In my hacked versions of babl/GEGL/GIMP the babl flips are disabled, with LCH blend modes patched in (http://ninedegreesbelow.com/photography/gimp-lch-blend-modes.html), and with all the hard-coded sRGB values replaced by the Y and XYZ values that are appropriate to my preferred RGB working spaces (http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#wider-gamut-working-space-workarounds). I wish that having proper GIMP RGB color management didn't mean hacking the code for each and every color space I want to use, but that's the current situation. I wish I had the coding skills to recode babl/GEGL/GIMP color management to give the user control over her RGB data and to not use hard-coded sRGB, but I don't. I wish the babl/GEGL/GIMP devs could be persuaded to use the babl flips to empower GIMP users than to limit what users are allowed to do with their own RGB data, but I don't have much hope for that happening. I wish I were rich and could hire developers to fork GIMP and do color management the right way, but I'm not. I'm very glad to have had the chance to work with you all for the last couple of years. For various reasons I've decided to bow out from further active participation in GIMP development, though I still plan to make bug reports and submit the occasional patch. If anyone has a color management question that I might be able to help with, send me a private email (I'm unsubscribing from the list). And if anyone wants to fork GIMP, send me an email because I might want to lend a hand. Best, Elle Stone -- http://ninedegree
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/02/2015 03:39 PM, Øyvind Kolås wrote: I'm not entirely sure what you are proposing or how it could be implemented >in the UI. Is this what you mean? > >1. Make a list of all RGB editing operations that are provided by GIMP. > >2. Decide for each operation whether it should be done using linear or >perceptual RGB and set that as the default way the operation will be done. > >3. Figure out which RGB operations "legitimately" should also be allowed to >be done using the opposite choice from what the developers decided. > >4. For the operations for which users can choose other than the default, do >what? I can think of two possibilities: > > i. Make an entirely new RGB editing operation. For example >Curves-linear and Curves-perceptual, Gradient-linear and >Gradient-perceptual, Soft-light-blend-linear and >Soft-light-blend-perceptual, and so forth. Then stuff these new editing >operations into the menu. > > ii. Put an override button on the UI for the particular layer blend >mode or tools/operation UI. But you said specifically said you don't want to >put additional, possibly confusing buttons in the UI. > >Is above close to what you are envisioning? Nope, I envison the operator of GIMP to do a*separate* action before a particular action to override the default/sane pixelformat for, and then a*separate* action afterwards. What does this separate action before and after the RGB operation look like in the UI? You are saying that this "three click" approach is better from a user viewpoint than simply having a button on the Curves UI to switch between the clearly marked default and the alternative? For some particular operations more direct ways of achieving it can be provided if it is common tasks; like for instance adding the ability to do curves/levels in CIE Lab instead of RGB; but in general the sledge hammer to offer the operator this ability is additional actions. So if users are allowed to choose between perceptual and linear for RGB Curves, there might be two Curves operations, each with their own entry in the UI, one for linear RGB and one for perceptual RGB? How is this a cleaner UI than one Curves dialog with a button? Or do you mean one UI entry for linear RGB Curves and one for CIELAB Curves? CIELAB Curves is not a substitute for RGB Curves, though CIELAB Curves would be an excellent addition to GIMP. What about layer blend modes? Will there be two layer blend modes, one for linear and one for perceputal, for those layer blend modes for which the devs decide the user should be given a choice? The "button on the layer or tool interface" approach does seem like a cleaner solution from the UI point of view. Best, Elle ___ 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
[Gimp-developer] I got on this list by accident - which should not be possible but that's another issue. Can you please delete me
___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On Sat, May 2, 2015 at 3:12 PM, Elle Stone wrote: > On 05/02/2015 02:44 PM, Øyvind Kolås wrote: >> >> On Sat, May 2, 2015 at 9:45 AM, Elle Stone >> wrote: >>> >>> To be more blunt, the babl flips are Pippin's brain-child. If Pippin says >>> "no user choice", is there any real benefit to anyone if I write up a >>> spec? >>> Wouldn't it just be a waste of everyone's time? >> >> >> I have not stated *no*user*choice*, but I have stated that good ways >> to let the user override these choices seem to be more along the lines >> of what Gez is proposing, explicit conversions to and from other >> working spaces / linearity / unpremultiplication. Let it be a separate >> manual step to override sane defaults where sane defaults helps the >> vast majority of uses by both operators of the software unaware of >> these nuances as well as color management experts. This can be done as >> separate actions without having additional, possibly confusing, >> buttons in the UI. > > > I'm not entirely sure what you are proposing or how it could be implemented > in the UI. Is this what you mean? > > 1. Make a list of all RGB editing operations that are provided by GIMP. > > 2. Decide for each operation whether it should be done using linear or > perceptual RGB and set that as the default way the operation will be done. > > 3. Figure out which RGB operations "legitimately" should also be allowed to > be done using the opposite choice from what the developers decided. > > 4. For the operations for which users can choose other than the default, do > what? I can think of two possibilities: > > i. Make an entirely new RGB editing operation. For example > Curves-linear and Curves-perceptual, Gradient-linear and > Gradient-perceptual, Soft-light-blend-linear and > Soft-light-blend-perceptual, and so forth. Then stuff these new editing > operations into the menu. > > ii. Put an override button on the UI for the particular layer blend > mode or tools/operation UI. But you said specifically said you don't want to > put additional, possibly confusing buttons in the UI. > > Is above close to what you are envisioning? Nope, I envison the operator of GIMP to do a *separate* action before a particular action to override the default/sane pixelformat for, and then a *separate* action afterwards. For some particular operations more direct ways of achieving it can be provided if it is common tasks; like for instance adding the ability to do curves/levels in CIE Lab instead of RGB; but in general the sledge hammer to offer the operator this ability is additional actions. > Sometimes babl/GEGL/GIMP developers say things that make me think that some > of the devs think GIMP users as a whole are not very bright people. Even though humans and other primates that glow in the dark are part of our intended user base, too bright people might have problems - in particular if their screens are reflective. Designing user interfaces is tricky; and often it helps to try to make them work well also for drunk or otherwise impaired operators; if they work well for that – the tools should work even better for fully present and competent operators. /pippin ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/02/2015 02:44 PM, Øyvind Kolås wrote: On Sat, May 2, 2015 at 9:45 AM, Elle Stone wrote: To be more blunt, the babl flips are Pippin's brain-child. If Pippin says "no user choice", is there any real benefit to anyone if I write up a spec? Wouldn't it just be a waste of everyone's time? I have not stated *no*user*choice*, but I have stated that good ways to let the user override these choices seem to be more along the lines of what Gez is proposing, explicit conversions to and from other working spaces / linearity / unpremultiplication. Let it be a separate manual step to override sane defaults where sane defaults helps the vast majority of uses by both operators of the software unaware of these nuances as well as color management experts. This can be done as separate actions without having additional, possibly confusing, buttons in the UI. I'm not entirely sure what you are proposing or how it could be implemented in the UI. Is this what you mean? 1. Make a list of all RGB editing operations that are provided by GIMP. 2. Decide for each operation whether it should be done using linear or perceptual RGB and set that as the default way the operation will be done. 3. Figure out which RGB operations "legitimately" should also be allowed to be done using the opposite choice from what the developers decided. 4. For the operations for which users can choose other than the default, do what? I can think of two possibilities: i. Make an entirely new RGB editing operation. For example Curves-linear and Curves-perceptual, Gradient-linear and Gradient-perceptual, Soft-light-blend-linear and Soft-light-blend-perceptual, and so forth. Then stuff these new editing operations into the menu. ii. Put an override button on the UI for the particular layer blend mode or tools/operation UI. But you said specifically said you don't want to put additional, possibly confusing buttons in the UI. Is above close to what you are envisioning? Does anyone on this list seriously find the idea of a button that says "Linear", that can be clicked to become "Perceptual" or vice versa, too confusing to use? Sometimes babl/GEGL/GIMP developers say things that make me think that some of the devs think GIMP users as a whole are not very bright people. Best, Elle ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On Sat, May 2, 2015 at 9:45 AM, Elle Stone wrote: > To be more blunt, the babl flips are Pippin's brain-child. If Pippin says > "no user choice", is there any real benefit to anyone if I write up a spec? > Wouldn't it just be a waste of everyone's time? I have not stated *no*user*choice*, but I have stated that good ways to let the user override these choices seem to be more along the lines of what Gez is proposing, explicit conversions to and from other working spaces / linearity / unpremultiplication. Let it be a separate manual step to override sane defaults where sane defaults helps the vast majority of uses by both operators of the software unaware of these nuances as well as color management experts. This can be done as separate actions without having additional, possibly confusing, buttons in the UI. On a related note, I hope we get rid of the FIR / IIR UI choice in gaussian blur - that is parts of our UI which in reality are even less useful for our operators. /pippin ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/02/2015 10:21 AM, Gez wrote: El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: But you're not proposing to add a toggle to gradients alone, you're proposing to put them*everywhere*. Yes. And your reason is that users have to decide how operations are performed, no matter the result, no matter if it makes any sense or it doesn't. In the specific case of perceptual vs linear RGB, the user is the only person qualified to say whether it makes sense or not. The toggle or other mechanism for allowing the user choice between perceptual and linear RGB should plainly indicate the default choice made by the devs. But the user needs the option to override the default choice made by the devs. A tooltip that educates the user about why the default makes sense would be a nice addition. So what about other aspects like alpha association then? Should toggles be added everywhere for that too so the users can decide if alpha will be associated or unassociated? Well, you might be able to answer that question. I'm not qualified. Personally I don't use alpha channels except in the extremely rare instance when I'm exporting a png with a transparent background for use on a website. I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. You are presupposing that the devs can foresee every possible use to which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. "Let me do whatever I want" is not a good argument. Gez, you want explicit, known-in-advance justifications for every exception to your proposed rule that all RGB editing operations should operate on linear RGB, with no user choise to override the default. Let's say that as developers we take the time to examine every single RGB editing operation supplied by GIMP. Let's say we can find good reasons for allowing 50% of all RGB operations to have a user choice between linear and perceptually uniform RGB: First, how much is the UI less complicated if only 50% (or 30%, or whatever percentage you'd like to pull out of a hat) of the RGB editing operations have a means to allow the user to override the developer-set default? Second, what if we make a mistake with one of the "no user option" operations? Right now drawing a gradient can only be done using perceptual RGB, and on radiometric grounds that is a mistake. But on artistic grounds, it depends on the artist's intention. Giving the user choice with respect to linear vs perceptual RGB provides a necessary safety net for developer mistakes. Unlike Robert Krawitz's wonderful examples from Gutenprint, GIMP users aren't running any risk of physically harming their digital darkroom when they go against developer defaults. The worse thing that might happen is they might learn something about why certain defaults were chosen in the first place. The need of linear and perceptually uniform gradients is a real need. You can easily document when you need one or the other and create simple examples. Now, give me a good example why scaling should be better done in perceptual gamma (other than preserving legacy appearance, which is the ugly situation that took us here in the first place). Personally I can only think of two specific use cases: Pedagogic: teaching a class on why scaling should be done using linear RGB. Artistic: I was quite amused to see that the lights in this image twinkle as the image is scaled larger and smaller by the Firefox browser: http://ninedegreesbelow.com/tcb/img/pine-branch-over-lake.jpg I can imagine an artist deliberately making a background image where lights twinkle as the image scales up and down. You will rightly say that there are other ways to acheive the same effect. So what? You'll find soon that aside from keeping legacy appearance, > the situations where you need operations to actually work in > perceptual gamma are rare. I don't have a personal stake in keeping legacy appearance, not having any legacy files. Nonetheless, removing user choice regarding perceptual vs linear will invalidate an awful lot of user workflows right off the bat before the user has a chance to figure out why linear gamma RGB is often a better choice to get them to where they want to go. I've been working with linear gamma image editing in the specific context of editing high bit depth photographic images since around 2005, which doesn't make me an expert, just saying I do have some experience. I prefer to edit using linear gamma RGB as much as possible. However, the instances where I choose to use perceptual RGB aren't rare but rather fairly common depending on the particular editing task and artistic goal. There are specific editing operations
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 11:18 -0400, Robert Krawitz escribió: > On Sat, 02 May 2015 11:21:37 -0300, Gez wrote: > > El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: > >> > I'd like to see this discussion heading towards a real world list of > >> > examples of real needs for such options that can't be satisfied with > >> > anything else than these toggles. > >> > >> You are presupposing that the devs can foresee every possible use to > >> which a user might put a given editing operation. > > > > No, I'm saying that users like us should describe real world situations > > where certain options are needed in order to convince developers of the > > necessity of such options. > > "Let me do whatever I want" is not a good argument. > > Yes it is, because we don't know every possible use to which someone > will put something. > > We've had the same issue come up in Gutenprint. Gutenprint exposes > just about every internal control option to users, if they want to > play with them. It allows things that could actually cause _physical_ > damage to printers, in particular specifying ink limits so high that > they would completely soak through non-coated paper and would form > large puddles on coated papers that could gum up the print head. > > But then it turned out that people wanted to do things with printers > that we had never envisioned: printing T-shirts, and doing chemical > deposition (in one case, literally printing circuits onto paper using > electroconductive inks). It turned out to be very fortunate for those > users that we had never imposed limits of that kind because "that > isn't something anybody should be doing". > > The one concession that we did make was to group options into > different levels of interface complexity, and add an option to the PPD > file generator to generate simplified PPD files with only the basic > options. But the default is to use the full-featured interface. > > Obviously there are resource constraints here; developers can only do > so much, and have to make decisions about what to do that are mutually > exclusive on time constraints alone. But deliberately leaving > something out of this kind of project because there isn't an obvious > real world use case is not, in my view, a good thing. Let me clarify that I'm not against flexibility or giving users control on the processes. It's not about choosing between no control and full control. Is finding a balance where a UI provides the necessary tools for the regular job without hindering the possibility of experimentation. It's extremely difficult to create a UI that both exposes every possible user and provides a fast and comfortable workflow. Adding checkboxes and buttons for every need doesn't solve the issue. Pretending that you can separate the "basic" and the "advanced" users in two simple groups by providing insufficient tools for basic users and the cluttered UI for advanced ones is not going to result in a good tool. Nodal UIs aren't perfect, but provide a good balance because every tool is an individual node, and power and flexibility come from combining those nodes. In this case of linear vs. perceptual, a gamma node would allow to turn every operation in a linear workflow into perceptual. Notice how different is the paradigm: a single tool that changes how other tools act instead of adding an extra option to every single tool. And a tool that is added on demand, only people who want to use it will be exposed to it, and the rest wouldn't be disturbed by a cluttered interface. Unfortunately, the UI paradigm in GIMP and similar applications makes this really difficult, because it's inherited from a time where all the operations were sequential and destructive. Again legacy stopping progress. Part of this is a UI problem, and adding buttons or checkboxes for every possible alternative isn't a good way to design UIs. https://twitter.com/cowbs/status/516045565847535616 ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On Sat, 02 May 2015 11:21:37 -0300, Gez wrote: > El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: >> > I'd like to see this discussion heading towards a real world list of >> > examples of real needs for such options that can't be satisfied with >> > anything else than these toggles. >> >> You are presupposing that the devs can foresee every possible use to >> which a user might put a given editing operation. > > No, I'm saying that users like us should describe real world situations > where certain options are needed in order to convince developers of the > necessity of such options. > "Let me do whatever I want" is not a good argument. Yes it is, because we don't know every possible use to which someone will put something. We've had the same issue come up in Gutenprint. Gutenprint exposes just about every internal control option to users, if they want to play with them. It allows things that could actually cause _physical_ damage to printers, in particular specifying ink limits so high that they would completely soak through non-coated paper and would form large puddles on coated papers that could gum up the print head. But then it turned out that people wanted to do things with printers that we had never envisioned: printing T-shirts, and doing chemical deposition (in one case, literally printing circuits onto paper using electroconductive inks). It turned out to be very fortunate for those users that we had never imposed limits of that kind because "that isn't something anybody should be doing". The one concession that we did make was to group options into different levels of interface complexity, and add an option to the PPD file generator to generate simplified PPD files with only the basic options. But the default is to use the full-featured interface. Obviously there are resource constraints here; developers can only do so much, and have to make decisions about what to do that are mutually exclusive on time constraints alone. But deliberately leaving something out of this kind of project because there isn't an obvious real world use case is not, in my view, a good thing. -- Robert Krawitz *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: > > But you're not proposing to add a toggle to gradients alone, you're > > proposing to put them*everywhere*. > > Yes. And your reason is that users have to decide how operations are performed, no matter the result, no matter if it makes any sense or it doesn't. So what about other aspects like alpha association then? Should toggles be added everywhere for that too so the users can decide if alpha will be associated or unassociated? > > I'd like to see this discussion heading towards a real world list of > > examples of real needs for such options that can't be satisfied with > > anything else than these toggles. > > You are presupposing that the devs can foresee every possible use to > which a user might put a given editing operation. No, I'm saying that users like us should describe real world situations where certain options are needed in order to convince developers of the necessity of such options. "Let me do whatever I want" is not a good argument. The need of linear and perceptually uniform gradients is a real need. You can easily document when you need one or the other and create simple examples. Now, give me a good example why scaling should be better done in perceptual gamma (other than preserving legacy appearance, which is the ugly situation that took us here in the first place). You'll find soon that aside from keeping legacy appearance, the situations where you need operations to actually work in perceptual gamma are rare. So in practice, combining linear and perceptual back and forth during your work is not something you need all the time. Tell me for instance why in your UI proposal you merged a layer using the screen blending mode in perceptual gamma. What's the need there, what's the effect achieved? Each case is different and should be designed according the needs. That's what design is about. Addressing needs and crafting solutions. Again: "I want to do whatever I want with the tool" is not a good starting point. You can use your laptop as a hammer if you want, but it's not designed for that use and you can't expect designers to contemplate that use when they plan the thing. > Currently the user does already have linear vs perceptual choices > through the GIMP UI for most editing operations (scaling is always > linear, drawing a gradient is always perceptual). > > Currently the user can use or not use the gamma hack. And the user can > use linear or gamma precision. That's two time two equals four > possibilities for the user to try for each and every editing operation. Again: developers have already said that the gamma hack and even the precision modes are a temporary situation and they are not final. You're exposing your case based on the wrong assumption that those things are going to stay as they are. > Now tell me without taking the time to try all four possibilities: > > How does the user get a linear gradient? (sorry, you can't) That's a reasonable question. It's easy to show why true linear gradients are necessary. > How does the user get linear gamma channel mixer? > How does the user get perceptually uniform Filter/Noise/Add RGB noise? I think you're asking the wrong questions. The real question is: Why and when operations should be performed in perceptual gamma? The answer seems to be (at this point at least) legacy appearance. Most of the times. So, if the goal is to release a GEGLized GIMP that provides the same results as 2.8.x, tools have to work like that. I don't like it and I'd prefer that a true linear workflow is implemented where nothing has to be flipped to perceptual unless there's a good reason. And I bet that those good reasons would be rare, real exceptions that could be treated as such. Why don't we use the energy and time we're using for these discussions for documenting an artist workflow based on linear RGBA (as most of the modern digital compositing packages use)? ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/02/2015 09:00 AM, Michael Schumacher wrote: On 05/02/2015 01:28 PM, Elle Stone wrote: On 04/30/2015 05:43 PM, Michael Schumacher wrote: For examples have a look at the Save & Export and Single Window Mode specifications: * http://gui.gimp.org/index.php/Save_%2B_export_specification * http://gui.gimp.org/index.php/Single-window_mode_specification I am willing to write up formal specifications but only if there is a consensus from the main devs that the proposal for changing the UI to allow easy switching between linear and perceptual RGB might actually be seriously considered. The specs as linked above are what convinced and convinces the main developers of the usefulness of the changes. So "I will only write a spec if the main developers already agree with said spec" will be a bit hard. If the core devs are interested in allowing the user to easily choose between linear and perceptual RGB on a per op/per layer blend mode basis, then a spec would seem to provide a starting point for figuring out how to implement the user's ability to choose between linear and perceptual RGB. If the devs already have agreed among themselves to remove that choice from the user, there's no point in my writing a spec for functionality that goes against developer consensus. To be more blunt, the babl flips are Pippin's brain-child. If Pippin says "no user choice", is there any real benefit to anyone if I write up a spec? Wouldn't it just be a waste of everyone's time? If the main devs are opposed to the idea then I don't want to put any more effort into the topic. Any change needs support, preferably by many people who are involved in the project already.If there is the choice between the status quo and something they do not understand, guess what they will support. Hmm, well, see, I have this website devoted to color management. Half (well, probably only a third) the articles on my website were written to help the GIMP devs understand various aspects of color management. It seems I have failed to boil color management down to bites that are small enough for easy developer consumption and yet comprehensive enough to be sufficiently informative. I do keep trying. Please ask questions! Best, Elle -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/02/2015 01:28 PM, Elle Stone wrote: > On 04/30/2015 05:43 PM, Michael Schumacher wrote: >> For examples have a look at the Save & Export and Single Window Mode >> specifications: >> >> * http://gui.gimp.org/index.php/Save_%2B_export_specification >> >> * http://gui.gimp.org/index.php/Single-window_mode_specification > I am willing to write up formal specifications but only if there is a > consensus from the main devs that the proposal for changing the UI to > allow easy switching between linear and perceptual RGB might actually be > seriously considered. The specs as linked above are what convinced and convinces the main developers of the usefulness of the changes. So "I will only write a spec if the main developers already agree with said spec" will be a bit hard. > If the main devs are opposed to the idea then I don't want to put any > more effort into the topic. Any change needs support, preferably by many people who are involved in the project already. If there is the choice between the status quo and something they do not understand, guess what they will support. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 04/30/2015 05:43 PM, Michael Schumacher wrote: On 04/30/2015 11:40 PM, Elle Stone wrote: What are specifications? Something that describes how features are supposed to work when they are implemented. For examples have a look at the Save & Export and Single Window Mode specifications: * http://gui.gimp.org/index.php/Save_%2B_export_specification * http://gui.gimp.org/index.php/Single-window_mode_specification Thanks! for the links. On 04/29/2015 03:57 PM, Joao S. O. Bueno wrote: So, I hope that with the previous e-mail you could get to a good summary of what would be needed for GIMP not only to be vaibale, but to surpass current photoshop U.I. when dealing with these issues . I hope so. Now help us think on the next steps. For example get that e-mail worked into a feasible specification: If you can, refine it, then maybe try to get someone with UI expertise that could fine tune that your suggestions into specifications that could be really great - now we don't have Peter helping the project anymore. (could be someone from your area, to whom you could get face to face meetings) - (I'd rather have another switch along the layer modes than to duplicate all layer modes in the UI, for example) - And then...help use having more people who could help with development. :-) FWIW, I put up a call for GIMP programmers "above the fold" on the home page of my website: http://ninedegreesbelow.com/ There's "title text" if you hover over the link. At least I can see the suggested features as great. And I can't think of a way to even begin takling them without an enormous amount of weekly hours to dedicate to it (or Americo's issues for the matter) I am willing to write up formal specifications but only if there is a consensus from the main devs that the proposal for changing the UI to allow easy switching between linear and perceptual RGB might actually be seriously considered. If the main devs are opposed to the idea then I don't want to put any more effort into the topic. Best, Elle ___ 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
Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
On 05/01/2015 07:03 PM, Gez wrote: You chose one of the few cases where both linear and perceptually uniform could be valid options and none of them are right or wrong. Of course I'm not against allowing two valid instances of the same thing, like in this case. I've already given other examples. But you're not proposing to add a toggle to gradients alone, you're proposing to put them*everywhere*. Yes. I'd like to see this discussion heading towards a real world list of examples of real needs for such options that can't be satisfied with anything else than these toggles. You are presupposing that the devs can foresee every possible use to which a user might put a given editing operation. Currently the user does already have linear vs perceptual choices through the GIMP UI for most editing operations (scaling is always linear, drawing a gradient is always perceptual). Currently the user can use or not use the gamma hack. And the user can use linear or gamma precision. That's two time two equals four possibilities for the user to try for each and every editing operation. Now tell me without taking the time to try all four possibilities: How does the user get a linear gradient? (sorry, you can't) How does the user get linear gamma channel mixer? How does the user get perceptually uniform Filter/Noise/Add RGB noise? I'm proposing to make the current GIMP UI for switching between linear and perceptually uniform RGB much simpler and clear to use: 1. Eliminate the precision switches by putting the linear vs gamma choice on each layer, rather than having to convert the entire layer stack to a new precision. This will have the side benefit of cutting the number of precision dialog entries in half. 2. Replace the gamma hack dialog with a "Linear/Perceptual" switch or drop-down menu that shows the default setting that was set by the devs, and also allows the user to quickly and easily choose the other setting. Right now the babl flips and GIMP UI give the user a choice, at least for most editing operations. But how to get linear or perceptual out of any given editing operation isn't at all clear. The current UI wasn't ever intended to be permanent and does need to be redesigned. The babl flips and GIMP UI can be redesigned to: * Prevent the user from making an edit on linear RGB if the devs decide the particular editing operation "should" be done on perceptually uniform RGB. * Prevent the user from making an edit on perceptually uniform RGB if the devs decide the particular editing operation "should" be done on linear RGB. Or the babl flips and GIMP UI can be used to provide the user with the same choices that users of PhotoShop and Krita and every other high bit depth image editor already have: which is to perform all edits on either linear or perceptually uniform RGB. In PhotoShop, Krita, etc, the only way to change whether the RGB data is linear or perceptually uniform is by doing an ICC profile conversion. In GIMP the UI could be designed so the switch between linear and perceptually uniform can be done easily on a per-op basis, if the UI were redesigned the way I am suggesting, or some way that provides equivalent functionality. Or in GIMP the UI could be redesigned so the switch between linear and perceptually uniform is taken completely out of the user's control. I fail to see any advantage at all to giving the user a choice for some operations and not for all operations. It places the devs in the not-so-nice position of having to know in advance all possible uses to which the user might want to put all possible editing operations. Why do you want to put roadblocks in the user's way? There are certainly rights and wrongs when using a tool. If the tool is designed to work some way and you don't respect that, you're doing it wrong. Try taking a hammer upside-down and hammer nails with the handle. That's wrong. Sorry. Not a good analogy. Like all tools, a hammer is a means to accomplish a goal, nothing more, nothing less. The precise goal, and hence the right way to use the hammer, depends on the goal of the person using the hammer. Not every problem for which a hammer is a good solution happens to be a nail: Maybe you want to mold some soft metal into a curved shape and the hammer's handle happens to be the right shape for the task. Maybe you are using the hammer to hold something in place so you can accomplish some other task. Recently I used a sledge hammer to hold down a spring-clipped cover so I could access some bolts hidden behind the cover. Should I have gone to the store and asked for a "heavy duty spring-clipped cover holder downer"? Maybe you want to reset a nail that is coming out of place, but you use the side of the hammer to gently press the nail back in place because you don't want to further damage some old and rotted wood. The person who made the hammer doesn't and can't know all the inventive uses
