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

On 11/19/2014 10:47 PM, Simon Budig wrote:
Since a few questions have popped up on IRC and it really is a weird
concept to grasp I thought I'd expand a bit on the color math that is
being discussed here. Sorry it is so long, I hope it is somewhat
entertaining though  :)

Most of what you said is exactly right.

When we talk about "unbounded" sRGB in the Gegl/Babl context we do away
with this restrictions: We allow absurdly high intensities way beyond
the physical capabilities of a specific light source. And we allow for
negative intensities.

Yes, negative intensities are 100% absurd and wrong when you think about
them in terms of implementing computer monitors.

However, we don't need to model a real computer monitor. We are not
bound to the laws of physics when dealing with pixels in memory.

Allowing negative coefficients for the RGB values makes it possible to
escape the dreaded gamut triangle. In fact this makes the unbounded sRGB
color space as expressive as AdobeRGB, ProPhotoRGB and XYZ.

To reiterate: Every XYZ coordinate can be represented in the terms of
sRGB primaries.

Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities.

What you can't do is EDIT using sRGB as a universal RGB working space.

I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities.

See this article and follow the links and keep reading because I'm getting tired of repeating myself:

Using unbounded sRGB as a universal color space for image editing is a really bad idea

You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter.

For example:

The Green Primary of the AdobeRGB 1998 colorspace is - specified with
its own primaries - at the coordinates (0, 1, 0) (which is somewhat

Using e.g. the slightly convoluted color calculator at we can convert this to
  XYZ = ( 0.185554, 0.627349, 0.070687 ).

(Note that there is a normalization involved here: AdobeRGB (1, 1, 1) is
converted to an XYZ value scaled to Y = 1.0. We also get the xy
coordinate of the green point here: xy = (0.21, 0.71) )

This in turn translated into unbounded linear sRGB yields:

    sRGB = (-0.398283, 1.0, -0.042939)

And thats it. The color represented by (0,1,0) in AdobeRGB is equivalent
to the color represented by (-0.40, 1.0, -0.04) in unbounded linear sRGB
("bablRGB"). Yes, there are negative coefficients, no, we don't need to
worry about them.

And we can use the same math in reverse to reconstruct the AdobeRGB
value to use it as userRGB for our multiplication operation. We end up
at RGB=(0,1,0) where we started.

Note that there is nothing special about the sRGB that makes this
possible. The same math would work with any other primaries, as long as
they don't form a line in the xy diagram (i.e. they need to be linearily
independant in XYZ).

However, for this to work we absolutely must not clamp negative values
to zero. As soon as we do that huge errors will be introduced.

Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic.

Again, EDITING is different from STORING and DISPLAYING.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]