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.


gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Reply via email to