[Openicc] Linux CM ideology... ICC image map converter

[Kai-Uwe Behrmann]

Am 04.02.11, 13:27 -0700 schrieb Chris Murphy:
> On Feb 4, 2011, at 10:07 AM, Kai-Uwe Behrmann wrote:
>> Am 04.02.11, 16:04 -0000 schrieb Richard Hughes:
>>> On 4 February 2011 15:46, Jan-Peter Homann <homann at colormanagement.de> wrote:
>>>> This "ICC image map converter" should transform both image maps for output
>>>> to the monitor or for print out.
>>>
>>> In GTK we use cairo for printing too. "Print preview" support would be
>>> very easy to add.
>>
>> "Print preview" needs to pass the print ICC profile to the preview 
>> window. I see that not adressed with your CUPS icc changes. Eigther the 
>> profile from the print dialog needs to be passed to Ghostscript and the 
>> print driver. Or the profile from CUPS needs to be transparent to the 
>> preview code. Otherwise the preview is fragile.
>
> I would say it's problematic to literally pass the printer ICC profile 
> to the preview window, because the data could be RGB or CMYK or deviceN, 
> depending on the printer. It probably makes more sense to have 
> GhostScript normalize the PDF to Display RGB first, then do the hand 
> off.

You want to see it fool proof.

> Example:
>
> 1.
> Starting out with a PDF print spool file with various objects which are 
> tagged with their respective source spaces, whatever they are, and there 
> is also an OutputIntent which is a destination profile. The user would 
> have chosen this either directly in the print dialog, or automatically 
> inferred by CUPS using *cupsICCProfile in the printer's PPD, based on 
> user settings.

Then the print profile would not tell anything new, provided the 
OutputIntent is respected and no further conversion is planed.

> 2.
> Ghostscript+lcms color manage the objects per the pdf canonical sequence 
> (which is important, the order must be right, the blend spaces must be 
> correct, etc) to the OutputIntent space, so now this still probably 
> mostly vector PDF is color managed to the output intent but hasn't been 
> fully rasterized.
>
> 3.
> Now you have a PDF in a single normalized print space, which could be 
> RGB or CMYK (or maybe deviceN). Now it needs both rasterization for 
> display and also needs to be color managed for display.  This could be 
> done in either order. But for performance reasons it's probably better 
> to get the print file into Display RGB before moving it to a preview 
> application.

Thats not easy to do correctly inside CUPS.
It would mean to know inside CUPS about the actual users Xorg 
configuration. But CUPS can not much tell about Xorg. It would require a 
communication over its head. Next problem, how to correct for multiple 
monitors? I do not know. Normalising to some larger RGB space could help, 
somewhat.

> 4.
> Once in Display RGB, you could handoff to the preview application. It 
> would be nice if the preview application could leverage Ghostscript for 
> on-the-fly rasterization so the user has the ability to zoom into the 
> print preview file and it looks nice and sharp, no jaggy text, etc. But 
> if not, Ghostscript could raster a medium resolution version earlier in 
> the chain then hand off to the preview app and it would probably be OK.
>
> Another variation would be to fully color manage and rasterize it to 
> print resolution, and then convert a "copy" of that to DisplayRGB 
> redirected to the preview application.

Seems a rather long list of steps involved.

The relyable print ICC profile with a local installation of Ghostscript 
and the same conversion module would be assumedly more easy I guess.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org