【文字認識】OCRソフト【 自炊 】 [無断転載禁止]©2ch.net

光学文字認識（こうがくもじ にんしき、Optical character recognition）ソフト

Windows版bunkoOCRをMX-Linux上のWine6.22で実行してみた-7

bunkoOCR_20230918を試してみました。

・私にとっての戦争は終わりました

素で起動するとやはりエラーになったが、神の指示に従いparam.configの"use_GPU:1"を"use_GPU:0"に書き換えて保存/実行したところ、エラーウィンドウは現れず、ドライブをまたいだ別ドライブ中の日本語フォルダの.tif画像を複数指定でき、画像と同じファルダ内に.jsonファイルができあがりました！！

ここまで対応していただいた神に感謝します。

linuxでGPUの方がよければ、CUI版にしてfind inputdir -name '*.png' | OCRengine -
とかできるようにもできるけど、需要あるのかしら。
Linuxの民なら、オリジナルのpython版で実行しそうな気もする。

AozoraEpub3の説明
青空文庫をEPUBやMOBIファイルなどに変換して、kobo、kindle,などのEPUBリーダーなどで読むことができるソフトウェアです。作成したEPUBは電子書籍販売サイトで販売できるので、電子出版ツールとしても使うことができます。
https://github.com/kyukyunyorituryo/AozoraEpub3/wiki

むしろepubを青空文庫形式に変換してくれるツールが欲しい。
縦書きルビ入りとかきれいに表示してくれるソフトがあんまないから。

>>859
半自動で変換するツールなら作った。
HTMLのタグを変換と削除、ルビの変換、UTF文字のタグ変換くらいだが。
画像やタグの追加は全自動化出来ないので手動だが。

bunkoOCRに読み込ませる画像ファイルは、縦横256ピクセルの倍数のサイズが効率よいのかな

bunkoOCRに読み込ませる画像ファイルは、縦横256ピクセルの倍数のサイズが効率よいのかな

512 x 512に区切って処理してて、256でウインドウをスライドさせているので256の倍数だと
最後のブロックに余りが出ないですね。

>>860
ベクターあたりでの公開希望

iOS17から縦書き日本語が読み取れるようになった
APIなりSDKあれば縦書き日本語OCRでは最強かもしれん知らんけど
ペラ紙書類の縦書きはもうiPhoneで完結だわ

>>0860
私もEPUBから青空文庫形式への変換を試みています
がEPUBの仕様の自由度が高くて難航しています。
出来れば公開してほしいです
お願いいたします。

公開するとメンテナンスしなきゃならないし、バグ対象はともかくおま環にまで対応しなきゃならないしエラー処理も細かく作らなきゃならないからヤダ。

epub, mobi →青空文庫の変換は対応タグに違いがいろいろあって、青空文庫では調整できないのも多いし、一部は標準化されてなくてビュアーごとの独自拡張だったりする。
結局、書籍の特徴や自分の好みや使ってるツールに合わせて決め打ちで変換することになる。汎用のツールを作るのは無理。

>>866
https://kyukyunyorituryo.github.io/aozora/

pdfに画像透明テキスト埋め込みするのって最適のライブラリって何かあるですか？
縦書きに対応は必須で、ふりがなに対応できるとうれしい。
それとも、コピペするとき不便だから、ふりがなは除去して埋め込むのが普通ですかね

PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて

PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて

PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて

使ってないから違うかもだがCapCapはどう?

スマホのGoogle翻訳アプリで画面撮影。

bunkoOCRの作者様へ
要望が有ります
１．
ルビに関係ない所に挿入された特殊文字（U+FFF9からU+FFFB）は、無視してほしい
２．
行頭の全角スペースと”「”の認識精度を上げてほしい
３．
青空文庫形式での出力時は以下の文字を置換してほしい
ルビ以外外での「《」を「［＃始め二重山括弧］」に
ルビ以外外での「》」を「［＃終わり二重山括弧］」に
縦書き未対応の記号の「≪」を「［＃始め二重山括弧］」に
縦書き未対応の記号の「≫」を「［＃終わり二重山括弧］」に
★変換したい文字は、ファイルで指定できればなお良い
４．
空行も出力してほしい
自炊小説の場合は空行も重要です

>>873
PCOTならデスクトップは無理だがアプリ内OCR＆翻訳はいける

>>0873
ソフトウェアとして配布はされていませんが
以下のリンク先の記事は参考になりませんか？
ttps://qiita.com/gabigabi/items/2c58eb9a500fc0b33e19

>>0876

ルビが変なところに認識されるのは、孤立したものを除くルーチンがバグっているので直します
今、認識エンジンを再学習させているので、行頭の認識ももう少し改善する予定です
文字置換は、なにか変換テーブルを作ればいいのかしら
空行については、実は仕組み上めっちゃむずいのでちょっと考えます。

文字のブロックの座標は取れるのですが、その間隔が何行に相当するかをちゃんと
算出するのがかなりむずい。
今は、ブロックごとに空行を1行挟んで出力しています。
章番号とかも明後日に飛んでいくので、本当は間にちゃんと挟みたいのですが。

>>879
876です
回答ありがとうございます。
改善に期待しています
さて、文字の置換については
>>文字置換は、なにか変換テーブルを作ればいいのかしら
この方向でお願いします
実装して頂けるのであれば、ルビの表記の変換前に挿入して下さい
青空文庫形式の時のみの仕様ですので、他の形式には影響が
無いようにお願いします。

Googleレンズみたいにリアルタイムにレシートを読み取ってくれるのがないか検索。

https://www.isp21.co.jp/solution/quickdata/
リアルタイムテキスト解析
独自のかざしOCR技術

spexperts が かざしOCR を利用
spexperts は LINEレシートを提供

でもLINEレシートは写真撮影してから解析で時間かかる。かなり正確だけど。

memo

>>881
特許6435017