通过编写程序工具提取.pal调色板文件为Rgb/Yuv分量数据的文本保存

嵌入式ARM 2019-03-28

授权转载自「拿不稳烙铁的嵌入式从业者」(居水)的CSDN
作者更多文章:https://blog.csdn.net/psy6653
原文地址请点击底部
「阅读原文」

作者寄语:自己编写的一个小工具,可能比较偏上层一点,给大家分享下。


一、前言


到做工作记录的时候,本节主要的工作有先保存pal调色板数据位位图,再对位图的数据结构进行分析,再通过源码对数据进行提取,最后通过程序运行进行演示结果。因为Win7和Win10系统保存后的位图存在差异,在编写程序时通过修改宏定义可以解决,同时宽、高也是宏定义配置的。

开发需求:需要添加一种256等级的伪彩条,而且底层FPGA的接口为YVU数据接口,而市场部只给我提供了一个.pal的文件,什么是pal文件,可能相关资料比较少,度娘搜索关键字[pal+空格+调色板]可以看到一部分信息,具体怎样的数据格式没有去深究。任务的输入文件如下图,最终输出为RGB/YVU分量数据的文本数据。



用X86 PC的画图软件打开该文件如下,可以看到是一些颜色渐变的过程,目的就是要把每个颜色等级的数据提取出来。



笔者的思路是把pal文件用X86 PC(Win7和Win10)的画图软件分别保存了24bit BMP格式的位图(其他位的位图没研究过),Win7系统保存完之后如下(Win10同样):



查看这张位图的属性,可以看到一共256个颜色等级,每个等级的颜色宽度为25。satagr_win7为Win7系统保存出来的图片(19K,颜色深度24位)。笔者在Win10系统上也用画图软件也存了一张24Bit的位图,有趣的是与Win7系统转换的位图不一样,satagr_win10为Win10系统用画图软件保存出来的位图(25K,和原始的pal文件一样大,颜色深度32位)。猜想是买个不同操作系统的画图软件编码bmp的实现不一样吧。


用UltrEdit打开该位图,前面54个字节是BMP的标准,可以发现数据是倒着放的(第一行的颜色数据在文件最后,最后一行的数据在文件的开始),如下:


红色框的是最后一个颜色的数据,Win7的颜色深度为24BIt,所以每个像素点颜色BGR每个颜色分量占用一个字节,而每行的颜色以00结束,所以每行的数据为25*3+1个字节大小;而Win10的颜色深度为32Bit,所以每个像素点颜色BGR占用4个字节,没个像素点以BGR的每个分量+FF,每个数据为BGR+FF(00 00 00 FF),在在画图软件中我们可以看到该颜色刚好为位图的最后一个颜色(黑色):


再来验证数据为什么是BGR排布,以及进一步确认数据是倒立放的,直接看位图最开的颜色(红色),数据如下:


数据大小的计算:Win7_data = 54 +(25*3+1)*256 ==  19510字节(0x4C36);Win10_data = 54 + 25*4*256 == 25654字节(0x6436),和Linux系统显示的一致


把对应的十六进制数据换算成十进制,然后在画图软件就行验证,如下:


可以看到:

32(50)  对应的-----------------蓝(U)

0A(10)  对应的-----------------绿(G)

FA(250)对应的-----------------红(R)


所以数据的排列是BGR+FF,同时位图的最开始的颜色数据在文件的最后,因为把这50、10、250三个数据随便怎么调换,只有上图的顺序才是红色。文件数据的格式我们已经知道了,下面就是编写程序提取24Bit 位图数据为RGB数据;

二、程序源码的分享


1、首先开辟一块内存,存放位图的数据


unsigned char* bmpBuf;bmpBuf =  (char*)malloc(BMP_SIZE);if(bmpBuf == NULL){   printf("failed to allocate buff_in_bmp %s, %d\n", __FILE__, __LINE__);   return -1;}
int src_fd = open(INPUT_BMP_PATH, O_RDONLY );if( -1 == src_fd ) { printf("++++++open file failed %s,%d\n", __FILE__, __LINE__); return -1;}int read_size = read( src_fd, bmpBuf, BMP_SIZE);


