見出し画像

dev 型 FLUX.1で追加の LoRA F1 ファイルの効果を試すうちに不測の事態に。【重要な落とし穴情報あり】

先の LoRA F1 ファイル正式評価(最低画質ではない
flux1-dev-bnb-nf4-v2.safetensors が使えるようになったので)
の首記記事を一旦書き終えて、その後、巨大な Checkpoint F1 群に
関する何記事かを書きつつ、追加でいくつか見つけた LoRA F1
ファイルを書き終えていたその首記記事に追加しようとしたところ
で、不測の事態に陥りました。

再び画が拡散してまともにならなくなりました。
追加で適用しようとした LoRA F1 ファイルが何かを壊して
しまったかのように、先日まで動いていた LoRA F1 ファイルも
Checkpoint ファイルも拡散が全く止まりません。

途中、update.bat を実行して不具合解消を期待しましたが、
効果はありませんでした。

各パラメタを例の参考記事に立ち戻って設定項目を確認しましたが、
原因特定には至りませんでした。設定は記事での説明の通りでした。

当方の記事化のために先日来、処理成功していた期間も、設定画面の
ハードコピーを逐次残していましたので、それで全部、成功していた
時期の設定にしてみましたら、ようやく問題解消しました。

「Sampling Method」が「Eular」でなければならなかったのでした。
理由はさておき、ここは重要な確認事項でした。

成功していた時期には「Schedule type」も「Simple」になって
いましたが、ここは「Automatic」でも「Simple」が適用になるのかも
しれません。未確認(今は描画評価優先のため確認のゆとりが皆無)
ですので、ここは「Simple」設定が無難です。

恐らく比較対象のために SD1.5 での描画を何件か作業に挟んだ時に、
その設定が別の値(恐らくDPM ++2M)に変わったままだったのでしょう。

そして以前の画の拡散が初めて起こった時には、プロンプトの平文化で
回避したように考えていたのですが(何故急にそんな仕様変更が必要
だったか納得出来ていませんでしたがやはり)、事実はそうではなかった
のでした。平文化をした後、最後に上掲参考記事に見えている全ての
項目を、説明されていない項目も含めて設定し直した時に
「Sampling Method」が「Eular」、「Schedule type」も「Simple」
が説明にはなかったものの、画には含まれていたので設定したのでした。

それは記事化のために逐次取得していた画面のハードコピーを
改めて眺めて行きましたら、まさにその状態となっていました。

処理が通ったものの、画が拡散している(「Sampling Method 」が「DPM++ 2M」)
参考記事のプロンプトで描画させてみた時に、説明項目以外のパラメタも見えるところは
全部倣った結果、「Sampling Method 」に「eular」が設定された
プロンプトの平文化が効果あったかのように見えたが、実は
「Sampling Method 」に「eular」を設定が決め手だった

(追記:当日…実際は記事公開前の 2024/09/14 に加筆)

未検証ですが、別記事で先人様からご指摘を頂いた「VAE / Text Encoder
には同時に 3 つのファイルを設定する」お勧めにこの時点で対応して
いなかった(描画実行と記事執筆が先でした)ことが、本件に影響して
いる可能性があります。その設定により「Sampling Method 」が
他の設定でも、本件が起こらないようになるかもしれません。

….そんな気がして来ました。「Sampling Method 」の設定で描画が
まともにならない、など仕様として不完全で考えにくいからです。
が、まあ当方は「Sampling Method 」設定を「eular」で描けるなら
それでも問題はないかな、と考えます。非力なPC で出来る限り使用
メモリを減らすことも一つの考え方かなとも思いますので。


とりあえず現象は解消したので、改めて追加評価しようとしていた
LoRA F1 ファイルをこの記事で扱ってみます。

今回最初に試した LoRA F1 ファイルでしたが、名称にもfp16 用と
限定してある印象で、それを t5xxl_fp8_e4m3fn.safetensors の
VAE / Text Encoder 当方環境で試そうとして何かを壊してしまった
のかと焦ったものでした。
拡散の不具合解消後は t5xxl_fp8_e4m3fn.safetensors 下でも使えています。
無理な適用で何かの内部モジュールを壊してしまったのでなくて
安心しました。

ただ作例ほどは良くないです。画質ではなく美人度が、です。
nano-suits の質感は悪くないです。

気になった作例の「効き」は「0.9」です。当方は「1.8」でした。
より flux1-dev-bnb-nf4-v2.safetensors 剥き出しの「怖い顔」に
近づきそうなものですが….。プロンプト表現の差ですかね。

seed 番号も含めて、その作例のプロンプトで描画させてみました。

best quality, masterpiece,
raw photo of asian female in white dress, close up face, brown hair, fashion accessories, looking at viewer, indoor, day time,
professional photo, high contrast exposure, soft bokeh, high key light, hard shadow, soft bokeh, simple background, white background,
<lora:hinaFluxAsianMixLora_v1:0.9>

seed : 4256190823

うーむ。違うなあ…。似て非なる仕上がりです。(それこそが
この題材を検証に使う最大の理由です。他の題材ではその差分
というか不充足に気づけなかったのではないかと考えます。)

もっと上位の CheckPoint ファイルを使われたのでしょうか。

