YCrCb and friends (Colorspaces VII)

May 22, 2018

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.

Read the rest of this entry »


YDbDr (Colorspaces VI)

May 15, 2018

Also an analog colorspace, YDbDr was used in SÉCAM (quentielle ccouleur à mémoire), the French analog TV standard that was also used in Germany, Greece and the Middle east, among others. YDbDr, like the others, use the luminance, Y, and two chrominance components: Db, Dr (for différence bleue and différence rouge).

Read the rest of this entry »


YUV and YIQ (Colorspaces V)

May 8, 2018

Not all colorspaces are inherently digital, and in fact, most were first conceived as, and for, analog means. Let’s have a look at two of those colorspaces, YUV and YIQ. The YUV colorspace was used for the European analog TV standard, PAL, while YIQ was used for the North American and Japanese standard, NTSC.

Read the rest of this entry »


Xerox YES (Colorspaces IV)

May 1, 2018

It seems pretty much everyone tried their hands at designing a colorspace. One such example—essentially forgotten today—is Xerox’s YES colorspace. I am not sure what problem this colorspace tries to solve:

\begin{bmatrix}  0.253 & 0.684 & 0.063\\  \frac{1}{2} & -\frac{1}{2} & 0\\  \frac{1}{4} & \frac{1}{4} & -\frac{1}{2}\\  \end{bmatrix}  \begin{bmatrix}  r\\  g\\  b\\  \end{bmatrix}  =  \begin{bmatrix}  Y\\  E\\  S\\  \end{bmatrix}

The first line, yielding Y, gives something close to the brightness, but it differs from most other colorspaces that will use 0.299, 0.587, and 0.114 to compute brightness. Are Xerox YES’ values gamma corrected? Or relative to some other space than RGB?

Read the rest of this entry »


Kodak YCC (Colorspaces II)

April 17, 2018

The Kodak 1 colorspace we saw last week doesn’t really capture the perceptual response to colors; the brightness is merely a mix of the RGB components, and the two other components are unbalanced “yellow vs blue” and “red vs cyan” channels. On the plus side, Kodak 1 can be computed in integers only, and perfectly reversibly. But what if we wanted a colorspace that is closer to our perception of colors?

Read the rest of this entry »


Kodak 1 (Colorspaces I)

April 10, 2018

Images (and, by extension, video) compression depends strongly on the color space used. A color space is a (hopefully convenient) representation of colors. We’re all familiar with the RGB color space used by video hardware. The RGB color space is based on three standard primary colors: red, green, and blue. Combining these three colors, each with varying intensity, yields a wide gamut of perceived colors.

However, if RGB is intuitive, it is not a very good color space for compression because it doesn’t exploit any of our perceptual quirks. We’re very good at distinguishing small variation in brightness, but not so much in tint or saturation. Compression schemes need to exploit this in order to destroy information (and obtaining better compression). This is why almost all image and video compression algorithm out there use a different color space, one that represents color as brightness, and two (or more!) components that are more or less related to tint and saturation—or some other measure of difference of color.

Read the rest of this entry »


Yes? No? Maybe? (Part II)

March 27, 2018

Last week, we had a look at how to implement a trool, or a tri-valued boolean what accepts true, false, and undefined. We remarked that the storage of an enum likely defaults to int, and that my poc wouldn’t play well with std::vector as that container has no specialization to deal with this new type.

A specialization would be interesting because we can do much better than using an integer to store three different values. We can do much, much better.

Read the rest of this entry »