ループ動画を思い通りに作ろう！パディング値とセクション設定【FramePack-eichi検証①】

こんばんは、スタジオ真榊です。前回に引き続き、ローカル動画生成ツール「Framepack-eichi」の各種検証を行っていきます。今回は動画の動きを激しくでき、セクションごとのキーフレームを守ることもできる「オールパディング機能」についての検証です。

＜注意＝記事中にR-18画像・動画が多数含まれます。閲覧時は周囲にご注意下さい＞

前回の記事をベースとして、今後はさまざまな枝記事で検証を重ねていきたいと思っています。「動画をどう作るか」だけでなく、これまでと同様AIイラストやAI漫画を作るときにどう活用できるか、LoRAや背景素材に使えるか…といった気になる部分を順次検証していくつもりです。

Framepack-eichiは日々盛んにアップデートが加えられているリポジトリですので、記事内容と最新バージョンでUIや使い勝手が変更になる可能性があります。記事中のスクリーンショットが古いUIの場合もありますので、記事執筆時のバージョンをご確認ください。（本記事はv1.61現在）

１．オールパディング機能とは

まず最初に、オールパディング機能で設定できる「パディング値」とは何で、なぜ低くするとキーフレームが守られるのか、本家FramePackのペーパーなどを基に考えてみます。

FramePackは動画生成を複数のセクションに分割して、未来から過去へ向けた順で処理していくわけですが、1つのセクションを処理するとき、生成したフレーム群をTransformerが読めるよう「一定の長さのコンテキスト配列」に詰め替えてから渡しています。このとき、足りない分は「境界フレームを複製して埋める」作業を行います。これがパディングです。

かなり乱暴に言い換えてみます。セクションごとにFramePackが作るお弁当箱は、きちんと埋まっていないとAIが食べられません。おかずにスキマがあるとき、FramePackはその分ご飯を「カサ増し」して見栄えを整えます。この「カサ増し」がパディングで、その度合いを示す係数が「パディング値」であると考えてみます。

本家FramePackの場合、セクションごとに「どれだけご飯を足してカサ増しするか」を自動で計算するわけですが、eichiに搭載されたオールパディング機能は、この「カサ増しの量」をユーザーが一発で変えられるつまみを付けた改造版、ということになります。

パディング値が低いほど境界フレームの複製が最小限になり、各セクションが実際に動くべきフレームでほぼ埋まるので、動きが激しくなります。最低値の0.2の場合、お弁当のどの区画もご飯（コピペ）少なめでおかず（キーフレームを参考に作られた本物のフレーム）ぎっしりな感じになるのですね。するとキーフレームの支配が強くなり、eichiによって現在のフレームと違うキーフレームに切り替わった瞬間、一気に姿勢が変わって動きが派手になるわけです。逆にパディング値が大きいと、カサ増しによって各セクションの頭とお尻に同じフレームが大量に並ぶので、セクション境界の前後でほぼ同じ画が続きやすくなるようです。

この例え話は乱暴でかなり穴があるのですが、eichiのReadMeにある通り「オールパディング機能を起動して、数値を低くするほど動きが激しく、キーフレーム指示を厳格に守る」「数値を高くするほど緩和され、キーフレーム通りに動かなくなる」とだけ覚えておけば遠からずだと思います。

２．実際の生成比較

理屈だけ考察しても理解が進まないので、実際にループモードにおける比較実験を行います。前回に引き続き、こちらのスタート・エンドフレーム（下がスタートで上がエンドである点に注意）を使います。

6秒モードを選択し、上のプロンプトで動画を作りましょう。セクション設定は以下の通りで、パディング値のみを変更してみます。まずはテスト生成ですので、このように、すべて同じ深く咥えた画像を設定してみました。（結果的に失敗しますが、まずはこのままお読みください）

各秒数モードごとにセクション数は変わり、赤いふちがあるのが特に重要なセクション。何度も書きますが、上から下へ生成されるので、出力されるのは下から上へ向かう動画です（重要）。6秒の場合、最初に参照し生成されるエンドフレームが「キーフレーム画像0」となります（重要）

・パディング0.2（最低値）

まず最低値であるパディング値0.2から試します。

このように、「スタートフレームから指定キーフレームに瞬間移動し、最終セクションだけは等速直線運動で最終フレームに戻る」という動作をしました。パディング値の効果が非常に分かりやすい結果です。

