catalinaの備忘録

ソフトウェアやハードウェアの備忘録。後で逆引きできるように。

外出先からDNNの学習状況を確認したい

今回はchainerでの学習進捗を見るのが目的ですが、あんまりchainer関係ないです。webフロントまわりですね。

やりたいこと・その経緯

DNNを試しておいて、自動で学習してる間にちょっと出かけたりとかしたいです。

そうすると出先で学習の経過が見えたほうが便利ですよね。

帰宅中の電車の中で結果を見ることができれば、次どうするかの策を移動中に考えることができます。

リモートデスクトップでいいじゃない

外出先でもVPN使えばPCにログインできるので、リモートデスクトップでなんとかなったりします。

ただWindowsリモートデスクトップって今回やりたいことに対して少々オーバースペックです。ちょっとjpegファイルみたりログ読みたいだけなのに。

そのうえ外出先だとスマホからのアクセスがメインになるので、リモートデスクトップが操作しづらいです。

というわけで、外出先から自宅のPCにアクセスしてchainerの学習状況を確認するための「使いやすい」構成を考えてみました。

  • Chainerが走ってるPCでWebサーバを走らせる
  • VPNはこれまで通り使う
  • WebサーバからChainerの状況を読み出す
  • スマホのブラウザから進捗が確認できる

こんなところでしょうか。 実験用のWebサーバをそのまま外部に公開するのはセキュリティ的に少々怖いので、VPNは維持しておきます。

使用するフレームワークの選定

DNNのフレームワークはchainerを使います。

Webサーバとしては候補は色々ありますが、ChainerがPythonなのでPythonで統一したいところです。

とりあえずWebから見たい情報は

  • 学習の進捗
  • グラフの形状
  • 各層の状況

などでしょうか。

グラフの形状を見れるなら、そこから画面遷移したいとか要望が増えることも考えられます。

画面遷移とか考えるとbottleでは少々力不足です。 せっかくなので、勉強も兼ねてDjangoを使ってみることにします。

今回使うDjangoは公式のチュートリアルをやっておけば最低限の扱いはできそうな感じでした。 https://docs.djangoproject.com/ja/1.11/intro/tutorial01/

ではやってみます。

環境

環境はいつものです。

Djangoを使う準備

Djangoとはpythonでwebアプリケーションを作るためのフレームワークです。 軽く触ってみた感触ではよくあるフレームワークと同じなのかなと思っています。

まずはインストールしてコマンド類を確認します。

pip install django

Webサーバを立てる

プロジェクトを作ります。 このときプロジェクトと同名のWebアプリケーションも自動で生成されます。

django-admin.exe startproject dnn_view
cd dnn_view

しばらくはこのディレクトリがカレントであったほうが作業しやすいです。 ほとんどのコマンドはこのディレクトリに生成されたmanage.pyで使うので。

どんなコマンドがあるのかは

python manage.py --help

で確認できます。

とりあえずサーバを立ち上げてみます。

python ./manage.py runserver

これでhttp://127.0.0.1:8000 にアクセスすればDjangoのページが開きます。

同様にして http://127.0.0.1:8000/admin にアクセスするとWebサイト管理者用の画面が開きますが、まだユーザー作ってないので入れません。

管理ユーザーを作る

今回使用するDjangoのバージョンでは、DBのマイグレーションしてからユーザーを作る手順になります。 DBはデフォルトでSQLite使ってくれるみたいなので、当面は気にしなくていいでしょう。

python ./manage.py migration
python ./manage.py createsuperuser

ユーザー名、メールアドレス、パスワード、再確認パスワードを入力して完成。 先ほどの管理者用のページでログインできるようになります。

とはいえ、今回は管理者ページを使ったことは何もしません。

Webページを作る

初めてのDjangoなので、簡単なページを作ることにします。 幸いにもChainerは進捗状況をpngに吐いてくれる機能があるので、このpng画像を張り付けただけのページWebサーバで見せることにします。

次のものを作成・変更します。

  • URLとビューを結びつける urls.py。djangoが作ったものに変更を加えます
  • ビューを表現するviews.py。これもdjnagoが作ってくれてます
  • ビューの具体的な表示内容を示すhtml。自前で書きます。

URLとメソッドを結びつける

ページのパス名とpythonメソッドを結びつける必要があります。 とりあえず適当なviewに結び付けます。

from django.conf.urls import url
from django.contrib import admin
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
from . import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^dnn_view/', views.net),
]

これでhttp://127.0.0.1:8000/dnn/ へブラウザでアクセスするとviews.pyに定義されたnetという関数が呼び出されます。

ビューをつくる

ビューをつくります。 アプリケーションのディレクトリ(urls.pyとかと同じ階層)にtemplateディレクトリを作ってて、その中にdnn_view/index.htmlを置いたので、このファイルを読み出して使うという単純なものです。

from django.template import loader
from django.http import HttpResponse

def net(request):
    t = loader.get_template('dnn_view/index.html')
    return HttpResponse(t.render())

テンプレートをつくる

お行儀よくテンプレートで定義することにします。パスがちょっとアレなのでお行儀良くないかもしれませんが。

これはUWPでいうXAMLに相当するものかなと思っています。

Microsoft-Edgeさんで実験していると、DocTypeなしのHTMLだと警告がうるさいので、つけておきます。

{% load static %}
<!DOCTYPE html>
<img src="{% static "loss.png" %}" alt="My image"/>

どうしてEdge?

私のスマホはWindowsPhoneです。なのでEdge。

あとはPC版EdgeだとUAのエミュレーション試験機能もついてるので。こいつですね。 f:id:Catalina1344:20170805012100p:plain

モバイル用UAに設定してから適当なサイト見るとモバイル用のボタンとか増えたりして楽しかったりします。

テンプレートと画像のパスを登録する

Djangoが静的ファイル(画像とかcssとか)を探すときに使うパスを登録しておきます。 本番だとこういうやりかたはオススメできないみたいな話もありますが、所詮は実験用なので良しとします。

どうやらDjangoにはデプロイ用に静的ファイルまとめてくれる機能があるらしいです。今回は目的からそれるので試しません。

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.11/howto/static-files/

STATIC_URL = '/static/'

STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),
    'C:/myproject/deep_learning/sdks/result', # chainerの学習結果が吐かれるパス
]

できた!

これでブラウザから http://127.0.0.1:8000/dnn_view/ にアクセスするとこんなの出ました。よさげですね。

f:id:Catalina1344:20170805012147p:plain

感想と今後

これで学習の経過は見れるようになりました。 出かける前に仕掛けておいて、昼休みとかに進捗どうですかと確認したりとかできますね。 あとはスナップショットとグラフ構造も見せるようにしてUIつければ、色々と楽しいかもしれません。

それでは今回はこれくらいで。

カードゲームARの実現可能性検証

なんとなくですが実現可能性は高い気がしてきました。かたりぃなです。 本題に入る前に問題領域を今一度整理します。

やりたいこと

MTG遊戯王みたいなカードゲームの遊びの付加価値として、AR化を考えています。 やりたいことはARと一言で済むのですが、もう少し問題領域を整理します。

  • 現実空間のカードを自動的に検出できる
  • 検出したカードが何なのかを言い当てられる
  • カード上に任意の3Dモデルをレンダリングできる

こんなところです。

このうち「現実空間のカードの検出」が今回のエントリでのお題です。

カードが何なのかを言い当てるのは、以前のエントリで実現可能性は見えてきているので今回は触れません。

