color management spec

[Kai-Uwe Behrmann]

Am 30.05.08, 13:10 -0400 schrieb Zack Rusin:
> On Friday 30 May 2008 11:28:38 am Tomas Carnecky wrote:

> > When a compositing manager is running, all the windows are kept
> > off-screen and, everytime the window contents change, the compmgr copies
> > the frames to the frontbuffer. Compositing managers already use shaders
> > for various effects, so sneaking one line of fragment shader comes at
> > almost no additional cost.
> 
> It's probably worth noting that at this stage some aspects of color-space 
> conversion will be already off. Currently all our vector graphics framework 
> operate in sRGB/anonymous colorspace. For all intense and purposes while 

If they would really do so, they would be colour managed and would allow 
for monitor profile selection and so on. So this claim is as correct as 
every monitor is sRGB.

> blending benefits from this approach, anti-aliasing, which is a physical 
> operation, should really be done in linear color-space. The reality is that 
> for performance reasons that has never been done especially since a non-lossy 
> conversion between sRGB and linear RGB would require (iirc) 10bpc.

I am afraid a integer coding is not useful at normal costs to roundtrip 
8-bit. The colour management (CM) project of Tomas can no handle this. 
Therefore the infrastructure could be provided by compiz to deliver 
buffers with higher bit depth, possibly on request. To think about this 
is a good thing.

> So the fact that you only have a 32bpp pixmap with the contents already 
> creates a problem. If your display uses xvYCC (x.v.Color) then if you're 
> composing 32bpp sRGB pixmaps you've already lost the battle.
> Before doing anything else it'd be probably worth trying to figure out how to 
> at least let applications use more than 32bpc for offscreen.

This would be very welcome and a different project.

> So yea, I think it's a two step process:
> a) we need to actually allow creating arbitrary color-space offscreen 
> renderings, which would make sense in graphics toolkits,
> b) something can map those offscreen to the  output.
> Without both it won't work. And since I'm assuming you won't tackle "a", let 
> me just point out that Qt doesn't use subwindows (the exception being things 
> you xembed).

Toolkits are not a promising level to handle for this special project. 
I dont have enough fingers on my hands to count all 
thos tookits in question. It is too much work. 
Of course we like to discuss of integrating CM into toolkits or any other  
level, like into Cairo. 

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