VAE - sd_toshiaki

#contents

*VAE [#vae]
**VAEって何？ [#t650efc1]
Variational Auto Encoder。
変分オートエンコーダの略

#shadowheader(3,VAEの効果)

一応VAE自体も広義の画像生成モデルの一種なのだが、一般ユーザーにそう認識されることは少ない。
Stable Diffusionのような画像生成AIは潜在拡散モデルと呼ばれ、潜在空間(latent space)と呼ばれる情報が圧縮された世界で生成処理をしている。
これは単純に画像のサイズを縮小するのとは全く別物((とは言ってもエンコード後の表現形式もビットマップ画像（ラスター画像）に近い。ただし各マスはRGB値ではなくそのマスの特徴を圧縮した潜在表現になっている。))。
VAEはこの潜在空間との橋渡しをする役割を果たしている。
具体的には生成の最終段階でVAEが潜在空間表現から一般的な画像の形式にデコードすることで画像が完成する。
生成の最後でトラブルが起きることが多いのはこのデコード処理に多くのVRAMが必要なため。
逆にimg2imgでは最初にVAEが画像を潜在空間表現にエンコードしている。

#br

SD1.5のアーキテクチャ設計は軽量高速化に重点が置かれており((拡散モデルの前後で軽量なVAEを使うというアイデアはStable Diffusionで初めて実用化されたもので、当時はまだ技術的に成熟していなかった。))、
結果としてVAEと生成したい画像との相性の問題が今より大きかった。

原則的にすべてのモデルにVAEが内包されているが、それが適切なVAEとは限らない。
具体的には、彩度が低く灰色っぽくなったり、紫色の斑点が出現したり、といった問題が発生することがある。
必要や好みに応じて別のVAEを指定しよう！

#fold(もっと見る){{
>96 無念 Name としあき 23/02/10(金)02:33:24 ID:iNtCkbRs No.1065201947 del +
>~>そもそもVAEが何だかよくわかってない
>t2iでの説明をすると
>画像の元になるノイズ画像 を　VAEを通して64x64のサイズに(正確には各辺1/8のサイズに縮小する)
>SD本体でpromptを見比べながらノイズを画像にしていく
>SD本体が作った64x64サイズのものをVAEが512x512のサイズに戻る
>　
>ざっくり説明だとこんな感じ
>AIにとって理解しやすい拡大縮小をしてる部分だから色味や細部の線のでかたに影響がある
>今あるのだとイラストに強くて奇麗だけど少し色あせてボケ気味なのと
>イラストに強くて色味が強すぎるのと
>何でもできるけど他がイラストに特化してる分実写が得意なのと選択肢が狭い
}}

#ref(初めての方はこちら/1676079055003.jpg,25%,VAEのFAQ)

#br

#shadowheader(3,VAEが使われている場所)
#ref(./260620_01_モデルの役割_2.png,80%)
引用：としあき自作

