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

**名無しさん＠お腹いっぱい。** · 2024/11/30(土) 09:07:30.91

bunkoOCRでIntel Iris XeはGPUとして認識されないけど次のような方法を試して使えるようになった
作者様にもメールで確認をした

(1) タスクマネージャーのパフォーマンスでGPUの共有GPUメモリの最大値を見る

(2) 何かのコンパイラで次の2行を標準出力に書くexeファイルを作る

8000MiB meomry
0

1行目は(1)のGB表示に1024を掛けた数値の端数を切り捨てて書けばよい

(3) detectGPU.exeをそのファイルに置き換える

Intel Iris Xeは能力が低いのでそれほど早くはならないけど消費電力が低いので
熱くなってファンがうるさくなることも少なくなる

**名無しさん＠お腹いっぱい。** · 2024/12/01(日) 04:00:56.64

>>481
作者です。よく確認したら、結果はあってるけどちょっと違ったです。
detectGPU.exeの結果は、標準出力は使ってなくて、エラーコード(実行ファイルの返り値)
を使っているので、出力内容は何でもよくて、エラーコード0(正常終了)を返すexeなら何でもいいです。

int main() {
return 0;
}

なプログラムが必要です。
0がgpuインデックスになる感じです。

**名無しさん＠お腹いっぱい。** · 2024/12/01(日) 10:32:00.77

>>482
お知らせありがとうございます

**名無しさん＠お腹いっぱい。** · 2024/12/02(月) 02:35:21.53

エロ広告が死ぬほどうざいが、OCRの火はまだ燃え続けているようでうれしい。

**名無しさん＠お腹いっぱい。** · 2024/12/12(木) 20:16:06.27

bunkoOCRは段組を自動で判断してるみたいだけど
？や！のあとに一文字空白があると多段と認識して後半の文が
改行したり文章の一番うしろに飛ばされることが度々ある
一段か多段かを選択できたら精度が上がる気がする

**名無しさん＠お腹いっぱい。** · 2024/12/13(金) 01:31:08.67

やっぱりフォーマット解析を先に通すべきかな。
2行以上同じ場所に空白があると、そこに引っかかることが多いので。
段組の解析と、文章ブロックの解析を先に回して、順番を確定してから
中身をOCRするといいのかもしれない。範囲が狭くなって時短になるし。

**名無しさん＠お腹いっぱい。** · 2024/12/24(火) 12:10:25.05

bunkoOCRは先頭が「だと必ず欠けるのが困るッス。

**名無しさん＠お腹いっぱい。** · 2024/12/28(土) 22:16:33.65

朝方プラスだった？
よかった！

**名無しさん＠お腹いっぱい。** · 2024/12/28(土) 22:49:26.78

https://news.yahoo.co.jp/articles/bb73dfa4d3ffdcea3453253108688b774e186f3d
はじめの枕詞は無しにして、記事の説明で出してくるケース

**名無しさん＠お腹いっぱい。** · 2024/12/28(土) 22:49:55.47

誤爆だった

**名無しさん＠お腹いっぱい。** · 2024/12/30(月) 05:40:44.33

ABBYYとUMI-OCRで日本語の認識精度もしかして大差ない？

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 17:36:55.32

れえかにはみもぬみおにかいるくもねきおえさてんのふま

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 17:53:03.26

一応オリエンタルバイオという既存スポンサーから更に基地外だと思う
カルト被害にあう人間はたいがい依存症だからね

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 18:22:24.27

高齢者がテレビでやってるし
しかし
カプレーゼは簡単でいいよな！
だよなあ
https://eagle.5ch.net/test/read.cgi/livejupiter/1736702458/

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 18:57:41.19

んりふさらおいてわあぬつもてうすうをきうらすひよあそむさけいいもんすのんこれ

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 19:18:18.23

つつんせせなへちへんえんねをもよおむたすねなたほゆよちりやしいもゆのちねんうをりすろのうふてひよ

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 19:20:49.55

>>435
この人はそういうものだから
ソンフンジェイ撮られてないし
歌ってもないのが失礼だとか
そんな怪しさだと思うんだよお婆さん

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 19:35:04.41

アップで見てるだけ
若者以前に技術的な会議だ
要するにウンコでなく有効期限もチェックしても
すぐに観たい人ばかりなんだよ

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 19:59:31.57

防御率が悪いのではあるんちゃうか
今回
保険屋もディーラーも
変な人は作品の質が流石にあれは業界人が出してきた
サル痘とかじゃなくても文句はないけど妙なカリスマ性もある

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 21:13:00.18

別にどう思うか？

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 21:17:29.98

常に権威を過剰に反応されてたんだ～ぁ
さて、このうち乗客が気付いてはいるんじゃね
練習場所の前の身内の事
https://i.imgur.com/P1TAYez.jpeg

