alpha混合聽上去很神秘，實際非常簡單，其作用就是要實現(xiàn)一種半透明效果。假設(shè)一種不透明東西的顏色是A，另一種透明的東西的顏色是B，那么透過B去看A，看上去的顏色C就是B和A的混合顏色，可以用這個式子來近似，設(shè)B物體的透明度為alpha(取值為0-1，0為完全透明，1為完全不透明)

R(C)=alpha*R(B)+(1-alpha)*R(A)
G(C)=alpha*G(B)+(1-alpha)*G(A)
B(C)=alpha*B(B)+(1-alpha)*B(A)

　　R(x)、G(x)、B(x)分別指顏色x的RGB分量。看起來這個東西這么簡單，可是用它實現(xiàn)的效果絕對不簡單，應(yīng)用alpha混合技術(shù)，可以實現(xiàn)出最眩目的火光、煙霧、陰影、動態(tài)光源等等一切你可以想象的出來的半透明效果。

　　火光、煙霧的效果是事先做好一個火或霧的圖和一個alpha通道圖(用過Photoshop的人都該知道什么是alpha通道)，畫上去的時候每點每點計算，得到的就是火光掩映的效果。霧化效果在3D里還需要模糊一下，在這里就免了，本來alpha混合就有不小的計算量了，算法再不優(yōu)化再加上模糊或其它的一些什么原因，那么你就是在看幻燈片了。(關(guān)于優(yōu)化，網(wǎng)上見仁見智，我再找時候再講)。

　　動態(tài)光源，聽起來高深的一塌。那我先講一下陰影，這個就簡單了，以往的游戲也有陰影(象《仙劍》)，不過我們把它升一下級，從不透明變成半透明而已。就是把一個影子圖放在地表上面作alpha混合(而且可以簡化，因為影子的alpha值可以是一定的，這樣就可以大幅提高計算速度)就OK了。

　　該講動態(tài)光源了。我們把沒有光源的地方想象成一張黑幕蒙在屏幕上，沒光也就什么都看不到。那么我們就加上一個光源，相當(dāng)于在黑幕上挖了一個洞，這個洞的大小就是被照亮的范圍，現(xiàn)在我們可以看到下面的東西了。但現(xiàn)在這個效果說是光源，倒不如說是個窗戶，要顯得象光源，就要讓光源的中心最亮，逐漸向四周暗下去，最后到什么都看不見，這才象個光源。具體實現(xiàn)就是alpha混合啦，蒙版的顏色是黑，中心alpha值為0，完全透明，到光源的盡頭alpha值為1，完全不透明，成果就是這個樣子，象這么回事吧！光源做好了，動態(tài)的光源就是實時生成一個動態(tài)的alpha蒙版，然后蓋上去就行了。

　　不難吧！游戲里(其實也不只游戲，好多算法也是這樣)的一些技術(shù)聽起來很玄，說通了也就是那么回事，只不過不是一下子就能想到就是了。

　　Diablo里面就大量應(yīng)用了alpha混合技術(shù)(至少我看上去象)，那些眩目的魔法產(chǎn)生出來的半透明效果，還有亂飛的火球照亮迷宮，每個火球也就是個小的光源，一堆光源產(chǎn)生出來的蒙版(就是對應(yīng)的alpha相加，超過255就截斷)再蒙上去。(真正的光源應(yīng)該是這樣的：當(dāng)alpha值超過255時，alpha=alpha-255，alpha是一個Byte時也就是回繞，同時該點蒙版的色彩變?yōu)榘咨@才是對的，不過簡單起見，還是原來那樣就可以了)。

歐拉角是瑞士數(shù)學(xué)家萊昂哈德·歐拉（Leonhard Euler）用來描述剛體在三維空間中取向的方法。簡單來說，就是任何一個物體的取向，都可以用3個有次序的旋轉(zhuǎn)角度來表示。

歐拉在三維空間中定義了一個靜止不動的參考系，即慣性系。還定義了一個運動的坐標(biāo)系，即物體坐標(biāo)系。慣性系與物體坐標(biāo)系的區(qū)別在于，當(dāng)物體取向發(fā)生改變之后，物體坐標(biāo)系也隨之改變，而慣性系卻不變。

例如，我們認(rèn)為北極星的位置對于地球上的任意觀察點都是不變的，因此可以看作一個靜止的參考系。而基于公路上一輛行駛的汽車的坐標(biāo)系，因為汽車的轉(zhuǎn)彎而不斷改變，是一個物體坐標(biāo)系。

