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

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

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

ルビまではとりあえずいらないけど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

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

普段ほとんど見ないようなレアな漢字や段組みまでケアした完璧なものよりも
普通の文庫やハードカバーのOCRなら問題なく出来る程度のバージョンでもいいので出してほしいです

それな
いいとこ取りしてndlocrliteにレイアウトまかせて、文字認識はbunkoocrとか出来ない？のが残念

普通の文庫というか、私が今読んでる文庫本の小説を読みながら、ミスってるところを修正してるので
読書の時間が律速過程になっているという。
自分で読む本くらいちゃんとスキャンできないと意味がないのでな

ndlocrliteのやってるPARSeqと、bunkoOCRで使ってるfindtextCenterNetは、文字のデコードの仕方が異なるので
なかなか合わせにくい

PARSeqの方式は、先に文字列のあるBoxを見つけておいて、短冊状の文字列の画像をテキストにするやり方。
findtextCenterNetの方式は、文字の座標とその連結方向を見つけておいて、文字を順番に連結してテキストにするやり方。

PARSeqはTransformer系なので、文字を落としたりする。
findtextCenterNetは文字ごとにデコードするので、あとから文脈で補正できるようにTransformerで修正してる。

bunkoOCR作者に画像送るURLがサーバーエラーになってない？

>>859
ほんまや。直しておきます

動くようになったです。だいぶ止まってたっぽ

対応ありがとうございます
漢字の一が認識されないのがちょいちょいあったので送っときました

>>862
ありがとうございます。
手元の最新の開発版では上手くいけているので、バグがあったのがどこかで直ったっぽいです。
現在の修正が一段落ついたらリリースしたいと思います。

漢数字の「一」と同様にカタカナの「ー」も欠落することがありますね

横だけどテスト画像提供者が作者最新版でのテスト結果を受け取れるように
画像のハッシュ値か何かをキーとしてダウンロード出来る仕組みがあったら良いのに
と思いました。

確かに。こっちから結果送りたい時に困ってたんですよね。
仕組み考えておきます。

gemma4試したけどマルチモーダルのLLMがOCRで座標返すのが意味わからなすぎる
E4Bはスマホで動かしたけど一つ上をパソコンで動かしかったが30GBとかとびすぎやろ

NDLOCR-Liteが作成するpdfはUniJIS-UCS2を使っているので認識できる文字範囲は
それ以下だと想像しますがbunkoOCRの認識文字範囲はどれくらいなんでしょうか

>>868
学習自体は、Unicodeコードポイントが単独で振られている漢字は対応できるようにしたはず。（異体字フラグは未対応）なので、学習に使ったフォントに、文字が収録されてたら反応すると思います。
しかし、ちょっとバグがあって、transformerで文脈補正すると新字体になってしまう文字があるので、今直してます。今のところこの部分をオフにしたら多分出そう。

NDLOCR試してみたけどDocument intelligenceよりは落ちるね。取り敢えずonnx直接叩いて出力まで行けたけど
レイアウト解析はLayoutモデルより使いかって良さそう

Bunko OCRはキャラクターの中心検出だっけ？Document intelligenceでキャラ単位配置までできたけど元々のポリゴンが若干ずれてるみたいなんよね
Macで使う場合モデルとengineのc++ソースだけあればいいんかな？

あ、findtextcenternetの方見ればいいのか
上に書いてあった

https://kanji.jitenon.jp/cat/jisdai3 のJIS第3水準一番上の表をbunkoOCRで試してみましたが完璧ですね
NDOCR-Liteは古い本のために作ったはずなのに誤認識も多いし期待外れ

NDLOCR-Liteはここに列挙されている7千文字余り以外は出力されない(認識しない)のでは？
https://github.com/ndl-lab/ndlocr-lite/blob/master/train/parseqcode/configs/NDLmoji.yaml

textcenternet、macで使ってみてるけどなんかメチャクチャ時間かかってる
図表付きレイアウト600dpi高解像度だと対応してなかったりします？
単に自分の実装が悪いだけだと思うけど、どのくらいの速度が普通なんだろう

>>874
Macでやるなら、coreMLに変換してあげて。macのMPSはそんなに速くない

>>875
調べてみる
ありがとう

NDL OCRなんか＆がエスケープなのか&って取得されるな...
あと全角アルファベットが半角にされる
bunko ocrは少し全角で拾ってくれるけど、それでも半角が多い印象

