Jubatus Casual Talks #1 (2013/06/02) の講演資料。

1. Jubatusを用いた
大量映像の異常値検知
小川 宏高
Jubatus Casual Talks #1
2013/06/02

2. 自己紹介
• 小川 宏高 (@ogawa)
• 独立行政法人 産業技術総合研究所
• 専門
– 大規模データ処理
– 並列分散処理
– クラウド技術、グリッド技術
– JavaのJust-in-timeコンパイラ

3. Jubatus+AIST
• fv_converterの拡張⇒Datum魔改造
– 多種多様なリアルタイムデータ処理の支援
– 外部RPCサーバへのアウトソース機構の実現
• マルチメディアデータに特化した特徴抽
出の実現
• 以下ではそれぞれご紹介

4. fv_converterの拡張
• 多種多様なリアルタイムデータ処理の支
援
– 文字列・数値
⇒ 特徴が顕で取り扱いは比較的自明
– メディアデータ（静止画像、動画、音響）
⇒ 必ずしも自明でない
⇒ しかし重要: 実世界へのセンサ装置（監
視・車載カメラ、スマートフォン等）の浸透
が顕著、feature rich
• 外部RPCサーバへのアウトソース機構の実現

5. Datum魔改造
string_type num_type custom_type
string_filter_rules
string_rules
num_filter_rules
num_rules
datum
feature vector
Custom
Feature Detector
(OpenCV
HLAC/CHLAC)
任意のデータ型
を入力データと
して利用可能
入力データ型に
特化した特徴抽
出モジュール

6. Datum魔改造
string_type num_type custom_type
string_filter_rules
string_rules
num_filter_rules
num_rules
datum
feature vector
Custom
Feature Detector
(OpenCV
HLAC/CHLAC)
Custom
Feature Detector
(RPC Client)
Custom
Feature Detector
(RPC Server)
RPCの仕様を
満たしていれば
言語は問わない

7. マルチメディアデータに
特化した特徴抽出の実現
• OpenCVライブラリの提供する特徴抽出器
を用いた特徴抽出モジュール
• AIST謹製手法を用いた特徴抽出モジュー
ル
– 高次局所自己相関特徴法（HLAC）
– 立体高次局所自己相関特徴法（CHLAC）
• 音響情報に対する特徴抽出モジュール
– （開発中）

8. HLAC／CHLAC
• HLAC特徴
– 画像平面の2次元の局所領域に
おける相関パターン(3×3の局
所マスク)の出現を数え上げる
ことで特徴を算出
– 画像全体から相関を取る⇒位
置の影響を受けない
• CHLAC特徴
– HLACを時間を含めた3次元に
拡張
– 3×3×3の立方局所マスクの出
現を数え上げることで特徴を
算出
– 二値動画像の場合、独立な局
所マスクの個数は251通りとな
るため、CHLAC特徴は251次
元のベクタ値として算出
図は「大津、適応学習型汎用認識システム：ARGUS、Synthesiology, 4(2), 2011」より引用
http://www.aist.go.jp/synthesiology/vol04_02/vol04_02_p70_p79.pdf

9. 大量映像に対する異常値検知
• リアルタイムに動画像のCHLAC特徴を算出
• 251次元のCHLAC特徴値を元にLOFスコアによる
外れ値を検知
640x480,30FPS
640x480,30FPS
1/4×1/4
CHLAC
CHLAC
1/4×1/4
(k[i], f[i])×251
(k[i], f[i])×251
jubaanomaly
add
calc_score
• システム全体では多数の映像を同時並列に検査
• 同じ枠組みで、OpenCVの特徴抽出器や多値分類
器も利用可能

10. Example
正常と判断されれば
1
外れ値と判断されれば
より大きな値を返す
人為的なムービー
1. 0〜60sec: ブランク表示
2. 60〜70sec: 正方形オブ
ジェクトを表示〜平行移
動
3. 70〜90sec: ブランク表示
4. 以降、2.,3.を繰り返し
繰り返し刺激を与え
るにつれ徐々に外れ
値とみなさなくなる

11. 評価
• 評価環境
– 下記ノードからなる8ノードクラスタ
• Intel Xeon CPU E5-2620 2.00GHz × 2ソケット
– ノードあたり12コア、24HTスレッド
• 32GBメモリ
– Jubatus version 0.4.3
• Jubatusの外れ値検知器jubaanomalyでは、バックエン
ドの近傍探索アルゴリズムとしてeuclid_lshを利用
• 評価条件
– 最大224本の動画像ストリームを同時並行処理
• 640×480、30FPS
• ノードあたり1〜28本