**主なVAE [#f017aeb7]
***SD v1.x専用 [#p4b61a5a]
VAEは、モデルに比べると極端に数が少ない。主要なVAEファイルは5～6種類程度。
|モデル名|備考|h
|[[vae-ft-ema-560000-ema-pruned.safetensors>https://huggingface.co/stabilityai/sd-vae-ft-ema-original/tree/main]]|二次系で安定|
|[[vae-ft-mse-840000-ema-pruned.safetensors>https://huggingface.co/stabilityai/sd-vae-ft-mse-original/tree/main]]|実写向き・二次でもいい|
|[[kl-f8-anime.ckpt>https://huggingface.co/hakurei/waifu-diffusion-v1-4/tree/main/vae]]||
|[[kl-f8-anime2.ckpt>https://huggingface.co/hakurei/waifu-diffusion-v1-4/tree/main/vae]]|彩度高い|
|[[autoencoder_fix_kl-f8-trinart_characters.ckpt>https://huggingface.co/naclbit/trinart_characters_19.2m_stable_diffusion_v1/tree/main]]|彩度めちゃ高い|
|[[としあき製VAEシリーズ>https://mega.nz/folder/lZ5UmKqC#g1Vuuz-FqAN3jRe0XTWLjg]]||
|[[ClearVAE>https://civitai.com/models/22354/clearvae]]|壺産。シャープ、かつ彩度が若干高め。|

***SDXL専用 [#ib93741f]
SDXLはモデル内蔵（U-Net+TextEncoder+''VAE''）の構成が基本。

SD1.5系はVAEが原因で生成が破綻するケースもあったが、SDXLの標準VAEは最初から完成度が高くそれが原因で生成に支障をきたすということはほぼなくなっている。
SD系モデルは学習時に用いられたVAEの潜在分布との整合性が重要であり、安易な差し替えによる副作用が発生しやすい。
この為、代替VAEの重要性は薄れた。
#br
VAEの重要性が十分に広まったため、モデル（checkpoint）にもともとVAEを焼き込んでくれている場合が多い。
VAEがbakeされていない場合はモデルの作者が推奨するVAEを使っておけば大丈夫。
どうしてもVAEを独自に指定したい場合は、特にこだわりがなければ[[SDXL VAE>https://civitai.com/models/296576/sdxl-vae]]を使うと良いだろう。
ちょっと雰囲気の違う塗りが欲しい場合は[[XL_VAE_C>https://civitai.com/models/152040?modelVersionId=202582]]というものがある。
XL_VAE_Cのバリエーションの一つであるEシリーズとFシリーズは彩度が高く独特の透明感があり特にアニメ塗りモデルによく合う。
&attachref(./sdxlVAEsample.png,nolink);

***SDXLより後のモデル [#w7d86f52]
-VAEは単独で配布されることが一般的になりました。
--SD3やFLUX.1といった超巨大[[DiT]]ファイル単体の登場が、一体化を困難にした原因
--その後、軽量化のための量子化バージョンの登場や、異なるモデルからの共用（例：AnimaはQwen3からの流用）が増えました。
-基本的に、各シリーズ（FLUX.1, Anima等のこと）につき１種類。
--データ型（bf16）違いや、各DiTに合わせた独自VAEを配布している場合があります。
-どのモデルがどのVAEを使用するかは、各モデルの説明ページに書いています。

**VAEを置く場所・適用方法 [#qe67748e]

#shadowheader(3,VAEの保存先)
-(1111の場合)
 C:\stable diffusion\webui\models\VAE
 人によって親フォルダ名は異なります。
-(NMKDの場合)
 \Data\models\vae

#shadowheader(3,VAEの適用方法)
Stable diffusionの設定を変更し、VAEを実際に適用させよう。
-(1111の場合)
&ref(./1111_settings_VAE.png,35%,1111でのVAE適用方法);
-(NMKDの場合)
--まず右上の歯車アイコン(Open Settings)を押す。
--そしてこの画像の通り。
&ref(./NMKD_1.9.1_settings_VAE.png,20%,NMKD 1.9.1でのVAE適用方法);

**(1111)VAEを手軽に切り替える方法 [#jc6d4384]
Quicksettings listを利用しよう。
#ref(./1674399937239.jpg,around,30%,QuicksettingsにVAEを追加する方法)


Settings → User interface → Quicksettings list
に「sd_vae」を書き足して画面上部の&color(white,#ce6400){'' Apply settings ''};を押す。
するとあら不思議、画面上部にSD VAEの欄が！
#clear

*画像生成AIとしてのVAEの特徴 [#v021456d]
''Stable Diffusion等ではオリジナルのVAEとはだいぶ違う使われ方をしている為、''
''SD以外の分野でのVAEの文献がSDでのVAEにそのまま当てはまるとは限らないので注意''。

高速で無難な出力をするが、ボケやすいという特徴を持つ。
SDのVAEがそんなにボケないのは、不正値への耐性と引き換えに画質を取っており、またディテール描写に優れる[[GAN]]の手法を一部取り入れて構築されているため((LDM論文Robin Rombach他「[[High-Resolution Image Synthesis with Latent Diffusion Models>https://arxiv.org/abs/2112.10752]]」arxiv, 2021の「3.1. Perceptual Image Compression」に「an autoencoder trained by combination of a perceptual loss and a patch-based %%%adversarial objective%%%（敵対的目的関数）. 」とある。これがGAN＝敵対的生成ネットワークにヒントを得た部分。))。
とはいえGANの弱点があまり出ない程度の利用に抑えられているため、長所の部分も本家のGANには及ばない。なのでUpscalerにはそちら等が使われる。

#br

「重い画像生成モデルの前後に軽量なVAEを挟んで計算コストを抑える」という手法は現在では当たり前になっているが、Stable Diffusionが初めて実用レベルで成功させた。
VAEを使わない拡散モデルはそれ以前にもあったが、計算コストが極めて重かった為OpenAIやGoogleなどのAI先進企業がクローズドソースでWebサービスとして公開する程度だった。
現在個人のPCでも動くような画像生成AIが多数普及しているのもこのVAEのおかげである。

**SD以前のもともとのVAE [#j0cd153b]
単独で乱数ベクトルから画像を生成できるAIとして発表された。
SD等では入力がノイズだとVAEでデコードしてもノイズになるが、本来のVAEはどんな潜在を入力してもできるだけ教師画像に近い雰囲気になるよう出力する。
が、先の通りボケやすい。

VAEのデコーダは、潜在表現zを確率的に画像xにデコードするよう訓練される。
訓練時に「確率的に」zを揺らしてからデコードさせるのはzを点ではなく中心μ±誤差eの広がりとして学習させて潜在空間全体を埋めるためだが
(でないとまともな画像を出せる入力値の幅が狭くなり独立生成モデルとして使えない)、
SD本体と異なり生成時は通常乱数を使わず期待値E[x|z]を出力させる。
学習目標は条件付き確率p(教師画像xi|zi)を最大化すること、および潜在表現zの差異が大きいときは大きく異なる画像を出力することだが、これはデコーダ単独では計算不可能。
ベイズの定理における尤度の近似として、画像xが潜在表現zにエンコードされる確率を表すq(z|x)をシミュレートするためにエンコーダが置かれている。

なのでもともとは、エンコーダは[[GAN]]の識別器Dのような副産物だった。

#br

Stable Diffusionでは画像生成に適した圧縮・展開器として利用されており、
KL正則化も「どんな潜在でも自然な画像にできる」ではなく「若干潜在が崩れていても画像にできる」程度の調整になっている。
潜在表現の許容値を広げるには潜在表現ziがズレていてもそれに近い教師画像xiを出力するように訓練する必要があるが、それを広げると近隣の教師画像が平均化されてボケボケになるため。

逆にKL正則化を強めたβ-VAEは、教科書的には潜在表現の解釈可能性が高いXAIのように書かれることもあるが、生成品質の評価値は拡散モデルの100倍くらい悪い。
CIFAR10データセットでの[[FID]]評価がDDPM（拡散モデル）3.17に対しβ-VAEは200とかになっている((Miroslav Fil他「[[Beta-VAE Reproducibility: Challenges and Extensions>https://arxiv.org/abs/2112.14278]]」arxiv, 2021))。

#br

LDM（SD）発表当時、独立生成モデルとしてのVAEは画質で[[GAN]]に後塵を拝しており、
潜在空間も独立生成に使うために正規分布に正則化されていたのでぱっと見ランダムノイズと大差ないと思われがちだったが、
ハイパーパラメータ調整でちょうどいい感じの次元圧縮ツールに生まれ変わらせたのがLDMのブレークスルー。

**画像生成AIとしてのVAEの長所 [#fff155ca]
-生成が高速。
-多様性は比較的確保しやすい。分からないから適当に描きこんだだろみたいなのはGAN程にはない。
-オートエンコーダの名の通り次元圧縮にも使える。
-教師なし学習なのでアノテーション（キャプション）の手間がない。
-学習も安定しやすい。

**画像生成AIとしてのVAEの短所 [#q1396fdc]
-単独で生成に使うとボケやすい。AIにとっての無難な選択＝平均化なのでボケやすくなる。
-プロンプトによる条件付けが難しい。

*コメント [#vb22299a]
#pcomment(,5,reply)
>(Tips)
-既存コメントの先頭にあるラジオボタンをONにすると、そのコメントの下にぶら下げ返信する形になります(ツリー構造)。
-コメントの文中で&#8629;ボタン(下の画像参照)を押すと「&#38;&#98;&#114;&#59;」の文字列が挿入されます。これは送信後に改行として機能するので、文章の整形に役立ちます。
&ref(wikiwiki編集のコツ/br.png,around,50%);
----