AVS › AVS Forum › Display Devices › Display Calibration › Equations to convert xyY to RGB
New Posts  All Forums:Forum Nav:

Equations to convert xyY to RGB - Page 2

post #31 of 55
1/21/09 at 12:36pm
Thread Starter 
Quote:
Originally Posted by TomHuffman View Post

Casey:

I just realized that I had the math for the RGB-xyY conversion. I asked Greg Rogers about this and what he said rang a bell so I went back and looked at my spreadsheets and this was lurking there all along.

This at least shows how Lindbloom gets his numbers, though I don't suppose it helps to answer the question of why RGB-xyY gives different results than a straight linear calculation from the white point to the target color.

1. Start with the RGB values. I'll use 50% red (R100%, G50%, B50%) as an example.

2. Apply gamma to these values. I'll use 2.22. That's what Lindbloom uses. This results in R1.0, G0.2146, B0.2146

3. Use the same math we use for the xyY-RGB conversion, except instead of multiplying the gamma-corrected R,G,B by an inverted matrix of the XYZ of the selected gamut, you multiply by the actual XYZ of the selected gamut. For Rec. 709 that is:
Code:
     R          G          B
1    0.41232    0.21260    0.01933
2    0.35760    0.71520    0.11920
3    0.18050    0.07220    0.95063
For red, this results in the following XYZ values:
X0.5278
Y0.3816
Z0.2490

4. Convert this to xyY, which results in:
x0.456
y0.329
Y0.382

which is exactly what Lindbloom shows.

Tom, can you use your spreadsheet to calculate the xyY with gamma = 1? I wonder if that will yield our linear calculation results... which may be a clue.
Reply
Reply

AVS Top Picks

post #32 of 55
1/21/09 at 2:32pm
Quote:
Originally Posted by hwjohn View Post

Tom, can you use your spreadsheet to calculate the xyY with gamma = 1? I wonder if that will yield our linear calculation results... which may be a clue.

No, not even close.

This is the correct method for converting RGB to xyY. The only question is whether you want to begin with RGB specifications or simply stay in the xy realm.
Reply
Reply
post #33 of 55
1/21/09 at 2:41pm
Thread Starter 
Quote:
Originally Posted by TomHuffman View Post

No, not even close.

This is the correct method for converting RGB to xyY. The only question is whether you want to begin with RGB specifications or simply stay in the xy realm.

Tom,
Is the original method incorrect you proposed incorrect? I guess I'm a little confused as to why gamma shows up in the second calculation but not the first?
Reply
Reply
post #34 of 55
1/21/09 at 2:47pm
Quote:
Originally Posted by stereomandan View Post

Code:
            R           G         B
0%     21.371   21.281   21.282
25%   41.222   15.914   15.966
50%   60.802   10.631   10.632
75%   80.370   5.350     5.300
100% 100.161  0.000     0.000
These are based on the x, y points from my calculations.

Also, you forgot to mention if 190, 95, 95 was what the HCFR guys asked for, re 50% Red saturation. Do you know that 100%, 50%, 50% is the correct values for 50% saturation of red? When I click on 50% Red, HCFR shows RGB% 285%, 49%, 49%, and the RGB numbers above.

I'll take a look tonight at your calculations if I have more time.

Dan

Those RGB values will get the linear xy values WITHOUT any gamma.

The HCFR number of 285%, 49%, 49% gets the same xy result as R60.802%, G10.631%, B10.632% for 50% saturation but with a much higher level of brightness, again with no gamma applied.
Reply
Reply
post #35 of 55
1/21/09 at 3:18pm
Tom,

Do we need to know gamma if we are tryign to keep the luminance the same, like HCFR wanted?

I think you and I are looking for two different sets of target points. For my calibrations, I want the x, y locations spread out evenly from D65 to 100% saturation, and to keep the luminance constant(proportional based on 100% gray luminance).

Even if this is not the "theoretical" correct positions for the saturation points(which is what you are after I believe), it still gives a nice logical placement for them. The luminance should be held constant for the reasons I mentioned already.(easier to diagnose CMS errors).