配置するときにズレる原因になるんだよな
座標から推測してもいいけど自動認識できるモデルないかな
とくにndlはline座標だから

エスケープは&だったわ

あれここでもされるんか
& ampてなる

xmlの仕様だったみたいだわ
パーサー通したら元に戻るから問題無かった
全角半角問題はまだあるけど

全角半角は本質的に形が一緒なので、判定はむずい
補正判定するとしたら、文字の幅が全角なのを使うか、文字送りが全角幅なのを使うか

全角文字が複数あればともかく
Mとかは全角でもプロポーショナルでも横幅が同じようなものなので1文字だと人間でもAIでも厳密な区別は不可能
前後の文脈とか縦書きか横書きかとか他の場所でどう現れてるかとかフォントの癖とか、より上位のコンテキストから判断する必要がある
全角と半角は使用フォントの違いであってテキストの違いではないと捉えるべき

まぁ、その通りでテキスト抽出するだけなｒら問題にならないんだが、PDFに戻すと結構ずれて気になることがあるんだよね
コンテキスト判断必要なところからしてAI向けだとは思う

>>883
それをきちんとやろうとしたら全角半角以外でもフォントのサイズやイタリックやボールドなど他の字形要素でも同じ問題が起きるので
「OCRでテキストだけじゃなく各文字の使用フォントとサイズまで識別する。透明テキストを埋め込む際に同じフォントとサイズで埋め込む」までやらないといけない

フォント識別してもそのフォント持ってない問題とかもあって、裏技としてはOCRしながら画像から新しくフォントを生成してそのフォントで埋め込むみたいなのもできるんだろうけど普通はコストに見合わない

英文専用OCRではイタリックやボールド、飾り文字も認識出来るのがあったかと

>>884
Document intelligence ではフォントとスタイル認識できるからやってみてるけど、あっちはあっちでポリゴンが実際の文字の位置とちょっとずれてるっぽくて面倒くさいのよね

NDLOCR-Lite v.1.2.1 で本に載っているC言語系のソースコードを OCR でテキストファイルに出すと関数の終わりのカッコ } で謎の数字が入っている。
記号やプログラムで使われる特定のキーワードだと、プログラム的に解釈して、その時持っている変数をOCRの結果に出してそう。
変換精度は満足。
1と小文字Lを間違えるのと、スペース区切りを間違えるのは仕方がない。

中国語日本語の専門用語辞典をNDLにかけてみたら時々謎の英語ぽい無意味なアルファベット文字列が出力されてた

ndlocr-liteにプレビューとして1.2.2が出ていた
PDFの透明テキストの位置が改善されていた
PDFの画像は今まで可逆のFlateエンコードだったのが品質75のDCTエンコードに変えられた
初期版の時のようにASCIIのPDFになってしまったのでcpdf -squeezeとかしないとサイズがでかい

OCRが作成するPDFの画像を差し替えるために透明テキストを抽出してみた
https://yoshitan98.github.io/ocrtextlayer
既成プログラムしか使わないバッチファイル

NDLOCR-Liteを使おうと思ったら起動してすぐ落ちるんですが
必要スペックってどれくらいですか？

Macでも余裕なので本当にスペック不足ならすぐに捨てて買い換えるべき

読み込むファイルの解像度が高すぎるんじゃないの

Windows11じゃない起動できないんですかね

んなこたあねぇだろ
Linuxでしか使ってないから知らんけど
Sandy Bridge世代の産廃でも余裕で動く
流石にメモリは12Gあるが
メモリ少なすぎるんちゃう？

自分もSandy Bridgeでメモリは16GBです
AIにはスペックかWIN10だからと言われましたがどうやら違うんですね

ググってみたらフォルダの場所でエラーがおきるみたいで
試しにCドライブ直下にフォルダを展開したら起動できました

Rust_DN_SuperBook_PDF_Converter　の環境構築をもう一度頑張ってみたい。
俺の環境はWindows11
情報系学部2年生レベル向けの解説を希望。

環境構築の完全解決につながる回答には仮想通貨で200円分払ってもいいです。

AIに聞きながらやってるんだが、何の説明もなくあれこれコマンドを実行させたり、アプリを次から次へとインストさせようとしててマジで不信感しかわかん。

もしかして世に言うAI格差ってやつですか

>>898
これがAIに代替される人材ｗ

Windows2000版とWin98版
希望です

