[poppler] Testing color management functionality

[Hal V. Engel]

On Friday 15 May 2009 12:14:36 am Koji Otani wrote:
> From: Albert Astals Cid <aacid at kde.org>
> Subject: Re: [poppler] Testing color management functionality
> Date: Thu, 14 May 2009 19:40:17 +0200
> Message-ID: <200905141940.20444.aacid at kde.org>
>
> 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