歐拉角的三個旋轉(zhuǎn)是繞物體坐標(biāo)系的三個軸復(fù)合形成。為何不使用慣性系？因為物體坐標(biāo)系在數(shù)學(xué)處理上是簡單的。為了描述一架飛機的取向，定義航偏角為yaw, 俯仰為pitch, 橫滾為roll。假如分別使用矩陣I1, I2, I3來表示這三個角度，那么飛機繞自身先轉(zhuǎn)yaw角，再繞pitch角，最后繞roll角的結(jié)果可用I3*I2*I1來表示。 有關(guān)矩陣，看這里 。

通常來說，一個物體的取向用歐拉角來表示是簡單有效的。但是在某種特殊的情況下，歐拉角將失效，形成所謂的“萬向節(jié)死鎖”。

一個簡單直觀的例子是炮塔模型。假設(shè)地面上的一個炮塔有兩個旋轉(zhuǎn)軸：Y垂直于地面，使炮塔可以平行地面360度旋轉(zhuǎn)（正北設(shè)為0度）；X平行于地面，使炮口可以繞著它上下90度旋轉(zhuǎn)（平行地面使設(shè)為0度）。現(xiàn)在，天空中的任意一點就可以使用兩個坐標(biāo)的度數(shù)來表示了！

這時，一架敵機從正東面飛來，我們轉(zhuǎn)動炮塔對準(zhǔn)它，目前的坐標(biāo)是（10,90）。因為飛機飛行方向不變，所以Y固定為90，而X由于飛機距離的接近而增大。當(dāng)飛機恰好飛到炮塔頂端時，即X的角度也達(dá)到90度時，飛機忽然向南飛行！我們必須立即改變炮塔朝向，否則即將都丟失目標(biāo)。但是我們發(fā)現(xiàn)，無論是轉(zhuǎn)動X軸還是Y軸，我們都無法讓炮塔轉(zhuǎn)向南方了，即炮塔在此時丟失了一個自由度！

為什么不把Y轉(zhuǎn)動到180度的位置繼續(xù)跟蹤呢？注意此時炮塔的狀態(tài): 炮口已經(jīng)對準(zhǔn)炮臺的正上方, 平行于Y軸，無論Y軸怎樣轉(zhuǎn)動，炮口都改變不了朝向的, 即炮臺的物體坐標(biāo)系不會變化了。能轉(zhuǎn)動的只有X軸，但是這樣一來，炮口又回到東面了。

歐拉角的萬向節(jié)死鎖就是這樣：我們依次繞物體坐標(biāo)系的X軸、Y軸、Z軸旋轉(zhuǎn)，當(dāng)Y軸旋轉(zhuǎn)了90度之后，Z就會指向原來的X軸。這樣一來，我們事實上只繞了X軸和Y軸兩個軸旋轉(zhuǎn)，第三根軸的自由度就丟失了！(值得指出的是，我們在描述的時候使用的是世界坐標(biāo)系的x, y, z軸，但是旋轉(zhuǎn)的時候卻是使用繞物體的)

萬向鎖的一個有趣實驗是當(dāng)先把飛機Yaw 45度，再Pitch 90度，與先Pitch 90度，再Roll 45度的結(jié)果完全相同。 這個現(xiàn)象也叫歐拉角的別名現(xiàn)象（同一個慣性系下同一個值有不同的表示方法），這也是很糟糕的。

正因為歐拉角在三維空間中有死鎖的問題，所以科學(xué)家尋找了新的表示空間取向的方法。以后再詳細(xì)說明。

理解：萬向節(jié)死鎖是由于旋轉(zhuǎn)后產(chǎn)生自由度丟失而產(chǎn)生的問題。解決辦法是通過四元數(shù)

像素格式解析

　　像素格式描述了像素數(shù)據(jù)存儲所用的格式。定義了像素在內(nèi)存中的編碼方式。下面的像素格式 (PF_*) 類型定義了：
 

　　本地格式 (PF_A8R8G8B8 以及其他大量的不同的類型)

　　這意味著在內(nèi)存中使用了本地儲存方式（big endian或者little endian，包括16，24，，32位）的整形數(shù)據(jù)。同時意味著可以把PF_A8R8G8B8格式的圖片看作一個32位的整形數(shù)組，在16進(jìn)制表現(xiàn)為0xAARRGGBB。這些字母的意義我們在稍后會提供
      （由于CPU的不同，整形的存儲形式不同。直接寫內(nèi)存的時候需要注意）。

　　位組格式Byte formats(PF_BYTE_*)

　　在這種格式下每個通道對應(yīng)一個byte，通道在內(nèi)存理的組織方式和格式名稱定義的相同。例如PF_BYTE_RGBA格式的像素包含了四個byte，一個對應(yīng)紅色，一個綠色，一個藍(lán)色，以及一個alpha通道。