12. 0"
10"
20"
30"
40"
50"
60"
1000" 2000" 3000" 4000" 5000" 10000" 20000"
1"
2"
4"
8"
12"
16"
20"
24"
28"
結果
学習済みフレーム数
スループット(FPS)
• 学習済みフレーム数10,000以下なら
概ね元データのフレームレートを上
回る
• 特徴点数の増加につれスループット
の低下が見られる

13. まとめ
• 産総研（AIST）は、Jubatusを用いて多種
多様大量のセンサーデータ、特にマルチ
メディアデータのリアルタイム分析を試
みています
– 今日挙げた成果（の一部）はOSSで公開予定
• Jubatusを用いた大量映像の異常値検知
– コア数〜HTスレッド数のオーダーの映像監視
が可能
– 学習済みフレーム数が増加すると性能劣化

14. 以降、補足スライド

15. レスポンス時間
• 学習フェーズ
– 1フレーム学習するのに要する時
間
• 検知フェーズ
– 1,000フレーム学習した状態で、1
フレームの検知に要する時間
0"
10"
20"
30"
40"
50"
60"
70"
80"
0" 100" 200" 300" 400" 500" 600" 700" 800" 900" 1000"
learning" learning"(plugin)" detec: on" detec: on"(plugin)"
• 検知フェーズ
– レスポンス時間8〜10msec
– 100〜125FPSで動画像の前処理、特
徴抽出、外れ値検知のリアルタイム
処理を行うだけの処理能力がある
• 学習フェーズ
– 学習したデータ数にほぼ比例した処
理時間
– 検知は高速であることから学習自体
に時間を要することが分かる
• fv_converterプラグインのオーバヘッ
ド
– 平均1〜2msec
– プロセス間通信のオーバヘッド
• 前処理・特徴抽出
– クライアント側で実施
– サーバ側（fv_converterプラグイ
ン）で実施
• クライアントはフレームデータを
送出
• Jubatusの特徴変換モジュールで前
処理・特徴抽出

16. スループット
学習フェーズ
1秒あたりの学習フレーム数
検知フェーズ
1秒あたりの検知フレーム数
• 学習フレーム数の増加に伴い、ス
ループット低下
⇒毎フレーム学習するのは困難
• ノードあたりのスレッド数はHTス
レッドくらいまでスケール
• 学習済みフレーム数10,000以下なら
概ね元データのフレームレートを上
回る
• 特徴点数の増加につれスループット
の低下が見られるが、学習フェーズ
に比べればマイルド
0"
5"
10"
15"
20"
25"
30"
35"
1000" 2000" 3000" 4000" 5000" 10000" 20000"
1"
2"
4"
8"
12"
16"
20"
24"
28" 0"
10"
20"
30"
40"
50"
60"
1000" 2000" 3000" 4000" 5000" 10000" 20000"
1"
2"
4"
8"
12"
16"
20"
24"
28"

17. レスポンス時間に関する考察
• JubatusのLOFの実装
– nn_engine->decode_row()
• すでに登録された点かどうかの判定
– nn_engine->update_row()
• 対象点をLSH (Locality Sensitive Hash)に格納
– collect_neighbors(1)
• LSHから対象点の擬似近傍点を取得
– collect_neighbors(2)
• LSHから擬似近傍点の擬似近傍点を取得
– update_kdist_with_neighbors()
• k距離の計算
– update_lrd_with_neighbors()
• LRD (Local Reachability Density)の計算
• 擬似近傍点をn個取得
⇒LSHの中で擬似近傍点の候補を対象点のハッシュ値から求め、それらを
対象点との距離でソートし、近いものからn個選択
– ハッシュ値が同じ点が非常に多い場合、時間を要する
• 実際、動きの少ない動画像で試したところ、10,000フレーム分追加した時点で
7,041フレームが同一のハッシュ値
0"
10"
20"
30"
40"
50"
60"
70"
80"
90"
100"
0" 1000" 2000" 3000" 4000" 5000" 6000" 7000" 8000" 9000" 10000"
update_row" collect_neighbors(1)" collect_neibors(2)"

18. レスポンス時間に関する考察
• 対策: ハッシュの量子化幅を小さくする
– LSHにおいて擬似近傍とみなされる点の個数が減少
– 計算精度は犠牲になる
– 量子化幅を10程度にすれば、処理時間を30%弱削減できる
– スループットを十分改善させるには不十分
量子化幅 総時間 (秒)
1 211
10 363
50 506
100 (デフォルト) 502