[Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB
The single biggest useability issue with GIMP 2.9 is the mechanism for allowing the user to switch between linear and perceptually uniform RGB. In the current UI, the user has no way to know whether any given editing operation is performed on linear or perceptually uniform RGB. For most operations there are four possibilities for the user to try: 1. Switch to linear precision and don't use the gamma hack. 2. Switch to linear precision and use the gamma hack. 3. Switch to gamma precision and don't use the gamma hack. 4. Switch to gamma precision and use the gamma hack. I realize the above situation is supposed to be temporary. However, given the current UI, the only way the user can know what's happening to her RGB data is to: 1. Compile a version of GIMP with the babl flips disabled and have two versions of an image open, one in regular sRGB and one in linear gamma sRGB. 2. Perform the editing operation in the version of GIMP with the babl flips disabled on both the regular and the linear gamma version of the image. 3. Compare results to what happens in default GIMP when editing the regular sRGB image, by systematically trying all four combinations listed above. The suggestion was made on IRC that it doesn't matter to the user what's happening to the RGB data because the user can see what the image looks like on the screen and if s/he doesn't like the result, s/he can do something else. This view on image editing is just plain wrong. A person who is new to image editing might be content to just push sliders around and see what happens. But there is a difference in the editing needs of slider-pushing beginners (everyone starts out as a slider pusher) and people who have sufficiently mastered the art of image editing to know what they want to accomplish and how to make it happen. People who use advanced workflows with previsualized editing goals need to be able to control whether any given editing operation happens on linear or perceptually uniform RGB. In PhotoShop, switching between linear and perceptually uniform RGB required doing an actual ICC profile conversion, which is quite time-consuming once the image has more than a couple layers. Converting between linear and gamma precision in GIMP is just as slow and a good deal less predictable from the user's point of view. At least in PhotoShop, once you convert to linear RGB, you know all operations are performed on linear RGB, and the same for converting to perceptually uniform RGB. But you don't have that kind of assurance in GIMP - rather you are left to guess what's happening to your RGB data. The babl flips ought to make it possible for GIMP users to instantly flip between linear and perceptually uniform RGB, at the *user's* own discretion. Such fundamentally important editing decisions should not be dictated by developers who can't possibly know the user's particular artistic or technical goals. The current UI for selecting whether an operation is done on linear or perceptually uniform RGB works isn't useable for anyone except a slider pusher. Here's a suggestion for improving the situation: 1. Eliminate the (linear) and (gamma) options in the Image/Precision menu. 2. Double the number of layer blend options, so that the user can choose whether each layer blend mode should be done using perceptually uniform or linear RGB. Deal with the increased number of layer blend modes by allowing the user to collapse the less-used blend modes and expand the more-used blend modes, as Krita does. 3. For all editing operations, in the UI include a check box so the user can select whether the operation is done on linear or perceptually uniform RGB. 4. Have the technically correct option preselected. For example, for Gaussian blur, linear RGB would be preselected. And for adding RGB noise, perceptually uniform RGB would be preselected. And so on. 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 in private schools and educational institutions
How do we know that the word Gnu is not offensive in some schools in some culture in some language? Also, the word manipulation has negative connotations for some people in some cultures .. On Sat, Apr 18, 2015 at 10:55 PM, Liam R. E. Quin l...@holoweb.net wrote: On Wed, 2015-04-08 at 12:58 -0500, Sam Bagot wrote: A product called Gimp can't be used [in schools] Although GIMP can be used in at least some schools, I agree with your premise. These conversations always seem to run the same course: A: the name GIMP is offensive to me, or to people with whom I work. B: No. The name GIMP is not offensive. A: yes it is. B: It doesnt offend me, and your opinion doesn't matter to me. A: We like the name. Bye. For my own part I have some hesitation - for example, I am not about to go to a meeting on making the Web accessible to people with special needs while wearing a GIMP tee-shirt, and obviously can't promote GIMP usage too openly at work. If it was called Wilber, or maybe Nazi or Spic or Hun... hmm, no, not those last three perhaps, but Wilber would be OK. The brand argument doesn't really cut much ice - plenty of other Free and proprietary applications have been renamed in the past, and the publicity can increase visibility. Maybe instead of GIMP 3.0 we could have a Goat Rainbow 1.0 or something? But then you get into endless discussions about the name. In the meantime, for school use, could you refer to the program as the GNU Image Manipulation Program, and if people comment on GIMP explain it's short for the longer name as that's too long to use everywhere? ___ 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-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 2.9 useability - out of gamut and HDR channel values
On 04/19/2015 03:40 PM, Liam R. E. Quin wrote: On Sun, 2015-04-19 at 09:56 -0400, Elle Stone wrote: An issue that will arise for everyone who uses GIMP 2.9 is how to deal with HDR and out of gamut colors. Can't say it has arisen for me yet Maybe you only edit sRGB images and you haven't converted any wider gamut images to sRGB, so you haven't generated out of gamut colors that way. Maybe you've never used Levels to generate OOG/HDR colors intentionally or accidentally. Maybe you've never had portions of an image reappear that you thought you had blanked out using a mask, but you forgot to use Curves to clip the mask, and a subsequent operation on the mask made the previously masked portions of the image reappear. Maybe you keep your images at 8-bit or 16-bit integer, and so avoid OOG/HDR colors altogether. Maybe you do generate OOG/HDR colors while editing, but you don't check around your image with the color picker or pointer, so you don't know it's happening. And maybe you don't care because such values haven't ever caused you any editing problems. Yet. Try soft proofing to a printer profile and see how long it takes you to figure out that the problem is you need to clip the layer colors before trying to soft proof. Try converting to an output profile such as sRGB for display on the web and conclude that everything is fine, until you actually output the image to a file format that doesn't support OOG/HDR colors and all the pretty colors that you saw on your screen turn to yuck because those colors were within your monitor profile's color gamut but outside the sRGB color gamut. but I agree that (if we ignore rhetorical overstatement) it could be useful to address. To what rhetorical overstatement are you referring? Except for people who never use floating point precision, *everyone* who uses high bit depth GIMP *already* has the ability to easily create OOG/HDR values, whether intentionally or not. Those colors *already* interfere with a whole host of editing operations. Many editing operations depend on being confined between 0.0 and 1.0 floating point. Many editing operations produce garbage output when performed on negative channel values. If you'd like specific use cases and examples, peruse the long discussion on problems with unbounded sRGB image editing, or read this article and follow the links: http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html As more unclipped operations are added to GIMP, opportunities for accidentally or intentionally producing OOG/HDR colors will keep increasing. Those OOG/HDR colors can be very useful for image editing, even for display-referred image editing, and I for one enjoy the new editing possibilitis that GIMP makes possible via OOG/HDR colors. Those same OOG/HDR colors can also turn into a right big mess if users don't have an easy way to clip colors at will. What about a View Module that shows out of gamut pixels in a configurable way? (e.g. two solid colours and an optional blink-rate setting)? That would be nice, but it wouldn't provide a direct user option to deal with OOG/HDR colors. It would just show where they are. In addition, I can imagine a Colours-Out Of Gamut filter that allows clipping, logarithmic squishing, clipping with inpainting (G'MIC and Darktable have some of this), automatic replacement of clipped regions with penguins, maybe an expression language, we could call it the gimp module for implace clipping... In other words I don't think there's a single approach that works for everyone, or even for most people, or even for one person most of the time, as it depends on the image. So it'd seem like a bunch more work than your email appeared to me to suggest. The options you suggest sound wonderful, but there does also need to be an easy way to clip at will OOG/HDR colors on a per layer and per layer mask basis. As an aside, I suspect providing at will per layer and layer mask clipping might not be all that easy to code up. In the meantime in my own workflow the lack of repeat last filter used is a much bigger usability issue than anything to do with gamma or clipping. So phrases like everyone and the biggest usability problen don't carry as much weight as specific use cases, I think. I have provided specific use cases that cause problems when trying to edit OOG/HDR colors. Do you want more examples? How much detail do you want? 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 2.9 useability - out of gamut and HDR channel values
On Sun, Apr 19, 2015 at 10:40 PM, Liam R. E. Quin wrote: What about a View Module that shows out of gamut pixels in a configurable way? (e.g. two solid colours and an optional blink-rate setting)? We have that in Preferences already :) Alex ___ 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 2.9 useability - out of gamut and HDR channel values
On Sun, 2015-04-19 at 09:56 -0400, Elle Stone wrote: An issue that will arise for everyone who uses GIMP 2.9 is how to deal with HDR and out of gamut colors. Can't say it has arisen for me yet but I agree that (if we ignore rhetorical overstatement) it could be useful to address. What about a View Module that shows out of gamut pixels in a configurable way? (e.g. two solid colours and an optional blink-rate setting)? In addition, I can imagine a Colours-Out Of Gamut filter that allows clipping, logarithmic squishing, clipping with inpainting (G'MIC and Darktable have some of this), automatic replacement of clipped regions with penguins, maybe an expression language, we could call it the gimp module for implace clipping... In other words I don't think there's a single approach that works for everyone, or even for most people, or even for one person most of the time, as it depends on the image. So it'd seem like a bunch more work than your email appeared to me to suggest. In the meantime in my own workflow the lack of repeat last filter used is a much bigger usability issue than anything to do with gamma or clipping. So phrases like everyone and the biggest usability problen don't carry as much weight as specific use cases, I think. Hmm, having GIMP and darktable able to share modules (like the out of gamut filter) might be a really interesting summer project for a suitable student, if such exist. Liam ___ 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 2.9 useability - out of gamut and HDR channel values
An issue that will arise for everyone who uses GIMP 2.9 is how to deal with HDR and out of gamut colors. An HDR color is any floating point color with at least one RGB channel value that is greater than 1.0. An out of gamut (OOG) color is any color with at least one RGB channel value that is less than 0.0. It is very easy to generate OOG/HDR colors using GIMP 2.9. Ways to generate such colors already include: * Levels slider adjustments. * Converting images from one RGB color space to another. * The LCH blend modes. * Apparently some GEGL operations also generate such colors. New ways to generate OOG/HDR colors will eventually be added to GIMP, for example the addition/subtract/multiply/divde/etc blend modes will need to be unclipped if GIMP is ever to accomodate high dynamic range scene-referred editing. On the one hand, allowing OOG/HDR colors makes possible many editing opportunities that are not possible when all RGB values are clipped to the range 0.0-1.0. For example (and putting HDR editing to one side), for display-referred editing: * The fact that Levels doesn't clip RGB values makes it possible to make extreme adjustments to raise shadows and then selectively mask out highlights to bring them back below 1.0. This is a lot more useful than it might sound. * The ability to let stand any OOG colors created by LCH blend modes or by ICC profile conversions allows to deal with these colors at a later point in the processing pipeline rather than have them be summarily clipped. On the other hand, many times OOG/HDR colors will interfere with the user's efforts to edit images, being inconsistent with many display-referred editing operations. And OOG colors generate nonsense values when used in many editing operations, whether HDR or display-referred. Right now the only way the user has available to clip OOG/HDR channel values is either to change the precision to one of the integer precisions, which will clip all OOG/HDR values in the entire layer stack, or else to apply a straight line null Curves adjustement to an individual layer that has OOG/HDR channel values. These are blunt and cumbersome ways to deal with something that every GIMP user will eventually have to come to terms with. Ways need to be provided to allow the user better control over whether and when OOG and HDR colors should or shouldn't be clipped. Here are some suggestions for consideration: 1. LCMS 2.7 does provide the option for floating point ICC profile conversions to be clipped or not clipped. Currently GIMP only supports unclipped conversions. It would be nice to add the option to allow the user to choose to do a clipped ICC profile conversion. 2. An option could be added to the Preferences dialog to allow the user to choose to automatically clip the OOG and HDR results of all editing operations. For many users this will be a true useability enhancement as many users simply won't want to deal with OOG and HDR colors. 3. An option could be added to every layer and editing operation to do one of three things: i. not clip the RGB values; ii. clip just the negative RGB values; iii. clip all OOG/HDR colors. For all three possible ways to help users deal with OOG/HDR colors, probably the default option should be clip all. Adding options to enable the user to control clipping will complicate the User Interface. But if GIMP provide users with enhanced, cutting edge, high end editing capabilities, GIMP also needs to provide users with similarly powerful controls. 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 in private schools and educational institutions
On Wed, 2015-04-08 at 12:58 -0500, Sam Bagot wrote: A product called Gimp can't be used [in schools] Although GIMP can be used in at least some schools, I agree with your premise. These conversations always seem to run the same course: A: the name GIMP is offensive to me, or to people with whom I work. B: No. The name GIMP is not offensive. A: yes it is. B: It doesnt offend me, and your opinion doesn't matter to me. A: We like the name. Bye. For my own part I have some hesitation - for example, I am not about to go to a meeting on making the Web accessible to people with special needs while wearing a GIMP tee-shirt, and obviously can't promote GIMP usage too openly at work. If it was called Wilber, or maybe Nazi or Spic or Hun... hmm, no, not those last three perhaps, but Wilber would be OK. The brand argument doesn't really cut much ice - plenty of other Free and proprietary applications have been renamed in the past, and the publicity can increase visibility. Maybe instead of GIMP 3.0 we could have a Goat Rainbow 1.0 or something? But then you get into endless discussions about the name. In the meantime, for school use, could you refer to the program as the GNU Image Manipulation Program, and if people comment on GIMP explain it's short for the longer name as that's too long to use everywhere? ___ 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
