AVS › AVS Forum › Display Devices › Display Calibration › Calibration disc for SD?
New Posts  All Forums:Forum Nav:

Calibration disc for SD?

post #1 of 25
Thread Starter 
I recently purchased an LCD TV and have heard a lot about getting it calibrated. I know the best option is to have it professionally calibrated, but I don't think my wife will go for that.

So, I intended to use a disc for the calibration. But, I also do not have Blu Ray or HD-DVD player. So, I will be using a standard DVD player.

Can I use the Avia disc in standard DVD player? I am pretty sure the DVE disc will, but what about Avia?

Also, what about using the free AVS DVD ones located here? They are both in HD-DVD and Blu Ray, but is there a standard DVD one I can use?

I plan on upgrading to a Blu Ray or HD-DVD player in the future, but right now all I have is an Xbox 360 and don't want to wait to calibrate it. Thanks!
post #2 of 25
I'd just use the free THX Optimizer that comes with many DVD"s these days...it should get your set looking good...better than the default settings for sure..

I wouldn't invest money in getting an LCD professionally calibrated unless you are an uber perfectionist.
post #3 of 25
Quote:
Originally Posted by cmcfalls View Post

I recently purchased an LCD TV and have heard a lot about getting it calibrated. I know the best option is to have it professionally calibrated, but I don't think my wife will go for that.

So, I intended to use a disc for the calibration. But, I also do not have Blu Ray or HD-DVD player. So, I will be using a standard DVD player.

Can I use the Avia disc in standard DVD player? I am pretty sure the DVE disc will, but what about Avia?

Also, what about using the free AVS DVD ones located here? They are both in HD-DVD and Blu Ray, but is there a standard DVD one I can use?

I plan on upgrading to a Blu Ray or HD-DVD player in the future, but right now all I have is an Xbox 360 and don't want to wait to calibrate it. Thanks!

A lot of questions here so here goes:

1. I disagree with the previous poster in that calibration is a must for those for whom the best/perfect picture is a must...after having my displays calibrated I could not live without it and have since learnt how to do it myself.

2. A standard dvd player and a standard disk can be used to calibrate a HD LCD...the one fly in the ointment is that you are assuming that the LCD's video processor is properly converting SMPTE-C colot gamut (i.e. SD) to the REC 709 color gamut (i.e. HD). As such an HD-DVD player or Blu-Ray player with HD test disks would be better.

3. A disk is not a disk...based on my reading -- and what I use when using a disk -- the most accurate and easiest to navigate disk is GetGray which cost USD 25.00...the thread for this desk is in this forum...buy the disk, you will not be disappointed (NOTE: You need the capability to burn DVDs).

HTH

Cheers.
post #4 of 25
Quote:


2. A standard dvd player and a standard disk can be used to calibrate a HD LCD...the one fly in the ointment is that you are assuming that the LCD's video processor is properly converting SMPTE-C colot gamut (i.e. SD) to the REC 709 color gamut (i.e. HD). As such an HD-DVD player or Blu-Ray player with HD test disks would be better.

There is not correct, there is no twist of gamut. There is a twist of the component video matrix between 601 and 709. There is no ability to affect any change between SMPTE C and 709 gamut, this is physical to the display device itself and what its primaries are. These are easily confused because they both deal with color, but they are quite distinct. Also, you are making the very significant assumption of an upscaling DVD player that is outputting component video (digital or analog). It sounds like the poster was just asking about a "standard" DVD player, which I think it is safe to assume means just a 480i/480p DVD player, not one that upscales. If there is no upscaling that crosses the SD/HD threshold, there is no need for a twist of colorspace (and also again assuming component video, if it's RGB out it's a moot point).
post #5 of 25
Quote:
Originally Posted by John Ryder View Post

I'd just use the free THX Optimizer that comes with many DVD"s these days...it should get your set looking good...better than the default settings for sure..

