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

bunkoOCRのiOS版を更新しました。審査通ればそのうち配信されると思います。

OCRの結果をpdf出力で透明検索可能テキストとして埋め込めるようにしました。
pdfの画像ページを取り込んで、画像と文字ページをそのままにして、
透明検索可能テキストを埋め込めるようにしました。
Transformerの部分を修正して、画像が粗くて認識失敗したときに文字ズレが起こりにくくしました。
官報みたいに90度くるくる回っている画像の為に、回転オプションをつけました。
国会図書館デジタルコレクションのpdfの下部80pixelのところに文字が入れられて邪魔なので、
上下左右をトリミングできるようにしました。

ロジックは出来たので、このバージョンをWindows版にも反映させます。
もうしばらくお待ちください。

Window楽しみに待ってます

お疲れ様です
ずっと待っていました
トリミング機能追加ありがとうございます

Windows版bunkoOCRのおかげで絶版文庫本を非破壊で電子化できたー、ありがとうございます

スキャンした住民票をテキスト化するんでアプリ探してたんだが
数十ページ分とかでなければ
OS付属のSnipping Toolで十分だなこりゃ
そこそこ画数の多い漢字も正確に変換してくれた
今のところ誤字変換も無さそう

OneNoteのテキスト抽出は操作が分かりやすいが
Snipping Toolと比べると誤認識が多くてまあまあ直しが必要

>>660
Windows10のやつだとOCR機能が無かった

11からの機能だったはず

外部ツールを使えばWindows10でもOCR使えるはず

bunkoOCRなんだけど
本文中に《　》で囲まれた文字がルビ扱いになるね

　漢字《本文》　や　《｜本文《ルビ》》　みたいの

【　】などに置き換えてるけど青空文庫の仕様だから仕方ないのかな
文字認識としては正しいのに

内部的には0xFFF9-0xFFFBを使っているのですが、対応している環境が皆無なので
適当なフォーマットに変換してます。《　》じゃない文字でも出力できる必要がありますね。
ラノベだとわりと被るから

青空文庫のフォーマット考えたやつバカだよな

>>667
SJIS しか使えない機材が多数だった時代に
特別なツール無しでそれこそワープロ専用機でも本を読み書きできることを目標に決められたフォーマットなんで足りないのは仕方ない
過去の遺物、epub とか使え

縦書きのePubとか止めてくれ

>>669
なんで？ 便利じゃん

bunkoOCR使ってみたら、普通に読めるレベルに認識してすごい
ドキュメントスキャナーのソフトは、誤字があまりに多く読めなかったのでありがたい
windows版の新バージョン期待してます

作者さんとしては、windows版もios版みたいにする予定かもしれないけど、
希望としては、iosでは修正済みらしい（>>587、>>598みたいな）問題のとりあえず対策版を出してほしいな〜

bunkoOCR on macOSで、旧字が大量にある縦書き文書のPDFをOCRしました
認識率がすごいですね、感動しました

で、これをPDFのテキストデータとして戻したいのですが、元のPDFの描画はそのまま
保持することはできますかね? 現行は書き出すとPDFのページは画像化するようですが
画像化でもかなりいけてますが、より高い解像度（600dpiとかそれ以上）って選べます?

あと、処理中はCPUが200％ぐらいしかいきませんが、もっと並列化とかもできる
ものなんですかね

>>673
画像の部分だけを処理したい場合は、「PDFから画像を抽出する」の方を選んで
画像の部分だけを処理して、エクスポートのボタンから
「全てのページ」「PDF（元の画像を保持する、ふりがなを無視する）」で出力すると
テキストで元々ある部分はそのままにされて、画像の部分にだけ透明テキスト埋め込みになるはずです。

Windows版に反映しようとしている途中に、ロジックにバグが見つかり
直している途中で、別のタスクが割り込んできてちょっと時間が取れていません。
お待たせして申し訳ない。

並列度はわざと落として、iPadとかでkillされないように調整してたのを元に戻すの忘れてますね。
次いじるときに調整できるようにするか、もっと並列度あげておきます。

いくつか試したのでレポ

