Mercurial > mplayer.hg
annotate DOCS/tech/colorspaces.txt @ 17974:9a5a62f480e6
Rename the default GUI skins directory from 'Skin' to 'skins', keeping
backwards compatibility.
author | diego |
---|---|
date | Mon, 27 Mar 2006 11:39:27 +0000 |
parents | 786628f8db88 |
children | f01023c524c3 |
rev | line source |
---|---|
5586 | 1 In general |
2 ========== | |
3 | |
4 There are planar and packed modes. | |
15033 | 5 - Planar mode means: You have 3 separate images, one for each component, |
5735 | 6 each image 8 bits/pixel. To get the real colored pixel, you have to |
5586 | 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. | |
5312 | 10 |
5586 | 11 There are RGB and YUV colorspaces. |
15033 | 12 - RGB: Red, Green and Blue components. Used by analog VGA monitors. |
5586 | 13 - YUV: Luminance (Y) and Chrominance (U,V) components. Used by some |
15033 | 14 video systems, like PAL. Also most M(J)PEG/DCT based codecs use this. |
5312 | 15 |
5586 | 16 With YUV, they used to reduce the resolution of U,V planes: |
17 The most common YUV formats: | |
15033 | 18 FOURCC: bpp: IEEE: plane sizes: (w=width h=height of original image) |
7833 | 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] | |
15033 | 21 YV12,I420 12 YUV 4:2:0 Y: w * h U,V: (w/2) * (h/2) [MPEG, H.263] |
7833 | 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] | |
5586 | 24 |
8814 | 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 | |
5586 | 28 conversion: (some cut'n'paste from www and maillist) |
5312 | 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 | |
15033 | 44 Julien (sorry, I can't recall his surname) suggests that there are |
45 problems with the above formula and proposes the following instead: | |
5735 | 46 Y = 0.299R + 0.587G + 0.114B |
5312 | 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' | |
15033 | 53 Note: This formula doesn't contain the +128 offsets of U,V values! |
5312 | 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) | |
5314 | 58 V = Cr = red component (0=green 128=grey 255=red) |
5312 | 59 |
5586 | 60 |
61 Huh. The planar YUV modes. | |
62 ========================== | |
63 | |
5735 | 64 The most misunderstood thingie... |
5586 | 65 |
5312 | 66 In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it |
15033 | 67 doesn't matter what the order of the planes in the memory is: |
5314 | 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 | |
15033 | 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! | |
5314 | 75 |
15033 | 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 | |
5312 | 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 | |
5587 | 86 Huh 2. RGB vs. BGR ? |
87 ==================== | |
88 | |
5735 | 89 The 2nd most misunderstood thingie... |
5587 | 90 |
91 You know, there are Intel and Motorola, and they use different byteorder. | |
15033 | 92 There are also others, like MIPS or Alpha, but all follow either Intel |
5587 | 93 or Motorola byteorder. |
5735 | 94 Unfortunately, the packed colorspaces depend on CPU byteorder. So, RGB |
5587 | 95 on Intel and Motorola means different order of bytes. |
96 | |
97 In MPlayer, we have constants IMGFMT_RGBxx and IMGFMT_BGRxx. | |
5735 | 98 Unfortunately, some codecs and vo drivers follow Intel, some follow Motorola |
5587 | 99 byteorder, so they are incompatible. We had to find a stable base, so long |
5735 | 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. | |
15033 | 103 Unfortunately, most of the x86 codecs call our BGR RGB, so it sometimes |
104 confuses developers. | |
5587 | 105 |
12997 | 106 memory order: name |
13032 | 107 lowest address .. highest address |
12997 | 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 | |
13535 | 116 most significant .. least significant bit |
12997 | 117 8A8R8G8B IMGFMT_BGR32 |
118 8A8B8G8R IMGFMT_RGB32 | |
119 5R6G5B IMGFMT_BGR16 | |
120 5B6G5R IMGFMT_RGB16 | |
121 1A5R5G5B IMGFMT_BGR15 | |
122 1A5B5G5R IMGFMT_RGB15 | |
13992 | 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 | |
15033 | 126 come from a codec!), their palette is organized in such a way |
13992 | 127 that you actually get: |
128 | |
12997 | 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 | |
15033 | 136 Depending upon the CPU being little- or big-endian, different 'in memory' and |
13032 | 137 'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32) |
17680
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
138 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
139 Practical coding guide: |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
140 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
141 The 4, 8, 15, and 16 bit formats are defined so that the portable way to |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
142 access them is to load the pixel into an integer and use bitmasks. |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
143 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
144 The 24 bit formats are defined so that the portable way to access them is |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
145 to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0], |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
146 ((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2]. |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
147 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
148 When a 32-bit format is identified by the four characters A, R, G, and B in |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
149 some order, the portable way to access it is by addressing the 4 components |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
150 as separate bytes. |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
151 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
152 When a 32-bit format is identified by the 3 characters R, G, and B in some |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
153 order followed by the number 32, the portable way to access it is to load |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
154 the pixel into an integer and use bitmasks. |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
155 |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
156 When the above portable access methods are not used, you will need to write |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
157 2 versions of your code, and use #ifdef WORDS_BIGENDIAN to choose the correct |
786628f8db88
Add a practical description of endian-independent RGB/BGR coding
pacman
parents:
15033
diff
changeset
|
158 one. |