Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
SCALE 8x: Color management for everyone
Posted Mar 5, 2010 23:39 UTC (Fri) by roelofs (guest, #2599)
No--any application that does its own alpha-blending, for example, needs to convert the image(s) and background from their native color space(s) to linear (gamma = 1.0), do the compositing, and (usually) convert back. Other transformations (lighting/shading calculations and whatnot in 3D, IIRC) also require linear gamma for correctness. And it's hard to imagine a driver complex enough to support multi-source display app like a browser ("this block of pixels is linear, this block uses this custom ICC profile, that block is SGI/gamma-1.7, and everything else is sRGB"). Conceivably it's doable, but I'm not sure a driver is the best place for it.
Posted Mar 8, 2010 3:50 UTC (Mon) by psyquark (subscriber, #58373)
All color triplets have a color space, either explicit or implicit. On a stand alone uncalibrated machine the implicit colorspace is the colorspace of the display. The problems start when sharing files with other computers, each of which has its own implicit colorspaces. Known colorspace to known colorspace mapping is doable but unknown colorspace to any colorspace is not feasible. To fix that the sRGB colorspace was created. It was defined to be a decent approximation of the standard displays of the time. The web standard became "If you don't know the space and care about color, treat it as sRGB."
The naive solution is to have the client handle all color management and output pixel values in the display's colorspace. This can be useful in cases when a specific or controlled rendering intent is needed to accommodate special needs. The problem is that client side management does not handle multiple outputs well. In fact, it is not possible for a client to handle simultaneous display on multiple outputs such as from software mirror to a projector or a visual pager application showing a preview on a second display.
The best solution is to have the Compositor handle the final colorspace conversion. It knows exactly where each pixel is going to be displayed because it will be putting that pixel there. There has been some work towards this (but not mentioned in any slides or the writeup) from a Google Summer of Code in 2008. It was called "Color Management Near X" and I believe the "net-color" standard. The solution was not to send colorspace with each pixel, but rather to set window properties defining the icc profile for the window or regions of the window. I should note that specifying client's colorspace to be the same as one of the outputs results in a null transform. That gives the application the same power as before, but allows the Compositor to give sane colors on other displays. Sadly I can't find much information on it with google.
As it stands "color managed applications" can display correctly on my wide-gamut LCD or my normal gamut LCD but not both. The colors will be flat wrong when they appear on the "other" output.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds