【文字認識】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

ソース読んでみたけど、一発で出力のdpi設定できなさそう。
canvasの設定で、ちゃんと換算して設定しないとだめっぽ。githubにissue立てるか、
Twitterアカウントに突撃して報告したら直してくれそうではある。

reportlab.pdfgen の Canvasを使ってるみたいだけど、このライブラリは72dpi前提で
簡単には変わらないっぽい。画像のサイズの方をPixelから実サイズに調整する必要があって
けっこうめんどくさそう。
後から変換するソフトとか(あれば)調整した方が早そう

詳しくありがとうございます。私には難しそうなので、印刷する必要がある場合はどうなるのか考えて継続して使えるか検討してみます。縮小印刷したら普通に印刷できそうな気もする。
bunkoOCRならこういう問題は生じないと思うので、必要あればiPad airでOCRも検討です。遅いし電池が減るけど、、、。Windowsの新版に期待。

ocrarena
https://www.ocrarena.ai/battle
ちょっと試しただけだけどgpt5と5.2でだいぶ認識率が向上してるみたい

それによるとdots ocrとQwen 8Bが優秀ってことかな

初見。OCRソフトが欲しい。アドバイス下さい。

・紙の本を電子化してOCRを掛けるのが主目的。理系学術書(従って数式多数)が過半数。他はPC関係の図表の多い書籍。
・現状、Acrobat 9を使っている。文章のレイアウトがちょっとでも非定型となると即座に精度悪化。数式なんておよそ認識しない。
・Amazonで読取革命v17が7870円だったが、★2.9。ソースネクストでFineReader v15が27500円。Acrobat最新版は高すぎ。

読取革命はマジでクソゴミだからやめとけ

Thanks 質問者と別人だけど

数式をTeXで認識したいとかなら、なんかモデルあったはず。
それとは別に図版多いならYomitokuが強かったような

数式混じりの日本語の本で、図版入っているやつ
私もスキャンしてOCRしたいんだけど、最終形態としてどうするのがいいんだろうか。
単なるテキストにすると、数式辛いし図版飛ぶし
図だけjpgで持っとくとしても、どの部分に入ってたかとかmdにするとかかなぁ
数式はTeX形式にするとしても、ふつうの人間はそのままで読めないという
結局レンダリングするなら、画像でよくねとかも思う

画像と透明テキストのpdfはどうかな
>>625～のbunkoOCRのpdf作成に期待してる
図表や数式を誤OCRしてても目で見る分には正しい画像だから問題ない気がする

bunkoocrのwindows板って最新になってないんだっけ?
iosでやれってことか

ごめんまだwindowsのやつ作業できてない。お正月に作業してみるわ

>>709
楽しみにしてます

bunkoOCR、雑誌記事とか順番がややこしくなくても、単純な段組の小説でも何故か文章の順番がめちゃくちゃになることがあるなあ

どうも章番号があるところで変な処理がががる感じがする
アラビア数字だと何があるんだろうか？
単純に右から処理してくれるだけでいいんだが、どうすりゃいいんだろ

>>711
ios版ね

気付いたので、今直してるところです。
単純に右からでいいんですけど、いろいろとややこしい処理になってるのが敗因
正月休みは、「なんの進捗もありませんでしたーーー！！」だったので、もうちょいかかりそう

>>713
ありがとうございます。
精度の高さが商用の製品と比べても段違いなのでとても重宝しています。
パラメータを色々いじってみてたのですが上手くいかなかったので、アップデートしていただけるのは助かります。
忙しいと思いますが、よろしくお願いします。

bunkoOCRの作者さんが居るみたいで伸びてるけど
図表を取り込めるようにはする予定ないですかね？

手元のデータをみると図表の全くない本はほとんどなくて
市販の電書みたいにテキスト部分はテキスト、図表は画像で取り込めると便利だなぁと思いながら見ています

>>715
それは文字のOCRというアプリケーションの機能自体を変更することになるのでは
機械学習自体を見直す必要があったりして今のモデルを使ってまでやることではないような

欄外のページ番号とかを弾くのに、どこが本文でどこが欄外か判定する新たな機械学習モデルを導入する予定。その時に、図版の場所も判定できるようになるかも
でも図版をjpgとかで抜き出すとして、座標とか本文との位置関係とかはどう扱うべきなんやろう。最終の出力フォーマットの形式が見えないので、いい方法募集中ではある

国会図書館デジタルアーカイブの古い書籍をＰＤＦでダウンロードしてテキスト化するのに
よいＯＣＲソフトがあればどなたか教えてくれませんか？
もちろん読み取り後に修正は大前提でそれなりに文字興し出来たらいいです。

