読者です 読者をやめる 読者になる 読者になる

ラズパイ3と microSD あれこれ

ラズパイ 購入したもの

ただの動作報告みたいなものです。

先に結論。Transcend製のmicroSDddコマンドと相性が悪いか、もしくはラズパイと相性の悪いハズレ個体がある模様。どうも東芝製のmicroSDが一番無難。

東芝の経営が大丈夫かというのはともかく、microSDは安定しているようです。

TranscendmicroSD 関連

発生する症状は下記の通り。現象はRaspbianとopenSUSEで発生。SDカードリーダーに問題があるとは思えない。

  • 初回起動時の、起動プロセスのどこかで失敗
  • 問題なく動作するが、再起動後に起動プロセスのどこかでストップする
  • 問題が必ず発生する訳ではない
  • 問題を起こしてmicroSDを他の用途に使う分には不具合は起きなかったりする*1

年属で大量にデータを書き込んだ場合など、熱がこもるとおかしくなるのか、もしくはラズパイのトリッキーな起動プロセスと相性が悪いのかは判断できず。

必ず起きる訳じゃなくて、不定期に発生するのでたちが悪い……。発生すると大抵ファイルの破損を伴うのでddコマンドによるディスクイメージの書き込みからやり直しになる。

結局、セット商品として購入時についてきた海外マイナーブランドのmicroSDが大活躍。東芝製のmicroSDを購入したので移行中です。


以下、TranscendmicroSDに関する不具合事例(ラズパイ2を含む)。

ddコマンドでインストールした場合は上手くいかなくても、NOOBSというツールを使ってセットアップした場合は問題なかったというブログ記事も見た覚えあり。

動作報告情報

やや古い情報も混じっているが下記のページが網羅的にまとめられてる(英語)。

RPi SD cards - eLinux.org

どのメーカーについても相性問題の報告があるのでこのメーカーなら安全とは言い切れないように見える。
別メーカーのOEM製品の可能性もあるし。

ラズパイ2、3ともにToshibaSandiskPanasonicあたりが確実。

ただし、ラズパイ3とSandiskの組み合わせででダメだったという報告例あり

デジカメとかスマホのお下がり品のmicroSDで試してみるのが一番かも。

動作した microSD の詳細情報

手元にあるmicroSD で動作したものを記載しておきます。

Linuxから確認できるデバイス情報をチェックする。方法は、前記のサイトの方法。

$ cd /sys/class/mmc_host/mmc?/mmc?:*
$ echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"

各項目の意味は、カーネルのドキュメント参照。

https://www.kernel.org/doc/Documentation/mmc/mmc-dev-attrs.txt

MIXZA

液晶とラズパイのセット商品に付属してきたやつ。地味に高性能。単品でも購入できるがちょっと未知数。

f:id:atuyosi:20170328003500j:plain:w320

[asin:B01JO5I3RI:detail]

別の販売業者も存在しているが取扱終了になっている。

“MIXZA TOHAOLL” とかで検索されたし。

カード裏面にはMade in TAIWANと記載。

香港の会社みたいだが詳細不詳。だって中国語のページしかないし。

レビューを記載しているサイトにあるパッケージ画像を見る限り、

Produced by: Hong Kong Mixza Industrial Limited.
Agent Company: Shenzhen YEHENO Electronic Limited.

$ echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"
man:0x00009c oem:0x534f name:USD00 hwrev:0x0 fwrev:0x2

2行目がmanufacture id などカードの製造元の情報。番号に対応する企業名は公開されていない。

elinux.orgで確認するとSonyの64GB品と同じ結果が出てる。……そんなアホな。

OEM元の製造工場が同じなのか、あるいはどちらかがコピー品とか?

Toshiba

ググってみた範囲では低速モデルについては結構実績がある。

class 10規格の製品のみ注目すると、読出し速度で40MB/s、48MB/s、90MB/s*2、95MB/sとグレードごとにかなり差がある。270MB/s*3って製品もある。 ラズパイ側のmicroSDカードリーダー自体が高速規格に対応していないので意味がないけど。

