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

**名無しさん＠お腹いっぱい。** · 2016/08/09(火) 21:24:11.61

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

**名無しさん＠お腹いっぱい。** · 2018/09/13(木) 20:22:21.28

日本語音声入力と日本語OCRの停滞ぶりは凄いよね。日本語というのは損な言語なんだね。

**名無しさん＠お腹いっぱい。** · 2018/09/13(木) 21:27:50.69

>>101
需要が一段落したのでは？

新しい文書は電子化されてるし、主要な活字本はOCRで取り込んだ。

次のターゲットは、手書き、特に古文書だろうけど、あまりにもニッチ。

**名無しさん＠お腹いっぱい。** · 2018/09/23(日) 22:14:27.95

>>102
ぜんぜん電子化されてないじゃん。いまだに断裁しているよ。紙の本は滅びて欲しいわ。

**名無しさん＠お腹いっぱい。** · 2018/09/23(日) 23:33:25.62

とりあえず>101がGCV使ったことないのは分かった
googleさんはここ数年でむっちゃ進化すすめてるやろ

**名無しさん＠お腹いっぱい。** · 2018/09/23(日) 23:48:00.36

GoogleのCloud Visionでアプリ作ったものですが
これをWindows向けに開発して
リリースしたら需要あるみたいですね？

まぁGCV自体従量制なんで、
ポイント式にしないと危ないですが
Windowsでも出来たかなぁ

**名無しさん＠お腹いっぱい。** · 2018/09/24(月) 02:04:54.60

手書きとか写真からの文字抽出とかは進化してるけど、
スキャン文書の99.9%の認識率を99.99%に上げるような進化はしてないよ
ーー(二重ダッシュ)がかすれ扱いされて消されたり
ルビを巻き込んで盛大にグチャるのも10年前から変わらん

**名無しさん＠お腹いっぱい。** · 2018/09/24(月) 09:48:02.72

そりゃどこまで行ったって100%完璧にはならんだろ
それを停滞というのならもうOCRは諦めろとしか

>>105
ユーザーが自分のAPIキーを設定できるようにしてくれるとありがたい
もちろんGCP使えるエンドユーザーは限られるだろうからソフト内の課金制度も
平行して必要だとは思うけど

**名無しさん＠お腹いっぱい。** · 2018/09/24(月) 12:06:18.22

>>104
本当に？じゃあ使ってみるわ。俺はメディアドライブとかAdobeとかXEROXのOCRを使って毎日ゲンナリしています。

**名無しさん＠お腹いっぱい。** · 2018/09/25(火) 13:21:20.30

>>107
返信ありがとう。
APIキーと課金両方つけるアイディアはいいね。

**名無しさん＠お腹いっぱい。** · 2018/09/25(火) 20:38:03.49

良かったら作ったOCRアプリの名前教えてほしい
せっかくだから試してみたい

**名無しさん＠お腹いっぱい。** · 2018/09/25(火) 21:00:00.34

>>110
興味を持っていただきありがとうございます。
ClipOCRというアプリです
iOSで出してます

**名無しさん＠お腹いっぱい。** · 2018/09/26(水) 02:36:36.23

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

**名無しさん＠お腹いっぱい。** · 2018/09/26(水) 15:32:33.40

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

**名無しさん＠お腹いっぱい。** · 2018/09/26(水) 15:46:44.32

がんばれー

**名無しさん＠お腹いっぱい。** · 2018/10/18(木) 06:31:56.70

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

**名無しさん＠お腹いっぱい。** · 2018/10/21(日) 21:47:44.30

「できらあ！」

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

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

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

2018/10/22(月) 08:29:07.17

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

**名無しさん＠お腹いっぱい。** · 2018/10/22(月) 11:56:35.83

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

**名無しさん＠お腹いっぱい。** · 2018/10/29(月) 16:05:36.04

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

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

**名無しさん＠お腹いっぱい。** · 2018/10/29(月) 17:58:02.72

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

