Colorimeter spreadsheet for SpyderTV - Page 7

Greeno, I'm sorry to tell you that, but I checked the differential method and it doesn't work very well. Take a perfect 2.2 gamma dataset, sample it in a few points (the ones you get with Avia or DVE) and run the algorithm - you'll get a higher than 2.2 number. (I've checked it with DVE samples of 20,40,80,100 and got an error of ~0.2)

The reason is that Y1-Y2/(X1-X2) isn't really a dY/dx, but an approximation. Since we've got pretty few points, the total error is big. I'm guessing with Avia it will be smaller though (more sampling points).

This method will work well when you have a lot of sampling points.

The original raider's method (bar small number correction) combined with my BIAS/GAIN calculation gets much closer result (easily verified even visually comparing the reference and the acquired gamma graphs).

Of course you're right that a forward difference is only a first order approximation and will improve with more data. In my testing on 4-5 dataset (and I also played with an ideal curve or two), I get a gamma approximation (average of the pointwise values) that is spot.

I don't have your implementation so I can't judge it, nor do I want to. I offered this reference up just to provide some additional technical info that avoids the problems associated with more simplistic ways of calculating gamma.

Thanks for the feedback.

Best,
jeff

Can anyone take a look at my speadsheets for a standard GetGray calibration, versus my SpyderTV calibration? I would like to know which is more accurate. I attached both speadsheets in the zip file.

Thanks!

just want to say thanks to everyone in this forum, Brian Hampton for his ancient writeup on calibration, URSA, the faq's, radar the spreadsheet maker, I've personally been gathering and trying to understand/absorb as much about grayscale and color temp calibration as I could the past few days.. a subject I admit I wasn't really that interested in before since it involved delving into the service menu and I just didn't want to spend my time deciphering every single SM setting there was I'd rather be enjoying my set

anyhows since I got a Sony KDL-40xbr2, where there was surprisingly White Balance controls in the user menu, I knew right away that this was it.. so I tried reading as much as I can and absorbing stuff and eventually I jumped into it

anyhows my previous avia calibrations:
http://fate-owns.us/imgs/misc/HomeTh...colortemp1.jpg
http://fate-owns.us/imgs/misc/HomeTh...-avia-rgb1.jpg
http://fate-owns.us/imgs/misc/HomeTh...ammacurve1.jpg

I wasn't really that satisfied so I did things over again under DVE:
http://fate-owns.us/imgs/misc/HomeTh...-dve-6500k.jpg
http://fate-owns.us/imgs/misc/HomeTh...rgblevels1.jpg
http://fate-owns.us/imgs/misc/HomeTh...DVE-gamma1.jpg
http://fate-owns.us/imgs/misc/HomeTh...ammacurve1.jpg

now is it *perfect* ? No.. it is not, but for me, it's better than it was pre-finetuning ^^ Thanks again everyone, -off to enjoy his set and maybe rewatch some old movies again

Hello rader, everyone

First, many thanks and appreciation for posting and maintaining the spreadsheet. Great job.

I've finally got some time to review it thoroughly.
Below are my inputs, hope you find them useful.

1. RGB from input XYZ calculation, using the matrix specified in F56..H58.
The values specified are of the matrix used for transforming XYZ->RGB of the sRGB color space (not Rec. 709 RGB as specified in the above comment). Hence, caculated RGB values (actual: I56..K65, ideal: J72..L81) are inadequate for RGB Error calculations, and for estimating per-component gammas.
Furthermore, even if the correct Rec709 XYZ->RGB matrix was used, it applies only to HD signals, as SDTV (480i and 576i) use different RGB color spaces (different primaries), hence have different XYZ->RGB matrices (SMPTE RP 145 for 480i and EBU 3213 for 576i).
The user must be able to choose the standard being calibrated - either 480i, 576i or HD - and the matrix values should change accordingly. This assures the calculated RGB values correspond to the correct color space.

2. Gamma estimation
Terminology for the following section:
gamma: exponent _approximation_ (power function approximation: y = x^gamma)
gammaE: gamma used at encoding
gammaD: gamma at decoding. CRTs have intrinsic 2.5 gammaD (due to its built-in relationship betweem voltage input and light output in the electron gun)
transfer function: an explicit formula which defines the correlation between linear-light component and the gamma corrected video signal

