2026年5月5日火曜日

Stepって…

仕組みとしては何となくザックリとした感じとしてとらえていましたが、実際にはどういう感じなんでしょうね? 

と言うわけで、Flux1-devは推奨値50のところそれ以下だったらどうなってるのだろう?という疑問が湧いてきたので実際にやってみます。

Step1で終わらせてみると


さすがになんだかわからん状態です。(笑)

(追記)step5ができました。

写真の画像としてみるとまだ厳しい感じです。
 

経験上20でもまともそうな画像が得られたので半分の10では?


こーなりました…

何かとりあえずまともそうじゃないですかね…てか、後ろ向いてるんだ(汗

今のところ時間があればやってみたいなーレベルで、safetensorsからggufへの変換についてもう少し突っ込んで知りたいという点と、stable-diffusion.cppで指定したStep数以外の中間地点でも画像出力させたら面白いんじゃないかなとか。

生成AIの原理として、チャットを前提に考え何らかの処理で画像を起こして、あとは適当な部分に注目して細部化して整えていくのかと思ってたのですが、根本的に違ってるってことなんでしょうね。非常に興味深い…。いまstep5も出力してるからそのあと15も出してみましょうかね…。


 (追記)できました…15でこれってことは正面を向くまで劇的変化がどこかでおこるのでしょうか…気になりますねw

ただ、20と比べると輪郭とか髪とかおんなじだったりするんですよ…まるで騙し絵です。 

Flux1 ClipLの量子化の影響

Flux1-devでは細部まで物体の詳細を持っているためなのか、影響の比率が少ないのかわかりませんが、あまりClipLの影響を受けていない感じ、対してschnellではClipLの影響を思っていた以上に受ける結果となりました。

結果から言えば、Flux1-schnellではClipLの量子化モデルは使用すべきではないと言えるでしょう。Flux1-devでは出力の影響の差が少ないのと、矛盾と言うよりフィルタ効果がの意味合いが強そうなので、好みで使い分けられるかもしれません。

2026年5月4日月曜日

ちょっと気になったのでサンプル程度に。

Flux1用のプロンプトではないのですが、gemma4に作ってもらったプロンプトをベースにしたものを流用してどんな差が出るのか比べてみました。(多分一般的ではない比較w)

そもそも(あくまでも量子化されたモデルで)devとschnellの違い。テキストエンコーダの量子化の違い。あと、Stepの違い。

この辺がどの程度変わるのか、気になったわけです。SD3.5では違いはあるものの、基本的な部分は変わらないかなと。

まず、devとschnellの違いとしては、似てるけど、別物という結論に至りました。SD3.5とFlux1との差ほど違いは無いですが、同じプロンプト、同じseed値、同じテキストエンコーダを使っても出力されているものは内容は同じものの、がらりと変わっています。

step数による違いは思っていた以上に出るような気がします。(SD3.5でStep50とかで動かしたことがないので比較はできませんがw)。とは言え、プロンプトに指定した内容は固定化されているので、指定されていない部分の差が出てくる感じでしょうか。

テキストエンコーダの量子化の差については乱数の誤差が出てくるためにやはり結果が異なってきますが、全体的なイメージはStepの影響よりは出にくいようで、この辺はSD3.5も同様だった感じです。実際のオブジェクトも誤差の結果で変わってきているようですがw

以下モデル、Step、ClipLの量子化状態のマトリクスが以下のようになります…まぁ未完成ですが、気が向いたら埋めていくかも?wあと、ClipLはsafetensorsのままでもいけると思うので、それとの比較や、あとは、現状512x512のみ出力サイズですが、サイズを変えたものも並べていきたいんだよなぁ… 

-Stepsclip l
Q4_0Q8_0safetensors
schnell4
20
dev20
50

ちなみにClipLとT5xxlのエンコーダはFlux1に同梱されているものではない(SD3.5ベース)ですが、すべて同じプロンプト「Full body shot of a beautiful woman standing, dynamic pose, highly detailed, realistic photography, natural lighting, golden hour, soft shadows, cinematic quality.」で作成しています。Seed値はstable-diffusion.cppのデフォルト値(42)です。

恐ろしい話として、実行環境はN150 CPUのみでStep50で出力時間は3時間。1Stepあたり3.6分。これはdevでもschnellでもほぼ変わらずでした。なのでStep4の画像でも15分程度かかってたりします(笑)てか、SYCLも試したい…w

Q4_0
Q8_0
safetensors

サイズ違いでschnellでClipLはQ4_0、Step4、サイズを768x768にしたパターンが出来上がりました。なんかポージングから違ってるwこりゃぁ難しいですねwプロンプトで抑止すれば落ち着いてくれるのだろうか?ネガティブプロンプトもないのであれですが、指の本数が明らかに多いwと、放置してるとQ8_0も出来上がりました。服の細かいところもしっかりしているイメージです。サイズが大きくなるとClipLの量子化も結構影響が出てきますね。背中の乗っかりが脂肪なのか筋肉なのか判断が難しいですが、ちょっと不自然な感じがしますね。
そうこうしているうちに768x768サイズのClipLの最終版、safetensors版も出来上がりました。Q8_0でボトムに布が追加されてますが、safetensorsでは無くなっていますね。

safetensorsを正とすると量子化されたことにより劣化によるノイズが発生しているととらえられるかもしれませんね。そもそもClipLの量子化モデルファイルを使う意味合いは、ファイルサイズ的にもあまりないことなのですが、予想以上の影響が出ている気がします。

番外編として追加でもう一枚。こちらはClipLをzer0intさんが調整されたもので出力してみました。比較するとQ8やQ4とも混ざっている感じ。予想ですが、元となるClipLが最初からか途中からかわかりませんが、一旦F16とかBF16、もしくは部分的に量子化されてしまっているのかもしれません。ベルトのあたりはQ8_0みたいになっていますが、ボトムの布地は無い様子。トップが違うのはまぁ小物の数も違うのでその辺の乱数ズレで変わってる感じがします。ご参考までに。

 

2026/05/05 16:06 ようやく貼り終えた…orz

2026年5月3日日曜日

Flux1で…

変換が終わって絵ができるかどうか?しか判断結果を気にしていなかったおかげでとんでもないミスをしていたことが後から分かりました…

LocalAIだと諸々の設定ができなければ実行状態にすらならないので気にしていなかったのですが、直接cliで叩くと結構動いちゃうもんなんですね…

分割されたsafetensorsファイルの結合

ちょっとした予想はしてました。全体がメインメモリーを超える大きさのsafetensorsファイルの結合って結構厄介カモということを…

現状を踏まえると、stable-diffusion.cppが分割されたsafetensorsファイルを直接読み込めればいいのですが、どうもダメそうなので、結合作業を事前に行う必要があります。