question about 709 colour space calibrating material - Page 2 - AVS Forum
Forum Jump: 
Reply
 
Thread Tools
post #31 of 149 Old 10-11-2007, 05:14 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
alluringreality

Your misunderstanding is coming from the fact that RGB is an abstract system. It does not say what color Red actually is - it is self defining by saying Red is Red. SMPTE specifies the actual colors for REC709 and SMPTE-C using CIE XYZ colorspace - which assigns a coordinate to all the various spectra that the human eye sees as the exact same Red - and each video standard picked a different Red. Part of those standards is the transform matrix to convert abstract RGB to XYZ colorspace chosen by the standard. Your computer right now is only doing color decoder - which is only the brightness of color. Your display is doing the color gamut - which is the color (hue,saturation) of color.

So if your DVD player does the decoding from REC601 DVD data and generates an RGB Red - it is up to the display to make sense of that Red. Should it map it to a SMPTE-C Red, or a REC709 Red, or a sRGB red, or an EBU Red, or an Adobe RGB Red, etc- both of the above linked sites discuss many of these different colorspaces.

Most displays will use the video signal as a clue to the color space as the color space requirement is not communicated to the display over component video. However Windows does support monitor color profiles - so it has the potential to know if it knows what your monitor is by auto/manually selecting the proper monitor driver. As far as the display is concerned if it is an HD signal - good assumption that a REC709 gamut is desired, if it is an SD signal good assumption is that a SMPTE-C gamut is desired. If your HTPC knew you used a HDTV or sRGB display it should desaturate the RGB so that the proper SMPTE-C colors are shown within the sRGB/REC709 display. Then the software would have to ask the user what color gamut the display is - and do the transform coding to warp SMPTE-C inside the REC709 gamut so the DVD can be displayed properly. Lot simpler though incorrect for the programmer to just say - Red is - Red. Especially when you consider that to do it right - it should use the displays actual gamut which likely deviates from REC709 in the first place - so now you have two transforms - SMPTE-C within REC709 gamut and REC709 within your displays gamut. At this point the programmer says screw these video guys - they need to clean up their display standard mess before I waste time coding anything.
krasmuzik is offline  
Sponsored Links
Advertisement
 
post #32 of 149 Old 10-11-2007, 06:18 PM
AVS Special Member
 
alluringreality's Avatar
 
Join Date: Jul 2006
Posts: 3,124
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 9 Post(s)
Liked: 34
I think that was consistent with what Bear5k was saying about the RGB not matching for SD and HD. I believe my SXRD expects a colorspace dependant upon resolution, so WMP's way of seemingly having HD and SD colorbars of the same RGB values appears incorrect on the display. I'm not aware of any monitor drivers for an SXRD, and I believe both my 8600GTS and 2600XT label it as a Sony TV. I had read that Zoom Player handled color correctly, so maybe the increasing RGB levels in the HD colorbars is correct.
alluringreality is offline  
post #33 of 149 Old 10-11-2007, 07:43 PM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by ChrisWiggles View Post

First thing, his answer above is slightly confusing. There are two different things going on. One is the primary chromaticity difference that is called for in the standard, which has to do with the location of the primaries, which are slightly different between SMPTE C and 709.

The second problem, the one you are dealing with, is the matrix coefficients between 601 and 709 that move between YCbCr <-> RGB. Whether or not the matrix flow is correct, you also need a display with the proper primaries, and these are distinct questions.

As for your question with regards to upconverting dvd players, it depends on the dvd player. Hopefully it twists to 709 if it is outputting component. Most displays will just apply 709 to decode component if it is an HD resolution. Some displays allow you to choose the matrix manually, and if you have an upconverting player that is not twisting to 709, this can be advantageous since you can then force a manual decode in 601 for the HD input and get the right colors. Remember, if you output RGB, say from DVI, or from HDMI set to RGB out, then the decoding is going on in the player and the display is not involved since it is seeing already decoded RGB. This is also discussed briefly in my guide, linked in my sig.

But again, the issue of primary chromaticity and color decoding are two different questions, and its easy to confuse the two together, but they are distinct.

Chris - Let's let them walk before making them run the 100m sprint in the Olympics? Precious few displays have correct primaries. That is before we talk about what color the phosphors really are on the BVMs used to master content.

Fundamentally, the "twist" between the SD and HD spaces can be collapsed to a single 3x3 matrix multiplication. You can either do it in the decoder or as an adjunct. However, the result is the same. The purpose of the twist is to ensure that the output chromaticities align with the chromaticities that are assumed to have been present during encoding.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #34 of 149 Old 10-11-2007, 09:21 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by Bear5k View Post

Chris - Let's let them walk before making them run the 100m sprint in the Olympics? Precious few displays have correct primaries. That is before we talk about what color the phosphors really are on the BVMs used to master content.

Fundamentally, the "twist" between the SD and HD spaces can be collapsed to a single 3x3 matrix multiplication. You can either do it in the decoder or as an adjunct. However, the result is the same. The purpose of the twist is to ensure that the output chromaticities align with the chromaticities that are assumed to have been present during encoding.

Bill

Bill,
Can you post a link or give an example of the equations that are involved in the "twist?" I thought I understood Chris' post, but it seems to be contradictory to yours (maybe I misunderstand both). By Chris's post, I thought that only the luminance of the individual primaries could be affected by a certain source, not the chromacities. If that is the case, then I can't see what needs to be twisted besides the equations governing the conversion that Chris talked about (YCbCr <-> RGB).

It seems as though you would have to pick your poison in terms of chromacity and either have 601 or 709 compliant primary chromacities. If your primaries are 709 chromacity and you display 601 content, you just have to live with the slight error in chromacity, but you can adjust the luminance values by using the correct equations to decode the colors.

I hate being an idiot Someone straighten me out?

EDIT: I found the equation. It looks fairly straightforward to "twist" the space, but it will only affect the luminance values You are stuck with whatever chromacities your display is set up for.

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #35 of 149 Old 10-12-2007, 09:32 AM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hwjohn View Post

