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

bunkoOCRは色々改良していただいているようだが更新公開頻度を上げていただけるといいんだが・・・

>>575
すまんの。自分で使ったり報告があったバグを潰してたら、バグのモグラ叩きになってて時間かかってたです。
iOSの方で直したやつを、Windowsの方に持ってきてる形なので、遅くなってます

主流のcuda以外も見捨てずに対応してくれるだけで大感謝です
2年前のに比べて認識精度がかなり上がっているので昔OCRしたものも再度やり直してます

透明テキストPDF化をなにとぞお願いいたします

全ファイルのOCRが完了した時に何らかの音が鳴ると嬉しいですね
以前と違ってかなり早く終わるので気づかないことも多い

GUIだけでなくCUIでも動作できるようにしていただけると超うれしいですが、優先度は低めでも

>>580
基本的には、OCRengine.exeでほとんど処理してるので、標準入力に順番に対象ファイルを入れて行けば処理される感じです。
次のやつにコマンドラインから呼ぶ時の方法も書いておきますね。

>>581
ありがとうございます！気長にお待ちしております

連続した会話文で2つ目以降の「（カギカッコ）が抜ける例ですが
bunkoocrの最新のバージョンですと、ある程度の高解像度の画像ファイルならほぼ無くなりましたが
古いスキャナやデジカメで撮影したような低解像度のファイルだとたまに出てきますね
文意はわかるのであまり気にはなりませんが

ゴミを除去するための空白閾値が高すぎると、細い文字や薄い文字が巻き込まれて除去されるので、0に近づけるとよいかも
blank_cutoffというやつ。20だと薄めの字は飛ぶと思うです

>>1にあるフリーのOCRの中ではフロントエンドがないNDLOCRが一番敷居高い気がする

【脳科学】「政治行動の激しさ」に関連する脳回路の存在が研究で判明 [すらいむ★]
http://egg.5ch.net/test/read.cgi/scienceplus/1744637408/

上記のリンクをたどったリンク先の本文とコメントを読まれると・・・
余裕ありますか・・・
大々的にインターネット上にばらまかれました！

本性露骨に露したな

>>572
分割するよりNTFSでフォーマットしたほうが早いと思う。

>>572 です
新品のスティックならNTFSでフォーマットもありえます｡
今回は､新品のスティックではなく､既に幾つかのファイルが保存されてる使いふるし品への追加です｡

ベクター･フリー･ソフトの[ファイル分割 FDHoot]は手っ取り早く分割できました｡
よくできてます｡

bunkoOCRで「こ」が「と」に認識されるのがあった
出版社によって使ってるフォントが違うせいだと思うけど
「こ」の間が「乙」みたいにつながってる文字が誤認識するみたい

>>591
どこの出版社のやつとかわかりますか。次の再学習の時に入れたいので、サンプルになる本を教えていただけるとありがたいです

>>592
新潮文庫で辻村深月「ツナグ」という本です

「こ」の部分
https://i.imgur.com/RNf6Qv1.jpg

>>593
ありがとうございます。新潮文庫は、手持ちにあるので同様の文字が無いか確認してみます。

あ、これ
内容からすると特別にフォント変えてあるのかな。実物見てみます。

人間さんも読み間違いしそうで...
aとoを読み間違える某教科書体にはムカついている。

>>595
画像は「こ」が入ってるところを幾つか抽出して貼っただけです
小説全体でこんな感じのフォント使ってますね
探したところ講談社でも似たようなフォントで見つかりました

bunkoocr様、目次や登場人物紹介のレイアウトが崩れるのはどうしようもないことなんでしょうか？

目次だと漢数字のページ数（一ニ三など）が全部まとめて文章後方に行って
見出し部分は前に固まる感じ

登場人物も、　人名A---------その説明文、のようなものですと中盤から崩れ始めます
数ページなので手動で直してもあまり手間はかかりませんが

と、書き込んだら何やら興味深い話

