Python+OpenCV で顔検出 - OpenCV に付属の評価器を試す

画像の中から人の顔が写っている場所を自動的に判定する 顔検出 ってやつをやってみようと思います。

そのために OpenCV という有名なライブラリを使用します。OpenCV 自体は様々な言語と組み合わせて使うことが出来るのですが、今回は自分が書き慣れている Python でいきます。
幸いに Python は OpenCV が公式でサポートしている言語(C++, Python, Java)の一つですしね。

評価器を用意する

顔検出をするためには「画像のこの部分は、人の顔である/人の顔ではない」という判定をする 評価器 という部品が必要です。
この評価器は通常、事前に用意した何千枚というテスト画像をプログラムに読ませ、学習させて(機械学習というやつですね)作らなければいけません。

この機械学習で評価器を用意するという工程にとてつもない労力が掛かります。
人の顔が写ったたくさんの画像を用意して、画像の中の顔の部分を指定するなどの下準備が必要になるからです。

ところが、ありがたいことに OpenCV には標準で多くの種類の評価器が付属しています。
今回は OpenCV 標準の評価器を GitHub から落としてきて使おうと思います。

github.com

顔以外の評価器もあるようですが、今回使うのは以下の7つです。

• haarcascade_frontalcatface.xml
• haarcascade_frontalcatface_extended.xml
• haarcascade_frontalface_alt.xml
• haarcascade_frontalface_alt_tree.xml
• haarcascade_frontalface_alt2.xml
• haarcascade_frontalface_default.xml
• haarcascade_profileface.xml

6つは正面顔(front face)用、1つは横顔(profile face)用です。

基本的な顔検出

シンプルに顔検出して顔の部分を枠で囲むだけならば、非常に少ないコード量で可能です。

import cv2


# 画像の読み込み
image = cv2.imread("img/src/01.jpg")

# 処理速度を高めるために画像をグレースケールに変換
gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

# 評価器を読み込み
cascade = cv2.CascadeClassifier("opencv/data/haarcascades/haarcascade_frontalcatface.xml")

# 顔検出
facerect = cascade.detectMultiScale(
    gray,
    scaleFactor=1.11,
    minNeighbors=3,
    minSize=(30, 30)
)

if 0 != len(facerect):
    BORDER_COLOR = (255, 255, 255) # 線色を白に
    for rect in facerect:
        # 顔検出した部分に枠を描画
        cv2.rectangle(
            image,
            tuple(rect[0:2]),
            tuple(rect[0:2] + rect[2:4]),
            BORDER_COLOR,
            thickness=2
        )

# 結果の画像を保存
cv2.imwrite("img/dest/detected.jpg", image)

import cv2 で読み込んでいるモジュールが OpenCV です。
簡単ですね。

精度を高める

顔検出が簡単に行えるのは分かりました。問題は精度です。
顔検出の間違いには2つのパターンがあります。

• 第一の過誤 - 顔ではない対象を顔であると誤って検出する
• 第二の過誤 - 顔である対象を顔であると正しく検出できない

今回は顔検出の際のパラメーターをいろいろに変えつつ、7つの評価器を比べてみます。

と言いつつ、比べてみるパラメーターは minNeighbors だけです。
minNeighbors は信頼度に関するパラメーターで、値を大きくすると第一の過誤のリスクを抑える代わりに第二の過誤のリスクが増します。つまり、何でもない部分を顔だと勘違いしづらくなる代わりに人の顔の部分も見落としやすくなるわけです。
今回は minNeighbors を 3, 10, 20 と変えてそれぞれの評価器の精度を比べてみます。

評価器毎の精度を比較する

信頼度=3 のとき

というわけでこちらをご覧ください。

• 評価器比較 - 信頼度=3

minNeighbors=3 で各評価器を使って顔検出を走らせた結果です。
ものによっては枠が30個以上描かれて大変なことになってる画像もありますね。これは人の顔ではない対象を誤検出してしまっている状態です。

各評価器の精度を数字で比べましょう。
まずは第一の過誤の割合から。

全部で12枚の画像があり、1枚あたり2.4個の顔が写っています。精度の悪い評価器では1枚あたり19.6カ所もの誤検出があるようです。
その中で frontalface_alt2 と profileface の精度が良いですね。frontalface_alt2 は1枚あたりの誤検出が0.2カ所、非常に優秀です。

