The big picture (Colorspaces VIII)

A few posts ago, I said that while the colorspaces looked random, they really weren’t, and that there was underlying order. The structure cannot be easily seen just by looking at the numbers themselves, but at how the numbers are obtained.

The story begins sometimes in the 1950s, were transmitting color TV images started to be the next logical step. Someone (not sure who was first, but it may have been Valensi, in the 1930s) proposed that TV color should be encoded in a perceptually friendly way [1]. It was known for a while that the retina had four types of sensors, rods for brightness with no color information, and three other types corresponding to red, green, and blue, but also that in, and beyond the retina, information travels as brightness, yellow-blue and red-green differences [2,3].

YCrCb and friends (Colorspaces VII)

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.

YDbDr (Colorspaces VI)

Also an analog colorspace, YDbDr was used in SÉCAM (Sé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).

YUV and YIQ (Colorspaces V)

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.

Xerox YES (Colorspaces IV)

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:

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?

Ohta (Colorspaces III)

Let’s continue with lesser known color spaces. In 1980, Yu-Ichi Ohta [1] to segment images based on colors, and to do this, introduced a new colorspace—or more precisely, two variants of the same color space.

Ohta’s concern wasn’t image coding but region separation. He supposed (without much evidence) that a color space with a basis close to the principal components of the colors in the image should be maximally discriminant. He then proposed that the colorspace

Kodak YCC (Colorspaces II)

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?

Kodak 1 (Colorspaces I)

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.

swappity::swap

constexpr is one of C++11’s features I’m starting to like very much. constexpr is a bit finicky, but it allows you to evaluate functions—including ctors—at compile time. This of course, allows computations to be replaced directly by results.

So in the best of cases, you could end-up with less code, or better yet, no code at all!

Yes? No? Maybe? (Part II)

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.