On 11/15/2014 08:20 PM, Øyvind Kolås wrote:
On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
<ellest...@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

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".

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.

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/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?


gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Reply via email to