第二の過誤についても比べてみましょう。

はい、人の顔を検出できなかった割合は、全て横並びで7%という結果になりました。
とは言っても、さきほどの結果の画像を並べたページを見てもらえれば分かるとおり評価器によっては手当たり次第に枠がついている状態なので、まさに下手な鉄砲も数打ちゃ当たるの結果ですね。

信頼度のパラメーターをいじってもう少し比べてみましょう。

信頼度=10のとき

minNeighbors=10 で試して見ます。誤検出は減り、検出できない顔が増えるはずです。

• 評価器比較 - 信頼度=10

第一の過誤

さすがに誤検出は1枚あたり7カ所ほどに減りましたね。
そして先ほど優秀だった frontalface_alt2, profileface がイマイチになり、今度は frontalface_default が優秀です。はて。

第二の過誤

続いて見落とし率ですが、信頼度を上げ慎重になった代わりに見落としが増えています。
軒並み4,5割は見落としてますね。これはいただけない。

信頼度=20のとき

もう少し試してみましょう minNeighbors=20 です。

• 評価器比較 - 信頼度=20

第一の過誤

再び frontalface_alt2 が優秀です。驚異の誤検出0%。

第二の過誤

5割以上の顔を見落とすようになってしまいました。これ以上 信頼度を上げていっても期待はできないですね。

まとめ

というわけで比較の結果、評価器は frontalface_alt2 を使い minNeighbors=3 の設定で顔検出するのが最も精度を高めることができました。
この設定では人の顔が映った個所を見落とす確率は7%、そして1枚あたり約0.2カ所の誤検出があります。

今回特に検出しづらかったのは、この方のお顔です。

横顔ですし天地も逆になってますからねぇ。このお方の顔を検出するには画像を回転させながら評価器にかけるなどの工夫が必要そうです。

今回の比較のためのコード一式は下記のリポジトリに置いています。

github.com

また、その他のパラメーターによって顔検出の制度がどのように変わるかについても興味深いところですが、それについてはMakoto Koikeさんが書かれた下記の記事でよく研究されていましたので、興味のある方はそちらを参考にしてみてください。

http://workpiles.com/2015/04/opencv-detectmultiscale-scalefactor/

http://workpiles.com/2015/04/opencv-detectmultiscale-minneighbors/

私からは以上です。

Scrapy でエラーハンドリング for v1.1.3 (※一部未解決)

突然ですが Scrapy v1.1.0 から Python 3 に対応して嬉しいですね。これまで Scrapy のために 2.7 で通してきたんで。

さて、今回は Scrapy における エラーハンドリング(例外処理) についてまとめようと思います。

スクレイピングという行為は外部の構造化されていないデータを取ってくるものなので例外はつきものです。
例外が投げられたとき 何となく正常終了したように見せる ことは厳禁です。例外から正しく復帰させるか、または例外が投げられたならば正しく落とすことが重要です。
でないと、その後に例外に気づいて調節→リトライできませんからね。

Scrapy データフローに沿ったエラーハンドリング

スクレイピング中に起こる不測の例外をキャッチするために通常の try ... except 文を使う事はできません。
なぜなら、我々が記述した Spider を実際に起動するのは Scrapy エンジンだからです。

我々は parse() メソッドを実装することはあっても、parse() メソッドに response を食わせて呼び出すことはしません。parse() メソッドの呼び出しは Scrapy エンジンの管轄になります。

では parse() メソッドでの処理中に投げられた例外は誰が面倒を見るのでしょうか？
デフォルトでは Scrapy エンジンが控えめにログに書き出してくれます。が、その動作をカスタマイズすることは可能です。

Scrapy でエラーハンドリングするために (私の観測範囲では) 以下の3種類の方法があります。

1. Request オブジェクトを生成するときに errback を渡す
2. Spider の spider_error シグナルをキャッチする
3. Spider Middleware の process_spider_exception で処理する

それぞれ解説していきます。

1. Request オブジェクトを生成するときに errback を渡す

