https://arxiv.org/pdf/1705.03098.pdf
画像から3次元の関節を推定する論文。ただし、入力は画像ではなく2次元の関節座標で、そこから3次元の関節を回帰する。
2次元から3次元へのマッピングをDNNとして学習する手法は、これまでにも提案されてきているが、それらに共通するのは、3次元座標を2次元（画像や関節座標）から直接推定することはそもそも困難という認識である。本論文では、Dropout、Batch NormalizationとReLU、Redisual Connectionを用いたシンプルなDNNにより、SOTAな手法に負けない精度で3次元座標の推定が可能であることを示している。
3次元の関節座標へ変換するを定義し、変換後の関節座標と正解関節座標の差を最小にする
を求める。
は、DNNでモデル化し、次の図のような構成を提案している。
図には書かれてないが、二つのlinear layerが入力直後と出力直前に存在し、また図のブロックは二層存在するので、linear layerは合計で6となる。学習パラメータ数は4Mから5M。
Residual connectionsを設けることで、エラーが10%も低下した。
Linear-ReLuとResidual connectionsを用いたシンプルなネットワークの場合、2次元座標のGTで学習すれば良い精度を得られるが、 detectorの2次元座標で学習した場合や、2次元座標のGT で学習してdetectorの2次元座標で推論した場合には精度低下が見られた。Batch normとdropoutを併用することで、これらのケースでの精度を改善することが出来た。
Batch normと組み合わせて、各層の重みのノルムの上限を1.0に正規化することで、汎化性能の向上が見られた。
学習時のハイパーパラメータは表のようになっている。
| epochs | 200 |
| optimizer | Adam |
| learning rate | 0.001 (exponential decay) |
| Initialization | Kaiming initialization |
評価に使ったデータセットは、Human 3.6MとMPII。Human3.6Mはその名の通り、3.6millionの画像があり、2d / 3d jointsやカメラパラメータのground truth を含む大規模なデータセット。一方のMPIIはもう少し小規模。
Linear-ReLu + Batch norm + Dropout + Residual connectionのシンプルな基本構成で、既存手法を超える性能を達成しているのは驚き。論文タイトルにもあるように、これらからの研究のベースラインになる（改善が色々とできそう）手法だと思われるし、detectorの2次元座標があれば手軽に3次元座標が得られるので、応用もしやすそうである。
以前、ナンバープレート認識モデルを参考にして、ロゴ認識CNNを作りました。
前回のモデルは独自モデルだったのと、物体候補領域はSelective Searchで実行していたため計算時間が大きかったので、one stageで標準的なモデルを使用するように変更してみました。
Tensorflow Object Detection APIにあるSSDモデルで、Flickr Logos 27 datasetを学習してみたところ、割と簡単にロゴ検出ができました。
検出した結果を見ると、誤検出はない一方で、未検出が結構多い印象です。領域サイズが小さかったり、向きや傾きが大きい場合に未検出が増えている様子なので、Data augmentationを見直すなどは必要になる感じですね。
CNNの中でもよく使われるアーキテクチャの一つであるGoogLeNet。GoogLeNetの層を構成するのがInceptionで、今までにv1からv4までの改良が行われていて、またresidual blockを導入したinception-resnetも提案されています。
Mediumの解説記事を参考に、基本となるGoogLeNet（V1）とKerasなどのフレームワークでもよく使われるV3を簡単にメモ。
A Simple Guide to the Versions of the Inception Network | by Bharath Raj | Towards Data Science
Inception V4の論文では、以下のように定義されているので、ここでもそれを参照します。
# The total loss used by the inception net during training. total_loss = real_loss + 0.3 * aux_loss_1 + 0.3 * aux_loss_2
42層のモデルで、GoogLeNetに対して2.5倍程度の計算コストで、Top1 errorを5.6%ほど改善している。
例えば、ファイルに含まれる数の合計を計算する場合。
int DoSum(const std::string& file);
ファイルに含まれるのが正の値だけであれば、負の値でエラーを示すことができるが、正も負も含まれる場合には適用できない。
int DoSum(const std::string &file, int &sum) { /* return value of zero indicates a sum has been computed other values indicate an error status */ }
struct ReturnData { int sum; int error_indicator; }; struct ReturnData DoSum(const std::string &file) { }
int DoSum(const std::string &file) { /* do calculations */ if (error_has_occurred) throw some_appropriate_exception(); else return calculated_sum; }
1と2の場合、エラーが致命的でなければ呼び出し側で何もする必要がない一方で、エラー処理をしなくても動くので変な結果で処理が進んでしまうことがある。 3の場合、例外をcatchしなくても処理が異常終了するので変な結果が処理が進むことはないのに対し、この関数を使う全ての呼び出し側でcatchして適切に扱うようにしないといけない。
Googleのコード規模でということなので、自分たちのサイズで考える必要がありますが、既存のコードに対して、例外を導入するコストが高いので、 Google C++ Style Guideでは例外は使わないとしています。 ただ、自分たちの問題で考えてみても、関係する全てのコードで新しく例外処理を実装するのはやはり大変なので、1か2を使うことが多い印象です。
NEVER LOST AGAIN グーグルマップ誕生 (世界を変えた地図)
中の人による、キーホール起業からグーグルによる買収、グーグルマップとグーグルアースの成功に向かう物語が書かれた内容は、とても興味深いものでした。個人的なハイライトは、ストリートビューがグーグル内部で始まった当時の描写と、グーグルマップを他社の地図データから自社データへと切り替えることになったGround Truthプロジェクトの章でした。
後にストリートビューとなるプロジェクトを担当していたのは、2004年に入社したLuc Vincent氏。入社した時は、グーグルブックスのチームに所属して世界の書籍をスキャンするタスクを担っていたが、ラリー・ペイジとのミーティングで構想を聞き、スタンフォード大学のMarc Levoy教授と既に始めていたストリートビューをリードする役割を任されたらしい。
最初の検証では、ラリー・ペイジがセルゲイ・ブリン、マリッサ・メイヤーとドライブしながら助手席でビデオカメラを回して撮った映像！を使ったようだが、Vincent氏はスタンフォード出身のエンジニアとインターン生とともに、撮影車両プロトタイプと360度画像をつなぎ合わせるソフトウェアツールを作り、撮影を行っていた。
何のロゴマークも書かれていない深緑色のシボレーのバンの上にはコンピュータ、カメラ、レーザーセンサーの複合体が取り付けてあり、時速16㎞以下のスピードで走行した。それ以上の速さだと撮影した画像がブレ、使い物にならないのだ。バンから何回か煙が上がったため、電力の安定供給のために今度はホンダのガソリン発電機も屋根に取り付けた。
このプロトタイプでは数々の問題が起こっていたようだが。
この撮影車両の性能は、驚くほど当てにならなかった。毎日、チームがその日の撮影作業を計画し、すべての機器を慎重につないで走行の準備を整える。そうしてインターン生がバンを走らせるのだが、毎日、１時間ほどでコンピュータがクラッシュしたり、他の不具合が起きたりして作業が中断した。少し走ってはマウンテンビューに連絡を入れ、母船に戻って何がうまくいかなかったかを調査するということの繰り返しだった。
それでも、2005年の夏頃には、マウンテンビューとパロアルトの撮影データセットを構築し、グーグルマップと統合したデモを完成させ、正式なプロジェクトに昇格。その後は、2007年にストリートビューがアメリカ5都市のみ対応でローンチされ、自動運転のチームも加わった2007年の終わりにはアメリカ中の道路600万マイルのうち100万マイルを走破するまでになった。
グーグルマップとグーグルアースが大ヒットするのに伴い、地図データのライセンス料の問題が無視できないものになっていた。
グーグルの地図プロダクトの爆発的な人気に伴い、地図データのライセンス料は急騰していた。その中でも最も高額だったのは交通網のデータベースだ。この業界は2社が市場を占領している。オランダに拠点を置くテレ・アトラスとアメリカのナブテックだ。
問題はライセンス料が高いということだけではなく、データをどう使うかまで制限されていたことだという。
彼らは毎年グーグルが支払うデータの利用料金を決定し、またグーグルがどのようにデータを使っていいかを指示していた。ナブテックとテレ・アトラスは、豊富な利益が得られるナビゲーション端末市場に影響がでないようにしたいと考えていた。彼らにとってパーソナルナビゲーション端末を何十億台と販売しているガーミン、トムトム、マゼランとのビジネスの方が重要だった。
当然、とはいえある意味無謀な、自分たちの交通網地図を作る方向に舵を切ることになる。それが、ストリートビューの画像から画像認識技術で交通データを抽出し、全世界の交通網の情報を書き出すプロジェクト「Ground Truth」。
このGround Truthのために内製したのが、地図作成ソフトウェアのアトラスで、2013年のGoogle I/Oでスクリーンショットと合わせて紹介されている（下記リンク参照）。アトラスでは、空中写真、衛星写真、ストリートビューの画像と、画像認識で自動抽出した道路標識や住所などの道路に付随する情報など、グーグルが持つ特定地域に関する全ての情報を1つの画面で見ることができる。さらに、例えば道路の両側で同じ進行方向の車が撮影されている画像があれば、アトラスがその道路を一方通行であると推測する機能も持っている。ただし、最後は、人間のオペレータがアトラスの解析したデータを確認し、修正して、正確な情報として公開する承認をする。
Google I/O 2013 - Project Ground Truth: Accurate Maps Via Algorithms and Elbow Grease - YouTube
2009年末には、利用料もなく、使用制限もない、グーグル製地図データへの切り替えが行われた。
ユーザを第一に考え、世界の地理情報を整理してアクセス可能にするため、必要なリソースにちゃんと投資し、何十億というユーザが使う現在のグーグルマップを実現してきた裏側は、とても面白かった！
自社製地図データへの切り替えによって、使用用途制限がなくなったことにより、モバイル版グーグルマップで音声道案内が実現されたということを知ると、最近のグーグルマップの地図データ切り替えも、次の新しいユーザ体験の布石かもしれないと思うと、楽しみでなりません。
最近、YoutubeでライブのPV見て、そこについてるコメントを見てなんか書いてみたくなった。
2005年に解散したスーパーカーは、自分の青春時代そのものだった気がする。当時はまだネットが一般的に使われる前だったし、スマホなんてものは当然なかったから、とにかくインタビューが掲載されている雑誌があれば購入し、スペシャで特集が放送されればビデオに録画して、頑張って東京までライブ見に行ったりしていた。
解散ライブも幸運にもチケット取れて、もしかしたらファーストアルバムの曲やらずに解散あるかも？と心配して行ったけど、creamsodaとかLuckyとか見れて最高に感慨深かった。まあ、MCゼロで歌声以外に声を発することなく終わって、しかもアンコールはなしだったのは、やっぱそうかーと思ったな。
スーパーカーは色々と変わったバンドだと思うんだけど、変わったエピソードといえば、このようなものを雑誌とかで読んだような気がする。でも、本当なのかどうかはわからないけど。
そういえば、解散した後だったか、スーパーカーのラジオ「オールOK」が一夜限りで復活して、そのときに質問募集してたので、ネットで質問送ったらなんと採用されたという！それで、どう使っていいか分からない鉛筆みたいなのが送られてきたんだよね。でも、当時は会社の寮に住んでて、ラジオが聞けない環境で、どういう風に答えてくれたのか分かってないんだよなぁ... どこかに音源ないだろうかなぁ。