**名無しさん＠お腹いっぱい。** · 2025/01/13(月) 21:44:28.58

甘酒を適宜飲むてのは知ってた時代に比べると皆アホほど上手くなった

**名無しさん＠お腹いっぱい。** · 2025/02/05(水) 18:59:29.70

>>501
グロ

代行 · 2025/02/18(火) 20:46:53.61

【本文】↓（↓下段に書いてください)
>>491
縦書きも試してみた？

**名無しさん＠お腹いっぱい。** · 2025/02/18(火) 23:38:19.78

Windows 11 が持っているOCRの機能ってCopilot+ PCだと精度上がるのだろうか？
うちのWin11ではSnipping Toolからのテキスト抽出のアイコンが出て来ないので、PowerToys のOCRを使ってみたけど、別に精度よくなかった。

**名無しさん＠お腹いっぱい。** · 2025/02/19(水) 09:20:59.81

copilotを使うというのは思い付かなかったな
自分のsnipping toolにもテキスト抽出というものは無かった

ためしにcopilotに画面をコピペした日本語の横書き・縦書きテキストのファイルをアップロードして「OCRして下さい」と書いたらどちらも完璧にOCRされた
ただし段落最初のスペースは消えた

エクセルの表をコピペしたらちょっと崩れたけど罫線は文字で表示されて再現された

少量の文書ならば使い物になるかもね

**名無しさん＠お腹いっぱい。** · 2025/02/19(水) 11:28:02.87

そこら辺はちゃんとチェックしてたがcopilot runtimeにOCRのAPIが追加されるんだよな
でちょうど2週前ぐらいにリリースされたWinAPpSdk exp で使えるようになってんだが
NPUが必要で試せないという
NVIDIAさんいずれRTXを対応させるドライバ出してくれるんだよね?

**名無しさん＠お腹いっぱい。** · 2025/02/19(水) 12:42:05.44

WebのCopilotにお願いしたら、これまで見たことあるOCRの中で一番出来が良かった。
横書きだけど。
ソースコードの所は改行消えていたけど。

**名無しさん＠お腹いっぱい。** · 2025/02/19(水) 13:03:47.43

縦書きで試してみたけど、正しく読めた文字から日本語を再作成しているもので、元の文と違う文字列を出してくる。
結局、全文チェックしないといけない奴だ。

**名無しさん＠お腹いっぱい。** · 2025/02/20(木) 16:56:56.72

まとめ機能ついちゃってるのか
それだと、まだOCR専用AIのDocument Intelligenceの方で良い気がする

**名無しさん＠お腹いっぱい。** · 2025/03/03(月) 09:30:55.99

AIのOCRは余計な事するから使うのを止めた。
余計な文を挟み込んでくるんだよ。野坂昭如の翻訳がそうらしい。

**名無しさん＠お腹いっぱい。** · 2025/03/07(金) 23:03:33.49

テストヨロ

高速かつ高精度な文字認識AIモデル「Mistral OCR」が登場、LaTeXで書かれた数式や図表入りPDFのレイアウトを崩さずマークダウン形式で出力できてJSONへのデータ抽出も簡単に - GIGAZINE
ps://gigazine.net/news/20250307-mistral-ocr/

**名無しさん＠お腹いっぱい。** · 2025/03/08(土) 12:45:25.35

>>512
英語はよさそうだけど、日本語は諦めが速すぎる。画像として貼り付けよる

**名無しさん＠お腹いっぱい。** · 2025/03/08(土) 12:49:39.07

わかった。横書きオンリーですな。
横書きなら日本語でもだいたい認識する

**名無しさん＠お腹いっぱい。** · 2025/03/08(土) 15:42:27.79

>>512,513
「数式をOCR処理」の意味するところが良く分からなかったけど
> 複雑な数式を含む文書もOCR処理できます。
> 英語はよさそうだけど、日本語は諦めが速すぎる。画像として貼り付けよる
この二つから類推すると画像内の数式部分を正しく「ここは数式だな」と判別して
文字認識は諦めて画像として貼り付けするという事かな？

表は「ここは表だな」と判断した上で文字認識もしてmarkdownの表として出力して、その結果レイアウトが崩れたりしているけど
数式は「ここは数式だな」と判断してるけどレイアウトが一切変化ないので、画像そのまま
(数式内の各記号を認識して)LaTeXやMathJax等で出力している訳ではない

> Mistral OCRは数式やスキャンデータを含むすべてのカテゴリで最も精度の高いOCRが可能です。
これも「ここは数式だな」と言う判断の的中率を言っているだけな気がして来た

**名無しさん＠お腹いっぱい。** · 2025/03/08(土) 16:22:01.74

>>515
https://i.imgur.com/sspTI0R.png

