行程表圖片縮小 27%，字會糊掉嗎？Oxipng 無損壓縮實測
重點摘要
- Oxipng 10.2.1 將自製 1600×1000 行程表 PNG 從 47,262 縮至 34,622 位元組，減少26.74%，錄影單次耗時0.190秒。
- 自製行程表壓縮前後尺寸相同，解碼為RGBA後逐像素完全相同。
- 800×600固定亂數雜訊PNG僅縮小0.13%，不能把行程表的縮幅套用到所有圖片。
- 透明區填入亂數RGB的自製圖使用--alpha後縮小99.64%，白底合成像素相同，但原始RGBA不同；這是特殊測試圖。
- 結論： 本次行程表PNG可保留尺寸與像素並省26.74%，雜訊圖僅省0.13%。
- 適合： 願意使用指令、希望保留原尺寸與像素的PNG圖表使用者；本次只驗證自製樣本。
- 不適合： 需要保證每張圖片大幅縮小者；需要透明區原始RGB不變者不宜使用--alpha。
| 實測項目 | 結果 |
|---|---|
| 行程表PNG | 47,262→34,622 bytes；26.74%；0.190秒；RGBA相同 |
| 雜訊PNG | 1,442,625→1,440,783 bytes；0.13%；RGBA相同 |
| 透明圖預設最佳化 | 1,034,862→1,033,867 bytes；0.10%；RGBA相同 |
| 透明圖 --alpha | 1,034,862→3,751 bytes；99.64%；原始RGBA不同、白底合成相同 |
要把行程表、教學截圖或圖卡傳給朋友，常見的兩難是：檔案想小一點，又不想讓文字變糊。把圖片長寬縮小當然能省空間，但有沒有保留原尺寸的做法？這次用免費開源的 Oxipng 10.2.1，拿自製行程表 PNG、隨機雜訊圖與透明圖案實測，先看檔案變多小，再核對像素有沒有被改動。
測試設備是 Mac mini M4 Pro（12 核、64GB）；本次單次執行的時間只供參考，不能當成所有電腦的速度保證。受測程式是官方 v10.2.1 的 aarch64 發行檔，測試當天原始碼版本為 21c1fff，授權為 MIT。全程使用自己產生的圖片，沒有拿私人照片或客戶文件測試。
一張行程表，省下 26.74%
第一張素材是 1600×1000 的行程表式圖卡，有標題、色塊與五列活動資訊，使用 Pillow 預設設定存成 PNG，並沒有刻意先存成完全不壓縮的大檔。原檔是 47,262 位元組，壓縮後剩 34,622 位元組，省下 12,640 位元組，也就是 26.74%。錄影這次執行花了 0.190 秒。
實際使用的核心指令如下。--out 把結果另存，讓原檔留著，方便比較。
oxipng -o 2 --out planner_small.png planner.png
-o 2 是這次選用的最佳化等級。輸出尺寸仍是 1600×1000；把兩張圖都解碼成 RGBA，再逐一比較所有像素，結果完全相同。這次省空間來自檔案編碼的改變，不是把圖片縮小，也不是只憑肉眼說「看起來差不多」。但這張本來就只有約 47 KB，省下的絕對容量其實有限，不必為每張小圖多做一道手續。
換張圖，結果幾乎沒差
第二張是固定亂數種子產生的 800×600 雜訊 PNG。原本 1,442,625 位元組，輸出 1,440,783 位元組，只省 1,842 位元組，縮幅 0.13%。RGBA 仍完全相同，卻幾乎沒省到空間。
這不是照片測試，也不能推論所有照片都只能省這麼多；它是這次刻意加入的反例：同一套指令，面對不同圖案，效果會差很多。不能看到第一張省了約四分之一，就承諾所有 PNG 都有一樣的縮幅。
透明最佳化的界線
第三張是自製透明圖案，透明區刻意填入亂數 RGB，用來確認 --alpha 的行為，並非一般圖檔的代表樣本。
oxipng -o 2 --alpha --out badge_small.png transparent.png
這張從 1,034,862 降到 3,751 位元組，縮小 99.64%。把前後兩張合成在白底上，像素相同；直接比較原始 RGBA 卻不同。原因是完全透明區原先藏著的顏色數值被改變。官方 README 也提醒，這項設定在技術上可能屬於有損轉換。若後續工作需要保留透明區原始色值，就不要只看畫面一樣便認定資料完全相同。
我的結論是：需要保留尺寸與文字清晰度、又願意使用指令的人，可以拿自己的 PNG 先另存試一次；只想按個按鈕的人，這次測的指令介面會多一道門檻。本次沒有測 JPG、動畫 PNG、大量批次，也沒有測任何圖形介面的包裝軟體。不要拿特殊透明圖的 99.64% 當一般圖片的預期成績。
專案與使用說明：https://github.com/oxipng/oxipng
授權：MIT。測試日期：2026-10-16。