On 11/18/2014 03:05 AM, Michael Henning wrote:
On Mon, Nov 17, 2014 at 11:39 PM, Gez <lis...@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
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:
and eight follow-up messages
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
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.
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.
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list