4. And now for the big the closing the matrices are a result of the differences in the color gamut because, for example, (235,16,16) must be encoded to the different red point...
Do I have the above correct and, if not, then where is the flaw in my thinking between the realtionship between the color gamuts and the decode/encode matrices?
This isn't correct. You are getting gamut/encoding confused again. Encoding to YPbPr doesn't have anything to do with the gamut, except that each recommendation has an associated gamut that goes with it. You can encode something with SMPTE-C assumed primaries using the 709 matrix, and vice versa, with no ill effects as long as the same matrix is used to decode.
Let's take an example. Suppose we want to encode the RGB triplet (235,16,16). Notice that there is no information regarding gamut. That triplet simply tells the display device to turn on the "Red" fully. RGB contains no information as to whether or not that "Red" is a 709 primary or SMPTE-C primary.
These are arbitrary numbers and aren't correct, used just for explanation:
Encode (235,16,16) with Rec. 709 Matrix, we get (10,15,20) in YPbPr.
Encode (235,16,16) with Rec. 601 Matrix, we get (30,45,60) in YPbPr.
Now lets decode:
Decode (10,15,20) in YPbPr using Rec. 709 Matrix, we get (235,16,16) in RGB.
Decode (10,15,20) in YPbPr using Rec. 601 Matrix (incorrect matrix), we get (220, 30,30) in RGB (Wrong color!)
Decode (30,45,60) in YPbPr using Rec. 709 Matrix (incorrect matrix), we get (215, 45,45) in RGB (again wrong color!)
Decode (30,45,60) in YPbPr using Rec. 601 Matrix, we get (235,16,16) in RGB.
Now, in all that we didn't need or provide any information concerning the gamut. This is because RGB is independent of the gamut. Again, (235,16,16) just tells the display device to turn on full "Red," it doesn't tell it any information about what color "Red" should be. Your primaries determine that.
Now lets take an upscaling DVD player with the same example as above. The upscaler knows that the TV will use Rec. 709 to decode an HD signal (the TV is dumb in the sense that it does not know anything about the original material or how it was encoded). The upscaler also knows that the original disc was encoded using a Rec. 601 matrix. It must "translate" from 601 to 709 so that when the TV decodes using 709, it gets the right RGB triplet. Here we go again, using phony numbers (this isn't what happens, but explains the point):
1) RGB (235,16,16) gets encoded using Rec. 601 matrix and is stored on disc as (10,15,20) in YPbPr.
2) Upscaler decodes (10,15,20) using Rec. 601 matrix to get RGB (235,16,16).
3) Upscaler encodes the decoded RGB of (235,16,16) using Rec. 709 matrix to get (30,45,60) in YPbPr, and passes that YPbPr signal to TV.
4) TV decodes incoming YPbPr (30,45,60) with Rec. 709 matrix as the incoming signal is HD, we get RGB (235,16,16), which is the original RGB triplet we encoded in the beginning. The TV turns on full "Red," as was intended on disc.
Notice again, no information regarding gamut. If the original disc was mastered assuming SMPTE-C primaries, then the disc really wanted the TV to turn on full SMPTE-C defined "Red", but our HDTV could have been using a Rec. 709 Red. So, we get full "Red", but it is the wrong "Red." Fortunately the difference between the two isn't much, as ChrisWiggles pointed out. If you really wanted to get it right, you can also transform between the two gamuts, but that is another post.
-- How are greater/more bit depth created.
-- What exactly is banding?
-- Why does it reduce banding?
Once again, thanks for sharing your knowledge, it is much appreciated.
I'll attempt to answer these, although ChrisWiggles can probably do a much better job.
Greater bit depth isnt really created. You simply perform the calculations using "more bits" to avoid error. For instance, with 8 bits you can represent the numbers 0-255 in integers only. Lets say we need an operation that divides 255 by 30. If you divide those numbers, you get 8.5, but we can't represent 8.5 with 8 bits, we can only represent 8 or 9. So we round up to 9.
Now imagine you do hundreds of operations, with each one having to be rounded because you are using 8 bit. The end result will have some error because you had to round off at every step.
Now say we use 12 bits, but we assign those last 4 bits to represent digits beyond the decimal point. Now we can easily represent 8.5, or 8.455 for that matter. We do all of our calculations in 12 bit space so that rounding error is minimized. The end result is much more accurate because we didn't round at each step. We don't round until we get to the final answer.
The next two questions Chris would be better at answering. Banding is when you have a subtle gradient, say a transition from RGB(17,17,17) to RGB(18,18,18), and as a result of some processing, that transition gets lost and everything becomes either 17 or 18. This can happen because of the round off problems discussed above. Using "more bits" in your calculations can help you preserve those subtle gradients, thereby avoiding banding.
Well, that was long. I hope ChrisWiggles doesn't find that all of it is wrong and I just wasted a lot of time