善悪の屑(1)~(2)

Amazon取扱していないんだね。

最初の話はグロ度が 外道の歌 よりも高いですね。
話の流れといいインパクトを狙って書かれた感じがします。

にしても、依頼人がもういいよって言っているのに殺しちゃうのってありなんだろうか。
被害者の代行として私刑するって事かと思ったら、カモの私情が入ってきてビックリした。
いや、そっちの方が人間くさいんですけどね。
カモ先輩は子どもが被害にあっているとマジ容赦ないっすね。

そういう意味で、この行動は伏線というかカモの行動原理に根ざすものがありますね。

わりと拷問が凝っているというか、よく思いつくなぁと。
映画のソウみたいな感じがするな。

一家洗脳の主導者なんて避雷針さされて逆さ吊りなんで、最初の話の拷問のパワーアップ版で、どう考えても無理ゲー感がある。

JOJO岸辺露伴が殺人鬼になったようなヤツも早速でてますね。
頭がいいし最後の敵になるのかな。
擬態が上手いというか日常に溶け込んでいるので、どう見つけるんだろう。

あと、元となる事件があるんですね。
ちょっと読んでいるだけで気分が悪くなるレベルです。
読まないのをオススメします。

kameyatakefumi.hatenablog.com

広告を非表示にする

外道の歌(1)~(4)

外道の歌(1) (ヤングキングコミックス)

外道の歌(1) (ヤングキングコミックス)

面白い。
よくできている。
一気に4巻まで読んでしまった。

予備知識なしで読みました。
最初はクズ同士のくだらない縄張り争いなのかなぁっと気が重かったのですが、読んでみると全然違う。

とてもリアルなんだけど、いい感じにフィクションを混ぜて、読みやすいし感情移入しやすい。
エロとかグロとかの描写が薄いのもいいですね。

いわいる悪が悪を裁く内容です。
人間は感情の生き物なので、綺麗事じゃ割り切れません。

これだけ発達した社会だと復讐代行の仕事は本当にありそうです。

4巻の最後の話は賛否ありそうですね。
作者的に解釈を読者に任せる感じの書き方が非常にうまく語りたくなるような内容です。

悪というほどでもないが無責任で想像力のあまりない人間って難しい。
出所後、罪悪感にかられて謝罪したいっとなっていますが、これもあくまでも自分が楽になりたいという自分勝手な感情ですからね。

そういう意味で 命には命をもって償う っていうのは、わかりやすいです。

調べたら2部にあたり、1部は 善悪の屑 っていうタイトルみたいですね。

タイトルが変わると予備知識なしだと察せません。
1部も読もう。

kameyatakefumi.hatenablog.com

広告を非表示にする

JavaCV を使用して 三国志大戦4 の 武将カードの 将器副 復活減少 を判定する

kameyatakefumi.hatenablog.com

前回、解任済み武将カードを判定する事ができました。
今回は個の判定に戻ろうと思います。

個の判定についてはバリバリにプログラムを書いていく事になりそうです。

調べた結果 OpenCV という画像処理系のライブラリが熱いみたいですね。
導入の手軽さから JavaCV を利用します。

将器副 復活減少 は以下になります。
f:id:kameya_takefumi:20171017162323p:plain

将器副 復活減少 が以下の画像に何個あるか判定したいです。
f:id:kameya_takefumi:20171013133242p:plain

指定の画像が対象となる画像のどこにあるのかを判定する処理を テンプレートマッチング というそうです。
最初、言葉がわからずに検索に苦労しました。

以下、JavaCV のテンプレートマッチングのサンプルです。
javacv/TemplateMatching.java at master · bytedeco/javacv · GitHub

テンプレートマッチング と OpenCV の説明では以下がわかりやすかったです。
Pythonでテンプレートマッチング、OpenCVサンプルコードと解説 : ネットサーフィンの壺

サンプルを以下の通り修正して実行しました。

public class TemplateMatching {

    public static void main(String[] args) {

        //read in image default colors
        Mat sourceColor = imread("SR董卓.PNG");
        Mat sourceGrey = new Mat(sourceColor.size(), CV_8UC1);
        cvtColor(sourceColor, sourceGrey, COLOR_BGR2GRAY);
        //load in template in grey 
        Mat template = imread("将器副 復活減少.PNG", CV_LOAD_IMAGE_GRAYSCALE);//int = 0
        //Size for the result image
        Size size = new Size(sourceGrey.cols() - template.cols() + 1, sourceGrey.rows() - template.rows() + 1);
        Mat result = new Mat(size, CV_32FC1);
        matchTemplate(sourceGrey, template, result, TM_CCORR_NORMED);

        getPointsFromMatAboveThreshold(result, 0.947f).stream().forEach((point) -> {
            rectangle(sourceColor, new Rect(point.x(), point.y(), template.cols(), template.rows()), randColor(), 2, 0, 0);
        });

        imshow("Original marked", sourceColor);
        waitKey(0);
        destroyAllWindows();
    }