　　Short格式(PF_SHORT_*)

　　在這種格式下每個通道對應(yīng)一個unsigned short數(shù)據(jù)(16 bit整形)，通道在內(nèi)存理的組織方式和格式名稱定義的相同。例如PF_BYTE_RGBA格式的像素包含了四個unsigned short數(shù)據(jù)，一個對應(yīng)紅色，一個綠色，一個藍(lán)色，以及一個alpha通道。

　　Float16 格式(PF_FLOAT16_*)

　　在這種格式下每個通道對應(yīng)一個16 bit浮點數(shù)，通道在內(nèi)存理的組織方式和格式名稱定義的相同。例如PF_BYTE_RGBA格式的像素包含了四個16 bit浮點數(shù)數(shù)據(jù)，一個對應(yīng)紅色，一個綠色，一個藍(lán)色，以及一個alpha通道。16 bit浮點數(shù)也被稱為半浮點（half float），非常類似于IEEE 對32bit單精度浮點數(shù)標(biāo)準(zhǔn)，只不過它只有5個exponent位和10個mantissa位而已。值得注意，這并不是一個標(biāo)準(zhǔn)的C++數(shù)據(jù)，CPU對其支持也不夠好，不過GPU卻能如同處理32bit浮點數(shù)一樣高效的處理它。

　　Float32格式(PF_FLOAT32_*)

　　在這種格式下每個通道對應(yīng)一個32 bit浮點數(shù)，通道在內(nèi)存理的組織方式和格式名稱定義的相同。例如PF_BYTE_RGBA格式的像素包含了四個32 bit浮點數(shù)數(shù)據(jù)，一個對應(yīng)紅色，一個綠色，一個藍(lán)色，以及一個alpha通道。再C++中，這個數(shù)據(jù)就是普通的float。just “float”。

壓縮格式formats (PF_DXT[1-5])

S3TC壓縮紋理格式。

顏色通道介紹

　　顏色通道中R,G,B,A,L 以及 X 的意義是：

　　R

　　紅色成分，通常范圍從0.0（沒有紅色）到1.0（全部的紅色）。

　　G

　　綠色成分，通常范圍從0.0（沒有綠色）到1.0（全部的綠色）。

　　B

　　藍(lán)色成分，通常范圍從0.0（沒有藍(lán)色）到1.0（全部的藍(lán)色）。

　　A

　　alpha（不透明度）成分，通常范圍從0.0（完全透明）到1.0（不透明）。

　　L

　　亮度成分，通常范圍從0.0（黑暗）到1.0（全白）。最終這個成分會被分散到RGB每個中完成最終的圖像效果。

　　X

　　這個是被系統(tǒng)忽略的成分。

　　對于RGBL通道來說，默認(rèn)的情況下設(shè)置為0。而Alpha通道卻不同，在默認(rèn)的情況下被設(shè)定為1，代表不透明。

******************************************************************************************

全部像素格式

　　當(dāng)前版本的Ogre支持下列像素格式：

　　位組格式

　　PF_BYTE_RGB, PF_BYTE_BGR, PF_BYTE_BGRA, PF_BYTE_RGBA, PF_BYTE_L, PF_BYTE_LA, PF_BYTE_A

　　Short格式

　　PF_SHORT_RGBA

　　Float16 格式

　　PF_FLOAT16_R, PF_FLOAT16_RGB, PF_FLOAT16_RGBA

　　Float32 格式

　　PF_FLOAT32_R, PF_FLOAT32_RGB, PF_FLOAT32_RGBA

　　8 bit 本地格式

　　PF_L8, PF_A8, PF_A4L4, PF_R3G3B2

　　16 bit 本地格式 '

　　PF_L16, PF_R5G6B5, PF_B5G6R5, PF_A4R4G4B4, PF_A1R5G5B5

　　24 bit 本地格式

　　PF_R8G8B8, PF_B8G8R8

　　32 bit 本地格式

　　PF_A8R8G8B8, PF_A8B8G8R8, PF_B8G8R8A8, PF_R8G8B8A8, PF_X8R8G8B8, PF_X8B8G8R8, PF_A2R10G10B10 PF_A2B10G10R10

　　壓縮格式

　　PF_DXT1, PF_DXT2, PF_DXT3, PF_DXT4, PF_DXT5

******************************************************************************************

像素格式管理

　　1、Windows下的調(diào)色板

　　OpenGL可以使用16色、256色、64K和16M真彩色。真彩模式下不需要調(diào)色板，而在16色模式下根本不可能得到較為滿意的效果，因此對OpenGL而言，調(diào)色板只有在256色模式下才有意義。

