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

[Graeme Gill]

Kai-Uwe Behrmann wrote:

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

I understand, but I'm thinking this is not justified. There is no prospect
over foreseeable time frames (ie. 3-4 years) of ICC being usurped by
anything else, and even Microsoft have simply mixed their WCS profiles
in with all their ICC profiles in a single directory in Vista. If there
is a need that arises in the future, it's simple enough to add another
distinguishing top level directory (ie, "color2" etc.), or a sub directory.

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

I'm thinking that "profiles" is more user friendly, since it's generic
rather than being technology specific, which requires more detailed technical
knowledge to recognize.

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

Maybe I'm being mislead by the one example given, and haven't fully grasped
all the combinations possible from 'editing' 'device' 'camera' 'scanner' 'monitor'
'printer' 'output' 'input' 'abstract' 'named_color_list' 'colorspace' 'file' 'standard'.

I'm not so sure about the whole idea through. The above list seems to be largely
taken from ICC profile attributes, and the way other CMM's work (and the way I
am presuming it was intended) is that these attributes are in the ICC profile
so that the profiles can be stored in one directory, and the CMM can
then distinguish them :- ie. the very intention was to avoid the need for putting
profile in separate directories. The assumption I think is that
since the CMM is intended to be used to install and enumerate profiles,
that it will cache the profile information, and keep it up to date
using file change notifications in the face of other agents changing things.
The typical CMM API's allow the applications to search/sort/filter the
profiles, so that the user can be presented with manageable lists.

That's certainly the path MSWindows and ColorSync have taken. ColorSync has gone
for some structure in actual directory layout, but that isn't visible to the
users. Since you seemed to have gone down the path of having sub-directories rather
than a single directory, I was suggesting schemes similar to the ColorSync one.

As for user/system, for system device profiles that's the scope of the setting,
not the nature of the device/profile. i.e. system wide scope settings go in system,
user scope settings go in a users home directory, at least as far as system device
profiles go.

I think there is a case for two trees here, although there is some overlap.
One is system device installed profiles. They don't need to be finely categorized,
because it's just automated systems that have to access them most of the time.
The other is user application profiles, in which a good deal of flexibility as to
the categorization is probably a good thing, since it's a UI issue. Whether
the categorization is done with directories is a point for debate however,
and certainly the case is made in existing CMM's for doing this with
other mechanisms than directories.

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

Some users might regard it as a feature, since then there is less
chance of a profile getting lost in some other 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 ?

I don't see the above as at all suitable for system device profiles,
and only of potential interest to user profiles.
The vendor is irrelevant, as is the colorspace. All that's
of interest is what device it's associated with.

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

Well, it would be disconcerting if the EDID is:

	Identical between different monitors
	Unstable (changes each time it's read).
	Appears and disappears.

Is this known to be the case ?

If so, falling back to the X11 display/screen seems to be a reasonable
alternative. I'm not sure how you could use geometry, as I though such
information comes from the EDID.

cheers,

Graeme Gill.