在讀取BMP圖像的時候，主要處理了24位和32位圖像，在處理24位BMP圖像的時候，BMP圖像的數(shù)據(jù)已經(jīng)被修改以便4字節(jié)自動對齊，
對于24位BMP圖像而言，最需要注意的一點是，規(guī)定了每條行掃描線的數(shù)據(jù)大小必須是4的整數(shù)倍，如果不是4的整數(shù)倍，那么需要在行末端進行補0，否則數(shù)據(jù)讀取將出現(xiàn)偏移，直接導(dǎo)致的結(jié)果：會加載出一張傾斜的圖像。這個補0的操作叫做數(shù)據(jù)寬度對齊。
很抽象？舉個例子，對于400×400的24位BMP圖像而言，行掃描是400px，是4的整數(shù)倍，那么無需進行補0操作。如果是30×38（本篇每張麻將牌素材的尺寸），那么行掃描顯然不是4的整數(shù)倍。對于24位BMP而言，一個像素由RGB三字節(jié)組成，那么一個行掃描的total字節(jié)是30 × 3 = 90字節(jié)，進行數(shù)據(jù)寬度對齊之后，行掃描的實際total字節(jié)是30 × 3 + 2 = 92字節(jié)。如此，才能被4整除。換句話說，每一行多出2個無用的字節(jié)。這在編程中，需要進行處理丟棄，否則圖像再次變形
int channel= 0;
if ( texture->bpp == 24 )
{
channel = 3;
texture->imageType = GL_RGB;
}else{
channel = 4;
texture->imageType = GL_RGBA;
}
int biWidth = 0; //每行補齊字節(jié)數(shù),如果是24位的話需要補齊成4字節(jié)的倍數(shù)
if ( (texture->width*channel) % 4 != 0 )
biWidth = 4 - ( (texture->width*channel) % 4 );
for( int i = 0; i < height; i++ ){
GLubyte* pdest = texture->imageData + i * width * channel;
fread( pdest, 1, width * channel,file );
for( int j = 0; j < width* channel; j+=channel ){
pdest[ j ] ^= pdest[j+2] ^= pdest[j] ^= pdest[j+2]; //將BGR轉(zhuǎn)為RGB,BMP數(shù)據(jù)從左下角到右上角的方式存儲
}
fseek( file, biWidth, SEEK_CUR ); //丟棄補足字節(jié)，開始填充下一行
}
讀取數(shù)據(jù)完畢，可以打印檢驗一下，用WINHEX打開看下，NoPropblem
因為我讀取的圖片不全是512*512,256*256,.......,所以我用OPENGL生成紋理的時候用了個gluBuild2DMipmaps
BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D, texture->bpp/8, texture->width,texture->height, texture->imageType, GL_UNSIGNED_BYTE, texture->imageData );
畫出來后又成斜著的圖像了，數(shù)據(jù)也沒問題，只能說是生成MipMap 的時候讀取數(shù)據(jù)跨度有問題，但是我傳遞的是32位圖像的時候，生成的MIPMAP沒任何問題，即使圖像大小不能被2整除，即非512*512,256*256,.......
所以我做了個比較惡心的做法
if ( bMipmap ){
if ( texture->imageType == GL_RGB ){
GLubyte* data = new GLubyte[texture->width*texture->height*4 ];
int counter = 0;
for( int i = 0; i < texture->width*texture->height*3; i+=3 ){
data[i+counter] = texture->imageData[i];
data[i+1+counter] = texture->imageData[i+1];
data[i+2+counter] = texture->imageData[i+2];
data[i+3+counter] = 1.f;
counter++;
}
BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D, 4, texture->width,texture->height, GL_RGBA, GL_UNSIGNED_BYTE, data );
delete[] data;
}else{
BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D, texture->bpp/8, texture->width,texture->height, texture->imageType, GL_UNSIGNED_BYTE, texture->imageData );
}
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_LINEAR );
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
將24位的圖像生成紋理的時候，我把數(shù)據(jù)轉(zhuǎn)換為32位的就沒問題了，一直沒更好的辦法，請大家不吝指導(dǎo)
題外文章：
BMP文件的結(jié)構(gòu)，從大的分類來看，可以分成2部分：頭部信息區(qū)和圖像數(shù)據(jù)區(qū)。其中頭部信息區(qū)中，保存了圖像的各種屬性，如文件格式，圖片寬度，調(diào)色板等等。過了頭部信息區(qū)之后，就是用來呈現(xiàn)圖像的真正的數(shù)據(jù)區(qū)了。BMP文件屬于像素文件，也就是說，數(shù)據(jù)區(qū)中的數(shù)據(jù)，其實就是記錄了圖像中每一個像素的顏色，以32位BMP圖片來說，每一個像素由ARGB四個字節(jié)保存其顏色，其中A是透明度。那么，一副400×400的32位BMP圖像，就由160000個像素組成，則，數(shù)據(jù)區(qū)大小=160000×4byte = 640000byte = 640kb，所以也不難怪，BMP圖像文件給人的印象就是文件非常大。
那么將BMP文件中的像素逐個讀入數(shù)據(jù)緩沖再顯示，是否就能正常顯示了呢？顯然不是的。前面說了，在文件開頭有一塊頭部信息區(qū)，如果把這些數(shù)據(jù)也一起讀進緩沖，那么圖像是無法最終顯示的。因此，通常載入BMP圖像的首要任務(wù)是要知道這塊頭部信息區(qū)的大小，也就是數(shù)據(jù)區(qū)的偏移量offset，再利用fseek尋址到這個位置，再進行逐個像素的解析。而頭部信息區(qū)的大小值貌似在頭部信息區(qū)的某個字節(jié)中有的，只需要讀取該字節(jié)，便可知道。對于24位和32位的BMP圖像而言，這個offset值為0x36，也就是頭部信息區(qū)的大小是54個字節(jié)。
如果你要把加載圖像的函數(shù)做的通用一些的話，那么圖片的寬度和高度也是需要獲取的，對于24位BMP圖像，這兩個值可以分別在0x12和0x16進行尋址得到，注意fread需要讀雙字，即4字節(jié)，否則會出錯。
對于24位BMP圖像而言，最需要注意的一點是，規(guī)定了每條行掃描線的數(shù)據(jù)大小必須是4的整數(shù)倍，如果不是4的整數(shù)倍，那么需要在行末端進行補0，否則數(shù)據(jù)讀取將出現(xiàn)偏移，直接導(dǎo)致的結(jié)果：會加載出一張傾斜的圖像。這個補0的操作叫做數(shù)據(jù)寬度對齊。
很抽象？舉個例子，對于400×400的24位BMP圖像而言，行掃描是400px，是4的整數(shù)倍，那么無需進行補0操作。如果是30×38（本篇每張麻將牌素材的尺寸），那么行掃描顯然不是4的整數(shù)倍。對于24位BMP而言，一個像素由RGB三字節(jié)組成，那么一個行掃描的total字節(jié)是30 × 3 = 90字節(jié)，進行數(shù)據(jù)寬度對齊之后，行掃描的實際total字節(jié)是30 × 3 + 2 = 92字節(jié)。如此，才能被4整除。換句話說，每一行多出2個無用的字節(jié)。這在編程中，需要進行處理丟棄，否則圖像再次變形。
最后一個需要注意的小細節(jié)是，BMP圖像的原點坐標，都是以左下角為基準，向右、向上增加。所以，在編程時，需要對y軸數(shù)據(jù)做一些小變換。否則將會得到一幅顛倒的圖像，此外，BMP的三原色順序是BGR，注意編程中的處理。
原文地址：BMP文件的結(jié)構(gòu)，從大的分類來看，可以分成2部分：頭部信息區(qū)和圖像數(shù)據(jù)區(qū)。其中頭部信息區(qū)中，保存了圖像的各種屬性，如文件格式，圖片寬度，調(diào)色板等等。過了頭部信息區(qū)之后，就是用來呈現(xiàn)圖像的真正的數(shù)據(jù)區(qū)了。BMP文件屬于像素文件，也就是說，數(shù)據(jù)區(qū)中的數(shù)據(jù)，其實就是記錄了圖像中每一個像素的顏色，以32位BMP圖片來說，每一個像素由ARGB四個字節(jié)保存其顏色，其中A是透明度。那么，一副400×400的32位BMP圖像，就由160000個像素組成，則，數(shù)據(jù)區(qū)大小=160000×4byte = 640000byte = 640kb，所以也不難怪，BMP圖像文件給人的印象就是文件非常大。
那么將BMP文件中的像素逐個讀入數(shù)據(jù)緩沖再顯示，是否就能正常顯示了呢？顯然不是的。前面說了，在文件開頭有一塊頭部信息區(qū)，如果把這些數(shù)據(jù)也一起讀進緩沖，那么圖像是無法最終顯示的。因此，通常載入BMP圖像的首要任務(wù)是要知道這塊頭部信息區(qū)的大小，也就是數(shù)據(jù)區(qū)的偏移量offset，再利用fseek尋址到這個位置，再進行逐個像素的解析。而頭部信息區(qū)的大小值貌似在頭部信息區(qū)的某個字節(jié)中有的，只需要讀取該字節(jié)，便可知道。對于24位和32位的BMP圖像而言，這個offset值為0x36，也就是頭部信息區(qū)的大小是54個字節(jié)。
如果你要把加載圖像的函數(shù)做的通用一些的話，那么圖片的寬度和高度也是需要獲取的，對于24位BMP圖像，這兩個值可以分別在0x12和0x16進行尋址得到，注意fread需要讀雙字，即4字節(jié)，否則會出錯。
對于24位BMP圖像而言，最需要注意的一點是，規(guī)定了每條行掃描線的數(shù)據(jù)大小必須是4的整數(shù)倍，如果不是4的整數(shù)倍，那么需要在行末端進行補0，否則數(shù)據(jù)讀取將出現(xiàn)偏移，直接導(dǎo)致的結(jié)果：會加載出一張傾斜的圖像。這個補0的操作叫做數(shù)據(jù)寬度對齊。
很抽象？舉個例子，對于400×400的24位BMP圖像而言，行掃描是400px，是4的整數(shù)倍，那么無需進行補0操作。如果是30×38（本篇每張麻將牌素材的尺寸），那么行掃描顯然不是4的整數(shù)倍。對于24位BMP而言，一個像素由RGB三字節(jié)組成，那么一個行掃描的total字節(jié)是30 × 3 = 90字節(jié)，進行數(shù)據(jù)寬度對齊之后，行掃描的實際total字節(jié)是30 × 3 + 2 = 92字節(jié)。如此，才能被4整除。換句話說，每一行多出2個無用的字節(jié)。這在編程中，需要進行處理丟棄，否則圖像再次變形。
最后一個需要注意的小細節(jié)是，BMP圖像的原點坐標，都是以左下角為基準，向右、向上增加。所以，在編程時，需要對y軸數(shù)據(jù)做一些小變換。否則將會得到一幅顛倒的圖像，此外，BMP的三原色順序是BGR，注意編程中的處理。
原文地址：
http://naozifangde.blog.163.com/blog/static/1280042642009101614938531/
posted on 2010-05-29 11:22
風輕云淡 閱讀(2659)
評論(0) 編輯 收藏 引用 所屬分類:
圖像讀取