なぜこうした動きをしたか考えてみます。最初に生成されるセクション0（動画の最後）では、終わりのフレームが目を開けた画像（final frame）、セクションの始まりが「キーフレーム画像0」となるので、「目を閉じた画像から目を開けた画像へ素早く等速直線運動する」セクションとなりました。その後、セクション1、2、3の順で生成されますが、どれもセクション開始/終了フレームとも目を閉じた画像がキーフレーム画像として指示されているので、セクション0で辿り着いた目閉じ画像のまま微動だにしなくなったのです。最後のセクション4（動画の冒頭）でも同じことが起きますが、動画の最初は目を開いた画像（スタートフレーム）にしなくてはならないため、「生成の最後の最後＝動画が始まった瞬間」に目を閉じた画像に瞬間移動するしかなかったわけですね。

・パディング1.0

今度はパディング1.0です。0.2のときほど厳格にキーフレームを守らねばならないわけではないので、ある程度揺らぎが出るはずです。

パディング値0.2と比べると違いは明らかですね。

セクション0では、最後のフレームが目を開けた画像（final frame）であることは確定していますが、「こう変えて」という指示であるキーフレームをパディング値0.2のときほど厳格に守りません。そのため、動画の終盤では「プロンプトに従ってやや動かすが、あまりエンドフレーム（目を開けた目を画像）から大きくは動けない」という結果になりました。セクション1、2、3でも同じことが起こります。ところが、最後に生成されるセクション4ではキーフレームが優先されて、目を閉じた画像から開いた画像へ等速直線運動で動くセクションになりました。ついでに、0.2のときと同様に最初のフレームだけは目を開いた画像にしておこう…という不自然な動きになりました。

ここまでで分かるのは、「セクション4の画像はスタートフレーム画像と同じにしないと、動画の始まりから瞬間移動が起きてしまう」ということです。そして、パディング値が0.2だと動画のほぼ全体（最終セクションを除く）がキーフレーム画像を厳格に守ることとなり、パディング値が1.0になるとそこまで厳格に守り続けられず、動画の早い段階で最終フレームに向けて動いてしまう…という法則が分かりました。

・パディング2.0、3.0

その後パディング値2.0、3.0でも同じ実験を行いましたが、基本的な動きは1.0とほぼ同じでした。下の動画はパディング3.0ですが、見ていただくと分かる通り、全体の流れは1.0とほぼ変わらず【動画冒頭のセクション4：瞬間移動後、等速直線運動】【セクション3～0：少し揺らぐものの、ほぼエンドフレーム画像と変わらない】という動画になっています。内部で起こっていることもパディング値1.0のときとおそらくほぼ同じですね。

ループ動画におけるオールパディング機能は、基本的に0.2から0.6程度で調整するのがベターなようです。数値が大きすぎると、上の動画のように生成の最後（つまり動画の最初）までなかなかキーフレームまでたどり着けなくなり、数値が小さいと、生成の最初（つまり動画の最後）でさっとキーフレームに移動する…という動きになります。順当に考えれば、0.2～1.0の間に設定すると、動きが動画の中央付近に移動することが想像できますね。

・瞬間移動を防ぐには？

ここまでの検証によって「最初に生成される（一番数字が大きい）セクションの画像はスタートフレーム画像と同じにしないと、動画の始まりで瞬間移動が起きてしまう」ということがわかりましたので、今度は以下のようなセクション構成にしてみます。動画の始まりと終わりに当たるセクション番号4と0をスタート・エンドフレームの画像と同じにしました。

こうするとどうなるのか、生成前に考えてみます。スタートフレームとセクション4のキーフレームが一致しているので、動画の冒頭で瞬間移動は起こらず目を開いた画像から始まります（生成順は最後）。次のセクション3に入ったとたん目を閉じたキーフレーム画像に向かって素早く動き、セクション2、1はその画像のまま、0は目を開いたエンドフレーム画像に向かう…というような結果になるはずです。つまり画像の並びそのままに、５つのセクションで「A→B→B→B→A」の動きになれば成功です。

こちらが生成結果。パディング値0.2です。

お見事！瞬間移動がなくなり、ちゃんと意図通り「A→B→B→B→A」の動きになりました。

これで、まず6秒動画における2点間の移動であれば、意図通りにコントロールできるようになりました。次に思いつくのは、「A→B→B→B→A」の動きができたなら、「A→B→A→B→A」もできるだろう、ということです。

３．「ABABA」の動画を作る

先ほど得た知見にしたがって、次のようにちょうど真ん中のキーフレーム画像2を変更します。セクション01234の順番で生成され、ちょうどピストン運動をする形になるはずですね。（動画の時系列は下から上）

設定はさきほどと変わらず、パディング値0.2で6秒モード。プロンプトも同じ、日本語で「女の子が頭を激しく下げたり、上げたりする。カメラ目線のまま、ペニスを口にくわえ、不満そうな表情で睨んでいる。ときおりまばたきをする」です。

こちらが生成結果。

