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

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

今どきディープラーニングも使わないtesseractじゃね・・・。


自作アプリに組み込んだが、
認識精度は低かったぞ。

さて、それなりに吟味して作ったブラックリストの内容を記述したファイルをとりあえず

black.conf

とでも名づけて保存しておきます。

当テスト環境はLinux(LinuxBean)なので、文字コードはutf-8、改行コードはLFですが、
Windows環境でこの辺どうすべきなのか、当方には不明です。

あとはシェルスクリプトを介してtiffファイルの数だけOCR処理を繰り返し処理させれば、
マシンパワーに応じた待ち時間の末に同じ数だけtxtファイルが出来上がります。


以下点線の内側をシェルスクリプト ocr.sh として保存します。
----------------
#!/bin/bash
#連番ファイルの1009.tifから1360.tifまでblack.confファイルのブラックリストを
#参照しつつtesseract-ocrでOCR処理を繰り返す

for i in `seq 1009 1360`
do tesseract ${i}.tif ${i} -l jpn black.conf
done

ちなみにLinuxではファイルとかフォルダの位置関係が重要なので、このスクリプトを
目論見どおり動作させるには、同じフォルダに必要なファイルを全部入れておく必要が
あります。トップディレクトリ直下のDocuments辺りがいいんじゃないでしょうか。
（裏を返すとファイルパスを指定することで全然別のところからも参照できます）

・OCR元のtiff画像ファイル（1009.tif〜1360.tif）
・シェルスクリプトファイル（ocr.sh）
・ブラックリストファイル（black.conf）

tiffファイルが1009から始まっているのは、スキャンした後連番リネームするときに
ノンブル（ページ番号）と同じ番号にしておくとスキャン時に重送しなかったかが
すぐ分かるので便利だからです。つまりこの本は本文が9ページから始まり360ページで
終わっているということです。4ケタなのはゼロ埋めが面倒だからです。

シェルスクリプトを実行すると、できあがったテキストファイルも同じフォルダ内に生成
されます。
・1009.txt〜1360.txt

（連番リネームやファイル連結はやっぱ古兵のvixが便利なのでwine上で愛用中）

なおtesseract-ocrには対象が縦書き文書であることを強制指定するコマンドオプションが
ありますが、これは罠です。そんなものを指定しなくても縦書き/横書きを自動認識しますし、
むしろこれを指定すると段組みを認識しなくなるので指定してはいけません。知らなかった
ばっかりに二段組を上下に分割して以下略……。

>17
まあそう急くなて。

>13にもチラと書いたけど、Google Cloud Vision APIってプログラムとかアプリそのもの
じゃないから、『使え』といわれて使えるひとって既にエンドユーザーじゃないし。

そりゃ話聞くとGoogle Cloud Vision APIって、良い意味で『コレ世に出していいの？』
レベルらしいし、ある日を境に木製複葉機が一斉に時代遅れになったのも知ってるけど、
ジャンルによらず古典に親しむのは大事なことだし、何より初手からそんな最先端使って
ったら、ディープラーニング様の有り難みが感じられないじゃないですか。

変速機のないギヤ比固定のママチャリで坂道を登った経験があるからこそ、人は変速機
付きの自転車に感謝できるのだとは思いません？

で、その一方で変速機ナシの自転車でもギアを交換して坂道を登り易くすることはできない
ことじゃないんだけど、いかんせんこのtesseractってチャリは情報が少なくてね。

tesseract-ocrでどこまで行けるのか、もう少し先まで見てみたいんですよ。

クレジットカードもいらないしね。

「うわっはっはっ、何を言い出すかと思えば、所詮はクレジットカード一枚作ることが
できない自宅警備員のたわごとではないか。カード一枚と引きかえに最先端のAIや
ディープラーニングが手に入る時代に、tesseract-ocrなどという旧態依然のフリーソフト
にこだわるなどとは笑止千万。本当の最先端が今やどんな高みにまで昇りつめているか、
この私がお目にかけよう」

と、白髪混じりのオールバック美食家なスーパーハカーが登場して、エンドユーザー
にもやさしく解説してくれるなら、アタシは黙って身を引くわ……。

OCRについて検証したり語らったりできる場所ってここくらいしかないし
tesseract-ocrもなんでも小さな情報でもどんなことでも俺はウェルカムだよー
使い方見たり知ったりすればそれを生かす機会が来るときもあるかもしれないからね

tesseract-ocrの識字率を上げるためにスキャン画像から学習ファイルを作る手口は、
検索でヒットする幾多のサイトで指南されています。

さながら刀匠のごとく、コマンドを重ねて玉鋼から刀身を作るように順繰りに加工していく
訳ですが、Linux版tesseract-ocrのver.3.03だと途中の unicharset というコマンドが
なぜか実行できず（『そんなプログラムありません』でエラーになる）、ubuntu16.04LTS
（16年4月製長期サポート版の意）でver.3.04を試したらやっと最後の jpn.traineddata
ファイルの生成まで辿り着けたのですが、実はこれと同じ名前のファイルはすでに
アプリケーション側の設定フォルダにあります。

元の jpn.traineddata は30MB超えの、テキストエディタでも開けないようなゴツい代物で、
対する新jpn.traineddata は1MB足らず。ならばあとは旧ファイルの認識がおかしい部分に
新ファイルをマージすれば良さそうですが、その手段が何故か何処の指南役サイトにも書いて
ありません。

旧ファイルに匹敵するサイズの新ファイルをゼロから作るのは現実的ではないと思われますが、
先達がこの辺をどうしているのかは不明。

ちなみにWindows版tesseract-ocrには tesseract-box-editor というMicrosoft .Net
Framework 4.0で動作するアドオンだかがあって、それを使うと新旧ファイルをマージできる
らしいです。

