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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]