Re: [Gegl-developer] [Gimp-developer] babl roadmap

[Elle Stone <ellestone ninedegreesbelow com>]

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