当前位置: 首页 > 编程笔记 >

关于图片存储格式的整理(BMP格式介绍)

明财
2023-03-14
本文向大家介绍关于图片存储格式的整理(BMP格式介绍),包括了关于图片存储格式的整理(BMP格式介绍)的使用技巧和注意事项,需要的朋友参考一下

BMP

BMP(全称Bitmap)是Window操作系统中的标准图像文件格式

可以分成两类:设备相关位图(DDB)和设备无关位图(DIB),使用非常广。

它采用位映射存储格式,除了图像深度可选以外,不采用其他任何压缩,因此,BMP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。BMP文件存储数据时,图像的扫描方式是按从左到右、从下到上的顺序。由于BMP文件格式是Windows环境中交换与图有关的数据的一种标准,因此在Windows环境中运行的图形图像软件都支持BMP图像格式。

组成

  典型的BMP图像文件由四部分组成:

  1:位图头文件数据结构,它包含BMP图像文件的类型、显示内容等信息;
  2:位图信息数据结构,它包含有BMP图像的宽、高、压缩方法,以及定义颜色等信息;
  3:调色板,这个部分是可选的,有些位图需要调色板,有些位图,比如真彩色图(24位的BMP)就不需要调色板;
  4:位图数据,这部分的内容根据BMP位图使用的位数不同而不同,在24位图中直接使用RGB,而其他的小于24位的使用调色板中颜色索引值。

对应的数据结构

  1:BMP文件组成
  BMP文件由文件头、位图信息头、颜色信息和图形数据四部分组成。

  2:BMP文件头(14字节)
  BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。
  其结构定义如下:
  typedef struct tagBITMAPFILEHEADER
  {
  WORD bfType; // 位图文件的类型,必须为BM(1-2字节)
  DWORD bfSize; // 位图文件的大小,以字节为单位(3-6字节)
  WORD bfReserved1; // 位图文件保留字,必须为0(7-8字节)
  WORD bfReserved2; // 位图文件保留字,必须为0(9-10字节)
  DWORD bfOffBits; // 位图数据的起始位置,以相对于位图(11-14字节)
  // 文件头的偏移量表示,以字节为单位
  } BITMAPFILEHEADER;


  3:位图信息头(40字节)
  BMP位图信息头数据用于说明位图的尺寸等信息。
  typedef struct tagBITMAPINFOHEADER{
  DWORD biSize; // 本结构所占用字节数(15-18字节)
  LONG biWidth; // 位图的宽度,以像素为单位(19-22字节)
  LONG biHeight; // 位图的高度,以像素为单位(23-26字节)
  WORD biPlanes; // 目标设备的级别,必须为1(27-28字节)
  WORD biBitCount;// 每个像素所需的位数,必须是1(双色),(29-30字节)
  // 4(16色),8(256色)或24(真彩色)之一
  DWORD biCompression; // 位图压缩类型,必须是 0(不压缩),(31-34字节)
  // 1(BI_RLE8压缩类型)或2(BI_RLE4压缩类型)之一
  DWORD biSizeImage; // 位图的大小,以字节为单位(35-38字节)
  LONG biXPelsPerMeter; // 位图水平分辨率,每米像素数(39-42字节)
  LONG biYPelsPerMeter; // 位图垂直分辨率,每米像素数(43-46字节)
  DWORD biClrUsed;// 位图实际使用的颜色表中的颜色数(47-50字节)
  DWORD biClrImportant;// 位图显示过程中重要的颜色数(51-54字节)
  } BITMAPINFOHEADER;
 

  4:颜色表
  颜色表用于说明位图中的颜色,它有若干个表项,每一个表项是一个RGBQUAD类型的结构,定义一种颜色。RGBQUAD结构的定义如下:
  typedef struct tagRGBQUAD {
  BYTE rgbBlue;// 蓝色的亮度(值范围为0-255)
  BYTE rgbGreen; // 绿色的亮度(值范围为0-255)
  BYTE rgbRed; // 红色的亮度(值范围为0-255)
  BYTE rgbReserved;// 保留,必须为0
  } RGBQUAD;

   颜色表中RGBQUAD结构数据的个数有biBitCount来确定:
  当biBitCount=1,4,8时,分别有2,16,256个表项;
  当biBitCount=24时,没有颜色表项。
  位图信息头和颜色表组成位图信息,BITMAPINFO结构定义如下:
  typedef struct tagBITMAPINFO {
  BITMAPINFOHEADER bmiHeader; // 位图信息头
  RGBQUAD bmiColors[1]; // 颜色表
  } BITMAPINFO;

  5:位图数据
  位图数据记录了位图的每一个像素值,记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。位图的一个像素值所占的字节数:
  当biBitCount=1时,8个像素占1个字节;
  当biBitCount=4时,2个像素占1个字节;
  当biBitCount=8时,1个像素占1个字节;
  当biBitCount=24时,1个像素占3个字节;
  Windows规定一个扫描行所占的字节数必须是
  4的倍数(即以long为单位),不足的以0填充,
  biSizeImage = ((((bi.biWidth * bi.biBitCount) + 31) & ~31) / 8) * bi.biHeight;
  具体数据举例:
  如某BMP文件开头:
  424D 4690 0000 0000 0000 4600 0000 2800 0000 8000 0000 9000 0000 0100*1000 0300 0000 0090 0000 A00F 0000 A00F 0000 0000 0000 0000 0000*00F8 E007 1F00 0000*02F1 84F1 04F1 84F1 84F1 06F2 84F1 06F2 04F2 86F2 06F2 86F2 86F2 .... ....

