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
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: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list