[過去ﾛｸﾞ] 【文字認識】OCRソフト【 自炊 】 [無断転載禁止]©2ch.net (882ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
833(1): 名無しさん＠お腹いっぱい。 [] 2023/09/15(金)03:30 ID:SxicWH5N0(2/2)
bunkoOCR_20230915.zip アップロードしました。
>>832 の内容を直しました。
そのほか、NVIDIA以外のGPUの場合、
一番よさそうなGPUが1.8GB以上のメモリがある場合にDirectMLで動くと思います。
834: 名無しさん＠お腹いっぱい。 [sage] 2023/09/15(金)20:00 ID:rObGG81S0(1)
>>833
連日のアップデートありがとうございます
今回のバージョンでRadeonのGPU支援でのOCRができました
CPU使用率が2割ぐらいになり、代わりにRadeonの使用率が100％になりました
ファンが1000rpmでGPUの温度は80度前後で推移していたので長時間動かしても問題なさそうです
1分に4枚程度の処理速度はGeforceに比べるとすごく遅いんでしょうが、それでも私にとっては大感謝です
835: 名無しさん＠お腹いっぱい。 [] 2023/09/15(金)23:28 ID:yvCdDh3I0(1/2)
試してみて感動したので使用報告です。
環境 Core(TM) i5-12600K メモリ32GB(一部RAMディスク) GeForce RTX 3060Ti
Windows11 bunkoOCR_20230915 使用
小説を1冊試してみました。（昔自炊したラノベ）
…うっかり事前にノンブル個所トリミング忘れ。
1.ノンブルが上の右か左の隅だったからか、生成されたtxtファイルの先頭１行目がノンブルだったので、chatgptさんに聞いて、一行目削除しながらtxt結合をパワーシェルで実行。
2.結合したtxtファイルの改行を全部消して、” ”もしくは”「”の前に、改行を挿入（なんかもうちょっとスマートな方法ありそう）
これでほぼほぼいけるtxt完成。半分くらい試読したけど、文字は9割8分がた認識OK。※”｜”が”I”になるのと行頭の”「”の認識不良はちょこちょこあったけど読むのに支障はない。
報告
360ファイル一気に追加したら、「bunkoOCR.exe」がフリーズ。
右上の×でタスクの終了したら、「OCRengine」は動きはじめて、150ファイル程度jsonを出力して、消えた。
3回ほど試して同じ症状でした。
※「bunkoOCR.exe」のタスクを終了しないと5分ほど待ってもjsonの出力ははじまりませんでした。
なんとなくですが、ファイルパスを保管する配列の制限な気がします。"R\小説名 第01巻￥001.jpg"を360ファイル一気に追加するとフリーズしましたが、フォルダ名を変えて"R\a￥001.jpg"にすると追加できました。
久しぶりに携帯で自炊した小説読もうとしたら、画面が縦長になったこともあり文字が小さく読みにくく、読取革命の体験版を試して絶望してたところでした。
素晴らしいソフトありがとうございます。
836: 名無しさん＠お腹いっぱい。 [] 2023/09/15(金)23:42 ID:yvCdDh3I0(2/2)
追記；
正確には、こういう流れで試したので、２バイト文字とかではなく、パス長かなぁと判断した次第です。
1回目:"R\小説名 第01巻￥image-001.jpg"
2回目:"R\aaa￥image-001.jpg"
3回目:"R\a￥001.jpg"
837: 名無しさん＠お腹いっぱい。 [sage] 2023/09/16(土)00:39 ID:ECc3An080(1)
Windows版bunkoOCRをMX-Linux上のWine6.22で実行してみた-5
bunkoOCR_20230915を試してみました。
・Wineのエラーが出たああああああああ
ついに完全体が使えると思ったところで正直これはくやしいが、もともとWindows用のソフトを勝手にLinuxで動かしているので、直してとは言うまい。
エラーログの一部ですか、意味ありげな矢印があやしい？
---------
00000138 (D) E:\home\XXXX\ダウンロード\bunkoOCR_20230915\bin\OCRengine.exe
0000013c 0 <==
00000144 0
00000148 0
0000014c 0
00000150 0
00000154 0
00000158 0
0000015c 0
-----------
念のため、ver.914を消さないでおいてよかった。
幸い.jsonファイルから.txtに変換するツールの新バージョンは複数ファイルを一括選択できるので、テキスト化ツールをver.915に差し替えてver.914でOCRすることになろうか。
うーむ残念。
838: 名無しさん＠お腹いっぱい。 [] 2023/09/16(土)02:52 ID:Cnx2YXrY0(1/2)
GPUの判定のために、DirectXの関数を呼ぶようにしたのがよくないのかしら。
サーバー上には旧バージョンも保持しているので、ファイル名変えて落としてください。
というかLinuxで動くと便利かもしれないとも思った。
839(1): 名無しさん＠お腹いっぱい。 [] 2023/09/16(土)19:07 ID:Cnx2YXrY0(2/2)
>>0836
ひょっとして、半濁点とかの正規化の問題なのかも。そういった文字が入ってそうですか？
840: 名無しさん＠お腹いっぱい。 [sage] 2023/09/16(土)23:02 ID:eNgZ5CS80(1)
すごい精度ですね。文庫をtxtにして適宜加工、voiceoaekで出力して車で聞かせて頂いています。ありがとうございます。
私だけかもですが、起動して初回に、ふりがな無しのテキスト出力だけ選択、他の出力のチェックボックスを外して実行すると、jsonだげ出力されてtxtが出力されないみたいです。複数ファイルの時は二つ目からはtxt出力されてる。
841: 名無しさん＠お腹いっぱい。 [] 2023/09/16(土)23:35 ID:VKdO3VUp0(1)
>>839
とりあえず。以下でテストしました。
プログラム本体は、以下のパスにて実行"R:\bunkoOCR_20230915\bin\bunkoOCR.exe"
起動した[bunkoOCR.exe]にドラッグ＆ドロップでファイルの追加
ファイル名は”007.bmp”~"325.bmp"までの計316ファイルを一回で追加
※今回はトリミングした時に一部表紙や白紙のファイルを除いていますので連番ではありません。
ファイルの位置を以下のフォルダ直下に置いて追加。
・”R:\新しいフォルダー” フリーズ
・”R:\aaaaaaaaaaaaaa” フリーズ
・”R:\aaaaaaa” 追加成功
・”R:\aaaaaaa\aaaaaaa” フリーズ
・”R:\a\a” 追加成功
フリーズの判定は、”タスクマネージャーでCPU・ディスクアクセスの数値が０になり、メモリの数値も変動しなくなって１０秒程度経過したこと”としました。
１回だけは、フリーズ状態で5分程度放置しております。
最後に"半濁点"・"２バイト文字"・”ー”の可能性を考慮して、
ファイル名を”新ォダー001.bmp” ~”新ォダー316.bmp”にリネーム
・”R:\aaaaaaa” フリーズ
・”R:\a” 追加成功
なので、ファイル名の半角・全角とかではなく、総パス長なのかなという想像ですが、プログラムは10数年前に大学時代に軽く触った程度なので自身はあまりない
842(1): 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)00:27 ID:6FdPC6Jr0(1/6)
>>0841
検証ありがとうございます。
追加したときに、左側のリストに待ち行列が並ぶはずですが、フリーズしたときは
ここに追加されている状態でしょうか。
追加されていた場合は、bunkoOCR.exeの画面の一番下に出ているログはどんな文字で止まっていますか。
OCRengine.exeとやりとりして処理をさせているのですが、OCRengine側のどこを今処理しているかが
この部分に順次表示されています。
843: 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)01:44 ID:hTcgI3oY0(1)
>>842
直前の表示で止まってます。”prosess start”もしくは”ready”など
ドロップインドロップした瞬間に、左側にスクロールバーが表示されますが、ファイル名は1行も追加されません。
あと、”jsonToText.exe”に”R:\小説名 第02巻” の”001.jpg.json”等ファイルを一気に追加は動作しました。が、
"bunkoOCR.exe"に”R:\小説名 第02巻” の”001.jpg”等ファイルを一気に追加はフリーズしました。
844: 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)02:08 ID:6FdPC6Jr0(2/6)
>>0837
Ubuntu 22.04でWineを入れて試して見たところ、CPUモードだとちゃんと動くっぽい
OCRengine.exeの方をコマンドラインで動かして、readyって表示されるところまで行かない感じですか。
多分GPUのロード処理で新しく追加したところが怪しいのですが、いま良いGPUはお仕事中なので
別のLinuxでしか試せなくてよくわからん感じです。GPUが空くまでお待ちください。
>>0841
こちらで検証してみたら、原因がわかりました。
処理すべきファイルのリストを、OCRengine.exeに送って処理してるのですが、
多数のファイルが一気に追加されたときに待ち行列が溢れる状況になり、
(パイプで送っているけども標準入力のバッファがいっぱいになる)
追加が途中で詰まるようです。
バッファサイズは4Kバイトらしいので、ファイル名を短くするとバッファに入りきるため
固まらないようです。
この部分の処理を調整しましたので、あとでアップロードしておきます。
845: 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)02:43 ID:6FdPC6Jr0(3/6)
bunkoOCR_20230917.zip アップロードしました。
一気にファイルを追加したときに固まるのを修正しました。
846: 名無しさん＠お腹いっぱい。 [sage] 2023/09/17(日)18:47 ID:Y9TuI/LZ0(1/2)
Windows版bunkoOCRをMX-Linux上のWine6.22で実行してみた-6
bunkoOCR_20230917を試してみました。
・今度は動いた!?
神のubuntu環境では動いたらしいし、これがあるからLinux版を作って欲しいとか安易に言えんのよな、GMバリエーション並に種類だけはあるから……とダメ元でVer.917を試したところ、起動しても『重大な問題が発生したため……云々』という例の文言が出てこない。
え？ もしやと思って別ドライブの.tifファイルを複数指定してみると、OCRが始まった！
やった、さすがは神！ と思ったら、プロセスはちゃんと仕事してたのに.jsonファイルができていない……。
また次元の谷に落ちたか？
↓さすがにファイルパスが長かったのでしょうか？
E:\media\xxxx\62F8754E43FDBE64\■■■■\●● ●●●●\ノンブル除去済み種\out\1009.tif
まあ動くだけいいかと起動ドライブ側のファイルを指定したら、いつもの文言が出てダメだった。
というか何で最初の1回だけ動作したのだろう？
ウィンドウは起動するが、ステータス欄の『process start』が出た辺りで例のエラーメッセージが出てしまう。再起動してみたがやはり同じ。
ま、まあLinux者としてはVer.914にバッファ問題を解決したjsonToText.exeの併せ技で十分しのげるから、高望みは慎もう。
847(1): 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)18:49 ID:6FdPC6Jr0(4/6)
bunkoOCR_20230917b.zip アップロードしました。
>>0837
GPUの判定処理を分離して、失敗した場合CPUフォールバックするようにしました。
多分sshでX転送してると思うのですが、ディスプレイが存在しない場合WineでD3Dの
関数が失敗します。この場合は、どっちみちDirectXだと速度が出ないのでCPUに落としています。
848(1): 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)18:53 ID:6FdPC6Jr0(5/6)
>>0846
すみませんjsonファイル作るときに20230917だと上書きのミスがあるかもです。
元ファイル確認してください。末端のヌル文字を抜き忘れてjsonが足せてないファイルに書いた可能性が。
849: 名無しさん＠お腹いっぱい。 [sage] 2023/09/17(日)21:56 ID:Y9TuI/LZ0(2/2)
>>847
>>848
折角神に骨折っていただいのに、残念ながらVer.917bでも起動後にエラーが出てダメでした。
あとjsonToText.exeで対象ファイルを一括選択したくて。Ctrl+Aを押しても反応せず、Shift+→でまとめて選択しようとしても、なんか反応が遅いです。
850(1): 名無しさん＠お腹いっぱい。 [] 2023/09/17(日)22:52 ID:6FdPC6Jr0(6/6)
>>0849
エラー出るけども、別のexeに分けたので無視して続けるとそのまま処理できませんか？
jsonToText.exeでCtrl+Aが効かないのは、wineの方が悪い感じがします。Windows11だと効くので。
なんかフラグ足したらましになるとかありますかね(クラシックモードなら効くとか)
851(1): 名無しさん＠お腹いっぱい。 [sage] 2023/09/18(月)00:44 ID:kMx4hZfp0(1/3)
>>850
エラーが出てもあまりにも堂々とウィンドウが出ているので、ファイルを選択して食わせるまではできるのですが、ステータスに"Host version: 5.10.0-25-amd64"と出て、そこから先がいくら待っても進まないですね。残念ながら。
jsonToText.exeでCtrl+A不可の件、大変失礼しました。
連日のように付き合っていただいているというのに。
Wineのモード？ もwindwos7相当からWindows10相当にしてもダメでした。
それにしても、何であの一回だけ動いたんだろう……。
852: 名無しさん＠お腹いっぱい。 [] 2023/09/18(月)08:36 ID:0SjZIDuo0(1/4)
>>851
Ver.917bのOCRengine.exeだけを、直接wineで実行したらどこで止まりますか。
wine OCRengine.exe
wine OCRengine.exe 0
で、エラーは変わりそうですか。
上はCPUモード、下はDirectMLモードになるようにしています。
試してて気付いたのですが、winehq-devel まで上げるとエラーウインドウ出ないような気がします。
853: 名無しさん＠お腹いっぱい。 [] 2023/09/18(月)09:58 ID:0SjZIDuo0(2/4)
bunkoOCR_20230918.zip
パラメータが保存されているparam.configをテキストエディタで開き、
use_GPU:0に書き換えるとDirectMLを使用しないように強制できます。
wine OCRengine.exe
で落ちないようなら、use_GPU:0にしてもらうと処理できるようになると思います。
854: 名無しさん＠お腹いっぱい。 [sage] 2023/09/18(月)11:05 ID:kMx4hZfp0(2/3)
早朝からすいません。
CPUモードなら正常、ということでしょうか。
wine OCRengine.exe の場合
--------
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
（略）
OpenVINO
OpenVINO
OpenVINO
ready
--------
23行目のredyまで実行。エラーウィンドウは出ない。
wine OCRengine.exe 0 の場合
--------
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
（略）
00c8:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
wine: Unhandled exception 0xc06d007e in thread c8 at address 000000007B037FC8 (thread 00c8), starting debugger...
013c:fixme:imm:ImeSetActiveContext (0x154e00, 1): stub
013c:fixme:imm:ImmReleaseContext (0000000000010064, 0000000000154E00): stub
006c:fixme:imm:ImeSetActiveContext (0x15dba0, 0): stub
006c:fixme:imm:ImmReleaseContext (0000000000010020, 000000000015DBA0): stub
--------
19行目までは同じ。25行目が出てエラーウィンドウが出る。
今Ver.918をダウンロードしてますので、追試結果はもう少々お待ちください。
855: 名無しさん＠お腹いっぱい。 [] 2023/09/18(月)11:22 ID:0SjZIDuo0(3/4)
こっちで考えた状態であってたようです。DirectMLでロードしようとすると落ちちゃうようですので、
Ver.918でuse_GPU:0に書き換えて実行すると、とりあえずは動くようになりそうです。
856: 名無しさん＠お腹いっぱい。 [sage] 2023/09/18(月)11:49 ID:kMx4hZfp0(3/3)
Windows版bunkoOCRをMX-Linux上のWine6.22で実行してみた-7
bunkoOCR_20230918を試してみました。
・私にとっての戦争は終わりました
素で起動するとやはりエラーになったが、神の指示に従いparam.configの"use_GPU:1"を"use_GPU:0"に書き換えて保存/実行したところ、エラーウィンドウは現れず、ドライブをまたいだ別ドライブ中の日本語フォルダの.tif画像を複数指定でき、画像と同じファルダ内に.jsonファイルができあがりました！！
ここまで対応していただいた神に感謝します。
857: 名無しさん＠お腹いっぱい。 [] 2023/09/18(月)12:29 ID:0SjZIDuo0(4/4)
linuxでGPUの方がよければ、CUI版にしてfind inputdir -name '*.png' | OCRengine -
とかできるようにもできるけど、需要あるのかしら。
Linuxの民なら、オリジナルのpython版で実行しそうな気もする。
858: 名無しさん＠お腹いっぱい。 [sage] 2023/09/21(木)18:58 ID:IZK9wj/L0(1)
AozoraEpub3の説明
青空文庫をEPUBやMOBIファイルなどに変換して、kobo、kindle,などのEPUBリーダーなどで読むことができるソフトウェアです。作成したEPUBは電子書籍販売サイトで販売できるので、電子出版ツールとしても使うことができます。
https://github.com/kyukyunyorituryo/AozoraEpub3/wiki
859(1): 名無しさん＠お腹いっぱい。 [sage] 2023/09/21(木)23:06 ID:LsrnBNJV0(1)
むしろepubを青空文庫形式に変換してくれるツールが欲しい。
縦書きルビ入りとかきれいに表示してくれるソフトがあんまないから。
860(1): 名無しさん＠お腹いっぱい。 [sage] 2023/09/22(金)06:50 ID:dJI/QveM0(1)
>>859
半自動で変換するツールなら作った。
HTMLのタグを変換と削除、ルビの変換、UTF文字のタグ変換くらいだが。
画像やタグの追加は全自動化出来ないので手動だが。
861: 名無しさん＠お腹いっぱい。 [sage] 2023/10/02(月)15:23 ID:dw1v1evD0(1/2)
bunkoOCRに読み込ませる画像ファイルは、縦横256ピクセルの倍数のサイズが効率よいのかな
862: 名無しさん＠お腹いっぱい。 [sage] 2023/10/02(月)15:23 ID:dw1v1evD0(2/2)
bunkoOCRに読み込ませる画像ファイルは、縦横256ピクセルの倍数のサイズが効率よいのかな
863: 名無しさん＠お腹いっぱい。 [] 2023/10/03(火)06:17 ID:8+ujl4QD0(1)
512 x 512に区切って処理してて、256でウインドウをスライドさせているので256の倍数だと
最後のブロックに余りが出ないですね。
864: 名無しさん＠お腹いっぱい。 [sage] 2023/10/04(水)20:44 ID:vRUF6acm0(1)
>>860
ベクターあたりでの公開希望
865: 名無しさん＠お腹いっぱい。 [sage] 2023/10/09(月)23:35 ID:WG0A8Uhb0(1)
iOS17から縦書き日本語が読み取れるようになった
APIなりSDKあれば縦書き日本語OCRでは最強かもしれん知らんけど
ペラ紙書類の縦書きはもうiPhoneで完結だわ
866(1): 名無しさん＠お腹いっぱい。 [] 2023/10/19(木)07:36 ID:zGVZ5rc10(1)
>>0860
私もEPUBから青空文庫形式への変換を試みています
がEPUBの仕様の自由度が高くて難航しています。
出来れば公開してほしいです
お願いいたします。
867: 名無しさん＠お腹いっぱい。 [sage] 2023/10/19(木)09:00 ID:9iReVXET0(1)
公開するとメンテナンスしなきゃならないし、バグ対象はともかくおま環にまで対応しなきゃならないしエラー処理も細かく作らなきゃならないからヤダ。
868: 名無しさん＠お腹いっぱい。 [sage] 2023/10/19(木)09:27 ID:bNKbLe6D0(1)
epub, mobi →青空文庫の変換は対応タグに違いがいろいろあって、青空文庫では調整できないのも多いし、一部は標準化されてなくてビュアーごとの独自拡張だったりする。
結局、書籍の特徴や自分の好みや使ってるツールに合わせて決め打ちで変換することになる。汎用のツールを作るのは無理。
869: 名無しさん＠お腹いっぱい。 [sage] 2023/10/30(月)01:26 ID:zJhf5BLT0(1)
>>866
https://kyukyunyorituryo.github.io/aozora/
870: 名無しさん＠お腹いっぱい。 [] 2023/10/31(火)01:41 ID:dvkv99P10(1)
pdfに画像透明テキスト埋め込みするのって最適のライブラリって何かあるですか？
縦書きに対応は必須で、ふりがなに対応できるとうれしい。
それとも、コピペするとき不便だから、ふりがなは除去して埋め込むのが普通ですかね
871: 名無しさん＠お腹いっぱい。 [] 2023/11/05(日)14:23 ID:0L6HLOnn0(1/3)
PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて
872: 名無しさん＠お腹いっぱい。 [] 2023/11/05(日)14:24 ID:0L6HLOnn0(2/3)
PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて
873(1): 名無しさん＠お腹いっぱい。 [] 2023/11/05(日)14:24 ID:0L6HLOnn0(3/3)
PC画面の文字を認識して即翻訳できるソフトってありますか？できれば\０〜１０００以内で、
無料のCapture2Text試しましたが使い物にならなくて
874: 名無しさん＠お腹いっぱい。 [sage] 2023/11/05(日)15:35 ID:UJ3RQ2Wr0(1)
使ってないから違うかもだがCapCapはどう?
875: 名無しさん＠お腹いっぱい。 [sage] 2023/11/05(日)15:46 ID:dDirpvM+0(1)
スマホのGoogle翻訳アプリで画面撮影。
876: 名無しさん＠お腹いっぱい。 [] 2023/11/07(火)11:11 ID:g1O/GcqC0(1)
bunkoOCRの作者様へ
要望が有ります
１．
ルビに関係ない所に挿入された特殊文字（U+FFF9からU+FFFB）は、無視してほしい
２．
行頭の全角スペースと”「”の認識精度を上げてほしい
３．
青空文庫形式での出力時は以下の文字を置換してほしい
ルビ以外外での「《」を「［＃始め二重山括弧］」に
ルビ以外外での「》」を「［＃終わり二重山括弧］」に
縦書き未対応の記号の「≪」を「［＃始め二重山括弧］」に
縦書き未対応の記号の「≫」を「［＃終わり二重山括弧］」に
★変換したい文字は、ファイルで指定できればなお良い
４．
空行も出力してほしい
自炊小説の場合は空行も重要です
877: 名無しさん＠お腹いっぱい。 [sage] 2023/11/07(火)13:45 ID:EgBq2MV30(1)
>>873
PCOTならデスクトップは無理だがアプリ内OCR＆翻訳はいける
878: 名無しさん＠お腹いっぱい。 [] 2023/11/08(水)19:09 ID:EULq7AvV0(1)
>>0873
ソフトウェアとして配布はされていませんが
以下のリンク先の記事は参考になりませんか？
https://qiita.com/gabigabi/items/2c58eb9a500fc0b33e19
879(1): 名無しさん＠お腹いっぱい。 [] 2023/11/09(木)02:26 ID:cayyqdYs0(1)
>>0876
ルビが変なところに認識されるのは、孤立したものを除くルーチンがバグっているので直します
今、認識エンジンを再学習させているので、行頭の認識ももう少し改善する予定です
文字置換は、なにか変換テーブルを作ればいいのかしら
空行については、実は仕組み上めっちゃむずいのでちょっと考えます。
文字のブロックの座標は取れるのですが、その間隔が何行に相当するかをちゃんと
算出するのがかなりむずい。
今は、ブロックごとに空行を1行挟んで出力しています。
章番号とかも明後日に飛んでいくので、本当は間にちゃんと挟みたいのですが。
880: 名無しさん＠お腹いっぱい。 [] 2023/11/09(木)05:17 ID:HO7qvDxE0(1)
>>879
876です
回答ありがとうございます。
改善に期待しています
さて、文字の置換については
>>文字置換は、なにか変換テーブルを作ればいいのかしら
この方向でお願いします
実装して頂けるのであれば、ルビの表記の変換前に挿入して下さい
青空文庫形式の時のみの仕様ですので、他の形式には影響が
無いようにお願いします。
881(1): 名無しさん＠お腹いっぱい。 [sage] 2023/11/10(金)21:38 ID:qu/YelkG0(1)
Googleレンズみたいにリアルタイムにレシートを読み取ってくれるのがないか検索。
https://www.isp21.co.jp/solution/quickdata/
リアルタイムテキスト解析
独自のかざしOCR技術
spexperts が かざしOCR を利用
spexperts は LINEレシートを提供
でもLINEレシートは写真撮影してから解析で時間かかる。かなり正確だけど。
882: 名無しさん＠お腹いっぱい。 [] 2023/11/11(土)00:14 ID:bRi6xLZA0(1)
memo
>>881
特許6435017
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s