color management spec

[Kai-Uwe Behrmann]

Am 31.05.08, 23:42 -0400 schrieb 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.

Ah, you mean Rgb as requirement for blending and so on? 
Well I would agree to such a precondition. Compositing shall happen in 
monitorRgb for simplicity. A selectable intermediate editing(blending) 
colour space would be too much of perfection at this stage. So all input 
will be converted to monitorRgb and compiz will do its work as usual.

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

The goal of many colour people is to build a end to end colour management 
system
One or two colour aware toolkits is a call for problems as we see on 
other OS'es. Toolkits can in my eyes provide convinience layers, speed and 
smooth graphics - important but not important to skip the "end to end"
concept.

Qt? I spoke with some people on their booth at LinuxTag Berlin two days 
ago. No one I asked there had a glue about colour management in Qt.
With Cairo developers we planed, meet and discussed concepts.


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