Around 15 o'clock on Dec 17, Dr Andrew C Aitchison wrote:
> Xcms is the only existing technology for this that I'm aware of -
> "man xcmsdb XcmsCreateCCC" may be a reasonable starting point.
>
> I believe that Keith Packard thinks that it should be replaced.
> Here is a list of things I've learnt about Xcms over the years:
The X Color Management SYstem (Xcms) is built upon the X Device Color
Characterization Convention (XDCCC) which is part of the ICCCM spec and
involves a pair of properties set on the root window which contain tables to
convert between pixel RGB values and intensity ("gamma" correction) and
matrices for mapping between this linear RGB to CIE XYZ.
Xcms then takes this information and exposes several CIE traceable color
spaces, such as CIE XYZ, CIE uvY, CIE xyY, CIE Lab, CIE Luv and the
Tektronix HVC color space as well as both the original non-linear monitor
RGB and the "gamma" corrected linear RGB space.
The only problem with Xcms is that it's integrated into Xlib in a useless
fashion; it allows the specification of colors in any of these color
spaces in string form through the regular Xlib color name APIs. This
means that Xlib is burdened with all of Xcms.
In addition, Xcms makes it somewhat difficult to add new color spaces and
doesn't expose the underlying XDCCC data structures to applications.
Because the typical monitor used for X has no color calibration data,
application developers never saw value in this complicated color managment
mechanism and hence never really adopted any of it's functionality.
I think the underlying monitor calibration data is sound, but what we
should do is look again at what API should be exposed to applications to
take advantage of this calibration information, in particular I can see
value in adding several new color spaces such as sRGB. I would also like
to see the Render extension include gamma corrected compositing operations
using the gamma tables provided through XDCCC.
Xcms includes extensive support for automatic gamut compression; I don't
have enough experience with that part of the API to know if it's useful or
not; it's a hard problem with significant data dependencies.
> 2) Xcms uses its own trig routines for Polar<->Cartesian conversion
> between color-spaces*, and these are buggy.
Sigh. Of course that was forced because Xcms is integrated into Xlib and
it wasn't possible to require applications to link against the math
library just to use Xlib; systems without chained library dependencies
were more common 10 years ago than they are today.
> but my experience, and perceived wisdom, is that on average using the
> default setup gives more accurate color than trusting the info provided by
> the monitor itself
I recall the results of that experiment -- assuming a standard gamma of
2.2 was more accurate on average than believing the DDC gamma values. I
must assume that's true because Windows doesn't expose that data to
applications. I've heard that DDC information on "mac friendly" monitors
is significantly more accurate.
Keith Packard XFree86 Core Team HP Cambridge Research Lab
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
