【文字認識】OCRソフト（3文字目）【 自炊 】

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

主なOCRソフトウェア（市販ソフト）
・読取革命16（開発元パナソニック、販売元ソースネクスト）
・本格読取5（開発元パナソニック、販売元ソースネクスト）
・e.Typist v.15.0（メディアドライブ）
・ABBYY FineReader PDF 16（ABBYY）

主なOCRソフトウェア（フリーソフト）
・tesseract-ocr
・PaddleOCR
・RapidOCR
・NDLOCR
・MangaOCR
・bunkoOCR

過去スレ
【文字認識】OCRソフト【 自炊 】
https://egg.5ch.net/test/read.cgi/software/1470745451/l50

【文字認識】OCRソフト（２文字目）【 自炊 】
https://egg.5ch.net/test/read.cgi/software/1701326685/l50

>>755
行の中で文字の幅を合わせるのは、実はpdfのフォーマット上めっちゃ難しいのです。
フォントで設定されている文字幅と、認識した文字Boxの大きさとの倍率を調整して誤魔化さないといけない。
bunkoOCRでやってる位置合わせも、だいたいしか合わないのです。
行として文字列の検索を当てやすく文字列にするか、完璧に位置を合わせるために一文字ずつ置いていくか
のうち前者を採用すると、比率をでっち上げて行の末尾を合わせるくらいしか出来ないのです。

文字単位で配置するとコピペが不便になりそう

ルビまではとりあえずいらないけどNDLのXMLにルビの位置情報があるがテキスト自体が含まれてないところみると解析まではしてないのかコレ
たまに本文あたりにルビが紛れこんだりしてるが、このルビの位置情報と照らし合わせて捨てればいいのかな

複雑なレイアウト解析まではyomitokuにまかせてNDLは単純な構造の解析をいかに高精度にやるかを頑張ってほしい

>>756
そうですか。それでとりあえずpdfはベータ版としてリリースしたのかな
bunkoOCRはWindows版しか使っていないのでpdfがどうなっているかは見ていません

今のAcrobat Readerは透明テキストの途中にスペースや改行が入っていても それらを取り除いた文字列で
検索できるようなので、透明テキストは文字列にして スペースを混ぜたりしてごまかしてもらうのがいいのかな
検索できなければ意味ないですしね

Acrobat Readerは行またぎの検索はできるけどページをまたぐと検索できないのが残念
ワードとかではできるのにね

pdfのiFilterはいつのまにかAdobeが勝手に削除していることに気付いたのでサイトに残っていたPDFFilter64Setup.msiをインストールした
消される前のiFilterは何だったのかは気にしていなかったがその時にはできなかった行またぎ検索ができるようになった
スレチごめん

NDLOCRLiteの出力pdf解像度下がらない？

NDLOCRはブロック化が優秀なんやな。しっかりまとめてくれる

NDLOCRで縦書き中の横書き「22」は「2」になってしまい「23」は「 」(スペース)になってしまった
縦書きで横書き数字2桁という書き方は割と使われるように思うのだが・・・

知ったかすると縦中横とかいうやつね。そこら辺はNDLだめだめぽっい。いろんな組版頑張ってるのはbunkoocr？

1とかIとかの区別はLLMとか組み合わせんと無理やね。超ミニミニSLMとかで修正

>>763
PDFは72dpiで作られるみたいだからソース画像をそれに合わせてサイズ変更すればいいんじゃないのかな

NDLOCR-lite、なかなかいいです
一番面倒だった章タイトル、ページ番号を最初にクロップ処理で指定しておくと
残りのファイルも全部自動で処理してくれる
この処理は自炊なり拾ったPDFなりjpg変換したあとで手動で色んなソフト使ってやってたけど
時間も手間もかかるしスキャン時のズレもあるから自動化できずに最後は目視で確認でとにかく大変だった
これをやらずに済むだけでかなり助かる

まぁ、GPU使ってないので速度は遅いけどね
750ページの文庫本で30分ぐらいかかった
bunkoocrの作者様には悪いけどこちらに浮気してしまいそう
速度が遅くても前述の処理の時間がいらないので合計時間だと多分早い
それでもbunkoocrのバージョンアップに期待です

