diff options
Diffstat (limited to 'DOCS/OUTDATED-tech/colorspaces.txt')
-rw-r--r-- | DOCS/OUTDATED-tech/colorspaces.txt | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/DOCS/OUTDATED-tech/colorspaces.txt b/DOCS/OUTDATED-tech/colorspaces.txt new file mode 100644 index 0000000000..eaf9d221e4 --- /dev/null +++ b/DOCS/OUTDATED-tech/colorspaces.txt @@ -0,0 +1,158 @@ +In general +========== + +There are planar and packed modes. +- Planar mode means: You have 3 separate images, one for each component, +each image 8 bits/pixel. To get the real colored pixel, you have to +mix the components from all planes. The resolution of planes may differ! +- Packed mode means: you have all components mixed/interleaved together, +so you have small "packs" of components in a single, big image. + +There are RGB and YUV colorspaces. +- RGB: Red, Green and Blue components. Used by analog VGA monitors. +- YUV: Luminance (Y) and Chrominance (U,V) components. Used by some + video systems, like PAL. Also most M(J)PEG/DCT based codecs use this. + +With YUV, they used to reduce the resolution of U,V planes: +The most common YUV formats: +FOURCC: bpp: IEEE: plane sizes: (w=width h=height of original image) +444P 24 YUV 4:4:4 Y: w * h U,V: w * h +YUY2,UYVY 16 YUV 4:2:2 Y: w * h U,V: (w/2) * h [MJPEG] +YV12,I420 12 YUV 4:2:0 Y: w * h U,V: (w/2) * (h/2) [MPEG, H.263] +411P 12 YUV 4:1:1 Y: w * h U,V: (w/4) * h [DV-NTSC, CYUV] +YVU9,IF09 9 YUV 4:1:0 Y: w * h U,V: (w/4) * (h/4) [Sorenson, Indeo] + +The YUV a:b:c naming style means: for <a> samples of Y there are <b> samples +of UV in odd lines and <c> samples of UV in even lines. + +conversion: (some cut'n'paste from www and maillist) + +RGB to YUV Conversion: + Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16 + Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128 + Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128 +YUV to RGB Conversion: + B = 1.164(Y - 16) + 2.018(U - 128) + G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128) + R = 1.164(Y - 16) + 1.596(V - 128) + +In both these cases, you have to clamp the output values to keep them in +the [0-255] range. Rumour has it that the valid range is actually a subset +of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the +values into [0-255] seems to produce acceptable results to me. + +Julien (sorry, I can't recall his surname) suggests that there are +problems with the above formula and proposes the following instead: + Y = 0.299R + 0.587G + 0.114B + Cb = U'= (B-Y)*0.565 + Cr = V'= (R-Y)*0.713 +with reciprocal versions: + R = Y + 1.403V' + G = Y - 0.344U' - 0.714V' + B = Y + 1.770U' +Note: This formula doesn't contain the +128 offsets of U,V values! + +Conclusion: +Y = luminance, the weighted average of R G B components. (0=black 255=white) +U = Cb = blue component (0=green 128=grey 255=blue) +V = Cr = red component (0=green 128=grey 255=red) + + +Huh. The planar YUV modes. +========================== + +The most misunderstood thingie... + +In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it +doesn't matter what the order of the planes in the memory is: + for mp_image_t and libvo's draw_slice(): + planes[0] = Y = luminance + planes[1] = U = Cb = blue + planes[2] = V = Cr = red + Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC + (YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers + (not only the first one) normally supports YV12 and I420 (=IYUV), too! + +But there are some codecs (VfW, dshow) and vo drivers (xv) ignoring the 2nd +and 3rd pointer that use only a single pointer to the planar YUV image. In +this case we must know the right order and alignment of planes in the memory! + +from the webartz fourcc list: +YV12: 12 bpp, full sized Y plane followed by 2x2 subsampled V and U planes +I420: 12 bpp, full sized Y plane followed by 2x2 subsampled U and V planes +IYUV: the same as I420 +YVU9: 9 bpp, full sized Y plane followed by 4x4 subsampled V and U planes + +Huh 2. RGB vs. BGR ? +==================== + +The 2nd most misunderstood thingie... + +You know, there are Intel and Motorola, and they use different byteorder. +There are also others, like MIPS or Alpha, but all follow either Intel +or Motorola byteorder. +Unfortunately, the packed colorspaces depend on CPU byteorder. So, RGB +on Intel and Motorola means different order of bytes. + +In MPlayer, we have constants IMGFMT_RGBxx and IMGFMT_BGRxx. +Unfortunately, some codecs and vo drivers follow Intel, some follow Motorola +byteorder, so they are incompatible. We had to find a stable base, so long +time ago I've chosen OpenGL, as it's a wide-spreaded standard, and it well +defines what RGB is and what BGR is. So, MPlayer's RGB is compatible with +OpenGL's GL_RGB on all platforms, and the same goes for BGR - GL_BGR. +Unfortunately, most of the x86 codecs call our BGR RGB, so it sometimes +confuses developers. + +memory order: name +lowest address .. highest address +RGBA IMGFMT_RGBA +ARGB IMGFMT_ARGB +BGRA IMGFMT_BGRA +ABGR IMGFMT_ABGR +RGB IMGFMT_RGB24 +BGR IMGFMT_BGR24 + +order in an int name +most significant .. least significant bit +8A8R8G8B IMGFMT_BGR32 +8A8B8G8R IMGFMT_RGB32 +5R6G5B IMGFMT_BGR16 +5B6G5R IMGFMT_RGB16 +1A5R5G5B IMGFMT_BGR15 +1A5B5G5R IMGFMT_RGB15 + +The following are palettized formats, the palette is in the second plane. +When they come out of the swscaler (this can be different when they +come from a codec!), their palette is organized in such a way +that you actually get: + +3R3G2B IMGFMT_BGR8 +2B3G3R IMGFMT_RGB8 +1R2G1B IMGFMT_BGR4_CHAR +1B2G1R IMGFMT_RGB4_CHAR +1R2G1B1R2G1B IMGFMT_BGR4 +1B2G1R1B2G1R IMGFMT_RGB4 + +Depending upon the CPU being little- or big-endian, different 'in memory' and +'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32) + +Practical coding guide: + +The 4, 8, 15, and 16 bit formats are defined so that the portable way to +access them is to load the pixel into an integer and use bitmasks. + +The 24 bit formats are defined so that the portable way to access them is +to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0], +((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2]. + +When a 32-bit format is identified by the four characters A, R, G, and B in +some order, the portable way to access it is by addressing the 4 components +as separate bytes. + +When a 32-bit format is identified by the 3 characters R, G, and B in some +order followed by the number 32, the portable way to access it is to load +the pixel into an integer and use bitmasks. + +When the above portable access methods are not used, you will need to write +2 versions of your code, and use #if HAVE_BIGENDIAN to choose the correct +one. |