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