3Dモデルのレンダリングは、あとでやります。モーションやエフェクトも考えるとUnity使ったほうがラクかなぁと思っています。

肝心の3Dモデルデータはありません。mod方式にしておいてユーザーが差し替えられる仕組みがあれば楽しめそうです。最初はコナンの犯人シルエットみたいなのでも出しておくつもりです。もしモデル作ってる人がいたら、そのとき考えることにします。

概念図

Hololensだけではマシンパワー不足なので、PCのパワーを借りることにします。 実際に実現できて採算がとれるならクラウドでやればいいですし。

気分転換に概念図書いてみました。赤文字が今回やるところです。 f:id:Catalina1344:20170720223327p:plain

既存のライブラリで不足していること

Hololens単体でも、Vuforia使っても、私のやりたいことには単体では届きません。

まずそれぞれでできることは

  • Hololensは空間認識ができる
  • Hololensは自分の位置を知っている
  • Vuforiaは検出対象物が既知でなければならない

です。 Vuforiaを試そうかと思いましたが、全部のカードを登録していくのは少々面倒です。ほかのARライブラリについても同様です。

じゃあHololensなら解決できるの?と問われると、そんなことは全然なくて、あくまで空間と自身の位置を認識することで、その空間に任意の3Dレンダリングを行えるだけです。

というわけで、検出対象物の検出をどう工夫するかといったところが今回のお題です。

R-CNN

領域抽出をいろいろと調べて回りました。

ざっと年代順にR-CNNの技術要素を並べると

  • R-CNN
  • fast R-CNN
  • faster R-CNN
  • YOLO
  • SSD

こんな感じのようです。 古いものは領域抽出自体はselective searchで、その領域の分類をCNNでやっているだけの雰囲気でした。(ざっと読んだだけなので違うかもしれません)

SSDは「物体の領域抽出と」「物体のカテゴリ分類」を一度のCNN計算で済ませることからついた名前らしいです。(Single Shot Detect)

実際にくっつけてみる

R-CNN自体は以前のエントリでchainercvを使って試したので、今回も同様にしてみます。

chainercvの実装が変わったのか、うまく検出できなくなっているのでスコアが低いオブジェクトも列挙できるようにuse_presetで閾値をさげておきます。

このモデルは自分の目的にあわせて学習させていないので、あとで少しずつ方法論を考えます。

rcnn_model.predict()で領域抽出してもらいます。 一度に複数枚の画像を入力できるらしく、引数はリストです。 戻り値も当然リストなので0番目の要素をとっておきます。 bboxが傾いていないバウンディングボックスで、labelがその領域のカテゴリです。

    rcnn_model = SSD300(
            n_fg_class=len(voc_detection_label_names),
            pretrained_model='voc0712')
    chainer.cuda.get_device(0).use()
    rcnn_model.to_gpu()
    rcnn_model.use_preset('evaluate')

    # R-CNNへ入力してobject-proposalをする
    bboxes, labels, scores = rcnn_model.predict([pixels])
    bbox, label, score = bboxes[0], labels[0], scores[0]

バウンディングボックスをもとにcropする

バウンディングボックス内にカード画像が含まれているとするなら、そのバウンディングボックスのROIに対してカード検出をかければいいと考えます。 というわけで、バウンディングボックスのROIを作ります。ここからopencvの世界です。

    for i, b in enumerate(bbox):
        top, left, bottom, right = b
        t = 0 if top < 0 else top
        l = 0 if left < 0 else left
        croped_img = base_img[int(t):int(bottom), int(l):int(right)]
        croped_img_clone = np.array(croped_img)

カードを検出する

以前c++でやったことをpythonで実装します。 実装し終わって気づいたのですが、C++で作った部分をdll化してCTypes使えば済んだかもしれません。

夏バテなのか、疲れがたまっているのか、コード汚いです。動けばいいやというスタンスです。

def card_detect(img):
    # 平滑化、二値化、輪郭抽出
    g_img = cv2.GaussianBlur(img, (5,5), 8)
    r, bin_img = cv2.threshold(g_img, 85, 255, cv2.THRESH_BINARY_INV)
    canny_img = cv2.Canny(bin_img, 50, 200)

    # 確率的ハフ変換による線分検出
    h, w, c = img.shape
    minLineLength = min(w,h) // 4
    maxLineGap = 10
    lines = cv2.HoughLinesP(canny_img, 1, np.pi/180, 40, minLineLength, maxLineGap)
    if lines is not None:
        if len(lines) < 4:
            return None

        # 検出した線分のすべての頂点を列挙
        pts = np.array(lines)
        pts = pts.reshape(-1, 2)

        # 回転を考慮した外接矩形を求める
        rect = cv2.minAreaRect(pts)
        box = cv2.boxPoints(rect)
        box = np.int0(box)

        return box
    return None

この関数は、カードらしい領域が見つかった(=線分が4本以上ある)ならば、傾きを考慮したバウンディングボックスが返されます。見つからなかったらNoneです。

傾きを考慮したといっても、透視投影変換のような変換には耐えられないので、机に対して斜めから撮影した画像ではズレが大きくなります。あとでもうちょっとまともにしましょう。

画像分類するために透視投影変換をする

以前、chainerで画像分類のために学習させたモデルはカードの正位相(MTG用語)での画像です。 なので、正位相の画像を作ります。

(省略)

画像分類する

以前にchainerを使って実装したものそのままです。 このコード自体はいたって普通なのですが、NNから間違えた答えしか返ってきません。悲しい。

なんとなくですが、opencvとpillowで行列の形が違う気がします。特にカラーチャネルとか。 あとで見直しましょう。

def detect_cardtype(image):
    # NNへ入力可能な形式に変換する
    pixels = np.asarray(image).astype(np.float32)
    pixels = pixels.transpose(2, 0, 1)
    pixels = pixels.reshape((1,) + pixels.shape)

    print("NN input image shape = {}".format(pixels.shape) )
    # 識別
    y = model(pixels)
    prediction = F.softmax(y)
    m = np.argmax(prediction.data)
    return m

実行結果

カード検出と分類結果の取得まで1秒くらいで動いています。実測はしていませんが、これくらいの遅延なら実運用に耐えられるかなと思います。

Hololensと連携したい

実際のアプリと連携させるにあたって、この遅延時間を考慮する必要があります。

遅延時間の考慮とはどういうことかというと、ある画像からカードを検出して識別結果が返ってきたとして、それは過去の映像フレーム上での話であってHololensの今現在の状態から過去に-delta遡った時点での推定結果です。

ここでHololensが「自身の空間上の位置と姿勢」を把握していることを活用することになりそうです。

つまり識別したい映像フレームが採取されたタイミングでのHololensの空間上の位置・姿勢を保持しておけば、そこからの相対位置で本来あるべき位置へと補正できるというアイデアです。

DeepLearningで推定されたカードの位置・姿勢は、確かにDNNの計算時間による遅延はあります。 けれども、Hololensがフレームを採取した時点での位置姿勢とは必ず合致するはずです。 ということは、推定された位置と姿勢は現在時刻からみて-deltaの時刻の姿勢にあたるので、このdelta時間の間に変化したHololensの位置・姿勢の変化量を加味してあげれば辻褄はあうはずです。

カード種別間違えて識別しているのはそのうち調査するとして、先にこっちの理屈が正しいかどうかの確認をすすめたいところです。

今後の方針

私は技術的な課題(遅延)を追及することよりも、実用性・コストパフォーマンスのほうが重要だと思っています。 ただし技術を無視していいとは思いません。あくまで優先順位の話です。

