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

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

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

**名無しさん＠お腹いっぱい。** · 2018/04/08(日) 00:49:22.65

Ubuntuで最新tesseractビルドでも高精度認識できたよー
とりあえずスクショだけ
https://i.imgur.com/saI3kEb.jpg
https://i.imgur.com/Gs7Mokj.jpg

ビルドのやり方とかは希望あればまとめます

**名無しさん＠お腹いっぱい。** · 2018/04/08(日) 01:18:01.31

>>42
そっちの方が参考になった
やっぱり文章レイアウトの認識はあんまりみたいだな

**名無しさん＠お腹いっぱい。** · 2018/04/08(日) 01:19:35.90

OCR認識に満足してる人
数式･化学式が沢山ある理科系のページをOCRかけてごらん
グチャグチャになるよ

**ハカーを待ちながら** · 2018/04/08(日) 01:53:17.65

>>42
すげえ！！　神が降臨した。

ビルドのやり方ぜひ！　まとめて下さい。

>>44
うーん、気持ちは分かるんだけど縦書きの日本語小説だけがターゲットの者にとっては、
レイアウト情報以前に少しでも正確なプレーンテキストを得られそうなことが凄いのよ。

まあでもAIが正確なテキストを作ることに飽きたら、今度は正確なレイアウト情報の
再現に、ほっといても邁進してくれることでしょう。

**名無しさん＠お腹いっぱい。** · 2018/04/08(日) 02:20:22.39

了解です
ちとまとめるので時間ください

>>43
いやこれただのテキストデータなんでレイアウト情報は元々ない
認識文字の見比べしやすいようにテキストエディタで擬似的に縦書きや段組っぽく見せてるだけ
PDF出力すれば透明テキストはちゃんと画像の文字の上に被さるけどね

数式に関してはあれは図と同じだと思いなせえ
そもそも平テキストだけで表現できずLaTeXなどの組版処理が必要なカテゴリですやん
もともとOCRでどうこうできるものではない

42 · 2018/04/12(木) 00:27:46.59

遅くなってすまん
まとめるとか偉そうに言ったけどほぼに↓の通りにやっただけ
https://ameblo.jp/yoshihirow/entry-12280797214.html

1. コンパイルに必要なライブラリのインストール
2. Leptonicaのコンパイルとインストール
3. tesseract-ocr 4.0.0β のコンパイルとインストール
4. 言語データtessdataのダウンロード
5. サンプル画像でOCRのテスト

注意点としては
2.Leptonicaは公式でtar.gz貰ってくるとconfigureで引っかかるので
githubから最新ソース落としてmakeする

$ git clone --depth 1 https://github.com/DanBloomberg/leptonica.git
$ cd leptonica
$ ./autobuild
$ ./configure
$ make
$ sudo make install

