[poppler] Color Management

Koji Otani sho at bbr.jp
Fri Feb 27 02:06:05 PST 2009


Hi

Thank you for your comments.

First, poppler is a library. So, applications using poppler should be
responsible for location of profiles, I think.
Applications (not poppler) can know 
on which device output is displayed and which
profile is appropriate one.

I think that what we should do next about this is to add some 
API (that set location of profiles) to the poppler external API (glib API).

Though current code looks /usr/share/poppler/ColorProfiles/display.icc
 and  ~/.xpdf/ColorProfiles/display.icc, this is only default behavior.
It seems OK to change these default to other files 
such as /usr/share/color/icc/poppler.icc and ~/.color/icc/poppler.icc.

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


From: "Hal V. Engel" <hvengel at astound.net>
Subject: [poppler] Color Management
Date: Thu, 26 Feb 2009 15:29:11 -0800
Message-ID: <200902261529.14470.hvengel at astound.net>

hvengel> I have been using the Color Management patches that Koji Otani posted to this 
hvengel> list in Dec since that time.  And after these were merged into git trunk I 
hvengel> have been using git head.  These are a significant step forward and I would 
hvengel> like to thank Koji for his hard work and Albert for taking the time to review 
hvengel> the patch set and getting it committed.  This is a significant step forward 
hvengel> although it will take more work to get this in a fully working condition.
hvengel> 
hvengel> One issue is how display profiles are currently selected (or actually not 
hvengel> selected is more correct).
hvengel> 
hvengel> In a follow up note on Dec. 14 James Cloos wrote:
hvengel> 
hvengel> "I've only tested with a few alternate display profiles.  Nothing broke,
hvengel> but I havn't been able to tell that a different profile was in use."
hvengel> 
hvengel> The reason that James didn't notice different display profiles making a 
hvengel> difference is that the current code does not correctly pick up changes to the 
hvengel> display profile settings in X11 and it does not use the X11 _ICC_PROFILE atom.  
hvengel> 
hvengel> In addition there are other issues with the code related to locating profiles 
hvengel> as well.  
hvengel> 
hvengel> Having had a look at the code let me make some comments related to these 
hvengel> issues. 
hvengel> 
hvengel> 1. Where to look for profiles on a *nix system.
hvengel> 
hvengel> As early as May 2004 OpenICC had a proposal to use /usr/share/color/icc and 
hvengel> ~/.color/icc for system and user ICC profile directories.  This later became a 
hvengel> formal standards proposal and that has been through a number of revisions.  
hvengel> This link
hvengel> 
hvengel>  http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal
hvengel> 
hvengel> has the latest version of the proposed standard which is an extension of the 
hvengel> widely used XDG base directory specification.  This standard may be subject to 
hvengel> more revisions but it is considered the working standard for where ICC 
hvengel> profiles should be located on *nix machines and is now fairly stable.
hvengel> 
hvengel> 2. X11 display profiles.
hvengel> 
hvengel> X11 has had a _ICC_PROFILE atom for some time now.  This is based on a draft 
hvengel> specification that came out of the OpenICC group in 2005 which can be found 
hvengel> here:
hvengel> 
hvengel> http://www.burtonini.com/computing/x-icc-profiles-spec-0.1.html
hvengel> 
hvengel> This draft had issues with some multi monitor setups and was later revised but 
hvengel> I can't find the revisions on-line right now.  But I do have a copy of a note 
hvengel> to the OpenICC list that summarizes those changes.
hvengel> 
hvengel> "Remove: ?Currently there is only one atom defined.
hvengel> and: ? ? ?The _ICC_PROFILE atom is set on the root window for each screen.
hvengel> 
hvengel> 
hvengel> And add:
hvengel> 
hvengel> The atom name for the first screen in a root window is _ICC_Profile. 
hvengel> 
hvengel> For root windows spanning more than one screen, as typical in Xinerama 
hvengel> multihead configurations, a atom for each screen is added holding the 
hvengel> appropriate ICC profile. All screens in a root window starting from 
hvengel> number one use _ICC_Profile as atom name extended with an underscore plus 
hvengel> the screen number, e.g. _ICC_Profile_1 .
hvengel> 
hvengel> followed by your text:
hvengel> 
hvengel> The atoms are of type XA_CARDINAL with 8-bit elements. The value of the 
hvengel> atoms should be a literal ICC profile, that applications can read and 
hvengel> parse directly." 
hvengel> 
hvengel> I know the updated specification was published somewhere but I can locate it 
hvengel> at this time.
hvengel> 
hvengel> So how is this used?
hvengel> 
hvengel> Here is a snippet of code that shows how this might be done using GTK+ (I 
hvengel> think this was pulled out of the GIMP code base around 6-2005):
hvengel> 
hvengel> static cmsHPROFILE *
hvengel> get_screen_profile (GdkScreen *screen)
hvengel> {
hvengel>        Display *dpy;
hvengel>        Atom icc_atom, type;
hvengel>        int format;
hvengel>        gulong nitems;
hvengel>        gulong bytes_after;
hvengel>        guchar *str;
hvengel>        int result;
hvengel>        cmsHPROFILE *profile;
hvengel> 
hvengel>        g_return_val_if_fail (screen != NULL, NULL);
hvengel> 
hvengel>        dpy = GDK_DISPLAY_XDISPLAY (gdk_screen_get_display (screen));
hvengel>        icc_atom = gdk_x11_get_xatom_by_name_for_display gdk_screen_get_display 
hvengel> (screen), "_ICC_PROFILE");
hvengel> 
hvengel>        result = XGetWindowProperty (dpy, GDK_WINDOW_XID 	
hvengel> 				    (gdk_screen_get_root_window (screen)),
hvengel>                                     icc_atom, 0, G_MAXLONG,
hvengel>                                     False, XA_CARDINAL, &type, &format, 
hvengel> 				    &nitems, &bytes_after, (guchar **)&str);
hvengel> 
hvengel>        if (nitems) {
hvengel>                profile = cmsOpenProfileFromMem(str, nitems);
hvengel>                XFree (str);
hvengel>                return profile;
hvengel>        } else {
hvengel>                g_printerr("No profile, not correcting\n");
hvengel>                return NULL;
hvengel>        }
hvengel> } 
hvengel> 
hvengel> For those using the Qt widget set I found this piece of untested but plausible 
hvengel> code (this was posted to the kde-core-devel list by Lubos Lunak):
hvengel> 
hvengel> static cmsHPROFILE *
hvengel> get_screen_profile (int screen)
hvengel> {
hvengel>        Display *dpy;
hvengel>        Atom icc_atom, type;
hvengel>        int format;
hvengel>        long nitems;
hvengel>        long bytes_after;
hvengel>        unsigned char *str;
hvengel>        int result;
hvengel>        cmsHPROFILE *profile = NULL;
hvengel> 
hvengel>        static Atom icc_atom = XInternAtom( qt_xdisplay(), "_ICC_PROFILE", 
hvengel> False );
hvengel> 
hvengel>        if ( XGetWindowProperty ( qt_xdisplay(), qt_xrootwin( screen ), 
hvengel>                                               icc_atom, 0, INT_MAX, False,
hvengel>                                               XA_CARDINAL, &type, &format, 
hvengel>                                              &nitems, &bytes_after, 
hvengel>                                               (unsigned char **)&str)) {
hvengel> 	if( nitems ) {
hvengel>                profile = cmsOpenProfileFromMem(str, nitems);
hvengel>                XFree (str);
hvengel>                return profile;
hvengel>        } else {
hvengel>                kdDebug() << "No profile, not correcting" << endl;
hvengel>                return NULL;
hvengel>        }
hvengel> }
hvengel> 
hvengel> Using the X11 _ICC_PROFILE atom(s) will fix the issue that James was seeing.  
hvengel> But the code also needs to be updated to search for profiles in the correct 
hvengel> locations.  In addition it should allow user programs to override using the 
hvengel> _ICC_PROFILE X11 atom. 
hvengel> 
hvengel> Hal
hvengel>  
hvengel> 
hvengel> 
hvengel> _______________________________________________
hvengel> poppler mailing list
hvengel> poppler at lists.freedesktop.org
hvengel> http://lists.freedesktop.org/mailman/listinfo/poppler


More information about the poppler mailing list