ImageDreamの調査

image条件づけによるmultiview diffusionであるImageDreamについてメモ
[2312.02201] ImageDream: Image-Prompt Multi-view Diffusion for 3D Generation

最近は高品質なmultiview diffusionがよく出てくるが、初期の頃に出たものの中で高品質なものとしてMVDreamという手法がある。MVDreamはtext条件づけによるmultiview diffusionを学習し、それ利用してsdsによって3dのreconstructを行うtext-3dの手法。
GitHub - bytedance/MVDream: Multi-view Diffusion for 3D Generation

multiview diffusion部分としては以下のようなもの

90°毎の4 viewの生成に特化
- 1 viewのimage sizeは256x256
fov: [15, 60], elevation: [0, 30]に対応
3d attentionを加えることでmultiviewの一貫性を担保
学習時はobjaverseから集めたrendering viewの他に、LAION subsetも使い画像クオリティを担保
- rendering viewだけだと生成画像のクオリティが下がるため

ImageDreamは上記のMVDreamに対しimage条件づけのための拡張を加えた手法で実装はこちら
GitHub - bytedance/ImageDream: The code releasing for https://image-dream.github.io/

ちなみに以下に貼ってある画像はImageDreamの論文から引用

multiview diffusion

diffusion部分の基本的な構成はMVDreamをそのまま使っており、ref imageに似せた生成を行うための仕組みを付加してfinetuneを行っている。付加した仕組みとして、論文では3つコンポーネントが説明されているが、最終的なモデルでは後の2つのみが使われている模様。

global controller

objectの全体的な特徴をref imageに一致させる目的で当初導入したが、最終的なモデルでは使っていない。 ip-adapterと同様の形で、ref imageをembedings化したものをmlpで変換しcross attetionへ渡してK, Vとして使う。

ref image -> clip embeddings -> mlp -> global feature(f_g)
- f_g -> mlp(K) -> K
- f_g -> mlp(V) -> V

We refer to decoupled cross-attention in IP-Adaptor for additional details.

と書かれており、K, Vの使い方やtext embeddingsとの合わせ方はIP-Adapterと同じ模様。

式はこちらから引用
[2308.06721] IP-Adapter: Text Compatible Image Prompt Adapter for Text-to-Image Diffusion Models

Qはtext用のものを共通で使い、K, Vはtext/imageでそれぞれ別の値を使ってattentionの出力を計算し和を取る。

local controller

global controllerだと細かい部分の見た目がref imageから引き継げなかったため、global pooling前のclip featureを使うことでdetailの情報を取得する。

clipの最終出力手前のfeatureを取り出して、global controllerと同様の形でcross attentionに使う。ただし、元のfeatureそのままだと過度にfeatureへの適合が起きてしまい生成画像の品質が低下したため、featureの次元数を257 -> 16へ落とすことでぼやかして使う。

pixel controller

MVDreamにおける3d attentionが各viewにおける見た目の一貫性を取るのに重要な役割を果たしており、ここにref imageも足すことで直接的にattentionして見た目をあわせる。

MVDreamでは4 viewにより3d attentionしていたところを以下のように変更

ref imageを5 view目として追加
camera poseのembeddingsはすべて0に設定してref imageであることの印に

これを入れた目的は細部の見た目の一致をさらに高めることだったようだが、最終的にはmultiviewの生成においてはpixel controllerが重要だったと書いてある。

ref imageと生成したいviewが一致している場合、IP-Adapterの方法で十分に見た目が一致した画像を生成することが可能だが、今回の場合は一つのviewを参考にして別の角度から見たviewも生成する必要がある。

clip featureのような圧縮された情報を使う場合、それを実現するにはより多くのデータと長い学習時間をかける必要がありそうで、ImageDreamで行うfinetuneくらいの学習においては有用とのこと。

pixel単位(LDMなので実際にはlatentだが)でref imageの情報にアクセスしながら生成するのでコストはかかるが確かに有用に思える。むしろこれがあればlocal controllerさえ要らないような気もするのだが、論文ではpixel controllerのみ評価結果は載っていなかった。localすらないと学習時間が増えてしまうというのはありそう。

global, local, pixel controllerの有無による生成画像の見た目の違い

3d reconstruction

finetuneしたref image付きのmultiview diffusionを利用してsdsによりnerfを最適化する

MVDremaと基本的には同じだがref imageが存在することによる違いが2つ挙げられている。

ref imageの背景色をreconstruction時の色に合わせる
camera poseの範囲を狭める

一般的なnerfの学習時にはrandomに背景色を変えながら最適化していくため、ref imageの背景色がそのままだと条件が合わずにartifactの原因になる。

また、ref imageは特定のcamera条件下でrenderingしたものに相当する。なのでそれを条件付けとして3d表現をreconstructする以上、そのcamera条件と大きく異なる場合はうまく学習できない。なのでMVDreamと違って以下のようなcamera poseに制限している。

fov: [45, 50]
elevation: [0, 5]

ref imageの条件にあった範囲にするというのではなく、一律この範囲に狭めているのは少し謎。multiview diffusionのfinetuneに使うデータセットはMVDreamの条件と合わせると書いてあるので同じelevationの範囲などを持ったデータでfinetuneしてあるはず。

LAION subset側に含まれるimageが正面向きのものが多く自然とそちらの条件にfitしていってしまうということなのか。

ちなみに実際に動かしてみても、elevation 30°などにすると確かに崩れた見た目のviewが多くなるのは確認済み。

limitations

論文で挙げられている点としては、camera poseが制限されること以外には顔などの細かい部分が崩れること。

これはpixel controllerによるものらしく、pixel controllerを使わない場合にはある程度ちゃんと描けている。

ただし、clip featureからの情報によるものなのでref imageとして与えたものと比べると変わっており、顔であるという情報（や上記の場合は有名人だからsdが知ってる）から意味的に描いたものと言える。

ちなみに論文には挙げられていないものの、ImageDreamのmultiview diffusionはやや青みがかった絵を生成しやすいように思われる。動かしたみた結果や論文(他の論文も含む)にある評価時の画像例など見ていると、青くなる要素がなさそうなのに青っぽくなっていたり、他の手法の生成例では普通の色なのにImageDreamだけ青っぽいのを見かける。