Based on my measurements, I'm confident that the AVSHD is authored to meet the target x,y and Y points that I want.

I still don't know why evenly spacing them out in the x, y plane would be wrong though. True, it is an arbitrary colorspace, but it works. Evenly spacing them in 'u, 'v would work fine as well, but HCFR is just setup so nicely for xyY.

Dan
Reply
Reply
post #36 of 55
1/21/09 at 3:41pm
Thread Starter 
Quote:
Originally Posted by TomHuffman View Post

Those RGB values will get the linear xy values WITHOUT any gamma.

The HCFR number of 285%, 49%, 49% gets the same xy result as R60.802%, G10.631%, B10.632% for 50% saturation but with a much higher level of brightness, again with no gamma applied.

Wow, this continues to get more mind blowing.

AFAIK, 195, 90, 90 was the RGB given to us by HCFR for 50% Red. I know for sure that those values are the ones used to master AVSHD.

I'm still unsure how gamma ties into it. It looks like you could compute it in linear light or gamma corrected and come out with the same answer.
Reply
Reply
post #37 of 55
1/21/09 at 4:05pm
I'm still trying to figure out why gamma would matter. Y for all of these patterns are based on the Y at 100% gray

Do you have the RGB points for all of the red saturation points on the AVSHD disc?

Or maybe blue?

If I enter my x, y Y(0.4764, 0.3295, 0.213) location for 50% red into Bruce Lindbooms website, I get R = 204.6, G = 91.7, B = 91.7.(scaled)

I know for certain that this is what HCFR expects, and targets for it's saturation charts.

Dan
Reply
Reply
post #38 of 55
1/21/09 at 7:33pm
Thread Starter 
Dan,
I know the RGB for AVSHD, but not off the top of my head. If you look in the AVSHD thread, alluringreality has posted a zip file with all the .tga files used to create the Saturation patterns. If you have a graphics program that can open those files, you should be able to tell the RGB using a color picker type tool. If you can't get the RGB let me know and I'll get them, but it will be tomorrow night at the earliest.
Reply
Reply
post #39 of 55
1/21/09 at 9:37pm
Here's the AVSHD data, RGB values and xyY conversions.

Code:
                R       G       B       GammaR  GammaG  GammaB  X       Y       Z       x       y       Y
R       25%     66.7%   43.4%   43.4%   41%     16%     16%     0.2519  0.2097  0.1754  0.395   0.329   0.210
        50%     79.5%   36.1%   36.1%   60%     10%     10%     0.3034  0.2095  0.1228  0.477   0.329   0.209
        75%     90.4%   26.5%   26.5%   80%     5%      5%      0.3578  0.2112  0.0715  0.559   0.330   0.211
        100%    100.0%  0.0%    0.0%    100%    0%      0%      0.4123  0.2126  0.0193  0.640   0.330   0.213
G       25%     69.4%   91.3%   69.4%   44%     82%     44%     0.5559  0.7113  0.5286  0.310   0.396   0.71
        50%     53.9%   95.0%   53.9%   25%     89%     25%     0.4692  0.7101  0.3521  0.306   0.464   0.71
        75%     37.0%   97.7%   37.0%   11%     95%     11%     0.4049  0.7108  0.2199  0.303   0.532   0.71
        100%    0.0%    100.0%  0.0%    0%      100%    0%      0.3576  0.7152  0.1192  0.300   0.600   0.72
B       25%     29.7%   29.7%   39.3%   7%      7%      13%     0.0746  0.0716  0.1287  0.271   0.261   0.07
        50%     28.3%   28.3%   49.8%   6%      6%      21%     0.0851  0.0717  0.2104  0.232   0.195   0.07
        75%     25.1%   25.1%   66.2%   5%      5%      40%     0.1081  0.0721  0.3870  0.191   0.127   0.07
        100%    0.0%    0.0%    100.0%  0%      0%      100%    0.1805  0.0722  0.9506  0.150   0.060   0.07