スクレイピング中、parse() メソッドの中で scrapy.Request のインスタンスを返すと、スクレイピング対象 URL を追加できます。
そのとき errback という名前付き引数に関数を渡してあげると、レスポンスの取得に失敗したときにその関数が呼ばれます。

こんな風に、

# spiders/foo.py

import scrapy
from scrapy import Request


class FooSpider(scrapy.Spider):
    name = "foo"
    allowed_domains = ["httpbin.org"]
    start_urls = (
        "http://www.httpbin.org/",           # ステータスコード: 200
        "http://www.httpbin.org/status/500", # ステータスコード: 500
    )

    def start_requests(self):
        for url in self.start_urls:
            yield Request(
                url,
                callback=self.parse,
                errback=self._errback # 200 以外が返ったときに呼ばれる
            )

    def parse(self, response):
        return {
            "url": response.url,
            "status": response.status,
        }

    def _errback(self, failure):
        self.logger.error("### ERRBACK ###")
        self.logger.error(failure.type)
        self.logger.error(failure.getErrorMessage())

Request オブジェクトの errback にコールバック関数を渡しています。
コールバック関数の _errback() はリクエストに対して 200 以外のステータスコードが返ってきたときに呼ばれます。

上記のサンプルコードで start_urls に指定している httpbin(1) は色々なステータスコードで色々なレスポンスを返してくれる便利なサービスです。
1つめURLは ステータスコード200 が、2つめのURLは ステータスコード500 が返ります。なので2つめのリクエストは parse() ではなく _errback() で処理されることになります。

errback で指定したコールバック関数には failure オブジェクトを渡してもらえるので、エラーメッセージなどを取得することも可能です。
今回のログはこんな感じになりました

2016-09-24 22:35:08 [foo] ERROR: ### ERRBACK ###
2016-09-24 22:35:08 [foo] ERROR: <class 'scrapy.spidermiddlewares.httperror.HttpError'>
2016-09-24 22:35:08 [foo] ERROR: Ignoring non-200 response

ところが、この方法は私の求めている例外処理ではありません。
なぜなら parse() メソッドの実行中に何かしらの例外が投げられても、_errback() が呼ばれることは無いからです。

_errback() が呼ばれるのは

• リクエストに対して 200 以外のステータスコードが返ったとき
• そもそもDNSルックアップに失敗したとき
• リクエストがタイムアウトしたとき

この場合に限ります。

ステータスコード200 が返って、そのあとに parse() で例外が投げられたとしても _errback() は呼ばれません。

この方法は「全部でnページ分のリクエストを投げてmページの取得に失敗した」みたいなログを残すのに使うようです。
あくまでもダウンロード時のエラーに対処する目的ですね。

2. Spider の spider_error シグナルをキャッチする

というわけで、本当の例外処理です。

パース中に例外が投げられると、spider_error というシグナルが発生します。
spider_error シグナルにコールバック関数を紐づけることでエラーハンドリングが可能です。

# spiders/bar.py

import scrapy
from scrapy import signals


class BarSpider(scrapy.Spider):
    name = "bar"
    allowed_domains = ["httpbin.org"]
    start_urls = (
        "http://www.httpbin.org/",
    )

    @classmethod
    def from_crawler(cls, crawler, *args, **kwargs):
        spider = super(BarSpider, cls).from_crawler(crawler, *args, **kwargs)

        # シグナルとコールバック関数を紐づける
        crawler.signals.connect(spider._handle_error, signal=signals.spider_error)

        return spider

    def parse(self, response):
        bar = 1 / 0 # ZeroDivisionError 例外が発生

        yield {
            "url": response.url,
            "status": response.status,
            "bar": bar,
        }

    def _handle_error(self, failure, response, spider):
        self.logger.error("### HANDLE_ERROR ###")
        self.logger.error(failure.type)
        self.logger.error(failure.getErrorMessage())

from_crawler() の中で signals.spider_error シグナルと _handle_error() メソッドを紐づけています。

parse() メソッドの中の bar = 1 / 0 の行で ZeroDivisionError 例外が投げられます。
それが _handle_error() でキャッチされ、ログにエラーの詳細が吐き出される流れです。

ログはこんな感じ、

