[Openicc] ICC Profiles in X Specification 0.4

[Kai-Uwe Behrmann]

Am 25.03.10, 09:27 -0000 schrieb Richard Hughes:
> On 25 March 2010 08:48, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> 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.
>
> I don't use Xinerama, as it's deprecated. Please read
> http://en.wikipedia.org/wiki/Xinerama -- it's insane to base a new
> spec on an obsolete technology.

I still refere to the client side API, which the wiki does not talk about.

>> The original _ICC_PROFILE spec misses several use cases. We should correct
>> that.
>
> Has anybody actually written down those use cases?

* multi monitor support and its relation to Xinerama/XRandR
* server side colour management
* colour space tagging of window regions

... add your favourits.

>> 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.
>
> If _ICC_DEVICE_PROFILE was moved to a XRandR property, that would make
> sense. It's already way too difficult for applications to know "what's
> the output ICC profile for this window". I'm currently providing a
> simple DBus server to get this kind of information easily if an
> application wants to do early color binding. In that way, applications
> get a filename from a simple window XID, rather than having to work
> out what Xinerama output they are on (or mostly on) and then to get a
> property from the root window.
>
>> The net-color spec itself is pretty indifferent. What we need to discuss
>> here is how to integrate with the ICC in X spec.
>
> Well, if an application is using net-color then presumably this
> interacts with other part of the specification. net-color seems to be
> telling the composting manager of the source profile, and then
> offloading the processing to the compiz frontend, where I assume sRGB
> is used for the non-tagged regions. Whilst it's a cool trick, I'm not
> sure how well viewing something like a PDF would work, with multiple
> ICC profiles for each image, and the application has to tag each
> sub-region of the file (which changes as the user scrolls, etc),
> rather than windows. I'm sure for applications like that it would be
> more useful to do early color binding (using lcms for instance) and
> then tag a window region as "don't color convert me to monitor profile
> twice".

The later case is the target currently. I have not much written for the 
window region profiles.

> In this way it would be a bit like a firewall, where you only 'punch'
> out regions of the desktop which are already color managed. All we

Yes, thats what the compiz colour server plugin only does.

> need to do is ask applications which respect _ICC_PROFILE to tag the
> window with an X property (_ALREADY_COLOR_CORRECTED?), and then leave
> it up to compiz to color correct the rest of the screen, masking out
> the tagged areas. This seems a much easier thing to ask application
> authors to do, and we can even provide hooks in the toolkit (e.g. for
> an auto color corrected GtkImage) to make things even easier.

I would consider the ICC profile tagged regions a good thing to speed up a 
preview or to work in the 8-bit domain like firefox to offload the 
computation to the GPU. Its not that important to start with.

> This seems a lot easier that trying to upload profiles to the server
> and referencing them by uuids, trying to keep the two synchronized,
> and then trying to convert from all the different source profiles to
> destination profiles in one place. In my opinion, of course.

The net-color spec is unfinished.
I use just XColorRegion in _NET_COLOR_REGIONS, which is not very detailed 
described.

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