その一方、上述の update.bat 実行後、処理本体のバッチ画面のメッセージ
推移が以前と違っていて、「Patching LoRA for KModel 」の進行バー表示
が無くなり「Patching LoRA weights out of memory, Retrying by offloading models」との代替処置が 100% 通るようになってました。


update 前の「Patching LoRA for KModel 」の進行バー処理では CPU VRAM
へのスワップがなかったので、ここでメモリ不足で異常終了することが
多く、LoRA を使う時には VAE / Text Encoder を  t5xxl_fp16.safetensors
(9.56 GB)から t5xxl_fp8_e4m3fn.safetensors(4.78 GB)に落として
いました。

しかしこの update でその処理の泣き所が解消されたようなので、
再び VAE / Text Encoder を  t5xxl_fp16.safetensors(9.56 GB)に
戻してみましたが、LoRA を併用しても処理が落ちません。

その状態でも描画してみました。

それでもやはり作例には届きませんでしたか….。
もっと巨大な CheckPoint ファイルも現在動くようになったので、そちら
でも LoRA 評価が update 後に可能になっているなら、試す価値はありそう
です。

もしかしたら今のPC 再起動からの、ややアクロバチックな描画開始方法
も不要となるのかもしれません。(現在、描画データを別号機に移管中で
未テストです。クラウド系動画生成サービスの利用はメインの描画PC で
実行するゆとりが FLUX.1 実行のために無くなったので逐次、X230 の
3号機に生成させた静止画データを移管することにしました。)

(追記:同日)巨大なものも含めて CheckPoint F1 ファイルの入替、
 LoRA F1 ファイルの差し替えと効きの修正、プロンプトの修正
 (メモ帳に退避しておいた内容のペーストと加筆)程度なら
 やはり PC の再起動からの描画開始をしなくても、処理は途中で
 落ちなくなりました。描画前や描画中、参考のために Chrome の
 別タブウインドウでネット参照をしていても大丈夫です。
 今回の update.bat での改善はもの凄いです。

こちらは一転、作例の雰囲気に近い、使えそうな表情を多く描く LoRA F1
ファイルです。

画の拡散が止まらなかった件で、当該 LoRA F1 ファイルの描画は
その拡散失敗した画しか残してなかったと勘違いしていましたが、
別フォルダ名でしっかりリベンジをしていました。
(おいおいジジイ、耄碌は大丈夫か。何せ FLUX.1 環境構築自体だけ
ではなく、CivitAI での予期しない投稿削除トラブルと英語で相手を
説き伏せる対応(無事完了)を含めて、とにかく未知の体験が次々
噴流のごとく自身に遭遇して来ている毎日ですので、全てを管理掌握
出来ていないのが正直なところです。……@_@;;;)

そのため、多めに蓄積してしまった画を改めて振り返り、当該 LoRA F1
ファイルに関しては後日に別途記事を設けて特集したいと考えます。
お気に入り(nipples 後処理に手間がかかるがその価値はある)の
flux-000003.safetensors に匹敵する描画の魅力があります。

(本来、次の記事でその別途特集を公開予定でしたが、緊急割り込み
で別の話題を複数記事に纏める必要が急遽出て来ました。)

これも作例の雰囲気に近い、使えそうな表情を多く描く LoRA F1
ファイルです。

あ、これはダメです(^^;)。用途が違ってました。
顔の造形より衣装に重きを置く LoRA F1 ファイルだったようでした。

これは nipples も navel もサイドカットデザインでの肌の露出もあって
手がかかる LoRA F1 ファイルです。
flux-000003.safetensors のように表情に愛嬌があれば、補正の遣り甲斐も
ありますが、ややアメコミチックなバタ臭さも使いにくいですかねえ…。

たった 18.4 MB しかない LoRA F1 ファイルです。数秒でダウンロード
出来ました。調べてみると当方お気に入りの  flux-000003.safetensors
も同じようなサイズでした。

IOPaint-LaMA を使っての nipples 隠しを行ってもなお残る過剰な肉感、
公開はしないものの、補正不能な面積の肌の露出(nipples どころか
乳房剥き出しなど)の画も多く、当方の用途には馴染まない印象です。

ただ良い表情は多くありますね。肩から上だけ使いますか(^^)。
当該 LoRA F1 ファイルの「効き」を下げれば肉感も緩和される一方で、
きっとこれらの魅力的な表情も活かされないと考えます。
(余裕なく現時点で無検証ですが。)

遥か未来に彼女たちが存在して、その未来の技術であるタイムマシンで
当方がその場に居合わせたかのような(まあきっとそんな未来の技術が
あっても、当方のような老いぼれに直接謁見のご縁はないとは思い
ますが^^)描写に感動を覚えるしかありません。

もう既に SD1.5 世界に戻れない感じもしています。
この 1 年の七転八倒があって、その我流で手探りした模索を通しての
知識の積み上げがあってこそ、今の FLUX.1 dev での描画の感動が
あるのだ、という自身と環境の進化速度を理解しつつも、膨大に蓄積
した過去の描画がほぼ無為に帰した喪失感もあって、心境は複雑です。


ご覧いただきありがとうございます。



(2024/09/08 執筆)


この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?