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

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

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.


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