
本文目錄
WebM Alpha、ProRes 4444 和 PNG 序列都能儲存透明度,但分別面向不同的交付環節。網頁交付優先考慮 WebM Alpha,剪輯與合成優先考慮 ProRes 4444,需要逐影格控制或通用母版時保留 RGBA PNG 序列。
僅有這個結論還不夠。相同動畫匯出後究竟有多大?經過影片編碼和再次解碼,Alpha 是否真的還在?我們把同一段 AnimGen 動畫分別匯出為三種格式,記錄檔案大小,再把兩種影片完整解碼回 96 影格,與源 PNG 做逐像素對照。本文使用的檔案也全部開放下載。
按最終交付目標選擇格式
| 最終去向 | 建議首先選擇 | 原因 | 主要代價 |
|---|---|---|---|
| 網站或相容的瀏覽器執行時 | WebM Alpha | 單個透明影片,體積緊湊 | 不同瀏覽器對 Alpha 的支援不一致 |
| 影片剪輯、動態圖形或合成 | ProRes 4444 | 帶 Alpha 的高品質交換格式 | 檔案明顯更大,不適合常規網頁交付 |
| 逐影格檢查、歸檔或自定義流程 | RGBA PNG 序列 | 每一影格都是獨立無損圖片 | 檔案數量多,需要額外儲存順序與播放速度 |
| 2D 遊戲即時執行 | 精靈圖或引擎資產包 | 影格、時間與引擎後設資料一起交付 | 需要繼續檢查貼圖、軸點、過濾與匯入設定 |
如果整個流程都由你控制,可以把 PNG 序列留作通用原始檔,再按目標產生 WebM、ProRes 或遊戲資產。若只匯出一種,就從“下一個軟體如何使用它”出發,而不是從格式名字聽起來是否專業出發。
同一段透明動畫,三份真實檔案
本次使用 AnimGen 公開的等軸戰士揮砍序列。原始檔包含 96 張 512 × 512 的 RGBA PNG,按 24 FPS 播放,共 4.00 秒。畫布尺寸固定,動作不迴圈,四角都是完全透明像素,適合用來檢查 Alpha 是否在處理過程中丟失。
可以直接下載本文使用的檔案:
兩份影片都由目前 AnimGen 匯出編碼器從這 96 張來源影格產生。WebM 探測結果是 VP8,並帶有 ALPHA_MODE=1;MOV 為 ProRes 4444 profile、ap4h codec tag 與 yuva444p12le 像素格式。隨後我們分別把兩份影片解碼回 96 張 PNG,才進行後面的透明度和像素對比。
本機安裝 FFmpeg 後,可以對任一下載檔案檢查相同的容器與影片流欄位:
ffprobe -v error -show_entries "stream=codec_name,profile,codec_tag_string,pix_fmt,width,height,r_frame_rate:stream_tags=ALPHA_MODE:format=duration" -of json your-export.webm
但 metadata 不是透明度的最終驗收,因此本文還實際解碼了全部影格,並把它們放到不同背景上檢查。
檔案大小實測
這一個範例的結果如下:
| 輸出 | 精確位元組數 | 約合大小 | 相對 WebM |
|---|---|---|---|
| WebM Alpha | 828,010 位元組 | 0.79 MiB | 1× |
| PNG 序列 ZIP | 14,427,494 位元組 | 13.76 MiB | 17.42× |
| ProRes 4444 MOV | 20,052,159 位元組 | 19.12 MiB | 24.22× |
這個壓縮倍率只屬於本次範例。解析度、時長、畫面細節、運動幅度、編碼參數,以及 ZIP 如何組織 PNG 檔案,都會改變大小。本例的 WebM 明顯更小;PNG 序列和 ProRes 則以更高的儲存成本,換取更適合製作環節的檔案結構。
影片經過解碼後,透明度還在嗎?
在這次測試中,兩種影片都保留了透明度。解碼後均得到 96 影格,Alpha 範圍都是 0–255,四角取樣仍為完全透明。同一影格放到淺色、深色和高飽和背景上,下面的背景都能透出來,沒有被一塊固定矩形覆蓋。
我們還在 0–255 的通道範圍內,計算瞭解碼影格相對源 RGBA 影格的平均絕對誤差:
| 解碼輸出 | Alpha 平均誤差 | 單影格最高 Alpha 平均誤差 | 可見區域 RGB 平均誤差 |
|---|---|---|---|
| WebM Alpha | 0.0497 | 0.0911 | 2.5984 |
| ProRes 4444 | 0.0016 | 0.0038 | 0.4524 |
RGB 對比中的“可見區域”是指來源圖 Alpha 大於 8 的像素;數值為 0 才代表逐像素完全一致。本例裡,兩種格式都保住了可用的透明度,而解碼後的 ProRes 在 Alpha 與可見 RGB 上都更接近來源圖。這符合兩類格式的常見定位,但一次範例並不能推出“任何場景下 ProRes 肉眼都一定更好”。
PNG 序列不需要經歷影片編解碼:ZIP 裡的內容就是原始獨立 RGBA 影格。因此當你要判斷問題來自產生結果、影片編碼還是目標播放器時,PNG 是最清楚的基準。
網頁交付:優先考慮 WebM Alpha
透明角色、特效或吉祥物需要在相容的瀏覽器或 Web 執行時播放時,WebM Alpha 通常是更合適的第一選擇。本例不到 1 MiB,避免了傳輸 96 張圖片和更大的合計體積,也不需要讓網頁自己管理逐影格播放。
但有兩點必須考慮。
第一,“支援 WebM”不代表一定支援這個編碼組合中的 Alpha。AnimGen 目前匯出的是 VP8 Alpha。MDN 的影片編碼指南指出 Safari 不支援 VP8/VP9 影片 Alpha。需要實測產品真正覆蓋的瀏覽器、作業系統、裝置、內嵌 WebView 和播放器。
第二,準備一張真正透明的 PNG poster 或降級圖。現代瀏覽器可能認識 <video> 標籤,卻無法正確解碼或合成你提供的 Alpha 影片。更穩妥的實現是用獨立 <img> 兜底,確認目標播放路徑可用後再切換到影片。網頁透明角色動畫實戰提供了完整 HTML、CSS、降級邏輯、減少動態效果支援和可下載範例。
以下情況適合 WebM Alpha:
- 下載體積很重要;
- 只需要連續播放,不需要在執行時直接讀取每一影格;
- 已經明確並實測瀏覽器或執行時範圍;
- 可以為不相容環境提供 PNG 降級。
如果以後還要精修單影格,不要把 WebM 當作唯一母版。
剪輯與合成:優先考慮 ProRes 4444
ProRes 4444 面向需要 Alpha 的動態圖形、合成與中間交換流程。Apple 的 ProRes 白皮書說明,ProRes 4444 與 4444 XQ 支援 4:4:4:4 影像來源,並支援最高 16-bit Alpha 通道。
本例裡,ProRes 解碼結果在 Alpha 和可見 RGB 上都比 WebM 更接近來源影格,代價則是體積:4 秒 MOV 為 19.12 MiB,大約是 WebM 的 24 倍。對於剪輯母版,這可能完全合理;對於網頁素材,則通常沒有必要。
以下情況適合 ProRes 4444:
- 下一站是剪輯、合成、廣播或動態圖形工具;
- 希望用一個時間線友好的影片,而不是一整個影格目錄;
- 中間製作階段更看重顏色與 Alpha 保真,而不是下載體積;
- 已經在真正使用的軟體中驗證 ProRes 4444 Alpha。
不要因為 ProRes 能帶透明度,就把大型 ProRes 母版直接放上網站;應該另做輕量交付版本。
逐影格控制與排障:選擇 RGBA PNG 序列
PNG 序列是最不含糊的動畫表達方式。每一影格都是獨立 RGBA 圖片,可以直接檢查,也能只替換有問題的影格,而不用重新編碼整段動畫。PNG 是 W3C PNG 規範定義的無損圖片格式。
下面這些情況尤其適合 PNG 序列:
- 美術需要修正少量影格;
- 自研工具需要直接讀取像素、遮罩或影格矩形;
- 需要保留一個以後還能產生 WebM、ProRes、精靈圖或引擎包的通用原始檔;
- 透明度出了問題,需要把故障定位到具體處理階段。
它的代價主要在管理:96 個檔案必須保持正確順序,播放速度需要單獨儲存,儲存和傳輸也會很快增長。ZIP 便於下載,但編輯器或引擎最終仍要解壓並理解這些影格。
匯入時要檢查檔名排序、FPS、畫布尺寸、pivot、顏色處理、紋理過濾,以及目標軟體使用 straight Alpha 還是 premultiplied Alpha。即便來源影格像素完全正確,不合適的匯入設定仍可能讓邊緣變髒。
遊戲專案還可以選擇精靈圖或引擎包
WebM、ProRes 和 PNG 序列並不是全部選擇。2D 遊戲通常更適合精靈圖加時間/軸點後設資料,或直接使用面向目標引擎的資產包。它們犧牲一部分通用性,換來更直接的即時匯入和更少的貼圖切換。
本次三種格式對比故意保持 512 × 512 單影格輸入完全相同。現有公開引擎範例採用了另一組面向執行時的打包參數,因此不把它們的體積塞進同一張圖。應該把它們視為工作流選擇,而不是本次編碼測試中的“第四根柱子”。
如果目標是 Godot,可以檢視Godot 4 透明動畫匯入實測:文章包含完整公開資產包、96 個影格區域、播放時間與可復現專案。輸出格式文件則列出了精靈圖、Unity、Godot、Unreal Paper2D、Cocos Creator 及對應 API 格式名。
為什麼透明影片有時會顯示黑底?
看到黑色矩形,並不能馬上證明檔案丟了 Alpha。建議按這個順序排查:
- 把同一匯出的 PNG 影格分別放到淺色和深色背景上。
- 如果 PNG 正常透明,用明確支援相應編碼與 Alpha 模式的解碼器或合成工具檢查影片。
- 確認伺服器以
video/webm提供 WebM,以video/quicktime提供 ProRes MOV。 - 在真實目標瀏覽器或軟體中測試,不要只看作業系統產生的縮圖。
- 如果所有輸出都不透明,再返回檢查來源圖 Alpha 和透明匯出設定。
上面的三背景測試看似簡單,卻很有效:真實透明邊緣應該能適應多種底色,而不是隻在一個方便的背景上看起來正常。頭髮、發光、運動模糊、陰影和接近鍵色的顏色,需要比空白四角更仔細地檢查。透明格式相容性和透明匯出排障整理了更完整的檢查方法。
一套更穩妥的匯出策略
一個專案不必一輩子只選一種格式。更穩妥的流程是:
- 先產生動作,並裁出真正有用的區間。
- 首先匯出 PNG 影格,把代表影格放到多種背景上檢查。
- 根據團隊是逐影格製作還是時間線製作,保留 PNG 序列或 ProRes 4444 作為生產原始檔。
- 目標是網頁時,再產生 WebM Alpha 並實測瀏覽器。
- 目標是即時遊戲時,產生精靈圖或對應引擎包。
- 把 FPS、影格順序、畫布尺寸與 pivot 資訊和素材一起儲存。
AnimGen 的免費 PNG 影格匯出,可以先確認結果是否真的可用,再決定是否購買生產格式。WebM Alpha、ProRes 4444、精靈後設資料、引擎資產包與商業使用權以目前付費方案或 Credit Pack 權益為準;請直接檢視目前匯出與商業使用權益,不要依賴文章裡可能過期的固定價格。
如果你已經有一張透明 PNG 角色圖,可以從透明動畫工作流開始,產生動作,再根據下一個工具的實際要求選擇匯出。優先選擇能夠被驗證、編輯並最終交付的格式,不必追求規格聽起來最強的選項。



