MacBook Proと4Kディスプレイその他の環境

MacBook Pro

タッチバー環境です。AUKEYのUSB変換アダプタは動作には問題ないが、少し干渉する。 pic.twitter.com/28jbJOtl4l

— (╹◡╹ (@non_117) 2016年11月19日

Touch Barの13インチのやつを買いました。

キーボードが使いにくい、Touch Barなんて使わないなど諸説ありますが、スペックが上がっているだけで価値があると思っています。

レガシーUSBとの共存

AUKEY USB C to USB 3.0 変換アダプタ 新しいMacBook Proなどに対応 CB-A1

 変換するためにこれを買いました。 

つらい pic.twitter.com/jE204J1ELZ

— (╹◡╹ (@non_117) 2016年11月19日

ヘッドホンやTime Machineバックアップ用のディスクなどを有線で繋ぐのにハブを使っています。お金がある人はストレージやヘッドホンやキーボードを無線化すると良いんじゃないでしょうか。

この変換アダプタの問題点がひとつあり、上の図のようにAUKEYの変換アダプタ同士が干渉するので、隣り合うコネクタには刺さないほうが良さそうです。

無理やり刺すといやな音がします。

4Kディスプレイ

Dell ディスプレイ モニター P4317Q/4K/42.5 インチ/IPS/8ms/DP,mDP,HDMI,VGA,RS232/USBハブ/3年間保証

気持ちが高まって買いました。

選択肢はそれなりにあって、先人の知恵として

r7kamura.hatenablog.com

ディスプレイ遍歴 - 9mのパソコン日記

この辺の記事が参考になりました。

40インチはでかすぎないか

PC用の4Kディスプレイには28インチ帯と40インチ帯にピークがあるのですが、個人的には40インチ帯のほうがおすすめです。確かに、届いたときはあまりの大きさに引くのですが、日常的に使っていたらディスプレイは慣れで縮みます。

また、幅100cmくらいのディスプレイを50cmの距離から見ると、だいたい視野すべてがディスプレイで埋まるので没入感が上がるような気がしています。

コネクタ類

PS4 PROを4Kで繋ぐならHDMI 2.0対応のものを買いましょう。P4317QはHDMI2.0には対応していません。DisplayPortは2つあれば十分だと思います。

MacBook Proとの接続

在庫切れになっていますが、

https://www.amazon.co.jp/gp/product/B01EXKDRAC/

を買いました。

ケーブルが少し硬いですが接続性は全く問題がないです。

その他のポイント

MacBook Proに繋ぐケーブルの数

4Kディスプレイ環境で充電をしながら、レガシーUSBを繋ぐので合計3つです。

www.apple.com

3in1 USB 3.1 Type-C to HDMIアダプター USB3.1 type C to HDMI+USB3.0+Type-C/F MACBOOK 2015、2016 /GOOGLE Chromebook /GAGABYTE Z170X /Microsoft Lumia950 /Lenovo Yoga 900/ Huawei matebook対応 (シルバー)

この手のドック的なコネクタを買うと1あるいは2端子専有に抑えることも可能ではあります。

上記のように3本つなぐなら、Touch Barのモデルにするのは確定です。よかったですね。

Touch Bar使うのか問題

プログラマにはあまり恩恵無さそう……。

覚えられるくらいよく使うショートカットキーなら覚えているキーを押すほうが速いので、たまに使うかも？くらいの機能にTouch Barを割り当てると便利になるかもしれません。

ただし、ボタンとしてのTouch Barではなく音量や写真のフィルタのような連続値を制御するには良いインターフェイスだと思います。

以上です。どれも良い製品なので迷ったらこの構成にするとやっていきが捗ります。

ReactでもDOMの木構造はつらいよ問題

nippo.wikihub.io

r7kamura

Commented on 2016-09-01

何も考えずにReact, Redux使うような気はするのだけど、Reduxを使わない場合は各位どうやってState管理してるんでしょうか？

親コンポーネントがstateとメンバ関数を持っており、子コンポーネントはpropsかcontext経由でその値を参照しながら描画とイベントバインディングを行っています。

日報で疑問を書いたら、id:r7kamuraさんが答えてくれた。

immutable.Recordに状態とロジック押し込んでそいつをContainer Componentのthis.stateに入れておく設計とか。

— 下京区 (@non_117) 2016年9月1日

 facebookが想定してるのはこの用途かな。

DOMサブツリー間で状態の共有が発生するか、設計段階で予見するの難しそう。

— 下京区 (@non_117) 2016年9月1日

原則として、木構造を小さくするべきだと思っている。木のデータ構造はノード間の依存関係があるからである。バケツリレーはノード間の結合を強くするので良くない。

なので、ページ全体のComponent木を部分木で構成するべきである。部分木の中でのstate置き場が部分木でのRootのContainer Componentで、子孫がPresentational Componentとなる。部分木とは、UI上で意味のある単位で分割されたComponent木である。

部分木同士が疎結合であるならば話は簡単なのだけど、部分木間でstateを共有したいとなると厄介なことになる。

仮に木全体のRoot Container Componentにグローバル変数を置いてもそれを子孫に渡すにはバケツリレーかcontextが必要になる。contextは暗黙的にバケツリレーしてるだけなので(ちょっと認識が合ってるか自信はない)部分木同士に依存関係が発生することに変わりはない。

部分木たくさん作ったときに、グローバルStateの注入で木同士の依存を発生させにくいのがRedux, [ここにあなたの好きなFluxの名前が入る] だと思っている。

私はReduxしか真面目に勉強しなかったのでReduxの話になるが、Reduxの場合は唯一のStoreにグローバル変数をぶち込んで好きなときに切り出して部分木に流し込むことができる。この時に部分木間でpropsが流れることはない。

contextを使ってルートComponentからグローバル変数を配るの出来なくはないが、その辺(状態の共有)からがflux使う分水嶺になりそう。

— 下京区 (@non_117) 2016年9月1日

 結論としてはこれになる。

原始的Propsバケツリレー

こうしたい

おまけポエム

とはいっても、人間は複雑なものを認知できないので、人間が直接触る木構造とかさっさと無くすべきだと思っている。スマートヒョンのGUI作る君だってGUIじゃないですか。

木構造は機械に優しいが人間には優しくない。特に変更をするときは。

UIとか作っては弄っての繰り返しを避けられないので木構造の変更・メンテナンスを人間がやるはめになって消耗必至である。

「君の名は。」感想, ネタバレ込み

「君の名は。」を観たので言語化を行います。上映が終わって1時間も経っていないので大変新鮮なエモをお届けできることかと思います。ネタバレは多量に含むものとするので各位勝手にやっていってください。

✨表現✨になんか負けない (@ イオンシネマ京都桂川 - @ac_katsuragawa in Kyoto, Kyōto w/ @pastak) https://t.co/6n52EdvnlG

— 下京区 (@non_117) 2016年8月29日

客層

中高生メインで小学生も見受けられた。イオンで観たというのもあるかもしれないが。客層のせいか、せっかくのやまむらやCMが流れている間にも喋っている人が多くて大変よくない態度だった。でも、我々は大人なので慈悲の心で許さなければならない。

序盤

どのタイミングで入れ替わっているのかが多少わかりにくかったが慣れるとなんとかなった。OPが流れるまでのシーンですでに映像表現と5.1chサラウンドで脳がやられかけていた。桂川イオンの設備はULTIRAとかいうやつで、スクリーンがでかくて音が良い。眼前いっぱいのスクリーンにかわいい女の子と美麗な風景、光表現が登場するとオタクは速やかに脳をやられて死ぬ。

中盤

ちょっと退屈だったがぎりぎり没入できていた。たぶんここの筋に致命的な所は少なかったのだと思う。

終盤

おいおいまじか爆破させるのか。

一つだけデバッグ的発言をすると、電力系にSPOFは無いのでは？というツッコミです。

— 下京区 (@non_117) 2016年8月29日

これは許せない。
あと結局落ちちゃったのは、新海誠が蒸発→衝撃波を描きたかったのだと思っています。

ラスト

直後の感想としては『良かったですね👏』だったんだけど、スタッフロールが流れ始めた途端にもやっとしたものがとめどなく。

— 下京区 (@non_117) 2016年8月29日

記号！映像！音楽！ドーン！

— 下京区 (@non_117) 2016年8月29日

総括

記憶力を無にして素直に観ると大変良い作品だったと思う。後味が良くて象徴的な記号シーンでいい感じの歌が流れていたら脳直で人々は感動するんですよ。三葉がこけて手を開いたシーンとかで隣の席の女性泣いてたし……。

しかし、細かいところを突っ込みだすとキリがないくらいもぐらたたきができると思う。我々オタクはだいたいアニメの台詞を覚えて日常生活で喋っちゃうタイプなので、大筋に満足するのだけど細かいところが気になってモヤモヤするという現象が起きる。

なぜモヤモヤするのか

物語での整合性として、登場人物の気持ちで解決できるラインと、魔法で解決できるラインがあると思う。ヤシマ作戦とかの勝利が前者で、ウィッチに不可能は無いのが後者。ガルパンの特殊カーボンも後者。

フィクションである以上は気持ちが存在しない作品はおそらく存在しないので、これはある前提で良い。ここを疑ってはならないので、気持ちのパワーで秋の山頂で寝ても大丈夫だし、気持ちの力で山を高速に降りることができる。

問題なのは、魔法の存在とそのルールが視聴者に共有されるかどうかで、これが共有されてないと視聴者は混乱したり没入できなくなる。「君の名は。」でも魔法はいくつか登場しており、入れ替わりや酒と紐で物理はねじ曲がるのが主である。日記アプリのログが消えるのも個人的には絶対に許せないがそれは今いいです。
現代のフィクションでは物語の序盤で魔法のルールとその運用について視聴者に説明されることが多い。ラノベ原作アニメの第一話で見られるアレである。理想的には、最初のルールに原則従っていきつつ気持ちでルールをハックしたり、隠しルールを出す物語が視聴者にとってわかりやすいのだと思う。ただし、ルールが追加、更新されるさいには必ず視聴者への説明が必要になる。これが無いものはご都合主義のそしりを逃れることはできない。(既存の世界観やルールから自然に類推できるものが追加されるのであれば省略されることも多い気はする)

魔法の提示方法を踏まえたうえでの「君の名は。」での問題点は、現代っぽいどこかの世界を前提にしているのに、要所要所は未説明魔法で物語が進んでしまう点にある。簡単に言うとご都合主義にすぎない。というのも、我々は現実世界に生きているので魔法の説明がされなければ自然と現実世界ルールで物語を消費することになるからだ。
新海誠の世界が現実に即したものではなく、完全にファンタジーな世界であれば、多少変なことが起きてもそういう世界なんですねで済むのだが、現実世界ルールが適用されてるとなるとそれは守られなければならない。説明で例外が適用されない限りは。
だが、新海誠は鉄道とふすまのオタクなので現実世界を書かないわけにはいかないし、現実世界ルールが前提になっていると視聴者が覚えるルールが少なくて済むので一般人にとって楽というメリットもある。
このようにして、大衆的商業主義に舵を切ると現実世界ルールがベースになるのだけど、そこに追加ルールを敷いて全体の面白さと整合性のルールを守るのはけっこう難しい作業な気がする。

とは言ったものの、「君の名は。」のルール違反で私が思いつくのは送電網の単一障害点問題と、衝撃波での生き残りすぎ問題くらいで、大半は気持ち駆動で片付けられるような気はする。というか私は割と没入できてしまった弱いオタクです。。。
気持ち成分強めの作品は、気持ちの振幅が小さい人々には響きにくいので没入感が得られにくく、没入できないとなるとかなり冷静に物語を眺めるので物語のルール違反が散見されるのが各位が苦しんでいる現象ではないでしょうか。たしかに、気持ち多すぎは胸焼けするので良くないです。

(追記)

気持ちで物語を動かすのにも準備が必要で、登場人物みんなの気持ち遷移の整合性も重要そう。つまり、徐々に高まっていって状況を作り、最後にえいっと気持ちでキメるみたいな？

この状況作りができずに、我々視聴者の知らないところで勝手に主人公の気持ちが高まるとご都合主義だとか置いてけぼり感が出てしまうのだと思う。

(追記終わり)

どうすればモヤった視聴者は救われるのか

救われません。残念でしたね諦めましょう。

父との融和は？？？

ここまで書いて気がついたのだけど、三葉と父が最後の最後でかち合ってから避難するシーンが描かれていない。実は生きてたんよ〜演出をして視聴者をびっくりさせたいのもわからないでもないが、親子の確執をよくあるテーマとして記号的に出した割に解決しないのは中途半端で良くない。他に削れるシーンあるでしょ。

(追記2)

r7kamura.hatenablog.com

に記載されたやり取りでわかりもあったが、外伝小説読んだらすべて解決した。

www.amazon.co.jp

以上です。私はここまで言語化できたのでもう満足です。
それにしても三葉はかわいいですね。

なぜReactなのか

なぜReactなのか

React, Cyclejs, Reduxを学んだ上でこれらの技術が何を解決したのかまとめてみる。発想はオリジナルではなく、今まで私が読んだ記事から拝借した解釈などが含まれている。たぶんReact, Fluxを学んだ人にとっては当たり前の感覚を言語化しているだけの内容となる。

TL;DR

Q: なぜReactなのか
A: フロントエンドが自由度の高いGUIアプリケーションになった。既存の手法では自由度の高いGUI実装を人間にわかりやすく管理することが難しくなった。

自由度の高いGUIな世界

• 自由度(複雑さ)の低い時代ではrender済みのDOMの上にDOMを操作する(jQueryによる)UIを載せる設計でも十分だった
• 現代のwebフロントエンドではVisual StudioやXcodeで作るネイティブGUIと同等の複雑さを求められる時代になっている

• jQueryだけで複雑なGUIを実装するとDOMそのものが状態(State)であることが問題になる

  • DOMというグローバル変数に対してあちこちからCRUDする状況で、複雑さが増すにつれて人間にはメンテできないコードになる
    • クソコードと呼ばれる状況

• React ComponentはDOMと状態を切り離した上でUI部品のコンポーネント化も行った点で優れていた

  • コンポーネント化は真新しい概念ではなく、おなじみの「関心の分離」
    • 人間にとって管理しやすくなることが重要
    • 再利用性が上る(こともある)、単体テストしやすくなるといった恩恵
    • コンポーネント化を担うのはReactである必要はない
  • 状態の管理は有史以来プログラマを苦しめ続けたやつ
    • たとえばサーバサイドだとDBとモデルに押し込めたり、マルチスレッドだとロックをきちんととったり
    • React Componentには this.state, this.props の変更を検知してDOMをrenderするライフサイクルがある
      • React Component単体ですでにDOMの状態を変更するフローは一方向になっている
      • DOMの状態を変化させるフローをUI設計全体に適用したのがFlux
    • FluxもReact Component同様に状態の変化に制約を与えるのが目的
      • 複雑な問題は制約を与えることで解きやすくなるし人間にとって認知しやすくなる
      • UI実装がスケールするならFlux層はなんでもいい
  • 状態の切り離し・管理とコンポーネント化を推し進めた設計が優れていたのであり、React, Reduxであるから無批判に良いというわけではない
    • React, Reduxにも問題はある
      • propsバケツリレーつらい問題
      • Reduxの非同期処理いけてない問題
      • React, ReduxそのものはStateとComponentをどう構造化すべきかフレームワークレベルの制約を与えてない(ドキュメントに指針はある Usage with React | Redux)

• SPAであることが重要なのではなく、フロントエンドを複雑なGUI環境としてとらえる視点が重要ではないか

  • 自由度の高いUIを実装するには状態管理の制約とコンポーネント化があったほうが効率が良い
  • 要件で必要とされるUIの自由度によって適切な手段を選ぶべき
    • 自由度が低いなら今までどおりjQueryでもスケールする要件はある
    • 境界がどこにあるかは不明

今後

• UIのコンポーネント化やGUI実装そのものの運用はMicrosoftなどから学べるものも多そう
  • UnityのようなReactコンポーネントストアできるのでは(既にある？)
  • 個人的にはWPFのようにGUIのUIビルダーがReact向けに出てきてほしい

まとめ・言いたかったこと

• GUI実装自由度の向上によって状態の管理とコンポーネント化が必要になったのではないか
• SPAであることが重要なのではない
• React, Reduxといったフレームワークは決して銀の弾丸ではないので、問題に応じて相応しいフレームワークを選びましょう

「人工知能は人間を超えるか」という本を読んだ

www.amazon.co.jp

現役の研究者が、人工知能技術の現状と今後の展望について地に足の着いた視点で論じている本だった。
過去の人工知能ブームが何故収束し冬の時代を迎えたのか、そして今の人工知能ブームが何故もてはやされており、巨額の投資が行われているかを技術的な観点から語っている。

1~5章

ここを読めば、何故今の人工知能ブームとビッグデータ(付随してIoT？)が喧伝されているか理解できるはずだ。人工知能研究の黎明期から現代への流れと、要所要所の技術について、そしてそれを踏まえて何故ディープラーニングが優れているかを述べている。特に、ディープラーニングの要素技術である、特徴表現学習とロバスト性を獲得する手法についての解説がわかりやすかった。（オートエンコーダ, ドロップアウト）

6章〜終わり

研究スライドでの今後の展望にあたるので、眉唾ぎみで読むと良いと思う。ディープラーニングを使って一発当てたい人は、参考にしつつ自分で頭を捻れば良いのではないだろうか。そもそもそれには大量のデータと計算資源が必要ということは終章で指摘されているが。
また、シンギュラリティによって人工知能が人類を支配するのか、という問は明確に否定されており、計算機の上で動作する人工知能が自己生産を行うのはコスト的・技術的に困難であることがよくわかる。
現在のブームの空回りしている点については明確に釘を刺しており、web上の適当なメディアの記事を鵜呑みにするよりはこの本を読むほうが良い。

ゆゆ式を無限に楽しみたかった話 〜 ゆゆ式 Advent Calendar 2014 20日目 〜

ある日のこと、後輩たちがこんなことを言いました。

「ゆゆ式のコマをランダムに並びかえたら無限にゆゆ式が楽しめるのでは？」

真面目に計算してみると、10の15乗くらいの組み合わせができることがわかりました。
この記事ゆゆ式アドベントカレンダー20日目は、そんな無限にゆゆ式をたのしむためのシステムを真面目に作ってみた話をします。

コマの切り出し

漫画のコマを並び替えるためには、コマがバラバラな画像として存在していなければなりません。
なので、まずは自炊で電子化された書籍をコマの線にそって切り出していく処理を自動化することにしました。

上の図がふつうの4コマの1ページですね。これの枠線を識別して、1ページから8枚のコマを取り出してくる方法を考えます。

ハフ変換で直線検出

OpenCVという画像処理のライブラリに直線を検出するツールがあったので、まずこれを試してみました。

が、結果はこのとおり。

漫画には直線がたくさん含まれており、ノイズだらけでなかなか上手くいきませんでした。確かに枠の直線も検知されていますが、複数の線が検出されたりして微妙ですね。パラメータ調整をがんばったらそのうち上手くいきそうですが、あまりに面倒です。
よって、この方法はボツ。

ヒューリスティック導入

さて困ってしまい手も足も出ず放置することn日、天啓がひらめきました。

4コマの枠というのは、ページに対して水平に引かれています*1。なので、2次元の画像を縦(あるいは横)から眺めると、4コマの枠線は必ず同じ直線上に並びます。
そして、この直線上に並ぶ枠線は濃い黒色で、コマの内側は灰色、コマの外側は白色になります。つまり、行列の縦ベクトルのように画像を一方向から見て画素値を足しあわせていき、画素値の平均値が255付近から急激に変化する箇所がコマの枠線になります。

抽象的な話でわけがわからないかもしれないので、実際にグラフを見てみましょう。

まずは縦方向から画素を足しあわせて平均値を求めます。

このグラフは横軸が画像の横方向のピクセル(座標)で、縦軸が画素値です。ちゃんと枠線の数だけ4つのピークが見つかるのがわかりますね？

同様に横方向も見てみます。

枠線の数、8つのピークがちゃんとありますね。

このように、画素を足し合わせるだけの簡単な処理で枠線の位置を見つけられることがわかりました。実際には、ピーク値をもっと急峻にするために微分や画像のフィルタ処理をしています。
そして、このピークの値で切り出すべき線を引いてみたのが次の画像です。

以上のように、画像を縦横から見て画素値が急激に変化する座標を見つければコマの枠線を見つけ、全てのコマを切り出せるようになりました。
実際には、ゆゆ式の凶悪なフォントによってノイズが発生したこともありましたが、数が少なかったので閾値の調整でなんとかなりました。

ゆゆ式ガチャの完成

さて、これでゆゆ式全6巻すべてのコマをひとつの画像として切り出してくることに成功しました。あとはそれらを並び替えるだけです。この処理は単純にゆゆ式DBからランダムに4つのコマを取り出してくるだけでした。@tyage, @pastakくんが実装してくれたのが次のようなシステムになります。

ページを開くと、ランダムなゆゆ式画像が4つ表示されます。また、リロードするたびに4コマ？を生成するため、同じコマと出会うことはできません。一期一会です。

また、コマをクリックするとランダムでそこだけ入れ替わります。頑張ってガチャを回しまくればそれっぽいものもできます。

 

これを作ってみた当初は皆頻繁にガチャを回していたのですが、なかなかおもしろい組み合わせは出てこなくてブームも下火になってしまいました。やっぱり原作が一番という結論でしょうかね。

以上がゆゆ式を無限に楽しもうとしたシステムの紹介です。

おまけ

話は脱線するのですが、このゆゆ式DBを作るさいに副産物的にゆゆ式の全台詞を書き起こしてIRC botにする計画が立ち上がりました。こちらの計画は、次のようなアノテーションツールを作るところからスタートしました。

1ページに切り抜かれた1コマが表示され、テキストボックスにその台詞や擬音語・擬態語を入力します。ショートカットキーを押すと次のコマに移動するものです。
また、キャラのタグ付けもすることになり、これもアノテーションツールになりました。

各キャラにショートカットキーが対応しており、キーを押すと選択されます。

このアノテーションを引き受けてくれたpossumさんですが、この作業に大いにハマってしまい、
「ゆゆ式アノテーション無限に時間をつぶせる。レポート出すまで封印しないと……」

「短時間に過剰なゆゆ式を摂取すると体調を崩す恐れが」

「この前今日はここまでにしておこうって思ったけど結局その後も入力してたし吸引力強い」

などと言いながら3週間で全巻のコマの書き起こしとタグ付けをしてくれました。
このデータは今ゆゆ式のコマを文字列検索するシステムとして運用されています。

以上、ゆゆ式をきっかけに作ってみたシステムの紹介でした。当然の事ながらここで紹介したデータ・システムはインターネットで共有することはできません。もし作りたいという方がいらっしゃるなら協力しますので、そのさいはご連絡下さい。

*1:理想的には. 実際には傾いてしまうため、eTilTranを使って修正しました

Kinect v2で人間の3Dスキャンとポイントクラウドでの描画をする 〜KMC／OUCCアドベントカレンダー2014 13日目〜

皆さん進捗どうですか？ KMC2回生の non117 です。私はダメです。

こちらはKMCアドベントカレンダー2014およびOUCC Advent Calendar 2014の13日目の記事となります。

はじめに

元々は古巣であるOUCCのアドベントカレンダーとKMCのアドベントカレンダーを同じ日に同じ記事で寄稿し、記事を節約することを目論んでいました。
しかし、気がついたらカレンダーが埋まってたため泣く泣く別々の記事を書くことにしました。 

新しくネタを用意するのも面倒なので、OUCCアドベントカレンダーで書いたKinect v2すごいよ！という記事の続きを書きます。

※追記

なんとOUCCアドベントカレンダーの13日目が空いてたので、目標が達成されてしまいました。

関連研究 

OUCCアドベントカレンダーではKinect v2がいかにモーションキャプチャとして優れているかという内容でした。また、具体的に人間の骨格座標を取得する方法を紹介しました。

他にもKinectはカラー画像, 深度画像, 音などをAPI経由で取得できます。これらのデータを取得し画面に表示するコードはSDK付属のサンプルで網羅されていますが、このサイトの解説記事がよりわかりやすいでしょう。

ところで話は変わりますが、近年ポイントクラウドと呼ばれる技術がもてはやされています。ポイントクラウドとは、（色付きの）3次元の点を大量に使って物体を表現する試みです。現代の3DCGでは多面体のモデルにテクスチャを貼り付けて物体を表現していますが、ポイントクラウドは計算資源の暴力によりきめ細かな表現が可能になるのかもしれません？ 知らんけど。

Kinect v2は照射した赤外線がセンサに返ってくるまでの時間の遅れ（Time of Flight! ）で物体までの距離を測るので、3次元物体のスキャンが可能です。つまり、Kinectで取得できる空間の3次元座標情報からポイントクラウドを作成することができます。

UnityとKinect v2を使ってポイントクラウド風の描画をしたのが以下の記事です。

しかし、UnityはMono上で動作するため制約が多い上にリアルタイムに描画すると大変重くなります。リンク先の記事でも10fps程度しか出ないようです。また、真のポイントクラウドとして描画するためには、3次元座標での色情報も取ってくる必要があるため、もっと処理は重くなります。

目標

そこで、私はC# で直接KinectのAPIを叩き、ポイントクラウドの情報をバイナリファイルとして保存してから、後でUnity上で描画する手法をとります。

ついでにただのポイントクラウドだけではなく、Kinectが得意な人領域抽出も組み合わせて人間のポイントクラウドを作ってみます。

アプローチ 

Kinectでは1種類のセンサに対して1つのFrameReaderが対応し、FrameReaderにイベントハンドラを登録することで、センサからのデータを処理します。
しかし、深度センサ、カラー画像など複数のデータを扱う場合にはひとつひとつFrameReaderをメンバとして保持し、それぞれにイベントハンドラを登録する必要があり非常に面倒なコードになってしまいます。
そんな時には 

gista66e54a0aad21d13dd6f

のように書くことで、複数のデータソースをひとつの関数で処理することができます。
FrameSourceTypeではDepth, Color, Bodyがそのまま深度、カラー、骨格に対応し、最後のBodyIndexが深度情報( 512 x 424 )のうち、どこが人の領域かという情報を与えてくれます。

毎フレームごとの処理の概略は以下のコードのようになります。

giste7073853191278fc1de6

それぞれのフレームからデータを読んで配列なりに格納するだけです。
そして次に深度画像を走査して人領域の座標と色を見つけます。

gist54b128d930b1e554b956

上のように, 深度画像を人領域画像でフィルタリングすることで、リアルワールドでの座標とその色を習得できます。
以上の処理で得られた点群を配列などに適当に格納し、シリアライズするとUnityでも扱えるデータになるでしょう。
ただしこの際には.net 3.5以前で使える基本的なデータ型としてシリアライズしないとMono環境でのデシリアライズに失敗しやすいことに注意しましょう。
Unityで描画するさいはこちらの記事のようにParticleSystemを使うか、愚直にSphereを作って色を塗るのが良さそうです。

実験

できたのがこんなポイントクラウドです。

しっかり服の皺まで再現されていることがわかりますね。 

裏から見るとハリボテになっていることがわかります。

近づいてみます。

きもちわるい。。。

結果・今後の展望

Kinect v2を使って人間の3次元スキャンをし、それをポイントクラウドとして表現することができました。
Kinect 1台だとハリボテが限界ですが、複数台使うか、あるいは人間が回転して数フレーム分記録することで、背中側のモデルも構築できそうです。
また、毎フレーム異なるポイントクラウドを描画することでアニメーションにもできますが、全身で数万個の点群になるためフレームレートを落とすか点群を適当に間引きする必要がありそうです。 

まとめ

以上、KMCアドベントカレンダー2014 13日目の記事でした。
明日はohaiさんによる"京大周辺のランチ"だそうです。生協の食堂は飽きたけど野菜をちゃんと採りつつ美味しいものを食べたいという怠惰な私にも嬉しい記事になりそうですね？

KMCM

KMCこと京大マイコンクラブでは「KMCアドベントカレンダーに参加したい!!」方を募集しています。KMCには入部制限はありません。年齢や学歴、人種、宗教、信条、性別、社会的身分、門地、国籍、経験などは不問です。また活動に関する制約もありません。IRCのチャット越しに会話に参加することだけでも大丈夫です。詳細は下記Webページを御覧ください。 

OUCCM

OUCCでは優秀なラボ畜候補生を募集しております. まいにち進捗たのしい研究！