ググっても、DN_SuperBook_PDF_Converterの環境構築のブログはヒットしても、Rust_DN_SuperBook_PDF_Converterの環境構築についてはヒットしない

マジで誰か初心者向けの解説記事書いてくれ。数百円程度なら課金するから

OCRのソフトって、いくらで売るべきなのかね？

bunkoOCRそろそろ更新してくれー

個人開発のbunkoOCRは期待できないので親方日の丸のNDLOCR-Liteをメインに使うことにした
OCRなんて所詮精度は五十歩百歩

最近YomiTokuを併用してる

NDLOCRは振り仮名つけるオプションがあるみたいだけどliteはないのかな？
それさえ出来れば完全に乗り換えられる

うちはCPUなのでliteしか使えないがまあまあの精度で速いのでそれでいい
多少まちがっていてもいいように、また、どんなレイアウトでもいいように
PDFにして使っている
PDFだと振り仮名は不要だし検索ではかえって邪魔

低スペPCは切り捨ててgpuフル活用してほしい

昔の雑誌のプログラムリストをOCRするには何を使うのがいい？
スラッシュ付きのゼロが使われている

>>911
プログラムリスト部分だけでいいなら日本語関係ないからClaudeやChatGPTにOCRやらせてみたらどうかな

なるほど　そういう手があったんですね

ndlocr-liteのv1.3.0-previewでpdf出力がベータ版ではなくなって
透明テキストの位置が少し改善された

税金で炊いた本 >>718
税金で作った炊飯器 >>914
NDL応援アゲ

目視じゃないと判断できない文字結構あるね

「○(まる)」と「〇(漢数字ゼロ)」
ひらがな、カタカナの「へ」と「ペ」
「口(くち)」とカタカナの「ロ」
など

これはよくあるな
二一（漢数字）がニー（カタカナ）になってた時は笑ってしまった
OCR結果を別AIで文脈を元に検証させたら良さそう

フリーの日本語OCRはNDLOCR-Lite・YomiToku・PP-OCR V6・bunkoOCRあたりが有力？
これらに対応したWindows・iOS・Androidアプリが出たらすごく捗りそう

OCRの結果を多数決させる方式を、論文で提唱してる人がいた
有名なやつで演算してから結果投票して、よさげな部分だけいいとこ取りしたら完璧になりそう

iPhone18Proの可変絞りカメラ
OCRする用に、スマホを固定して見開きで撮影するときの、端の方のピントボケが解決しそう
だがお値段

今話題のJevを正誤判定に使えそう

候補はコードで出す。Jevで同音異義語の誤変換ハンターを作った
https://zenn.dev/mistletoe/articles/jev-kanji-typo-hunter

これはその用途に近いな
誤字になりやすい文字の辞書を用意する感じ

Gemini無料web版でOCRを試してみた
プロンプトを適切に書けば段落最初の空白文字や空行も再現してリフローテキストを作ってくれた
OCR専用ソフトよりも便利だね

読取革命を扱うソースネクストががが

日本語OCRモデルを比較 ー 速度・性能・メモリから最適解を探る
https://zenn.dev/acompany/articles/ddf8677f09e252

Detector + Recognizer のハイブリッド構成も検証してる

縦書きについての評価がないのは片手落ちだろう

わざわざ歴史がかった差別用語を使って教養マウント取るのはやめたほうがいい

何言ってんだこいつ

縦書きと横書きで違いが出るのなら普通に知りたいな

国会答弁とか見たことないの？
自身の語学力をひけらかすためにわざわざ差別表現を使う人は批判されてるよ

片手落ち
いつの間にか、差別主義者によって差別発言にされたかわいそうな日本語

日常会話で使わない言い回しでマウント取る厨二病マインド

普通に使うしマナー講師()みたいなカスが勝手に差別用語にしてるの今知ってびっくりしたわ
この程度で衒学趣味扱いされたら大学受験なんて出来ねえぞｗ

単なる言葉狩りなんで通常の利用では気にすんな
企業とか公営ならアホの子からのクレームを減らして対応コスト削減のための自主規制とかすることもあるけど、あくまで自衛策
「片手落ち」が差別用語なら「手落ち」とかだって駄目なはずだが、そっちは放置、根拠なく適当に文句言ってるやつと自衛してるやつがいるだけ

俺も普通に知ってるし、普通に使う
高校、大学ぐらいで知るレベルの語彙だと思ってたが