DeepSeek OCR
一応日本語読める。いくつかのサンプルで試したところ、画像によっては途中でLLMが崩壊してしまうこともある。
英語は精度よさそうだけど、日本語の精度はちょいちょいミスがある感じがする。

dots.ocr
日本語も対応してて精度も良いんだけど、LLMに起因する「嘘」が時々混じるのが残念ポイント
少々の誤差を許容できるなら、精度よさそうでいい感じ

bunkoOCRやyomitokuとどっちが精度が高いのよ
それが問題だ
PaddleOCRも新しいの出したよね

特化型vsリソース食いのごり押しVLMの戦い

PaddleOCR
日本語の縦書きで試してみた。
合っているところはほぼ合ってるけど、なぜか認識に失敗しているところが所々ある。
認識結果が所々飛ぶイメージ。ふりがなは律儀に認識してるけど、多分座標で自前で何とかしないとだめっぽ。

認識結果は失敗の出方に特性があって評価が難しいけど、独断と偏見でいうと
dots.ocr > PaddleOCR > DeepSeek OCR
の順に精度がよさそう。ただし、自前で環境構築するのはどれもちょい面倒。
Dockerイメージあるならそれ使った方が楽できる。

なお、独断と偏見によるとbunkoOCRやyomitokuの方が日本語性能はずっと高そう。
多言語対応すると、個別の性能はチューンされきってない感じがしますね。

参考になった。ありがとう
今DoclingやVLM OCRとか流行りだけど期待のDeepseek OCRしょぼーんやな
ローカルLLMとかも性能向上そろそろ限界かな

精度90%って高そうだけど10文字に1文字はずっこけるってことだから使えんよな
95%は20文字に1文字はずっこけ　これもきっつ
98%は50文字に1文字はずっこけ　ここら辺になると実用的やな

もう全部DeepSeekOCRでいいや
bunko も yomitoku もバイバイ

DeepSeek 中国製だから漢字圏では勝ってしまう可能性大有り

>>682
なお字体

依然としてbunkoOCRがトップ

欧米製：Tesseract、EasyOCR
中国製：dots.ocr、PaddleOCR、DeepSeek OCR
日本製：bunkoOCR、yomitoku、NDL OCR

フリーのOCRをまとめてみたが実行・利用するにはプログラミング知識（可能ならGPUも）が必須なのが多い印象
フロントエンドができればTesseractやbunkoOCR以外も少しは普及しそう

日本製は日本語だけ?
せねて、英語やフランス語とか西洋だけでもいけるといい

まか、日本製はモデルサイズが圧倒的に小さくて日本語性能優秀ってのが特徴であるが

pythonとかわかんね。これならdeepseek ocr簡単に使えるの？　https://github.com/TimmyOVO/deepseek-ocr.rs　https://egg.5ch.net/test/read.cgi/software/1711002779/l50

DeepSeek-OCRはvLLM版じゃないと本気出してくれなさそう
ってことらしい。また試すか

YomiTokuがCPUでも高速に動くように進化したらしい

bunkoOCRで三桁の数字がバラバラになってしまうのが結構あった
123が132や231になったり二桁や四桁は問題ないけど

なんで3桁だけなんやろ
ちょっとテストしてみるわ。よければサンプルいただけますか

>>544のとこに送っておきました

>>693
ありがとうございます。

手元の最新の開発中バージョンでは、101のところが上手くいっているみたいなので、早くリリースできるようにします。
割注と縦中横の判定をいじって上手くいくようになった気がする

yomitokuでpdfファイル入力、PDF出力したら、17.5 x 24.5 cm, 400 dpiが、97.3 x 136 cm, 72 dpiになった。ディスプレイで見るぶんには問題ないが、やや気持ち悪い。仕様でしょうか？

使ってるライブラリの、デフォルトdpiが72なんだと思う。ソースのdpiを引き継ぐようにすればよさそう

読み取り解像度は指定できるけど、ソースのdpiが引き継げそうなやり方はなさそう？に思いました。

ソース読んでみたけど、一発で出力の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でやってる位置合わせも、だいたいしか合わないのです。
行として文字列の検索を当てやすく文字列にするか、完璧に位置を合わせるために一文字ずつ置いていくか
のうち前者を採用すると、比率をでっち上げて行の末尾を合わせるくらいしか出来ないのです。