圖片壓縮工具

線上圖片壓縮用於降低圖片檔案大小，可用來加快網頁載入、符合上傳限制，並減少分享與傳輸時的頻寬消耗。檔案會上傳到 ToolAct 的轉換服務，由服務端的影像處理函式庫（libvips、mozjpeg、libwebp 等）完成解碼與重新編碼，再把壓縮結果回傳到瀏覽器；處理完成後原檔案會立即從伺服器刪除，不做歸檔，不用於訓練。不同格式會牽涉畫質、中繼資料、色彩資訊與編碼參數的取捨，一張照片可能明顯變小，但在一般顯示尺寸下仍維持可接受的觀感。它適合部落格配圖、商品照片、社群圖片、客服附件和不需要保留原始像素的草稿素材。若用於列印、長期儲存或細節檢查，壓縮後仍應確認文字、邊緣和紋理是否受影響。請勿上傳含有個人身分資訊、內部資料或其他敏感內容的圖片。

圖片壓縮沿有損/無損的界線清晰劃分。有損格式（JPEG、WebP 有損）利用人類感知的極限：眼睛對高頻色度的敏感度遠低於亮度，因此編碼器在 8x8 或 16x16 區塊中丟棄微小的色彩細節而不被大多數人察覺。JPEG 自 1992 年以來一直使用這條基於 DCT 的路徑；現代替代方案包括 mozjpeg（相同 SSIM 下比 libjpeg 小約 5-10%，編碼較慢）、libwebp（Google 的 VP8/VP8L 圖像編解碼器，2010 年）和 AVIF（Alliance for Open Media，AV1 幀內編碼，2019 年）。無損格式（PNG、GIF、WebP 無損）透過熵編碼縮減位元組 — LZ77 滑動視窗字典加上 Huffman 或算術編碼 — 且不會改變任何一個像素。 本工具的處理流程完全在服務端完成。瀏覽器把每張圖片以簽章鑑權的多部分上傳發送到 ToolAct 的壓縮接口（/image/compress）。服務端校驗請求後將位元組流交給 libvips — 一款流式、按需求驅動的高效能、低記憶體影像處理函式庫 — 它解碼來源檔案，按需縮放長邊以約束輸出尺寸，再分別透過 mozjpeg（JPEG）、libwebp（WebP）或 libpng/oxipng（PNG）重新編碼。編碼後的位元組直接以下載回應的形式回傳到瀏覽器，臨時上傳檔案會在回應寫出後立即從磁碟刪除。流程中不做歸檔、沒有訓練管線，也沒有人工查看上傳內容。 JPEG 量化是格式的核心：品質 90 保留幾乎所有 DCT 係數，75 開始丟棄中頻係數（黃底紅字場景明顯可見），50 是明顯的 JPEG 區域，平滑漸層上出現方塊效應，25 則在人像上產生明顯的色調分離。PNG 壓縮基於 zlib（DEFLATE）等級 0-9；等級 1 速度快但檔案較大，等級 9 以 CPU 為代價從純色橫幅中榨出最後幾個位元組。EXIF、ICC 設定檔、XMP 和 IPTC 中繼資料通常會在重新編碼時被丟棄，因為編碼器從頭重建檔案標頭 — 這就是為什麼一張 200 KB 的相機照片在相同解析度下可能變成 60 KB 的上傳檔案，也是為什麼圖片來源和色彩管理中繼資料如果重要的話應另行保留的原因。

• libvips（John Cupitt，LGPL）是服務端的影像處理引擎：流式、按需求驅動的管線，即使處理 1 億像素輸入也能保持低記憶體佔用，是 Sharp、ImageMagick 的 IM7 vips delegate 以及本工具背後轉換接口的基礎。
• mozjpeg（Mozilla，libjpeg-turbo 分支，具有更好的心理視覺模型）在相同 SSIM 下比原生 libjpeg 小 5-10%，但編碼速度約慢 3-5 倍 — 這是 2017 年以來大多數網頁預設 JPEG 品質 80-85 背後的取捨。
• PNG 是 LZ77 + Huffman：編碼器在 32 KB 滑動視窗內尋找重複的位元組序列，輸出（距離、長度）對，然後對結果進行 Huffman 編碼。WebP 無損（VP8L）使用類似概念加上 Local Palette 修補，通常在同一 RGBA 像素上比 PNG 小 20-26%。
• libwebp 是 Google 的 WebP 參考編解碼器；服務端用它輸出有損 VP8（品質 0-100，預設 4:2:0 色度）或無損 VP8L（品質參數控制壓縮力度而非像素保真度）。WebP 解碼廣泛可用（Chrome 32+ 2014、Firefox 65+ 2019、Safari 14+ 2020），轉出的 WebP 幾乎在所有現代瀏覽器中都能正常顯示。
• JPEG 預設的 4:2:0 色度子取樣（每 4 個亮度取樣對應 2 個色度取樣）是品質 60 時黃底紅字看起來模糊的原因 — 色度細節在亮度細節之前被丟棄。對於截圖和 UI 擷取等文字邊緣重要的場景，請切換到 4:4:4（不子取樣）。
• EXIF（可交換圖像檔案格式，JEITA CP-3451）和 ICC 色彩設定檔在重新編碼時預設被剝離，因此一張 6.3 MB 的 iPhone JPEG 經過服務端處理後通常降至 1.8 MB。這就是為什麼消費者攝影師看到檔案大小在每次經過網頁工具往返後都會下降。 實際的批次陷阱：當一個資料夾混合了小圖示（200x200 px 以下、帶 Alpha 的 PNG）、純色 UI 截圖（PNG、高度可壓縮）和手機照片（JPEG、大多是噪點類內容）時，單一品質滑桿對三者都不適用。圖示需要無損 PNG 或 WebP 無損；截圖需要品質 85-90 的 4:4:4 JPEG；照片需要品質 75-80 的有損 WebP。全部以品質 60 壓縮會節省位元組，但在圖示上引入紅色邊紋、截圖周圍出現環繞效應、照片出現色帶。更智慧的流程是為每個類別執行不同的編碼器路徑，這就是接口允許為每個檔案覆寫目標格式的原因。 展望未來，JPEG XL（ISO/IEC 18181，2022）是 Google 和 Cloudflare 自 2020 年以來推動作為 JPEG 後繼者的格式：相同品質下約小 20%、完整的無損模式、無色度子取樣、對慢速網路友善的漸進式解碼。瀏覽器支援有限（Chrome 在 110 版移除了 JPEG XL），因此目前實際的遷移路徑是品質 80 的 WebP、需要額外位元組節省的首圖使用 AVIF，以及為舊版 Safari 或較舊的電子郵件使用者端保留 JPEG 回退。本頁面將品質、最大尺寸和目標格式作為三個重要控制項暴露；其餘都是實作細節。
• 服務端轉換生命週期：每個上傳檔案僅在 libvips 解碼 + 重新編碼並將結果串流回傳期間存在；無論轉換成功還是失敗，臨時檔案都會在回應關閉時刪除。原本會讓瀏覽器主執行緒卡頓 200-500 毫秒的 24 MP JPEG 完全在使用者裝置之外完成處理。
• 遷移方向：AVIF 是下一代目標（Alliance for Open Media，AV1 幀內編碼，支援 10/12 位元、Alpha、動畫）。即便在服務端透過 libavif/aom 編碼，速度仍比 WebP 慢 10-30 倍，因此大多數頁面堅持使用品質 80 的 WebP，並將 AVIF 保留給受益於額外 15-20% 位元組節省的首圖。