On 04/20/2014 11:03 AM, Øyvind Kolås wrote:
On Fri, Apr 18, 2014 at 4:22 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
I've been trying to summarize the discussion of whether some operations
don't work in unbounded mode sRGB, and if they really don't work, what can
be done to fix the problem.
Is the following a fair summary of the BABL/GEGL/GIMP code?
Premise 2: To provide consistent editing results, all editing should be done
using the sRGB chromaticities. An important side benefit of using the sRGB
chromaticities is that the performance impact of using LCMS for color space
conversions is thereby eliminated.
Not entirely right as a premise; the premise is that
editing/processing in ops should default to being done
relative to XYZ; in pixel formats specifiable with babl (we control
babl; and can decide how we extend it).
I'm not sure what you mean by "done relative to XYZ" - that processing
is done using sRGB chromaticities which make one of the infinite number
of possible RGB color spaces that can be defined relative to XYZ?
Premise 3: For any given editing/compositing operation, there is only one
correct color space in which that operation should be performed (for
example, linear light unbounded mode sRGB vs perceptually uniform unbouded
mode sRGB).
As Alan Kay says, "simple things should be simple, complex things
should be possible". Local; manual overrides of pixel format used
would probably permit more complex workflows than global working-space
overrides provides.
I'm not sure what the difference is between global and local overrides.
What's the practical or perhaps UI? difference? An example of one vs the
other?
Conclusion 1: For the sake of coding efficiency and consistent editing
results, images should be losslessly converted to the sRGB chromaticities
before editing the image.
the sRGB chromaticities; or CIE Lab, or any other babl defined format.
With a potential future babl lcms2 extension; the original pixels
could even be kept in the layers raster storage.. doing so would have
no effect on display of the pixels or processing of them since things
are converted _on_demand_ to the pixel formats requested by the
operations. Doing this would for the user not be functionally
different in any way; apart from a risk of things being slower.
* Add code that remembers the source color space metadata. This way the
source color space chromaticities can be used to add to the list of color
spaces that are available for various editing/compositing operations.
* When one of the affected editing operations is invoked, automatically
convert, or else provide the UI option to convert, the buffer to the source
color space chromaticities.
Yes; this could also possibly be done in specific group of pixelformats :]
I posted to GIMP bugzilla sample LCMS code for pulling XYZ colorants
from an ICC profile. The sample code just uses a profile from disk, how
to get a profile from memory is probably beyond my coding skills. As you
mentioned a babl lcms extension, perhaps I should have sent that code to
babl instead of GIMP?
The arguments *against* adding an editing color space based on the source
color space chromaticities can be summarized as follows:
1. My demonstrations of where editing in the unbounded mode sRGB color space
fails are all *corner cases*, variously described as involving:
* Highly image-specific colors (quoting from IRC, "an example of highly
input data dependent photo that with other colors would not have the
striking amount of data in the blue channel").
* A highly image-specific workflow (quoting from IRC, "workflow is
highly scene/data dependent; and might not make general sense")
* Extreme, hence meaningless editing moves.
At least some of them do - and not seeing out of gamut colors in the
histogram in headroom/footroom on the sides are UI bugs. Apart from
maybe color selectors GIMP-2.9 is a 8bit image editing UI with backend
capabilities for more. Picking a different flower with other hues;
would make redistribution among the components less of an issue.
It seems like what you are saying is that the less saturated the image
colors, the less of a problem channel redistribution will cause upon
conversion to sRGB chromaticities. Which of course is 100% true.
But surely GIMP users other than myself will occasionally photograph
colorful flowers and such? For example, after interpolating a raw file
and applying the input profile, upon conversion to unbounded mode sRGB:
* The green channel of red flowers is likely to be negative.
* The blue channel of yellow flowers and bright green leaves is likely
to be negative.
* The red channel of saturated cyan is likely to be negative. And so on.
The sRGB bounded gamut holds only 35% of all real colors, and not
exactly a judiciously chosen 35%, being dictated by phosphors used in
consumer grade CRTs from the 1990s rather than anything intrinsically
meaningful to film, print, digital cameras when shooting raw, or current
and future advances in display technology.
But even if the conversion were to some larger gamut unbounded mode
color space, those channel redistributions still would cause problems
for *some* editing operations.
2. An unacceptably large amount of new and complicated code and UI
modifications would be required to accomodate the corner cases where
unbounded mode sRGB image editing fails.
Or put differently; allowing the user to override processing globally
at will - effectively _destroys_ actual color management, making
whether things are color managed or plain wrong a highly likely choice
in user configuration.
Choosing the appropriate RGB working space for a given editing task is
an essential part of the creative process. It's part of "the right tool
for the right job".
As far as I have seen work has barely started
in GIMPs UI with dealing with >8bpc images.
I apologize if it's too soon to be worried about UI problems. But it
does seem logical that if a user is working on a Rec. 2020 image,
reddest Rec. 2020 red should be (1,0,0), not the linear gamma sRGB
equivalent (1.660581, -0.124595, -0.018144). Unless perhaps there is a
way to communicate visually to the user which colors lie entirely in the
Rec. 2020 color gamut.
Perhaps a chromaticity diagram on which the user can choose to overlay
various color space triangles, including but not limited to the source
color space xy coordinates? Such a tool wouldn't be as precise as
dialing in exact values.
3. When considered from the point of view of colors located in XYZ space,
HDR colors and out-of-gamut colors are essentially the same thing. So
many/most/all of the corner cases that I posted as examples of operations
that fail in the unbounded mode sRGB color space will be handled by code
modifications that are required anyway to enable GIMP to handle HDR images.
Is this a fair summary of the discussion so far about operations that don't
work in the unbounded mode sRGB color space?
Or from my point of the view I summarise it as stubborn
operators/developers that want to be able to manually
misconfigure/override color management like they are used to instead
of dependable color management and consistency of operations.
Do you mean things like Channel Mixer, Levels, Gradients, and Invert,
which currently use the regular sRGB TRC instead of linear light?
I hadn't realized that Channel Mixer isn't using linear light. But when
I tried using Channel Mixer to desaturate the yellow cone flower in my
modified BABL/GEGL/GIMP that disables all the background TRC switches,
in a true linear gamma sRGB color space, it worked!
Resulting saturation and value are slightly different in my custom
camera space vs unbounded mode linear light sRGB, most noticeable in
saturated reds. But hue is constant and at least the results are believable.
So I was wrong about Channel Mixer desaturation not working in unbounded
mode sRGB. Desaturation using Channel Mixer does give "close to the same
results" as the source color space in unbounded mode sRGB, but *not* in
perceptually uniform sRGB, rather *only* in linear light sRGB.
Similar issues are easy to demonstrate with Levels upper and lower
sliders, Gradients, Invert. These really need to be linear light operations.
Is there a list of the operations that don't currently use linear light?
There
are ways of achieving the goals that Elle is trying to achieve in the
examples; that can fit into GEGLs strongly color managed internal
architecture. Globally overriding the "working-format" is the approach
that is most contrary to the architecture and removes the benefits it
is meant to bring.
Elle
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
