画像処理

OpenCV: Camera Calibration and 3D Reconstruction カメラ行列（内部パラメータ / intrinsic parameters） $$ A = \left( \begin{array}{ccc} f_x & 0 & c_x \ 0 & f_y & c_y \ 0 & 0 & 1 \end{array} \right) $$ 焦点距離 ( f_x, f_y ) 単位は画素（pixels） 2つの役割をもつ ピンホールカメラモデルにおける焦点距離(tex: f )（参考：ピンホールカメラモデル） 任意の単位で表される変換前の座標からコンピュータ上の画素の単位であるピクセル単位に変換する ピンホールカメラモデルでは1つの焦点距離(tex: f )しかなかったのに、なぜ(tex: f_x, f_y )と2つ含まれているのか 2つ目の役割（撮像素子の位置＝実世界の距離からピクセル単位に変換）のため、撮像素子の特性（px/mm）がx、y方向で異なる場合を想定している（( f_x, f_y )はレンズの物理的な焦点距離 ( tex: f )（mm）と撮像素子の特性( c_x, c_y)の積。また、カメラ画像からそれぞれを独立に求めることはできない） 参考：computer vision - Why does the focal length in the camera intrinsics matrix have two dimensions? - Stack Overflow, Learning OpenCV 画像の中心 (c_x, c_y) 単位は画素（pixels） 射影変換行列（Perspective transform matrix, 外部パラメータ/ extrinsic parameters） 参考：2次元の射影変換行列 $$ [R|t] = \left( \begin{array}{cccc} r_{11} & r_{12} & r_{13} & t_x \ r_{21} & r_{22} & r_{23} & t_y \ \end{array} \right) $$ ...

Pinhole camera model - Wikipedia OpenCV: Camera Calibration and 3D Reconstruction 3次元空間をカメラで撮影したときの、「3次元空間（実世界）上の点の座標\((x, y, z)\)」と「2次元写真平面上の点の座標\((u, v)\)」の変換\((u, v) = T(x, y, z)\)を考える。 カメラの位置を3次元空間における原点\(O\)とする。 ここでカメラに固有なパラメータとして、焦点距離\(f (> 0)\)を導入する。焦点距離は、カメラ（原点\(O\)）に入射した光が写真として実像を結ぶスクリーン（写真平面）までの距離である。この設定から、3次元空間上で写真平面（スクリーン）は\(z = -f\)にあるとわかる（写真平面をx-y平面と並行とし、z軸を3次元空間上の奥行きとする）。なお、\(f\)がより大きいカメラで撮影したとき、同じ距離にある被写体はより大きく写る（凸レンズ）。 （図はPinhole camera model - Wikipediaから引用。軸X1, X2, X3はx, y, zに、Y1, Y2はu, vに対応） 点P\((x, y, z)\)から原点Oを通過し、スクリーン上の点Q\((-u, -v, -f)\)に入射する光を考える。なお、実像は光軸を中心に上下左右に反転するため、このとき点Qは写真において座標\((u, v)\)にある。 点Pからxz平面上に落とした点P’\((x, 0, z)\)、点Qからxz平面上に落とした点Q’\((-u, 0, -f)\)を導入する。ここで、三角形POP’と三角形QOQ’は共通の角度を持つ相似な三角形である。この性質から、辺POと辺P’Oの長さの比\(x / z\)、辺QOと辺Q’Oの長さの比\((-u) / (-f)\)は等しい。すなわち、\(\frac{x}{z} = \frac{u}{f}\)。\(u\)について整理すると、\(u = f \frac{x}{z}\)。 （図はPinhole camera model - Wikipediaから引用。青線がスクリーン上の実像、赤線が実体。計算では図中の\(f\)を\(-f\)としている） ...

History GitHub - aoirint/SSBUFrameAnalyzer SSBUFrameAnalyzer · えやみぐさ SSBUFrameAnalyzer v2 · えやみぐさ What’s New 「ストック」を取得できるようにした（精度イマイチ） 3ストックまで想定（4ストック以上は未実装） 一応団体戦考慮してストックごとにキャラクター推定 精度イマイチな原因かも：背景、ファイター順によってちょっと決め打ち座標がズレてる、画像が小さすぎる→大きく補間してからHOG？ 勇者（Hero）のデータを追加（v3のdictionary） コマンド出てるときは（顔に被るから）邪魔で難しいと思う… GitHub - aoirint/SSBUFrameAnalyzer at v3 TODO ファイター数の推定 bboxのズレ解消 bboxの自動算出 残タイムの推定 画面中のファイター位置の推定 深層学習（YOLO/R-CNN系かセグメンテーション）になりそう、データがない… 精度向上 normalizeしたり、コントラスト上げたり、周辺ぼかすフィルタ掛けたりしたら精度上がらないかな チャージ・残量系キャラ（ルフレ、クラウド、リトル・マック、インクリング、ジョーカー、勇者他？）のチャージ・残量推定 ステージの推定（データ…）

