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



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



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