数据恢复工程师深度拆解BMP文件格式

简介: BMP是一种与硬件设备无关的图像文件格式,使用非常广。它采用位映射存储格式,除了图像深度可选以外,不采用其他任何压缩,因此,BblP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。
+关注继续查看

BMP是一种与硬件设备无关的图像文件格式,使用非常广。它采用位映射存储格式,除了图像深度可选以外,不采用其他任何压缩,因此,BblP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。BMP文件存储数据时,图像的扫描方式是按从左到右、从下到上的顺序。
由于BMP文件格式是Windows环境中交换与图有关的数据的一种标准,因此在Windows环境中运行的图形图像软件都支持BMP图像格式。
典型的BMP图像文件由三部分组成:位图文件头数据结构,它包含BMP图像文件的类型、显示内容等信息;位图信息数据结构,它包含有BMP图像的宽、高、压缩方法,以及定义颜色等信息。
具体数据举例:
2


如某BMP文件开头:
424D 4690 0000 0000 0000 4600 0000 2800 0000 8000 0000 9000 0000 01001000 0300 0000 0090 0000 A00F 0000 A00F 0000 0000 0000 0000 000000F8 0000 E007 0000 1F00 0000 0000 0000*02F1 84F1 04F1 84F1 84F1 06F2 84F1 06F2 04F2 86F2 06F2 86F2 86F2 …. ….

BMP文件可分为四个部分:位图文件头、位图信息头、彩色板、图像数据阵列,在上图中已用*分隔。
一、图像文件头 
 1)1:图像文件头。424Dh=”BM”,表示是Windows支持的BMP格式。
 2)2-3:整个文件大小。4690 0000,为00009046h=36934。
 3)4-5:保留,必须设置为0。
 4)6-7:从文件开始到位图数据之间的偏移量。4600 0000,为00000046h=70,上面的文件头就是35字=70字节。
 5)8-9:位图图信息头长度。
 6)10-11:位图宽度,以像素为单位。8000 0000,为00000080h=128。
 7)12-13:位图高度,以像素为单位。9000 0000,为00000090h=144。
