color management spec

Graeme Gill graeme2 at argyllcms.com
Sun Jun 1 20:29:49 PDT 2008


Tomas Carnecky wrote:

> conversion. To allow for fine-grained color management (if an
> application has only a region that it wants to have color managed), the
> applications have to be able to specify subregions of their window and
> attach profiles to that. Since toolkits (at least GTK+) already make
> heavy use of subwindows, using those makes sense to me. So I came up
> with a document (in the attachment) that describes which window
> properties and messages are used.

It only makes sense to do this if the compositing manager is normally
responsible for composing such subwindows into the screen.

> ------------------------------------------------------------------------
> 
> 
>    Color Management Spec
>   -----------------------
> 
>   Overview:
> 
>   Each window can have a color profile attached. This profile is used by the
>   compositing manager to perform automatic colorspace tranformations.
> 
> 
>   _NET_COLOR_PROFILE window property
> 
>   This property specifies the profile. The only type currently supported is
>   'ICC', it specifies that the data is an ICC profile. Other profile types
>   may be added at a later time. Profiles are inherited from the parent window.
>   Applications can disable the automatic colorspace transformation by setting
>   the profile to None.

If the application/toolkit wants to provide device link profiles, how does it
represent each combination of window colorspace and monitor colorspace for
a multi-monitor setup, if there is only one property per window ?

You need a property for each monitor. Perhaps a better approach would be for
the compositing manager to request the transformations it needs from the
application/toolkit, so that device links need only be generated for
window/monitor combinations that will actually be used. (Generating
high quality device links using A2B table inversion can take some minuets,
so you wouldn't want the application to do this unnecessarily).

Graeme Gill.



More information about the xorg mailing list