Update to MPlayer SVN rev 29473 and FFmpeg SVN rev 19572.
[vaapi:athaifas-mplayer.git] / DOCS / tech / colorspaces.txt
1 In general
2 ==========
3
4 There are planar and packed modes.
5 - Planar mode means: You have 3 separate images, one for each component,
6 each image 8 bits/pixel. To get the real colored pixel, you have to
7 mix the components from all planes. The resolution of planes may differ!
8 - Packed mode means: you have all components mixed/interleaved together,
9 so you have small "packs" of components in a single, big image.
10
11 There are RGB and YUV colorspaces.
12 - RGB: Red, Green and Blue components. Used by analog VGA monitors.
13 - YUV: Luminance (Y) and Chrominance (U,V) components. Used by some
14   video systems, like PAL. Also most M(J)PEG/DCT based codecs use this.
15
16 With YUV, they used to reduce the resolution of U,V planes:
17 The most common YUV formats:
18 FOURCC:    bpp: IEEE:      plane sizes: (w=width h=height of original image)
19 444P       24   YUV 4:4:4  Y: w * h  U,V: w * h
20 YUY2,UYVY  16   YUV 4:2:2  Y: w * h  U,V: (w/2) * h      [MJPEG]
21 YV12,I420  12   YUV 4:2:0  Y: w * h  U,V: (w/2) * (h/2)  [MPEG, H.263]
22 411P       12   YUV 4:1:1  Y: w * h  U,V: (w/4) * h      [DV-NTSC, CYUV]
23 YVU9,IF09   9   YUV 4:1:0  Y: w * h  U,V: (w/4) * (h/4)  [Sorenson, Indeo]
24
25 The YUV a:b:c naming style means: for <a> samples of Y there are <b> samples
26 of UV in odd lines and <c> samples of UV in even lines.
27
28 conversion: (some cut'n'paste from www and maillist)
29
30 RGB to YUV Conversion:
31     Y  =      (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
32     Cr = V =  (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
33     Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
34 YUV to RGB Conversion:
35     B = 1.164(Y - 16)                  + 2.018(U - 128)
36     G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)
37     R = 1.164(Y - 16) + 1.596(V - 128)
38
39 In both these cases, you have to clamp the output values to keep them in
40 the [0-255] range. Rumour has it that the valid range is actually a subset
41 of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the
42 values into [0-255] seems to produce acceptable results to me.
43
44 Julien (sorry, I can't recall his surname) suggests that there are
45 problems with the above formula and proposes the following instead:
46     Y  = 0.299R + 0.587G + 0.114B
47     Cb = U'= (B-Y)*0.565
48     Cr = V'= (R-Y)*0.713
49 with reciprocal versions:
50     R = Y + 1.403V'
51     G = Y - 0.344U' - 0.714V'
52     B = Y + 1.770U'
53 Note: This formula doesn't contain the +128 offsets of U,V values!
54
55 Conclusion:
56 Y = luminance, the weighted average of R G B components. (0=black 255=white)
57 U = Cb = blue component (0=green 128=grey 255=blue)
58 V = Cr = red component  (0=green 128=grey 255=red)
59
60
61 Huh. The planar YUV modes.
62 ==========================
63
64 The most misunderstood thingie...
65
66 In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it
67 doesn't matter what the order of the planes in the memory is:
68     for mp_image_t and libvo's draw_slice():
69         planes[0] = Y = luminance
70         planes[1] = U = Cb = blue
71         planes[2] = V = Cr = red
72     Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC
73     (YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers
74     (not only the first one) normally supports YV12 and I420 (=IYUV), too!
75
76 But there are some codecs (VfW, dshow) and vo drivers (xv) ignoring the 2nd
77 and 3rd pointer that use only a single pointer to the planar YUV image. In
78 this case we must know the right order and alignment of planes in the memory!
79
80 from the webartz fourcc list:
81 YV12:  12 bpp, full sized Y plane followed by 2x2 subsampled V and U planes
82 I420:  12 bpp, full sized Y plane followed by 2x2 subsampled U and V planes
83 IYUV:  the same as I420
84 YVU9:   9 bpp, full sized Y plane followed by 4x4 subsampled V and U planes
85
86 Huh 2. RGB vs. BGR ?
87 ====================
88
89 The 2nd most misunderstood thingie...
90
91 You know, there are Intel and Motorola, and they use different byteorder.
92 There are also others, like MIPS or Alpha, but all follow either Intel
93 or Motorola byteorder.
94 Unfortunately, the packed colorspaces depend on CPU byteorder. So, RGB
95 on Intel and Motorola means different order of bytes.
96
97 In MPlayer, we have constants IMGFMT_RGBxx and IMGFMT_BGRxx.
98 Unfortunately, some codecs and vo drivers follow Intel, some follow Motorola
99 byteorder, so they are incompatible. We had to find a stable base, so long
100 time ago I've chosen OpenGL, as it's a wide-spreaded standard, and it well
101 defines what RGB is and what BGR is. So, MPlayer's RGB is compatible with
102 OpenGL's GL_RGB on all platforms, and the same goes for BGR - GL_BGR.
103 Unfortunately, most of the x86 codecs call our BGR RGB, so it sometimes
104 confuses developers.
105
106 memory order:           name
107 lowest address .. highest address
108 RGBA                    IMGFMT_RGBA
109 ARGB                    IMGFMT_ARGB
110 BGRA                    IMGFMT_BGRA
111 ABGR                    IMGFMT_ABGR
112 RGB                     IMGFMT_RGB24
113 BGR                     IMGFMT_BGR24
114
115 order in an int         name
116 most significant .. least significant bit
117 8A8R8G8B                IMGFMT_BGR32
118 8A8B8G8R                IMGFMT_RGB32
119 5R6G5B                  IMGFMT_BGR16
120 5B6G5R                  IMGFMT_RGB16
121 1A5R5G5B                IMGFMT_BGR15
122 1A5B5G5R                IMGFMT_RGB15
123
124 The following are palettized formats, the palette is in the second plane.
125 When they come out of the swscaler (this can be different when they
126 come from a codec!), their palette is organized in such a way
127 that you actually get:
128
129 3R3G2B                  IMGFMT_BGR8
130 2B3G3R                  IMGFMT_RGB8
131 1R2G1B                  IMGFMT_BGR4_CHAR
132 1B2G1R                  IMGFMT_RGB4_CHAR
133 1R2G1B1R2G1B            IMGFMT_BGR4
134 1B2G1R1B2G1R            IMGFMT_RGB4
135
136 Depending upon the CPU being little- or big-endian, different 'in memory' and
137 'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32)
138
139 Practical coding guide:
140
141 The 4, 8, 15, and 16 bit formats are defined so that the portable way to
142 access them is to load the pixel into an integer and use bitmasks.
143
144 The 24 bit formats are defined so that the portable way to access them is
145 to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0],
146 ((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2].
147
148 When a 32-bit format is identified by the four characters A, R, G, and B in
149 some order, the portable way to access it is by addressing the 4 components
150 as separate bytes.
151
152 When a 32-bit format is identified by the 3 characters R, G, and B in some
153 order followed by the number 32, the portable way to access it is to load
154 the pixel into an integer and use bitmasks.
155
156 When the above portable access methods are not used, you will need to write
157 2 versions of your code, and use #if HAVE_BIGENDIAN to choose the correct
158 one.