I wouldn't invest money in getting an LCD professionally calibrated unless you are an uber perfectionist.

I recommend against using the Optimode patterns, as they vary from disc to disc, which means necessarily that some are wrong. They work as a temporary stopgap, but beyond that their use is fairly limited, and the pattern complement is minimal.

I very much recommend Avia II generally, and also GetGray for digital displays.
post #6 of 25
Quote:
Originally Posted by ChrisWiggles View Post

There is not correct, there is no twist of gamut. There is a twist of the component video matrix between 601 and 709. There is no ability to affect any change between SMPTE C and 709 gamut, this is physical to the display device itself and what its primaries are. These are easily confused because they both deal with color, but they are quite distinct. Also, you are making the very significant assumption of an upscaling DVD player that is outputting component video (digital or analog). It sounds like the poster was just asking about a "standard" DVD player, which I think it is safe to assume means just a 480i/480p DVD player, not one that upscales. If there is no upscaling that crosses the SD/HD threshold, there is no need for a twist of colorspace (and also again assuming component video, if it's RGB out it's a moot point).

It is possible to "re-map" or "twist" (whatever you want to call it) the 709 gamut to SMPTE-C. Whether a player actually does it or not is a different question. Bear5k has discussed this pretty extensively.
post #7 of 25
Quote:
Originally Posted by hwjohn View Post

It is possible to "re-map" or "twist" (whatever you want to call it) the 709 gamut to SMPTE-C. Whether a player actually does it or not is a different question. Bear5k has discussed this pretty extensively.

This is a source of ongoing disagreement between Chris and me. Personally, I'd like for more enthusiasts to demand a) accurate primaries, and b) color decoding that preserves rendering intent. If you have (a), then (b) is pretty trivial. If you don't have (a), then I'll take "best efforts" on (b) and trust in my Radiance to bring the gamut into shape.

Bill
post #8 of 25
Quote:
Originally Posted by ChrisWiggles View Post

There is not correct, there is no twist of gamut. There is a twist of the component video matrix between 601 and 709. There is no ability to affect any change between SMPTE C and 709 gamut, this is physical to the display device itself and what its primaries are. These are easily confused because they both deal with color, but they are quite distinct. Also, you are making the very significant assumption of an upscaling DVD player that is outputting component video (digital or analog). It sounds like the poster was just asking about a "standard" DVD player, which I think it is safe to assume means just a 480i/480p DVD player, not one that upscales. If there is no upscaling that crosses the SD/HD threshold, there is no need for a twist of colorspace (and also again assuming component video, if it's RGB out it's a moot point).

Chris:

Although you are correct that I did simplify things in that I

(i) assumed the DVD player would be outputting YCbCr
(ii) assumed that the SD primaries would be mapped to HD primaries and
(iii) assumed that the display's gamut was REC 709 I do respectfully -- and I do mean respectfully -- disagree with you...

And here is why:

-- Yes, the display primaries are either SMPTE-C or REC 709 and calibration can not change that...they are what they are!