もちろん、差別用語かなんて当時は学んでねぇし
つかこの用語以外でも学んだ時からアップデートされた語彙なんてほとんどねぇわ

なんか障害者だろ？この字で揉めたぐらいは知ってるけどあっそって感じ

だれでもわかる簡潔な表現「足りない」とすべきところで、
わざわざ歴史文学通を気取った差別的な言い回しを使うと、
「背伸びしたがるバカ」と思われてしまうだけだから注意したほうがいい

縦書きと横書きと、2つあるのに横書きしかテストしてないのは、まさに「片手落ち」やろうが

片手落ちだな

結論、キチガイにどう思われようが普通は気にしない

いかにも親ロシアな参政党支持者っぽい人が好んで使いそうな言い回しなんだよね。
常に相手にマウント取ることばかり考えてるから実生活でトラブル起こしやすいタイプのひとたち。

実世界で身近な周りにマウント取るやつなんてほとんど見かけないが?
もちろん、友達にそんなマウント取るやつなんて皆無だし
そんな競争激しい環境にいるの？
実世界で生きてなくてネットで他者と接点ばっかもってるからそんな偏った意見になってんでしょ
気づいたほうがいいよ

>>941
時代小説にしか出てこないような挑発的な表現を公の場で使ったら言い争いになると普通の人は思うけど、
いかにも親ロシアな参政党支持者っぽい人はそう思わず、教養マウントのために使ってしまう。

突然、親ロシアとか参政党とか言い出したり大丈夫か？

(定年後?)やることないから、ネットで情報集めすぎて知識に溺れて
偏った意見になってどっちが正義だーとか他のスレでやってそう君
マーナー警察やるぐらいしだし


正義とかに取りつかれてた完全に闇堕ちジジイでしょ

片（片側）＋ 手落ち（考慮不足）なのに「片手＋落ち 」だと思ってる日本語弱者が湧いてるだけなので日常では笑いものにしとけば良い
報道、広告、公共とかで多くの人に対応しなければいけない現場だと、こういうバカにも対応しなければいけないので説明する手間暇考えて配慮してるだけ

「片手落ち」を教養とを結びつけるとか どういう頭してるの？

逆
時代がかった気取った言い回しで対象をこき下ろそうとするいやな感じになるから日常で使わないほうがいい

>>946
時代がかってないぞ、手落ちは日常表現
知らないのは小説とかの大人向けの表現を学んでないだけ

相手に責任押しつける気満々な言い回しなので、手落ちも使わないほうがいい。
こういうのは面白おかしく表現する文学ならアクセントになって良いだろうけど、日常会話で使えばただのヤクザなクレーマーだよ。

>>948
普通のビジネス用語で日常的に使うぞ「こちらの手落ちです。すいませんでした。ただちに対応させて頂きます」とか

5chで言葉狩りとか場違いだよ
俺が知りたいのはあのレビューに追加の縦書きに関する情報だ
数字はなくてもいいのでどなたか知っていることがあれば教えて下さい

Pythonのpandasで
請求書を読み取ってデータ化したいんですが、デタラメに文字化けしたり認識できません
AIならきちんと読めるけどオンラインなので請求書は渡せないし
無料中華ローカルLLMもサイバー攻撃みてると危なっかしいです

Pythonでやれると、そこらに書いてあるけどコツがあるんでしょうか？

>>949
汚い言葉や荒い言葉は、我が方に使えば謙譲表現になりうるけど、相手方に使えばヤクザなクレーマー

>>952
汚いとか関係ない、普通の言葉
「お前のミス」と「私のミス」
の違いに過ぎない、お前が世間の常識が分かってないだけ

>>953
客に面と向かって「あなたのミス」とは言わないでしょ。
世間の常識がわかってないから杜撰な言葉を使ってしまうんだろうけど。
口臭の強い人が自分の口臭に気づけないのに似てるとは思う。お大事に。

倫理と論理の争いだな

ド迷惑噛みつき野郎はむしろ倫理レスだし言ってることの要点も別に倫理の話じゃないだろ

謙譲語の機微すらわかってないくせにうっかり古めかしい表現を使うと
「背伸びしたがるバカ」と思われてしまうだけだから気をつけたほうがいい、マジで

ウヨ臭への反発とサヨ臭への反発ですね、わかります

で、縦書きの性能も網羅して調べてくれる人待ちかしら

