有損 vs 無損：影像格式為何故意遺忘

拿同一張 1200 萬像素的照片（4000 × 3000 像素）存兩次。一次存成 PNG：24 MB；一次存成品質 90 的 JPEG：3.4 MB。並排放在螢幕上，你分不出哪張是哪張。放大到 400%，差異才冒出來：頭髮和草地稍微柔化，最銳利的邊緣旁浮起淡淡的光暈。

兩個檔案，同一張影像，大小差了 7 倍，而且兩個檔案都沒壞。它們只是給了不同的保證：PNG 保證一個位元都不動，JPEG 保證你會注意到的東西一樣不少。一個格式選了哪一種保證，幾乎就決定了它的一切。

壓縮為什麼分成兩大陣營

1948 年，Claude Shannon 發表〈A Mathematical Theory of Communication〉，替壓縮劃出一條硬下限。他的訊源編碼定理說：要無損表示一份資料，不可能壓到它的**熵（entropy）**以下，熵就是每個符號的平均資訊量。一張完全隨機的影像完全壓不動，一張純白影像可以壓到幾乎什麼都不剩。真實影像都落在這兩個極端之間，而且沒有任何無損演算法能越過這條線。

有損壓縮的存在，靠的是一個漏洞。熵的下限管的是你手上的資料，不是你之後留下的資料。如果先把影像換成一張稍有不同、熵更低的影像，下限就跟著降。竅門就一句話：先改資料，再打包。工程上的問題只剩一個：哪些改動可以接受。

答案看兩件事。第一是內容本身。設定面板的截圖大多是大片純色和重複的形狀，熵低，好預測；森林的照片在像素層全是光子散粒雜訊和感光元件的讀取雜訊，熵高，難預測。第二是誰來讀。程式讀檔案，需要完全正確的位元；人眼看圖，天生就容錯：對色彩的空間解析力有限，對細碎的高頻紋理不敏感，對亮度的感知看的是比例而不是絕對值（韋伯定律，大約 1% 到 2% 的亮度差異）。

格式於是分道揚鑣。內容好預測、讀者是機器，或是會放大到像素級慢慢挑的人，選無損。內容充滿雜訊、讀者只是在正常距離看螢幕的人，你就丟得起。

有損壓縮如何運作

有損編解碼器常被說成是「丟資料」，這話沒錯，但不夠精確。它們丟的是特定的資料，由一套人類視覺模型負責挑。整條管線長這樣：

1. 把 RGB 轉成亮度、色度分離的色彩空間（JPEG 用 YCbCr，別的格式也有類似的拆法）。人眼解析亮度細節的能力遠勝色彩細節，所以色度通道只用四分之一的解析度儲存（4:2:0 子採樣）。光這一步就砍掉約 50% 的原始資料，而且在大多數照片裡根本看不出來。

2. 把每個區塊換成頻率。 JPEG 對 8 × 8 區塊做離散餘弦變換（DCT），JPEG 2000 用小波，AV1 和 HEVC 用更大、尺寸可變的變換。結果的樣子總是一樣：少數幾個大係數描述整體輪廓，一大堆小係數描述細微紋理。

3. 量化。 每個係數除以一個步長，四捨五入成整數，小係數就此歸零。這是整條管線裡唯一真正有損的一步，編碼器上的品質設定不過是這些步長的倍率。品質 95 用小步長，幾乎什麼都留；品質 30 用大步長，把大部分細微紋理統統歸零。

4. 替活下來的數字做熵編碼。 zig-zag 掃描、游程編碼、Huffman 或算術編碼。這一階段是無損的，只是把已經量化過的數字裝箱打包。

把這份清單再讀一遍。步驟 1、2、4 只是把數字搬來搬去，完全可逆；真正動手毀掉影像的是步驟 3，而且是故意的，靠一次次的捨入慢慢磨掉。

這種破壞有它認得出來的招牌特徵。品質壓太低，就會出現塊效應（blocking）（天空和牆面上浮現 8 × 8 的網格邊）、振鈴（ringing）（文字和高對比邊緣周圍的光暈），以及色帶（banding）（平滑漸層塌成一級一級的階梯）。把有損檔案再存一次，整條管線就在已經受傷的資料上再跑一遍，這就是**代際損失（generation loss）**會累積的原因：同一張 JPEG 重存到第十次，看起來就像第一張的水彩畫。

無損壓縮如何運作

無損編解碼器沒有這種自由。解出來的檔案必須和原始檔案逐位元相同，能做的只有建模和打包。標準配方分兩個階段。

第一階段：去相關。 PNG 壓縮之前會先過濾每一條掃描線。每一列都由編碼器從五種預測器（None、Sub、Up、Average、Paeth）裡挑一種，然後只存實際像素和預測值的差。一列純白會變成一個白色像素，後面跟著幾千個零；一段平滑漸層會變成一串微小、緩慢變化的殘差。不管哪種情況，數字都會變小、聚在零附近，而這正是下一階段最喜歡的樣子。

第二階段：熵編碼。 PNG 用的是 DEFLATE，gzip 和 zip 背後的同一套演算法，由兩個 1970 年代的點子組成。LZ77 掃描重複的位元組序列，把每次重複換成一個（距離、長度）指標，指向先前 32 KB 內的資料；Huffman 編碼再把短碼分給常見的值，長碼留給罕見的值。兩步都不丟任何東西。拿到打包後的串流，就一定能原封不動還原出原本的位元組。

這就是為什麼 PNG 對截圖無往不利，對照片一籌莫展。介面圖形充滿重複：相同的列、重複的圖示、一大段一大段的純色，LZ77 到處都能找到匹配，過濾器再把剩下的東西磨成接近零的殘差。照片什麼都不重複，散粒雜訊讓每個像素都和旁邊的略有不同，預測器猜不中，殘差又大又亂，LZ77 找不到任何可以指的東西。PNG 面對一張 1200 萬像素的照片，對原始像素通常只壓得出 1.3:1 到 1.6:1；視覺品質差不多的 JPEG 能到 10:1。

用更大的檔案換來的，是一項絕對的保證：解碼一張 PNG，對像素做雜湊，每次都和來源一致。要送去 OCR 的截圖、要再編輯的掃描檔、可能出現在論文或法庭上的醫學與科學影像，要的就是這個保證。

JPEG 為何在 1992 年押注有損

聯合影像專家小組（Joint Photographic Experts Group）1986 年開始工作，那個年代的限制解釋了它的每一項設計決策。一顆 20 MB 的硬碟要價數百美元，1.44 MB 軟碟是搬檔案的標準工具，數據機跑 14.4 kbps 已經算你運氣好：下載一張 921 KB 未壓縮的 VGA 照片，大約要九分鐘。10:1 的有損版本不到一分鐘傳完，2:1 的無損版本還是要四分多鐘。

委員會自己的測試也說了實話：無損榨不出更多。他們鎖定的目標是照片類內容（「連續色調影像」），這種東西根本沒有足夠的冗餘。數學把話說死了，他們只好在僅剩的變數上做文章：觀看者。

比較少人知道的是，他們 1992 年發布的標準（ISO/IEC 10918-1）其實包含一個無損模式：完全跳過 DCT，用七種固定預測器中的一種，從最多三個相鄰像素預測每個像素，再對殘差做熵編碼。概念上就是 PNG 三年後用的同一招。但幾乎沒人實作它，解碼器不理，編碼器也不理；等到醫學影像真的需要無損 JPEG，業界拿到的是另一份獨立標準（JPEG-LS，ISO/IEC 14495，1999）。

委員會還得繞開專利。JPEG 的算術編碼選項纏在 IBM 的 Q-coder 專利裡，免權利金的基線規格於是定調為 Huffman 編碼，大多數實作始終沒碰算術編碼那條路。專利焦慮左右編解碼器設計，在 1992 年不是新鮮事，而且很快就會變得更糟。

追根究柢，JPEG 是一場心理視覺的賭注：壓縮的最後 5 倍靠的不是數學，是生物學。

PNG 為何在 1995 年押注無損

PNG 一開始不是工程專案，是一場法律危機。

1994 年 12 月，Unisys 宣布要對使用 GIF 的軟體收授權費，因為 GIF 的壓縮靠 LZW 演算法，而 LZW 落在 Unisys 手上一項 1985 年專利的範圍內。GIF 的創造者 CompuServe 和 Unisys 談妥，把成本轉嫁給開發者。Usenet 上的圖形社群群情激憤：GIF 免費了七年，整個早期網路的影像和工具，一夜之間全踩進了別人的專利地盤。

不到幾週，1995 年 1 月初，Thomas Boutell 貼出了替代方案的第一份草案。一群志願者在郵件論壇上花了幾個月把設計敲定。PNG 1.0 在 1996 年 10 月以 W3C 推薦標準的身分問世，1997 年 3 月再成為 RFC 2083。

有兩項要求從來不容討論。每個演算法在專利上都必須乾淨，於是選了 DEFLATE（Phil Katz 的 PKZIP 裡那套 LZ77 加 Huffman 的組合，由 Jean-loup Gailly 和 Mark Adler 實作在 zlib 裡）。格式本身則必須無損，沒得商量。社群要取代的是 GIF，替代品要是會讓影像劣化，一推出就不會有人買單；更何況那輪專利清查，本來就沒給 JPEG 賴以運作的感知技巧留下任何空間。

內容同樣關鍵。PNG 是為 GIF 實際承載的東西而生：標誌、圖表、線條畫、圖示、螢幕截圖。銳利邊緣加大片純色，恰好是 JPEG 振鈴偽影最顯眼的地方。去追照片，等於重新發明 DCT，還要跟一個根深蒂固、免權利金的 JPEG 硬碰硬。PNG 挑了一場自己打得贏的仗，而且贏得徹底。GIF 專利 2003 年到期（美國以外是 2004 年），但到那時，PNG 早已把工作接手過來了。

有損為何還是贏得了市場

PNG 拿到了它的利基，JPEG 拿到了全世界。

原因在於量。網路上的影像絕大多數是照片，而對照片來說，有損不是妥協，是正確的工具。2025 年的 Web Almanac 指出，三十年後的今天，JPEG 仍約佔所有送出影像的 57%。社群動態、新聞攝影、商品照片、不動產列表，全是連續色調內容；在人們實際使用的螢幕上，品質 75 的有損編碼和來源看不出差別。

成本也指向同一個方向。儲存和頻寬都按位元組計費，10:1 對 2:1 不是差一點，是在品質可接受的前提下，傳輸成本差了 5 倍。頁面速度跟著檔案大小走，檔案大小跟著壓縮走。每台相機和手機出廠預設就是有損（JPEG 或 HEIC），每套 CMS 都產生有損縮圖，社交平台會把每個上傳的檔案重新編碼，一半為了體積，一半為了剝掉中繼資料和藏在裡面的惡意東西。攝影師可以上傳一張完美無瑕的 TIFF，動態消息端上桌的，是一張品質 85 的 JPEG。

無損算不上輸，只是退守到它的保證真正重要的地方：螢幕截圖和 UI 素材，偽影在那裡一眼可見，內容本來又好壓；編輯管線裡的母版，每多一代有損就多累積一次傷害；醫學、法律和科學影像，「夠接近」在那裡不算證據。在這些利基裡，PNG 和 TIFF 沒有對手，只是流量不在那裡。

各格式的地盤

兩個趨勢很醒目。新編解碼器不再選邊站：WebP、HEIC、AVIF 和 JPEG XL 都在單一規格裡同時提供有損和無損模式，JPEG 2000 早在 2000 年就這麼做了。「有損還是無損」這個問題，從「選哪種格式」變成了「選哪種模式」。跨界案例也持續出現：JPEG XL 能把現有的 JPEG 無損重壓縮到大約 80% 的大小，這招可行，是因為兩大陣營花了三十年，把彼此的數學都學透了。

實務上怎麼選

決策樹很短：

• 要發布照片？選有損。重視相容性選 JPEG，重視體積選 WebP 或 AVIF。
• 要存螢幕截圖、標誌，或任何有文字和大片純色的東西？選無損，存 PNG。
• 要編輯？母版保持無損，匯出時才產生有損副本，而且永遠不要把有損檔案用同一個格式再存一次。每多一代，傷就多疊一層。
• 要轉換？讓輸出配合用途，不是配合輸入。一張要進相簿的 PNG 截圖，該變成 JPEG 或 WebP；一張要進設計稿的 JPEG，該變成 PNG。不是因為品質會變好（不可能），而是因為它不會再繼續損失。

最後這一點，最多人搞錯的地方就是 iPhone 照片。HEIC 本身就是有損的 HEVC 壓縮，轉成 PNG 不會還原任何東西，只是把目前的狀態凍結起來，保證不再進一步損失；如果你打算編輯，這樣做仍然有用。但要分享的話，直接轉成 JPEG 才是最實在的做法。我們的 HEIC 轉 JPG、HEIC 轉 PNG 和 HEIC 轉 WebP 轉換器都在你的瀏覽器本機執行，檔案不會離開你的裝置。

剩下的組合也照同一套邏輯走。把 JPEG 送進無損編輯流程：JPG 轉 PNG。把 PNG 截圖縮小給網頁用：PNG 轉 JPG；想要更小的檔案又保住透明，選 PNG 轉 WebP。反過來，WebP 轉 PNG 和 WebP 轉 JPG 可以找回與舊軟體的相容性。手上如果是未壓縮的 BMP 掃描檔，BMP 轉 JPG、BMP 轉 PNG 和 BMP 轉 WebP 讓你一步做完同樣的有損、無損選擇。連文件渲染也會遇到同一個岔路：把 PDF 頁面匯出成影像，照片型頁面選 PDF 轉 JPG，文字必須保持銳利就選 PDF 轉 PNG。

三十年過去，活下來的格式，都是那些把使用者丟得起什麼、丟不起什麼，算得一清二楚的格式。