[Openicc] Basic colour managed Printing stack

Kai-Uwe Behrmann ku.b at gmx.de
Tue Mar 1 07:20:48 PST 2011


Edmund,

of course colour mangagement is just beginning to get widley distributed 
and understood. Hence we discuss here many aspects and many are new to us. 
Bugs have more recently detected and need to be fixed. Thats pretty normal 
at this stage. Do not care about rendering intent bugs if its too 
complicated for you to understand or follow. Thankfully others care 
already to understand and fix that.
The "CUPS Color Management under Linux gets into distros" thread contains 
the essential annoucement.

Ok here comes the IMO most simple and important data flow. A chart my 
follow later by me about this case.
Basic printing colour management is done by CUPS + Ghostscript/Poppler, 
the according pdftoraster filters and a supplied PPD with cupsICCProfile 
included. Thats all which is needed to print "Jpeg photographs in sRGB".

Here the steps:
* client sends a PDF, Jpeg or whatever is allowed to CUPS
* CUPS server sees the file and
* CUPS parses the queue's cupsICCProfile in the belonging PPD
* the ICC profile is passed to the xxxtoraster filter by CUPS
* the colour conversion will happen inside the xxxtoraster filter

That works as well remotely.
It covers the most frequent future scenario: canned vendor profiles.

Am 01.03.11, 13:59 +0100 schrieb edmund ronald:
> Kai Uwe,
>
> At this point with all this discussion of complexities, I am giving
> up hope that you people will ever be able to design a system which is
> actually capable of printing even an sRGB file decently. Can't you get

Depending how you set your expectation, everything can be a success or 
failure. But I am pretty sure the basic techical work is already in place
for sRGB printing.

> it? 99% of files out there are simple Jpeg photographs in sRGB and
> THEY NEED TO BE PRINTED.

Oh. You surely meant meant most printed area in PC use is text. That might 
be one reason, why colour management was not worked on much earlier on 
Linux. For sRGB being dominant in graphics I completly agree.

> What might really advance our discussion here is a flow chart of CUPS
> - anyone got one? Showing how files are dispatched and filters
> invoked?
>
> And a decision to declare some basic file types which the print
> system may wish to special case, eg. the various profiling targets and

File types are not special handled per se. PDF can be 
sent with appropriate DeviceXXX + OutputIntent as was mentioned several 
times. However there are lurking some bugs around, which need to be fixed 
to make this work. For other file types is no such agreement in sight. I 
spare the discussion around that matter here.

> "special" sRGB for when the system is just a skeleton.

I am afraid I do not get that translated useful.

> Edmund

hope this helps,
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org



More information about the openicc mailing list