[Openicc] Re: common ICC profile directory

[Kai-Uwe Behrmann]

comments see below ...

Am 24.02.05, 14:47 +1100 schrieb Graeme Gill:

> Someone emailed me about a standard Linux location for ICC profiles,
> and I decided to research this a little more than has been done in
> the past, so though others might be interested in the results.
> 
> > I was wondering if you are aware of any standard location in the Linux
> > filesystem to put ICC profiles?
> 
> There was some discussion about this on the OpenICC mailing list a while
> back:
> 
> Stefan Klein wrote:
> > Marti Maria, developer of littlecms (www.littlecms.com), suggested
> > /usr/share/color/icc and ~/.color/icc as intuitive paths. We decided to
> > go along with this.
> 
> Kai-Uwe Behrmann wrote:
> > I followed the suggestions of using
> > /usr/share/color           for global configuration data and
> > /usr/share/color/icc       for global ICC profiles
> > ~/.color and ~/.color/icc  as user pendant.
> 
> Googling for "common Linux ICC profile directory" brings up other references.
> 
> For instance Scribus puts its profiles in
> 
> 	/usr/local/share/Scribus/profiles
> 
> 
> SUN has been implementing CMM's on its Solaris system
> for a long while (using Kodaks KCMS), and have already
> established other conventions in its part of the the Unix world:
> > 1. The current directory
> > 2. Directories listed by the KCMS_PROFILES environment variable, which
> > is a
> > colon-separated list of directories
> > 3. /etc/openwin/devdata/profiles
> > 4. /usr/openwin/etc/devdata/profiles
> as well as having extensive support for ICC profiles in Java, on multiple
> platforms (again using KCMS and the native platform CMM's it seems).

... is to close to an platform 
 
> SGI has a CMM called Coloratura on their IRIX Unix system, and uses
> yet another convention:
> > The Coloratura CMS searches for a file sequentially in the directories
> > specified
> > by the environment variable CMS_DEFAULT_PATH, which is a colon-separated
> > list of
> > pathnames similar to that used in the environment variable MANPATH.
> > The value of CMS_DEFAULT_PATH defined in cms.h is
> > “/var/cms/profiles/local:/var/cms/profiles:.”,
> > which allows you to place profiles you prefer in
> > /var/cms/profiles/local,
> > and generic profiles, which might have the same names, in
> > /var/cms/profiles or your working directory.

Seems reasonable. Except there is no user directory. Seems the IRIX CMS 
takes full control, not allowing user wide settings. The current directory 
is not adequate for this issue.
 
> Apple in OSX (another Unix based system) chooses
> 
> /Library/ColorSync/Profile
> /System/Library/Colorsync/Profiles
> /Network/Library/ColorSync/Profiles
> ~/Library/ColorSync/Profiles

... too specific to mac conventions.

> and individual drivers store relevant profiles in their application
> resources: eg.
> 
> 	/Library/Image Capture/Devices/EPSON SScanner.app/Contents/Resources/
> and
> 	/Library/Printers/Canon/BJPrinter/PMs/BJC8200PM.plugin/Contents/Resources/
> and
> 	/Library/Printers/hp/Profiles
> and many other places.
> 
> Microsoft Windows chooses:
> 
> \WINDOWS\SYSTEM\COLOR
> \WINNT\SYSTEM32\COLOR
> \WINNT\SYSTEM32\SPOOL\DRIVERS\COLOR

as above

> depending on the operating system version.
> Photoshop on MSWindows seems to use its own location:
> 
> \Program Files\Common Files\Adobe\Color\Profiles

Well, Photoshop seems to use an autonome aproach, as I heared from user 
comments.

> Note that Apple ColorSync, Microsoft ICM2.0 and KCMS as implemented
> by SUN are all existing CMM's with detailed technical documentation
> available via the web (as examples of how it has been done, and the variety
> of facilities a CMM may make available.)

I looked at the 2. osX standard only. Does You think it is possible to 
simply copy one of the existent APIs? Would be nice to simplify 
programming effort.

There are two options to design an API for an open source CMS
(I use the term CMS here in the manner of an system level coordinator):

 1. new API, with (possibly) further compatibility to other OS of choice

 2. copy an API and bound as most as possible to standards of this OS


The first is running solely on linux / BSD ...
and additional an topping layer for open source applications on other 
OSes.

The second targets to make porting of existing applications mostly 
trivial. Unix like environment prefered. This could be an way to go in 
agreement with the requested OS company.

> Graeme Gill.
> 

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name