Reading and interpreting calibration charts and data for dummies - Page 3

So, if I wanted to do a greyscale on a pj, I should take a primaries measurement first (and make sure the constrain option is unticked which it was when I last looked), then do the greyscale. Does CF remember the primaries data afterwards then and use it to calculate for greyscale better?

Also, and not wanting to appear to be too much of a dummy, but why is the colour temp graph so useless? Isn't it useful to see how far the greyscale was out before being calibrated so a potential purchaser knows how innacurate (or accurate) for greyscale the pj is likely to be?

Gary.

Gary Lightfoot,

Correlated color temperature is not very useful because a color temperature is a line on the xy coordinate system and not a point. The goal is to target D65 as the white point which is at x=0.3127 and y=0.3290. CCT does not describe this point to enough precision to be very useful.

For example, 6500K could be D65 and it might not be. A measurement at 6600K could possibly be closer than one at 6500K to D65. That is why a color tolerancing function like delta E of some form is much more useful.

Here is a link to a diagram that illustrates the problem.

http://www.ecse.rpi.edu/~schubert/Li...%20diagram.jpg

guitarman

Great angle with Optoma firmware there - really am suprised they 'authorized' an 'unauthorized 'service! And you get the calibration bucks to boot while it is there! I have often wanted to clean customers colorwheels (NEC HT1100, SP4805 has a problem) - but no way I would touch it unauthorized - I would have to buy the projector if I had too much caffeine and broke a wheel! If I was guaranteed a dealer or calibrator authorized warranty colorwheel replacement - I would be doing it like crazy - as it makes a huge difference on projectors for which it is a problem! (and I see someone on cheaper projector forum posted same thing about LCD polarizers needing cleaning)

Bob

Ok back to the calibration charts for dummies. I'll let my charts soak in - they make sense to me anyways.

Why is 6500K useless? To explain it you need a CIE chart that has the black body curve on it - I have several copyrighted versions I cannot scan - but if anyone has a handy link. Think of the black body curve as the color of flame (technically incorrect analogy - but close enough) - red flame is warm, white flame is warmer, blue flame is hottest. What nobody realizes is that if you have a different element inflamed - you can actually get a different color than that curve - a green flame or a magenta flame. Think of your pressed christmas log with the wierd chemicals in it that makes the purty colors. To accomdate that - the invented the 6500K CCT (correlated color temperature). to capture those other colors normal (perpincular) to that curve that are the same 'temperature' but a different color.

So if the calibrator or customer or manfacturer focuses on the 6500K chart- you can actually have a major Green or Magenta push to White - yet still be absolutely perfect per the curve. Now it is now small accident that more green means more brighter displays - don't you think manufacturers would love it if we still used this 6500K measures? They can do green whites and nobody would be the wiser. Just like whiter than white Tide is actually a bluing agent....

It should have been dropped a long time ago to give the x,y coordinates in the CIE space - which is how all the video color standards define their greyscale and color points.