Bill,
Can you post a link or give an example of the equations that are involved in the "twist?" I thought I understood Chris' post, but it seems to be contradictory to yours (maybe I misunderstand both). By Chris's post, I thought that only the luminance of the individual primaries could be affected by a certain source, not the chromacities. If that is the case, then I can't see what needs to be twisted besides the equations governing the conversion that Chris talked about (YCbCr <-> RGB).

It seems as though you would have to pick your poison in terms of chromacity and either have 601 or 709 compliant primary chromacities. If your primaries are 709 chromacity and you display 601 content, you just have to live with the slight error in chromacity, but you can adjust the luminance values by using the correct equations to decode the colors.

I hate being an idiot Someone straighten me out?

EDIT: I found the equation. It looks fairly straightforward to "twist" the space, but it will only affect the luminance values You are stuck with whatever chromacities your display is set up for.

Since you found some of the links, unless you want to get into the matrix math itself, you want to begin reading this thread here:
http://www.avsforum.com/avs-vb/showthread.php?t=877191 (post 969) for a discussion about going from a broader to a narrower color gamut. The math is the same and the intuition is the same, but the specific example is slightly different. Bruce Lindbloom has the raw matrix math on his site if you want to look at that. The punchline is that the primary mixes are governed by a combination of the chromaticities of the primaries and the white point. Since the white point is the same between SD and HD, the changes in the mix derive from the differences in the primary chromaticities.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #36 of 149 Old 10-12-2007, 02:31 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by Bear5k View Post

Since you found some of the links, unless you want to get into the matrix math itself, you want to begin reading this thread here:
http://www.avsforum.com/avs-vb/showthread.php?t=877191 (post 969) for a discussion about going from a broader to a narrower color gamut. The math is the same and the intuition is the same, but the specific example is slightly different. Bruce Lindbloom has the raw matrix math on his site if you want to look at that. The punchline is that the primary mixes are governed by a combination of the chromaticities of the primaries and the white point. Since the white point is the same between SD and HD, the changes in the mix derive from the differences in the primary chromaticities.

Bill

Thanks Bill. I'll read that post; I have already been through Bruce Lindblooms site a few times as well. What I dont quite understand is if an upscaling DVD player somehow tries to compensate for differences in the primary chromacities by adjusting the luminances or if it just ignores the primary chromacities. Let me give an example:

Take a film frame that is "pure red" according to the 601 standard. The RGB for that frame would be (I think):

RGB: 235,0,0

Now I don't know the coeffiecients for the 709 YPbPr<->RGB conversion, so I'll do it "air code" style. We convert the RGB to YPbPr using the 601 definitions to get (these numbers are fake):

Y = 1
Pb = 0.4
Pr = 0.2

Again, those are just made up numbers. That is how the luminance info is stored on the DVD. Now, if we decode that signal using 601 we get:

RGB: 235, 0, 0

But if we decode it using 709 we get something different, say (again made up numbers):

RGB: 215, 0, 0

In order for this not to happen, we have to scale the 709 equations with the 601 equations, which is simple enough, so the DVD player changes the YPbPr signal before sending it. It alters the YPbPr signal from so that when it is decoded by the TV using 709, we get:

RGB: 235,0,0

Which is what we should get. The problem with this scheme is that it ignores the fact that the primary chromacities in the TV are different, so the same RGB of 235,0,0 actually produces a slightly different color than the original film frame. This is due to the fact that RGB 235,0,0, just tells the set to turn on the RED 100%, with the BLUE and GREEN at 0%. It does not tell the TV what RED, GREEN, and BLUE should be in terms of chromacity.

