

Thread Tools 
That would be great to see. When you do it, please make clear what you mean by "Samsung" primaries, because there are two options: (i) the default Samsung xy primary points (all of which differ from 709), or (ii) the "as close to rec709 as Samsung can get" xy primary points (in which case only Green differs from 709, but is closer to the 709 point than it is if left in the default Samsung position).
If that makes any sense.
By Samsung primaries I mean the native positions (xy) and Y of the primaries as they come from Sammy. However I mentioned the idea of pulling the green primary towards red to see whether there is a point for green that would result in a lower dE for green. BTW, any movement of green towards red would also result in lower dEs for both magenta and cyan.
I only bring up green because that is the primary in my Samsung that is the most off, and, more importantly, it is the only primary that can be "moved" (perhaps) to a lower dE location. Blue is spot on, and red is off a little with too high a y value, but nothing can be done with red to get lower the y value. (All the primaries can be "pulled" towards the two primaries across the triangle. None can be pushed away.)
I didn't mention it before, but I'm also going to do the calibration both ways, methods 1&2, using 75% saturations.
No matter how it's done, aside from dE measurements, it's purely subjective which method looks better. At least dEs are objective. I just hope all pertinent factors are included in dE measurements (factors such as the definition of secondaries being complementary to primaries, which I believe would mean the line would need to pass through white and be on the line between the other two primaries. I know Greg says it isn't necessary and clearly he knows orders of magnitude more about this material than I. That's why I'm going to redo my efforts to calibrate his way and hope it looks good.)
Sponsored Links  
Advertisement 

No matter how it's done, aside from dE measurements, it's purely subjective which method looks better. At least dEs are objective. I just hope all pertinent factors are included in dE measurements (factors such as the definition of secondaries being complementary to primaries, which I believe would mean the line would need to pass through white and be on the line between the other two primaries. I know Greg says it isn't necessary and clearly he knows orders of magnitude more about this material than I. That's why I'm going to redo my efforts to calibrate his way and hope it looks good.)
There really aren't two distinct schools of thought on calibrating a CMS the way there seems to be with setting color decoders. What Greg was referring to was some fundamental attributes of the CMS in question. In a 3x3 linear RGB CMS, the relationship of the secondaries to the primaries is maintained. In a 6way CMS, these relationships are, necessarily, broken. In this latter case, you want to minimize the dE at each of your measurement points (RGBCYM) irrespective of what it does to the linear relationship between the primaries and their complements.
Make sense?
Bill
JUST when I thought I was getting it along comes this interaction. ... What is the distinction between adjusting the color decoder and changing things in the CMS? How do I adjust the color decoder???? and how does this help with adjusting the cms if the cms is to be adjusted to a standard (Rec709)?
Guys, I'm running out of time I can spend on this, but I'll answer anyway. This is really basic so my sense is that if you didn't know this you need to get some more basic video system understanding from somewhere before you try to use tools like the Display Calibration Calculator and adjust a CMS. i.e. if you didn't know this, there are probably other things that will cause you problems too.
The color decoder is a function in the display that converts YCbCr (digital) or YPbPr (analog) signals to RGB signals. The display must ultimately have RGB signals to drive its LCD or LCoS panels, it's DLP chips, its CRT, or whatever physical mechanism it has to produce an image. But video input signals are almost always (except from computers) YCbCr or YPbPr signals. The CMS also needs RGB input signals and outputs RGB signals. So the CMS occurs after the color decoder. They are two entirely different functions, and a display will have a color decoder even if it has no CMS.
The YCbCr/YPbPr input signals were created (encoded is the proper terminology) from original RGB signals (in a camera or a filmtovideo telecine suite) using a transform specified by the Rec 601 (standarddefinition) or Rec 709 (highdefinition) standards. The encoding is different for SD and HD formats. So every display has a color decoder that should conform exactly to the inverse of the encoding standards, using different SD and HD matrix equations to convert incoming YCbCr/YPbPr signals back to the original RGB signals. So there are independent SD and HD color decoding matrices in the display, and either or both could be wrong. This is a completely separate function and a completely different issue than the matrix conversions involved in the CMS.
The color decoder typically has two user adjustments, the Color control and a Hue (Tint) control. If the color decoder is correctly designed, there is one and only one position of those controls that produce the original RGB signals from the YCbCr/YPbPr input signals. If the color decoder is incorrectly designed, there is NO position of those controls that produce the original RGB signals. My point is that these are not really user controls, they are calibration controls to get standard color decoding of the input signals. (But unfortunately sometimes they have to be treated as user controls and I will get to that in a moment.) Ordinarily, if the color decoding is designed correctly, then the default positions of the Color and Hue controls will also be the correct calibrated positions. But sometimes the Color and Hue controls are internally set wrong at their default position, so it's always necessary to check and adjust them if they are wrong. Sadly, there has also been an absurd number of instances where the color decoders are mismatched to the input signals because of firmware bugs, carelessness, or unfortunately even incompetence. By mismatched I mean the display automatically selects to use the HD decoding matrix with SD input signals, or visa versa. If that happens you may be just out of luck with that product, or it may eventually (if you live long enough) get fixed by a firmware revision, or the display may provide manual SD/HD color decoding matrix selection in a menu so you can override incorrect auto selection. Finally, there is also the unfortunately too common case where the signals pass through a source or intermediate processor device, where the SD/HD encoding gets reversed, or the signals are upconverted from SD to HD but the encoding matrix is not changed from SD to HD (this happens in some DVD players). So for all of those kinds of reasons, you MUST check to make sure that the color decoding is working correctly with the sources that you use.
A person with a little experience can look at a color bar test pattern and within a few seconds tell whether or not the encoding/decoding matrices have been mismatched. If you want to get serious about video you should learn to do that. But it is not so easy to detect if there are simply errors in the matrix equations, or Color or Hue calibration errors in the color decoding. To do that you must measure the primary and complementary colors, both the x,y and Y values (although if the x,y positions are correct, the Y values are normally also correct). When the color decoder is working correctly, the complementary colors will lie on that famous line that connects the opposite primary and the white point. This is what the now infamous (in this thread) straight line will tell you. It tells you if the color decoder is "aligned" (uses a matrix with all the right coefficients) correctly (and the technical term for that is that the color decoding is "orthogonal"). BUT you MUST make these measurements using the NATIVE primaries of the display. Obviously, since a CMS can move the primary and complementary colors around arbitrarily, you can't check the color decoder accuracy when a CMS is operational. So the Display Calibration Calibrator allows you to enter where the NATIVE primary colors AND the reference white point are located and it will calculate for you where the complementary colors should lie (i.e. what their x,y points should be on the infamous straight line). Also it is possible, but not likely, that the color decoding could still have Y errors, so you can also check for the correctly calculated Y values with the calculator. The color decoding MUST be checked against the measured native primaries of the display and not against standard primaries or any primaries created by a CMS.
So in many cases this is primarily a check function, but it also allows you to adjust the Color and Hue controls to calibrate the color decoder if they are incorrectly set at the factory. But if the complementary colors are significantly incorrect for your native primaries, there may be little you can do about it. The major things you can do is to adjust the Hue control to rotate the position of the complementary colors around the color gamut triangle, adjust the Color control to improve the saturation or Y values, and/or adjust the white point slightly away from D65. The latter can actually produce good results with certain types of color decoder errors and your eye will adapt to small changes in the color of white.
Unfortunately, some displays have major color decoding errors on purpose. The reason for that is that the color decoding is sometimes designed to mitigate (it can not accurately compensate) for very high color temperatures (9300K or above) that some manufacturers use as the factory default in the products to increase sales. In some of these instances, the service menu may include a set of up to 6 "advanced" color decoding adjustments (or 2x6 for SD and HD) that could allow you to calibrate the color decoder for standard, orthogonal, color decoding. The problem is that these adjustments can be very difficult to understand (i.e. if you have to ask you won't understand how to use them) and you are very likely to mess things up very bad and unless you are very careful, never get them back to the factory setup. You have been warned!
Finally, I said above that the Color control is really a calibration control but sometimes has to be used as a User control. The reason for that is if the primary colors are fixed (no CMS) and you have very oversaturated colors (very common in front projectors) you may have little choice but to use the Color control to reduce overly red skin tones. And depending on the source material, you may elect to change the Color control from DVD to DVD, etc. In this case you are purposely messing up the standard color decoding to compensate for the nonstandard primary color gamut, because you have few if any other options (sometimes you can get some improvement by using a nonstandard color temperature) to get a watchable picture. This is just another instance of trying to compensate for a fundamentally inaccurate system with inadequate adjustments, which is a subjective crapshoot, and that is what you sometimes end up with.
So finally, let me point out that contrary to any assertions this has nothing to do with the idea of adjusting a CMS using some intermediate primaries produced by the CMS to determine where to put the complementary colors on a "straight line". This is adjusting the Color Decoder (not a CMS) with native primaries (not CMS produced primaries) as I discussed on page 2 of this thread as use #1 for the Display Calibration Calculator. Use #2 for the Display Calibration Calculator was to adjust a CMS.
Greg Rogers
Video Engineer/Product Designer
Following up on your comments that the 6axis CMS gives us separate control over the RGB transformation matrix in each part of the CIE triangle, I thought I would do some further experimentation with this. I think if you bear with the long description, you will see that the results support what Bill and you wrote. The context for my comments is still a very limited situation, where the CMS allows us to get close to but not identical to the Rec709 color points in the xy domain, and after achieving the best possible match to the primary colors in the xy domain, two procedures had been suggested for a calibrating the set: calibrate the primary Y values and the secondary colors to the Rec709 coefficients, calibrate the primary Y values and the secondary colors to match the simple XYZ<>RGB conversion matrix constucted by Lindbloom's formulas using the primary xy points.
A couple of points on which there should be agreement:
(a) Were there only three CMS color controls and no white balance, we would have to use the Y coefficents predicted by Lindbloom's formulas in order for redgreenblue to add together to the intended D65 white point.
(b) Given that we have six color controls plus white balance, an idealized CMS would act as if there are six different RGB>XYZ conversion matrices, one for each sextant of the triangle.
(c) Using the Rec709 Y values for the colors intuitively should give a better fit at the primary/secondary 100% saturation points. In other words, if we had some magic Rec709 color flash cards tuned to match the set's max white luminance, were we to compare these flash cards to the colors for the two alternative calibrations, one would expect to see a closer match when the calibration used the Rec709 Y values, because the Y values would match even though our xy coordinates did not.
So my experiment was to simulate this idealized CMS in Excel, to see how it would work given the two alternative calibrations. My assumption was that I started with my best achievable calibration, taking my actual xy cooordinates of the primary colors and their exact complements as the secondaries. The two alternatives were, to use the Rec709 Y coefficients for the six colors, or to use the calculated Y cooefficients implied by taking the primary color xy values as defining the color gamut.
(1) Not surprisingly, if one takes the closebutnotexact primaries with the Rec709 Y values, reversing Lindbloom's calculation of the RGB<>XYZ conversion matrix M, these imply a different white point. With my data this worked out to have (x,y) coordinates of (.314,.337), and HCFR gives this a color temperature of about 6380.
(2) It is indeed fairly straight forward to calculate the RGB>XYZ matrix separately for each of the six pieces of the CIE gamut. When the Y values were set using the actual primaries to define the target gamut, these six matrices are all identical. When the Y values are calibrated using the Rec709 Y cooefficients, the matrices are distinct.
(3) To compare the two calibrations, for convenience I used the RGB values associated with the saturation patterns on the AVSHD disk. This gives 30 points of comparison, six colors times 5 saturations, although six of the points are all white with varying intensities. Here is where things get interesting. Looking at all 30 points, comparing each point against where it should be in a perfect calibration to Rec709 using CIELUV76, the calibration using the target gamut Y values faired slightly better, with an average delta E of 2.02 compared to 2.60 using the Rec709 Y values. For some of the 100% saturation points, using the Rec709 Y value gave a worse error than using the actual gamut, but this seems to be an anomaly of the interaction of lightness with the other coordinates in CIELUV76. Looking at all 30 points, again compared to a perfect Rec709 calibration but using CIE94, the average delta E values were nearly identical, 0.59 and 0.60 using target gamut Y values and Rec709 Y values respectively. And with CIE94, all the 100% saturation points have a lower delta E when calibrated using the Rec709 Y coefficients.
Comparing the two calibrations, one to the other, over the 30 points, the average delta E using CIELUV76 is 1.0 and using CIE94 0.36, so comparing the two sidebyside, you would on average not see a difference, although the differences would be perceptible around 100% red, blue and magenta. I have attached the spreadsheet I used for this simulation experiment, if anyone would like to look through the detail. I hope it is not too cryptic; most of the labels match the relevant formulas on Lindbloom's site.
The experiment tends to say that calibrating to the Rec709 Y values gives a better calibration for the 100% saturation points, matching one's intuition, but that calibrating using the actual primaries to define a new gamut may give an equally good calibration when looking at intermediate points in the CIE triangle. But this experiment was not conclusive, one way or the other. This might be an accident of the actual primary color xy coordinates. It might also be an accident of the 30 data points chosen, all on the edges of the six triangles. I did not expand this to try all 10 million combinations of studio RGB. Nor did I look for any research weighting errors in one part of the CIE gamut, e.g., skin tones, as more annoying than errors in another part. And I did not yet look at whether one calibration did a better job than the other at preserving perceptual distances between points; the comparisons were between the expected points in each calibration and the corresponding intended color in an ideal Rec709 calibration.
Even were the result conclusive, the domain where it was true might be limited, e.g., only in this particular situation of an actual color gamut strictly contained in the Rec709 gamut. Perhaps only in the case where the primary xy coordinates were calibrated to minimize hue error, as I did using CIE94, so they are essentially in line between white and the Rec709 points.
When dealing with a real set, e.g., mine, I can see that the saturation points for each color are not in a straight line, so we know that the actual Samsung CMS varies from the idealized one of six linear matrices. This may be from the CMS itself, or the fact that one cannot get perfect grayscale or gamma linearity either. So, in practice on a particular set, one or the other calibration approach might yield a better result. The only way to distinguish would be to compare the delta E values on all the color and saturation measures. There does not seem to be any magic in using the actual primaries to define a new gamut and keeping straight lines in the CIE chart that would lead to a demonstrably better calibration; when it does, it may be a complete accident.
Â
CMSSimulation.zip 74.51171875k . fileBill, if I take what you wrote literally then you have a misunderstanding. I, and I'm sure Bill (Bear5K), never suggested that you try to match the Y levels from Rec. 709 if you can't match the x,y points. The objective is to achieve minimum dE errors from Rec. 709, and that will not happen with Rec. 709 Y values if you don't match the Rec. 709 x,y points. Again, one purpose of my Calculator is to calculate the dE values so you can minimize the dE errors from the Rec 709 (or other standard). If your objective was to just match the Y values there would be no reason to calculate the dE errors. So I don't know why anyone would assume that matching Y values was the objective. Similarly (again reading what you wrote literally) the objective is not to calibrate the "complementary [secondary] colors to the Rec 709 coeffcients" it is to minimize the dE errors of the complementary colors relative to the Rec 709 (or other standard) target.
A couple of points on which there should be agreement:
(a) Were there only three CMS color controls and no white balance, we would have to use the Y coefficents predicted by Lindbloom's formulas in order for redgreenblue to add together to the intended D65 white point.
But of course there always is a white balance function, so the Y values will be automatically determined when the white balance is calibrated. However, this only applies to a 3axis CMS, and a 6axis CMS may or may not work that way.
There are different ways to design a 6axis CMS, but that is one way.
(c) Using the Rec709 Y values for the colors intuitively should give a better fit at the primary/secondary 100% saturation points. In other words, if we had some magic Rec709 color flash cards tuned to match the set's max white luminance, were we to compare these flash cards to the colors for the two alternative calibrations, one would expect to see a closer match when the calibration used the Rec709 Y values, because the Y values would match even though our xy coordinates did not.
That is definitely not true. Again, that's the point of the dE calculation. It allows you to find the best Y value for a given x,y mismatch that minimizes the perceptual color difference from a target (in this case Rec 709).
I don't have time tonight to look over what you did in Excel, but if I read the remainder of your post correctly you were operating with the misunderstanding about matching Y values.
Greg Rogers
Video Engineer/Product Designer
Bill, if I take what you wrote literally then you have a misunderstanding. I, and I'm sure Bill (Bear5K), never suggested that you try to match the Y levels from Rec. 709 if you can't match the x,y points. The objective is to achieve minimum dE errors from Rec. 709, and that will not happen with Rec. 709 Y values if you don't match the Rec. 709 x,y points. Again, one purpose of my Calculator is to calculate the dE values so you can minimize the dE errors from the Rec 709 (or other standard). If your objective was to just match the Y values there would be no reason to calculate the dE errors. So I don't know why anyone would assume that matching Y values was the objective.
...
Yes, I misunderstood what you were saying.
That does make the calibration a little trickier. When one knows what the target Y value is, either the Y coefficient from Rec709, or the calculated Y value using the primary color xy coordinates to define the gamut, one has an actual value to target. If, after finding the best achievable point in the xy plane for minimizing the delta E, one must then find the corresponding Y value empirically that minimizes delta E, that is a little more time consuming. I will have to think about whether that is a calculable target.
Thanks,
Bill
Yes, I misunderstood what you were saying.
That does make the calibration a little trickier. When one knows what the target Y value is, either the Y coefficient from Rec709, or the calculated Y value using the primary color xy coordinates to define the gamut, one has an actual value to target. If, after finding the best achievable point in the xy plane for minimizing the delta E, one must then find the corresponding Y value empirically that minimizes delta E, that is a little more time consuming. I will have to think about whether that is a calculable target.
Thanks,
Bill
Not to be too discouraging, but if you are thinking in terms of dE, you should also remember that a given error level will generally describe an ellipse of some eccentricity around the given target on the xy plane. You are better off thinking in terms of u'v' if you want to describe an error optimization function. THAT being said, we generally find dE(94) to be more useful when working with a CMS from a practical standpoint (dL, dC and dH give clues about what to change where), though this then requires a shift over to Lab. Isn't colorimetry grand?
Bill
Not to be too discouraging, but if you are thinking in terms of dE, you should also remember that a given error level will generally describe an ellipse of some eccentricity around the given target on the xy plane. You are better off thinking in terms of u'v' if you want to describe an error optimization function. THAT being said, we generally find dE(94) to be more useful when working with a CMS from a practical standpoint (dL, dC and dH give clues about what to change where), though this then requires a shift over to Lab. Isn't colorimetry grand?
Bill
My experiences have been that with a good CMS implementation if I hit the x,y target as close as possible and then dial in Y to minimize dE, I can usually get most of the primaries and complementaries within 1 dE, or 2 dE at the most, which is plenty good enough (I prefer dE [CIELUV 76]). In fact, in another thread I'll share some data next week on the performance of an improved CMS for a very popular front projector that has previously had some CMS issues.
Greg Rogers
Video Engineer/Product Designer
My experiences have been that with a good CMS implementation if I hit the x,y target as close as possible and then dial in Y to minimize dE, I can usually get most of the primaries and complementaries within 1 dE, or 2 dE at the most, which is plenty good enough (I prefer dE [CIELUV 76]). In fact, in another thread I'll share some data next week on the performance of an improved CMS for a very popular front projector that has previously had some CMS issues.
And what do you do when the colors on the Accupel Generator and Lumagen Radiance do not begin to agree with each other?
I have noticed some significant different readings using an Accupel Test Pattern Generator and the Lumagen Radiance Patterns. There were some pretty significant differences in the IRE patterns, so before I started to work on a monitor yesterday, I measured RGB at 100IRE from the Accupel and the Radiance. I did a full factory reset on the Radiance as well fwiw.
The Accupel was feeding the Radiance. There are more differences than I would like to see  and the difference on the y axis in the Green is 10%....the blue isn't exactly comforting either. The error in the x axis isn't exactly comforting either.
The fL on the green was significantly different as well.
Accupel Red/Radiance Red
Accupel Green/Radiance Green
Accupel Blue/Radiance Blue
To put it bluntly, I am more than a little concerned when I see things like this as no display calculator will allow you to get the colors correct when there is this much discrepancy.
My experiences have been that with a good CMS implementation if I hit the x,y target as close as possible and then dial in Y to minimize dE, I can usually get most of the primaries and complementaries within 1 dE, or 2 dE at the most, which is plenty good enough (I prefer dE [CIELUV 76]). In fact, in another thread I'll share some data next week on the performance of an improved CMS for a very popular front projector that has previously had some CMS issues.
Greg, I was doing some experiments regarding minimizing errors and was getting some confusing/interesting results at least given what I understand.
Assuming the following yellow location and luminance value scaled to 1. Also assume that it is not possible to add more saturation to yellow. All I can do is change the hue or brightness.
yellow .410, .490, .925
When compared to the Rec709 yellow, this gives me error measures of:
dELUV1976  7.18
dELAB1976  11.04
dE1994  2.11
percent of error:
lightness: 0.88%
saturation: 88.70%
hue: 10.41%
The dE1994 numbers tell me that I'm undersaturated and that is almost all of the error which seems to jive with what I see visually on the CIE chart. The x,y points seem to be optimized as far as hue is concerned (although dE1994 does tell me that if I move it a little more toward red  .411,.489  I can lower the percent hue error a bit but not at an improvement of overall error). dE1994 is telling me that brightness is optimal and if I lower/raise Y at all, the error increases.
But with dELUV, if I raise the brightness all the way up to 1.02 (brighter than white), I can lower the error measure to 5.08 and dE1976 to 9.14 but dE1994 goes all the way up to 3.98.
The error calculations seem to be saying two different things but dE1994 seems to be more reasonable to me in this case since raising yellow's brightness to more than white doesn't seem to make sense. Is this a case of error measures just not being an adequate way to determine color accuracy (or is my math wrong somewhere along the way)?
cheers,
tom
And what do you do when the colors on the Accupel Generator and Lumagen Radiance do not begin to agree with each other?
I have noticed some significant different readings using an Accupel Test Pattern Generator and the Lumagen Radiance Patterns. ...
The Accupel was feeding the Radiance.
The fL on the green was significantly different as well.
The first thing you should do is feed the generator directly to the display. Use digital RGBvideo (or RGBPC) signals from both the generator and the output of the Lumagen. The results should then agree. Then switch to YCbCr output signals from the Lumagen. See if the results still agree. If they don't then you know there is a problem between the Lumagen and the display (probably a color decoding matrix mismatch). If they do agree then switch the generator back to the input of the Lumagen. If they then don't agree the problem is in the input setup of the Lumagen for the generator. Look for a wrong (SD/HD) matrix if using YCbCr signals from the generator, or a mismatch in Video/PC levels if using RGB from the generator.
The fact the green Y is very different between your two setups makes it extremely likely that there is a YCbCr color decoding matrix mismatch somewhere in your setup.
Greg Rogers
Video Engineer/Product Designer
Greg, I was doing some experiments regarding minimizing errors and was getting some confusing/interesting results at least given what I understand....
yellow .410, .490, .925
When compared to the Rec709 yellow, this gives me error measures of:
dELUV  7.18
dE1976  11.04
dE1994  2.11
percent of error:
lightness: 0.88%
saturation: 88.70%
hue: 10.41%
But with dELUV, if I raise the brightness all the way up to 1.02 (brighter than white), I can lower the error measure to 5.08 and dE1976 to 9.14 but dE1994 goes all the way up to 3.98.
The error calculations seem to be saying two different things but dE1994 seems to be more reasonable to me in this case since raising yellow's brightness to more than white doesn't seem to make sense. Is this a case of error measures just not being an adequate way to determine color accuracy (or is my math wrong somewhere along the way)?
tom
You are way off the correct x,y point (0.419, 0.505), i.e. undersaturated. You have an x,y error of (0.009, 0.015). So there is no way in hell that a dE error of around 2 makes any sense (given you have approximately the Rec 709 Y value). That would imply that the error is nearly undetectable. dE CIELUV(76) tells you that you are off dE>7, which makes sense. It also tells you that by raising the luminance (because you are undersaturated) you could reduce the dE error. That makes sense. (I'm suspicious there is an error in your dE 1994 calculation since the value doesn't make sense, but I don't waste my time messing around with dE 1994.)
It doesn't matter that the optimum Y value for the best perceived match is greater than 1.0, because the dE calculation (or the physical matching of colors) is not constrained by any projector implementation. It merely says that for a color with your x,y values you would need a luminance ratio of 1.02/0.9278 to get the best match to the Rec 709 x,y point, per dE CIELUV(76). If your display can't produce that luminance for yellow, so what? That has nothing to do with the best way to calculate color error.
Greg Rogers
Video Engineer/Product Designer
The constraint that the RGB Y coefficients all add to 1 is debatable, but it seems to match my experience with the Samsung that increasing the RGB Y values also increases the luminance of 100% white. Although I have seen measurements where white does not equal the sum of red, green, blue, I attribute these so far to normal measurement variation in the EyeOne, and not to any adjustment of the grayscale gains. I don't think the constraint invalidates the experiment.
As you would expect, your recommendation to optimize the Y values to minimize the overall delta E worked out to be a better strategy than trying to match either the Rec709 Y coefficients or the Y coefficients of a new gamut. Although it gave a slightly higher dE at green, this was compensated for with a better dE at blue. More importantly, over the entire range of saturation points, the average dE94 was 0.59 with a maximum of 1.20, compared to a maximum of 1.37 and 1.26 with strategy 2 (straight lines) and 3 (naive). Also, there were no more anomalies in the saturation data, where some points appeared better in one strategy, and other points better in another.
The caveats are that I ran this only on one set of color points, but as the strategy makes sense it should give generally better results. With some effort, I incorporated a choice of CIELUV76 or CIE94 into the spreadsheet. Using either metric, solving for target Y values to minimize deltaE, gives a better result than either the straight lines or naive strategy. But, the two measures recommend very different optimum Y values. The optimum Y value under CIE94 is worse when evaluated under CIELUV76 than either of the wrong strategies, and vice versa.
Now I need to go try it out on my set, to see if the calculated optimal Y values do indeed yield a better result.
Thanks,
Bill
P.S. I have since relaxed the assumption that RGB Y's add to 1.0 for White, which let's the Excel Solver make a slightly better choice of Ys.
Â
CMSSimulation.zip 74.51171875k . fileNot to be too discouraging, but if you are thinking in terms of dE, you should also remember that a given error level will generally describe an ellipse of some eccentricity around the given target on the xy plane. You are better off thinking in terms of u'v' if you want to describe an error optimization function. THAT being said, we generally find dE(94) to be more useful when working with a CMS from a practical standpoint (dL, dC and dH give clues about what to change where), though this then requires a shift over to Lab. Isn't colorimetry grand?
Bill
Yes, Bill, colorimetry is grand. Last weekend's exercise, following your hint, was to reproduce in Excel the calculations to breakdown grayscale into its RGB components, taking into account how these change when the RGB primary chromaticities differ from the spec. Now this weekend, the fun to use Excel Solver to calculate optimal target Y values so one does not have to use so much trialanderror. With so many "exercises for the student", I'm not sure how much more fun I can stand.
Yes, Bill, colorimetry is grand. Last weekend's exercise, following your hint, was to reproduce in Excel the calculations to breakdown grayscale into its RGB components, taking into account how these change when the RGB primary chromaticities differ from the spec. Now this weekend, the fun to use Excel Solver to calculate optimal target Y values so one does not have to use so much trialanderror. With so many "exercises for the student", I'm not sure how much more fun I can stand.
Probably a dumb question, but are you doing this out of curiosity or to better understand all of this? I ask because the Accupel calculator gives you the optimal target Y values for RGBYCM for any given set of primary colors' xy coordinates and white xyY values.
Yes, Bill, colorimetry is grand. Last weekend's exercise, following your hint, was to reproduce in Excel the calculations to breakdown grayscale into its RGB components, taking into account how these change when the RGB primary chromaticities differ from the spec. Now this weekend, the fun to use Excel Solver to calculate optimal target Y values so one does not have to use so much trialanderror. With so many "exercises for the student", I'm not sure how much more fun I can stand.
If you are taking realtime measurements, you can generally get goodenough results just by watching a zoomedin view of your gamut and your dE measurement. However, you are experiencing some of the pains we've gone through, ourselves. We have a standing offer to help people implement an automated CMS if they use a 3x3 Linear RGB model. The sixway stuff, especially if they have blending functions, make this a lot harder and each impelementation tends to be custom.
Bill
Greg, I redid my CMS simulation to include the strategy you recommended as I now understand it. ... Strategy 1, the optimized strategy you suggested, uses Excel Data Solver to optimize the Y coefficients such that the total error relative to the Rec709 primary and secondary points is minimized, with the constraint that the RGB Y coefficients all add to 1.0 for white. ...
P.S. I have since relaxed the assumption that RGB Y's add to 1.0 for White, which let's the Excel Solver make a slightly better choice of Ys.
Yes, there is no need for that constraint with a 6axis CMS. It is an automatic constraint of properly functioning 3axis CMS, but it is not normally (or necessarily) a constraint for most 6axis designs. (This is similar to the fact that a complementary luminance value will automatically be the sum of the surrounding primary luminance values in a 3axis CMS, but not in a 6axis CMS.)
Greg Rogers
Video Engineer/Product Designer
No! No!! No!!! You still don't get it. The calculator provides the primary and complementary Y values and the complementary x,y values for adjusting/checking a color decoder. The calculator does not automatically calculate the Y values to minimize the dE error when adjusting a CMS vs a standard (i.e. Rec. 709) if the primaries are not exactly the standard. It does calculate the dE values for doing that, but you have to find the Y value that minimizes those dE values yourself by very simple trial and error substitution of the "measured" Y values in the calculator. Once you find those Y values you can calibrate to them. Maybe, I should add that automatic function to the calculator, but I did this for free as a convenience tool for people that understood colorimetry and calibration and would already understand how to use it. I almost regret doing it now.
Greg Rogers
Video Engineer/Product Designer
The first thing you should do is feed the generator directly to the display. Use digital RGBvideo (or RGBPC) signals from both the generator and the output of the Lumagen. The results should then agree.
Then switch to YCbCr output signals from the Lumagen. See if the results still agree. If they don't then you know there is a problem between the Lumagen and the display (probably a color decoding matrix mismatch). If they do agree then switch the generator back to the input of the Lumagen. If they then don't agree the problem is in the input setup of the Lumagen for the generator. Look for a wrong (SD/HD) matrix if using YCbCr signals from the generator, or a mismatch in Video/PC levels if using RGB from the generator.
The fact the green Y is very different between your two setups makes it extremely likely that there is a YCbCr color decoding matrix mismatch somewhere in your setup.
Very strange. A reboot of the Lumagen and Accupel corrected the issue and now I am unable to reproduce it.
which makes sense. It also tells you that by raising the luminance (because you are undersaturated) you could reduce the dE error. That makes sense. (I'm suspicious there is an error in your dE 1994 calculation since the value doesn't make sense, but I don't waste my time messing around with dE 1994.)
Thanks very much Greg  the dE1994 calculation was right  I verified it using Tom H's spreadsheet. I shouldn't have brought up the numerical numbers since comparing dE1994 and dELUV are like comparing apples and oranges or perhaps potato chips. My main question/point was the increase in luminance to compensate for the undersaturation. After restudying the error formulas, I can see why dELUV says increase while dE1994 does not  or at least not nearly as much depending on the case. I think all of this boils down to which error model do you want to "trust" and you work from there. I don't want this thread to turn into a debate on that particular subject.
cheers,
tom
That makes it seem even more likely it was caused by a firmware bug in the projector or processor causing one of them to use the wrong matrix until you rebooted and reset the firmware. I've seen this happen several times in projectors and processors.
Greg Rogers
Video Engineer/Product Designer
Thanks very much Greg  the dE1994 calculation was right  I verified it using Tom H's spreadsheet. ... I think all of this boils down to which error model do you want to "trust" and you work from there. I don't want this thread to turn into a debate on that particular subject.
There isn't anything to debate because you had a very large x,y error of (0.009, 0.015) and one system said that was only a dE error of about 2. That's absurd.
Greg Rogers
Video Engineer/Product Designer
Greg already highlighted again that the Accupel calculator does not in itself give optimal Y values, rather it gives the error measures for a given set of data. So, one could determine the optimal Y values by trying values up and down from the current measured values and see which direction reduces the overall error. Doing this with the Excel Data Solver just provides a way to do all this iterations automatically, without writing the software to optimize a minimum.
To the more general question, yes, I have a lot of curiosity. So far, everytime I've realised I did not know how a number was calculated and decided to reproduce the calculation in Excel, I've learned a lot.
This is just another instance of that. Having worked my way through various error formulas not that long ago, I should have realised that Y has a pretty significant effect on the components other than Lightness, and not an effect one can ignore. But I had not quite got there on my own yet; Greg's comment was one of those, "Duh, I should have realised that" moments.
Not at all. CIE94 has much lower error tolerances than CIELUV. 2.1 in CIE94 is roughly equivalent to 7.2 in CIELUV.
Tom Huffman
ChromaPure Software/AccuPel Video Signal Generators
ISF/THX Calibrations
Springfield, MO
Tom this doesn't make any sense. The error in this case is large, and the CIELUV dE is 7.2, which indicates a large error. So if CIE94 yields a dE of only 2.1, it is giving a huge error tolerance compared to CIELUV, i.e. it says the error is small when it really is large.
Greg Rogers
Video Engineer/Product Designer
It makes no sense only if you assume that that these two metrics report color errors according to exactly the same scale. They don't. For almost any comparison between CIELUV and CIE94 of a single color, the CIELUV number will be much larger, usually 23 times larger. SMPTE established 4.0 as the color error tolerance for DCI. However, this 4.0 is in CIELAB. 4.0 in CIE94 would have been madness.
For example, take this notatypical measurement of a RS1 gamut and the two dE formulas using Rec. 709 as a reference.
x  y  Y  CIELUV  CIE94  
Red  0.664  0.335  0.217  13.6  6.9 
Green  0.296  0.691  0.762  31.1  11.0 
Blue  0.152  0.053  0.072  6.7  2.8 
The CIE94 number is almost always considerably smaller for the same color error. 4.0 is a small CIELUV error, but it is an unacceptably large CIE94 error. They just have to be interpreted with different error tolerances in mind.
When measuring grayscale it is a little different. If you leave the lightness component out of the color difference equation, CIE94 then reports almost exactly what CIELAB reports, and the value is much closer to CIELUV. For example, the three formulas exhibit smaller differences for this bluish white.
y  y  Y  CIELUV  CIE94  CIELAB 
0.303  0.318  1.0  10.3  6.1  6.1 
However, again with the same RS1 measurements, where lightness is again considered, CIELAB actually returns higher numbers than CIELUV.
x  y  Y  CIELUV  CIELAB  
Red  0.664  0.335  0.217  13.6  24.7 
Green  0.296  0.691  0.762  31.1  56.1 
Blue  0.152  0.053  0.072  6.7  15.8 
The ONLY case that I am aware of where CIELUV will report lower numbers for the same color error than CIE94 is with an oversaturated, but too dim, color. CIELUV reports that the lower level of brightness attenuates the color error caused by oversaturation. CIE94 reports that it makes it slightly worse. For example,
x  y  Y  CIELUV  CIE94  
Green 1  0.296  0.691  0.715  26.9  10.3 
Green 2  0.296  0.691  0.521  12.9  13.3 
This is actually my main beef with dE as a metric for color error. There are multiple dE formulas and they all report different numbers. One must be careful to specify the dE formula being used for the value to mean anything.
Tom Huffman
ChromaPure Software/AccuPel Video Signal Generators
ISF/THX Calibrations
Springfield, MO
Tom, I think this also happens when you have an undersaturated but bright color  at least according to my brief experiments. CIELUV reports a lower dE with the higher brightness compensating for the undersaturation whereas CIE94 reports a dE that is worse. In my mind, it seems to boil down to whether you think brightness changes in a color help to offset errors in saturation. CIELUV says 'definitely yes' while CIE94 mainly says 'not really'.
cheers,
tom
It makes no sense only if you assume that that these two metrics report color errors according to exactly the same scale. They don't. ... The CIE94 number is almost always considerably smaller for the same color error. 4.0 is a small CIELUV error, but it is an unacceptably large CIE94 error. They just have to be interpreted with different error tolerances in mind.
Tom, I agree. I'm just saying it seems absurd to me to have a scale where something that is 2x the JND (dE=1 by definition in all systems) is a big error. Why should something twice as bad as something that is barely noticeable under perfect conditions be really bad. It just seems like doubling an error that is just barely noticeable, shouldn't create a huge color difference. In the end fractional differences between 1 and 2 span the range from "doesn't matter" to "I can't live with it", and that as a scale doesn't feel good to me.
I'll admit to being quite biased about using CIELUV. That is because I have used it for years and I have a very good feel for the perceptual differences represented by a dE of say 3 vs 6 vs 10 for green or red. That, in addition to its relationship with CIE x,y and CIE u'v' diagrams that don't exist with the other systems, is probably why we old engineers are perfectly comfortable with it, and very uncomfortable with the other systems that were primarily driven by the paint and textile industries. It's not only "if it ain't broke (for my application, i.e. video displays) don't fix it", but that it has proven to work very well for this application for a long time and it's a common language that I can use to communicate with my (apparently older ) professional associates.
Now, I'll quietly leave the old engineer's retirement home and ride off into the sunset ...
Greg Rogers
Video Engineer/Product Designer
I'll admit to being quite biased about using CIELUV. That is because I have used it for years and I have a very good feel for the perceptual differences represented by a dE of say 3 vs 6 vs 10 for green or red. That, in addition to its relationship with CIE x,y and CIE u'v' diagrams that don't exist with the other systems, is probably why we old engineers are perfectly comfortable with it, and very uncomfortable with the other systems that were primarily driven by the paint and textile industries. It's not only "if it ain't broke (for my application, i.e. video displays) don't fix it", but that it has proven to work very well for this application for a long time and it's a common language that I can use to communicate with my (apparently older ) professional associates.
Now, I'll quietly leave the old engineer's retirement home and ride off into the sunset ...
Greg, CIELUV is fine. I honestly don't think it much matters which dE formula we use so long as we are clear upfront which it is.
Tom Huffman
ChromaPure Software/AccuPel Video Signal Generators
ISF/THX Calibrations
Springfield, MO

Thread Tools  
Show Printable Version Show Printable Version
Email this Page Email this Page


Posting Rules  