>>718
間が良いねえ、お客さん。

SoftEtherVPNで有名な登大遊老師が、いまいちスキャンコンディションの良くなかったPDFファイルでもいわば高精細リマスター化するようなツールに更に日本語OCRのYomiTokuを合体させた飛び道具を作ってくださったばかりなんですよ。

スキャン書籍PDFをデジタル書籍並みに大変クリアにするAI-PDF高品質化・各種調整ツールDN_SuperBook_PDF_Converter
ttps://github.com/dnobori/DN_SuperBook_PDF_Converter

コレを更に別な開発者の手により改良されたWindows/Linux/macで動作する別バージョン
Rust_DN_SuperBook_PDF_Converter
ttps://github.com/clearclown/Rust_DN_SuperBook_PDF_Converter

メモリーたんまりなPCとハイスペックなGPUさえあれば極楽だね！

初心者なんだけど本をスキャンした画像にOCRかけて、図が入ったMarkdownに変換して、epubに変換してタブレットで読むみたいなことできる？ PDFにocr掛けただけだとページめくりが重くてね

Google Docs の OCR 機能を駆使して自分で Markdown にすれば良いんじゃね

AIエージェントにお任せできそうなお題

GLM-OCR使った人いる？ Ollamaから起動して画像投げてもうんともスンとも言わねえ
Ollamaのバージョンが0.15.5なんだけどrc2じゃないとダメなんかねえ

さっきpre releaseに入った0.15.6でcontext値？を上げたカスタムモデル使ったらいけたわ

色々試したけどgeminiにpdf投げつけるのが一番手っ取り早くて綺麗

と自分も思ったけれど、
gemini（に限らずLLM）は、長い文章の
途中を気づかないうちに省略したりする
コンテキストウィンドウ溢れとは
また少し違う挙動で、バリデーションが大変

というわけでbunkoOCRには大変期待し
応援しております

geminiくんは、文庫の見開きくらいの文章量だと完璧に近いけど、ちょっと多くなると諦めが早い

Win11 の Snipping Tool でちょこちょこOCRかけているけど、一昔前の絵を見ながら手打ちと比べて神。
単語のみだと読まなかったり、狭い範囲だと言語間違える動きするけど。

江戸時代に書かれた手書きの本（楷書）とかをOCRしたいのですが
思ったより識字率がよくない模様

字をよく見るとへんやつくりなどに書いた人毎の省略癖があり、
人が見れば文脈などから「ああこれはあれかな」というのがわかるのだが
そういうのが拾えてないような

そりゃ、古文書用に学習させてなければ識字できなくて当然なのでは？

> 思ったより識字率がよくない模様

こういうのは、どのソフトの事なのか書かないと

いま NDL古典籍OCR-Lite Web版 てのを試してみたが、結構しっかり認識してるな
...かなり時間がかかったが
Web版でもローカルに処理させてんのか、これ？

>>731
とりあえずbunkoOCR と >>732 のなどを。どちらも特に崩された文字が弱いかも
活字ならいいんでしょうけど

ぶっちゃけ、私の場合もGeminiが一番いいかもしれない。OCRもともかく、OCR後の
古文への現代語訳も付き、さらに「これは〇〇の分野の文書ですね」とか言って
その分野特有の語彙なども拾って訳したり。うわー

geminiで変になる言うてる人はチャットにそのままPDF貼ってるの？
pythonでgemini 3 flash previewのapi指定してPDF処理させてるけど変になったことはないぞ

ここはプログラム板じゃなくてソフトウェア板

そもそも古文書ってどこで手に入れてくるの？

ヤフオク

国会図書館のネット公開とかじゃないの？

今は色々画像で公開されたりしているので
古墳から発掘された木簡とか

あちこちの大学図書館で漢方古典の医学書の画像が公開されてるんで集めてるわ
漢文の医書は日本のも含めて中国でほとんどがText化されてるけど和文のは全然ないんだよなー
完璧じゃなくてもOCRがかけられるようになったのは有り難い

gemini 3 flashのレイアウト認識は頭一つ抜けてるけどテキストのアンダーラインやオーバーラインは上手く認識してくれないな。
良いプロンプトはないだろうか

>>740
そういうマニアもいるのなー
今だとデジタルスキャン→AIなりOCR解析みたいな手法になるのかな？
そういう技術も有用度高そうだな

