color management spec
Maarten Maathuis
madman2003 at gmail.com
Sat May 31 13:14:37 PDT 2008
On 5/31/08, Kai-Uwe Behrmann <ku.b at gmx.de> 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, 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
>
> _______________________________________________
>
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
It would be a good idea to ask someone what the price of a
implementation would be at the level of a compositing manager, maybe
even make a draft fragment shader. Because whatever you think up has
to fit a typical gpu, otherwise it's a disaster waiting to happen.
More information about the xorg
mailing list