#! /usr/bin/env ruby

require 'json'
require 'google/apis/vision_v1'

Vision = Google::Apis::VisionV1
vision = Vision::VisionService.new
#vision.key = "API KEY"
vision.key = ENV['GOOGLE_PRIVATE_KEY']

filename = ARGV[0]

features_list = Google::Apis::VisionV1::Feature.new({max_results: 3, type: "TEXT_DETECTION"})
context = Vision::ImageContext.new({language_hints: ["Japanese"], lant_long_rect: nil})

request = Vision::BatchAnnotateImagesRequest.new(  { requests:  [ features: [ features_list ], image: Vision::Image.new({content: File.read(filename) , image_context: context } ) ] }) 

result = vision.annotate_image(request) do |result, err |


  unless err  then

    result.responses.each do | res |
      puts res.text_annotations[0].description

#      res.text_annotations.each do | ta |
#        puts ta.description
#      end

    end

#    print JSON.pretty_generate(result.to_h)
  else
    puts err
  end

end

必要に応じて32行目をコメントアウトする。

使い方は前回と同じく環境変数をセットして引数に対象画像ファイル名を指定する。trial.rbという名前にしているので、下記のように実行。

$ export GOOGLE_PRIVATE_KEY="APIキー"
$ ruby trial.rb 画像ファイル名

検証その1

まずは絵文字と文字サイズから。

検証画像

本来はちゃんと解像度を固定するところだけどPagesのスクリンーンキャプチャ画像で代用。

f:id:atuyosi:20160906234743p:plain

744 x 566ピクセル。

結果

絵文字
文字サイズ(6pt-18pt)
2,完璧主義、憂鬱、誹謗中傷、薔薇。
3,完璧主義、憂鬱、誹謗中傷、薔薇。
4,完璧主義、憂鬱、誹謗中傷、薔薇。
5·完璧主義、憂鬱、誹謗中傷、薔薇。
6,完璧主義、憂鬱、誹謗中傷、薔薇。
7,完璧主義、憂鬱、誹謗中傷、薔薇。
*元

末尾のゴミはご愛嬌として*1。

絵文字は全滅。6ptの文字列は全く認識されてない。文字の大きさは一定サイズより小さいと認識されないらしい。人間から見て読みづらいサイズは認識しないのか、文字がありそうな領域の検出時点で弾かれているのか。

絵文字を文字とみなすかと言われると微妙なので妥当といえば妥当。

検証その2

画像

f:id:atuyosi:20160907155530p:plain

739 x 751ピクセル。壁の字の羅列箇所は、2、8、12番目の文字だけ完璧の「璧」になっている。逆に意図的に完璧の璧を壁(かべ)にしている。

丸囲み数字とはあまり言わないのかも。Wikipediaでは丸数字、丸付き数字と書いてある。

結果

丸囲み文字
-NEC特殊文字
闢] ㍾ ㍽ ㍻キロ芋ン脊/ラトン7-Myy?"-ドルトンth龍す
,似たような漢字の中に紛れ込ませると?
壁璧壁壁壁壁璧璧壁壁壁璧壁壁壁壁壁(10pt)
壁璧壁壁壁壁辟璧壁壁壁璧壁壁壁壁壁(12pt)
壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(14pt)
完璧の璧を壁に変えてみると?
完璧な人間はいない。(10pt)
完璧な人間はいない(1 4pt)
,下線
我輩は猫である名前はまだない。
傍点
我輩は猫である。名前はまだない。
·その他
吾輩は猫である。 はまだない。
Cehぶうまんばん
漢字にルビを振る。重複するデータを削除する。順風満帆。

中黒（・）の認識が不安定なのと、一部存在しないはずの文字が出ている。なぜか「漢字(かんじ)」と「重複(じゅうふく)」のルビは無視されて、不完全ながら「順風満帆(じゅんぷうまんぱん)」の方は認識されている。

認識結果をエディタに貼り付けて検索をかけると、「璧」と「壁(かべ)」の識別に失敗しているのは10ptのケースと「完」の文字の直後。

f:id:atuyosi:20160907162951p:plain

完璧の「璧」を壁(かべ)に置き換えたものは補正されている。これは前回の叱咤激励と同じ。意図的に「壁(かべ)」の文字にしているので（通常は誤字だけど）意図した文字ではない。

ちょっとサンプルが足りないですが、ざっくりまとめると以下のようになる。

丸囲みの数字は全滅というか無視されている
"㍾㍽㍻" はきっちり認識しているけど、「㌔」が二文字で認識されている以外の単位系の特殊文字は全滅
傍点は無視しているようで対象の文字は認識できている
アンダーラインは句点（。）の認識に失敗している
黒背景に白抜きの文字は認識できない
熟語の場合は認識結果に補正がかかる
文字に振り仮名がふってあったとしても認識できるが、振り仮名自体は完全には認識できない