大成功ですね！

これでおおむね、オールパディング機能によるキーフレームコントロールの基本が確認できました。

・パディング値1.0

さきほどの動画はパディング値0.2だったので始終等速直線運動でスムーズに遷移したわけですが、全く同じ設定でパディング値1.0にするとどうなるかというと…

このように、キーフレーム画像の影響が薄すぎて、あいまいな動きに終始します。ループ動画を作るなら、オールパディング機能をオンにして1.0よりもかなり弱めないと、思ったような動きはしてくれないということです。

・パディング値0.5

そして、最後に試すのがパディング値0.5。0.2と1.0の間なので、よりキーフレームを守ろうとはしますが、完全に指定画像の通りにはならず、ちょうどよい「揺らぎ」が生まれてくれるはずです。

こちらが生成結果。

こちらも思った通り「ほどよく揺らいだ」結果になりました。パディング値0.2ほど厳格に守らないまでも、かなりキーフレーム画像の影響が強いため、ほどよくランダマイズされて自然な動きになっています。キャラクターとしての一貫性も問題なく保てているので、0.2～0.6程度の間で状況に応じて設定するのがループ動画のコツということになりそうですね。

４．ループ動画のワークフロー小括

ここまで得られた知見をループ動画のワークフローとしてまとめると次のようになります。

①「ループモード」を選び、秒数のモードを決定。秒数に応じたセクション数が内部で決定する（6秒なら5セクション）

②上段のエンドフレーム（FinalFrame）に動画の始点・終点となる画像Aを入力。自動でスタートフレームにもコピーされる。

③セクション設定欄を展開。一番上のセクション0に同じ画像Aを投入。一番下の数字が一番大きいセクションにも同じ画像Aを投入します。（分かりやすいようにこう書きましたが、画像A部分は空欄でも結果はほぼ変わらないです。空欄の場合スタート・エンドフレームが優先されるためです）

④5セクションのループ動画ならA→？→？→？→Aという動きになるので、中間の三つのフレームを設定する。動画の最初は一番下のセクション、動画の最後は一番上のセクションなので、動画の順と逆に並べます。

⑤オールパディング機能をONにし、パディング値を記入する。基本は0.2。あまりロボット的な等速直線運動になりすぎるようなら多少強めてもよい。（強めすぎるとランダム性が上がり、プロンプトの影響が強まる）

つまり、ABABAで動かすにせよ、ABCDAにするにせよ、その数だけキーフレーム画像を自分で用意する必要があります。また、パディング値0.2だとプロンプトの影響はほぼ見られませんので、単にモーフィングしたような動きになってしまうことも留意が必要。破綻や矛盾があるとそこが「うにょーん」と変化してしまうということも覚えておきましょう。

５．８つのポーズを動かす

さて、FramePack-eichiによるループ動画のポイントが理解できたところで、もっと複雑な動きをさせてみましょう。

ループ画像なので最初と最後の画像は同じ。その間の８コマを経由して、ずっとループできる動画にしてみようと思います。制服の細部は多少デザイン矛盾がありますが、どのようにモーフィングするかも確かめたいので、インペイントで直さずそのまま生成してみましょう。

この枚数だと、10セクションからなる10秒モードが適しているはず。先ほどのワークフローに従うと、セクション画面は以下のようになります。生成順は上から下なので、動画的には下から上へ遷移していきます。

こちらが生成結果。ある重大なことが分かります。

あれ？また冒頭で「瞬間移動」が起きてしまいました。なぜでしょうか。

セクション9とファーストフレームはちゃんと一致しているはずなのに、一瞬でセクション8のポーズに飛んでいます。そのほか、おおむね番号順にポーズが遷移できているのですが、後半アップになったところで妙に動きが鈍る瞬間もありました。

これはおそらく、「1秒＝1セクションではない」問題のせいだと思われます。実際、6秒モードは5セクションでしたよね。10秒モードは8～9セクションになるはずが、10セクション分表示されているので、最後のセクション9（0から数えるので10個目）がおそらくほとんど秒数のないセクションになってしまったのだと考えられます。なので、セクション9の生成が始まって一瞬でセクション8に飛ばざるを得ず、瞬間移動が起きたのですね。

・正しい設定は？

ならば、正しいセクション設定は以下になります。一つポーズを減らして、最後の二つのセクションを同じキーフレーム画像にすれば解決です。さきほどはスタート・エンドフレームを除くと八変化でしたが、一つ減って「七変化」になるわけですね。

こちらの設定で作り直した10秒動画がこちらです。

冒頭部分の「瞬間移動」はこれで避けられました。3秒あたりの瞬間移動は、おそらくプロンプトに従って口パクをさせ始めてしまい、そっちに気が行っていたせいでうまくつながらず、ワープしてしまったんじゃないかと想像しています。

