[poppler] Color Management

[Koji Otani]

From: "Hal V. Engel" <hvengel at astound.net>
Subject: Re: [poppler] Color Management
Date: Fri, 27 Feb 2009 12:45:12 -0800
Message-ID: <200902271245.13112.hvengel at astound.net>

hvengel> On Friday 27 February 2009 02:06:05 am Koji Otani wrote:
hvengel> > Hi
hvengel> >
hvengel> > Thank you for your comments.
hvengel> >
hvengel> > First, poppler is a library. So, applications using poppler should be
hvengel> > responsible for location of profiles, I think.
hvengel> > Applications (not poppler) can know
hvengel> > on which device output is displayed and which
hvengel> > profile is appropriate one.
hvengel> 
hvengel> This is correct.  I was mostly pointing out how end users would expect this to 
hvengel> work eventually with the intent of making sure that the poppler API would 
hvengel> allow for that to happen.  It appears that the API does but there are no 
hvengel> current apps, even demo apps included with poppler, that make the calls for 
hvengel> this to occur so it is untested at this time.  
hvengel> 
hvengel> Apps that are not CM aware like Okular built against poppler git head are much 
hvengel> better behaved when rendering ICC based pdf objects than before. Poppler now 
hvengel> has a reasonable default behavior when it encounters ICC based objects in 
hvengel> spite of not having access to the correct output profiles.   This is a good 
hvengel> thing and a big step in the right direction.
hvengel> 
hvengel> >
hvengel> > I think that what we should do next about this is to add some
hvengel> > API (that set location of profiles) to the poppler external API (glib API).
hvengel> 
hvengel> Having taken a look at okular as an example of how applications are coded I 
hvengel> see that they are interfacing to poppler through the API defined in poppler-
hvengel> qt4.h perhaps believing that this provides a complete interface.  Of course 
hvengel> the API for setting the output profiles and for setting up the color 
hvengel> transforms is not exposed in poppler-qt4.h.  Okular basically does things in 
hvengel> about the same way as qt4/demos/poppler_qt4viewer so this appears to be fairly 
hvengel> typical of how many apps are/will be coded.   
hvengel> 

There are 2 external APIs for poppler. They are Qt4 and Glib.
I mentioned only Glib in the previous mail, but as you wrote, it's
needed to add the API for setting profiles to Qt4.
And it's good to change sample programs to use this API.

hvengel> Perhaps a good way to validate the API would be to incorporate basic CM 
hvengel> awareness into the demo apps.  In addition, this would then give application 
hvengel> developers some example code that would help guide their work in this area.
hvengel> 
hvengel> Speaking of the API, this is a minor issue, but one that should be fixed 
hvengel> before applications start using the CM APIs.  The "displayProfile" is actually 
hvengel> the output profile and it could be for any type of output device such as a 
hvengel> CMYK printer or even a N channel device.  For example a program using poppler 
hvengel> to generate raster output for a printer would call either setDisplayProfile() 
hvengel> or setDiplayProfileName() before calling setupColorProfiles() to setup the 
hvengel> correct transforms for getting output for the printer.  This is somewhat 
hvengel> counter intuitive.  The code looks like it handles this correctly so I am 
hvengel> pointing this out mostly to make the API more accessible since it would make 
hvengel> things clearer if this where named outputProfile rather than displayProfile.  
hvengel> The same thing applies to other parts of the API that use displayProfile or 
hvengel> display or Display as part of their name.  These should all be changed to 
hvengel> output* or Output* for clarity.  
hvengel> 

I see.

hvengel> >
hvengel> > Though current code looks /usr/share/poppler/ColorProfiles/display.icc
hvengel> >  and  ~/.xpdf/ColorProfiles/display.icc, this is only default behavior.
hvengel> > It seems OK to change these default to other files
hvengel> > such as /usr/share/color/icc/poppler.icc and ~/.color/icc/poppler.icc.
hvengel> 
hvengel> Looking at the code it appears that it will try to load display.icc by 
hvengel> default.  I don't find any references to poppler.icc in the code.  Of course 
hvengel> neither of these (display.icc or poppler.icc) exist in any location on most 
hvengel> machines including mine.   So I am not sure what profile is actually being 
hvengel> used by the current code.
hvengel> 

hvengel> In addition, it is accepted practice that if no display or output profile is 
hvengel> specified by the user or is available through system calls that this should 
hvengel> default to sRGB.  I have attached a patch that changes the section of 
hvengel> GfxColorSpace::setupColorProfiles() that sets up the output (display) profile 
hvengel> so that it defaults to sRGB.  This patch also changes references to 
hvengel> displayProfile and displayTransform and other things like this to use output 
hvengel> instead of display.  The patch does not address the profile path issue since 
hvengel> this should probably be handled using Oyranos since this is a more generalized 
hvengel> solution.
hvengel>

If no display or output profile is specified, current code uses
littele cms's built in sRGB profile.(see GfxState.cc: line 305)

hvengel> I tested the above code with okular and poppler_qt4viewer and  it appears to 
hvengel> be working correctly.  At least it builds and the apps run without apparent 
hvengel> errors.
hvengel> 
hvengel> Again I would like to thank Koji for his hard work on this since it is a 
hvengel> significant improvement to poppler even at this early stage.  In fact so much 
hvengel> so that I hope it is included in a formal release sometime soon.  I will be 
hvengel> looking this over as time permits and will make additional comments as                
hvengel> necessary and perhaps even supply a few patches.  I will also try to take a 
hvengel> look at qt4/demos/poppler_qt4viewer to see if perhaps I can find some time to 
hvengel> create a CM awareness patch for it.
hvengel> 
hvengel> Hal
hvengel> 
hvengel> 
hvengel> >