or Connect
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

Evidently 6 years of college engineering has left me mathematically inept. Does anyone have equations to convert to RGB from xyY? I tried deriving them using the xyY->XYZ and XYZ->RGB equations from Bruce Lindbloom and Poynton's sites, but there is either some step I'm missing or I'm just plain stupid. If you have them, please note if they are normalized or for a specific range.

I need these in reference to AVSHD. There have been some reports that the saturation windows are incorrect, and I'm trying to check them. The RGB triplets for the windows was given to us by the HCFR guys best I remember. The patterns seem to hold Y constant while only varying saturation. I wanted to take a known xyY coordinate (e.g. 25% Red @ x = 0.4764, y = .3295), determine the constant Y that the HCFR guys came up with, then use all 3 (xyY) to compute the RGB triplet and see if it matched the triplet we used to author the patterns.

Equations need to be for D65 Rec. 709.

### AVS Top Picks

Quote:
Originally Posted by hwjohn

Evidently 6 years of college engineering has left me mathematically inept. Does anyone have equations to convert to RGB from xyY? I tried deriving them using the xyY->XYZ and XYZ->RGB equations from Bruce Lindbloom and Poynton's sites, but there is either some step I'm missing or I'm just plain stupid. If you have them, please note if they are normalized or for a specific range.

I need these in reference to AVSHD. There have been some reports that the saturation windows are incorrect, and I'm trying to check them. The RGB triplets for the windows was given to us by the HCFR guys best I remember. The patterns seem to hold Y constant while only varying saturation. I wanted to take a known xyY coordinate (e.g. 25% Red @ x = 0.4764, y = .3295), determine the constant Y that the HCFR guys came up with, then use all 3 (xyY) to compute the RGB triplet and see if it matched the triplet we used to author the patterns.

Equations need to be for D65 Rec. 709.

1. Convert the xyY of the chosen gamut to XYZ
For a Rec. 709 that would be
Code:
```R X0.412315    Y0.212600    Z0.019327
G X0.357600    Y0.715200    Z0.119200
B X0.180500    Y0.072200    Z0.950633
```
This is now a 3x3 matrix.
2. Invert this matrix, which results in:
Code:
```  R        G          B
1 3.24156  -0.96920  0.05562
2 -1.53767 1.87589   -0.20396
3 -0.49870 0.04155   1.05686
```
3. Convert a target xyY color to XYZ. This creates a 3x1 matrix.

4. Multiply the 3x1 matrix of the target color with the 3x3 inverted matrix of the reference gamut.
Let's take white as example.
x0.3127
y0.329
Y1.0

becomes

X0.95042
Y1.00000
Z1.08916

Multiplying
3.24156 -0.96920 0.05562
-1.53767 1.87589 -0.20396
-0.49870 0.04155 1.05686

by

0.95042
1.00000
1.08916

yields

1, 1, 1
or
R100%, G100%, B100%

This is without gamma applied.

BTW, since all we are concerned with is saturation, it is not clear to me the value of keeping a constant Y. It only complicates the process and adds nothing that I can see.
Quote:
Originally Posted by TomHuffman

1. Convert the xyY of the chosen gamut to XYZ
For a Rec. 709 that would be
Code:
```R X0.412315    Y0.212600    Z0.019327
G X0.357600    Y0.715200    Z0.119200
B X0.180500    Y0.072200    Z0.950633
```
This is now a 3x3 matrix.
2. Invert this matrix, which results in:
Code:
```  R        G          B
1 3.24156  -0.96920  0.05562
2 -1.53767 1.87589   -0.20396
3 -0.49870 0.04155   1.05686
```
3. Multiply the XYZ value with the inverted matrix of the gamut in the following way:
R = (RX*R1)+(RY*R2)+(RZ*R3)
G = (GX*G1)+(GY*G2)+(GZ*G3)
B = (BX*B1)+(BY*B2)+(BZ*B3)

4. For color, convert the result to % values. For white, also normalize the results by dividing by the initial value of Y. This is without gamma applied.