　　我們知道，Windows把調(diào)色板分為系統(tǒng)調(diào)色板和邏輯調(diào)色板。每個應(yīng)用程序都擁有一套自己的邏輯調(diào)色板（或使用缺省調(diào)色板），當(dāng)該應(yīng)用程序擁有鍵盤輸入焦點時可以最多使用從16M種色彩中選取的256種顏色（20種系統(tǒng)保留顏色和236種自由選取的顏色），而失去焦點的應(yīng)用程序可能會有某些顏色顯示不正常。系統(tǒng)調(diào)色板由Windows內(nèi)核來管理，它是由系統(tǒng)保留的20種顏色和經(jīng)仲裁后各個應(yīng)用程序設(shè)置的顏色組成，并與硬件的256個調(diào)色板相對應(yīng)。應(yīng)用程序的邏輯調(diào)色板與硬件的調(diào)色板沒有直接的對應(yīng)關(guān)系，而是按照最小誤差的原則映射到系統(tǒng)調(diào)色板中，因此即使應(yīng)用程序自由選取256種不同顏色構(gòu)成自己的邏輯調(diào)色板，也有可能某些顏色顯示到屏幕上時是一樣的。

　　當(dāng)應(yīng)用程序的窗口接收到鍵盤輸入焦點時，Windows會向它發(fā)送一條WM_QUERYNEWPALETTE消息，讓它設(shè)置自己的邏輯調(diào)色板，此時Windows會在系統(tǒng)調(diào)色板中盡量多地加入該應(yīng)用程序需要的顏色，并生成相應(yīng)的映射關(guān)系。接著Windows會向系統(tǒng)中所有的覆蓋型窗口和頂級窗口（包括擁有鍵盤輸入焦點的窗口）發(fā)送一條WM_PALETTECHANGED消息，讓它們設(shè)置邏輯調(diào)色板和重繪客戶區(qū)，以便能更充分地利用系統(tǒng)調(diào)色板，已擁有鍵盤輸入焦點的窗口不應(yīng)再處理這條消息，以避免出現(xiàn)死循環(huán)。

　　2、OpenGL的顏色表示與轉(zhuǎn)換

　　OpenGL內(nèi)部用浮點數(shù)來表示和處理顏色，紅綠藍(lán)和Alpha值這四種成份每種的最大值為1.0，最小值為0.0。在256色模式下，OpenGL把一個像素顏色的內(nèi)部值按線性關(guān)系轉(zhuǎn)換為8比特（Bit）來輸出到屏幕上，其中紅色占最低位的3比特，綠色占中間的3比特，藍(lán)色占最高位的2比特，Windows將這個8比特值看作邏輯調(diào)色板的索引值。例如OpenGL的顏色值（1.0，0.14，0.6667）經(jīng)過轉(zhuǎn)換后二進(jìn)制值為10001111（紅色為111，綠色為001，藍(lán)色為10），即第143號調(diào)色板，該調(diào)色板指定的顏色的RGB值應(yīng)與（1.0，0.14，0.6667）有相同的比率，為（255，36，170），如果不是該值，那么顯示出來的顏色就會有誤差。

　　3、調(diào)色板的生成算法

　　很明顯，OpenGL輸出的8比特值中直接表明了顏色的組成，為了使圖形顯示正常，我們應(yīng)以線性關(guān)系來設(shè)置邏輯調(diào)色板，使其索引值直接表明顏色的組成。因此生成調(diào)色板時，把索引值從低位到高位分成3-3-2共三個部分，將每一部分映射到0-255中去，這樣3比特映射為｛0，36，73，109，146，182，219，255｝，2比特映射為｛0，85，170，255｝，最后把三部分組合起來成為一種顏色。

　　經(jīng)過上面的處理后，256種顏色均勻分布在顏色空間中，并沒有完全包含系統(tǒng)保留的20種顏色（只包含了7種），這意味著將會有數(shù)種顏色顯示成一樣，從而影響效果。一個較好的解決辦法是按照最小均方誤差的原則把13種系統(tǒng)顏色納入到邏輯調(diào)色板中。

　　從原理上來說，并非一定要使用線性映射，還可以用其它一些映射關(guān)系，如加入Gamma校正以便更能符合人眼的視覺特性，不過這些映射關(guān)系應(yīng)用得并不廣泛，在此不再討論。

　　像素格式設(shè)置

　　像素格式是OpenGL窗口的重要屬性，它包括是否使用雙緩沖，顏色位數(shù)和類型以及深度位數(shù)等。像素格式可由Windows系統(tǒng)定義的所謂像素格式描述子結(jié)構(gòu)來定義（PIXELFORMATDESCRIPTOR），該結(jié)構(gòu)定義在windows.h中。