2016-09-24 22:38:15 [bar] ERROR: ### HANDLE_ERROR ###
2016-09-24 22:38:15 [bar] ERROR: <class 'ZeroDivisionError'>
2016-09-24 22:38:15 [bar] ERROR: division by zero

例のごとく failure オブジェクトを渡してもらえるので、カスタムのエラーログを書き出したりエラー詳細をメールで通知することも可能でしょう。

ところが、この方法ではパース中の例外の通知を受けることしかできません。
そう、エラーからの復帰が出来ない のです。

というわけで続きます。

3. Spider Middleware の process_spider_exception で処理する

最後の方法です。例外をキャッチして、復帰するところまでをやります。
そのためには Spider Middleware を自作する必要があります。

Scrapy のアーキテクチャを紹介でよく見る図ですね。Spider と Scrapy エンジンの間にあるのが Spider Middleware です。

カスタム Middleware を定義することで、

• Downloader から Spider に渡される直前のリクエストオブジェクト
• Spider から Pipeline に渡される直前のアイテムオブジェクト
• Spider から投げられた例外オブジェクト

この3つを加工できるようになります。

3つめのやつが本題ですね。
Spider で投げられた例外を Middleware の中で正常なアイテムにすり替えて Pipeline に流すことができるわけです。

これが try ... except で例外から復帰する処理に最も似ていると思いませんか？

カスタム Middleware 自体は普通の class として書きます。

# middlewares.py

class HandleErrorMiddleware(object):
    def process_spider_exception(self, response, exception, spider):
        spider.logger.error("### PROCESS_SPIDER_EXCEPTION ###")
        spider.logger.error(exception)

        return [{
            "url": response.url,
            "status": response.status,
            "error": str(exception),
        }]

このように、

そして、settings.py の中で有効化してあげます。

# Enable or disable spider middlewares
# See http://scrapy.readthedocs.org/en/latest/topics/spider-middleware.html
SPIDER_MIDDLEWARES = {
    'example.middlewares.HandleErrorMiddleware': 543,
}

そうして、先ほどと同じ Spider を走らせてみると、

2016-09-24 22:54:46 [bar] ERROR: ### PROCESS_SPIDER_EXCEPTION ###
2016-09-24 22:54:46 [bar] ERROR: division by zero
2016-09-24 22:54:46 [scrapy] DEBUG: Scraped from <200 http://www.httpbin.org/>
{'url': 'http://www.httpbin.org/', 'error': 'division by zero', 'status': 200}

このように、bar = 1 / 0 の時点で process_spider_exception() が呼び出されつつ、例外が無かったことにされてアイテムが流れています。

試しに、結果を JSON で保存してみると、

[
  {
    "url": "http://www.httpbin.org/",
    "error": "division by zero",
    "status": 200
  }
]

このようにエラーの詳細をアイテムとして流すことに成功しています。

ところが...

何度目の「ところが」でしょうか。
Spider Middleware の process_spider_exception には バグがあります 。

Spider Middleware のバグ

先ほどの process_spider_exception() ですが、通常のメソッドの中で投げられた例外は正しくキャッチしてくれますが、ジェネレーター関数の中で投げられた例外をキャッチすることができません 。(v1.1.3 時点)

Issue にも挙げられています。

• process_spider_exception() not invoked for generators

どうやら Scrapy が内部的に依存している Twisted の挙動が関係しているらしく一筋縄では解消できないようです。
「help-wanted」というタグがつけられているのが絶望感を煽りますね。

Scrapy では複数のアイテムを抜き出して返すためにジェネレーター関数を多用しますからね。これは痛い。痛すぎる。

まとめ

というわけで Scrapy のエラーハンドリングの方法3種類をまとめてみました。

ちなみに、最後のバグについては、現時点でこれといった解決策を見つけられていません。 ひとまず今後の Isuue の流れを watch しておきます。あー、力が欲しい。

私からは以上です。

【jQueryの基本の"き"】パート4 - jQueryのいろんなバージョン

これまでjQueryの使い方についてねちっこく解説してきましたが...。
今回は「使い方」ではなく「選び方」です。

ビギナーズからよく飛び出す質問「どのバージョンのjQueryを使えばいいの？」について。

jQueryは最新版だけでも全部で8つ

