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

[Kai-Uwe Behrmann]

Am 23.04.08, 13:47 +1000 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> 
> > 0.3 was not yet commited. I have given a detailed change log for 0.3 at 
> > the from me mentioned www adress. I dont think these changes make 0.2 
> > currently obsolete.
> 
> I notice that there is some inconsistency in this draft.
> Is it _ICC_PROFILE or _ICC_Profile ? Note that property names
> are case sensitive in X11, so this is important. (I've assumed
> all upper case in my implementation).

Agreed and in 0.2 too. It is fixed in the 0.3 draft.
 
> It would be good if there was some discussion/justification
> with regard to the _ICC_PROFILE_IN_X_VERSION property. What
> function is it meant to serve ?

It was suggested to further avoid ambiguities, like the 0.1 versus 0.2 
multi monitor atoms. I found a suggestion on list, but no discussion.

References for the 0.3 draft can be found here:
http://www.oyranos.org/wiki/index.php?title=Oyranos/X11_Requirements#Further_Tasks

> > 0.3 would still be open for XRandR, who ever writes it.
> 
> The basic idea is simple - there should be an _ICC_PROFILE in
> the XRandR 1.2 output object that corresponds with the connected monitor.

Graeme or Ross,
can you turn this into a final text form to include it in the draft?

> That's what the next version of dispwin will do.
> 
> >>I'm, not sure yet. It seems a bit more complicated than it really needs to
> >>be though.
> 
> > Comments are welcome, just a bit more detail is required to understand 
> > you.
> 
> It would be useful if there was a justification for the multi directory
> per user locations. Why is $HOME/.local/share/color  better than
> $HOME/.color ?
> 
> Why should there be then (yet another) sub directory icc ?

According to the referenced XDG specification these directories follow a 
different layout, than the previously on this list discussed ~/.color 
/usr/share/color one.
Your question would probably better fit on the XDG mailing list, as it is 
the source for this pattern, which the OpenICC proposal simply follows.

As a matter of taste, $HOME/.local/share/color is not what I like much.
Even though it may have practical implications, the depth is too high.

> This doesn't seem to be explained in the documents.
> 
> I'm not sure that the vendor/colorspace subdirectories are
> at all useful for installed device associated profiles. Little

They can be used. There is no must:
http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal#Subdirectory_naming_rules
As I read you, the faculty of subdirectories could be more explicitely 
... done

> or no such organization is actually necessary, and it raises

We had one vendor, which I tried to guide with this suggestion. More 
vendors to follow this rout  is prepared by the example given in the 
proposal.

> complexity without there being any justification yet. The
> vendor/colorspace organization may be useful for users storing
> profiles that they want to select in applications, but I would
> think that the organization could be just a suggestions.

We are on one line with that.

> By the time you're at
> 
> 	~/.local/share/color/icc/vendor/cmyk/profile.icm
> or	~/.local/share/color/icc/installed/argyll/profile.icm

I would not use this for casual device profiles. In case you consider 
providing a set of standard profiles, this might by an option.

> I'm wondering if it's a bit ridiculous ?

We are on Linux/BSD not that far with installing a bunch of profiles from 
a vendor CD. On other systems hundreds of profiles in a flat hierarchy has 
been proven a burden. For a user it is relatively difficult to decide 
what can be moved around and what not. The profile paths can be made 
transparent in a CM configuration panel for pure information.
 
> The exact location isn't that important, it's the device
> identification and association that's important, since
> this will point to the profile location.

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