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

[Kai-Uwe Behrmann]

Am 02.06.08, 16:40 +1000 schrieb 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.

The proposal for the ~/.color/icc and /usr/[local/]share/color/icc 
directories appeared quite some time ago:
http://bugs.freestandards.org/show_bug.cgi?id=77
http://lists.freedesktop.org/archives/openicc/2005q4/000636.html

The OpenIccDirectoryProposal is as stated on the very top a write down of 
previous discussion on this list. It comes not out of the blue.

Deprecating ~/.color/icc disturbs me already, but it is justified in my 
eyes by the XDG convention. The changes you, Graeme, propose now are 
touching the top structures of all remaining profile paths, namely 
/usr/[local/]share/color/icc.
This is the specific point, which makes me unlikely to support a change 
where /usr/[local/]share/color/icc is substituted by 
/usr/[local/]share/color/profiles, or whatever one chooses for "profiles" 
and holding the same content. I know profile packages, toolkits and 
applications working with the paths from 2005.

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

In my opinion it is already too late for such a change, see my above 
comment.

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

The current OpenIccDirectoryProposal just reserves these names. There is 
no scheme implied so far.

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

You can continue to place all profiles in the top ICC profile directories.

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

The subdirectories started just on request. I will remove the subdirectory 
subsection
http://www.oyranos.org/wiki/index.php?title=OpenIccDirectoryProposal#Subdirectory_naming_rules
from the proposal. From your reading I take, the emphasis through 
the heading and the provided example is at best confusing.

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

agreed

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

I have a LCD which's EDID dissappeared after a xorg version change.

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

Oh, I meant the Xinerama geometries. It is one of the few and of course 
even not very constant properties to identify monitors.

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