When color is encoded (camera side), the Rec. 709 transfer function is used:
V' = 4.5L ; 0 <= L < 0.018
1.099(L^0.45) - 0.099 ; 0.018 <= L <= 1

(lets disregard the linear part for the following discussion)

Due to the scale factor and offset, stating Rec709 has a gammaE of 0.45 is wrong. When approximating this function to a pure power function, you'll get gammaE of about 0.52.

Futhermore, the inverse transformation, L = ((V' + 0.099) / 1.099) ^ 2.2222 simply describes how to recover the scene's linear light RGB values, NOT the RGB values produced by the display's transfer function - which is ofcourse unknown and _should not_ resemble rec709 inverse transformation.
For example, if a CRT is used, then its intrinsic L = V' ^ 2.5 is applied, resulting in an overall (end to end) gamma of 1.3 - suitable for dim environment watching.
I think we should assume display devices try to mimic CRT's intrinsic 2.5 gammaD, hence assume their transfer function is of the type L = (V' + e) ^ gammaD, where 'e' is an error introduced by the zero signal not truely displayed as black.

How this applies to the spreadsheet?
I think all gamma estimation caclulations, which assume display transfer function is similar to the inverse of Rec709 transfer function, are incorrect.
See V56, W56, P72, Q72, R72, S72, T72, U72.
I think that the "+0.099)/1.099" (offset and factor adjustments) should not be used.

GammaD should be estimated using the simple "L=(V'+e)^gammaD" model.
Since you already deduct black level error when normalizing Y values (see P56, formula is deducting Ymin value for normalization purposes) - you are left with even simplier model: L = V' ^ gammaD.

(and thanks to Poynton's excellent "Digital Video and HDTV" ...)

3. % RGB error
Error is calculated as the relative difference between actual RGB values (I56..K65) and the "ideal" RGB values (J72..L81).
However, the "ideal" RGB values are calculated using the _actual_ normalized Y, not the ideal normalized Y (see J72 which refers to D72,E72,F72 which all refer to P56).
Hence, we have RGB errors measured from the reference white point at the luminance level produced by the display (that has non ideal gamma).
An alternative approach might measure the RGB errors from the reference white point with an _ideal_ luminance for the input stimuli.
I'm not 100% sure, but I think that the current implementaion is indeed the desired one, however the issue is debatable...

4. Redundant calculations of ideal X Y Z (D72..F81) and ideal R G B (J72..L81).
Ideal X Y Z are calculated in order to derive ideal RGB values.
However, in any color system, _by definition_, the <1,1,1> RGB triple represents the system's reference white (with Y = 1), and any RGB triple whose components are equal, e.g , represent the reference white with Y = a.
Hence, ideal R G B values (J72..L81) must always be equal to one another, and their value must always be the same as Y (cell E72).
No need to calculate X and Z, no need for the XYZ->RGB matrix multiplication.

Again, many thanks.
Hope my comments make sense

Ok, I've run through about 7 runs and got RGB error under 10%, and De under 4 except for 10% and 100% (it's at 5 for 100%). My color temperature hovers within 200K of 6504K, except at 0-10% irE.

I'm concerned I should be higher overall with the grayscale in order to keep contrast ratio maximized, but maybe this is not a concern as I had to reduce overall contrast by a bit in order to reduce red clipping at 100% IRE. Any input on this?

My main concern is gamma. It is at 2.88. What is the most effective way of getting this down?

Thanks

Hi all,

Ok, I've finally wrapped up the calibration of my Sony GWIII with Radar's spreadsheet, a SpyderTV, and GetGray. I ran it using Theatertek 2.4 using Purevideo process in VMR9 over DVI at 720p.

My results are pretty good, as you can see from the attached images, other than a bit of red runout which I can't seem to eliminate. I got gamma down around 2.3 which is perfect for my viewing environment (fair amount of ambient light).

Questions:

1. With this spreadsheet, is there any way to measure my contrast ratio?

2. I had to increase gamma significantly (UGAM setting from default 0 to 8) to get it into the ideal range of 2.2 to 2.5. Obviously my darks are no longer as black, but I have much more detail in them, but I also now see a lot more grain. Is this normal? Or should I be adjusting something else to compensate for this?

3. Is it safe to assume 1080i over component will have the same settings (HD-PVR, can't run the disk)?

4. I adjust CBOF for 1080i component down to 8 from 31, as per UMR's GWIII recommended settings. Does this sound accurate?

5. Finally, I'm going to post my end result SM settings here for anyone to comment on and possibly provide feedback on if things look accurate or not:

RDRV - 130
GDRV - 129
BDRV - 104
RCUT - 252
GCUT - 242
BCUT - 243
UGAM - 8
AXIS - 2
Contrast (Picture) - 60
Brightness - 39
Colour - 29
Hue - 32

Thanks,

Joe,

I actually personally would prefer the before calibration gamma curve that you posted to the post-calibration one. Granted it's too high (you said ~2.88) but it's a smooth, properly-shaped gamma curve for the mostpart. I'm very familiar with the GWIII's as I owned one myself (a 60" XBR950) for close to 3 years so I can attest to mine calibrating similarly to yours.

There are a couple things I see with your calibration that you could probably improve upon. One is the aforementioned gamma curve. The other is that the red gamma curve (as you see) climbs faster (i.e., is lower) than green and blue and subsequently begins to hit its limit sooner (as seen from the highest levels not being as bright as they should be going by the gamma curve). I would suggest you back off on the picture setting slightly to get more headroom for red (ending up with something in probably more like the 56-58 range instead of the 60 you're now using) and lower UGAM to more like 4. Then (if needed) lower RGAM separately a notch or two to bring the red curve down to match the green and blue ones. And of course touch up on the grayscale at that point too. If you find that you're not clipping on any of the colors at all at that point you could bring UGAM back up a bit to get closer to 2.222 (but right now you look like you're clipping all 3 with pretty bad clipping on red).

Also, you're using an AXIS value of 2 - did you adjust the color decoder settings RYR, RYB, GYR, and GYB separately or are you just currently accepting the severe red push you most likely have as a result?

Thanks great advice and i will try it tonight. i"ve switched to axis=1< which i think has ryr and ryb lower than axis=2.

i thought that since all rgb error were within 10% i was ok, but i guess the gamma curve needs to be more smooth, and the clipping is affecting it mostly right now

by backing off on contrast, aren't i severely reducing my contrast ratio?

btw, what did you trade up your gwiii for?

Yes you'll probably reduce contrast ratio, but not by all that much given that you're clipping right now. The idea is you want to hit the max level you can without clipping any of the colors. As I recall on my XBR950 that was with a picture of 58.

As for what I'm trading up for, it was originally going to be a 70" XBR2, but my order was cancelled on me, at which point I decided to re-evaluate. Now my order (which with any luck I'll be getting tomorrow or Wednesday in the absolute worst case) is a Pearl (projector).

Googer,
I adjusted things as you suggested, gamma to 4, contrast to 59 from the above settings, and then some grayscale adjusting, and here are my results. Much better than before and I think I am done unless there is something you or anyone else feels I should make.

I also adjusted AXIS to 0 which is RYB - 24 and RYR 91. Gamma with this calibration is at 2.63, but I can't do anymore about that. There's is a slight red runout at the end, but I can live with that (unless you really feel I should adjust it).

Picture quality looks fantastic!

here also is rgb error

sorry, here it is

That looks quite good now; as you said, there appears to still be very minor clipping on red but it's slight enough it might not be noticeable. You could possibly toy with increasing RGAM to 5 or 6 (and once again have to retouch grayscale ) and see if you could make it better yet but you would now be getting to the point of diminishing returns. At this point you'd almost definitely see much more improvement by properly playing around with the color decoder rather than accepting one of Sony's presets.

What should I be looking at when adjusting the color decoder? Should I be looking at the color/tint on DVE or GetGray through the red filter? What am I looking for? Or should I assume AXIS 0 is best?

You're looking to move the color secondaries (yellow, magenta, and cyan) closer to their reference points. What you should aim for is to have them form a straight line with the complementary primary color (i.e., blue for yellow, green for magenta, and red for cyan) that passes straight through the D65 point, though I don't know that I've ever seen if it's considered more optimal to put a secondary color closer to the reference point or if it's better to maintain this 'straight-line' approach when one has to make a decision as to which one to go for. Optimal would be to move the primaries to their reference points as well but that's unfortunately not possible.

So in Radar's spreadsheet, when I select GetGray tab and do the xyY values, and have gotten that all naileddown, is the CIE chart on the HD907 tab my CIE chart, or for another evaluation and thus not tied to my calibration.

If so, then I guess I can use that in your explanation, otherwise, when I'm looking through filters at GetGray or DVE patterns, I can't really work to "line up color points".


Thanks,

When sending an HDMI signal from an upscaling DVD player, through an HDMI-switching equipped AV receiver, and then out to the Sony GWIII's DVI-input, is is better to set the receiver and player to output the video in RGB or YCbCr format?
Also, what is the best upscaled resolution to send for the KF50WE610?

Thanks.

I think that one of the most important reasons for calibrating gamma in a TV is to make each luma step have nearly equal perceived weight. So instead of trying to calibrate for a specific gamma we could try to achieve a uniform lightness step size. To do that we could divide the range of lightness from the measured black point to the measured white point into uniform lightness steps and use the corresponding intensity levels as calibration targets. To see how uniform we should expect the lightness steps to be I wrote a Matlab script to plot the perceived lightness steps for a theoretical monitor driven with 5% luma steps. I noticed that for a TV with good black levels in a dark room where the achieved CR might be 5000:1 a gamma of 2.5 yielded reasonably uniform perceived lightness steps. In a different situation with an achieved CR of only 50:1 like might happen in a bright room a gamma of 2.22 yielded fairly uniform lightness steps. These plots are included below after the Matlab code. So, would calibrating for uniform lightness steps be a good idea?

Matlab code:
lightness= inline('(116*x.^(1/3)-16).*(x>.008856) + 903.3*x.*(x<=.008856)','x');
intensity= inline('((x+.099)/1.099).^g .*(x>.081) + (.18/1.099).^g/.081*x.*(x<=.081)','x','g');
y= 0:0.05:1;
gamma= 2.22;
I= intensity(y,gamma);
CR= 50;
I0= 1/(CR-1);
Itotal= (I+I0)/(1+I0);
steplightness= diff(lightness(Itotal));
ymidstep= mean([y(1:end-1); y(2:end)]);
plot(ymidstep,steplightness/mean(steplightness));
grid;
title(['Lightness Step Size: CR= ' num2str(CR), ', Gamma= ',num2str(gamma)]);
maxstepoffset= max(abs(steplightness/mean(steplightness)-1))

Joe, Googer is good at color decoder settings....I forgot about this post....G.B.

I use my Dell 24" LCD monitor hooked to a Scientific Atlanta Explorer 3250HD cable box to watch tv, I downloaded the spread sheet last night and hooked my Samsung DVD player to the monitor and took readings (Using Spyder2Pro with the Filter on).

IRE x y Y
Black 0.289 0.257 0.831
10 0.27 0.196 1.109
20 0.275 0.248 10.577
30 0.278 0.268 38.448
40 0.28 0.279 84.622
50 0.291 0.295 150.262
60 0.297 0.306 220.835
70 0.302 0.314 248.098
80 0.288 0.301 270.456
90 0.307 0.337 363.795
100 0.325 0.342 392.212


The only controls for this input I have are:

Brightness 52
Contrast 63
Hue / Tint 52
Saturation 92

Settings made with the Avia Disk and filters for basic calibration, there is no way to adjust RBG Any suggestions? I plan to test this method out on my 27" CRT TV in Living room this weekend.

Edward

I found a minor spreadsheet error and I also have a question.


First the error: On the "HD Color" tab, in the Delta E plot (top right) the magenta bar is plotting the Cyan data.



Now for my question. I'm discovering that the green primary on my set (Pioneer 6070) is off from the standard as measured with the Spyder. Does this impact the validity of the math used to calculate the red,green and blue errors in the color temperature (i.e. the AVIA tab) ?

Does anyone have the corrected version of the Rader spreadsheet?

Hi

i have a Konica Monolta CA-210 at work can i use this with your spread sheet, it uses x, y, Lv is Lv just the same as Y.

thank you

Why isn't this very useful spreadsheet and info not a sticky??

The forum moved on to using HCFR as the freeware solution. We, obviously, have a low-cost alternative, and since both programs talk directly to the meters, a manual spreadsheet just isn't as useful as it once was (CalMAN originally stood for Calibrate Manually).

Bill

I remember the hours of that manual labor!