Quote:
Originally Posted by feisty2
oh, and btw, just say if 127.5 is exactly how standards defined it
|
The only standard I know of defining what to do with full-range YCbCr is JFIF, and it has a nominal luma range of 0 to 255 and a nominal chroma range of 0.5 to 255.5. (
libjpeg-turbo implements this. Z also assumes this convention, as does Dither_convert_rgb_to_yuv/yuv_to_rgb. I
think swscale also does this, but the source code is a nightmare to read so I'm not 100% sure.)
AVS (and by extension, AVS+)
uses a different convention for the Convert* filters, where the nominal luma range is 0 to 255 and the nominal chroma range is 1 to 255.
The "correct" convention is obviously 0 to 255 for both luma and chroma, but for whatever reason that's not what we ended up with. Apart from JFIF (which, you know, defines only what to do for JFIF files), no standard in common use defines what the nominal levels for full-range YCbCr should be; BT.601, BT.709, etc. only define the nominal levels for TV-range YCbCr.
Edit: Since vivan mentioned H.264, I went and checked that, and it defines a nominal chroma range of 0.5 to 2^n−0.5 in Annex E. (I assume HEVC says the same thing.) But really, my original point was that these all map RGB values to YCbCr values linearly; the exact endpoints to use for the range is something we can decide after we get rid of the strange idea of mapping 0 to 0, 128 to 32768, and 255 to 65535.
Quote:
pure black will be rounded to its closest color [0, 128, 128] at uint8_t
|
In case you're bad at arithmetic, 127.5 is equally close to both 127 and 128.
Quote:
and obviously the error between 32768 and 32767.5 << the error between 32896 and 32767.5
|
Also, dithering exists and anyone who cares about colour accuracy is already using it when converting between colourspaces with limited precision.