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.

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
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:
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.

1. Convert the xyY of the chosen gamut to XYZ
For a Rec. 709 that would be
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:
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.

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.

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.

"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.

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).

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.

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.

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.

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.

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.

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.

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

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.

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? :D

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.
http://www.geocities.com/stereomandan/projector/gamut.jpg

Dan

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.

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...?

http://www.avsforum.com/avs-vb/showthread.php?t=1111066

Dan

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...?

http://www.avsforum.com/avs-vb/showthread.php?t=1111066

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:
http://www.geocities.com/stereomandan/projector/saturationshiftcalculatedpoints.jpg

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:

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:
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:
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


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:
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.

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


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.

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:
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.

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.

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?

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.000These 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.

DanThose 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.

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

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.

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

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.

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

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.

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 ?

Tom,
Did you resolve the measurement discrepancies you originally reported?

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)
http://www.geocities.com/stereomandan/projector/gamutcalibratedto100percentsaturation.jpg
Adjusted using 75% saturation windows: (100% luminance)
http://www.geocities.com/stereomandan/projector/gamut.jpg
Dan

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.

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

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

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 (http://www.avsforum.com/avs-vb/showthread.php?p=15724576#post15724576) 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

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

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

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 (http://www.avsforum.com/avs-vb/showthread.php?p=15724576#post15724576) 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

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.

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.


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. :eek:

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.

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.

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.

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. :)

Here's a nice calculator.

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

Ron

Thanks, Ron. I'll have to check that one out, too!