question about 709 colour space calibrating material - Page 5

To answer your question strictly: Yes. As a matter of fact, I have thought about it.

To be a little less cavalier: You lose dynamic range when going from YCbCr to RGB no matter what you do. Quite simply: the color space for YCbCr is a form of lossless compression, so you already face this issue. It gets worse, in fact, once you start implementing the xvYCC (xvColor). Since xvColor uses even more of the existing 8-bit YCbCr data containers, you face an even bigger problem than this little exercise.

To your specific point about clipping: this is why you do not clip at 16 and 235. As I said before, there is a reason for the head and toe room, and this is one of those uses.

Bill

Although it means nothing I am with you on this one...




I will take your word on this and opt not to push for an explanation...

This is what I've been trying to carve out some time to explain on the CalMAN support forum, but time (and family commitments) have conspired against me. (Yep, I'm too lazy to gut it out...)

Bill, I think that I can say that I know you well enough to say that (i) you are not lazy and (ii) you will explain this in the CalMAN support forum...that said, I do look forward to reading your answer in the weekd to come...




Bill, the above seems to have slipped through the cracks...ca you take a crack at it since I am calibrating my system (i) using an upconverted disk (ii) assuming that the RadianceXD maintains the RGB values (at least for now) and (iii) CalMAN measured dE* based on the defined secondaries...TIA


Happy New Year to Bill, Chris, Derek, hwjohn and everybody else participating in this thread...

I would just use the Radiance's internal patterns. For your other displays, go ahead and assume that they maintain the RGB values, and see what happens. You are better off using a filter method, more than likely, to try to set your decoder at that point, as well.



Happy new year, as well!

Not that I am looking to spend more of my hard earned money but it is looking more and more like an AccuPel is in my future as it appears to be the best and only way to get 100% reliable test patterns for all displays -- RadianceXD connected or otherwise -- for those of us who do not want to use an HTPC (i.e. I recognize that CalMAN;s pattern generator would be an option for those that do!).

Thanks for responding.

If you have an HD DVD or Blu-ray player, then you should be able to get accurate patterns using AVS HD. There is a lot less to go wrong (no conversions necessary) if you are using HD test discs. Of course, pattern generators can work with all types of equipment instead of just HD players.

Fully agree with what you are saying...for better or worse (and probably worse) I am very loyal to the manufacturers/products that I own which means that on the DVD side I am waiting, and waiting, and still waiting for Meridian to announce their plans...that said, should they make no announcement at CES then I will probably buy a LG/Samsung combi player until Meridian gets their act togather...

In any event the problem -- as you note -- is that I have neither a HD DVD or Blu-ray player at present...thinking pattern generator as the BEST OF THE BEST solutions...

I think you meant lossy not lossless? You lose color when going from RGB to component, in fact the majority of addressable RGB colors. This is separate from any chroma subsampling which will be done which is also a lossy 'compression.'
[/quote]

Chris:

So then why not BOTH improve and simplify things by leaving them in the RGB domain...is there a reason other than space/system requirements?

TIA.

YCbCr is considered lossless. Using real numbers, you can send an RGB triplet into the conversion and get the same RGB out. The same is not true for LPCM audio going into an MP3 encoder.

This only holds for 4:4:4, though. Somewhat embarrassingly, I have had a few professional video folks tell me, in all seriousness, that they were using "lossless" 4:2:2 which is incorrect.

I think what ChrisWiggles was saying is that most consumer formats are subsampled to 4:2:0 or 4:2:2, which is lossy.

EDIT: Re-read ChrisWiggles post, and evidently he wasn't saying that. I apologize. I'll let you two hash it out

As far as I know, component is used purely because it saves "space." RGB inherently contains redundant information. Component does away with that redundancy and, on top of that, is typically subsampled so that you throw away some of the chroma resolution.

There is also history at work here, which is a pretty powerful force. Component video's precursor (YIQ) was developed to help the transition from black-and-white to color TV, and there has never really been a major event that required shifting over to a pure RGB format. Realistically, component video is not the chief bugbear in this nightmare. Sub-sampling down to 4:2:0 is a bigger issue in my book, followed closely by sticking with 8-bit video. I would have loved to see 10-bit 4:2:2 (aka D-5, part 2) be the dominant format for HD optical media, but we did not get it. That being said, the 8-bit 4:2:0 we did get is still pretty nice looking on a good display.

And to bring this back to the topic: Blu Ray and HD-DVD do not require conversion between 601 and 709 colorspaces!!

Bill

Is Bill letting in on his age?


Which is exactly why we created AVS HD. We got tired of guessing if the SD conversion was done correctly, and I'm too broke to afford an Accupel...

I hear your pain and feel your pain....

March isn't for a couple of months, so it's probably a little early to start a pool...

Ideally staying in RGB is the best way to do it. Component video has no merit except that it allows subsampling, which allows you to save data space and bandwidth with very little perceptual loss.

Moving to component is not lossless. Codeword utilization is much much worse than RGB because you have exactly the same number of component legal codewords, however the vast majority of those triplets are not legal in RGB and are completely outside the RGB unit cube. Many RGB codewords will map to the same component triplet as a result. You get less than 3 million addressable colors when you move to component video, out of the 16.7mil of the original RGB, and that loss is permanent. And then you spatially subsample the chroma on top of that.