「ネットに載っていないblacklistファイルまで自力で辿り着けたのはなかなかだが、jpn.traineddataが元のままなのはいただけないな」
「！」
「一週間お待ちください。本物のtesseract-ocrの実力をお目にかけますよ」

井上和彦の声で喋るオールバックのスーパーハカーの登場をお待ちしています。切実に。

tesseract-ocrの、30MB超えで開くことすら困難な設定ファイル jpn.traineddata。
この中には日本語認識する際のルール・ファイルが各種入っているようですが、
開けないファイルからどうやって取り出すのか、長らく謎でした。

とりあえず認識結果後の変換マッピングを司る jpn.unicharambigs に関しては、
このコマンドで掘り出して、
$ combine_tessdata -e tessdata/jpn.traineddata jpn.unicharambigs
別ファイル化して修正したのち、このコマンドで再度埋め戻せることが分かりました。
$ combine_tessdata -o tessdata/jpn.traineddata jpn.unicharambigs

tesseract-ocrはver.3.04になって認識率がやや向上し、3.03では
並
ョ
と二文字の並びと見なされていた縦書きの　普　がキチンと一文字と認識されます。
それでも縦書きで三点リーダーが二個（……）並ぶのは不得手らしく、認識結果は
ナカグロが六個（・・・・・・）並びます。

もっとも blacklist で認識候補の記号を制限する前は、羅列するのもバカらしいですが
順列組み合わせで200パターン以上になっていたので、それを思えば検索置換一発で修正
できるようになったのは、楽なものです。

でももっと楽になりたくて、『・ が三個連続したら、問答無用で、… 一個にする』
という修正パターンを書いてマージしたのですが、何故か反映されませんでした。

何がいけないというのでしょう？

3　・・・　1　…　1
2　並ョ　1　普　1　（←3.03の場合はこう書けば一文字になると思われる）

無料で

数式OCRできる方法教えてくれ

googleのはなあ…
こいつらに情報渡したくないからいくら良くても使えないわ

逆に言えば渡していい情報ならいくらでも使える。
スマホやタブでスキャンして、資格試験の暗記問題なんかをタイプウェル用のテキストにしようと
思って、試行錯誤した結果googleに落ち着いた。
なんとなくここに来たら、やっぱ同じ結論か。

あとはコンデジ使うかスマホ使うか

自炊板に書いたけど、こっちにも置いておくかな。

88 名前:名無しさん＠お腹いっぱい。 [sage] :2017/08/20(日) 10:04:39.07 ID:2KZZB/L/
Google Cloud Vision OCR使って検索可能なpdf作るコマンド昔作ったけど、Googleがjsonの形式変えて後ろに余計なものつけたせいで使えなくなったw
直したいけどヒマないな…

https://github.com/dinosauria123/gcv2hocr

Linux用。Bash on Windowsでも使える。

自炊版てどこですか

たぶん電子書籍板のことかと

ありがとうございます

所見

サンプルの画像に対してOCRかけて
｢この画像に○○のソフトでOCRかけてかけるとこういう風になりました｣
ってのないの？
さすがに言葉だけじゃ微妙な感じが全然伝わらないから

>>38
自炊技術総合25@電子書籍板のレス番#906に、Windows版VietOCR(=ベトナム語用OCRソフト)を
使った結果のスクリーンショット画像が載ってる。
https://i.imgur.com/tj1ARCW.png

OCRエンジンは毎度おなじみオープンソースのtesseract-ocrを使ってて、VietOCRは
窓口だけのはずなのに、認識した文字列の正解率が横書きのみとはいえ何故か異様に高い。
Linux版は、インストールしてみたけど間違え方が違う程度で、Windows版には及ばなかった。

Windows環境で横書き文書をOCRしたい人は試して欲しい。

#Linux＋tesseract-ocrの結果サンプル画像はもう少し待ってくれ

cloudvisionは？

>>39
確かにそれは参考情報と言われれば参考情報だけど
原本が都合よすぎるだろ？
言ってみれば、OCRソフトにとって最も力が発揮出来る状況=ベストエフォート？を示しただけに過ぎないって言うか。

その原本は文字オンリーで図も表もグラフも無くて、しかも1つ1つの文字が人間にとっても明確に視認出来るから。

自炊してる人にとっちゃ家庭用スキャナでスキャンしたものはその原本までハッキリ･くっきりじゃないし、図･表･グラフ･写真･数式あるし

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

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

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

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

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

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

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

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

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

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

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

遅くなってすまん
まとめるとか偉そうに言ったけどほぼに↓の通りにやっただけ
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 が一番精度良くなるよ

>>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と似たようなもんかしら。

神のお言葉に従いテストベッド環境に最新版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点リーダー]を正しく認識できないが、これが現段階の自身でできる
最善のチューニング状態。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>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変換するもんで酷い有様になっとった
直リン＆専ブラのサムネ表示の重要性を痛感するわ

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

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

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

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

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

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

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

>>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からやり直す
もんだから、文庫や新書をひらきにしたスキャン画像は十冊分くらいあるんだけど、
テキストデータの校正を終わらせて完品にまで至ったのは実はないんだわ。

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

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

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

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

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

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

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

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

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

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


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

スキャン画像・・・

もう一つ

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

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

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

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

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

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

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

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

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

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

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

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

長文駄レスやめーや

そんなルールはないぞ

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

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

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

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

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

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

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

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

長い
要点3行でまとめて

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

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

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

いろいろずれているな

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

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

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

校正作業効率化　その３

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

いろいろ捗る

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

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

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

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

#折角なので乗っかる

校正作業効率化　その４

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

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

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

が

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

がんばれー

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

「できらあ！」

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

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

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

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

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

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

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

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

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

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