[poppler] Testing color management functionality

[Koji Otani]

From: "Hal V. Engel" <hvengel at astound.net>
Subject: Re: [poppler] Testing color management functionality
Date: Fri, 15 May 2009 18:11:33 -0700
Message-ID: <200905151811.33985.hvengel at astound.net>

hvengel> >
hvengel> > Poppler doesn't support overprinting, so #27 and #28 fail.
hvengel> > I'm not sure poppler support spot color.
hvengel> 
hvengel> It appears that it does not.
hvengel> 
hvengel> >
hvengel> > Colors of vector regions are same as those of pixel regions in #34-#38.
hvengel> 
hvengel> I am sorry I got this wrong.  When looking more closely at the documentation 
hvengel> on the altona site it appears that the differences I am seeing in #34 are not 
hvengel> vector vs. pixel but rather DeviceCMYK vs. ECI-RGB.  The altona documentation 
hvengel> says:
hvengel> 
hvengel> "Under no circumstances shall a distinct color difference be visible per color
hvengel> mode between vector and pixel elements. A subtle color difference between
hvengel> the elements of different color modes is acceptable. As a consequence, along
hvengel> the virtual line between ECI-RGB and DeviceCMYK (from upper left to lower
hvengel> right corner), a subtle color difference may be visible. Color differences 
hvengel> between elements – vector versus pixel – within the same color mode indicate
hvengel> that vector and pixel elements are treated differently"
hvengel> 
hvengel> The difference I am seeing is very pronounced and not at all subtle and is 
hvengel> along the virtual line between ECI-RGB and DeviceCMYK.  I do not see any 
hvengel> difference between the vector and pixel elements in the same color mode.  So 
hvengel> this indicates a problem with how DeviceCMYK is handled and perhaps other 
hvengel> Device* color spaces.  
hvengel> 
hvengel> Looking at the PDF specification I see that it is possible for the the 
hvengel> dictionary for a Device* object to have a default color space specified.  I 
hvengel> don't know if the altona document has this but looking at the code it is clear 
hvengel> that no attempt is made to get or use the default color space for the Device* 
hvengel> objects.  If it is in the document it should be used any time the Device* 
hvengel> color space is not a match with the output device color space. 
hvengel> 

I see. Color management code which I added doesn't touch Device* color
spaces.

hvengel> #35 I can see a slight difference between the CIELab and ECI_RGB sections.  
hvengel> Looking at the code it was not doing the white point correction to the XYZ 
hvengel> values after the calll to getXYZ() in GfxLabColorSpace::getRGB.  Fixing that 
hvengel> corrected the problem.  While looking at this I discovered that in 
hvengel> GfxLabColorSpace::getGray() it had the same problem.  I will create a patch 
hvengel> with this set if fixes.
hvengel> 


hvengel> #36, #37 and #38 do not show any of the difference from changes to rendering 
hvengel> intent that should be there.
hvengel> 
hvengel> Looking at the code it is always using INTENT_RELATIVE_COLORIMETRIC and there 
hvengel> is no attempt to get the Intent from the dictionary in 
hvengel> GfxICCBasedColorSpace::parse().  So the code is not parsing out the intent and 
hvengel> using that to create the transforms.  I had a look at the code but I was not 
hvengel> able to get the Intent from the dictionary since I am not at all familiar with 
hvengel> the code base.   Perhaps someone who understands how the dictionary stuff 
hvengel> works could take a look at adding this to GfxICCBasedColorSpace::parse().
hvengel> 

As Leonard said INTENT can come from several places, it's not so
simple to handle INTENT correctly. We have to check if current INTENT
is changed and recreate transform if needed.
This is why I didn't support INTENT this time.