2016年8月末時点でjQuery本体の最新バージョンは バージョン3.1.0 です。
しかし バージョン1系列 と バージョン2系列 についてもサポートが打ち切られているわけではありません。
さらにファイル名に「.slim」や「.min」という文字がつくものも配布されています。

現在 公式サイトで配布されているjQuery を並べてみるとこんな感じ。

• jquery-3.1.0.js
• jquery-3.1.0.min.js
• jquery-3.1.0.slim.js
• jquery-3.1.0.slim.min.js
• jquery-2.2.4.js
• jquery-2.2.4.min.js
• jquery-1.12.4.js
• jquery-1.12.4.min.js

うむ、困りましたね。
少しずつ噛みくだきながら解説していきます。

.min の有無はファイルサイズの違い(機能は同じ)

「.min」が付くものと付かないものは、コードが圧縮されているか圧縮されていないかという違い があります。

JavaScript はコードの途中とちゅうに改行やスペースを入れても動作自体は変わりません。
これは HTML や CSS と同じ性質ですよね。

そのために「.min」無しバージョンでは適宜改行を入れ込んで読みやすく整形されています。
逆に「.min」付きバージョンではできる限り改行もスペースも入れずに書かれているため、ファイルサイズが小さくなっています。

というわけで「jquery-3.1.0.js」と「jquery-3.1.0.min.js」などは基本的に同じ機能を持っています。
どちらを使っても同じです。

ファイルの読みやすさを重視するならば「.min」無しを、サイズの小ささを重視するならば「.min」付きを選べばいいでしょう。
ただ、jQuery本体のソースコードを読みたくなることってほとんど無いので、基本的には「.min」付きで充分 だと思います。

参考に、

• jquery-3.1.0.js - 263,767 バイト
• jquery-3.1.0.min.js - 86,351 バイト

1/3 ほどのファイルサイズになってますね。軽い！

バージョン1系列とバージョン2系列の違いは対応しているブラウザの違い

バージョン1系列とバージョン2系列は 対応しているブラウザの違い です。
バージョン2系列は比較的新しいブラウザでしか動きませんが、バージョン1系列を使えば古いブラウザでも動きます。

公式サイト によれば、バージョン2系列の対応ブラウザは、

• Google Chrome の最新版とひとつ前のバージョン
• Microsoft Edge の最新版とひとつ前のバージョン
• Firefox の最新版とひとつ前のバージョン
• Internet Explorer 9~11
• Safari の最新版とひとつ前のバージョン
• Opera の最新バージョン
• (モバイル)Android 4.0以上の標準ブラウザ
• (モバイル)iOS 7以上のSafari

だそうです。

バージョン1系列を使えば、ここにさらに古いブラウザが加わります。

• Internet Explorer 6~8
• Opera 12.1x (Prestoエンジンを積んだバージョン)
• Safari 5.1以上

特に重要なのは Internet Explorer に対応するかどうかでしょう。
IE8 などでも問題なく表示できるサイトにしようと思えば、jQueryのバージョン1.12を使うべきです。

ただし、対応しているブラウザが多いことはメリットだけではありません。
バージョン1系列は古いブラウザに対応させるためにファイルサイズが大きく、処理速度も遅いのです。

ちなみに、対応ブラウザって時代によって変わります

さて、ここで要注意なんですが、
さきほど紹介した対応ブラウザはあくまでも2016年8月末時点のものです。

時が流れて「こんな古いブラウザ誰も使ってないよね」というようなブラウザが出てくれば、そのブラウザのサポートは打ち切られるはずです。
公式サイト では常に対応ブラウザについての情報が公開されています。
定期的に情報を確認して、最新のブラウザ事情にキャッチアップしてみてください。

バージョン2系列とバージョン3系列の違いは設計の違い

バージョン2系列とバージョン3系列では対応しているブラウザは同じです。
が、バージョン3系列は2016年現在のブラウザ事情や JavaScript 事情に合わせて 設計のレベルから見直されて作り直されています 。

そのために機能の面でも大幅な違いがあり、jQuery バージョン2.2.4 を想定して作られたプラグインとjQuery バージョン3.1.0を組み合わせて使うと正常に動作しないかもしれません。

バージョン2系列からバージョン3系列に上がるあたって、もっとも大きく変わったのは .hide() と .show() が廃止されたことです。

