[Openicc] CUPS Color Management under Linux gets into distros

Koji Otani sho at bbr.jp
Sun Feb 20 20:55:25 PST 2011


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.
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 and not
available in most distributions. also it's not enough tested.
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.
--------
Koji Otani


More information about the openicc mailing list