[Xr] API questions

[David Forster]

On Thu, Jul 03, 2003 at 06:07:27PM -0700, Bill Spitzak wrote:
> I fully understand that, but since the device cannot display
> out-of-gamut colors then it is impossible to produce the same output
> on two different devices anyway, so it really does not matter what
> it does with such colors (though I recommend that the device choose
> reasonable values).

OK, you're right...I totally misunderstood what you where talking
about and wasn't thinking clearly.

Right, while RGB values specify well-defined colors, the color gets
clipped in the frame buffer...The only `correct' solution is to store
pixels in some high precision format...

> I hope everybody can see that unless this is defined this way, Xr
> cannot use hardware for compositing, and must store full-floating
> point for every pixel in it's display.

Yes, hard to see how to get around it.  Floating point, however, is
not necessary.  HP's e-sRGB color space defines values in the range
-0.53 to 1.68, which is then mapped to a 10, 12 or 16-bit integer.
This gamut is large enough for printers...The frame buffer could be in
this format.

This of course could not be accelerated with today's hardware, but if
48/64-bit buffers ever materialize, then it could be.  Simply render
in e-sRGB and then shift/expand the color values...

One could also do the same thing today by stretching 8-bits over
e-sRGB, at the expense of precision...But I doubt it would look good.

OK, I'll try again:

Support both e-sRGB and sRGB.  The user specifies which when the
surface is created.  Most folks (like toolkit authors) will specify
sRGB, but users doing higher quality work can specify an e-sRGB
buffer.

e-sRGB won't be accelerated for the time being, but will be correct.
I don't know, though, how slow 48-bit rendering is in software.  If it
isn't doable, then Xr could just refuse to create an e-sRGB surface.

All values still accepted by XrSetRGBColor() no matter what color
space, but clamped to appropriate values.

To prevent color flashing for accelerated 48-bit output, however,
double-buffering would have to be integrated into Xr.  This may not be
so horrible, however.  If Xr is also going to support rendering to PDF
like Quartz, then it will also need a `new page' operator.  Also,
client side rendering needs to know when to send the buffer anyways.

Now, it's true that having two color spaces like this complicates
things a bit, but if you can't trust the implementation to do e-sRGB
correctly, then users might be inclined not to use it all, or hack
there rendering code up to expect either e-sRGB or sRGB anyways.

You can end up with some very strange output doing e-sRGB to sRGB
blindly.

> > If you're doing color management the value isn't going to get passed
> > straight on anyways.
> 
> Well actually for almost all current-day hardware, if the values are
> sRGB*255 then they are going to be passed unchanged to the hardware.

Ack ;).  Of course, the whole point of sRGB...I wasn't thinking.

-Dave

(e-sRGB, btw, can be found at www.srgb.com)