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

[Elle Stone <ellestone ninedegreesbelow com>]

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

http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html

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
> obvious).
>
> Using e.g. the slightly convoluted color calculator at
> http://www.brucelindbloom.com/ 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.

Elle