【文字認識】OCRソフト【 自炊 】 [無断転載禁止]©2ch.net

光学文字認識（こうがくもじ にんしき、Optical character recognition）ソフト

iosかあ残念持ってないや
GCV使用だからって泥アプリとは限んないやね

Windowsアプリ興味あるんで
OCRアプリ作ってみようかなと思います。
今ゲームアプリ作ってるんで
平行しながらになるとは思いますが。

がんばれー

ocrで自炊完全テキスト化なんて幻だろ
自炊本全部リフローにしたい野望はみんな一度は夢見るが現実はまだ無理

「できらあ！」

と言いたいところだけど、現実は

「（時間と手間さえかければ）できらあ……」

くらいしか言えないけど、それじゃイヤなんだよね？
スキャンするなり即修正無しで使えるようでないと。

AI のできしだいだろうなぁ

結局のところ､googleのエンジンが一番優秀ということ？
そうなら､googleエンジンを組み込んでる市販ソフト買えば使えるね。

Google様でも手書き文字は全然ダメだね。

国内メーカーの企業向けのOCRって月ん百万取ってるけど、
Googleエンジンより出来が良いのだろうか？

>>119
そんな事はないが、Googleだって企業向けは当たり前に金取るから。
一日中検索してたらGoogleから50万円だったか請求する画面出て来たよ。免除してもらったが。

業務向け（BtoB）で高額でも、出来が良いとは限らない

>>111　が無料でリリースしてるOCRにも劣る大手企業のソフトなんて普通に有りそう

すげー処理が遅くなると思うけど、レイアウト認識・文字の切り取り・文字認識　等、各プロセスで得た複数の候補を（結果的に膨大な候補になる）、すべて辞書と照らし合わせるみたいな、
ディープラーニング（自分門外漢なので言葉の使い方に不安）みたいな事をやってくれるソフトは無いものか。

計算資源をバカ食いする点以外は、技術的にはそれほど難しくないとおもうけど。

連投すまない。補足。既存の技術の組み合わせで出来るのではという意味。

>>122
レイアウト認識と文字の切り出しを別のステップに分けるのが案外、難しい。

人間なら簡単に認識できるけど機械には難しい画像を利用したのがCAPTCHA

>>124
返信ありがとう。
レイアウト認識の段階で誤りがあるとその次のステップに進んでも答えに辿り着けないという事でしょうか?

自分もそれについては全く同意見なのですが、前段階での認識候補を複数出し、その次でのステップでも、前段階で上がった複数候補を愚直にすべて処理し、各候補ごとに更に複数候補を‥というのを続け、
ネズミ算的に膨れ上がった候補から辞書を使って答を探る事は出来ないのかなと思ってます。

そうではなくて言葉通り”レイアウト認識と文字の切り出しを別のステップに分けるのが難しい”という意味でしたらすみません。

喰いが止まってるので投下。

校正作業効率化　その５

「ScanTailor」

えるち某みたいなのがLinux陣営にも欲しいものだと思っていたら
ちゃんとあった。Windows版も。

画像フォルダを丸ごと読み込んで、
　・見開き画像を左右に分割
　・傾きを補正
　・トリミング
　・余白付加
　・ゴミ取り
　・dpi変更
　・濃度調整
上記を複数頁に対して一括自動実行して、新たな画像が作られる。

使ってみたがOCRのヒット率は向上したような気がするし、少なくとも
生スキャン画像にありがちな上下左右への偏りを除去できるから、
ビュアーでペラペラめくるときに同じ位置に揃うので見やすくはなる。

惜しむらくはノンブルを自動除去できないのと、上下に分割はできない
こと（二段組の小説とかで）だな。

>>126
なかなか良さそう。帰ったら試してみる。

もっとも、本当に欲しい機能は、
GoogleのOCRの前処理で
1. ノンブルを含む余白の自動カット と、
2. 縦複数段組の自動分割 なので、
かゆいところには手が届かない、かな。

