なんとなく ABBYY Cloud OCR SDK を試してみた
ABBYY Cloud OCR SDK、日本語の情報が全然ないみたいなのでちょっと試してみる。
ぶっちゃけると認識率云々よりも料金体系的にあまり使い勝手がよろしくない。
概要など
ABBYYという会社は画像から文字を読み取るとかテキストの翻訳技術を手がけるソフトウェア会社。ABBYY Fine Reader ぐらいしか知らない。 日本だとシャープとか東芝と提携したというニュースを見た記憶がある。
このエントリで対象にしているのは、老舗のOCRソフトウェアの会社(たぶん)の、文字認識機能を提供するWeb API。
リファレンス:OCR SDK API Reference
モバイル向けの別の選択肢
上記のAPIとは別に(Cloudではない)モバイル向けのエンジンもあるみたいだけどそっちはめんどくさそうなのでスルー。
Mobile Data Capture Solution proides an alternative way of data input via mobile devices
Free OCR API Open Source for Real-Time Text Recognition on Mobile devices
1つ目は方は法人向けで個人開発者は相手にする気なさそう。2つ目の方は販売数5,000までは無料らしいが、CJK(つまりい日中韓)は拡張パッケージだと書いてある。
開発者向けの評価プログラム(free trial)
登録すると月間50リクエスト(A4?)までならクレジットカードの登録不要で試せる。
Tweet したりすると月間利用枠が増えるみたいだが試していない。
とりあえず登録
ドメイン名が"abbyy.com"ではないので不安な感じは否めないが、whois的にはバッチリABBYYだったので大丈夫なはずである。
画面中央の"Start free trial now"というボタンをクリックすると、メールアドレスとパスワード、CAPTCHAの入力画面に移動する。
まずはPrivacy Notice のリンクをクリックして内容を確認する。
Facebook または Google のアカウントでもいいみたいだが、ひとまずそういう用途向けのメールアドレス*1で登録する。
詳細入力
詳細入力画面は特に変な項目はない。こんなアプリを作りたいんです云々と入れておけば良い。自動的にメールが来るので内容はどうでもいいのではないだろうか。
重要なのはABBYY CLOUD OCR SDK DEVELOPER AGREEMENT 2016。
“Submit"を押す。
Application ID
Application名を聞いてくるので適当な名前をつける。
あとでApplication ID としてAPIの呼び出しの際に必要になるのであまり短くないほうがいいだろうと思う。
“Create Application” を押す。
登録完了
メールでパスワードが送られてくる。そのまま進むには"Proceed"というリンクをクリックすればいい。
使ってみる
気軽に試すだけならデモページがあるのでそっちでも良いと思う。
とりあえずサンプルがgithubで公開されているので動かしてみる。
ocrsdk.com/Python at master · abbyysdk/ocrsdk.com · GitHub
もしくは、Code Sample のページからダウンロードする。
準備
process.py
というのが実行用のスクリプトで、残りはライブラリになっている。
Python版のスクリプトは環境変数からAPI呼び出しに必要なIDとパスワードを読み取る仕様なので、
ABBYY_APPID
と``をセットする。
$ export ABBYY_APPID=登録時に指定したApplicationの名称 $ export ABBYY_PWD=送られてきたメールに記載のパスワード
結果
使用した画像。
実行コマンド例。出力フォーマットはテキスト以外にPDF、XML、docx、RTFが選択できる。自分でAPIのオプションをセットするなら他にも色々できる。
$ python2.7 process.py -l Japanese -txt misc_trial_special.png test01.txt Uploading.. Id = XXXXXXXX-YYYY-XXXXX-ZZZZ-XXXXXXXXXXXX Status = Queued Waiting...Status = Completed Result was written to test01.txt
Id は伏せています。画像をアップロードしたあと、キューに投入してから結果を返すようなAPIになっています。
丸囲み文字 ①②③④⑤⑥⑦⑧⑨⑩ -问日(:特殊文字 睇糙好铖キ。Iン奴2,トンぐ鉍玟”辟、?ン& ^ -似たような漢字の中に紛れ込ませると? 型璧莖型型莖壁璧壁型壁璧壁型型型型(10以) 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(12卩卞) 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(14的) -完璧の璧を壁に変えてみると? 完型な人問はいない。(1〇口1) 完壁な人間はいない(14|31:) -下線 我灌は猫である。名前はまだない。 -傍点 我輩は猫である。名前はまだない。 -その他 吾36は猫である。逛はまだない。 漢字にルビを振る。重&するデータを削除する。順風満帆。
意外とミスってる。画像サイズの問題なのか?
言語の指定方法をJapanese+Englishに変更して再実行。
$ python2.7 process.py -l "Japanese,English" -txt misc_trial_special.png test02.txt
結果は以下。
丸囲み文字 ①②③④⑤⑥⑦⑧⑨⑩ • NEC特殊文字 _糙好铖キ。r奴rトンr鉍_はr辟t ?ン&鉍?r •似たような漢字の中に紛れ込ませると? 型璧莖型型®壁璧壁型壁璧壁型型型型(10pt) 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(12pt) 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(I4pt) •完璧の璧を壁に変えてみると? 完型な人問はいない。(10pt) 完壁な人間はいない(14pt) •下線 我«は猫である。名前はまだない。 •傍点 我輩は猫である。名前はまだない。 •その他 吾Sは猫である。_はまだない。 漢字にルビを振る。重&するデータを削除する。順風満帆。
目につく認識ミスと特徴は以下のとおり。
- 「・(中黒)」がハイフンになったり、「•(U+2022)」になったり安定しない
- 言語の指定が"Japanese"の場合、英単語を認識してくれない
- 背景に色のついている箇所、黒地に白の箇所で認識ミスを起こしている
- ルビを無視している
- NEC特殊文字は認識できていない*2
- 下線とルビ付きのテキストで認識ミスを起こしている
- テキスト形式で出力させるとBOM(Byte Order Mark)がついてる
- 文字サイズが小さいと認識ミスを起こしやすい?
前回のMicrosoftのAPIと比較すると、取りこぼしは少ない(ふりがなだけ)が、細々と認識ミスがある。それと言語を自動判定してくれない。
リファレンスを見てもファイルサイズの制限はなく、解像度の上限しか記載がないので、ある程度解像度の高い画像が前提なのかもしれない。
Knowledge Base によると30MBまでのファイルに対応しているらしい。
Cloud OCR SDK limitations for input files
完璧の「璧」を意図的に「壁」置き換えたケースで素直に壁と認識している。逆にいうと辞書による変換結果の補正はしてないのだろうか?
欠点
何と言っても価格体系。純粋な従量課金がないので営業担当者と相談になってしまう。紙の面積ベースで価格表示されてもなあ。
一応、事前に料金を払うプラン*3と、毎月支払うプランの2種類ある。リクエスト数の上限次第で価格が変わるが、不特定多数に提供するようなアプリなりWebサービスにすることを考えると要お問い合わせコース。
そのほか
Microsoft のAzure 上で動いているらしい。
iOSに関してはCocoaPods 経由で非公式のライブラリ(Objective-C)がインストールできる。詳細はpod search OCRSDKClient
。ただし、メンテナンスされていないように見える。
また、github で各種言語のサンプルが公開されている。
GitHub - abbyysdk/ocrsdk.com: ABBYY Cloud OCR SDK
npmのパッケージも存在する。
ユーザーフォーラムが503 Service Unavailableなのは地味につらい。
感想など
文字サイズが小さいと認識結果がよろしくない印象だが出力フォーマットのPDFおよぼdocxは魅力的。やはり価格がネック。そういう点では毎月1000リクエストまで無料のGoogle Cloud Vision APIの方が使い勝手は良さげ。
他のAPIと合わせてJIS第3水準などの漢字のカバー率は別途チェックしておきたい。
ざっくり試した感想としては以上です。
Microsoft Cognitive ServicesのOCR API を試す(Computer Vision API) その1
世間は機械学習やら動画解析APIで盛り上がっているような感じですが、いつも通り周回遅れで。
去年から試そうと思いながらアカウントが作れず*1に放置状態だった。今更だけどネタにしてみる。
以前英語のページから登録しようとした時は、IE以外のブラウザではダメなのか、うまくいかなかった。
c.f. Microsoft Cognitive Services「Computer Vision API」を使ってOCR認識を試す - 吉田の備忘録
実際に日本語の認識も含めてテストしている方のエントリがあるので詳細は下記を参照。
以下、目次
概要
そもそもMicrosoftのOCR関係のAPIとしては、私の知る限りでは下記の3つ。
- Web API ではないWindows 用のOCRライブラリ(Microsoft OCR Library for Windows Runtime)
- Microsoft Cognitive Services の Computer Vision APIのOCR機能
- Azure Media Services の、Azure Media Analytics OCR
この記事で試しているのは2番目。3番目は動画用のAPIらしい。
Cognitive Services についてはどうやら2015年あたりにProject Oxfordという名称で発表されたシロモノで、MSの画像などのデータを解析して何かをするサービスの総称。
人工知能とか機械学習がどう使われているかはともかく、今時の流行を踏まえて"Cognitive"という単語を使った名称にしたのだろうと思う。
Computer Vision APIはそのうちの画像を解析・認識するAPI。まだ「プレビュー」という位置付けなので仕様や料金体系は変化すると思われます。
日本語の解説は下記のサイトが詳しい。
Microsoft Cognitive Services(マイクロソフト認知サービスAPI)まとめ | 蒼いねずみのお仕事
APIの詳細
公式リファレンスがすっきりしていてわかりやすい(英語だけど)。ページの最後あたりに各言語のサンプルもある。
Cognitive Services APIs Reference
文字の方向などの情報と、文字の含まれる領域、行、単語、という形で結果が返ってくる。行および単語というのはGoogle Vision APIより細かい単位。
日本語は分かち書きしないので、単語イコール文字。
利用条件など
Free と Standard の2種類の料金プランがある。Free の場合はデータをサービスの向上に提供することに同意する必要あり。
Freeの場合はComputer Vision APIについては1分あたり20リクエスト、一ヶ月あたり5000リクエストまで無料で利用可能*2。
APIの有効化およびAPIキーの取得
準備
英語ページのリンクからは登録できなかったので日本語のAzure のページからSkype 用に作成したMicrosoft アカウントで登録。
Computer Vision — 画像処理および画像分析 | Microsoft Azure
流れとしてはAzure にユーザー登録し、そのあとにCognitive Service を有効にする。
注意点としては、SMSによる認証画面では電話番号の先頭のゼロを取った方がスムーズだと思う。先頭のゼロを最後まで電話番号を入力できるが、よく見ると先頭2桁でスペースが入っている。
- uBlock origin とかAdblock は無効化しておく
- 「¥20,500 無料クレジット」とやらは有効期限が30日とG社よりケチくさいので注意が必要。
API の有効化
Azure のダッシュボードにログインし、左側のメニューからプラス記号のアイコンをクリック。検索ボックスに「Cognitive Services API」と打ち込むとMarket Place のアイテムがリストに表示されるのでそれをクリックする。
説明を読んで「作成」をクリックする。
必要な情報を入力する。注意点としては、無料のプレビューとして利用する場合は、「ユーザーがAPI経由で送信したデータをAPIの改善のためにMicrosoftに提供することに同意」する必要がある。
あとは以下の画像を参考に。
APIキーの取得
初回作成時は自動的にAPIのダッシュボードに移動するはず。しない場合は、ダッシュボードのサブスクリプション一覧から該当するもの*3を選択する。
左側のメニューの一覧から"Key"をクリックするとお目当のAPIキーが表示される。
とりあえず試す
リファレンスのサンプルをちょこっと改変して使用します。
画像は過去にGoogle の Vison API を試した時のもの。適当にスクリーンショットを切り出したもの(過去記事参照)。
今更だけどGoogle Cloud Vision APIでOCR その1 - ながいものには、まかれたくない
今更だけどGoogle Cloud Vision APIでOCR (その2) - ながいものには、まかれたくない
改変したスクリプト
リファレンスマニュアルに記載されているPythonスクリプトを以下のように改変。
Modified Python Script for MS Computer Vision API …
実行してみる
APIキーは環境変数から取得するようにしているので、下記のようにして値をセット。
$ export MSCV_API_KEY="取得したAPIキー"
下記のようにファイル名を指定して実行。
$ python3 test.py 画像ファイル名
結果 その1
$ python3 do_ocr_ms.py test1.png region: 72,69,599,44 line: 72,69,599,18 お前に足りないものは・・・、それは!!情熱思想理念頭脳気品優雅さ動勉さ!! line: 89,97,318,16 そしてなによりもオ!!速さが足りない!!
認識ミスは一箇所だけ。小書きカタカナのォ
だけで、あとは…
が3文字に展開されているのみ。非常に優秀。
結果 その2
$ python3 do_ocr_ms.py test4.png region: 69,48,531,568 line: 70,48,120,18 字形が似ている line: 70,102,326,14 叱U+53F1叱U+20B9F叱咤激励叱咤激 line: 69,153,105,17 第ニ水準漢字 line: 69,205,157,18 倅・伜・悴せがれ line: 70,257,285,18 弐萬円虞美人草「朕は国家なり」 line: 69,310,227,18 檳榔(ビンロウ)、刀劍亂舞 line: 70,363,226,17 囹、圀、囿、圄、圉、圏、圍 line: 70,415,389,18 坩堝(るっぽ)、妲己(だっき)、骨嵬(くがい) line: 69,468,105,17 第三水準漢字 line: 69,521,531,17 鄧小平(とうしようへい)、任侠(にんきよう)、王嘉(オウテッ) line: 70,573,232,17 吐囈喇列島(とかられっとう) line: 81,599,484,17 (ロ之島・中之島・平島・諏訪之瀬島・悪石島・小宝島・宝島)
認識ミスは「任俠」の「俠」、「吐噶喇列島」の「噶」。
Google Vision APIで認識できなかった囗(くにがまえ)シリーズをきっちり認識している点は非常に良い。
叱咤激励については、全部U+53F1
で認識されています。厳密には「𠮟咤激励」の方が正しいらしいですが、Google先生もMicrosoft様も一般的に普及した方を提示されるとのこと。
文字化けリスクを考えたら仕方ないのか。しかしOCRエンジンとしてそれでいいのか?
まあ、早くガラケーにトドメを刺してくださいって話。
結果 その3
文字サイズは画面上におけるポイント数、つまり相対サイズでしかないです。
$ python3 do_ocr_ms.py misc_trial2.png region: 70,93,370,403 line: 70,93,44,14 絵文字 line: 71,190,153,17 文字サイズ(6pt-18pt) line: 70,260,164,10 2完第主義、高を、第中既第を line: 70,290,206,12 ふ完主義、憂鬱、誹嵭中傷、薔瓦 line: 70,328,247,15 4.完劈主義、憂鬱、誹謗中傷、薔薇。 line: 71,373,287,17 5.完璧主義、憂鬱、誹謗中、薔薇。 line: 71,422,328,19 6.完璧主義、憂鬱、誹謗中傷、薔薇。 line: 71,474,369,22 7.完璧主義、憂鬱、誹謗中傷、薔薇。
絵文字は全滅。文字サイズが小さい場合(6pt)まったく認識できないみたい。中途半端なサイズ(8、10pt)で「璧」と「傷」の字を認識できていない。
結果 その4
$ python3 do_ocr_ms.py misc_trial_special.png region: 70,31,362,554 line: 71,31,67,13 丸囲み文字 line: 84,73,179,14 ①②③④⑤⑥⑦⑧⑨⑩ line: 75,116,93,13 ・NEC特殊文字 line: 102,158,320,13 朝%空トン弊ドル卩第 line: 75,201,253,13 ・似たような漢字の中に紛れ込ませると? line: 70,242,259,14 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁いOpt) line: 71,284,361,19 壁璧壁壁壁壁壁璧壁壁壁璧壁壁壁壁壁(14pt) line: 75,332,197,13 ・完璧の璧を壁に変えてみると? line: 71,374,170,14 完壁な人問はいない。(10pt) line: 71,393,221,19 完壁な人間はいない(14pt) line: 84,483,211,13 我輩は猫である。名前はまだない。 line: 75,526,35,13 ・傍点 line: 84,568,269,17 我輩は猫である。名前はまだない。 region: 75,616,49,37 line: 75,616,49,13 ・その他 line: 112,641,12,12 は region: 195,640,25,13 line: 195,640,25,13 名前 region: 84,683,362,14 line: 84,683,362,14 漢字にルビを振る。重複するデ-タを削除する。順風満帆。
結果の概要としては以下の通り。
- 丸囲み数字(丸付き数字)は認識できる
- NEC特殊文字の「㍻」や「㍍」の類は認識できていない(「㌔」と「㌦」はそれぞれ2文字で認識)
- 完璧の「璧」と「壁」を判別している(なぜか1行ロストしている)
- アンダーライン・傍点については問題ない
- ルビ(振り仮名)は綺麗に無視
- 青背景はダメだが、黒地に白は認識できる
- という単語が丸ごと認識されていない
文字領域の切り出しに失敗して認識できていない行が二箇所ある。特殊文字については微妙な結果。
Google Vision API との比較
どっちもどっちという印象。ざっくり試した範囲では、Microsoft の方は取りこぼしが発生しやすいが、文字と判定した部分については細かい差異を判別している。
Microsoft のAPI は(Google のAPIで認識できなかった)、「①」とか「②」をきっちり認識している。 一方、NEC特殊文字についてはGoogleのOCR API の方が認識できていた*4。
おわりに
サンプル数が少ないですが、Google のOCR API といい勝負。どっちにしろTesseract よりははるかに高精度。
さすがに文字サイズが小さい場合に認識率が良くないのは仕方ない。
あとはもう少し解像度の高い画像データとまとまった文章での比較は試したいと思います。
グダグダですが、(たぶん)続きます。
とりあえずここまで。
追記(2017/04/05)
表形式データの場合
罫線のない表形式データで試してみたところ、左側からそれぞれの列ごとに上から下に読み取った結果が返ってくる。
上の画像だと左端の数字の列の全ての行のあとに2列目の全ての行、3列目の全ての行という順序でデータが返ってくる。
未加工のJSONデータを取り損ねたので結果のデータは省略。
API の利用停止
ダッシュボードから対象APIをクリックすると Overview という画面に遷移するので、中央の情報表示エリアの左上にあるDelete
をクリックするだけ。
5分ほど各種メニューを彷徨ったが、非常にわかりやすい箇所にあったのでびっくりした。まさかそんなわかりやすい位置にあるとは夢にも思わず。
罫線ありの場合は未検証。
関連URL
- Microsoft Cognitive サービスによる OCR 解析 | 寺田 佳央 - Yoshio Terada
- [C#] Cognitive Servicesで光学文字認識(Computer Vision API OCR) – cloud.config Tech Blog
- 最近の画像認識の実力~MS の最先端の研究成果 Computer Vision API を Python で使ってみた - Qiita
- 作者: Bill Lubanovic,斎藤康毅,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/12/01
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
SwiftOCRというOCRライブラリを試してみた
某所で紹介されていたSwiftOCR
というライブラリ付属のサンプルを試してみたので一応?
Tesseract より高速、省メモリらしい。一応昨年末の時点でSwift 3にも対応している。
一行のテキスト、それもシリアルナンバーのようなランダム英数字に向いているとのこと。
githubのissueトラッカーを見る限り、複数行のテキストのOCRには対応していない模様。
日本語の解説は以下が詳しい(というか他に発見できず)。
Swiftで書かれたOCRライブラリ「SwiftOCR」をiOS実機で試してみた - Qiita
付属のプロジェクトを試す
まずは付属のサンプルを試す。shu223氏の記事によると、アルファベットの大文字と数字のみ学習した状態とのこと。
$ git clone https://github.com/garnele007/SwiftOCR.git $ cd example/iOS/SwiftOCR\ Camera/ $ open SwiftOCR\ Camera.xcodeproj
Xcode が起動するので、スキーマをSwiftOCR Camera
に切り替えてビルドしてやれば起動する。
下記のエラーに遭遇した場合は、プロジェクトナビゲーターの画面から"Provisioning Profile" を設定する。
Signing for "SwiftOCR Camera" requires a development team. Select a development team in the project editor. Code signing is required for product type 'Application' in SDK 'iOS 10.2' Code signing is required for product type 'Application' in SDK 'iOS 10.2' Code signing is required for product type 'Application' in SDK 'iOS 10.2'
実行した結果。
薄いグレーの帯状のエリアにテキストが入るようにして"Take Photo"を押すと画面の上部に認識結果のテキストが表示される。
真ん中下のスライダで拡大倍率を調整できる。
“ISBN4"という文字列に対して"TSBN4"になっている。数字の"3"をすんなり読んでくれないなど不安定。
学習ツールと他の文字種
小文字アルファベット
一度Xcodeを閉じて、SwiftOCR\ Training
に移動。
$ cd ../../OS\ X/SwiftOCR\ Training $ open SwiftOCR\ Training.xcodeproj
テキストフィールドに文字列が入力されているのでアルファベットの小文字と数字ハイフン、円記号を追加。
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-¥0123456789
書体は"Times New Roman" とは “Tahoma” とかメジャーな英語用フォントのみ。
小文字と記号の一部を追加しておもむろに"Start Training"。終了すると表示が元に戻るので、"Test"を実行。
“Save"をクリックするとデスクトップにOCR-Networkというファイルが出力される。
むやみに書体を増やすと"Test"の時点で認識率が下がる……。
トレーニング時点で79.2%は不満だけどとりあえず小文字対応版のデータをコピーして実機テスト(斜体フォントなし)
$ cp ~/Desktop/OCR-Network ../../../framework/SwiftOCR/OCR-Network
パスは環境に応じて変更。
swiftOCR.swift
の開いて、 recognizableCharacters
を修正
public var recognizableCharacters = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-¥0123456789"
必ずトレーニングした時と同じ文字列にすること。
文字の種類や順序が学習させた時と異なると、"Take Photo"の直後にエラーで落ちる。
イマイチ認識できていない上に、単語と単語のスペースを無視している。
数字はそこそこ認識するが、小文字との混同が発生している。
ただ、文字を認識した位置と、他の候補の情報を出力してくれるので、前後が数字なら数字の候補を優先するような後処理ロジックを仕込むことは可能。
SwiftOCR.SwiftOCRRecognizedBlob(charactersWithConfidence: [("a", 0.398129016), ("2", 0.382261425), ("3", 0.0667025894)], boundingBox: (262.0, 20.0, 19.0, 27.0)),
カタカナ
この辺から文字のリストをサクッと借用。
ヒラギノフォントとか游明朝・游ゴシック体あたりを学習させてみた。
「ひらがな」は試す気が起きず。
ァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポマミムメモャヤュユョヨラリルレロヮワヰヱヲンヴヵヶ
長音符(ー)と中黒(・)が抜けているので注意。
トレーニングの時点で43%。小書きカナを除去すると改善するはずだけど、それはそれで違う気もする。
全部「ポ」になって使い物にならず。アルゴリズムの限界なのか?
気になった点
- アルファベットの小文字を学習させると認識率が下がる(例えば"x"と"X"、"v"と”V”など形状が同じで大きさが違うもの)
- イタリック体を学習させると認識率が下がる(特にBold Italic)
- 数字とのゼロと小文字の"o"の判別ミス
- 小文字を学習させると数字の認識率も下がる
- 文字と文字がくっついていると認識できない
- 文字と文字のスペースを認識していない
- 文字列が複数行になっている場合、1行目しか認識しない
最大の欠点は複数行の認識に対応していない点。
まとめ
認識結果が安定しない印象。確かにメモリ消費も少ない。認識対象の文字がアルファベットの大文字と数字、記号の一部に限定できるケースならなんとか使えそう。ただし、二値化処理と行の検出を自力でやる必要がある。
ただ、Tesseract 3.x も単語辞書をオフにしてやれば似たような使い方はできるし、シリアルナンバー用の学習データも存在している*1。
Tesseract もバージョン4系はLSTMベースのニューラルネットワークを採用した結果、高速化しているはずなのでリソース消費量だけが長所だとあまりメリットにはならない。
中途半端な記事になってしまったけど今後に期待。
それでは。
*1:Homebrew のtesseactパッケージのオプションで"snum.traineddata"というファイルをダウンロードできる
ラズパイをプロキシサーバー(キャッシュサーバー)として使う( Raspbian & Squid )
大したネタではないですが備忘録。
複数の仮想マシンでapt
(あるいはyum
とかHomebrewも含めて)で同じパッケージをダウンロードをするケースが結構ある。
Ubuntu 16.04の仮想マシンが複数あるとして、どっちも同じようにapt upgrade
を実行すると、同じ修正パッケージを取得することになり、明らかに無駄。
ホスト側でプロキシサーバーを動かして、透過型プロキシもありかと思ったけど、ちょっと面倒だなってことでラズパイを活用してみる。
構成
仮想化ホストマシンと同じサブネット上に接続したラズパイをキャッシュサーバーとして使う。
スループットの面からすると激しくイマイチだけど、どのみち外向けの回線がWiMAX2+なので問題ない。
ラズパイのイーサネットポートは100MbpsなのでIEEE 802.11n のWifiの方が速度は出るかもしれない。
要件
- LAN内部に設置
- ローカルホストおよび仮想マシン(ゲスト)から接続できればOK
- ある程度大き目のファイル(100MB〜200MBぐらい)もキャッシュさせたい
- ラズパイの microSD の空き領域の有効活用(10GBぐらいはキャッシュに使って問題ない)
インストール
$ sudo apt update $ sudo apt upgrade $ sudo apt install squid $ sudo apt install squidclient
squidclient
は動作状態をチェックするためのツールです。なくても動作します。
設定
$ sudo vi /etc/squid/squid.conf
修正結果の差分は以下のとおり。
$ sudo diff -N /etc/squid/squid.conf.orig /etc/squid/squid.conf 609,611c609,611 < acl localnet src 10.0.0.0/8 # RFC1918 possible internal network < acl localnet src 172.16.0.0/12 # RFC1918 possible internal network < acl localnet src 192.168.0.0/16 # RFC1918 possible internal network --- > #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network > #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network > acl localnet src 192.168.0.0/24 # RFC1918 possible internal network 676c676 < #http_access allow localnet --- > http_access allow localnet 1738c1738 < # cache_mem 8 MB --- > cache_mem 16 MB 1747c1747 < # maximum_object_size_in_memory 8 KB --- > maximum_object_size_in_memory 16 KB 1945c1945 < # cache_dir ufs /var/spool/squid 100 16 256 --- > cache_dir ufs /var/spool/squid 8196 16 256 1988c1988 < # maximum_object_size 20480 KB --- > maximum_object_size 204800 KB 3392a3393 > visible_hostname unknown 4699c4700 < # forwarded_for on --- > forwarded_for off
要点は、
- ローカルネットワーク(192.168.0.0/24)からのアクセスを許可
- キャッシュするファイルのサイズを大きく(
maximum_object_size
) - 使用するディスク領域の上限を大きく(
cache_dir
) - プロキシ経由であることをアクセス先に通知しない(
forwarded_for
)
下記のコマンドで設定ファイルの書式のチェック。
$ sudo squid -k parse
エラーが出なければプロセスを起動。
$ sudo systemctl start squid
設定ファイルのリファレンス:squid : Optimising Web Delivery
有効化
問題なく動くようなら自動的にsquid
起動するようにする。
$ sudo systemctl enable squid
クライアント側の設定
ブラウザからは利用するようにしてもいいが、基本的にapt
やgit
で同じファイルをダウンロードするケースを高速化できればいいので環境変数のみセットする。
VirtualBox 上のゲスト
VirtualBoxの「環境設定」から「プロキシ」タブを選択して「手動設定」で設定する。ゲスト側は気にする必要がない。
コンソール系のツール
一度実行すればあとはコマンド履歴から再実行すればいい。ノートPCを持って外出する場合は環境変数の値を空にする。
export http_proxy=http://プロキシサーバーのIP:3128 export https_proxy=$http_proxy export ftp_proxy=$http_proxy export rsync_proxy=$http_proxy export no_proxy="localhost,127.0.0.1,localaddress,.localdomain.com"
ポート番号をデフォルトの"3128"から変更している場合はそれに合わせて修正する。
手作業で環境変数をセットするのが面倒ならArch Linuxにオンオフを切り替えるスクリプトの例が記載されているのでこれを参考にする。
sudo
経由で実行するコマンドは設定しない限り環境変数は引き継がないので注意する(Arch Linux のWikiを参照。
動作状態のチェック
悲しいことにsquidclient
コマンドを実行するとIPv6のポートへ接続しようとするのでエラーになる。
$ squidclient -h localhost mgr:mem client: ERROR: Cannot connect to [::1]:3128: Connection refused
対処法としては-h
でIPv4のアドレスを指定する。
$ squidclient -h 127.0.0.1 mgr:mem Sending HTTP request ... done. HTTP/1.0 200 OK Server: squid/2.7.STABLE9 Date: Thu, 09 Mar 2017 19:30:52 GMT Content-Type: text/plain Expires: Thu, 09 Mar 2017 19:30:52 GMT X-Cache: MISS from unknown X-Cache-Lookup: MISS from unknown:3128 Via: 1.0 unknown:3128 (squid/2.7.STABLE9) Connection: close Current memory usage: Pool Obj Size Allocated In Use Idle Allocations Saved Hit Rate (bytes) (#) (KB) high (KB) high (hrs) impact (%total)(#) (KB) high (KB) portion (%alloc) (#) (KB) high (KB) (number) (%num) (%vol) (%num) (number) 2K Buffer 2048 2 4 4 0.42 2 2 4 4 100 0 0 2 28 0.52 5.89 93.33 30 4K Buffer 4096 4 16 16 0.35 7 1 4 16 25 3 12 16 61 1.13 25.65 93.85 65 Store Client Buffer 4096 1 4 4 0.05 2 1 4 4 100 0 0 4 3 0.06 1.26 75.00 4 acl 48 11 1 1 0.42 0 11 1 1 100 0 0 0 0 0.00 0.00 0.00 11 acl_ip_data 16 5 1 1 0.42 0 5 1 1 100 0 0 0 0 0.00 0.00 0.00 5 acl_list 12 23 1 1 0.42 0 23 1 1 100 0 0 0 0 0.00 0.00 0.00 23 CacheDigest 24 1 1 1 0.42 0 1 1 1 100 0 0 0 0 0.00 0.00 0.00 1 <skip>
他にも確認できる項目の一覧を表示する場合は、squidclient -h 127.0.0.1 mgr:
を実行。
関連URL
- squid : Optimising Web Delivery
- FrontPage - Squid Web Proxy Wiki
- rasbianにSquidをインストール - Qiita
- プロキシ設定 - ArchWiki
- Squid - ArchWiki
今更な感じもしますが、ないよりマシでしょうってことで。
[2017/03/12 追記] よく考えたらgithub経由のダウンロードはHTTPS経由なんで(プロキシではキャッシュできないので)大した効果はない……。
それではまた。
Tesseract OCR 3.05 のインストールと新機能
2月16日付でオープンソースのOCRエンジンである Tesseract OCR の3.05がリリースされています。
2月中に記事にしようと思いつつ結局3月になってしまいました。
Ubuntu 17.04 の Feature Freeze に間に合わせたいという要望が出た結果、唐突にリリースされたようです*1。
実際のところ、Ubuntu 17.04 に採用されるのかどうかは不明です。
変更点
ざっくりいうと一番のメインはTSV出力。あとは諸々のバグ修正。HTML形式の出力*2についても改善しているようです。あとはバグ対応など。
以下、リリースノートからのざっくり訳。
- hOCR 出力 における改善(微調整)
- 新しい出力オプションとしてTSVを追加
- バージョン 3.04.00における
AnalyseLayout()
メソッドのABI非互換を修正 - text2image tool : すべてのOpenType リガチャが有効に(この機能にはPango 1.38以降が必要)
- Training tools :
assert
関数をtprintf()
とexit(1)
に置き換え - Cygwin 環境における互換性問題を修正
- マルチページのTIFFファイル処理の改善
- 埋め込みpdfフォントについての改善 (pdf.ttf)
- コマンドラインからOCRエンジンモード指定するオプションを追加(
--oem
オプションの追加)) tesseract
コマンドの、オプション指定形式を ‘-psm’ から ‘–psm’ (ハイフン2つ)に変更- 新しいC APIの追加と古いAPIの削除( for orientation and script detection )
- ビルドに必要なautoconf のバージョンを 2.59 に変更
- 不要なコードの削除
- 多数のコンパイラの警告に対処
- メモリリークおよびリソースリーク*3を修正
- ‘Cube’ OCR エンジンのバグ修正
- openCL 関連のバグを修正
- CMake によるビルドに対応
- Windows環境向けに CPPAN supportを追加
オプションの指定方法ですが、従来と同じく-psm
でもエラーにはなりません。将来的には--psm
のようにハイフン2つに移行するはず。
また、--psm
オプション*4に指定できる値が追加されています(詳細はtesseract -h
で確認)。
text2image
コマンドのmac環境におけるバグは修正されたかと思いきや、4系からのバックポートの余波でリグレッションしているので要注意*5。
各種ラッパーの対応状況
すんなり対応したのはJava/Android 系ぐらいで全然進んでいないようです。TSV出力を使わないのであれば、tesseract
コマンドを呼び出すタイプのライブラリは普通に動くと思います。
新機能
新機能であるTSV出力を試してみます。認識結果をタブ区切りテキストとして出力する機能という認識です。普通の文書よりは表とか本の目次のような画像データ向き。
$ tesseract -v tesseract 3.05.00 leptonica-1.74.1 libjpeg 8d : libpng 1.6.28 : libtiff 4.0.7 : zlib 1.2.8
手頃な画像が見つからないので適当な画像で試します。
電子書籍版の『[改訂第7版]LaTeX2ε美文書作成入門』のp.225の表の一部を切り抜いたもの(実際は幅640pxに拡大)。
実際にtesseract
コマンドで試すには、コマンドラインの末尾にtsv
を追加して実行。
$ tesseract -l eng resize_table.tiff stdout tsv 2> /dev/null level page_num block_num par_num line_num word_num left top width height conf text 1 1 0 0 0 0 0 0 640 146 -1 2 1 1 0 0 0 55 11 30 119 -1 3 1 1 1 0 0 55 11 30 119 -1 4 1 1 1 1 0 55 11 30 16 -1 5 1 1 1 1 1 55 11 30 16 79 pbk 4 1 1 1 2 0 55 45 30 16 -1 5 1 1 1 2 1 55 45 30 16 79 pbk 4 1 1 1 3 0 55 79 30 17 -1 5 1 1 1 3 1 55 79 30 17 78 phk 4 1 1 1 4 0 55 113 30 17 -1 5 1 1 1 4 1 55 113 30 17 79 pbk 2 1 2 0 0 0 220 45 18 12 -1 3 1 2 1 0 0 220 45 18 12 -1 4 1 2 1 1 0 220 45 18 12 -1 5 1 2 1 1 1 220 45 18 12 66 it 2 1 3 0 0 0 220 113 18 12 -1 3 1 3 1 0 0 220 113 18 12 -1 4 1 3 1 1 0 220 113 18 12 -1 5 1 3 1 1 1 220 113 18 12 79 it 2 1 4 0 0 0 303 8 209 118 -1 3 1 4 1 0 0 303 8 209 118 -1 4 1 4 1 1 0 303 8 147 20 -1 5 1 4 1 1 1 303 8 97 15 78 Bookman— 5 1 4 1 1 2 402 8 48 20 74 Light 4 1 4 1 2 0 303 43 186 18 -1 5 1 4 1 2 1 303 43 186 18 75 Bookman—Lighfltalic 4 1 4 1 3 0 303 76 155 15 -1 5 1 4 1 3 1 303 76 155 15 67 Baum-Dem! 4 1 4 1 4 0 303 110 209 16 -1 5 1 4 1 4 1 303 110 209 16 72 Boahmul-Dzmfltaflc
ちょっと認識ミスト取りこぼしが発生してますが、一列目の一行目のセルから順に出力されています(最後の列が認識したテキスト)。 拡大倍率としきい値処理をちゃんとやればちゃんと認識してくれるはずですが、とりあえず確かこんな感じだったはず。
それぞれの列ですが、level
とpar_num
というのはよくわかりませんが、ヘッダのconf
は確からしさ、あとはそのまま。
TSV出力させるために必要なのはtessedit_create_tsv
というパラメータなので、さらに挙動をコントロールすることも可能です。
上記のコマンドラインで指定しているtsv
の実態は、tessdata/configs
ディレクトリ配下にあるtsv
という設定ファイルです。
$ cat /usr/local/share/tessdata/configs/tsv tessedit_create_tsv 1 tessedit_pageseg_mode 1
ある程度複雑なレイアウトの画像からテキストを認識する場合に有効だと思います。
各種OS向けパッケージ
Linux
Arch Linux はすでにパッケージが提供されています。
githubのリリースページで配布されているアーカイブは以前と異なり、configure
スクリプトが含まれないので./autogen.sh
を実行する必要がある点に注意。もしくはcmake
を使うことも可能。
Ubuntu 17.04 に採用されるのかと思いきや、17.04 Beta 1 の時点では3.04系のままのようです。
Arch Linux
記憶違いでなければ新バージョンリリースの翌日だか翌々日にはパッケージが提供されていたはず。
$ sudo paceman -S tesseract $ sudo paceman -S tesseract-data-{eng,jpn}
他の言語についてはpacman -Ss tesseract-data
で検索してインストール。なお、向き判定のosd.traineddata
ファイルは(Arch Linux のパッケージの場合)、本体と一緒に/usr/share/tessdata
にインストールされる。
Ubuntu 16.04
バイナリパッケージは提供されていないのでソースからインストール。 Leptonica についてはバージョン 1.74系が必要です。
まずは必要なライブラリを一式インストールする。
sudo apt install autoconf automake libtool sudo apt install autoconf-archive sudo apt install pkg-config sudo apt install libpng12-dev sudo apt install libjpeg8-dev sudo apt install libtiff5-dev sudo apt install zlib1g-dev sudo apt install libleptonica-dev
学習用のツールが必要なら下記もインストールしておく。
sudo apt install libicu-dev sudo apt install libpango1.0-dev sudo apt install libcairo2-dev
せっかくなのでcmake
を使いたいところだが、CMakeLists.txt
というファイルにinstall
ターゲット用の記述がないのでmake install
できない……。
Leptonica のインストール
Ubuntu 17.04用のパッケージをビルドし直すのもありかもしれないが、上書きしてほしくはないのでソースコードからビルドする。
Releases · DanBloomberg/leptonica · GitHub
$ tar zxf leptonica-1.74.1.tar.gz $ cd leptonica-1.74.1/
ソースアーカイブを展開すると、`autobuild`というスクリプトがあるのでまずこいつを実行。
$ ./autobuild $ ./configure $ make -j2 $ sudo make install $ sudo ldconfig
/usr/local
配下にインストールされるはず。
Tesseract のインストール
$ tar zxf tesseract-3.05.00.tar.gz $ cd tesseract-3.05.00.tar.gz
以前は不要だったような気がするが、./autogen.sh
を実行してconfigure
スクリプトを生成。
$ ./autogen.sh $ LDFLAGS="-L/usr/local/lib" CFLAGS="-I/usr/local/include" ./configure --with-training-tools $ make $ sudo make install $ sudo ldconfig
学習用のツールが不要な場合はconfigure
スクリプトの、--with-training-tools
は必要ない。
$ tesseract --version tesseract 3.05.00 leptonica-1.74.1 libjpeg 8d (libjpeg-turbo 1.4.2) : libpng 1.2.54 : libtiff 4.0.6 : zlib 1.2.8
macOS
Homebrew はプルリク投げてみた結果、コメントを削除してマージされた。MacPports は3.04のまま。
以下はHomebrew の場合。
$ brew update $ brew install tesseract --with-training-tools
既存の学習済みの言語データしか使わないのであれば--with-training-tools
は不要。
途中でglib
がらみでエラーになる場合は、表示されるメッセージの通りにする。
Error: You must `brew link glib` before tesseract can be installed
以下のようにbrew link
コマンドを実行してから上記のコマンドを再度実行する。
$ brew link glib
標準では英語とテキストの方向判別データしかダウンロードされないので、/usr/local/share/tessdata
配下にそれぞれの言語別のデータファイルを(3.04用)ダウンロードしてコピーする(後述)。
このパッケージではtesstrain.sh
関連ファイルはインストールされないので必要であればソースアーカイブから適当な場所にコピーする。
バグ対策
mac環境固有のバグ対策。
text2image
を実行する、あるいはtesstrain.sh
を使う場合は、環境変数PANGOCAIRO_BACKEND
に値としてfc
をセットする。
export
コマンドでもいいし、コマンドの先頭にPANGOCAIRO_BACKEND=fc
を付加していい。
参考:
$ PANGOCAIRO_BACKEND=fc ./training/tesstrain.sh --lang jpn --langdata_dir ../github_tesseract/langdata/ --training_text ../github_tesseract/langdata/jpn/jpn.training_text --fonts_dir /Library/Fonts/
それぞれのファイルのパスは環境に応じて修正。
なお、mac環境ではtesstrain.sh
をエディタで編集してmktemp
をgmktemp
に置き換える必要あり。
Windows
公式ページからリンクされているのは今のところアルファ版であるバージョン4.0になっています。
ドイツの大学の方がビルドしたWindows 向けの開発版バイナリが以下より入手できるようです(3.05devと4.0dev)。ご利用は自己責任で。
“training tool"に関してはビルドした張本人がWindowsバイナリを使用していないようなので他の環境で。
Cygwin 版の方がトータルで見るとまともかもしれません。
それぞれの言語別のデータファイル
パッケージ管理ツール経由で取得できる場合はそちらから入手。Homebrew の場合は全部まとめてダウンロードするか、英語と向き判別用のデータだけの2択…。
[2017/03/11 追記]
公式ページに各バージョン(3.03rcを除く)向けのダウンロード用のリンクが記載されたページがあるので必要ならそこからダウンロード。
Data Files · tesseract-ocr/tesseract Wiki · GitHub
[追記ここまで]
GitHub - tesseract-ocr/tessdata at 3.04.00
リポジトリにある最新版は4.00用のファイルなので、3.04.00
タグのツリーから取得する。
あるいは、言語コードが明らかな場合はwget
でURL直打ち。
$ wget https://github.com/tesseract-ocr/tessdata/raw/3.04.00/jpn.traineddata
jpn
の部分を必要な言語に置き換えれば他の言語も取得できます。
ソースからビルドした場合は、/usr/local/share/tessdata
にコピー。それ以外の場合はおそらく/usr/share/tessdata
*6。
もしくは、環境変数 TESSDATA_PREFIX
にtessdata
ディレクトリの一つ上の階層のディレクトリを指定する。
まとめ
もう少しまともな検証用の画像を用意してみたいと思いますがひとまずここまで。
認識精度については3.04系と比較して特に改善していない印象です。バージョン4系に期待しましょうとしか。
何はともあれiOS向けのラッパーの安定板が新規リリースされて欲しいと思う今日この頃です。
それではまた。