2) The second scenario I can think of is that, since the SD gamut falls inside the HD gamut, you try to adjust the signal to reproduce the correct SD chromacity by altering the luminances (I'm not even sure this is possible). For instance:

The DVD player recognizes that (same fake numbers as before)

Y = 1
Pb = 0.4
Pr = 0.2

is decoded in SD as:

RGB 235,0,0

The DVD players knows that, since the HD primary chromacities are different, that RGB 235,0,0 is going to produce the wrong color for the upconverted HD signal. So it adjusts the RGB to something like (again made up numbers):

RGB 225,20,25

Where the BLUE and GREEN components shift the color reproduced by the TV from 100% 709 primary red to some point inside the color gamut that actually corresponds to the 601 primary red (again, not sure that even works).



It seems like scenario 2 is considerably more complicated and would only yield marginally better results considering that the 601 and 709 primaries are already pretty close to each other. Do you know if either of these scenarios are actually what happens, or is it something else?

Off to read the post you linked to...

Thanks,
Casey

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #37 of 149 Old 10-12-2007, 04:06 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by hwjohn View Post

Thanks a lot Chris. I'm new to the calibration scene, so I'm trying to learn (I didn't mean to hijack this thread a bit, I apologize). That clears things up a lot.

What you are saying is that the chromacity of the primaries for a given TV are either set to the HD (709) or SD (601) standards and can't be changed unless you manually change them using a CMS. A set without a true CMS has little or no capability to change the chromacity of the primaries, you are stuck with them the way they came.

Correct.

Quote:
What we can change is the luminance of the primaries, which is what is indicated by the RGB triplet and is controlled by the color decoder. That leads me to another question.

Well, sort of, it's just color decoding. For instance, you may be familiar with inaccurate color decoding that leads to red push. It's the same thing, if you use the wrong decode matrix you don't get the right colors. The signal flow is RGB->YCbCr->RGB. The encode matrix to create the YCbCr has to be the same as the decode matrix, otherwise the RGB you end up with (your colors) are not the same as the RGB that we started with. So one goal is simply to get the right RGB. The other, distinct goal, is to have the display have accurate primaries. The goal of getting the right RGB to the display is attainable whether or not the display is accurate or not.

Quote:
Since the chromacity of the primaries are set for a given TV, when we talk about all this colorspace twisting we are really talking about how the DVD player or TV decodes the RGB luminance values from the component signal, right?

Correct. You're just trying to make sure that you end up back where you started, with the original RGB values before it was ever encoded as component video.

Quote:
And the only reason the decoding is different from SD to HD is the fact that the encoding was also different, such that a certain value for a component signal corresponds to a different RGB triplet depending on which set of equations were used, correct?

Exactly correct. You've got it.

Quote:
Do you have the equations? I did a quick Google search but didn't find them.

Thanks a lot for your help (and Bear5k), it has really improved my understanding.

I think they're on Poynton's site, I think they're also on the DVE site. I'm sure they're around. You can also see visually the effects of mis-matched color decoding here: http://www.sigmadesigns.com/public/S...omaticity.html

And there are also some patterns that are in the first few posts of my thread that are the same but on color bars, again see the linked thread in my signature.

Hope that helps clarify things!
ChrisWiggles is offline  
post #38 of 149 Old 10-12-2007, 04:07 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by alluringreality View Post

I'm just trying to figure out what I don't get. It's quite possible there are some big lapses in my understanding considering how long it took me to get XYZ to RGB conversion in excel to match HCFR last night. What got me thinking was the comment about the computer test "if they measure the same, then this means something is wrong inside your playback software."

My impression has been that correct RGB decoding on a computer will have similar SD and HD RGB values. Is that correct or incorrect? By pulling colors some software does that and some software adjusts RGB values with HD material. HCFR seems to show that regardless of SD 601 or HD 709 colorspace, colors should have the same RGB values on a computer. I can't come up with a reason why the computer would be using the same RGB values and producing substantially different measured results between SD and HD material. If they shouldn't be similar RGB values for 75% SD color bars and 75% HD color bars, then can someone clue me into what sort of RGB values I should be seeing for test patterns on my computer between SD and HD material? Can anyone explain why HCFR appears to use the same RGB colors if that's incorrect? If colors with the same RGB numbers somehow measure differently, why is that?

I'm unclear as to what you're looking at. RGB isn't SD or HD, it's just RGB. There is no difference. Only when you encode that to component video does the question of what encode coefficients, which differ between SD and HD, even come into play.
ChrisWiggles is offline  
post #39 of 149 Old 10-12-2007, 04:10 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by zoyd View Post

Are any content producers even using the wider gamut for color correction or is it all based off of SMPTE C primaries anyway?

That is an excellent question. I don't know, however a while ago Stacey Spears indicated that mastering houses he was aware of were all still using monitors with SMPTE C primaries, making the question of whether you even wanted to use a display with 709 primaries (if available) would be accurate or not. I assume that they will change gradually to 709 as they replace their monitors, but I don't know anything about what they are using currently, or how prevalently they are using SMPTE C or 709. It's part of the reason I don't concern myself with whether or not a display has accurate primaries between SD and HD, as most of the time the primaries are wildly off SMPTE C even, with a delta that is much larger than the delta between SMPTE C and 709 anyway.
ChrisWiggles is offline  
post #40 of 149 Old 10-12-2007, 04:16 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by Bear5k View Post

Chris - Let's let them walk before making them run the 100m sprint in the Olympics? Precious few displays have correct primaries. That is before we talk about what color the phosphors really are on the BVMs used to master content.

Fundamentally, the "twist" between the SD and HD spaces can be collapsed to a single 3x3 matrix multiplication. You can either do it in the decoder or as an adjunct. However, the result is the same. The purpose of the twist is to ensure that the output chromaticities align with the chromaticities that are assumed to have been present during encoding.

Bill


The twist is not to correct for difference in primaries, but differences in encode. Whether the primaries are accurate is still a concern. The fact that the 709 matrix does follow theoretically what the primaries are does not mean that the two things are the same thing, which is I think the source of the confusion. The purpose of the twist is NOT so much to "ensure that the output chromaticities align with the chromaticities that are assumed to have been present during encoding," but merely to ensure that the RGB matches the original RGB. Chromaticities are not really involved in that at all, except in explaining the theoretical rational as to why the matrices are different, but that is what adds in the confusion. The two things are really distinct. One is the component video encode/decode flow, the other is the display chromaticity. To put it another way, if we never move to component video, and stay with RGB the whole way, we never encouter an encode/decode flow at all, and the matrix never comes into play. However, we still have primary chromaticities to pay attention to, and that is completely distinct.
ChrisWiggles is offline  
post #41 of 149 Old 10-12-2007, 04:42 PM
AVS Special Member
 
alluringreality's Avatar
 
Join Date: Jul 2006
Posts: 3,124
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 9 Post(s)
Liked: 34
Quote:
Originally Posted by ChrisWiggles View Post

I'm unclear as to what you're looking at. RGB isn't SD or HD, it's just RGB. There is no difference. Only when you encode that to component video does the question of what encode coefficients, which differ between SD and HD, even come into play.

When I said SD or HD I was referring to resolution of the file being played back. For example I would call DVD SD and 1080p HD. My guess is that those video formats are generally encoded differently when it comes to color (I guess SMPTE-C and Rec 709).

With most computer video playback software in windows (except maybe PowerDVD for copyright reasons), you can press print screen and capture an image. When you paste it into a typical image editing software you can pull RGB colors. With unexpanded SD material using VMR9 or EVR, the RGB colors reported on my computer generally match the RGB colors I've read about, such as 16 being black and 235 white.

Far as I can figure by reading, SD and HD commercial video generally uses different encoding. So I would have to think SD vs. HD is relevant when going from Ycbcr to RGB on a computer. Since I use HDMI from my video card to my TV I think the video playback software and the video drivers are the last alteration to what the display uses.

My current guess is that maybe Zoom player is correct when 75% 709 color bars from a 1080p source don't have the same RGB values as a 75% color bar from a DVD considering that I think my TV always receives a 1080p RGB signal with both. I was asking if that sort of behavior is correct, or if instead the RGB values should be the same for both SD and HD, like with Windows Media Player. I was trying to resolve why the quote I listed seemed to imply that RGB should be different if the encoded colorspaces don't match, yet why HCFR would use the same RGB for both 601 or 709 if that was true.
alluringreality is offline  
post #42 of 149 Old 10-12-2007, 04:48 PM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by ChrisWiggles View Post

The twist is not to correct for difference in primaries, but differences in encode. Whether the primaries are accurate is still a concern. The fact that the 709 matrix does follow theoretically what the primaries are does not mean that the two things are the same thing, which is I think the source of the confusion. The purpose of the twist is NOT so much to "ensure that the output chromaticities align with the chromaticities that are assumed to have been present during encoding," but merely to ensure that the RGB matches the original RGB. Chromaticities are not really involved in that at all, except in explaining the theoretical rational as to why the matrices are different, but that is what adds in the confusion. The two things are really distinct. One is the component video encode/decode flow, the other is the display chromaticity. To put it another way, if we never move to component video, and stay with RGB the whole way, we never encouter an encode/decode flow at all, and the matrix never comes into play. However, we still have primary chromaticities to pay attention to, and that is completely distinct.

Chris - Exactly where do you think the differences in RGB come from?

Since you don't believe me, re-read Poynton's ColorFAQ, specifically question #20. The relevant part:

Quote:
Originally Posted by Charles Poynton View Post

RGB values in a system employing one set of primaries can be transformed
into another set by a three-by-three linear-light matrix transform.
Generally these matrices are normalized for a white point luminance of
unity. For details, see Television Engineering Handbook [13]."

Luma (Y') is a combination of red (R'), green (G') and blue (B') in a particular ratio. That ratio, with some committee-induced issues, is basically the same as the white balance mix. The color difference signals are a little less obvious, but the intent is there, even if the arithmetic is just ever so slightly off.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #43 of 149 Old 10-12-2007, 04:53 PM
AVS Addicted Member
 
krasmuzik's Avatar
 
Join Date: Oct 1999
Location: NewPort, VA
Posts: 11,270
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Your second scenario is correct (not the numbers just the thinking).

Desaturation is not reducing the value or brightness of Red - it is done by adding white. Red+White = Pink which is a desaturated Red. But since White = Red+Green+Blue, wat you really have is More Red + Some Green+Some Blue = Pink. Then the matrix just needs to compensate for the different brightness of Red so it does not screw up the decoding while it was adjusting the gamut - so that what is Pink in HD is the correct Red in SD.

Of course the SD Red is not actually a true Pink - it is more of a slightly paler orangey Red.
krasmuzik is offline  
post #44 of 149 Old 10-12-2007, 06:14 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by krasmuzik View Post

Your second scenario is correct (not the numbers just the thinking).

Desaturation is not reducing the value or brightness of Red - it is done by adding white. Red+White = Pink which is a desaturated Red. But since White = Red+Green+Blue, wat you really have is More Red + Some Green+Some Blue = Pink. Then the matrix just needs to compensate for the different brightness of Red so it does not screw up the decoding while it was adjusting the gamut - so that what is Pink in HD is the correct Red in SD.

Of course the SD Red is not actually a true Pink - it is more of a slightly paler orangey Red.

So... if my second scenario is correct... let's take a perfect TV (perfect primaries, decoding, etc.) and perfect upscaling DVD player (perfect twisting, etc.). Please correct me where I'm wrong...

1) When we view the SD Avia disc for red primary (on our perfect TV and DVD player), our measurement device should show the SD (601) red chromacity even though the image has been upscaled to an HD resolution. This is because the DVD player has twisted the colorspace for us. The same should be true for all other primaries.

2) If the 601 primaries, as measured from the Avia disc, are dead on and the color decoding of the TV is perfect, then the 709 primaries should also be dead on. This could prove valuble in practice because we could calibrate our HDTV's with an SD disc by making sure that the 601 primaries are correct and the color decoding is correct (or at least as close as possible).

