Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/07/2014 04:25 AM, Simos Xenitellis wrote:
> Hi All,
>
> I am a recent subscriber to the list and I have read with interest the
> recent threads and I am trying to figure out the "what next?".
> Developer resources in any project are generally very limited, so it's
> important to get more people contributing.
>
> Is there a test suite available that could show the expected behavior?
> If not, let's try to build one, both the test-suite code plus the images
> (before/after).
>
> Regarding the color spaces and conversions, it should be easy to try to
> make some of the the changes
> (most of them sound like simple text substitutions),
> compile the source and see how well it performs on the test-suite.
> Any comments on that?
>
> Simos

The text/code editor Geany can be used to do a file search in GEGL and 
GIMP for the following string (confine the search to *.c and *.h files): 
babl_format ("

GEGL has 212 such strings. GIMP has 503.

Here are some example strings with the actual babl formats included (the 
list is not exhaustive):

babl_format ("Y' u8")
babl_format ("Y u32")
babl_format ("YA u32")
babl_format ("Y float")
babl_format ("Y' float")
babl_format ("Y'A float")
babl_format ("Y'CbCrA float")
babl_format ("R'G'B'A u8")
babl_format ("R'G'B'A u16")
babl_format ("R'G'B' float")
babl_format ("R'G'B'A float")
babl_format ("R'aG'aB'aA float")
babl_format ("CIE Lab alpha float")
and so on . . .

If I understand Jon Nordby correctly, all of these babl_formats really 
are supposed to be dedicated formats that were intended to be used only 
with images encoded using the sRGB primaries. Changing the intended 
meaning of these formats might break compatibility with other software 
that uses babl.

So new babl_formats need to be written to take the place of all the 
"dedicated sRGB only" formats. Then the text substitutions could be made.

The problem is made more complicated by the fact that babl does many of 
the calculations for GEGL and GIMP functions that use Y (in particular 
painting on a mask and making an grayscale copy of the image for use as 
a mask). Babl also does the conversions to the YCbCr and CIELAB formats 
for GEGL and GIMP.

So all the babl functions that currently use hard-coded sRGB parameters 
either need to be generalized to use parameters pulled from UserRGB 
(meaning whatever RGB working space the user chooses, which might in 
fact be sRGB, or might be ProPhotoRGB, or etc). Or else duplicate babl 
functions for UserRGB need to be written.

The same is true for GEGL and GIMP functions that use Y to calculate 
Luminance, except most likely for GEGL and GIMP there won't be any "side 
by side" generalized and sRGB-only functions. Instead the existing 
functions will all be generalized.

Only a few GIMP UI functions use RGB working-space-specific ("UserRGB") 
Y and XYZ values. This article lists where UserRGB Y and XYZ parameters 
need to be used: 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html

To avert any possible confusion, when you open an image using GIMP, 
there is not and never has been a forced conversion from UserRGB to 
sRGB. The previously planned code that would have done so, never was 
written. If I understand Jon Nordby correctly, the development plan that 
would have required such code seems to have been put aside.

Currently only a few GIMP UI editing operations (that use Y to calculate 
Luminance or XYZ to convert to LAB) are affected by the "babl_format" 
assumption that the image really is an sRGB image. This article lists 
most of the GIMP UI functions that are currently only accurate for sRGB 
images: 
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html

Hopefully Jon Nordby will point out any mistakes I might have made in 
the above summary.

Best regards,
Elle