4.言語データはすべて tessdata_fast (https://github.com/tesseract-ocr/tessdata_fast)を使う
jpnとjpn_vert両方入れるのが胆

5.サンプル出力 ver.4では--oem 0と2のオプションはエラーになるので使わない
言語指定は -l jpn+jpn_vert が一番精度良くなるよ

42 · 2018/04/12(木) 00:28:08.34

他所の環境でちゃんと動くかは分からないけど
コンパイル手順を自動化したスクリプトとビルド済みパッケージ置いときます
作成&テスト環境
　　windows10 WSL Ubuntu 16.04.4 LTS
　　vagrant ubuntu/xenial64 (vurtualbox)

ビルド自動スクリプト --> https://www.axfc.net/u/3902696.zip
ビルド済パッケージ(.deb) -> https://www.axfc.net/u/3902697.zip

**ハカーを待ちながら** · 2018/04/12(木) 23:19:55.32

>>47
まとめ作成お疲れ様です。

tesseract-ocr4.00αをインストールするとき、自分も当時同じサイトを参考に
しましたけど、Leptonicaもtesseract-ocrもそれぞれバージョンが上がってたのね。

とはいえ最新ソースからmakeするとか言語ファイルをtessdata_fastから取ってくるとか、
自分ひとりでは絶対思いつかないし、あまつさえインストール用のシェルスクリプト
（Windowsでいうバッチファイルみたいなもの）まで作ってくれて、どうもありがとう。

既存環境との衝突防止対策するより、バージョン違いのWineとのからみもあるので、
MicroSDカード上にクリーンなxubuntu環境を作って、そこにインストールしようかな。

当方32GBのMicroSDHCをUSBに変換するアダプタに挿して、切り替えボタン付きのUSBハブから
ブートさせてxubuntuを使っているので、複数のMicroSD＋USBアダプタさえ用意すれば異なる
Linux環境をUSBハブのボタンひとつで使い分けられて、そこそこ便利です。

でも同じOSをインストールしているはずなのに、出来上がった挙動やファイル構成が微妙に
違うのは、再インストールしたWindowsと似たようなもんかしら。

**ハカーを待ちながら** · 2018/04/16(月) 16:40:46.99

神のお言葉に従いテストベッド環境に最新版tesseract-ocrをインストールして、250ページほどの
新書をまるごと一冊OCRしてみたのですが、どうもこちらの信心か功夫が足りないのか、正直
『かなり悪くはないがけして手放しで喜べる程良くはなかった』というのが正直な所。

以下、不慣れながらもスクリーンショットを挙げてみたので、見ながら解説。

オフィス用複合機のADFで300dpi・G4圧縮で保存したOCR元のtif画像
　https://imgur.com/FRIY8a9

以前jpgでスキャンしたものより的中率が向上したのとファイルサイズが小さくなるので、
以後ずっとtifで保存するようにしているのだが、元の紙面が経年劣化によるシミ・ソバカス
でクリーンな状態とは言いがたく（だからテキスト化するのだが）、ノイズが少なからず
乗ったままOCRかけるので、今後は別の手段を考えるべきかもしれない。

最新版から一つ前のtesseract-ocr4.0αでOCRした結果のスクリーンショット
　https://imgur.com/21b2PK4

[っ]直後の[は行のひらがな]は必ず[半濁音にする]的な後処理を加えてあるので、厳密には
スタンダードとは言えない。[ぁぃぅぇぉゎ]が混ざるのが地味にいらつく。

最新版から一つ前のtesseract-ocr4.0α＋blacklist（小書きを禁止＋後処理）
　https://imgur.com/6Yh4riW

後処理に加えて、blacklistで[小書きのひらがな]や[日本語の文章に出てこない記号]をはじく
ように事前処理してある。[3点リーダー]を正しく認識できないが、これが現段階の自身でできる
最善のチューニング状態。

**ハカーを待ちながら** · 2018/04/16(月) 17:33:07.75

最新版のtesseract-ocr4.0β＋jpn+jpn_vertでOCRした結果のスクリーンショット
https://imgur.com/OmTeJEv

jpnだけだと半角スペースが入りまくりだが、jpn+jpn_vertで見事に消える。
認識結果を一つ前のと比較すると、全体に大振り気味で当たれば見事ホームランだが外すと
余計な文字が混入する感じ。『ピーキーなチューニング』とでもいうべきか。
--oem オプションで0を選択できない（=複数のOCRエンジンを使用）せいか、CPUパワーの
消費が三倍くらい増える。

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 19:06:06.80

ルビが入った時の処理が気になる
ソフトによっては一行とみなして空白だらけの一行ができたり、完全に無視して勝手に除去したりするから
後者も問題だけど、前者の場合手動修正の手間が相当増える
ルビを含めて1字として処理して、認識不能を返すのは論外

**ハカーを待ちながら** · 2018/04/16(月) 19:28:05.86

ふと「ノイズの極少ない元画像からならどこまでやれるのか？」を思い立ち、エディタの
画面上に22ポイントで縦書き画面を再現したものをスクリーンショットして、それを元画像
にして神の手版tesseract-ocrでOCRしてみたところ、結果は段落空きと3点リーダー以外ほぼ
完璧と言っていい認識結果となりました。

22ポで画面上に再現した擬似元画像
https://imgur.com/Z967Vz9

それをOCRした結果のスクリーンショット
https://imgur.com/Psbsp9m

つまり最新版のtesseract-ocrは現状でほぼ完全に近い認識能力を持っていると。
……ノイズのない完璧な元画像からであれば。

ただそれは物理の問題とかに出てくる『ここに伸び縮みしない真っ直ぐな棒がある』と同様、
スキャナーを通して読み取る以上現実にそんなノイズのない元画像はあり得ない訳で、あとは
どうやってノイズが少なくなるような加工技術を編み出すか？　になっていくのでしょうか。

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 20:17:56.21

>>50のいちばん最初の画像を使って、Google Cloud VisionのOCRをかけてみた。

https://imgur.com/a/3TL1i

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 20:42:37.96

CloudVisionはOCR性能は抜群なんだけど縦書きの属性情報は返してくれないみたいで
>>34の方法で透明テキスト付PDF作るとき難が出るんだよね
惜しい
https://github.com/tmbdev/hocr-tools/issues/54

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 20:49:18.86

>>55のgithubに投稿した者だけど、hocr-toolsでpdf生成に使っているPythonのreportlibが日本語縦書きをサポートしてないことまではわかりましたw

reportlibを弄るのは手に余るので、求むハカー！ですw

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 20:56:21.22

ただ、GCVのjson出力は文字の座標を返すので、次の文字の座標を考慮すれば縦横判定はできるかもしれない。

あと、縦横混在はさすがにきつい。
事前に画像を切り出しておくと大丈夫だけど。

レイアウトを考慮するオプションが英文だとあるけど、日本語はまだみたいw

**ハカーを待ちながら** · 2018/04/16(月) 23:01:41.54

>>54
同じ元ネタ画像をonlineOCRというサイトに投げてみた結果。
https://imgur.com/sEPqF76

改行コードが半角スペースにされているので、置換するとほぼ原文に正確な
認識結果が得られているのが分かる。

とはいえいくら優れたOCRとはいえ、誰がやっているのか分からないネットの
向こう側に金玉を握られているような状態ってのはやっぱ釈然としないのよ。

自炊行為の是非以外にも内部の文書をネットに放流するリスクとかもあるし、
Google Cloud Vision APIがとてつもなく優れているのはよく分かるんだけど、
エンドユーザーにAPIとやらを扱うのは簡単じゃないし、ネットに繋がないと
結果が得られないなら、いっそスタンドアロンのお手元のハコの中でなんとか
できる範囲で改良を……と、もう少しtesseract-ocrをいじっていたい。

最新のマシーンＺが優れているのは分かるけど、共に死線をくぐってきた
ロボットマンにこだわりたかったあきらくんのように。
（コミック版「ミクロマン」はいいぞ）

まあ結局は乗り換えたんですけどね。

**名無しさん＠お腹いっぱい。** · 2018/04/16(月) 23:39:00.31

>>56
gcv2hocrの作者様ですね。有用なツール開発ありがとうございます

縦書きPDFの出力は tesseract 4.0 や OCRmyPDFがが実現してるので
pdfrenderer.cpp あたりの出力部分だけ切り出して何とかならないのかなあ、なんて
なんつって自分はソース見ても全然理解できなかったですが
json座標から縦横判定のほうが厳しそう
googleさんは解析時に縦横分かってるわけだし今後のアプデでオプション増えるのを期待

個人的に自炊PDF(OCRなしで画像のみ)を画像劣化なしでサーチャブルにするツールが欲しくて調べてた

　・OCRmyPDF (tesseractエンジン元々そういう用途向き)
　・tesseract 4.0　→ 画像を含まない透明テキストのみのPDFが作れる (-c textonly_pdf=1)
　・gcv2hocr + hocr-tools →フォーク版で画像を含まない透明テキストのみのPDFが作れる(--nodraw)
　　https://github.com/zvezdochiot/hocr-tools

→ pdftk の multibackground オプションで画像pdfと透明テキストpdfを重ねる
　　pdftk images.pdf multibackground text.pdf output full.pdf

Win使いがAcrobatだのe.Typistでコレジャナイ感味わい続けてる間に
linux界隈ではとっくにできるようになってたという…
exe化して1パッケージにまとめればWinの自炊者にも需要あると思うわこれ

**名無しさん＠お腹いっぱい。** · 2018/04/17(火) 00:21:57.55

>>53
補正に関しては自炊ノウハウも確立してるので自分はわりと楽観してるわ
自力で納得のいく補正かけた後に任意のタイミングで
OCRかけられてPDFにできるというアドバンテージは大きい

程度の低い話ですまんがWindowsでOCR付き自炊PDF作ろうとすると
スキャン時にPDFで保存するか(黄ばみや斜行がひどくても後修正が困難)
後からAcrobatなどの有料ツールでPDF化するか(せっかく補正しても画質劣化する上に認識率も超残念)
ポピュラーな方法がこの2者だったのよね

**名無しさん＠お腹いっぱい。** · 2018/04/17(火) 05:54:08.82

画像アップするなら　.jpg まで付けてリンク張ってくれ
一々リンク先まで飛ぶのが面倒

**名無しさん＠お腹いっぱい。** · 2018/04/17(火) 10:22:08.67

>50
＞オフィス用複合機のADFで300dpi・G4圧縮で保存したOCR元のtif画像
https://i.imgur.com/FRIY8a9.png
＞最新版から一つ前のtesseract-ocr4.0αでOCRした結果のスクリーンショット
https://i.imgur.com/21b2PK4.png
＞最新版から一つ前のtesseract-ocr4.0α＋blacklist（小書きを禁止＋後処理）
https://i.imgur.com/6Yh4riW.png

>51
＞最新版のtesseract-ocr4.0β＋jpn+jpn_vertでOCRした結果のスクリーンショット
https://i.imgur.com/OmTeJEv.png

>53
＞ 22ポで画面上に再現した擬似元画像
https://i.imgur.com/Z967Vz9.png
＞それをOCRした結果のスクリーンショット
https://i.imgur.com/Psbsp9m.png

>58
＞同じ元ネタ画像をonlineOCRというサイトに投げてみた結果。
https://i.imgur.com/sEPqF76.png

泥タブから見たらimgurモバイル版が勝手にjpg変換するもんで酷い有様になっとった
直リン＆専ブラのサムネ表示の重要性を痛感するわ

**名無しさん＠お腹いっぱい。** · 2018/04/18(水) 11:26:59.67

>>62
さっそく拡張子付けてくれたね

**ハカーを待ちながら** · 2018/04/18(水) 21:35:49.78

>>62
どなたか存じませんが、代わりにお手数ありがとうございます。

この手のサイトにアップロード自体初めてで、ボツ画像を何倍もアップしたのは内緒。
画像上→右クリックで拡張子込みのアドレスが得られるのね。次回があればそうします。

**ハカーを待ちながら** · 2018/04/20(金) 23:15:45.08

最新版tesseract-ocrの認識スコアが最後まで前回レベルで持続できていたら問題はない
のですが、残念ながら大振りゆえブレ幅が大きく、外したときは「なんでこうなるの？」
という結果になってしまいます。。

300dpiでスキャンした元tiff画像
　　https://i.imgur.com/yPcJCI0.png
上記画像を最新のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/eBH0JQn.png
上記画像を一つ前のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/buq3aE5.png
これだと旧バージョンの方が間違える幅が小さいと感じられるのではないでしょうか。

では元画像をチューニングすることでもう少し何とかできないか？　Linux界にはImageMagick
というコマンドラインから使う画像変換ツールがあるので、ぼかしオプションを適用して
もう少し滑らかな曲線に近づけてからOCRしてみました。　

元tiff画像をImageMagickで-blur（ぼかし）オプションを施して太く滑らかにした画像
　　https://i.imgur.com/AQey4zb.png
上記画像を最新のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/TK4GNwm.png
上記画像を一つ前のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/Mr61je5.png

果たしてOCRには画像がどう見えているのか？　結果は変われどあさっての方に振っています。

**ハカーを待ちながら** · 2018/04/20(金) 23:23:17.07

しつこく今度はノイズ除去オプションを使ってみます。
元tiff画像をImageMagickで-despeckle（ノイズ除去）オプションを施して滑らかにした画像
　　https://i.imgur.com/8CE8uD3.png
上記画像を最新のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/0HQ6Pog.png
上記画像を一つ前のtesseract-ocrでOCRした結果のスクリーンショット
　　https://i.imgur.com/JithSee.png

どうも何というか、こじらせているというか、なかなか言うことを聞いてくれないですね。

**名無しさん＠お腹いっぱい。** · 2018/04/21(土) 10:32:53.20

ディティールの失われてる2値画像を後から弄ってもどうにもならんよ
検証用の画像はグレースケールかフルカラーでスキャンしたものを用意する
(業務用複合機だとデフォルト値が輪郭強調の超圧縮モードなのでオプション設定には注意が必要)

過去のものは従来tessaですでにデータ化済んでるんだろうし
今から再OCRのために骨折ってもしょうがない
完全移行の方向でなく単に検証のためにやってるならなおさら
紙原稿残ってるなら再スキャンしてやり直しもいいけどね

**名無しさん＠お腹いっぱい。** · 2018/04/21(土) 14:10:45.01

あー… よく見たら2値画像をカラータイプ変換も拡大もしないで補正かけてんのね
これはヒゲ増えただけでボケてないしOCR的にどうとかいう以前に補正かけた意味がない
https://i.imgur.com/EzPduGV.png
画像に関してある程度のフォーマット知識と目視で判断できる眼や環境がないと
検証に値する画は作れないと思う
これでは勤勉な無能者状態で、申し訳ないが何の参考にもならないし誰の得にもならない

コマンドラインでがんばりたい縛り？なのか知れんけど
まずはGIMPなりでプレビュー見ながら調整して設定詰めて方針が固まったら
本運用時にImageMagickにメモっといたパラメータで流し込むとか手順踏んだほうがよくない？

**ハカーを待ちながら** · 2018/04/23(月) 01:44:27.61

>>67
>>68
高度なアドバイスをありがとう。ご存知の通り画像処理はやったことないし、知識もない。

出がらし状態の死体にいくら細胞活性剤を注入したところで生き返る訳がないのは当然だけど、
せめてゾンビ程度に動けるようにできないかなと、今度はInkscapeを使ってビットマップを
ベクターデータに変換したものを再度pngにしてみたよ。

肉眼にはノイズが減ってクッキリとしたように見えるが、さてOCRからはどう見えるか。
　https://i.imgur.com/u1WXYIs.png
上記画像を最新のtesseract-ocrでOCRした結果のスクリーンショット
　https://i.imgur.com/Ky49xV0.png
上記画像を一つ前のtesseract-ocrでOCRした結果のスクリーンショット
　https://i.imgur.com/i9QwHS7.png

……やはり修正しやすさからいうと、一つ前のtesseract-ocrかな。

不完全なテキストを校正するには、sedによるフィルター処理で複数箇所の一括置換を
やってるんだけど、途中でもっと良いやり方がないかと思って何度もOCRからやり直す
もんだから、文庫や新書をひらきにしたスキャン画像は十冊分くらいあるんだけど、
テキストデータの校正を終わらせて完品にまで至ったのは実はないんだわ。

何度も繰り返すうちにちょっとずつ正解率も向上してはいるんだけど、今度は再スキャンも
検討してみます。

**sage** · 2018/04/23(月) 15:36:58.50

OCRで、ごくまれになのだけど、な-た　の誤読があって。
これにまいったのが遠い思い出。されたい　されない　　というのは
あまりに神経を使うので、自分で校正するのを諦めた。

**名無しさん＠お腹いっぱい。** · 2018/04/26(木) 02:18:58.59

されたい　と　されない　をどうやって校正してたんですか？

**sage** · 2018/04/26(木) 11:36:23.50

突き合わせ。それしかないだろう。みつけるのは、文脈。

**名無しさん＠お腹いっぱい。** · 2018/04/26(木) 21:38:26.21

さすがに肉眼じゃなくて、検索/置換とかgrep的なツールを使ってサーチ、ですよね？

**名無しさん＠お腹いっぱい。** · 2018/04/28(土) 22:11:29.01

あのね、ほんの30年前までは万葉集の中に「●」という文字が
何か所使われているか、一晩徹夜で5回最初から最後までめくって
書き出してリストを作ってたの。

**名無しさん＠お腹いっぱい。** · 2018/06/01(金) 10:48:04.16

同好の士がいるみたいなので私のやり方の一つを紹介

縦書き小説のテキスト化限定
段組み無しか2段組み程度のレイアウトの単純なもの限定
読取革命使用前提

スシャン画像の傾き補正余白除去など画像処理を程々にする

処理した画像を横に8ページ分つなげる（2段組みの場合は縦に6ページ）※これが校正作業効率化の肝

つなげた画像を読み込ませて読取革命で作業

認識率アップは程々に
校正作業効率アップの方が気楽

**名無しさん＠お腹いっぱい。** · 2018/06/01(金) 10:50:24.17

スキャン画像・・・

**名無しさん＠お腹いっぱい。** · 2018/06/01(金) 11:02:23.02

もう一つ

校正前のテキストをワードで開く
原本のページ体裁出来るだけワードで再現する
（用紙サイズ、字数、行数、字間、行間など）
ウインドウ透明化ソフトでワードを半透明化最前面
元画像をにワードを重ねる（行間に重ねたり）
比較校正作業

**名無しさん＠お腹いっぱい。** · 2018/06/07(木) 22:56:25.84

ルビが扱いたいと結局e.Typistしか選択肢がない感じがあるけど
e.Typistは――とか・・・・・・にすごく弱い感じがする
ーや1として認識されるならまだいい方で
空白を認識する設定にすれば空白として出力してくれるけど
逆に言えば文字としては認識されてないことが多いので修正も不能で困る

**ハカーを待ちながら** · 2018/06/15(金) 21:07:25.53

>>75-77
新たなノウハウの提供ありがとうございます。

OCRからの校正作業は未踏の部分が多いし、未だ正解がある訳でもないですから、
こうして持ち寄ったノウハウが少しでも蓄積していくと良いですね。

透過して元画像とテキストを重ねるってのは自分も一度は考えたけど、当時
Linuxでまともに縦書き表示のできるテキストエディタとかワープロはなかった
ので、結局縦書きの元画像と横書きのOCR化テキストを横に並べて見比べるしかなかった。

まあでもLinuxも悪いところばかりじゃなく、1ページずつ200件超えに分割されたまま
一冊分のテキストファイルをタブで全部開き（ページの移動はタブ上でスクロール）、
開いた全ページに跨って検索/置換ができるBluefish（本来はHTMLエディタ）とか
Geany（本来はIDE）が使えるので、Meryやotbedit時代のように検索/置換のために
ひとつのファイルに結合してから校正という手段を取らなくて済むのは良かった。
（好みというか選択肢の問題ね）

今は元画像とテキストファイルを一対一で、突き合わせが終わった分だけ閉じています。

ただ何故かLinuxのエディタって行間を広げるオプションがないのが多くて、仕方なく
ttfname3.exeを用いて（Wineで実行）フォント側で行間を広げる加工をしたのは余談。

**名無しさん＠お腹いっぱい。** · 2018/06/16(土) 09:37:39.11

長文駄レスは過疎の元
自分語りは程々に

**名無しさん＠お腹いっぱい。** · 2018/06/16(土) 13:35:14.61

スレの性質上、情報提供は歓迎
長くても読みとれる情報はある
脳のOCR機能を鍛えるべき

**名無しさん＠お腹いっぱい。** · 2018/06/16(土) 14:01:15.28

情報提供レスが長文になるからこそ雑談は短文で抑えるべき
要点の無い長文日記と入り混じるとどれが重要なレスなのかわからなくなる

この手のスレは情報収集＆提供目的を主として見に来る人がほとんどだし
匿名掲示板で名無し書込みする人間の多くは(特定のコテハンとの)
「過度」の慣れ合いは求めてない、ということを念頭に入れましょう
winユーザーにlinuxでの苦労話で返すようなのは相手の目線に立ってるとも言い難い
雑談するにしても簡潔に

**名無しさん＠お腹いっぱい。** · 2018/06/16(土) 17:16:54.01

長文駄レスやめーや

**名無しさん＠お腹いっぱい。** · 2018/06/17(日) 14:51:45.64

そんなルールはないぞ

**名無しさん＠お腹いっぱい。** · 2018/06/20(水) 00:23:42.81

MSのOCRはどうなんかね？
https://docs.microsoft.com/en-us/uwp/api/Windows.Media.Ocr#code-snippet-4

**ハカーを待ちながら** · 2018/07/10(火) 16:36:25.03

>>82
うーん、>>79を『Linuxの苦労話』としか読んでもらえなかったのは残念だな。
後半の「おかげでWindowsだけ使っていた頃にはできなかった
　・200件超えのテキストファイルを一度に開ける
　・開いている複数のファイルに跨って検索/置換ができる
ことができるソフトに出会えた」ってのがキモなので（だから固有名詞を出してる）、
期待していたレスは『○○というエディタならWindowsでも同じことができますよ』
だったんだけどね。

実際「Windowsで（上記2点）ができるエディタを教えてください」って質問を投げれば
一行で済むけど、経験上質問を一行しか書かない奴って返答してもダンマリだし、人様の
知見をお借りする前に自分でどこまで試したか？　を加えて書き直すと、

「Meryやotbeditではできない（上記2点）ができるエディタを教えてください」

『そんなことできるのか？』というツッコミがあるかもしれないので、自分なりの
知見を追加して更に書き直すと、

「Meryやotbeditではできない（上記2点）ができるエディタを教えてください。ちなみに
LinuxではBluefish（本来はHTMLエディタ）とGeany（本来はIDE）ではできました」

これを自分なりに雑談めかして書くと >>79になるのだが、内容がつまらないと言われると
申し訳ないとしか言えないけどね。

で「Windowsで（上記2点）ができるエディタ」について何かご存じない？>>all

**名無しさん＠お腹いっぱい。** · 2018/07/10(火) 16:44:44.78

長い
要点3行でまとめて

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 00:52:02.90

画像背景のエディタはAA用のがあったと思うけど縦書きには対応してないと思う。
MS WORD には、画像背景として重ねて文字を入力できる機能があった気がするけど
HTMLなら透過レベル指定できると思う。

HTMLでも writing-mode vertical-rl で縦書きできるんだな。

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 11:08:12.89

Linuxなんてただで手に入るし､情報の入手が簡単な現代では小学生でも導入できます。

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 11:36:57.04

いろいろずれているな

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 11:59:37.61

ぶっちゃけOCRの用途はPDFに透明テキスト埋め込むのが目的な人が多いだろうし
それは置いとくとしてもテキストエディタ云々はもうOCR関係なくない？

200pを各ページごとにファイル分けて全部一遍に開きたいというのは運用としても特殊すぎる
Grepで横断検索できてピンポイントでファイル開ければ
同時オープンファイル数は20もあれば充分だと思うが

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 16:59:13.66

完全なテキスト化を目指す人にしてみればそっちも重要

**名無しさん＠お腹いっぱい。** · 2018/07/11(水) 17:04:31.64

校正作業効率化　その３

複数ファイル複数条件一括置換ソフト
「TextSS.net]

