最近はあまり画像生成について調べてなかったのですが、NovelAIから11月にNovelAI Diffusion Anime V3が出て、触ってみたら案外面白いかも？という感じだったので、そこらへんの感想とか考察とか書いておきます。
NAI Diffusion Anime V3
一昨年NovelAIが画像生成機能をリリースしたときには記事を書いたりしていましたが、そのときぶりに触りました。
最初は前に触ったときのAnlasが余ってたのでそれで試していたのですが、面白くて結局追加でAnlasに課金して遊んでました。
特定のキャラクターの再現とかに関しては明らかに昔よりできるようになってるな、という雰囲気。SDXLのベースモデルは3.5Bパラメータのモデルなので、SD 1.5とかよりも学習元データを忠実に表現できるというのはまあ当然か。（SD1.5はU-NetとText Encoder合わせて1Bパラメータくらい）
プロンプトがちゃがちゃしてて思ったのは、自分の欲しい画風に固定するのがちょっと難しい？ これは自分がプロンプト書くの下手なだけな説がある。
いわゆる今風？な綺麗なイラストを生成させる方法がよく分からなかった。なんかそれっぽいのをやっている人はいるけど、プロンプトが公開されてないのでよく分からんみたいな状態。みんな知見を共有してくれ。
表現できる幅は多分旧モデルよりめちゃくちゃ広がってて、その分制御が難しく感じる印象でした。
NovelAIの画像生成機能はGPUを持ってないとか、GPUはあるけどSDXLは動かないみたいな人が試すのにはいい感じがする。そんなに価格は高くない、と個人的には思う。
ただやっぱりプロンプトの順序をちょっと変えて生成してみるとか、そういう細々した実験をたくさんやるには有料だとやっぱり気になってしまうなあ、という感想でした。
自分でSDXLモデルを動かしてみる
年が明けてから一週間くらいしてAnimagine XL 3.0がリリースされた。これが結構すごい気がする。
以前ローカルでCounterfeitXLを動かしたことがあったと思うのだけど、久しぶりにwebuiを開いてSDXLのモデルをロードしてみようとしたらうまくいかず。
最初はAnimagineのリポジトリに掲載されているサンプルコードを使ってColabで動かしてみたのだが、どうもdiffusersだとVRAM消費が11GB？くらいになるっぽく、こりゃーローカルで動かすのは無理かと思っていた、のだが
どうやらComfyUIを使うとVRAM消費を抑えてSDXLモデルが動くらしいという噂を聞き、試してみた。
SDXL向けのワークフローを組んで動かしてみると、本当に動く。しかも、タスクマネージャーで見ている限りVRAM消費6GBくらいで済んでいる？ 謎の技術だ。
blenderとかノードを繋ぐGUIを触ったことある人ならComfyUIはすぐに慣れると思う。
RTX 3070だと、832x1216サイズの画像の生成は2it/sくらいの速度でできる。28stepsとすると、VAEを通してデコードするまで入れて15秒、16秒くらいか。
ローカルでちょっと遊ぶくらいの感じなら全然これで良い気がする。無料で色々実験できるのは嬉しい。
Animagineの感想としては、個人的にはこっちの方がNovelAI Diffusion Anime V3よりも使いやすい。というのも、あんまり品質制御とかみたいなそういう非本質的なところでプロンプトをコネコネしなくてもそれらしい画像を生成してくれる。
それでいて、NAID V3の方でできたことと似たようなことがAnimagineでもできる。もちろんAnimagine XL V3が完全に上位互換ということではないと思うが、今のところ自分はこれでいいかなあという印象。
ComfyUIの仕様についてのあれこれ
いちばん有名な画像生成の環境であろうwebui（自分が使っていたのはSD.Nextだけど）から乗り換えた人から見たComfyUIの感想とか。
上で話したようにVRAM消費が少ないというのはとてもメリットなのだが、仕様に細かい文句がある。
まず、Save Imageノードのファイル命名の仕様。prefixじゃなくて普通にファイル名指定できるようにして欲しい。自分は保存した画像のファイル名を日時とかにしたい派なので、あんまり思想が合わない。
そのためだけにファイルの保存にカスタムノード使うのもなあ、という絶妙なラインの不満。
あと、CLIP Text Encodeノードの話。SDXLはどうも標準ではプロンプトの長さは77トークンまでという仕様らしいのだが、ComfyUIではそれよりも長く入力しても問題なく動作するようになっている。これはwebuiでもそういう入力長上限の拡張がなされているので馴染みのある挙動だが、（おそらく実装の仕方の影響で）長いプロンプトを書いていると途中で急激にプロンプトの指示の効果の強さが変わる点が存在する。
webuiではSD1.5時代に75トークンごとに入力文字列を分割するという方法でトークン長の制限を回避していたが、おそらくComfyUIでもSDXLに対して同様の実装をしていると考えられる。1トークン目が一番影響力が強く、75トークン目？か77トークン目？が最も弱くなり、その1トークン次がまた一番強くなる、というようになってるのではないかな？という仮説です。
この仕様があるので、webuiのようにCLIP Text Encodeに渡している文字列が何トークン分の長さなのか生成前に確認できるようになって欲しい。なってほしいなあ。結構これ不便。
まあ別にノードベースにこだわりがあるわけでもないので、webuiとかでも普通にSDXLモデル動かせるならそっちでやる。
生成モデルの将来どうなる
インターネット上ではもう画像生成というと検索候補に「炎上」と出てきそうなブツになってしまいましたが、これからどうなっていくんでしょうか…。良識のある人たちはどんどん閉じたコミュニティに隠れていっていて、素行に問題のある人だけ目につくみたいな環境になっている気がします。わざわざイラストレーターを煽りにいくみたいなのは、本当によく分からないですね。どういう感情なんだろう。
規制とかをするにしても、学習を規制してしまうと……困りますね。ChatGPTとかDeepL翻訳は普通にみんな使っているのに、画像だけNGなのは二枚舌になってしまいます。なんか上手い落とし所が見つかったら良いなあ、と思っている今日このごろです。