ndlocrliteはベータだけどnvidia gpuあればcudaでうごかせるんじゃないかな

--device cudaオプションがある

NDLOCRが作成するPDFはストリームがASCIIで書かれていてサイズが大きいので
qpdfでバイナリに変えたらサイズを小さくできた

NDL系ってどんどんいろんな技術とりいれてるのか？
bunkoocrの作者はやる気触発されたかな

NDLOCR-lite使ってみた
精度も速度も良い感じだけど欠落が多い

ndlocrって学習データは公開されてないんだよね？
bunkoocrもそうだけど学習する場合どれくらいのスペックのどれぐらいぶん回せばいいんだろう

NDL-OCR事業の資料
https://www.nijl.ac.jp/pages/cijproject/info/img/event/r04/nijl_sympo2022_handouts_3.pdf
https://lab.ndl.go.jp/data_set/ocr/r3_software/
https://lab.ndl.go.jp/data_set/r4ocr/r4_software/
https://github.com/ndl-lab/pdmocrdataset-part2

bunkoOCRの資料
https://github.com/lithium0003/findtextCenterNet
https://huggingface.co/datasets/lithium0003/findtextCenterNet_dataset/tree/main

学習データで、レイアウト認識は実地のデータでやらなきゃなので、けっこうデータ数がいるはず。
国会図書館のやつは約247万点（約2.2億画像）だって。

bunkoOCRのやつは、基本的にfontから生成したテキスト画像を元に学習してる。100*1024枚くらい
後は実地のデータとして手元でスキャンした画像を追加して失敗しそうなやつを修正してる。
findtextCenterNetは、条件確定したらA100で数日くらいやれば十分だった。
BatchNormarizationのせいでバッチサイズを大きくしなきゃなのでA100とか使ってるけど、
そこさえなんとかできれば、もっと小さいGPUでも学習出来ると思う。

>>776
おお、詳しくありがとうございます
A100か。調べたら定価300万のやつか。だからiOSアプリでGPU借りるようの募集してたんですね。
ocrの技術調べてたらおもしろくなって学習について興味を持った次第です

短冊状に認識行の画像を取ってきて、文字列を生成するモデルに入れて、OCR結果を得るというタイプと
文字の場所を特定して、一文字ずつ文字を生成するモデルに入れて、OCR結果を得るというタイプがあると思う。

アラビア語とか行書とかは、前者の方式が強いと思う。
日本語みたいに一文字ずつ切れてる言語は、後者の方がよさそうに感じてる。

ocrした後の誤認識修正して再pdf化するのになんのソフト使ってますか？

>>778
そこらへんもちょっとだけ日本の3大OCRを比較して勉強してました
ndlocrとYomiTokuはレイアウト解析で行を求めて、その行ごとPARSeqになげて言語知識(ViTrasfomer?)なども踏まえてテキスト認識
bunkoOCRはCenterNet+EfficentNetで文字レベルの位置と特徴をもとめて、特徴を後段のTransfomerにぶんなげて言語知識が補正?

アラビア語とかつなってるやつ、文字レベルで分割が大変そうだからPARSeqとかの方がよさそうですよね

>>780
bunkoOCRで、文字レベルの位置でやってるのは、文字の横についてるふりがながどの部分にかかってるかを
検出したいというのと、そもそも日本語と英語くらいしか知らなかったからというのがあります。
くっついてる文字の言語や、筆記体や速記みたいな文字も、それぞれの文字部分に分割は可能っぽいので
やろうと思えば不可能では無い感じです。
(Unicodeからフォントで生成するとそれぞれの文字の領域が取れるので、ある程度自動生成でアノテーション出来る)
文字ごとの位置を求めると、文字の属性を別途与えることができるので、文字空きとかふりがな文字とかのマークとか
文字のコードとかを直接生成出来るのが利点です。

PARSeqの手法では、短冊状（にかぎらず行を取って来れればいい)に取ってきた画像を、直接文字列に起こすので
行を取り損ねるとミスると思うので、曲がった文字列をどう切り抜くかがポイントなのかなと思います。
この手法の利点は、少々ノイズが入っていてもこの時点で前後から補正出来るということです。

