一、文件格式
Bmp文件是非常常用的位图文件,无论是游戏还是其他都被广泛使用。针对bmp文件的处理也有一堆现成的api进行调用,然而文件内部究竟怎样,如何自己来解析这样的文件呢?为了消除无聊,我用了几天时间来研究了一下,同时作为学习笔记,进行记录。
首先,整个bmp文件的内容可以分为3到4块。之所以分为3到4块而不是固定的值,是因为,对于bmp来说可能存在调色板或者一些掩码。具体稍候讨论。
第一块是bmp的文件头用于描述整个bmp文件的情况。结构如下:
typedef struct tagBITMAPFILEHEADER {
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER, *PBITMAPFILEHEADER;
这些信息相当有用,如果你想直接来解析bmp文件。第一个bfType用于表示文件类型,如果它是bmp文件,那么它这个位置的值一定是”BM” 也就是0x4D42。第二个bfSize表示整个文件的字节数。第三第四个 则保留,目前无意义,最后一个相当重要,表示,位图的数据信息离文件头的偏移量,以字节为单位。
第二块是位图信息头,即BITMAPINFOHEADER,用于描述整个位图文件的情况。以下挑重要的数据进行解释
typedef struct tagBITMAPINFOHEADER{
DWORD biSize; //表示本结构的大小
LONG biWidth; //位图的宽度
LONG biHeight; //位图的高度
WORD biPlanes; //永远为1 ,由于没有用过所以 没做研究 附msdn解释
//Specifies the number of planes for the target device. This value must be set to 1.
WORD biBitCount;//位图的位数 分为1 4 8 16 24 32 本文没对1 4 进行研究
DWORD biCompression; //本以为压缩类型,但是却另外有作用,稍候解释
DWORD biSizeImage; //表示位图数据区域的大小以字节为单位
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;
第三块就是调色板信息或者掩码部分,如果是8位位图 则存放调色板 ;16 与32位 位图则存放RGB颜色的掩码,这些掩码以DWORD大小来存放。
最后一块就是位图的数据实体。
以上文件信息可以在任意一篇bmp文件结构的文章中找到描述,所以本文只是稍微带过。
二、4字节对其问题
关于数据读取。Bmp文件有个重要特性,那就是对于数据区域而言,每行的数据它必须凑满4字节,如果没有满,则用冗余的数据来补齐。这个特性直接影响到我们读取位图数据的方法,因为在我们看来 (x,y)的数据应该在 y*width+x这样的位置上 但是因为会有冗余信息 那么必须将width用width+该行的冗余量来处理,而由于位图文件有不同的位数,所以这样的计算也不尽相同。
下面列出计算偏移量的一般公式。
首先将位图信息读入一个UCHAR 的buffer中 :
8位:
int pitch;
if(width%4==0){
pitch=width;
}else{
pitch=width+4-width%4;
}
index=buffer[y*pitch+x]; 因为8位位图的数据区域存放的是调色板索引值,所以只需读取这个index
16位
int pitch=width+width%2;
buffer[(y*pitch+x)*2]
buffer[(i*pitch+j)*2+1]
两个UCHAR内,存放的是(x,y)处的颜色信息
24位
int pitch=width%4;
buffer[(y*width+x)*3+y*pitch];
buffer[(y*width+x)*3+y*pitch+1];
buffer[(y*width+x)*3+y*pitch+2];
32位
由于一个象素就是4字节 所以无需补齐
虽然计算比较繁琐,但是这些计算是必须的,否则当你的位图每行的象素数不是4的倍数,那么y*width+x带给你的是一个扭曲的图片,当然如果你想做这样的旋转,也不错啊,至少我因为一开始没有考虑(不知道这个特性) 让一个每行象素少1字节的16位图片变成了扭曲的菱形。
三、有了数据分离RGB分量。
由于我的测试代码用了GDI,所以我必须讲得到的某一个点的值 分离成 24位模式下的RGB分离,这不是一件容易的工作。位图麻烦的地方之一就是他的格式太多,所以我们还是要分格式再讨论。
8位
通过第二部分提到的操作我们得到了一个index,这个值的范围是0~255 一共256个 正好是调色板的颜色数量。
在8位bmp图片中 数据信息前256个RGBQUAD的大小开始就是调色板的信息。不过如果要组织成调色板还要一定的转换 因为里面是RGBQUAD信息 r b 两个与调色板中的顺序是颠倒的。因为我不需要调色板设置所以我字节读取到RGBQUAD数组中,并且通过下面的表达式获取RGB值:
UCHAR r=quad[index].rgbRed;
UCHAR g=quad[index].rgbGreen;
UCHAR b=quad[index].rgbBlue;
16位
这是最麻烦的一个。因为在处理时有555 565 两种格式的区别,而且还有所谓压缩类型的区别。
之前的bitmapinfoheader里面提到一个biCompression
现在我们分两种情况讨论:BI_RGB和BI_BITFIELDS
当他等于BI_RGB时 只有555 这种格式,所以可以放心大胆的进行如下的数据分离:
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<6)&0xFF)>>3)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=(buffer[(i*pitch+j)*2+1]<<1)>>3;
希望不要被这个表达式折磨的眼花缭乱,我想既然你在看这篇文章,你就有能力阅读这样的代码,否则只能说你还没有到阅读这方面的地步,需要去学习基础的语法了。
有一点值得提醒的是由于有较多的位操作 ,所以在处理的时候在前一次操作的上面加上一对括号,我就曾经因为没有加而导致出现误差,另外虽然buffer中一个元素代表的是一个UCHAR 但是右移操作会自动增长为两字节 所以需要在进行一次与操作截取低位的1字节数据。
现在讨论BI_BITFIELDS。
这个模式下 既可以有555 也可以有565 。
555 格式 xrrrrrgggggbbbbb
565 格式 rrrrrggggggbbbbb
显然不同的格式处理不同,所以我们要首先判断处到底属于那种格式。
Bitmapinfoheader的biCompression为BI_BITFIELDS时,在位图数据区域前存在一个RGB掩码的描述 是3个DWORD值,我们只需要读取其中的R或者G的掩码,来判断是那种格式。
以红色掩码为例 0111110000000000的时候就是555格式 1111100000000000就是565格式。
以下是565格式时的数据分离:
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<5)&0xFF)>>2)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=buffer[(i*pitch+j)*2+1]>>3;
现在我们得到了RGB各自的分量,但是还有一个新的问题,那就是由于两字节表示了3个颜色 555下每个颜色最多到0x1F 565格式下最大的绿色分量也就0x3F。所以我们需要一个转换 color=color*255/最大颜色数 即可
如565下RGB(r*0xFF/0x1F,g*0xFF/0x3F,b*0xFF/0x1F)
24位
UCHAR b=buffer[(i*width+j)*3+realPitch];
UCHAR g=buffer[(i*width+j)*3+1+realPitch];
UCHAR r=buffer[(i*width+j)*3+2+realPitch];
32位
UCHAR b=buffer[(i*width+j)*4];
UCHAR g=buffer[(i*width+j)*4+1];
UCHAR r=buffer[(i*width+j)*4+2];
四、剩余的问题
当数据取到了,颜色也分离出来了 ,但是可能你绘出的位图是倒转的,这是因为有些位图的确是翻转的。通过bitmapinfoheader的biHeight可以判断是正常还是翻转,当biHeight>0的时候颠倒,它小于0的时候正常,不过测试写到现在看到的文件都是颠倒过来的。
五、相关测试代码:
采用MFC 目的只是实现自行解析位图文件
void CBmpTestView::OnDraw(CDC* pDC)
{
CBmpTestDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
// TODO: 在此处为本机数据添加绘制代码
if(filename==""){
return;
}
FILE *fp=fopen(filename,"r");
if(fp==NULL){
pDC->TextOut(100,200,"no file found");
return;
}
BITMAPFILEHEADER fileheader;
BITMAPINFO info;
fread(&fileheader,sizeof(fileheader),1,fp);
if(fileheader.bfType!=0x4D42){
pDC->TextOut(100,200,"无位图文件 请选择位图文件");
fclose(fp);
return ;
}
fread(&info.bmiHeader,sizeof(BITMAPINFOHEADER),1,fp);
long width=info.bmiHeader.biWidth;
long height=info.bmiHeader.biHeight;
UCHAR *buffer=new UCHAR[info.bmiHeader.biSizeImage];
fseek(fp,fileheader.bfOffBits,0);
fread(buffer,info.bmiHeader.biSizeImage,1,fp);
if(info.bmiHeader.biBitCount==8){
int pitch;
if(width%4==0){
pitch=width;
}else{
pitch=width+4-width%4;
}
RGBQUAD quad[256];
fseek(fp,fileheader.bfOffBits-sizeof(RGBQUAD)*256,0);
fread(quad,sizeof(RGBQUAD)*256,1,fp);
if(height>0){
//height>0 表示图片颠倒
for(int i=0;i<height;i++){
for(int j=0;j<width;j++){
int index=buffer[i*pitch+j];
UCHAR r=quad[index].rgbRed;
UCHAR g=quad[index].rgbGreen;
UCHAR b=quad[index].rgbBlue;
pDC->SetPixel(j,height-i,RGB(r,g,b));
}
}
}else{
for(int i=0;i<0-height;i++){
for(int j=0;j<width;j++){
int index=buffer[i*pitch+j];
UCHAR r=quad[index].rgbRed;
UCHAR g=quad[index].rgbGreen;
UCHAR b=quad[index].rgbBlue;
pDC->SetPixel(j,i,RGB(r,g,b));
}
}
}
}else if(info.bmiHeader.biBitCount==16){
int pitch=width+width%2;
if(height>0){
//height>0 表示图片颠倒
if(info.bmiHeader.biCompression==BI_RGB){
//该模式只有555
for(int i=0;i<height;i++){
for(int j=0;j<width;j++){
//5 5 5 格式
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<6)&0xFF)>>3)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=(buffer[(i*pitch+j)*2+1]<<1)>>3;
pDC->SetPixel(j,height-i,RGB((r*0xFF)/0x1F,(g*0xFF)/0x1F,(b*0xFF)/0x1F));
}
}
}else if(info.bmiHeader.biCompression==BI_BITFIELDS){
//该模式在bitmapinfoheader之后存在RGB掩码 每个掩码1 DWORD
fseek(fp,fileheader.bfOffBits-sizeof(DWORD )*3,0);
DWORD rMask;
fread(&rMask,sizeof(DWORD ),1,fp);
if(rMask==0x7C00){
// 5 5 5 格式
MessageBeep(0);
for(int i=0;i<height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<6)&0xFF)>>3)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=(buffer[(i*pitch+j)*2+1]<<1)>>3;
pDC->SetPixel(j,height-i,RGB((r*0xFF)/0x1F,(g*0xFF)/0x1F,(b*0xFF)/0x1F));
}
}
}else if(rMask==0xF800){
//5 6 5 格式
for(int i=0;i<height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<5)&0xFF)>>2)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=buffer[(i*pitch+j)*2+1]>>3;
pDC->SetPixel(j,height-i,RGB(r*0xFF/0x1F,g*0xFF/0x3F,b*0xFF/0x1F));
}
}
}
}
}else{
if(info.bmiHeader.biCompression==BI_RGB){
//该模式只有555
for(int i=0;i<0-height;i++){
for(int j=0;j<width;j++){
//5 5 5 格式
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<6)&0xFF)>>3)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=(buffer[(i*pitch+j)*2+1]<<1)>>3;
pDC->SetPixel(j,i,RGB((r*0xFF)/0x1F,(g*0xFF)/0x1F,(b*0xFF)/0x1F));
}
}
}else if(info.bmiHeader.biCompression==BI_BITFIELDS){
//该模式在bitmapinfoheader之后存在RGB掩码 每个掩码1 DWORD
fseek(fp,fileheader.bfOffBits-sizeof(DWORD )*3,0);
DWORD rMask;
fread(&rMask,sizeof(DWORD ),1,fp);
if(rMask==0x7C00){
// 5 5 5 格式
MessageBeep(0);
for(int i=0;i<0-height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<6)&0xFF)>>3)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=(buffer[(i*pitch+j)*2+1]<<1)>>3;
pDC->SetPixel(j,i,RGB((r*0xFF)/0x1F,(g*0xFF)/0x1F,(b*0xFF)/0x1F));
}
}
}else if(rMask==0xF800){
//5 6 5 格式
for(int i=0;i<0-height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*pitch+j)*2]&0x1F;
UCHAR g=(((buffer[(i*pitch+j)*2+1]<<5)&0xFF)>>2)+(buffer[(i*pitch+j)*2]>>5);
UCHAR r=buffer[(i*pitch+j)*2+1]>>3;
pDC->SetPixel(j,i,RGB(r*0xFF/0x1F,g*0xFF/0x3F,b*0xFF/0x1F));
}
}
}
}
}
//pDC->TextOut(100,200,"16位图");
}else if(info.bmiHeader.biBitCount==24){
int pitch=width%4;
//b g r
if(height>0){
//height>0 表示图片颠倒
for(int i=0;i<height;i++){
int realPitch=i*pitch;
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*width+j)*3+realPitch];
UCHAR g=buffer[(i*width+j)*3+1+realPitch];
UCHAR r=buffer[(i*width+j)*3+2+realPitch];
pDC->SetPixel(j,height-i,RGB(r,g,b));
}
}
}else{
for(int i=0;i<0-height;i++){
int realPitch=i*pitch;
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*width+j)*3+realPitch];
UCHAR g=buffer[(i*width+j)*3+1+realPitch];
UCHAR r=buffer[(i*width+j)*3+2+realPitch];
pDC->SetPixel(j,i,RGB(r,g,b));
}
}
}
//pDC->TextOut(100,200,"24位图");
}else if(info.bmiHeader.biBitCount==32){
// b g r a
if(height>0){
//height>0 表示图片颠倒
for(int i=0;i<0-height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*width+j)*4];
UCHAR g=buffer[(i*width+j)*4+1];
UCHAR r=buffer[(i*width+j)*4+2];
pDC->SetPixel(j,height-i,RGB(r,g,b));
}
}
}else{
for(int i=0;i<height;i++){
for(int j=0;j<width;j++){
UCHAR b=buffer[(i*width+j)*4];
UCHAR g=buffer[(i*width+j)*4+1];
UCHAR r=buffer[(i*width+j)*4+2];
pDC->SetPixel(j,i,RGB(r,g,b));
}
}
}
//pDC->TextOut(100,200,"32位图");
}
delete buffer;
fclose(fp);
}
CreateDIBSection 理解分辨率 我们常说的屏幕分辨率为640×480,刷新频率为70Hz,意思是说每行要扫描640个象素,一共有480行,每秒重复扫描屏幕70次。理解调色板 有一个长宽各为200个象素,颜色数为16色的彩色图,每一个象素都用R、G、B三个分量表示。因为每个分量有256个级别,要用8位(bit),即一个字节(byte)来表示,所以每个象素需要用3个字节。整个图象要用200×200×3,约120k字节,可不是一个小数目呀!如果我们用下面的方法,就能省的多。 因为是一个16色图,也就是说这幅图中最多只有16种颜色,我们可以用一个表:表中的每一行记录一种颜色的R、G、B值。这样当我们表示一个象素的颜色时,只需要指出该颜色是在第几行,即该颜色在表中的索引值。举个例子,如果表的第0行为255,0,0(红色),那么当某个象素为红色时,只需要标明0即可。 让我们再来计算一下:16种状态可以用4位(bit)表示,所以一个象素要用半个字节。整个图象要用200×200×0.5,约20k字节,再加上表占用的字节为3×16=48字节.整个占用的字节数约为前面的1/6,省很多吧? 这张R、G、B的表,就是我们常说的调色板(Palette),另一种叫法是颜色查找表LUT(Look Up Table),似乎更确切一些。Windows位图中便用到了调色板技术。其实不光是Windows位图,许多图象文件格式如pcx、tif、gif等都用到了。所以很好地掌握调色板的概念是十分有用的。 有一种图,它的颜色数高达256×256×256种,也就是说包含我们上述提到的R、G、B颜色表示方法中所有的颜色,这种图叫做真彩色图(true color)。真彩色图并不是说一幅图包含了所有的颜色,而是说它具有显示所有颜色的能力,即最多可以包含所有的颜色。表示真彩色图时,每个象素直接用R、G、B三个分量字节表示,而不采用调色板技术。原因很明显:如果用调色板,表示一个象素也要用24位,这是因为每种颜色的索引要用24位(因为总共有224种颜色,即调色板有224行),和直接用R,G,B三个分量表示用的字节数一样,不但没有任何便宜,还要加上一个256×256×256×3个字节的大调色板。所以真彩色图直接用R、G、B三个分量表示,它又叫做24位色图。bmp文件格式介绍完位图和调色板的概念,下面就让我们来看一看Windows的位图文件(.bmp文件)的格式是什么样子的。 bmp文件大体上分成四个部分,如图1.3所示。图1.3 Windows位图文件结构示意图第一部分为位图文件头BITMAPFILEHEADER,是一个结构,其定义如下: typedef struct tagBITMAPFILEHEADER {WORD bfType; DWORD bfSize; WORD bfReserved1; WORD bfReserved2; DWORD bfOffBits; } BITMAPFILEHEADER; 这个结构的长度是固定的,为14个字节(WORD为无符号16位整数,DWORD为无符号32位整数),各个域的说明如下:bfType指定文件类型,必须是0x424D,即字符串“BM”,也就是说所有.bmp文件的头两个字节都是“BM”。bfSize指定文件大小,包括这14个字节。bfReserved1,bfReserved2为保留字,不用考虑bfOffBits为从文件头到实际的位图数据的偏移字节数,即图1.3中前三个部分的长度之和。 第二部分为位图信息头BITMAPINFOHEADER,也是一个结构,其定义如下: typedef struct tagBITMAPINFOHEADER{DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER; 这个结构的长度是固定的,为40个字节(LONG为32位整数),各个域的说明如下:biSize指定这个结构的长度,为40。biWidth指定图象的宽度,单位是象素。biHeight指定图象的高度,单位是象素。biPlanes必须是1,不用考虑。biBitCount指定表示颜色时要用到的位数,常用的值为1(黑白二色图), 4(16色图), 8(256色), 24(真彩色图)(新的.bmp格式支持32位色,这里就不做讨论了)。biCompression指定位图是否压缩,有效的值为BI_RGB,BI_RLE8,BI_RLE4,BI_BITFIELDS(都是一些Windows定义好的常量)。要说明的是,Windows位图可以采用RLE4,和RLE8的压缩格式,但用的不多。我们今后所讨论的只有第一种不压缩的情况,即biCompression为BI_RGB的情况。biSizeImage指定实际的位图数据占用的字节数,其实也可以从以下的公式中计算出来: biSizeImage=biWidth’ × biHeight 要注意的是:上述公式中的biWidth’必须是4的整倍数(所以不是biWidth,而是biWidth’,表示大于或等于biWidth的,最接近4的整倍数。举个例子,如果biWidth=240,则biWidth’=240;如果biWidth=241,biWidth’=244)。 如果biCompression为BI_RGB,则该项可能为零biXPelsPerMeter指定目标设备的水平分辨率,单位是每米的象素个数,关于分辨率的概念,我们将在第4章详细介绍。biYPelsPerMeter指定目标设备的垂直分辨率,单位同上。biClrUsed指定本图象实际用到的颜色数,如果该值为零,则用到的颜色数为2biBitCount。biClrImportant指定本图象中重要的颜色数,如果该值为零,则认为所有的颜色都是重要的。 第三部分为调色板Palette,当然,这里是对那些需要调色板的位图文件而言的。有些位图,如真彩色图,前面已经讲过,是不需要调色板的,BITMAPINFOHEADER后直接是位图数据。 调色板实际上是一个数组,共有biClrUsed个元素(如果该值为零,则有2biBitCount个元素)。数组中每个元素的类型是一个RGBQUAD结构,占4个字节,其定义如下: typedef struct tagRGBQUAD {BYTE rgbBlue; //该颜色的蓝色分量 BYTE rgbGreen; //该颜色的绿色分量 BYTE rgbRed; //该颜色的红色分量 BYTE rgbReserved; //保留值 } RGBQUAD; 第四部分就是实际的图象数据了。对于用到调色板的位图,图象数据就是该象素颜在调色板中的索引值。对于真彩色图,图象数据就是实际的R、G、B值。下面针对2色、16色、256色位图和真彩色位图分别介绍。 对于2色位图,用1位就可以表示该象素的颜色(一般0表示黑,1表示白),所以一个字节可以表示8个象素。 对于16色位图,用4位可以表示一个象素的颜色,所以一个字节可以表示2个象素。 对于256色位图,一个字节刚好可以表示1个象素。 对于真彩色图,三个字节才能表示1个象素,哇,好费空间呀!没办法,谁叫你想让图的颜色显得更亮丽呢,有得必有失嘛。 要注意两点: (1)每一行的字节数必须是4的整倍数,如果不是,则需要补齐。这在前面介绍biSizeImage时已经提到了。 (2)一般来说,.bMP文件的数据从下到上,从左到右的。也就是说,从文件中最先读到的是图象最下面一行的左边第一个象素,然后是左边第二个象素……接下来是倒数第二行左边第一个象素,左边第二个象素……依次类推 ,最后得到的是最上面一行的最右一个象素。 下面的函数将pBuffer指向的内存块中的位图数据写入文件中,lBufferLen参数为pBuffer指向的内存块的大小,注意必须先指定位图的BITMAPFILEHEADER结构和BITMAPINFOHEADER结构。 STDMETHODIMP CSampleGrabberCallback::BufferCB(double time,BYTE* pBuffer,long lBufferLen) {if(!g_bSnap) return E_FAIL; BOOL bWrite=FALSE; HANDLE hFile=CreateFile("E://Test.bmp",GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, NULL, NULL); if (hFile == INVALID_HANDLE_VALUE) {return E_FAIL; } //首先初始化位图文件头结构(BITMAPFILEHEADER),并将其写入文件。 BITMAPFILEHEADER bmpFileHeader; //memset(&bmpFileHeader,0,sizeof(bmpFileHeader)); ZeroMemory(&bmpFileHeader,sizeof(bmpFileHeader)); bmpFileHeader.bfType='MB'; bmpFileHeader.bfSize=sizeof(bmpFileHeader)+lBufferLen+sizeof(BITMAPINFOHEADER); bmpFileHeader.bfOffBits=sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER); DWORD dwWritten=0; bWrite=WriteFile(hFile,&bmpFileHeader,sizeof(bmpFileHeader),&dwWritten,NULL); if(!bWrite) {MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK); }//初始化BITMAPINFOHEADER结构并将其写入文件。 //VIDEOINFOHEADER*viInfoHeader=(VIDEOINFOHEADER*) g_media_type.pbFormat; //FreeMediaType(g_media_type); BITMAPINFOHEADER bmpInfoHeader; ZeroMemory(&bmpInfoHeader,sizeof(bmpInfoHeader)); //memset(&bmpInfoHeader,0,sizeof(bmpInfoHeader)); bmpInfoHeader.biSize=sizeof(bmpInfoHeader); bmpInfoHeader.biWidth=lWidth; bmpInfoHeader.biHeight=lHeight; bmpInfoHeader.biPlanes=1; bmpInfoHeader.biBitCount=16;//???248 dwWritten=0; bWrite=WriteFile(hFile,&bmpInfoHeader,sizeof(bmpInfoHeader),&dwWritten,NULL); if(!bWrite) {MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK); }//最后将位图的主要数据写入文件。 dwWritten=0; bWrite=WriteFile(hFile,pBuffer,lBufferLen,&dwWritten,NULL); if(!bWrite) {MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK); } CloseHandle(hFile); CWnd* pMainWnd=theApp.GetMainWnd(); CDfgDlg* pDfg=(CDfgDlg*)pMainWnd; HWND hwnd=pDfg->m_picture.GetSafeHwnd(); RECT rc; ::GetWindowRect(hwnd,&rc); long lStillWidth=rc.right-rc.left; long lStillHeight=rc.bottom-rc.top; HDC hdcStill=GetDC(hwnd); PAINTSTRUCT ps; BeginPaint(hwnd,&ps);SetStretchBltMode(hdcStill,COLORONCOLOR); StretchDIBits(hdcStill,0,0,lStillWidth,lStillHeight,0,0,lWidth,lHeight,pBuffer,(BITMAPINFO*)&bmpInfoHeader,DIB_RGB_COLORS,SRCCOPY); EndPaint(hwnd,&ps); ReleaseDC(hwnd,hdcStill); g_bSnap=!g_bSnap; return S_OK; } 关于CreateDIBSection函数:
HBITMAP CreateDIBSection(
HDChdc,// handle to DC
CONST BITMAPINFO*pbmi,// bitmap data
UINTiUsage,// data type indicator
VOID**ppvBits,// bit values
HANDLEhSection,// handle to file mapping object
DWORDdwOffset// offset to bitmap bit values
);
CreateDIBSection函数会根据位图结构信息(pbmi)分配内存空间,你不用为它分配内存,这块内存也不需要你释放,系统会自己释放的。
然后将位图中的图像数据读入这个内存地址,显示即可。
LPBYTE lpBits;
HBITMAP hBmp=::CreateDIBSection(dcMem.m_hDC,lpBitmap,DIB_PAL_COLORS, &lpBits,NUL L,0); //将图像数据填充到得到的内存地址中
file.ReadHuge(lpBits,dwBitlen);
pDC->StretchBlt(0,0,bmp.bmWidth,bmp.bmHeight,&dcMem,0,0,
bmp.bmWidth,bmp.bmHeight,SRCCOPY); 首先让我们检查一下如何简化CreateDIBSection,并正确地使用它。首先,把最後两个参数hSection和dwOffset,分别设定为NULL和0,我将在本章最後讨论这些参数的用法。第二,仅在fColorUse参数设定为DIB_ PAL_COLORS时,才使用hdc参数,如果fColorUse为DIB_RGB_COLORS(或0),hdc将被忽略(这与CreateDIBitmap不同,hdc参数用於取得与DDB相容的设备的色彩格式,CreateDIBitmap创建的是DDB(设备相关位图,CreateDIBSection创建设备无关位图),因此必须指定与位图所关联的设备,即hdc,位图根据hdc所代表的设备来取得位图的色彩格式)。 因此,CreateDIBSection最简单的形式仅需要第二和第四个参数。第二个参数是指向BITMAPINFO结构的指标, BITMAPINFOHEADERbmih ;
BYTE * pBits ;
HBITMAP hBitmap ;
现在初始化BITMAPINFOHEADER结构的栏位
bmih->biSize = sizeof (BITMAPINFOHEADER) ;
bmih->biWidth = 384 ;
bmih->biHeight= 256 ;
bmih->biPlanes= 1 ;
bmih->biBitCount= 24 ;
bmih->biCompression= BI_RGB ;
bmih->biSizeImage= 0 ;
bmih->biXPelsPerMeter= 0 ;
bmih->biYPelsPerMeter= 0 ;
bmih->biClrUsed = 0 ;
bmih->biClrImportant = 0 ;
在基本准备後,我们呼叫该函式:
hBitmap = CreateDIBSection (NULL, (BITMAPINFO *)&bmih, 0, &pBits, NULL, 0) ; 这是函式呼叫所做的:CreateDIBSection检查BITMAPINFOHEADER结构并配置足够的记忆体块来载入DIB图素位元。(在这个例子里,记忆体块的大小为384×256×3位元组。)它在您提供的pBits参数中储存了指向此记忆体块的指标。 然而,我们还没有做完,点阵图图素是未初始化的。如果正在读取DIB档案,可以简单地把pBits参数传递给ReadFile函式并读取它们。或者可以使用一些程式码「人工」设定。 注意:使用CreateDIBSection函数获得的内存块指针(输出的第四个参数)所指向的地址中是没有内容的,我们必须向里面写入图像数据,然后才能够显示图像。
如果觉得《位图文件(BMP)格式分析》对你有帮助,请点赞、收藏,并留下你的观点哦!