Oculus Quest の Passthrough+ (疑似視点合成) の仕組み

CTO室で研究開発を担当している松尾と申します。 今回はいつもと若干毛色を変えて Virtual Reality (VR) 関係のトピックを紹介します。

撮影された画像から復元された弊社の休憩スペース

Oculus Quest 2

昨年 Oculus Quest 2 が発売されたこともあり、VR関係のトピックが大変盛り上がってきています。

Oculus Quest 2 はスタンドアロン型のVRヘッドマウント・ディスプレイであり、 スマートフォンの SoC として定評がある Qualcomm 社の SoC Snapdragon XR2 が採用されています。 特徴としてはリアルタイムで動作する SLAM を搭載していて 数m x 数m のスペースを動き回ってプレイすることが可能です。 またディスプレイサイズは片目 2K と十分な解像度を備えています。 ハードウェア・機能的にも高機能にもかかわらず安価で提供されているため大変魅力的な製品になっています。 (同等性能の携帯 (SoC Snapdragon 865) と比べても半額程度に安価)

弊社でもこのデバイスに注目していてプル型開発プロジェクト(社員が自発的に研究活動するプロジェクト)でもデバイスを購入して色々な技術を開発したり試したりしています。(とうとう個人でも買ってしまいました。。)

デバイス上で開発する以外にも内部システムとして興味深い物が含まれています。

一つは Oculus Insight の機能です。これは外部センサの類を一切置く必要がない SLAM (自己位置推定とマップの更新を同時に実行する) システムです。 実際に試してみた感想としてはVRの利用に耐えうる90Hzでの推定が可能、同じ場所を再度認識する能力が高いなどの点で素晴らしいと思いました。 Oculus のホームページによると複数のIMU+カメラと運動予測で対応しているとありその動作原理は大変気になります。

他に興味深い機能として Passthrough+ [1] があります。これは設定した移動可能エリアの外に出るとカメラ映像が表示されて周囲の状況が分かる機能です。 一見外部カメラの映像をそのままディスプレイに出しているだけだと思われるのですが、実際には違う場所にあるカメラ映像を合成してヘッドマウントディスプレイに表示する機能になっています。 今回の記事ではこの機能の動作原理について論文を踏まえて紹介します。

視点合成

近年視点合成(複数のカメラから撮影された画像の合成)はホットなトピックになりつつあります。 NeRF [2] は昨年発表された論文で Radiance Field を CNN で表現してそれを最適化するアプローチであり、生成される画像のリアルさから評判になり後続の研究も次々発表されています。 Free View Synthesis [3] は同じく昨年の論文で事前に SfM でカメラ位置と大まかな三次元構造を復元してから、目標のカメラ位置にワープ(転写)した情報を使って CNN で画像を直接生成するアプローチになります。 このように色々なアプローチが提案されているものの多大な計算量を必要とするアプローチが主流であるため、実アプリケーションまで至っている物はほとんどありません。

Oculus Quest 2 にも搭載されている Passthrough+ [1] はカメラの位置関係が固定されていて、 そこまで品質が問われない状況で高速に視点合成を達成する方法を採用しています。

Passthrough+

概要

この手法はVRゴーグルの下付きカメラx2から両目位置での視点位置映像を 72 Hz @ CPU 1 core + GPU (Snapdragon 835 (Oculus Quest)) で合成可能な物になっています。 この合成では、他のアプリケーションの動作を阻害しないように、計算リソースをほぼ使っていません。にもかかわらずこの速度を出せるのは驚異的です。

[1] Fig.2 より引用

上の図からも分かるように両眼(橙)とカメラ(青)の位置・方向が一致していません。

全体的な構成としては

  1. ステレオカメラによる Depth 推定 & 時系列的なフィルタリング @ CPU
  2. 半球上での Depth 補間 @ CPU
  3. ステレオレンダリング @ GPU

になっていて、 前方を覆う程度の半球上のメッシュを三次元構成してそれを別位置から見ることで視点合成を達成しています。 高速な動作を達成するために 1-2 は 70 x 70 程度の解像度で実行されます。

1. ステレオカメラによる Depth 推定 & 時系列的なフィルタリング

ステレオカメラ(2眼カメラ)ではそのカメラの位置関係が予め分かっていれば2枚での対応点を検索して、 その画像中での位置の違いを見ることでその点の三次元位置を計算することができます。(三角測量の原理)

一般に 2 枚の画像の対応点検索を CPU で処理すると時間がかかりがちなのですが、ここでは SoC に搭載されている H.264 Encoder を利用することで消費電力の削減と処理時間の削減を達成しています。

動画の圧縮規格である H.264 では基準となる I フレーム以外は動きと残差を記録することで全体のデータサイズを抑えています。 したがって H.264 の Encoder は 8 x 8 のブロック(マクロブロック)のブロックマッチングを高速に求める H/W ブロックが搭載されており、その結果を利用することで2枚画像の対応点検索を高速に行なうことが可能です。

H.264 のフレーム間予測のイメージ

この対応点検索を行なう2枚画像については歪み補正と平行化と呼ばれる処理を実施した物を入力します。 この前処理を行なうことで1枚の画像の特定の対応点は違う画像での同じ高さの線上に位置することになります。 したがってブロックマッチによって検出された対応点組から同じ高さにあるものだけを抽出する必要があります。

他に注意すべき点としては H.264 でのブロックマッチには画像の差分だけではなく動きの大きさも考慮されていることがあります。

これらの点を踏まえて以下のような画像が入力されます。

[1] Fig.4 より引用

半マクロブロックシフトの組み合わせ4通りが埋め込まれていることが分かります。 ( ( 0, 0 ), ( 0, shift ), ( shift, 0 ), ( shift, shift) )

