Hi Owen, I agree that it's a good idea to use sRGB as the preferred reference (although I'm still not totally convinced of their display-gamma-2.2 but use-power-2.4).
I see premultiplied alpha and non-linear colourspaces to be great for output, but scary for intermediate operations: they both imply loss of information. I think ideally RENDER would use a 64bpp linear non-premultiplied framebuffer for compositing, then render its output to the framebuffer. However, any app that really wants to do hardcore compositing would probably just do it themselves, and so since RENDER's scope is limited primarily to text rendering and window manager/toolkit decorations, just getting things 'mostly correct' would be best. I like the colour model you suggested with different profiles so that I can switch between the various gamma models, or try compositing in a perceptually linear space. :) Owen Taylor ([EMAIL PROTECTED]): > - What's the performance impact? I think defaulting to sRGB for the > intermediate space (no gamma correction) is necessary because gamma > corrected isn't going to be hardware accelerated in most cases and > isn't that amenable to software acceleration such as via MMX. Sad but probably true. > - How does it correlate to hardware? The new Matrox card apparently > does gamma-corrected alpha compositing for text in hardware. DX9 is apparently pushing for hardware-accellerated gamma correction operators in the shaders, for texture lookups, all over the place. At least, I'm hopeful. :) > - What to do about premultiplied alpha? It makes the computations > much more expensive, especially when you have destination alpha. > > It's possible that working in 16/16/16/16 linear sRGB might > actually be easier for heavy compositing into destination alpha in > some apps. I think so, but see above... -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