新潮文庫は自分も10冊近くやりましたが画像とは違う繋がっていないフォントでしたね
文春・講談社・集英社・小学館・角川・朝日ソノラマなど150冊以上ocrしましたが
そのような事例はなかったと思います
ジャンルや発行年代が違うのかな？

作家によってはこだわりでフォントを指定してくることがある…みたいな話をなんかでみたことがある
出版関係者じゃないのでホントかどうかはしらんけど

>>598
iOS版では多分直ったと思うので、windows版に反映させているところです。
文のブロックの形成方法を少し修正しました。

bunkoOCRを使わせてもらいましたがすごく良かったです。
だた「廣」が「広」になってしまうのが気になりました。
ある意味正しいのでしょうけど人名だったので手打ちで修正しました・・・

「こ」も必ずしも失敗しないのがまた悩ましい
https://i.imgur.com/n3bTQ0f.png

>>602
旧字のあたりは、勝手に変換してしまう時があるんですよね。見つけ次第直してたんですが、
廣と広は学習が足りてなかったみたいです。
どこの学習データにそのへんの変換が入ってしまっているのかが実はよく分かってなくて。
文字コードと字体の変換テーブルが、新しい字の方になってしまっているフォントが
使っている中にあるのかな。

>>597
ありがとうございます。貼っていただいた画像で試したところ、なぜか95%のサイズに縮小すると
ちゃんと認識しました。
一応リサイズオプションつけたような気がするので、もしよければ試していただけますか。
今のモデルは、大きい字になった場合繋がっていると間違えるやすいようなので、追加学習でまた直しておきます。

bunkoOCRの作者に聞きたいことがある

・Android版を作る予定はある？
・（NDL古典籍OCR-Liteみたいに）精度が多少落ちてもいいので、CPUのみで高速処理できるバージョンは作れる？

Android版なんていらんだろ

>>605
Androidだと、性能の保証ができないので難しそうだなと。
なお、Androidのスマホをプレゼントしてくれるなら別ですけど、使ってないデバイスで開発するのは難しいです。
精度があんまり落ちないCPUバージョンは一応できましたが、これ以上速くするにはモデルサイズを
刈り込まないといけないのでちょと面倒。蒸留とかすればいいんでしょうけど、そんなにすぐにはできないです。

bunkoocrで出力されたjsonファイルを皆さんはどうやって活用してるんですか？
そのままじゃ読みにくいですよね
epubやら変換するツールみたいなのがあるんですか？

>>607
>蒸留とかすればいいんでしょうけど、そんなにすぐにはできないです。
わかりました、無理に急がなくても大丈夫です

しかしソフ板でなんでエロ広告？

bunkoOCR作者様、とても重宝させてもらってます
ありがとうございます

ところで横書き縦書きを指定することはできないでしょうか
横書きの文書で各ページ中の4行ぐらいが縦書きに判定されてしまいます

>>611
windows版の方でしょうか。
オプション入れ忘れてる気がしますので、次のバージョンで足しておきますね

>>612
Windows版です
よろしくお願いします！

次のバージョンはまだ時間がかかりそうですかね？
楽しみに待っています

ついでにTransformerの部分の再学習をさせてるので、もうちょいかかりそうです。
もう少しのところで微妙に精度が上がらないので苦しんでいるところです。

>>615
ありがとうございます
作者様のおかげで私の自炊ライフはかなり捗っています
もう数百冊自炊して一人でスマホの本棚画面を見てニヤニヤしてる感じです

ocrbunkoで、これみたいに括弧内が2行になってるの読み取り方法ありますか？
https://i.imgur.com/LCXKvKF.jpeg