3) What does the TV do with a 480i signal from a standard player? It would seem that the TV would have to do the colorspace twisting in place of the DVD player to get a consistent output across all sources. For instance:

DVD player sends our (phony) 100% red signal in component form to the TV (it is untouched, just read straight from disc, as no upconversion is being done):

Y = 1
Pb = 0.4
Pr = 0.2

The TV receives this signal and uses Rec 601 to decode to RGB (since it sees an SD resolution). The decoded RGB is:

RGB 235,0,0

Which would be correct for an SDTV... but if an HDTV uses this RGB as is, then it will display the Rec 709 primary (100% red) instead of the Rec 601. This means the TV would have to do some colorspace twisting of its own, correct?

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #45 of 149 Old 10-12-2007, 06:28 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,442
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 87 Post(s)
Liked: 309
Quote:
Originally Posted by hwjohn View Post


Which would be correct for an SDTV... but if an HDTV uses this RGB as is, then it will display the Rec 709 primary (100% red) instead of the Rec 601. This means the TV would have to do some colorspace twisting of its own, correct?

no, you are mixing up decoding with primary chromiticity. Your display has only one set of primaries and unless it employs an automatic CMS (which I don't think exists) you just want it to use a decode that matches the encode. DVD players do the twist on the assumption that the display expects 601 for SD resolutions and 709 for HD resolutions.
zoyd is online now  
post #46 of 149 Old 10-12-2007, 06:51 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by zoyd View Post

no, you are mixing up decoding with primary chromiticity. Your display has only one set of primaries and unless it employs an automatic CMS (which I don't think exists) you just want it to use a decode that matches the encode. DVD players do the twist on the assumption that the display expects 601 for SD resolutions and 709 for HD resolutions.

Your statement seems to correspond to scenario 1 in my earlier post, where the only thing important is to make sure the encoding/decoding is consistent from YPrPb<->RGB based on which set of equations was used to encode the original signal. This approach simply ensures that the RGB triplet decoded by the TV is the same as the RGB triplet that was encoded to YPrPb on the disc.

However, as explained in scenario 2 in my post, I think it is possible to display the Rec 601 primaries (they aren't really the primaries any more) on an HDTV with Rec 709 primaries. This is because the 601 primaries are inside the gamut created by the 709 primaries. This "twist" is the more complicated of the two scenarios.

There seems to be some disagreement as to which scenario actually takes place during this "twisting." It seems like scenario 2 is plausible, but I do not know if it is used in practice. According to krasmuzik, it is. According to others, scenario 1 is used.

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #47 of 149 Old 10-12-2007, 07:02 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,442
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 87 Post(s)
Liked: 309
My understanding is (and it may not be correct) is that you need SMPTE C primaries for SMPTE C source and Rec709 primaries for Rec709 source, the encode/decode process (or information delivery system) is not relevant. To display SMPTE C source using Rec709 primaries would require an extra matrix operation either on the production side or the display side.
zoyd is online now  
post #48 of 149 Old 10-12-2007, 09:08 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by Bear5k View Post

Chris - Exactly where do you think the differences in RGB come from?

I'm not clear what differences you are referring to.

Quote:


Since you don't believe me, re-read Poynton's ColorFAQ, specifically question #20. The relevant part:



Luma (Y') is a combination of red (R'), green (G') and blue (B') in a particular ratio. That ratio, with some committee-induced issues, is basically the same as the white balance mix. The color difference signals are a little less obvious, but the intent is there, even if the arithmetic is just ever so slightly off.

Bill

Yes, again, I'm not sure how that differs from what I've described?

It isn't a question of me not believing you, the reason why the Rec 709 coefficients differ is indeed (as you state) because they were derived theoretically from the 709 primary coefficients. But that fact is not really relevant to the signal flow. For instance, the 601 coefficients are holdovers from far outdated primaries from 1950s, and do not match theoretically what they would be for SMPTE C. As Poynton describes, "the luma coefficients in SDTV no longer theoretically match the primaries. The mismatch has little practical significance." He also states in the margin, "...however, the mismatch of luma coefficients between SDTV and HDTV has great practical significance!"

The goal is to arrive again at the original RGB values of the content, regardless of what kind of primaries are being assumed. That's what color decoding is for. This issue would never even be a concern except that we choose to use component video to chroma subsample. If we stuck with RGB as I mentioned above, we never would have moved away from the original RGB to another color space, and then been met with the challenge to return ourselves, unchanged, to the original values.

So, putting it yet another way, if you have a 75% colorbar expressed in RGB, those RGB values will be identical in the RGB domain between SD and HD. However, in the component domain, they will differ.
ChrisWiggles is offline  
post #49 of 149 Old 10-12-2007, 09:13 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by hwjohn View Post

So... if my second scenario is correct... let's take a perfect TV (perfect primaries, decoding, etc.) and perfect upscaling DVD player (perfect twisting, etc.). Please correct me where I'm wrong...

1) When we view the SD Avia disc for red primary (on our perfect TV and DVD player), our measurement device should show the SD (601) red chromacity even though the image has been upscaled to an HD resolution. This is because the DVD player has twisted the colorspace for us. The same should be true for all other primaries.

If the display's primaries are SMPTE C, it will read SMPTE C no matter WHAT you feed it, as long as you are viewing a pattern that is indeed isolating a single color. You could feed it spaghetti, and the primary will be whatever the display's primary is. That never changes unless you physically alter the display (by filtering a CRT for instance, or with a CMS system, etc).

Quote:


2) If the 601 primaries, as measured from the Avia disc, are dead on and the color decoding of the TV is perfect, then the 709 primaries should also be dead on. This could prove valuble in practice because we could calibrate our HDTV's with an SD disc by making sure that the 601 primaries are correct and the color decoding is correct (or at least as close as possible).

No, the display's primaries will never change. IF you had an HD source, properly decoded with rec 709, your color decoding will be accurate, but your display, being a SMPTE C display, will still be a SMPTE C display.

Quote:


3) What does the TV do with a 480i signal from a standard player? It would seem that the TV would have to do the colorspace twisting in place of the DVD player to get a consistent output across all sources. For instance:

It should just decode it with 601, since it is an SD source and presumably was encoded in 601.

Quote:


DVD player sends our (phony) 100% red signal in component form to the TV (it is untouched, just read straight from disc, as no upconversion is being done):

Y = 1
Pb = 0.4
Pr = 0.2

The TV receives this signal and uses Rec 601 to decode to RGB (since it sees an SD resolution). The decoded RGB is:

RGB 235,0,0

Which would be correct for an SDTV... but if an HDTV uses this RGB as is, then it will display the Rec 709 primary (100% red) instead of the Rec 601. This means the TV would have to do some colorspace twisting of its own, correct?

No, it would still decode that SD content in 601. No twist. The content calls for 100% red, it should be decoded into RGB and display 100% red. Now, there will be a chromaticity error since the red of the display is not the same red called for in the content, but it still will, and should be 100% red.
ChrisWiggles is offline  
post #50 of 149 Old 10-12-2007, 09:14 PM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hwjohn View Post

So... if my second scenario is correct... let's take a perfect TV (perfect primaries, decoding, etc.) and perfect upscaling DVD player (perfect twisting, etc.). Please correct me where I'm wrong...

1) When we view the SD Avia disc for red primary (on our perfect TV and DVD player), our measurement device should show the SD (601) red chromacity even though the image has been upscaled to an HD resolution. This is because the DVD player has twisted the colorspace for us. The same should be true for all other primaries.

Yes. The "smaller" gamut should be correct, within reason for bit loss due to the recasting of the primaries.

Note: this is all theory, since the original AVIA has color errors...

Quote:


2) If the 601 primaries, as measured from the Avia disc, are dead on and the color decoding of the TV is perfect, then the 709 primaries should also be dead on. This could prove valuble in practice because we could calibrate our HDTV's with an SD disc by making sure that the 601 primaries are correct and the color decoding is correct (or at least as close as possible).

