
轉(zhuǎn)轉(zhuǎn)大師PDF轉(zhuǎn)換器
支持40多種格式轉(zhuǎn)換,高效辦公
寬泛來說,BMP圖像是支持壓縮的,他甚至支持jpeg壓縮算法,但更一般的情況是,BMP用來存儲所謂的真彩色影像,即24位的BitMap(位圖),本文并不想刨BMP的祖墳,將它所有的細(xì)節(jié)抽絲剝繭一一展現(xiàn),本文只想針對其最常見 的存儲模式做個(gè)總結(jié),備忘。
先來看BMP格式圖像的文件總體結(jié)構(gòu):
從上到下,分別是三個(gè)結(jié)構(gòu)體,代碼表示如下(重要的成員已標(biāo)注為紅色):
struct header
{
int16_t type;
int32_t size; // 圖像文件大小
int16_t reserved1;
int16_t reserved2;
int32_t offbits; // bmp圖像數(shù)據(jù)偏移量
}__attribute__((packed));
struct info
{
int32_t size; // 本結(jié)構(gòu)大小
int32_t width; // 圖像寬度(單位像素)
int32_t height; // 圖像高度(單位像素)
int16_t planes; // 總為零
int16_t bit_count; // 色深
int32_t compression; // 是否壓縮
int32_t size_img;
int32_t X_pel;
int32_t Y_pel;
int32_t clrused;
int32_t clrImportant;
}__attribute__((packed));
struct quad
{
int8_t blue;
int8_t green;
int8_t red;
int8_t reserved;
}__attribute__((packed));
看代碼總是很無聊的,尤其是看不懂的代碼!但是如果真要處理BMP圖像數(shù)據(jù),那就必須搞清楚以上代碼了,挑幾個(gè)重點(diǎn)說一下:
第一,定義了這三個(gè)結(jié)構(gòu)體之后,一定要使用__attribute__((packed));來去除系統(tǒng)的地址對齊,否則讀到的格式頭會(huì)發(fā)生錯(cuò)誤。
第二,header.size就是圖像文件的大?。次募偞笮p去格式頭大小)。
第三,header.offbits就是格式頭的大?。赡苁乔皟蓚€(gè)結(jié)構(gòu)體,也可能是三個(gè)結(jié)構(gòu)體,因?yàn)榈谌齻€(gè)結(jié)構(gòu)體quad可能有也可能沒有)
第四,info.compression決定了格式頭中是否含有quad結(jié)構(gòu)體。
最后,要正確處理BMP圖像還必須牢記在心的幾個(gè)要點(diǎn):
1,圖像每一行所包含的字節(jié)數(shù),必須是4的倍數(shù),如果不夠則會(huì)湊齊補(bǔ)足到夠?yàn)橹?。比如某BMP圖像色深為24bits,寬度為65像素,算下來一行的字節(jié)數(shù)是65乘以3等于195個(gè)字節(jié),那在文件中將會(huì)增加一個(gè)額外的字節(jié)湊夠196個(gè)字節(jié)來表示一行的數(shù)據(jù)量。
2,最后一行數(shù)據(jù)是圖像的第一行,換句話說BMP是反著存儲的。因此在讀取BMP圖像時(shí)一般從最后一行開始讀取,然后讀倒數(shù)第二行,以此類推,然后將讀取到的數(shù)據(jù)依次刷新到顯存,這樣才能正確顯示圖像,否則圖片看起來是反的。