認識結果
'\n\n数式を認識します。\n\n> > > $y=3 x+b$\n\n積分してみます。\n\n> > > $f(x)=\\int_{b}^{a} e^{-i \\omega t} d x$'

**名無しさん＠お腹いっぱい。** · 2025/03/08(土) 17:00:14.75

mistralは日本語縦書き駄目だね。勢いで久しぶりにAzure試したらこれも駄目。
Google Vision ,Google Document AI のデモやったみたら大成功。
今、スクリプト作成中。

**名無しさん＠お腹いっぱい。** · 2025/03/11(火) 16:22:09.99

https://lithium03.info/product/bunkoOCR.html
機械学習モデルを新しくしたので、色々いじった

性能が上がったのか下がったのか、もう訳わかんなくなってきたので、
暇な人誰かテストして。

ページ番号とかの邪魔な文字を外すやつは、ちょっと保留にしてます。
別のエンジンで領域を選択してやる予定なので、これから作るとこ

**名無しさん＠お腹いっぱい。** · 2025/03/11(火) 22:40:15.06

ありがとうございます
まだ見ている最中ですが2023年版で段組みが崩れていたものが直っていたり、貧弱なIntel Iris Xeでも処理速度が上がっていたりとよくなっていますね

**名無しさん＠お腹いっぱい。** · 2025/03/12(水) 00:14:22.09

新バージョンはどこ？

**名無しさん＠お腹いっぱい。** · 2025/03/12(水) 01:26:05.48

見つけられない子は触らない方がいいよ。
5GB ダウンロードする必要もあるし。

**名無しさん＠お腹いっぱい。** · 2025/03/12(水) 08:47:48.58

>>518
ありがとうございます
ずっと待っていました

ページ番号除去はChainLPなどを使ってやってますが
複数のソフト使わないで済むのは助かりますね

今日中に試してみますね
連続した会話文で2行目のカギカッコが抜ける
ダブルクォーテーションの最初の「“」が抜けるあたりが改善されていたらかなり嬉しい

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 02:06:33.53

bunkoOCR_20250313_patch.zip

出力先を指定出来るようにした。
出力jsonファイル名が被ったときに上書きするかどうか選べるようにした。

要望サンクス

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 15:59:49.10

>>518
早速使わせていただきました
旧バージョンより速度も精度も格段にアップしていて感激です
カギカッコやダブルクオーテーション、一と-の判別も正確に認識されていました

radeon7600xtなのでdirectMLのみチェックして使いましたが
tensorやQudaに対応していなくても何も問題なく快適に動きます
ただ、以前は読み込んだファイルは誤字脱字はあっても全部処理されていましたが
今回のですと稀に処理されずにウインドウ左側に残ったままなのがありました
600ページで7～8個程度で挿絵も入っていない普通の文章の画像ファイルです
（もう一度読み込ませたらちゃんと処理してくれました）
また、ルビの小さい文字「ゃ」「っ」を「や」「つ」と認識するのが結構ありました
それとキャッシュフォルダも見た限りでは作成されてない思います

以前のバージョンに比べて質の低いファイル、低画質でぼやけてたり汚れてたり傾いているものも
かなり正確にocr出来ている感じです
旧版はファイルの画質やサイズに関わらず同じような時間と負荷がかかっていましたが
今のですと低画質ファイルならRADEONでもかなり速くなります

420ページの文庫本、1ページあたり200～300ＫＢ程度のファイルでも
旧版だと1時間7分程かかっていたのが今回は7分で終わったので10倍近く速くなりました
それでいて認識精度も良くなっているので嬉しい限りです
600dpi、1ページあたり6～800ｋｂのものだと多少遅くなり420ページで20分程度。
GPU負荷はどちらもほぼ100％ですが消費電力は前者が平均120W程度に対して後者だと150～60と高くなります
温度も平均45度と53度で高くなっています
低画質でも読み取り精度が高く結果が変わらないのであまりスペックが高くないPCの方、省エネしたい方は
画像編集ソフトなどでリサイズすれば負荷がかからなくていいかも

とにかく素晴らしいソフトをありがとうございました
以前はOCR処理してる時間に自炊や他の作業をしてましたが
今はいつのまにか終了してる感じです

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 16:36:32.91

>>524
テストありがとうございます。

リストに残っちゃうのが謎です。ちょっと負荷テストしてどこがおかしいかチェックしてみます。

つとやの小さいのと大きいのを間違えるのは、ふりがなで小さくしないルールの文庫本と、ちゃんと小さく書く青空文庫を両方取り込んだので、迷いがあるのかもしれません。
アルファベットを半角にするか全角にするかとかも、迷いが見られるので、この辺りはどうしたもんかなと。
後処理でなんとかする方がよいかもしれません。

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 16:38:42.69

DirectMLとCUDAは、キャッシュ使わないので生成されないので合ってます。
TensorRTとOpenVINOがキャッシュ出すはずです

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 17:06:11.45

