| |||||||||||||
YUV and YCbCr irrelevantYUV and YCbCr irrelevantPosted Mar 4, 2010 23:07 UTC (Thu) by spitzak (guest, #4593)In reply to: SCALE 8x: Color management for everyone by farnz Parent article: SCALE 8x: Color management for everyone
Spaces such as YUV and YCbCr are not "color spaces" really. They are simply an encoding of an RGB space, and any definition of them will include the values of the R, G, and B primaries and the fact that they are YUV or YCbCr encoded. There is no such thing as a "Y primary" and certainly no such thing as a "Cb" primary (since there .5 is black!).
Claiming these are color spaces is equivalent to claiming that jpeg is a color space, rather than a compression algorithm.
(Log in to post comments)
YUV and YCbCr irrelevant Posted Mar 5, 2010 10:02 UTC (Fri) by farnz (guest, #17727) [Link] Depends on how you define a colour space; on the one hand, they are just a reversible transform from a known RGB colour space. On the other hand, practical YUV colour spaces, while sharing primaries with practical RGB colour spaces, tend to have different gamuts. Additionally, they only correspond perfectly under the assumption of infinite precision; in colour management situations, it's of interest to the output driver to know that when I ask for 8-bit BT601 RGB (236, 250, 255), it actually came from YUV (230, 140, 120), and thus if display RGB (237, 251, 255) corresponds to BT601 RGB (237, 251, 255) while display RGB (236, 250, 255) corresponds to BT601 RGB (235, 249, 255), the former is a closer approximation to the desired colour than the latter. YUV colour spaces differ from JPEG in a very important manner; JPEG is lossy by design, whereas YUV isn't lossy until you subsample. Any loss between an RGB and YUV colour space occurs due to loss of precision
|
|||||||||||||