1.
「スプラトゥーン」リアルタイム画像解析ツール
「IkaLog」の裏側
（ver.1.3）
Nov 26, 2015
＠サイボウズさまオフィスにて
Takeshi Hasegawa (@hasegaw)
本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物からの引用です。

2.
@hasegaw is 誰
長谷川 猛 (HASEGAWA Takeshi)
twitter: @hasegaw
Ø もともと、インフラエンジニア(2004-2011)
SEとしてシステム構築、客先のシステム運用、提案
気付いたらプリセールス∼PMを担当するインフラエンジニア
（ざっくりデザイン、工数／導入物品見積もり、
構築プロジェクトの管理、保守等の問い合わせ対応）
Ø フラッシュストレージを軸とした、アプリケーション高速化を
支援するセールスエンジニア(2011-2014)
Ø ファブレス半導体ベンチャーでコンピュータ関連なんでも
2

3.
著書／寄稿
3

4.
記事紹介（？）
4
下記２本の記事(40ページ強)が
まとめて収録されました。
ISBN: 978-4774177823
価格: 2,786円
• Software Design 2014/10
第二特集
サーバの目利きになる方法 前編
• Software Design 2014/11
第二特集
サーバの目利きになる方法 後編

5.
はじめに
スプラトゥーン、そしてIkaLogとは

6.
スプラトゥーンとは
• 第三者視点(TPS）のシューティングゲームの一種
• インクで自分たちのナワバリを広げないと進めない
• シューティングが苦手でも
バケツやローラータイプのブキで気軽に楽しめる
• 本気でやってる人たちは怖い
6

7.
スプラトゥーンとは
（ビデオ：会場のみ）
7

8.
IkaLog とは何か
• Wii U用ゲーム「スプラトゥーン」支援ソフト
– HDMIキャプチャを介して情報を自動取得
– 数値・文字列データとして認識
– お好みの方法で
蓄積、出力
8

9.
IkaLog のイメージ
9
HDMIキャプチャ
IkaLog
実行用PC

10.
IkaLog の画像認識例
10

11.
IkaLog の画像認識例
11

12.
IkaLog の画像認識例
12

13.
IkaLog の画像認識例
13

14.
各種ソフトウェアとの連携（デモビデオ）
14
(ビデオ：会場のみ)

15.
プラガブルで様々な使い方に対応
15
録画ソフト 自動制御
AmaRecTV
カラーLED連動
Fluentd
転送
スプラトゥーン戦績記録SNS
CSV/JSONファイル保存
スクリーンショット保存
SNS投稿
IkaLog

16.
Embeded IkaLog （ライブラリモード）
• IkaLog 自体が Python モジュールとして実装されている
• Python コードから IkaLog を実行して、情報を受け取れる
• 作ってみたアプリケーションの例
16
アプリケーション
説明
IkaRename.py
スプラトゥーンのビデオを分析
ステージ／ルール／勝敗のついた
ファイル名にリネームする
IkaClips.py
スプラトゥーンのビデオを分析
敵を倒した／倒されたシーンだけクリップし、
“忙しい人”向けのサマリムービーを生成

17.
IkaLog が出力するデータの複雑化（１）
17
IkaLogの当初のスコープ
・ステージ／ルール検出、勝敗（２択）
・スクリーンショット保存
追加された検出内容
・目標（ガチホコ／ガチヤグラ）の位置検出
・プレイヤーの死因（凶器）検出
・時系列のスコア検出
・プレイヤーのランク、所持金などの数値検出
・全プレイヤーの生死ステータスのモニタリング
・ロビー（パブリック／プライベートタッグ）検出
今後追加する（かもしれない）検出
・コミュニケーション検出（ナイス／カモン）
・スペシャル蓄積・利用検出
・目標に対するチームのイベント

18.
IkaLog が出力するデータの複雑化（２）
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)
※本当はもっと色々出せる
→
情報量の増加に伴い分析基盤の構築が必要

19.
stat.ink (戦績SNS)
• IkaLogユーザのひとり @fetus_hina さんが
開発、運営する Web サイト
• IkaLog からのプレイデータを受け取り、表
示・集計する
19

20.
20

21.
21

22.
stat.ink
（全ユーザのプレイ結果からの統計）
22

23.
ゲームルールによるK/Dと勝率の相関
23

24.
stat.ink
（ブキの統計）
24

25.
ステージによって異なる
KO勝ち／KO負け率
25

26.
IkaLog + stat.ink のDAU、処理ゲーム数
26
データソース
hJps://stat.ink/enLre/users
【ピーク】
130ユーザ/日
5,500ゲーム/日を分析
毎日 約70ユーザが利用
24時間あたり2000ゲーム前後を処理