It is correct that both component video and chroma subsampling are not semantically considered "compression", subsampling is in essence a form of lossy compression. However, that is why a lot of pros will call subsampled component "uncompressed" because it hasn't been MPEG compressed etc. But you're right, it is basically just a form of lossy compression.

From what I've been told by some video engineers I respect, there are things that are less computationally intensive (i.e., easier, less hardware required) that are often done in component space (e.g., gamma modulation, saturation modulation). However, this is not a battle I care to join.

As I said, inside the industry, component video is considered lossless. I happen to buy the arguments as to why, but I'm not a torchbearer for component video. I offered the PCM->MP3 example (aka Sirloin into Hamburger) to show what a REAL lossy compression scheme looks like. The gray area for 4:4:4 is that it includes code words on both sides that are either illegal or indistinct on the other.

In ordinary 8-bit RGB video, there are approximately 10.5 million colors within the reference space (16.7 is if you count the full 0 - 255, which is not legal). Inside the normal (not xvYCC) colorspace for component video, there are just south of 11 million codewords, though as you mention, many of these do not map back into the RGB gamut. From my perspective, I consider the implementation of component video to be a lossy compression scheme, but the theory/academic model behind it is not. Personally, I'm looking forward to xvYCC and then 10-bit video after that (eventually, once there is a media source that uses it), but until then, we have what we have.

Bill

Certainly, I don't mean to insinuate that component video is bad. It is very much advantageous to use because it allows such data savings with subsampling for very little perceptual loss. But technically speaking, you are only getting like 1/4 of the RGB colors with component video. Many of those are perceptually unimportant, but it certainly isn't lossless at all. I don't know who would consider that move lossless, you lose like 3/4ths of your colors and those are gone forever. It is considered 'uncompressed', sure, but it's not the same as the original RGB. Sure isn't lossless at all when you're throwing out the majority of addressable RGB colors.

The volume ratios (YCbCr/RGB) are 20.4% for YIQ, 23% for YUV, and 25% theoretical maximum.

For instance, Y=16 Cb=136 Cr=110 would be a perfectly legal and valid 8-bit component triad. Redundant or nonsensical however as it would define a color with zero intensity. Ditto the many valid yet wildly out-of-gamut triad permutations.

Dave

To an extent, this is where xvColor comes into play. However, this example also illustrates the question that any lossy compression scheme would ask, which is whether the incremental code values are perceptible or not. If you only have 3 million perceptible colors in the defined gamut using RGB, and YCbCr handles 95% of those, then by one measure of efficiency, you are doing well. By a different measure, though, you are still doing poorly if you can only use 1/4 of the allowable/actual code words in your lossy compression scheme. Ideally, you would use closer to 100% of the allowed code values to represent an equally high percentage of the perceptible code values in the uncompressed state.

Bill

It seems to me that if you only have ~3 million uniquely addressable, valid, in-gamut codewords in your 8-bit RGB, it's only because it was once exposed to being defined in terms of 8-bit YCbCr. If it could've stayed in the RGB domain then

Dave

Gauntlet thrown. Gauntlet accepted.

Editing the image in any way is cheating, by the way.

 

color_test.zip 2.73828125k . file

Ahh the old “can you perceive a single 8-bit step” test? This time with 234 on a 235 background. I’ve posted several of these test images in the past too. FWIW- No, I can’t perceive this single bit step and agree that for the most part, a single 8-bit step is below the HVS detection threshold. Good thing too or 8-bit video would be a banded mess. The fact that it largely isn’t is a testament that single 8-bit steps are below the discrimination threshold. Also FWIW, you may have slightly different results if you choose different levels. Try a low gray like 30,30,30 on a 31,31,31 background in a dark room on a display with a 2.22 degamma…

Anywho, if your point is that the HVS is incapable of differentiating the 10.7 million valid in-gamut codewords available to StudioRGB then I’d probably agree. Again, good thing too. Can we perceive more than the ~2.7 million valid in-gamut codewords available to 4:2:2 YCbCr? I can’t count that high and that a lot of test cases. I’ll note that when I posted similar images in the past, cases could be made either way. I posted test cases where none reported being able to perceive the single step. I also posted test cases where some reported that they could resolve and perceive the single 8-bit step. Depended on where the step was and on what the capabilities of the display and environment were.

http://www.avsforum.com/avs-vb/showt...7#post10944917

If each 8-bit staircase is to span the same distance, (gamut) which staircase would have the smallest step size and have the most likelihood of not having perceptible steps? sRGB with 16.7 million steps, StudioRGB with 10.6 million steps, or 4:2:2 YCbCr with 2.7 million steps?


Dave

Exactly..this is why Poynton makes use of the adjective:

"To shade smoothly over this range, so as to produce no perceptible steps"


I would also like to comment on this question, while the answer is obvious; one detail that escapes most AVS subscribers (not you Dave) is the non-linear nature of video. This non linearity does not correlate to the “spacing of adjacent digital steps" but in reality only exist in the analog voltage domain. Gamma correction is usually implemented in the analog domain and is propagated through the digital payload as a gray scale pre-emphasis. The non-linear ingredient is a result of a given LUT weighting. The digital steps are perceptually linear and their spacing are separated by equal size and do NOT vary.