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