Y       25%     97.7%   97.7%   79.9%   95%     95%     61%     0.8411  0.9253  0.7094  0.340   0.374   0.93
        50%     98.6%   98.6%   63.5%   97%     97%     36%     0.8125  0.9261  0.4809  0.366   0.417   0.93
        75%     99.1%   99.1%   44.3%   98%     98%     16%     0.7840  0.9209  0.2916  0.393   0.461   0.92
        100%    100.0%  100.0%  0.0%    100%    100%    0%      0.7699  0.9278  0.1385  0.419   0.505   0.93
C       25%     78.5%   92.2%   92.2%   58%     84%     84%     0.6909  0.7824  0.9055  0.290   0.329   0.78
        50%     65.3%   95.0%   95.0%   39%     89%     89%     0.6400  0.7848  0.9617  0.268   0.329   0.78
        75%     47.9%   97.3%   97.3%   20%     94%     94%     0.5865  0.7819  1.0096  0.247   0.329   0.78
        100%    0.0%    100.0%  100.0%  0%      100%    100%    0.5381  0.7874  1.0698  0.225   0.329   0.79
M       25%     64%     53%     64%     38%     24%     38%     0.3103  0.2816  0.3940  0.315   0.286   0.28
        50%     74%     47%     74%     51%     19%     51%     0.3720  0.2828  0.5195  0.317   0.241   0.28
        75%     85%     38%     85%     70%     12%     70%     0.4540  0.2812  0.6888  0.319   0.197   0.28
        100%    100%    0%      100%    100%    0%      100%    0.5928  0.2848  0.9700  0.321   0.154   0.28
It definitely uses gamma-weighted values. Without gamma, it doesn't keep a relatively constant brightness.

They are keeping constant distances. So what it looks like from this data is that it started with the constant distances and then derived the gamma-weighted RGB triplets from that, rather than going the other way around.

I think that this puts this issue to bed.
Reply
Reply
post #40 of 55
1/22/09 at 8:20am
Quote:
Originally Posted by TomHuffman View Post

Here's the AVSHD data, RGB values and xyY conversions.

It definitely uses gamma-weighted values. Without gamma, it doesn't keep a relatively constant brightness.

They are keeping constant distances. So what it looks like from this data is that it started with the constant distances and then derived the gamma-weighted RGB triplets from that, rather than going the other way around.

I think that this puts this issue to bed.

Just curious... does this put the entire issue to bed or just the Gamma issue ? Hoping someone will write a brief conclusion to the thread once the calcs are resolved. Will the AVSHD disc need to be updated or is it more likely that certain settings within HCFR will be recommended based on any differences between the HCFR software and how the patterns were derived in AVSHD ?
Reply
Reply
post #41 of 55
1/22/09 at 8:34am
Thread Starter 
Tom,
Did you resolve the measurement discrepancies you originally reported?
Reply
Reply
post #42 of 55
1/22/09 at 8:38am
Tom,
I’m glad we can put that to rest. At least now we know, and can calibrate accordingly. Thanks Tom, (and hwjohn, alluringreality) for finding out this answer.

Well, the x, y numbers line up well with my calculated points, but the Y value for red varies from 0.209 to 0.213. I assume that this is real, and what I should expect to measure? If so, I will change my spreadsheet accordinly. Not a big deal, but I want my spreadsheet to be accurate.

I hate to ask, but is it possible to get the Y values in your table out to three significant digits? For blue, is it 0.07 precicely, or 0.072 like I would expect. There is a three percent difference there.

I’m glad you know how to derive these numbers, because I am lost there. I haven’t spent as much time as you with these calculations.

This whole topic brings up a new dimension to calibrating, in my opinion.
I have an Epson 1080UB and didn’t like what I saw when I calibrated the CMS as you typically would (100% saturation windows). At first it looked great, but then I started to notice washed out faces and other similar problems with color saturation.

