From: "Hal V. Engel" <[email protected]> Subject: Re: [poppler] Color Management Date: Mon, 2 Mar 2009 23:50:53 -0800 Message-ID: <[email protected]>
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. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
