[Openicc] Printing targets: App or driver ? Profiling RGB or CMYK
Robert Krawitz
rlk at alum.mit.edu
Tue May 17 17:32:34 PDT 2011
On Wed, 18 May 2011 00:23:59 +0100, Alastair M. Robinson wrote:
> On 17/05/11 23:41, Chris Murphy wrote:
>
>> Some inkjet printers are CMYK, most have more than four
>> colorants. But most of those consumer printers with more than four
>> colorants don't provide access to individual channels, i.e. DeviceN
>> not possible.
>
> Epson inkjets at least - and I believe Canon too - are driven at a
> pretty low-level - Gutenprint is telling the printer precisely which
> ink drops to print at which sizes at which locations - so yes,
> DeviceN is available. Its not being available on closed platforms
> is just a driver limitation.
All Epson inkjets provide DeviceN, but it's a dithered DeviceN
(usually 1 or 3 non-linear levels per colorant), and you have access
to every drop position. A lot of the newer ones also provide sRGB
input (ESC/P-R). We haven't done this yet in Gutenprint because it's
not clear how to fit this in with the rest of our settings, but
something just occurred to me: we could offer an additional color
correction option of "Native sRGB" (or whatever we want to call it)
for those printers, and bypass all of the other color stuff.
Canons, I'm not sure exactly how they work, but it seems to be more
complex than Epsons. A lot of HP inkjets do provide (only) an RGB
input.
>> 2. Not clear to me is the exact nature of alternative paths to
>> these printers, when available. Are they unspecified RGB?. CMYK?
>> Or DeviceN?
>
> If you're talking about the path between Gutenprint and the printer,
> rather than the path between CUPS filters and Gutenprint, then
> *only* DeviceN is available. Having said that, Gutenprint has
> support for limiting which channels are used, so you can print using
> only CMYK if you really want to. There are other more exotic
> situations to handle, too, such as on the R800 and friends, CMYRB
> and only one of two available blacks, and with or without gloss
> optimiser!
Don't remind me; I have enough tsuris as it is. I get a headache
every time I think of that printer and its fiends. And then there are
the 7900 and 9900...
>> 3. If DeviceN is available, how is this utilized by Gutenprint? Is
>> there first a CMYK to DeviceN LUT?
>
> Hand-tuned parameterised curves, rather than a LUT, but broadly,
> yes.
There are a couple of steps in this case, depending upon the printer:
there are gamma curves, and then if the DeviceN is really a CMYK
variant (with light inks, such as CcMmYK, CcMmYKkk, or the like),
there's what we call a "channel splitting" step, where we generate the
light inks. This isn't a pure per-channel curve; it depends
dynamically on the total amount of ink (for e. g. pure cyan, we use
more light ink than if there are other color inks mixed in, to
modulate the total ink load). I think of this as DeviceCMYK* rather
than DeviceN.
>> And then there is a separate RGB to CMYK LUT? Is RGB is reached via
>> concatenation of RGB-CMYK-DeviceN LUTs? Or is it a separately
>> developed RGB-DeviceN LUT?
>
> That I don't know - but it wouldn't surprise me if the answer to
> that varied between, say, a CMYKRB printer (R800 and friends), and a
> CcMmYK printer (random Photo printer of your choice) I think it
> would depend on the precise ink set supported by the printer in
> question. CMYK -> CMYKRB is of course way more complicated than
> CMYK -> CcMmYK!
It's RGB -> CMY -> CMY(RB) -> CMYK(RB) -> CcMmYK(RB) -> CcMmYK(RB)+gloss.
Obviously, not all of the steps apply to all of the printers. And
yes, the R800/R1800/R1900 are a lot nastier than the others. The
CMY->CMY(RB) conversion is done in hue space.
And if you don't like it, you're welcome to grab a copy of our source
and do your worst to print-color.c, color-conversions.c, and channel.c :-)
>> What what is the basis for the RGB space? sRGB or other?
>
> I'd say "de-facto sRGB" (as in, whatever looks about right when
> Robert's hand tuning the printer in question!) - the process isn't
> yet instrument based.
De facto sRGB is probably the best description of it.
More information about the openicc
mailing list