An unadjusted monitor, through fortunate circumstances, very closely matches the non-linear response of the human eye.
Why would you want a monitor with a non-linear response? Suppose a monitor is displaying an image of some everyday street-scene. A human watching the monitor would like the monitor and the real-world to look identical. This means the light emitted at every point on the monitor should be equal to, or, less ideally, just proportional to, the intensity of light at the corresponding point in the original scene. This is identical to saying ideal monitors have a linear response.
The visibility of steps between neighbouring gray levels in a gray level ramp/gradient image is mainly due to the Mach effect in human vision exaggerating the perceived steps, rather than being due to the size of the gray-level differences. Because of the Mach effect, viewing a gray level ramp is actually a poor method of judging the quality of a monitor and its calibration. A monitor should be calibrated with proper test equipment like a photometer, and, ideally, a spectrophotometer.
By the way, the human retina has a logarithmic response to light intensity, while an uncalibrated monitor has an exponential response to gray level, with gamma as the exponential base. Visual perception and many interesting neurophysiological experiments are discussed by Spillman and Werner (Visual Perception, 1990)
Anti-aliasing for black-and-white texts can work but it's worth noting that anti-aliasing of colored text is intrinsically flawed because anti-aliasing of colored texts on colored backgrounds creates linear combinations of two different hues which are perceptually different from the original hues, creating a false dark border next to the text.
To see what I mean, using xmag or xzoom look at the border area between the red text and green background color image of the anti-aliased xterm
(4th column, 8th row) on Keith Packard's X rendering page.
No watermarking method is truly secure and useful unless
It can be proved there is no feasible method of erasing or changing the watermark.
The probability of the method incorrectly detecting a non-existent watermark is extremely low, ideally 0.
The probability of the method correctly detecting a true watermark is very high, ideally certain.
Together these requirements are tough for a watermarking scheme to meet. See the StirMark project for examples of supposedly "secure" watermarking methods being broken.
Your criticisms are very confused. The X Window System provides color calibration for displays (monitors). X is a networked graphics display system. X is not a printing system. If your printer driver does not support color calibration, you blame your printer driver supplier but you do not blame X because it's not the purpose of X to do printer color calibration.
You are confused about color calibration. If a calibrated chain of systems creates graphics output on a display device the output is only as good as the end-to-end calibration. Calibration can be done either by modelling each component of the chain and then composing the separate models, or by modelling the entire chain as a single black box.
In answer to your question, blame can indeed be apportioned!
If a picture looks bad only on your monitor, blame it on your monitor's limited color space or your monitor's inaccurate color calibration.
If a picture looks bad only on my printer, blame it on my printer's limited color space or my printer's inaccurate color calibration.
If a picture looks bad even on a perfectly calibrated monitor or printer (hypothetical beasts of course), blame it on the picture scanning calibration.
In my opinion, X has all the color calibration features it needs; extras would make X bloated. Swapping pictures between Gimp and Photoshop is an application problem of converting file formats, not with calibration per se. Try asking Adobe for information about the file formats they use in Photoshop, then implement them in Gimp.
A quick explanation of X color calibration is here
A quick search on Altavista for xcmsdb.c gives the untarred X source code (delete spaces in the URL by hand otherwise it won't open. If only slashdot would fix that bug. If only more sites would keep the whole untarred X). Look in the datafiles sub-directory therein for examples (delete spaces in URL) of the data formats used to specify the forward and inverse color-correction matrices. You can load one of the example files onto the root window using xcmsdb sample2.doc. Check the data loaded ok using cmsdb -query
Calibrated color is now set up!
Specify all your colors for any X program in a device-independent color space like CIE XYZ, and you'll automatically get calibrated colors on the monitor (assuming your monitor matched the data in sample2.doc). The colors can be specified by command-line options or in X resource files. To use the example of the previous poster, try xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Leave that xterm running in the background. Remove the calibration: xcmsdb -remove. Start another xterm as before, and notice the slightly different appearance of the background color: xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Ignoring the hard part of creating the calibration data, that's a quick tour of color calibration in X!
Why do I want multiple libc versions of programs? Because the net-present-cost of upgrading certain binaries outweighs the net-present-benefit.
Your suggestion of using links works in many cases for differentiating libc5 / glibc-2.0 programs but I haven't managed to get either it -- or the alternative of setting LD_PRELOAD -- to work for distinguishing glibc-2.0 / glibc-2.1 programs. For example, the commonest problem is the dynamic loaders ld-2.1.3.so and ld-2.0.7.so get confused about matching some symbol or other to the different versions of the shared libraries, e.g._xstat even though LD_PRELOAD is telling the loader which are the correct Xlibs (2.1.3 or 2.0.7) to use.
Get or measure some monitor color calibration data, and anyone can do full color calibration in X very easily and transparently in all X applications -- more details are here and here
X, including all the free Xserver implementations, have had complete support in Xlib for doing color calibration -- see other posts here and here. The feature's been there since X11R5 which is years old.
As I posted below, the whole point of the color calibration stuff in X is it can handle color in a device-independent way by using CCCs (Color Conversion Contexts) to specify a display's color pecularities. Do your own monitor color calibration and simply load the calibration data onto your Xserver using xcmsdb. Once you've done that your example of specifying a device-independent foreground color in xterm using the CIE XYZ color space would give a properly calibrated color on your monitor. That's pretty useful. Your criticism of color management in X is inaccurate and misleading because you don't understand how to use it properly.
As a footnote, doing an accurate color calibration of a monitor, requires expensive test equipment like a tele-spectrophotometer.
Have you read the man pages on using XcmsCCC structs to define a color calibration in X?
man XcmsSetWhitePoint
man XcmsCreateCCC
BTW, has "DLL hell" got to Linux? I mean there're all those nasty incompatibilities between different versions of the libc shared libraries, like libc5, glibc-2.0, glibc-2.1, etc.
What's the best way to organise/lib/usr/lib/etc/ld.so.conf so you can have all of the glibc versions and dynamically linked programs available?
Slashdot Mirror
Thanks, Keith. I was indeed assuming in my comment that the anti-aliasing was on a typical CRT display without automatic gamma correction.
BTW your render extension work looks very interesting. Is it also integrated with the GNOME libs yet?
An unadjusted monitor, through fortunate circumstances, very closely matches the non-linear response of the human eye.
Why would you want a monitor with a non-linear response? Suppose a monitor is displaying an image of some everyday street-scene. A human watching the monitor would like the monitor and the real-world to look identical. This means the light emitted at every point on the monitor should be equal to, or, less ideally, just proportional to, the intensity of light at the corresponding point in the original scene. This is identical to saying ideal monitors have a linear response.
The visibility of steps between neighbouring gray levels in a gray level ramp/gradient image is mainly due to the Mach effect in human vision exaggerating the perceived steps, rather than being due to the size of the gray-level differences. Because of the Mach effect, viewing a gray level ramp is actually a poor method of judging the quality of a monitor and its calibration. A monitor should be calibrated with proper test equipment like a photometer, and, ideally, a spectrophotometer.
By the way, the human retina has a logarithmic response to light intensity, while an uncalibrated monitor has an exponential response to gray level, with gamma as the exponential base. Visual perception and many interesting neurophysiological experiments are discussed by Spillman and Werner (Visual Perception, 1990)
Anti-aliasing for black-and-white texts can work but it's worth noting that anti-aliasing of colored text is intrinsically flawed because anti-aliasing of colored texts on colored backgrounds creates linear combinations of two different hues which are perceptually different from the original hues, creating a false dark border next to the text.
To see what I mean, using xmag or xzoom look at the border area between the red text and green background color image of the anti-aliased xterm (4th column, 8th row) on Keith Packard's X rendering page.
Unfortunately watermarks can be removed.
No watermarking method is truly secure and useful unless
- It can be proved there is no feasible method of erasing or changing the watermark.
- The probability of the method incorrectly detecting a non-existent watermark is extremely low, ideally 0.
- The probability of the method correctly detecting a true watermark is very high, ideally certain.
Together these requirements are tough for a watermarking scheme to meet. See the StirMark project for examples of supposedly "secure" watermarking methods being broken.You can email to William.Mackeown@ieeeNOSPAM.org after a few days when IEEE customer services will, I hope, have fixed my email account.
My micro HOWTO on color calibration in X is here.
Your criticisms are very confused. The X Window System provides color calibration for displays (monitors). X is a networked graphics display system. X is not a printing system. If your printer driver does not support color calibration, you blame your printer driver supplier but you do not blame X because it's not the purpose of X to do printer color calibration.
You are confused about color calibration. If a calibrated chain of systems creates graphics output on a display device the output is only as good as the end-to-end calibration. Calibration can be done either by modelling each component of the chain and then composing the separate models, or by modelling the entire chain as a single black box.
In answer to your question, blame can indeed be apportioned!
In my opinion, X has all the color calibration features it needs; extras would make X bloated. Swapping pictures between Gimp and Photoshop is an application problem of converting file formats, not with calibration per se. Try asking Adobe for information about the file formats they use in Photoshop, then implement them in Gimp.
A quick explanation of X color calibration is here
A quick search on Altavista for xcmsdb.c gives the untarred X source code (delete spaces in the URL by hand otherwise it won't open. If only slashdot would fix that bug. If only more sites would keep the whole untarred X). Look in the datafiles sub-directory therein for examples (delete spaces in URL) of the data formats used to specify the forward and inverse color-correction matrices. You can load one of the example files onto the root window using xcmsdb sample2.doc. Check the data loaded ok using cmsdb -query
Calibrated color is now set up!
Specify all your colors for any X program in a device-independent color space like CIE XYZ, and you'll automatically get calibrated colors on the monitor (assuming your monitor matched the data in sample2.doc). The colors can be specified by command-line options or in X resource files. To use the example of the previous poster, try xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Leave that xterm running in the background. Remove the calibration: xcmsdb -remove. Start another xterm as before, and notice the slightly different appearance of the background color: xterm -bg CIEXYZ:0.371298/0.201443/0.059418 &. Ignoring the hard part of creating the calibration data, that's a quick tour of color calibration in X!
Why do I want multiple libc versions of programs?
Because the net-present-cost of upgrading certain binaries outweighs the net-present-benefit.
Your suggestion of using links works in many cases for differentiating libc5 / glibc-2.0 programs but I haven't managed to get either it -- or the alternative of setting LD_PRELOAD -- to work for distinguishing glibc-2.0 / glibc-2.1 programs. For example, the commonest problem is the dynamic loaders ld-2.1.3.so and ld-2.0.7.so get confused about matching some symbol or other to the different versions of the shared libraries, e.g. _xstat even though LD_PRELOAD is telling the loader which are the correct Xlibs (2.1.3 or 2.0.7) to use.
Get or measure some monitor color calibration data, and anyone can do full color calibration in X very easily and transparently in all X applications -- more details are here and here
Here are pointers to info about the color calibration that is already built into the X Window System on Linux systems here and here
Learn more about the full support for color calibration that is available in X here and here
X, including all the free Xserver implementations, have had complete support in Xlib for doing color calibration -- see other posts here and here. The feature's been there since X11R5 which is years old.
As I posted below, the whole point of the color calibration stuff in X is it can handle color in a device-independent way by using CCCs (Color Conversion Contexts) to specify a display's color pecularities. Do your own monitor color calibration and simply load the calibration data onto your Xserver using xcmsdb. Once you've done that your example of specifying a device-independent foreground color in xterm using the CIE XYZ color space would give a properly calibrated color on your monitor. That's pretty useful. Your criticism of color management in X is inaccurate and misleading because you don't understand how to use it properly.
As a footnote, doing an accurate color calibration of a monitor, requires expensive test equipment like a tele-spectrophotometer.
Have you read the man pages on using XcmsCCC structs to define a color calibration in X?
man XcmsSetWhitePoint
man XcmsCreateCCC
BTW, has "DLL hell" got to Linux? I mean there're all those nasty incompatibilities between different versions of the libc shared libraries, like libc5, glibc-2.0, glibc-2.1, etc.
What's the best way to organise /lib /usr/lib /etc/ld.so.conf so you can have all of the glibc versions and dynamically linked programs available?
one more
test again