On 10/15/2014 01:58 PM, Michael Henning wrote:
Yes, the majority of operations will operate in myfavoriteRGB space, but you seem to be operating under the premise that absolutely *no* filters can possibly exist that require a specific color space to function properly. This isn't the case.
Actually, I did go through the code base as thoroughly as possible, and I did identify various editing operations that depend on the data being in specific color spaces (not always D50-adapted sRGB). See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
Take, for example, the color blindness simulation in gimp. This filter tries to simulate color blindness so that artists can create images that look good to people who are color blind. An operation like this should not change based on which working space you choose to edit in; it must always try to be as faithful to colorblindness as possible. For an operation like this, being able to specify the working space on the developer's side is a must. Otherwise, it can't work properly.
This is one of the operations that I identified. I also noted that ALL such operations should be clearly identified as such in the UI.
While operations like that might not be too common, it should still be physically possible to create them. Before you say "okay, so a proper icc color managed editor will convert between icc profiles, what's the big deal?", realize this: babl is exactly the mechanism that we are using to make that happen. These "background conversions" that you seem to hate so passionately
The background conversions that I was objecting to two years ago convert between perceptually uniform and linear gamma RGB data, using the sRGB TRC as a stand-in for true perceptual uniformity. Those are the babl/babl/base/util.h TRC flips.
I do recognize (now, but not two years ago) the point of the TRC flips. The point is to be able to flip instantly between linear gamma and perceptually uniform RGB. See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html#best-solution
In my working copies of babl/GEGL/GIMP I have the babl TRC flips disabled because the ways in which the user can choose perceptual vs linear encoding are not transparent and also subject to change. But I'm looking forward to having the UI make it easy for the user to be able to switch at will. Assuming the devs will allow the user the freedom to make such choices.
are exactly the same conversions that you already admitted were necessary when copying and pasting between images. Just because conversions shouldn't be common does not mean they should be impossible, or removed altogether.
I've already said elsewhere in this thread that how you get from RGB to XYZ/LAB/etc is really irrelevant as long as the end result is correct. The same thing applies to conversions from one set of RGB primaries to another set of RGB primaries.
Also, given a bug in current LCMS conversions between RGB matrix profiles, I would rather babl did the conversions. See http://sourceforge.net/p/lcms/mailman/message/32834352/
But even when that particular LCMS bug is fixed, there doesn't seem to be any advantage to calling on LCMS to do simple matrix conversions.
The only real drawback to all of the above is I can't see any way a GIMP user can edit their images in an RGB *LUT* color space. From my own point of view, that would never be a concern. But it should be noted that babl/GEGL/GIMP does seem to have this one requirement.
It should be noted that such cases as the colorblind filter and the old device-based code should be treated as explicit exceptions, labelled in the UI.
The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries.
Kind regards, Elle Stone _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