新バージョンでも482のexeに差し替えてDirectMLでIntel Iris Xeが使えました
遅いけど消費電力が小さいのでファンが静かでいいです

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 18:36:21.87

>>527
新バージョンでは、設定からDirectMLで使用するGPU番号が決めうちできるようにしたので、番号を指定するとそのGPUを使う、はずです。
-1の時だけ、detectGPUで探すようにしました

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 19:22:24.88

detectGPUを差し替えしなくてもDirectMLでidを0に指定したら確かにIntel Iris Xeが使用されました

**名無しさん＠お腹いっぱい。** · 2025/03/13(木) 23:28:54.36

>>524
bunkoOCR_20250314_patch.zip
多分リストに残る原因が分かった気がするので、修正しました。
いわゆるスレッド競合というやつをやらかしたっぽいです。

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 16:14:41.94

11世代のcore i7を使っていますが、あるサンプルで処理時間を比較してみました
CPU 55秒
DirectML 55秒 (内蔵GPUが使用される)
Open VINO 43秒 (内蔵GPUは使用されない)

CPUとDirectMLが同じというのは意外でした

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 17:37:29.68

>>530
更新ありがとうございます
処理できなかったファイルは2バイト文字を含むフォルダの7階層ぐらい下にあるファイル
だったのでそれが原因かと思ってました
10数冊OCRしていますが処理できないファイルが数個残ったのはその一冊だけでした

小さいひらがなは設定を変えてもあまり上手くいかないのですが
普通に理解は出来るのでそのままにするか
気になる場合は「《」をエディタで検索して手作業で直すか
それとも一括処理できる方法があるか考えてます

あと今回は嬉しい改善点があって、正式な名称がわからないのですが強調に使う傍点？
これは以前のバージョンだと青空文庫用にしてもルビ無し設定にしても
1行として認識されてレイアウトがかなり崩れていたのですが
今回はデフォルト設定でもしっかりと認識されてました

https://imgur.com/a/Rd23WtH

こういう表現は小説ではよく見るのでかなり助かります

すごく精度が高いので、あとは読み込ませる画像ファイルをちゃんとノンブル削除しておくと
出来上がった数百個のテキストファイルを結合して、
改行コード一括削除、『「』を文頭に『。』や『」』の次を改行
空白の後も改行。目次は余裕があったら設定して表紙を付ければ
誤字ゼロではないですが読むには全く問題ない電子書籍が出来ますね

これで電子化にあまり積極的ではない作家の著作を自炊するのが捗ります
どれだけ感謝してもし足りないぐらいです　ありがとうございました

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 18:50:56.21

CPUの演算は int8に量子化してるので、ちょっと精度落ちる分だけ速いはず。
DirectMLはfloat16じゃなくてfloat32になってるっぽいからちょっと速度損してる
と思われる

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 19:22:49.69

>>531
float16で計算するようにしてみたのですが、これでDirectMLの速度と精度は変わりますか？
bunkoOCR_20250314b_patch.zip

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 21:41:44.19

>>534
早速のご対応ありがとうございます
同じサンプルで55秒が45秒まで短縮されました（プログラム起動後それぞれ2回目の処理時間を目視で測りました）

サンプルが文庫本のスキャンではなくて対象外かもしれませんがOCR後のレイアウトは崩れています。パッチ前後での相違はテキストファイルの31行目の「[6]」が「助」から「囮」に変わったことだけです

ファイルをアップしました
https://2.gigafile.nu/0622-bc206218ec4003ae69eed667b4091af4b

**名無しさん＠お腹いっぱい。** · 2025/03/14(金) 22:24:02.86

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

フォーマットが崩れるのは、竹と藁のとこらへんが一文字なので、ここだけ縦書きじゃないかと
誤認してる感じですね。
Mac版で同じロジックで図示するとこんな感じ
https://i.imgur.com/AOSYw9k.png
区切り部分が連続してるから、隣の段落だと誤解してるので本文と泣き別れてしまっています。

この辺は、ロジックでがんばっているところなので、段組を処理するのと別々にして
上から(右から)順に処理するモードも必要そうですね。

[6]は、括弧が近接しすぎているので認識が難しいみたいです。
どっちみち化けるなら、ちゃんと取れている部分が高速に処理できる方がいいかしら。
fp16にしちゃおうかな。モデルサイズも半分になるし

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 10:52:50.58

bunkoOCRの作者様へ質問ですが
https://imgur.com/a/HcKL7d6
のように前後が空行の見出し行というのはよくありますがどうして字下げにならないのでしょうか
何か設定がありますか

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 11:22:31.89

