影像與照片 · 影像轉換器和壓縮器
canvas.toBlob 如何在瀏覽器中將 PNG 轉換為 WebP
· 工作原理
影像格式 畫布 網頁
瀏覽器圖像轉換器是連結在一起的解碼器、點陣圖和編碼器，整個鏈內建於瀏覽器中。這篇文章透過解碼、canvas 和 toBlob 將一個 PNG 文件轉換為 WebP 文件，並記錄了在此過程中遺失的內容。
不涉及伺服器時 WebP 從何而來——離線工作轉換器背後的具體問題
WebP 不是來自伺服器端轉換佇列。您的瀏覽器已經具有圖像解碼器、可繪製像素表面和編碼器； ToolAcre 轉換器將它們連接起來。這就是為什麼 PNG 可以在網站載入後在選項卡中進行轉換的原因。 「無上傳」是指來源影像和轉換輸出，而不是指完全沒有網路活動的網站。
第一步：解碼－瀏覽器如何將 PNG 位元組轉換為 RGBA 位圖，以及為什麼每種格式最終都會變成相同的網格
首先，PNG 被解碼為影像點陣圖。 PNG 壓縮、調色板選擇和色彩元資料決定了其位元組如何變成像素，但畫佈在解碼的光柵上工作，而不是在 PNG 檔案的區塊上工作。即使檔案本身小得多，1600×900 的螢幕截圖也會產生 1.44 百萬像素位置。 ToolAcre 使用 createImageBitmap 並強制執行像素預算；大的解碼映像在成為上傳問題之前首先是記憶體問題。
第二步：將畫布作為暫存區域 — 將點陣圖繪製到尺寸匹配的畫布或 OffscreenCanvas 上
點陣圖被繪製到具有請求的輸出尺寸的畫布或 OffscreenCanvas 中。如果這些尺寸與來源相符且未選擇裁剪，則drawImage會暫存像素以進行編碼；如果尺寸發生變化，畫布會對它們重新取樣，且像素值可能會在 WebP 編碼開始之前發生變化。相同的渲染例程服務於互動式預覽和工作路徑，防止這兩個輸出遵循不相關的演算法。
第三步：具有 MIME 類型和品質的 toBlob — 如何選擇編碼器、品質數字控制什麼以及為什麼 PNG 會忽略它
在普通畫布上， toBlob(callback, "image/webp",quality) 要求瀏覽器對 WebP 進行編碼並使用 Blob 進行回調。在 OffscreenCanvas 可用的情況下，ToolAcre 使用 ConvertToBlob({type,quality}) 來完成相同的作業。品質控制有損編碼器；它不是特定位元組數的承諾。 PNG 導出是無損的，其品質參數不會設定類似 JPEG 的壓縮等級。始終檢查實際傳回的格式，因為編碼器可用性取決於瀏覽器。
管道丟棄的內容——元資料、顏色配置檔案和 16 位元精度，以及為什麼這是技術的屬性而不是錯誤
重新編碼已解碼的柵格無法保留原始 PNG 容器中的所有事實。文字區塊、相機或編輯器元資料、某些顏色設定檔詳細資料和源位深度可能無法在畫布往返中保存下來； 16 位通道不會僅僅因為輸入攜帶它們而成為 16 位元 WebP。當編碼器支援時，WebP 可以保持透明度，而 JPEG 匯出需要填滿透明區域。僅檔案大小無法表示轉換是否保留了細線或顏色。
工作範例：將 1.8 MB PNG 螢幕截圖轉為 WebP — 依照檔案執行三個步驟並讀取結果
考慮帶有文字、漸層和透明角落的 1.8 MB PNG 螢幕截圖。對其進行解碼，保持尺寸不變，選擇 WebP，匯出並將 Blob 大小和 MIME 類型與原始文件進行比較。生成的大小是經過測量的，不可預測：乾淨的螢幕截圖可能會壓縮得很好，而嘈雜的內容可能不會。在接受較小的文件之前，請放大小字形和透明角。如果清晰的 UI 文字變得模糊，請保留 PNG 或調整編碼器質量，而不是聲稱 WebP 總是更好。
這不包括動畫圖像、瀏覽器無法解碼的格式以及 API 不公開的編碼器設置
此管道不保證動畫保留、每個裝置上的 HEIC 解碼或對 WebP 編碼器的子取樣和工作參數的完全控制。它還無法透過將 JPEG 來源儲存為 PNG 或 WebP 來恢復已遺失的細節。重複的解碼/重新編碼週期會累積損失。保留原始文件，並使用實際工具頁面上列出的支援的輸入/輸出格式，而不是假設此處接受您的作業系統知道的每種格式。
重點：三步，零上傳－影像轉換器和壓縮器如何在您的裝置上運行此管道
機制是解碼→繪製→編碼，使用瀏覽器API進行，沒有影像上傳。 ToolAcre 公開了目標格式和尺寸，因此您可以判斷您是否只是更改容器或調整像素大小。在處理整批之前，在圖像轉換器和壓縮器中測試一個具有代表性的螢幕截圖，然後以人們將看到的大小檢查下載的結果。