Why is RGB barchart useless? As we discussed the % maybe meaningless - already it looks like Ursa, ColorFacts, and umr are using different methods to figure the %. So a % chart across softwares may be meaningless. What if one guy zooms the chart - and the other does not - (this one really annoys me - as the default in ColorFacts is non-zoomed in which everything looks perfect - the first bar is 20% off!) So you label the chart (but the labels are not ever going to be intelligible on a jpeg or 2" magazine offset print).

OK disregrad all that and assume calculates the % and presents it the same way. What does it mean to you as a calibrator? Are your projector control labels for RGB gain/offset correlated with those % labels - NOPE!. Do you really think your customer knows what color a +10%R, -7%G, +16%B is - I have no idea myself!. And if another display is +5%R, +8%G, -12%B - can you tell which display is better by looking at this chart?

So this RBGB chart is really only usefully for getting the bars even. I bet as a novice calibrator - you did not know that when it says more Red, maybe you want to cut the other colors - how do you know which to do based on this chart (you don't) When I calibrate at local meets they are always confounded that I do not move in the directions the RGB bars are telling me - and that is a newbie assumption that I must be doing it 'wrong' I do however use the RGB histogram - solely for telling me when I have reached my RGB clipping points - because the lines will clip.

Greg

I did have an idea to stack all the gamma modes available onto one chart - so you can see 1.8 vs. 2.5 vs. 3.0 and how each of them varies individually. Just not sure how best to present it and still be understandable.

The greyscale chart I found most of my customers have groked it without any explanation - indeed the intent of the chart was to put into a picture what is said with a thousand words about the greyscale (what colors it is pushing to) and do what is difficult to say in words - how much it is pushing. The radius is indeed dC*.

Look at the older charts I just sent you that have bad greyscale - the dots are not cluttered all over the place (I hate the colorfacts report for that very reason!) - because I use L* from the ideal gamma fit to scale each dot. Black dot is always at the center - because black cannot have color. White dot is usually furthest away because White is brightest and can thus have the most color error (it would be more correct to say Chroma or Colorfulness error per Poynton - read his rants about video control names).

Colorfacts prints charts with or without the table of numbers as the calibrator always wants to record the real numbers - but the customer usually just wants the executive one-page summary with just the charts. I have done enough executive presentations in my former engineering career to know - the chart better say what you want it to say - don't make the executive thumb thru tables of data or worse yet - actually read a sentence!

Gary

Yes - do the Primaries & Secondaries measures first. Why Secondaries? If secondaries are off it is color decoder error or grey scale error. It is a lot easier to see your White is Blue by noticing that Cyan & Magenta are blue. Now do your greyscale.

Now retake the Primaries & Secondaries. The Primaries will not change - if they do your sensor or environment is drifiting - but the Secondaries should change!. Secondaries should be on the triangle edges - as well as be on a line thru White to the opposing primary. If not you have basic adjustment error - or service menu decoder error to fix (if the manufactuerer allows it!)

I realize the differences aren't huge, but if the purpose of the RGB percentages is to adjust the RGB gain and bias controls to calibrate the grayscale, it makes those RGB percentages less accurate to calculate them relative to an idealized set of RGB primaries (even if the errors are small). The errors will even be different if you use the Rec 709 primaries, or the Rec 601 (SMPTE C) primaries. So why would/should a user pick Rec 601 vs Rec 709 to constrain to when they give different answers (both wrong)? The only advantage for using some arbitrary set of primaries is that the user doesn't have to take time to let the measuring instrument "learn" the actual primaries. That's reasonable because the errors are usually pretty small, and I would hope the user will ultimately finish the grayscale adjustment by looking at the x,y & dE(dC) values, not the RGB percentages. But the RGB percentages are still more accurate when the instrument "learns" the actual primaries.

So I still don't know why Mark said it was more accurate to use the "constrain" option when calibrating grayscale, but I do believe Mark understands his own product. I suspect we don't know the full context of what he meant, or what he was thinking. Perhaps he meant that if the instrument had previously "learned" very different primaries on another display, and you weren't going to take time for the instrument to learn the new primaries, that you would typically get smaller errors with the constain option.


I presume you just made up these x,y values because the red primary is impossible. The sum of x+y+z must always equal 1. In this example x+y=1.0392, which is impossible because z can not be negative.

Greg Rogers
AccuPel
Widescreen Review

I did just make up some very large errors in the primaries to illustrate the errors are small even in an extreme case. With reasonable primaries the differences are so small that they do not show up on most readings.

My goal in doing the calculations this way is to simplify the process and eliminate the potential error a person could enter into the equation if they measured the wrong color at the wrong time (i.e. red as green). That would provide completely wrong guidance and frustrate the process. I prefer eliminating those huge errors over eliminating some vanishingly small errors that are irrelevant to the process. I also recommend people check their calibration with a delta E function.

Good point, that would certainly frustrate the process without some primary error checking. And as krasmuzik suggested, I don't suppose anyone is looking at the actual numbers anyway. They are just trying to line up the RGB bars by increasing/decreasing the RGB gain and bias controls. When they get close they should revert back to the x,y, and dE measurements to finish the job.

Unfortunately, I need to bow out of this thread tonight. I have articles to write/edit. Publishing deadlines don't move.

Greg Rogers
AccuPel
Widescreen Review

umr - that is when you pop up the big screen saying plug in your AccuPel to get the color ordering right - if you don't have one then click here to order from gregr

Colorfacts wizard has the different order than AVIA PRO DVD- so I know what you mean though! PITA

Even so I still like to put up the primaries/secondaries first - it tells me where I am and what the display nature is before I begin mucking around with adjustments.

Kevin,

I never said you should not look at the color bars first. My measurement wizard puts up the color bars first for a visual check followed by pluge and contrast. This allows the user to confirm/adjust the levels are set correctly, confirms that the proper input type (RGB, YPbPr) has been selected when using a generator and it allows the display time to synchronize to a new resolution so the following tests do not need to wait for sync.

An AccuPel generator is a very useful tool in this process. When one is available and the connection supports color (not composite) the measurement process is highly automated.

Hi Guys,

Thanks for the info.

I do understand the difference between 6500k being a line in color space and D65 being a (white) point, but when you do a greyscale you can see if the RGB values at each IRE that were measured fell on the D65 point on the balck body curve within the CIE (I'm referring to Colorfacts btw). Often the values below 30IRE will fall outside due to the sensors low light sensitivity but generally they should all fall on the same place on the curve and appear as a single dot.

I assumed the color temp graph was just showing us those points as a line from left to right rather than as a set of dots on a curve in the CIE chart - the line is easier to see as the dots (should) all overlap on the BBC and if they're out by a small amount you can't really see it.

If the graph is D65 at each IRE value which is just different luminence of white IIRC, then isn't it a valid graph with respect to D65 acuracy?

I must be missing something but as this is for dummies I can only be helping.

Gary.

Gary

Nope the line graphs are 6500K. You could do a dE line graph for D65 (or another target) - ColorFacts does not do that - you have to pull up the raw data window or report to get it. gregr's reviews do publish that. Whenever ColorFacts forum comes back up - that would be a good chart request to put in though! The problem is that dE does not tell you the color push direction - you need dC and dH for that - or the greyscale polar diagram in my proposed charts. It is basically an improved version of the existing ColorFacts target instrument.

And the RGB line graphs kinda give this info if you could do RGB to xy to dE math in your head. But as we discussed already - the RGB% are probably meaningless.....

umr

I am sure nagware would increase sales - have the nag requestor say send me $$$ and gregr $$$$ to run the RGBCMYWB charts automagically - otherwise click here once you have found the chart on your DVD! Maybe not $$$ - but I know I have paid $$ to get rid of the nagwares!

What do you mean by nagware?

nagware is what sharewares do - pops up a reminder screen before you use it that you have not sent in your money - forcing you to click here to buy a license - or click over there to continue using it. Very effective for demos as long as it cannot be hacked - you can try out the software before you buy - but if you want to be productive - you have to pay.

You may have noticed my Matlab charts are nagware - the university has an educational license given to students - but it pops up these annoying for student use only screens and reports. Means if I want to charge someone for an acoustical report without looking like a rube - I have to payup! (Or figure out how to snapshot the graph only.....)

I see no reason to hastle people who have paid for the software. I am not distributing this on a shareware basis.

That is the point - you hassle those who have not paid! Shareware is a pretty effective distribution system - but obviously something like this that requires a sensor - probably makes little sense. The sensor is effectively the license to use anyways. But that is what ColorFacts Pro demo is - a simulated sensor in the real software. You don't pay for the software - you pay for an all instrument USB dongle key or a S/N licensed instrument file.

I also see no reason to make a demo version with the cost of the Eye-One required to use this. Anyone who wants the least expensive option for a colorimeter is not going to use an Eye-One Pro.

When people ask me how do I learn about calibration so I can decide if it is worth buying an instrument - I tell them to download ColorFacts Pro. Read the help files and play with the instruments and print the reports. Often they are afraid to make the investment because they are not sure they will grok the color science - a demo gets them over that fear.

I honestly don't know if Milori ever made any sales that way - but that is what I tell people when they ask. I certainly cannot spend the time to teach them calibration on the forum!

I do provide the documentation for download which includes calibration information, but I doubt I will develop a demo version.

Actually, for my $0.02, the RGB Bar chart should merely be a summary of the RGB histogram. At least, it is in my little corner of the universe. Since I could not reverse out several of the calculations that ColorFacts does, I gave up pretty quickly on mirroring those too closely. However, the RGB histogram can be calculated in several ways:

1) Calculate the light output contribution of each primary, then normalize each color (100% Stim == 1.0). Then, take an average of the primaries at each measurement point. The end result is that there is no error at 100% stim (Red = Green = Blue = 1.0), and there is a scaling error throughout the grayscale.

2) Calculate the light output of each primary, then create a set of three idealized white lights using one of the primaries from the measured set. Then relate each of these to a CCT graph. I believe that this is how ColorFacts does its histogram. I do not know how this then translates into the RGB% bar chart, but I doubt it is directly related to the CCT primary histogram chart.

3) Calculate the light output contribution of each primary at each measurement point. I then average the RGB blend, and use this for the histogram. Since the output of an XYZ->RGB transformation is normalized under ideal circumstances, deviations from an even "mix" are meaningful, as Kevin has noted. Of course, getting the right XYZ->RGB matrix is a bit of an issue (Poynton is too focused on Rec709, so Bruce Lindbloom's sight is a good second source)!

4 - n) There are several other ways to do this (xyY directly into RGB using a mixed matrix for both XYZ and RGB conversion, etc.), but others can post how they do this.