　　在該結(jié)構(gòu)中包含有26個屬性信息，其形式為：

　　typedef struct tagPIXELFORMATDESCRIPTOR

　　{

　　WORD nSize;

　　WORD nVersion;

　　DWORD dwFlags;

　　BYTE iPixelType;

　　BYTE cColorBits;

　　BYTE cRedBits;

　　BYTE cRedShift;

　　BYTE cGreenBits;

　　BYTE cGreenShift;

　　BYTE cBlueBits;

　　BYTE cBlueShift;

　　BYTE cAlphaBits;

　　BYTE cAlphaShift;

　　BYTE cAccumBits;

　　BYTE cAccumRedBits;

　　BYTE cAccumGreenBits;

　　BYTE cAccumBlueBits;

　　BYTE cAccumAlphaBits;

　　BYTE cDepthBits;

　　BYTE cStencilBits;

　　BYTE cAuxBuffers;

　　BYTE iLayerType;

　　BYTE bReserved;

　　DWORD dwLayerMask;

　　DWORD dwVisibleMask;

　　DWORD dwDamageMask;

　　} PIXELFORMATDESCRIPTOR;

　　各變量的含義如下：

　　nSize：該結(jié)構(gòu)所占內(nèi)存空間。

　　nVersion：版本號，當(dāng)前為1。

　　dwFlags：指定像素格式屬性，可選參量如表1.1所示。

　　 像素格式屬性

　　標(biāo)識符 解釋

　　PFD_DRAW_TO_BITMAP 支持內(nèi)存中繪制位圖

　　PFD_DRAW_TO_WINDOW 支持屏幕繪圖

　　PFD_DOUBLEBUFFER 支持雙緩沖

　　PFD_CENERIC_FORMAT 指定選擇GDI支持的像素格式

　　PFD_NEED_PALETTE 指定需要邏輯調(diào)色板

　　PFD_NEED_SYSTEM_PALETTE 指定需要硬件調(diào)色板

　　PFD_STEREO NT不支持

　　PFD_SUPPORT_OPENGL 支持OpenGL

　　PFD_SUPPORT_GDI 支持GDI，此時不可使用PFD_DOUBLEBUFFER

　　iPixelType：像素顏色模式，可選項為PFD_TYPE_RGBA或PFD_TYPE_INDEX，分別對應(yīng)于RGBA模式和顏色索引模式。

　　cColorBits：指定顏色的位數(shù)。

　　cRedBits：采用RGBA模式時，紅色組分占用位數(shù)。

　　cRedShift：采用RGBA模式時，紅色組分偏移量。

　　cGreenBits：采用RGBA模式時，綠色組分占用位數(shù)。

　　cGreenShift：采用RGBA模式時，綠色組分偏移量。

　　cBlueBits：采用RGBA模式時，藍(lán)色組分占用位數(shù)。

　　cBlueShift: 采用RGBA模式時，藍(lán)色組分偏移量。

　　cAlphaBits：采用RGBA模式時，Alpha組分占用位數(shù)。

　　cAlphaShift：采用RGBA模式時，Alpha組分偏移量。

　　cAccumBits：指定累積緩沖區(qū)表示一個像素所用位數(shù)。

　　cAccumRedBits：指定累積緩沖區(qū)表示紅色組分占用位數(shù)。

　　cAccumGreenBits：指定累積緩沖區(qū)表示綠色組分占用位數(shù)。

　　cAccumBlueBits：指定累積緩沖區(qū)表示藍(lán)色組分占用位數(shù)。

　　cAccumAlphaBits：指定累積緩沖區(qū)表示Alpha組分占用位數(shù)。

　　cDepthBits：指定深度緩沖區(qū)表示一個像素所用位數(shù)。

　　cStencilBits：指定模板緩沖區(qū)表示一個像素所用位數(shù)。

　　cAuxBuffers：指定輔助緩沖區(qū)，Windows9x、NT不支持。

　　iLayerType：Windows9x、NT下只能是PFD_MAIN_PLANE。

　　bReserved：＝0。

　　dwLayerMask：指定覆蓋層的屏蔽，Windows9x、NT不支持。

　　dwVisibleMask：Windows9x、NT不支持。

　　dwDamageMask：Windows9x、NT不支持。

　　Windows提供了四個像素格式管理函數(shù)，分別介紹如下：

　　（1） int ChoosePixelFormat(HDC hdc,

　　PIXELFORMATDESCRIPTOR *ppdf)

