[poppler] Testing color management functionality

[Albert Astals Cid]

A Dilluns, 18 de maig de 2009, Hal V. Engel va escriure:
> 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.

Go Hal Go! You can do it ;-)

Albert

>
> Hal
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler