I am curious about the YCbCr color model for representing grayscale images.

Can someone provide a detailed explanation of how image data is encoded as YCbCr, when it might be used over another encoding format, and what additional capabilities it may offer over other encoding formats?

I'm sorry, but I'm having some trouble understanding this. Do you mean "How are grayscale images encoded in YCbCr?"
–
mattdmNov 13 '11 at 13:24

It would also be helpful if you could explain the situation in which you are running into this problem.
–
mattdmNov 13 '11 at 13:31

Wikipedia seems to provide a reasonable summary en.wikipedia.org/wiki/YCbCr . A quick scan suggests that it's primarily as a way of allowing image/video data to be compressed...
–
forsvarirNov 16 '11 at 11:11

@Flimzy (and Imre): you've improved the sentence structure, but I'm not sure the meaning of the question is clarified. The original text had "if we convert to YCBCR we havent had any color image how is it?", and I'm not sure that "If we convert to YCBCR we don't have a color image" accurately represents that (and also doesn't make any sense).
–
mattdmNov 18 '11 at 11:44

I've reworded the title and question. I hope I have not lost anything from the original while making it a more useful question.
–
jrista♦Nov 20 '11 at 1:32

1 Answer
1

The YCbCr model has a few variations in different application contexts, but essentially they are all some affine (linear) transformation on the RGB color data. If you think of the RGB space in terms of a 3D cube, with its sides representing the R, G and B axes (for JPEG, their range would normally be from 0 to 255), then each pixel in your image corresponds to a 3D point inside the cube, where its color component values are the point's coordinates. This forms a "cloud" of points inside the cube.

Examining many normal images in this representation shows that the clouds tend to have some common shape, where most of the points are concentrated along the main diagonal (more or less) of the cube. So, if we now rotate the cube (our reference axes system) such that its first axis is aligned with the long axis of the cloud we now have a new set of point coordinates where the first coordinate carries most of the information and the other two carry less information.

The first coordinate happens to carry the intensity value of the pixel where the other two coordinates correspond to the color information of the pixel. Grossly, these constitute the Y (luma, intensity), Cb and Cr (chroma) components of the YCbCr representation of the color of the pixel in the image.

There are a couple of outcomes from this. First, you can take the Y channel and directly display it as a gray scale image. Then, as @forsvarir commented, we can discard some of the color information and still have acceptable image quality - which helps us to get better compression ratios.

The origins of this kind of pixel representation dates back to the days of transition from B&W to color TV broadcasts, where backward compatibility was required so that people who did not upgrade their sets would be able to watch color programs in B&W. The solution was to remain with the intensity (i.e. B&W) signal and superimpose some color components on top of it. This way, the B&W tuner could still use the broadcast signal with some acceptable level of distortions.