27.
エコシステム
27
ユーザー
開発者
hasegaw/IkaLog
stat.ink
ダウンロード
記録
送信
hasegaw
一部データ
(QA用)
開発、
stat.inkデータに
よる機械学習
Windows版
実行ファイル生成
（本スライド中の画像の一部はイメージであり実際のものとは異なります。）
PR
モ
ツ
鍋

28.
開発開始の経緯と
基本的なしくみ

29.
IkaLog開発の経緯
• スプラトゥーン プレイヤー同士で
モツ鍋を食べていたら、戦績の統計の話に
• ゲームには、戦績の統計機能は存在しない
• 手動でExcelを使い戦績を整理している人も
29

30.
とあるイカの戦闘記録
30

31.
とあるイカの戦闘記録
31

32.
とあるイカの戦闘記録
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.
スプラトゥーン プレイヤーにとっての
主なメトリック
• どのステージが得意か？苦手か？
• どのルールが得意か？苦手か？
• どのブキが得意か？苦手か？
• どのブキにやられやすいか？
• どれぐらい突進していいのか？し過ぎなの
か？
33

34.
ツールを作ろう(検討編 1)
720p １プレイ分の動画を相手に検討開始
• 非圧縮 5分 → 20GB
OpenCV のテンプレートマッチングで試行錯誤
• 判ったこと：使えなそう
– 誤検出が多い
– マッチングアルゴリズムが遅い
34

35.
ツールを作ろう(検討編 2)
• もっと単純な方法で画像をマッチングする
– スプラトゥーンのシステムメッセージは
ほとんどが、決まった位置に白色で表示される
– 文字部分だけが黒く、残りが白い画像を加算し、加
算した後の画像のヒストグラムで判定する
– 基本的に足し算、引き算で実現できるため
非常に高速に処理できる
– 画面が真っ白なときに誤動作
→もともと白い画像は無視する
35

36.
IkaLogの画像マッチング (第一世代)
36
ソース映像
マスク画像
加算画像
+
=
=
正しいマスクを加算すると画像が真っ白になる
違うマスクを加算すると画像が真っ白にならない

37.
IkaLogの画像マッチング (第二・三世代)
• 第二世代
– 「前景が白」だけでは他の場面で誤認識するケースが
増えてきた
– 「背景が黒」「背景が白以外」のどちらかを
指定して、条件以外のドットが多ければ False-Positiveと判
断できるように拡張
• 第三世代
– 「前景がオレンジ」「前景が黄色」などを認識したい
ケースがでてきた
– 前景・背景ごとにHSV色成分などをして条件通り・
条件以外のドットを検出できるように拡張
37

38.
入力画像から目的に色だけを取り出す
38
入力画像
黄色のみ
白のみ
黒のみ

39.
ＲＧＢ色空間とHSV色空間
39
RGB色空間
HSV色空間

40.
数字の認識と機械学習

41.
数字の認識
• ゲーム中で使われているフォントは２種類
• 画面上に現れる数字フォントは１種類
• フォントが判っているのだから、
認識できるはず
• 試行錯誤の後、既存OCRエンジンの利用は断念
• 機械学習ベースの認識エンジンを実装
41

42.
既存OCRでの問題点
• Tesseract OCRを評価
– 認識率が安定しない
– もともと文章を読み取るためのもの
– 1∼2文字の文字、数字の認識は苦手
– 0, 8, 3 などを間違えることがある
– Python 3.x のスクリプト上から
利用しづらかった
• 既存の文章向けOCRエンジンよりも
単純で目的に適した認識方式を検討
42
文字として
認識されないことも

43.
kNN(K近傍法)の考え方
43
●
●
●
●
■
■
■
■
?
▲
▲
▲
▲
?
?
?
?
とてもシンプルな機械学習
標本 の傍にあるサンプルがどれかで
分類する。
K=1
の場合は最寄りのサンプルがある
クラスに分類される。
K=3
の場合は近くに3つのサンプルがある
クラスに分類される。

44.
kNNによる図形マッチングの例(1/2)
• GitHub にソースあり
– https://github.com/hasegaw/opencv_knn_example/
• 三つのパターン ○ △ □ で画像を生成し、
kNNで学習する
• ランダムに ○ △ □ から画像を生成し、その画
像の種類を判定する
– KNN を用いてそれに近い画像を見つけ出す
– 見つけた画像の種類から、問題図形の種類を特定
44

45.
kNNによる図形マッチングの例(2/2)
45
問題図形をランダムに
生成
K近傍法を用いて、学習済みの
図形から、もっとも近い図形を調べる
仕分ける
○
△
□
○
学習済み図形
○
△ □

