On Friday 15 May 2009 12:14:36 am Koji Otani wrote: > From: Albert Astals Cid <[email protected]> > Subject: Re: [poppler] Testing color management functionality > Date: Thu, 14 May 2009 19:40:17 +0200 > Message-ID: <[email protected]> > > aacid> A Dimecres, 13 de maig de 2009, Hal V. Engel va escriure: > aacid> > Now that it looks like the color management support will be > released with aacid> > version 0.12 I decided to do some more testing. I > did this testing using a aacid> > patched version of the Qt4 demo viewer > (the same patch set I sent to the aacid> > email list on Monday) using the > altona pdf test suite > aacid> > http://www.eci.org/doku.php?id=en:downloads. This test suite has > tests for aacid> > many things but I was only interested in those that were > related to color aacid> > rendering. > aacid> > > aacid> > The most significant issues are with the following test elements: > aacid> > > aacid> > #26 "Duotone and Spot Color" Poppler fails the spot color test > but appears aacid> > to work for the doutone test. > aacid> > > aacid> > #27 "Overprinting spot color and process color black" Only the > overprinted aacid> > color is displayed. > aacid> > > aacid> > #28 "Overprinting process colors only" Only the overprinted color > is aacid> > displayed. > aacid> > > aacid> > #34 through #38 These are renderings involving different source > color aacid> > spaces and/or different rendering intents. Currently the > color management aacid> > code in poppler does not handle rendering intents > and this shows up in aacid> > tests #35 through #38. But it also appears > that CM is not functioning at aacid> > all for vector elements (test #34). > aacid> > > aacid> > The altone test suite appears to be comprehensive and is a harsh > test of aacid> > any PDF rendering engine but it should help to find and > correct rendering aacid> > issues since each test element only tests a > specific well documented aacid> > feature. > aacid> > > aacid> > Not all of the above issues are specifically color management > problems. aacid> > #34 through #38 are definitely color management issues > and #26 (spot color) aacid> > may also be a color management issue. #27 > and #28 may be transparency aacid> > issues but may also be impacted by > color management. > aacid> > > aacid> > I think one goal for v 0.12 should be for poppler to be able to > pass all aacid> > (or maybe most) of the above tests. > aacid> > aacid> Koji any input on this? > aacid> > > Poppler doesn't support overprinting, so #27 and #28 fail. > I'm not sure poppler support spot color.
It appears that it does not. > > Colors of vector regions are same as those of pixel regions in #34-#38. I am sorry I got this wrong. When looking more closely at the documentation on the altona site it appears that the differences I am seeing in #34 are not vector vs. pixel but rather DeviceCMYK vs. ECI-RGB. The altona documentation says: "Under no circumstances shall a distinct color difference be visible per color mode between vector and pixel elements. A subtle color difference between the elements of different color modes is acceptable. As a consequence, along the virtual line between ECI-RGB and DeviceCMYK (from upper left to lower right corner), a subtle color difference may be visible. Color differences between elements – vector versus pixel – within the same color mode indicate that vector and pixel elements are treated differently" The difference I am seeing is very pronounced and not at all subtle and is along the virtual line between ECI-RGB and DeviceCMYK. I do not see any difference between the vector and pixel elements in the same color mode. So this indicates a problem with how DeviceCMYK is handled and perhaps other Device* color spaces. Looking at the PDF specification I see that it is possible for the the dictionary for a Device* object to have a default color space specified. I don't know if the altona document has this but looking at the code it is clear that no attempt is made to get or use the default color space for the Device* objects. If it is in the document it should be used any time the Device* color space is not a match with the output device color space. #35 I can see a slight difference between the CIELab and ECI_RGB sections. Looking at the code it was not doing the white point correction to the XYZ values after the calll to getXYZ() in GfxLabColorSpace::getRGB. Fixing that corrected the problem. While looking at this I discovered that in GfxLabColorSpace::getGray() it had the same problem. I will create a patch with this set if fixes. #36, #37 and #38 do not show any of the difference from changes to rendering intent that should be there. Looking at the code it is always using INTENT_RELATIVE_COLORIMETRIC and there is no attempt to get the Intent from the dictionary in GfxICCBasedColorSpace::parse(). So the code is not parsing out the intent and using that to create the transforms. I had a look at the code but I was not able to get the Intent from the dictionary since I am not at all familiar with the code base. Perhaps someone who understands how the dictionary stuff works could take a look at adding this to GfxICCBasedColorSpace::parse(). > > --- > When _ICC_PROFILE atom doesn't exist, qt4/demos/poppler_qt4viewer > produces following error. > > lcms: Error #12288; Read from memory error. Got 0 bytes, block should > be of 128 bytes > > I attached patch to fix this. > Please note that XGetWindowProperty returns 'Success' even when > requested atom doesn't exist. Thanks. I only tested this on a system that had these atoms set. I know that at this time this is not a common setup so it needs to handle the common case gracefully. > > --------- > Koji Otani _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
