Mon Aug 15 11:10:41 PDT 2005
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
> > 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
More information about the cairo