東芝 microSDHC 32GB Speed class10/ UHS-I class3 最大90MB/s 高速のEXCERIAシリーズ THN-M302R0320C4 [並行輸入品]

f:id:atuyosi:20170328003625j:plain:w320

「風見鶏 -カザミドリ-」という販売業者から購入。

$ cd  /sys/class/mmc_host/mmc0/mmc?:*
$ echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"
man:0x000002 oem:0x544d name:SA32G hwrev:0x2 fwrev:0x5

製品情報ページを見ると、一部の商品は生産終了になっている。

Sandisk

ダメだったという報告が存在しますが、私の手元にあるものは問題ないです。型番次第なのか個体差なのか不明。

私が入手した海外パッケージ品は問題なく動作しています。

f:id:atuyosi:20170328003852j:plain:w320

「風見鶏 -カザミドリ-」という販売業者から購入。

型番:SanDisk microSDHC Ultra 80MB/s 32GB UHS-I SDSQUNC-032G

$ cd /sys/class/mmc_host/mmc0/mmc?:*
$ echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"
man:0x000003 oem:0x5344 name:ACLCD hwrev:0x8 fwrev:0x0

相性問題の報告のあったモデルとは少なくともnameが違う。

先頭の0x000003はサンディスクらしいので問題ない。どこの工場なのか、とか他は特定できず。

その他

高耐久とか動作保証とかいうのもあるけど、保証期間1年だったり書き込み速度がイマイチだったりして微妙。

当面は東芝製のmicroSDが一番確実ではないでしょうか。

参考URL

  • SDカード : 一部のブランドの、Manufacturer ID (MID/manid) が記載されてる

manufacture id は松下が0x000001東芝0x000002SanDisk0x000003なのは確実なようです。


おしまい。

*1:大量にいデータを書き込まなければ顕在化しないだけかも

*2:製品リストにはないので海外用?

*3:UHS-II インターフェース対応製品使用時

なんとなく ABBYY Cloud OCR SDK を試してみた

API OCR ABBYY

ABBYY Cloud OCR SDK、日本語の情報が全然ないみたいなのでちょっと試してみる。

ぶっちゃけると認識率云々よりも料金体系的にあまり使い勝手がよろしくない。

概要など

ABBYYという会社は画像から文字を読み取るとかテキストの翻訳技術を手がけるソフトウェア会社。ABBYY Fine Reader ぐらいしか知らない。 日本だとシャープとか東芝と提携したというニュースを見た記憶がある。

このエントリで対象にしているのは、老舗のOCRソフトウェアの会社(たぶん)の、文字認識機能を提供するWeb API

ocrsdk.com

リファレンス:OCR SDK API Reference

モバイル向けの別の選択肢

上記のAPIとは別に(Cloudではない)モバイル向けのエンジンもあるみたいだけどそっちはめんどくさそうなのでスルー。

1つ目は方は法人向けで個人開発者は相手にする気なさそう。2つ目の方は販売数5,000までは無料らしいが、CJK(つまりい日中韓)は拡張パッケージだと書いてある。

開発者向けの評価プログラム(free trial)

登録すると月間50リクエスト(A4?)までならクレジットカードの登録不要で試せる。

Tweet したりすると月間利用枠が増えるみたいだが試していない。

とりあえず登録

f:id:atuyosi:20170319174512p:plain

ドメイン名が"abbyy.com"ではないので不安な感じは否めないが、whois的にはバッチリABBYYだったので大丈夫なはずである。

画面中央の"Start free trial now"というボタンをクリックすると、メールアドレスとパスワード、CAPTCHAの入力画面に移動する。

f:id:atuyosi:20170319174544p:plain

まずはPrivacy Notice のリンクをクリックして内容を確認する。

Facebook または Google のアカウントでもいいみたいだが、ひとまずそういう用途向けのメールアドレス*1で登録する。

詳細入力

詳細入力画面は特に変な項目はない。こんなアプリを作りたいんです云々と入れておけば良い。自動的にメールが来るので内容はどうでもいいのではないだろうか。

重要なのはABBYY CLOUD OCR SDK DEVELOPER AGREEMENT 2016

