若要調整 GIF 檔案大小，請以整數像素設定目標寬度,讓瀏覽器根據來源畫布比例重新計算高度,然後下載重新編碼的動畫檔,確保所有可見影格與每格延遲時間都完整保留在使用者的裝置上。讀者的操作分為三個部分:確認頁面從所選檔案中偵測到的畫布尺寸、輸入新的寬度,以及點擊調整大小按鈕以取得一個可下載的檔案。由於瀏覽器在縮放前會依照每個影格的銷毀指令 (disposal instruction) 解碼所有影格,因此輸出結果會反映觀看者在每個影格邊界應該看到的畫面,而不是原始串流可能使用的原始增量更新區塊。這一點很重要,因為有相當比例的 GIF 會儲存一張完整的首張影像加上較小的更新矩形,而單獨縮放每個原始區塊可能會留下透明破洞、遺失的背景,或在移動物件後方產生殘影。對於需要將 GIF 檔案縮放以符合網站欄位、電子郵件簽名、聊天回覆框、投影片,或固定�度文件版面的使用者來說,以寬度為導向、在瀏覽器內執行的做法是最簡單的方式,可避免使用桌面編輯器、上傳步驟,或伺服器端轉換。GIF Resizer 完全在目前的瀏覽器分頁中執行,使用畫布繪製與 Blob 下載連結,因此來源檔案、解碼後的像素,以及縮放後的結果在使用者主動儲存匯出檔之前,都會一直留在裝置上。
目標寬度如何成為新的 GIF 畫布
該頁面只接受一項幾何輸入:以整數像素表示的輸出寬度。內部會讀取 GIF 標頭與邏輯畫布描述元,然後將要求的寬度除以來源寬度,再將來源高度乘上該比例。計算結果會四捨五入為整數像素,因為 GIF 以整數儲存尺寸,小數值不是被截斷就是被進位,這可能會讓輸出結果差一個像素。寬度是唯一用於控制幾何的參數,因為這能讓長�比保持明確無歧義,而且單一整數輸入也避免了要求輸入兩個可能不具備整潔比例之數值所帶來的模糊性。
對於 800 乘 600 像素的來源畫布來說,輸入 400 的目標�度會產生 400 乘 300 的輸出畫布。運算過程為 400 除以 800 等於 0.5,然後 600 乘以 0.5 等於 300。由於來源尺寸與目標寬度都是整數,而倍率化簡後是一個簡單的分數,因此結果是精確的。瀏覽器會繪製該畫布,將每個完整的輸出影格編碼為一個新的 256 色調色盤,並回報實際使用的尺寸。
逐步縮放 GIF 檔案
- 開啟 GIF Resizer 並從您的裝置中選擇一個動畫 GIF。檔案大小最多可達 20 MB;該頁面會在任何處理開始之前讀取 GIF 標頭並顯示偵測到的來源畫布尺寸。請確認這些尺寸符合您原本打算載入的檔案。
- 以整數像素輸入目標寬度。該頁面會根據來源畫布比例計算對應的高度,並四捨五入至整數像素。請勿輸入百分比或高度值;幾何控制僅由�度決定。
- 點擊「Resize GIF」按鈕。瀏�器會解碼所有可見影格、套用每個影格所攜帶的銷毀指令、使用標準畫布繪製在新尺寸下渲染完整的合成影像,並在本機重新編碼動畫。
- 等待頁面顯示新的輸出畫布尺寸、影格數,以及產生的檔案大小。如果在解碼過程中超出任何瀏覽器端的限制,頁面會顯示錯誤訊息,並且不會留下失效的下載連結。
- 下載縮放後的 GIF,並在瀏覽器分頁或目標應用程式中開啟。在發布檔案之前,請先觀看第一輪循環以確認時間節奏、文字可讀性,以及邊緣品質。
為何縮放可見影格不同於縮放更新區塊
GIF 並非總是完整的圖片序列。許多動畫會儲存一張完整的首張影像,然後再儲存一系列只變更部分畫布的較小更新矩形。這些更新區塊中的每一個也可以攜帶銷毀指令,告訴下一個影格應該保留先前的像素、清除已變更的矩形,或是恢復較早之前的畫布。如果工具單獨縮放每個原始更新區塊,結果將會出現遺失的背景、移動物件後方不正確的殘影,或原始串流原本無需明確繪製之區域中的透明破洞。
GIF Resizer 會先根據這些銷毀指令合成每個影格,然後再縮放完整的可見畫布。輸出結果代表觀看者在每個影格邊界應該看到的內容。來自解碼串流的每格延遲時間會被保留,因此動畫的節奏在縮放後依然能維持。由於畫布是使用瀏覽器的標準二維繪製 API 所繪製,因此結果會與 HTML 頁面在內嵌顯示來源 GIF 時以所要求大小所呈現的內容一致。
GIF Resizer 的限制與瀏覽器會拒絕的情況
瀏覽器會透過明確的邊界來保護自己,讓一個小型的壓縮檔案不會悄悄配置巨大的輸出畫布。任何超出界限的檔案會在縮放開始之前就被拒絕,而不會產生部分下載或讓頁面凍結。已公布的限制如下表所列。
| 限制 | 最大值 |
|---|---|
| 選擇的檔案大小 | 20 MB |
| �輯畫布寬度 | 4,096 像素 |
| 邏輯畫布高度 | 4,096 像素 |
| 單一影格中的解碼像素數 | 3,000,000 |
| 動畫中的影像影格數 | 50 |
| 每個輸出影格的調色盤顏色數 | 256 |
這些檢查之所以重要,是因為一個小的壓縮 GIF 仍可能解碼為非常大的工作畫布。一個 600 KB 的檔案若邏輯畫布為 2000 乘 1500,則每個影格含有三百萬個像素,正好接近每影格上限。如果同一個檔案包含超過 50 個影像影格,即使檔案本身遠低於 20 MB 的上限,頁面仍會拒絕它。了解是哪一項限制拒絕了該檔案,有助於使用者決定是否要裁剪影格數、選擇不同的來源,或先在桌面編輯器中預先處理檔案後再重試。
儲存前先讀取輸出結果
該頁面會在縮放完成後回報三個數字:輸出畫布尺寸、影格數,以及以千位元組 (KB) 表示的產出檔案大小。這些數字反映的是實際編碼後的檔案,而非承諾或估計值,因此變更後的結果會立即可見。如果輸出尺寸看起來不正確,最常見的原因是輸入的寬度未能保留來源比例;請挑選不同的寬度並重新執行縮放。
由於 GIF 使用以調色盤為基礎的色彩,瀏覽器會為每個完整的輸出影格建立一個最多 256 色的新調色盤。漸層、精細的攝影細節與抖色 (dithering) 在經過這第二次調色盤轉換後,可能會呈現不同的外觀。請在瀏覽器或目標應用程式中檢查下載後的動畫再進行發布,特別是在原始檔案包含小字、透明、快速動態,或平滑漸層的情況下。透明像素仍維持單一位元透明,這是 GIF 本身唯一支援的透明模型。此工具最適合用於目前瀏覽器能解碼的一般網頁 GIF;如果來源檔案含有損毀的影格資料、誤導性的尺寸,或無效的 GIF 簽章,頁面會顯示錯誤,並且不會留下失效的下載檔案。
縮放 GIF 檔案是否一定能讓檔案變小?
減少像素通常有助於縮小檔案,但縮放 GIF 檔案並不能保證位元組數一定會變少。輸出是一個全新的 GIF 編碼,而不是對原始串流的逐位元組縮放。影格內容、調色盤選擇,以及 GIF 壓縮方式都會影響最終大小。一個由平面色區域組成、高度可壓縮的動畫可能會大幅縮小,而一個像照片般、影格含有細膩漸層的序列,由於調色盤轉換帶來的每影格變化可能比原始編碼器所記錄的更多,因此最終大小反而可能變大。
對於真正目標在於縮小檔案而非改變像素尺寸的讀者來說,僅靠縮放是不夠的。裁剪影格數、縮減調色盤大小,或移除冗餘的銷�步驟,通常對位元組數的影響會比小幅縮小尺寸來得更顯著。如何在不上傳的情況下縮減 GIF 檔案大小指南會逐步說明這些可在瀏覽器中執行的補充步驟;當目的地同時需要較小的尺寸與較小的檔案時,可以結合使用縮放與調色盤最佳化。如果縮放後的結果已經足夠小以符合目標需求,則無需進一步處理。
若您正在權衡各種方案,如何將 GIF 分割成個別的 PNG 影格對此有詳細說明。