なぜなら「技術的・理論的に美しい」ことと、「面白い・実用的なアプリである」というのは別の概念です。

なので「実現可能性があること」と「実現に向けた課題の洗い出し」のためにプロトタイプを作ります。

応用分野

物体の検出と分類がほぼすべてDeepLearningで実現できそうなので、あとはゲームが変わっても学習モデルを更新するだけで済むんじゃないかなと思っています。

汚いコードですがgistにあげておきました。 https://gist.github.com/javoren/2fa2fc6ebcd8582d72b86f7017e742eb

今後の展望

古いPCがお亡くなりになって、夜な夜な貯めていたアレな動画とか重要参考資料がなくなってしまいました。 バックアップ大事。

gistが正しい意味でバックアップといえるかどうかはさておき。

それでは今回はこれくらいで。

UWPで非同期taskを書くときに気を付けること

まだまだtaskの操作に慣れていません。かたりぃなです。

今日はUWPのコードをC++/cxで書くにあたって、詰まったポイントと解決策を書いてみます。

UWPでの非同期taskとは

ムーアの法則の限界が叫ばれてからCPUはマルチコア時代に入っています。モバイル端末でさえも。

CPU資源の有効活用を考えたとき、マルチスレッド・マルチプロセスなコードにすればCPU資源を有効活用できるよねと概念レベルで言うだけならタダですが、実際にやってみると難しいことがあります。

難しいポイントとしては、例えば従来型の手続き型プログラミングの延長でマルチスレッド・マルチプロセスをやろうとすると、次のような問題に直面します。

  • スレッドやプロセス間のデータ受け渡し
  • スレッドの同期
  • スレッド立ち上げのコストと、並列実行のトレードオフ

特にC/C++のような手続き型・オブジェクト指向な言語でこれらを乗り越えようとすると相当キツイです。

設計上はうまく作ったつもりでも、マルチスレッド・マルチプロセスではテスト難しくなってきて「動くこともあるけど、動かないこともある」なんてことが簡単に起きます。

こういった類の問題はテストでは再現が難しい問題になりがちなので、相当タチが悪いバグになってプログラマを悩ませます。

Windowsアプリではこの問題に対する多くのアプローチがあります。

今回はその中でもtaskをどうやってうまく扱うかという問題に焦点をあてて分析してみます。

いわゆるMicrosoft-PPLです。

公式ドキュメントはこのあたりです。

https://msdn.microsoft.com/ja-jp/library/dd492418.aspx

https://msdn.microsoft.com/ja-jp/library/dd492418.aspx

taskを返す関数=高階関数としてとらえてコードを書く

これは私なりの結論です。

taskとは何かということを考えてコードを書くとき、それは関数であり、taskを生成する関数とは関数を返す関数、いわゆる高階関数だという解釈です。

※あくまで概念レベルで「ああ、私が欲しかったの、こういうやつだ」と感じただけの話なので、その世界で本気でやってる人からは異論あるとは思います。

高階関数の概要はwikipediaで一行で簡単に述べられています。 https://ja.wikipedia.org/wiki/%E9%AB%98%E9%9A%8E%E9%96%A2%E6%95%B0

要は

  • 関数を引数にとる関数
  • 関数を戻り値にできる関数

です。

というわけで 以下にコードと概念を整理します。

PPLでは、従来の関数と呼ばれてきたものを「タスク」として定義できる

タスクとはppl::concurrency::taskテンプレートクラスによってラップされた関数です。

ここではラムダをtaskで包むことに焦点をあてます。実際そういう使い方がほとんどですし。

PPLでタスクを作るには2つの方法がありました。

taskクラスのコンストラクタを使う方法

たとえば整数のリストを受け取って合計を出す関数を考えたとき

auto sum_lambda = [](std::vector<int> nums) -> int {
    int s = 0;
    for(auto val : nums){s += val;}
    return s;
};
auto sum_task = task(sum_lambda(arg_list));

こんな感じになります。 ここでは分けて書きましたが、以下のようにtaskクラスのコンストラクタに直接ラムダを渡してしまうほうが便利かつ安全です。

auto sum_task = task([](std::vector<int> nums) -> int {
    int s = 0;
    for(auto val : nums){s += val;}
    return s;
});

この例を手続き型orオブジェクト指向の考え方のまま読むと「sum_taskはtaskクラスのインスタンス」になります。

しかし「合計を求める"関数"をインスタンス化した」と考えたほうが後々スッキリします。

create_task関数を使う

関数をcreate_task()に渡すことでコンストラクタと同じようにtaskクラスを作ることができます。

UWPのAPI呼び出しなんかは、この関数を使って書かれているサンプルが多かった印象です。 APIの戻り値型はAPIごとに異なっていますが、taskクラステンプレートに戻り値型が適用されるため、あんまり気にせずautoで受ければいいかなと思っています。

ただし、普通は後続の処理(後述のthen)で型を明示的に指定するので、taskクラスインスタンスを直接どうこうするということは意識せずとも良さそうです。

たとえばファイルを開くタスクを作るコードはこうなります。

auto file_get_task = create_task(StorageFile::GetFileFromApplicationUriAsync(uri));

GetFileFromApplicationUriAsyncが返してきたタスクが生成されます。

タスクを実行する

上記の方法で、タスクを作ることはできました。 次は作ったタスクを実行する必要があります。

taskがラップしている関数であっても、C/C++のふつうの関数と同じです。 関数定義だけ書いてもどこかから実行してもらわなければ意味がありません。

wait, when_all, when_anyなどでタスクの実行完了を待つことができます。 結果を拾いたいときはget()で。

上記の方法で生成したタスクに対してそれぞれ呼び出すだけです。

waitとgetは単一のタスクの終了を待つものです。

たとえばこんな風に。

