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

Win+Shift+Tの画面OCRは自動で縦中横認識出来る

というか横しか対応してないオチとか

bunkoOCRはテキストの行が入れ替わるだけでなく、テキストのブロックが丸々抜けてしまうことがあり、
そういう時にはjsonにもそのテキストのブロックは記録されていない
それでも文字は全部精度よく記録されているのでjsonでPDFも作っておくのがよさそう

>>849
あれやこれや処理してる時にバグが取れてなくて飛ぶことがあるので、失敗する画像例を作者に送りつけてくれると
バグの発見が速くなるのでもしよければ送っておいてください。
だいぶ直したけど、まだリリースできてなくてすみません

>>850
作者様に以前メールでお送りしたブロック順がメチャクチャになり横を縦と認識された部分もあるサンプル
https://i.imgur.com/rr8qttx.jpeg
でPDFを作ってみました
「テキストのブロックが丸々抜けてしまう」は見間違いでした　すみません
SumatraPDFはページまたぎ検索もできてでPDFでもリフローテキストと同様に使えますがこの例では
bunkoOCRでの誤認識と同じく「竹藁」と「原料となっている。竹紙は」がヒットしてしまいました
「竹」と「藁」がつながってしまうのは理解できますが、「原料となっている。」と「竹紙は」が
つながってしまうのはちょっと不思議です

透明テキストを可視化したものを一応アップします
https://3.gigafile.nu/0808-cf784ae298abe230af3d5df929a4f435c

>>851
あれかー。めちゃ難易度高いやつで、まだ完全にはクリアできてないです。
近い所を連結するようにしてるのが悪さしてるんですよね。
表っぽい、枠線がないやつは順序が難しい

いまのところこれくらい
https://120.gigafile.nu/0505-babdafae4f15de5d1577424efe06b6342

bunkoOCRの書き出したテキストが、

「・・・現在、日本紙幣の主原料となっているほか、ティーバッグ、掃除機の紙パック
の原料となっている。

竹紙は、中国で唐時代（7世紀）から作られ、宋時代（10世紀以降）には竹が紙
の主原料となった。・・・」

となっていますが、１文字ずつ書き込んだだけのPDFをどうテキストとしてつなげるかはリーダーの判断だと思うのですが、
OCRテキストとSumatraのどちらも「原料となっている。」と「竹紙は」がつながっていたのがどうしてかなと思いました

レイアウトを維持しようという意図のないNDLOCRはテキストの順序だけは正しいですね
文字化けもいくつかあるしbunkoOCRに期待しています

内部的に、「竹」と「藁」のタイトルの後の空白が、段落の区切れと誤認していて
「竹　藁」で一つにしちゃってて、その後ろの本文が、空行区切りで連続している本文とみなして
繋げて出力してしまっています。
https://i.imgur.com/EnzPhEQ.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エスケープは&だったわ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows2000版とWin98版
希望です

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

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

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

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

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

最近YomiTokuを併用してる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

何言ってんだこいつ

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

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

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

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

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

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

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

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

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

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

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

片手落ちだな

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

倫理と論理の争いだな

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

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

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

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

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

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

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

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

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

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

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

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

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

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