　　該函數(shù)比較傳過來的像素格式描述和OpenGL支持的像素格式，返回一個最佳匹配的像素格式索引。該索引值可傳給SetPixelFormat為DC設(shè)置像素格式。返回值為0表示失敗。

　　在比較像素格式時，匹配優(yōu)先級順序為像素格式描述子結(jié)構(gòu)中的下述各域：

　　dwFlags－>cColorBits－>cAlphaBits－>cAccumBits

　　－>cDepthBits－>cStencilBits－>cAuxBuffers－>iLayerType

　　硬件支持的像素格式優(yōu)先。

　　（2） int DescribePixelFormat(HDC hdc, int iPixelFormat, UINT nBytes,

　　LPPIXELFORMATDESCRIPTOR *ppfd)

　　該函數(shù)用格式索引iPixelFormat說明的像素格式來填寫由ppfd所指向的像素格式描述子結(jié)構(gòu)，利用該函數(shù)可以枚舉像素格式。

　　（3） int GetPixelFormat(HDC hdc)

　　該函數(shù)用于獲取hdc的格式索引。

　　（4） BOOL SetPixelFormat(HDC hdc, int iPixelFormat,

　　LPPIXELFORMATDESCRIPTOR *ppfd)

　　該函數(shù)用格式索引iPixelFormat來設(shè)置hdc的像素格式。在使用該函數(shù)之前應(yīng)該調(diào)用ChoosePixelFormat來獲取像素格式索引。另外，OpenGL窗口風(fēng)格必須包含WS_CLIPCHILDREN和WS_CLIPSIBLINGS類型，否則設(shè)置失敗。

　　應(yīng)該注意的是ChoosePixelFormat函數(shù)并不一定返回一個最佳的像素格式值，可以利用DescribePixelFormat來枚舉系統(tǒng)所支持的所有像素格式。OpenGL的通常支持24種不同的像素格式，如果系統(tǒng)安裝了OpenGL硬件加速器，它可能會支持其它的像素格式。

像素格式筆記

　　NUKE:

　　nuke的圖像數(shù)據(jù)保存在channel中，我們只需要用到其中的r,g,b三個channel。這三個channel是相互獨立的，可以分別從中讀取數(shù)據(jù)，每一次可以讀取圖像的一行像素。這樣看來，最合理的線性存儲方式就是每個channel的數(shù)據(jù)作為一組來保存，即：RRRR...RRRRGGGG...GGGGBBBB...BBBB的形似。

　　FFMPEG:

　　ffmpeg支持的編碼比較多，如果按照像素格式來分，主要有兩類，一類是是RGB，另一類是YUV。對于影像類編碼，比如xvid/mpeg4之類，顏色模式只能是YUV，甚至僅僅支持yuv420p這一種。因為要考慮到與nuke相結(jié)合，這里只看rgb像素格式中的rgb24。rgb24的線性格式為:RRRR...RRRRGGGG...GGGGBBBB...BBBB，可以很方便的和nuke中的channel數(shù)據(jù)結(jié)合。

　　ffmpeg提供了一個函數(shù)可以在各種像素格式之間轉(zhuǎn)換。yuv420p的Cr和Cb分量只有Y分量大小的一半，因此需要的空間只有rgb24的2/3。

　　libquicktime:

　　libquicktime中沒有與上面RGB24一致的原始rgb格式，有一種rgb888格式。其線性格式為:RGBRGBRGB...。libquicktime在保存幀的時候也要先將rgb轉(zhuǎn)換為yuv，不過這個過程是自動完成的。

　　從rgb24到rgb888的轉(zhuǎn)換：

　　pFrameBufferLinear[y*w*3+3*x] = pFrameRGB_r[Y*w+i]; //R

　　pFrameBufferLinear[y*w*3+3*x+1] = pFrameRGB_g[Y*w+i]; //G

　　pFrameBufferLinear[y*w*3+3*x+2] = pFrameRGB_b[Y*w+i]; //B

WPF圖像像素格式

　　在WPF中，圖像的像素格式較之于GDI+中有不少變化。比如新增了CMYK印刷通道的支持，對灰度圖片的灰階支持也有長足的進(jìn)步，在顏色空間方面，新增了scRGB顏色空間，使圖像的色彩處理能力有很大的提高。

　　為了方便加深了解，我將它們按格式性質(zhì)和色彩空間大致進(jìn)行了分類。比如將Gray類的放在一起，將Index類的又放在一起....

　　(1) BlackWhite：

　　用于顯示黑白兩種色值的像素格式（非黑即白）。

　　(2) Gray2：

　　2BPP（Bits Per Pixel，位/像素）的灰色通道。允許四種灰階。

