背景透過画像をLTXVに渡すとComfyUIで動画化が止まる
切り出した人物や物だけを残して背景を透かした画像は、ComfyUIの合成用ノードから当たり前に出てくる形式だ。JoinImageWithAlphaで作った透過画像をLTXVの動画化に渡す人は、特別な使い方をしているつもりはないだろう。
ところが、この透過画像を動画化の前処理ノードであるLTXVPreprocessに通すと、圧縮の設定によって結果が変わる。圧縮をかけない状態では透過の情報がそのまま素通りし、圧縮をかけた状態では処理がエラーで止まる。同じ入力なのに、設定一つで動くか止まるかが変わってしまう。
| 入力画像 | 圧縮の設定 | 結果 |
|---|---|---|
| 透過なし | なし | そのまま進む |
| 透過なし | あり | そのまま進む |
| 透過あり | なし | 透過の情報が残ったまま進む |
| 透過あり | あり | 処理が止まる |
止まったときに表示されるのは、想定していない形のデータが渡ってきたという内容のエラーだ。動画を作る側からすると、画像を透過させたことがなぜ動画化の失敗につながるのか、エラーの文面だけでは分かりにくい。
この不具合を報告したsanchit-jarvisさんは、コアのノードだけを使った最小限の手順を示している。空の画像とマスクを合成して透過画像を作り、それをそのままLTXVの前処理ノードへつなぐだけで再現する。
特別な拡張ノードも、モデルの読み込みも必要ない構成だ。手元でComfyUIのノードをつないだことがある人なら、同じ組み方を一度はしたことがあるはずだ。
この報告が重く見えるのは、特殊な使い方を罰しているからではない。背景を透かして動画の素材を整えるという、ごく普通の下準備が引っかかっているからだ。
動画制作の現場では、背景を透過させた素材はむしろ基本の構えだ。人物だけを切り出して別の背景と合わせたり、複数の素材を重ねたりするとき、透過の情報を保ったまま次の工程へ渡すのは当たり前の進め方になっている。
だからこそ、透過画像を動画化の前処理ノードに渡した途端に処理が止まるという今回の報告は、他人事では済まない。普段どおりの素材の作り方をしているだけで、同じ場面に行き当たる制作者は少なくないはずだ。
この報告を読んで気になるのは、画像が透過の情報を持っているかどうかは見た目では判断しにくいという点だ。画面上は背景が黒や灰色で塗られているように見えても、データの中には透過の情報がそのまま残っている場合がある。
圧縮設定を変えるだけで透過画像の扱いが変わる理由
ComfyUI公式のドキュメントは、JoinImageWithAlphaについて、画像と透過マスクを合成し一枚の出力画像にするための合成用ノードだと説明している。つまり透過情報を含む画像は特殊な例外ではなく、公式に用意された合成の仕組みがそのまま生み出す、標準的な出力だということになる。
一方のLTXVPreprocessは、動画の一枚ごとの画像を一定の形式で書き出す処理を担っている。この書き出しの奥では、三つの色の情報だけを前提にした関数が使われており、透過の情報を入れる場所が用意されていない。
圧縮をかけない経路では、この関数を通らずに画像がそのまま次へ渡るため、透過の情報が混ざったままでも表面上は問題が起きない。圧縮をかける経路に入った瞬間、三つの色の情報しか受け付けない関数に四つ目の情報がぶつかり、そこで処理が止まる。
同じノードの中に、透過を素通りさせる経路と、透過を受け付けない経路が両方あるということだ。設定を一つ変えるだけで結果が変わって見えるのは、この二つの経路のどちらを通るかが切り替わるからにすぎない。
報告ではこの点も具体的に比べられている。透過のない画像と、合成用ノードから出てきた透過画像の両方を、圧縮をかけない設定とかけた設定で通した結果が並べて示されており、透過の情報が残っている場合だけ結果が変わることが分かる。
似た処理を行う輪郭線抽出のノードは、入力の先頭にある三つの色の情報だけを取り出してから処理に回しており、透過の情報があっても影響を受けない。LTXVPreprocessにも同じ考え方を当てはめれば直せるはずだと、報告者自身が修正の方向性まで示している。
報告の文面には、入力の形式と圧縮の設定を組み合わせた結果が整理されており、透過のない画像なら圧縮の設定を変えても常に同じ形で次へ進むことが示されている。透過がある画像だけが、圧縮の設定によって結果を変える非対称な振る舞いをしている。
この非対称さが、原因の切り分けを難しくしている。同じワークフローの中で一見関係のない設定を変えただけなのに、処理が止まったり動いたりするように見えてしまうからだ。
圧縮の設定は画質や書き出しの速さを調整するためのものであり、普段は透過の有無と結び付けて考える機会がない。その設定が、内部では三つの色の情報だけを前提にした処理を呼び出す入り口になっているとは、使っている側からは見えにくい。
背景を透過したままLTXVへ渡す前に確認したいこと
すぐにできる確認は、動画化の前処理ノードに渡す直前の画像が透過の情報を持っているかどうかを見ることだ。合成用のノードを経由した画像や、背景を取り除く処理を通した画像は、透過の情報を持ったまま次のノードへ流れていきやすい。
透過の情報が要らない場面なら、動画化の前処理ノードへつなぐ前に、三つの色の情報だけを取り出す処理を挟んでおくと安全だ。輪郭線抽出のノードが同じ状況で問題を起こさないのは、この取り出しを内部で行っているからにほかならない。
透過の情報を残したい場面、例えば切り出した人物を別の背景と動画の中で合わせたいような使い方では、今回の不具合を避けるのが難しい。報告が指す修正が取り込まれるまでは、合成の段取りを動画化よりあとの工程に回すなど、順番を入れ替えて様子を見るほうが安全だろう。
圧縮の設定を無理に下げて止まらないようにする対処も考えられるが、画質と引き換えになるうえ、透過の情報が消えずに残ったままになる場合もある。原因を分かったうえで避けるのと、症状だけを抑えるのとでは、あとで同じ場面に出会ったときの対応の速さが違ってくる。
公開されているテンプレートには、動画化の前処理ノードをそのまま使うものがいくつも含まれている。背景を透過させた素材を使う制作者ほど、気づかないうちにこの経路を踏んでいる可能性があるという点は、あらかじめ知っておく価値がある。
動画を作る側がここから持ち帰れるのは、エラーの文面を暗記することではない。透過の情報がどこで生まれ、どこで消えるはずだったのかを順番で追えるようになることだ。
動画化のテンプレートを配布元からそのまま使っている場合でも、入口で渡す画像を自分で選べる以上、この確認を配布元だけの責任にはできない。渡す画像を用意する側が一度は透過の情報を意識しておく必要がある。
直し方の見込みが共有されている以上、しばらくは今回の確認を手元の手順に加えておくだけで十分だ。直った後も、透過の情報がどこで生まれるかを把握しておく習慣自体は無駄にならない。
このような食い違いは、ノード同士の役割分担が細かく分かれているComfyUIならではの落とし穴でもある。一つのノードの中だけで完結する問題ではなく、合成用のノードと動画化の前処理ノードという、別々に作られた仕組みの境目で起きている。境目で起きる不具合ほど、見落とされやすい。
AI編集部のつぶやき
