Guess I should finally expand a bit on the topic of getting monitors to match in terms of color.
Originally Posted by Proxish
I'm trying to calibrate the colours on my monitor, but I'm just don't understand what I'm supposed to do.
I downloaded Colour Sustainer, and I can't figure it out, I also downloaded profiles as well, but no joy with those, no idea how to use them.
I have had the monitor for months, and I'm only just getting around to colour calibrating it.
I use my Pc for artwork as well as gaming, for gaming it's fine, but for artwork it's awful because of the vast difference in colour when switching monitos.
My monitor is a Glossy QNIX QX2710LED, I overclocked it to 100hz via the nVidia control panel. I also have a Cintiq 12WX which the colours seem fine on, I also have another Tv sitting above the QNIX monitor.
If someone could help me figure out how I can get all monitors to display the same colours, that'd be great, as it's making colour checking my artwork a nightmare.
We have several types of display calibration. Let's talk about grayscale calibration first.
This graph shows the measurements of Red, Green, and Blue luminance obtained on 100 grayscale levels on the Qnix left uncalibrated:
These grayscale levels are produced by mixing the Red, Green, and Blue primaries. These primaries are shown on the following CIE diagram:
This CIE diagram is a normalized diagram. We take color values from a 3D space and normalize them by making the 3rd axis (Y) represent luminance, and leave only x and y (chromaticity coordinates) representing the colors themselves. This allows us to map these values to a 2D space.
The R,G,B primaries have the same chromaticity coordinates for all values of R,G, and B respectively. R64 and R255 both have the same *hue* of the color Red, just different luminance. A purely Red color emitted by the display should have the same wavelength / chromaticity but different brightness for different values of Red, given that the backlight is a perfect white light source (more on what *white* is later).
The black triangle you see in that CIE diagram is the sRGB colorspace. The colorspace is the range of colors according to which content is produced. The sRGB colorspace is that which all (99.99%?) consumer content we currently have available is produced in.
This colorspace specifies the chromaticity coordinates / wavelengths of R,G,B required to hit a whitepoint Color Temperature
) of 6500K (Daylight), when these primaries are mixed in equal quantities (luminance). The grayscale levels should all be of 6500K color temperature as well, and grays such as 75,75,75 or 231,231,231 (near white) should have these primaries mixed in equal amounts (luminance) as well.
Let's assume we are dealing with a monitor that has its primaries perfectly matching those required by the sRGB colorspace. Grayscale calibration ensures that all grays are at 6500K, with no error. Red, Green, and Blue primaries are also accurate, thus the secondaries Cyan, Magenta, Yellow, and all other colors are perfectly accurate within the sRGB colorspace. No issues, perfect monitor that can display all colors accurately for sRGB content.
How are these primaries produced? The chromaticity coordinates / wavelengths of these primaries are a function of the backlight used (CCFL, White LED, RGB LED, GB-LED, Blue LED with Quantum Dots, etc...) and the filter material used in the pixels themselves, and what wavelengths they allow to pass through. You would need a perfectly white light source @ 6500K for the backlight, plus perfect filter material for the pixels that allows R, G, and B to match the wavelengths specified by the sRGB colorspace (or any colorspace, for that matter). It's hard enough to do that without factoring in time, as the backlight will drift over time, and so will the pixels, meaning that to ship out a monitor that's perfect in terms of primaries is pretty much an impossible feat currently. Even professional monitors costing in the thousands of dollars should be regularly calibrated for color-critical work.
We are thus dealing with monitors with inaccurate primaries to begin with:
Observe the DeltaE values. These represent the degree of error. <1 is an invisible error. Above 3 is a clearly visible error.
Grayscale calibration CANNOT
correct the primaries. Correcting the primaries entails mixing in other primaries. For example, if Red is off, R255 (G and B are naturally set to 0 by default) needs to be corrected to R255,G23,B21 for example to now match Red as specified in the sRGB colorspace. What then varies is the luminance, which can be controlled by changing the backlight brightness. The sRGB colorspace does not factor in luminance, as we have discussed before, but the standard which governs sRGB content also specifies certain luminance values that are suitable for color-critical work, e.g. 120 cd/m2. We shall see soon why grayscale calibration cannot tell the system that instead of asking for R255,G0,B0, it should ask for R255,G23,B21 so that R255 is actually displayed in accordance with the sRGB colorspace.
To prove this point graphically...Qnix @ Default vs. Calibrated:
How exactly is the luminance of each grayscale level determined? Gamma curve, output = input^gamma. Since the input is in the range 0-->1 (corresponding to 0-->255 for 8-bit color channels), a gamma greater than 1 shifts the curve down from the linear curve output = input. Target gamma is 2.2. Gamma correction
Now, on to the CIE diagram and the measures for the Primaries and Secondaries:
Primaries and Secondaries:
By changing the whitepoint, the saturations align, but they are still not accurate as the primaries that produce these saturations are not accurate as well. Each of these primaries is equally inaccurate across the entire range of grayscales and saturations, therefore the saturations will still line up to produce 6500K white / grayscales at R=G=B (max, 255 in the case of white).
Why cannot grayscale calibration correct the primaries?
Look at these curves. Each is an individual curve. The Red curve says: map an input of 129 to an output of 121.67. This means that when the color R129,Gj,Bk is requested, the output produced is R121.67, GJ, BK, so that we actually get a value of R129,Gj,Bk according to the sRGB standard. The input-output curve of Red operates independently of Green and Blue. Regardless of the values j and k, and their corresponding mappings (in the Green and Blue curves) J and K respectively, 129 will ALWAYS map to 121.67.
Take the simplest case of wanting to keep the blackpoint the same, since we can only make the blackpoint more accurate by raising luminance for the R,G,B components used to produce black (0 by default, we cannot go below 0). To make Red accurate, R255,G0,B0 --> R255,G23,B21; however, we would want to keep G0 --> G0 and B0 --> B0 and that we cannot do with three separate, independent curves which can only affect colors together when this color has all three components R,G,B.
Obviously, this limitation applies to all other colors, except grayscale. Given that we have inaccurate primaries, mix those primaries in a fashion such that in mixture, the grayscale produced is accurate. Have 10% less Red than is necessary? Make a Red I/O curve such that all Red values are raised to compensate for the 10% difference.
This wraps up, in a nutshell, why we call this type of calibration "Grayscale calibration".
Windows supports these types of curves. So, applications such as Color Sustainer (cool dev made this
) load these profiles using functions provided with Windows. For calibrations further than grayscale, you would require the application to be color-aware. Games are not color-aware, but applications such as Photoshop are, and these applications allow gamut mapping in order to correct the primaries themselves, and not only the grayscale.
When using multiple monitors, there is a clear issue when using applications that are not color-aware: Different monitors, especially different models using different panels, have different gamuts. Here is the Qnix vs. my ViewSonic VX2450wm-LED, even when calibrated:
Whites will be pretty close, so will grayscale, but the other colors are not. There will be a difference in saturation, where, let's say, Yellow is more saturated on the Qnix vs. the ViewSonic. In fact, all colors will be more saturated on the Qnix, given that it covers 99.7% of the sRGB colorspace but is actually ~117% the volume of the sRGB gamut. On the other hand, the ViewSonic covers ~95% and its volume barely exceeds the volume of the sRGB gamut.For best results
, you would need to buy a hardware sensor to calibrate all displays to the same standard. Do not rely on profiles available on the internet if you're doing color-critical work, especially
on multiple displays since each monitor is different. At the very least, monitors from the same model (just different samples) might have gamuts that are close enough to be indiscernible, but will have different gamma response and thus will require grayscale calibration. At the most, each might require different gamut mapping in order to display sRGB content properly.
Even when using a single monitor, the mere fact that its gamut will not perfect match the sRGB colorspace and the grayscale will be off means that you would require a hardware sensor for the best results.
My recommendations, as of 2014-07-24? The Spyder4Express (budget), the Colormunki Display (reverse-engineered to work with 3rd-party applications, medium budget), and the i1 Display Pro.
Spyder4Express: similar sensor in a cheaper package than the Pro, Elite packages, works with 3rd-party applications such as ArgyllCMS + dispcalGUI. Lacks an ambient sensor, though.
Colormunki Display & i1DP: Similar (if not identical) hardware. X-Rite quotes a difference in measurement speed, although that might be their software at play (really, really unsure; there might actually be a hardware difference, as I might have read once that the Colormunki is somewhat slower even on ArgyllCMS). The i1DP has an SDK available and 3rd-party applications support it without reverse-engineered drivers.
Paid 3rd-party software such as CalMAN will only support the i1DP. Open-source 3rd-party software such as ArgyllCMS (and dispcalGUI and HCFR which work based on the ArgyllCMS library) support both sensors, albeit with a reverse-engineered driver for the Colormunki Display.
Feel free to add this to the OP, wntrsnowg