f:id:atuyosi:20170319174735p:plain

“Submit"を押す。

Application ID

Application名を聞いてくるので適当な名前をつける。

f:id:atuyosi:20170319174844p:plain

あとでApplication ID としてAPIの呼び出しの際に必要になるのであまり短くないほうがいいだろうと思う。

“Create Application” を押す。

登録完了

メールでパスワードが送られてくる。そのまま進むには"Proceed"というリンクをクリックすればいい。

f:id:atuyosi:20170319175138j:plain

使ってみる

気軽に試すだけならデモページがあるのでそっちでも良いと思う。

とりあえずサンプルがgithubで公開されているので動かしてみる。

ocrsdk.com/Python at master · abbyysdk/ocrsdk.com · GitHub

もしくは、Code Sample のページからダウンロードする。

Code Samples

残念ながらPython 2.x のスクリプト

準備

process.pyというのが実行用のスクリプトで、残りはライブラリになっている。

Python版のスクリプト環境変数からAPI呼び出しに必要なIDとパスワードを読み取る仕様なので、 ABBYY_APPID と``をセットする。

$ export ABBYY_APPID=登録時に指定したApplicationの名称
$ export ABBYY_PWD=送られてきたメールに記載のパスワード

結果

使用した画像。

f:id:atuyosi:20170319165142p:plain

実行コマンド例。出力フォーマットはテキスト以外に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)がついてる
  • 文字サイズが小さいと認識ミスを起こしやすい?

前回のMicrosoftAPIと比較すると、取りこぼしは少ない(ふりがなだけ)が、細々と認識ミスがある。それと言語を自動判定してくれない。

リファレンスを見てもファイルサイズの制限はなく、解像度の上限しか記載がないので、ある程度解像度の高い画像が前提なのかもしれない。

Knowledge Base によると30MBまでのファイルに対応しているらしい。

Cloud OCR SDK limitations for input files

完璧の「璧」を意図的に「(かべ)」置き換えたケースで素直に壁と認識している。逆にいうと辞書による変換結果の補正はしてないのだろうか?

欠点

何と言っても価格体系。純粋な従量課金がないので営業担当者と相談になってしまう。紙の面積ベースで価格表示されてもなあ。

Plans and Pricing

一応、事前に料金を払うプラン*3と、毎月支払うプランの2種類ある。リクエスト数の上限次第で価格が変わるが、不特定多数に提供するようなアプリなりWebサービスにすることを考えると要お問い合わせコース。

そのほか

Microsoft のAzure 上で動いているらしい。

iOSに関してはCocoaPods 経由で非公式のライブラリ(Objective-C)がインストールできる。詳細はpod search OCRSDKClient。ただし、メンテナンスされていないように見える。

また、github で各種言語のサンプルが公開されている。

GitHub - abbyysdk/ocrsdk.com: ABBYY Cloud OCR SDK

npmのパッケージも存在する。

abbyy-ocr

ユーザーフォーラムが503 Service Unavailableなのは地味につらい。

感想など

文字サイズが小さいと認識結果がよろしくない印象だが出力フォーマットのPDFおよぼdocxは魅力的。やはり価格がネック。そういう点では毎月1000リクエストまで無料のGoogle Cloud Vision APIの方が使い勝手は良さげ。

他のAPIと合わせてJIS第3水準などの漢字のカバー率は別途チェックしておきたい。


ざっくり試した感想としては以上です。

FineReader OCR Pro

FineReader OCR Pro

  • ABBYY
  • 仕事効率化
  • ¥13,800

*1:漏洩しても困らないメールアドレスにしておけば怖くない

*2:機種依存文字だし使用頻度も高くないので問題ない

*3:ただし有効期限あり

Microsoft Cognitive ServicesのOCR API を試す(Computer Vision API) その1

API OCR Microsoft Cognitive

世間は機械学習やら動画解析APIで盛り上がっているような感じですが、いつも通り周回遅れで。

去年から試そうと思いながらアカウントが作れず*1に放置状態だった。今更だけどネタにしてみる。

azure.microsoft.com

