Intelの研究部門を率いるJustin R. Rattner(ジャスティン・R・ラトナー)氏(Senior Fellow, Chief Technology Officer, Intel)は、昨年(2011年)の同社のカンファレンスIntel Developer Forum(IDF)のキーノートスピーチで、マルチコアプログラミングの例として、JavaScriptからマルチコアに並列化するAPI「River Trail(リバートレイル)」を発表した。Intelの研究部門が開催するカンファレンス「Research@Intel 2012」では、同社のプロジェクトの進展が展示された。

　River TrailはFirefoxの拡張として実装され、JavaScriptからOpenCLのコードに変換する仕様となっていた。Intelのデモでは、OpenCLからマルチコアCPUのAVX/SSEエンジンに落とし込んでいた。今回のResearch@Intelでも、FIrefoxでのRiver Trailのデモが行なわれ、シーケンシャルなJavaScriptを、River Trailで並列化した場合に、15fpsだったアニメーションが45fpsに上がる様子が展示されていた。

　しかし、今回のResearch@Intel 2012では、より上位のレイヤーにスポットが当てられていた。Intelが推奨する、3D WebのためのHTML拡張である「XML3D」と、XML3Dをベースにしたデータフロープロセスカーネルである「Xflow」だ。それって、WebGLに対してどうなのか、という疑問が沸いてくると思うが、XML3Dはややレイヤーが異なる。より抽象化した仕様で、WebGLに落とし込む形を取ることもできる。実際に、Research@Intelでデモを行なっていたのは、WebGL上で動作しているバージョンだった。ChromeとFirefoxでの“ネイティブ”バージョンは、動いていると説明しているが展示はなかった。

　Research@Intelイベントでは、IntelはFirefox版とChrome版の2種類のデモを展示。どちらもWebGL上のXML3Dの同じアニメーションのデモで、アニメーション自体はXflowカーネルとなっていた。Xflowカーネルからの実装は、Firefox版とChrome版で異なっており、Firefox版ではXflowからRiver Trail APIで並列化し、River TrailからOpenCLへと落とし、マルチコアCPUで実行していた。それに対して、Chrome版はRiver Trailを呼ばずにシーケンシャルなコードのままCPUとGPUで実行していた。

　厳密に言うと、下の図のようになる。Xflowでのアニメーションのフローでは、図の下の方になる、上流の部分はCPUでシリアルに実行し、skinDirectionとskinPositionからGPUとなっている。Firefox版では、このスキンの部分をRiver Trailに渡して並列化して、複数のCPUコアで実行しているという。上流のパイプラインは、カーネルが小さ過ぎるため、並列化を試みてもオーバーヘッドが大きいので、そのままにしてあるという。

　現在のIntelのデモでは、Xflowの部分は、OpenCLでCPUに持って行っているが、今後はGPUにもマップして行くという。また、これはXML3D全体の話になるはずだが、LLVM(Low Level Virtual Machine)コンパイラインフラストラクチャを使うことで、NVIDIAのPTX(中間言語)などへもコードをはき出すことを考えているという。

　Interactive Surfacesは、壁面を使ったインタラクティブなジェスチャコントロールのユーザーインターフェイスのデモだ。このデモの最大の特徴は、何の変哲もないただの壁を、インタラクティブな画面に変えてしまう点。壁面に表示した写真や動画を、移動させたり、大きさを変えたりといった操作を、壁をタップ(叩く)したりホールド(押さえる)したり、壁をスワイプ(壁面で手を滑らせる)することで実現する。

　壁面に表示される画像はプロジェクタで映し出している。壁面自体にはしかけは何もない。どうやって人間のジェスチャを検知しているかというと、それはKinectセンサだ。壁面に取り付けたKinectセンサのデプス(深度)カメラが、壁に向かって操作する人間のジェスチャを捕らえる。あっけない程の仕掛けだ。

　Intelの研究者によると、この利点は3つあるという。まず、コストが非常に安く済む。壁面に特殊な装置を取り付ける大がかりな作業が必要がない。次に電力を抑えられる。センサーだけで、壁面全体に展開するなら200Wが必要になるところを、わずか3Wに抑えられるという。次に、形状に捕らわれない柔軟なインターフェイスが可能になること。実際には壁面だけでなく、曲線状や波打った形状でも、どんな壁面にデータを映し出しても、Kinectセンサーで操作が可能だ。

　実際には、操作だけを考えるなら、Kinectなので、壁面である必要もない。しかし、Intelの研究室では、色々試した結果、壁面に向かって操作するアプローチが一番いいと判断したという。それは、壁面をタッチしたり、スワイプすることで、ユーザーが実際に手応えのフィードバックを得ることができるからだという。「機械の方は壁が必要ないが、人間の方はフィードバックを得るために壁が必要だ」とIntelの研究者は説明する。

　IntelがResearch@Intel 2012のデモで見せていたのは、シングルタッチのインターフェイスだ。しかし、実際には研究室レベルではマルチタッチが実現できているという。イベント会場では壁の1方向からKinectで検知しているが、研究室ではさらに天井にもう1基のKinectセンサを据えることで、マルチダイレクションの検知が可能になっているという。

　現在の問題は、Kinectセンサー自身の仕様で、検知できる範囲が狭いため広い壁面をカバーできないこと。しかし、Kinectを利用することで、安価に研究ができているため、トレードオフだという。「こうした試みができるようになったのも、Microsoftのおかげ。彼らは、Kinectでは素晴らしい仕事をした」とIntelの研究者は語る。Kinectで一気に広がった、リサーチコミュニティでのヒューマンインターフェイスのブームは、Intelにも及んでいる。

　Kinectを使った研究では、もう1つユーモラスなものが展示された。