>>617
19　インスマウスの影
たちが、いろいろ毛色の変わった各地の人間を連れてきたということもよくごぞんじのことと
思います。セイラム（マサチュセッツ州北東部にある港町）の男が支那人を妻にして帰ってきたという話をお聞きに
なったことがあるでしょう。それに、ほら、どこかコッド岬（マサチュセッツ州にある大西洋につきだした岬）の近くに
は、フィジー諸島（太平洋南部の英領植民地）の住民がいまでも大ぜいいるそうじゃありませんか。
　まあ、なんですね、インスマウスの連中の背後には、なにかそんなことがあるにちがいあり
ませんな。あの町は、沼や入江がたくさんあって、よその町とはいつも連絡が遮断されたよう
な形になっているものですから、くわしいことはよくわからないんです。が、マーシュ老船長
が、自分に任されている三隻の船を使って、二十人、三十人と、妙な住民たちを連れ帰ったに
ちがいないことだけは、かなりはっきりわかっています。現在インスマウスに住んでいる連中
には、確かに妙な特徴がありますな――もっともそれを、どう説明したらいいのかわたしには
わかりませんが、なにかこう、背すじがむずむずしてくるようなものなんです。あのサージェ
ントのバスにお乗りになれば、あの男にも、そういうところがあるから、ははあこれだな、と
すぐわかりますよ。あの連中のなかには、妙に頭が狭くって鼻が平べったく、それに眼はふく
らんでいて開きっぱなしみたいにじっと人をにらんでいるようなご面相のものがいるんですが、
こいつらの皮膚ときたら、お話になりません。鮫肌で吹きでものだらけだし、頸の両側はしわ
だらけでくびれているんです。おまけに、若いうちから、頭が禿げるときています。年を取っ
た連中は、それぁもう、見られたもんじゃありません――まったくの話が、あの連中をこの目
で見たときは、まさかと思いましたよ。自分の姿を鏡で見たら、きっと死ぬにちがいありませ
こんな感じでよければ。
ふりがなの判定と、割注(文中に2行に分けて注釈を入れる)の判定が難しいので誤判定されることがあります。
この画像の場合、ちょっと文字が小さい(解像度が低い)ので、少し拡大すると判定が上手くいくようです。
x2.5くらいリサイズしてみてください。

>>617
ありがとうございます。帰ったらやってみます

>>618
自分の環境では3倍でうまくいきました！ありがとうございます

非常に高速なプログラムではUIの更新がボトルネックになるそうだけど
デバッグ出力を止めたら速くなりそう

エラーが発生したファイルはWait listに残りますが、もう一度やり直せませんか？
Windows版です

読取革命を持っているがPDFにOCRをかけてPDFで保存すると元画像を維持できない
FineReaderは画像を改変しないとのこと(AIで調べただけ)
FineReaderを使っている方　いかがですか

FineReaderはバージョン16になるとサブスクだけになるようだ
今はまだソースネクストで15の買い切り版が買える
27,500円と安くはないけど

ScanSnap付属の古いバージョンは持っているがOCR精度はよくない
元画像は維持されるから有料バージョンでも同じだとは思うが

ScanSnap SV600に付属していたScanSnap Organizerをずっと使っていたが
PCのクラッシュを機に後継のScanSnap Homeをインストールしてみた
日本語縦書き雑誌をOCRしてみたが精度は変わらなかった
ScanSnap Homeは使いにくいので元に戻そうかな

bunkoOCRの精度が最も高いことはわかっているがPDFに埋め込めないのが残念

bunkoOCRで埋め込みPDFを作るべく、フォーマットのお勉強してるのでしばしお待ちを
いまここまで来た
https://github.com/lithium0003/pdf_addtext

すばらしい
楽しみにしてます

それはありがとうございます　期待してお待ちします

もう１つお願いがあります
市販品のスペックを見るとオプションでOCRをリフローにできるものがあります
https://www.sourcenext.com/Product/1000001825/ とか
改行が削除されることで改行をまたいだ検索ができます
ご検討いただけるとうれしいです

>>628
画像の文字の場所に埋め込むとすると、行の切れ目で分けざるを得ないのですが、
Acrobat readerとかは次の行っぽい場所にあればくっつけてくれるようです。
リフローOCR処理されたpdfのサンプルってありますか。どうやってるのかがわからないので、どうやって実装するのかかがわからんのです。