初見。どもこん。
Rust_DN_SuperBook_PDF_Converter　(及び必須な関連ツール)をWindows 11下に環境構築したいんですが、全くわからないです。
どこを探しても、Mac系(？)の解説サイトばかりでコマンドラインの操作を説明しててWindows 11ユーザーにはわからないです。
Windows 11ユーザーでも分かる解説サイト教えてください

rust版は何やっても動かんから諦めたわ
大人しく本家の使うがよろし

レイアウト解析やOCR精度はgeminiがぶっちぎりで最強なんだけどサーチャブルpdf作れないのが難点
geminiでテキスト抽出したのにyomitokuでもう一回ocrかけるのも二度手間感あるし

語彙力ぅ.....OCRも色々あるけどAIのOCRが一番精度いいの？
しらんけど

一番かは知らんけど格安でもそこそこ認識してくれるよ

語彙力…？文章中に気に障るところでもあったか？
やってみれば分かるが、マルチモーダルLLMは複雑な表や手書き、特殊文字への対応が比較にならないほど優れている

語彙力…？文章中に気に障るところでもあったか？
やってみれば分かるが、マルチモーダルLLMは複雑な表や手書き、特殊文字への対応が比較にならないほど優れている

いうて流石に外部Aiに社内の内部情報とか読ませるわけにはいかんから言うほど使えない

それはそう。ローカルで回すとなるとgemini3より何段階か劣るのになる
Qwen3.5とかね

NDLOCRliteもアップデート期待できなさそうやな
お役所仕事で予算とかあるのか？
liteは外部委託じゃないっぽいけど

ndlocrは振り仮名がつかないのが問題
たいして試してないので実は付けられるんだったら謝るけど
２冊ほど読み込ませたら振り仮名ついてなかったよ

>>788
大事な事なので2回いいました？？？ｗｗｗ

初見、どもこん
~5日後~
語彙力ぅ⋯
大事なことなので2回いいました？？？wwww

この間3レス
久々に大物来たな

>>792
ルビは座標取れてて、わざと除外してる様子

>>794
初見、どもこん は明らかに別のやつだろｗｗ
一々監視してるお前もきもいわｗ

どうでもいいです
生産性のない生ゴミは焼却場に飛び込んでどうぞ

単なる漢字に対する振り仮名なら無くても読むのは可能だけど
当て字になってたり、英語表記になってたりする場合はあったほうがいいな
そうするとやはりbunkoocrに期待してしまう
もう１年ぐらいバージョンアップしてないしずっと楽しみにしてる
ページ番号と章タイトルを自動でトリミングしてくれる機能があれば
一冊辺りの本の電子化にかかる時間が大幅に短くなるんだけど

>>798
いらないところを分類するモデルができたっぽいので、ご期待ください。
ページ番号とかの本文じゃないところを検出出来るようになった気がしてる。
枠線とかも認識して、新聞とかの段組を順序正しく読めるようにがんばってるところ。
もうちょいかかりそうなので、まっててください

>>797
自殺教唆の💩製造機くんは一生畑の肥料作っててどうぞｗｗｗ

NDLOCRバズってるよな
githubスター一気に1,000とか
他と性能的に大差ないと思うが
国家機関？だからか？

NDLOCR-Lite が試し易いからでしょう。
他のOCRと同じ間違い方をするので、本のフォントが悪いくて正しく読めないかな、と私は諦めた。

文庫本のOCRでだが
NDLOCRは欠落が多く、難しい漢字の誤字も多い印象
bunkoOCRは修正する必要が少なく優秀さが際立ってる

bunkoOCRやYomiTokuもCPUで高速に動作かつプログラミング知識なしで利用できるようになったら普及しそう

プログラミング知識はなくても利用できるでしょう

NDLOCR liteはテキスト認識の縦が16ピクセルしかないから精度悪め？

ちょっとスレチだが以前話が出ていたので・・・

エディタでテキストを印刷して作ったPDFをSumatraPDFで開いてみたら行またぎだけでなくてページまたぎも検索できた
Acrobat Readerではできない

>>807
>>エディタでテキストを印刷して作ったPDFをSumatraPDFで開いてみたら行またぎだけでなくてページまたぎも検索できた
この時、印刷（PDF）したドライバーは何でしたか？
エディタの名前は？
エディタの表示モードは「縦書き」でしたか？
縦書きPDFが難しいと言う事なのでこういった情報がヒントになるかもです。

