[Openicc] Profile installation and association for Linux/Unix/X11

[Hal V. Engel]

On Monday 21 April 2008 12:22:05 Tomas Carnecky wrote:
> This whole discussion can be split up into two questions:
>
> 1) Where to store the profiles
> 2) Who is responsible for setting the _ICC_PROFILE property

You missed one.  Where is the configuration information that is needed to manage the "loading" of profiles stored and how is that configuration data managed?  This might be part #2 but since this same question applies to other devices like printers, scanners and cameras I don't think that is the case since #2 is display device specific.

>
> To the first question. Where in the filesystem the files are stored
> doesn't really matter, as long as the location is agreed upon and
> captured in a specification. But you have to keep one important thing in
> mind: the network transparency of X11, which is far more widespread in
> the *nix domain then on Windows or MacOS. Due to the network
> transparency it's impossible to predict on which host applications will
> be running. It may be the same computer as the xserver is on, but it
> also may be some remote computer. Applications from many different
> computers can connect to one xserver and that is quite common. If the
> profiles are stored in some directory in the filesystem, you risk having 
> applications see a different set of profiles. 

This is correct if by this you mean the file system of the host running the application (IE. the xclient) if it is not the same machine that is running the xserver.  

> The only place that is  
> common to all X clients is the xserver. If you want all clients to have
> a consistent view of available profiles, then registering them in the
> xserver is the only solution (I will probably have to do something like
> that for my GSoC project).

I am not sure what you mean by registering them in the xserver?

>
> To the second question. Obviously the xserver itself has the most
> informations about which display devices are attached to it. So it would
> be again preferable if the xserver managed the _ICC_PROFILE property.
> See it this way: a xserver will always have the same display devices
> attached (modulo notebooks), 

Well sort of but RandR 1.2 supports hot plugging so it is possible that the xserver could have devices change dynamically for example by plugging a new monitor into a machine running an xserver.  So going forward that is the general case (IE. one or more monitors per xserver that can change at runtime).  Clearly the xserver is what knows about the devices although it is my understanding that with RandR 1.2 user mode apps can somehow register to receive notifications of changes to the display configuration so it should be possible to handle this from a user mode app with no additional code in xorg.  But I may be wrong about how these notifications work.  Anyone know more about this?

> a session is more likely run on different 
> devices/xservers. In a large networked environment, the session would
> have to manage a big database of display device/profile mappings,
> whereas each xserver would only require one or two profiles for its
> display devices.

Maybe more than one or two but more correctly one for each display device that might be connected to the xserver.  Which in most cases will be one or two but for some machines might be a larger number (a laptop that is used with projectors and multiple external monitors).  But in any case a fairly small number of display profiles.

>
> Does Windows/MacOS distinguish between color profiles and device
> profiles? 

There is no distinction made anywhere.  Some profiles are for an abstract non-existant device, for example sRGB or AdobeRGB.  But the profiles we are talking about are always for a specific device or at the very least for a specific model of a device. 

> IMHO it makes little sense to put a display device profile 
> into a shared directory,

I assume you mean a shared directory on the application host (xclient) and not a shared directory on the xserver machine.

> since it's used only for that one particular
> device. Instead if stored in a local directory accessible by the
> xserver, 

This is exactly the point I was trying to make.

> it could be loaded when the xserver starts 

This would be ideal but it also implies that the xserver knows how to do this and there has been significant resistance on the part of the xorg folks to adding this type of functionality to the xserver.  Part of the resistance I think is that it would not be that difficult to create a set of user space applications and connect them up to the xserver (IE. register them to get display hot plug notifications) to handle this.  But "loading" the profiles at server start up is only part of the problem since we need to "load" and "unload" profiles as displays are plugged and unplugged.

> and the session  
> script wouldn't have to worry about loading the correct profile.

To be clear what "loading" a profile means for monitors there are two parts to this.  First if there is VCGT tag data a gamma loader needs to run and load the gamma table for the device and second the _ICC_PROFILE atom for the device must be loaded with the data from the profile.

As a side note I have come to like the ArgyllCMS style cal files for doing gamma table loading since using them cleanly separates the video card gamma tables (calibration data) from the profile and makes maintaining these easier.  I would perfer any system that is put in place to allow for the use of that type of setup.  That is the configuration information for display devices would include both a profile file name and a calibration file name for each display device.  If the profile VCGT is to be used for gamma loading the configuration would simply use the profile file name for the calibration file. 


>
> I saw that there are still free slots in the LGM conference schedule. I
> could write a few slides about my GSoC project and outline some of the
> things that I'm planing to work on. Some of it would also partially
> cover the things that came up in this thread here...
>
> tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20080421/b0bcd4bd/attachment.html