自炊技術総合25 @電子書籍板
レス数が950を超えています。1000を超えると書き込みができなくなります。
今画像をチェックしたら、左の写真は背景の色も白で、写真と、背景が同一化して分かりづらいので
右側の画像を見て下さい。すみません。 複数のメーカーのスキャナ使ってるし、
そうなると特定メーカー用資材はかえって使いにくいんだよね。
今のところエタノールで困ってないし。 斜行補正と用紙サイズ検知をバッチリしてくれる機種ってある?
なんで代行業者の仕上げてくるデータは見開きがズレないんやろ F1割高だしPFUのスキャナだけ使ってる人以外は純正の安心感を得られるわけでもないからなあ 業者は横装填してるからじゃね?
見開きが合わないのは縦方向の搬送ムラか来る伸びのズレだろうし。 ADFで光速でスキャンするタイプは用紙送り方向が間延びしたり縮んだりしてスキャンされる?
正方形が微妙に長方形にならない? される
fiはカラー雑誌の見開き合わせなんかも一応できたけど
コミックの見開き合わせはフラベ使った方がいい >>866
自分はコミックの場合は傾き補正OFFだな。
斜めの枠線を誤認識したりするからね。
自分は読んでて傾いていてもあまり気にならないし。
フチが黒ベタなページでも認識異常起こす事があるし。
文字本の場合はページめくった時にガクっと傾くのが気になるのでマイナス設定のサイズ認識とセットで傾き補正も入れてる。
文字のページとカラーやイラストのページはスキャン設定変えて別スキャンなので
誤認識しやすいページはどうせ棄てるスキャンだし。
カラーやイラストのページはコミックと同じような設定でスキャンしてる。
基本的にはスキャナが何を縦横の基準として認識しそうか考えて、紛らわしいものがあるページや本は傾き補正を切る。 >>868
富士通のクリーナーF1、良さそうですね、ただ、価格が・・。
>>869
やっぱり1台ですべてOKってわけではないんですね。
>>873、874
間延び、縮みは初耳です、長方形しかスキャンしたこと無いから気づきませんでした。
>>875
結構複雑なんですね、知りませんでした。ありがとうございます。 >>876
モモタロウでイソプロビルアルコールを注文しよう。
クリーナーとして最適 イソプロビルアルコールってオウム真理教事件で覚えた 【中国委託のSAY企画】「まさかスキャナーで読み取ってるとは・・・」年金機構甘いチェック 95万人以上のデータ入力ミス★2
http://asahi.5ch.net/test/read.cgi/newsplus/1521957998/
OCRってそんなもんだよね >>880
ここの住民なら名前部分のみ4800dpiでスキャンして傾き補正、白飛ばし、ダイナミックレンジの端強調、縮小(ry
とかのフォトショアクション作ってデータミス100件以下にできそう OCRなんて解像度上げれば良いってモンじゃないと思うが >>752,754-755
遅レスですがWSLでUbuntu入れて環境構築できました、CygwinとかVirtualBoxとか要らんかったんや
https://remoteroom.jp/diary/2017-10-12/
https://linuxfan.info/wsl-setup-guide
まだサンプル動かして遊んでるだけですが WSLならコマンドラインで使えるので
GUI被せるかバッチ組めばwinのお作法でD&D実行できそう
自炊PDF → 検索可能PDF はGhostscriptでの圧縮やめて
pdftoppm の代わりに pdfimages使えば画像を変質させずに透明テキストだけ被せられる気がする
https://marvelph.wordpress.com/2010/06/10/scansnap%E3%81%A7%E8%AA%AD%E3%81%BF%E5%8F%96%E3%81%A3%E3%81%9Fpdf%E3%82%92%E7%84%A1%E5%8A%A3%E5%8C%96%E3%81%A7%E7%94%BB%E5%83%8F%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AB%E5%A4%89%E6%8F%9B%E3%81%99/
ただ hocr-tools が Ubuntu + python2.7 以外の環境で上手く動作させられずにモヤっとする
VirtualBox + Xubuntu + python2 → 成功
Ubuntu on WSL + python2 → 成功
Cgywin / MSYS2 + python2 → pipでのインストールに失敗する
python2 for windows → 作成されたPDFの透明テキスト内の日本語が文字化けする
Ubuntu + python3 → 上と同様 何言ってるか分かんねぇ
自炊にそこまで情熱捧げてんのか 趣味の一環と考えれば「追求型」の人がいてもおかしくないでしょ。
自分も今までつぎ込んだ機材や手間を考えたら、
自炊に興味ない人から見たら異常だろうと思われるだろうし。 すまん
ここは元々取りっぱなし派補正派zip派PDF派入り乱れてるから
わかってる人興味のある人に伝わればいいかなと
既存のOCR製品やスキャナ付属のソフトでのPDF作成に不満しかなかった身からしたら
googleのOCR性能で補正済み画像からPDF作れるなら「そこまで」の価値はあった
副次的効果として今までずっと隣の芝生だった分からない世界が
Windows Subsystem for Linuxであっさり自分ちの庭と繋がったというのも大きい 大学生です
自炊してocr処理したpdfの教科書を
onenoteに入れようと思っています
onenoteなら本文を横断検索できそうだからです
どう思いますか 自炊書籍を見たり読んだりするのに最適なソフトやアプリ、ハードってどんな組み合わせだろ? そんなの何を読むかによって変わるだろ
12インチのiPadが最適という人もいればkobominiを愛用する人もいる >>891
それぞれ、環境別のベストバイみたいな物があれば・・・
PCで使ってるけどビューアーって言うほど洗練された物がない気がする >>892
デスクトップならマンガミーヤ
タブレットやタッチ画面で操作するならストアのPicoViewerを推しておく >>889
ファイルとして添付するとOneNoteから直接PDFの中身の検索はできない
印刷イメージとして挿入するとPDF内のOCR情報は失われる
後者についてはOneNote内臓のOCR機能で新たに検索用テキストが作られるけど
>自 炊 し て ocr 処 理 し た pdf の 教 科 書 を
みたいな感じで日本語は1文字ごとにスペースが入るので検索ではほぼ使いものにならない
横断検索だと
・EverNoteに張り付けておく
・Googleドライブに放り込んどいて必要なときにブラウザから検索かける
・ローカルにPDFのまま保管しておいてDocFetcherのようなPDF対応のGrepソフト使う
あたりが実用的じゃないかな 同じく。WindowsタブレットならPicoviewer一択だな。
アンドロイドのPerfectviewerより機能的に上の部分が多いし。
自炊してる人なら買って損なしだと思う。 >>884
Pythonスクリプトが見にくかったので、シェルとPHPにしてみた。
シェルでcurlコマンドでGCVにOCR処理を投げて、自作のPHPでjsonをhocrファイルに変換、最後にgostscriotでPDFに変換って感じ。
WSLで使うのは考えたことなかった。
Unbuntsは苦手なのでFedoraが出たら試してみる。 すごいなあリナックスで自炊とかマゾとしか思えん
なぜそんな険しい道をゆくのか
すごいなあすごいなあ 趣味嗜好なんて他人に理解できなくて当然だろ
自分も酒やたばこをうまいと思ってる奴らの嗜好が理解できん >>899
険しくてもやるだけの価値があるから?OCRができたら便利じゃん。それも出来るだけ精度が高ければ。 >>898
よろしければ差支えない範囲でコード見せていただけないでしょうか、特に
>最後にgostscriotでPDFに変換
のあたり
自分もhocrファイル作成までは何とかわかるんですが
hocr→pdf の部分がhocr-toolsでpython依存になってしまうんですよね
ここのやり方理解できてうまいことwin用バイナリ組み合わせられれば
linuxに下りなくてもできそうな気がしてるんですが >>902
ごめん、そこ説明抜けてた、hocr-pdfでhocrからpdfに変換してます。 >>896
PDFviewer by PSPDFkit
Apple Pencilで書き込みながら使える >>903
そうでしたか了解です、無理言ってすみませんでした。
ググってて hocr2pdf というのも出てきたけど透明テキストじゃなくてテキストに置き換えるっぽい?
とりあえずhocr-pdfの代替には無理みたい
調べる過程でtesseract-ocr ってフリーのOCRツールを知ったんですが
これ、素のtesseractのWindows用バイナリ(ver4α)だと残念な感じだったのに
フロントエンド被せてある VietOCR がGoogleさんもびっくりな認識率で驚いた
カスタマイズで相当辞書を鍛えてるっぽい?
https://i.imgur.com/tj1ARCW.png
tesseract.exeでは1ページずつだけどOCRからPDF出力までできるのでVietOCR同梱のほうで
tesseract.exe -l jpn hoge.jpg hoge pdf
バッチ組んであとでgsとかで纏めればローカル環境だけでそこそこ精度のPDFが作れてしまう予感 >>905
PDFviewerって高速でページめくると落ちやすくない? >>894
ありがとうございます
onenote駄目でした
DocFetcher使ってみます >906
すげえな、まじかよコレ。
当方、もうずっと以前からxubuntu16.04上でtesseract-ocr4.00alfaを使って、
スキャンした小説のテキスト化をやっているが、最近やっとそれなりの認識結果の
テキストファイルを吐き出せるようになったというのに、これはかなわない。
本来ベトナム語用OCRソフトだったVietOCRも、以前に一度使ったことがあったけど
認識結果はとくに変わらなかったから素のtesseract-ocrでずっと使ってきたけど、
ここまで向上できるものなのか? 桁違いの認識精度だな。とくにtesseract-ocr
のくせに余計な半角スペースが全然挟まってないのが素晴らしい。
ちょっとVietOCRインストールしてくるわ。 MSのブラウザでも音声読み上げが搭載されとるし
OSに内蔵されてゆくんだろうな CANNONのWIAドライバって不便でしょうがないな
Windows10 ×64で更新したせいか
BTscanのソース選択からTWAINドライバが項目から消えて、
TWAINドライバから起動する ScanGearを呼び出せないわ
ずいぶん前からほうっておいてる
ファイヤーウォールのせいだろうが、
サイトの設定項目の説明が残念ながらどこも古くてわからんちん 909
うーむ、昨夜喜び勇んでVietOCRをxubuntu16.04にインストールした>>909だが、
残念ながら思わしい結果にはならなかった。
>>906が上げてくれた画像の左半分をサンプルにして、同じようにVietOCR5.0alfa
でOCRかけてみたが、↓こんな感じに一文字ごとに半角スペース入りまくりで(後半カット)
----------------------
光 学 文 字 認 識
光 挙 文 字 部 橿 に う が く も じ に ん し き 、Oplilldaricer ricognidom は 、
ス キ ナ ー で HR り 込 ま れ る ) を コ ン ピ ュ ー タ が 鎖 集 で き る 形 弐
ー 舩 に OCR と 賊 記 さ れ る .OCR は 人 工 知 背 や マ シ ン ピ ジ ョ ン の
----------------------
----------------------
光学文字認識
峙文零鵬(こうがくちじ仁んしき 0璽囁由・ 血「加艶「 峡皿踵柑皿 は 活字の文書の幟
ス圭ヱナーで取り込まれる)をコンピユータが編集できる形式(茎臺コー建の列)に蛮換すろ
一般に 0C翼 と略記される”OC翼 (ま Jや咄の研究分野として始まっア髑研究は統けられ
----------------------
素のtesseract-OCRだと↑こんな感じで、同じOCRエンジンでもかなり異なる間違え方を
しているから、Windows版程正解率が高くなくても手駒が増えるのなら悪くなかったんだけど、
残念ながらいつも使ってる300dpiの縦書き小説スキャンtiff画像を読ませると、文字コード
間違えてんのか? ってくらい謎の文字列になってしまう。オプションで縦書き指定にしても
ダメ。残念ながら使用に耐えない。
Windows版と何が違うんだろうね。 Google Cloud VisionのOCRの精度すごいな。
本1冊分だとちょっと時間かかるけど 傾き補正や見開き上下ズレの解消を考えたら、
やっぱり黒背景で読み取りできる高級機の方がよさそうだなぁ
おすすめのスキャナある? 予算次第でしょ
ちなみにうちの中古で買った業務機さんはときどきでっかいブロックノイズが出る困ったちゃんだ 予算と中古OKかどうかでかなり分かれるんじゃないかな。 黒背景は裏写り対策であって傾きや見開き上下ズレは直接関係ないと思う
見開きに関しては高価な業務機のほうが伸び縮みしにくいというのはあるけど
傾きは印刷が紙とずれてる場合 紙端基準での傾き補正では対応できないし
あと紙端に除去しきれなかった黒縁残るし断ち切り黒原稿は自動サイズ自体失敗するから
自力で手動トリミングする覚悟じゃないと使いこなすの難しい
白背景の家庭用機より画質はきれいだけどね ただ黒背景は漫画の回想シーンのような地色が黒のページでサイズのページで誤認識を起こすのが欠点。 見開きズレ対策は横装填する為=A3対応機ってことじゃないかな
機種にもよるだろうけど傾き補正にもたぶん使われてる。
文字列の角度と紙端の角度のちょうど中間みたいな角度に補正されることがあるし、
うちのスキャナは傾き補正入れると黒背景になるわ。
だからうちでは文字主体の原稿の場合はアンダースキャンさせて紙端を傾きの基準にさせないようにしてる。
コミックなんかだとコマ枠で誤認識しちゃうのでそもそも傾き補正はOFFだし、
うちでは黒ベタは背景の黒から浮かせた黒にしてスキャンしてるわ。 見開きが多い漫画の自炊は頭が痛い
どうしようかプランを立ててから
単行本サイズだと横装填でいいけど、愛蔵版サイズだと横にスキャンできない
と言ってもむちゃくちゃ伸び縮みするかというとそうでもない
ただ上下の高さがずれて左右ページの高さを合わせるのが大変
見開きノウハウがあれば教えて欲しい なんとかなったわ
自分用にメモ
BTScanを管理者として実行
ソースにTWAINも無事表示された。
さっきまで受信の規則やらなんたらをいじって諦めていたので、
簡単すぎてちと笑った。
もう少しでVueScan買うところだった オレはA5の本を横装填しても上下ズレが生じるよ
なんかScanするときの設定が悪いのかな
ちなみにEpsonのDS570W DR-M260買うのと、
中古の業務用買うの、どっちが幸せになれるかな。
コンピュータ系技術書6割
カラーのコンピュータ系雑誌3割
漫画単行本1割
ぐらいな割合で。 見開きは素直にフラベ使った方が楽な印象
>>921
有用な情報thx
BTScan使えるのかありがたい
家族が持ってる900F借りたときにハマったのでこういうレポは助かる 横装填するのはズレ防止じゃなくて連結辺の間延び防止じゃね? >>912
>906のサンプル画像はこちらのを借りてます
https://github.com/dinosauria123/gcv2hocr/blob/master/sample/jpn/jptest2.jpg
WSLに入れて試してみたけど、よく見たら同梱はwin用exeのみっぽい?
公式ページのInstallationには Linuxでは別途 tesseract本体とベトナム言語データ入れろって書いてあるね
win用の同梱版はexeも言語データも素のものとはサイズ違い過ぎて謎
それぞれtraineddataを交換するとエラー吐いて止まる
https://i.imgur.com/2gApWiM.png
なおこのαカスタムTesse4.0は 縦書き対応してない模様
ちなみに 下のViet4.7.1 by Tesse3.0.5 (αじゃない最新版)は 公式と同一の言語データだった
https://i.imgur.com/LqXRr5s.png Gimpで画像を90度変えて画質100で出力しただけなのにファイルサイズが2倍になったんだけどなんで?
ただ単に画像を90度変えたいだけなのに 設定100で再圧縮したらそりゃ容量増えるだろ
回転だけしたいなら無劣化回転を謳うツール使え 品質100で2倍で収まるならむしろ少ないほうだろう
白黒君はいい加減 不可逆圧縮がどういうものかくらいは理解したほうがいいと思う 横スキャンと縦スキャンでOCRの精度って変わるの? それは付属ソフトでスキャンと同時にPDF化するって意味?
ならおまけソフトで精度を気にしても仕方ないよ 予算6マンぐらいで業務用スキャナ買いたいんだけど、
オススメとか鉄板ってあるの? >>926
自己レス
Viet5αのメニューから取得した言語データはここのtessdata_fastのjpn.traineddataと同じものだった(compで確認)
https://github.com/tesseract-ocr/tesseract/wiki/Data-Files
tessdata_fastのページの下のほうに書かれてるけど縦書き用は言語データが分かれてた
jpn_vertmをダウンロードしたら一応行けたけど縦はまだ未チューニングで従来と精度変わらないぽい
https://i.imgur.com/Jg5KqkK.png
コマンドラインからは jpn+jpn_vert で辞書切り替えなしで縦横両方いけた
時間むっちゃかかるけど
-- cmd_ocr.bat (tesseract-ocrフォルダに配置) ---
@echo off
set TESSDATA_PREFIX=%~dp0
"%~dp0tesseract.exe" -l jpn+jpn_vert %1 %~n1 %2
----------------------------------------- もしかして白黒でも1800~2400dpiなら写真集でもすっげー綺麗にスキャンできるの?
今iX500の白黒1200dpiでスキャンしてまぁまぁ不満無くまぁまぁ妥協出来るいい感じに取れてるんだが。
すっげー綺麗って言う表現だけだと大ざっぱすぎるけど
言ってみたら高画質フルカラーから色だけを抜いた みたいな? まずは印刷による表現の仕組みを勉強した方が良いよ
仕組みもわからずに表面だけの返答を得ても、
その手段で正解かどうかは当人の基準に掛かっているから最終的には自分で答えを出すことになる。
グレスケと2値の件で体感したでしょ。
印刷は基本的に極小の点で表現される。
印刷の仕様にって点の細かさは様々であり、
カタログや写真集などのカラーの高精細印刷では400線などの精細度がある。
線数というのは印刷の精細度の単位であり、dpiに直すとその2倍に相当すると言われる。
つまり300線なら600dpi。この精細度で印刷原稿と同等。
さらに印刷の点とスキャン画素の完全一致は不可能なので、印刷よりも細かいスキャン解像度が必要になる。
これが下回るとモアレになる。
カラーの2値化をきれいにするのはdpiの問題ではない。
高dpiが必要なのは確かだが、カラー写真印刷を微細な色インクの点で表現しているように
2値の点の集密で表現することは可能だが、
単純に高解像度でスキャンすればOKとかいう話ではなく
印刷インク色の点を、黒の点の集密にどう変換するかのアルゴリズムが影響する。
そんな処理をスキャナ内蔵のプロセッサー、しかも廉価機の予算で搭載されたプロセッサーに任せるのは
画質へのこだわりを放棄しているようなもの。
カラースキャンして演算力有り余るPCで変換するのが最も近道だと思うよ。
もしくは高性能な画像処理プロセッサー搭載をアピールしてる業務機を使うか。それで納得できるかは知らんけど。 >>936
いってることの30%ぐらい理解出来た
原理部分の事言ってるみたいだけど、そんな事言われてもなんの改善策もおもいつかんわ
結局は良いソフト・ハード買えって言ってるようなもんやん
Ralphaは使ったけどトーンカーブ一々毎回いじるの面倒だし、作業工程増えるし、ファイルサイズ増えるし、その割にそこまでよくなるわけじゃないし
そもそも俺まだ本が300冊以上残ってるから1冊1冊に時間なんてとても掛けられないし
汎用的手法で流れ作業のようにやっていきたいし だから拘りと妥協のポイントを各自で見つかるしかない
自炊とはそのポイントを見つけることが全てと言ってもいいくらいだ。
拘りたいのなら金や手間をかけろ。
掛けられないなら妥協しろ。
そういうもんだ ならできないことは諦めて我が道を貫くしかなかろ
人に助言など求めずに
そもそも人のアドバイス聞く気がないのに何故他人に助言を求めるのか
答えてる人説明するだけ無駄にされてでほんと可哀想 IDなしはNGにしとけ
詳しくはこのスレのレス100あたりから読めばわかる だ〜〜〜か〜〜〜〜ら〜〜〜
アドバイスが抽象的すぎるんだよ
自分が説明した気になって満足するだけじゃダメなんだよ
俺が欲しいのは、>>935の 中 の画像の文字と 右 の画像の写真を合わせたような仕上がり
そのための具体的アドバイスが欲しいの
>>936の原理みたいな事言って自己満足に浸られても俺の願望は叶わない 写真屋とまでいかずともRalphaやレベル補正も面倒となるとこれはこの3枚の中で妥協する以外仕方がないと思うぞ
今までは600dpiカラー補正無しスキャンを原本に技術の構築されてきたからその方向でなら改善の可能性はあるかもしれないが
グレスケかつお手軽にとなるとこの時点で終了かと
後は手間をかけるかどうかの判断だな
一応可能性としては、neatimageを使って写真部分のノイズを減らしつつシャープ効果で文字をくっきりさせることが出来るかもしれんが
neatはプロファイル設定さえできればあとはソフト任せでいけるので1手間増やすだけ
プロファイル設定を作るのが面倒だが生臭でいくならソフト自身にオートで作らせるかデフォルト使ってシャープ効果強めるだけで妥協 手間も金も頭もかけられないのなら諦めろといってるだろ。 >>943
ありゃりゃなんの参考にもならんお前のレスを自己満足に浸ってるって言われてキレちゃったかww ありゃりゃ
このすれって>>946こいつみたいな何の根拠も無い程度の低い悪口言ってる小学生居たんだ
このスレって割と会話の成り立つ奴が多いだけにお前みたいな奴の存在って意外だな 右がいいわな
ディスプレイ買い替えたらまた違うのかもしれない >>938
部屋を広くしたいのがスタート地点だから
自分の場合は仕上がりはあきらめた!
スピード第一 アマゾンで中古価格が1円の書籍を手間暇掛けて電子化してる時ってちょっと悲しくなる時あるよな そろそろ次スレだし 対白黒君用のテンプレ纏めといたほうがいいな
ワッチョイはこのままなしでいいんだっけ? アレですぐ分かるけど、擬装しほうだからワッチョイ付けてもいいかも すみません、この画像の原因が分かる人いらっしゃいますか? DRC225Wです
→ http://imgur.com/jRGTszb わりといきなり出ました、何回やってもでます。
このエラーが出る前、いつも、4枚くらいずつスキャンしてるのですが、ほぼ毎回、紙詰まりエラー
がでたり、この直前くらいに、左半分は、裏写り防止をしてるみたいに白っぽくなり、右半分は
普通だったりと、意味不明なことがおこってました。 センサー系のトラブルかな? 頻発の時点で修理依頼だが、一応ドライバ入れ直して様子見 よく「修理するぐらいなら買い直した方が長い目で見れば安い」って聞くけど >>932
あんまり期待しないほうがいいなとは思う
いたれりつくせりではないから
うちのはオートクロップがアホの子だったので、
サイズを定規で測り、最初にミリで入力しておく癖がついた
結果、気持ちよく揃うようになった
業務機ならではだなあって思う >>933
VietOCR-5α用の縦書きモジュールjpn_vert.traineddataの検証、サンクス。
tessdata_fastとか、英語のソースから見つけ出せるってすごいな。
早速xubuntu16.04上のVietOCR-5αでjpn_vert.traineddataを試してみた
ところ、横書き用のとは共存できないのか、リネームしてjpn.traineddataの
ふりをさせることで、半角スペースまみれとはいえ、縦書きの画像から見事
それなりの認識結果が得られた。
正直、正解率からいえばblacklistでNG文字を設定し、jpn.unicharambigs
を改造して後処理パターンを修正したjpn.traineddataを使用した現行環境
の方がややマシだった。
とはいえ選択肢が増えるのは良いことなので、メニュー→コマンド→一括OCR
でフォルダ内のtiff画像200件超えを連続処理させてみたところ、相変わらず
020.tif辺りから開始して、最後まで行ってから001.tifに戻ってOCRする
謎行動だったが、何故かjpn_vert.traineddataではない方を使った時と同じ、
日本語になっていない認識結果が得られた(泣)
認識後の後処理に正規表現を使ったリストが使えるらしいのは魅力だが、
残念ながらLinux上ではまだVietOCR-5αは使えないようだ。
あと素のtesseract-ocr4.00αにjpn_vert.traineddataを食わせてみたが、
リネームしようが、jpn+jpn_vertに指定しようが、エラーになって使えなかった。 >>953
ワッチョイありがいいのならIP表示までやった方がいいよ 5chに金払ってID消してるやつはIPもワッチョイも消せるから無駄だよ 消してる奴は避けるという目印にはなるけどね。
IDだけでもできるけど >>961
それは書き込む人が激減するから絶対反対 しかし業務機のフルカラー300dpiは爆走だなあ
満足できるかはまた別として レス数が950を超えています。1000を超えると書き込みができなくなります。