The Hacker Factor Blog

Recently I've been playing with a bunch of color conversion functions. For example, converting from RGB to YUV or from HSV to CMYK. I've also been graphing the values. As it turns out, many programs compute the conversions differently. Part of the difference is due to differing algorithms. But I was surprised to find that many of the algorithms are backwards!

One thing I implemented was a color histogram system similar to the one generated by VirtualDub's ColorTools plugin. This computes a histogram of the color intensities per column (or per row). In this case, the horizontal axis is the image column and the vertical axis is the color intensity index. (The index ranges from 0 at the bottom to 255 at the top. The color channel's key is on the right.)


Original image

Intensity (grayscale) per column

Red

Green

Blue

Even though each color channel is different, they all have the same basic shape. While this isn't always the case (especially if the colors are only found in 1 or 2 color channels), most colors span all three color channels.

Intended Inversion

Some algorithms are expected to have an inverted shape. For example, CMYK is really the inverse of RGBI ("I" is the gray-scale intensity). So CMYK should look upside-down:

Cyan (C in CMYK) is the inverse of red (R in RGB)

However, other algorithms have intensities that are clearly inverted. For example, the algorithm for converting HSV to RGB has an inverted Saturation function. Although S is supposed to be in the range [0:1], it really should be [1:0] to match the same intensity curve. (Saturation shows the amount of color that isn't washed out by the white level.)

Saturation (S in HSV) has an inverted power level

Now, keep in mind, HSV is a color space that traces back to the early 1800's. Back then, they didn't have computers for quickly generating power curves. So although the function is inverted, it has been inverted for over 200 years. Changing it now would just confuse people.

Unintended Confusion

Of course, other complex color systems don't have consistent power levels. For example, the chrominance power levels found in YUV (used by JPEG) may appear upright or inverted depending on the colors. The chrominance power curve is not directly influenced by the RGB values.

Luminance (grayscale)

Chrominance-Blue

Chrominance-Red

Why Be Consistent?

While the color curves are not consistent with other color spaces, that isn't a technical problem. The technical issues arise from all of the confusing aspects related to YUV. For example, with RGB, CMYK, and HSV, each letter stands for the color's name or attribute; R=red, Y=yellow, H=hue, etc. However, YUV is not an acronym or set of initials. "Y" (sometimes written Y') is just a letter chosen to represent the luminance. (I still wonder why the mathematicians did not use 'L' for luminance. It was probably too obvious.) And the luminance is really just the gray-scale intensity (so they could have used "I" for intensity).

Making things more confusing, the letters from YUV conflict with other color spaces. "Y" is already used by CMYK for "Y=Yellow". Similarly, V is the value from HSV -- the V from HSV is not the same as the V in YUV.

YUV or YVU?

Since the letters don't mean anything, people (including myself) frequently get them confused. For example, YUV is sometimes written YCC (luminance and two chrominance values; ignore that the two "C" values are different from each other and different from the Cyan color in CMYK).

YCC is really a shorthand notation for YCbCr (Luminance [Y], Chrominance-blue [Cb], and Chrominance-red [Cr]). Or is it YCrCb? According to Google, there are plenty of documents that associate YUV with YCrCb.

• Wikipedia. The Wikipedia definition is correct: YUV aligns with YCbCr. You can even see this if you plot the U and V values with a constant Y. (In this case, Y=0.5.) Notice how U goes from greenish to blue (it is the blue chrominance) and V goes from greenish to red (V is the red chrominance).
  
  
  
• yuv2ppm.c. The source code for yuv2ppm.c has the correct algorithm, but the wrong labels. The author says YCrCb but implemented YCbCr.
  
  
• FourCC. The FourCC web site has a great description of the various equations for implementing YUV. However, the page sometimes calls it YCbCr and sometimes says YCrCb.
  
  
• Kioskeo. Kioskeo.net says that YUV is YCrCb. They even say, "U is sometimes written as Cr and V is sometimes written as Cb, hence the notation YCrCb." While they have the correct equations, they got the definition backwards.
  
  
• ImpulseAdventure. This web site is a great reference for everything camera related. On their colorspace page, they correctly describe YCbCr but also mention that some people call it YCrCb.

For the record: YUV is analogous to YCbCr and not YCrCb. U is the chrominance-blue and V is the chrominance-red. They are not interchangeable.

Inequality

If you noticed, I keep saying YUV is analogous to YCbCr instead of "YUV is YCbCr". Depending on the documentation you read, there is a little difference. Some papers describe two different algorithms, while others differentiate between analog and digital signals. So while most people use the terms interchangeably and nearly everyone seems to implement YUV with the same algorithms, YCbCr may be a wee bit different numerically.

Then again, not everyone implements the same algorithms. Most people use one of these:

Y = 0.299R + 0.587G + 0.114B U = -0.147R - 0.289G + 0.436B V = 0.615R -0.515G -0.100B

Y = 0.257R + 0.504G + 0.098B + 16 U = -0.148R - 0.291G + 0.439B + 128 V = 0.439R - 0.368G - 0.071B + 128

Although the coefficients are similar, they are not identical.

Both sets of equations can be computationally expensive if R, G, and B are integers and you need to constantly convert between floats and ints. Microsoft uses a faster algorithm that only uses integers but isn't numerically equivalent:

Y = ( (  66R + 129G +  25B + 128 ) >> 8 ) +  16

U = ( ( -38R -  74G + 112B + 128 ) >> 8 ) + 128

V = ( ( 112R -  94G -  18B + 128 ) >> 8 ) + 128

Perhaps this is one reason why JPEGs rendered by Microsoft have slightly different coloring from Photoshop and other systems.

Here's a faster method for integers that is numerically equivalent to the first of the original equations:

Y = ( 299R + 587G + 114B)/1000

U = (-147R - 289G + 436B)/1000

V = ( 615R - 515G - 100B)/1000

Simply multiply out all fractions and then do one integer division at the end. (Add 128 to U and V if you want the range to be from 0 to 255.)

So while HSV may have an inverted power level for the saturation component, at least everyone is numerically equivalent. With YUV, you may see it called YCrCb but it is likely implemented as YCbCr using one of a handful of different (but similar) equations. And while the implementation differences probably won't be noticed by the human eye, these differences can lead to big problems with some automated systems and may also impact the ability to convert from RGB to YUV and back to RGB.

March was insane... I still can't believe that I wrote as much as I did. Besides trying to blog 1-2 times a week, I also wrote...

New Book

Completed my 3rd book: Ubuntu: Powerful Hacks and Customizations. Technically, this is the 2nd edition of my 2nd book. (Long story about why the 2nd edition has a new name. It's one of those things that is outside of the author's control.)

When I first wrote Hacking Ubuntu, the focus was on Ubuntu 6.06 (Dapper Drake). However, Dapper is past its support for the desktop edition and the server edition has about a year of support left. Also, with each Ubuntu release there are major changes. While the hacks worked well for Dapper, a few had problems with Hardy Heron and some didn't work for later releases. With this new book, I fixed the hacks so they would support Dapper Drake, Hardy Heron, and Karmic Koala. They should also be good for the next Ubuntu versions (but since Lucid Lynx and Maverick Meekat have not yet been released, I cannot guarantee everything).

One would think that revising an existing book would not be as time consuming as writing a new book from scratch. However, that really isn't the case. It takes almost the same effort to revise an entire book for the latest operating system releases.

Documentation

I've been finishing up the documentation for the photo and image analysis software. The software is geared toward law enforcement. I am not planning a general, public release because the learning curve is just too steep for the average person. Instead, the release will be initially limited to US law enforcement. (I'll probably change my focus to non-US law enforcement later this year.) When investigators testify on the witness stand, they cannot just say "I pressed a button and it drew a picture". They actually need to understand the algorithms. So my technical documentation explains the algorithms, provides sample use cases, and details the known limitations. I finished the writing last month -- over 100 pages for the technical documentation plus a 16-page guide for common scenarios and an 8-page installation guide.

I still have a little more work to do with the documentation. My friend, Chris Hanson, has been a godsend -- he's provided me with great example images. Unfortunately, I will need a few more pictures. Specifically, I need a few 100% computer generated images that are professional and high quality. If you are a professional graphic artist and can make high quality images similar to those found at the CG Society, please let me know! (I don't need custom graphics, exclusive rights, or a transfer of copyright. I'm hoping to find an artist who already has a sample portfolio and is willing to let me include one or two images.)

Papers and Code

I also wrote a bunch of white-papers including two that were over 100 pages. In total, I wrote nearly 200 pages last month and completed over 500 pages in papers, reports, and a book.

Not everything I wrote was in English. I did a ton of programming -- sloccount claims I wrote 3 months of code in one month, using C, Perl, Shell Script, and HTML. And while my college didn't recognize C or Perl as a foreign language, I think they really should count.