Display Calibration Calculator - Page 3

I just downloaded the manual to see what kind of CMS it has. It appears to segment the input colors into six independent sectors. The answer to your question probably depends on how the CMS handles the transitions between the segments. The flesh colors should primarily land in the yellow or red sectors. If you freeze the image (use a DVD player) of a closeup of someone's face, does changing the green saturation affect the flesh color? If not, I would try to get the yellow and red segments as close as possible to Rec 709 or Rec 601 and see how the flesh tones look. If the green sector setting has an effect on the flesh tones then you may have to balance that by moving the yellow segment back out (more saturation).

But BEFORE you do any of the above, make sure the color decoder is orthogonal using the NATIVE primaries as explained above, else nothing is going to make any sense in the rest of your adjustments. AND make CERTAIN that the color temperature (and grayscale) are not being affected by the CMS adjustments. i.e. check the color temp and grayscale AFTER you adjust the CMS. If the flesh colors aren't looking right the answer could be in the grayscale or the color decoder. The other possibility (actually a pretty good one in a product like this) is that the CMS is non-linear. To determine that you need to make the xyY measurements with 75% RGBYCM color windows and also with 100% color windows (you should also do it with 50% color windows but you probably don't have a source of them). You should get the same xyY results with both 75% and 100% (and 50%) color windows (Y as a percentage of white). If the CMS isn't linear (a fair chance here it isn't) then that will never allow you to get accurate color and a lot more seat-of-the-pants compromising will be necessary to get reasonable color.

It's certainly odd that the CMS doesn't have enough range to get green into position. Even when you reduce the green component of the green sector? That is a clue to me that the CMS may not be linear.

Did you follow all of that? If not feel free to ask questions before you do a lot of work.

Ah.... the green is less saturated than Rec 709. Surprise! I just guessed it was way more saturated than Rec 709 because that is so common these days. So what is the x,y position of green?

Thanks Bill. That isn't bad at all. If the Y value is correct (0.7152) that's a dE of just 3.9, which is pretty negligible.


That's a bit more error in red than I would like if I were targeting Rec 709 (it's closer to SMPTE C), but it's not too bad a shift for red (a shift of about 3 dE from 7.7 to 10.4) if the Y value is correct and holds between 75% and 100%. Do you know how much the Y values are changing? If they are changing very little than I would consider this relatively linear, at least between 75% and 100%.

I need to go out for a while. I'll respond again later if there is some Y value info.

The shift in Y for blue actually reduces the error at 100% compared to if the Y value stayed the same as for 75%. From a practical point of view errors less than dE=3 are nearly insignificant in real video images, so the blue primary errors are negligible. A shift of 1 dE, such as occurs for green is practically undetectable in real video images, and even a shift of 2 dE would be very hard to spot except under really special conditions. So the linearity here is really very good (congrats to Samsung for doing that right!) but you would like to be just a bit closer on the red primary to comply with Rec 709. The red primary is really in the middle between Rec 709 and SMPTE C. Red relative to SMPTE C - dE=5.8 at 75% and dE = 8.2 at 100%. I added the dE values compared to Rec. 709 below.


Yes, grayscale errors always help to create color errors. But this is not bad performance at all for an LCD display.

Yes, once someone told me what product you guys were trying to calibrate I downloaded the manual and saw the type of CMS controls it had. You confused me earlier when you said you couldn't change the x,y point of green. That made me think you had no CMS. But obviously you can change the x,y point of green, just not to where you really want it. Anyway, the errors in the numbers that Bill provided are not too bad as I discussed above. The biggest error is really in red in Bill's case, but that could vary with different units and different cal's. Nevertheless, if you are getting values close to dE=5 or less (as is generally the case here) you are doing pretty good. dE of 3 or less for the primary colors is really good, especially if the CMS adjusted gamut is linear (as it is here). I sometimes see people calculating dE values to 2 or 3 decimal places and that is just silly. No one can recognize those kinds of differences, and one decimal place is enough to check the linearity itself.


The errors are small enough that I would always adjust for the best agreement with the Rec 709 targets. There is no need to worry about discontinuity issues across the CMS segments with errors this small.


It's not important that the lines intersect at the white reference point when you are adjusting a CMS. You should be adjusting for minimum dE error vs the standard target at each primary and secondary. There is no practical significance to where the lines intersect in that case. The significance to where the lines intersect describes the performance of the color decoder, which can only be assessed relative to the native primaries, or if the pseudo primaries are created using a simple RGB to RGB linear matrix transform (sometimes called a 3-axis CMS). But when using a 6-axis CMS (which is what this is) there is no longer any significance to straight lines intersecting at the white point in the final calibrated result. (Don't let this confuse you, but the 6-axis CMS is really a non-linear transform made up of 6 linear color gamut segment transforms. The lines pass between segments and therefore are no longer straight lines, but rather two line segments with a break point at the white reference, so they really do still intersect at the white reference point.) So forget about the straight lines when using a 6-axis CMS, although if you get the primary and complementary colors perfect, and the white reference point perfect, they will be straight lines again.