プリンタはMicrosft Print to PDFです
自分はいまだにSJISをメインに使っているのでWZ Editor 3の横書きです
ヘッダー・フッター・ページは除いて印刷
SumatraPDFはまだテスト中ですが縦書きではフォントが埋め込まれていないと
句読点が横書き用になってしまうという話は聞いています
PDFのフォント情報を見たら CIDFont+F1 (TrueType (CID); Identity-H; embedded) になっていました

スキャナに付いていた古いPower PDFとNDL_OCL_liteで作成した縦書きPDFを試したところSumatraPDFではページまたぎ検索ができた
ファイルの右クリックメニューにまでサブスク機能を出すようになったウザいAcrobat Readerはアンインストールした
SumatraPDFはIFilterがインストールできるようになっているが機能しなかった
レジストリを見たらHKCR\.pdf\PersistentHandlerからPdfFilter.dllまでつながっていなかったので動作するはずがない
自分はウィンドウズサーチをよく使うので探しておいたAdobe製の古い64bit IFilterを再インストールした
但しIFilterでは原理的に行またぎ検索はできないが

すみません　レジストリは読み間違えてました
「すべてのユーザーに対してインストール」にチェックを付けてみたらIfilterは機能した
Adobe製より検索の取りこぼしが多いと作者も書いていたので使わないけど

NDL OCR liteはpngで画像を保存してしまうから元画像を不可逆圧縮しておくことは無用だね
bunko-ocrがpdf作成をサポートしてくれる時にはOCRmyPDFのように元画像を保存できるようにして頂きたいです
pdfのサイズは自分で調整したいので

Gemma4出たけどローカルでこれに勝てるオープンソース無くない？

書き起こしAIの進化もいいけど
リアルタイムで読み込んでログに吐き出すとかそういうUI・IOレベルのの機能性の進化が中々行われない

テキストや画像を音声読み上げして、それを聴いてテキスト変換？？？

>>814
プライバシーもあるからじゃない？監視資本主義とか最近言われてるじゃんｗ
Enter押してから情報が送信される方がプライバシー的にも安全かと

bunkoOCRのjsonには１文字ずつの座標も書かれているようだから透明テキスト付きPDFを自分で作れるかな
作者様が作ってくれるにこしたことはないけど

bunkoOCRが出力するjsonと元画像から画像を変更しない日本語透明テキスト付きPDFを作ってみた
画像は電子テキストのスクショ
使い物になる既存ツールがなくPythonのライブラリを使う必要があるようだ
自分はPythonに慣れていないのでGeminiにhOCRをPDFに変換するスクリプトを書いてもらった
hOCRへの変換はjsonに書かれている数値をそのま使った
ちょっと位置がずれたけど検索できるPDFができた
jpegの他に圧縮率が高いモノクロのJBIG2にも対応
https://62.gigafile.nu/0727-c07f987827af7af3cbb2aaf524bdffeef

透明テキストなのでフォント埋め込みは不要ではないのかとGeminiに聞いたら
スクリプトを少し変更してくれました
事前に画像を加工してからJBIG2に変換すれば写真部分も少しは見やすくなるのかな？
https://68.gigafile.nu/0727-bd023607a527ef2fd34c772d8d09e56fb

>>818
> ちょっと位置がずれたけど検索できるPDFができた

sample.png.jsonの一文字目の座標をGimpに入れて見たら最初から文字の位置がずれている気がする
しかもPDFに埋め込む段階でそのずれが大きくなっている

https://i.imgur.com/1YZ83Oh.png

