[Openicc] ICC Profiles in X Specification 0.4

[Kai-Uwe Behrmann]

Am 25.03.10, 10:02 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
>> Am 24.03.10, 09:23 +1100 schrieb Graeme Gill:
>
>> 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 see how any existing applications can be using ICC_PROFILE_xxx,
> if it doesn't work reliably. Using the output property in XRandR

I use Xinerama APIs on a daily basis. They work relyable. The indexing 
of ICC_PROFILE(_xxx) must follow the Xinerama API. It should be 
explicitely described in the next spec version. Thats all.

> is the natural and reliable approach. Any other approach is difficult
> and unreliable to implement, and we should be trying to straighten things 
> out.

Xinerama was the natural way some time ago. That most of new features go 
into the object oriented XRandR approach has nothing to do with current 
requirements for a colour managed desktop.

> I don't see any problems in recommending that XRandR output _ICC_PROFILE
> be used as well as ICC_PROFILE_xxx on the root display. Ultimately
> we should then deprecate the ICC_PROFILE_xxx approach.
>
> [Argyll will continue to work this way.]
>
>>> I don't understand what _ICC_DEVICE_PROFILE is for. _ICC_PROFILE holds
>>> the (display) device (destination) profile already. 
>
>> 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). 
>
> I see many problems with this. Why is the _source_ colorspace described
> by the _destination_ ? The source colorspace should be described by some
> resource associated with the source object (ie. window, graphic, etc.)
> 
> Why is the property that describes the destination space being altered
> by an application/server that is concerned with the source colorspace ?
> It shouldn't be touching it.
> 
>> 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. 
>
> Sorry, this seems like a really horrible hack to me. Any such color transform

The original _ICC_PROFILE spec misses several use cases. We should correct 
that.

> facility should _not_ be changing fundamental information about the device,
> and overturning the assumptions of many established tools and software.

Which kind of software could break through a altered _ICC_PROFILE atom in 
a colour managed server?

> Instead it should be a resource made available to the higher level rendering
> libraries, and coordinated at that level. The rendering libraries & systems

This implies to me to deprecate _ICC_PROFILE and move device informations 
into _ICC_DEVICE_PROFILE. Thus apps can be explicite together with the 
net-color spec.
The _ICC_PROFILE is then there for backward compatibility only and free to 
be altered by the colour server.

> will/should have their own way of gathering the source colorspace 
> information,
> or falling back to some default source space. Adding extra "magic" layers of
> hidden color management is generally a really bad idea. It creates
> difficult problems when things don't work.

Yes, you are right. A straight forward written spec is very valuable.

> (Apple discovered this the hard way recently. They changed their
> printer driver so as to impose a default source colorspace for
> untagged sources, and guess what - they broke most of the
> profiling applications. It's only taken about 6-9 months for
> them to straighten it out, and only by all the printer manufacturers
> supplying new printer drivers.)
>
> So in summary, I have currently have great reservations about the
> "net_color spec" approach, and don't think it should be proceeded with
> without a very much wider consensus, that it is the best technical direction.

The net-color spec itself is pretty indifferent. What we need to discuss 
here is how to integrate with the ICC in X spec.


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