    public static Scalar randColor() {
        int b, g, r;
        b = ThreadLocalRandom.current().nextInt(0, 255 + 1);
        g = ThreadLocalRandom.current().nextInt(0, 255 + 1);
        r = ThreadLocalRandom.current().nextInt(0, 255 + 1);
        return new Scalar(b, g, r, 0);
    }

    public static List<Point> getPointsFromMatAboveThreshold(Mat m, float t) {
        List<Point> matches = new ArrayList<>();
        FloatIndexer indexer = m.createIndexer();
        for (int y = 0; y < m.rows(); y++) {
            for (int x = 0; x < m.cols(); x++) {
                if (indexer.get(y, x) > t) {
                    System.out.println("(" + x + "," + y + ") = " + indexer.get(y, x));
                    matches.add(new Point(x, y));
                }
            }
        }
        return matches;
    }

}

以下、実行結果です。
f:id:kameya_takefumi:20171017164552p:plain

判定されている!
けど、何重にも判定が行われているようにみえます。

出力結果は以下の通りです。

(103,57) = 0.95975274
(104,57) = 0.9996804
(105,57) = 0.9592217
(159,57) = 0.9535268
(160,57) = 0.9985073
(161,57) = 0.9670713

しきい値 0.947f だと1つにつき3回判定されていますね。
しきい値を上げると、今度は別の画像を読ませたときに、引っかからないものが出てくるでしょう。
悩ましい所です。

私としては しきい値 を緩めで設定して、判定した対象の座標から +-3 ぐらいを1つとみなしてまとめる対応が好きですね。

変数として しきい値 以外に 許容誤差の値 も必要そうです。

OpenCV というか JavaCV は簡単に導入できて素晴らしいですね。
サンプルも豊富だし凄いし楽しい。

Custom Vision Service を使用して 三国志大戦4 の 解任済み武将カードの画像か判定する

kameyatakefumi.hatenablog.com

前回、SR董卓を判定しようとして失敗しました。

Custom Vision Service の説明が結構フワッとしていて、なんとなしに使ってしまいました。
使ってみて改めて考えてみると、画像から特徴を抜き出し概念として捉えているっと思いました。

その概念にタグを設定して識別しているんじゃないかな。

なので、SR董卓といった個ではなく、もっと抽象的なものを判定するのに向いていそうっというわけで 解任済み武将カード を判定する事にしました。

前回、判定に使用したSR董卓は、解任済み武将カードの一覧から一点だけ抽出したものになります。

以下を学習させます。

解任済み武将カード
f:id:kameya_takefumi:20171016164400p:plain

Twitterハッシュタグより適用な画像を判定させてみます。
twitter.com

結果は以下の通り。
f:id:kameya_takefumi:20171016165009p:plain

お!いい感じです。

色々と試してみましたが、明らかに違う画像に対して高得点を付けているものが何点かありました。
Custom Vision Serviceさん、私にはわからない共通点を見出しているんだろうか。

この明らかに違うものを排除していくにはどうするんだろう。
そのタグに対するケースを増やしていき精度をあげるのが王道っぽいですね。
エラーケースを追加して個別に裁く方法は取れないように思える。

あとは、何点以下は除外といった しきい値 の設定ですね。

人間の仕事って良い学習データを集めてきて Custom Vision Serviceさん に与えて、しきい値を調整するっていう泥臭い事なのかな。
なんか農業している気になってきた。

kameyatakefumi.hatenablog.com

Custom Vision Service を使用して 三国志大戦4 の画像を判定する(失敗)

kameyatakefumi.hatenablog.com

Computer Vision API - OCR での読み取り結果が辛いので別の方法から判定できないか試してみる。
良さそうだと思ったのが Custom Vision Service というサービス。

Custom Vision Service | Microsoft Azure

さっそく学習データを用意する。

第1弾 群 SR 董卓
f:id:kameya_takefumi:20171013153956p:plain

将器主 速度上昇
f:id:kameya_takefumi:20171013154022p:plain

以前の画像を読み込みます。
f:id:kameya_takefumi:20171013133242p:plain

結果は以下の通り。
f:id:kameya_takefumi:20171013154251p:plain

は?
わくわくしてただけに心理的なダメージがありますね。

学習データが悪いのか、用途がそもそも間違っているのか、今の知識では判断がつきません。

画像の部分一致的な使い方ではなく、全体一致的な使い方のほうが適していそうですね。
そもそもそういうものでもない気がしますが。
ちゃんとした知識あれば、やらない失敗をしている気がします。

今回やってて思ったのが学習データを集めるのが非常に面倒だという事です。
面倒だと聞いてはいましたが、本当に面倒です。

どういう単位でタグをつけるのか、また処理の全体としてどう位置づけて利用するのかは人間の仕事だと感じますね。

私のやろうとしている事が単純すぎて Custom Vision Service が高度すぎるのかな。

kameyatakefumi.hatenablog.com