"box": [
{
"blockidx": 0,
"lineidx": 0,
"subidx": 0,
"vertical": 0,
"ruby": 0,
"rubybase": 0,
"emphasis": 0,
"cx": 244,
"cy": 738,
"w": 23.1483002,
"h": 21.8736,
"text": "菅"
},

>>820
ごめんドキュメントにないな、cx, cyは中心位置なので、boxは(cx-w/2,cy-h/2,cx+w/2,cy+h/2)で書いてください。

>>821
なるほど、cから想像が出来てもよさそうで、こちらが早とちりしました

>>818,819
そのような扱いになっているのかGeminiに確認してみてはどうでしょう

>>818,819
BunkoOCRのJsonを直接処理するように改造した
効率悪そうだけど横書きはぴったり

https://pastebin.com/aeB9HnPk
https://i.imgur.com/v0lErte.png
https://i.imgur.com/qUjtgzA.png

>>820
ありがとうございます　ぴったり合いました
bunkoOCRではテキスト出力で行が変になっていても文字単位でPDFにすれば問題なしですね
PDFリーダーは意外と賢くて縦横混在ページでも段組みがあるページでも検索できて便利

GeminiにhOCRを使うように作っておいてもらったのは後でNDLでも使おうと思っていたためです
そちらは文字単位の座標がないので縦書きは面倒だし正確にはできないけどね
NDLのPDF画像を任意の不可逆圧縮画像に差し替えたい

>>823
専用スクリプトありがとうございます
あいにくJBIG2ではエラーになってしまいました
対応していただくことはできますか
Pythonはほとんどわからなくてお願いするしかないのですが・・・

>>825
自分も詳しく無いけどAIがなんとかしてくれた
https://pastebin.com/dNmnVHmn
https://i.imgur.com/HOCkho7.png

$ pip install pymupdf --only-binary :all:

>>826
ありがとう　JBIG2も読み取れました
近くKindleのDRM解除ができなくなると予想されているので替わりに
白黒2値だが非常に高圧縮のJBIG2でpdf化しようかと考えていました
サイズが変えられないのは難点だがいつも同じ大きさで読んでいるのでそれに合わせてスキャン

「NDLのPDF画像を任意の不可逆圧縮画像に差し替えたい」と書きましたがAIに聞いたら826さんが使った
pymupdfを使うとサイズが同じ画像で置換できるという回答でした
巨大なNDLOCRのPDFを好きなように圧縮できるので安心しました
https://36.gigafile.nu/0729-dc8d1a276928acdad7ea69853d4c83555

block情報も利用して縦書きのラインを揃えた
https://pastebin.com/7rWVsnNT
https://i.imgur.com/3aywECH.png
BunkoOCR専用度増し増し

>>827
pdf化はどうやって?

>>830
823-826-829さんのツールを使うのであれば
bunkoOCRは品質のよい画像で使って、サイズを落とした画像に変換をしておいて、
ツールでそれを指定してpdfを作るだけです
pdfはページごとになるけど結合ツールは色々あるでしょう

>>831
いえ、Kindle書籍から作るのは自明ではないような（そういう話じゃないのかな）
もしかしてスクショを撮ってそれを変換とか? という気素朴な疑問です

>>829
画像→PDFのオーバーヘッドが819よりも少し大きいので10個まとめてpdfを作ったらどうか試そうとしていたら
途中でエラーが発生しました
指定画像はpngでもjbig2でも発生
https://74.gigafile.nu/0730-b986119e63a9000debde011fa8daf0c4f

>>832
近くKindle for PCは使えなくされてDRM解除はできなくなりそうです
新リーダーでスクショがブロックされたらアウトですがスクショが取れればUWSCのスクリプトとかで
まとめてスクショを取って変換するつもりです

エラーにならなかった9個を1つのPDFにまとめてみました

jbig2のサイズ合計86.5KB
819のpdf 129KB
829のpdf 185KB

今までepubで保存できていたのができなくなるので代替としてできるだけ小さく
保存しておきたいという特殊用途には向かないようでした

>>833,835
パブリックドメインや所有物(紙の本)に対する個人的な利用範囲内での使用を想定してました
別の人との話の流れ的に電子書籍の権限外利用に使われそうなので一旦打ち止めにしようと思います

ndlocrlite改善きたー
もう精度あのまんまかと思ってたわ

おお。モデルの修正入ってるやん
試そう

縦中横検出ができるようになったのか

振り仮名は付けてくれるの？

ndlocrliteのjsonは縦書き横書きどちらのテキストにも
"isVertical": "true"
と書かれているのはどうしてなのかな

縦中横直ってないじゃん
https://www.toyobijutsu-prt.co.jp/com-design/dtp-63/
の例をためしたけど一番最初の
最初の「帝国の支配は52年続いた。」からデタラメ。

>>842
https://i.imgur.com/WcJingk.jpeg

>>842
--enable-tcy --tcy-min-line-width 25 --tcy-seg-min-gap 3 --tcy-max-aspect-ratio 0.82 --tcy-ocr-margin-ratio 0.2

数字・位取り・小数点について
・連数字、適用する数字の桁数
(例)
(1)帝国の支配は、52年続いた。
(2) 気温が氷点下になったのは112年ぶりのこと。
(3) 気温が氷点下になったのは112年ぶりのこと。
・漢数字とアラビア数字の統一 (西暦など)
(例)
(4)二〇一一年九月から続いた●●内閣は五ヶ月あまりで
終了し、 2012年1月に××内閣が誕生した。
数字4桁以上の時の位取り
(例)
(5)静岡県浜松市の面積は約一五五八kmiである。
(6) 静岡県浜松市の面積は約一、五五八kmiである。
(7) 静岡県浜松市の面積は約一.五五八kmiである。
・小数点
(例)
(8)濃度0・5%の食塩水
(9)濃度0.5%の食塩水
(1)濃度0.5%の食塩水

流石に㎢は2がちっちゃすぎて出ないか

コマンドラインで指定する必要があるのね
２桁の数字くらいGUI版デフォルトで対応してほしいな

Win+Shift+Tの画面OCRは自動で縦中横認識出来る

というか横しか対応してないオチとか

bunkoOCRはテキストの行が入れ替わるだけでなく、テキストのブロックが丸々抜けてしまうことがあり、
そういう時にはjsonにもそのテキストのブロックは記録されていない
それでも文字は全部精度よく記録されているのでjsonでPDFも作っておくのがよさそう

>>849
あれやこれや処理してる時にバグが取れてなくて飛ぶことがあるので、失敗する画像例を作者に送りつけてくれると
バグの発見が速くなるのでもしよければ送っておいてください。
だいぶ直したけど、まだリリースできてなくてすみません

>>850
作者様に以前メールでお送りしたブロック順がメチャクチャになり横を縦と認識された部分もあるサンプル
https://i.imgur.com/rr8qttx.jpeg
でPDFを作ってみました
「テキストのブロックが丸々抜けてしまう」は見間違いでした　すみません
SumatraPDFはページまたぎ検索もできてでPDFでもリフローテキストと同様に使えますがこの例では
bunkoOCRでの誤認識と同じく「竹藁」と「原料となっている。竹紙は」がヒットしてしまいました
「竹」と「藁」がつながってしまうのは理解できますが、「原料となっている。」と「竹紙は」が
つながってしまうのはちょっと不思議です

透明テキストを可視化したものを一応アップします
https://3.gigafile.nu/0808-cf784ae298abe230af3d5df929a4f435c

>>851
あれかー。めちゃ難易度高いやつで、まだ完全にはクリアできてないです。
近い所を連結するようにしてるのが悪さしてるんですよね。
表っぽい、枠線がないやつは順序が難しい

いまのところこれくらい
https://120.gigafile.nu/0505-babdafae4f15de5d1577424efe06b6342

bunkoOCRの書き出したテキストが、

「・・・現在、日本紙幣の主原料となっているほか、ティーバッグ、掃除機の紙パック
の原料となっている。

竹紙は、中国で唐時代（7世紀）から作られ、宋時代（10世紀以降）には竹が紙
の主原料となった。・・・」

となっていますが、１文字ずつ書き込んだだけのPDFをどうテキストとしてつなげるかはリーダーの判断だと思うのですが、
OCRテキストとSumatraのどちらも「原料となっている。」と「竹紙は」がつながっていたのがどうしてかなと思いました

レイアウトを維持しようという意図のないNDLOCRはテキストの順序だけは正しいですね
文字化けもいくつかあるしbunkoOCRに期待しています

内部的に、「竹」と「藁」のタイトルの後の空白が、段落の区切れと誤認していて
「竹　藁」で一つにしちゃってて、その後ろの本文が、空行区切りで連続している本文とみなして
繋げて出力してしまっています。
https://i.imgur.com/EnzPhEQ.png

これを解決するには、表のヘッダーと本文の部分に分けて認識できる構文解析が必要なので
結構難しい