比較的フォーマルな文書ではNEC 特殊文字は使われないだろうからいいとして丸囲み数字*2はきっちり認識してほしいところ。

特に Tesseract に対する優位点を整理すると、

（文字サイズが小さい場合に）圧倒的な認識率
傍点、下線、ルビによる影響を受けにくい
認識可能な漢字の対応範囲が広い

一応補足しておくと、画像を拡大してやれば Tesseract の方も認識率は改善するはず*3 。ただ Tesseract は傍点、ルビの類は苦手なようなので前処理で除去してしまうか、ルビは独立した行としないとつらい。

個人の主観であって定量データではないです。労力の割に得るものなさそうなので。

検証その3（数式）

まあダメ元でやるだけやってみました。全然ダメです。

LaTeXでと言いたいところだけど面倒なのでPages+MathTypeで逃げる。30日間の評価期間が終了しても"MathType Lite"として数式エディタ機能は使えるとのこと。

画像

f:id:atuyosi:20160907193818p:plain

マクスウェル方程式の積分系と組み合わせの計算式あたりで妥協。 581 x 314ピクセル。

結果

B.dA-0
OB
Vx E
at
E.dA
through
n!
DE
dA

英数字はもう少し認識するかと思いましたが微妙な感じ。括弧はいけるかと思いましたが分数はダメだった模様です。

まとめ

Google Vision API のOCR機能について、①、②のような数字と黒背景かつ白抜きの文字を認識できないことがわかったのは大きな収穫。他の条件（アンダーラインや振り仮名）は画像自体を拡大してやればなんとかなりそう。

認識対象文字をコントロールできないのは難点だけど、それでも Tesseract と比べれば圧倒的な認識率。

傍点などの文字に対する装飾の情報は普通にロストするのでそこは頭に入れておく必要がある。

絵文字と数式は無茶振りとして、天下のGoogle製APIにも不完全な部分があるということでした。

それではまた。

*1:背景色は白色なんで二値化でおかしくはならないはず

*2:これもNEC 特殊文字の一部ではある

*3:というか拡大しないとひどい結果を返してくるときがある。

2016-09-05

OpenCV 3.x のインストール方法(Mac OS X)

OpenCV 画像処理

O'Reilly Mediaの半額セールでOpenCV 3の本を購入したので OpenCVの環境構築についてメモ。

購入したのはEarly-Release版*1です（英語）。年内には読み終わりたいです。

shop.oreilly.com

書籍の正式リリースは2016年11月の模様。

Amazon（予約受付中）：Learning Opencv 3: Computer Vision in C++ With the Opencv Library

一時期Amazon.co.jp側は発売中になっていましたが、間違いだったようです。

調べた範囲では、下記の3通りのアプローチがある。なお、iOSはCocoaPods経由で3.0がインストールできる模様。

Homebrew でインストールする（共用ライブラリとして）
CmakeでMakefileを作成してビルド（GUI/CLI）
付属のPython スクリプトでframework形式のライブラリとしてビルド（内部ではCMakeが利用される）

方法1. はHomebrewさえセットアップしていれば最も簡単なようだが、いろいろとライブラリがセットでインストールされる。Linux環境向けのバイナリに近いものができるように見える。

方法2. についてはCMakeに-G Xcodeオプションを指定してXcode用のプロジェクト形式で出力させればXcodeのGUIからビルドすることもできる。有効にするモジュールをカスタマイズするには一番良さそう。

方法3.はframework形式でビルドされるのでmake install しなくて済むのと、作成した（macOS向けの）ソフトウェアとOpenCVライブラリを一緒に配布する場合はを3.一番確実。難点はライブラリのバージョン管理。

macOS用のアプリを配布する可能性を考慮に入れて、3. の方法でインストール。よって3. のみ記載。C++またはObjective-Cから利用する前提です。

Xcode 7 + OpenCV 3.1 の組み合わせで試しました。MacBook Airのカメラから画像を取り込むサンプルが動くことは確認しています。逆に言うと他はまだ未検証です。あしからず。

参考:Introduction to Framework Programming Guide

準備（共通）
- OpenCV 本体
- opencv_contrib
- CMake
  - (a.) CMake をHomobrewでインストールする。
  - (b.) GUIのインストーラを使用する
Python スクリプトによる framework 形式のビルド
- contrib を無効にしてビルドする場合
- contrib を有効にしてビルドする場合
- ビルドに失敗した場合
- iOS
- カスタマイズ
Xcodeからの利用
- その他
まとめ
参考URL