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

[Elle Stone <ellestone ninedegreesbelow com>]

In keeping with Simon's request, I'm not copying the user list.

On 11/18/2014 11:16 AM, Alexandre Prokoudine wrote:
> On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote:
>
> > Michael Henning did understand and did make appropriate changes to babl's
> > hard-coded sRGB Y values. But I doubt whether any of the other devs
> > understood; if they did, babl wouldn't still use D65 device sRGB to convert
> > to XYZ before converting to LAB, and GIMP wouldn't still be full of
> > hard-coded D65 device sRGB Y values. See:
>
> Elle, assuming that things are not done/fixed, because we don't
> understand them or don't care about them, is simply incorrect. We have
> a roadmapful of things we care about which still need someone to work
> on. It really is that easy.

I didn't mean to offend anyone and my apologies if I did.

Not too long ago I wanted to submit a patch for the GIMP sRGB Y values. 
I was told by one of the developers that it was still undecided as to 
whether D65 or D50-adapted Y values were appropriate. This would have 
been a small code change to make. I would have done the required coding, 
so it would have required no developer time except the time to make the 
commit. It would have brought GIMP Y into line with babl Y.

There was no reason to not accept the change other than a failure to 
understand that in an ICC profile color-managed application where the 
profile illuminant is D50, using D65 unadapted Y values is incorrect. 
This is not casting blame. This is describing a situation where the 
required knowledge for making a decision simply wasn't there.

I used to tutor math students and learned very quickly that the only way 
to get information from teacher to student is to enable the student to 
ask the right questions, which means trying to see things from the 
student's perspective.

Before I suggest anything related to color management to the GIMP devs, 
I've already tested it sixteen ways from Sunday. In the cases of "which 
Y" and the inadvisability of using sRGB chromaticities for editing 
images that the user intends to be in some other RGB working space, my 
advice is correct.

But explaining why really is taking a long time and also is trying 
everyone's patience, including mine. I think part of the problem is 
people (no doubt including me) aren't asking the right questions.

I've been trying to understand the babl/GEGL/GIMP perspective on color 
management. I've also been trying to impart enough information to enable 
the devs to ask me the right questions, but I don't seem to be doing a 
very good job.

> By now, it's been repeated about a dozen of times that we had adjusted
> our plans in the past to honor your useful input, and we are going to
> do so in the future __time permitting__. Is there a good reason why
> there should be another dozen of times for this to be said in the
> public?

Actually I feel very honored that you all trust my input enough to make 
changes. And I do realize that tasks need to be prioritized. For 
instance, I expect you probably will release 2.10 before fixing the 
hard-coded sRGB parameters. Rome wasn't built in a day and even I will 
agree that getting GIMP geglified and removing more of the deprecated 
functions is a higher priority task than fixing GIMP color management.

> As Michael already stated, there are things we simply don't know yet,
> because they are implementation details. hence we don't have all the
> answers for you. Please show us some patience.

Well, I've been patiently explaining why some of those "implementation 
details" really belong over in the "overall plan" category. And you all 
have been extraordinarily patient with my efforts to communicate.

Elle