whatifbmpformat

1、BMPBMP文件結(jié)構(gòu)的探索文件結(jié)構(gòu)的探索WhatIf2004910一、文件格式Bmp文件是非常常用的位圖文件，無論是游戲還是其他都被廣泛使用。針對(duì)bmp文件的處理也有一堆現(xiàn)成的api進(jìn)行調(diào)用，然而文件內(nèi)部究竟怎樣，如何自己來解析這樣的文件呢？為了消除無聊，我用了幾天時(shí)間來研究了一下，同時(shí)作為學(xué)習(xí)筆記，進(jìn)行記錄。首先，整個(gè)bmp文件的內(nèi)容可以分為3到4塊。之所以分為3到4塊而不是固定的值，是因?yàn)?，?duì)于bmp來說可能存在調(diào)色板或者一些掩碼。

2、具體稍候討論。第一塊是bmp的文件頭用于描述整個(gè)bmp文件的情況。結(jié)構(gòu)如下：typedefstructtagBITMAPFILEHEADERWDbfTypeDWDbfSizeWDbfReserved1WDbfReserved2DWDbfOffBitsBITMAPFILEHEADERPBITMAPFILEHEADER這些信息相當(dāng)有用，如果你想直接來解析bmp文件。第一個(gè)bfType用于表示文件類型，如果它是bmp文件，那么它這個(gè)位置的值一

3、定是”BM”也就是0x4D42。第二個(gè)bfSize表示整個(gè)文件的字節(jié)數(shù)。第三第四個(gè)則保留，目前無意義，最后一個(gè)相當(dāng)重要，表示，位圖的數(shù)據(jù)信息離文件頭的偏移量，以字節(jié)為單位。第二塊是位圖信息頭，即BITMAPINFOHEADER，用于描述整個(gè)位圖文件的情況。以下挑重要的數(shù)據(jù)進(jìn)行解釋typedefstructtagBITMAPINFOHEADERDWDbiSize表示本結(jié)構(gòu)的大小LONGbiWidth位圖的寬度LONGbiHeight位圖的

4、高度WDbiPlanes永遠(yuǎn)為1由于沒有用過所以沒做研究附msdn解釋Specifiesthenumberofplanesfthetargetdevice.Thisvaluemustbesetto1.WDbiBitCount位圖的位數(shù)分為148162432本文沒對(duì)14進(jìn)行研究DWDbiCompression本以為壓縮類型，但是卻另外有作用，稍候解釋DWDbiSizeImage表示位圖數(shù)據(jù)區(qū)域的大小以字節(jié)為單位LONGbiXPelsPer

5、MeterLONGbiYPelsPerMeterDWDbiClrUsedDWDbiClrImptantBITMAPINFOHEADERPBITMAPINFOHEADER第三塊就是調(diào)色板信息或者掩碼部分，如果是8位位圖則存放調(diào)色板；16與32位位圖則存放RGB顏色的掩碼，這些掩碼以DWD大小來存放。最后一塊就是位圖的數(shù)據(jù)實(shí)體。以上文件信息可以在任意一篇bmp文件結(jié)構(gòu)的文章中找到描述，所以本文只是稍微帶過。Ub=quad[index].rg

6、bBlue16位這是最麻煩的一個(gè)。因?yàn)樵谔幚頃r(shí)有555565兩種格式的區(qū)別，而且還有所謂壓縮類型的區(qū)別。之前的bitmapinfoheader里面提到一個(gè)biCompression現(xiàn)在我們分兩種情況討論：BI_RGB和BI_BITFIELDS當(dāng)他等于BI_RGB時(shí)只有555這種格式，所以可以放心大膽的進(jìn)行如下的數(shù)據(jù)分離：Ub=buffer[(ipitchj)2]Ug=(((buffer[(ipitchj)21]3)(buffer[(ip

7、itchj)2]5)Ur=(buffer[(ipitchj)21]3希望不要被這個(gè)表達(dá)式折磨的眼花繚亂，我想既然你在看這篇文章，你就有能力閱讀這樣的代碼，否則只能說你還沒有到閱讀這方面的地步，需要去學(xué)習(xí)基礎(chǔ)的語法了。有一點(diǎn)值得提醒的是由于有較多的位操作，所以在處理的時(shí)候在前一次操作的上面加上一對(duì)括號(hào)，我就曾經(jīng)因?yàn)闆]有加而導(dǎo)致出現(xiàn)誤差，另外雖然buffer中一個(gè)元素代表的是一個(gè)U但是右移操作會(huì)自動(dòng)增長(zhǎng)為兩字節(jié)所以需要在進(jìn)行一次與操作截取低

8、位的1字節(jié)數(shù)據(jù)。現(xiàn)在討論BI_BITFIELDS。這個(gè)模式下既可以有555也可以有565。555格式xrrrrrgggggbbbbb565格式rrrrrggggggbbbbb顯然不同的格式處理不同，所以我們要首先判斷處到底屬于那種格式。Bitmapinfoheader的biCompression為BI_BITFIELDS時(shí)，在位圖數(shù)據(jù)區(qū)域前存在一個(gè)RGB掩碼的描述是3個(gè)DWD值，我們只需要讀取其中的R或者G的掩碼，來判斷是那種格式。以紅

9、色掩碼為例0111110000000000的時(shí)候就是555格式1111100000000000就是565格式。以下是565格式時(shí)的數(shù)據(jù)分離：Ub=buffer[(ipitchj)2]Ug=(((buffer[(ipitchj)21]2)(buffer[(ipitchj)2]5)Ur=buffer[(ipitchj)21]3現(xiàn)在我們得到了RGB各自的分量，但是還有一個(gè)新的問題，那就是由于兩字節(jié)表示了3個(gè)顏色555下每個(gè)顏色最多到0x1F5

10、65格式下最大的綠色分量也就0x3F。所以我們需要一個(gè)轉(zhuǎn)換col=col255最大顏色數(shù)即可如565下RGB(r0xFF0x1Fg0xFF0x3Fb0xFF0x1F)24位Ub=buffer[(iwidthj)3realPitch]Ug=buffer[(iwidthj)31realPitch]Ur=buffer[(iwidthj)32realPitch]32位Ub=buffer[(iwidthj)4]Ug=buffer[(iwidthj