　　(3) Gray4：

　　4BPP的灰度通道，允許16種灰階值表示灰色。

　　(4) Gray8：

　　顯示8BPP的灰度通道，允許256種灰階值表示灰色。

　　(5) Gray16：

　　16BPP的灰色通道，最多允許65536種灰階值表示灰色。這種格式的Gamma是1.0。

　　(6) Gray32Float：

　　32BPP的灰度通道，允許超過40億灰階。此格式的Gamma值是1.0。

　　(7) Indexed1：

　　指定2種顏色作為調(diào)色板的像素格式。

　　(8) Indexed2：

　　指定4種顏色作為調(diào)色板的像素格式。

　　(9) Indexed4：

　　指定16種顏色作為調(diào)色板的像素格式。

　　(10) Indexed8：

　　指定256種顏色作為調(diào)色板的像素格式。

　　(11) Bgr24：

　　Bgr24像素格式是一種采用24BPP的sRGB格式。每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)各占8BPP（位/像素）。

　　(12) Bgra32：

　　Bgra32像素格式是一種32BPP的sRGB格式。每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)各占8BPP（位/像素），與Bgr24不同的是，它還有用于表現(xiàn)不透明度的alpha通道（8BPP）。

　　(13) Bgr101010：

　　Bgr101010像素格式是一種采用32BPP（位/像素）的sRGB格式。每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)各占10BPP（位/像素）。

　　(14) Bgr32：

　　Bgr32像素格式是一種采用32BPP（位/像素）的sRGB格式。與Bgr101010格式不同的是，它的每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)各占8BPP（位/像素）。

　　(15) Bgr555：

　　Bgr555也是一種sRGB格式，它采用16BPP（位/像素）. 它的每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)各占5BPP（位/像素）。

　　(16) Bgr565：

　　Bgr565像素格式是一種16BPP（位/像素）的sRGB格式。它的每個顏色通道（藍(lán)色blue, 綠色green, 紅色red)分別占5BPP，6BPP，5BPP（位/像素）。

　　(17) Pbgra32：

　　采用32BPP的一種基于sRGB的像素格式。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red，Alpha通道)各占8BPP（位/像素）。每種顏色通道是經(jīng)過與Alpha值預(yù)處理之后的。

　　(18) Prgba64：

　　是一種基于sRGB格式，采用64BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red，Alpha通道)各占32BPP（位/像素）。每種顏色通道是經(jīng)過與Alpha值預(yù)處理之后的。這種格式的Gamma是1.0。

　　(19) Rgb24：

　　是一種基于sRGB格式，采用24BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red)各占8BPP（位/像素）。

　　(20) Rgb48：

　　是一種基于sRGB格式，采用48BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red)各占16BPP（位/像素）。這種格式的Gamma是1.0。

　　(21) Rgba64：

　　是一種基于sRGB格式，采用64BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red，Alpha通道)各占16BPP（位/像素）。這種格式的Gamma是1.0。

　　(22) Rgb128Float：

　　是一種基于ScRGB格式，采用128BPP。每個顏色通道各占32BPP（位/像素）。這種格式的Gamma是1.0。

　　(23) Rgba128Float：

　　是一種基于ScRGB格式，采用128BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red，Alpha通道)各占32BPP（位/像素）。這種格式的Gamma是1.0。

　　(24) Prgba128Float：

　　是一種基于ScRGB格式，采用128BPP。每個顏色通道(藍(lán)色blue, 綠色green, 紅色red，Alpha通道)各占32BPP（位/像素）。每種顏色通道是經(jīng)過與Alpha值預(yù)處理之后的。這種格式的Gamma是1.0。

　　(25) Cmyk32：

　　用于表現(xiàn)印刷色格式，采用32BPP，共四個顏色通道即C、M、Y、K（青色Cyan, 品紅Magenta, 黃色Yellow和黑色blacK)，各占8PP。

OpenGL窗口渲染

　　表述像素格式：PIXELFORMATDESCRIPTOR

　　在OpenGL對窗口渲染之前，必須根據(jù)渲染需要對窗口進(jìn)行配置。

　　需要硬件渲染還是軟件渲染？

　　渲染使用單緩沖還是雙緩沖？

　　是否需要深度緩沖區(qū)？

　　是否需要模板、目標(biāo)Alpha或積累緩沖區(qū)？

　　當(dāng)為窗口設(shè)置這些參數(shù)之后，就無法對它們進(jìn)行修改。為了從一個只有深度緩沖和顏色緩沖區(qū)的窗口切換到一個帶有模板緩沖區(qū)的窗口，必須首先銷毀第一個窗口，然后根據(jù)需要重新創(chuàng)建一個窗口。