>>954
ウェブサイトに向かって「テスト手順のミス」というのは普通だろ、なんで顧客向けの用語を強制されるの？

>>960
対象をおとしめたり責任追及したりする他罰的な意味合いを強く含んでいるからだよ
実際、それらの古めかしい言葉のあと、誰かに「詰め腹」を切らせる展開がありがちだろ
簡潔な「偏りがある」とか「足りない」なら、他罰的な意味合いをさほど含まないので問題ない

>>961
そんな意味はない、お前の妄想
「ミス」とか「考慮漏れ」とか「手違い」みたいな中立な言葉、どれも他人に使えば責めるニュアンスが出るだけ

レスがすごく伸びてるからようやくbunkoocrのバージョンアップ来たのかと思ったらつまらん喧嘩かよ
がっかり

自分で動けない無能のゴミに他人を罵る権利なぞない

ローカルLLMの glm-ocr を試してみたら いいとは言えないがまあまあだった
プログラムソースはインデントしてくれる
各国語に対応していてあのサイズというのはちょっと感心
geminiに投げる方が速いけどね

「いいとは言えないがまあまあ」と書いたが「使い物になる」と訂正
レイアウトをきちんと把握できるのが強みだな
中国製のお決まりで中国文字が混ざることがあるけど読めないことはないし後で一括置換すればいいかな

ネット上の無記名解説文のPDFの1ページをgeminiに投げたら著作権的に全文出力できないと言われてしまった
ローカルLLMならばケチをつけられることはない

昔の雑誌のN88 BASICを読ませてみたら かすれていても I と 1 が区別されていた
しかし昔のBASICの知識はないのか行番号がきれいにカットされていた

PaddleOCRも試してみたら普通のOCRよりマシだが I と 1 は区別されていなかった
行番号は付いているが印刷都合の改行もそのまま

いまさら気付いたのですが、昔ScanSnapで自炊した本の類いのPDF、OCRのデータは付いているが
文字の間に半角スペースが入ってるし、カタカナは半角カタカナになっている
そりゃあ検索したりがうまくいかないはずだ

そういうPDFを大量に持っていて、それらをまともなOCRにかけ直そうと思ったら、今って
何でどうやったらいいんですかね

大量の数とその使い道に依るのでは

>>969
本の中には技術書や参考書があり、「あれ、あの項目ってどの本に書いてあったっけ」と思った
とき、コンピュータ（Mac)上で検索したかったんですよね

PDFのOCRがちゃんとできていればMacの機能でPDFの中身を検索できるはずなんですが

検索の正規表現を工夫するしかない

こういう事案>>968もAIに適当に投げて雑なプロンプトで欲しい情報を抽出できそうｗ
なんかOCRとかも全部データをデバイス内に取り込んでおけばAIが処理してくれる時代のようなｗ

>>968
手軽なのだとmacのOCRが結構精度高かった。claudeに言ったら背面ノイズ除去からなんやらやってくれて背面の図表やグラフィックまで切り出してPDFまで再構成、読み取りミスも文脈から判断補正してくれる。

問題は書籍をフルに任せるとAPI料金(トライしたページで換算)が1冊数千円から1万かかってほぼ買い直しみたいになること

そこそこの品質(たまに検索できない,改行またいで検索できない)でいいならDocument Intelligenceのが安い

なんで>>972はあながち間違ってない

てか既にデータあるんだからclaudeにテキストデータ補正してもらうだけでいいのでは

それならvision使わないから多分安い

掲示板とチャットの区別ついてないタイプの人久々に見たな

スキャンしてアクセス性を高めて来たけど、IT関係技術書や理系専門書で調べるよりAIに聞くのが速いしなあ

>>968
PDFリーダーはスペースや改行を無視して検索してくれる
普通のOCRが自動で作るPDFでは順序が狂うことが多いので改行が挟まると検索できなくなることが多いけどね
AIのOCRが作るテキストは順序を正しく取ってくれるようだ

>>976
全く同じ状況で、全く同じことを考えて
Claudeに整形させたら見事に流麗になった

しかし、致命的な課題があることに気づいた
LLM、例えばOpusは使用頻度が低い言葉を
OCRの誤りとみなして、頻度がより高い言葉へ
置き換えてしまう（踏面→路面）

OpenAI、Anthropic、xAI系をさんざん試して、
結局はGoogleのLLMではない文字認識、
具体的にはDocument AIが
正確さでは最善の選択ということが分かった