On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. > The code *experiment* linked to has nothing to do with ink limiting; what I linked to is rather naive additive and subtractive color mixing in a 20 band spectral color space, a little bit like how physics works. But yes; as I noted it doesn't take into account subsurface scattering and other things that ICC profiles try to encompass indirectly. > 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? The ink-simulator code as it stands is a naive; and when one has an ICC profile that can be softproofed through LCMS; there should be no reason for not using such a code path. The LCMS code path should however most likely live in a different GEGL op; and GIMP or something else would swap things around as needed (or have no such op there at all.) There is a reason I listed the code as being limited. If you look at the code and read it; you would understand what I meant by the spectral responses used not being "sane", or "sound", they are all 0.0 and 1.0; in comparison to the cone response curves used; which are based on real data. One wouldn't need spectral responses for inks/pigments under different illuminants, something close to illuminant E would suffice. And illuminants are standardised. The reason for that softproofing experiment is hunting for ways to deal with CMYK as a subset of the ink-plate printing/spot-color problem. Is it is easy to create and dynamically update/replace ICC profiles programattically using LCMS/agryll for a combination of inks coming from a couple of pantone colors (and yes, I'll include metallics and reflective transparent again); on a custom fabric choice. Like perhaps simulating the printing of silver, black and reflective transparent on top of black fabric. > 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? Because LCMS traditionally has been unpredictably slow (due to different type of ICC profiles and code paths the code needs to take); thus from GEGLs point of view LCMS is suitable for import (into one of the babl managed spaces). And export to a custom ICC profile. > 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. LCMS is intended for all external/ICC-requiring conversions; for internal conversions we bring our own faster ones through babl. > > 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. GEGL is taking over all pixel processing in GIMP; color mangement is part of that. In particular the display filters should all be turned into GEGL operations. See https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for an older writeup I did on the topic of GEGL and color. > 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? GEGL is intended to be _strongly_ color managed. Far from color space agnostic. Each operation specifies it's working space; and you are not permitted to override that. For instance a 5% brightness adjustment should do the same absolute colorimetric changes to your image data regardless of the source/import ICC profile. This means that compositing in with a linear working space, and compositing with a perceptual gamma working space should be two _different_ GEGL ops; at least it doesn't depend on the GeglBuffer. Similar for linear-invert and perceptual-invert. If you pass a CIE-Lab buffer to GEGLs gaussian-blur; the gaussian blur will turn the data into alpha premultiplied single precision floating point with linear light gamma. which is the working space of the gaussian blur operation, if you really wanted to blur in CIE-Lab space; you would have to put a fake "RGB" bablformat on the buffer, do the blur and the put back the CIE-Lab format. I've spent more time writing emails about this code; than writing - and playing with it. It would've been nice if you had had time to come to LGM. /pippin _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