Look at what happens to my saturations when I try to calibrate using the 100% saturation windows. Yowza. Look at my measured green 75% saturation point. It’s down close to 50%! Same with yellow and cyan! Even red is bad. That is what brought up this whole issue. So I did some investigating to see what was going on and found out that my 1080UB is pretty linear up to 75% saturation(for both brightness and saturation), and then really takes off at 100%. So I adjusted everything to the 75% saturation windows, and voila, the second picture below. At least my gamut is now extremely accurate up to 75% saturation(which is still a heck of a lot of the color gamut.) The 100% saturations are oversaturated, but they are pretty evenly off in u’, v’ space so at least it’s perceptually uniform. I can tell you that my skintones are incredible now, as they mostly fall in that 75% and below region, and my picture went from pretty good, to stunning. No more washed out colors, in background, faces, … All of those colors that were getting desaturating are now dead on.

Adjusted to 100% saturation windows: (100% luminance)

Adjusted using 75% saturation windows: (100% luminance)

Dan
Reply
Reply
post #43 of 55
1/22/09 at 8:47am
Yes, my measurement discrepancies were based on the erroneous belief that, for example, 50% red should be R100%, G50%, B50%. However, because of gamma this isn't correct. It is more like 100%, 45%, 45%. Because the disc endeavors to keep the brightness constant, the actual RGB triplets look a little strange (e.g., 50% red is 80%, 36%, 36%).

The AVSHD disc is correct, at least for a 2.22 gamma. It requires no changes.

And, yes, you need to specify a target gamma to get the right values. The disc assumes a 2.22 gamma, so if your gamma is higher or lower, then the disc will be off somewhat. I see no solution to this. For example, a 2.5 gamma for the same 50% red will in fact be 100%, 50%, 50%.

In as much as I was the one who initially claimed that the disc was off, I am pleased to report that I was mistaken.
Reply
Reply
post #44 of 55
1/22/09 at 4:24pm
So Tom, do you think this will change the way you perform calibrations at all? For me, it was somewhat of a neccessity, since the 1080UB is just so nonlinear for saturation. Calibrating to the 75% saturation windows helped tremendously. It's a tradeoff for the higher saturations at 100%.

I guess you'll have to see how a particular projector performs according to these saturation measurements. Then decide if changes are needed. I wonder how many projectors out there actually perform as expected once colors are adjusted to the 100% saturation locations as usual?

Dan
Reply
Reply
post #45 of 55
2/3/09 at 7:41pm
Quote:
Originally Posted by TomHuffman View Post

And, yes, you need to specify a target gamma to get the right values. The disc assumes a 2.22 gamma, so if your gamma is higher or lower, then the disc will be off somewhat. I see no solution to this. For example, a 2.5 gamma for the same 50% red will in fact be 100%, 50%, 50%.

Sorry for resurrecting this thread but I just read through it and am trying to wrap my thick-head around this issue. Tom, are you saying that the presumed reference saturation points that HCFR uses all assume a reference 2.22 gamma? For example, HCFR's HD709 reference 50% saturation point (using x,y) is ~.477/.329 - will the correct reference location for 50% saturated red change if one's reference gamma changes to say 2.5? Or are you saying something completely different which I'm not understanding at all.

thanks much for any insight for my thick-head,


--tom
Reply
Reply
post #46 of 55
2/3/09 at 8:18pm
Quote:
Originally Posted by thomasl View Post

Sorry for resurrecting this thread but I just read through it and am trying to wrap my thick-head around this issue. Tom, are you saying that the presumed reference saturation points that HCFR uses all assume a reference 2.22 gamma? For example, HCFR's HD709 reference 50% saturation point (using x,y) is ~.477/.329 - will the correct reference location for 50% saturated red change if one's reference gamma changes to say 2.5? Or are you saying something completely different which I'm not understanding at all.

thanks much for any insight for my thick-head,


--tom

I think that is exactly what Tom was saying, that the point would change, but only slightly. It was in part to investigate this that I worked up a spreadsheet to try to calculate the predicted saturation targets given the measured primaries and gamma, when one has already got the primaries as close as possible. As Tom wrote, the changes for gamma are small, but present.

Bill
Reply
Reply
post #47 of 55
2/3/09 at 8:40pm
Quote:
Originally Posted by thomasl View Post

Tom, are you saying that the presumed reference saturation points that HCFR uses all assume a reference 2.22 gamma?

Yep.
Reply
Reply
post #48 of 55
2/4/09 at 3:04am
Quote:
Originally Posted by TomHuffman View Post