https://github.com/ndl-lab/ndlocr-lite
お上謹製のOCRこと、NDL-OCRのデスクトップアプリ版が出たぞ。
ほぼ元の精度で、簡単に使えるようになってる。

試したところ、ちゃんと撮影する国会図書館のデータに合わせてつくられてるので
ズボラして斜めった画像を与えたりすると、ちょっと失敗するけど、ほぼ完璧にいける

同じだけど
https://lab.ndl.go.jp/news/2025/2026-02-24/

GPUなしで動作する軽量なAI OCRツール「NDLOCR-Lite」、国会図書館のラボから無償公開
https://forest.watch.impress.co.jp/docs/news/2088188.html

bunkoOCRのように段落は空けてくれないけど段違いに速いし正確だし
PDFも作ってくれるし十分実用的だね

>>746
たしか、行の座標が取れるので、1行空いているのを検出したら改行を追加するとかいけそう

>>743-745

https://github.com/ndl-lab/ndlocr-lite
の最後の段階を画面キャプチャOCRした

Windows11 25H2組み込み(Win+Shift+T)

技術情報について(開発者向け情報)NDLOCR - Lite は「レイアウト認識」、「文字列認識」、「読み順整序」の 3 つの機能(モジュ ー ル)を組み合わせて実現しています。レイアウト認識には D 日 Mv2 [ 1 ]、文字列認識には PARSeq [ 2 ]をそれぞれ用いており、読み順整序については当館が公開している NDLOCR と同様のモジュ ー ルを用いています。[1]Shihua Huang and Yongie Hou and Longfei Liu and XuanIong Yu and Xi Shen. Real-Time Object Detection Meets[2]Darwin Bautista, RoweI Atienza. Scene text recognition with permuted autoregressive sequence models.arXiv:2212.06966 , 2022. ( ps :〃 a 「 x ⅳ .0r9 / abs / 2207.06966 )レイアウト認識及び文字列認識の機械学習モデルは、いずれも p 。「 ch をフレ ー ムワ ー クとした学習を行った後に ONNX 形式に変換して利用しています。詳しくは学習及びモデル変換手順をご覧ください。団 NOv3. arXiv preprint arXiv:2509.20787. 2025. い ps :〃 arx ⅳ .0r9 / abs / 2509.20787 )


ndlocr-lite

技術情報について(開発者向け情報)
NDLOCR-Liteは「レイアウト認識」、「文字列認識」、「読み順整序」の3つの機能(モジュール)を組み合わせて実現していま
す。
レイアウト認識にはDEIMv2111、 文字列認識にはPARSeal2]をそれ用いており、 読み順整序については当館が公開して
いるNDLOCRと同様のモジュールを用いています。
[1]Shihua Huand Hou Liu Lonqfei Liu Liu and Liu and Xu.anlong Yu and Xi Shen. Real-Time Object Detection Meets
DINOv3. arXiv print arXiv:2509.20787,2025.(https://////arxiv.orabs/2509.20787)
[2]Darwin Bautista, Rowel Atienza. Scene text recognition with permuted autoregressive sequence models.
arXiv:2212.06966,2022.(https://arxiv.org/abs/2207.06966)
レイアウト認識及び文字列認識の機械学習モデルは、いずれもpytorchをフレームワークとした学習を行った後にONNNA
式に変換して利用しています。詳しくは学習及びモデル変換手順をご覧ください。

bunkoOCRはしばらく使っていなかったが久しぶりに使ったら処理がかなり速くなった気がした
Core i7のIris Xe使用でDirectML GPU id=0という設定
Windowsやグラフィックスドライバのアップデートで何か改善されたのかな

ndl系って古文書系かと思っててスルーしてたわ
lite使って見たけど想定以上に正確やん。凄い
英文も実験的に対応ね

bunkoOCRが書き出すjsonとNDLOCRのxml共 元画像の行の座標位置がピクセル数で書かれているね
それなのにNDLOCRのPDF出力はベータ版とは言え透明テキストの位置がどうしてこんなにずれているのかな

PDF出力は試してないが、バウンディングボックスか書かれた出力された画像みると隙間ないから、PDFへの書き出しでその現象発生してるのかね
つかliteがいい感じなのでliteなしの方が気になってきた。
もっとすごいか？

liteなしは「清」や「教」の旧字が「〓（ゲタ）」に丸められるので良くない

>>751
pdfは透明でも青色テキストでも同じ位置(オフセット)にオーバーレイされるね

>>754
こんなに位置がずれるのですけど・・・
ttps://87.gigafile.nu/0329-c0a7cbae326c84c412bfa5b80371ff98d

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

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