>>537
字下げの判定のロジックが、そのブロックの他の行よりも下がってるかどうか、に今なってるので、単独行が下にあっても字下げにならないです。
対策するには、ブロック全体がほかのブロックよりも下にある、というのは検出できそうなので、その場合は字下げを追加する、とかがいいかもしれません。
もうちょいこの辺のロジックは良い感じにいじってみます。

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 20:07:02.01

ルビの文字が少しおかしくなってるのがあったわ

「ちゆう」が「ちゆう」、「しよう」が「しうよ」　になってたり

本文は大丈夫みたい

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 20:08:26.41

間違えた、

「ちゆう」が「ちうゆ」

みたいに入れ替わってるみたい

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 21:28:06.13

ルビを無視する設定にできるように上か下にあるページ番号や章の名前などを無視する項目は追加可能ですかね？
一括でトリミングすると削りすぎて本文まで消えたり、逆に消しきれなかったりするのであると便利だと思います

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 22:07:21.03

>>539
もし可能なら、ふりがながおかしくなる該当画像を提供していただけますか。
こちらで、どこにバグがあるか確認しやすくなるので。
手元でもいろいろ不具合はあるので直してますが、入れ替わってるのは別の原因がありそうな気がします。
メールでよければcontact@lithium03.info

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 22:09:07.66

>>541
私も困ってるので、いま効率的にヒットできる方法を考えています。
いいアイデアが出るかフォーマット解析モデルが上手くいくまで、しばしお待ちください

**名無しさん＠お腹いっぱい。** · 2025/03/15(土) 23:21:39.09

bunkoOCRで上手く処理できない画像があった場合、作者に匿名で届けれるように
https://lithium03.info/upload/
作りました。コメント欄にどの辺りがおかしいか書いてもらえると助かります。

**名無しさん＠お腹いっぱい。** · 2025/03/16(日) 10:51:53.43

532さんが電子書籍化のことを書かれていたが自分もそのことを考えていた
完璧な物ができなくてもいいけどリフロー化できれば便利になる
段落が空白で始まり会話文の行頭が「であるような小説は機械的に処理するロジックはできそうだが、そうでない本もあるので汎用的に作るのは難しそうだ
新書的な本で本文だけでよければ図表は事前にグラフィックソフトで消しておくしかないかな

**名無しさん＠お腹いっぱい。** · 2025/03/16(日) 11:36:14.47

縦書きで、上や下にページ番号と章タイトル書いてあるパターンと、横書きで右や左にあるパターンは
多分簡単に外せそうな感じ
横書きで上下にあるパターンはどうしよう。文字の大きさで何とかしようかしら。

図や表は、真面目に解析しないとダメなので、もうちょい時間かかるです。
NDLの認識エンジン使ってみようかしら。

**名無しさん＠お腹いっぱい。** · 2025/03/16(日) 11:54:13.81

図表についても考えていただけているとはうれしいです

**名無しさん＠お腹いっぱい。** · 2025/03/17(月) 15:39:06.11

>>539
ルビが順序入れ替わるバグ、確認しました。どこが原因か探してみます。

**名無しさん＠お腹いっぱい。** · 2025/03/18(火) 14:46:00.77

bunkoOCRの作者様、
１画像の最終行には論理的には改行を付けるべきではないでしょうか
複数画像のテキストを結合するにも手間がかかりませんし

ちなみに市販品「読取革命」でも最終行には改行が付いています

**名無しさん＠お腹いっぱい。** · 2025/03/18(火) 19:38:32.49

>>549
修正してて抜けてることに気付きました。
空改行を含めて改行を入れるように仕様を変更します。
ページ結合する際にやりやすいよう、2行または1行の空改行が入るようにして
2行の連続空改行を置換すると文が連続するようにしようと考えています。

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 10:38:27.72

読取革命は文章だけの本で勝手なレイアウト認識をされるのが邪魔だ
ページ等を事前に削除した画像で１ページ全体を１つの領域にするにはページを選択して右クリックの「すべて選択」→「属性変更」でできることがわかったが
それを全画像でまとめてやることができないようだ
何かいい方法ある？

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 11:15:07.52

枠固定みたいなのあったような

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 11:19:14.21

かえって扱いづらくなるかも

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 17:28:33.58

UWSCでマウスを操作するスクリプトを作って「ページ一覧」ウィンドウの「次ページ」ボタンと画像ウィンドウとを行き来させることで
読取革命で自動的に全画像をそれぞれ単一領域に設定できるとわかった

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 20:45:02.29

どうしてそんなことにこだわっているかと言うとテキストファイルに変換するのに読取革命を自動レイアウト認識で使うと
空行が無視されてしまうためです
出来が悪いとしか言いようがない

例
https://1.gigafile.nu/0627-c0d522a2ed7abb86d0ee3d804f786bb33

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 21:05:17.67

bunkoOCR作者様、
上にアップした例を変換するとbunkoOCRは文字も正確に認識されていていいのですが、
最後の行頭の「　一一月」が「一月」になってしまうのはどうしてでしょうか