エチル、読取革命時代からなんも進歩してないじゃねえか

ScanTailorはだいぶ前から全然アップデートされてないと思ってたら、別の所にScanTailor Advancedなんてのが出てるんだな。
まだ普通に検索しても一発で出てこない。

ScanTailor Advanced
https://github.com/4lex4/scantailor-advanced/releases

LINE(PC版とAndroid版)の新機能がOCRの文字起こし機能をいつのまにか搭載してたようだよ

Googleやtesseractと比べてどうなのかな？

こうなってくるとLINEの友達にOCR変換投げつけ用アカウントの人が必要だｗ

レシート読み取りに関してはレシーピが最高。
グラム（ｇ）を９と読み取るためにおかしくなる以外は濁音半濁音を間違う程度で正確に読み取る。
濁音半濁音は出来るだけ画面いっぱいで手振れ無しで撮らないとよくミスる。
グラム（ｇ）とか数字＋改行とかは修正ペンで消してから撮影すれば、金額はほぼ１００％正確に読み取ってくれるんで修正が必要ない。
割引もマイナス値で読み取ってくれる。

OCRする前に、原稿が上下逆かどうかを自動判別する手法、何か無いですか？
Linuxで使える物で

普通に考えて「OCRする前に」は無理だろう。

そのままOCRをして。上下逆にしてOCRして、
2種類の日本語の単語数を数えて、(どんな方法かは分からない)
多い方を正解にするとかは？

>>132
ドキュメントスキャナには上下を自動的に判別する機能があるよね｡ドライバを解析すればわかるかもね｡

>>132
領域を9等分して、明るさを数値化する。明るい区画は空白が多いという事だから、下になる。
領域を細かく分ければ精度が上がる。

>>136
なるほど。ありがとうございます。
これだと、言語を問わず判定出来そう。

>>137
横書きなら右に空白が増え、
縦書きなら下に空白が増え、
同じ横書きでもアラビア語みたいに右から書くと左に空白が増える。

この方法を使うためには、縦書きか横書きかを決めておく必要があるのでは？

>>75　に追加

読取革命でほとんどのエラー（フリーズ、エンドレス処理など）は
属性変更→認識→文字種→
で「記号」のチェックを外すことで回避できる
必要な記号は「ユーザー定義」欄に入れる
「」『』（）、。ー…・！？々　など

ようやく気付けた・・・
私の環境だけ？

tesseractでそれぞれの文字の一致率が何％だったのか取得することってできない？
もしくは高性能なOCRソフトで一致率が何％だったのか取得できるものない？

論理矛盾と言うか哲学的な質問だな

まぁtesseractは精度悪くはないけど
実用には値しないよなぁ

何を持って実用というかによると思うが
tesseractエンジンのCapture2Textにはずいぶんお世話になってる

tesseractって認識精度はともかく校正はどうやんの？
なんかいいツールある？

テキストエディタで認識結果のファイルを開いて、
誤認識している文字列を肉眼で拾ったら、
Grepツールに渡してフォルダごと全ページを正規表現検索して、
ヒットしたら正しい文字列に置換。
の繰り返しが基本。

最初にやるのは、まず一行の文字数を揃えること。
一行40文字で組まれているのに、それ以上あればその行はどこか
間違っている。

