color management spec

[Zack Rusin]

On Saturday 31 May 2008 04:15:55 pm Kai-Uwe Behrmann wrote:
> 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,

Well, they do, that's how we wrote them.

> they would be colour managed 

Well, no. "if they cared about color management" is the proper qualification. 
Decision to do math in one anonymous colorspace that happens to match sRGB 
doesn't affect that. It's a decision that was made based on the performance 
requirements and ease of implementation not colorspace awareness.

> 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.

That's not what I had in mind. The offscreen buffers are piggy-backed on top 
of X pixmaps which are 32bpp, it's phisically impossible to have a true 40bpp 
output if you're sampling from 32bpp. Compiz already has the architecture to 
deliver it, it's higher-depth textures (floating point textures being a 
little different thing, largely hindered by patents), we'd need something in 
place for X though.

> > 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.

I don't think so. Realistically speaking making Qt4 and Cairo deal with 
colorspaces will account for probably more than 90% of big applications. 
Switching these two is not an impossible project. I think that both Cairo and 
Qt4 have open bugreports about color-management and at least for Qt it was a 
high priority project.

z