On 03/13/2014 10:37 PM, Øyvind Kolås wrote:
On Wed, Mar 12, 2014 at 10:27 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