If I haven't transposed some numbers, I think this is correct.

BTW, since all we are concerned with is saturation, it is not clear to me the value of keeping a constant Y. It only complicates the process and adds nothing that I can see.

Thanks for the help Tom. If you don't mind, let me get clarification on a couple things.

1) The first matrix, am I to dot (compute the dot product) of that matrix with my xyY coordinate, and that will give me XYZ coordinates, correct? I got confused with it because it had RGB out to the left. Just to make sure I have it correct, the first equation would be:

X = (X0*x) + (Y0*y) +(Z0*Y)

Seems like I have that wrong just looking at it. Please let me know. The second matrix is the same one Poynton has, just inverted, so I at least had that part close.

2) Please see if the following seems to be a logical approach for validating 50% red:

RGB values we used for 50% red sat pattern: 190,95,95 (video range 16-235)

The goal is to verify that this RGB produces the correct chromacity for 50% red @ some unknown, arbitrary Y as chosen by the HCFR guys. I have to solve for the unknown Y first.

Take the R equation with x,y being known for 50% red saturation. Normalize the R component (190) by the video range (219), e.g. 190/219. Now R, x, y, are all known leaving Y as the only unknown. Solve for Y, which should be constant from here on.

Use the known x,y,Y (Y obtained from step above) to compute G and B for 50% red. If everythig is kosher, G and B should come out to 95,95 to match our original values above. If not, we at least know something is wrong.

Does this seem like a logical approach to validate the RGB? I'm almost positive that the encoding is correct as a reference decoder spits out the correct values.

P.S. - I don't know why it was chosen to hold Y constant, unless chromacity starts to interact with Y for some displays. I'm sure there was a good reason, those HCFR guys are pretty smart.
Quote:
Originally Posted by hwjohn

1) The first matrix, am I to dot (compute the dot product) of that matrix with my xyY coordinate, and that will give me XYZ coordinates, correct? I got confused with it because it had RGB out to the left. Just to make sure I have it correct, the first equation would be:

X = (X0*x) + (Y0*y) +(Z0*Y)

Seems like I have that wrong just looking at it. Please let me know.

Gosh, I have read this a couple of times and I just don't know what you are asking. The first matrix is just
Rx, Ry, RY
Gx, Gy, GY
Bx, By, BY

converted to XYZ

RX, RY, RZ
GX, GY, GZ
BX, BY, BZ

The formula for the conversion is:
X = x(Y)/y
Y = Y
Z = (1-x-y)Y/y

I provided the results in my first post. Just invert these to get the second matrix. I sense we are talking past one another.

I really don't have any advice about the encoding to disc part. Not my area of expertise.
Quote:
Originally Posted by TomHuffman

it is not clear to me the value of keeping a constant Y. It only complicates the process and adds nothing that I can see.

My PDF is probably not very well written in regards to the saturation patterns. The saturation patterns were created to go with the ColorHCFR software. In their software they apparently are expecting for the "saturation scale" measurements to hold a constant luminance based on the "saturation - luminance graph". It's been a long time since I measured the "saturation scale" items, but I think the "saturation - shift graph" also has to do with luminance. Certainly the RGB is a lot easier to figure if you let the resulting Y vary, but I don't think that's what ColorHCFR was going for in their "saturation scale" measurements that the patterns were created to go with.
"
Quote:
Originally Posted by alluringreality

My PDF is probably not very well written in regards to the saturation patterns. The saturation patterns were created to go with the ColorHCFR software. In their software they apparently are expecting for the "saturation scale" measurements to hold a constant luminance based on the "saturation - luminance graph". It's been a long time since I measured the "saturation scale" items, but I think the "saturation - shift graph" also has to do with luminance. Certainly the RGB is a lot easier to figure if you let the resulting Y vary, but I don't think that's what ColorHCFR was going for in their "saturation scale" measurements that the patterns were created to go with.

