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

[Kai-Uwe Behrmann]

Am 04.02.11, 16:05 -0700 schrieb Chris Murphy:
> On Feb 4, 2011, at 3:39 PM, Kai-Uwe Behrmann wrote:
>>> 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.
>
> Haha, yes preferably!
>
>>
>>> 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.
>
> I'm not sure what you mean in the first part before the comma. There's 
> no good reason why the output intent would not be respected, Ghostscript 
> can handle this. The one additional conversion is that to display RGB.

I meant, the OutpuIntent profile which is set by the application would be 
passed back to the applications. That will not contain new information. In 
case of a PPD configured profile, that is as well likely to be already 
parsed by the application (or through a helper).

The additional conversion to RGB can happen inside the application where 
the RGB belongs to. Then it is far more easy to select a nice RGB profile.

Can we have the cases written, where the OutpuIntent shall override any 
internal configured device profile from the PPD or whatever mechanism? I 
tent to get lost in the PDF specifications and be afraid too many other 
non print experts too. (The wiki would be good.) That could/should become 
part of the colour managed print architecture plan.

>>> 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.
>
> Both are questions maybe for Michael Sweet to answer if he's monitoring. 
> I actually don't know the pipeline for this on Mac OS X. It's a lot 
> different, of course, because everything is effectively PDF (or PDF 
> like) and rasterized by core graphics. I might have something important 
> out of sequence here, but it appears to work largely like I've described 
> on OS X. I can soft proof documents and zoom in to see that they still 
> have resolution independence. And it's quite fast.
> 
> How do correct for multiple monitors? I can't answer that. Ideally you'd convert directly from printspace to displayRGB for each display independently without an intermediate space. But maybe architecturally on Linux you end up needing an additional conversion to a larger space and then in that case what space should that be? I think it's almost a waste of time to do so many conversions to enable soft proofing for a small number of users who want this capacity and not do it very high quality or you may end up with some combinations of output devices and displays, getting profile induced posterization. So you'd need to keep all of these conversions high-bit even if the original data is all 8bpc.
>
>
>>> 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.
>
> I think I've abbreviated it, sticking to just the basic color space 
> conversions. If transparency is going to be supported in the print spool 
> file with blending modes, then you have the additional conversions to 
> transparency blend space before the flattening can occur. But this is 
> the job of Ghostscript. And it's already doing these correctly for CMYK

Agreed, and thats why I think its not much a problem to simulate (proof) 
inside the application, which has very likely access to the same 
Ghostscript/poppler installation, at least in a local installation.

> only content. I'm unaware of a problem with it working with RGB. I 
> haven't tested it with mixed mode RGB+CMYK, but I also don't know if 
> this is something you plan to support in the PDF print spool file 
> either.
>
>
>> The relyable print ICC profile with a local installation of Ghostscript and the same conversion module would be assumedly more easy I guess.
>
> Maybe.
>
>
> Chris Murphy

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