構件詳解
1. 位圖文件頭
位圖文件頭包含有關于文件類型、文件大小、存放位置等信息,在Windows 3.0以上版本的位圖文件中用BITMAPFILEHEADER結構來定義:
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中:
bfType
|
說明文件的類型.(該值必需是0x4D42,也就是字符’BM’。我們不需要判斷OS/2的位圖標識,這么做現在來看似乎已經沒有什么意義了,而且如果要支持OS/2的位圖,程序將變得很繁瑣。所以,在此只建議你檢察’BM’標識)
|
bfSize
|
說明文件的大小,用字節為單位
|
bfReserved1
|
保留,必須設置為0
|
bfReserved2
|
保留,必須設置為0
|
bfOffBits
|
說明從文件頭開始到實際的圖象數據之間的字節的偏移量。這個參數是非常有用的,因為位圖信息頭和調色板的長度會根據不同情況而變化,所以你可以用這個偏移值迅速的從文件中讀取到位數據。
|
2. 位圖信息頭
位圖信息用BITMAPINFO結構來定義,它由位圖信息頭(bitmap-information header)和彩色表(color table)組成,前者用BITMAPINFOHEADER結構定義,后者用RGBQUAD結構定義。BITMAPINFO結構具有如下形式:
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
其中:
bmiHeader
|
說明BITMAPINFOHEADER結構,其中包含了有關位圖的尺寸及位格式等信息
|
bmiColors
|
說明彩色表RGBQUAD結構的陣列,其中包含索引圖像的真實RGB值。
|
BITMAPINFOHEADER結構包含有位圖文件的大小、壓縮類型和顏色格式,其結構定義為:
typedef struct tagBITMAPINFOHEADER { /* bmih */
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
其中:
biSize
|
說明BITMAPINFOHEADER結構所需要的字數。注:這個值并不一定是BITMAPINFOHEADER結構的尺寸,它也可能是sizeof(BITMAPV4HEADER)的值,或是sizeof(BITMAPV5HEADER)的值。這要根據該位圖文件的格式版本來決定,不過,就現在的情況來看,絕大多數的BMP圖像都是BITMAPINFOHEADER結構的(可能是后兩者太新的緣故吧:-)。
|
biWidth
|
說明圖象的寬度,以象素為單位
|
biHeight
|
說明圖象的高度,以象素為單位。注:這個值除了用于描述圖像的高度之外,它還有另一個用處,就是指明該圖像是倒向的位圖,還是正向的位圖。如果該值是一個正數,說明圖像是倒向的,如果該值是一個負數,則說明圖像是正向的。大多數的BMP文件都是倒向的位圖,也就是時,高度值是一個正數。(注:當高度值是一個負數時(正向圖像),圖像將不能被壓縮(也就是說biCompression成員將不能是BI_RLE8或BI_RLE4)。
|
biPlanes
|
為目標設備說明位面數,其值將總是被設為1
|
biBitCount
|
說明比特數/象素,其值為1、4、8、16、24、或32
|
biCompression
|
說明圖象數據壓縮的類型。其值可以是下述值之一:
|
BI_RGB:沒有壓縮;
|
|
BI_RLE8:每個象素8比特的RLE壓縮編碼,壓縮格式由2字節組成(重復象素計數和顏色索引);
|
|
BI_RLE4:每個象素4比特的RLE壓縮編碼,壓縮格式由2字節組成
|
|
BI_BITFIELDS:每個象素的比特由指定的掩碼決定。
|
|
biSizeImage
|
說明圖象的大小,以字節為單位。當用BI_RGB格式時,可設置為0 |
biXPelsPerMeter
|
說明水平分辨率,用象素/米表示 |
biYPelsPerMeter
|
說明垂直分辨率,用象素/米表示 |
biClrUsed
|
說明位圖實際使用的彩色表中的顏色索引數(設為0的話,則說明使用所有調色板項) |
biClrImportant
|
說明對圖象顯示有重要影響的顏色索引的數目,如果是0,表示都重要。
|
現就BITMAPINFOHEADER結構作如下說明:
(1) 彩色表的定位
應用程序可使用存儲在biSize成員中的信息來查找在BITMAPINFO結構中的彩色表,如下所示:
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount=1 表示位圖最多有兩種顏色,缺省情況下是黑色和白色,你也可以自己定義這兩種顏色。圖像信息頭裝調色板中將有兩個調色板項,稱為索引0和索引1。圖象數據陣列中的每一位表示一個象素。如果一個位是0,顯示時就使用索引0的RGB值,如果位是1,則使用索引1的RGB值。
biBitCount=4 表示位圖最多有16種顏色。每個象素用4位表示,并用這4位作為彩色表的表項來查找該象素的顏色。例如,如果位圖中的第一個字節為0x1F,它表示有兩個象素,第一象素的顏色就在彩色表的第2表項中查找,而第二個象素的顏色就在彩色表的第16表項中查找。此時,調色板中缺省情況下會有16個RGB項。對應于索引0到索引15。
biBitCount=8 表示位圖最多有256種顏色。每個象素用8位表示,并用這8位作為彩色表的表項來查找該象素的顏色。例如,如果位圖中的第一個字節為0x1F,這個象素的顏色就在彩色表的第32表項中查找。此時,缺省情況下,調色板中會有256個RGB項,對應于索引0到索引255。
biBitCount=16 表示位圖最多有216種顏色。每個色素用16位(2個字節)表示。這種格式叫作高彩色,或叫增強型16位色,或64K色。它的情況比較復雜,當biCompression成員的值是BI_RGB時,它沒有調色板。16位中,最低的5位表示藍色分量,中間的5位表示綠色分量,高的5位表示紅色分量,一共占用了15位,最高的一位保留,設為0。這種格式也被稱作555 16位位圖。如果biCompression成員的值是BI_BITFIELDS,那么情況就復雜了,首先是原來調色板的位置被三個DWORD變量占據,稱為紅、綠、藍掩碼。分別用于描述紅、綠、藍分量在16位中所占的位置。在Windows 95(或98)中,系統可接受兩種格式的位域:555和565,在555格式下,紅、綠、藍的掩碼分別是:0x7C00、0x03E0、0x001F,而在565格式下,它們則分別為:0xF800、0x07E0、0x001F。你在讀取一個像素之后,可以分別用掩碼“與”上像素值,從而提取出想要的顏色分量(當然還要再經過適當的左右移操作)。在NT系統中,則沒有格式限制,只不過要求掩碼之間不能有重疊。(注:這種格式的圖像使用起來是比較麻煩的,不過因為它的顯示效果接近于真彩,而圖像數據又比真彩圖像小的多,所以,它更多的被用于游戲軟件)。
biBitCount=24 表示位圖最多有224種顏色。這種位圖沒有調色板(bmiColors成員尺寸為0),在位數組中,每3個字節代表一個象素,分別對應于顏色R、G、B。
biBitCount=32 表示位圖最多有232種顏色。這種位圖的結構與16位位圖結構非常類似,當biCompression成員的值是BI_RGB時,它也沒有調色板,32位中有24位用于存放RGB值,順序是:最高位—保留,紅8位、綠8位、藍8位。這種格式也被成為888 32位圖。如果 biCompression成員的值是BI_BITFIELDS時,原來調色板的位置將被三個DWORD變量占據,成為紅、綠、藍掩碼,分別用于描述紅、綠、藍分量在32位中所占的位置。在Windows 95(or 98)中,系統只接受888格式,也就是說三個掩碼的值將只能是:0xFF0000、0xFF00、0xFF。而在NT系統中,你只要注意使掩碼之間不產生重疊就行。(注:這種圖像格式比較規整,因為它是DWORD對齊的,所以在內存中進行圖像處理時可進行匯編級的代碼優化(簡單))。
(3) ClrUsed
BITMAPINFOHEADER結構中的成員ClrUsed指定實際使用的顏色數目。如果ClrUsed設置成0,位圖使用的顏色數目就等于biBitCount成員中的數目。請注意,如果ClrUsed的值不是可用顏色的最大值或不是0,則在編程時應該注意調色板尺寸的計算,比如在4位位圖中,調色板的缺省尺寸應該是16*sizeof(RGBQUAD),但是,如果ClrUsed的值不是16或者不是0,那么調色板的尺寸就應該是ClrUsed*sizeof(RGBQUAD)。
(4) 圖象數據壓縮
① BI_RLE8:每個象素為8比特的RLE壓縮編碼,可使用編碼方式和絕對方式中的任何一種進行壓縮,這兩種方式可在同一幅圖中的任何地方使用。
編碼方式:由2個字節組成,第一個字節指定使用相同顏色的象素數目,第二個字節指定使用的顏色索引。此外,這個字節對中的第一個字節可設置為0,聯合使用第二個字節的值表示:
 |
第二個字節的值為0:行的結束。
|
 |
第二個字節的值為1:圖象結束。
|
 |
第二個字節的值為2:其后的兩個字節表示下一個象素從當前開始的水平和垂直位置的偏移量。
|
絕對方式:第一個字節設置為0,而第二個字節設置為0x03~0xFF之間的一個值。在這種方式中,第二個字節表示跟在這個字節后面的字節數,每個字節包含單個象素的顏色索引。壓縮數據格式需要字邊界(word boundary)對齊。下面的例子是用16進制表示的8-位壓縮圖象數據:
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
這些壓縮數據可解釋為 :
壓縮數據
|
擴展數據
|
03 04 |
04 04 04 |
05 06 |
06 06 06 06 06 |
00 03 45 56 67 00 |
45 56 67 |
02 78 |
78 78 |
00 02 05 01 |
從當前位置右移5個位置后向下移一行 |
02 78 |
78 78 |
00 00 |
行結束 |
09 1E |
1E 1E 1E 1E 1E 1E 1E 1E 1E |
00 01 |
RLE編碼圖象結束 |
② BI_RLE4:每個象素為4比特的RLE壓縮編碼,同樣也可使用編碼方式和絕對方式中的任何一種進行壓縮,這兩種方式也可在同一幅圖中的任何地方使用。這兩種方式是:
編碼方式:由2個字節組成,第一個字節指定象素數目,第二個字節包含兩種顏色索引,一個在高4位,另一個在低4位。第一個象素使用高4位的顏色索引,第二個使用低4位的顏色索引,第3個使用高4位的顏色索引,依此類推。
絕對方式:這個字節對中的第一個字節設置為0,第二個字節包含有顏色索引數,其后續字節包含有顏色索引,顏色索引存放在該字節的高、低4位中,一個顏色索引對應一個象素。此外,BI_RLE4也同樣聯合使用第二個字節中的值表示:
 |
第二個字節的值為0:行的結束。
|
 |
第二個字節的值為1:圖象結束。
|
 |
第二個字節的值為2:其后的兩個字節表示下一個象素從當前開始的水平和垂直位置的偏移量。
|
下面的例子是用16進制數表示的4-位壓縮圖象數據:
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
這些壓縮數據可解釋為 :
壓縮數據
|
擴展數據
|
03 04 |
0 4 0 |
05 06 |
0 6 0 6 0 |
00 06 45 56 67 00 |
4 5 5 6 6 7 |
04 78 |
7 8 7 8 |
00 02 05 01 |
從當前位置右移5個位置后向下移一行 |
04 78 |
7 8 7 8 |
00 00 |
行結束 |
09 1E |
1 E 1 E 1 E 1 E 1 |
00 01 |
RLE圖象結束 |
3. 彩色表
彩色表包含的元素與位圖所具有的顏色數相同,象素的顏色用RGBQUAD結構來定義。對于24-位真彩色圖象就不使用彩色表(同樣也包括16位、和32位位圖),因為位圖中的RGB值就代表了每個象素難丈 2噬 碇械難丈 囪丈 鬧匾 耘判潁 飪梢愿ㄖ 允廄 絳蛭 荒芟允咀愎歡嘌丈 南允舊璞趕允靜噬 枷蟆 GBQUAD結構描述由R、G、B相對強度組成的顏色,定義如下:
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
其中:
rgbBlue
|
指定藍色強度
|
rgbGreen
|
指定綠色強度
|
rgbRed
|
指定紅色強度
|
rgbReserved
|
保留,設置為0
|
4. 位圖數據
緊跟在彩色表之后的是圖象數據字節陣列。圖象的每一掃描行由表示圖象象素的連續的字節組成,每一行的字節數取決于圖象的顏色數目和用象素表示的圖象寬度。掃描行是由底向上存儲的,這就是說,陣列中的第一個字節表示位圖左下角的象素,而最后一個字節表示位圖右上角的象素。(只針對與倒向DIB,如果是正向DIB,則掃描行是由頂向下存儲的),倒向DIB的原點在圖像的左下角,而正向DIB的原點在圖像的左上角。同時,每一掃描行的字節數必需是4的整倍數,也就是DWORD對齊的。如果你想確保圖像的掃描行DWORD對齊,可使用下面的代碼:
(((width*biBitCount)+31)>>5)<<2