また動きベクトルの妥当性を検証するために逆順でも計算します。(P (左側) -> I (右側) -> I (左側) の順)

得られた動きベクトルは1ブロックについて 4 x 2 で 8 通り取得されますが、これらを

  • L ↔ R で動きベクトルが一致していること
  • 動きベクトルの垂直成分が小さいこと

を基準にして選択します。この対応点情報を使うことで物体点の Depth 値の推定をすることが可能になります。

ただしこの対応点情報も時系列的にフィルタリングすることで安定性を改善しています。 観測点を使って以下のように点候補を更新します。(各点候補は重みを持っています)

  • 各ステップ、点候補に存在する観測点だけを最終的な対応点として使用
  • 各ステップ終了時に観測点は以下のアルゴリズムに則り点候補に追加
    • 観測点で点候補に近い物は重みを増加
    • 点候補に近い物がない場合は重み0で追加
    • 観測点が存在しない点候補の重みを削減
    • 重みが0より小さくなったものを点候補から削除

このような手法を取ることで対応点の時系列的な外れ値除去が可能になります。

2. 半球上での Depth の補間

前の節で対応点を求めることが可能になりましたが、そのままではスパースな対応点でしかないためメッシュとして三次元表現するためにそれを Dense にします。

Depth の補間については様々なアプローチが知られていて最適化による方法の他に CNN によるアプローチも最近は取られています。 (文献紹介)Depth Completionの最新動向 - Morpho Tech Blog

[1] Fig.6 より引用
ここでは前方の半球上のグリッド (70 x 70) で Depth 値を補間します。 実際には、手前側を重要視するようにグリッド上の値を Inverse Depth で計算します。 画像合成の Poisson Matting などと同様に Poisson 方程式を解くことで滑らかな三次元曲面を推定します。 x : グリッド上の Inverse Depth, \bar{x} : 観測点の Inverse Depth, S : 観測点の集合として以下の2次形式の最小化に対応します。 これは停留条件の線形方式を解くことで計算することができ、ここでは SOR 法を採用して計算しています。 (共役勾配法の方が収束性能はよいが計算の都合上 SOR 法の方が結果として高速だったようです)

二次形式の最小化と線形方程式

この最適化問題に対する観測点を

  • 時系列的フィルタリングで得られた点候補 (重みw=1/6)
  • 前フレームで得られたポイントを現在位置に射影した点 (重みw=5)

とすることで時間的にさらに平滑化しています。

3. ステレオレンダリング

GPU 上で Depth Map の情報からメッシュを生成する部分です。 ヘッドマウントディスプレイなので両眼を設定する必要があり、左目・右目でそれぞれ左カメラ画像・右カメラ画像をテクスチャに設定します。 単一テクスチャの場合に比べて (1) ワープする量が小さくて済むので自然な絵になりやすい (2) 視野の大半をカバーしやすい などの利点がある一方で物体が近距離にあると視覚的に違和感がでやすい欠点があります。

その他 CPU と GPU を適切に連携させることで遅延を意識させないような工夫がなされています。 CPU はカメラ映像を即時に GPU に転送、幾何的情報は計算後に転送し、 GPU は情報の更新がない限りは自己位置の情報とテクスチャとメッシュで常にレンダリングを実行し続けます。

4. 結果

ステレオの計算部分については Rectification (0.6 ms), Motion vectors (2.8 ms), Decoding (1.7 ms), Spatial checks (0.5 ms), Temporal filtering (1.0 ms) と 6.6 ms 程、 Depth 補間については System matrix setup (0.8 ms), Solver (0.7 ms) と 1.5 ms 程でトータルで見ても 9 ms 以下で動作が完結していることが分かります。

実際のカメラで撮影されてからディスプレイに表示される時間(photon-to-texture latency)は 49 ms 程度であり、 実体験としても特に違和感がない動画が描画できています。 筆者によるとこの時間が視覚的な違和感につながりやすく、100 ms 程度の場合はかなり遅延があるように見えるそうです。 一方で三次元構造がディスプレイに反映される時間(photon-to-geometry)は 62 ms 程度ですが、この遅延は 100 ms でも特に顕著ではないとのことで興味深い知見になっています。

絶対的な精度に関しても 1m 程度の Depth の誤差が 0.02m 程度であり、 それなりの精度が達成できています。

5. まとめ

論文ではリアルタイムかつ低消費電力な視点合成について提案されていて、実際に市販の端末で体験できるものになっています。 視差推定のあたりの H/W の利用方法などかなりエンジニアリング的な方法ですが、実際携帯端末での低消費電力かつ高速な実行を考えると H/W の活用は避けて通れない道です。 論文中でも述べられていますが Optical Flow 計算などについては SoC 側での H/W での機能拡張が進んでいる領域になっておりこれからも活用が進んでいくと思われます。 視点合成の端末での実現もホットなトピックになっていてこれからもキャッチアップしていきたい分野になります。

6. 引用文献

[1] Chaurasia, Gaurav and Nieuwoudt, Arthur and Ichim, Alexandru-Eugen and Szeliski, Richard and Sorkine-Hornung, Alexander, Passthrough+: Real-Time Stereoscopic View Synthesis for Mobile Mixed Reality, in Proceedings of the ACM on Computer Graphics and Interactive Techniques (2020).

[2] Ben Mildenhall and Pratul P. Srinivasan and Matthew Tancik and Jonathan T. Barron and Ravi Ramamoorthi and Ren Ng, NeRF: Representing Scenes as Neural Radiance Fields for View Synthesis, ECCV (2020).

[3] Gernot Riegler and Vladlen Koltun, Free View Synthesis, ECCV (2020).