以前英語のページから登録しようとした時は、IE以外のブラウザではダメなのか、うまくいかなかった。

c.f. Microsoft Cognitive Services「Computer Vision API」を使ってOCR認識を試す - 吉田の備忘録

実際に日本語の認識も含めてテストしている方のエントリがあるので詳細は下記を参照。

azure-recipe.kc-cloud.jp


以下、目次

概要

そもそもMicrosoftOCR関係のAPIとしては、私の知る限りでは下記の3つ。

この記事で試しているのは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 のアイテムがリストに表示されるのでそれをクリックする。

f:id:atuyosi:20170307010518p:plain

f:id:atuyosi:20170307010248p:plain

説明を読んで「作成」をクリックする。

必要な情報を入力する。注意点としては、無料のプレビューとして利用する場合は、「ユーザーがAPI経由で送信したデータをAPIの改善のためにMicrosoftに提供することに同意」する必要がある。

あとは以下の画像を参考に。

f:id:atuyosi:20170307005436p:plain

APIキーの取得

f:id:atuyosi:20170307014741p:plain

初回作成時は自動的にAPIのダッシュボードに移動するはず。しない場合は、ダッシュボードのサブスクリプション一覧から該当するもの*3を選択する。

f:id:atuyosi:20170307014556p:plain
左側のメニューの一覧から"Key"をクリックするとお目当のAPIキーが表示される。

f:id:atuyosi:20170307015151p:plain

とりあえず試す

リファレンスのサンプルをちょこっと改変して使用します。

画像は過去にGoogle の Vison API を試した時のもの。適当にスクリーンショットを切り出したもの(過去記事参照)。

今更だけどGoogle Cloud Vision APIでOCR - ながいものには、まかれたくない

今更だけど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

f:id:atuyosi:20170316012830p:plain

$ python3 do_ocr_ms.py test1.png
region: 72,69,599,44
line: 72,69,599,18
お前に足りないものは・・・、それは!!情熱思想理念頭脳気品優雅さ動勉さ!!

line: 89,97,318,16
そしてなによりもオ!!速さが足りない!!

認識ミスは一箇所だけ。小書きカタカナのだけで、あとはが3文字に展開されているのみ。非常に優秀。

結果 その2

f:id:atuyosi:20170316015100p:plain

$ 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

f:id:atuyosi:20170316235054p:plain

文字サイズは画面上におけるポイント数、つまり相対サイズでしかないです。

$ 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

f:id:atuyosi:20170317000131p:plain

$ 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 の方は取りこぼしが発生しやすいが、文字と判定した部分については細かい差異を判別している。

MicrosoftAPI は(GoogleAPIで認識できなかった)、「①」とか「②」をきっちり認識している。 一方、NEC特殊文字についてはGoogleOCR API の方が認識できていた*4

おわりに

サンプル数が少ないですが、GoogleOCR API といい勝負。どっちにしろTesseract よりははるかに高精度。

さすがに文字サイズが小さい場合に認識率が良くないのは仕方ない。

あとはもう少し解像度の高い画像データとまとまった文章での比較は試したいと思います。

グダグダですが、(たぶん)続きます。


とりあえずここまで。

関連URL

入門 Python 3

入門 Python 3

*1:ブラウザによるのか、広告ブロッカーのせいだったのかよく分からない

*2:ただし、送信したデータをAPIの精度向上に提供することについて同意する必要がある

*3:プロジェクト名みたいなもの

*4:2文字に展開されるのは仕方ない

SwiftOCRというOCRライブラリを試してみた

Mac OCR Swift iOS

某所で紹介されていたSwiftOCRというライブラリ付属のサンプルを試してみたので一応?

Tesseract より高速、省メモリらしい。一応昨年末の時点でSwift 3にも対応している。

一行のテキスト、それもシリアルナンバーのようなランダム英数字に向いているとのこと。

github.com

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に切り替えてビルドしてやれば起動する。

f:id:atuyosi:20170311090752p:plain

下記のエラーに遭遇した場合は、プロジェクトナビゲーターの画面から"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'

実行した結果。

f:id:atuyosi:20170311092018j:plain

