GSoC CM collaboration

[Tomas Carnecky]

Graeme Gill wrote:
>> you also cannot modify the pixmap
>> contents because the application still expects to find its data as it
>> wrote it. And you don't want to modify every application, of course.
>> The solution might "simply" be to write a compositing manager that
>> does whatever lookup you want. Fairly recent X.Org versions allow
>> that.
> 
> That would be one approach if you need to maintain pixmap contents
> to allow application readback. Of course the color space affects
> composition, so ideally you need to convert all the different
> colorspaces into an additive space, compose, and then convert
> into the monitor space for display. This may not be viable
> for interactive systems currently, but having the GPU color
> convert into monitor space during composition sure seems feasible
> with modern hardware. All you need is some standards as to
> how it is to be managed, and an implementation :-) :-)

As part of a GSoC project I'd be willing to dive into this subject. I'm 
very interested in video coding/compositing (and colorspaces is a big 
part of it). I've worked on compiz in the past (wrote a little module 
for it) and I'd like to learn how to write OpenGL shaders at some point. 
Oh and I have two LCD monitors (different size, brand and age) and I 
clearly see the differences in colors (and can't get them to look the 
same). So I see first-hand what it means if the color configuration 
doesn't match :)

I was thinking about special atoms attached to windows that specify in 
which colorspace/profile its contents are, and the compositing manager 
(compiz) converting the window contents to the monitor colorspace using 
shaders. That way each application could use its own colorspace without 
having to know which ICC profile the monitor uses or incorporating color 
conversion code into its own codebase. Or does that sound stupid?

In any case, if you're looking for someone willing to work on this 
subject, I'd gladly help.

tom