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

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