Yep.

Ok - thanks for confirming that. At least I know that after reading through the thread that I understood things when I reached the end.

cheers,


--tom
Reply
Reply
post #49 of 55
2/4/09 at 4:03am
Quote:
Originally Posted by Bill Mitchell View Post

I think that is exactly what Tom was saying, that the point would change, but only slightly. It was in part to investigate this that I worked up a spreadsheet to try to calculate the predicted saturation targets given the measured primaries and gamma, when one has already got the primaries as close as possible. As Tom wrote, the changes for gamma are small, but present.

Thanks Bill - yes, I saw your post but haven't had a chance to look at your spreadsheet. I'm also interested in working through the math.

cheers,


--tom
Reply
Reply
post #50 of 55
9/20/11 at 8:14pm
Not to beat a (2-year) dead horse, but doing some research on Rec.709 - xyY conversion turned up this thread in a search and something caught my eye.

I see all these numbers being tossed around, and I understand the different objectives by HCFR, etc.. with regards to equal distance and so on, but the thing that caught my eye with regards to the calculations not matching was that it appears as though not all values being used in the calculations are being corrected for video levels (and I'm not referring to the Lindbloom relying on 0-255).

For example, if we are to use the case of the propsed 190, 95, 95 (or whatever the values are from the previous post), if one is to normalize those then don't you take (190-16)/219 instead of 190/219 (as was indicated) as the useful value?

Also, in terms of RGB value for saturation (not adhering to the equal-spaced xyY value method) wouldn't 25% Red be 235, 191, 191? it appeared as though some of the values presented / used were calculated as % of 255 instead of 219, and then again the 16 value wasn't consistently added / subtracted where necessary. If all calculations are done as %RGB and then converted to 8-bit (or 10/12/16/other) video-levels in the final stage then the numbers may seem to work. I'm not going to recalc all the examples here (since this *specifically* isn't what I was trying to track down when I stumbled on this post), but I'd be curious to find out if this makes the initial conversion using Tom's formulas line up and it was simply the 16/black that was throwing the coordinates off.

I realize that this post is not well composed and perhaps a bit off-the-cuff, but I'm hoping that if anybody else stumbles on to this that they may make the same observations I have should they chose to try an calculate the values out for the sake of getting the head around the math behind the process.

Okay, I'll shut up now.
Reply
Reply
post #51 of 55
9/20/11 at 8:32pm
Quote:
Originally Posted by DFrost View Post

For example, if we are to use the case of the propsed 190, 95, 95 (or whatever the values are from the previous post), if one is to normalize those then don't you take (190-16)/219 instead of 190/219 (as was indicated) as the useful value?

yes, if the value is 190 and you are in video levels, to get the percentage you need to go (190 -16)/219.

Quote:
Originally Posted by DFrost View Post

Also, in terms of RGB value for saturation (not adhering to the equal-spaced xyY value method) wouldn't 25% Red be 235, 191, 191?

Saturation percentages are really loosely defined. Infact I'd say you can do it anyway you want. You just need to be able to calculate the target xyY for the RGB triplet of the pattern you want. One key criteria for that is the target gamma curve. You need to take the percentage stimulus and degamma it into percentage of linear light in order to convert the RGB into XYZ.

But yeah what 25% saturation do you want? xyY, uvY, CIELab, CIE LUV? What gamma are you targeting 2.2, 2.4, sRGB? What percentage luminance do you want? do you want 100% luminance at 25% saturation or do you want 75% luminance and 25% saturation.

Hopefully someone will have some software soon that takes all of that into account.
Reply
Reply
post #52 of 55
9/25/11 at 8:11pm
The *main* point of my long-winded post was to confirm that the 16 didn't seem to be getting accounted for in the % value calculations, so thanks for the confirmation of that.

With regards to % Saturation, thus far I've only had the need to use 100%Lum, and I treat the %Sat as the percentage of values I can change *above* the current value (numerically, primarily due to the ambiguity of the other options: gamma, xyY-spacing, etc..). So to use the example I posted above of 235, 191, 191, I'm 1/4 of the way (in terms of quantity of values) away from solid white, so my red is only 25% saturated. Right or wrong (if there *is* a right or wrong here) that's the way I think of it.

