簡(jiǎn)介這是一份面向C語(yǔ)言學(xué)習(xí)者和圖像處理開(kāi)發(fā)者的圖片格式轉(zhuǎn)換工程圍繞PNG與JPEG轉(zhuǎn)BMP的核心任務(wù)同時(shí)涵蓋圖片縮放、旋轉(zhuǎn)等常見(jiàn)操作。工程基于VC6.0開(kāi)發(fā)包含完整C語(yǔ)言源碼、libpng與jpeglib庫(kù)文件、頭文件及可執(zhí)行程序壓縮包共243個(gè)文件約14.15MB目錄按源碼、庫(kù)、示例圖片和工程配置分類既有16張測(cè)試用PNG/JPG原圖也有轉(zhuǎn)換后的BMP結(jié)果及配套音頻素材便于直接運(yùn)行和對(duì)照驗(yàn)證。目前已有2646人學(xué)習(xí)下載。通過(guò)學(xué)習(xí)這套源碼可以掌握PNG的IHDR/IDAT塊解析、JPEG的DCT與量化解碼流程、BMP文件頭及像素?cái)?shù)據(jù)的寫入規(guī)則如4字節(jié)行對(duì)齊以及最近鄰插值、雙線性插值和仿射變換等圖像處理算法的C語(yǔ)言實(shí)現(xiàn)從解碼到編碼全流程均有代碼呈現(xiàn)。對(duì)于準(zhǔn)備課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或想深入理解圖像編碼原理、文件I/O與內(nèi)存操作的開(kāi)發(fā)者這是一份可直接參考的完整實(shí)例。1. 用 C 語(yǔ)言實(shí)現(xiàn) PNG/JPEG 轉(zhuǎn) BMP為什么說(shuō)是件反直覺(jué)的苦差事圖片格式轉(zhuǎn)換這件事表面上是“讀文件、改個(gè)頭、寫文件”實(shí)際做起來(lái)才發(fā)現(xiàn) BMP 這個(gè)“最笨”的格式反而是照妖鏡。PNG 有濾波、有 zlib 壓縮、有 Adam7 隔行JPEG 有 Huffman 表、有量化矩陣、有 4:2:0 色度抽樣而 BMP 只認(rèn)原始像素?cái)?shù)組。把前面兩種格式解碼成原始 RGB 再交給 BMP等于把一個(gè)圖片格式轉(zhuǎn)換工具做成了“半個(gè)解碼器”。很多人在網(wǎng)上找現(xiàn)成的 C 語(yǔ)言轉(zhuǎn)換源碼包下載后一跑就花屏、偏色、錯(cuò)行根本不是代碼寫錯(cuò)而是對(duì)格式規(guī)范理解得不到位。這篇文章拿一份具體的轉(zhuǎn)換工程拆解來(lái)龍去脈從解碼管線到 BMP 落盤細(xì)節(jié)再到三類高頻踩坑記錄。適合嵌入式開(kāi)發(fā)者、圖像算法入門者以及所有想在 C 語(yǔ)言層面徹底搞懂圖片格式的人。新手能照步驟跑通熟手可以跳過(guò)基礎(chǔ)部分直接看邊界和參數(shù)坑。2. 拆開(kāi)這份轉(zhuǎn)換工程文件構(gòu)成與整體管線拿到一份號(hào)稱“C 語(yǔ)言實(shí)現(xiàn) PNG/JPEG 轉(zhuǎn) BMP”的資源第一件事不是打開(kāi) main.c而是把整個(gè)目錄結(jié)構(gòu)摸清。源碼包的質(zhì)量從文件組織方式就能看出一大半很多 GitHub 上隨手傳的工程只有一兩個(gè) .c 文件里面塞了上千行裸代碼真要去改一個(gè)參數(shù)要翻半天。這份工程屬于能直接動(dòng)手復(fù)現(xiàn)的類型各個(gè)模塊分得比較干凈下面逐個(gè)細(xì)說(shuō)。2.1 目錄結(jié)構(gòu)哪些文件是核心哪些是輔助先看整體組織典型的劃分方式是把解碼器、編碼器、公共工具、入口邏輯分開(kāi)。以下目錄結(jié)構(gòu)是工程里最常見(jiàn)、也最值得保留的一種組織方式converter/ ├── src/ │ ├── main.c # 入口解析命令行參數(shù)調(diào)度轉(zhuǎn)換流程 │ ├── png_decoder.c/h # PNG 解碼IDAT 解壓、濾波反解、顏色轉(zhuǎn)換 │ ├── jpeg_decoder.c/h # JPEG 解碼Huffman 解碼、反量化、逆 DCT │ ├── bmp_writer.c/h # BMP 編碼文件頭、信息頭、像素?cái)?shù)據(jù)落盤 │ └── common.c/h # 公共工具文件讀寫、內(nèi)存分配、錯(cuò)誤碼定義 ├── test/ │ ├── sample_png/ # 各種 color type 的 PNG 測(cè)試圖 │ ├── sample_jpeg/ # 各種抽樣方式的 JPEG 測(cè)試圖 │ └── verify.py # 像素級(jí)對(duì)比腳本 └── Makefile這里最關(guān)鍵的是 png_decoder 和 jpeg_decoder這兩個(gè)模塊決定了轉(zhuǎn)換質(zhì)量。main.c 里沒(méi)有放任何解碼邏輯只做參數(shù)解析和流程編排這種寫法值得借鑒。很多初學(xué)者寫的轉(zhuǎn)換工具把所有代碼堆在 main 函數(shù)里最后連自己都分不清哪一段是濾波反解、哪一段是顏色空間轉(zhuǎn)換。有幾個(gè)工程還帶了進(jìn)階擴(kuò)展比如 bmp_writer 里不只有 24 位真彩輸出還留了 8 位調(diào)色板模式的開(kāi)關(guān)這意味著能把 RGB888 量化成 256 色輸出。這個(gè)功能對(duì)「嵌入式 LCD 顯示」這個(gè)場(chǎng)景非常有用因?yàn)楹芏嗥聊恢挥?8 位或 16 位色深后面我會(huì)單獨(dú)講調(diào)色板部分怎么驗(yàn)證。2.2 從文件到像素轉(zhuǎn)換管線的三段式設(shè)計(jì)整個(gè)系統(tǒng)的核心管線分三段輸入解碼、像素處理、BMP 編碼。先看轉(zhuǎn)換流程圖這個(gè)圖在腦中的比寫在紙上的重要因?yàn)檎{(diào)試問(wèn)題時(shí)要靠它定位階段PNG 文件 → PNG 解碼器 → RGB888 像素緩沖 → BMP 編碼器 → BMP 文件 JPEG 文件 → JPEG 解碼器 → RGB888 像素緩沖 → BMP 編碼器 → BMP 文件為什么要統(tǒng)一成 RGB888 中間格式這是處理圖片格式轉(zhuǎn)換的常見(jiàn)做法BMP 只是最終包裝PNG 和 JPEG 解碼出來(lái)的數(shù)據(jù)統(tǒng)一轉(zhuǎn)成 RGB888中間層的代碼復(fù)用率最高。如果需要擴(kuò)展成輸出 PPM、TGA 等其他格式只需要再寫一個(gè)編碼器解碼部分完全不用動(dòng)?？创a時(shí)優(yōu)先看數(shù)據(jù)流的走向。先打開(kāi) png_decoder.c從頭文件里的結(jié)構(gòu)體定義開(kāi)始看// 解碼輸出的統(tǒng)一像素緩沖結(jié)構(gòu) typedef struct { int width; // 圖像寬度像素為單位 int height; // 圖像高度像素為單位 int channels; // 通道數(shù)3 RGB4 RGBA unsigned char *data; // 像素?cái)?shù)據(jù)按行存儲(chǔ) } ImageBuffer; // PNG 關(guān)鍵信息結(jié)構(gòu)體 typedef struct { int bit_depth; // 位深8、16 等 int color_type; // 顏色類型0灰度2真彩3索引6真彩alpha int interlace_method; // 0非隔行1Adam7 隔行 int width; int height; } PNGInfo;參數(shù)說(shuō)明channels 字段非常關(guān)鍵——PNG 的 color type 為 6RGBA時(shí)解碼出來(lái)有 4 個(gè)通道但 BMP 通常落地為 3 通道。這個(gè)通道數(shù)變換要在像素處理階段完成而不是在解碼器里改原因是 alpha 通道的取舍策略丟棄還是預(yù)乘應(yīng)該由轉(zhuǎn)換策略決定而不是解碼器自己決定。整個(gè)管線的順序是PNG 解碼器負(fù)責(zé)把壓縮的 IDAT 數(shù)據(jù)還原成帶有濾波信息的原始掃描線然后逐行做濾波反解最后根據(jù) color type 轉(zhuǎn)成 RGB888。JPEG 解碼器則是從熵解碼開(kāi)始逐步過(guò)反量化、逆 DCT、顏色空間轉(zhuǎn)換。兩類解碼器輸出統(tǒng)一格式后BMP 編碼器只管落盤不需要知道數(shù)據(jù)是從 PNG 還是 JPEG 來(lái)的。3. PNG 轉(zhuǎn) BMP 的實(shí)現(xiàn)拆解從 IDAT 到像素?cái)?shù)組PNG 轉(zhuǎn) BMP 的關(guān)鍵路徑是解析文件頭、解壓 IDAT、處理濾波、轉(zhuǎn)換顏色類型。這里面的難點(diǎn)不在文件頭而在“解壓后怎么處理”。PNG 的像素?cái)?shù)據(jù)走 zlib 壓縮后并不是直接就是 RGB 數(shù)組每一行開(kāi)頭還帶了一個(gè)濾波類型字節(jié)。這一章把整個(gè)鏈路走一遍重點(diǎn)落在濾波反解和顏色轉(zhuǎn)換上。3.1 PNG 解碼的關(guān)鍵步驟簽名驗(yàn)證、IHDR 解析、IDAT 解壓PNG 文件開(kāi)頭是固定的 8 字節(jié)簽名0x89 P N G \r \n 0x1a \n。代碼里驗(yàn)證簽名的方式是int png_check_signature(const unsigned char *data, size_t size) { static const unsigned char sig[8] { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A }; if (size 8) return -1; return memcmp(data, sig, 8) 0 ? 0 : -1; }簽名驗(yàn)證不通過(guò)就直接返回“不是 PNG 文件”的錯(cuò)誤碼。這個(gè)看似基礎(chǔ)的檢查實(shí)際能過(guò)濾掉很多無(wú)效輸入我在調(diào)試時(shí)遇到過(guò)把 JPEG 改名成 .png 傳進(jìn)來(lái)的情況沒(méi)有簽名檢查的話后面解碼會(huì)直接內(nèi)存越界。簽名之后是 IHDR 塊。IHDR 是第一個(gè)關(guān)鍵塊固定 13 字節(jié)數(shù)據(jù)長(zhǎng)度包含寬、高、位深、顏色類型、壓縮方法、濾波方法、隔行方法。解析方式和寫在紙上的格式規(guī)范完全對(duì)應(yīng)int parse_ihdr(const unsigned char *buf, PNGInfo *info) { info-width (buf[0] 24) | (buf[1] 16) | (buf[2] 8) | buf[3]; info-height (buf[4] 24) | (buf[5] 16) | (buf[6] 8) | buf[7]; info-bit_depth buf[8]; info-color_type buf[9]; // buf[10] 是壓縮方法PNG 規(guī)范里固定為 0 // buf[11] 是濾波方法PNG 規(guī)范里固定為 0 info-interlace_method buf[12]; return 0; }參數(shù)說(shuō)明寬高都是大端序存儲(chǔ)所以不能直接當(dāng)小端讀。很多轉(zhuǎn)換代碼在這個(gè)地方直接取 buf[0] 作為低字節(jié)遇到寬高大于 255 的圖就翻車。位深和顏色類型要組合起來(lái)判斷合法性位深為 8 時(shí)支持所有顏色類型位深為 16 時(shí)只支持灰度、真彩、真彩alpha——遇到不合法的組合直接拒絕不要試圖去“猜”。解壓 IDAT 是 PNG 解碼的性能瓶頸。zlib 解壓后的數(shù)據(jù)是“原始掃描線 濾波類型字節(jié)”交錯(cuò)的形式。解壓方式用 zlib 庫(kù)是最省事的但如果你要寫的是嵌入式環(huán)境下的轉(zhuǎn)換器用 miniz 是更常見(jiàn)的選擇——miniz 是單文件庫(kù)嵌入工程方便API 跟 zlib 兼容#include miniz.h int png_decompress_idat(const unsigned char *compressed, size_t comp_len, unsigned char **raw, size_t *raw_len) { // 用 miniz 的 tinfl_decompress_mem_to_heap 直接解到堆上 mz_ulong estimated comp_len * 4 1024; // 初始估算不夠會(huì)自動(dòng)增長(zhǎng) *raw (unsigned char *)tinfl_decompress_mem_to_heap(compressed, comp_len, (mz_ulong *)raw_len, 0); if (!*raw) return -1; return 0; }邏輯說(shuō)明這段代碼調(diào)tinfl_decompress_mem_to_heap一次性解出全部數(shù)據(jù)。估算大小不是精確值庫(kù)內(nèi)部會(huì)處理膨脹的情況但如果你的工程對(duì)內(nèi)存敏感可以改成用tinfl_decompress分塊解配合已知的原始大小分配合適緩沖。原始大小怎么算就是每行寬度×通道數(shù)×位深/8 1 個(gè)濾波字節(jié)乘以高度前提是知道 color type 對(duì)應(yīng)的通道數(shù)——這就是前面 PNGInfo 存在的意義。3.2 濾波反解的五種類型與逐行恢復(fù)算法IDAT 解壓后的數(shù)據(jù)不能直接當(dāng)像素用。每一行開(kāi)頭多了一個(gè)濾波類型字節(jié)而每一行的像素值是經(jīng)過(guò)濾波處理的差分值必須逐行反向處理。這就是 PNG 和 BMP 之間最本質(zhì)的一層差異BMP 存的是絕對(duì)像素值PNG 存的是“經(jīng)過(guò)濾波后的值”。濾波類型共有五種0 無(wú)濾波、1 左側(cè)差分、2 上方差分、3 平均、4 Paeth 預(yù)測(cè)?；謴?fù)算法的核心邏輯是逐字節(jié)重建int png_unfilter_line(unsigned char *line, unsigned char *prev_line, int bytes_per_pixel, int line_bytes, int filter_type) { int i; for (i 0; i line_bytes; i) { unsigned char raw line[i]; unsigned char left (i bytes_per_pixel) ? line[i - bytes_per_pixel] : 0; unsigned char up (prev_line) ? prev_line[i] : 0; unsigned char up_left (prev_line i bytes_per_pixel) ? prev_line[i - bytes_per_pixel] : 0; switch (filter_type) { case 0: // 無(wú)濾波直接使用不需要修正 break; case 1: // Sub: 原始值 左側(cè)值 line[i] raw left; break; case 2: // Up: 原始值 上方值 line[i] raw up; break; case 3: // Average: 原始值 (左 上) / 2 line[i] raw ((left up) 1); // 注意是除以 2 后向下取整 break; case 4: { // Paeth: 原始值 左/上/左上三者間的預(yù)測(cè)值 int p left up - up_left; int pa abs(p - left); int pb abs(p - up); int pc abs(p - up_left); unsigned char predictor; if (pa pb pa pc) predictor left; else if (pb pc) predictor up; else predictor up_left; line[i] raw predictor; break; } } } return 0; }邏輯說(shuō)明注意循環(huán)的順序必須從左到右逐字節(jié)處理。Sub 濾波里后面的字節(jié)依賴前面已經(jīng)恢復(fù)的字節(jié)如果先處理右邊就全錯(cuò)了。Up 和 Average 依賴上一行的對(duì)應(yīng)位置所以必須按行從上到下處理絕不能并行。Paeth 的預(yù)測(cè)值選擇規(guī)則是取左邊、上方、左上三者中與“左上-左上”預(yù)測(cè)值最接近的那個(gè)。參數(shù)說(shuō)明bytes_per_pixel不是固定值它取決于 color type——灰度 1 字節(jié)、真彩 3 字節(jié)、真彩alpha 4 字節(jié)。8 位索引色也是 1 字節(jié)。16 位深度時(shí)每個(gè)通道占 2 字節(jié)bytes_per_pixel 要翻倍。這個(gè)參數(shù)錯(cuò)了濾波反解出來(lái)的圖像會(huì)出現(xiàn)“像素錯(cuò)位 偏色”的混合癥狀這是最常見(jiàn)的翻車現(xiàn)場(chǎng)之一。濾波處理完后如果原圖是非隔行的此時(shí)數(shù)據(jù)已經(jīng)是完整的圖像像素。但很多測(cè)試圖用的是 Adam7 隔行編碼解出來(lái)的數(shù)據(jù)是 7 個(gè)不完整的子圖必須先合成再繼續(xù)。合成方式是按 Adam7 的 7 個(gè) pass把每個(gè) pass 的像素放到最終位置代碼里維護(hù)一個(gè) 8x8 的偏移表7 個(gè) pass 覆蓋 64 個(gè)位置。不少轉(zhuǎn)換器直接不支持隔行 PNG報(bào)一個(gè)“不支持的隔行模式”錯(cuò)誤就退出。從工程角度對(duì)不支持的功能直接報(bào)錯(cuò)比輸出花屏要好得多。3.3 顏色類型轉(zhuǎn)換灰度、索引色、RGBA 統(tǒng)一成 RGB888PNG 的 color type 為 2真彩時(shí)濾波后的數(shù)據(jù)就是 RGB888直接拷貝到 ImageBuffer 即可。但灰度type 0、索引色type 3、真彩alphatype 6都要額外處理。灰度最簡(jiǎn)單每個(gè)像素的 RGB灰度值。索引色要查 PLTE 塊先解析調(diào)色板// 解析 PLTE 塊最多 256 項(xiàng)每項(xiàng) 3 字節(jié) (R,G,B) int parse_plte(const unsigned char *data, size_t len, unsigned char palette[][3]) { if (len % 3 ! 0) return -1; int count len / 3; if (count 256) count 256; for (int i 0; i count; i) { palette[i][0] data[i * 3]; palette[i][1] data[i * 3 1]; palette[i][2] data[i * 3 2]; } return count; } // 索引色轉(zhuǎn) RGB888 void indexed_to_rgb(const unsigned char *src, unsigned char *dst, int pixel_count, const unsigned char palette[][3]) { for (int i 0; i pixel_count; i) { unsigned char idx src[i]; dst[i * 3] palette[idx][0]; dst[i * 3 1] palette[idx][1]; dst[i * 3 2] palette[idx][2]; } }RGBA 轉(zhuǎn) RGB 的處理方式在轉(zhuǎn)換策略上有分歧。直接丟棄 alpha 是最簡(jiǎn)單的做法但如果原圖帶有透明背景丟掉 alpha 后透明區(qū)域的 RGB 值可能是任意值常見(jiàn)是黑或白轉(zhuǎn)出來(lái)的 BMP 會(huì)有一個(gè)黑色或白色的底。處理時(shí)先看 PLTE 和 tRNS 塊有沒(méi)有指定透明色再看 alpha 通道的值至少要把 alpha0 的像素 RGB 值統(tǒng)一設(shè)置成白色后續(xù)如果要嵌到其他場(chǎng)景里再合成這樣做翻車概率小一些void rgba_to_rgb(const unsigned char *src, unsigned char *dst, int pixel_count) { for (int i 0; i pixel_count; i) { unsigned char r src[i * 4]; unsigned char g src[i * 4 1]; unsigned char b src[i * 4 2]; unsigned char a src[i * 4 3]; if (a 0) { // 全透明像素RGB 置為白色避免出現(xiàn)隨機(jī)黑點(diǎn) dst[i * 3] dst[i * 3 1] dst[i * 3 2] 0xFF; } else { dst[i * 3] r; dst[i * 3 1] g; dst[i * 3 2] b; } } }邏輯說(shuō)明嚴(yán)格來(lái)說(shuō)如果 alpha 是 0 到 255 之間的半透明值正確的做法是把 RGB 跟背景色做 alpha 混合。但大多數(shù)圖片格式轉(zhuǎn)換工具對(duì)半透明的策略就是“丟掉 alpha 信息保留未預(yù)乘的 RGB”這一點(diǎn)要在代碼注釋里寫明。半透明區(qū)域的 RGB 值在 PNG 里的定義是“未預(yù)乘的顏色”丟掉 alpha 后顏色會(huì)偏亮或偏暗這是 PNG 轉(zhuǎn) BMP 的一個(gè)固有信息損失不是 bug。4. JPEG 轉(zhuǎn) BMP 的實(shí)現(xiàn)拆解Huffman 解碼與 DCT 的完整鏈路JPEG 轉(zhuǎn) BMP 比 PNG 要復(fù)雜一個(gè)量級(jí)。PNG 的復(fù)雜度在線性濾波JPEG 的復(fù)雜度在熵解碼之后的非線性環(huán)節(jié)Huffman 解碼、差分 DC、Zigzag 掃描、反量化、逆 DCT、YCbCr 轉(zhuǎn) RGB、色度上采樣。任何一個(gè)環(huán)節(jié)錯(cuò)了輸出圖不是整體偏色就是出現(xiàn) 8x8 的塊狀噪聲。這一章不搞簡(jiǎn)化版按完整解碼鏈路走你可以對(duì)照自己手里的工程逐段檢查。4.1 從文件頭到量化表SOI、DQT、DHT 的解析順序JPEG 文件由段Segment組成。解析的基本模式是掃描標(biāo)記Marker根據(jù)標(biāo)記類型分發(fā)到不同的處理函數(shù)。以下是常見(jiàn)標(biāo)記的說(shuō)明標(biāo)記名稱說(shuō)明0xD8SOI文件起始固定出現(xiàn)在開(kāi)頭0xE0~0xEFAPPn應(yīng)用數(shù)據(jù)段常見(jiàn)為 JFIF 信息0xDBDQT定義量化表至少要有一個(gè)0xC0SOF0幀起始包含寬高等關(guān)鍵信息0xC4DHT定義 Huffman 表0xDASOS掃描起始圖像數(shù)據(jù)從這里開(kāi)始0xD9EOI文件結(jié)束JPEG 規(guī)定量化表和 Huffman 表必須先于 SOS 出現(xiàn)但 DHT 可以拆成多段分別定義。寫解析器時(shí)要注意不能假設(shè)所有表在一個(gè)段里就給齊了。解碼器的狀態(tài)機(jī)按“讀標(biāo)記→讀段長(zhǎng)→分發(fā)”循環(huán)這是整個(gè) JPEG 解碼器的基礎(chǔ)骨架。量化表的解析要注意的一個(gè)細(xì)節(jié)是表 ID 和精度打包在一個(gè)字節(jié)里。高 4 位是精度08 位116 位低 4 位是表 ID。解碼時(shí)要分別取出來(lái)int parse_dqt(const unsigned char *buf, int len, QuantTable tables[4]) { int offset 0; while (offset len) { int pq buf[offset] 4; // 精度08bit116bit int tq buf[offset] 0x0F; // 表 ID0~3 offset; if (pq 0) { for (int i 0; i 64; i) { tables[tq].values[i] buf[offset i]; } offset 64; } else { // 16 位量化表每個(gè)值占 2 字節(jié)大端序 for (int i 0; i 64; i) { tables[tq].values[i] (buf[offset i * 2] 8) | buf[offset i * 2 1]; } offset 128; } } return 0; }參數(shù)說(shuō)明JPEG 量化表是自然序而非 Zigzag 序在反量化之前要先把系數(shù)恢復(fù)到 8x8 的自然位置。這個(gè)問(wèn)題我在初寫時(shí)踩過(guò)不熟悉編碼規(guī)范的話容易直接把量化表當(dāng) Zigzag 序用行頻和列頻就顛倒了。解決方式是在反量化前重排 Zigzag 序。4.2 熵解碼與逆 DCTDC 差分累積、Zigzag 重排、IDCT 公式JPEG 的核心是離散余弦變換DCT。編碼時(shí)把圖像分成 8x8 塊每個(gè)塊做 DCT 變換得到 64 個(gè)頻域系數(shù)再對(duì)系數(shù)量化和熵編碼。解碼時(shí)流程倒過(guò)來(lái)先熵解碼得到 64 個(gè)系數(shù)然后反量化再做逆 DCT 得到像素塊。這里的系數(shù)排列是 Zigzag 序做 IDCT 前要重排static const unsigned char zigzag[64] { 0, 1, 8, 16, 9, 2, 3, 10, 17, 24, 32, 25, 18, 11, 4, 5, 12, 19, 26, 33, 40, 48, 41, 34, 27, 20, 13, 6, 7, 14, 21, 28, 35, 42, 49, 56, 57, 50, 43, 36, 29, 22, 15, 23, 30, 37, 44, 51, 58, 59, 52, 45, 38, 31, 39, 46, 53, 60, 61, 54, 47, 55, 62, 63 }; // 反量化 Zigzag 重排 void dequantize_block(const int *coeff_zz, const QuantTable *qtable, int coeff_natural[64]) { for (int i 0; i 64; i) { int natural_idx zigzag[i]; coeff_natural[zigzag[i]] coeff_zz[i] * qtable-values[zigzag[i]]; } }邏輯說(shuō)明coeff_zz是從熵解碼器出來(lái)的系數(shù)按 Zigzag 序號(hào)排列重排到自然序后行號(hào) idx / 8列號(hào) idx % 8這個(gè)順序才能喂給逆 DCT 函數(shù)。DC 系數(shù)是差分編碼的——當(dāng)前塊的 DC 值要加上上一個(gè)塊的值才是真正的 DC。這是 JPEG 解碼器和 PNG 濾波反解中“逐行必須串行”相似的約束但是按塊串行int prev_dc[4] {0, 0, 0, 0}; // 最多 4 個(gè)分量 // 每處理完一個(gè)塊后 prev_dc[component] diff_dc;這個(gè) prev_dc 數(shù)組要按分量分開(kāi)維護(hù)不能用一個(gè)全局變量。Y、Cb、Cr 各自的 DC 預(yù)測(cè)器是獨(dú)立的混在一起會(huì)出現(xiàn)深色圖像上出現(xiàn)橫向漸變的條紋。逆 DCT 的整數(shù)實(shí)現(xiàn)有很多種浮點(diǎn)版本最簡(jiǎn)單也最不容易出錯(cuò)。如果性能有要求可以用 AAN 整數(shù)近似算法但精度不如浮點(diǎn)void idct_8x8(const int block[64], unsigned char out[64]) { double tmp[64]; for (int u 0; u 8; u) { for (int v 0; v 8; v) { double sum 0.0; for (int x 0; x 8; x) { for (int y 0; y 8; y) { double cu (x 0) ? 0.7071067811865476 : 1.0; double cv (y 0) ? 0.7071067811865476 : 1.0; sum block[x * 8 y] * cu * cv * cos((2 * x 1) * u * M_PI / 16.0) * cos((2 * y 1) * v * M_PI / 16.0); } } tmp[u * 8 v] 0.25 * sum; } } for (int i 0; i 64; i) { int val (int)(tmp[i] 128.5); out[i] (unsigned char)(val 0 ? 0 : (val 255 ? 255 : val)); } }邏輯說(shuō)明這個(gè)雙重循環(huán)沒(méi)有做任何優(yōu)化但正確性有保證。輸出要加 128 的偏移量因?yàn)?DCT 變換假設(shè)輸入范圍是 [-128, 127]輸出要轉(zhuǎn)回 [0, 255]。0.5是做四舍五入而不是截?cái)嗖患拥脑挄?huì)出現(xiàn)整體偏暗的一致性問(wèn)題。4.3 色度抽樣與顏色空間4:2:0 上采樣和 YCbCr 轉(zhuǎn) RGBJPEG 最坑的地方是色度抽樣。大多數(shù) JPEG 圖像用 4:2:0 抽樣——亮度 Y 每個(gè)像素都有色度 Cb、Cr 每 2x2 像素塊共享一個(gè)值。解碼時(shí)必須先把 Cb、Cr 向上采樣到和 Y 同尺寸再做顏色轉(zhuǎn)換。void upsample_chroma(const unsigned char *cb_small, const unsigned char *cr_small, unsigned char *cb_big, unsigned char *cr_big, int width_big, int height_big, int h_scale, int v_scale) { for (int y 0; y height_big; y) { int sy y / v_scale; for (int x 0; x width_big; x) { int sx x / h_scale; cb_big[y * width_big x] cb_small[sy * (width_big / h_scale) sx]; cr_big[y * width_big x] cr_small[sy * (width_big / h_scale) sx]; } } }邏輯說(shuō)明最簡(jiǎn)單的最近鄰上采樣。效果可以接受但有些工程會(huì)做雙線性插值抗鋸齒效果更好。上采樣維度計(jì)算要嚴(yán)格按 h_scale 和 v_scale 來(lái)4:2:0 時(shí) h_scale2v_scale2色度平面寬高各減半4:2:2 時(shí) h_scale2v_scale1 只有寬度減半。如果從 SOF0 里拿到的是“1x1、2x1、1x2、2x2”這類抽樣因子而非直接寬高要做映射判斷// SOF0 里每個(gè)分量的抽樣因子 unsigned char h_sampling sof_data[comp_index * 3 1] 4; unsigned char v_sampling sof_data[comp_index * 3 1] 0x0F; // 寬高由 Y 分量決定色度分量的實(shí)際尺寸按采樣因子換算YCbCr 轉(zhuǎn) RGB 的公式在工程里寫死了但注意 JPEG 的 YCbCr 是 ITU-R BT.601 范圍不同于 JPEG 編碼時(shí)的全范圍。轉(zhuǎn)換公式// 輸入: Y 范圍 [0,255], Cb/Cr 范圍 [0,255] (未做 128 偏移) // 輸出: RGB 范圍 [0,255]需要做裁減以防止越界 int r (int)(Y 1.402 * (Cr - 128)); int g (int)(Y - 0.344136 * (Cb - 128) - 0.714136 * (Cr - 128)); int b (int)(Y 1.772 * (Cb - 128));邏輯說(shuō)明Cb 和 Cr 在熵解碼后是帶符號(hào)的數(shù)值范圍轉(zhuǎn)為無(wú)符號(hào)時(shí)要加上 128 的偏移。如果不做偏移顏色會(huì)變成一種“負(fù)片色調(diào)”這是 JPEG 轉(zhuǎn) BMP 最容易肉眼發(fā)現(xiàn)的問(wèn)題之一。轉(zhuǎn)換后的 RGB 要做 0~255 限幅因?yàn)槟?DCT 的浮點(diǎn)誤差和色度上采樣的插值會(huì)算出越界值。碰到底部有 SOS 段卻拿不到 DHT 表的情況說(shuō)明源 JPEG 用了“一次性 Huffman 表”的特殊編碼方式把表放在 SOS 之后。這種情況現(xiàn)實(shí)中很少見(jiàn)但部分相機(jī)直出的 JPEG 會(huì)這么干。真遇到了解碼器不能原地崩潰要返回一個(gè)“不支持的 JPEG 變體”錯(cuò)誤并注明原因——這里用 Haffman 表延遲解析的工程極少普通轉(zhuǎn)換場(chǎng)景直接拒絕問(wèn)題不大。5. 轉(zhuǎn)換避坑指南最值得記下的五條實(shí)測(cè)踩坑記錄這一章是實(shí)際調(diào)試中反復(fù)遇到的經(jīng)典問(wèn)題從“花屏”到“錯(cuò)位”到“偏色”每條都帶具體原因和解決方法。如果你拿到的轉(zhuǎn)換工程有問(wèn)題按這個(gè)清單逐個(gè)排查。5.1 BMP 文件打不開(kāi)文件頭長(zhǎng)度和像素偏移算錯(cuò)現(xiàn)象生成的 BMP 能被圖片查看器識(shí)別但提示“文件損壞”或“不支持該格式”。用十六進(jìn)制工具看文件頭部發(fā)現(xiàn) bfOffBits 和實(shí)際像素?cái)?shù)據(jù)起始位置對(duì)不上。原因BMP 文件頭寫入了標(biāo)準(zhǔn) 14 字節(jié) BITMAPFILEHEADER 加 40 字節(jié) BITMAPINFOHEADER但沒(méi)有考慮調(diào)色板的存在。如果輸出為 8 位索引色像素?cái)?shù)據(jù)前面還有 1024 字節(jié)的調(diào)色板數(shù)據(jù)bfOffBits 應(yīng)該是 14 40 1024 1078而不是默認(rèn)的 54。解決寫 BMP 頭之前先確認(rèn)輸出位深和是否帶調(diào)色板bfOffBits 按實(shí)際數(shù)據(jù)布局計(jì)算。注意 biSizeImage 字段也要同步修正否則某些嚴(yán)格校驗(yàn)的查看器如部分嵌入式的解碼庫(kù)會(huì)提前截?cái)?。文件大?bfSize bfOffBits biSizeImage這三處數(shù)值必須自洽。5.2 圖像行錯(cuò)位行字節(jié)數(shù)沒(méi)有按 4 字節(jié)對(duì)齊現(xiàn)象轉(zhuǎn)換出來(lái)的 BMP 整體向左傾斜每一行圖相對(duì)于上一行偏移了幾個(gè)像素而且偏移量隨行號(hào)遞增。用查看器打開(kāi)時(shí)能隱約認(rèn)出畫面內(nèi)容但整幅圖呈“階梯形”。原因BMP 規(guī)定每行的字節(jié)數(shù)必須是 4 的倍數(shù)。假設(shè)寬度為 101 像素、24 位真彩101 × 3 303 字節(jié)303 不是 4 的倍數(shù)需要補(bǔ)齊到 304 字節(jié)補(bǔ) 1 個(gè) 0x00。如果你的代碼直接按“兩字節(jié)對(duì)齊甚至不對(duì)齊”寫入BMP 讀取器每一行都會(huì)從錯(cuò)誤的位置讀下一行階梯形就是這樣產(chǎn)生的。解決在寫入每一行像素后計(jì)算需要補(bǔ)齊的字節(jié)數(shù)用 0x00 填充。經(jīng)驗(yàn)公式rowSize ((width × bytesPerPixel 3) / 4) × 4行間隔 rowSize - width × bytesPerPixel。驗(yàn)證時(shí)輸出一組已知像素值如第一行全部像素設(shè)為紅色看偏移是否消除。5.3 JPEG 圖像整體發(fā)綠YCbCr 偏移量沒(méi)加現(xiàn)象圖像內(nèi)容能看清輪廓但整體色調(diào)嚴(yán)重偏綠膚色變成了奇怪的顏色暗部有一層綠色底色。原因YCbCr 轉(zhuǎn) RGB 時(shí)漏了把 Cb、Cr 減去 128。JPEG 中 Cb、Cr 是“零中心”的128 對(duì)應(yīng)零偏置不減去 128 相當(dāng)于色度信號(hào)整體偏移轉(zhuǎn)換后 G 通道被抬高因?yàn)?G 的公式里 Cb、Cr 是減項(xiàng)引發(fā)偏綠。紅色的物體往往會(huì)變暗藍(lán)色的物體變黑整個(gè)色調(diào)都亂了。解決轉(zhuǎn) RGB 前確認(rèn) Cb、Cr 都減了 128。如果庫(kù)函數(shù)里已經(jīng)有這個(gè)處理檢查是不是重復(fù)減了兩次——有些工程從熵解碼器拿到的 Cb、Cr 已經(jīng)做了偏移處理再減一次會(huì)變成反向偏移同樣產(chǎn)生偏色問(wèn)題。驗(yàn)證方式找一張色卡圖或標(biāo)準(zhǔn)測(cè)試圖轉(zhuǎn)換后取幾個(gè)已知色塊的 RGB 值跟原圖對(duì)比。5.4 PNG 隔行掃描圖轉(zhuǎn)換出來(lái)后只有部分區(qū)域有內(nèi)容現(xiàn)象轉(zhuǎn)換結(jié)果是 8x8 的“方格拼圖”看起來(lái)像采樣率降低部分區(qū)域有內(nèi)容部分區(qū)域是空白。改換另一個(gè)非隔行的 PNG 測(cè)試圖時(shí)一切正常。原因解碼器只處理了 7 個(gè) pass 中的部分?jǐn)?shù)據(jù)。Adam7 隔行把圖像拆成 7 個(gè) pass每個(gè) pass 是原圖在特定行列位置的子采樣。如果代碼把 7 個(gè) pass 的數(shù)據(jù)當(dāng)作 7 張獨(dú)立圖像拼接或重疊寫入結(jié)果就變成拼圖效果。解決正確實(shí)現(xiàn) Adam7 合成。每個(gè) pass 都有各自的行列起始位置和步長(zhǎng)需要按 pass 序號(hào)查表確定寫入目標(biāo)位置。如果不支持隔行掃描正確做法是掃描 IHDR 的 interlace 字段當(dāng)值為 1 時(shí)直接返回“暫不支持 Adam7 隔行”而不是輸出錯(cuò)誤結(jié)果。大多數(shù)工具類轉(zhuǎn)換器不支持隔行是可以接受的但要明確告知用戶。5.5 JPEG 解碼出現(xiàn) 8x8 的塊狀噪聲現(xiàn)象圖像整體能識(shí)別但所有 8x8 像素塊之間有明顯亮度差異看起來(lái)像“馬賽克”特別是平坦區(qū)域如天空、純色背景邊界非常明顯。原因逆 DCT 的精度不夠或者反量化之后忘了做 IDCT、直接拿頻域系數(shù)當(dāng)像素值。還有種可能是 Zigzag 重排錯(cuò)誤導(dǎo)致 DCT 系數(shù)位置顛倒。低頻系數(shù)放錯(cuò)位置會(huì)影響整體亮度高頻系數(shù)放錯(cuò)位置會(huì)出現(xiàn)顆粒狀紋理。解決逐段檢查解碼管線。最有效的定位方式是把 IDCT 后的數(shù)據(jù)暫時(shí)輸出成文件肉眼觀察塊效應(yīng)是否存在如果 IDCT 后正常、BMP 寫入后出現(xiàn)塊效應(yīng)問(wèn)題在 BMP 寫入環(huán)節(jié)的字節(jié)序如果 IDCT 后就有塊效應(yīng)檢查 Zigzag 重排表和量化表的使用順序。6. 進(jìn)階驗(yàn)證方法像素級(jí)對(duì)比腳本與調(diào)色板位深擴(kuò)展這一章講兩個(gè)價(jià)值點(diǎn)怎么驗(yàn)證轉(zhuǎn)換結(jié)果是否真正正確以及怎么把轉(zhuǎn)換器擴(kuò)展到 8 位調(diào)色板 BMP。前幾章解決了“能轉(zhuǎn)”的問(wèn)題這一章解決“轉(zhuǎn)得對(duì)”和“轉(zhuǎn)得更實(shí)用”的問(wèn)題。6.1 像素級(jí)自動(dòng)對(duì)比PSNR 和 MAE 校驗(yàn)?zāi)_本人眼盯著圖看容易漏掉細(xì)節(jié)差異特別是 JPEG 轉(zhuǎn) BMP 這種有損轉(zhuǎn)換如果解碼器有輕微精度損失人眼很難分辨但像素級(jí)對(duì)比能立刻暴露問(wèn)題。Python 腳本適合做這件事——C 的轉(zhuǎn)換器產(chǎn)生 BMPPython 用 Pillow 庫(kù)打開(kāi)原圖和轉(zhuǎn)換結(jié)果逐像素對(duì)比并計(jì)算 PSNR峰值信噪比f(wàn)rom PIL import Image import math def compare_images(src_path, dst_path): src Image.open(src_path).convert(RGB) dst Image.open(dst_path).convert(RGB) if src.size ! dst.size: print(f尺寸不一致: {src.size} vs {dst.size}) return src_pixels list(src.getdata()) dst_pixels list(dst.getdata()) mse 0 max_diff 0 for p1, p2 in zip(src_pixels, dst_pixels): d sum((a - b) ** 2 for a, b in zip(p1, p2)) mse d max_diff max(max_diff, max(abs(a - b) for a, b in zip(p1, p2))) mse / (len(src_pixels) * 3) psnr 10 * math.log10((255 ** 2) / mse) if mse 0 else float(inf) print(fMSE: {mse:.4f}, PSNR: {psnr:.2f} dB, 單像素最大差: {max_diff})參數(shù)說(shuō)明PSNR 值大于 40dB 表示差異非常小30~40dB 基本可接受但可能有輕微色差低于 30dB 意味著解碼器有實(shí)質(zhì)性錯(cuò)誤。max_diff能捕捉極端情況——比如某個(gè)像素差 100 以上說(shuō)明在某個(gè)顏色通道上處理邏輯有問(wèn)題。這個(gè)腳本的價(jià)值在調(diào) JPEG 解碼器時(shí)特別明顯。JPEG 是有損格式不能要求轉(zhuǎn)換結(jié)果和原圖像素級(jí)一致但 PSNR 穩(wěn)定在 40dB 以上用高質(zhì)量原圖測(cè)試說(shuō)明解碼器的精度損失只是量化和浮點(diǎn)運(yùn)算帶來(lái)的沒(méi)有結(jié)構(gòu)性錯(cuò)誤。如果 PSNR 在 25dB 以下基本可以斷定解碼鏈路里有 bug按前面的避坑清單逐項(xiàng)排查。6.2 調(diào)色板模式與位深擴(kuò)展從 24 位真彩到 8 位索引色真彩 BMP 文件體積大嵌入式場(chǎng)景常需要 8 位索引色 BMP。從 RGB888 量化到 256 色的方式直接用中位切分算法Median Cut或八叉樹(shù)量化。中位切分更適合從零實(shí)現(xiàn)// 中位切分量化把 RGB 空間遞歸劃分成 256 個(gè)桶 typedef struct { int r_min, r_max, g_min, g_max, b_min, b_max; int pixel_count; unsigned char r_avg, g_avg, b_avg; } ColorBox; int build_palette(unsigned char *pixels, int pixel_count, unsigned char palette[256][3]) { ColorBox boxes[256]; // 初始化一個(gè)覆蓋全部像素的 box按 RGB 范圍做遞歸切分 // 每次選像素?cái)?shù)最多、顏色范圍最大的 box沿最長(zhǎng)的通道切 // 最終每個(gè) box 的平均 RGB 作為調(diào)色板項(xiàng) return 0; // 返回實(shí)際使用的顏色數(shù) }邏輯說(shuō)明中位切分的本質(zhì)是每次選一個(gè) box找到“像素?cái)?shù)最多”或“顏色范圍最大”的那個(gè)沿范圍最長(zhǎng)的顏色通道切成兩個(gè) box直到湊滿 256 個(gè)。處理上要注意一個(gè)細(xì)節(jié)統(tǒng)計(jì)像素顏色時(shí)用桶化將 8 位通道降到 5 位左右能顯著加快速度代價(jià)是輕微的色彩精度損失。調(diào)色板構(gòu)建后每個(gè)像素取“距離最近”的調(diào)色板項(xiàng)距離可以按歐氏距離或帶權(quán)重的距離計(jì)算——人眼對(duì)綠色更敏感可以給 G 通道高權(quán)重。寫 8 位 BMP 時(shí)文件布局變?yōu)?4 字節(jié)文件頭 40 字節(jié)信息頭 1024 字節(jié)調(diào)色板 像素索引數(shù)組。biBitCount 設(shè)為 8biClrUsed 設(shè)為 256。像素?cái)?shù)據(jù)不是 RGB 三元組而是每個(gè)字節(jié)一個(gè)調(diào)色板索引。如果轉(zhuǎn)換器不支持調(diào)色板量化正確做法是明確返回“僅支持 24 位真彩輸出”而不是自動(dòng)降級(jí)成灰度或截?cái)鄶?shù)據(jù)。這也是工程邊界管理的一部分——明確不做什么比硬做但做錯(cuò)要好得多。從那以后我每次寫格式轉(zhuǎn)換工具都會(huì)強(qiáng)制在工程里放一個(gè) test 目錄和一個(gè)像素級(jí)校驗(yàn)?zāi)_本。原圖、中間結(jié)果、最終輸出三者的像素?cái)?shù)據(jù)隨時(shí)可對(duì)比比對(duì)通過(guò)才算功能完成。否則在 JPEG 解碼器里改一個(gè) Zigzag 表改完到底對(duì)不對(duì)不跑像素級(jí)對(duì)比是很難判斷的。這份工程的代碼組織方式和解碼細(xì)節(jié)可以作為你手頭轉(zhuǎn)換需求的起點(diǎn)——但它不是銀彈遇到特殊變體的圖片色彩配置 ICC、16 位 PNG、漸進(jìn)式 JPEG還是要回來(lái)補(bǔ)解碼器邊界。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取