[poppler] Color Management

[Koji Otani]

From: "Hal V. Engel" <hvengel at astound.net>
Subject: Re: [poppler] Color Management
Date: Mon, 2 Mar 2009 23:50:53 -0800
Message-ID: <200903022350.53720.hvengel at astound.net>

hvengel> On Monday 02 March 2009 02:33:08 am Koji Otani wrote:
hvengel> snip
hvengel> > hvengel> Having taken a look at okular as an example of how applications
hvengel> > are coded I hvengel> see that they are interfacing to poppler through the
hvengel> > API defined in poppler- hvengel> qt4.h perhaps believing that this provides
hvengel> > a complete interface.  Of course hvengel> the API for setting the output
hvengel> > profiles and for setting up the color hvengel> transforms is not exposed in
hvengel> > poppler-qt4.h.  Okular basically does things in hvengel> about the same way
hvengel> > as qt4/demos/poppler_qt4viewer so this appears to be fairly hvengel>
hvengel> > typical of how many apps are/will be coded.
hvengel> > hvengel>
hvengel> >
hvengel> > There are 2 external APIs for poppler. They are Qt4 and Glib.
hvengel> > I mentioned only Glib in the previous mail, but as you wrote, it's
hvengel> > needed to add the API for setting profiles to Qt4.
hvengel> > And it's good to change sample programs to use this API.
hvengel> 
hvengel> I started looking at the Qt4 API since I work mostly in Qt and added wrapper 
hvengel> functions for the CM API to the Qt4 Document class.  This may not be the best 
hvengel> place for this but I am just trying stuff at this point.  But if Koji or 
hvengel> someone else thinks these belong in another location let me know.    I have 

I don't think it's wrong place. I meant that we need to add API to both
Glib and Qt4. It's good that you started on Qt4.

hvengel> also started working on making poppler_qt4viewer color management aware in 
hvengel> that it should be able to use the X11 _ICC_PROFILE atoms if these exist.  I 
hvengel> have a preliminary version of this that is mostly working.    Later on someone 
hvengel> should also add similar code for Windows and OS/X.
hvengel> 
hvengel> One  issue I still have is that the transform is only being setup one time and 
hvengel> it does not change if I move the app to another monitor (with a different 
hvengel> _ICC_PROFILE atom) or change the atom on the current screen and then reopen 
hvengel> the document.  I have it setup to get the X11 atom and call the 
hvengel> setDisplayProfile() wrapper when ever a document is opened.  So I have to 
hvengel> restart the app to get it to pickup the changed profile.    I removed the "do 
hvengel> only once" code from setupColorProfiles() but this did not fix the issue.  
hvengel> Perhaps Koji or someone else more familiar with the code has some idea why 
hvengel> this is happening.
hvengel> 

In current code, RGBProfile, displayProfile, displayPixelType adn
XYZ2DisplayTransform are static member of GfxColorSpace. And only when
these vars are uninitialized, setupColorProfiles initializes them.
So, to change them, if they are initialized, you need to free them and
reinitialize them with other profiles.

hvengel> Also the current version of my X11 atom code may not work on a XRandR 1.2 
hvengel> machine (IE. using a XRandR 1.2 video driver). I will post patches once I have 
hvengel> the code cleaned up and I have resolved the only once issue.  I may even take 
hvengel> a shot at adding some XRandR atom code.  I don't have anyway to test this 
hvengel> however but if someone had an XRanR 1.2 machine and wants to test this please 
hvengel> let me know.  The current X11 atom code has been tested on an xinerama machine 
hvengel> and works other than the once only issue.
hvengel> 
hvengel> I also noticed that setupColorProfiles() is being called from GfxState().  
hvengel> This is the reason that apps like okular are picking up the default profiles 
hvengel> and using them.  Watching what it does it appears that user apps only need to 
hvengel> call setDisplayProfile() to setup the correct output profile as part of 
hvengel> opening the document and setupColorProfiles() will happen automatically.  Is 
hvengel> this correct and is this how it should act?  
hvengel> 

I didn't expect to change output profile dynamically
and I wanted that applications don't need to be changed.
But I understand that output profile need to be change dynamically
and it's needed to fix the code.

hvengel> 
hvengel> > If no display or output profile is specified, current code uses
hvengel> > littele cms's built in sRGB profile.(see GfxState.cc: line 305)
hvengel> 
hvengel> OK I see it now.  The actual logic to use the RGBProfile is on lines 1498 and 
hvengel> 1499.  I didn't see that since it was so isolated from where the main code for 
hvengel> setting this stuff up is located.  Perhaps this should be located in the area 
hvengel> around line 305 so that it is near where all of the other code that sets up CM 
hvengel> is located?  I think this would make it easier to maintain.
hvengel> 

It seems so.

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

-------------
Koji Otani.