color management spec
ku.b at gmx.de
Sun Jun 1 10:36:20 PDT 2008
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
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"
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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the xorg