例：一行41文字以上で行末が句読点ではない文字列を検索する正規表現
^(.{41,}[^、。]$

仕事で手書きのファックスがバンバンきて、金額いれて計算して合計送り返す昭和なことしてるんだけど、
pc.スマホでスキャンしてエクセルで自動計算するには何が良いですかね？pc買い替え？タブレット購入？
ちなみに得意先のファックスの連打はパソコン持ってない奴らがほとんどでそちらの改善はほぼ無理

最近の手書きOCRは優秀らしいぞ。
でも､ソリユーション価格だから数百万円とかなんだろうな

C2Tの翻訳結果に変な文字列↓が挟まるようになったけど、何ぞこれ
ce4eb3e12fa6d7940ab33a38d4d816ab
文章の終端にくっついてるみたいだから、改行記号か何かが化けてるんだろうか

>>149
tesseract-ocrでOCRすると、たしかテキストの末尾に何か挟まってることが多いね。
Meryだと一文字の記号で[FF]と表示されるけど、同じものかしら。
検索/置換で真っ先に削除するから実害は感じないけど。

MicrosoftのLensを使って、FAXで送られた書類をスマホで撮影して取り込んだけど
文字小さいから全然読み込めなかったわ

あげ

Capture2Text使ってたら突然翻訳されなくなりました
英語と日本語で上下に別れていた枠が上の英語のみ
再翻訳のボタンも消えました
設定見直してもまったく変わっておらず
対処方検索してみてもみつからないです

>>143
tesseractの最大の欠点は、認識できなかった文字を無かったことにして何も出力しないこと。

認識できなかったら変な文字でよいから出力すべき。これだと後から目で見て気付きやすい。

>>146
おっしゃるとおり。
この方法の最大の欠点は、少しずつOCRに掛けながら校正出来ないこと。
最初に全部をOCRに掛けてから、全部を校正するしかない。

>>154
tesseract --print-parameters

A list of useful control parameters
https://github.com/tesseract-ocr/tesseract/wiki/ControlParams

認識に自信が無くても何かの文字を出力するようなパラメータが見つけられません。

いつまでたっても小説テキスト化位では
eTilTran　読取革命の組み合わせが最強だな
進歩なし

winでは

Capture2TextのCLI版で日本語をスキャンして結果をコマンドプロンプトに出力すると
文字化けするのですが対処法はありませんでしょうか
オプションで--clipboardをつけてクリップボードを経由すると文字化けなしで結果が取得出来るのですが
クリップボードを汚したくないので文字化け無しで出力したいです
OCR実行前にコマンドプロンプトの文字コードを変えても効果がありませんでした

つい最近OCRソフト探し始めたんだけど、日本じゃ結構前から開発してるとこ無いと知って唖然。
ネットで検索すると丁寧に比較解説してるサイトがすぐ見つかるけど、そこによるとパナの読取革命が一番高性能みたいだね。
ただ長らくバージョンアップしてないしこれからもする事はないみたいだ。
その点アドビは性能面ではパナに劣るけどこれからも開発続けてくし何よりOCR化した時のサイズが小さい。
パナのほうは最大10倍近く膨れ上がるしどうにかならんかの

>>159
読取革命でOCR透明テキストを足してからAcrobatで圧縮

>>159
DeepLearningに期待しよう。まず手書き文字認識と、版木本の古文書文字認識から始めて、手書き古文書文字認識が目標。

Adobeの認識エンジンは自社開発ではなかったような。
今は違うのかな。

GoogleのAPIが実用的になってきている。
あとフロントエンドのGUIさえあれば良いのだが。

PDFelementtってやつ買おうと思ってるんだが、これも結局パナソニックのシステム利用してるんかね。
買い切りでPDFも編集も出来るからいいのかなって思って。

>>160
横からだけどこれで圧縮可能なのか
試してみるわ
ありがとね

結局のところ修正作業がしやすいのが一番
なんなら必ず同じ読み取りミスをするならそのほうがいいくらい
あとルビ対応が少なすぎる

e.Typist使ってるが
透明テキストPDFにするなら修正しないし、
txt化するなら良くある読み取りミスを一括で置き換えてそれだけになっちまうわ
ルビはレイアウトを誤認識することがあるから無視してる
高圧縮のPDFの出来がAcrobatより良いんでそこは良い

縦書きの透明テキスト付きpdfで
読取革命超える認識率のOCRって無いんかな？
Google Cloud Visionで出来れば最高なのになぁ

正月休みでGoogle Compute VisionのOCRで透明テキスト付pdf作るの作ったけど需要ある？

現状バグあり、Google API Key必要。
Windows用、複数ページは連番のjpgファイルをあらかじめ作ること。

日曜に削除予定。githubに置こうと思う。


https://1drv.ms/u/s!Agi0gM6bLD5Wr2wURjeqAok7F450

あとpython入ってないと動かないかもしれんw

Python入れなくても動くようにした。

https://1drv.ms/u/s!Agi0gM6bLD5WsALWMKVa2ub96WSG?e=Yc19Fs

需要ないのかなｗ

バグってたので差し替えｗ

https://1drv.ms/u/s!Agi0gM6bLD5WsAPZ9F1s7wGI7PVa?e=ymPlj1

正月明け土曜じゃリアルが忙しくて5ch見てる暇ない人も多いんじゃない？
見てても今時はスマホの専ブラだし

ていうか家帰ったらPCから落とすからちょっと待って

ありがとうー
そっちでも動くといいなw

試してみました
gcv2hocrの作者さんですかな、ご苦労様です
win環境でexe実行するもエラーで動かず
WSLでsrcを直接実行してみようとしたけど無理でした。
(なおWSL環境下では従来のgcv2hocrのmakepdf.shからの検索PDFは作成できてます)

WSLでgcvocr.py実行したときのメッセージ
$ python ./gcvocr.py ./page001.jpg "API key"
Traceback (most recent call last):
File "./gcvocr.py", line 8, in <module>
from requests import Request, Session
ImportError: No module named requests

つづく

winからmakepdfgui.exeを直接実行したときのメッセージ(長いので1枚分だけ)

google OCR page002.jpg
Traceback (most recent call last):
File "E:\tmp\makepdfGUI\makepdf\urllib3\connectionpool.py", line 588, in urlopen
File "E:\tmp\makepdfGUI\makepdf\urllib3\connectionpool.py", line 248, in _get_conn
File "E:\tmp\makepdfGUI\makepdf\urllib3\connectionpool.py", line 816, in _new_conn
urllib3.exceptions.SSLError: Can't connect to HTTPS URL because the SSL module is not available.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "E:\tmp\makepdfGUI\makepdf\requests\adapters.py", line 439, in send
File "E:\tmp\makepdfGUI\makepdf\urllib3\connectionpool.py", line 637, in urlopen
File "E:\tmp\makepdfGUI\makepdf\urllib3\util\retry.py", line 399, in increment
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='vision.googleapis.com', port=443):
Max retries exceeded with url: /v1/images:annotate?key="APIキー"
(Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available."))

During handling of the above exception, another exception occurred:

つづく

つづき

Traceback (most recent call last):
File "E:\tmp\makepdfGUI\makepdf\gcvocr.py", line 63, in <module>
File "E:\tmp\makepdfGUI\makepdf\gcvocr.py", line 50, in recognize_image
File "E:\tmp\makepdfGUI\makepdf\requests\sessions.py", line 646, in send
File "E:\tmp\makepdfGUI\makepdf\requests\adapters.py", line 514, in send
requests.exceptions.SSLError: HTTPSConnectionPool(host='vision.googleapis.com', port=443): Max retries exceeded with
url: /v1/images:annotate?key="APIキー" (Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available."))
Convert page002.jpg to hocr
No input file.
Generating out.pdf
Traceback (most recent call last):
File "E:\tmp\makepdfGUI\makepdf\hocr-pdf.py", line 171, in <module>
File "E:\tmp\makepdfGUI\makepdf\hocr-pdf.py", line 74, in export_pdf
File "E:\tmp\makepdfGUI\makepdf\hocr-pdf.py", line 84, in add_text_layer
File "src\lxml\etree.pyx", line 3469, in lxml.etree.parse
File "src\lxml\parser.pxi", line 1839, in lxml.etree._parseDocument
File "src\lxml\parser.pxi", line 1865, in lxml.etree._parseDocumentFromURL
File "src\lxml\parser.pxi", line 1769, in lxml.etree._parseDocFromFile
File "src\lxml\parser.pxi", line 1163, in lxml.etree._BaseParser._parseDocFromFile
File "src\lxml\parser.pxi", line 601, in lxml.etree._ParserContext._handleParseResultDoc
File "src\lxml\parser.pxi", line 711, in lxml.etree._handleParseResult
File "src\lxml\parser.pxi", line 638, in lxml.etree._raiseParseError
OSError: Error reading file 'E:/tmp\page002.hocr': failed to load external entity "file:/E:/tmp/page002.hocr"
Done!

すまぬ、dllがいくつか足らないようです。

チョット調べてみます。

ちなみにWinで動かした時、ウインドウは出ますか？

WSLの時は、モジュールが足らないのでpip installが必要かもです。

実行するのは4つexeがあるうち、makepdfgui.exeです。これをダブルクリックしてみてください。

プロンプトとボタンが3つあるGUIが別窓で出てます

WSLではghostscriptとhocr-toolsが使ってるライブラリ(Pillow / lxml / reportlab)はインストールしましたが
後は何が必要か分からなくて入れてないです

ありがとうございます。

今dllを全部入れたのを作ってますのでしばしお待ち下さい。

再アップしました。お試しいただければ幸いです。

https://1drv.ms/u/s!Agi0gM6bLD5WsAXIZw7kr90bLghC?e=hFLhW0

Linux版はこちらです。WSLで動くかもしれません。

https://1drv.ms/u/s!Agi0gM6bLD5WsAYHp7BPFWjaiCk6?e=RLjW5c

>>182
修正ありがとうございます　無事動きました

makepdfgui.exeは簡易的なフロントエンドという感じですが
gcv2hocr / gcvocr / hocr-pdf をそれぞれexe化されたものが同梱されているので
各プログラムのコマンドライン解説があればバッチ処理で連続実行させられそうですね
あと個人的には出力パス(PDFファイル名)と中間ファイルのテンポラリパスも指定して画像ソースできればいいなと思いました

まあそのあたりはせっかくソース同梱ですし.pyが動かせれば自分で改変できるので
おま環で実行環境づくりに試行錯誤してました
WSLはPython2.7のままだったのでTkinterでハマって一旦断念
dosプロンプト+miniconda でパッケージにrequestsを足してなんとか

```
conda create -n makepdf python=3.7 Pillow lxml reportlab requests
conda activate makepdf
python makepdfGUI.py
```

なお os.path.dirname(__file__) は os.path.dirname(os.path.abspath(sys.argv[0])) に書き換える必要がありました

×画像ソースできればいいなと思いました
〇画像ソースと分離できればいいなと思いました

ありがとうございます！

動いてよかったです。
来週にでもgithubに上げますのでforkするなりなんなり宜しくお願いします。

Windows版は.pyファイルのコンパイルにnuitkaを使ってます。コンパイルオプションが長いのでそれも併せてアップします。

Windowsで使えれば少し拡がるかな、と思ってますw

python由来のexeファイル（gcvocr.exe, hocr-pdf.exe)は単体での起動ができなくて、一緒にたくさん入っている
共有ライブラリが必要になります。

gcv2hocrはMingw64でコンパイルしているので、単体で動作すると思います。

大したものでもないですが、誰かに使ってもらえると嬉しいものです。
ありがとうございます。

こちらこそ有用なものを上げていただいてありがとうございます

自分もgcv2hocrをexe化できないかなあと思って弄ってた時期もあったんですがニワカ知識だとなかなか
winだとサーチャブルPDFをスキャン時ではなく後から作ろうと思うと
いまだにAcrobatか旧来の有料OCRソフトかみたいな感じでなかなか歯がゆいとこあります

とりあえずGithubにあげました。

https://github.com/dinosauria123/makepdf

★入れときました

ありがとうー

出力pdfを任意の場所に置けるようにしました。

上のgithubのページにダウンロードのリンクがあります。

中間ファイルは別フォルダに置くようにしました。

実行時にコンソールウインドウが出ないようにしました。

改良乙

乙

Googleドライブに入れてGoogleドキュメントで開いて…のOCRって、使用量に
何か制限があるのかねえ？

1枚に2000文字程度書かれたビットマップファイルを1800枚ほどOCRしてたら、
途中なぜかGoogleに繋がらなくなった。(googleトップページにも繋がらない・
Google以外は問題なく繋がるので回線の問題では無い)
怪しい利用者と思われ、ロックアウトされたのかねえ？
色々やってたら(20分ぐらい？)復活したが・・・


最初e.TypistOneを使ったが、誤認識があまりにも多く断念。

プログラミングのスキルがあれば Google Cloud Vision API を使うアプリ
を作るのだが、無いのでGoogleドライブ経由で利用。

一旦全てのビットマップをGoogleDriveに入れ、ブラウザ上で、
(1) ビットマップファイルをGoogleドキュメントで開く
(2) 書式無しテキストでダウンロード＆閉じる
(3) 処理の終わったファイルをDriveから削除
という一連のマウス操作を、UWSCというアプリを使って記録、繰り返し再生し
てる。(1枚約1分)

Google DriveでのOCRで上限を感じたことはない。
でも1800枚は時間なり量なりの制限にかかるのかもね。

同じ作業をPowershellのスクリプトで行っているが、
無料のGoogle Driveと有料のCloud VisionAPIとでは
認識結果が異なり、精度は意外にも前者が高く、
処理速度は後者が速い。ゆえに使い分けている。

>>197
＞無料のGoogle Driveと有料のCloud VisionAPIとでは
＞認識結果が異なり、精度は意外にも前者が高く、
これは意外＆嬉しい情報です。 ありがとうございます。

まだ細かくは見ていませんが、Google DriveでのOCR結果は満足いく物のようです。

UWSCは自分も使っている。良いソフトだね。
でもUWSCのスクリプトが組めるならば、
PythonなりPowershellなりへの移行も容易では？
速度が当社比10倍にはなると予想。

OK

この辺？

https://qiita.com/rarara_x16/items/639ebc3069c4d5a4fb8a

https://github.com/thinkAmi-sandbox/google-api-python-client-sample/blob/master/README.md

>>199
とりあえず今回は、Google-Drive+UWSCでTEXT化を終えました。
次回があればCloud VisionAPIも検討します。
(何もインストールせずに使えるということで、とりあえずPowerShellで
「Hallo World!」を表示させてみた)

参考に教えて頂きたいのですが、>>197でGoogle Driveより精度が低かっ
たと書かれているCloud VisionAPIは DOCUMENT_TEXT_DETECTION か
TEXT_DETECTION のどちらでしょうか？

Foxit PDF は英語と日本語を混ぜてスキャンするとエラーになる？

>>189
ありがとうございます
1200dpiのスキャナー欲しくなりましたw

昭和４０年頃の手書き青焼きのコピー（Ａ４　２３行×１００Ｐ以上）をテキスト化したいんですが
そういう悪条件につよいソフトって家庭用で存在しますか。
ゴミ、旧漢字、略字・・・　「多」の上が「ヨ」だったり

Adobe Acrobat はバージョンが上がるごとにOCR精度は向上しますか？

とりあえず「Capture2Text」使ってみたんだけど、まったく使えなかった…
これ常用してる人いる？

そんな使えないの誰もいないでしょ

使いこなせないアホなどいないと言いたいのか
使えないから常用者がいないと言いたいのか

Capture2Textはtesseract & Google翻訳のフロントエンドとしては有能だぞ
基本よその国のマンガやゲームのフキダシを母国語に翻訳しながら読む用途向けなので長文は苦手だが
tessdataをtessdata_fastと入れ替え jpn_vert.traineddataも足せばOCR精度は多少マシになる

あとググってたら Capture2TextみたいなのをGoogle OCR でやってるツールもあった
SSTRとかいうの
要GCPキーだがクソ速い