46.
KNNで見つけた「一番近い文字画像」で
画像を置き換え(1/2)
• 各日本語フォント文字をPNG形式に変換
• 上記データをKNNで学習
• 画像を入力しグレースケールに変換
• 画像を文字サイズにあわせて分割、KNNで
各領域にもっとも近い文字フォントを調べる
• 画像を文字に置き換え
46

47.
KNNで見つけた「一番近い文字画像」で
画像を置き換え(2/2)
47

48.
48
kNN
による数値認識を実装後、はじめての
テスト結果。１０の位は文字画像の位置ズレで
誤認識が生じているが、１の位は１００％認識
できた

49.
数字の認識
１）画面上の数字部分（位置固定）を切り抜き
２）縦・横のヒストグラムを生成し各文字の位置を特定
３）文字を検出用サンプルのサイズ（等幅）にリサイズ、
二値化
４）KNNにより既知の検出用サンプルと照らし合わせて
認識する
49

50.
死因の認識

51.
死因の認識
51

52.
死因の認識
• 「数値が認識できているから、
死因もなんとかなるだろう」
• 数字認識との共通点
– 目的の情報が白色なので二値化しやすい
– 文字列の位置を特定し、切り抜きできる
• 数字認識との相違点
– アニメーションにより、常にサイズが変化
52

53.
死因の認識（３） 死因のリスト
53

54.
死因の認識（３）
• 基本は数字の認識と一緒
– 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
}

55.
ブキの認識

56.
スプラトゥーンのブキ
• スプラトゥーンでは、５０種類を超えるブキから
好きなものを選んで利用できる
• 全体的にバランスが取れているゲームだが
戦略や戦術、ブキの選択で優劣が発生する
• 分析したい -> 画像認識
56

57.
スプラトゥーンのブキ画像リスト
57
スプラトゥーンのブキ ５９種類（スライド作成当時）

58.
画像判別においてのチャレンジ
• ブキ画像が小さい（47x45ドット・外枠込み）
• 表示条件（背景・被る画像）が変わる
• 誤判定すると後の統計結果に多大な影響が出る
• 一回の判定に使えるのは画像１枚のみ
58
他の装備品が被っている
保護色（まだマシ）
保護色（マジつらい）

59.
ブキ認識アルゴリズム（第１∼３世代）
世代
特徴、利点
課題
-­‐
すべての正解画像を保持しておき、
入力画像を比較
第三者著作物のデータをそのま
まデータに含めて配布する必要
があった
第1世代
画像の色相ヒストグラムを特徴量とした
統計的手法（のちにK近傍法へ切替）。
認識率 ８０％以下
第1.5世代
第一世代の特徴量のまま、分類アルゴ
リズムをKNNに切り替え
認識率が若干悪化
第2世代
（現在）
特徴量を色相ヒストグラムから”画像の
複雑さ”に変更
・ラプラシアンフィルタなどを通して画像
の特徴量を算出
・開発環境で９９．９９％〜の精度を実現
ユーザの環境（デバイス、設定差
異、設定ミス）により認識率が大
幅低下
第3世代
CNN（畳み込みニューラルネットワーク）
を利用した深層学習
stat.ink投稿データで９９．９７％以上の
精度を実現
分類処理に要するCPU時間
学習データのサイズ、配布方法
59

60.
第1, 1.5世代
色相ヒストグラムによるブキ特徴量の算出
60
（まだバグがあった頃のバージョンの表示なので色がずれているけども）
こんなかんじで特徴量を抽出していた

61.
ブキ認識テストの様子（かなり初期）
61

62.
第2世代
ラプラシアンフィルタを用いた特徴量の算出
62
入力画像
ラプラシアン
フィルタ適用
グレー
スケール
輪郭情報
特徴量画像
（合計64ドット)
→
課題が浮かんできた
• キャプチャデバイスの画質特性により特徴量が変化する
• WiiUの出力解像度
(720p/1080p)
により、
特徴量に差異が生じる
• ユーザがキャプチャ関連ソフトでWiiU画像を間接取り込みし
本来のWiiUの信号とは異なる解像度、オフセットで入力され、
特徴量が変化する
Thanks
@itooon

63.
新しい特徴量算出方法での分類結果（１）
63

64.
新しい特徴量算出方法での分類結果（２）
64
テストデータは12000弱
正解の一覧は作っていないので目視で確認
多分、分類できている

65.
想定通りの特徴量となるケース、
ならないケース
65
IkaLog内部処理フォーマット
ユーザが縮小した画像
720p
???
1080p
720p

