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.
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: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list