View
30.296
Download
1
Category
Preview:
Citation preview
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
(ver.1.3) Nov 26, 2015 @サイボウズさまオフィスにて Takeshi Hasegawa (@hasegaw)
本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物からの引用です。
@hasegaw is 誰 長谷川 猛 (HASEGAWA Takeshi) twitter: @hasegaw Ø もともと、インフラエンジニア(2004-2011)
SEとしてシステム構築、客先のシステム運用、提案 気付いたらプリセールス~PMを担当するインフラエンジニア (ざっくりデザイン、工数/導入物品見積もり、 構築プロジェクトの管理、保守等の問い合わせ対応)
Ø フラッシュストレージを軸とした、アプリケーション高速化を支援するセールスエンジニア(2011-2014)
Ø ファブレス半導体ベンチャーでコンピュータ関連なんでも
2
記事紹介(?)
4
下記2本の記事(40ページ強)が まとめて収録されました。 ISBN: 978-4774177823 価格: 2,786円 • Software Design 2014/10
第二特集 サーバの目利きになる方法 前編
• Software Design 2014/11 第二特集 サーバの目利きになる方法 後編
スプラトゥーンとは
• 第三者視点(TPS)のシューティングゲームの一種
• インクで自分たちのナワバリを広げないと進めない
• シューティングが苦手でも バケツやローラータイプのブキで気軽に楽しめる
• 本気でやってる人たちは怖い
6
プラガブルで様々な使い方に対応
15
録画ソフト 自動制御
AmaRecTV
カラーLED連動
Fluentd 転送
スプラトゥーン戦績記録SNS
CSV/JSONファイル保存 スクリーンショット保存
SNS投稿
IkaLog
Embeded IkaLog (ライブラリモード)
• IkaLog 自体が Python モジュールとして実装されている
• Python コードから IkaLog を実行して、情報を受け取れる
• 作ってみたアプリケーションの例
16
アプリケーション 説明
IkaRename.py スプラトゥーンのビデオを分析 ステージ/ルール/勝敗のついた ファイル名にリネームする
IkaClips.py スプラトゥーンのビデオを分析 敵を倒した/倒されたシーンだけクリップし、 “忙しい人”向けのサマリムービーを生成
IkaLog が出力するデータの複雑化(1)
17
IkaLogの当初のスコープ ・ステージ/ルール検出、勝敗(2択) ・スクリーンショット保存
追加された検出内容 ・目標(ガチホコ/ガチヤグラ)の位置検出 ・プレイヤーの死因(凶器)検出 ・時系列のスコア検出 ・プレイヤーのランク、所持金などの数値検出 ・全プレイヤーの生死ステータスのモニタリング ・ロビー(パブリック/プライベートタッグ)検出 今後追加する(かもしれない)検出 ・コミュニケーション検出(ナイス/カモン) ・スペシャル蓄積・利用検出 ・目標に対するチームのイベント
IkaLog が出力するデータの複雑化(2)
18
{'time': 1442394550, 'result': 'win', 'rule': 'ガチホコバトル', 'event': 'GameResult', 'map': 'モズク農園'}
{'rank_in_team': 2, 'weapon': 'デュアルスイーパーカスタム', 'result': 'win', 'kills': 1, 'time': 1444491154, 'cash_after': 1820744, 'players': [{'rank_in_team': 1, 'weapon': 'プライムシューター', 'kills': 2, 'deaths': 1, 'udemae_pre': 'B-', 'team': 1}, {'rank_in_team': 2, 'weapon': 'デュアルスイーパーカスタム', 'kills': 1, 'deaths': 0, 'udemae_pre': 'B', 'team': 1}, {'rank_in_team': 3, 'weapon': 'プライムシューター', 'kills': 1, 'deaths': 0, 'udemae_pre': 'C+', 'team': 1}, {'rank_in_team': 4, 'weapon': 'スプラシューターコラボ', 'kills': 1, 'deaths': 0, 'udemae_pre': 'B-', 'team': 1}, {'rank_in_team': 1, 'weapon': 'ジェットスイーパーカスタム', 'kills': 1, 'deaths': 2, 'udemae_pre': 'C', 'team': 2}, {'rank_in_team': 2, 'weapon': '3Kスコープ', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B-', 'team': 2}, {'rank_in_team': 3, 'weapon': 'プロモデラーRG', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B-', 'team': 2}, {'rank_in_team': 4, 'weapon': 'ダイナモローラーテスラ', 'kills': 0, 'deaths': 1, 'udemae_pre': 'B+', 'team': 2}], 'rule': 'ガチホコバトル', 'event': 'GameResult', 'deaths': 0, 'udemae_pre': 'B', 'map': 'アロワナモール', 'team': 1}
GitHub イニシャルカット時の IkaLog が出力した戦績ログ (JSON)
近の IkaLog が吐く戦績ログ (JSON) ※本当はもっと色々出せる
→ 情報量の増加に伴い分析基盤の構築が必要
IkaLog + stat.ink のDAU、処理ゲーム数
26
データソース hJps://stat.ink/enLre/users
【ピーク】 130ユーザ/日
5,500ゲーム/日を分析
毎日 約70ユーザが利用 24時間あたり2000ゲーム前後を処理
エコシステム
27
ユーザー
開発者
hasegaw/IkaLog
stat.ink
ダウンロード
記録 送信
hasegaw
一部データ (QA用)
開発、 stat.inkデータに よる機械学習
Windows版 実行ファイル生成
(本スライド中の画像の一部はイメージであり実際のものとは異なります。)
PR
モ ツ 鍋
IkaLog開発の経緯
• スプラトゥーン プレイヤー同士で モツ鍋を食べていたら、戦績の統計の話に
• ゲームには、戦績の統計機能は存在しない
• 手動でExcelを使い戦績を整理している人も
29
とあるイカの戦闘記録
32
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
スプラトゥーン プレイヤーにとっての 主なメトリック
• どのステージが得意か?苦手か?
• どのルールが得意か?苦手か?
• どのブキが得意か?苦手か?
• どのブキにやられやすいか?
• どれぐらい突進していいのか?し過ぎなのか?
33
ツールを作ろう(検討編 1)
720p 1プレイ分の動画を相手に検討開始
• 非圧縮 5分 → 20GB
OpenCV のテンプレートマッチングで試行錯誤
• 判ったこと:使えなそう – 誤検出が多い
– マッチングアルゴリズムが遅い
34
ツールを作ろう(検討編 2)
• もっと単純な方法で画像をマッチングする – スプラトゥーンのシステムメッセージは ほとんどが、決まった位置に白色で表示される
– 文字部分だけが黒く、残りが白い画像を加算し、加算した後の画像のヒストグラムで判定する
– 基本的に足し算、引き算で実現できるため 非常に高速に処理できる
– 画面が真っ白なときに誤動作
→もともと白い画像は無視する 35
IkaLogの画像マッチング (第二・三世代)
• 第二世代 – 「前景が白」だけでは他の場面で誤認識するケースが 増えてきた
– 「背景が黒」「背景が白以外」のどちらかを 指定して、条件以外のドットが多ければ False-Positiveと判断できるように拡張
• 第三世代 – 「前景がオレンジ」「前景が黄色」などを認識したい ケースがでてきた
– 前景・背景ごとにHSV色成分などをして条件通り・ 条件以外のドットを検出できるように拡張
37
数字の認識
• ゲーム中で使われているフォントは2種類
• 画面上に現れる数字フォントは1種類
• フォントが判っているのだから、 認識できるはず
• 試行錯誤の後、既存OCRエンジンの利用は断念
• 機械学習ベースの認識エンジンを実装 41
既存OCRでの問題点
• Tesseract OCRを評価 – 認識率が安定しない
– もともと文章を読み取るためのもの
– 1~2文字の文字、数字の認識は苦手
– 0, 8, 3 などを間違えることがある
– Python 3.x のスクリプト上から 利用しづらかった
• 既存の文章向けOCRエンジンよりも 単純で目的に適した認識方式を検討
42
文字として 認識されないことも
kNN(K近傍法)の考え方
43
● ● ●
●
■ ■
■ ■
? ▲
▲
▲
▲
?
?
?
?
とてもシンプルな機械学習 標本 の傍にあるサンプルがどれかで 分類する。 K=1 の場合は 寄りのサンプルがある クラスに分類される。 K=3 の場合は近くに3つのサンプルがある クラスに分類される。
kNNによる図形マッチングの例(1/2)
• GitHub にソースあり – https://github.com/hasegaw/opencv_knn_example/
• 三つのパターン ○ △ □ で画像を生成し、 kNNで学習する
• ランダムに ○ △ □ から画像を生成し、その画像の種類を判定する – KNN を用いてそれに近い画像を見つけ出す
– 見つけた画像の種類から、問題図形の種類を特定
44
KNNで見つけた「一番近い文字画像」で 画像を置き換え(1/2)
• 各日本語フォント文字をPNG形式に変換
• 上記データをKNNで学習
• 画像を入力しグレースケールに変換
• 画像を文字サイズにあわせて分割、KNNで各領域にもっとも近い文字フォントを調べる
• 画像を文字に置き換え
46
数字の認識 1)画面上の数字部分(位置固定)を切り抜き
2)縦・横のヒストグラムを生成し各文字の位置を特定
3)文字を検出用サンプルのサイズ(等幅)にリサイズ、 二値化
4)KNNにより既知の検出用サンプルと照らし合わせて 認識する
49
死因の認識
• 「数値が認識できているから、 死因もなんとかなるだろう」
• 数字認識との共通点 – 目的の情報が白色なので二値化しやすい
– 文字列の位置を特定し、切り抜きできる
• 数字認識との相違点 – アニメーションにより、常にサイズが変化
52
死因の認識(3) • 基本は数字の認識と一緒
– 1文字単位ではなく文字列を一組として処理
– 文字列は左寄せして処理(したほうがいいのかはよく判っていない)
• 認識率はそれほど高くないが、認識回数で精度を確保 – IkaLogは現在毎秒10フレームほど解析している
– 下記例では、死因のメッセージ合計49fを解析し、 最多頻度は96gal_deco (18f, 36%) だった → 結果的に正解
54
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 }
スプラトゥーンのブキ
• スプラトゥーンでは、50種類を超えるブキから 好きなものを選んで利用できる
• 全体的にバランスが取れているゲームだが 戦略や戦術、ブキの選択で優劣が発生する
• 分析したい -> 画像認識
56
画像判別においてのチャレンジ
• ブキ画像が小さい(47x45ドット・外枠込み)
• 表示条件(背景・被る画像)が変わる
• 誤判定すると後の統計結果に多大な影響が出る
• 一回の判定に使えるのは画像1枚のみ
58
他の装備品が被っている 保護色(まだマシ) 保護色(マジつらい)
ブキ認識アルゴリズム(第1~3世代) 世代 特徴、利点 課題
-‐ すべての正解画像を保持しておき、 入力画像を比較
第三者著作物のデータをそのままデータに含めて配布する必要があった
第1世代 画像の色相ヒストグラムを特徴量とした 統計的手法(のちにK近傍法へ切替)。
認識率 80%以下
第1.5世代 第一世代の特徴量のまま、分類アルゴリズムをKNNに切り替え
認識率が若干悪化
第2世代 (現在)
特徴量を色相ヒストグラムから”画像の複雑さ”に変更 ・ラプラシアンフィルタなどを通して画像の特徴量を算出 ・開発環境で99.99%〜の精度を実現
ユーザの環境(デバイス、設定差異、設定ミス)により認識率が大幅低下
第3世代 CNN(畳み込みニューラルネットワーク)を利用した深層学習 stat.ink投稿データで99.97%以上の精度を実現
分類処理に要するCPU時間 学習データのサイズ、配布方法
59
第2世代 ラプラシアンフィルタを用いた特徴量の算出
62
入力画像 ラプラシアンフィルタ適用
グレー スケール
輪郭情報 特徴量画像 (合計64ドット)
→ 課題が浮かんできた • キャプチャデバイスの画質特性により特徴量が変化する • WiiUの出力解像度 (720p/1080p) により、
特徴量に差異が生じる • ユーザがキャプチャ関連ソフトでWiiU画像を間接取り込みし
本来のWiiUの信号とは異なる解像度、オフセットで入力され、 特徴量が変化する
Thanks @itooon
第3世代 ‒ 深層学習によるブキ判定
• CNN を用いてブキ画像を学習(AlexNet, GoogleNet)
• Caffeで動作確認後Chainerベースで再実装 – IkaLogが使うPython3ではCaffeが利用できない
– WindowsでのCaffe利用が難しい
– Chainer on Python3ではCaffeモデルが利用できず、 Chainer + Python3 で改めて実装、学習
68
Thanks @itooon
第3世代 ‒ 深層学習によるブキ判定
• 驚異的な正答率 – 様々なユーザが投稿した数万ブキ画像の クラスタリングでほとんどミスなし(30件以下)
• 学習はGPGPU必須、マッチングはCPUも可 ~300ms(CPU)
~200ms(CPU w/Intel MKL)
~50ms(GPU) 程度
8枚の画像が3秒以内に認識できれば十分現実的
69
Thanks @itooon
第3世代 (CNNベース) ユーザ環境への導入に向けての課題
• モデルデータの肥大化が課題 400MB~ (AlexNet)
100MB (GoogleNet) ←→ 1MB (KNN)
配布方法は?コスト対効果は?
• CPU性能が確保できない場合は? – Core2世代などの非力なプロセッサの場合
– ストリーミングソフトウェア、 ソフトウェアビデオエンコーダとの共生
70
第3世代 (CNNベース) 機械学習への利用
• CNNベースのほうがKNNベースより正答率が高い – KNNベースの教師有り学習は手作業での分類などに手間がかかる
– KNNの教師有り学習にCNNの分類結果を利用できれば手作業を減らすことができる
• CNNでユーザーの投稿データを分析し、 KNNのモデル生成に活用することも検討
71
Webcamサポート
• HDMIキャプチャデバイスを持っている人は少ない – ゲーム実況をするニコ生主などなら 持っているが…
– 新たに購入しようとすると、約2万円の投資
• HDMIキャプチャの代わりにWebカメラを利用できないか?
73
Webcam サポート(イメージ)
74
1) TV、ディスプレイに Webcam を向ける 2) WiiU のホーム画面を表示
3) IkaLog で Webcam を介して ワープ キャリブレーション 4) 以後 IkaLog は画面と認識した範囲に対して処理を行う
Webcam経由の入力状況
• 「既知の画像」(WiiU ホーム画面)を 画面上に出して、キャリブレーション
• 720p (1280x720) の画面を ±5pxぐらいの精度で取り込める
• 白色が (255,255,255) にならないため 何らかの対策が必要 – カラーバランス、ガンマ調整
– IkaLog 内の画像検出のスレッショルド変更 79
Webcam 対応の課題点と これまでに得られた知見
• もし、このような「変な使い方」をするときは 自動調整機能をオフにできるWebcamがオススメ – カラーバランスが固定できること
– コントラストが固定できること
– オートフォーカスをオフにできること
• プラズマTVは明るすぎて Webcam の ダイナミックレンジが追いつかない? EL液晶は?
• 新しめのスマートフォンのカメラも非常に優秀
80
よさそうな WebCam の一例
81
Logicool の Webcam はカラーバランス、コントラスト、フォーカスを 固定できるのでこのような用途に向いている(アキヨドで試して購入した)
ただし上記の固定機能は Windows 専用。 Mac では実装されていない(怒
まとめ
82
画像処理のノウハウ • OpenCV 3.0で高速に
マスク処理、スコア算出 • スプラトゥーンの画面は
検出しやすい (ほぼ位置固定・白色文字)
機械学習すごい • K近傍法は簡単に使える • 特徴量の計算方法が ポイントになる
そのほか • 情報の見える化、大事 • 一人では全部できない • スプラトゥーン楽しい
Recommended