カテゴリー別アーカイブ: Academic Research

プリレンダリングから両眼立体視

この記事はOculus Rift Advent Calendar 2015の12月18日の記事です。

17日目はkoukiwfさんのVRにスマホ持ち込んだ話でした。

今回のネタは国際時空間設計学会第7回世界大会(ISTD-07)で発表研究を簡単に説明したものを記事にしました。

この記事のまとめ

  • リアルタイムに複数視点から両眼立体視を作る

  • 首を傾けても視差のズレが気になりにくい仕組み

  • 視点の数を増やすほどなめらかになるが・・・

まえがき

Googleでパノラマ両眼立体視のサービスが始まり、早数ヶ月がたちましたが、未だに乗り遅れ組みです。普通のパノラマ動画はすぐに投稿できたのですが・・・

さて、最近立体視ができるパノラマ写真や動画の仕組みについて、色々考えるところがあり、ガチの研究ネタに応用したいと考えていました。今回は簡単?な解説に留めておりますが、実際の理論については論文として公開されるはずですので、しばらくお待ちください・・・

通常のパノラマ画像の仕組みについて

先に通常のパノラマ撮影の仕組みについて説明します。これが分かれば後でパノラマ立体視の仕組みが理解しやすくなります。

昨今Ricoh THETAやSP360のおかげで、パノラマ画像の展開図である正距円筒図法(Equirectangular Projection)がメジャーになりましたが、以前は通常のカメラの画像をKolorのAutopanoなどのソフトを使ってパノラマ画像を作成していました。

撮影する際も、各カメラの焦点中心(No Parallax Point-NPP、以下NPP)の位置がなるべく近くないと、大きな死角ができてしまい、パノラマのスティッチに影響が出ます。同時撮影をする場合はどうしてもNPPを回転中心に揃えられないので、なるべく小さなカメラを利用して、パノラマ撮影のセットアップを行うことが必要でした。

被写体がカメラに近い位置にある時に、スティッチングがうまくいかないのはこの死角の部分に被写体が潜り込み、スティッチに必要な範囲の映像が取れていないことが原因だからです。

下の図は各カメラにパノラマ構造を持たせた場合の視界の範囲を表し、水色の部分はそれぞれのカメラでカバーできる視界の範囲、オレンジ色の部分は構造上撮影できない死角の視野範囲を表しています。カメラ本体が小さいほど、NPPのアライメント円が小さくなり死角が減るので、小型で高範囲の視野を持つGoProのカメラが理想のパノラマカメラになったわけです。

もちろんTHETAやSP360は構造上さらに小さなNPPのアライメント円を持ちますが、解像度を考えると業務用向けではまだGoProに軍配が上がります。

さて上の説明ではNPPが近い、遠いという表現をしましたが、これには専門的にはジンバル構造、非ジンバル構造という言い方があります。

よくカメラ用語でジンバルというと、レンズの中心位置に回転軸をあわすことを指しますが、完全なジンバル構造は3軸の回転軸の中心にNPPが置かれます。同じ種類でゆがみのないレンズのカメラなら、最低限のつなぎ目で完全に補完できる状態です。

なので、本来パノラマ画像の作成にはジンバル構造に近いことが好まれ、非ジンバル構造になるほど疎まれていたのですが、両眼立体視をする際に、この非ジンバル構造が活きてきます。これについては次で説明します。

普及しているパノラマ両眼立体視の仕組みについて

通常の360度パノラマ動画の場合、一つの視点位置からぐるっと球面方向に完全な視界を持つことになりますが、立体視にすることが困難になります。

なので、パノラマ両眼立体視はある「妥協」に似た何かをすることで、立体視を実現しています。

この方法の正式な名前が分からないのですが、普段は『ステレオパノラマ』と呼ばれることが多いようです。(自分は『スイングステレオパノラマ』と呼んでますが、検索すると違うイメージが出てきます)

ちゃんとした名前をつけるとしたら、『非ジンバル構造下での撮影による視差付きパノラマ』という名前あたりになるのではと思っています。

ステレオパノラマはNPPのズレを利用し、カメラに角度を付けて円周上に配置しています。 頭部の回転運動に合わせて右目側の向き、左目側の向きの視界に分けて繋ぎあわせたパノラマを作成します。そのパノラマをそれぞれの視界として表示することで視差を再現し、立体視を実現しています。

この方法ではアライメント円の径の大きさが視差に影響してくるため、ヒトの頭部以上になる構造だとうまく調整しないと違和感が出るようになります。

グーグル検索でstereo panorama(panoramic) camera実際の撮影手法とか製品とかが出てきますので、これ以降の説明は省きます。

構造上、スティッチが繋がりにくいところが出てきますが、パノラマ撮影にカメラの台数を増やしていくことと、パノラマ編集に特化したAutopanoなどを使うことで両眼の視界をカバーしたパノラマを作成することができます。

