VideoHelp Forum
+ Reply to Thread
Results 1 to 4 of 4
Thread
  1. I know that in YUV (aka YCbCr) encoding, the luma (Y component) range is 16 to 235. I originally assumed this was to allow for all possible values from a composite video signal to be stored in a video file, from blanking IRE=-40 up to the maximum excursion of the chroma signal IRE=131, while normal composite video image luma (not the same as YUV luma) range for NTSC is from IRE=7.5 to IRE=100.

    However when I scaled Y-component values from 16 to 235 into the 7.5 to 100 range for image IRE, I found that with a Y value of 0 does NOT convert to an IRE of -40 (sync level) or even an IRE of 0 (blanking level). Instead it converts to an IRE of 0.74. This value holds no special significance in the official IRE levels in the NTSC specification. And when I set the Y value to 255, I find the IRE is 108.45, which again holds no significance in the NTSC specification. Even when I scale the Y values into an IRE range of 0 to 100 (IRE=0 is black in Japanese NTSC, as well as in the PAL video standard), I find that Y=0 converts to IRE=-7.31 and Y=255 converts to 109.13. Neither -7.31 nor 109.13 are special values at all for composite video signals.

    The only special IRE values outside the normal image range are -40 for sync, -23 for minimum possible chroma excursion (in American NTSC), 0 for blanking (in American NTSC), -20 for minimum color burst excursion, and 131 for maximum possible chroma excursion (in any NTSC, but not sure about in PAL). So this begs the question, why are the levels 16 to 235 used for the Y component of YUV encoding? And what significance are the 0 and 255 Y levels, when displaying a YUV encoded image or video?


    I notice a similar situation with the U and V (chroma) components in YUV encoding. They use a 16 to 240 range. Why is that? And if they need to be limited range, why not have the U and V components also use the 16 to 235 range of the Y component (or alternatively have the Y component use the 16 to 240 range of the U and V components). Also for the 16 to 240 range of the U and V components, why not use 15 to 240 instead? In that case, 15 is 15 away from 0, and 240 is also 15 away from 255, so the range would at least make sense. 16 is 16 away from 0, but is only 15 away from 255, so it's not balanced.

    Anybody know why those ranges were chosen for YUV encoding?
    Quote Quote  
  2. Formerly 'vaporeon800' Brad's Avatar
    Join Date
    Apr 2001
    Location
    Vancouver, Canada
    Search PM
    I recommend picking up a used copy of the first edition of Digital Video and HD: Algorithms and Interfaces by Charles Poynton. (The second edition removes a lot of info on analog video.)

    The reason is "footroom and headroom". Not sure if the link will work, but you can look at some pages on Google Books.

    The logic behind the chroma values is that they're centred at 128 with excursions of +/-112.
    My YouTube channel with little clips: vhs-decode, comparing TBC, etc.
    Quote Quote  
  3. Originally Posted by Brad View Post
    I recommend picking up a used copy of the first edition of Digital Video and HD: Algorithms and Interfaces by Charles Poynton. (The second edition removes a lot of info on analog video.)

    The reason is "footroom and headroom". Not sure if the link will work, but you can look at some pages on Google Books.

    The logic behind the chroma values is that they're centred at 128 with excursions of +/-112.
    So basically for ringing or incorrectly adjusted equipment it says. My question then would be, then why not just clip the out-of-range values, and keep the correct values in the range of 0 to 255 for all YCbCr channels? And that way the chroma channels will be centered on 127.5. While that number is not an integer, there will be tiny amounts of noise, on even the best quality analog signals, so the chroma voltages will never be at exactly 0.0000... volts. Anything that's slightly below 0 volts will be rounded down to 127 by the analog to digital converter, and anything that's even slightly above 0 volts will be rounded up to 128. Because noise tends to be completely random in nature, half of the noise-impacted 0v values will be below 0v, and half will be above 0v. Therfore, half of the 0v chroma values will be digitized randomly to 127, and the other half to 128, so that on average the digitized level for 0v chroma signals will be 127.5.

    I really don't like systems that don't make full use of the available values. I think that YCbCr certainly should use all values from 0 to 255 on all of its channels.

    This is particularly true with YCbCr to RGB conversion. While every RGB color maps to a valid color in YCbCr color space (colors who's Y values are in the 16 to 235 range and chroma values in the 16 to 240 range), not every RGB value maps to a unique YCbCr value. Some YCbCr values can be made from 2 different RGB pixel values. The reverse conversion though has more issues. Not every valid color in the YCbCr color space can be mapped to a unique RGB color, and some would even be out-of-gamut in RGB color space. Conversion both from RGB to YCbCr and also the reverse are lossy, but this is made even worse by the limited range of valid YCbCr values.
    Last edited by Videogamer555; 21st Oct 2021 at 15:56.
    Quote Quote  
  4. Originally Posted by Videogamer555 View Post
    that way the chroma channels will be centered on 127.5.
    Then nothing could ever be perfectly black, white, or any shade of grey.

    Originally Posted by Videogamer555 View Post
    not every RGB value maps to a unique YCbCr value. Some YCbCr values can be made from 2 different RGB pixel values.
    It's far worse than that. On average about 6 RGB values (8-bit, full range) map to the same YCbCr (8-bit, limited range) value .

    Originally Posted by Videogamer555 View Post
    Not every valid color in the YCbCr color space can be mapped to a unique RGB color, and some would even be out-of-gamut in RGB color space.
    Look at the RGB cube inside the YCbCr cube:



    (from https://www.intel.com/content/www/us/en/develop/documentation/ipp-dev-reference/top/vo...en?language=en )

    Enlarging the RGB cube to full range still leaves most of the YUV cube out of gamut; because of the way the RGB cube is rotated.

    Originally Posted by Videogamer555 View Post
    why not just clip the out-of-range values
    Clipping produces sharp corners. That results in lots of high frequency ringing artifacts in analog systems.

    Originally Posted by Videogamer555 View Post
    I really don't like systems that don't make full use of the available values. I think that YCbCr certainly should use all values from 0 to 255 on all of its channels.
    Nobody cares what you like/dislike. These are international agreed upon standards. Used by DVD, BD, streaming video sites, broadcast TV, etc.
    Last edited by jagabo; 21st Oct 2021 at 19:45.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!