[Xr] API questions

[Bill Spitzak]

On Monday 09 June 2003 11:04 am, Keith Packard wrote:

> We'll probably get Xr using the XDCCC stuff so that it can offer true sRGB
> for calibrated monitors.  That'll require gamma-corrected compositing in
> the underlying rendering engines which RENDER doesn't currently support.

Having done some work with this, I have found that almost all cgi images made 
for GUI's have been made to precompensate for compositing in gamma-corrected 
space and thus look better if you don't try to do this.

There are also problems with premultipied images, and with questions of 
whether the alpha is in sRGB space or not (most programs output linear alpha, 
but if you treat it that way, an image of an alpha channel itself will look 
different than white drawn through that alpha channel, which will annoy a lot 
of people).

I have also discovered that if you have thin objects (lines and text) and you 
invert them, they look the same "weight" to a human when they are composited 
in gamma space, but they look very different when composited in linear space. 
This could be a big problem for a drawing library designed for GUI.

So I'm thinking Xr will need to define all compositing as being done in sRGB 
space.

The sad part is that antialiasing looks *much* better when done in linear 
space. Perhaps something special can be done for larger polygons and larger 
scaled fonts, where this really makes a difference and the inverted weight 
problem is no longer there.

> > To allow devices to support any color space Xr does have to offer an
> > interface that allows sRGB to be specified with values outside the 0-1
> > range. Not all interfaces need to, just for instance a floating-point
> > one.
>
> Hmm.  That's just crazy enough that it might work.  I'll have to think how
> this would affect the compositing algebra.

The alpha should always be clamped to the 0-1 range, but I believe all color 
values will go through the compositing algebra ok. I think implementations 
should be allowed to clamp incoming data to their gamut before compositing, 
this means that that the exact result of partially-transparent pixels that 
are out of gamut is undefined.

> > *maybe* the floating point interface should be in "linear sRGB". This is
>
> Yeah, maybe.  But, as most applications currently present RGB values in
> non-linear space, I'm not sure that's the best idea.  I think we should
> use regular sRGB everywhere and do gamma corrected compositing.

Having thought about this some more, I agree that the floating-point 
interface should be in sRGB as well.

-- 
                   ,~,~,~,~ ~ ~ ~ ~
     /\_       _|_========___         Bill Spitzak
 ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak at d2.com