On 11/15/2014 08:20 PM, Øyvind Kolås wrote:
On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone
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
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
gamma adjustments are among the things that definetely would not end
up using bablRGB; regardless of how far we get in specifying other
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.
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/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/Enhance/Red Eye Removal
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
"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
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: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list