線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:2276
推到 Plurk!
推到 Facebook!

[轉貼]高質量高解碼速度的高彩圖象壓縮

 
axsoft
版主


發表:681
回覆:1056
積分:969
註冊:2002-03-13

發送簡訊給我
#1 引用回覆 回覆 發表時間:2002-08-15 12:36:10 IP:61.218.xxx.xxx 未訂閱

高質量高解碼速度的高彩圖象壓縮

作者:雲風 來源: 雲風工作室 2D 游戲中, 圖片通常是最占內存的一種資源, 當內存因為游戲用圖的量增加而吃緊的時候, 尋找高解碼速度的圖象壓縮算法通常是最直接的解決方案之一. 這些方法的一個共性就是需要 engine 的編寫者有較高的匯編能力. 需要自己實現基本的 blit 函數, 再就是解碼算法要相當簡單, 能夠滿足實時的要求, 使得可以直接在內存中存放壓縮的數據, 在顯示的時候, 一邊解碼一邊傳送 到顯示 buffer 中去. 最為常用的是 RLE 算法, 但是只對 sprite 效果比較明顯, 可以摳去大約 30%~50% 的 透明色數據. 其次就是在高彩游戲中使用 256 色數據, 和 256 色游戲不同的是, 往往是採用 多個調色盤, 使得色彩足夠豐富, 這樣可以節省 50% 的內存空間. 不過對于大塊色彩豐富的 圖象, 容易形成馬賽克, 或一些花斑. 在這里, 云風將介紹一種自己發現的, 更為有效的方法. 我命名為動態 16 色壓縮算法. 壓縮方法就是將一張高彩圖片, 按 16x16 像素塊分割開. 對每塊 256 個像素點進行統計分析, 找到 16 個不同的顏色, 能夠最精確的描述這 256 個像素. 然后以每個像素 4bit 的方式進行 保存下 256 個 index 值. 並在這個塊首保存下 16 個 index 對應的 16 種顏色. 每種顏色 16bit (高彩) 這樣. 每個 16x16 的塊只占用了 4 bits*16*16 16 bits*16=1280 bits=160 bytes. 而以 256 色方式保存卻需要 8bits*16*16=256 bytes. 體積只有之 62.5%. 相對高彩的原圖, 體積僅為 31.25%. 而只需要適當的編寫對應的 blit 函數, 速度比 256 色有過之而無不及. 這個方法的起源于云風對 jpeg 壓縮的研究. 有了理論基礎, 我在沒有看到效果前, 並不對這種壓縮結果的畫質有絲毫的懷疑. 但是畢竟寫出壓縮程序, 真正處理出壓縮圖片欣賞, 更有成功感. 而且恐怕很多朋友會十分懷疑局部 16 色的表現能力. 下面我展示幾張圖. 上面這張是大話西游這個游戲中的一個場景. 採用 jpeg 格式. 讓大家看到全貌 :) (在大話西游中, 硬盤上就是以 jpeg 算法壓縮的場景, 採用多線程動態加載的方式管理圖片, 用輔線程只在需要的時候將屏幕附近的場景讀入內存,並解碼. 這也是一種節省內存的好方法) 為了能更細致的比較, 我將抽取局部, 用幾種方案壓縮比較, 並採用無損的 png, 格式放在下面: 這是原圖一角. 真彩格式, 當然我們游戲里使用的高彩色. 我們可以看到右上角的藍天白云 非常細膩. 我用 octree 算法, 轉換成 256 色的圖片, 可以看到, 畫面的右邊的云層已經明顯出了問題. 當我用 octree 的同時, 做了一下 Dither (誤差擴散) 情況有了明顯的改善, 但是由于 256 色色彩數的限制, 那些白云中出現了雜點. 我們可以看一下動態16色的算法的效果了. 即使不加 Dither 也很不錯不是? 做一些細微的 Dither 會更好. 我們留在下面展示. 其實, 上面這一組圖尚不能體現這種新算法相對 256 色圖片的優勢. 我們下面來看 mm 吧 :) 這張圖有很多的過渡色, 這將是 256 色模式的致命之處 很糟糕:( 不是嗎? 過渡色的細節全丟失了, 留下了大快的色斑. 這就是簡單用 Octree 算法裁減 調色盤的結果. 經過 Dither 后, 基本不錯了:) 只是 mm 的面部變得粗糙, 畫面上的背景也多了一些髒亂的雜點 下面還是用無損壓縮暫時細節, 但為了節約圖片的顯示時間, 我只放了局部上面. (動態16色技術, 和 256 色圖片不同, 它的局部不會被整體影響, 而 256 色圖將受到整體調色盤的牽制) 換用云風本文中提到的算法, 效果比簡單的 256 色圖片好很多. 當然, 細節還是很難看. 現在 Dither 一下. 情況能改善許多. 當需要提高畫質的時候, 我們可以把 16x16 的採樣塊減少到 12x12 甚至 8x8. 當 8x8 為一個塊的時候. 每快的數據為 64bytes (其實 32bytes 為顏色索引) 這和 256 色圖片相當. 只是畫質不可同日而語. 幾乎接近了無損壓縮. 在此算法的基礎上, 我們還可以做簡單的 RLE 壓縮等等處理. 達到更高的壓縮比. 希望大家看了本文能有所啟發 :) 我個人認為此方法優于將圖片轉換成 256 色來節省空間. 它的畫質比 256 色高, 而壓縮比更大. 如果依此定義出一種新的圖象格式, 在技術上完全能取代 GIF. 當然 gif 的流行並非技術推動出來的. 附: 在色彩空間里找 16 個顏色可以最接近, 16*16=256 個像素 的顏色這個問題可能比一般人想的稍微複雜一點, 由于顏色教少, 像傳統的 octree 基于色彩空間裁減的方法我試了后不太適用. 在寫 encode 程序的時候還嘗試過用模擬退火法逼近最優解. 可惜收斂速度過慢. 后來採用了一個苯方法, 建立一個 256*256 的表, 硬在里面搜索和匹配劃簡, 反而取得了很好的效果. 就是速度太慢. 編碼一張 1024x768 的圖片, 我的 1GHz CPU 都感覺慢吞吞的. 實在是有待改進啊. 時間就是金錢---[ 發問前請先找找舊文章] 發表人 - axsoft 於 2002/08/15 12:40:12
系統時間:2024-03-28 20:04:43
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!