　下の写真の不審な赤いフード付きジャージは、買い物Kinectロボットだ。買い物客の目となって、実際のショップで動き回り、商品を見て歩く。リモートで操作するユーザーの指示に合わせて商品に近づき、ラベルを読み取り、ユーザーが求める商品の情報を集める。クラウド側のデータベースで商品のデータを得て、購入する場合は、オンラインストアで購入する。実際に、買い物ロボットが商品を持って帰るわけではない。利点は、実際の品物を、自分の眼代わりのロボットカメラで確かめることができる点。ストックの有無や、実物を前にしなければわからないさまざまな情報をリアルタイムで入手できる。

　毛色が変わった研究では「Seeing through Rain」と題した、自動車のライト技術がある。これは、雨の夜のドライブ時に、ライトを雨粒が反射して前が見えにくくなる現象を軽減しようというものだ。言ってみれば、画像版のノイズキャンセラだ。

　具体的には、ライト光源のところにビームスプリッタを仕掛けて、カメラでライトに向かって反射して来る雨粒からの光を捕らえる。カメラから取り込んだ、雨粒のラインをプロセッサで処理して、雨粒の予測位置の位相を反転させたデータを生成する。ライトは実際には画像プロジェクタとなっていて、予測雨粒のライン部分を暗転させた光をプロジェクタから照射する。プロジェクタの照射で暗転している部分が、雨粒のラインと重なるため、雨粒の反射はなくなる。それによって、ドライバの眼からは雨粒が見えないようになる。下のスライドは実験の結果で、右側が装置を作動させた結果で、雨粒が消えている。

　実験装置では16の雨ジェネレータが1秒間に2粒ずつ雨粒を落とすことで、90mm/hのどしゃぶり状態を再現している。その雨粒群からの反射を、ライトに仕掛けたカメラで捕らえて、雨粒の下に向かうラインの光を反転させて打ち消していた。現状では、プロセッシングのタイムラグがあるため、ビーム照射範囲の上側に13msec分の雨粒のラインが残る。13msecは、カメラでキャプチャしてから照射するまでの全行程のレイテンシだ。

　また、実際にはカメラで捕らえられる幅が限られるため、狭いレンジでしか打ち消し処理をしていない。雨粒は、ドライバから見たライトの先の位置ということで、現在は150cmに設定している。そこから20cmの範囲の雨粒に対する処理を行なっている。今後は、プロセッシングパフォーマンスが上がるにつれて、処理する雨粒の数を増やして行くという。

　最終的なゴールは、クルマの前面ガラス全体の範囲で、雨粒を消すこと。その場合は広範囲な雨粒を相殺しなければならず、また、相殺する雨粒の深度をどの程度にするかなどの課題があるという。もっとも、クルマ側にドライバの眼球の動きをトラックする機能をつければ、ドライバが見ている部分の雨粒だけを消すといったことも可能になるだろうという。

実際の実験装置。ガラスがビームスプリッタ	雨粒を実際に落としているところで、雨粒の予想位置の光を反転させている	反転させない状態

実験装置の概要図

　下の写真は、アバターベースのコミュニケーションアプリケーション「Avatar Video Chat」の研究で、人間の顔をアバターに変換して会話できるようにするものだ。相手の顔のアバターが現れて、表情豊かに対話するというわけだ。PCだけでなく、スマートフォンやタブレットもプラットフォームとして想定している。ポイントは、低帯域と低パフォーマンスCPUに最適化している点。

　このアプリケーションは、ユーザーの顔を認識して、頭の動きや表情をトラックしてアバターに反映する。スマートフォンに実装するためには、顔認識のアルゴリズムを軽くする必要がある。顔認識では、通常は映像のピクセルを総当たりで一定サイズのグリッド単位で探査して、人間の顔を検出する。いったん顔を検知した後は、次のフレームでは顔を検出した近くのピクセルを走査するだけで済むため負担は小さいが、最初や、顔位置を見失った場合は負担が大きい。

　そこで、この研究では、スマートフォン側のアプリに、ユーザー自身の顔が映し出されるカメラ映像のウインドウを設けた。ユーザーは、自分の顔が映し出されるため、自然にウインドウに自分の顔をはめ込むようにスマートフォンを操作するように誘導される。これによって、顔自体の検知の負担を減らした。

　顔認識では、目などのパーツの検知も重要だ(人種によっては目鼻立ちの認識が難しい場合がある)。これについては、この研究では、前後のフレームを比較して、瞬きしている部分を目として認識するようにしたという。人間の瞬きという生理現象を利用するわけだ。このアプリでは、表情も認識して転送するため、瞬きも検知するが、それを目自体の検知にも利用している。ただし、怪我などで瞬きが停止してしまった場合は、多少困ることになる。

　ユーザーの口の開閉もアバタの表情に反映させるが、これは口だけでは難しいため、実際にはアゴの位置も使っている。検知しやすいアゴの下の部分やアゴの左右の部分の動きで補完することで、口の動きを認識してアバターに反映している。

　こうして検出した19のアバターパラメータを、32bit単精度浮動小数点演算の3次元xyz座標データとして送り、アバターの顔と表情を操作している。アバターは3Dだけでなく、2Dの線画のようなデザインも用意している。必要なデータ帯域は、わずか15.2kbpsで、25fpsのレートを実現できるという。ちなみに、デモを行なったスマートフォンは、IntelのAtom系のスマートフォン用SoC(システムオンチップ)「Medfield」を使ったLenovoのスマートフォンだった。

　今年(2012年)で10回目を迎えた、Intelの研究カンファレンスResearch@Intel 2012。米サンフランシスコのYerba Buena Center for the Artsの会場には、この他にもさまざまなテーマの研究が展示された。