いろいろ捗る

**名無しさん＠お腹いっぱい。** · 2018/07/25(水) 21:52:36.75

>>91
まあ確かに完全テキスト至上派といえども、200ページ以上にまたがった
要・校正テキストファイルをイッキに処理できる集中力の持ち主なんてのは
完璧超人か紙一重だろうから、常人は真似できないしするべきでもないし、
確かに実際は一度に20件も開ければ十分だろう。

ただ、できるけどしない　と　できないからやれない　とは違うから、
ツールの限界は少ないほうがいいし、選択肢は多いほうがいいと思うぞ。

せめてタブで開いた複数のファイルに対して一度に検索/置換できた方が
便利だと思うが、Windows用でご存じないか？

ちなみにBluefishもGeanyもオープンソースなソフトだから、Windows版も
実はある。

**名無しさん＠お腹いっぱい。** · 2018/07/25(水) 22:14:26.85

#折角なので乗っかる

校正作業効率化　その４

対象がフォルダでもファイルでも検索して、置換もできるツール
Devas

すでに開発は終了したようだが、Wineを介せばLinux上でも動作するのが◎。
検索結果の文字がセンタリングされて上下でビシッと揃うので視認性も◎。
検索結果を好みのエディタで開けるように設定できるのも◎。

**名無しさん＠お腹いっぱい。** · 2018/07/26(木) 00:25:51.34