I've been bouncing around a spreadsheet collecting what information I can, but perhaps the biggest problem I've run into is getting *exact* (or most accurate) values to use for the calculations. There are the values of, for example, D65 of X=95.047, Y=100.00, Z=108.883, which becomes x=0.312726614681012, y=0.329023130326062, z=0.358250254992926, but then other documents point out that the 709 spec truncates the xy to x=0.3217, y=0.3290, which leaves we wondering that if the *spec* truncates these values, is it "wrong" to try to even bother with more *exact* values? So many different sources provide such slightly different values after conversion, that it leaves me wondering if rounding errors aren't the source of the deviations.

Being a perfection in general, I'm trying to make the definitive calculator so I can answer such question for myself (and learn quite a bit in the process, and perhaps share it when (if) I ever get it done), because it's one thing if the values differs by amounts small enough to not change an RGB value, or maintain 4-digit precision on xy coordinates, but when there's enough slop to cause numbers to change (especially now that I'm working on some 16-bit charts, so the tolerance is tighter) then it drives me to find the source of the difference in results.
Reply
Reply
post #53 of 55
9/25/11 at 10:38pm
Quote:
Originally Posted by DFrost View Post

With regards to % Saturation, thus far I've only had the need to use 100%Lum, and I treat the %Sat as the percentage of values I can change *above* the current value (numerically, primarily due to the ambiguity of the other options: gamma, xyY-spacing, etc..). So to use the example I posted above of 235, 191, 191, I'm 1/4 of the way (in terms of quantity of values) away from solid white, so my red is only 25% saturated. Right or wrong (if there *is* a right or wrong here) that's the way I think of it.

Sure you can set them up that way, but you'll still need to calculate their x,y targets based on the target gamma formula. The gamma either changes the x,y targets or the RGB triplet.

Quote:
Originally Posted by DFrost View Post

I've been bouncing around a spreadsheet collecting what information I can, but perhaps the biggest problem I've run into is getting *exact* (or most accurate) values to use for the calculations. There are the values of, for example, D65 of X=95.047, Y=100.00, Z=108.883, which becomes x=0.312726614681012, y=0.329023130326062, z=0.358250254992926, but then other documents point out that the 709 spec truncates the xy to x=0.3217, y=0.3290, which leaves we wondering that if the *spec* truncates these values, is it "wrong" to try to even bother with more *exact* values? So many different sources provide such slightly different values after conversion, that it leaves me wondering if rounding errors aren't the source of the deviations.

Actually D65 is defined as a spectrum at 5nm increments. You then use the 1931 standard observer color matching function to convert in to XYZ, then from XYZ you can convert it to xy. As for targets 0.31272 rounds to .3127 and .32902 rounds to .3290, but the longer full number is technically more accurate. Also the XYZ numbers have a lot more decimal places if you start with the spectrum. At some point the additional precision isn't neccessary. The degree of error would be below visual perception and even things like the color matching functions themselves are created with somewhat course precision.

Quote:
Originally Posted by DFrost View Post

Being a perfection in general, I'm trying to make the definitive calculator so I can answer such question for myself (and learn quite a bit in the process, and perhaps share it when (if) I ever get it done), because it's one thing if the values differs by amounts small enough to not change an RGB value, or maintain 4-digit precision on xy coordinates, but when there's enough slop to cause numbers to change (especially now that I'm working on some 16-bit charts, so the tolerance is tighter) then it drives me to find the source of the difference in results.

All I can say to that is, me too.
Reply
Reply
post #54 of 55
9/26/11 at 4:02am
Here's a nice calculator.

http://home.roadrunner.com/~res18h39/color.htm

Ron
Reply
Reply
post #55 of 55
9/28/11 at 4:38am
Thanks, Ron. I'll have to check that one out, too!
Reply
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration

AVS Top Picks

AVS › AVS Forum › Display Devices › Display Calibration › Equations to convert xyY to RGB