薄いグレーの帯状のエリアにテキストが入るようにして"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"

必ずトレーニングした時と同じ文字列にすること。

f:id:atuyosi:20170312225113p:plain

文字の種類や順序が学習させた時と異なると、"Take Photo"の直後にエラーで落ちる。

f:id:atuyosi:20170312223615j:plain
イマイチ認識できていない上に、単語と単語のスペースを無視している。


f:id:atuyosi:20170312221251j:plain
数字はそこそこ認識するが、小文字との混同が発生している。

ただ、文字を認識した位置と、他の候補の情報を出力してくれるので、前後が数字なら数字の候補を優先するような後処理ロジックを仕込むことは可能。

SwiftOCR.SwiftOCRRecognizedBlob(charactersWithConfidence: [("a", 0.398129016), ("2", 0.382261425), ("3", 0.0667025894)], boundingBox: (262.0, 20.0, 19.0, 27.0)), 

カタカナ

この辺から文字のリストをサクッと借用。

ヒラギノフォントとか游明朝・游ゴシック体あたりを学習させてみた。

「ひらがな」は試す気が起きず。

ァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポマミムメモャヤュユョヨラリルレロヮワヰヱヲンヴヵヶ

長音符(ー)と中黒(・)が抜けているので注意。

f:id:atuyosi:20170312225037p:plain

トレーニングの時点で43%。小書きカナを除去すると改善するはずだけど、それはそれで違う気もする。

全部「ポ」になって使い物にならず。アルゴリズムの限界なのか?

気になった点

  • アルファベットの小文字を学習させると認識率が下がる(例えば"x"と"X"、"v"と”V”など形状が同じで大きさが違うもの)
  • イタリック体を学習させると認識率が下がる(特にBold Italic)
  • 数字とのゼロと小文字の"o"の判別ミス
  • 小文字を学習させると数字の認識率も下がる
  • 文字と文字がくっついていると認識できない
  • 文字と文字のスペースを認識していない
  • 文字列が複数行になっている場合、1行目しか認識しない

最大の欠点は複数行の認識に対応していない点。

まとめ

認識結果が安定しない印象。確かにメモリ消費も少ない。認識対象の文字がアルファベットの大文字と数字、記号の一部に限定できるケースならなんとか使えそう。ただし、二値化処理と行の検出を自力でやる必要がある。

ただ、Tesseract 3.x も単語辞書をオフにしてやれば似たような使い方はできるし、シリアルナンバー用の学習データも存在している*1

Tesseract もバージョン4系はLSTMベースのニューラルネットワークを採用した結果、高速化しているはずなのでリソース消費量だけが長所だとあまりメリットにはならない。


中途半端な記事になってしまったけど今後に期待。

それでは。

*1:Homebrew のtesseactパッケージのオプションで"snum.traineddata"というファイルをダウンロードできる

ラズパイをプロキシサーバー(キャッシュサーバー)として使う( Raspbian & Squid )

Raspberry Pi ラズパイ Squid プロキシ

大したネタではないですが備忘録。


複数の仮想マシンapt(あるいはyumとかHomebrewも含めて)で同じパッケージをダウンロードをするケースが結構ある。

Ubuntu 16.04の仮想マシンが複数あるとして、どっちも同じようにapt upgradeを実行すると、同じ修正パッケージを取得することになり、明らかに無駄。

ホスト側でプロキシサーバーを動かして、透過型プロキシもありかと思ったけど、ちょっと面倒だなってことでラズパイを活用してみる。

構成

仮想化ホストマシンと同じサブネット上に接続したラズパイをキャッシュサーバーとして使う。

スループットの面からすると激しくイマイチだけど、どのみち外向けの回線がWiMAX2+なので問題ない。

ラズパイのイーサネットポートは100MbpsなのでIEEE 802.11nWifiの方が速度は出るかもしれない。

要件

  • 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

クライアント側の設定

ブラウザからは利用するようにしてもいいが、基本的にaptgitで同じファイルをダウンロードするケースを高速化できればいいので環境変数のみセットする。

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にオンオフを切り替えるスクリプトの例が記載されているのでこれを参考にする。