2、把每行对应的颜色提取成RGB数据,并以文本来保存。注意:①Win7和Win10不同的数据排版,对我们提取并没有影响,只要按照对应格式提取就行;②位图中颜色分量的数据排列顺序是以BGR排列的;③换行符在Linux和Window系统显示是有区别的


char str[25];FILE *fpRgb;if((fpRgb = fopen(OUTPUT_RGB_PATH,"w")) == NULL){   printf("cannot open this file %s, %d\n", __FILE__, __LINE__);   return -1;int i;for(i = 0; i< 256; i++){           sprintf(str,"\{%d, %d, %d\}\,",bmpBuf[54+i*BMP_PER_LINE_BYTE+2],bmpBuf[54+i*BMP_PER_LINE_BYTE+1],bmpBuf[54+i*BMP_PER_LINE_BYTE]);           if(fputs(str,fpRgb) == '\0'){             printf("cannot open file %s, %d\n", __FILE__, __LINE__);             return -1;             } #ifdef LINUX    fputs("\n",fpRgb);#else   fputs("\r\n",fpRgb);#endif}fclose(fpRgb);


即在Linux输出文本的换行符用

fputs("\n",fpRgb);


即在Windows输出文本的换行符用


fputs("\r\n",fpRgb);


保存出来的文本形式如下:


为什么要保存成这样的格式呢,因为我的需求是一个二维的数据,如下:


如果想要其他格式的数据可以用sprintf函数自行构造。当 “{” 与 “,”的格式与程序不匹配,可以用vim工具进行批量替换,指令是【:%s/被替换者/替换者/g】,演示如下:



3、把对应的RGB数据保存为YVU数据分量的文本,其中RGB转YVU的公式度娘上大把:


FILE *fpYuv;unsigned char y , u, v, r, g, b;if((fpYuv = fopen(OUTPUT_YUV_PATH,"w")) == NULL){         printf("cannot open this file %s, %d\n", __FILE__, __LINE__);         return -1;}        for(i = 0; i< 256; i++){         r = bmpBuf[54+i*BMP_PER_LINE_BYTE+2];          g = bmpBuf[54+i*BMP_PER_LINE_BYTE+1];         b = bmpBuf[54+i*BMP_PER_LINE_BYTE];                   y = ((77*r+150*g+29*b)>>8);         u = ((-43*r-85*g+128*b)>>8)+128;         v = ((128*r-107*g-21*b)>>8)+128;                  sprintf(str,"\{%d, %d, %d\}\,",y,u,v);         if(fputs(str,fpYuv) == '\0'){            printf("cannot open file  %s, %d\n", __FILE__, __LINE__);            return -1;         }#ifdef LINUX   fputs("\n",fpYuv);#else   fputs("\r\n",fpYuv);#endif}fclose(fpYuv);


以上就为整个main函数的内容,最主分享的一个思路,有基础的朋友一看就明白。是在不清楚的可以下载我上传的源码:


https://download.csdn.net/download/psy6653/11066072

(包括原始pal文件以及2种颜色深度位图)


源码可以通过宏定义确定是要Windows文本还是Linux文本格式,也可以通过修改一个宏定义,同时适合Win7(24位深度)和Win10(32位深度)所转换的位图,数据的宽高可以通过修改宏定义来实现。



三、实验结果


1、可以看到两种位图生成的RGB分量形式和YUV分量形式保存的文本是一致的。


2、分享下在嵌入式平台运行的结果,右边的伪彩条跟pal文件在画图工具显示的一致。



嵌入式ARM 关注这个时代最火的嵌入式ARM,你想知道的都在这里。
评论
热门推荐
相关推荐
我要评论
0
1
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