　　說明：

　　在OpenGL對窗口渲染之前，必須根據(jù)渲染需要對窗口進(jìn)行配置。

　　需要硬件渲染還是軟件渲染？

　　渲染使用單緩沖還是雙緩沖？

　　是否需要深度緩沖區(qū)？

　　是否需要模板、目標(biāo)Alpha或積累緩沖區(qū)？

　　當(dāng)為窗口設(shè)置這些參數(shù)之后，就無法對它們進(jìn)行修改。為了從一個只有深度緩沖和顏色緩沖區(qū)的窗口切換到一個帶有模板緩沖區(qū)的窗口，必須首先銷毀第一個窗口，然后根據(jù)需要重新創(chuàng)建一個窗口。

　　[ OpenGL]

　　PIXELFORMATDESCRIPTOR

　　The PIXELFORMATDESCRIPTOR structure describes the pixel format of a drawing surface.

　　typedef struct tagPIXELFORMATDESCRIPTOR

　　{ // pfd

　　WORD nSize; //結(jié)構(gòu)大小： sizeof(PIXELFORMATDISCRIPTOR)

　　WORD nVersion; //版本：總設(shè)置為1

　　DWORD dwFlags; //像素緩沖區(qū)的屬性標(biāo)記

　　BYTE iPixelType; //像素數(shù)據(jù)的類型

　　BYTE cColorBits; //顏色緩沖區(qū)中位平面的數(shù)量

　　BYTE cRedBits; //用多少位表示紅色

　　BYTE cRedShift; //紅色位的移位計數(shù)

　　BYTE cGreenBits; //

　　BYTE cGreenShift; //

　　BYTE cBlueBits; //

　　BYTE cBlueShift; //

　　BYTE cAlphaBits; //

　　BYTE cAlphaShift; //

　　BYTE cAccumBits; //積累緩沖區(qū)位數(shù)

　　BYTE cAccumRedBits; //積累緩沖區(qū)中紅色的位數(shù)

　　BYTE cAccumGreenBits;

　　BYTE cAccumBlueBits;

　　BYTE cAccumAlphaBits;

　　BYTE cDepthBits; //深度緩沖區(qū)位數(shù)

　　BYTE cStencilBits; //模板緩沖區(qū)位數(shù)

　　BYTE cAuxBuffers; //多少個輔助緩沖區(qū)

　　BYTE iLayerType; //過時或忽略

　　BYTE bReserved; //上層或下層平面的數(shù)量

　　DWORD dwLayerMask; //過時或忽略

　　DWORD dwVisibleMask; //下平面的透明顏色

　　DWORD dwDamageMask; //過時或忽略

　　} PIXELFORMATDESCRIPTOR;

　　//************************************************************************

　　//設(shè)置窗口像素格式

　　//************************************************************************

　　GLuint PixelFormat; // Holds The Results After Searching For A Match

　　static PIXELFORMATDESCRIPTOR pfd= // pfd Tells Windows How We Want Things To Be

　　{

　　sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor

　　1, // Version Number

　　PFD_DRAW_TO_WINDOW | // Format Must Support Window

　　PFD_SUPPORT_OPENGL | // Format Must Support OpenGL

　　PFD_DOUBLEBUFFER, // Must Support Double Buffering

　　PFD_TYPE_RGBA, // Request An RGBA Format

　　32, // Select Our Color Depth

　　0, 0, 0, 0, 0, 0, // Color Bits Ignored

　　0, // No Alpha Buffer

　　0, // Shift Bit Ignored

　　0, // No Accumulation Buffer

　　0, 0, 0, 0, // Accumulation Bits Ignored

　　16, // 16Bit Z-Buffer (Depth Buffer)

　　1, // No Stencil Buffer

　　0, // No Auxiliary Buffer

　　PFD_MAIN_PLANE, // Main Drawing Layer

　　0, // Reserved

　　0, 0, 0 // Layer Masks Ignored

　　};

　　if (!PixelFormat=ChoosePixelFormat(m_hDC,&pfd))) // Did Windows Find A Matching Pixel Format?

　　{

　　MessageBox("Can't Find A Suitable PixelFormat.","ERROR",MB_OK|MB_ICONEXCLAMATION);

　　return FALSE; // Return FALSE

　　}

　　if(!SetPixelFormat(m_hDC,PixelFormat,&pfd)) // Are We Able To Set The Pixel Format?

　　{

　　MessageBox("Can't Set The PixelFormat.","ERROR",MB_OK|MB_ICONEXCLAMATION);

　　return FALSE; // Return FALSE

　　}