8)14:位图的位面数,该值总是1。0100,为0001h=1。
二、位图信息头 
9)15:每个像素的位数。有1(单色),4(16色),8(256色),16(64K色,高彩色),24(16M色,真彩色),32(4096M色,增强型真彩色)。1000为0010h=16。
10)16-17:压缩说明:有0(不压缩),1(RLE 8,8位RLE压缩),2(RLE 4,4位RLE压缩,3(Bitfields,位域存放)。RLE简单地说是采用像素数+像素值的方式进行压缩。T408采用的是位域存放方式,用两个字节表示一个像素,位域分配为r5b6g5。图中0300 0000为00000003h=3。
11)18-19:用字节数表示的位图数据的大小,该数必须是4的倍数,数值上等于位图宽度×位图高度×每个像素位数。0090 0000为00009000h=80×90×2h=36864。
12)20-21:用象素/米表示的水平分辨率。A00F 0000为0000 0FA0h=4000。
13)22-23:用象素/米表示的垂直分辨率。A00F 0000为0000 0FA0h=4000。
14)24-25:位图使用的颜色索引数。设为0的话,则说明使用所有调色板项。
15)26-27:对图象显示有重要影响的颜色索引的数目。如果是0,表示都重要。
三、彩色板 (非必有)
16)28-35:彩色板规范。对于调色板中的每个表项,用下述方法来描述RGB的值:
1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
对于24-位真彩色图像就不使用彩色板,因为位图中的RGB值就代表了每个象素的颜色。
如,彩色板为00F8 0000 E007 0000 1F00 0000 0000 0000,其中:
00FB 0000为FB00h=1111100000000000(二进制),是红色分量的掩码。
E007 0000为 07E0h=0000011111100000(二进制),是绿色分量的掩码。
1F00 0000为001Fh=0000000000011111(二进制),是红色分量的掩码。
0000 0000总设置为0。
将掩码跟像素值进行“与”运算再进行移位操作就可以得到各色分量值。看看掩码,就可以明白事实上在每个像素值的两个字节16位中,按从高到低取5、6、5位分别就是r、g、b分量值。取出分量值后把r、g、b值分别乘以8、4、8就可以补齐第个分量为一个字节,再把这三个字节按rgb组合,放入存储器(同样要反序),就可以转换为24位标准BMP格式了。
四、图像数据阵列 
17)17-...:每两个字节表示一个像素。阵列中的第一个字节表示位图左下角的象素,而最后一个字节表示位图右上角的象素。
下面用winhex打开一个bmp文件,察看其16进制数据。
一个bmp文件以BITMAPFILEHEADER结构体开始,BITMAPFILEHEADER #frombyte.com的第1个属性是bfType(2字节),这里恒定等于0x4D42。由于内存中的数据排列高位在左,低位在右,所以内存中从左往右看就显示成(42 4D),所以在winhex中头两个 字节显示为(42 4D)就是这样形成的,以后的数据都是这个特点,不再作重复说明。
BITMAPFILEHEADER的第2个属性是bfSize(4字节),表示整个bmp文件的大小,这里等于0x000004F8=1272字节。
BITMAPFILEHEADER的第3个、第4个属性分别是bfReserved1、bfReserved2(各2字节),这里是2个保留属性,都为0,这里等于&H0000、0×0000。
BITMAPFILEHEADER的第5个属性是bfOffBits(4字节),表示DIB数据区在bmp文件中的位置偏移量,这里等于0×00000076=118,表示数据区从文件开始往后数的118字节开始。
BITMAPFILEHEADER结构体这里就讲完了,大家会发现BITMAPFILEHEADER只占了bmp文件开始的14字节长度,但需要 特别说明的是在vb中定义一个BITMAPFILEHEADER(#frombyte.com)结构体变量,其长度占了16个字节,原因就是第1个属性本来应该只分配2个字节,但实际被 分配了4个字节,多出来2个字节,所以如果想保存一张bmp图片,写入BITMAPFILEHEADER结构体时一定要注意这一点。
接下来是BITMAPINFO结构体部分。BITMAPINFO段由两部分组成:BITMAPINFOHEADER结构体和RGBQUAD结构 体。其中RGBQUAD结构体表示图片的颜色信息,有些时候可以省略,一般的24位图片和32位图片都不带RGBQUAD结构体,因为DIB数据区直接表 示的RGB值,一般4位图片和8位图片才带有RGBQUAD结构体。(多少位的图片就是用多少位来表示一个颜色信息,例如4位图片表示用4个bit来表示 一个颜色信息。)一个bmp文件中有没有RGBQUAD结构体,可以根据前面BITMAPFILEHEADER结构体的第5个属性bfOffBits来判 断,因为BITMAPINFOHEADER结构体长度为40bit,如果BITMAPINFOHEADER结构体结束后还未到DIB数据区的偏移量,就说 明接下来的数据是RGBQUAD结构体部分。这里讲的C:\WINDOWS\Blue Lace 16.bmp是一个4bit图片,所以它带有 RGBQUAD结构体。
下面进入正题BITMAPINFOHEADER部分。
BITMAPINFOHEADER的第1个属性是biSize(4字节),表示BITMAPINFOHEADER结构体的长度,最常见的长度是40字节,UltraEdit中可以看到紧接着的4个字节等于0×00000028=40字节。
BITMAPINFOHEADER(#frombyte.com)的第2个属性是biWidth(4字节),表示bmp图片的宽度,这里等于0×00000030=48像素。
BITMAPINFOHEADER的第3个属性是biHeight(4字节),表示bmp图片的高度,这里等于0×00000030=48像素。
BITMAPINFOHEADER的第4个属性是biPlanes(2字节),表示bmp图片的平面属,显然显示器只有一个平面,所以恒等于1,这里等于0×0001。
BITMAPINFOHEADER的第5个属性是biBitCount(2字节),表示bmp图片的颜色位数,即24位图、32位图等等。这里等于0×0004,表示该图片为4位图。
BITMAPINFOHEADER的第6个属性是biCompression(4字节),表示图片的压缩属性,bmp图片是不压缩的,等于0,所以这里为0×00000000。
BITMAPINFOHEADER的第7个属性是biSizeImage(4字节),表示bmp图片数据区的大小,当上一个熟悉biCompression等于0时,这里的值可以省略不填,所以这里等于0×00000000。
BITMAPINFOHEADER的第8个属性是biXPelsPerMeter(4字节),表示图片X轴每米多少像素,可省略,这里等于0x00000EC3=3779像素/米。
BITMAPINFOHEADER的第9个属性是biYPelsPerMeter(4字节),表示图片Y轴每米多少像素,可省略,这里等于0x00000EC3=3779像素/米。
BITMAPINFOHEADER的第10个属性是biClrUsed(4字节),表示使用了多少个颜色索引表,一般biBitCount属性小于16才会用到,等于0时表示有2^biBitCount个颜色索引表,所以这里仍等于0×00000000。
BITMAPINFOHEADER的第11个属性是biClrImportant(4字节),表示有多少个重要的颜色,等于0时表示所有颜色都很重要,所以这里等于0×00000000。
至此BITMAPINFOHEADER结构体结束。
由于这个图片到这里还未到达DIB数据区的偏移量,所以接下来的部分是RGBQUAD结构体。RGBQUAD(#frombyte.com)结构体由4个字节型数据组成,所以一 个RGBQUAD结构体只占用4字节空间,从左到右每个字节依次表示(蓝色,绿色,红色,未使用)。举例的这个图片我数了数总共有16个RGBQUAD结 构体,由于该图片是4位图,2^4正好等于16,所以它把16种颜色全部都枚举出来了,这些颜色就是一个颜色索引表。颜色索引表编号从0开始,总共16个 颜色,所以编号为0-15。从winhex中可以看到按照顺序,这16个RGBQUAD结构体依次为:
编号:(蓝,绿,红,空)
0号:(00,00,00,00)
1号:(00,00,80,00)
2号:(00,80,00,00)
3号:(00,80,80,00)
4号:(80,00,00,00)
5号:(80,00,80,00)
6号:(80,80,00,00)
7号:(80,80,80,00)
8号:(C0,C0,C0,00)
9号:(00,00,FF,00)
10号:(00,FF,00,00)
11号:(00,FF,FF,00)
12号:(FF,00,00,00)
13号:(FF,00,FF,00)
14号:(FF,FF,00,00)
15号:(FF,FF,FF,00)
为了更直观的表示这些颜色,可以见后面的图片。
到这里,正好满足DIB数据区的偏移量,所以后面的字节就是图片内容了。这里需要提醒的是所有的DIB数据扫描行是上下颠倒的,也就是说一幅图片先绘制底部的像素,再绘制顶部的像素,所以这些DIB数据所表示的像素点就是从图片的左下角开始,一直表示到图片的右上角。
由于这里的图片是4位图片,也就是说4bit就表示一个像素,一个字节有8个bit,所以一个字节能表示2个像素。
从winhex中可以看到,DIB数据区第一个字节是0×44,16进制正好是将2进制数每4个一组书写的,跟4bit图片正好吻 合,所以0×44表示两个像素,高位的4表示第一个像素,低位的4表示第二个像素。这里的4不是表示RGB颜色,而是表示颜色索引号为4,由于索 引号从0开始编号的,所以4表示索引表中第5个颜色,从附图中可以看到索引号为4的是蓝色。这是第一字节,表示的是图片左下角开始2个像素,如果有 PhotoShop打开这个图片可以看到,左下角2个像素取出来的颜色RGB值正好等于索引表中第5个颜色的RGB值。后面的DIB数据以此类推。
相关文章
|
4天前
|
存储 数据采集 固态存储
带三维重建和还原功能的医学影像管理系统(pacs)源码
带三维重建和还原功能的医学影像管理系统(pacs)源码
29 0
|
4月前
|
存储 固态存储 数据管理
PACS源码 带三维重建和还原 自主研发
C/S架构的PACS系统源码,PACS主要进行病人信息和影像的获取、处理、存储、调阅、检索、管理,并通过网络向全院提供病人检查影像及诊断报告;各影像科室之间共享不同设备的病人检查影像及诊断报告;在诊断工作站上,调阅HIS中病人的其它信息 (如: 病人信息、病历信息、医嘱、检验信息等)。
PACS源码 带三维重建和还原 自主研发
|
6月前
|
XML 安全 Java
【解决方案 十二】一文彻底解决文件格式判别问题
【解决方案 十二】一文彻底解决文件格式判别问题
135 0
【解决方案 十二】一文彻底解决文件格式判别问题
|
8月前
|
存储 编解码 搜索推荐
PACS系统源码(医学图像存储与传输)支持三维重建与还原
影像阅片 影像阅片是PACS最核心的部分,主要用来给医生提供调阅影像和影像处理,基础功能一般厂商都有,比如序列、旋转、放大缩小、标注、窗宽调整、四角信息设置、定位线、比例尺、测量、裁剪、伪彩等等,三维重建是一个亮点功能,很多厂商目前由于技术瓶颈尚未实现。这套PACS系统源码是带三维重建和还原的,是符合市场需求的PACS系统。
136 0
PACS系统源码(医学图像存储与传输)支持三维重建与还原
|
数据采集 Arthas 运维
日志瘦身方法论
在日常开发中,通常为了方便调试、方便查问题,会打印很多 INFO 级别的日志。 随着访问量越来越大,一不小心,某个日志文件一天的 size 就大于了某个阈值(如 5G),于是,收到了优化日志大小的告警,一定时间内不优化反馈给你主管,囧... 日志过大容易导致一些运维操作消耗机器性能,如日志文件检索、数据采集、磁盘清理等。而且,打印一些没必要的日志也会造成磁盘的浪费。因此,优化势在必行。 那么,日志瘦身哪些常
292 0
日志瘦身方法论
|
编解码 移动开发 视频直播
一文详解 m3u8 视频格式与分析视频秒开优化
秒开指的是,一秒内成功加载的播放数/播放总数。本意是想对比一下m3u8与mp4视频格式,并了解m3u8格式优缺点,以确定一个大概优化方向。但对m3u8做简单了解后,觉的m3u8可能是一个优化方向。
8719 1
|
前端开发 数据挖掘
前端图片合并方案调研
通过产品线数据分析,发现70%左右的图片为小于300K的图片,50%左右为小于100K的图片,因此调研前端图片合并方案是否有利于提高图片批量上传速度。之前做过的前端ZIP方案也是类似的思路。
188 0
|
Web App开发 移动开发 监控
文件批量上传ZIP方案调研
利用HTML5的新接口例如ArrayBuffer、Blob等可以在前端进行zip操作并且可以将zip后的文件上传到服务器。本调研主要关注zip方案的zip效率以及整体上传效率。
205 0
文件批量上传ZIP方案调研
|
缓存 Dart 前端开发
AliFlutter图片解决方案与优化
Flutter与Native混合开发将是接下来很长时间的主流开发方式。一套稳定、高效、与官方体系无缝融合的外接图片缓存方案是必不可少的。在AliFlutter系列第三场直播中,由阿里巴巴新零售淘系技术部无线开发专家王乾元为大家介绍AliFlutter提供的适合混合应用的外接图片库方案。首先对Flutter官方原生方案进行了分析,并提出了AliFlutter方案的切入点以及具体优化手段。
3006 0
AliFlutter图片解决方案与优化
|
存储 数据挖掘 Shell
GATK 软件分析流程
GATK 软件分析流程由阿里云和 Broad Institute 合作提供。Broad Institute 提供的 GATK 流程最佳实践用 工作流定义语言(WDL) 编写,通过批量计算集成的 Cromwell 工作流引擎解析执行。用户将为作业运行时实际消耗的计算和存储资源付费,不需要支付资源之外的附加费用。 Broad Institute GATK 网站和论坛为 GATK 工具和 WDL 提供了更完整的背景信息,文档和支持。 如果需要执行用 WDL 编写的通用工作流程,请参考 cromwell 工作流引擎和 WDL 支持的 APP 。
1601 0
GATK 软件分析流程
相关产品
云迁移中心
推荐文章
更多