文件部分

图像文件头
  1)1-2:(这里的数字代表的是"字",即两个字节,下同)图像文件头。0x4d42='BM',表示是Windows支持的BMP格式。(注意:查ascii表B 0x42,M0x4d,bfType 为两个字节,B为low字节,M为high字节所以bfType=0x4D42,而不是0x424D,但注意)
  2)3-6:整个文件大小。4690 0000,为00009046h=36934。
  3)7-8:保留,必须设置为0。
  4)9-10:保留,必须设置为0。
  5)11-14:从文件开始到位图数据之间的偏移量(14+40+4*(2^biBitCount))。4600 0000,为00000046h=70,上面的文件头就是35字=70字节。
位图信息头
  6)15-18:位图图信息头长度。
  7) 19-22:位图宽度,以像素为单位。8000 0000,为00000080h=128。
  8)23-26:位图高度,以像素为单位。9000 0000,为00000090h=144。
  9)27-28:位图的位面数,该值总是1。0100,为0001h=1。
  10)29-30:每个像素的位数。有1(单色),4(16色),8(256色),16(64K色,高彩色),24(16M色,真彩色),32(4096M色,增强型真彩色)。1000为0010h=16。
  11)31-34:压缩说明:有0(不压缩),1(RLE 8,8位RLE压缩),2(RLE 4,4位RLE压缩,3(Bitfields,位域存放)。RLE简单地说是采用像素数+像素值的方式进行压缩。T408采用的是位域存放方式,用两个字节表示一个像素,位域分配为r5b6g5。图中0300 0000为00000003h=3。
  12)35-38:用字节数表示的位图数据的大小,该数必须是4的倍数,数值上等于(≥位图宽度的最小的4的倍数)×位图高度×每个像素位数。0090 0000为00009000h=80×90×2h=36864。
  13)39-42:用象素/米表示的水平分辨率。A00F 0000为0000 0FA0h=4000。
  14)43-46:用象素/米表示的垂直分辨率。A00F 0000为0000 0FA0h=4000。
  15)47-50:位图使用的颜色索引数。设为0的话,则说明使用所有调色板项。
  16)51-54:对图象显示有重要影响的颜色索引的数目。如果是0,表示都重要。
彩色板
  17)(55+0)到(50-1+2^biBitCount):彩色板规范。对于调色板中的每个表项,用下述方法来描述RGB的值:
  1字节用于蓝色分量
  1字节用于绿色分量
  1字节用于红色分量
  1字节用于填充符(设置为0)
  对于24-位真彩色图像就不使用彩色板,因为位图中的RGB值就代表了每个象素的颜色。
  如,彩色板为00F8 0000 E007 0000 1F00 0000 0000 0000,其中:
  00F8为F800h = 1111 1000 0000 0000(二进制),是蓝色分量的掩码。
  E007 为 07E0h = 0000 0111 1110 0000(二进制),是绿色分量的掩码。
  1F00为001Fh = 0000 0000 0001 [1]1111(二进制),是红色分量的掩码。
  0000 总设置为0。

  将掩码跟像素值进行“与”运算再进行移位操作就可以得到各色分量值。看看掩码,就可以明白事实上在每个像素值的两个字节16位中,按从高到低取5、6、5位分别就是r、g、b分量值。取出分量值后把r、g、b值分别乘以8、4、8就可以补齐第个分量为一个字节,再把这三个字节按rgb组合,放入存储器(同样要反序),就可以转换为24位标准BMP格式了。

