[Xr] API questions
spitzak at d2.com
Mon Jun 9 18:41:12 PDT 2003
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
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
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
More information about the cairo