Unity上ではXVI様のStereo 360 Capture for VRを利用することでステレオパノラマの動画を簡単に出力することができます。

瞳孔間距離(IPD)の変化による視差のズレについて

ここから今回のネタの問題提起になります。

上記のステレオパノラマシステムでは、アライメント円上にNPPがあるため、頭部運動の旋回と伸展に対応しています。これは両眼の瞳孔間距離(InterPupillary Distance-IPD、以下IPD)が水平方向で変化が無いので、両眼での視差が崩れないからです。

しかし、側屈する場合には、IPDは3次元上では一定ですが、左右の視点位置が水平方向と垂直方向に変化していくのに対し、ステレオパノラマではNPPが常にアライメント円上にあるため、眼球位置との食い違いが生じ、視界のズレが大きくなってきます。

このため、首を横に傾げた場合、左右の視差が合わなくなり、ピントは合っても像が一致しない(2重に見える)状態になります。

まとめますと、ステレオパノラマによる立体視は頭部運動の旋回と伸展にはほぼ完璧に対応していますが、側屈だけはどうしようもなく、唯一で最大の弱点になると言えます。

今回はIPDの水平方向と垂直方向の変化に対応した両眼立体視をプリレンダリングした複数視点を持った画像群や動画から作るシステム(非パノラマの画像処理)の話になります。

IPDの変化に対応するためには

IPDを変化させるためには、視界の生成の仕組みを考え直す必要があります。ステレオパノラマでは2つの視点の円周上での回転運動を利用して視界を作っていましたが、IPDの変化に対応するためには、円周または球面上に仮想の視点を作る必要があります。

下の図では、A、B、C、Dのそれぞれ広い視野を持つカメラがありますが、一つの特定方向の視点方向はオーバーラップしており、この方向の視点はA、B、C、Dのそれぞれの視点から選ぶことができます。
両眼であれば、A-B、A-C、A-D、B-C、B-D、C-Dの組み合わせで視界が選べます。この時、カメラ間の直線距離をIPDとして、A-Dが最大、A-B、B-C、C-D、が最小のIPDとして選ぶことができます。

球面上に視野角の広いカメラを配置し、視点に近い位置のカメラ映像を選び、パノラマスティッチングと同じように映像を繋ぎ合わせることで、視点位置とIPDの変化に対応した立体視を作り出すことができるという理屈です。

実写の撮影機材はNokia OZOのようなカメラセットアップなら可能なのではないかと思います。ただし、相当広い視野を持つカメラが必要になります。最低でも140度、満足に見れるようにするには160度ぐらいの視野角が欲しいです。

Unity上でシミュレーション

Unityでシミュレーションしたイメージが下になります。今回のシミュレーションでは合計16視点を使っています。
通常のカメラをレンダリングしたもので150度前後の視野角を持つため、実写では魚眼イメージを利用することになります。

映像のスティッチングは両眼の視点位置に合わせて、リアルタイムに行なわれます。

上の画像から左右の視界を生成したものが下の画像です。

つなぎ合わせが分かるように色分けしたものが下の画像です。

さらに、カメラの視界との対応関係が分かるように枠で囲ったものが下の図です。黄色枠で囲われたものが左目で使われたカメラ映像、茶色枠で囲われたものが右目で使われたカメラ映像になります。

各カメラのNPPは球面上に置かれており、プログラムで自動的に左右の眼球位置に対応するカメラ視点をピックアップします。その画像を組み合わせて視界を生成します。

上の例では左右の視界で違う画像が採用されています。左右で視界が違うということは視差が付いており、立体視として提示できる映像ができていることになります。

現状の課題とまとめ

試み自体はうまくいったのですが、実際に運用しようとなると、いくつか解決したい問題があります。

  • 8Kぐらいの解像度がほしい

    16視点で一つの視点で1024×1024では解像度が足りないので、2048×2048で組もうとすると、必要な解像度が合計8192×8192という莫大な解像度が必要になる点がネックになっています。

  • 視点数を増やしたい

    上記の問題があるため、視点数を大幅に増やすことはできそうにないですが、視野角を狭くして角度ごとに割り当てられる解像度を上げればなんとかなるかもしれません。理想としては32視点ほど欲しいところです。

  • スマホなどのモバイル端末で動かしたい

    現状はシェーダーのコードが重く、PCであれば満足に動くのですが、最適化すれば携帯端末レベルでもリアルタイムにスティッチして処理ができるのではないかと考えています。

いまのところはこの技術はいろいろな面で有利なのですが、やはりかなりのスペックが必要になるため、デバイスの進化待ちで解決できるのではないか、という見込みです。

今は別の解決策が見つかっており、その方法を使えば4K程度の解像度で、GearVRでも動作可能なところまで到達しています。

それについてはまた別の機会で・・・

12月19日のOculus Rift Advent Calendar 2015shikemokumkさんの『VR時代のノベルゲーム開発』です。