Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/15/2014 08:20 PM, Øyvind Kolås wrote:
> On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > This really is my last post on unbounded sRGB unless someone has a specific
> > question to ask.

Well, I think a question was asked.

> > On 11/14/2014 11:47 AM, Øyvind Kolås wrote:
> > > I ask for an assumption of good faith, that the babl/GEGL developers
> > > know what they are doing and have incorporated your input from April
> > > on out how multiply and gamma produce undesirable results for values
> > > outside the 0.0-1.0 range working with unbounded sRGB. That we want to
> > > and will incorporate that in the color management model of GEGL. A
> > > model that differs from how traditional ICC based photo editors
> > > traditionally work, GEGL has both internal (babl) and external (ICC)
> > > color management; and you have correctly pointed out that the internal
> > > color management is lacking and needs to take more RGB spaces into
> > > account.
> >
> > I think it's important to clarify some of Pippin's misunderstandings that
> > are betrayed in the above quote:
> >
> > 1. Multiply and gamma slider adjustments are both highly chromaticity
> > dependent editing operations. What Kolås fails to acknowledge, and maybe
> > doesn't even understand, is that this is true regardless of whether the RGB
> > channel values are *in* or *out* of gamut with respect to the bounded sRGB
> > color space.
>
> The multiply compositing op; doesn't really have any sliders,

I don't think you intended to imply that I think the Multiply layer 
blend mode ("compositing op") has a slider. So I'll assume you are 
rightly pointing to an ambiguity in how I phrased the sentence. I should 
have said something like this: "Multiply and also Levels gamma slider 
adjustments".

> and
> gamma adjustments are among the things that definetely would not end
> up using bablRGB; regardless of how far we get in specifying other
> working spaces.

I'm going to ask you a question. Please don't take the question the 
wrong way. I'm trying to establish some common ground for communication.

Here's some background to the question:

There are four basic mathematical operations that can be performed on 
the pixels in an RGB image: add and subtract, and multiply and divide.

Add and subtract are inverses, and multiply and divide are inverses, so 
really the four basic operations reduce to two: add and multiply.

Here's the question:

Do you understand that when I say that Multiply is a 
chromaticity-dependent editing operation, I don't just mean the Multiply 
layer blend mode? that in fact *all* editing operations that use 
multiplication or division are chromaticity dependent, regardless of 
whether the colors are *in* gamut or *out* of gamut with respect to the 
very small bounded sRGB color gamut?

The exception to "all", of course, is when multiplying or dividing by 
black, gray, or white.

See:
1. 
http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb
2. 
http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html
3. 
http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html

> > 4. The list of chromaticity dependent editing operations is much longer than
> > just multiply and gamma slider adjustments:
> >
> >      * For editing performed on more or less perceptually uniform RGB data,
> > the list includes essentially *all* editing operations.
> >
> >      * For editing performed on linear gamma RGB data, the list includes at
> > least the following operations (I haven't checked every single editing
> > operation made available through the GIMP UI):
> >
> >          Channel data used as a blending layer
> >          Channel data used for making selections
> >          Colors/Alien Map HSL
> >          Colors/Alien Map RGB
> >          Colors/Auto stretch contrast
> >          Colors/Auto stretch contrast HSV
> >          Colors/Channel Mixer (try Margulis' "enhance green" formula)
> >          Colors/Desaturate average
> >          Colors/Desaturate lightness
> >          Colors/Mono Mixer (except straight Luminosity-based B&W conversion)
> >          Colors/Posterize
> >          Colors/Threshold
> >          Colors/Levels Gamma slider operations
> >          Colors/Levels Red, Green, and Blue Input/Output sliders
> >          Colors/Levels "Auto Pick" (used for white balancing images)
> >          Filters/Artistic/Cartoon (this uses hard-coded Y values)
> >          Filters/Edge Detect/Sobel
> >          Filters/Enhance/Red Eye Removal
> >          Filters/Noise/HSV Noise
> >          Filters/Noise/RGB Noise
> >          Filters/Artistic/Soft glow
> >          Filters/Artistic/Vignette (any color except gray, white, black)
> >          Layer blend Mode/Burn
> >          Layer blend Mode/Color
> >          Layer blend Mode/Darken only
> >          Layer blend Mode/Difference
> >          Layer blend Mode/Divide
> >          Layer blend Mode/Dodge
> >          Layer blend Mode/Hard light
> >          Layer blend Mode/Hue
> >          Layer blend Mode/Lighten only
> >          Layer blend Mode/Multiply
> >          Layer blend Mode/Overlay
> >          Layer blend Mode/Screen
> >          Layer blend Mode/Saturation
> >          Layer blend Mode/Value
> >          Paint tools depend on the working space chromaticities when using
> > the following blend Modes: Burn, Color, Darken only, Difference, Divide,
> > Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen,
> > Soft light, Value.
> >
> > In other words, *most* editing operations are chromaticity dependent. This
> > means the *artist*, not the developer, is the only person who should choose
> > the RGB working space.
>
> Is there anything above that hasn't already been stated a couple of times?

You are correct as far as what's been said on the developers lists. I 
was trying to summarize the information for GIMP users.

Somewhat switching gears, the revised babl roadmap 
(https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:

"Once a format has been resolved using babl_format(babl, "bar:RGBA 
float") the returned pointer would refer to the babl context that looked 
up "bar"'s definition of bar. This . . . allows rigging up a situation 
where the user has control over the RGB space used for chromaticity 
dependent operations."

In light of the revised roadmap and the above list of chromaticity 
dependent editing operations, I have two more questions. Again, I'm 
trying to establish common ground for communication, or at least clarify 
where we disagree.

1. Do you agree or disagree that for *all* chromaticity dependent 
editing operations, the *user* should be in control of which RGB 
chromaticities are used to perform the operation?

2. Do you agree or disagree that for chromaticity *in*depedent editing 
operations (for example, and assuming linearized RGB: adding, scaling, 
gaussian blur, etc), the same results (same XYZ values) are obtained 
whether the operation is done in the user's chosen RGB working space or 
in unbounded sRGB?

> /pippin

Elle