Basic Guide to Color Calibration using a CMS (updated and enhanced) - Page 17

Tom:

I am not one to question you but I believe that the above is incorrect in that you forgot to factor in the screen gain...in other words, the answer should be:

(Lux/10.76) * screen gain = fL

where screen gain = real world, as opposed to posted, screen gain.

Am I correct on this?

As always, much tahnks.

The following is for a Mits65833...(CIE u,v)

Now I know I can adjust Red to Ref points as shown, but then the Gamut between Red and Blue keeps Magenta out of its line but still through its ref point. I can adjust out ColorTintRed from Ref to line up Magenta through to Blue..(no saturation controls on the Mits)

Whats the approach i need to take here. Ive tried to line up my secondaries through white to where I would then adjust my primaries at best..

Generally all the following is academic, but I thought the idea was that the meter might be more inaccurate with lower light levels. Basically isn't this related to Y levels? Rather than the typical questioning of levels below 20%, would it make more sense to question levels below a certain Y reading? My RPTV iris can be varied so that 100% Y varies between about 70 and 325. Going off the 0.0063 for a 2.2 gamma at 10%, that gives between 0.44 and 2.05 Y for 10%. That Y around 2 is probably more than the 20% Y with the iris on minimum. My thinking is that for my TV with an adjustable iris, my low-grayscale readings might be more accurate with the iris open due to the greater light output from the TV. Do you see any flaws in this reasoning?

