[Openicc] CUPS Color Management under Linux gets into distros

[Alastair M. Robinson]

Hi :)

On 14/02/11 03:14, Hal V. Engel wrote:

> Yes a patch was created in response to the bug report I opened. It
> appears to be doing the right thing when you look at what is happening
> in the code but when run against pdf files that have tests for rendering
> intent it fails the tests. GhostScript also fails that same test so I am
> not sure what is going on. The only thing I can think of is that perhaps
> the tests are intended for CMY(K) output since I only tested this with
> RGB output at this point.

That's certainly part of it, I think.  Poppler by default uses the LCMS 
built-in sRGB as its output space, and sRGB doesn't have distinct 
perceptual / relative colorimetric tables, so the tests that should have 
shown a difference wouldn't when using that profile.

Today I've tried setting a different display profile in poppler's gtk 
demo program.  Only a few elements in the Altona test image are rendered 
to the specified profile at all.  The rendering intent test squares are 
among the elements that are, but it still fails the test.  I suspect 
there's some caching going on somewhere that's not taking the rendering 
intent into account.

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

All the best
--
Alastair M. Robinson