**名無しさん＠お腹いっぱい。** · 2018/11/05(月) 18:13:32.12

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

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

**名無しさん＠お腹いっぱい。** · 2018/11/05(月) 18:17:14.26

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

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

**名無しさん＠お腹いっぱい。** · 2018/11/05(月) 18:21:01.26

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

**名無しさん＠お腹いっぱい。** · 2018/11/05(月) 18:28:05.57

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

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

**名無しさん＠お腹いっぱい。** · 2018/11/05(月) 20:57:32.60

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

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

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

**名無しさん＠お腹いっぱい。** · 2019/01/24(木) 02:28:33.48

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

校正作業効率化　その５

「ScanTailor」

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2019/01/24(木) 18:19:29.58

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

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

**名無しさん＠お腹いっぱい。** · 2019/01/24(木) 20:58:14.74

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

**名無しさん＠お腹いっぱい。** · 2019/01/28(月) 19:33:43.72

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

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

**名無しさん＠お腹いっぱい。** · 2019/04/22(月) 13:29:43.28

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

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

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

**名無しさん＠お腹いっぱい。** · 2019/04/23(火) 03:18:57.23

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

**名無しさん＠お腹いっぱい。** · 2019/04/24(水) 17:27:12.85

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

**名無しさん＠お腹いっぱい。** · 2019/04/24(水) 23:45:13.63

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

**名無しさん＠お腹いっぱい。** · 2019/04/26(金) 21:22:29.83

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

**名無しさん＠お腹いっぱい。** · 2019/04/29(月) 11:28:12.88

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

**名無しさん＠お腹いっぱい。** · 2019/05/01(水) 07:14:36.04

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

**名無しさん＠お腹いっぱい。** · 2019/05/04(土) 09:49:33.30

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

**名無しさん＠お腹いっぱい。** · 2019/05/04(土) 15:42:35.53

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

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

**名無しさん＠お腹いっぱい。** · 2019/05/08(水) 21:36:16.90

>>75　に追加

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

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

**名無しさん＠お腹いっぱい。** · 2019/05/29(水) 07:43:25.13

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

**名無しさん＠お腹いっぱい。** · 2019/05/29(水) 17:19:09.12

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

**140** · 2019/06/01(土) 06:03:42.02

わかりにくくてすまん　　tesseractにある字体データと対象の文字の一致率って意味　
https://tesseract.patagames.com/help/html/b4effc4b-310d-4f1f-99a0-65bc001cd765.htm
このサイトにある　↓0.125って数字は一致率0.875以上だった場合、Good Matchを返すって意味だと思う　
matcher_good_threshold 0.125 Good Match (0-1)
matcher_perfect_threshold 0.02 Perfect Match (0-1)
やりたいことはこの一致率が指定した値以下だった場合、テキストファイルになにも書き込まないという処理をしたい　読み込む画像はすべて１行
一致率を取得できればほかのプログラムと組み合わせてできるようになる
もしくはこのサイトの関数をうまく使えばできそう
それっぽいのをいじってみたけどうまくいかなかった

**名無しさん＠お腹いっぱい。** · 2019/06/23(日) 10:49:31.56

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

**名無しさん＠お腹いっぱい。** · 2019/06/23(日) 11:32:22.27

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

**名無しさん＠お腹いっぱい。** · 2019/06/23(日) 15:55:40.30

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

**名無しさん＠お腹いっぱい。** · 2019/06/24(月) 00:53:07.52

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

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

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

**名無しさん＠お腹いっぱい。** · 2019/06/26(水) 20:48:52.13

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

**名無しさん＠お腹いっぱい。** · 2019/06/28(金) 09:45:39.33

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

**名無しさん＠お腹いっぱい。** · 2019/07/05(金) 13:04:14.42

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

**名無しさん＠お腹いっぱい。** · 2019/07/17(水) 14:53:00.47

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

