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

[Graeme Gill]

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're missing the:

   3) Where (and how) to store the profile to monitor association

> 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.

It matters because various utilities and programs would like to be able to
brows the profiles. On systems with CMM's (ie. MSWindows and OS X) the
CMM actually takes care of providing the locations of the profiles
or enumerating the available profiles for applications.

> 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. 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).

Right, but X11 doesn't have the concept of persistent properties. So
the profiles have to be stored on a real computer system. Effectively
one computer system has to act as the manager for the X11 server.
It needs to have a persistent copy of the profile, and be able to
load the appropriate profile into the X11 server property, so that
remote clients can access it. Ideally it should do this whenever the
monitor changes or appears.

> 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. 

If there were an established CMM to work with, yes. But there isn't,
so an interim, prototype systems is more likely.

> See it this way: a xserver will always have the same display devices 
> attached (modulo notebooks), 

People can (and) do unplug and plug different monitors and display
devices. The profile should follow the device instance if possible.

> Does Windows/MacOS distinguish between color profiles and device 
> profiles? IMHO it makes little sense to put a display device profile 
> into a shared directory, since it's used only for that one particular 
> device.

What do you mean by "color profiles" ? A color profile is a superset
of device profiles. (ie. Device, Device link, abstract, colorspace, named etc.)

It makes perfect sense when there are make/model specific profiles.
Typically this is what a manufacturer will supply.
Even if there is an instance specific profile, it may make sense
to share this to other instances of the same make/model.
You can't assume all or nothing, people will profile some devices,
and then cover everything else with what is closest.

> Instead if stored in a local directory accessible by the 
> xserver, it could be loaded when the xserver starts and the session 
> script wouldn't have to worry about loading the correct profile.

Right, which is where the discussion started.

Graeme Gill.