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:

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

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?

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

Reply via email to