通過編寫程序工具提取.pal調(diào)色板文件為Rgb/Yuv分量數(shù)據(jù)的文本保存

授權(quán)轉(zhuǎn)載自「拿不穩(wěn)烙鐵的嵌入式從業(yè)者」（居水）的CSDN
作者更多文章：https://blog.csdn.net/psy6653
原文地址請點(diǎn)擊底部「閱讀原文」

作者寄語：自己編寫的一個小工具，可能比較偏上層一點(diǎn)，給大家分享下。

編輯：付斌

一、前言

到做工作記錄的時候，本節(jié)主要的工作有先保存pal調(diào)色板數(shù)據(jù)位位圖，再對位圖的數(shù)據(jù)結(jié)構(gòu)進(jìn)行分析，再通過源碼對數(shù)據(jù)進(jìn)行提取，最后通過程序運(yùn)行進(jìn)行演示結(jié)果。因?yàn)閃in7和Win10系統(tǒng)保存后的位圖存在差異，在編寫程序時通過修改宏定義可以解決，同時寬、高也是宏定義配置的。

開發(fā)需求：需要添加一種256等級的偽彩條，而且底層FPGA的接口為YVU數(shù)據(jù)接口，而市場部只給我提供了一個.pal的文件，什么是pal文件，可能相關(guān)資料比較少，度娘搜索關(guān)鍵字[pal+空格+調(diào)色板]可以看到一部分信息，具體怎樣的數(shù)據(jù)格式?jīng)]有去深究。任務(wù)的輸入文件如下圖，最終輸出為RGB/YVU分量數(shù)據(jù)的文本數(shù)據(jù)。

用X86 PC的畫圖軟件打開該文件如下，可以看到是一些顏色漸變的過程，目的就是要把每個顏色等級的數(shù)據(jù)提取出來。

筆者的思路是把pal文件用X86 PC（Win7和Win10）的畫圖軟件分別保存了24bit BMP格式的位圖（其他位的位圖沒研究過），Win7系統(tǒng)保存完之后如下（Win10同樣）：

查看這張位圖的屬性，可以看到一共256個顏色等級，每個等級的顏色寬度為25。satagr_win7為Win7系統(tǒng)保存出來的圖片（19K，顏色深度24位）。筆者在Win10系統(tǒng)上也用畫圖軟件也存了一張24Bit的位圖，有趣的是與Win7系統(tǒng)轉(zhuǎn)換的位圖不一樣，satagr_win10為Win10系統(tǒng)用畫圖軟件保存出來的位圖（25K，和原始的pal文件一樣大，顏色深度32位）。猜想是買個不同操作系統(tǒng)的畫圖軟件編碼bmp的實(shí)現(xiàn)不一樣吧。

用UltrEdit打開該位圖，前面54個字節(jié)是BMP的標(biāo)準(zhǔn)，可以發(fā)現(xiàn)數(shù)據(jù)是倒著放的（第一行的顏色數(shù)據(jù)在文件最后，最后一行的數(shù)據(jù)在文件的開始），如下：

紅色框的是最后一個顏色的數(shù)據(jù)，Win7的顏色深度為24BIt，所以每個像素點(diǎn)顏色BGR每個顏色分量占用一個字節(jié)，而每行的顏色以00結(jié)束，所以每行的數(shù)據(jù)為25*3+1個字節(jié)大??；而Win10的顏色深度為32Bit，所以每個像素點(diǎn)顏色BGR占用4個字節(jié)，沒個像素點(diǎn)以BGR的每個分量+FF，每個數(shù)據(jù)為BGR+FF(00 00 00 FF)，在在畫圖軟件中我們可以看到該顏色剛好為位圖的最后一個顏色（黑色）：

再來驗(yàn)證數(shù)據(jù)為什么是BGR排布，以及進(jìn)一步確認(rèn)數(shù)據(jù)是倒立放的，直接看位圖最開的顏色（紅色），數(shù)據(jù)如下：

數(shù)據(jù)大小的計算：Win7_data = 54 +（25*3+1）*256 ==  19510字節(jié)(0x4C36)；Win10_data = 54 + 25*4*256 == 25654字節(jié)(0x6436)，和Linux系統(tǒng)顯示的一致

把對應(yīng)的十六進(jìn)制數(shù)據(jù)換算成十進(jìn)制，然后在畫圖軟件就行驗(yàn)證，如下：

可以看到：
32（50）  對應(yīng)的-----------------藍(lán)（U）
0A（10）  對應(yīng)的-----------------綠（G）
FA（250）對應(yīng)的-----------------紅（R）

所以數(shù)據(jù)的排列是BGR+FF，同時位圖的最開始的顏色數(shù)據(jù)在文件的最后，因?yàn)榘堰@50、10、250三個數(shù)據(jù)隨便怎么調(diào)換，只有上圖的順序才是紅色。文件數(shù)據(jù)的格式我們已經(jīng)知道了，下面就是編寫程序提取24Bit 位圖數(shù)據(jù)為RGB數(shù)據(jù)；

二、程序源碼的分享

1、首先開辟一塊內(nèi)存，存放位圖的數(shù)

2、把每行對應(yīng)的顏色提取成RGB數(shù)據(jù)，并以文本來保存。注意：①Win7和Win10不同的數(shù)據(jù)排版，對我們提取并沒有影響，只要按照對應(yīng)格式提取就行；②位圖中顏色分量的數(shù)據(jù)排列順序是以BGR排列的；③換行符在Linux和Window系統(tǒng)顯示是有區(qū)別的

即在Linux輸出文本的換行符用

fputs("n",fpRgb);

即在Windows輸出文本的換行符用

fputs("rn",fpRgb);

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

為什么要保存成這樣的格式呢，因?yàn)槲业男枨笫且粋€二維的數(shù)據(jù)，如下：

如果想要其他格式的數(shù)據(jù)可以用sprintf函數(shù)自行構(gòu)造。當(dāng) “{” 與 “，”的格式與程序不匹配，可以用vim工具進(jìn)行批量替換，指令是【：%s/被替換者/替換者/g】，演示如下：

3、把對應(yīng)的RGB數(shù)據(jù)保存為YVU數(shù)據(jù)分量的文本，其中RGB轉(zhuǎn)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, %dn", __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) == '?'){            printf("cannot open file  %s, %dn", __FILE__, __LINE__);            return -1;         }#ifdef LINUX   fputs("n",fpYuv);#else   fputs("rn",fpYuv);#endif}fclose(fpYuv);

以上就為整個main函數(shù)的內(nèi)容，最主分享的一個思路，有基礎(chǔ)的朋友一看就明白。是在不清楚的可以下載我上傳的源碼：

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

（包括原始pal文件以及2種顏色深度位圖）

源碼可以通過宏定義確定是要Windows文本還是Linux文本格式，也可以通過修改一個宏定義，同時適合Win7（24位深度）和Win10（32位深度）所轉(zhuǎn)換的位圖，數(shù)據(jù)的寬高可以通過修改宏定義來實(shí)現(xiàn)。

三、實(shí)驗(yàn)結(jié)果

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

2、分享下在嵌入式平臺運(yùn)行的結(jié)果，右邊的偽彩條跟pal文件在畫圖工具顯示的一致。