Yes, all that is really needed is a simple 3-axis (RGB) CMS that includes a 3x3 linear matrix multiple to convert one set of RGB values relative to one (standard or pseudo) color gamut to another set of RGB values relative to another (native) color gamut. The math is simple and the hardware implementation is easy. The only "catch" is that the transform must be executed on linear RGB values and not the R'G'B' gamma corrected values of the input signal. That potential (cost savings) error is the primary source of CMS non-linearities in bad implementations. The luminance balancing of the pseudo-primaries can be done in several ways, but simply remixing the grayscale using the resulting pseudo-primaries is sufficient. That automatically produces the correct complementary xyY values as well. An added bonus is that the user (or calibrator) only needs to adjust 3 primary colors for x,y (plus the grayscale) and not 6 colors for x,y and Y (plus the grayscale). Of course the YCbCr->RGB color decoding must also be correct (orthogonal) in the display.


The 6-axis CMS is really a marketing "feature" in a display. (In an external processor, a 6-axis CMS can be a benefit to help correct for bad color decoding or other non-standard color processing in a display, but in a display all of those things are already under the control of the manufacturer.) As I said above, it is easier to implement, and easier to correctly adjust (i.e. it is likely to produce better results in actual practice), a simple 3-axis CMS. But what manufacturer is willing to sell a display that only has RGB gamut adjustments to mess up when its competitors have RGBYCM gamut adjustments to mess up? (The answer was Yamaha, that provided both in its 1080p front projectors.)

Once you go to a 6-axis CMS there are lots of ways to implement it, but a simple basic approach is to divide the color gamut into 6 segments, each centered around one of the primary or complementary colors. Each segment shares boundaries with its adjacent segments. You can compute the angle of the incoming video signal very easily to determine which segment the signal falls into at any instant. Then each segment can be treated separately as its own 3-axis linear transform similar to the simple case above. (That is why I asked earlier if the green segment adjustments affected the out-of-segment flesh colors in this display.) It is necessary to deal with potential noise effects along the boundaries between segments, and again you must do all of the calculations using linear RGB signals and not gamma corrected RGB signals. White/gray signals (equal RGB component values) are treated as a special case, which can then retain the original calibrated grayscale if done right - but other things can also be done with white/gray calibration. The realtime hardware implementation of a 6-axis CMS system is more complex and can be done with a complete 3-D LUT (lookup table) which is normally not used because of cost implications in a product like this, or can be done with a pseudo 3-D LUT and interpolation (less expensive), or it can be done with parallel multipliers and other computational logic. The human interface functions to allow the CMS to be adjusted can sometimes get more complex to design/implement than the actual CMS implementation functions. The human interface in the Samsung is simple and effective.

(In answer to the question asked above by thomasl) Since the 6-axis CMS has independent linear color gamut segments (in general) the minimum overall color accuracy error is achieved by minimizing the color error of each segment at its reference color (primary or complementary color). Lines connecting primaries to opposing complementary colors will be straight lines if the CMS can be adjusted to the ideal targets and reference white, but if not, then the connecting lines will consist of two segments that break at the white point. There is no advantage (indeed there is an accuracy penalty) to manipulating the segment reference colors by introducing larger errors in their x,y positions just to create straight primary-complementary connecting lines.

Tom, attend "School 1" and minimize color errors. See my answer at the end of my post just above this one.

I agree that flesh colors are very important, perhaps the most important single noticeable feature. But dave999z said above that changing the green segment (as an example) had no effect on the flesh tones except perhaps at some extreme adjustment limit. So why adjust any segment that doesn't affect the flesh tones to create more error in that segment? Sorry, but I just don't get it. (I can see the red color error on a stop sign, or a bottle of Heinz Ketchup, or green error on fields where the green primary is out of whack - see the JVC DLA-RS2) Anyway, Caucasian flesh colors normally fall into the yellow or red segments. If you adjust those segments for minimum error and still don't like the skin colors, then you need to consider the reference white point and the grayscale tracking as the possible reason, or perhaps the accuracy of your color measuring equipment, or some other explanation. But the bottom line is this - when you are happy with the color, regardless of how you got there, stop tweaking and start watching!

Bill, Absolutely! I made exactly that point a couple of times earlier in this thread - read back farther. As I said earlier, you must first adjust the color decoder for orthogonal performance with the native primaries, then adjust the CMS.


I agree it shifts the color errors around. If you have no CMS, then shifting the complementary colors with the Hue control (not the Color control which leads to bigger problems) may improve the overall color accuracy, but it may also make it worse at critical colors like fleshtones. It really depends on the positions of the primaries and which complementary color is optimized. Improving yellow can often improve fleshtones, while optimizing cyan at the expense of yellow may make them worse. What it really boils down to is trying to compensate for a fundamentally inaccurate system with inadequate adjustments is a subjective crapshoot, and that is what you sometimes end up with.


Absolutely, but there seems to be a strong pull in the force here for people to "toe a straight line".

That is a choice created by misusing the calculator.

I don't know how many more times I have to say this - The Calculator is designed to help you calibrate a CMS to get "Yellow and Magenta to as close to the 709 standards as possible". That is why the Rec 709 (and SMPTE C, and EBU) color standards have default buttons in the calculator.

It is really a MISUSE of the calculator to use it to adjust a CMS to get "straight-lines" connecting the primary and complementary colors when the primary colors are incorrect. There is no rationale for doing that. If you do that, you are choosing to calibrate to a custom target with no rationale for why that would give you more accurate color. That is a choice you would have invented - not the calculator. (The calculator allows you to create that choice because it allows custom targets. There are reasons you may want to use it with a custom target - to use other color gamut standards, or with the measured native primaries to test external processors, etc. But it was not intended to be used to force "straight lines" while calibrating a CMS because there is no logical justification for doing that.)

The Calculator is also used to adjust a color decoder with the display's native primaries. That is a different use - an additional step before adjusting the CMS.