(In practical application, my HCFR RGB readings don't seem to vary much on my Display LT when changing the iris)

yes, it's better to discuss these limitations in absolute rather than relative units. With careful use I have had reliable Y readings from the i1pro down to 0.1 nits (it actually tracked my D2 to 0.057 nits on a plasma). By careful use I mean an extended stabilization period (~1/2 hour), frequent dark offset corrections, and multiple measures averaged together (16). The manufacturer rates it down to 0.2 nits (The D2 is rated to 0.02 nits). As far as color tracking goes, I measured dE < +/- 0.5 for a D65 target down to 0.5 nits. For your purposes if you want to be able to measure a 5% stim at say ~0.2 nits and gamma=2.2, then you need a 100% level which is at least 145.6 nits, but as Tom suggested I would shoot for somewhere around 125 nits and that would put the 5% point at 0.17 nits and the 10% at 0.79 nits.

Is it ok to use TomHuffman's DVD posted in this thread when calibrating for PAL?
(I do have a chart for xyY values)

Another question that I have in mind. Is it possible to determine which colorspace my setup utilize when doing a SDDVD upscale?

Thank's for the reply.

Maby I didn't made my self understandable about the color space. What I ment was how can I check which color space is used when upscaling SDDVD. I've heard that it supposed to use the HDTV-gamut, but it can also use the PAL vs. NTSC-gamut?

I have run in to some problems calibrating my BenQ8720 with neon-glowing reds, but HFCR report everything to be ok. I find this strange and cant find the answer behind the problem. Except maby that the pal/hdtv gamut is much wider than the NTSC. When calibrating with your DVD the levels are a bit off?

Regards

Color Matrix Errors is commonly referred to as "green depression". Green is the most noticeably distorted color when this occurs, but all colors will be effected. The best, and possibly most simple way to check for colorspace missmatch, or Color Matrix Errors, is to look at colorbars through a green colorfilter.

If there are Color Matrix Errors you will se a huge variation in lightness between the colors with green in them.

cheers

/Pär

Here is an example of the luminance shift when the rec.709 equations are used to decode rec.601 encoded material. The outer box is 601(encode)->601(decode), the inner box is 601(encode)->709(decode) The reason this happens is that in 601 encoding the luma (Y') is formed from R'G'B' with the weights [0.299,0.587,0.114] based on NTSC primaries, whereas in rec709 the weighting is [0.2125,0.7154,0.0721] based on HD primaries. The mismatch creates a luminance bump for both red and blue and a luminance hit for green.

I cant see how this is possible with the measurements I did. Ok this is not a professional one, but with a quite good meter. I used the i1pro with the HCFR Software, widely used here on the forum.

I do have a widely desaturated green/cyan (limitations in my 8720). All the points crossing D65. The intensity is very close to the standard. Gray scale tracking is good from 30IRE up to 80IRE where my red drops (on purpose, to output more light.) Gamma is average 2.26 with a little slope at the black's and heights. Gamma compensated in VisionHDP (orginal 2.54, without gammacomp. in Lumagen).
I did over saturate cyan, exceeding outside the gamut-rectangle. I haven't adjusted it yet. What impact does it have?

I do have the config-file if you want to look at it? Or maybe I'll post the screens in another thread.

 

8720.zip 53.1162109375k . file

Which standard are you talking about, color luminance fraction of white luminance? Your file indicates that all colors are ~30% low with respect to white. red/white=(6.4)/(42.359)=.151 for example is 31% lower than the rec.709 spec of 0.213

Best to post any subsequent discussion on specific user files to the HCFR results thread.

Ah, sorry! I should mention that the intensity of RGBCMY+W is measured in 75% windows. W=28,35Y

Main reason why I did measure 75% is because my contrast is set slight to high. Red is maxed out roughly 80IRE (Bad setting, but I wanted the extra "pop" for experimentations). I suspect that these values are good for 75IRE, but not above.

Since the relation is in % of white is should not matter if 100% or 75% is used, as long as same is used for both color and white.

cheers

/Par

PS: Varför inte föra denna diskussion på svenska istället?

This discussion about my private matter will continue on another forum, unfortunate in my native language (Swedish). If someone is interested just shout out!

PS: Okej Pär, lets shoot! Direktlänk

Tom, I think this may be wrong to use for rec.609 targets. Remember that SMPTE-C luminance weighting is not used for rec.601 encoding, they use the old NTSC primary weighting. The rec.601 encoding equations use the weighting I've shown above [0.299,0.587,0.114] [ref. eq.1] This would change the target decoded ratios to:

Red 0.299
Green 0.587
Blue 0.114
Cyan 0.701
Yellow 0.886
Magenta 0.413

What do you think?

Agreed, I'm sure he's got the math right, but then I don't understand why Poynton has the rec.601 luma component with the NTSC coefficients. Note that rec.709 coefficients are consistent with rec.709 primary Y values. Or it could be the case that the encoding coefficients don't matter, all that matters is the original specification - SMPTE-C.

Speaking of luminance errors, Eq. 6 in this document gives the luminance differences when decoding rec.601 using rec.709 matrix as R: + 8.7%, G: -15.6%, B: +4.2%, this is consistent with my post with the color patches above, Poynton calls these DC luminance errors and argues that rec.709 encoding shouldn't be used because of the potential for screwing things up when upconverting and downconverting (I guess he didn't win that argument!) and I get all that. What I don't get is the companion document found here that talks about high frequency luminance errors present in all video signals based purely on the fact that video signals are encoded non-linearly. Gregr, can you explain this one? Again, he uses this to argue against using rec.709 coefficients because the errors are larger using compared to rec.601 coefficients.

zoyd,
This may be totally unrelated but it's my understanding that video HF info is encoded with Negative Weighting, i.e. high frequencies are represented by low frequency detail (over shoot) in the vertical interval.

yes, unrelated, your reference is to mpeg encoding which has nothing to do with my question regarding non-linear RGB->Y'CbCr encoding. The error introduced, according to Poynton, is purely a mathematical one (additivity is not preserved in the logarithm domain) and breaks the principal of constancy of luminance (which is really just a restatement of conservation of energy). Where I don't follow his math is that it seems to only apply to high-frequency components, not the dc components.

I could not find a reference with analog (RGB or YCbCr) graphics, anyway I was trying to illustrate how High frequency information is really represented as low frequency info super imposed over the vertical interval waveform. I'm thinking this is possibly the DC error Poynton is referring to aka HF distortion.

The same concept was illustrated in the that link i.e. the DCT transform shows how average pixel brightness is conveyed in the digital payload as a "DC" component.

Hi, i got my TW1000 from service center with new lamp but with memory erased and needed to do new calibration. The color and gray scale part was not so difficult(i did it many times before), but i still fighting with gamma(not so much experience). When, using HCFR software and patterns and Spyder2 , i get the readings to 2.2 HCFR reference, the picture is too dark and i loose almost all shadow detail in the darkest parts of the picture. Only setting the brightness higher helps, but this changes the gamma readings again...a wishes circle. What i am doing wrong? how to get the gamma right without loosing brightness and with it shadow detail?

Zoyd sent me a note asking that I comment on this, but I just don't have any time for a week or so to get into any detail. The basic issue is a constant vs non-constant luminance system. All of our video source systems (based on YPbPr or YCbCr encoding) are non-constant luminance. Basically a constant luminance system would encode luminance signals using linear RGB components, i.e. it would conform to the CIE concept of luminance. But instead we encode luminance as a combination of gamma corrected RGB signals, which Poynton (myself and most other video engineers) refer to as a luma signal to make that distinction clear. In a constant luminance system we would combine the linear RGB components into a luminance signal and then apply gamma correction to that luminance signal at the source - i.e. we would have Y' = Y(r,g,b) ^ 1/gamma rather than Y' = Y(r^1/gamma, g^1/gamma, b^1/gamma), and then in the display we would degamma the Y signal and recover the linear R,G,B components using a matrix with the degamma'd Pb,Pr signals. i.e. we would have Y = Y' ^gamma, Pb = Pb' ^ gamma, Pr = Pr' ^ gamma followed by YPbPr to RGB matrix conversion. But instead we perform Y'Pb'Pr' to R'G'B' matrix conversion followed by individual R = R' ^ gamma, G = G' ^ gamma, and B = B' ^ gamma. A basic reason this non-constant luminance system was adopted was because the CRT intrinsically performed the individual R',G',B' to R,G,B operations for free and that was important in 1953. So as a consequence of this compromised approach part of the luminance signal really appears in the color difference signals (Pb',Pr' or Cb',Cr' for digital systems). Hence, when the color difference signals are bandwidth limited (as they are in all video systems through analog filtering or digital subsampling/filtering such as 4:2:2 or 4:2:0 digital formats) some of the high frequency luminance information is lost. I don't have time to read and comment on the document you refer to above, but that is the origin of high frequency luminance errors in our video systems. (Actually there is an additional reason in the case of Rec 601 systems because the wrong luma coefficients are also used, but that is independent of a non-constant luminance system.)

Ok,i now know what i did wrong with the lower light parts but i still would need some hel with the upper part. cant get them narow from 70 IRE to 100, the upper end always slipping under 2/1.9 and more. Not helping is that i actualy not shure if
- increases or diminisches the output on the TW1000. the graps ses me not much

Hi Tom,

In your DVD, regarding the color patterns, are they encoded in HD color space or in SMPTC? If the latter, a DVD player set to 480i going via a dedicated VP (assuming with correct colour space conversion) output to 1080p display (RGB) would that be ok to get correct color readings (709 rec RGB also set at display)?

Also listed in your steps, is to set the brightness first as a percentage of 100% Y (White). Wouldn't it make sense to set the contrast to the right FtL for the display type first and then set the brigthness to 10% of what Y (100%) gives at the desired/required FtL since FtL is calculated taking the 100%Y times 0.29 (if using HFCR)?

Many thanks and Regards,
Kopa13

I will this one for Tom as I do not know how he encoded his DVD.



No, because the proper fL for contrast will be impacted by the brightness...is is better to do brightness first and then contrast BUT it is BEST to do interate between the two until an optimal result is achieved...

HTH