[Openicc] Proposed "ucmm" display profile configuration convention used by ArgyllCMS.

[Kai-Uwe Behrmann]

Am 29.05.08, 18:16 +1000 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
 
> > > > For the local system context, the ucmm configuration file is located at:
> > > > 
> > > >        $XDG_CONFIG_DIRS/color.jcnf
> > > > or   /etc/xdg/color.jcnf
> > > > 
> > > > and display profiles are stored in
> > > > 
> > > >        $XDG_DATA_DIRS/color/devices/display/
> > > > or   /usr/local/share/color/devices/display/
> > > > 
> > > > For per user contents, the ucmm configuration file is located at:
> > > > 
> > > >        $XDG_CONFIG_HOME/color.jcnf
> > > > or   $HOME/.config/color.jcnf
> > > > 
> > > > and display profiles are stored in
> > > > 
> > > >        $XDG_DATA_HOME/color/devices/display/
> > > > or   $HOME/.local/share/color/devices/display/
> > 
> > 
> > The above proposed directory layout would be a major shift in what is
> > discussed upon in the OpenICC Directory Proposal. Probably it is not clear
> > enough. The idea is to store all profiles in icc/. 
> 
> Yes, but why ?
> (ie. icc/ is distinguishing what that would otherwise collide ?)

It distinguishes between ICC format and other options. It will increase 
runtime requirements to scan all files contained in such a directory while 
looking just for the ICC format profiles. We currently dont know what kind 
of other data blobs will be there in the future.
 
> > A /usr/local/share/color/icc/device/monitor directory would be inside the
> > directory proposal.
> 
> I'm happy to change "devices" to "device" if that helps things, although
> the plural seems to be more natural. I'm not really sure though whether
> even this is overkill. Perhaps:

Sorry, I dont wanted to say anything about plural or not. "devices" is 
your decission. Just keep icc/ and we have less to change in existing 
implementations.

> /usr/local/share/color/profiles/monitors

s%profiles%icc% appears more consent.

> would be sufficient.
> 
> > http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal#Colour_Profile_Paths
> 
> Yes, but that seems to cover user application profiles (vendor/colorspace etc.
> a user oriented categorization), whereas I'm dealing with system installed
> profiles.

There is already a user/system distingushing in the proposal. 
ECI_RGBv2.icc should appear in a system folder. ???

> I don't really see how vendor and colorspace is a relevant categorization,
> since
> the device association is the important one in this context.

Hmm...

> > Otherwise I am afraid we will get tons of new directories created without
> > meaningfull entry points and Oyranos would have to scan through all the CMM,
> > configuration ... directories to search for profiles, which adds overhead.
> 
> I guess I'm not following you, since it seems to me to be the opposite
> situation, as there are an unknown number of vendors and colorspaces,

I was talking about not to mix CMM and ICC data. But your further point is 
good.

> whereas the different sorts of color devices is much more limited:
> 
> 	monitors
> 	printers
> 	scanners
> 	cameras
> 
> covers just about everything, and could almost be hard coded as a search path.

Well, what applications need to provide are
* colour space conversion profiles (say Rgb -> Lab or Rgb -> Rgb)
* search for abstact type manipulation profiles (sepia, gray ...)
* probably do own device profile listing for manual assigment

With many RGB profiles being marked as monitor, the above scheme is 
already corrupted by most vendors or application maintainers. 
Not shure if Linux/BSD can go to enforce a clear handling again ;-)
So does it make us really happy to put all "mntr" profiles in one 
directory?
Well chances are better to find there a real device profile. But we cant 
be shure and have to take more measures, as it is now.

Would you be more happy to suggest the below scheme (?)
/usr/share/color/icc
   colorspaces/
       vendor/
           vendor_rgb.icc
   printers/
       vendor/
           vendor_fogra27.icc
           vendor_fogra28.icc

and in general go with ICC section 7.2.5 ?

> > > > The monitor to ICC profile association is organized as independent
> > > > records, having the form:
> > > > 
> > > >    key                                value
> > > > 
> > > >    devices/display/N/EDID             Monitor EDID  in upper case
> > > >    Hexadecimal
> > > >    devices/display/N/ICC_PROFILE      Full path to the associated ICC
> > > >    profile
> > > > 
> > > > or
> > > > 
> > > >    devices/display/N/NAME             X11 display name
> > > >    devices/display/N/ICC_PROFILE      Full path to the associated ICC
> > > >    profile
> > 
> > 
> > Can then be just one ICC_PROFILE key in devices/display/N to signal which
> > profile the record belongs to? So you can add NAME and EDID inside one
> > record.
> 
> In principle, yes, that's why I organized it this way (as opposed to
> indexing by a hash of the EDID for instance), but in practice it turned
> out to be one or the other (ie. I couldn't come up with a situation
> that would actually use both).

... a administrator with 12 monitors in a similiar setup, where some EDIDs 
appear flacky would probably be happy to see the EDIDs correctly connected 
with profiles and has some means to assign the others as well. Geometry is 
thought as a fallback in this case.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org