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



On 11/18/2014 03:05 AM, Michael Henning wrote:
On Mon, Nov 17, 2014 at 11:39 PM, Gez <listas ohweb com ar> wrote:
P.s.: If you think this discussion is a waste of your time and my time,
feel free to skip an answer. I don't think it's a waste of time at all,
it's developer/user interaction regarding important aspects of the tool.
Do you really think that discussing this is counterproductive?

Yes, I think that discussing this is counterproductive because it is
premature. If I had spent the time I spent responding to color-related
emails on coding this system instead, it would easily be working right
now.

If I had not spent time and effort explaining the problems *before* you got around to implementing unbounded sRGB image editing, you would have coded up a "working" high bit depth GIMP that was steadily churning out wrong results. And I'd be filing a whole lot of bug reports.

Then, we could be discussing the details of a system that
actually existed, instead of the details of a system that does not
exist, and if current rates of coding continue, will never exist.

And the discussion would be exactly the same. You would still need to use UserRGB chromaticities instead of sRGB chromaticities. But you'd have to undo a lot of new code to get there.

Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y:

* https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages
* http://ninedegreesbelow.com/photography/srgb-luminance.html.

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:

GIMP really does need someone on the team who understands ICC profile color management. But it doesn't do any good to have such a person around unless you actually listen.

To listen *intelligently* so you can ask the right questions when your color management person seems to be giving wrong advice (I'm just as capable as the next person when it comes to giving wrong advice), you need to understand a little bit about ICC profile color management. I've done my best to make this task easier:

Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs
http://ninedegreesbelow.com/photography/xyz-rgb.html

I've learned a lot while trying to explain where babl/GEGL/GIMP has gone off track regarding one or another color management issue. Hopefully the exchange of knowledge has been a two-way street.

You say I should stop responding, but it's hard to stop responding
when novels are being written about how wrong you are, but you believe
you are right. It's hard to stop responding when an article portraying
you as incompetent appears on hacker news. It's hard to stop
responding when you genuinely want people to understand.

   -- drawoc

I agree with you that it's hard to stop responding when you want people to understand something that you care about. I doubt whether any of you have a clue just how much I value GIMP as an RGB image editor. But GIMP is critically important to free/libre artists and therefore GIMP color management needs to be right.

Now, please explain this to me with a straight answer: Why is it so
insanely important to know what color space an operation happens in,
in a situation where it*by definition*  does not matter, that you are
willing to waste hours of your time and hours of developers' time
arguing about it?

This is exactly the right question. It will me take a bit of time to put together a straight answer that is also not one of my "walls of words". I'll try to post the answer today or at least by tomorrow morning.

Elle


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