JPEG, MPEG, and other compression algorithms all use a colorspace other than RGB. The colorspaces they use are such that most of the perceptually useful information is concentrated into one component, essentially brightness, and the color information diffused into the remaining components. Furthermore, we hope that we can heavily quantize the color information. JPEG separates the image into brightness and two other components: brightness is coded full resolution, but the two other components are downsampled 4:1. Yet, it’s not visible in the reconstructed image, because our eyes are good at brightness, but not at chrominance.
But that’s not a surprise. All the colorspaces we’ve seen so far do this, and (are believed to) have the same properties, grosso modo.
JPEG uses the YCbCr colorspace:
I proposed a variant of this colorspace for DjVu for fast decoding. Instead of starting from the “forward” transform, I started from the inverse:
The rationale is that multiplications using numbers such as are easily re-rewritten as additions and shifts. can be rewritten as as well as , and so can be computed as x-(x>>2). The inverse can be computed all in integers. The forward transform is given by the inverse’s inverse:
The values in the brightness line, 0.299, 0.587, and 0.114, were chosen a longtime ago for various reasons: the standard response of displays—then phosphorus-based—and industry-imposed corrections at capture-time—the standard gamma corrections. Overtime TV went from analog to digital and so the whole process changed. CRT were replaced by flat screens that used completely different technologies with different colors. To address these changes, new colorspaces where introduced: