<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> On Sunday, February 20, 2011 08:55:25 PM Koji Otani wrote: > From: "Alastair M. Robinson" <blackfive@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@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/openicc </body></html>