>>629
Acrobat Readerのその挙動には気付いていましたが必ず検索できるとは限らないようです
リフローならば確実に検索できるでしょうね
PDF OCRソフトはほとんどサブスクになってしまってしかもボッタくりの値段ですね
ソースネクストの旧版FineReader 15は買い切りなのでちょっと高いけど買って試してみようかと思っています
（読取革命は買ってありますが問題外）

>>630
場所がページ内のどこでもいいなら、全文貼るのは簡単なんですが。
場所を合わせつつ、切れないようにするのができないので、なんか裏技あるんかしらと

>>631
これとかどうですか
https://www.antenna.co.jp/XSL-FO/sample/pdf/sample-writing-mode.pdf
https://www.antenna.co.jp/AHF/ahf_samples/ja/fo/language/writing-mode-1.pdf

>>631
きちんとしたPDFエディタを持っていないのでFineReader 15を買ってみてしまいました
リフローのオプションはPDFには無くて、テキストやワードファイルに保存する場合だけでした
しかも段落の認識精度は低い

けしからんことには画像を変えずにOCRの透明テキストを追加することができませんでした

>>632
サンプルありがとうございます。

いまのところこんな感じなんですが、内部的な処理としては同じようにTjコマンドで
順番に出してるのですけど、これで皆さんの環境で検索可能になってますか。
https://github.com/lithium0003/pdf_addtext/raw/main/Sample/IMG_2399.pdf

>>633
ありがとうございます。
画像をそのままにして、ごにょごにょするのって実はめちゃくちゃむずいんです。
とりあえずの目標は、官報を全文検索可能にするテストですが、デコードややこしい。
模様の付いたタイトルとかも実は画像だったりもして、そういうのは弾かなきゃなのでまたややこしい

>>634
リフローなんてPDFではできないものだと思ってしまいました
余計なことを書いてすみませんでしたと謝らなければいけないのかと思ったのですが
官報を全文検索可能にするテストとは驚きました
期待しております

サンプルはAcrobat Readerで検索できています

サンプルIMG_2399.pdfで「婆さん」を検索すると24行目末尾は検索されません
リーダーが改行をまたいで検索するオプションを持っいてくれれば済む話だとと思うんですがね

>>634
サンプルIMG_2399.pdf

SmatraPDFで行末跨ぎ検索(「婆さん」など)やctrl+aで全選択してクリップボードコピーが出来ました
ただし行が傾いているせいか、マウスでの文字選択がトリッキーです
(選択してても所々カーソルの様な選択幅しか表示されない、実質無害ですが)

PythonのMyMuPDF(SmatraPDFも同じmupdfエンジン)でもテキスト抽出できました

SmatraPDFは使ったことがありましたがそんな機能があったとは気付きませんでした
本家も見ならってほしい

Acrobat Readerで行跨ぎ検索が効くのは検索語句が漢字語句かカタカナ語句に限られるような感じがする
よって「婆さん」には効かない
Windowsサーチ用のAcobat Reader付属のiFilterも同じである様子

Mac版のAcrobat readerだと、「婆さん」で改行かかっててもヒットするな。バージョンによるのかしら
座標を絵に合わせてTmで配置し直してるけど、前の行の近傍にある場合だけ、後続のTjがくっつく動作になってるっぽい。
Macのプレビューだと、そういう行は切れちゃう。

自分はAcrobat ReaderをインストールしてないですがエクスプローラーからPDF検索出来てます
(「婆さん」は何箇所もあるので別のものだと「そうした気候の恩恵」など)

Windowsデフォルトのハンドラーが使われているようです
(SumatraPDF IFilterもありますがインストールしてなかった)

Computer\HKEY_CLASSES_ROOT\CLSID\{6C337B26-3E38-4F98-813B-FBA18BAB64F5}
Reader Search Handler
%systemroot%\system32\Windows.Data.Pdf.dll

みなさん検証ありがとうです。
だいたい行けそうな気配がするので、この方針でpdf埋め込み行くことにします。
bunkoOCRに入れ込むので、もうちょっと待っててください。