**名無しさん＠お腹いっぱい。** · 2025/03/19(水) 21:16:44.54

読取革命、テンプレート作って、かんたん認識で設定したらできるかな

**名無しさん＠お腹いっぱい。** · 2025/03/20(木) 02:36:57.81

>>556
なんかバグ踏んでました。手元で修正している最新版ではちゃんと「一一月」に取れてるので、
処理の繋ぎ目で文字が行方不明になるバグだったっぽいです。

**名無しさん＠お腹いっぱい。** · 2025/03/20(木) 10:01:12.90

>>557
画像が同じような大きさならば一気にできますね
アドバイスありがとうございました

**名無しさん＠お腹いっぱい。** · 2025/03/30(日) 14:19:40.37

bunkoOCR、前後の文字が消えて同じ文字になるのがあったわ
「顔顔」「目目」「がが」「でで」みたいに

漢字なら正規表現([一-龯])\1で探せるけど
ひらがな([ぁ-ん])\1はマッチするのが多いから見つけるのが大変

**名無しさん＠お腹いっぱい。** · 2025/03/30(日) 18:57:40.83

>>560
ごめん今直してるところです。もうしばしお待ちを

**名無しさん＠お腹いっぱい。** · 2025/03/31(月) 17:02:05.31

bunkoocr作者様、お世話になっております
おま環の可能性も高いのですが、bunkoOCR_20250314_patch、bunkoOCR_20250314b_patchの2つのバージョンから
使っているうちにだんだん速度が遅くなってくる現象が見られます（それでも数年前のよりは早いですが）
同じファイルでもbunkoOCR_20250311の方が倍以上の速度で処理できます

例 bunkoOCR_20250311　337ページで10分
bunkoOCR_20250314b_patch　337ページで22分

20250311版はGPU使用率がほぼ9割以上で推移するのに対して
https://imgur.com/ovAhXBI
20250314以降は開始直後は上記と同じで高速で処理してくれるのですが2分ほど経つと使用率にたまに0～10％が出始め、
https://imgur.com/D0fXWCx
だんだんそれの頻度が多くなっていき10分も経つと一瞬だけ90％台で処理、あとはずっと0～5％で処理する状態が続きます
https://imgur.com/a/5wZgwIc
一回終了して再び起動するとまた高速で処理してくれますが、やはり2分程度で遅くなっていきます

**名無しさん＠お腹いっぱい。** · 2025/03/31(月) 17:03:54.57

負荷が軽いのはいいことなのですが同時に処理速度もかなり遅くなるので
今は20250311版にTextDetector.fp16.onnxを入れて処理しています
（これは入れたほうが速度が速くなりました）
ただ、もしかしてradeonのドライバの問題かもしれないです
一応、最新の25.3.1にしたうえでradeon chillなどの省電力機能が干渉してるかもと思い全部オフにして
GPUもデフォルトからOCしてみたりもしたのですが症状は変わらず
温度に関してはソフト実行中でも50度以下で制限がかかるほど熱くはなっていません

環境は以下です

Win10 22H2
Ryzen 5 2600X
radeon 7600←xtだと思ってましたが無印でした
メモリ　32GB
directMLのみチェック

そもそもこのスレでradeon使ってるのは私だけっぽいから他に同じ症状の人はいないのかな？

**名無しさん＠お腹いっぱい。** · 2025/03/31(月) 18:48:41.90

処理してるうちに遅くなるのは、開発環境でもそう言われてみると起きてたような気がします。
あまり長時間のテストをWindowsでしてなかったので気付いていませんでした。
今iOS版でロジックの修正を行っているのがもうちょいで終わるので、Windows版に反映するときに
一緒にみてみます。

**名無しさん＠お腹いっぱい。** · 2025/03/31(月) 21:41:14.63

パッチを当てた後、似たように処理が遅くなるのはあったな
キャッシュを削除して新しくキャッシュを生成したら直ったけど

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 05:22:43.86

>>562
すみません。単純なポカしてました
ログを表示していますが、そこの領域の行数に比例して遅くなっているみたいです
計算自体は遅くなっていないのですが、表示が詰まって最終的には計算まで巻き込まれて
遅くなっていそうです
どっちみちこの部分は進行具合を表示するためのものなので、過去30行くらい残して昔のを
消していくように修正します

その他、iOS版3.2で修正したOCRの処理上のエラーも一緒に直していますので次のバージョンを
お待ちください

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 06:18:19.94

>>566
対応ありがとうございます
楽しみに待ってます

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 21:21:47.40

bunkoOCR抜群です｡旧字体もへっちゃらです｡凄い｡
困ってるのは頁が､左欄､右欄が分かれて､コンサイス英和の様な体裁の時､
左欄一行､右欄一行､左欄二行､右欄二行､〃〃になってしまう｡