プロキシ設定 - ArchWiki

sudo経由で実行するコマンドは設定しない限り環境変数は引き継がないので注意する(Arch LinuxWikiを参照。

動作状態のチェック

悲しいことにsquidclientコマンドを実行するとIPv6のポートへ接続しようとするのでエラーになる。

$ squidclient -h localhost mgr:mem
client: ERROR: Cannot connect to [::1]:3128: Connection refused

対処法としては-hIPv4のアドレスを指定する。

$ 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

今更な感じもしますが、ないよりマシでしょうってことで。


[2017/03/12 追記] よく考えたらgithub経由のダウンロードはHTTPS経由なんで(プロキシではキャッシュできないので)大した効果はない……。


それではまた。

Tesseract OCR 3.05 のインストールと新機能

Mac OCR tesseract Arch Linux Ubuntu

2月16日付でオープンソースOCRエンジンである Tesseract OCR の3.05がリリースされています。

2月中に記事にしようと思いつつ結局3月になってしまいました。

github.com

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

手頃な画像が見つからないので適当な画像で試します。

f:id:atuyosi:20170308033249p:plain

電子書籍版の『[改訂第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

ちょっと認識ミスト取りこぼしが発生してますが、一列目の一行目のセルから順に出力されています(最後の列が認識したテキスト)。 拡大倍率としきい値処理をちゃんとやればちゃんと認識してくれるはずですが、とりあえず確かこんな感じだったはず。

それぞれの列ですが、levelpar_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用のパッケージをビルドし直すのもありかもしれないが、上書きしてほしくはないのでソースコードからビルドする。

ソースアーカイブgithubから入手する。

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をエディタで編集してmktempgmktempに置き換える必要あり。

Windows

公式ページからリンクされているのは今のところアルファ版であるバージョン4.0になっています。

ドイツの大学の方がビルドしたWindows 向けの開発版バイナリが以下より入手できるようです(3.05devと4.0dev)。ご利用は自己責任で。

github.com

“training tool"に関してはビルドした張本人がWindowsバイナリを使用していないようなので他の環境で。

Cygwin 版の方がトータルで見るとまともかもしれません。

Cygwin Package Search

それぞれの言語別のデータファイル

パッケージ管理ツール経由で取得できる場合はそちらから入手。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タグのツリーから取得する。

f:id:atuyosi:20170307165236p:plain

あるいは、言語コードが明らかな場合は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_PREFIXtessdataディレクトリの一つ上の階層のディレクトリを指定する。

まとめ

もう少しまともな検証用の画像を用意してみたいと思いますがひとまずここまで。

認識精度については3.04系と比較して特に改善していない印象です。バージョン4系に期待しましょうとしか。


何はともあれiOS向けのラッパーの安定板が新規リリースされて欲しいと思う今日この頃です。

それではまた。

*1:非互換云々とメンテナの労力を問題にしていたのは一体なんだったのか

*2:使っていないのでよくわかりません

*3:ファイルハンドラなどの解放もれ

*4: Page Segmentation mode

*5:環境変数ひとつで回避可能

*6:Ubuntuの公式パッケージは違う配置だったはず('/usr/share/tesseract-ocr/tessdata/‘)

言われてみればもう十年

雑記

ちょっとよそのブログで十年前に環境が変わって云々というエントリを読んでしまったので。

言われてみれば痛恨の判断ミスしたのは2007年なのか。

某大学の大学院受験も諦めて内部進学にしてのはこの時期。

そんで研究室選びで失敗したのが4月か。


ある意味十一年前の時点でミスっているとも言えるし、2000年の時点でもミスっていたのかもしれない。

まあ十年前の研究室選択はかなり大きいターニングポイントだったと思う。あの時材料系への未練を捨てて情報系にシフトしていたらどうだったのかと思うとモヤモヤする。

情報系にシフトしていたら大学院の推薦は取れなかっただろうし、研究室によっては某ベンチャーでのアルバイトどころではなかったか。

そしてまたもうそろそろ現状打破のための判断を要求されているのか。

なんというか、3月、4月はどうも鬼門らしい。


おしまい。