Re: [Gimp-developer] GIMP 2.9 useability - out of gamut and HDR channel values

[Elle Stone <ellestone ninedegreesbelow com>]

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