左欄全部､次に､右欄全部に指定する方法とかありますか｡

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 21:55:17.12

>>568
見開き+段組と、単ページ+段組で順序が違うので、オプションを導入する予定です。
このオプション入れたら、真ん中らへんに境目があればたぶんいけると思います。

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 22:02:43.53

縦書き本画像を左９０°回転させて横倒れ文字のまま横書き専用OCRソフトが対応してくれればいいのに

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 22:05:18.07

そうしたらみんな左上から右に向かって解析できる

**名無しさん＠お腹いっぱい。** · 2025/04/04(金) 23:10:01.91

568 です｡
レスポンス､ありがとうございます｡気長に待ってます｡

現版5.7G!!でかい｡ 1Mbit/secでダウンロード14時間余かかりました｡
256Gメモリー･ステックにセーブ試みるとエラー「大きすぎ､保存不可」
ベクター･フリー･ソフトの[ファイル分割 FDHoot]で分割して保存しました｡

色んな方々のお世話になってます｡

**名無しさん＠お腹いっぱい。** · 2025/04/05(土) 07:59:20.85

あんまりにアーカイブサイズがでかいので、自分の要らないプラグインに必要なdllを外してダウンロードできる
ダウンローダ作るわ。DirectMLの人やCPUの人はcuda要らないものね

**名無しさん＠お腹いっぱい。** · 2025/04/10(木) 05:03:58.39

bunkoOCRすごいね
久々に感動した

**名無しさん＠お腹いっぱい。** · 2025/04/10(木) 09:02:23.68

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

**名無しさん＠お腹いっぱい。** · 2025/04/10(木) 10:20:07.21

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

**名無しさん＠お腹いっぱい。** · 2025/04/10(木) 14:20:39.96

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

**名無しさん＠お腹いっぱい。** · 2025/04/12(土) 15:53:51.86

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

**名無しさん＠お腹いっぱい。** · 2025/04/13(日) 08:24:07.90

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

**名無しさん＠お腹いっぱい。** · 2025/04/14(月) 02:02:21.59

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

**名無しさん＠お腹いっぱい。** · 2025/04/14(月) 04:07:41.77

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

**名無しさん＠お腹いっぱい。** · 2025/04/14(月) 10:42:25.37

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

**名無しさん＠お腹いっぱい。** · 2025/04/14(月) 20:27:42.51

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

**名無しさん＠お腹いっぱい。** · 2025/04/15(火) 02:55:05.25

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

代行 · 2025/04/15(火) 06:33:59.42

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

**名無しさん＠お腹いっぱい。** · 2025/04/15(火) 11:03:36.31

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/15(火) 19:23:00.94

bunkoOCRさん、小説の節っていうのか知らないけど
1、2、3ってのが中盤にあっても文章の頭に表示されるのを修正してほしい

　　　　　1

みたいになってるやつ
空白が多いと難しいのかな

**名無しさん＠お腹いっぱい。** · 2025/04/16(水) 05:43:06.25

本性露骨に露したな

**名無しさん＠お腹いっぱい。** · 2025/04/16(水) 20:08:12.64

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

**名無しさん＠お腹いっぱい。** · 2025/04/16(水) 22:50:44.19

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 16:38:47.18

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 17:38:18.94

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 18:39:07.75

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 19:29:33.60

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 19:35:04.55

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 19:55:06.63

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 20:14:07.75

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 20:28:26.15

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 20:43:48.25

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 21:12:57.57

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 21:35:06.21

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 21:46:53.46

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 22:28:52.93

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/17(木) 23:06:12.17

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

代行 · 2025/04/19(土) 07:38:13.13

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

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

**名無しさん＠お腹いっぱい。** · 2025/04/19(土) 10:56:57.48

Android版なんていらんだろ

**名無しさん＠お腹いっぱい。** · 2025/04/19(土) 11:41:42.75

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

**名無しさん＠お腹いっぱい。** · 2025/04/19(土) 16:29:00.37

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

代行 · 2025/04/22(火) 07:32:38.20

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

**名無しさん＠お腹いっぱい。** · 2025/05/28(水) 15:57:35.30

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

**名無しさん＠お腹いっぱい。** · 2025/06/18(水) 15:54:40.27

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

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

**名無しさん＠お腹いっぱい。** · 2025/06/18(水) 18:23:50.70

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

**名無しさん＠お腹いっぱい。** · 2025/06/18(水) 20:05:12.30

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

**名無しさん＠お腹いっぱい。** · 2025/06/19(木) 13:48:15.39

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

**名無しさん＠お腹いっぱい。** · 2025/06/19(木) 19:05:28.87

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

**名無しさん＠お腹いっぱい。** · 2025/06/20(金) 20:22:39.16

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