As a second line of defense, I also calculate an idealized output for each primary using D65 and the luminance measured at each point, giving an absolute deviation from ideal for each primary at each measurement point. It would be pretty easy to convert my crude percent measure into a dH/dC number if it was more useful.

Later,
Bill

Ursa

Yes I think that is the only point - the RGB only has dual states of information - balanced or not balanced. The many different ways of doing it means don't get concerned over RGB% for comparisons. The clipping point info though is very useful if you want to maximize contrast at D65 with or without color filters.

krasmusik,

Thank you for your correction on my previous posting regarding XYZ to xyY conversion which should have read XYZ to RGB conversion. All of the other statements were correct however. For additional information on this subject please check out this link: http://semmix.pl/color/extrans/etr80p3.htm

Here is an excerpt from this link,

"In the case of the transformation of colors from the model of area CIE XYZ to colors RGB it can be happened that result components will have values <0 or, more generally, exceeding interval 0..1. Such circumstances mean that a color from CIE XYZ has not an equivalent in RGB."

Good lord - what manglish translator did they use for that website - more color science links are always appreciated though.

I used those guys as a back-up validation to Bruce Lindbloom, but what's funny is that the XYZ->RGB matrices they show do not match Bruce's. They do agree at between 2 - 3 decimal places, but that's it. Very odd.