图像数据阵列
  18)55(无调色板)-bfSize:每两个字节表示一个像素。阵列中的第一个字节表示位图左下角的象素,而最后一个字节表示位图右上角的象素。

存储算法
  BMP文件通常是不压缩的,所以它们通常比同一幅图像的压缩图像文件格式要大很多。例如,一个800×600的24位几乎占据1.4MB空间。因此它们通常不适合在因特网或者其它低速或者有容量限制的媒介上进行传输。根据颜色深度的不同,图像上的一个像素可以用一个或者多个字节表示,它由n/8所确定(n是位深度,1字节包含8个数据位)。图片浏览器等基于字节的ASCII值计算像素的颜色,然后从调色板中读出相应的值。更为详细的信息请参阅下面关于位图文件的部分。n位2n种颜色的位图近似字节数可以用下面的公式计算:BMP文件大小约等于 54+4*2的n次方+(w*h*n)/8,其中高度和宽度都是像素数。需要注意的是上面公式中的54是位图文件的文件头,是彩色调色板的大小。另外需要注意的是这是一个近似值,对于n位的位图图像来说,尽管可能有最多2n中颜色,一个特定的图像可能并不会使用这些所有的颜色。由于彩色调色板仅仅定义了图像所用的颜色,所以实际的彩色调色板将小于。如果想知道这些值是如何得到的,请参考下面文件格式的部分。由于存储算法本身决定的因素,根据几个图像参数的不同计算出的大小与实际的文件大小将会有一些细小的差别。

 类似资料:
  • 本文向大家介绍关于图片存储格式的整理(JPEG格式介绍),包括了关于图片存储格式的整理(JPEG格式介绍)的使用技巧和注意事项,需要的朋友参考一下 JPG jpg全名是JPEG 。JPEG 图片以 24 位颜色存储单个光栅图像。JPEG 是与平台无关的格式,支持最高级别的压缩,不过,这种压缩是有损耗的。渐近式 JPEG 文件支持交错。 jpg功能   可以提高或降低 JPEG文件压缩的级别。但是,

  •  吉里吉里/KAG 支持各种各样的图片格式,这些格式各有特色。 BMP 图片  吉里吉里支持无压缩的 BMP 图片格式。吉里吉里中使用的 BMP 不能使用 RLE 圧縮、游戏打包时的压缩也无法很有效的减小容量、但虽然容量很大、BMP 格式图片的读取速度却是最快的。 JPEG 图片  JPEG 、(一般情况下) 是使用了不可逆图片压缩技术的格式。因此、图片一旦转为JPG格式,就无法100%还员原来图

  • 问题内容: 我的内存中有一个位图,我需要将其保存在bmp文件中(使用bmp文件格式)。 有什么办法可以在Android上实现吗? (我读了很多建议使用png格式的文章-这是无损的-但这不是我所需要的:我真的需要 bmp格式 )。 我已经有一些代码使用Bitmap.compress方法将其保存为jpeg或png : 问题答案: (我在回答自己的问题) 这是我目前的解决方案。它是从以下来源派生的:ht

  • 本文向大家介绍C语言实现对bmp格式图片打码,包括了C语言实现对bmp格式图片打码的使用技巧和注意事项,需要的朋友参考一下 相信大家看到上面的标题一定觉的是上面高大上的技术,其实很简单。 前提准备:一张bmp格式的图片,如果没有的话,可以用Windows的画图软件来才裁剪。设置像素大小为(1024,768); 程序原理:将图片读入数组,然后给数组的指定位置存入随机数,最后再写入文件,这样图片就相应

  • 本文向大家介绍delphi实现将BMP格式图形转化为JPG格式图形的方法,包括了delphi实现将BMP格式图形转化为JPG格式图形的方法的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了delphi实现将BMP格式图形转化为JPG格式图形的方法。分享给大家供大家参考。具体实现方法如下: 希望本文所述对大家的Delphi程序设计有所帮助。

  • The Python Imaging Library supports a wide variety of raster file formats. Nearly 30 different file formats can be identified and read by the library. Write support is less extensive, but most common