ただ決まったキーフレームをモーフィングするように遷移するだけだと、非常にロボット的な変化になって、アニメーションとしては退屈になります。なので、プロンプトで上手に合間を「揺らいで」つないでほしいわけですが、そこが結構難しいんですよね。今回の実験で、キーフレームをなんとなく守らせることはできましたが、実際に自然なアニメーションを作りたい場合は、むしろ推論してもらう合間部分をプロンプトによってどれだけ自然に演出できるかがキモになるかなと思います。

６．「キリの悪い」秒数がある？

さきほどの例のように、「1秒＝1セクションではない」ので、セクションに分けたキーフレームが必ずしも均等に動画上で現れてくるわけではない、というのは一つ覚えておくべき事情かと思います。回避方法としては、少し長めの尺をとって、最初と最後の1セクションだけでなく2セクションずつサンドイッチにすることで「瞬間移動」を避け、あとで余分な前後があれば動画編集で落とすようにするのがよいでしょう。

おそらく秒数モードごとに「キリが悪い」モードがあるはずなので、使い勝手の良い秒数を重用することになるかもしれませんね。6秒モードと12秒（4×3）モードは比較的キリがよく、使いやすいモードかなと思います。

７．通常モードでの「パディング値」

今回はループモードについての検証でしたが、スタート・エンドフレームを指定した通常の動画生成では、パディング値はどのように影響するでしょうか。

こちらは6秒の通常動画を「パディング値0.2」で生成したときの失敗例です。「camera rotates around the character like a turntable.」というプロンプトでぐるりと回したかったのですが、何が起きたかというと、動画の最後のセクション（つまり最初に生成されるセクション）でこのように「ピャッ！」と回転して、あとはずっと正面のまま…という動画になってしまったわけですね。

「パディング値0.2」はその1秒ほどのセクション内であっという間に目標のキーフレームにたどり着かせたいときに使うものです。このようにゆっくり等速で目標のキーフレーム（この場合は背面の画像）へたどり着いてほしいときは、オールパディングモードを使わないか、パディング値1.0あたりにするのが良いかなと思います。

ちなみに、このような差分ペアはChatGPTなどに頼んでも結構うまく作ってくれます。ただ、頭身や画風がやはり少しおかしいのと、下図のように間違い（上げている手が左右違う）が起こること、元画像とアスペクト比が異なっていることがあるので、その点は注意して使うようにしてください。

通常モードにおける基本のセクション設定は以下のようになります。上が動画の終わりで、下が動画の始まりと考えてください。「終始始始始始始…」のようにきれいに並ぶと等速直線運動的な動画になりやすいです（Seed値により失敗もあり）

キーフレーム自動コピーをONにしておいて、下のセクション0へスタートフレームの画像を入力すれば、全部のセクションにコピーされるので楽です。一つ一つディレクトリ開いて選択してると鬼時間取られますからね…。（※コピー機能は頻繁に仕様変更されており、バージョンによっては使えません）

こちらが生成結果です。

これをフレームとして切り出してimage2imageしたりすれば、キャラクターLoRAの材料として使いやすいかなと思います。エンドフレームを指定しなかった場合も回転させることはできるのですが、品質はそちらの方がよいものの、45度-90度くらいまでしか回ってくれないので、背面を用意した方が現状は楽に出せるかと。

HunyuanLoRAが充実して簡単に使えるようになると、もっと簡単に「別角度」を出せるようになると思います。（ただ、LoRAを使うと生成時間が3倍とかになるので、漫画にぽんぽん使うにはまだもう少しかかるかも）

終わりに

そんなわけで、ループ動画を思い通りに作ろう！パディング値とセクション設定【FramePack-eichi検証①】でした。

動画生成ツールとしては、FramePackはかなり「オーダーメイド性」「振り付け性」の強いプロジェクトだなというのが、ここ数日触っていた印象です。つまり、完全に自分の思った意図通りに動いてほしくて、それ以外の動きはあまりしてほしくないときに扱いやすく、もっと雑に「なんか自由にダンスしてほしい」とか「一枚だけH画像あげるから動画にして」といった場合は、wan2.1を使った動画作りの方がニーズに沿うはずです。

特にzuntan（@zuntan03）さんのこちらの投稿などを見ると本当に凄まじいことができていて、これはFramePackのセクション設定には向かない作業だなと思います。「振付師」になりたい場合はFramePack、「映画監督」になりたい場合はWAN（EasyWanVideo）といったように、今後棲み分けが進んでいくのではないかなと想像しています。

それでは今回はこのへんで。スタジオ真榊でした。