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

**名無しさん＠お腹いっぱい。** · 2024/09/27(金) 09:32:15.05

AzureでOCR,DeepLで翻訳がオススメ
ただし、一定以上とか編集可能PDFにするには金がかかるけど

**名無しさん＠お腹いっぱい。** · 2024/09/29(日) 06:15:09.42

DeroLは無料だと1500文字制限が不便だったので試したらOCRと雲泥の差があって驚いた。アマゾンとグーグルも試してポンコツならDerpL課金します。
AIも課金してるが翻訳までハルシネーションがあって使い物にならないので不便。

**名無しさん＠お腹いっぱい。** · 2024/09/30(月) 10:05:17.06

AzureのOCRって縦書きもいける？
試してみようかな

**名無しさん＠お腹いっぱい。** · 2024/09/30(月) 11:18:20.27

文字の認識は優秀だけど縦書きレイアウト認識がポンコツ

**名無しさん＠お腹いっぱい。** · 2024/09/30(月) 17:38:39.66

言うほどポンコツかなー
俺は横書き本しか持ってないけど、親が専門関連の文庫を読みたいから英訳してって言われて
>>460でやったけどわかりやすいって言ってた
まぁ自分が読むだけなら知識と読解力でカバーできるってのもあるのかもしれんけど

**名無しさん＠お腹いっぱい。** · 2024/09/30(月) 22:36:21.63

>>464
そうなの？地味にアップデートしてるのかな？
少し前に試した時はそりゃあひどい代物だった

**名無しさん＠お腹いっぱい。** · 2024/10/05(土) 12:05:51.67

自分はそういうプログラムの知識はないので小説などを簡単にやれる方法として今は

課金済みv-flatで撮影（カメラ性能の良いスマホと三脚、照明が必要）
↓
PCにコピーしてノンブルなどをトリミング
↓
bunkoocr(ルビは認識が怪しいのでつけない)
↓
txt結合、改行やカギ括弧など修正
↓
calibreで表紙をつけてepubにして完成

挿絵や図表などある場合は面倒だけどcalibreで該当箇所に挿入
これでなんとか自分専用で読めるぐらいにはなる
誤字もあるし他人に見せるレベルじゃないし連続した「も認識ミスするけど
これを全部修正していったらどれだけ時間かかるかわからないし
途中のファイルもちょっと見るだけで修正したくなるのであえて割り切ってそのまま作成してる

v-flat単体でもOCR機能はあるけどノンブル自動トリミングがないのでほぼ使ってないが
認識率や速度はまぁまぁだと思う

代行 · 2024/10/14(月) 07:02:49.79

v-flatはサブスク制なのがなあ

**名無しさん＠お腹いっぱい。** · 2024/10/23(水) 08:56:07.95

bunkoOCRは１年以上進展ないな
期待しているんだが

**名無しさん＠お腹いっぱい。** · 2024/10/23(水) 22:40:28.18

>>468
うちのGPUはずっと唸りをあげて学習中なんですが、なかなか完璧とはいかず、公開できるとこまで行かないのです

**名無しさん＠お腹いっぱい。** · 2024/11/02(土) 22:57:05.03

bunkoOCRのソースをダウンロードしたが、うちの環境では動かん。
残念！

**名無しさん＠お腹いっぱい。** · 2024/11/13(水) 16:21:25.31

Text Grab
https://github.com/TheJoeFin/Text-Grab

**名無しさん＠お腹いっぱい。** · 2024/11/26(火) 19:47:10.80

縦書きも認識できるフリーのOCR少ないよね

**名無しさん＠お腹いっぱい。** · 2024/11/27(水) 01:44:57.81

有料でもポンコツだしなあ
まともなのはソリューション価格のしかないんだよねえ

**名無しさん＠お腹いっぱい。** · 2024/11/27(水) 10:37:20.67

>>472
フリーではbunkoOCRが一番よさそう
自分のIntel Iris Xeでは時間がかかるけど

**名無しさん＠お腹いっぱい。** · 2024/11/27(水) 18:49:17.31

こんなん出たらしい
https://github.com/kotaro-kinoshita/yomitoku

**名無しさん＠お腹いっぱい。** · 2024/11/27(水) 21:07:53.30

>>475
パッケージラベルで少し苦戦しているけど、枠線内の文字レイアウトが離れすぎだったり、歪みはしょうがない
デジタル出版例もスマホ撮影例も凄く高解像度な画像だから割と上手く行っている側面がありそう

肝心なのは印刷物の通常スキャン解像度(白黒300dpi程度)での精度なんだよね

**名無しさん＠お腹いっぱい。** · 2024/11/28(木) 10:26:27.62

国会図書館が古典籍資料からテキスト抽出する軽量OCRツールを公開～GPUなしでも動作 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1642941.html

**名無しさん＠お腹いっぱい。** · 2024/11/28(木) 11:42:12.15

ヘタレのためにほかのツールもWindowsバイナリを提供しておくれ

**名無しさん＠お腹いっぱい。** · 2024/11/28(木) 14:49:27.19

yomitoku凄いね
これで透明テキスト付きPDF作れるようにしてくれないかなー

**名無しさん＠お腹いっぱい。** · 2024/11/28(木) 18:08:28.78

yomitokuで縦書き文章を試してみたけどルビがよみにくい
たとえばある行に3ヶ所ルビがある時

ルビ1
ルビ2
ルビ3
本文行

のように4行となる

また、なぜか行の順番が入れ替わってしまうものもあった

**名無しさん＠お腹いっぱい。** · 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
>蒸留とかすればいいんでしょうけど、そんなにすぐにはできないです。
わかりました、無理に急がなくても大丈夫です

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

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