No subject

maps to a unique coordinate in this sRGB space, including the whole visible 
gamut and all other possible values of XYZ.

> void XrSetRenderingIntent(XrState *xrs, XrIntent intent);
> void XrSetESRGBColor(XrState *xrs, double red, double green, double blue);
> void XrSetCIEXYZColor(XrState *xrs, double x, double y, double z);

I would definately not use more than one colorspace. Multiple ones brings up 
all kinds of questions about which one is "best" and users have to worry 
whether their Xr implementation got it right or not. It also adds lots of 
unnecessary and complicated calls to the interface. Also believe me, anybody 
interested in color management is NOT going to use Xr's implementation, there 
is zero reason to trust the Xr authors to do it right, especially when nobody 
can agree on what right is.

Now it would be nice if the single color space was XYZ or linear rgb, but the 
reason for using sRGB is that it is trivial to convert to it from the colors 
that 99.99% of the programs in the world right now are using. I think that 
unless this is trivial Xr is dead in the water and will never be used by 
anybody.

> > Even though it sounds primitive, I would really like to see an
> > 8-bit/color interface added, like XrSetColor32(u32 color). This would
> > take a number 0xRRGGBBAA to specify the rgba. The reason for such an
> > interface is that is the way the vast majority of applications are
> > storing color for GUI and also how most current devices represent color,
> > and this interface avoids the overhead of converting to float and back. I
> > don't think an equivalent "get" function is needed.
>
> 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.

> The overhead of INT->FLOAT->INT is negligible
> for individual colors...even less if you just store things as floats
> to begin with.

Maybe true, but for a lot of people this *looks* slow. If you have a color 
stored this way you need to do (((c>>24)&255)/255.0, ((c>>16)&255)/255.0, 
((c>>8)&255)/255.0) and this bloats the source code size and looks bad to a 
programmer. If they have to add another layer of calls to wrap this they will 
wonder why they need this overhead, especially when they know it is turned 
back into 8 bits internally.

Also as you pointed out it already takes 8-bit pixmaps. There is certainly 
gong to be interest in getting the same color to fill rectangles as a given 
pixel in the pixmap.

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