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.