color management spec

[Maarten Maathuis]

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.