Close. You are running into using assumptions to prove your conclusion. We assumed correct 709 primaries (we also basically assumed infinite bit depth) to this point. Assuming infinite bit depth, you really can't say anything about where the larger gamut primaries are located by measuring the re-cast locations. You can calculate a new matrix to give you perfect SD colorimetry, while still having incorrect physical primaries. This is essentially what an external CMS will do. What an upconverting DVD player should do is assume perfect primaries and use the defined matrix for recasting SD into HD.

So that we are clear, the color decoder's job is simply to recover the RGB data from the Component video stream. The processor is what does the twist. From a silicon standpoint, this CAN be done all in one calculation since the matrices can be pre-loaded.

Quote:


3) What does the TV do with a 480i signal from a standard player? It would seem that the TV would have to do the colorspace twisting in place of the DVD player to get a consistent output across all sources. For instance:

DVD player sends our (phony) 100% red signal in component form to the TV (it is untouched, just read straight from disc, as no upconversion is being done):

Y = 1
Pb = 0.4
Pr = 0.2

The TV receives this signal and uses Rec 601 to decode to RGB (since it sees an SD resolution). The decoded RGB is:

RGB 235,0,0

Which would be correct for an SDTV... but if an HDTV uses this RGB as is, then it will display the Rec 709 primary (100% red) instead of the Rec 601. This means the TV would have to do some colorspace twisting of its own, correct?

Yes. This is what someone like Greg Rogers tests when looking at upconversion and color decoding. He has even been kind enough to post an applet that does some of the matrix math for you to give you the Luminance values to use when measuring your own sets.

Let's get down to something very concrete. Does anyone think that these two equations are unrelated:

Y' = 0.2126R' + 0.7152G' + 0.0722B'
Y = 0.2126R + 0.7152G + 0.0722B

This mix is defined due to the locations of the white point (D65) and the tristimulus primary locations.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #51 of 149 Old 10-12-2007, 09:15 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by hwjohn View Post

Your statement seems to correspond to scenario 1 in my earlier post, where the only thing important is to make sure the encoding/decoding is consistent from YPrPb<->RGB based on which set of equations was used to encode the original signal. This approach simply ensures that the RGB triplet decoded by the TV is the same as the RGB triplet that was encoded to YPrPb on the disc.

Correct.

Quote:


