As part of my GSoC project I have to work out a spec that covers how applications should communicate color management related properties between each other and the compositing manager. The main idea of the project is to let the compositing manager do the color management on behalf of the applications. But before that can happen, the applications have to tell the compositing manager how they want to have their colors managed. The following spec I came up with should cover exactly that communication. How colors should be interpreted is defined in so called 'ICC Profiles', that is a blob that contains all the necessary informations how colors should be interpreted. These profiles are attached to windows so that the compositing manager can get them and do the necessary color 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. Dennis Kasprzyk (compiz developer) wasn't happy that I want to attach properties to subwindows, instead he suggested to attach a list to the top-level window containing tuples of [(sub)window XID / Profile]. But I'd like to keep the properties on the subwindows, I think that will make it easier for toolkits. In GTK+ for example, widgets that create their own subwindow will be able to do the color management completely independent of the other widgets. If all profiles are kept in the top-level window then the widgets first have to find the top-level window and then coordinate with other widgets how to create the list. I'd like to hear other opinions on that. thanks tom -------------- next part -------------- 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. _NET_COLOR_MANAGER client message By sending this client message to the compositing manager, the application requests that the compositing manager checks whether it can perform the needed colorspace transformations. Upon recieving this client message, the compositing manager traverses the subwindows of the application and saves the attached profiles. It then checks whether it can perform the requested colorspace transformation and sends a reply to the application. The reply is either positive or negative. Upon a positive reply the application can expect that the colors will be automatically corrected by the compositing manager. A negative reply contains a list of all the windows on which the compositing manager can't perform the colorspace transformation. Usually due to the lack of the needed color management module.
Alex Deucher wrote:> On Fri, May 30, 2008 at 8:08 AM, Tomas Carnecky <tom at dbservice.com> wrote: >> As part of my GSoC project I have to work out a spec that covers how >> applications should communicate color management related properties >> between each other and the compositing manager. The main idea of the >> project is to let the compositing manager do the color management on >> behalf of the applications. But before that can happen, the applications >> have to tell the compositing manager how they want to have their colors >> managed. The following spec I came up with should cover exactly that >> communication. >> >> How colors should be interpreted is defined in so called 'ICC Profiles', >> that is a blob that contains all the necessary informations how colors >> should be interpreted. These profiles are attached to windows so that >> the compositing manager can get them and do the necessary color >> 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. >> >> Dennis Kasprzyk (compiz developer) wasn't happy that I want to attach >> properties to subwindows, instead he suggested to attach a list to the >> top-level window containing tuples of [(sub)window XID / Profile]. But >> I'd like to keep the properties on the subwindows, I think that will >> make it easier for toolkits. In GTK+ for example, widgets that create >> their own subwindow will be able to do the color management completely >> independent of the other widgets. If all profiles are kept in the >> top-level window then the widgets first have to find the top-level >> window and then coordinate with other widgets how to create the list. >> I'd like to hear other opinions on that. >> > > I think you may want to start with a basic app to load ICC profiles > and properly set the LUTs per crtc using xrandr, then move onto the > per-window stuff. That may be part of your plan already.IIRC the LUTs can be incorporated into ICC profiles. And we agreed that that would be preferred over setting the LUTs using xrandr. When you set the LUT in hardware you have the issue of applications resetting your LUT (There is an application, I don't remember which, that uses the LUT and when it finishes it resets it to linear instead of what it was before). Loading display profiles into xrandr output properties should be done by the session (gnome-session or whatever kde uses). There are already tools to load the profiles, but you have to do that by hand, it's not automated. And that part of desktop color management has completely different issues, like where and how to store the configuration etc. tom
Am 30.05.08, 11:27 -0400 schrieb Alex Deucher:> I think you may want to start with a basic app to load ICC profiles > and properly set the LUTs per crtc using xrandr, then move onto the > per-window stuff. That may be part of your plan already.What is the most easy way to get XRandr up with two monitors? My current card is a nvidia6200, but I'd be willing to change that. The propriarity driver is no option. Compiling nv + xorg(?) myself seems hard eigther. Then we could work on this part, which Tomas is not in need to handle himself. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
Am 30.05.08, 14:32 +0200 schrieb R?mi Cardona:> Tomas Carnecky a ?crit : > > Dennis Kasprzyk (compiz developer) wasn't happy that I want to attach > > properties to subwindows, instead he suggested to attach a list to the > > top-level window containing tuples of [(sub)window XID / Profile]. But > > I'd like to keep the properties on the subwindows, I think that will > > make it easier for toolkits. In GTK+ for example, widgets that create > > their own subwindow will be able to do the color management completely > > independent of the other widgets. If all profiles are kept in the > > top-level window then the widgets first have to find the top-level > > window and then coordinate with other widgets how to create the list. > > I'd like to hear other opinions on that. > > Qt 4.4 no longer uses sub-windows. I'd say that more or less validates > the "subregion/profile attached to the top-level window" approach.Can you support both, the subwindow ID's and, as fallback, the regions inside the top level window? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
On Sat, 2008-06-14 at 12:51 -0700, Hal V. Engel wrote:> On Wednesday 11 June 2008 08:33:04 am Owen Taylor wrote: > > > [ Intentionally not trimming quoting much due to various bounces > from lists > > > ] > > > > > > On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote: > > snip > > > > Tagging the window with the image colour space will render in > rather a > > > > mosaic of windows. > > > > > > I don't understand this. > > I think you are assuming that the image color space is some kind of > gamma corrected RGB color space. What is the image color space was a > CMYK color space or XYZ or Lab?If the visual of a window is ARGB, it can't hold XYZ or Lab, or most obviously CMYK data. I don't see color management support at the CM level as being a mechanism to simplify the writing of image handling code, it's a mechanism to allow the user to see the widest range of accurate colors possible on their monitor. For any color space you might want to support on a toplevel you have to ask "what is the advantage". sRGB: decent compromise between range and precision. Widely used standard. raw monitor color space: allows the application full control. difficulties in multi-monitor setups if the monitors aren't identical and calibrated identically. The reason why you might want to support other color spaces is to get greater gamut then is possible with sRGB without having to deal with the difficulties of per-monitor specifics... if I have an image in Adobe RGB with 8 bits per primary, it might be interesting to preserve that colorspace and use that as the colorspace on my toplevel, but that's not done to avoid having colorspace conversion code in the application: it's done to avoid losing gamut when converting it to something else. Honestly, the only reason this is at all interesting is the limitations of RGB 8:8:8. The long term solution here is support for something like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.) - Owen
Owen Taylor wrote:> If the visual of a window is ARGB, it can't hold XYZ or Lab, or most > obviously CMYK data.> difficulties of per-monitor specifics... if I have an image in Adobe RGB > with 8 bits per primary, it might be interesting to preserve that > colorspace and use that as the colorspace on my toplevel, but that's not > done to avoid having colorspace conversion code in the application: it's > done to avoid losing gamut when converting it to something else.If you have an image in CMYK the best way to avoid losing gamut, just like in your AdobeRGB example, is to let the CM convert it at the very last stage. So it might be useful to be able to upload CMYK pixels into the xserver and tag the data somehow. I don't see any conflict there as long as the application and CM agree on the pixel format.> Honestly, the only reason this is at all interesting is the limitations > of RGB 8:8:8. The long term solution here is support for something > like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)First the server would have to support buffers with at least 6 byte per pixel, which it does not currently. I would love to see support for arbitrary pixel formats in the xserver. I would even go as far as having the xserver create bare buffers and then tag them with the pixel format / icc profile. After all, if a (OpenGL-based) CM is running the xserver doesn't need to know anything about the windows besides the dimensions. tom