GitHub - aoirint/SSBUFrameAnalyzer いまのところ、スマブラSPのスクリーンショットから「ダメージ値」・「おなまえ」・「キャラ名」を取得できる（ただし2,3,4人対戦のみ）。 「おなまえ」の取得精度は微妙。アルファベットだったら少し精度いいかも？ SSBUFrameAnalyzer · えやみぐさ 「キャラ名」の取得 ダメージ値と同じくHOG特徴量で最近傍（knnに拡張できる）。データには対戦中のキャラ顔画像を使用。 一応（大きく）モデル違うやつ（色変えただけ以外、ex. むらびと、ポケモントレーナー、ルフレ♂♀、クッパJr.など）はデータ用意してるけど、確認はしてない。漏れあるかも。 Example 1 ['マリオ', 'マリオ', 'マリオ'] [5.536537823295048, 6.301248636752482, 6.390935400999263] ['ドンキーコング', 'ディディーコング', 'ルキナ'] [5.539215799855154, 9.311677857638966, 9.606319879292924] {'fighters': {0: {'chara_name': 'マリオ', 'name': 'ぷれしいやー', 'damage': 0.0}, 1: {'chara_name': 'ドンキーコング', 'name': 'DONKEY KONG', 'damage': 0.0}}} FPS: 2.286091 (0.437428 s) Example 2 ['マリオ', 'マリオ', 'マリオ'] [5.971331723619266, 6.220896989804241, 6.286527104504024] ['ドンキーコング', 'ディディーコング', 'ロボット'] [5.520510947750764, 9.599002436376757, 9.670321221911154] ['リンク', 'ルキナ', 'シュルク'] [5.455176600531569, 8.748479515310487, 8.780689053687928] {'fighters': {0: {'chara_name': 'マリオ', 'name': 'tbここ', 'damage': 0.0}, 1: {'chara_name': 'ドンキーコング', 'name': 'DONKEY KONG', 'damage': 0.0}, 2: {'chara_name': 'リンク', 'name': '1旧い|', 'damage': 0.0}}} FPS: 1.381940 (0.723621 s) Example 3 ['マリオ', 'マリオ', 'マリオ'] [5.5006358082686555, 5.74951932443511, 5.7915505642106995] ['ドンキーコング', 'ディディーコング', 'ルキナ'] [4.692127133850047, 9.475091942436732, 9.545288243557097] ['リンク', 'シュルク', 'ルキナ'] [4.3889363397440455, 8.67419528745303, 8.707431208635597] ['サムス', 'ダークサムス', 'ケン'] [4.181132231378159, 8.547772471042341, 8.683606629158557] {'fighters': {0: {'chara_name': 'マリオ', 'name': '1に', 'damage': 0.0}, 1: {'chara_name': 'ドンキーコング', 'name': 'IDONKEY KONG', 'damage': 0.0}, 2: {'chara_name': 'リンク', 'name': 'LINK', 'damage': 0.0}, 3: {'chara_name': 'サムス', 'name': 'SAMUS', 'damage': 0.0}}} FPS: 1.227384 (0.814741 s)

About GitHub - aoirint/SSBUFrameAnalyzer いまのところ、スマブラSPのスクリーンショットから「ダメージ値」・「おなまえ」を取得できる（ただし2人対戦のみ）。フルで毎フレーム処理できるほどのFPS出ないと思う。 適当なSSで動かした目安FPS（ノートPC）: 2.766284 (0.361496 s) 基本的にターゲットの場所を（座標決め打ちで）切り抜いて処理にかけてる。 ダメージ値の取得 HOG特徴量使ったk-nnにしたけど、適当に確認して（写真と違ってノイズ入らないし、バリエーションも少ない）問題なさそうだったのでとりあえずTop1しか使ってない。すごい。 （被ダメージ・ふっとびで）エフェクトかかると取れなくなるだろうけど、自動化するなら前フレーム維持/スキップでいいと思って考慮してない。 参照データ数減らせばちょっと速くなるだろうけど、OCRの方が負荷大では（試合中にほぼおなまえ変わらないし、別にいいのか？ 団体戦？）。 おなまえの取得 Tesseract使ってOCR。たまに精度あやしいけどだいたいOK。すごい。 か→が、ぷ→ふ、みたいに濁点/半濁点に弱そう。 おなまえの長さ上限10文字までいけると思う（ひらがな10文字はためしてOK）。 TODO ファイター数の推定 どうすればいいんだ。（自動化して連続的にとるなら）一回推定すればいい気がするから、遅延気にせずHOG系の枠を一通り試行してうまくいった組み合わせを採用？ 各種bboxの自動算出 ファイター種類（キャラクター）の推定 HOGでいけるだろうけど、データ集めが面倒 ストック数の推定 ホカホカ（高被ダメージ）のときエフェクトが重なるのがあぶない 残タイムの推定 タイム∞のとき表示されない例外 背景ころころ変わるので精度出そうと思ったらknnな気がする…… Example {'fighters': {0: {'name': 'ふれいやー', 'damage': 141.3}, 1: {'name': 'KOOPA', 'damage': 101.5}}} FPS: 2.499149 (0.400136 s) 濁点/半濁点は苦手…。プレイヤー→フレイヤーさん。

pip install scikit-image from skimage.feature import hog import numpy as np size = 32 channel = 1 image = np.random.randn(size, size, channel) feature = hog(image) print(feature.shape) print(feature) デフォルト（勾配方向数9, セルサイズ8, ブロックサイズ3）では32x32の画像に対して324次元のHOG特徴量が出力される。 出力例 (324,) [0.01877925 0.00125122 0.00899619 0.00630656 0.01330613 0.0150924 ... 0.00763393 0.01668535 0.01852621 0.01204107 0.00433798 0.01147866] 画像からHOG特徴量の抽出 - Qiita https://web.archive.org/web/20170917002713/http://qiita.com/mikaji/items/3e3f85e93d894b4645f7 ドキュメント： https://scikit-image.org/docs/dev/api/skimage.feature.html#skimage.feature.hog