However, as explained in scenario 2 in my post, I think it is possible to display the Rec 601 primaries (they aren't really the primaries any more) on an HDTV with Rec 709 primaries. This is because the 601 primaries are inside the gamut created by the 709 primaries. This "twist" is the more complicated of the two scenarios.

Yes, but this is not a simple matrix twist. You'd have to do that with a CMS system.

Quote:


There seems to be some disagreement as to which scenario actually takes place during this "twisting." It seems like scenario 2 is plausible, but I do not know if it is used in practice. According to krasmuzik, it is. According to others, scenario 1 is used.

Scenario 1. The goal there is simply color decoding to avoid inaccurate colors in the form of oversaturation of undersaturation(push and depression), especially of green. Again, see the sample images I cited previously for illustration of these problems.
ChrisWiggles is offline  
post #52 of 149 Old 10-12-2007, 09:27 PM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by ChrisWiggles View Post

The goal is to arrive again at the original RGB values of the content, regardless of what kind of primaries are being assumed. That's what color decoding is for. This issue would never even be a concern except that we choose to use component video to chroma subsample.

Chris - You need to read about color adaptation. That's really the piece you are missing. What does the RGB mean? What does (255,0,0) tell you? It needs context. That context is the color system. Otherwise, you do not know anything about what that "original RGB" is.

Quote:


If we stuck with RGB as I mentioned above, we never would have moved away from the original RGB to another color space, and then been met with the challenge to return ourselves, unchanged, to the original values.

In this, you are wrong. Again, see above. You still need meta data about RGB to determine what to do with it. There is nothing magical about RGB that gives it more context than component video. The "twist" should also happen when going from RGB coming in at 480i and going back out at 1080i.

Quote:


So, putting it yet another way, if you have a 75% colorbar expressed in RGB, those RGB values will be identical in the RGB domain between SD and HD. However, in the component domain, they will differ.

75% in which color space?

Really guys, I give up.

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #53 of 149 Old 10-12-2007, 09:37 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Ok, I guess we are going to have to agree to disagree

In my very humble, and somewhat dumb opinion, I think scenario 1 and 2 from my earlier post are both possible (Chris and Zoyd are Scenario 1, Bear5k and KrazMuzik seem to be Scenario 2). This is evident after reading the Poynton #20 that Bear5k mentioned. It seems relatively trivial to do two matrix operations... the first to convert YPrPb to RGB (correctly), and the second to do the "twist" to "re-cast" the primaries (as shown in #20). Whether or not they can be done in one step or not, it looks like it can be done.

I guess the real question now is which scenario is done in practice, not theory. I really appreciate everyone's input and I don't want to start any kind of "fight," but do we have any proof of what actually happens in modern players/TVs?

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #54 of 149 Old 10-12-2007, 09:45 PM
AVS Special Member
 
hwjohn's Avatar
 
Join Date: Oct 2006
Location: Down by the river
Posts: 1,018
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by Bear5k View Post

Assuming infinite bit depth, you really can't say anything about where the larger gamut primaries are located by measuring the re-cast locations.

Bill

Bill,
I don't quite understand this statement. If a TV can calculate (via matrix operations) the "re-cast" locations from the 709 primaries, then why can't we go the other way and calculate the 709 primaries from the "re-cast" locations?

AVS HD 709 - Free calibration disks
The 2007 Patriots: 18 -1
Tom who?
"...the small of napalm in the evening breeze, as I crouch behind a shopping cart in the parking lot..." - The Mall Ninja
hwjohn is offline  
post #55 of 149 Old 10-13-2007, 04:55 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,442
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 87 Post(s)
Liked: 309
Quote:
Originally Posted by Bear5k View Post

Chris - You need to read about color adaptation. That's really the piece you are missing. What does the RGB mean? What does (255,0,0) tell you? It needs context. That context is the color system. Otherwise, you do not know anything about what that "original RGB" is.


In this, you are wrong. Again, see above. You still need meta data about RGB to determine what to do with it. There is nothing magical about RGB that gives it more context than component video. The "twist" should also happen when going from RGB coming in at 480i and going back out at 1080i.


75% in which color space?

Really guys, I give up.


I didn't read Chris's comments the way you did, he's just separating the encode/decode process from the color science (I like the bit about using spaghetti to deliver RGB) . It's obvious "red" means nothing on it's own.


hwjohn,

I think we are all in agreement that scenario 1 is what most people have to live with and that scenario 2 is possible but requires a CMS.
zoyd is online now  
post #56 of 149 Old 10-13-2007, 06:55 AM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by hwjohn View Post

Bill,
I don't quite understand this statement. If a TV can calculate (via matrix operations) the "re-cast" locations from the 709 primaries, then why can't we go the other way and calculate the 709 primaries from the "re-cast" locations?

You are always going to be constrained by the physical primaries. In other words, if all that you have are SMPTE-C primaries, then that describes the boundary of your gamut, no matter what encoding scheme is used. You can recast the colors into the larger gamut, and you ought to, but you are going to have a lot of clipping as a result. In this scenario, it depends upon the material whether you want to do this. Films with a lot of deep blues may end up with objectionable banding if it was shot and mastered in 709 and you are confined to an 8-bit pipeline.

A CMS is a dynamic thing. What we are talking about here are simple matrix operations that ought to be done in a properly upconverting DVD player with an extension into what the display also ought to do when it processes the signal.

So that all of this is painfully clear from me:
  • A color decoder, when fed its native signal (e.g., HD for HD), should notchange the location of the primaries, unless it is poorly designed. It ought to change the way these primaries mix (relative luminance levels), though.
  • When fed HD material, a display ought to decode these signals with a matrix that takes into account its native primary locations. See Greg Rogers' RS1 review and the applet he released for how this works in practice. We have our own software in-house, but we are not releasing it yet.
  • The upconversion process ought to include a "twist" to recast SD colors into the HD gamut. This is a static matrix, and not a dynamic matrix that would qualify as a CMS. If they do not, then they are not preserving rendering intent.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #57 of 149 Old 10-13-2007, 01:52 PM
AVS Special Member
 
alluringreality's Avatar
 
Join Date: Jul 2006
Posts: 3,124
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 9 Post(s)
Liked: 34
Quote:
Originally Posted by Bear5k View Post

The upconversion process ought to include a "twist" to recast SD colors into the HD gamut. This is a static matrix, and not a dynamic matrix that would qualify as a CMS. If they do not, then they are not preserving rendering intent.

Okay, the question I've basically been asking though - is there any way to check that's happening correctly? I would think that if things are being run through a static matrix, then the conversion could be checked for general accuracy after that upconversion or by measuring on-screen. I have two video sources where I believe this conversion happens, on the computer and also my HD DVD player that I use for DVDs. All I'm looking to do is to put the theory into practical and useful means of testing how my video playback is actually working so I can tell if I'm getting correct colors for both SD and HD material. Like the original poster, I do have access to a basic colorimeter if that can be used as a means of checking.


THE COMPUTER:
My computer sends a 1080p resolution out to my TV over HDMI. From your comment about my suggested SD vs HD test on the computer, I get the impression that if someone plays back a typical SD DVD with 75% color bars then the resulting RGB values (checked by colorcop or print screen) should not match the RGB values from an HD video pattern with Rec. 709 75% color bars if they're both to be displayed on the same monitor receiving the same resolution.

So now that I'm under the impression that the RGB values should be differnt, is there a way I could tell if the RGB differences are correct? I could post all the colorcop or print screens I've looked at, but I still cannot find settings or a computer program that seems to match the above quoted scenario. My experience of using a matrix is merely limited to going from XYZ measured values to RGB in xcel, but I cannot find anything with my computer that seems to align with the above quote and that RGB values would differ on the computer for video encoded in different color spaces. The only RGB values I'm seeing that seem to at all possibly conform with the theoretical scenario being discussed is the following:

Zoom Player or The KMPlayer
File from Ovation SD DVD color bars
Gray - 180, 180, 180
Red - 183, 15, 15

Zoom Player or The KMPlayer
1080p video from w6rz.net 709 75% color bars
Gray - 180, 180, 180
Red - 169, 0, 17

Due to how other programs seem to measure similar to the SD DVD test, I would have to think that 601 color is being used and instead it's 709 that's being altered here. Again I'm sure it's possible to just dismissively say, those programs aren't converting HD correctly. Okay fine, but both PowerDVD and Windows media player seem to just make SD and HD the same RGB which you said was incorrect. If all that needs to be done is a simple static matrix, then I would have to think there's some test I could do to know that my computer is displaying color for SD and HD video correctly. krasmuzik did make mention of monitor drivers, but I've never really heard of such things being discussed for HDTVs in the HTPC area.


HD DVD PLAYER:
If I measure my HD DVD player's color, I do get different X, Y, and Z values between SD DVD and HD DVD color bars. The grayscale and xy values match, but Y varies. If I setup my color decoder with 709 patterns, can my XYZ values from SD and HD sources be used to check how close the player is getting SD by the upconversion?
alluringreality is offline  
post #58 of 149 Old 10-13-2007, 02:35 PM
AVS Club Gold
 
Bear5k's Avatar
 
Join Date: Feb 2006
Location: Houston, TX
Posts: 2,239
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by alluringreality View Post

Okay, the question I've basically been asking though - is there any way to check that's happening correctly? I would think that if things are being run through a static matrix, then the conversion could be checked for general accuracy after that upconversion or by measuring on-screen. I have two video sources where I believe this conversion happens, on the computer and also my HD DVD player that I use for DVDs. All I'm looking to do is to put the theory into practical and useful means of testing how my video playback is actually working so I can tell if I'm getting correct colors for both SD and HD material. Like the original poster, I do have access to a basic colorimeter if that can be used as a means of checking.

As I said, we have some stuff in-house that we are building out to go with our upcoming Pro release. Some subset of this functionality will be included in a future point release for v3. Other packages handle this now, some do not. I am willing to do one-offs for CalMAN users, provided that the burden isn't too great. Greg Rogers applet is the best freeware solution, and it will get you close.

Quote:


THE COMPUTER:
My computer sends a 1080p resolution out to my TV over HDMI. From your comment about my suggested SD vs HD test on the computer, I get the impression that if someone plays back a typical SD DVD with 75% color bars then the resulting RGB values (checked by colorcop or print screen) should not match the RGB values from an HD video pattern with Rec. 709 75% color bars if they're both to be displayed on the same monitor receiving the same resolution.

The rain in Spain falls mainly in the plain.

Quote:


So now that I'm under the impression that the RGB values should be differnt, is there a way I could tell if the RGB differences are correct? I could post all the colorcop or print screens I've looked at, but I still cannot find settings or a computer program that seems to match the above quoted scenario. My experience of using a matrix is merely limited to going from XYZ measured values to RGB in xcel, but I cannot find anything with my computer that seems to align with the above quote and that RGB values would differ on the computer for video encoded in different color spaces. The only RGB values I'm seeing that seem to at all possibly conform with the theoretical scenario being discussed is the following:

Zoom Player or The KMPlayer
File from Ovation SD DVD color bars
Gray - 180, 180, 180
Red - 183, 15, 15

Zoom Player or The KMPlayer
1080p video from w6rz.net 709 75% color bars
Gray - 180, 180, 180
Red - 169, 0, 17

Due to how other programs seem to measure similar to the SD DVD test, I would have to think that 601 color is being used and instead it's 709 that's being altered here. Again I'm sure it's possible to just dismissively say, those programs aren't converting HD correctly. Okay fine, but both PowerDVD and Windows media player seem to just make SD and HD the same RGB which you said was incorrect. If all that needs to be done is a simple static matrix, then I would have to think there's some test I could do to know that my computer is displaying color for SD and HD video correctly. krasmuzik did make mention of monitor drivers, but I've never really heard of such things being discussed for HDTVs in the HTPC area.

In addition to rolling your own model, there are existing options referenced above. HTPCs are both a boon and a bane, and troubleshooting the entire internal software chain is one of the complexities. My advice to people is to calibrate to the least complex amount of software you can get away with in the PC, typically the desktop or DirectDraw app (like our HTPC Pattern Generator), and then once the display is calibrated to that, then you can begin dissecting the playback chain to determine where the trouble spots are.

Quote:


HD DVD PLAYER:
If I measure my HD DVD player's color, I do get different X, Y, and Z values between SD DVD and HD DVD color bars. The grayscale and xy values match, but Y varies. If I setup my color decoder with 709 patterns, can my XYZ values from SD and HD sources be used to check how close the player is getting SD by the upconversion?

I'm not quite sure I understand you. Are the xy values matching at the periphery for both SD and HD? If so, then something is clearly wrong, since the HD gamut is larger. Either the HD gamut is too small, or the SD gamut has been expanded to be too large. For grayscale, since SD, HD and PAL all share the same whitepoint (D65), they ought to match here. It should only be at the periphery where you see differences.

Bill

Color accuracy evangelist and CalMAN insider
Bear5k is offline  
post #59 of 149 Old 10-13-2007, 02:38 PM
 
ChrisWiggles's Avatar
 
Join Date: Nov 2002
Location: Seattle
Posts: 20,730
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 14
Quote:
Originally Posted by Bear5k View Post

Chris - You need to read about color adaptation. That's really the piece you are missing. What does the RGB mean? What does (255,0,0) tell you? It needs context. That context is the color system. Otherwise, you do not know anything about what that "original RGB" is.

Yes, but what is your point? That's not relevant to the question of moving between RGB and a color opponent space.

Quote:


In this, you are wrong. Again, see above. You still need meta data about RGB to determine what to do with it. There is nothing magical about RGB that gives it more context than component video. The "twist" should also happen when going from RGB coming in at 480i and going back out at 1080i.

No, there is no twist to be made in RGB because there is no difference there. IT only occurs with the flow to component video. If you don't move to a component space, there is no matrix transform at all, and there are no differences that you have to account for in those matrix transforms because they are not present in the signal flow at all.

Quote:


75% in which color space?

Really guys, I give up.

Whether it's 601 or 709, the patterns in RGB would be identical. They will assume different primaries, but that's not really significant to the questions we're discussing here. That pattern would be DIFFERENT however as soon as you encoded the RGB into component video. But upon decoding, it would return the original RGB values and they would be identical.

Again, I really don't understand why you've taken an attitude about this, I'm just trying to keep these issues distinct and clear so people can understand them, and I'm not sure why that's so problematic?
ChrisWiggles is offline  
post #60 of 149 Old 10-13-2007, 02:44 PM
AVS Special Member
 
dlarsen's Avatar
 
Join Date: Mar 2001
Location: Beaverton, OR, USA
Posts: 1,908
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by alluringreality View Post

krasmuzik did make mention of monitor drivers, but I've never really heard of such things being discussed for HDTVs in the HTPC area.

If you're rendering video to a VMR9 surface on an HTPC and wish to alter the levels or change the mix of the final RGB you might look at editing the LUT via utilities like VideoEqualizer and or PowerStrip and creating profiles.
http://archive2.avsforum.com/avs-vb/...d.php?t=777353

If you're looking for something to control and manipulate between .601 and .709 to RGB you might look at utilities like the Avisynth utility Convert.

http://avisynth.org/oldwiki/index.php?page=Convert

Dave
dlarsen is offline  
Reply Display Calibration

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off