[Openicc] ICC Profiles in X Specification 0.4

[Kai-Uwe Behrmann]

Am 24.03.10, 09:23 +1100 schrieb Graeme Gill:
> Richard Hughes wrote:
>> I'm looking at the following page:
>> http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4
>> 
>> Now, my understanding is, we now should be setting the indexed
>> _ICC_DEVICE_PROFILE_xxx atom for the device output space, and ALSO the
>> _ICC_PROFILE_xx for the document space. This seems a little crazy.

The _ICC_DEVICE_PROFILE(_xxx) is only to be set by a colour server. I 
think this is clearly stated in the draft [1]. No setup tool must care 
about _ICC_DEVICE_PROFILE(_xxx). _ICC_DEVICE_PROFILE(_xxx) is written by 
the colour server at its start time and interpreted by net-color spec 
aware applications only.

> Hello Kai-Uwe,
> 	nice to meet you again, in Germany this time!

Hello Graeme,

it was fun to see you and enjoy your presentation.

> I agree with Richard. In regard to XRandR, either a consistent
> index needs to be assigned/determined for each output, or if this is
> not possible (and Richard makes the case that it is not), this approach
> should not be used for XRandR based multiple displays.

However I think we would add already complexity by using the per output 
atom as the spec has already the per root window ones. 
The initial ICC in X spec had no idea about several use cases. So we need 
to add extra complexity to support some of the newer use cases, while 
keeping things backward compatible. I am quite positive about adding 
necessary complexity as it is a evolving spec. What I try is keeping the 
changes as minimal as possible. I see adding XRandR at the moment as
redundant, when we need root atoms anyway in the spec.

> In my opinion, having the _ICC_PROFILE property in each XRandR output
> is the preferred approach. _ICC_DEVICE_PROFILE_xxx should only be used
> as an (unreliable) fall back for older applications in the case of XRandR.

Again, we do not create a spec from scratch. The 0.1 version is already 
widely adopted and used. I guess the following versions are as well. So if 
we break existing applications, user will blame us. And IMHO they would 
be right in doing so.

> I don't understand what _ICC_DEVICE_PROFILE is for. _ICC_PROFILE holds
> the (display) device (destination) profile already. What is "Xcolor library" 
> ?
> I'm finding this whole section very hard to interpret, and I'm struggling to 
> make
> sense of it. Nothing except a profiling application (or initial system
> start property restoration from non-volatile storage) should be changing
> the _ICC_PROFILE atoms (it would be highly unusual for an _ICC_PROFILE
> to be set to sRGB, since few displays behave exactly like sRGB!).
> I understood that _ICC_PROFILE, _ICC_PROFILE_xx (for Xinerama) and per
> output _ICC_PROFILE (for XRandR) represent the characterisation of the
> display device, and should only change when it is re-characterised or
> known to have changed characteristic (for those high end displays that
> can switch emulations). Graphics rendering systems use the 
> _ICC_DEVICE_PROFILE
> property to determine the current output (destination) device characteristic
> for an output region.

The net_color spec introduces the idea of a colour server. The colour 
server needs some means to correct from a source colour space to a 
destination as usual. It searches for per window (source areas) regions 
and corrects in my implementation all undescribed areas. Typical non 
net-color spec aware applications do not describe any region to be colour 
corrected. So the colour server can not differenciate what is already 
corrected, and should not be touched, and what can be corrected. The 
colour server places some reasonable colour space into the 
_ICC_PROFILE atom(s). This is the display document or blending colour 
space. Old standard applications will see that profile and correct to 
that. This avoids any double correction conflict with the colour server at 
the price of having no description of the real device capabilities. The 
real device colour profile is moved into _ICC_DEVICE_PROFILE by the colour 
server at run time. Apps supporting the per window region communication 
can use that _ICC_DEVICE_PROFILE atom(s). As said before the 
_ICC_DEVICE_PROFILE atom(s) are for backward compatibility with non 
net-color spec aware apps. The net-color spec can be obtained from here 
[2].


I think it is possible to detect _ICC_PROFILE atom changes in the colour 
server and adjust the exchange with _ICC_DEVICE_PROFILE therein. So 
profilers must not write _ICC_DEVICE_PROFILE atom(s). They shold write the 
_ICC_PROFILE atom(s) as usual.
But to get a uncorrected window the profilers colour patch area on screen 
must be marked with a colour region atom attached to the window. This is 
described in the net-color spec. I will try to get that later text 
completed and the according helper library published.

> What the source profile is, is very dependent on what graphic rendering
> system is being used, and therefore belongs in a different document,
> or in a completely separate section (one section per rendering
> system).
>
> I don't see that _ICC_PROFILE_SETUP_LOCK and _ICC_PROFILE_SETUP are a
> practical necessity, and add complexity. Any X client can already get 
> notifications
> of property changes (at least in theory - implementation lags), so there is 
> no need
> for them for that reason. Since _ICC_PROFILE properties are rarely changed, 
> and
> typically only at system start or at the users explicit request, I don't 
> think there
> is currently a case for these *_SETUP properties. ( In any case, I don't 
> think it
> has been thought out properly - a PID is unique only on a single system. 
> Multiple
> systems may be accessing an X server, so different clients may have the same 
> PID, etc.)

Agreed, these two later atoms are not much thought out. Perhaps colour 
servers can communicate switching just by property notification of the 
_NET_COLOR_DESKTOP atom containing the new colour servers pid. That later 
atom can be interpreted that a colour server wants to take over the 
service. This would obsolete the _ICC_PROFILE_SETUP* atoms sections.


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


[1] http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4#_ICC_DEVICE_PROFILE
[2] git clone git://www.oyranos.org/git/xcolor