BMP图象解析

 

BMP图象解析


作者:南京邮电大学 吴登荣

下载源代码


摘    要:对BMP图象格式进行解析,本工程在WinXP+VC6.0下编译运行成功。

关 键 字:BMP格式

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

一、BMP文件头
BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。其结构定义如下:

typedef struct tagBITMAPFILEHEADER
{
    WORD bfType;   // 位图文件的类型,必须为BM
    DWORD   bfSize;   // 位图文件的大小,以字节为单位
    WORD bfReserved1;  // 位图文件保留字,必须为0
    WORD bfReserved2;  // 位图文件保留字,必须为0
    DWORD   bfOffBits; // 位图数据的起始位置,以相对于位图文件头的偏移量表示,以字节为单位
} BITMAPFILEHEADER;
 

二、位图信息头
BMP位图信息头数据用于说明位图的尺寸等信息。其结构定义如下:

typedef struct tagBITMAPINFOHEADER
{
  DWORD  biSize;   // 本结构所占用字节数
  LONG biWidth;  // 位图的宽度,以像素为单位
  LONG biHeight; // 位图的高度,以像素为单位
  WORD   biPlanes; // 目标设备的级别,必须为1
  WORD   biBitCount// 每个像素所需的位数,必须是1(双色),4(16色),8(256色)或24(真彩色)之一
  DWORD  biCompression;   // 位图压缩类型,必须是 0(不压缩),1(BI_RLE8压缩类型)或2(BI_RLE4压缩类型)之一
  DWORD  biSizeImage; // 位图的大小,以字节为单位
  LONG biXPelsPerMeter; // 位图水平分辨率,每米像素数
  LONG biYPelsPerMeter;  // 位图垂直分辨率,每米像素数
  DWORD  biClrUsed;// 位图实际使用的颜色表中的颜色数
  DWORD  biClrImportant;// 位图显示过程中重要的颜色数
} BITMAPINFOHEADER;  

三、颜色表和位图信息
颜色表用于说明位图中的颜色,有若干个表项,每一个表项是一个RGBQUAD类型的结构,定义一种颜色。RGBQUAD结构的定义如下:

typedef struct tagRGBQUAD 
{
  BYTErgbBlue;// 蓝色的亮度(值范围为0-255)
  BYTErgbGreen;   // 绿色的亮度(值范围为0-255)
  BYTErgbRed; // 红色的亮度(值范围为0-255)
  BYTErgbReserved;// 保留,必须为0
} RGBQUAD; 

位图信息头和颜色表组成位图信息,BITMAPINFO结构定义如下:

typedef struct tagBITMAPINFO 

{
  BITMAPINFOHEADER bmiHeader;   // 位图信息头
  RGBQUAD  bmiColors[1];  // 颜色表
} BITMAPINFO;
四、数据读取和颜色分离
Bmp文件有个重要特性,那就是对于数据区域而言,每行的数据它必须凑满4字节,如果没有满,则用冗余的数据来补齐。这个特性直接影响到我们读取位图数据的方法,因为在我们看来(x,y)的数据应该在 y*width+x这样的位置上 但是因为会有冗余信息 那么必须将width用width+该行的冗余量来处理,而由于位图文件有不同的位数,所以这样的计算也不尽相同。

1位:
  for(int i=0; i<height; i++)
    for(int j=0; j<width; j=j+8)
    {
      int k=7;
      while(k>=0)
      {
        color[i][k+j]=buffer[n]%2;
        buffer[n]=buffer[n]/2;
        k--;
      }
    n++;
    }
4位:
          int pitch;
  if(width%8==0)
    pitch=width;
  else
    pitch=width+8-width%8;
    for(int i=0; i<height; i++)
    for(int j=0; j<width; j++)
  {
    int index;
    if(j%2==0)
      index = buffer[(i*pitch+j)/2]/16;
    if(j%2==1)
      index = buffer[(i*pitch+j)/2]%16;
    UCHAR r=quad[index].rgbRed;
    UCHAR g=quad[index].rgbGreen;
    UCHAR b=quad[index].rgbBlue;

8位:
int  pitch;
if(width%4==0)
  {
    pitch=width;
  }
  else
  {
    pitch=width+4-width%4;
  }
  index=buffer[y*pitch+x]; //因为8位位图的数据区域存放的是调色板索引值,所以只需读取这个index


  颜色分离:
  UCHAR r=quad[index].rgbRed;

  UCHAR g=quad[index].rgbGreen;

  UCHAR b=quad[index].rgbBlue;

16位:
 

  int pitch=width+width%2;
  buffer[(y*pitch+x)*2] 
  buffer[(y*pitch+x)*2+1]

  两个UCHAR内,存放的是(x,y)处的颜色信息

  颜色分离:

    1.若bitmapinfoheader中的biCompression为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;


    2.若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;


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];

  颜色分离:
  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位:
  由于一个象素就是4字节 所以无需补齐

  颜色分离:

  UCHAR b=buffer[(i*width+j)*4];
  UCHAR g=buffer[(i*width+j)*4+1];
  UCHAR r=buffer[(i*width+j)*4+2];

备    注:详细具体细节见工程内源码,运行后打开BMP图即可,解析代码在OnDraw()中。
### 解决 Dify 和 Ragflow 端口冲突的方法 当在同一台服务器上同时启动 Dify 和 Ragflow 时,可能会遇到 Redis 容器间的端口冲突问题。为了确保这两个应用能够顺利共存并正常工作,有几种有效的解决方案。 #### 方法一:指定 Docker Compose 的项目名称 如果不显式设置 Docker Compose 文件中的 `project_name` 参数,则默认情况下所有服务都会被放置在一个名为当前目录名的命名空间下。这可能导致不同应用程序之间存在资源竞争的情况。因此,在各自的 docker-compose.yml 中加入如下配置来区分各个项目的实例: ```yaml version: '3' services: ... # 添加此行以定义唯一的项目前缀 x-project-name: &project_name my_unique_project_prefix_ ``` 这样做之后,即使两个 compose 文件位于同一主机的不同路径下也不会发生冲突[^1]。 #### 方法二:调整 Redis 实例监听地址及端口号 为了避免直接暴露内部网络接口给外部访问带来的安全隐患以及简化防火墙规则管理等问题,建议修改每个 Redis 实例所绑定的具体 IP 地址及其对应的宿主机映射端口。对于 ragflow 可保持原有设定不变;而对于 dify 则需更改其对外提供服务的 TCP 端点至其他可用数值(如6380),具体操作方式是在相应的 service 配置项里增加或替换原有的 port 映射声明: ```yaml services: redis: image: redis:alpine container_name: dify_redis_container ports: - "6380:6379" ``` 上述改动使得客户端连接到本地机器上的 6380 即可触达该容器内的数据库引擎[^3]。 通过实施这些策略,可以有效地防止由于共享相同物理硬件而导致的服务间相互影响现象的发生,并保障各自独立稳定地运作环境[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值