Later,
Bill

To get back to a dummy question:

When using the RGB% bars, how do you know when to increase one primary over the other? For example, if there is too much red relative to blue and green, how do you know when to decrease red or instead increase blue and green? I had the impression that the direction you go only affects brightness and may have a slight affect on gamma, but not the color. Should I only follow the x,y and dE coordinates instead?

That's the spiffy think about the CA-6X. I presume it's addressing just maxleung's question. It has a little bubble target where you can see RGB and work toward centering a moving ball which relates to the x,y coordinates. Nice feature for us dummies.

Balancing RGB takes experience and really is about learning the art of science.. It is not just about following the dancing bars and dots - which ColorFacts also has BTW. The pretty pictures tend to make the newbie think it is easy - and I don't doubt that the software vendors want you to think that!

The first thing I do is find the clipping points. Usually for DLP this is Red for gains and Green for offsets. Then I work my way back to the target using the other colors. Knowing that luminance Y is mostly Green - if you do the gamma math you can balance out your gamma curve at the same time as grey scale and doing the clipping check maximizes contrast at the same time. Also knowing that dE is a perceptual error - you can try different moves on the target and see which has less perceptual error if you cannot make things perfect. Other technologies (LCOS, DLP, CRT, plasma) will have different natures - and it requires experience on those technologies to see what works best! LCD tends to have S shaped gamma curves, LCOS tends to be blue limited, CRT usually never has a flat blue across greyscale - and I am sure plasma has something wierd about them too - but I have never done any. When you cannot make it perfect - like all engineering fields you have to learn how to make acceptable compromises.

Combine that with what Bob is learning now - you have to understand the nature of your instruments and the compromises made in making them affordable - and figuring out how to use them for best accuracy, speed, and reliability.

Hey guys,

I don't have long, but did want to clarify a few things:

Greg wrote:

In ColorFacts, the RGB% levels *will* be relative to the display's actual primary colors, if those have been measured. If they have not been measured, the RGB% are relative to the color standard that is in use (HDTV, NTSC, etc).

However, the end result is *exactly* the same. When you get to 100%, 100%, 100%, you have reached the target (i.e. "D65"), no matter what set of primaries were used to calculate the RGB percentages.


Greg wrote:

True.

The idealized primaries are only used if the "real" primaries are not known. It's a shortcut designed to get you into adjusting the gray scale immediately if you don't intend to (or can't) measure the primaries.


Exactly.

Now, a completely different question is how the "Constrain Colors" option works.

The "Constrain colors to gamut" option in the Preferences creates an artificial "wall" at the edges of the color gamut (think WWF), and will not allow any colors to stray outside of this playground. If a color is measured and found to be outside of the gamut (theoretically impossible, but practically actually somewhat common), then that color is relocated to the closest point which is within the gamut (actually, on the very 'edge' of the gamut).

This feature was mainly for a customer in the Aerospace industry who wished to prioritize mathematical accuracy and purity over empirical data integrity.

Leaving this option OFF will make the software always show the raw readings that the hardware is providing, even if that means that a measurement plots outside of the gamut (and causes the RGB calculations, etc. to break down).

This option has *nothing* to do with calibrating gray scale, unless your gray scale is SO far off that it's outside of your RGB color gamut!

I hope that helps!

Mark