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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/14/2014 09:04 AM, Øyvind Kolås wrote:
> I have spent hundreds of hours more on babl/GEGL this year than I
> intended, most of them on unproductive arguments on mailinglists, a
> medium I not well suited for clearing up misunderstandings

I agree with you 100% that you shouldn't waste your time responding to 
mailing list discussions. Personally I would very much prefer that you 
use your time to:

* Write the requisite babl format specifiers for allowing GEGL and GIMP 
code to be modified so functions can use Y and XYZ values from the 
user's chosen RGB working space, instead of using hard-coded sRGB values.

* Write the requisite generalized or additional babl functions so that 
when the user draws on a mask or uses a grayscale image as a mask, the 
mask is drawn using the correct Y values from the user's chosen RGB 
working space, instead of using hard-coded sRGB Y values.

* And maybe fix the babl "conversion to LAB" code that still uses 
unadapted D65 sRGB values instead of the D50-adapted values suitable for 
an ICC profile color-managed workflow. The current code produces wrong 
results for ICC profile color-managed sRGB images, and even more so for 
images in other RGB working spaces.

However, I do understand that proper ICC profile color management isn't 
a high priority for GIMP 2.10. So the hard-coded sRGB values might still 
be in the code base when GIMP 2.10 is released, which would mean GIMP 
2.10 would produce incorrect results for some operations, for images 
that aren't sRGB images.

> but you
> refuse to spend time where the developers normally clear up
> misunderstandings, reach consensus and make plans; on IRC.

As you well know, I did try discussing unbounded sRGB with you on IRC. 
On IRC you felt free to issue personal insults. And you wasted time 
eliciting general agreement from people who learned everything they know 
about "color management" from you.

> I wrote the babl roadmap when it became clear that playing in your
> preferred medium, on the mailinglist, answering your questions was
> more conductive to deepen misunderstandings than clear them up. Like
> the continued refusal to understand that converting to unbounded
> linear sRGB on import to the system would be an implementation detail
> and not neccesarily mean that any processing would necessarily happen
> in that format -

STILL you want to convert to unbounded sRGB upon opening an image? 
STILL?? Why???? What is this "implementation detail" supposed to accomplish?

In case you hadn't noticed, I had already ceased discussing unbounded 
sRGB, on the apparently quite mistaken assumption that the unbounded 
sRGB architecture had actually been abandoned.

In an ICC profile color-managed workflow:

* sRGB is just another RGB working space.
* sRGB doesn't require special treatment, being handled just fine by 
generalized code that retrieves the user's chosen RGB working space's Y 
and XYZ values.
* Developers need to respect the user's RGB data. There is *never* any 
justification for forcibly convert the user's RGB data to an RGB working 
space not of the user's choosing.

> as well as broader principles of software engineering
> and how one keeps working code working.

Nothing in the current GIMP code base depends on unbounded sRGB. No GIMP 
functionality will be broken by not writing new code that will convert 
the user's image to unbounded sRGB.

If you insist on writing special "sRGB only" code (unbounded or 
otherwise), at least give the user the option to opt out of using such 
code, even for sRGB images.

> /pippin

Elle