**名無しさん＠お腹いっぱい。** · 2025/06/23(月) 18:47:06.12

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

**名無しさん＠お腹いっぱい。** · 2025/06/23(月) 20:37:06.16

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

**名無しさん＠お腹いっぱい。** · 2025/06/24(火) 05:48:46.88

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

**名無しさん＠お腹いっぱい。** · 2025/06/24(火) 19:12:34.99

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

**名無しさん＠お腹いっぱい。** · 2025/06/29(日) 08:10:40.59

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

**名無しさん＠お腹いっぱい。** · 2025/06/29(日) 08:24:47.07

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

**名無しさん＠お腹いっぱい。** · 2025/07/22(火) 10:44:44.00

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

**名無しさん＠お腹いっぱい。** · 2025/07/22(火) 16:19:35.07

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/28(月) 16:51:27.27

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 04:24:38.85

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 04:43:02.86

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 08:58:00.52

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 09:57:52.06

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 10:50:04.19

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 12:27:50.42

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 14:14:05.95

>>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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 18:26:38.14

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 19:09:37.39

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 19:42:41.45

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 20:20:13.41

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 21:16:00.17

>>634
サンプルIMG_2399.pdf

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/29(火) 21:38:58.51

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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 10:24:14.81

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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 17:33:30.37

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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 17:41:22.40

自分は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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 18:53:37.59

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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 18:59:27.02

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/30(水) 20:12:39.04

>>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までスクロール
で確認できると思います

**名無しさん＠お腹いっぱい。** · 2025/07/31(木) 07:22:57.88

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

**名無しさん＠お腹いっぱい。** · 2025/07/31(木) 09:47:16.66

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

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

**名無しさん＠お腹いっぱい。** · 2025/07/31(木) 11:31:09.20

ググったら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.

**名無しさん＠お腹いっぱい。** · 2025/08/01(金) 18:30:40.03

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/08/02(土) 06:49:17.77

官報でやってみた
埋め込み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++でコンパイルする必要があるけど

**名無しさん＠お腹いっぱい。** · 2025/08/02(土) 16:51:20.82

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/08/02(土) 17:11:04.77

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

**650** · 2025/08/02(土) 18:46:20.53

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/08/03(日) 12:00:05.05

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

**名無しさん＠お腹いっぱい。** · 2025/08/04(月) 08:03:12.76

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

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

**名無しさん＠お腹いっぱい。** · 2025/08/04(月) 08:30:40.14

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

**名無しさん＠お腹いっぱい。** · 2025/08/23(土) 10:27:18.08

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/08/24(日) 06:35:22.44

Window楽しみに待ってます

**名無しさん＠お腹いっぱい。** · 2025/08/25(月) 22:11:33.54

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

**名無しさん＠お腹いっぱい。** · 2025/09/01(月) 23:04:59.55

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

**名無しさん＠お腹いっぱい。** · 2025/09/06(土) 20:13:56.97

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

**名無しさん＠お腹いっぱい。** · 2025/09/06(土) 20:24:53.44

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

**名無しさん＠お腹いっぱい。** · 2025/09/09(火) 23:58:11.75

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

**名無しさん＠お腹いっぱい。** · 2025/09/10(水) 15:21:45.55

11からの機能だったはず

代行 · 2025/09/14(日) 08:47:38.72

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

**名無しさん＠お腹いっぱい。** · 2025/09/22(月) 20:57:38.33

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/09/23(火) 03:22:27.09

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

**名無しさん＠お腹いっぱい。** · 2025/10/03(金) 14:01:06.48

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

**名無しさん＠お腹いっぱい。** · 2025/10/03(金) 14:11:13.88

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

**名無しさん＠お腹いっぱい。** · 2025/10/03(金) 23:39:12.47

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

**名無しさん＠お腹いっぱい。** · 2025/10/04(土) 10:46:48.40

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

**名無しさん＠お腹いっぱい。** · 2025/10/15(水) 21:52:29.81

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

**名無しさん＠お腹いっぱい。** · 2025/10/15(水) 23:40:03.08

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

**名無しさん＠お腹いっぱい。** · 2025/10/17(金) 16:40:11.01

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/10/18(土) 01:32:44.93

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

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

**名無しさん＠お腹いっぱい。** · 2025/10/18(土) 01:35:17.01

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

**名無しさん＠お腹いっぱい。** · 2025/10/21(火) 19:15:01.75

いくつか試したのでレポ

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

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

**名無しさん＠お腹いっぱい。** · 2025/10/21(火) 21:09:05.68

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

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

**名無しさん＠お腹いっぱい。** · 2025/10/22(水) 00:35:00.94

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

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

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

**名無しさん＠お腹いっぱい。** · 2025/10/22(水) 10:45:15.53

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

**名無しさん＠お腹いっぱい。** · 2025/10/22(水) 19:38:07.66

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

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

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