文章來源: http://hqtech.nease.net
原文作者: 陸其明
小知識：RGB與YUV----摘自《DirectShow實務精選》作者：陸其明
計 算機彩色顯示器顯示色彩的原理與彩色電視機一樣，都是採用R（Red）、G（Green）、B（Blue）相加混色的原理：通過發射出三種不同強度的電子 束，使屏幕內側覆蓋的紅、綠、藍磷光材料發光而產生色彩。這種色彩的表示方法稱為RGB色彩空間表示（它也是多媒體計算機技術中用得最多的一種色彩空間表 示方法）。
根據三基色原理，任意一種色光F都可以用不同份量的R、G、B三色相加混合而成。
F = r [ R ] + g [ G ] + b [ B ]
其中，r、g、b分別為三基色參與混合的係數。當三基色份量都為0（最弱）時混合為黑色光；而當三基色份量都為k（最強）時混合為白色光。調整r、g、b三個係數的值，可以混合出介於黑色光和白色光之間的各種各樣的色光。
那 麼YUV又從何而來呢？在現代彩色電視系統中，通常採用三管彩色攝像機或彩色CCD攝像機進行攝像，然後把攝得的彩色圖像信號經分色、分別放大校正後得到 RGB，再經過矩陣變換電路得到亮度信號Y和兩個色差信號R－Y（即U）、B－Y（即V），最後發送端將亮度和色差三個信號分別進行編碼，用同一信道發送 出去。這種色彩的表示方法就是所謂的YUV色彩空間表示。
採用YUV色彩空間的重要性是它的亮度信號Y和色度信號U、V是分離的。如果只有Y信號份量而沒有U、V份量，那麼這樣表示的圖像就是黑白灰度圖像。彩色電視採用YUV空間正是為了用亮度信號Y解決彩色電視機與黑白電視機的兼容問題，使黑白電視機也能接收彩色電視信號。
YUV與RGB相互轉換的公式如下（RGB取值範圍均為0-255）：
Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B
R = Y + 1.14V
G = Y - 0.39U - 0.58V
B = Y + 2.03U
在DirectShow中，常見的RGB格式有RGB1、RGB4、RGB8、RGB565、RGB555、RGB24、RGB32、ARGB32等；常見的YUV格式有YUY2、YUYV、YVYU、UYVY、AYUV、Y41P、Y411、Y211、IF09、IYUV、YV12、YVU9、YUV411、YUV420等。作為視頻媒體類型的輔助說明類型（Subtype），它們對應的GUID見表2.3。
表2.3 常見的RGB和YUV格式
GUID 格式描述
MEDIASUBTYPE_RGB1 2色，每個像素用1位表示，需要調色板
MEDIASUBTYPE_RGB4 16色，每個像素用4位表示，需要調色板
MEDIASUBTYPE_RGB8 256色，每個像素用8位表示，需要調色板
MEDIASUBTYPE_RGB565 每個像素用16位表示，RGB份量分別使用5位、6位、5位
MEDIASUBTYPE_RGB555 每個像素用16位表示，RGB份量都使用5位（剩下的1位不用）
MEDIASUBTYPE_RGB24 每個像素用24位表示，RGB份量各使用8位
MEDIASUBTYPE_RGB32 每個像素用32位表示，RGB份量各使用8位（剩下的8位不用）
MEDIASUBTYPE_ARGB32 每個像素用32位表示，RGB份量各使用8位（剩下的8位用於表示Alpha通道值）
MEDIASUBTYPE_YUY2 YUY2格式，以4:2:2方式打包
MEDIASUBTYPE_YUYV YUYV格式（實際格式與YUY2相同）
MEDIASUBTYPE_YVYU YVYU格式，以4:2:2方式打包
MEDIASUBTYPE_UYVY UYVY格式，以4:2:2方式打包
MEDIASUBTYPE_AYUV 帶Alpha通道的4:4:4 YUV格式
MEDIASUBTYPE_Y41P Y41P格式，以4:1:1方式打包
MEDIASUBTYPE_Y411 Y411格式（實際格式與Y41P相同）
MEDIASUBTYPE_Y211 Y211格式
MEDIASUBTYPE_IF09 IF09格式
MEDIASUBTYPE_IYUV IYUV格式
MEDIASUBTYPE_YV12 YV12格式
MEDIASUBTYPE_YVU9 YVU9格式
下面分別介紹各種RGB格式。
¨ RGB1、RGB4、RGB8都是調色板類型的RGB格式，在描述這些媒體類型的格式細節時，通常會在BITMAPINFOHEADER數據結構後面跟著 一個調色板（定義一系列顏色）。它們的圖像數據並不是真正的顏色值，而是當前像素顏色值在調色板中的索引。以RGB1（2色位圖）為例，比如它的調色板中 定義的兩種顏色值依次為0x000000（黑色）和0xFFFFFF（白色），那麼圖像數據001101010111…（每個像素用1位表示）表示對應各 像素的顏色為：黑黑白白黑白黑白黑白白白…。
¨ RGB565使用16位表示一個像素，這16位中的5位用於R，6位用於G，5位用於B。程序中通常使用一個字（WORD，一個字等於兩個字節）來操作一個像素。當讀出一個像素後，這個字的各個位意義如下：
高字節 低字節
R R R R R G G G G G G B B B B B
可以組合使用屏蔽字和移位操作來得到RGB各份量的值：
#define RGB565_MASK_RED 0xF800
#define RGB565_MASK_GREEN 0x07E0
#define RGB565_MASK_BLUE 0x001F
R = (wPixel & RGB565_MASK_RED) >> 11; // 取值範圍0-31
G = (wPixel & RGB565_MASK_GREEN) >> 5; // 取值範圍0-63
B = wPixel & RGB565_MASK_BLUE; // 取值範圍0-31
¨ RGB555是另一種16位的RGB格式，RGB份量都用5位表示（剩下的1位不用）。使用一個字讀出一個像素後，這個字的各個位意義如下：
高字節 低字節
X R R R R G G G G G B B B B B （X表示不用，可以忽略）
可以組合使用屏蔽字和移位操作來得到RGB各份量的值：
#define RGB555_MASK_RED 0x7C00
#define RGB555_MASK_GREEN 0x03E0
#define RGB555_MASK_BLUE 0x001F
R = (wPixel & RGB555_MASK_RED) >> 10; // 取值範圍0-31
G = (wPixel & RGB555_MASK_GREEN) >> 5; // 取值範圍0-31
B = wPixel & RGB555_MASK_BLUE; // 取值範圍0-31
¨ RGB24使用24位來表示一個像素，RGB份量都用8位表示，取值範圍為0-255。注意在內存中RGB各份量的排列順序為：BGR BGR BGR…。通常可以使用RGBTRIPLE數據結構來操作一個像素，它的定義為：
typedef struct tagRGBTRIPLE {
BYTE rgbtBlue; // 藍色份量
BYTE rgbtGreen; // 綠色份量
BYTE rgbtRed; // 紅色份量
} RGBTRIPLE;
¨ RGB32使用32位來表示一個像素，RGB份量各用去8位，剩下的8位用作Alpha通道或者不用。（ARGB32就是帶Alpha通道的 RGB32。）注意在內存中RGB各份量的排列順序為：BGRA BGRA BGRA…。通常可以使用RGBQUAD數據結構來操作一個像素，它的定義為：
typedef struct tagRGBQUAD {
BYTE rgbBlue; // 藍色份量
BYTE rgbGreen; // 綠色份量
BYTE rgbRed; // 紅色份量
BYTE rgbReserved; // 保留字節（用作Alpha通道或忽略）
} RGBQUAD;
下 面介紹各種YUV格式。YUV格式通常有兩大類：打包（packed）格式和平面（planar）格式。前者將YUV份量存放在同一個數組中，通常是幾個 相鄰的像素組成一個宏像素（macro-pixel）；而後者使用三個數組分開存放YUV三個份量，就像是一個三維平面一樣。表2.3中的YUY2到Y211都是打包格式，而IF09到YVU9都是平面格式。（注意：在介紹各種具體格式時，YUV各份量都會帶有下標，如Y0、U0、V0表示第一個像素的YUV份量，Y1、U1、V1表示第二個像素的YUV份量，以此類推。）
¨ YUY2（和YUYV）格式為每個像素保留Y份量，而UV份量在水平方向上每兩個像素採樣一次。一個宏像素為4個字節，實際表示2個像素。（4:2:2的意思為一個宏像素中有4個Y份量、2個U份量和2個V份量。）圖像數據中YUV份量排列順序如下：
Y0 U0 Y1 V0 Y2 U2 Y3 V2 …
¨ YVYU格式跟YUY2類似，只是圖像數據中YUV份量的排列順序有所不同：
Y0 V0 Y1 U0 Y2 V2 Y3 U2 …
¨ UYVY格式跟YUY2類似，只是圖像數據中YUV份量的排列順序有所不同：
U0 Y0 V0 Y1 U2 Y2 V2 Y3 …
¨ AYUV格式帶有一個Alpha通道，並且為每個像素都提取YUV份量，圖像數據格式如下：
A0 Y0 U0 V0 A1 Y1 U1 V1 …
¨ Y41P（和Y411）格式為每個像素保留Y份量，而UV份量在水平方向上每4個像素採樣一次。一個宏像素為12個字節，實際表示8個像素。圖像數據中YUV份量排列順序如下：
U0 Y0 V0 Y1 U4 Y2 V4 Y3 Y4 Y5 Y6 Y8 …
¨ Y211格式在水平方向上Y份量每2個像素採樣一次，而UV份量每4個像素採樣一次。一個宏像素為4個字節，實際表示4個像素。圖像數據中YUV份量排列順序如下：
Y0 U0 Y2 V0 Y4 U4 Y6 V4 …
¨ YVU9格式為每個像素都提取Y份量，而在UV份量的提取時，首先將圖像分成若干個4 x 4的宏塊，然後每個宏塊提取一個U份量和一個V份量。圖像數據存儲時，首先是整幅圖像的Y份量數組，然後就跟著U份量數組，以及V份量數組。IF09格式與YVU9類似。
¨ IYUV格式為每個像素都提取Y份量，而在UV份量的提取時，首先將圖像分成若干個2 x 2的宏塊，然後每個宏塊提取一個U份量和一個V份量。YV12格式與IYUV類似。
¨ YUV411、YUV420格式多見於DV數據中，前者用於NTSC制，後者用於PAL制。YUV411為每個像素都提取Y份量，而UV份量在水平方向上 每4個像素採樣一次。YUV420並非V份量採樣為0，而是跟YUV411相比，在水平方向上提高一倍色差採樣頻率，在垂直方向上以U/V間隔的方式減小 一半色差採樣，如圖2.12所示。
顏色問題：
我們在DVDRIP或內嵌的時候，通常會遇到一些關於顏色方面的術語，比如YUV、RGB、YV12、4:2:2、4:2:0等等。不少人剛接觸到這些東西的時候，會覺得暈頭轉向，不知所云。
再如，不少文章中強調影片在VDM處理的過程中要選Fast recompress，但是Fast recompress、Normal recompress、Full processing mode之間又有什麼區別呢？
本文來一一為您解答這些問題。
本 文是一篇總結性的文章，所以不少段落都是直接摘自其他的文章的。在這裡向原作者表示謝意。本文參考了原載於DVD Benchmark由Don Munsil & Stacey Spears原作的《The Chroma Upsampling Error（顏色Upsampling錯誤）》和Silky的文章。
1.什麼是RGB？
RGB是紅綠藍三原色的意思，R=Red、G=Green、B=Blue。
2.什麼是YUV/YCbCr/YPbPr？
亮 度信號經常被稱作Y，色度信號是由兩個互相獨立的信號組成。視顏色系統和格式不同，兩種色度信號經常被稱作U和V或Pb和Pr或Cb和Cr。這些都是由不 同的編碼格式所產生的，但是實際上，他們的概念基本相同。在DVD中，色度信號被存儲成Cb和Cr（C代表顏色，b代表藍色，r代表紅色）。
3.什麼是4:4:4、4:2:2、4:2:0？
在 最近十年中，視頻工程師發現人眼對色度的敏感程度要低於對亮度的敏感程度。在生理學中，有一條規律，那就是人類視網膜上的視網膜桿細胞要多於視網膜錐細 胞，說得通俗一些，視網膜桿細胞的作用就是識別亮度，而視網膜錐細胞的作用就是識別色度。所以，你的眼睛對於亮和暗的分辨要比對顏色的分辨精細一些。正是 因為這個，在我們的視頻存儲中，沒有必要存儲全部顏色信號。既然眼睛看不見，那為什麼要浪費存儲空間（或者說是金錢）來存儲它們呢？
像Beta或VHS之類的消費用錄像帶就得益於將錄像帶上的更多帶寬留給黑—白信號（被稱作「亮度」），將稍少的帶寬留給彩色信號（被稱作「色度」）。
在MPEG2（也就是DVD使用的壓縮格式）當中，Y、Cb、Cr信號是分開儲存的（這就是為什麼份量視頻傳輸需要三條電纜）。其中Y信號是黑白信號，是以全分辨率存儲的。但是，由於人眼對於彩色信息的敏感度較低，色度信號並不是用全分辨率存儲的。
色 度信號分辨率最高的格式是4:4:4，也就是說，每4點Y採樣，就有相對應的4點Cb和4點Cr。換句話說，在這種格式中，色度信號的分辨率和亮度信號的 分辨率是相同的。這種格式主要應用在視頻處理設備內部，避免畫面質量在處理過程中降低。當圖像被存儲到Master Tape，比如D1或者D5，的時候，顏色信號通常被削減為4:2:2。
[center]
在圖一中，你可以看到4:4:4格式的亮度、色度採樣分佈。就像圖中所表示的，畫面中每個像素都有與之對應的色度和亮度採樣信息。[/center]
其 次就是4:2:2，就是說，每4點Y採樣，就有2點Cb和2點Cr。在這種格式中，色度信號的掃瞄線數量和亮度信號一樣多，但是每條掃瞄線上的色度採樣點 數卻只有亮度信號的一半。當4:2:2信號被解碼的時候，「缺失」的色度採樣，通常由一定的內插補點算法通過它兩側的色度信息運算補充。
[center]
圖 二表示了4:2:2格式亮度、色度採樣的分佈情況。在這裡，每個像素都有與之對應的亮度採樣，同時一半的色度採樣被丟棄，所以我們看到，色度採樣信號每隔 一個採樣點才有一個。當著張畫面顯示的時候，缺少的色度信息會由兩側的顏色通過內插補點的方式運算得到。就像上面提到的那樣，人眼對色度的敏感程度不如亮 度，大多數人並不能分辨出4:2:2和4:4:4顏色構成的畫面之間的不同。[/center]
色度信號分辨率最低的格式，也就是DVD所使用的 格式，就是4:2:0了。事實上4:2:0是一個混亂的稱呼，按照字面上理解，4:2:0應該是每4點Y採樣，就有2點Cb和0點Cr，但事實上完全不是 這樣。事實上，4:2:0的意思是，色度採樣在每條橫向掃瞄線上只有亮度採樣的一半，掃瞄線的條數上，也只有亮度的一半！換句話說，無論是橫向還是縱向， 色度信號的分辨率都只有亮度信號的一半。舉個例子，如果整張畫面的尺寸是720*480，那麼亮度信號是720*480，色度信號只有360*240。在 4:2:0中，「缺失」的色度採樣不單單要由左右相鄰的採樣通過內插補點計算補充，整行的色度採樣也要通過它上下兩行的色度採樣通過內插補點運算獲得。這 樣做的原因是為了最經濟有效地利用DVD的存儲空間。誠然，4:4:4的效果很棒，但是如果要用4:4:4存儲一部電影，我們的DVD盤的直徑至少要有兩 英呎（六十多釐米）！
[center]
圖三表示了概念上4:2:0顏色格式非交錯畫面中亮度、色度採樣信號的排列情況。同4:2:2格式 一樣，每條掃瞄線中，只有一半的色度採樣信息。與4:2:2不同的是，不光是橫向的色度信息被「扔掉」了一半，縱向的色度信息也被「扔掉」了一半，整個屏 幕中色度採樣只有亮度採樣的四分之一。請注意，在4:2:0顏色格式中，色度採樣被放在了兩條掃瞄線中間。為什麼會這樣呢？很簡單：DVD盤上的顏色採樣 是由其上下兩條掃瞄線的顏色信息「平均」而來的。比如，圖三中，第一行顏色採樣（Line 1和Line 2中間夾著的那行）是由Line 1和Line 2「平均」得到的，第二行顏色採樣（Line 3和Line 4中間夾著的那行）也是同樣的道理，是由Line 3和Line 4得到的。
雖然文章中多次提到「平均」這個概念，但是這個「平均」可不是我們通常意義上的(a+B)/2的平均。顏色的處理有極其複雜的算法保證其最大限度地減少失真，接近原始質量。[/center]
4.什麼是YV12，什麼是YUY2？
在個人計算機上，這些YUV讀出來以後會以一些格式包裝起來，送給軟件或硬件處理。包裝的方式分成兩種，一種是Packed format，把Y和相對應的UV包在一起。另一種是Planar format，把Y和U和V三種分別包裝，拆成三個plane（平面）。
其中YV12和YUY2都是一種YUV的包裝格式，
YV12和YUY2的不同，在於YV12是YUV4:2:0格式，也就是DVD/VCD上原本儲存的格式。YUY2則是YUV4:2:2格式。
5.為什麼影片在VDM處理的過程中要選Fast recompress？
選擇Fast recompress的原因，現得從Avisynth 2.5講起。
Avisynth 2.5最大的特色，就是支持YV12直接處理。我們知道原始MPEG數據是YUV4:2:0，也就是YV12的格式，以前我們在做DivX/XviD壓縮的時候，處理流程是：
DVD/VCD(YUV 4:2:0) -> DVD2AVI(YUV 4:2:0 ->YUV4:2:2 ->YUV4:4:4 -> RGB24) -> VFAPI(RGB24) -> TMPGEnc/AviUtl/VirtualDub(RGB24) -> DivX/XviD Codec(RGB24 ->YUV4:2:0) -> MPEG-4(YUV 4:2:0)
ps. VFAPI 內部只能以 RGB24 傳遞數據，所以會轉成 RGB24 輸出
或是
DVD/VCD(YUV 4:2:0) -> MPG2DEC.DLL(YUV 4:2:0 ->YUV4:2:2) -> Avisynth 2.0.x(只能用支援YUV4:2:2 的濾鏡，不能用 RGB24/32 的 filter) -> VirtualDub(YUV 4:2:2，不能使用 VD 的 filter，因為 VD 的 filetr 都是在 RGB32 上處理，壓縮時要選 Fast recompress，才會直接原封不動的送YUV4:2:2，也就是 YUY2 的數據給 Codec 壓縮) -> DivX/XviD Codec(YUV 4:2:2 ->YUV4:2:0) -> MPEG-4(YUV 4:2:0)
所以以前的處理流程中間要經過好幾次YUV<-> RGB 的轉換。這個轉換是有損的，做得越多次，原始的色彩信息就損失的越嚴重。而且這個轉換的計算又耗時（這就可以解釋為什麼我們將YV12轉為RGB輸出時會卡的多，不過，RGB的品質真的更高的多:)）。那麼有人（Marc FD）就想到，反正最後轉成 MPEG 都要存成YUV4:2:0 的格式，那麼為什麼不乾脆一路到底，全程都以YV12處理，也就是所有的 filter 都改寫成YV12的版本，直接在YV12上做調整色彩、濾噪訊、IVTC 等工作，這樣：
1. 處理的數據量少。（YV12的資料，UV 比YUY2少一半，比RGB 24/32少更多）
2. 不用轉換計算
所以速度快。再加上又可以避免YUV<-> RGB 轉換的損失，豈不是一舉兩得？
所以支持YV12的 Avisynth 2.5 就誕生了。
但是目前VirtualDub還是不支持 YV12，即使選 Fast recompress，VD還是會將YV12的輸入轉為 YUY2。所以要得到全程YV12處理的好處，必須使用VirtualDubMod才行，這個改版才有支持YV12。只有在選擇Fast recompress的時候，VDM才不會進行任何處理，直接將數據丟給編碼器壓縮，這樣就能保留YV12，實現了全程YV12。
沒有留言:
張貼留言