Re: [Gimp-developer] Soft proofing and the GIMP Display Filters and Color Management settings

[Elle Stone <ellestone ninedegreesbelow com>]

On 03/13/2014 10:37 PM, Øyvind Kolås wrote:
> On Wed, Mar 12, 2014 at 10:27 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > > In the New GEGL World, converting between different channel layouts is
> > > going to be a reality, and we should at least put _some_ thought into
> > > what that means for color management.  Of course, this is way out of my
> > > depth, and I have no idea.
> >
> > I'm also curious as to what gegl n-channel editing might be like. Soft
> > proofing to an n-channel printer is a one use case for n-channel editing,
> > when the goal is to convert to the n-channel ICC profile and tweak the
> > channels while soft proofing. Hopefully again the printer people will
> > correct me if I'm speaking nonsense.
>
> In the end; you'd have the buffers for individual ink plates in GIMP
> (more likely than having it as an n-component buffer as you would if
> there was a CMYK mode along with RGB); and need to preview/softproof
> it. In some cases lcms might provide what is needed; in others like
> silk screen printing a couple of metallic inks on colored fabric -
> maybe not.
>
> Today I wrote a proof of concept spectral soft proofing op for GEGL.
>    https://git.gnome.org/browse/gegl/tree/operations/workshop/ink-simulator.c
>
> The settings are edited in a little multi-line editor, with a default
> configuration like this:
> -----
> illuminant = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> substrate  = white
> ink1 = cyan
> ink2 = yellow
> ink3 = magenta
> ink4 = black opaque
> -----
>
> It currently uses an "RGBA float" as input; this could be changed to
> multiple buffers or an n-channel babl format. The 4 inks in order,
> though the order only matters if inks are suffixed with opaque. One
> can either pass in a 20 space separated numbers between 0.0 and 1.0
> (or higher), or one of few hardcoded colors.
>
> The op is in the operations/workshop/ directory of GEGL; so you have
> to type make && sudo make install; in the workshop dir to install it.
> For quickly preparing a file to use with the default settings;
> decompose a color imake to CMYK and recompose it to RGBA; then invoke
> the ink-simulator from the GEGL tool.
>
> The model is far from complete. It lacks spectral curves for commonly
> used illuminants, sane spectral responses for the inks, it doesn't
> take any form of dot gain into account - and has a naive idea about
> types of ink.
> With the addition of a couple of animated frames and more tweaks; one
> could add the ability to preview glossy or metallic inks as well.
>
> /pippin

I looked at the code. Some questions come to mind:

1. LCMS2 has CMYK soft proofing and also ink-limiting already covered. 
Here's the ink-limiting algorithm, quoted from the LCMS API (looks 
similar to the GEGL code):

Ink-limiting algorithm:
 Sum = C + M + Y + K
 If Sum > InkLimit
 Ratio= 1 - (Sum - InkLimit) / (C + M + Y)
 if Ratio <0
  Ratio=0
 endif
 Else
 Ratio=1
 endif
 C = Ratio * C
 M = Ratio * M
 Y = Ratio * Y
 K: Does not change

LMCS already supports up to 16 channels in an ICC profile. Granted, the 
LCMS ink-limiting algorithm seems at present limited to only four inks. 
But a patch to LCMS for more than four inks is surely possible.

2. Many people with printers go to great lengths to use Argyllcms or 
some commercial equivalent to make accurate printer profiles. LCMS 
already does accurate conversions from the source RGB color profile to 
the printer profile. So I guess I don't see the point of the gegl code.

The gegl code, no matter how refined and complicated it might become, 
can't compensate for the fact that real printers+inks+papers can and do 
have all kinds of unpredictable channel cross-overs and varying deltas 
in resulting color between any given color patch (combination of inks 
laid down on the paper) to the next closest color patches. Can gegl 
handle this kind of variation in colors from one color patch to the 
next? Real printer profiles have tremendous variation in resulting 
device white and black points - can the gegl code handle the wide 
variety of real printer white and black points? You mention different 
illuminants and spectral ink responses. In light of the tremendous 
variation in how actual inks on actual paper reflect actual wavelengths 
of light, what does "sane spectral responses for inks" even mean? An 
industry average? Or will GEGL developers build and maintain a database 
of spectral responses for various paper/ink/illuminant combinations and 
allow the user to choose a combination, instead of just letting them use 
their actual printer profiles along with LCMS for soft proofing?

3. LCMS can convert between XYZ, LAB, LUV, YCbCr, xyY, HSV, HSL, CMYK, 
CMY, RGB, and GRAY, plus handle spot colors (and a whole lot of other 
stuff, including providing gamut displays, useful for soft proofing, and 
also color temperature conversions). Why is there so much babl/gegl/gimp 
code for doing things like converting from RGB to "naive CMY", LAB, HSV, 
etc? Why not leverage LCMS to accomplish these goals?

babl/gegl is hard-coded to convert between only *s*RGB and LAB/CMY/HSV, 
etc. LCMS can convert between *any* RGB color space and these other 
color spaces. GIMP is already at the top of the heap of available image 
editors in so very many ways, but not with respect to color management. 
Leveraging LCMS to do all color space conversions would bring GIMP to 
the top of the heap of all available image editors even for color 
management.

4. Regarding 3, I would already have done my very best to write the 
color-conversion code for all the various color spaces handled by LCMS, 
except that I was told that GEGL is going to take over handling color 
management, a proposition that continues to baffle me.

5. Regarding 4 and slightly off-topic, one obstacle to writing 
additional color conversion code for GIMP as part of the lcms.c plugin 
is the lack of existing hooks for color spaces other than RGB. The 
writing of such hooks is frankly beyond my c-coding ability. But I did 
already write the code to convert between GRAY and RGB (there's already 
a hook for GRAY). Adding other color spaces involves the same sort of 
code - lots and lots of code, entries for every color space combination, 
for every precision, times 2 to handle alpha channels. But it's just the 
same sort of code repeated as needed, quite do-able if the hooks were 
there. I realize it's more complicated than just adding hooks to lcms.c, 
because sending information to the display screen and etc involves more 
than lcms.c. But if Cinepaint, Photoshop, and Krita can do it, surely 
GIMP can.

One of the things that seemed to me to be really cool about GEGL is the 
fact that it seemed color space agnostic - it just does pixel math. Or 
so I thought. Perhaps I'm wrong. If I'm right, then personally I really, 
really, really (that's not enough "reallys" but you get the point) want 
GIMP to support real CIELAB editing. LAB has three channels. RGB has 
three channels. LCSM can convert between RGB and LAB. Is there any 
reason why a hook can't be provided in the lcms.c plugin and elsewhere 
as needed, such that LCMS can do the conversion part - between LAB and 
*any* RGB color space, not just between LAB and *s*RGB - and let GEGL 
can handle the pixel math? And can a hook be provided for converting to 
CMYK? At least for soft proofing to the screen and for final conversion 
for exporting to disk?

Elle