pyramidflow 環境構築のその後。【RTX4060 GPU VRAM 8 GB 】（1）
公開記事順では少し間が開きましたが、本来この記事が上掲記事に
続く予定でした。原画の公開より先にそれを動画化した顛末が出る
のを回避したく、ここから 3 記事は原画群の紹介が終わったこの順序
で公開します。（1 日置きの記事公開ペースに戻します。）
pyramidflow 環境構築が遂に達成した、という中でその記事内容に
手順ミスがあることに気付いたのでした。
しかし実際は環境が無事動き出していた後での発覚だったので、
折角動き出した環境を上塗り潰しするリスクに躊躇しましたが、
やはり修正をしてみました。
先のミスは huggingface からに pyramidflow-miniflux に必要なモジュール
をダウンロードする際に、サイトにある「models」「pyramidflow」
「pyramidflow-sd3」が含まれるものを選ぶ、という意味だと推測しますが、
3番目のキーワードが「pyramidflow-miniflux」でなく元の「pyramidflow-
SD3」のまま修正漏れ（次の行のみ修正）していたので、 pyramidflow-
miniflux に必要なモジュールがダウンロードされていない懸念が生じた
のでした。
これを修正のうえ、既にダウンロードしたものはそのまま上書きされる
ことを期待し、必要だったのに欠けているモジュールがこれで補填
されることを期待しながら、推移を見守りました。
処理は終わりました。環境設定などはまたやり直しかもしれません。
ComfyUI - pyramid-miniflux は無事起動して、直前まで作業していた描画
パラメタ評価状態をリコールしてくれました。
定義をそれぞれ格納するサブフォルダも特に初期化はされていません
でした。よかった….。
この対策でもしかして 768p 動画生成も通るようになったのでは？と
期待するも….。
やはりメモリ不足ギリギリのキラキラ画像にしかなりませんでした。
clip エンコーダをサイズ最小の Clip_l.safetensors を両方の定義に入れて
みたら仕様メモリ容量が最小になるのでは、と浅知恵を考えまして…。
それで実行しましたら、逆にメモリ不足エラーで終わりました。不思議…。
pyramid_flow_miniflux_768_bf16.safetensors が HDD実装上で3,851,743 KB、
pyramid_flow_miniflux_bf16_v2.safetensors が同じく3,851,735KB ….
ほんの少しの差なのですが、前者はこの環境ではギリギリ使えないという
ことのようです。メモリ展開後の容積が大きく異なるのでしょうか。
24 fps 動画は既に得られているので、768p 相当の動画画面サイズを
どうしても必要な場合（あまり note や CivitAI では必要を感じません）
は、CogStudio 同様に Dain-APP を使って 768p 相当にリサイズは可能
でしょう。
それで 384p 動画生成を繰り返して最適なパラメタを CogStudio の
時と同じく探っていますが、これがなかなか癖があるものでして、
よくぞまあこれを動かすために RTX4080 / 4090 機のために借金しなかった
ものだな、と逆に安堵しています。（導入していたら大泣きだったかも）
生成する動画の質の問題ではなく、描く対象によってパラメタの最適値
の振り幅が CogStudio の比ではないです。
しかもどのパラメタが生成動画の何に効くのかその全貌が分からない
（さわれるパラメタが多すぎる）状態です。
このあたりをオートマチックにこなす Runway Gen-3 はやはり凄く、何度か
描画のやり直しを強いられるにしても、プロンプト / ネガティブ・プロン
プトと動画変更量の設定だけで追い込める KlingAI には逆に価値があるとも
思えて来ました。
今はただこの #50 PyramidFlowWrapper モジュールの guidance_scale と
video_guidance_scale の効きだけを探っていて、もう少し生成秒数を長く
しても破綻が無さそうだ、と思えたら temp を 16 から 19 （5 秒生成から
1 秒増し）に調整したりするだけで、 guidance_scale と
video_guidance_scale の効きの差もあまり区別が出来ていません。
初期値の guidance_scale = 5 と video_guidance_scale = 5 では…..。
うわー気持ち悪い。こんなの CogStudio を含め、過去のクラウド系の
動画生成でも体験したことがない（いや LUMA AI は似た感じがあったか）
醜い変形です。先日の最初の成功例は奇跡だったのか。
まずパラメタの上下方向（値を大きくすると効きが大きくなるのか逆か）
さえ分かっていませんので試してみました。
guidance_scale = 10 と video_guidance_scale = 10 では…..。
うわわー。悪い夢に出て来そう…（怖）。
何度か調整して guidance_scale = 2 と video_guidance_scale = 1 で…。
ようやく落ち着いたものの、原画にあるノーブルな印象とは違ってどこか
憮然とした表情変化にはがっかりします。
一度、最適値が決まれば、その描画力は Runway Gen-3 並みかと驚くも…。
（Adobe Express での GIF 化でカタカタ感と若干の劣化はあります。）
当然、この設定が他の原画では適合する筈も無く….。
ほぼ全く動きません。
あれこれパラメタを変えて、プロンプトに原画生成の時の内容に加えて
「The wheel spins, light dances along the curves, and the river in the
foreground flows silently.」と補足の上、
guidance_scale = 10.5 と video_guidance_scale = 10.5 で….。
試行 32 回目にしてようやく車輪状のものが回転して、手前の河川にも
流れが出ました。回転の仕方が先日の Tensol.Art 「pyramidflow-miniflux」
（384p）での動画生成に似て気に入りませんが。
途中こんな酷いのもありました。（パラメタ記録なし）
ただ車輪状の構造は景気よく回ってますね….(^^)。
少し以前なら最初の 2 秒ほどで切って半速化を 2 回くらい重ねて仕立て
ようとか考えたでしょうが、ああまで苦労して構築した pyramidflow 環境
ですから、出来ればその中で閉じて動画完成度を高めたいものです。
KlingAI でも期待に沿う動画化までには何投か繰り返しでの追い込みが
ないと勝手な演出をされましたが、暴れ馬度ではその比ではありません。
動画化のために横構図にしておけばよかった、と後悔することも
これまで多かったのでしたが、上下カットで原画を纏められるなら
動画化に使えるのは朗報です。原画は時の運で同じ表情を生成させる
のが難しいですから。（seed 番号指定して縦横入れ替え設定で対応
できるのかは、今のところ試したことはありません。次の記事で
関連事項として付帯確認して見ます。）
これを Windows 標準のペイントなどで上下カットして….。
guidance_scale = 12 と video_guidance_scale = 2 による動画化です。
原画から疑似拡大されている筈ですが、画質劣化は微塵も感じません。
この作例を生成する頃には、guidance_scale が全体の動き量を制御して
video_guidance_scale が対象となるオブジェクトの細部の余計な動き
（この例では人物の表情など）を抑える効果があるようだ、と分かって
来ました。
（前者が CogStudio の「Guidance Scale」、後者が同じく「Strength」
に相応している感じです。）
ちなみに原画を上下カットしないと、眼から上あたりが入力時点で
処理対象外になったようで、補完に無理が出て悲惨な動画が生成
されました。（設定は同じです）
この点は後日理解が進みました。
出力の縦横幅は UI 上で調整が可能です。入力有効範囲の規定も
それに連動しているのでしょう。
逆に何だか底なしに面白く興味深いです(^^)。
未知の世界を自力で徐々に制御して行く充足感というか….。
「新作ゲームをオレは〇分でクリアしたという自慢」の人生は所詮
そのゲームを構築した全ての「If …Then」の分岐をクリアしただけ
（作者が作ったダンジョンを抜けただけ）に過ぎませんが、入力
した原画によって環境を構築した技術者が想定する最適値も変わり、
正解が最終的に仕上がったものに対して個々の美学主観で価値が
判断されるという世界は、あまりに次元が異なるものだと感じます。
やや脱線しつつも続けますと、それはリュートやチェンバロでは生まれ
得なかった楽曲がピアノフォルテの発明で（その当時からは遥か未来に
完成する）フルオーケストラの倍音音響を代用し得る（構造上打鍵して
いない弦も筐体内で共鳴して高次倍音として鳴り得る。好例は
The Beatles 「Sgt.Pepper's Lonely Hearts Club Band」の最後の
E Maj 【それは西洋史における天上の至福を象徴する。ベートーベン
の交響曲第 9 番終章や、マーラーの交響曲第 1 番、第 2 番や第 8 番
の終章がその近接の調性で締めくくられたごとく】の打鍵（打鍵の
瞬間はカットしてありピアノ音とは聞こえないギミックまである）が、
打鍵していない他の弦もダンパーペダルを踏んで全弦を開放している
ので共鳴している）可能性を近現代音楽史上の大作曲家に与えたのに
等しいムーブメントなのか、と考える自身が居ます。
ネット記事の世界では既に AI 描画のこれまでを振り返るばかりで、
今ある可能性を実際に使い倒さない、奇妙な「終わった」感が最近
目立ちます。仮にプラットフォームの進化が今止まったとしても
その中での表現はどこまでも拡張し得るのです。
そのまま脱線を続けますが….。
この世界に熱狂した超々・非進学校での大学受験時代だった 10 代後半
（同世代は「永ちゃんサイコー！永ちゃんサイコー！」でしたか）を、
その後半世紀以上経過した現時点でも全く連続した同じ感覚で居ます。
この高次世界を何故西洋音楽と東洋文化をつなぐ幸運な位置に居れた
日本の近現代音楽の作曲家ではなく、パリ万国博で一瞬東洋の文化に
触れただけのフランス人がこの世界に産み落としたのだという複雑な
想いは、心酔者であるが故に当時も今も全く変わりません。
えーっと….。話を戻します。
ちなみに 改めて HDD 環境に構築した Pinokio - CogStudio の 8 fps 動画
生成（6 秒固定）に 40 分弱かかるのに対して、同じ HDD 環境に
構築したComfyUI - pyramidflow-miniflux の 24 fps （3 秒延長設定で
6 秒生成）では初期起動で全部のノード定義を舐めるので 9 分30 秒ほど、
入力原画を入れ替えるだけとか、プロンプトを部分変更しただけなど
環境の一部変更時には、その変更部だけを取り込む動きを見せる
（ノードの枠の光る動きを見る限り）ようで 6 分 30 秒ほどで済みます。
これも物凄いことです。
あと、同一プロンプト、同一設定で再実行は受け付けられません。
設定を動かすか、プロンプト、ネガティブ・プロンプトの文字列を
前後させるなど、何かの変更要素がなければ「それはもうやった」と
ばかり動こうとしません（驚）。
1 つの条件からその都度バリエーションを出力する、という概念が
pyramidflow には無さそうです。この点は CogStudio が勝っている
と言えます。（ 8fps 出力だろうが、Dain-APP があれば 32 fps で
大きな動画サイズにも変換可能なので、表現力の差だけを言及して
います。いずれ表現力対決はします。）
ご覧いただきありがとうございます。
（2024/12/28 執筆・冒頭段落のみ 2025/02/08 加筆）