.hide() はページ上の要素を見えなくする機能、反対に .show() は見えなくなっていた要素を表示する機能です。
これらがバージョン3系列では廃止されています。

jQueryの開発チーム曰く、要素を隠したり再表示したりしたいとき今後は、

.hide {
  display: none;
}

というような CSS を用意したうえで、隠したい要素に class="hide" を付与するようにして対応してほしいとのことです。

.hide() と .show() はこれまでにも多用されてきた機能だけに、その影響範囲は大きそう です。
バージョン3系列を採用する前に、自分が使いたいjQueryプラグインがバージョン3系列に対応しているかどうか調べる必要があります。

その代わり、バージョン3系列ではこれまで以上の性能向上が謳われていますよ。

.slim 付きは必要最低限の機能だけが含まれている

バージョン3系列にはさらにファイル名に「.slim」が付くものと付かないものがあります。
「.slim」付きバージョンは、「.slim」無しバージョンから Ajax やアニメーション関連機能など 一部の機能を削除することで究極の軽量化を目指したバージョン です。

「機能を削除する」なんてそんなことして大丈夫なんでしょうか？
大丈夫です。jQueryは本当に多機能で、中には「この機能最近あんまり使う機会無いよなぁ」というようなものもあるのです。

「.slim」付きバージョンはそういった機能を思い切って削除しています。

ちょっと余談ですが、Ajax やアニメーション関連機能がなぜ最近あんまり使う機会が無いのかお話ししましょう。

当たり前に使われるようになったがために標準機能に組み込まれた Ajax

Ajax とは、ユーザーがページを見ている最中にブラウザとサーバーがやり取りするための仕組みです。

実は Ajax 自体は2005年よりも前からブラウザに標準で存在した伝統的な機能でした。
しかし使い方が少々煩雑で初心者にはなかなか扱いづらいものだったのです。

そんな扱いづらい Ajax を断然扱いやすくする機能を提供したのもjQueryの功績でした。

それから時は流れ...
現在では Ajax はWebサイトを作るうえで欠かせない機能になっています。多くのサイトで今日も Ajax は多用されています。

そして需要の増加に伴って最新のブラウザでは、扱いが煩雑な Ajax の代わりに、より高機能でより扱いやすい Fetch API という機能が標準搭載されるようになってきています。

実際「もう Ajax のためにjQuery持ち出さなくていいよね、Fetch API使おうぜ」という考え方が現在の主流になりつつあります。

アニメーションの舞台は JS から CSS へ

もう一つアニメーション関連機能についてです。

こちらはご存知の方も多いでしょう。
CSS3 でアニメーション関連のプロパティ transition, animate などが追加されたおかげで、ページ上で要素をアニメーションさせることはとても手軽になりました。

CSSアニメーションはブラウザ自身が動作を制御してくれるため負担が少なく、レスポンシブデザインにも対応しやすいという利点があります。
「いまどきjQueryでアニメーションなんて流行らねぇんだよ、時代はCSSアニメーションだ！」そんな声が聞こえてきそうです。

---

このような時代背景から、わざわざjQueryでやる必要もなさそうな機能が「.slim」付きバージョンでは削除されています。
最新のWeb制作事情にしっかりと追いつけている人であれば、「.slim」付きバージョンも魅力的に見えるでしょう。

参考に再びサイズ比べを、

• jquery-3.1.0.js - 263,767 バイト
• jquery-3.1.0.min.js - 86,351 バイト
• jquery-3.1.0.slim.min.js - 68,952 バイト

うーんコンパクト！

まとめ

ざっくりまとめます。

• 基本的に「.min」付きのほうがファイルサイズ小さくて素敵
• 古いブラウザにも対応したいならバージョン1系列を使わざるを得ない
• プラグインなどがバージョン3系列に対応してそうなら、バージョン3系列を使ってみよう
• 慎重になるなら様子見でバージョン2系列かなぁ...
• 最新のトレンドに乗っかって究極の最小化を目指すなら、バージョン3系列の「.slim」付きで

こんな感じになりますかね。

私からは以上です。

jQueryの基本の"き" シリーズ

blog.mudatobunka.org

blog.mudatobunka.org

blog.mudatobunka.org