ファイル開いてなくてもgrepで一括検索も置換もできるし
200ファイル開いて操作するほうが大変なのでできないよりできたほうがいいとも思わない

が

＞ちなみにBluefishもGeanyもオープンソースなソフトだから、Windows版も実はある。
ならそれ使えばいいんじゃないですかね
無理難題系をわざわざ人に聴かなくても自分で出来るソフト知ってるならさー

**名無しさん＠お腹いっぱい。** · 2018/07/31(火) 00:40:51.95

>>96
>ファイル開いてなくてもgrepで一括検索も置換もできるし
>200ファイル開いて操作するほうが大変なのでできないよりできたほうがいいとも思わない

――そんなふうに考えていた時期が、俺にもありました。
確かにファイルを開かずともgrepやsedで検索/置換はできるけど、修正すべき間違いを見つけるには
結局一件ずつファイルを捲って見つけなきゃならなかったのよ。

勿論こういう作業に正解がある訳もなく、己の趣味とか流儀に従って粛々と各自でやっていくしか
ないけど、多様性の確保のためにも自分の流儀にかなわない手法を否定してほしくはないけどね。

>＞ちなみにBluefishもGeanyもオープンソースなソフトだから、Windows版も実はある。
>ならそれ使えばいいんじゃないですかね
>無理難題系をわざわざ人に聴かなくても自分で出来るソフト知ってるならさー

ィャ自分が知らないだけで世の中にはもっと優れたソフトがあるかもしれないから、
それを知りたくて、知ってる誰かに会えるかもしれないから、ひとはこうして掲示板に
集うんじゃないの？

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

3年ぶりに覗きに来たけど読み取り革命まだバージョン上がってないんか。
250dpiぐらいの低解像度のOCR得意なオススメありませんか？

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

>>98
苦手なのは国会図書館から提携図書館に送ってもらったコピー。

認識率が悪いときはコントラストとガンマ値を調整すると、それなりに読める。

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

>>99
2年前から読み取り革命を使ってます。

**名無しさん＠お腹いっぱい。** · 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

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

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

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