[Openicc] Printing targets: App or driver ? Profiling RGB or CMYK

[Robert Krawitz]

On Tue, 17 May 2011 18:15:22 -0600, Chris Murphy wrote:
> On May 17, 2011, at 5:23 PM, Alastair M. Robinson wrote:
>
>> Hi,
>> 
>> 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.
>
> When I suggest DeviceN not possible, I'm referring to the smaller
> consumer inkjets. I don't know that there is actually a DeviceN
> path. I know there is one for the 17" and wider Epson printers. But
> for the R1900, R2000, WorkForce printers, Picture Mates, etc. I
> don't know that they accept anything other than sRGB. Same for the
> $50 HP's and Canon's.

Well, *I* do, at least for Epson printers.  *All* of the current
Epsons, bar none, have a DeviceN path.

> Also, my understanding is that with Epson printers, the proprietary
> driver's sRGB option utilizes internal custom calibration tables,
> per printer, that allow very good consistency printer to printer of
> the same model. Whereas when not driven with the proprietary driver,
> this calibration information is not available and the repeatability
> between prints is not nearly as good. So again, I wonder if there is
> a way to access this sRGB entry path to the printer for open
> drivers, or if open drivers are stuck only using DeviceN?

It's possible that the printers have individual calibration tables; I
don't know.  It might be interesting to put a USB tap on the
bidirectional communication and analyze what flows in each direction.
The sRGB path (ESC/P-R) is pretty straightforward.

But I don't know about this "repeatability between prints" thing.
Unless there's evidence that there's a problem with, say, Gutenprint
but not with the OEM driver, it sounds like FUD.  One test would be to
take a look at print to file with the OEM driver that's then sent to
the printer vs. print directly to the printer.

>>> 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.
>
> Is this hand-tuned parameterized curve simpler, or more complex
> than, either the ICC output device profile format (which has lots of
> stuff in it, LUTs, multiple curves, matrices); or the ICC devicelink
> profile format?

Probably a lot simpler.  Some of the stuff is in the form of a curve
(HSL-based adjustments), but most of it is parameterized.  But the
computation isn't hthat straightforward.

>>> 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!
>
> Yeah so I'm curious if the base, always in place conversion, is CMYK
> -> DeviceN.

See my previous message.

>>> 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.
>
> Right.
>
> My brain is presently plugged up on how to do this, but I wonder how
> to have cake and eat it too. i.e. make it easier for the Gutenprint
> developers, and users who don't use custom ICC profiles, those users
> who do use custom RGB ICC profiles, and those who would use custom
> CMYK ICC profiles, and then bury it all behind an default interface
> that does the right thing for all of them. But it uses ICC profiles
> instead of this classic proprietary Epson, Canon, HP black box
> LUT...might be pie in the sky but I'm still wondering.

Fine by me, if we can get it to work.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton