最佳化 GIF 檔案意味著重新編碼一個動畫 GIF,讓它在仍以 GIF 格式播放的情況下佔用更少的位元組。這個格式中最可靠的調整手段是色彩調色盤:每個 GIF 影格都只能使用一張固定數量的色彩對照表,如果將這張對照表從 256 個項目縮減到 128 或 64,當作品本身不需要這麼多色彩時,就能減少位元組數量。GIF Optimizer 正是直接在您的瀏覽器分頁中執行這項作業,無需上傳,也不需要帳號。您選擇一個調色盤大小,頁面就會解碼您的檔案、將每個可見影格合成到底層畫布上、依據所選上限重新編碼每一格,然後並排顯示原始大小與新的大小,讓您看到實際的位元組變化,而不是一個含糊的承諾。這很重要,因為 GIF 已經是經過壓縮且以調色盤為基礎的格式,所以沒有任何轉換能保證一定讓檔案變小,而一個隱藏其唯一變數的工具,等同於在隱藏您這份特定輸入的真相。
GIF 是一種以調色盤為基礎的格式,當初是為短小的循環動畫與有限的色彩數量而設計。這也說明了為什麼沒有一個通用的「GIF 最佳化工具」能在每個檔案上都勝出。真正會影響結果的變數包括使用的色彩數量、每影格的像素區域、銷毀與透明度的行為,以及原始檔案是否依賴局部影格補丁來節省空間。一個只重新量化色彩的工具,對它唯一的輸入是誠實的;本文其餘部分會逐步說明可以預期什麼、如何選擇調色盤,以及在決定下載之前,如何解讀前後比較的數字。
如何在瀏覽器中最佳化 GIF 檔案
- 開啟 GIF Optimizer 頁面,點擊檔案選擇器,挑選一個大小不超過 20 MB 且不超過 50 影格的動畫 GIF。
- 選擇 256、128 或 64 色作為調色盤大小。您選的數字就是每個輸出影格可用的最大對照表大小。
- 點擊「Optimize GIF」,讓瀏覽器解碼檔案、將每個可見影格合成成完整的畫布,並在本地重新編碼每一格。
- 比較預覽下方顯示的原始大小與輸出大小。正數代表結果變大;負數代表結果變小。
- 在頁面上的預覽中觀看完整動畫循環,只有在大小與視覺品質都可接受時,才下載新的 GIF。
為什麼調色盤大小會改變輸出結果
每個 GIF 影格儲存兩項內容:一張最多 256 項的色彩對照表,以及一串指向對照表的像素索引。當您把對照表限制為 128 或 64 項時,量化器必須重新映射在新調色盤中找不到相近對應的色彩。這種重新映射可能會把平滑漸層變成可見的色帶、抹平細微的明暗,並在曲線與小字邊緣引入抖動假影。同時,較小的色彩對照表在 LZW 下通常壓縮效果較好,因為索引值保持較小,字典也不需要追蹤那麼多不同的項目。
對檔案大小的最終影響,取決於對您這段特定動畫來說哪個因素勝出。一張調色盤已經很緊湊的簡單平面插圖,可能根本縮不了多少,因為索引串流本來就已經很有效率,幾乎沒有什麼可再壓縮的空間。一段動畫擁有上千個細微色彩階梯,看起來像照片,則可能會大幅縮小,但視覺品質的下降可能不值得換取那些省下的位元組。唯一誠實的確認方式,就是實際執行編碼並把數字並排比較,這正是頁面上大小讀數的作用。
選擇調色盤大小
頁面提供三個明確的選項,每個選項對應一類典型的內容。下表摘要說明您在挑選每個選項時,編碼器所做的取捨。
| 調色盤大小 | 最適合 | 您所付出的代價 |
|---|---|---|
| 256 色 | 照片風格的影格、複雜漸層、動態中的反鋸齒文字 | 縮小幅度最小;與原始檔案的視覺最接近 |
| 128 色 | UI 動畫、螢幕錄影、具中等明暗的插畫角色 | 縮小幅度平衡;在密集漸層中出現輕微色帶 |
| 64 色 | 簡單繪圖、平面圖示、邊緣銳利的迷因與貼圖 | 縮小幅度最大;在柔和邊緣與天空處會出現明顯的簡化 |
這些是輸出控制項,而不是您原始來源已經包含什麼的描述。一個原本只用 32 色匯出的 GIF,不會因為選擇較大的選項就神奇地變成 256 色檔案;編碼器仍然會尊重輸入像素實際上較低的有效色彩數。這些數字描述的是上限,而不是下限。
當結果比原始檔案更大時
重新編碼 GIF 並不保證一定會變小,而頁面對此說得非常明確。以下三種情況經常會產生更大的輸出,在您斷定出了問題之前,值得先認識它們:
- 原始檔案使用了局部影格補丁,在每一個更新週期只重繪一小塊變動的矩形區域。最佳化工具在編碼前會把每個局部更新合成成一張完整的可見畫布,所以一個已經高度最佳化的貼圖或 UI 動畫,在整格重新編碼後反而可能變大。
- 來源檔案已經以緊湊的調色盤與高效率的銷毀順序進行編碼。移除色彩無法變出本來就沒有的空間,而新的調色盤配置在 LZW 下有時反而比原始檔案更不容易壓縮。
- 作品屬於照片風格,因此積極縮減調色盤會迫使大量抖動產生。抖動雜訊比平滑漸層需要更多位元組來編碼,所以即使視覺上的變化顯而易見,輸出檔案仍會變大。
如果顯示的輸出大小大於原始檔案,請把它當作一個真實的結果,而不是 bug。正確的回應通常是保留原檔,或是為輸出目的地選擇不同的格式,而不是假設只要改變調色盤就一定能得到更小的檔案。
輸出保留了什麼、捨棄了什麼
新的 GIF 保留了經解碼的可見影格順序,以及控制播放速度的每影格顯示延遲。它也遵守格式原生支援的單一位元透明度模型,因此透明區域在每個影格之間都保持透明。它不會保留的,則是所有存在於可見像素之外的內容:來源的調色盤對照表會被替換、註解區塊與應用程式擴充區段會被丟棄、原始的位元組層級最佳化方法不會被複製,任何有限的循環次數也會被無限制循環所取代。
這套最佳化工具不會把您的 GIF 轉成影片、音訊軌、WebP 或 MP4。它不會修剪影格、改變播放速度、移除重複影格,也不會調整畫布大小。如果您需要上述任何一項,那是另一個頁面上的獨立作業。下載的會是一個全新的 GIF 位元串流,由同樣的可見影格組成,透過 local Blob 寫入,再以一般檔案儲存的方式交回給您的瀏覽器。
可能讓執行作業失敗的瀏覽器限制
在編碼器配置記憶體之前,頁面會先檢查輸入是否符合一組硬性上限:20 MB 的檔案大小上限、最長 4,096 像素的畫布邊長、每影格最多三百萬像素,以及總計不超過 50 影格。它同時會在內部追蹤累積的補丁與輸出像素預算。一段壓縮過的動畫,解壓縮後可能是磁碟上大小的許多倍,所以一個技術上低於 20 MB 的輸入,若解碼後的體積對瀏覽器分頁來說太大,仍可能會被拒絕。當觸碰到任一限制時,頁面會以明確的錯誤訊息停止,而不會產生半成品,也不會讓一個過期的下載看起來像是新的結果。
一個通常有效率的實務工作流程
- 保留一份原始 GIF 的副本,這樣就能並排比較來源與輸出。
- 從 128 色開始,這是混合 UI 與插畫內容時最平衡的預設值。
- 執行最佳化工具,然後下載結果,在目的地的顯示尺寸下與來源並排播放一整個循環。
- 如果視覺品質可接受,且位元組數也較小,那就完成了。
- 如果視覺品質無法接受,改用 256 色。如果在 256 色下檔案仍然太大,只有在值得為了明顯的簡化效果而進行更激進的實驗時,才改用 64 色。
- 在實際託管素材的平台測試最終成品,因為社群網路、通訊應用程式與 CMS 系統可能會重新處理上傳的檔案,抵銷您本機省下的容量。
為什麼這項作業在本機執行
將 GIF 解碼為像素資料並重新量化這些像素,使用的是標準的瀏覽器畫布操作,包括用 CanvasRenderingContext2D.getImageData 讀取可見影格,以及用 Blob 建構下載資料。因為每一步都在當前分頁中執行,檔案從不送達伺服器,從不進入佇列,也從不留在雲端儲存空間。沒有帳號、沒有登入,也不需要等待上傳進度條。損壞或不支援的輸入會在任何輸出產生前就失敗,所以一個過期的下載絕不會在錯誤訊息之上冒充成新的結果。
延伸閱讀:如何在瀏覽器中將 GIF 縮得更小。