#IkaLog によるスプラトゥーンの画像解析と機械学習
•
8 likes•17,393 views
https://nsstudy.connpass.com/event/42602/ 「ディープラーニングとGPUコンピューティング」＆「スプラトゥーン画像解析」 #NSStudy 9 対バンが NVIDIA さんでした。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to #IkaLog によるスプラトゥーンの画像解析と機械学習
Similar to #IkaLog によるスプラトゥーンの画像解析と機械学習 (20)
More from Takeshi HASEGAWA
More from Takeshi HASEGAWA (20)
Recently uploaded
Recently uploaded (9)
#IkaLog によるスプラトゥーンの画像解析と機械学習
- 2. 2004 | 2011 2011 | 2014 2014 | SEサービス プリセールス @ So+ware Research Associates, Inc. システム構築、客先のシステム運用、提案でキャリアをスタート → プリセールス〜PMを担当するインフラエンジニア システムアーキテクト @ Trigence Semiconductor, Inc. 、ほか エンベデッド開発支援、ITシステム管理、機械学習支援まで 多岐に対応 セールスエンジニア @ Fusion-io, Inc. 高速半導体ストレージ ioDrive / ioMemory シリーズの SE として活動
- 5. 様々なステージとルール • １６のステージ、４つのルール • 勝利に向けチームで立ち向かう 多様な楽しみ方 • 90以上のブキから好きなものを 選んでプレイ
- 6. シューティングゲームの一種 – 第三者視点(TPS） スプラトゥーンの特徴 – 自分たちの“ナワバリ”を広げないと進めない – 「銃」タイプ以外に「バケツ」「ローラー」など、様々なブキがある 様々なプレイ層 – 小学校（クラスで半分がスプラトゥーン所有）〜大人まで – 塗らないと勝てない （“相手を倒す”ことが最終目的ではない） – 本気でやってる人たちは怖い
- 16. • IkaLogユーザのひとり @fetus_hina さんが開発、 運営する Web サイト • IkaLog からのプレイデータを受け取り、 表示・集計する • IkaLogからの投稿を分析し 統計情報、トレンドを表示
- 21. https://stat.ink/ ナワバリバトル – 互いの干渉が少ない ガチエリア – “相手を倒しつつ生存”がカギ ガチホコ – 全体的に乱戦になりやすい ガチヤグラ – 全体的に乱戦になりやすい
- 26. • 2014年INTEROPでの”Chainer”デモがきっかけ – 深層学習のプレゼンテーションみて「凄いな」と思った – “何か面白いソフトウェアを作りたいな” – ちょうどスプラトゥーンの発売直後だった • 未経験からのチャレンジ – OpenCV経験 3時間ぐらい – 機械学習／ディープラーニング経験 なし
- 28. 0" 2" 4" 6" 8" 0" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" Kill Win/Lose Win" Lose" 0" 1" 2" 3" 4" 5" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11" Death Win/Lose" Win" Lose" 0.0%$ 2.0%$ 4.0%$ 6.0%$ 8.0%$ 10.0%$ 12.0%$ 14.0%$ *5$ *4$ *3$ *2$ *1$ 0$ 1$ 2$ 3$ 4$ 5$ K*D
- 32. 32
- 34. 34
- 35. • ゲーム中で使われているフォントは２種類 – 画面上に現れる数字フォントは１種類 – フォントが判っているのだから、認識できるはず • 試行錯誤の後、既存OCRエンジンの利用は断念 – 機械学習ベースの認識エンジンを実装
- 38. • GitHub にソースあり – https://github.com/hasegaw/opencv_knn_example/ • 三つのパターン ○ △ □ で画像を生成し、 kNNで学習する • ランダムに ○ △ □ から画像を生成し、その画像 の種類を判定する – KNN を用いてそれに近い画像を見つけ出す – 見つけた画像の種類から、問題図形の種類を特定
- 45. • 基本は数字の認識と一緒 • 認識率はそれほど高くないが、認識回数で精度を確保 – IkaLogは現在毎秒10フレームほど解析している – 下記例では、死因のメッセージ合計49fを解析し、 最多頻度は96gal_deco (18f, 36%) だった → 結果的に正解 votes={ 'supershot': 6, 'carbon_deco': 1, 'bucketslosher': 1, 'octoshooter_replica': 1, 'splashshield': 1, 'sshooter_collabo': 5, 'hotblaster': 2, 'pablo': 1, 'nzap89': 6, 'sharp_neo': 3, 'hotblaster_custom': 2, '96gal_deco': 18, '52gal': 1, 'hokusai': 1 }
- 47. 47
- 52. 52
- 56. 56
- 62. • 機械学習／深層学習の精度は前処理の精度に影響を受ける • 画像のズレ／ゆがみ対策（自動補正）を実装し、対策 テンプレートマッチング、最小二乗法を用いて最適候補を選定 アスペクト比が壊れている なぜか画像がズレている リファレンス 分類に 使用する画像
- 63. Thanks @itoooon
- 67. • 入力値と出力値 – 入力値： RGBもしくはHSVの色情報 (47*45*3=6,345 units) – 出力値： 各クラスの出力値（91 units, So+maxを適用する） – 使用する結合：全結合のみを使用（理由は後述） – 目 的：特徴量の自動生成 • 今回の用途であれば、深層学習で特徴量を自動的に見つけ出せるはず • 各ブキの背景色の重みが自動的ゼロに調整されれば、背景色への考慮も不要 – 目標性能値 • 目標性能値: 91クラスのマルチクラス分類が350ms未満（画面１枚あたり3秒以内） • stat.ink の投稿データに対して99.99%の精度
- 69. 69
- 70. • Azure ML上でアルゴリズムの事前検証 – 小さなデータセットを使用し分類器を作成 – 入力層: ピクセル情報（をPCAにかけたもの） – 隠れ層: 1層、150ユニット（暫定） – 出力層: 各クラス（のはず） • この方針でトレーニングすれば、精度が高い分類器を 得られるだろうと判断 – 特に何も考えなくても９８％以上の精度が得られた – 各種ボケ画像も、おおよそ問題なく判定できた
- 72. 72
- 73. • Azure MLで得た結果をベースに、IkaLogに組み込む モデルを作成する – stat.inkに投稿された90万点のブキ画像を教師データとして用意 – フレームワーク「Chainer」を使用 – GPUの恩恵も受けられる • 学習したモデルの配布用フォーマット – float32 → float16に変換 – 配布するモデルファイルのサイズが半減
- 74. CPU GPU # of jobs Throughput (images/s) GPU Time /epoch (s) RelaJve perf. (virtual) Core i7-4790S 定格3.2GHz 使用せず 1 3,928 234.5s 1X Core i7-4790S 定格3.2GHz GeForce GTX760 1 10,371 39.2s 5.9X Core i7-4790S 定格3.2GHz GeForce GTX760 4 (bl) 15,988 25.8s (103 / 4) 9.0X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (bl) 30,320 6.25s (25.0s / 4) 37.5X ※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。 ※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。
- 75. 75 目的と手段が入れ替わる瞬間
- 76. 76
- 77. 77
- 78. CPU GPU # of jobs Throughput (images/s) GPU Time /epoch (s) RelaJve perf. (virtual) Core i7-4790S 定格3.2GHz 使用せず 1 3,928 234.5s 1X Core i7-4790S 定格3.2GHz GeForce GTX760 1 10,371 39.2s 5.9X Core i7-4790S 定格3.2GHz GeForce GTX760 4 (bl) 15,988 25.8s (103 / 4) 9.0X Core i7-4790S 定格3.2GHz GeForce GTX 1080 4 (bl) 30,320 6.25s (25.0s / 4) 37.5X 2X E5-2630L v3 定格 1.80GHz Tesla P100 4 (bl) 65,811 2.5s (10.3/4) 93.8X Special Thanks to ※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。 ※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。 自宅の Linux Box
- 79. パラメータチューニングのための事前学習ジョブ – 様々な隠れ層の構成（パーセプトロン数）で学習を行い、 モデルファイルサイズが小さくなるような構成を探索 – 4ジョブ同時投入（バッググラウンドプロセス化→ wait） – ジョブ実行開始 03:08 〜 終了 18:28 （実行時間 15時間20分） 最終的な学習速度 – 550エポック/24時間 ※ ファイルシステム書き込みへのモデルデータ書き込み、各エポックの Test / Cross Validadon テストの所要時間を含む – 第一弾として第617エポックの重みを採用 → 21GB のデータ・セットを用いて、数時間の作業、約48GPU時間で学習した Special Thanks to
- 80. K近傍法 既存ImageNet 新ニューラルネット 認識効率 一部ユーザでは 低い 99.99+% 99.99+% モデルサイズ 20MB（現時点） 400MB (AlexNet) 100MB (GoogleNet) 14MB (Float32) 7MB (Float16) 分類にかかる時間 @ IvyBridge 2GHz とても高速 ~300ms ~20ms • 既存のImageNetよりも高速、 より小さなモデルデータ（配布物） • 従来のIkaLogよりも高い認識精度を実現 Special Thanks to
- 82. • ニューラルネットを他の用途にも適用 – ブキ分類器のほか、ギアパワー分類器を作る（優先度 高） – ガチホコのタッチダウン分類器を作る – 戦況評価関数にRNNが使えるのではないか • 本当に必要なデータセットの選定 – 21GBのデータセットには大量の重複データが含まれている – 重複データをうまく取り除くと学習時間、効率ともに メリットがあると考える – PCA-based anomaly detecdon が使えそう
- 84. • IkaLogでは、複数の機械学習アプローチを適用している – リアルタイム処理では、おもにK近傍法(KNN)を利用 – 入力画像にロバストな分類器を作るため、深層学習を利用 • 特徴量の自動抽出、何十万の画像から自動的な学習 • IkaLogとディープラーニング – Windowsアプリケーションにそのまま組み込めるような 深層学習のフレームワークは限られている – しかし、関数や機能を限定すれば、比較的容易に実装可能 – 学習には既存の深層学習フレームワークやGPUを活用
- 85. らぴす (2000-2014)
- 86. © 07strikers