[Openicc] ICC Profiles in X Specification 0.4

[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
is the natural and reliable approach. Any other approach is difficult
and unreliable to implement, and we should be trying to straighten things out.

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
facility should _not_ be changing fundamental information about the device,
and overturning the assumptions of many established tools and software.
Instead it should be a resource made available to the higher level rendering
libraries, and coordinated at that level. The rendering libraries & systems
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.

(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.
	
regards,

Graeme Gill.