自炊技術総合25 @電子書籍板
レス数が950を超えています。1000を超えると書き込みができなくなります。
同じく。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は爆走だなあ
満足できるかはまた別として 自炊愛好家オフ会って無いん?w
お互いの自炊を自慢し合うみたいなwww そのまま交換会に発展しそうで危ないからやってたとしても表には出てこないだろ >>960
ubuntuにも入れてみたけど最新ソースからビルドで行けたよ
英語はchromeの自動翻訳まかせ これなかったら今更linuxデビューなんて絶対できんかったわ
まあスレも残り少ないしいい加減うざがられそうなので続きはOCRスレの方で
【文字認識】OCRソフト【 自炊 】 [無断転載禁止]©2ch.net
http://egg.5ch.net/test/read.cgi/software/1470745451/
あと>884 自己解決したので誰も興味ないだろうけど報告だけ
hocr-pdfの日本語文字化けは標準出力由来だった
ファイル出力に対応したfork版と差し替えで解決 https://github.com/zvezdochiot/hocr-tools.git いま、Kobo H2Oを使ってるんだけど、
電子化するか迷ってるA5サイズのマンガを寝る前に久しぶりに読んだから、
紙媒体の本が目も疲れないしページも自由に前後できるし本が楽しくて仕方なかった。
今の状態で電子化すると本を読む楽しさが劣化してしまう気がしてきた。
優秀なリーダーなら解決できるだろうか?
もし、お薦めのリーダーがあれば教えて欲しい。 紙本で読むことに価値を感じてるならスキャンなんてしないほういいんじゃね? >>970
了解
つか、その板のレス番4〜29まで長々と籠城してたの、オレ。
Linux+tesseract-ocrネタでバレバレだろうけど。 >>972
大引と束を追加して頑張ってたけど部屋にもう本を置く場所がない
それに地震が起きて本が分銅みたいになって揺れると家そのものが危険になりそうだから重量を減らそうと頑張ってる
ただ、最近紙で読むと楽しさが倍増したから、良いリーダーを買えば同じ楽しさが再現できるのではないかと思って質問した感じ
テキスト読むならどれでも同じような感じだけど、マンガと小説では感じ方が結構違う
大きい画面がいいかも とりあえず、手持ちの本を全部電子化。
でも紙で読むのがすきだから、
よみたい本の読みたい部分だけをプリントして、
よみ終わったら破棄する 自分なら読む本はそのまま残して、今後いつか読むだろうけど
今は捨てられない本は自炊する。 すみません、先輩方にお聞きしたのですが、予算7万くらい、なるべく中古なしで
キャノン以外でおすすめのドキュメントスキャナーありますか?
DR125、225Wと使ってきましたが、まともに斜め補正が機能しなくて
キャノンは糞だと思いました。
最低限、まっすぐ読み取る(補正する)やつがほしいです。縦線ノイズは
この分野の宿命だと諦めます。 >>977
DS-570W持ってるけどダメだなぁ
やっぱり黒背景じゃないと厳しそう 自動傾き補正は
コミック
→枠線を基準と誤認するので本質的に難しい
文字本
→文字列のみを基準としてくれればそこそこうまくいくが、
紙端も基準にされると印刷の傾き(文字列)と影響しあって失敗する
ページ全域のイラストや写真
→紙端基準にするしかないが、黒背景の方が確実に紙端を認識できる。
こんな感じでどこも一緒じゃないかな?
自分はコミック中心だからかもしれないが、
搬送の安定した中型以上の業務機で傾き補正OFFってのが、
傾きが少なく安定したスキャンを目指した自分の今の結論。
うちでは原稿サイズ+2mmでスキャンしてるが、紙端がスキャン範囲外に出ることはほとんどない。
+1mmだとたまにはみ出る ピックアップの時に傾いたまま斜めに入っていくんじゃないかなとおもうのいで、
斜行対策として自分は原稿ガイドまわりに手をかけてる。だと思う。
小口研磨された本とか裁断に失敗して裁断面が荒れた原稿の場合に斜行しやすいんだけど、
裁断面と反対側に軽い重しを置いて軽く抵抗掛けたり、
紙が薄い原稿の場合は原稿ガイドと干渉して浮き上がったりする場合にも
やっぱり重しを置いて浮き上がりを抑制したりしている。
原稿ガイドに引っかけて吸い込まれないような形にアクリル板を切っただけの重しだけどね。
自分のこの手間は後工程で角度補正はしたくないっていう方針から来てるが、
角度補正が許容できるのならスキャンの時の補正には期待しないのが楽でいいんじゃないかな? 傾き補正に上限設定がないのが前から不思議だ
45度とか90度とかそこまで曲がって吸い込まれるわけなかろうに
3度以上の傾きは検出しても無視するとかにできればいいのに ix500だと補正オフでも
紙を斜めに入れてもちゃんと補正されるので
適当に放り込むだけでいい
補正オンだと追加でランダムで90度回転する機能だから気が抜けない >>982
サイズ混載とかで適当に放り込んだ原稿に対応するようになってるんだろうけど、
リミット制限が有ればだいぶ使いやすいとは自分も思う。
紙端を認識したうえでそこから5度以上は無視するとかやってくれないかね。
スキャン影の塗りつぶし補正機能が有る以上は紙端の認識はできてるはずだから、
その内側から基準を探すだけで行けると思うんだけど。
>>983
それは傾き補正じゃなくて原稿の向き補正の機能では? レスありがとうございます。
まっすぐ読み取るのって意外と?難しいんですね。素人目に見て、例えば真っ白の原稿
でも、一応は白い原稿をスキャンできてるわけで、その上辺、下辺を平行にすれば、
横は裁断の程度で少し隙間が空くけども真っ直ぐスキャンでき、画像の枠線うんぬんは
関係無くできそうですけどねぇ‥、研磨された中古本はわからないが。
キャノンはホントひどかったですよ、たった1枚の週間漫画のカラー、ぱっと見、まっすぐなのに
斜めのスキャン結果が連発、補正切ったらまっすぐと、意味不明でした。
それと、表はまっすぐ、裏ななめ、とかもね。
ix500のアマゾンレビューだと、斜めるレビューが1個くらいしかなかったけども
S1500→ix500 がだいたい6年位。待って、より良くなったのを買おうかな? fiの中古のどれ買ったら良いのか分かんね
黒背景ってのに対応してるのがいいの? ドキュメントスキャナという用途を考えると
原稿紙端を基準にスキャンする場合と印刷を基準にスキャンする場合の両方を考える必要があるからね。
だから印刷内容から基準を探してこようとする。
コミックのようにワク線や斜めの文字列を見つけるとそれに合わせようとしたり、
角度の違う複数の基準らしきものから基準を作り出して合わせてきたりもする。
変な角度に回転させられた場合は何を基準にされたのか確認してみると良いよ。
その機種の補正のクセみたいなのがわかってくれば使い分けもしやすくなって、
不本意な角度補正に遭遇する率が下がるし。
大抵の人はコミックでは角度補正と原稿サイズ認識はOFFって所に到達すると思うけどね。 ちなみにスキャナの評価として斜めと言われるのは原稿を斜めにスキャン搬送してしまう『斜行』を指すのが一般的。
スキャン画像を補正機能で間違った斜めにされてしまう症状は、
本来の機能目的である文字列の認識と文字列基準の角度補正が出来ていれば
原稿が悪いという評価が多いんじゃないかな。 斜め補正はスキャン時OFFでえちる使うからあんま意識してないが
キヤノン機は斜行しやすい印象はあるな
ラウンドスキャンの125、225Wならなおさらだろうとは思う
>>984
scansnapは傾き&原稿の向き補正でひとつのオプション
どっちか片っぽだけ有効にはできなかったはず サイズ自動判別だと傾き補正が常に実行されるってことだけど、
サイズ自動判別をOFFにすれば読み取りモードオプションの文字列の傾きを自動的に補正するって機能が整除できるようになるんじゃないん?
初めて知ったけど傾き補正って5度までって制限がついてたんだね。 PFUのPaperStream IPって癖が強くてちょっと初心者の自分には難しいねー
クロッピングや傾き補正を使用すると
おせっかい機能で背景色や黒で画像の中まで塗りつぶされてしまう
だから使用しない設定つくっておかないといかんね
これ各モデル共通の仕様で普通? レス数が950を超えています。1000を超えると書き込みができなくなります。