上一篇測的是「網站已經壓過一次」的成品圖，ImgZilla 又省下 46.8%。這一篇換到另一個極端：相機和手機直出、從沒被任何工具處理過的原圖。同樣不引用任何行業統計，只放一次真實跑測的結果，附對照方法。
一、這次的測試對象：真正的「原圖」
上一篇的樣本有個前提——那些圖在入庫時被網站壓過一輪，已經不算生圖。這次把前提去掉，測的是相機 / 手機拍完直接輸出的 JPEG，沒有經過任何壓縮工具、沒有另存、沒有二次編碼。
樣本規模：32188 張 JPEG，按 16 個 bucket 子目錄歸檔，沒有為測試挑選或清洗過。
這批檔案的總體積：99.9 GB（約 93 GiB）。
圖片規格也很典型——全部是相機 / 手機的標準輸出解析度：
| 解析度 | 張數 | 佔比 |
|---|---|---|
| 4000×3000（12MP） | 19867 | 61.7% |
| 4032×3024（12MP，iPhone） | 3529 | 11.0% |
| 3456×4608（16MP 直式） | 2631 | 8.2% |
| 其它（3120×4208、4608×3456、2448×3264…） | 6161 | 19.1% |
平均每張 11.5 百萬像素、2.96 MB，最大的單張 18.3 MB、30 百萬像素。這就是一台手機或相機拍出來、你從沒管過的那些照片。
問題是：這種「誰都沒碰過」的原圖，一個專門的壓縮工具能擠出多少？
二、結果：省下 76.8%，99.9 GB 變成 23.1 GB
32188 張圖逐一原地壓縮，檔案名稱、目錄結構、解析度原樣不動：
| 體積 | 相對原始 | |
|---|---|---|
| 相機直出原圖 | 99.9 GB | — |
| ImgZilla 壓縮後 | 23.1 GB | -76.8% |
一次壓縮省下約 76.7 GB，壓縮後只剩原來的不到四分之一。 32188 個檔案的相對路徑、檔案名稱、目錄層級，壓縮前後完全一致——這是能直接拿真實數據對比出來的。
對照上一篇：
| 測試批次 | 圖片來源 | ImgZilla 壓縮率 |
|---|---|---|
| 上一篇（4624 張） | 網站已壓過一次的成品圖 | -46.8% |
| 本篇（32188 張） | 相機 / 手機直出原圖 | -76.8% |
結論很直接：越是沒被處理過的原圖，可挖掘的空間越大。 網站入庫時那輪壓縮已經吃掉了一部分冗餘，剩給 ImgZilla 的是 46.8%；而相機直出的圖這部分冗餘一點沒動過，ImgZilla 能一次拿走 76.8%。
三、為什麼相機原圖能省這麼多
相機和手機在輸出 JPEG 時，優先級是「先別丟細節」，不是「檔案盡量小」。所以直出的 JPEG 裡有大量對畫質沒有貢獻的體積：
- 偏保守的品質參數：直出 JPEG 常用 quality 90–98 的量化表，肉眼早已分辨不出更高品質帶來的差別，但位元組數差很多。
- 通用的、非最優的熵編碼：直出編碼用固定的標準霍夫曼表，不為每張圖單獨計算最優編碼，也不做 trellis 量化、不做漸進式掃描優化。
- 一堆附帶資料：EXIF、GPS、廠商私有欄位、內嵌的整張預覽縮圖、色彩設定檔——這些加起來經常是幾十上百 KB。
ImgZilla 對 JPEG 做的是視覺無損的重新編碼：用更優的編碼策略重排熵編碼、把量化參數收到肉眼無法分辨的區間、清掉冗餘附帶資料。像素層面確實有變化，但參數選在幾乎看不出差別的位置，所以在「原圖」這種冗餘充足的素材上，一次就能拿走四分之三。
必須說清楚一個容易被混用的詞：「視覺無損」不等於「無損」。無損（像素完全不變）只出現在 PNG（oxipng）和 SVG 上；JPEG、WebP、AVIF、HEIC、GIF 原理上都是有損重新編碼，只是壓縮參數選在了視覺無損的區間。不想憑這句話就信，ImgZilla 內建對比視窗，壓縮前後左右分割畫面、可縮放到實際大小逐像素對照，自己看。
四、拆開看：逐檔案壓縮比、像素尺寸、極端案例
前面的 76.8% 是整批 32188 張的總體積對比。拆到單檔案層級還能看到幾件更具體的事。
絕大多數圖省下 70%–90%
把 32188 張圖逐一按「壓縮前位元組 → 壓縮後位元組」配對，按省下的比例分檔：
| 省下比例 | 張數 | 佔比 |
|---|---|---|
| 90%–100% | 866 | 2.7% |
| 80%–90% | 11375 | 35.3% |
| 70%–80% | 15244 | 47.4% |
| 60%–70% | 3349 | 10.4% |
| 50%–60% | 398 | 1.2% |
| 低於 50% | 956 | 3.0% |
82.7% 的照片省下了 70%–90%。 逐檔案壓縮比的算術平均是省 76.6%，和按總位元組量算出的 76.8% 幾乎重合——說明這批檔案裡壓得多和壓得少的，在體積權重上分布得比較均勻，沒有被少數超大檔案帶偏。
按分位數看：一半以上的照片省下 77% 以上；即使是壓縮收益最差的 10%，也省下了約 68%；只有大約 1% 的照片（p99）省下的比例低於 40%。
像素尺寸：一個像素沒變
統計全部 32188 張圖的解析度變化：dimensions_changed 全為 false——100% 保持原解析度。ImgZilla 不縮放、不裁剪，省下的 76.7 GB 全部來自重新編碼，不是從像素上摳出來的。這是「原地壓縮」定義裡容易被忽略的一半：不只是檔案名稱和路徑不變，解析度也完全不動。
幾個極端案例
| 類型 | 原始 | 壓縮後 | 省下 |
|---|---|---|---|
| 壓縮比最高 | 3.55 MB（4000×3000） | 100 KB | 97.2% |
| 單張省下最多 | 17.90 MB（4000×3000） | 1.13 MB | 16.8 MB |
| 收益最差 | 70 KB（1242×1242） | 68.8 KB | 2.1% |
壓縮比最高的那批（省 95% 以上）通常是相機用了極高品質參數、又帶滿中繼資料的圖；收益最差的是本來就很小、早被處理過的圖。平均每張省下 2.38 MB。
五、換算成每月帳單：這 76.8% 值多少錢
體積省了，落到帳單上才有感覺。下面不引用任何「壓縮提升轉化率」之類的統計，只做一件事：拿實測出來的 76.8%，乘以幾家雲服務商目前公開報價，做純算術推算。
儲存費節省 = 省下的體積（GB） × 單價（元或美元 / GB / 月）
流出流量費節省 = 省下的體積（GB） × 當月下載次數 × 單價（元或美元 / GB）
儲存費
| 圖庫原始大小 | 省下體積 | 阿里雲 OSS 標準 ¥0.09/GB/月 |
AWS S3 Standard $0.023/GB/月 |
Google Cloud Storage $0.020/GB/月 |
Cloudflare R2 $0.015/GB/月 |
|---|---|---|---|---|---|
| 10 GB | 7.68 GB | ¥0.69/月 | $0.18/月 | $0.15/月 | $0.12/月 |
| 100 GB | 76.8 GB | ¥6.91/月 | $1.77/月 | $1.54/月 | $1.15/月 |
| 1 TB | 786 GB | ¥70.8/月 | $18.1/月 | $15.7/月 | $11.8/月 |
| 本次實測這批（99.9 GB） | 76.7 GB | ¥6.90/月 | $1.76/月 | $1.53/月 | $1.15/月 |
這是按月重複扣的費用，壓一次，此後每個月都按新體積計費——一次性投入、長期兌現。
流量費：真正的大頭
流量費是體積 × 下載次數的乘積，圖片被訪問得越多，壓縮收益越大。舉例：一個 100 GB 的圖庫，當月透過 CDN 產生 500 GB 下行流量（相當於整庫被完整下載約 5 次），流量隨體積同步下降 76.8%：
| CDN 出口流量報價（首檔價） | 壓縮前月流量費 | 壓縮後 | 每月省 | 一年省 |
|---|---|---|---|---|
| 阿里雲 CDN 國內（¥0.15/GB） | ¥75.0 | ¥17.4 | ¥57.6 | ¥691 |
| AWS CloudFront 亞太區（$0.12/GB） | $60.0 | $13.9 | $46.1 | $553 |
| Google Cloud CDN 北美/歐洲（$0.08/GB） | $40.0 | $9.3 | $30.7 | $369 |
取的都是各家最低階梯價，實際階梯價通常更高，帳單越大壓縮省下的絕對值越可觀。Cloudflare R2 是例外：出口流量本身 $0，收益幾乎全部體現在儲存費上。
以上單價為 2026 年各平台公開報價的整理，實際價格按地域、帳戶折扣、階梯檔位浮動，請以官網目前價格為準；下載次數為範例假設，請替換成自己帳單裡的真實數字。
六、本機場景：搬這批資料省多少等待時間
體積砍掉 76.8%，傳輸時間基本上同比例縮短——這條不需要雲帳單也成立，直接體現在複製、備份的等待時間上。
- USB3 行動機械硬碟：持續吞吐量取 120 MB/s。
- USB3 行動固態硬碟：持續吞吐量取 450 MB/s。
- 千兆有線網路：扣掉協定開銷後取 105 MB/s。
| 場景 | 省下體積 | USB3 行動機械硬碟 | USB3 行動固態硬碟 | 千兆有線網路 |
|---|---|---|---|---|
| 本次實測這批圖 | 76.7 GB | ≈11 分鐘 | ≈2.9 分鐘 | ≈12.5 分鐘 |
| 10 GB 圖庫 | 7.68 GB | ≈66 秒 | ≈17 秒 | ≈75 秒 |
| 100 GB 圖庫 | 76.8 GB | ≈11 分鐘 | ≈2.9 分鐘 | ≈12.5 分鐘 |
| 1 TB 圖庫 | 786 GB | ≈112 分鐘 | ≈30 分鐘 | ≈128 分鐘 |
和儲存費一樣，這是一次性投入、長期兌現：複製進出行動硬碟、同步 NAS、跑 Time Machine、換新機遷移、傳給同事——只要還在搬這批資料，每一次都按這個比例省時間。
七、如果壓縮發生在使用者上傳之前
前面算的是「圖存下來之後」的帳。還有一段路更值得算：使用者按下「上傳」到進度條走完的這段時間，走的是使用者自己的上行頻寬，而上行幾乎永遠是整條鏈路裡最慢的一環。相機直出的原圖單張幾 MB，比上一篇那種「網站已壓過、平均 299 KB」的成品圖大一個數量級，這段時間的差別也就明顯得多。
以本批實測的單張平均體積算：相機原圖平均 2.96 MB，ImgZilla 壓縮後平均 0.69 MB，每張省下約 2.27 MB。
| 上傳頻寬（公開測速的典型區間，僅供參考） | 單張 2.96MB→0.69MB |
上傳 50 張相簿 ≈148MB→34MB |
上傳本批全部 32188 張 99.9GB→23.1GB |
|---|---|---|---|
| 行動網路（4G/5G 綜合，取 30 Mbps） | 省約 0.6 秒 | 省約 30 秒 | 省約 5.7 小時 |
| 常見家用寬頻上行（取 25 Mbps） | 省約 0.7 秒 | 省約 36 秒 | 省約 6.8 小時 |
| 千兆對稱寬頻上行（1000 Mbps） | 省約 0.02 秒 | 省約 0.9 秒 | 省約 10 分鐘 |
單張 0.6 秒還是不太有感，但一次上傳一整本相簿、或批次匯入幾百張相機原圖時，省下的分鐘數是能明確感知的——尤其對上行本來就慢的行動網路使用者。
區間數字來自國內公開測速統計，實際速度受電信業者、地區、裝置、網路壅塞影響很大，僅作數量級參考。
八、資料與測試說明
- 樣本範圍：本文資料來自這一批 32188 張相機 / 手機直出 JPEG 的實測，反映的是這批樣本的結果，不等於「ImgZilla 平均能壓 76.8%」。不同相機、不同機型、結果都會不一樣；已被精細優化過的圖，可挖掘的空間會明顯更小。
- 樣本選取：整批檔案未做任何篩選或清洗，按原有的 16 個子目錄整體壓縮，不存在挑選有利樣本的情況。
- 與上一篇的可比性：上一篇 46.8%、這一篇 76.8%，差別幾乎全部來自素材是否被壓過。多數圖庫會落在這兩個數字之間——入庫做過壓縮的更接近 46.8%，使用者首次上傳的生圖更接近 76.8%。
- 統計口徑：文中的 76.8% 為「總節省位元組 ÷ 總原始位元組」；逐檔案壓縮比的算術平均為 76.6%，中位數 77.3%，兩種口徑均已在正文中列出。體積單位按 1 GB = 10⁹ 位元組換算。
- 壓縮參數：參數固定，介面上沒有品質滑桿。這是設計取捨——每種格式的參數已調校到視覺無損區間的平衡點。習慣自己手動調參的使用者，這一點需要留意。
- 執行環境：全程在本機完成，圖片不會離開這台 Mac，不需要連網（App Store 購買驗證除外）。
價格參考來源（2026 年公開報價，具體以各平台官網即時價格為準）：AWS S3 Pricing、阿里雲 OSS 收費標準、Google Cloud Storage Pricing、Cloudflare R2 Pricing、阿里雲 CDN 收費標準、AWS CloudFront Pricing、Google Cloud CDN Pricing。
想親自驗證？ 直接從 Mac App Store 下載 ImgZilla，用自己網站上已處理過的幾張圖實測一遍，再決定是否繼續壓縮其它。
Mac App Store： https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
了解更多： https://imagetool.app/ImgZilla
系統要求：macOS 12.3 或更高版本。