[poppler] Color Management

[Hal V. Engel]

On Monday 02 March 2009 02:33:08 am Koji Otani wrote:
snip
> 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.

I started looking at the Qt4 API since I work mostly in Qt and added wrapper 
functions for the CM API to the Qt4 Document class.  This may not be the best 
place for this but I am just trying stuff at this point.  But if Koji or 
someone else thinks these belong in another location let me know.    I have 
also started working on making poppler_qt4viewer color management aware in 
that it should be able to use the X11 _ICC_PROFILE atoms if these exist.  I 
have a preliminary version of this that is mostly working.    Later on someone 
should also add similar code for Windows and OS/X.

One  issue I still have is that the transform is only being setup one time and 
it does not change if I move the app to another monitor (with a different 
_ICC_PROFILE atom) or change the atom on the current screen and then reopen 
the document.  I have it setup to get the X11 atom and call the 
setDisplayProfile() wrapper when ever a document is opened.  So I have to 
restart the app to get it to pickup the changed profile.    I removed the "do 
only once" code from setupColorProfiles() but this did not fix the issue.  
Perhaps Koji or someone else more familiar with the code has some idea why 
this is happening.

Also the current version of my X11 atom code may not work on a XRandR 1.2 
machine (IE. using a XRandR 1.2 video driver). I will post patches once I have 
the code cleaned up and I have resolved the only once issue.  I may even take 
a shot at adding some XRandR atom code.  I don't have anyway to test this 
however but if someone had an XRanR 1.2 machine and wants to test this please 
let me know.  The current X11 atom code has been tested on an xinerama machine 
and works other than the once only issue.

I also noticed that setupColorProfiles() is being called from GfxState().  
This is the reason that apps like okular are picking up the default profiles 
and using them.  Watching what it does it appears that user apps only need to 
call setDisplayProfile() to setup the correct output profile as part of 
opening the document and setupColorProfiles() will happen automatically.  Is 
this correct and is this how it should act?  

snip

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

OK I see it now.  The actual logic to use the RGBProfile is on lines 1498 and 
1499.  I didn't see that since it was so isolated from where the main code for 
setting this stuff up is located.  Perhaps this should be located in the area 
around line 305 so that it is near where all of the other code that sets up CM 
is located?  I think this would make it easier to maintain.

One more thing that probably needs to be looked at.  The current code is 
setting up a simple cmsSetErrorHandler() but there is no change being made to 
the cmsErrorAction().   There are a significant number of non-compliant 
profiles in the wild.  Marti Maria (the LCMS author) has told me that he has 
done random samples and perhaps 25% of the existing profiles are in some way 
non-compliant with the ICC standard (none of those were produced with any of 
the open source tools that can produce profiles) and perhaps 1% to 2% will 
cause LCMS to abort because of problems that are bad enough that it can not 
continue (using little endian numbers where the standard calls for big endian 
numbers is not uncommon and can cause lcms to abort).  This means that 
applications opening profiles using lcms will on occasion terminate 
ungracefully unless additional steps beyond calling cmsSetErrorHandler() and 
cmsErrorAction() are taken to prevent this.  The solution is rather ugly but I 
can supply some example code.  It appears that lcms version 2 will be easier 
to deal with in this regard but it will not be available for some time. 

Hal