自分のPCも調べたらWindows標準のPDF検索機能が使われていて「そうした気候の恩恵」もマッチしました
Acrobat ReaderをインストールしていたのでてっきりそのiFilterだと思い込んでいました

何を見て「Windowsサーチ用のAcobat Reader付属のiFilterも同じである様子」なんていう嘘を書いてしまったんだろう
すみませんでした
Explorerの検索はよく使っているのでうれしい結果でした

>>642
良かったです、よろしくお願いします

>>643
すみません、少し複雑なので省略しました
実際にはここに書いてある順番で調べていく必要があります
https://learn.microsoft.com/en-us/windows/win32/search/-search-ifilter-registering-filters
https://learn.microsoft.com/ja-jp/windows/win32/search/-search-ifilter-registering-filters

自分の場合に使用されているifilterを示したかったのですが、>>641のレジストリーだけで決定されるわけではなく
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.pdf\PersistentHandler (Defalut)={1AA9BF05-9A97-48c1-BA28-D9DCE795E93C}
Computer\HKEY_CLASSES_ROOT\CLSID\{1AA9BF05-9A97-48c1-BA28-D9DCE795E93C}\PersistentAddinsRegistered\{89BCB740-6119-101A-BCB7-00DD010655AF}
下に>>641のCLSIDでの登録があるのでその部分だけ示しました

iFilterの表示名だけであれば
Win+Sサーチ -> Indexing Options -> Advancedボタン -> File Typesタブ -> リストのpdfまでスクロール
で確認できると思います

スマホのアプリでいくつか試したけど上のサンプルのでもできたりできなかったりするのでアプリ側が行跨いで検索する機能があるかどうかがまずあって、
サンプルのだとできたアプリでも自前のpdfだとできる文章とできない文章があるからpdfでも対応してなきゃいけないみたいですね

AIに聞いてみたら行跨ぎ検索に対応しているリーダーはWinでは有償無償含めてSumatraしかないそうだ(AIは堂々と嘘書くから信用はしてないが)

PDFでリフローのような構造が存在するのかどうかは存じませんがbunkoOCRテキスト出力にもリフローのオプションを用意していただけらうれしいです
それくらい自分でスクリプトなりなんなり書けと言われてしまうかもしれませんが本体に機能があると便利ですので

ググったらAI Overviewと言うのが表示されて、リフローPDFなるものは無いそうです

While PDF itself is not inherently reflowable, the Reflow feature in PDF viewers allows text to adjust to different screen sizes, making it easier to read on various devices. This feature is available in applications like Adobe Acrobat and similar PDF readers.

Here's a more detailed explanation:

PDFs are typically designed with a static layout:
This means the text and images are placed in a fixed position on the page, similar to a printed document.

Reflow mode rearranges the content:
When you enable reflow in a PDF reader, the text is reorganized into a single column that adapts to the screen width, eliminating the need for horizontal scrolling when zooming in or reading on smaller screens.

Not all PDFs are created equally:
While reflow can improve readability for many PDFs, it doesn't always perfectly follow the reading order, especially if the PDF wasn't created with accessibility in mind, according to Fondazione LIA.

Reflow is a viewing feature, not a file format change:
It's a display setting within the PDF reader, not a permanent change to the PDF file itself.

Converting to EPUB is another option:
For more significant control over text size and layout, you can convert a PDF to the EPUB format, which is inherently reflowable.

In summary: PDF reflow is a helpful feature in PDF readers that dynamically adjusts text for better readability on different screens, but it's not a fundamental characteristic of the PDF file format itself.

論文雑誌の画像スキャンOCR例がありましたので何かの参考までに
https://www.jstage.jst.go.jp/article/jjsai/27/1/27_67/_article/-char/ja

SumatraPDFですが
段組み内の改行跨ぎ検索は大丈夫、例「新聞やテレビ」
段組み跨ぎやページ跨ぎはダメでした、例「リアルタイム」

OCR処理ではなく画像処理の問題ですが、スキャン画像の傾きが補正されていて
画像は白黒ディザリングでサイズダウンしている様です

