[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Sunday, February 20, 2011 08:55:25 PM Koji Otani wrote:
> From: "Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>
> Subject: Re: [Openicc] CUPS Color Management under Linux gets into distros
> Date: Mon, 21 Feb 2011 01:34:37 +0000
> Message-ID: <4D61C12D.302 at fakenhamweb.co.uk>
> 
> blackfive> Hi :)
> blackfive>
> blackfive> On 14/02/11 03:14, Hal V. Engel wrote:
> blackfive>
> blackfive> > Yes a patch was created in response to the bug report I
> opened. It blackfive> > appears to be doing the right thing when you look
> at what is happening blackfive> > in the code but when run against pdf
> files that have tests for blackfive> > rendering
> blackfive> > intent it fails the tests. GhostScript also fails that same
> test so I blackfive> > am
> blackfive> > not sure what is going on. The only thing I can think of is
> that blackfive> > perhaps
> blackfive> > the tests are intended for CMY(K) output since I only tested
> this with blackfive> > RGB output at this point.
> blackfive>
> blackfive> That's certainly part of it, I think.  Poppler by default uses
> the blackfive> LCMS built-in sRGB as its output space, and sRGB doesn't
> have distinct blackfive> perceptual / relative colorimetric tables, so the
> tests that should blackfive> have shown a difference wouldn't when using
> that profile. blackfive>
> blackfive> Today I've tried setting a different display profile in
> poppler's gtk blackfive> demo program.  Only a few elements in the Altona
> test image are blackfive> rendered to the specified profile at all.  The
> rendering intent test blackfive> squares are among the elements that are,
> but it still fails the test. blackfive> I suspect there's some caching
> going on somewhere that's not taking blackfive> the rendering intent into
> account.

I had problems with profile cashing when I was playing around with the poppler 
code in late 2009 and I was never able to figure out why.  For example if you 
specify an output profile and render a PDF and then change the output profile 
and re-render the PDF or render a new one it will use the first output prfile 
specified and not the one you specified for the subsequent renderings.  I don't 
think the code that does this has had much change since that time so this is 
where the problem is likely to be. 

> blackfive>
> blackfive> Incidentally, I notice that the poppler-based pdftoraster *also*
> has a blackfive> hard-coded relative colorimetric transform in it; from
> what I can see, blackfive> when the CUPS profile is CMYK, the filter asks
> Poppler to render to blackfive> sRGB and then converts that to the printer
> profile afterwards. blackfive> Perceptual - or at the very least
> RelCol+BPC - would be better here, blackfive> if we *have* to render to
> sRGB as an intermediate step.  (Does poppler blackfive> not support
> rendering to CMYK?)
> blackfive>
> 
> I'm a maintainer of the poppler-base pdftoraster.
> Poppler has code for CMYK, but it's a compile time option 

I can't find anything in either the autotools or cmake build systems for 
poppler that appear to turn CM for CMYK on or off.  CM is either on or off and 
it does not appear to have any way to only turn it on for subset of object 
types or for specific output types.   Having looked at the poppler code I also 
don't see any way to disable (IE. conditional compilation stuff) CM in CMYK 
objects.  Could you provide more info about how this is controled?

> and not
> available in most distributions. also it's not enough tested.

But the way to get this tested is to start using it now so that issues can be 
ironed out as sooner.

> So, I don't use it.
> It's no problem for me to change hard-coded rendering intent to
> Perceptual in pdftoraster code.
> Please give me some advises about these.

I don't think this will do too much for us if you are rendering everything to 
sRGB first and then to the final colorspace.   The rendering intent needs to 
affect the conversion from the objects color space to the destination 
colorspace and by first rendering to sRGB you have already clipped some of the 
content (IE. there is data loss).  The conversion needs to happen directly 
from the PDF content to the output color space and it needs to use the 
rendering intents that are in the PDF dictionary.   So other than avoiding a 
double conversion this is really a poppler issue.

> --------
> Koji Otani
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110221/faa4dd30/attachment-0001.htm>