跳至正文
所有教學

WebM Alpha 與 ProRes 4444

WebM Alpha、ProRes 4444 還是 PNG 序列:透明動畫應該怎麼選?

用同一段 96 影格透明動畫實測 WebM Alpha、ProRes 4444 和 PNG 序列,對比檔案大小、解碼後 Alpha,並提供全部範例下載。

AnimGen更新於 15 分鐘閱讀
AnimGen 透明格式對比封面,同一個戰士揮砍影格旁展示 WebM Alpha、PNG ZIP 和 ProRes 4444 的實測大小
本文目錄

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 是否在處理過程中丟失。

等軸戰士揮砍動畫中的真實透明 RGBA 來源影格

可以直接下載本文使用的檔案:

兩份影片都由目前 AnimGen 匯出編碼器從這 96 張來源影格產生。WebM 探測結果是 VP8,並帶有 ALPHA_MODE=1;MOV 為 ProRes 4444 profile、ap4h codec tag 與 yuva444p12le 像素格式。隨後我們分別把兩份影片解碼回 96 張 PNG,才進行後面的透明度和像素對比。

本機安裝 FFmpeg 後,可以對任一下載檔案檢查相同的容器與影片流欄位:

bash
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×

同一段 96 影格動畫匯出為 WebM Alpha、PNG ZIP 和 ProRes 4444 後的實測檔案大小

這個壓縮倍率只屬於本次範例。解析度、時長、畫面細節、運動幅度、編碼參數,以及 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 肉眼都一定更好”。

WebM Alpha 與 ProRes 4444 解碼後的 Alpha 和可見 RGB 誤差結果

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。建議按這個順序排查:

  1. 把同一匯出的 PNG 影格分別放到淺色和深色背景上。
  2. 如果 PNG 正常透明,用明確支援相應編碼與 Alpha 模式的解碼器或合成工具檢查影片。
  3. 確認伺服器以 video/webm 提供 WebM,以 video/quicktime 提供 ProRes MOV。
  4. 在真實目標瀏覽器或軟體中測試,不要只看作業系統產生的縮圖。
  5. 如果所有輸出都不透明,再返回檢查來源圖 Alpha 和透明匯出設定。

上面的三背景測試看似簡單,卻很有效:真實透明邊緣應該能適應多種底色,而不是隻在一個方便的背景上看起來正常。頭髮、發光、運動模糊、陰影和接近鍵色的顏色,需要比空白四角更仔細地檢查。透明格式相容性和透明匯出排障整理了更完整的檢查方法。

一套更穩妥的匯出策略

一個專案不必一輩子只選一種格式。更穩妥的流程是:

  1. 先產生動作,並裁出真正有用的區間。
  2. 首先匯出 PNG 影格,把代表影格放到多種背景上檢查。
  3. 根據團隊是逐影格製作還是時間線製作,保留 PNG 序列或 ProRes 4444 作為生產原始檔。
  4. 目標是網頁時,再產生 WebM Alpha 並實測瀏覽器。
  5. 目標是即時遊戲時,產生精靈圖或對應引擎包。
  6. 把 FPS、影格順序、畫布尺寸與 pivot 資訊和素材一起儲存。

AnimGen 的免費 PNG 影格匯出,可以先確認結果是否真的可用,再決定是否購買生產格式。WebM Alpha、ProRes 4444、精靈後設資料、引擎資產包與商業使用權以目前付費方案或 Credit Pack 權益為準;請直接檢視目前匯出與商業使用權益,不要依賴文章裡可能過期的固定價格。

如果你已經有一張透明 PNG 角色圖,可以從透明動畫工作流開始,產生動作,再根據下一個工具的實際要求選擇匯出。優先選擇能夠被驗證、編輯並最終交付的格式,不必追求規格聽起來最強的選項。

查看圖片細節