The saturation shift graph only displays changes in the xy coordinates. Changes in brightness aren't reflected by these, so whether the brightness changes or stays the same it would have no effect on the way the data was represented. Their Help file says on the subject:

***********

Saturation-shifts graph

Saturation-difference histogram measures two distinct things. Curves on higher part of the graph show the difference between the measured saturation level and the expected level. The goal is to reach a 0% difference for all curves. Negative values mean a lake of saturation and positive values mean an excess of saturation.
Curves on the lower part of the graph show a delta E between the measured color and the expected color, without taking into account the saturation level. As an example, a measured green with 60% of saturation instead of 50% will have a delta E of 0, contrary to the saturation curves, which will show +10% saturation error. However, whether the saturation is correct or not, if this green is not pure with blue or red component, the corresponding delta E curve would show the error.

Note: This delta E is not a "true" delta E, because it is not computed using a fixed reference point, but using a projected point on a line coming from white to a primary or secondary color. It means delta E values used to draw these curves are different than those displayed in measures grid. Moreover, this delta E value never takes luminance into account, regardless do not use luminance in delta E formula option in Advanced Preferences.

*****************

Keeping the luminance constant doesn't hurt, but it complicates the task and makes getting the correct xy coordinates more difficult. I'm just suggesting that you guys make it easier for yourselves.
Quote:
Originally Posted by TomHuffman

Gosh, I have read this a couple of times and I just don't know what you are asking. The first matrix is just
Rx, Ry, RY
Gx, Gy, GY
Bx, By, BY

converted to XYZ

RX, RY, RZ
GX, GY, GZ
BX, BY, BZ

The formula for the conversion is:
X = x(Y)/y
Y = Y
Z = (1-x-y)Y/y

I provided the results in my first post. Just invert these to get the second matrix. I sense we are talking past one another.

I really don't have any advice about the encoding to disc part. Not my area of expertise.

I think we are talking past each other too. The matrices you provided are just in a little different format than what I'm used to seeing/using, but no problem. Let's see if this helps. Let's break it down onto 3 equations from the 3x3 matrix, going in reverse:

1) From the second matrix (XYZ->RGB) we should have the following 3 equations:

R = (3.24156*X) - (1.53767*Y) - (0.49870*Z)
G = -(0.96920*X) + (1.87589*Y) + (0.04155*Z)
B = (0.05562*X) - (0.20396*Y) + (1.05686*Z)

This should give us normalized (0-1) RGB values that will have to be scaled to whatever range we are using. We can agree on this part, right?

2) Now for part 2. I don't know the Y value, only x and y for the pattern I wish to check (50% Red, 190,95,95). Evidently this Y was selected by the HCFR guys. Because of this, I can't really go straight from (xyY->XYZ) using the first matrix you provided. What I can do is use the set of equations you provided and substitute in the RGB equations above:

Equations for xyY->XYZ
X = x(Y)/y
Y = Y
Z = (1-x-y)Y/y

Substituting into equations from step 1:

R = (3.24156*x(Y)/y) - (1.53767*Y) - (0.49870*(1-x-y)Y/y)
G = -(0.96920*x(Y)/y) + (1.87589*Y) + (0.04155**(1-x-y)Y/y)
B = (0.05562*x(Y)/y) - (0.20396*Y) + (1.05686**(1-x-y)Y/y)

Does everything look ok so far?

Now I need to solve for Y because, as stated above, I don't know it. Just looking at the first equation for R:

R = (3.24156*x(Y)/y) - (1.53767*Y) - (0.49870*(1-x-y)Y/y)

I know R,x,y but Y is unknown. One equation and one unknown so I can solve for Y. R for this equation will be the normalized value from the pattern we are checking (190/219) = 0.86758.

Using this information we can solve for Y. Now, we want to make sure that 190, 95, 95 is indeed the correct triplet for 50% red sat. To verify, calculate G and B by using the known x,y and the solved for Y:

G = -(0.96920*x(Y)/y) + (1.87589*Y) + (0.04155**(1-x-y)Y/y)
B = (0.05562*x(Y)/y) - (0.20396*Y) + (1.05686**(1-x-y)Y/y)

G and B should work out to the normalized value of (95/219) = 0.43379. If they don't, then the RGB triplet of 195,95,95 is wrong for 50% sat red.

Hopefully I have explained my method a little better this time; sorry for all the confusion the first time. Do you see anything wrong with what I'm doing?
Also remember this assumes that the display reproduces the color space with 100% accuracy. In actuality xyY is data drastically effected by the output of the display so in reality you can't easily go back from xyY to RGB reliably except for an idealized display (like the frictionless ball, 100% elastic ball from physics).
Quote:
Originally Posted by sotti

Also remember this assumes that the display reproduces the color space with 100% accuracy. In actuality xyY is data drastically effected by the output of the display so in reality you can't easily go back from xyY to RGB reliably except for an idealized display (like the frictionless ball, 100% elastic ball from physics).

We are taking the display out of it altogether. We know the theoretical chromacity for 50% red sat... the question is whether or not the RGB triplet we are using to author the pattern is correct (195,95,95) to represent that chromacity.
Quote:
Originally Posted by hwjohn

We are taking the display out of it altogether. We know the theoretical chromacity for 50% red sat... the question is whether or not the RGB triplet we are using to author the pattern is correct (195,95,95) to represent that chromacity.

Right, so you are assuming a perfect display

Anyway what I discovered writing my PCGG app was that 8bit RGB isn't accurate enought to acutally generate anything spot on. So everything is off just a bit.
Quote:
Originally Posted by sotti

Right, so you are assuming a perfect display

Anyway what I discovered writing my PCGG app was that 8bit RGB isn't accurate enought to acutally generate anything spot on. So everything is off just a bit.

In a sense, yes. We are just dealing with the theoretical math, so everything is perfect.

You are right about 8 bit RGB, but it would be true for any discrete system. The error just becomes smaller as you increase the bit depth. Pretty much every pattern we produce has some rounding.
Quote:
Originally Posted by hwjohn

1) From the second matrix (XYZ->RGB) we should have the following 3 equations:

R = (3.24156*X) - (1.53767*Y) - (0.49870*Z)
G = -(0.96920*X) + (1.87589*Y) + (0.04155*Z)
B = (0.05562*X) - (0.20396*Y) + (1.05686*Z)

This should give us normalized (0-1) RGB values that will have to be scaled to whatever range we are using. We can agree on this part, right?

Correct.

Quote:
Originally Posted by hwjohn

2) Now for part 2. I don't know the Y value, only x and y for the pattern I wish to check (50% Red, 190,95,95). Evidently this Y was selected by the HCFR guys. Because of this, I can't really go straight from (xyY->XYZ) using the first matrix you provided. What I can do is use the set of equations you provided and substitute in the RGB equations above:

Equations for xyY->XYZ
X = x(Y)/y
Y = Y
Z = (1-x-y)Y/y

Substituting into equations from step 1:

R = (3.24156*x(Y)/y) - (1.53767*Y) - (0.49870*(1-x-y)Y/y)
G = -(0.96920*x(Y)/y) + (1.87589*Y) + (0.04155**(1-x-y)Y/y)
B = (0.05562*x(Y)/y) - (0.20396*Y) + (1.05686**(1-x-y)Y/y)

Does everything look ok so far?

Now I need to solve for Y because, as stated above, I don't know it. Just looking at the first equation for R:

R = (3.24156*x(Y)/y) - (1.53767*Y) - (0.49870*(1-x-y)Y/y)

I know R,x,y but Y is unknown. One equation and one unknown so I can solve for Y. R for this equation will be the normalized value from the pattern we are checking (190/219) = 0.86758.

Using this information we can solve for Y. Now, we want to make sure that 190, 95, 95 is indeed the correct triplet for 50% red sat. To verify, calculate G and B by using the known x,y and the solved for Y:

G = -(0.96920*x(Y)/y) + (1.87589*Y) + (0.04155**(1-x-y)Y/y)
B = (0.05562*x(Y)/y) - (0.20396*Y) + (1.05686**(1-x-y)Y/y)

G and B should work out to the normalized value of (95/219) = 0.43379. If they don't, then the RGB triplet of 195,95,95 is wrong for 50% sat red.

Hopefully I have explained my method a little better this time; sorry for all the confusion the first time. Do you see anything wrong with what I'm doing?

To be quite honest I would have to give a lot more thought to the methodology you suggest here than frankly I have time for. If you have the basic xyY - RGB conversion straight--which is how I understood your original question--then I don't think I can help much more.

BTW, I have yet to hear a cogent explanation for why all this Y stuff matters. The problem I had with the original patterns was that the xy points measured quite a bit differently from what I got from the Accupel. The focus on getting the right Y values seems to me like a red herring. The HCFR graphs do not use Y data for the saturation scale. 25% red saturation is what it is, regardless of its brightness.
Quote:
Originally Posted by TomHuffman

Correct.

To be quite honest I would have to give a lot more thought to the methodology you suggest here than frankly I have time for. If you have the basic xyY - RGB conversion straight--which is how I understood your original question--then I don't think I can help much more.

BTW, I have yet to hear a cogent explanation for why all this Y stuff matters. The problem I had with the original patterns was that the xy points measured quite a bit differently from what I got from the Accupel. The focus on getting the right Y values seems to me like a red herring. The HCFR graphs do not use Y data for the saturation scale. 25% red saturation is what it is, regardless of its brightness.

The Y stuff isn't important as far as I'm concerned (maybe it is to alluringreality, but I doubt it). We were basically using what we were given to match HCFR.

However, I don't think we want to go changing things on the disc until we can verify that they are incorrect. I'm not knocking your measurements, but we have to find if there is a problem first, and then where the problem is in order to fix it.

I'm just trying to check our RGB values using the theoretical math.
Something just occurred to me. The method I used for generating 25%,50%, and 75% patterns was to simply enter different RGB values into the Accupel. For example, to get 50% red, I would input R100%, G50%, B50%. However, using Lindbloom's calculator, I see that this approach yields different numbers than simply calculating the distance at 25% increments between red and white.
50% red
Lindbloom/Accupel: x0.456, y0.329
Mathematical distance: x0.476, y0.330

Shouldn't these numbers be the same? Even when I calculate using u'v' coordinates, which should be more accurate than xy, and then convert back to xy I get
x0.478, y0.335
which is much closer to the mathematical distance than the number generated by Accupel/Lindbloom.

Perhaps my methodology of using R100%, G50%, B50% as a way to generate a 50% red saturation pattern is mistaken. Can anyone think why? The disc may be correct after all.
Quote:
Originally Posted by TomHuffman

Something just occurred to me. The method I used for generating 25%,50%, and 75% patterns was to simply enter different RGB values into the Accupel. For example, to get 50% red, I would input R100%, G50%, B50%. However, using Lindbloom's calculator, I see that this approach yields different numbers than simply calculating the distance at 25% increments between red and white.
50% red
Lindbloom/Accupel: x0.456, y0.329
Mathematical distance: x0.476, y0.330

Shouldn't these numbers be the same? Even when I calculate using u'v' coordinates, which should be more accurate than xy, and then convert back to xy I get
x0.478, y0.335
which is much closer to the mathematical distance than the number generated by Accupel/Lindbloom.

Perhaps my methodology of using R100%, G50%, B50% as a way to generate a 50% red saturation pattern is mistaken. Can anyone think why?

I'm pretty sure that Lindbloom (who I also played around with) uses PC levels. Maybe I'm thinking about it wrong, but 100,50,50 is different for PC level 0-255 than video level 16-235.

In other words, when you use Lindbloom's calculator, you are getting an x,y output based on 0-255.

Maybe I'm crazy. At this point I have looked at it too long and need to take a break.