66.
ユーザから投稿されるデータの例
（解像度の違い）
66

67.
第3世代 - 深層学習によるブキ判定
67
Thanks
@itooon

68.
第3世代 ‒ 深層学習によるブキ判定
• CNN を用いてブキ画像を学習(AlexNet, GoogleNet)
• Caffeで動作確認後Chainerベースで再実装
– IkaLogが使うPython3ではCaffeが利用できない
– WindowsでのCaffe利用が難しい
– Chainer on Python3ではCaffeモデルが利用できず、
Chainer + Python3 で改めて実装、学習
68
Thanks
@itooon

69.
第3世代 ‒ 深層学習によるブキ判定
• 驚異的な正答率
– 様々なユーザが投稿した数万ブキ画像の
クラスタリングでほとんどミスなし（3０件以下）
• 学習はGPGPU必須、マッチングはCPUも可
300ms(CPU)
200ms(CPU w/Intel MKL)
50ms(GPU) 程度
8枚の画像が3秒以内に認識できれば十分現実的
69
Thanks
@itooon

70.
第3世代 （CNNベース)
ユーザ環境への導入に向けての課題
• モデルデータの肥大化が課題
400MB (AlexNet)
100MB (GoogleNet)
←→ 1MB (KNN)
配布方法は？コスト対効果は？
• CPU性能が確保できない場合は？
– Core2世代などの非力なプロセッサの場合
– ストリーミングソフトウェア、
ソフトウェアビデオエンコーダとの共生
70

71.
第3世代 （CNNベース)
機械学習への利用
• CNNベースのほうがKNNベースより正答率
が高い
– KNNベースの教師有り学習は手作業での分類な
どに手間がかかる
– KNNの教師有り学習にCNNの分類結果を利用で
きれば手作業を減らすことができる
• CNNでユーザーの投稿データを分析し、
KNNのモデル生成に活用することも検討
71

72.
Webcam サポート
※ ソースコードは GitHub にありますが、現在開発中の
機能であり、一般ユーザー向けには提供していません。

73.
Webcamサポート
• HDMIキャプチャデバイスを持っている人は
少ない
– ゲーム実況をするニコ生主などなら
持っているが…
– 新たに購入しようとすると、約２万円の投資
• HDMIキャプチャの代わりにWebカメラを利
用できないか?
73

74.
Webcam サポート（イメージ）
74
1)
TV、ディスプレイに
Webcam
を向ける
2)
WiiU
のホーム画面を表示
3)
IkaLog
で
Webcam
を介して ワープ キャリブレーション
4)
以後 IkaLog
は画面と認識した範囲に対して処理を行う

75.
Webcam経由の動画サンプル
（会場のみ）
75

76.
OpenCVサンプル find_obj.py (1)
76

77.
OpenCVサンプル find_obj.py (2)
77

78.
HDMIキャプチャと間接キャプチャの比較
78
HDMIキャプチャ
(H264録画)
Webcamによる間接キャプチャ
雑なカラーコレクション適用済み

79.
Webcam経由の入力状況
• 「既知の画像」（WiiU ホーム画面）を
画面上に出して、キャリブレーション
• 720p (1280x720) の画面を 5pxぐらいの
精度で取り込める
• 白色が (255,255,255) にならないため
何らかの対策が必要
– カラーバランス、ガンマ調整
– IkaLog 内の画像検出のスレッショルド変更
79

80.
Webcam 対応の課題点と
これまでに得られた知見
• もし、このような「変な使い方」をするときは
自動調整機能をオフにできるWebcamがオススメ
– カラーバランスが固定できること
– コントラストが固定できること
– オートフォーカスをオフにできること
• プラズマTVは明るすぎて Webcam の
ダイナミックレンジが追いつかない？ EL液晶は？
• 新しめのスマートフォンのカメラも非常に優秀
80

81.
よさそうな WebCam の一例
81
Logicool
の
Webcam
はカラーバランス、コントラスト、フォーカスを
固定できるのでこのような用途に向いている（アキヨドで試して購入した）
ただし上記の固定機能は
Windows
専用。
Mac
では実装されていない（怒

82.
まとめ
82
画像処理のノウハウ
• OpenCV 3.0で高速に
マスク処理、スコア算出
• スプラトゥーンの画面は
検出しやすい
（ほぼ位置固定・白色文字）
機械学習すごい
• K近傍法は簡単に使える
• 特徴量の計算方法が
ポイントになる
そのほか
• 情報の見える化、大事
• 一人では全部できない
• スプラトゥーン楽しい

83.
質問タイム？
83
らぴす
(2000-­‐2014)

84.
マンメンミ！
(ありがとうございました）