官報でやってみた
埋め込みPDF
https://github.com/lithium0003/pdf_addtext/raw/main/Sample/20250718g00165full00010088.processed.pdf
オリジナル
https://github.com/lithium0003/pdf_addtext/raw/main/Sample/20250718g00165full00010088.pdf

13ページくらいから、条約の原文が画像で貼ってあるのをテキスト検索できるようになった、と思う。

あとは、どういう感じで画像を抽出しつつOCRして戻すのをやるかを考え中。
自分で遊びたい人は、ソースはこれ
https://github.com/lithium0003/pdf_addtext
C++でコンパイルする必要があるけど

官報のレイアウト難易度凄いですね(縦書き横書き、回転文書画像など)

しかも縦書きTrue PDF部分ではクリップボードコピーしたら一文字毎に改行されてました
(改行を取った状態『「第六十条第三項第一号」に改め、「規定による」を削り』などで検索は出来ますが)

これはもう対応しなくて良いと思いますが、OCR部分で気が付いたのがP25の点線囲いの部分が誤認識してる様です

４ 第一項及び第二項の規定による立入検査の権限は、犯
罪捜一査のためにーー認ーめーーられーーたーものーーとー解釈してーーーーーーーーはーならない。ーーーー
第百六条次の各号ーのいずれかに該当するときーはー、そ」の違
反行為をした者は、三十万円以下の罰金に処する。
一〜七（略）
八 第七十二条の二第一項又は第二項の規定に違反し
て、報告をせず、若しくは虚偽の報告をし、又はこれ
らの規定による検査を拒み、若しくは妨げたとき。
ー
ーー

>>650
そこの点線は誤認識してますね。
一応点線っぽいところは自動で外すロジックになってるのですが、文字に近接しすぎているので場所的に
ふりがな扱いの伸ばし棒と誤認されて拾ってしまってますね。
これはもう無理ゲー
前処理で、罫線を見つける処理を走らせてマスクする必要がありそう。

>>651
ですよね、どんなシステムで文書作成してるのか逆に気になります

>>650の「一文字毎に改行され」がSumatraPDFのせいなのかと思い、
観念してAdobe Acrobat Reader DCをインストールした所、その通りでした(64bit version 25.001.20577)

官報のTruePDF縦書きクリップボードコピーも「一文字毎に改行」はされなくて連続してコピーされ
さらにIMG_2399.pdfの「婆さん」の行跨ぎ検索も出来てます

縦書き文字列のマウス選択操作もSumatraよりも断然正確でした
(行が傾いていてもその傾き通りに選択状態になる)

ScanSnap用のScanSnap OrganizerやScanSnap HomeのOCRエンジンはABBYY製だと言われているので、
製品版ABBYY 15を高い金を出して買ってみたのだが、OCR精度(縦書き日本語)はScanSnap用よりも悪いし、
画像を変えずにPDFにOCR埋め込みはできないし、他のソフトでPDFに埋め込んだOCR透明テキストは編集できないし、
OCR後のリフローテキスト出力は段落認識の精度が悪いし、といった具合で、金をドブに捨てた感じ

PCをリカバリーしたら自分がScanSnapを買った時付いていたPower PDF Standardの認証ができなくなっていた
ベンダーが変わったからそんなこともあろうかと事前に調べてテストしておいたのだがライセンスは
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Licenses
に保存されているのでそれをregファイルにエクスポートしておいてインストール後実行前に開けばよろし
それにしても無責任なことだな

Power PDF StandardはScanSnap Orgaizer/HomeよりもOCRの精度が高い(日本語縦書)
欠点は既にOCR透明テキストが存在していても消してくれずOCRが二重になってしまうこと

その後気付いたのだがこういうページがあった
https://faq.pfu.jp/faq/show/4835
でもregファイルで保存しておく方が認証を気にせずに済み、何台でもインストールできて(そんなことはしないけど)いいと思う

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

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

ルビまではとりあえずいらないけど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
既成プログラムしか使わないバッチファイル