[poppler] Testing color management functionality

[Hal V. Engel]

On Monday 18 May 2009 03:33:09 am Leonard Rosenthol wrote:
> Or most likely, create the various intents on the fly and cache them. 
> Recreating each time you encounter them will have performance penalties
> (since creation of a transform is fairly heavyweight).
>
> Leonard

The current code creates a transform for each ICCBased object.  From my 
reading of the PDF spec. only ICCBased objects can have different intents.  
Therefore it would not add any new overhead to create the transforms with the 
correct intent other than the added overhead of getting the correct intent 
from the dictionary.  As Koji points out below there is some complexity to 
figuring out what the intent should be for any given object's transform.

The current code does have some hooks for caching of transforms and has a 
reference count on the transforms for this.  But this is currently 
unimplemented since there is no way to check to see if a given transform is 
already available so that it can be reused.  Implementing this could make the 
code more efficient but it will be non-trivial.

>On Behalf Of Koji Otani
snip
> 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.

And this is likely to be non-trivial to add since the PDF specification is not 
very clear about how this should be done.   At this point I think the focus 
should be on getting CM support in place for ICCBased and CIEBased objects.  
In addition this needs to be extended so that it is exposed in the various 
bindings like I did with the Qt4 bindings in the patch I created. The current 
code along with the various patches has most of this working (other than 
rendering intent and all of the bindings) although it could stand to be tested 
by a wider audience.  So it is mostly a matter of cleaning things up and 
finding and removing bugs in that code to get to that point. 

snip

> 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.

And when I looked at how this might be implemented in the code I can 
understand why this is the case since it will be fairly involved.  I spent 
about a half day looking at this and I still had no idea what needed to be 
done.  Of course someone who has a better understanding of how the dictionary 
stuff works and also how to read the PDF specification might have a easier 
time figuring it out.  It is not going to be trivial to implement but it is 
the only significant piece that is missing from having correct handling of 
ICCBased objects.

Hal