auto sum_task = task([](std::vector<int> nums) -> int {/* 略*/}
sum_task.wait();

when_allは複数のタスクが完了するのを待つ関数です。when_anyは複数のタスクの完了を待つという点では同様ですが、「いずれかが完了するのを待つ」関数です。 以下のコードではテクスチャの読み込み/デコードを並列実行可能なタスクにしたものです。

すべてが並列に実行される保証はありませんが、一例として。

 std::vector< task<void> >  texture_read_tasks;
    for (int i = 0; i < texture_num; i++) {
        auto readtask = task([](int num){/*ごにょごにょ*/});
        texture_read_tasks.push_back(readtask);
    }
    when_all(texture_read_tasks.begin(), texture_read_tasks.end()).then([]() {
        OutputDebugString(L"texture load/decode success\n");
        return;
    });

タスクとタスクをくっつけるthen

UWPのC++/cxでも従来の手続き型のように記述していきたいです。

従来の手続き型のように記述したいというのは、入出力の依存関係があって並列化できないケースなどがわかりやすいです。 たとえばファイル操作のopen/read-write/closeなんかが該当します。

こういうときに役立つのがtaskクラスのメソッドthenです。 タスクの後続タスクを定義するものです。

taskのthenの説明の前にコードを書くときの論理レベルで考えると

  • ファイルを開くタスク
  • ファイルハンドルを使って読みだすタスク
  • ファイルハンドルを閉じるタスク

とタスクを定義できます。これらのタスクの実行は、順序が大切です。

thenはあるタスクの後続タスクを定義するものなので、こういった場面で必須になります。

thenによって数珠つなぎにされたタスクをタスクチェーンと呼ぶらしいです。

タスクチェーンを実行する

thenが返してくるのもタスクです。 どのようなタスクでも実行してあげる必要があります。作ったまま放置ではいけません。

まだ完全に把握できていませんが、私が書いたコードについていえば、task関連の実行時エラーの原因の大半は作ったまま放置でした。

というわけでタスクチェーンの実行です。 これは末尾タスクの終了を待つだけで良いです。

タスクチェーンで「末尾のタスク完了を待つ」ということは、タスクチェーン全体が実行されるのを待つことに相当します。

ここで勘違いしていてすごく詰まったのですが、thenは「後続タスクを定義する」だけであって、「実行する」わけではないです。

なので、作ったタスクチェーンは誰かが実行してあげなければいけません。 (もしくはフレームワークのどこかで一括して実行する機構があるなど)

ラムダを使う理由

タスクを作るのにどうしてラムダを多用するのだろうと自分なりに考えてみました。

私なりの結論としては「task間のデータ受け渡しが安全である」ためと考えました。

C++のラムダは、定義した位置にクロージャオブジェクトが生成されます。 コンストラクタも生成されるので、それを使ってデータ受け渡しが行われます。

すなわち、ラムダの引数がtaskへ受け渡すデータになります。イメージとしてはプロセスへメッセージを送るというほうがしっくりきます。

ここで「安全」といっているのは「taskに渡すデータそのものが競合していない」という前提があったうえでの話です。

その前提を守ったうえでの安全です。

なお「ラムダ使ううえで、これは避けましょう」というのはMS公式からも提示されていました。

https://msdn.microsoft.com/ja-jp/library/dd492427.aspx

要は「taskに渡したラムダの実行完了前に寿命が尽きるオブジェクト(スタック上の変数とか)をキャプチャしないでね」ということですね。

これらの情報をもとに色々コード書いて試行錯誤した結果、スマートポインタ系をラムダの引数に渡すのが一番よさそうだと考えています。

ただし、スマートポインタとはいえ、もしstd::shared_ptrをtaskに受け渡す必要に迫られた場合、「それの寿命が尽きないこと」は言語側で保証できますが「競合をしていないこと」はプログラマが保証しなければいけないので注意が必要です。

理想的な設計

ここまででtaskの基本的な扱いができるようになりました。 次に一歩進んでキレイな設計とは何だろうということについて考えます。

宗教観とか時代の流れとかあるので、ここでの答えはあくまで現時点での私なりの答えです。

関数(をラップしたタスク)を返す関数

急に関数型言語っぽくなりましたね。関数型言語の世界でいう高階関数っぽいものです。

従来の手続き型プログラミングのように値やオブジェクトを返すのではなく関数を返そうみたいなアプローチです。

どうしてこれが良さそうと考えたかというと、

  • 色々試行錯誤した結果から
  • MSのサンプルコードでもこの方式が多い
  • タスクチェーンは呼び出し元が組み立てたいから

最後の以外あまり説得力ないので、最後のだけちょっと書きます。

タスクチェーンを呼び出し元で組み立てたい理由は、従来の手続き型プログラミングでの「ある関数の実行結果を使って、後続の関数を実行する」ように記述していたプログラミング方法の"関数"を"タスク"に置き換えたいからです。

混ぜるな危険

もし「順次処理の関数」と「PPLタスク」を混ぜると次のような面倒な事になってしまいます。

  • 手続き実行結果をもとに後続タスクを実行する
  • タスクの実行結果をもとに手続きを実行する

こういうコードを作ってしまうと「どこがタスクとして実行されて、どこが手続きとしてメインスレッドがら実行されるのか」が見えにくい・わかりにくいものができました。

順次処理とtaskを混ぜたコードは、一応完成しましたが、ちょっと機能拡張しようとかやりはじめたときに手も足もでなくなりました。

taskを返さずに、手続き関数の中でwaitしてはどうかと試みましたが、そうしてしまうと今度は「どの関数がブロッキングで、どの関数がノンブロッキングなのか」がわからなくなりました。

つまりデバッグできないのです。こういうコードは廃棄処分です。

というわけで、UWPの枠組みでやるならできるだけtaskにしたほうがスッキリします。UWPのC++API自体もtask返してくるのが多いですし。

感想

今まで何となくサンプルコードを真似して書いていたtaskですが、高階関数の概念のおかげでスッキリしました。

taskを使って競合を避けるコードを書こうとすると、どことなく関数型言語っぽくなってきた気がするので、また別途記事を書く予定です。

長くなりましたが今回はこれくらいで。

Hololensでカメラの解像度を変更する

前回つくったカード検出器をHololensで使ってみました。かたりぃなです。 処理がやっぱり重いみたいで表示がカクつくくらいに気持ち悪いです。

本当に負荷が原因なのか知るために、画像処理全体の負荷を下げて試すことにします。

簡単に負荷を下げる方法として、カメラの設定(解像度、フレームレートなど)を下げてしまうことにしました。

もちろんアルゴリズムによっては低解像度では使えないなど弊害はありうるので注意が必要です。

簡単に試したい理由は、アルゴリズムの最適化をかける前に「そもそも負荷が低ければアプリとして成立するのか?」を確認したいからです。

個人開発での限りある時間を無駄にはしたくないので。

カメラ(MediaCapture)の初期化

いつもどおりマニフェストファイルにカメラを使うよう設定してから、mediaCaptureクラスを使います。 Platform::AgileはいわゆるスレッドセーフなCLRらしいです。

初期化コードはこんな感じです。

        Platform::Agile<MediaCapture> mediaCapture( ref new MediaCapture() );
        return create_task(mediaCapture->InitializeAsync(settings))
            .then([=]
        {
                // ここでmediacaptureのカメラを起動する
        });        

カメラの解像度を変更

カメラ選択のUIとか作ろうかと思いましたが、面倒なのでやめました。

実験だけのつもりなのでデバッガで出力して、パラメータを書き換えるだけのほうが手っ取り早いです。

コードだけ簡単に。

         // ここまででmediaCaptureはインスタンス化されていること。開始はしてなくてもよい。

            // 負荷が低くなるよう、小さめのサイズのカメラ入力画像を設定する
            auto FindPreviewResolutions = [](Platform::Agile<MediaCapture> cap) -> Windows::Media::MediaProperties::VideoEncodingProperties ^
            {
                auto prop_list = cap->VideoDeviceController->GetAvailableMediaStreamProperties(MediaStreamType::VideoPreview);
                if (prop_list->Size == 0) {
                    // todo
                }

                Windows::Media::MediaProperties::VideoEncodingProperties ^ vp;
                for (auto prop : prop_list) {
                    auto name = prop->GetType()->FullName;
                    if (name == ref new String(L"Windows.Media.MediaProperties.VideoEncodingProperties")) {
                        auto video_prop = static_cast<Windows::Media::MediaProperties::VideoEncodingProperties ^>(prop);
                        char buf[1024];
                        sprintf_s(buf, 1024, "w=%d, h=%d\n", video_prop->Width, video_prop->Height);
                        OutputDebugStringA(buf);
                        if (video_prop->Width == 896) {
                            vp = video_prop;
                        }
                    }
                }
                return vp;
            };
            auto vp = FindPreviewResolutions(mediaCapture);
            // 低解像度のプロファイルがとれたので、設定する

簡単に説明。 cap->VideoDeviceController->GetAvailableMediaStreamProperties(type)で、メディアのプロパティリストが取れます。

このリストの要素はIMediaEncodingPropertiesというインターフェースなので、prop->GetType()->FullNameに目的のプロパティが入っていることを確認します。これはStringなので文字列比較です。

目的の型が入っていることが確認できたら、その型にキャストしてからプロパティを読み出します。

こういうキャストって個人的にはちょっと嫌です。ダウンキャストっぽく見えて。 たぶんただの宗教観なので気にしないことにします。MSのサンプルコードもこういう形になっていたので。

最後に取得したプロファイルをmediaCaptureに設定してあげれば完了です。 こんな感じに。 asyncなのでtaskでラップしてあげるのを忘れずに。

            mediaCapture->VideoDeviceController->SetMediaStreamPropertiesAsync(MediaStreamType::VideoPreview, vp);

というわけでこのコードをHololensの実機に放り込むと、サクサクとカメラ映像を処理できるようになりました。

つまり、カード検出まわりのアルゴリズムをもうちょっと工夫すればなんとかなるレベルというわけですね。 もしくは低解像度で検出できる仕組みを考えるか。

感想

C++らしくテンプレートで分岐できないかなと考えましたが、すぐには無理でした。

というのも、Stringの中身は実行時に確定するので、テンプレートを展開するコンパイル時にそれを判断する処理を入れるのにはちょっと工夫が必要になってしまいます。

ここまで書いて気づきましたが、いわゆるvisitorパターンを実装してあげればキャストなしでいけそうな気がします。 つまり任意のメディア型をacceptするクラスを作る。

しかしvisitorまで書き始めてしまうと今回の目的と比べると大がかりすぎるからやめておきます。

では今回はこれくらいで。

古典的な手法を使ってMTGのカードを検出する

古典的な方法で画像中からMTGのカードを取り出す実験をしてみます。かたりぃなです。

BRISK特徴点のマッチング実験

わかっててダメもとでやってみました。

ダメでした。はい。

f:id:Catalina1344:20170610212059j:plain

説明省略。

BRISKの使い方間違えていた

前回のエントリでBRISK使ったつもりでしたが、間違えていました。 正しくはこうです

 auto brisk = cv::BRISK::create();
    std::vector<cv::KeyPoint> brisk_kp;
    cv::Mat descriptors;
    brisk->detect(img, brisk_kp);
    brisk->compute(img, brisk_kp, descriptors);
    cv::Mat brisk_img;
    cv::drawKeypoints(img, brisk_kp, brisk_img, 255, cv::DrawMatchesFlags::DRAW_RICH_KEYPOINTS);
    cv::imwrite("brisk.jpg", brisk_img);

BRISK特徴量は方向を持っているので、その方向も表示されます。(前回のエントリでは出てなかった)

f:id:Catalina1344:20170610220231j:plain

古典的な手法の概要

単純に画像全体に対して特徴点マッチングをしても、「本来マッチしたいのが何か」というのがあいまいになってしまうため、そのままではうまくいきません。

というわけで、基本に立ち戻ってまずは古典的な方法で検出を試みることにします。

古典的アルゴリズムの概要だけ簡単に説明します。

  1. 前処理としてガウシアンフィルタと二値化を行う
  2. ラベリングをして、それっぽい面積の部分だけ抽出する
  3. canny法による輪郭抽出
  4. hough変換でカードの輪郭を表す直線を求める
  5. 直線同士の交点を求める
  6. できた!

この方法でMTGのカードを複数枚撮影した画像を処理すると、こんな感じになりました。

f:id:Catalina1344:20170610213754p:plain

やってみた詳細

今回もopencvです。 カメラ画像だとテストが大変なので、再現実験をやりやすい静止画でまずは実験します。

前処理

ガウシアンフィルタで細かいノイズを除去して、thresholdで二値化します。 後から知りましたが、ガウシアンフィルタを加えてthresholdする関数もあるらしい。

 cv::Mat img = cv::imread("testimg.jpg", 0);
    cv::Mat gaus_img = img.clone();
    cv::GaussianBlur(img, gaus_img, cv::Size(5,5), 8 );

    cv::Mat threashold_img;
    cv::threshold(gaus_img, threashold_img, 85, 255, cv::THRESH_BINARY_INV);

上記マッチング実験の画像の右側画像に対して処理をかけると、こうなります。

f:id:Catalina1344:20170610212225p:plain

ラベルングと領域抽出

srcが二値化画像。baseimgが元画像です。 結果を可視化するにはbaseimgを書き換えたほうがわかりやすいのでこうしています。

今回はとりあえず静止画でのテストなので、面積500以下の領域は除外しています。

void labeling_test(cv::Mat src, cv::Mat baseimg)
{
    //ラべリング処理
    cv::Mat LabelImg;
    cv::Mat stats;
    cv::Mat centroids;
    int nLab = cv::connectedComponentsWithStats(src, LabelImg, stats, centroids);

    // 小さすぎるエリアを除外する
    auto is_exactly_area = [](cv::Mat stats, int index) {
        int *param = stats.ptr<int>(index);
        int area = param[cv::ConnectedComponentsTypes::CC_STAT_AREA];
        return area > 500 ? true : false; };

    // ラベリング結果の描画色を決定
    std::vector<cv::Vec3b> colors(nLab);
    colors[0] = cv::Vec3b(0, 0, 0);
    for (int i = 1; i < nLab; ++i) {
        colors[i] = cv::Vec3b((rand() & 255), (rand() & 255), (rand() & 255));
    }

    // ラベリング結果の描画
    cv::Mat Dst(src.size(), CV_8UC3);
    for (int i = 0; i < Dst.rows; ++i) {
        int *lb = LabelImg.ptr<int>(i);
        cv::Vec3b *pix = Dst.ptr<cv::Vec3b>(i);
        for (int j = 0; j < Dst.cols; ++j) {
            pix[j] = colors[lb[j]];
        }
    }

    // カードと思われる矩形領域から、傾いていないカードの4点を探す
    for (int i = 1; i < nLab; ++i) {
        if (is_exactly_area(stats, i) != true) { // 適度な大きさでないものは処理しない
            continue;
        }
        int *param = stats.ptr<int>(i);
        int x = param[cv::ConnectedComponentsTypes::CC_STAT_LEFT];
        int y = param[cv::ConnectedComponentsTypes::CC_STAT_TOP];
        int height = param[cv::ConnectedComponentsTypes::CC_STAT_HEIGHT];
        int width = param[cv::ConnectedComponentsTypes::CC_STAT_WIDTH];
        cv::Mat tmp_img(src, cv::Rect(x,y,width,height) );
        hough_test(tmp_img, cv::Point( x, y), baseimg);
    }
}

こうなりました。 f:id:Catalina1344:20170610212250p:plain

上記コードの最後のほうでtmp_imgを作っていますが、こんな感じで取れます。 問題領域外を切り出してしまっているケースもあるので、そのうち対応を考えます。

f:id:Catalina1344:20170610212416p:plain f:id:Catalina1344:20170610212425p:plain f:id:Catalina1344:20170610212430p:plain f:id:Catalina1344:20170610212437p:plain

Canny法でエッジ抽出を行う

ここまでで、二値画像からカードらしき部分は抽出できました。 この二値画像からカードをあらわす長方形を求めます。

二値画像のままではハフ変換をできないのでcannyでエッジ抽出します。

二値化しただけの画像のままでハフ変換できない理由は、有効ピクセルが多すぎるためです。(カード内側や、枠外に値0でないピクセルが多数存在している)

void hough_test(cv::Mat src, cv::Point ofs, cv::Mat base_img)
{
    std::vector<cv::Vec4i>    lines;
    double in_rho = 4.0f;     // 距離分解能
    double in_theta = 3.14f / 180.0f;        // 角度分解能
    int threash = std::min(src.rows, src.cols) / 2;       // 有効投票数
    double min_len = std::min(src.rows, src.cols)/2;
    double max_len = src.rows + src.cols;

    // そのままの二値画像ではハフ変換ができない。
    // cannyを使う理由:
    //   ただの二値画像からのハフ変換では、直線は無限に求められる。(実運用上は分解能が上限となる)
    //   無限になってしまうのは、ハフ変換では値1のピクセルを通る直線を探そうとするため。
    //   すなわち、カードを検出するには領域の境界線(エッジ)のみの二値画像が良い。

    // Cannyエッジ抽出器でエッジを抽出する
    cv::Mat canny_img;
    cv::Canny(src, canny_img, 50.0, 200.0, 3);

これでエッジ画像ができました。 f:id:Catalina1344:20170610212552p:plain

どうでもいいことですが、上記画像とコードの位置関係の問題で、本文のほうが傾いているように見えてしまいます。

目の錯覚ですね。

ハフ変換による直線抽出

MTGのカードを撮影した画像からエッジ抽出した画像(上記)に対して直線検出を施せば、おそらくカードの枠を表す直線が取れるだろうことは予想できます。

というわけで、直線検出です。

opencvのハフ変換には、確率的ハフ変換と標準ハフ変換によるものが実装されています。 ここではアルゴリズムの詳細は置いといて、関数のインターフェースとして2つの違いを考えると、

  • 確率的ハフ変換は"線分"を求める
  • 標準ハフ変換は"直線"を求める

ということです。 今回は直線のほうが都合が良いので、標準ハフ変換で直線検出を行います。

#if 0
   // 確率的ハフ変換による"線分"の検出
   cv::HoughLinesP(canny_img, lines, in_rho, in_theta, threash, min_len, max_len);
   for (auto l : lines) {
       int x1 = l[0] + ofs.x;  // 始点 x 
       int y1 = l[1] + ofs.y;  // 始点 y
       int x2 = l[2] + ofs.x;  // 終点 x
       int y2 = l[3] + ofs.y;  // 終点 y
       cv::line(base_img, cv::Point(x1, y1), cv::Point(x2, y2), cv::Scalar(0, 0, 244));
   }
#endif

    // ハフ変換による"直線"の検出
    std::vector<cv::Vec2f>    lines2;
    cv::HoughLines(canny_img, lines2, 1, CV_PI/180, threash/2);
    for (auto l : lines2) {
        auto rho = l[0];      // 画像左上原点からの距離
        auto theta = l[1];        // 角度
        auto a = cos(theta);
        auto b = sin(theta);
        auto x0 = a * rho;
        auto y0 = b * rho;
        auto pt1_x = cvRound(x0 + 1000 * (-b));
        auto pt1_y = cvRound(y0 + 1000 * (a));
        auto pt2_x = cvRound(x0 - 1000 * (-b));
        auto pt2_y = cvRound(y0 - 1000 * (a));
        cv::line(base_img, cv::Point(pt1_x, pt1_y)+ofs, cv::Point(pt2_x, pt2_y)+ofs, cv::Scalar(0, 0, 255 ) );
    }

これで直線検出ができました。 たとえば一枚目のカードのエッジ画像に対する直線を表示するとこんな感じになります。

f:id:Catalina1344:20170610212944p:plain

直線の交点を求める

直線検出までできました。ただし、1つのエッジ直線に対して複数の直線が検出されていたりして問題がややこしいので、1つの仮定を置きます。 ここまでの処理で求めた直線について、「カードの外枠を表現する長方形をなすための4つの完璧な直線である」と仮定してみます。

そうしたとき、それら直線の交点はおそらく4つは存在すると考えられます。(歪みパラメータや透視投影変換の関係もあって5つ以上になる可能性もありますが、いまは考慮しません。)

というわけで、直線と直線の交点を求めます。

数学的に直線の交点を求める

ここはちょっとだけ数学の力を借ります。

直線の方程式は誰でも知っているものでは

{y = ax + b}

なんかがあります。

次に、2本の直線があるということは、たとえば

{y = 4x + 2}

{y = -2x + 10}

という2つの式が与えられたとき、その交点を求めよ。といったお話です。

連立方程式ですね。つまりこれを解けばいいのです。 ここまで中学数学です。

次に、ハフ変換で得られた直線は上記の表現ではありません。 ハフ変換の直線は、

{r = x*\cos(\theta) + y*\sin(\theta) }

で表現される式で、パラメータは距離rと傾きthetaです。

小難しく書きましたが、直線の表現方法(方程式)が変わっただけです。 つまり、「連立方程式を解くことで交点が得られる」という本質は変わっていません。

この連立方程式をプログラムで解くことを考えます。

OpenCVにも基本的な行列計算は入っているのでこれで済ませることにします。

さて、上記方程式の左辺と右辺をそれぞれ次のように表現することを考えます。

  • 左辺をlhandsという2x1行列で表現する
  • 右辺をrhandsという2x2行列で表現する

これはハフ変換で表現される直線の式をそのまま行列に代入しただけです。 この行列を計算することで、2つの値が得られます。すなわち交点を表すピクセル座標xとyです。

というわけでopencvに行列分解を任せましょう。 検出された直線すべての交点を求めます。

 for(int x = 0;x < lines2.size(); x++){
        for (int y = 0; y < lines2.size(); y++) {
            auto v0 = lines2[x];
            auto v3 = lines2[y];
            float lhandvalue[] = { sin(v0[1]), cos(v0[1]), sin(v3[1]), cos(v3[1]) };
            cv::Mat lhand(2, 2, CV_32FC1, lhandvalue);
            float rhandvalue[] = { v0[0], v3[0] };
            cv::Mat rhand(2, 1, CV_32FC1, rhandvalue);

            cv::Mat ans;
            cv::solve(lhand, rhand, ans);
            std::cout << ans;
            cv::Point   p(ans);
            cv::Point   a(p.y, p.x);
            a += ofs;

            // 交点を書く
            cv::circle(base_img, a, 8, cv::Scalar(0, 255, 255), 3);
        }
    }

opencvにはsolveという便利な関数があるので、これで済ませました。 行列分解の方法は第5引数(ここでは省略したのでLU分解になります)で指定できます。

ofsは原画像からカードのバウンディングボックスまでを表現するオフセットです。 つまり原画像に対して交点を書くので、このofsを加味するだけで良いです。

というわけで、各カード領域に対して直線の交点を求めていった結果こんなのが取れました。

f:id:Catalina1344:20170610213754p:plain

なんとなくよさげですね。

感想と今後の展望

これでカードのコーナー検出っぽいことはできました。

あとはコーナーと候補の点群から、それらを含む最大のバウンディングボックスをとればよさそうです。

あとは

  • それが本当にMTGのカードかどうか

を判別できれば目的に一歩近づけそうです。

この記事を書き終わってから気づきましたが、直線の交点ならベクトルの外積使ってごにょごにょしてあげればよかったのかもしれません。

それでは今回はこれくらいで。

物体検出器をいろいろと試す

Hololensで使える実用的な物体検出器がないか試行錯誤しています。かたりぃなです。

どうして物体検出器?

まず、現状までに作った機能では「特定の条件下」でのみMTGのカードを検出できています。 手順は次の通りです。

  1. ガウシアンフィルタで細かいノイズを除去
  2. キャニー法による輪郭抽出
  3. Hu不変量モーメントで、実際のカードの輪郭と比較

です。

しかし「特定の条件下」というのが曲者で、検出できたりできなかったりと不安定です。 この不安定さのせいで実験の手間がかかってしまいます。

というわけで、真面目に物体検出に取り組んでみました。

結果

今回試した方法だけでは私がやりたいことに届きませんでした。 原因は物体検出の検出率と実行速度のトレードオフがとれないためです。

  • 精度を上げると実行速度が下がる(リアルタイムに検出できない)
  • 高速な検出手法では検出精度が下がる

というわけです。 リアルタイム性を犠牲にしたくはないので、何か妥当な策がないか調べてみました。

物体検出器の種類

とりあえず色々調べてみたことを整理します。

物体検出の方法はたくさんありますが、今回調べた範囲ではこんな感じでした。

方法は大きく分けて2つあって

  1. 特定物体認識によるもの
  2. セグメンテーションによるもの

です。 今回調べたものはほとんどが2に該当します。 今回調べた範囲で、私の目的達成のために使えそうなものは次の3つでした。

  • R-CNN
  • saliency(顕著度)
  • 適当な特徴量と特徴記述

以下の2つは調べてみたものの、負荷が高すぎるのでリアルタイム処理には向いていないです。

  • k-means法
  • グラフカット

最後に、キーワードだけメモします。使えるかもしれない方法論。

  • selective search
  • object proposal
  • objectness-BING

以下は実験の記録です。

実験環境

  • 入力画像は1280x720,グレースケール
  • Windows-PC上で実行

では順にやってみたことを紹介します。

R-CNN

deep-learningです。deep-learningすごい勢いですね。

まず今回やってみたR-CNNについて。

CNNはconbolutional nural networkの略で、畳み込みニューラルネットワークです。

CNNの前についてる"R"は、文脈によって2つあります。

  • 領域抽出で使うRegion-CNN
  • 系列データで使う Recurent-CNN

今回試したのはRegionのほうです。

みんな大好きchainerを作っているPFNETさんがchainercvというものを出してくれているので、これを使うことにします。

公式のマニュアルどおりにインストールして、デモを起動します。

R-CNN(faster-r-cnn)のデモはリポジトリのexample/faster-rcnnディレクトリに入ってます。

こんな感じで画像ファイルを突っ込んであげるだけで、モデルのダウンロードと識別が行われます。

PS C:\myproject\deep_learning\chainercv\examples\faster_rcnn> python .\demo.py .\pic0.jpg --gpu 0

入力 f:id:Catalina1344:20170530225056j:plain

出力 f:id:Catalina1344:20170602231248p:plain

検出できた。すごい。 でも、chainercvさん、、、それテレビモニタちゃう!

なんか簡単にできすぎたので、複数枚のカードも見つけられるか試してみました。

出力 f:id:Catalina1344:20170602231419p:plain

すごい。

でもそれテレビじゃないよ?

テレビだと認識してしまう原因は単純です。 学習済みモデルは"MTGのカード"なんてニッチなオブジェクトを知らないので。 学習した中ではテレビモニタってこんなのだったのでしょう。

ちなみに識別の実行時間を測定してみると2秒くらいでした。 少々厳しいですね。。。

正確性よりもリアルタイム性が欲しいので、別の方法がないか考えてみました。

適当な特徴量と特徴記述

今回特徴量として試してみたのはFASTとBRISKです。

実行時間とコードはこんな感じです。

  • FAST : 30mSec
  • BRISK : 4mSec
 cv::Mat img = cv::imread("testimg.jpg", 0);

    std::vector<cv::KeyPoint> kp;
    cv::FAST(img, kp, 10); // 30msec
    cv::Mat fast_img;
    cv::drawKeypoints(img, kp, fast_img, 255, cv::DrawMatchesFlags::DRAW_RICH_KEYPOINTS);
    cv::imwrite("fast.jpg", fast_img);

    auto brisk = cv::BRISK::create();
    std::vector<cv::KeyPoint> brisk_kp;
    cv::Mat descriptors;
    brisk->compute(img, brisk_kp, descriptors); // 4msec
    cv::Mat brisk_img;
    cv::drawKeypoints(img, kp, brisk_img, 255, cv::DrawMatchesFlags::DRAW_RICH_KEYPOINTS);
    cv::imwrite("brisk.jpg", brisk_img);

FASTで検出した特徴点 f:id:Catalina1344:20170602231217j:plain

BRISKで検出した特徴点 f:id:Catalina1344:20170602231213j:plain

特徴点はそれっぽく出ているのですが、マッチングがうまくいきませんでした。

なぜかというと、画像の特徴量算出をかけると、イラスト部分の特徴点まで抽出されてしまうためです。

イラスト部分まで特徴抽出されてしまうと、カードのフチ画像だけの特徴点とマッチングを試みたとき、どうにもうまくいきません。 Opencvのmatcherが混乱してしまうから?それとも使い方が間違っているのか。

詳細を別の機会に追ってみたいところです。

まあ、この手法は単一マーカーでのARなら良いかもしれません。

しかし私のやりたいことを実現するには一工夫必要そうです。

欲しい機能は「イラスト以外の部分で特徴抽出とマッチング」です。 というのも、カードゲームのイラストは種類が多すぎるためです。

イデアとしては

  • 物体検出、トラッキング、姿勢推定はリアルタイムに行う
  • 実際のイラストの識別はdeep learning側に分類問題として解かせる

といったところです。 トラッキングと姿勢推定さえリアルタイムに動いていれば、「そこに何を表示するか」は多少の遅延があってもエンターテインメント用のアプリとしては成立するだろうと思っています。

遅延が許されるだろうというのは、HoloLensは、装着者(HoloLens本体)とオブジェクトの空間上の位置関係を覚えられるようになっています。

なので、オブジェクトを一度検出してしまえば、あとはオブジェクトの追跡さえできれば良いんじゃないかなと思っています。

というわけで、少し工夫してイラスト部分をマスクすればいいかもと考えました。

しかしマスク画像を作るためにはカードを正しく検出できていなければなりません。 また鶏が先か卵が先かみたいな不毛な話になってしまうので、この手法は一旦保留にします。

ちなみに、以下の条件下であれば、画像中のカードの場所に特徴点が集中していることは確認できました。

  • 模様のない台紙の上に置いたカード
  • 適当なパラメータでcanny法を適用
  • BRISK特徴量を求める

この集中している特徴点を利用できないかと考え、調べたの結果が以下のようなクラスタリングです。

k-means法

いわゆるデータクラスタリングの手法です。 映像中のカードの周辺に特徴点が集中するため、これをクラスタリングにかけてあげればいけるかもしれないという考えからです。

しかし、これは私の目的を達成する手段にはなりませんでした。 まずk-meansという名前のとおり、このアルゴリズムクラスタ数を与えたうえでクラスタリングを行うものです。

カメラからの入力映像に何枚のカードが含まれているかは事前に知ることはできません。

もちろんゲームのプレイ状況をすべて解析できるならクラスタ数を求められるかもしれませんが、敷居が高いです。 クラスタ数を動的に求める方法もあるみたいですが、この手段だけに拘るのもどうかと思い、いったん保留としました。

グラフカット

PRMLの下巻で、グラフカットを使ったノイズ除去の話があったのを思い出しました。 あれを応用できないかと考えました。

  • OpenCV本体のgrabCut
  • OpenCVのcontribにあるximgprocモジュールのグラフカット

この2つを試してみました。 重すぎて今回の用途では使えなさそうでしたが、後者はカードの領域は分離できています。惜しい。

 // 50 sec
    cv::Rect roi(10, 10, 1260, 700);
    cv::Mat dst, mask, bg, fg;
    cv::grabCut(img, dst, roi, bg, fg, 1, cv::GC_INIT_WITH_RECT);
    compare(dst, cv::GC_PR_FGD, mask, cv::CMP_EQ);
    img.copyTo(dst, mask);
    cv::imwrite("graphcat.jpg", dst);

    // 3 Sec
    cv::Mat segmented;
    auto graph_segmenter = cv::ximgproc::segmentation::createGraphSegmentation();
    graph_segmenter->processImage(img, segmented);
    cv::imwrite("graph_segmentation.jpg", segmented);

grabCut f:id:Catalina1344:20170602231230j:plain

graph_segmenter f:id:Catalina1344:20170602231226j:plain

saliencity

日本語では顕著度、顕著性と呼ばれます。

この手法を例えるならば、「ある画像を見たとき、人はまずどこに着目するの」というお話らしいです。 世の中に出回っているけしからん画像も、この理論を応用しているのかもしれませんね。(空想)

さて、この顕著度のアルゴリズムは高速に動作したので、今のところこれが第一候補になりそうです。

顕著度にもいろいろな尺度があるらしいので、2件ほど試してみました。 まだ理屈がよくわかっていないので、動作結果だけ示します。

spectral_residualのほうは特に軽いですね。検出結果を30FPSでのレンダリングに使うなら、リアルタイムに処理できるかもしれません。

 cv::Mat saliency_map;
    auto grained = cv::saliency::Objectness::Saliency::create("FINE_GRAINED");
    grained->computeSaliency(img, saliency_map);// 2 Sec
    cv::imwrite("grained.jpg", saliency_map);
    auto spectral_residual = cv::saliency::Saliency::create("SPECTRAL_RESIDUAL");
    cv::Mat spectral_residual_map;
    spectral_residual->computeSaliency(img, spectral_residual_map);// 20m Sec
    cv::imwrite("spectral_residual.jpg", spectral_residual_map);

SPECTRAL_RESIDUAL f:id:Catalina1344:20170602231237j:plain

FINE_GRAINED f:id:Catalina1344:20170602231223j:plain

感想と今後

思ったより物体検出手法がたくさんあって驚いています。 R-CNNの世界ではselective-searchが流行っているらしいので、次回はこのあたりを調べていきたいと思います。

あとは、もしかしたらHololensから取得できる深度マップをうまく使えば、何か進展があるかもしれません。 それでは今回はこれにて。

DirectXのHLSLシェーダーをデバッグする

DirectXデバッグが捗る便利な機能があるのを知りました。かたりぃなです。

その名も「VisualStudio Graphics Analyzer」。

VisualとGraphicって似たような意味だと思ってしまう私は英語が苦手です。

環境

公式ドキュメント https://msdn.microsoft.com/ja-jp/library/hh873197.aspx

DirectXグラフィクスデバッガでできること

DirectXグラフィクスデバッガを使って次のことができました

これはデバッグが捗りますね。

DirectXグラフィックスデバッガを起動する

VisualStudio2015communityでは次の手順で起動できました

画面上部のメニューから、デバッグ->グラフィックス->グラフィックスデバッグの開始の順に選択。

メニューから操作はこんな感じです。 f:id:Catalina1344:20170526214208p:plain

キーボードショートカットは手元の環境ではAlt+F5でした。(古いVisualStudioのキーバインドにしているので、ほかの環境だと違うかもしれません。)

無事起動すると、上記スクリーンショットでメニューの後ろに見えているタブが開きます。

Graphics Analyzerを起動する

新しく開いたタブの画面下部のカメラアイコン「フレームのキャプチャ」をクリックすると、フレームがキャプチャできます。 キャプチャしたフレーム画像をダブルクリックすると、以下のような画面が起動します。

f:id:Catalina1344:20170526214523p:plain

DirectXに慣れてる人であれば、あとはもう直観で使えそうな見た目ですね。

レンダリングの命令が期待通りに呼び出されていることを確認する

まず画面左の「イベント一覧」ペインは名前のまんまですが、わかりやすくいうと 「C++から呼び出した関数のうち、GPUに設定が行われたもの」と考えておけばよさそうです。 DrawIndexedInstancedとかUpdateSubresourceとか並んでいますね。 まずはここで期待した命令が順序通りに呼び出されているか確認できます。 たとえば、

  • テクスチャの更新(UpdateSubresource)の呼び出しを確認
  • 行列の設定(UpdateSubresource)の呼び出しを確認
  • レンダリング処理(DrawIndexedInstanced)の呼び出しを確認

などがあります。 スクリーンショットの時点でジオメトリ情報がおかしそうという推測はできるので、さらに詳細を見るために次のステップに進みます

レンダリングパイプラインを確認する

先の画面でDrawIndexedInstancedの関数をクリック選択すると、レンダリングパイプラインが表示されます。 どうやら、このレンダリング命令で実行されたパイプラインのようです。

f:id:Catalina1344:20170526214245p:plain

パイプラインの各シェーダーオブジェクトをクリックすると、入出力パラメータが表示されます。 実行されなかったパイプラインステージは「ステージが実行されませんでした。(理由)」と表示されるのでわかりやすいです。 パイプラインステージの実行をデバッガで追いたいときは、右矢印ボタンを押すとデバッガが起動します。 デバッガはVisualStudioでC++デバッグするのと同じように操作できました。

レンダリングに関連するオブジェクトを確認する

GPUに転送したデータが期待したものかどうか確認したいことって多々あります。 頂点バッファ、インデックスバッファ、テクスチャ…。 Graphic Analyzerではこれも確認できました。 先ほど開いたパイプラインステージの表示で、左に「オブジェクトテーブル」があります。これに切り替えると、こんな画面になりました。

f:id:Catalina1344:20170526214551p:plain

GPU側へ設定したものが一通り載ってますね。便利。

ここまでの手順で、入力アセンブラの段階で頂点データがおかしそうというのが見えているので、頂点バッファとインデックスバッファを確認してみたいところです。

とりあえずBlendStateとか今は関係ないので、バッファだけ表示させます。

f:id:Catalina1344:20170526214800p:plain

これでバッファだけ表示されます。C++からみた変数名では引けないのでC++側から識別する情報を見ます。 C++のデバッガで確認してサイズを照らし合わせて、どっちのバッファが何を表しているかを確認しました。

この図でサイズの大きいほうが頂点バッファ、小さいほうはインデックスバッファのようです。

頂点バッファの中身を確認する

頂点バッファの中身も見れます。

先の手順で表示されたオブジェクトテーブルの中から、見たいバッファをダブルクリックするとバイナリで表示してくれます。

この頂点バッファビューはデフォルトでは16bit幅区切りの16進数表示です。 インデックスバッファは整数値だからこれでいいでしょうけれども、今見たいのは頂点バッファなので浮動小数点数です。 浮動小数点数を16進数でさらっと読めるほど私は訓練されていないので、もうちょっと見やすくします。 「形式」のところに型を指定するっぽいのでfloat3と入力してみました。

f:id:Catalina1344:20170526215159p:plain

すごく読みやすくなりました。 型がわからないときはドロップダウンにプリセットがあるので、適当に選択してそれっぽい型を選べばよさそうです。

感想

デバッガを使って確認すると作業早く進むのでいいですね。

今回悩んでいたバグの原因は頂点バッファの入力が正しくGPUに渡っていないようです。

今やっているのは複数個のモデルを表示するところなので、そのあたりの関連が怪しいですね。

ありがとうMicrosoftデバッグが捗ります。