EDIT: Nevermind, just saw you can use it with normalized 0-1. I got the same xy you got with 1, .5, .5 for RGB (Scale is not checked).
Tom,
I just tried normalizing the 50% red we are using (190,95,95) and put those numbers into Lindblooms calculator. Basically use 190/219 for R, and 95/219 for Green and Blue (Scale box unchecked).

The resultant xyY is much closer to the Accupel/Lindbloom numbers you give, indicating that (190,95,95) may actually be a correct triplet for 50% red sat. It appears that all of us may be calculating the target x,y incorrectly. I was doing it the same way you were, by just finding the 25% distance along the saturation line. I have no idea why that would be the wrong way to do it, but it looks like it is Accupel/Lindbloom/HCFR against us... I hate to bet against us, but...

Casey
Quote:
Originally Posted by hwjohn

Tom,
I just tried normalizing the 50% red we are using (190,95,95) and put those numbers into Lindblooms calculator. Basically use 190/219 for R, and 95/219 for Green and Blue (Scale box unchecked).

The resultant xyY is much closer to the Accupel/Lindbloom numbers you give, indicating that (190,95,95) may actually be a correct triplet for 50% red sat. It appears that all of us may be calculating the target x,y incorrectly. I was doing it the same way you were, by just finding the 25% distance along the saturation line. I have no idea why that would be the wrong way to do it, but it looks like it is Accupel/Lindbloom/HCFR against us... I hate to bet against us, but...

190,95,95 gives the same xy as 100%,50%,50%
x0.456, y0.329

so if this method is correct, then the correct targets are:
75% x0.574, y0.330
50% x0.456, y0.329
25% x0.366, y0.329

Why these are different from a linear distance from the white point (xy or u'v') I do not know.
Quote:
Originally Posted by TomHuffman

190,95,95 gives the same xy as 100%,50%,50%
x0.456, y0.329

so if this method is correct, then the correct targets are:
75% x0.574, y0.330
50% x0.456, y0.329
25% x0.366, y0.329

Why these are different from a linear distance from the white point (xy or u'v') I do not know.

I don't either. Are you going to find out for us?
Y does matter, at least to me. On my display there is an interation between brightness and saturation (1080UB). Also look at the JVC RS-20. Changing the luminance from 75%Y to 100%Y for 100% saturation targets results in completely different x, y locations. At least that's my understanding of what the JVC is doing.

Holding Y constant allows ONE less variable to be changed, and helps diagnose problems with the CMS. If you vary Y, along with saturation, who knows what the CMS is doing. You can't seperate out the problem variable.