-- A SD signal at some point must be converted to a HD signal to be dispalyed on a HD device (and this will occur in the display since the OP is using a SD DVD plater)...so, the point is that to the extent that SMPTE-C red is mapped to REC 709 red (i.e. because I am assuming that the display's color gamut is REC 709 and that the RGB triplet rather than the RGB rendering intent is being preserved) then a SD test disk in a SD DVD player can be used to calibrate a REC 709 color gamut display..

Are we closer to agreeing?
post #9 of 25
Quote:
Originally Posted by hwjohn View Post

It is possible to "re-map" or "twist" (whatever you want to call it) the 709 gamut to SMPTE-C. Whether a player actually does it or not is a different question. Bear5k has discussed this pretty extensively.

No, the player does not do this. Some displays have CMS capabilities that allow you to adjust the effective primaries within the boundaries of the maximum physical gamut, though most do not. The matrix twist has no bearing on the display gamut whatsoever and only involves accurate color encode/decode flow. Whenever a "twist" is described, it most certainly refers to the component video colorspace and not to gamut, as it is describing the location and relationship of the component video cube to the RGB unit cube and its angle.
post #10 of 25
Quote:
Originally Posted by Joelc View Post

Chris:

Although you are correct that I did simplify things in that I

(i) assumed the DVD player would be outputting YCbCr
(ii) assumed that the SD primaries would be mapped to HD primaries and
(iii) assumed that the display's gamut was REC 709 I do respectfully -- and I do mean respectfully -- disagree with you...

And here is why:

-- Yes, the display primaries are either SMPTE-C or REC 709 and calibration can not change that...they are what they are!

-- A SD signal at some point must be converted to a HD signal to be dispalyed on a HD device (and this will occur in the display since the OP is using a SD DVD plater)...so, the point is that to the extent that SMPTE-C red is mapped to REC 709 red (i.e. because I am assuming that the display's color gamut is REC 709 and that the RGB triplet rather than the RGB rendering intent is being preserved) then a SD test disk in a SD DVD player can be used to calibrate a REC 709 color gamut display..

Are we closer to agreeing?

Unfortunately, no. Again, this is the common confusion between gamut on the one hand, and the component video encode on the other. They are two distinct issues. Your assumption ii is erroneous. The player has no ability to map any primaries at all. The player has no primaries. It can only output signals to which a display reacts, the DISPLAY has primaries which on some displays may be altered either by physically altering the display (for instance filtering a projection CRT device) or through electronic manipulation of the effective display primaries within the maximum gamut that is physically inherent to the display.

Quote:
-- A SD signal at some point must be converted to a HD signal to be dispalyed on a HD device (and this will occur in the display since the OP is using a SD DVD plater)...so, the point is that to the extent that SMPTE-C red is mapped to REC 709 red

Nope. The twist is for the color encode between 601 matrix and 709 matrix. It has NOTHING to do with the gamut difference between SMPTE C and 709. The twist that the player is performing is to preserve the correct color decoding, and that is all. It has no bearing on gamut.

I feel like a broken record since I've been trying to hammer this point home for quite some time, but I cannot emphasize it enough: color encode/decode flow is completely separate from the color primary position. Several people in this thread are confusing the former as the latter. The issue of choosing 601 or 709 to decode a YCbCr source back into RGB only has to do with accurate color decoding, it does NOT have to do with the primary location. That is what a player twist is for, and that is all it's for. If you have a display that is capable of altering its primaries between SMPTE C and 709, that is a completely different question, and is completely distinct from whether or the colors have been correctly decoded back into RGB.
post #11 of 25
Greg Rogers has a brief explanation of this difference here:

http://www.avsforum.com/avs-vb/showt...4#post12651674

quoted in entirety:
Quote:
Quote:
Originally Posted by Kris Deering
"Hey Greg

I think people here are still having trouble differentiating between color decoding and color primary position. They are two seperate animals but easy to get confused in general conversation. "

endquote

Gregr:
Yes, I agree. It's been confused several times above. But I'm having trouble figuring out how to explain the difference and be more clear.

Color decoding is how signals are converted from YCbCr to RGB, color encoding is how signals are converted from RGB to YCbCr. All projectors with analog YPbPr or digital YCbCr inputs must have the ability to switch between Rec 601 and Rec 709 color decoding in order to be compatible with both standard-definition and high-definition input signals. Some projectors (not all) allow the user to manually select which standard is used for color decoding. Sometimes they call that a Color Space selection, which is probably what confuses a lot of people.

SMPTE-C primaries or Rec. 709 primaries refer to the desired color of the red, green, and blue primaries used by the projector. In today's projectors the actual (native) colors of the red and green primaries are almost always more saturated than the colors defined by either of those standards. In many cases, there is nothing the user can do about that in the projector (although an external CMS - what Joel is doing - may be used). If the primaries are wrong, the colors produced by the projector will be wrong (although some people prefer that the primaries are wrong - that is a different issue). But in some projectors an electronic Color Management System (CMS) is provided, which allows the video signals to be modified so that 100% red, green, and blue signals produce colors (virtual primaries) different than the native primaries of the projector. In that case, the CMS can sometimes be used to calibrate the virtual primaries so that they are at (or close to) the location of the SMPTE-C and Rec. 709 primaries. i.e. a virtual color gamut is created electronically that can be made to match the standards. In that case, if the CMS is designed correctly, all of the colors within the virtual color gamut are modified to match the standards, and the projector can produce accurate colors.

The Marantz was cited earlier as having this ability - it does not. The InFocus was also cited as having this ability - I haven't seen one of those in a while but earlier versions did not have this ability. The Sharp XV-Z projectors have such a CMS, as did the Yamaha projectors I mentioned earlier. I've been told the Samsung projector mentioned by Chris had the ability to be calibrated in this way, but I don't know what user adjustments it had. Not all projectors that advertise or claim a CMS system have the ability to be calibrated correctly to the standards because they may lack the ability to make all of the necessary independent adjustments. i.e. just because a projector allows you to change its primary (or other) colors doesn't mean it allows you to do it correctly to match (or get close to) the standards. Some of the Sony projectors have a Wide and Normal color space mode. In the VPL-VW60 the Normal mode is relatively close to the SMPTE-C primaries, but it wasn't in previous Sony projectors that had Wide and Normal modes.
__________________
Greg Rogers
AccuPel
Widescreen Review
post #12 of 25
Quote:
Originally Posted by ChrisWiggles View Post

No, the player does not do this. Some displays have CMS capabilities that allow you to adjust the effective primaries within the boundaries of the maximum physical gamut, though most do not. The matrix twist has no bearing on the display gamut whatsoever and only involves accurate color encode/decode flow. Whenever a "twist" is described, it most certainly refers to the component video colorspace and not to gamut, as it is describing the location and relationship of the component video cube to the RGB unit cube and its angle.

Are you saying it is impossible for a player to re-map the gamut? Or are you saying that no player that you know of actually does it?

I think it is important to clarify those questions to make sure we aren't talking past each other.

I understand (and I'm pretty sure Joelc does too, but he can speak for himself) that color decoding and primaries are two completely different issues. However, the SMPTE-C gamut lies within the Rec 709 gamut, so it is possible for the player to alter the component (or RGB signals) so that a display with Rec 709 primaries would "preserve rendering intent" as Bear5k puts it.

For instance, suppose an RGB triplet of 235,16,16 is encoded on disc. Sending that triplet to a TV with Rec 709 primaries would produce the wrong "red," if your intent is to view what was originally captured by the camera. In order to see the correct red using Rec 709 primaries, the player could "re-map" the RGB triplet to something <235,>16,>16, which would correspond to SMPTE-C "red" within the Rec 709 gamut.
post #13 of 25
Quote:
Are you saying it is impossible for a player to re-map the gamut? Or are you saying that no player that you know of actually does it?

It's not completely impossible to do it if the gamut is smaller, but obviously you cannot make it larger. However, no player actually does this at all, nor would it make ANY sense at all. It would be a very bad thing to do in the player since it would be a re-map of values in 8-bit when it would be far more desireable to have the display do this past the LUT in far greater bit-depth. So not only do no sources do this, it would be a pretty stupid thing if they did do so. That's not what we are discussing, and it's not what would even be desireable to do.

Quote:
I understand (and I'm pretty sure Joelc does too, but he can speak for himself) that color decoding and primaries are two completely different issues. However, the SMPTE-C gamut lies within the Rec 709 gamut, so it is possible for the player to alter the component (or RGB signals) so that a display with Rec 709 primaries would "preserve rendering intent" as Bear5k puts it.

I suppose it theoretically could be done, but why one would want to do so there is beyond me.

Quote:
In order to see the correct red using Rec 709 primaries, the player could "re-map" the RGB triplet to something <235,>16,>16, which would correspond to SMPTE-C "red" within the Rec 709 gamut.

I suppose so, but that's a completely bizarre thing to do there in the chain. That's not what any player does, nor should it. It would haave to assume that the display was fully accurate to 709, and even still doing it in the player is a decidedly bad place to do it. It would be better to do it at the display, which is what CMS systems in quite a few displays allow.

But again, when you say "twist" that absolutely refers to the component video matrix, and has nothing to do with gamut. That's the question that is FAR more important to deal with, because inaccurate color decoding leads to gross color errors that are very easily visible and dwarf the small mismatch between SMPTE C and 709 which is anyway much smaller than the delta between the displays of most primaries and either SMPTE C or 709 anyway. A matrix twist SHOULD be performed in a device that is upscaling from SD to HD and outputting component video, and often is. Anything with gamut should be done at the display, the source can't realistically do anything about that, nor should it at all attempt to.
post #14 of 25
Chris...

You are correct as, I would suggest, is hwjohn and I but we are perhaps using less precise language...here goes:

1. Colour gamut (i.e. SMPTE-C and REC 709) are different and distincy from colour decoding

2. Colour gamut is the physical gamut of the display and can not -- other than through a CMS -- be changed (i.e. it is waht it is).

3. Colour decoding refers to the encoding of RGB to YCbCr and the decoding of YCbCr to RGB

4. The "twist" that is frequently referred to is the "conversion" of a REC 601 encoded YCbCr signal (note: REC 601 is the "standard" encoding algorithm/matric used for SMPTE-C material) to a REC 709 YCbCr encoded signal. This twist occurs so that a HD display which assumes/expects REC 709 encoded material will properly decode same.

How are we doing so far...and, hoping that we are in agreement...the one point where there is some disagreement amongst Bear5K, hwjohn, me and you is wrt what should happen in the twist...in other words, should the twist preserve the originally encoded RGB triplet (i.e. SMPTE-C red is twisted and decoded to REC 709 red) or preserve the originally encoded rendering intent (i.e. SMPTE-C red is twisted such that when it is decoded using a REC algorithm matrix it is inside the larger REC 709 gamut)...

That said...and hope not to read this again...WE ALL AGREE THAT THE COLOUR GAMUT, COLOUR ENCODING/DECODING AND TWIST ARE DIFFERENT ANIMALS..

Thanks for youe patience and explanations which help all of us better undersatnd things..

PS. hwjohn, in the event that i mispoke you position I apologize and ask you to correct it.

Now
post #15 of 25
Quote:
How are we doing so far...and, hoping that we are in agreement...

Points 1-4 are all correct.

Quote:
what should happen in the twist...in other words, should the twist preserve the originally encoded RGB triplet (i.e. SMPTE-C red is twisted and decoded to REC 709 red) or preserve the originally encoded rendering intent (i.e. SMPTE-C red is twisted such that when it is decoded using a REC algorithm matrix it is inside the larger REC 709 gamut)...

Absolutely the goal is to have the correct RGB triplet. That's the whole point of accurate color decoding, otherwise you have the wrong colors. Dealing with gamut should be done with a fully featured CMS system or something capable of dealing with such processing such as the lumagen, etc. I am not aware of any player out there that at all has this capability, and I would strongly disagree with a fixed gamut compensation that assumes accurate 709. The radiance doesn't, it is a user adjusted to compensate for oversaturated display to achieve the desired gamut.

I absolutely agree that accurate gamut is important, however, it is NOT at all involved in the matrix twist which is a very simple operation and should be performed in a source device if it is crossing the SD/HD threshold and outputting component video. Furthermore, displays should have the ability to manually choose the decode matrix to allow for correct decoding in cases where the source device does not perform a matrix twist.

My major problem is that many people mistakenly think that the source device is performing a twist to compensate for the difference in primary chromaticity between SD and HD. This is absolutely not true, the twist is a compensation for the different component video matrices, and the gamut difference is altogether distinct. Changing the gamut is not a twist at all.
post #16 of 25
Quote:
Originally Posted by ChrisWiggles View Post

Points 1-4 are all correct.



Absolutely the goal is to have the correct RGB triplet. That's the whole point of accurate color decoding, otherwise you have the wrong colors. Dealing with gamut should be done with a fully featured CMS system or something capable of dealing with such processing such as the lumagen, etc. I am not aware of any player out there that at all has this capability, and I would strongly disagree with a fixed gamut compensation that assumes accurate 709. The radiance doesn't, it is a user adjusted to compensate for oversaturated display to achieve the desired gamut.

I absolutely agree that accurate gamut is important, however, it is NOT at all involved in the matrix twist which is a very simple operation and should be performed in a source device if it is crossing the SD/HD threshold and outputting component video. Furthermore, displays should have the ability to manually choose the decode matrix to allow for correct decoding in cases where the source device does not perform a matrix twist.

My major problem is that many people mistakenly think that the source device is performing a twist to compensate for the difference in primary chromaticity between SD and HD. This is absolutely not true, the twist is a compensation for the different component video matrices, and the gamut difference is altogether distinct. Changing the gamut is not a twist at all.


Chris:

We are speaking the same language as we are in complete agreement and, to that end, I am happy that I am not "part" of the major problem alluded above...

Cheers,
post #17 of 25
Quote:
Originally Posted by ChrisWiggles View Post

Points 1-4 are all correct.



Absolutely the goal is to have the correct RGB triplet. That's the whole point of accurate color decoding, otherwise you have the wrong colors. Dealing with gamut should be done with a fully featured CMS system or something capable of dealing with such processing such as the lumagen, etc. I am not aware of any player out there that at all has this capability, and I would strongly disagree with a fixed gamut compensation that assumes accurate 709. The radiance doesn't, it is a user adjusted to compensate for oversaturated display to achieve the desired gamut.

I absolutely agree that accurate gamut is important, however, it is NOT at all involved in the matrix twist which is a very simple operation and should be performed in a source device if it is crossing the SD/HD threshold and outputting component video. Furthermore, displays should have the ability to manually choose the decode matrix to allow for correct decoding in cases where the source device does not perform a matrix twist.

My major problem is that many people mistakenly think that the source device is performing a twist to compensate for the difference in primary chromaticity between SD and HD. This is absolutely not true, the twist is a compensation for the different component video matrices, and the gamut difference is altogether distinct. Changing the gamut is not a twist at all.

Agreed. I haven't thought through it enough to say where a gamut remap should take place, but it is possible. I don't know if there is any equipment out there that currently does such a remap. I just wanted to make the point that it is possible (and desirable) if you can do it properly.

The whole situation would be made easier if all TVs had accurate primaries, which is what enthusiasts should push for from manufacturers. I doubt that the enthusiasts will win, as the general public seems to like oversaturated primaries. If DVD/video processors/etc. knew that every HDTV had accurate primaries, then it would be possible to program in an accurate remap from the factory. Where it should be done is probably another discussion.

This type of thing plagues a lot of areas in audio/video. Everything from MPEG specs to TV primaries are so loosely defined/policed that the end user consequently has to put up with inferior products.

For instance, suppose we have a TV with accurate primaries. There is an optional flag in MPEG2 that allows the player to determine what gamut material was mastered to. There is another flag that allows the player to determine what encoding matrix was used. However, both of these are optional and aren't often set. If they were mandatory and HDTVs all had accurate primaries, then we would be a lot closer to accurate pictures through upscaling.
post #18 of 25
Quote:


I don't know if there is any equipment out there that currently does such a remap.

The lumagen has this capability,but again it is manual for specific gamut errors (oversaturation) on displays, it isn't just an automatic compensation between 709 and SMPTE C which would be of minimal use since there are few or no displays that are really accurate to 709 except with the help of a CMS which is basically the same thing except included in the display.

Quote:


I just wanted to make the point that it is possible (and desirable) if you can do it properly.

I can agree with that, but it is very important to make a crystal clear distinction between this and a color matrix twist between 601 and 709, which absolutely does occur currently in quite a number of sources, and for good reason. It does not have any impact on any gamut issues however, and it is very important to make that clear. It is also, in my opinion, vastly more significant than the gamut differences anyway.

Quote:


The whole situation would be made easier if all TVs had accurate primaries, which is what enthusiasts should push for from manufacturers.

True, but accurate to what? SMPTE C? 709? And given that most HD content is still being mastered on SMPTE C displays anyway the same as SD, it's kind of just a guess anyway as to what it's supposed to be.

On the other hand, the encode difference is very significant, very visible when it's done wrong. It is mathematically unambiguous to get the right returned RGB values.
post #19 of 25
Quote:
Originally Posted by ChrisWiggles View Post


True, but accurate to what? SMPTE C? 709? And given that most HD content is still being mastered on SMPTE C displays anyway the same as SD, it's kind of just a guess anyway as to what it's supposed to be.


Chris:

Based on your above copmments that ....most HD content is still being mastered on SMPTE C display anyway... is it not the case that I should therefore use my Lumagen Radiance XD to calibrate the primaries and secondaries to match the SMPTE-C colour gamut?

If yes then great and no additional explanation is needed...if not then please explain why not.

TIA.
post #20 of 25
Joel:

Let me jump in here. I have recently started calibrating my display to both SMPTE-C and Rec. 709. I found that some HD material looks better with the display calibrated to SMPTE-C primaries (primarily broadcast cable) and other material looks better calibrated to Rec. 709 primaries (primarily Blu-ray/HD DVD content), although there are exceptions to each.

In your particular case, your display's native gamut seems to be SMPTE-C in any case, so I would just calibrate to that and call it a day. If at some point in the future you get a display with a larger gamut, you can calibrate to both and use whichever one suits for given content.

Quote:
Originally Posted by Joelc View Post

Based on your above copmments that ....most HD content is still being mastered on SMPTE C display anyway... is it not the case that I should therefore use my Lumagen Radiance XD to calibrate the primaries and secondaries to match the SMPTE-C colour gamut?

If yes then great and no additional explanation is needed...if not then please explain why not.
post #21 of 25
Quote:
Originally Posted by TomHuffman View Post

Joel:

Let me jump in here. I have recently started calibrating my display to both SMPTE-C and Rec. 709. I found that some HD material looks better with the display calibrated to SMPTE-C primaries (primarily broadcast cable) and other material looks better calibrated to Rec. 709 primaries (primarily Blu-ray/HD DVD content), although there are exceptions to each.

In your particular case, your display's native gamut seems to be SMPTE-C in any case, so I would just calibrate to that and call it a day. If at some point in the future you get a display with a larger gamut, you can calibrate to both and use whichever one suits for given content.


Tom:

Understood...I am/was curious as to whether one would consistently be better than the other as:

1. It is somewhat of a PITA to calibrate a projector to both colour gamuts even using a Lumagen RadianceXD; and

2. It requires great care becuase -- and I stand to be corrected -- one would need to play with the YCbCr decode matrix to see whether REC 601 or REC 709 decoding is better.

As always, thanks.
post #22 of 25
Quote:
Originally Posted by ChrisWiggles View Post

True, but accurate to what? SMPTE C? 709? And given that most HD content is still being mastered on SMPTE C displays anyway the same as SD, it's kind of just a guess anyway as to what it's supposed to be.

This is why I mentioned MPEG2 specs... most (if not all) compression schemes used for broadcast/BD/HD DVD have optional flags to set the original gamut and color decoding matrix. If it was mandatory to set those flags in the bitstream (and set them correctly), then we would have reliable information in the stream as to gamut and decoding matrix. We could then at least have a chance to get all the corrections/adjustments right either in the display itself or an external processor.

I really don't understand why these types of flags are optional in the specs, but they are.

EDIT: I think all HDTVs should have accurate Rec. 709 primaries, but with a way to correct (re-map) for SMPTE-C or smaller gamuts.
post #23 of 25
Quote:
Originally Posted by ChrisWiggles View Post

True, but accurate to what? SMPTE C? 709? And given that most HD content is still being mastered on SMPTE C displays anyway the same as SD, it's kind of just a guess anyway as to what it's supposed to be.

What? So don't even try? Sorry, but I want a function that correctly re-casts the SMPTE-C primaries into the 709 space. The fact that the primaries in the display are inaccurate is not a good excuse for NOT doing this since there is too much of an opportunity for mutual finger pointing. There is NO xvColor content that is commercially available, and yet this feature is hitting the market in a big way. I know that the CRT market is, um, static, but the digital world is moving right along.

Quote:


On the other hand, the encode difference is very significant, very visible when it's done wrong. It is mathematically unambiguous to get the right returned RGB values.

It is also mathematically unambiguous to re-cast SMPTE-C inside 709. There is not a difficulty issue on this for video engineers; it is an issue of knowing that people care. A defeatable switch, much like many other processing functions, in a few high-end players would go a long way for me.

Bill
post #24 of 25
Quote:
Originally Posted by Joelc View Post

Understood...I am/was curious as to whether one would consistently be better than the other as:

1. It is somewhat of a PITA to calibrate a projector to both colour gamuts even using a Lumagen RadianceXD; and

2. It requires great care becuase -- and I stand to be corrected -- one would need to play with the YCbCr decode matrix to see whether REC 601 or REC 709 decoding is better.

From my experience, as I said SMPTE-C looks consistently better to my eyes on broadcast, though there are some shows that look better in Rec. 709. We are not talking a night-and-day difference, but it is visible.

Can't you calibrate two entirely separate profiles on the Lumagen and then just switch between them when you like? Yes, you have to take care to do the 2 calibrations correctly, but that was always the case. If you just calibrate to the proper respective xyY values for each color space using the Accupel or DVD reference, you'll be fine.
post #25 of 25
Quote:
Originally Posted by TomHuffman View Post

From my experience, as I said SMPTE-C looks consistently better to my eyes on broadcast, though there are some shows that look better in Rec. 709. We are not talking a night-and-day difference, but it is visible.

Understood...



Quote:
Originally Posted by TomHuffman View Post

Can't you calibrate two entirely separate profiles on the Lumagen and then just switch between them when you like? Yes, you have to take care to do the 2 calibrations correctly, but that was always the case. If you just calibrate to the proper respective xyY values for each color space using the Accupel or DVD reference, you'll be fine.

Yes you can do as you suggest...for example, INPUT 1A can be SMPTE-C and INPUT 1B can be REC 709...the issues are as follows:

1. You would have to calibrate the primaries and secondaries twice -- once for SMPTE-C nd once for REC 709 which is very time consuming given the number of software releases...that said, I will probably do this once the gamut functionality settles down.

[NOTE: -- the grayscale and gamma should NOT have to be done twice because both gamuts have a commong white reference point and the grayscale / gamma calibrations are not impacted by the gamut calibration]

2. There is a little more to calibrating the two gamuts...presumably for SMPTE-C one would tell it to use a REC 601 decode matrix whereas for REC709 one would tell it to use a REC 709 decode matrix...here is an interesting question...do you think that the Radiance would do a reverse twist when a REC 709 encoded YCbCr INPUT signal is "forced" to be OUTPUT as a REC 601 encoded signal because it would be important to get this "reverse twist" right as well...

Over to you...
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › Calibration disc for SD?