**名無しさん＠お腹いっぱい。** · 2019/09/15(日) 22:59:06.77

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

**名無しさん＠お腹いっぱい。** · 2019/09/15(日) 22:59:40.51

あげ

**名無しさん＠お腹いっぱい。** · 2019/09/23(月) 22:23:53.52

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

**名無しさん＠お腹いっぱい。** · 2019/10/16(水) 04:14:51.41

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

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

**名無しさん＠お腹いっぱい。** · 2019/10/16(水) 04:18:09.12

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

**名無しさん＠お腹いっぱい。** · 2019/10/16(水) 07:25:42.98

>>154
tesseract --print-parameters

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

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

**名無しさん＠お腹いっぱい。** · 2019/10/16(水) 08:24:23.64

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

winでは

**名無しさん＠お腹いっぱい。** · 2019/11/05(火) 18:14:11.50

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

**名無しさん＠お腹いっぱい。** · 2019/12/10(火) 01:29:48.62

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

**名無しさん＠お腹いっぱい。** · 2019/12/10(火) 03:32:57.63

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

**名無しさん＠お腹いっぱい。** · 2019/12/10(火) 03:36:47.74

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

**名無しさん＠お腹いっぱい。** · 2019/12/10(火) 06:54:24.38

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

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

**名無しさん＠お腹いっぱい。** · 2019/12/11(水) 06:28:23.68

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

**名無しさん＠お腹いっぱい。** · 2019/12/11(水) 08:50:49.67

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

**名無しさん＠お腹いっぱい。** · 2019/12/13(金) 14:39:43.81

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

**名無しさん＠お腹いっぱい。** · 2019/12/22(日) 14:43:51.13

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

**名無しさん＠お腹いっぱい。** · 2019/12/25(水) 11:59:05.90

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

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 06:33:55.83

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 06:38:57.88

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

**168** · 2020/01/04(土) 20:16:15.28

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

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

需要ないのかなｗ

**160** · 2020/01/04(土) 20:28:29.43

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 21:08:20.99

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 21:16:47.30

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

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 23:54:22.70

試してみました
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

つづく

**名無しさん＠お腹いっぱい。** · 2020/01/04(土) 23:59:20.20

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:

つづく

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:00:30.96

つづき

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!

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:03:08.67

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

チョット調べてみます。

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:11:55.50

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:22:37.06

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:28:58.36

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:37:03.33

ありがとうございます。

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 00:44:00.95

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 01:00:42.23

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 21:43:56.51

>>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])) に書き換える必要がありました

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 21:46:07.12

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 22:01:04.34

ありがとうございます！

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

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 22:19:24.41

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

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/05(日) 22:43:03.98

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/06(月) 11:35:46.65

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

https://github.com/dinosauria123/makepdf

**名無しさん＠お腹いっぱい。** · 2020/01/06(月) 22:22:51.95

★入れときました

**名無しさん＠お腹いっぱい。** · 2020/01/07(火) 05:50:46.58

ありがとうー

**名無しさん＠お腹いっぱい。** · 2020/01/08(水) 19:11:22.77

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

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

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

**名無しさん＠お腹いっぱい。** · 2020/01/09(木) 10:44:21.50

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

**名無しさん＠お腹いっぱい。** · 2020/01/09(木) 23:57:29.83

改良乙

**名無しさん＠お腹いっぱい。** · 2020/01/10(金) 00:17:04.04

乙

**名無しさん＠お腹いっぱい。** · 2020/02/04(火) 10:31:25.64

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分)

**名無しさん＠お腹いっぱい。** · 2020/02/04(火) 12:00:35.26

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

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

**名無しさん＠お腹いっぱい。** · 2020/02/04(火) 13:11:16.64

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

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

**名無しさん＠お腹いっぱい。** · 2020/02/04(火) 20:20:23.79

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

**名無しさん＠お腹いっぱい。** · 2020/02/04(火) 21:22:14.83