By the way, HCFR says right in the help file that the x, y locations were chosen based on a equal spacing from D65 to 100% saturation for each color(X, Y space I'm asuming).

"Display saturations
Saturation measures can be drawn on DIE diagram. They must be regularly spaced on a line from D65 to the primary or secondary saturated color. Saturation setting evaluation is easier when using Saturation â€“ Luminance and Saturation â€“ Shifts. "

I can confirm this from doing my own set of calculations (based on where I assume the AVSHD disc targeted x, y) for saturation %error(shift) and dE. They match HCFR.

Also, it seems like a stange coincidence that I can get my measured dE's so good based on my assumption of where the x, y points should be according to my calculations. My projector has a problem with tracking saturation in a linear way, but up to 75% saturation does very well. Here's my example.

I just evenly spaced the saturation points for my assumed reference points, and you can see how well my 0-75% saturations line up. The problem with the 100% saturations from this point on is due to my projector.

Dan
Quote:
Originally Posted by stereomandan

Y does matter, at least to me. On my display there is an interation between brightness and saturation (1080UB). Also look at the JVC RS-20. Changing the luminance from 75%Y to 100%Y for 100% saturation targets results in completely different x, y locations. At least that's my understanding of what the JVC is doing.

For those displays that are non-linear in that when fed a x0.640, y0.330 test pattern at different levels of stimulus, they return different xy readings, I suppose that there would be some value in having a common brightness level for all saturations as it would bypass that problem.

But this is not the problem we are struggling with. In fact, this entire discussion of Y has been a distraction from the real problem. The real problem is what are the correct xy targets? We should be able to address that issue without concerning ourselves with Y at all.
Quote:
Originally Posted by TomHuffman

For those displays that are non-linear in that when fed a x0.640, y0.330 test pattern at different levels of stimulus, they return different xy readings, I suppose that there would be some value in having a common brightness level for all saturations as it would bypass that problem.

But this is not the problem we are struggling with. In fact, this entire discussion of Y has been a distraction from the real problem. The real problem is what are the correct xy targets? We should be able to address that issue without concerning ourselves with Y at all.

I agree with you Tom. Y is irrevalent to where the x, y points should be targeted.

I just personally like removing one variable from the measurement. Being an engineer, trying to diagnose the root cause of a problem, when a lot of variables are changing at the same time, can be a real head ache. Granted, tests can be setup to purposefully cause variable interactions, like multivariate tests, but you have to be very careful with how you analyze the results and that's out of scope for these display calibrations, IMO.

Sorry to digress, but that's why I like the constant Y.

Dan
I think the issue that Dan brought up is probably the reason the HCFR guys chose to keep it constant. I'm sure they knew exactly what the xy targets should be and how to get the correct RGB, so holding Y constant for them may have been trivial.

At this point I'm stumped on the xy coordinates. It seems from the HCFR help file that we are doing the same thing that they are. I feel fairly sure that the different methods we are using (Lindbloom/Accupel/Our calcs) are all using the same white point and primaries to at least 3 digits precision, so I don't know how we are all calculating them differently.
If you keep everything to the x, y colorspace, it's quite simple really. Just imagine the x, y CIE chart to be a typical chart with X and Y coordinates. Saturation is the distance from D65(x=0.3127, y=0.3290) to the 100% saturation point.

If you take a look at my Excel file here, you will see how I came up with the x, y targets that I assumed HCFR asked for. Just go to the Calibration Aid worksheet and click on any cell regarding saturation (other than 100%) and you will see how I calculated it. It's a simple vector calculation. It's kind of funny really, because intuatively, this is how I assumed AVSHD and HCFR were setup. It seems to be correct according to my assumptions, but isn't there any way to measure the true x, y points that the AVSHD is targeting, with a waveform monitor, or...?

Dan
Quote:
Originally Posted by stereomandan

If you keep everything to the x, y colorspace, it's quite simple really. Just imagine the x, y CIE chart to be a typical chart with X and Y coordinates. Saturation is the distance from D65(x=0.3127, y=0.3290) to the 100% saturation point.

If you take a look at my Excel file here, you will see how I came up with the x, y targets that I assumed HCFR asked for. Just go to the Calibration Aid worksheet and click on any cell regarding saturation (other than 100%) and you will see how I calculated it. It's a simple vector calculation. It's kind of funny really, because intuatively, this is how I assumed AVSHD and HCFR were setup. It seems to be correct according to my assumptions, but isn't there any way to measure the true x, y points that the AVSHD is targeting, with a waveform monitor, or...?

Dan

Dan,
Check your calculated targets against the targets Tom posted in post 17. I believe they are different. We are trying to figure out why. Bruce Lindbloom's calculator gives those xy as the correct targets for Red.
Just to be clear. Bruce Lindbloom's calculator matches my numbers or Toms?

The important thing to me is to figure out which x,y points the AVSHD is set for. I have no problem at all with Tom's numbers if they are correct. I think that the AVSHD will have to be updated to match those locations because they seem to be aligned to the locations I provided. (equidistant from D65 to 100% saturation in x, y space) The wording in the HCFR help files seems to agree with this as well.

Dan

:edit:
hwjohn,

Is 190, 95, 95 the known RGB levels used to master the AVSHD disc for 50% red?

Dan
O.k.,
Hereâ€™s what we know as fact. HCFR is targeting the saturation levels that I calculate. I can prove this by manually entering my calculated points into HCFR, which results in a saturation shift of zero for all colors, all saturations.

If HCFR gave you the targets to shoot for based how they wanted their saturation-shift chart to work, wouldnâ€™t that mean that the points they targeted are the same ones I calculate?

The only thing that could have gone wrong is if they did their calculations wrong when trying to target the x, y Y points that they were aiming for.

Does this make sense?

Dan

Here's the chart from HCFR is I enter in my calculated target points for saturaitons:
Dan,
Tom's Accupel and Bruce Lindblooms calculator both suggest the following targets for Red:

75% x0.574, y0.330
50% x0.456, y0.329
25% x0.366, y0.329

You can check out Lindblooms calculator on his site. If you input 1, 0.5, 0.5 (which is what Tom is using with his Accupel) in the RGB box (leave scale unchecked) then you will get the 50% value above. Likewise, if you take the 190, 95, 95 RGB triplet used to master AVSHD 50% Red Sat pattern and normalize it (e.g. 190/219) and plug that into the calculator, you will get the same numbers. This means that 190,95,95 that is used for AVSHD gives the same xy as RGB= 100%, 50%, 50%, indicating that AVSHD is correct.

However, the chromacities don't line up with what we are calculating. I think Tom and I are calculating the same numbers you are. The only way we are really going to figure this out is to use the equations that govern xyY->RGB and hand check the values.

If you look at one of my previous threads, I derived a set of equations that should go straight from xyY-RGB. One way to check things out is to set RGB = 1, 0.5, 0.5 in those equations and then solve the 3x3 matrix for x,y, and Y to get the 50% Red Sat targets.

Here are the equations if you want to solve them for us and see what you get:

Code:
```R = (3.24156*x(Y)/y) - (1.53767*Y) - (0.49870*(1-x-y)Y/y)
G = -(0.96920*x(Y)/y) + (1.87589*Y) + (0.04155**(1-x-y)Y/y)
B = (0.05562*x(Y)/y) - (0.20396*Y) + (1.05686**(1-x-y)Y/y)
```
If solving those gets too hairy you can always do it in two steps (this might be a lot easier now that I look at it). Revert to the XYZ<->RGB equations first to calculate the XYZ, then convert XYZ->xyY. Either way it is a system of 3 equations/3 unknowns.

XYZ<->RGB:
Code:
```R = (3.24156*X) - (1.53767*Y) - (0.49870*Z)
G = -(0.96920*X) + (1.87589*Y) + (0.04155*Z)
B = (0.05562*X) - (0.20396*Y) + (1.05686*Z)
```
XYZ<->xyY:
Code:
```X = x(Y)/y
Y = Y
Z = (1-x-y)Y/y
```
I know you know this, but if you enter those locations for Red into HCFR, you will see that they are spread all over the place. There is a very large gap between 50-75% and a small gap between 75% to 100%. It's even more noticeable in the u'v' colorspace. It's very non-linear.

If you were to reauthor the AVSHD disc to those values, HCFR will not calculate saturation shift correctly, and dE's will be way off.

If this helps, this is what HCFR is expecting for RGB saturation points for Red:
Based on 100 cd/m^2 for 100% gray window, 2.22 gamma

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
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.
Quote:
Originally Posted by stereomandan

I know you know this, but if you enter those locations for Red into HCFR, you will see that they are spread all over the place. There is a very large gap between 50-75% and a small gap between 75% to 100%. It's even more noticeable in the u'v' colorspace. It's very non-linear.

If you were to reauthor the AVSHD disc to those values, HCFR will not calculate saturation shift correctly, and dE's will be way off.

If this helps, this is what HCFR is expecting for RGB saturation points for Red:
Based on 100 cd/m^2 for 100% gray window, 2.22 gamma

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

I don't know at this point Dan. I have a feeling gamma corection has something to do with it, and that is why you see a non-linearity. Tom just posted some good info that we can experiment with.
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