http://mimizun.com/log/2ch/download/1117027378/

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
自炊：とりあえずこれだけやっとけば激しく地雷にはならないであろうテンプレ１／２
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

●スキャン技術･解体編
解体した方がスキャンしやすい。
ペーパータオルを背にあててアイロンで糊を溶かし、むしる。／レンジで1分暖めて、むしる。(火傷に注意)／カッター等でけずる。

●スキャン技術･スキャン編
「dpi（=dot per inch）」　※自分のスキャナの取りこみ速度／忍耐と相談して決定
この値が高いほうが高精細。300dpiか600dpiが一般的。360dpi以上は意味がないとの意見も。
「カラー／グレースケール」　※自分のスキャナの取りこみ速度／忍耐と相談して決定
通常、カラーでスキャンして後でグレースケール化した方が良い。
「BMP／PNG／JPEG」　※自分のスキャナの取りこみ速度／忍耐と相談して決定
カラーでスキャンする場合は「高画質の」JPEGでも良いと言われている。（グレスケ加工したら差がほとんど出ないため）
「裏写り防止TIPS」
フラットベッドスキャナ専用だが、裏に黒い紙（半透明の黒いアクリル板でも可)を敷く事で裏写りを防止できる。
「ScanSnap用TIPS」
1枚づつ手差しで差し込む。1枚スキャンしてる最中に次のをセットしておくだけ。
これならダブルフィードや斜め読み込みはまず起こらない上に読み込み位置が一定してトリミングが簡単にできる。
EOXからEOX3までハードは一緒なので3代目のドライバをいれれば最新型と同等の機能になる

●スキャン技術･加工編1 - 必須
「トリミング」
トリミングする事で読みやすさが格段に変わる。
範囲選択→切り抜き。バッチに登録するならメニュー項目の追加で「選択範囲を変形」を入れておくとずれた奴にも対応出来る。
「グレースケール化」
チャンネルミキサーを使用。モノクロにチェックを入れレッド100%、グリーン0%、ブルー0%で実行。
なお、藤-resizer-で白黒化法を「2」にして使用しても、同様の処理ができる。
「縮小」
藤-resizer-を使用。
複数のソフトを使うのが面倒なら写真屋でまとめてバッチ処理してもそこそこのクォリティは保てる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
自炊：とりあえずこれだけやっとけば激しく地雷にはならないであろうテンプレ２／２
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
●スキャン技術･加工編2 - お好み
「トーンカーブ／レベル補正／コントラスト」
白を飛ばして黒を強調。強さは好みで、ただしやりすぎるとモアレが出たり薄いトーンが消えるので注意。
「ノイズ除去／ぼかし」
ノイズ除去は強くかけると元の画像から大きく変質することがあるので要注意。
高dpiでスキャンした画像なら軽くぼかしをかける事で簡易のノイズ除去が出来る。
ぼかしはモアレ対策になる。
「角度調整」
角度調整するとぼける事がある。
定規ツールでまっすぐにしたい場所(枠線など)に沿って線を引きその後角度調整をするとその場所が直角になるように角度が入力される。
「アンシャープマスク」
お好みで。
アンシャープマスク以外は「縮小前」に全部済ませる。
アンシャープマスクは「縮小後」
以上の加工は画質に対する趣味の問題であるので好きなように組み合わせる。

●スキャン技術･保存編
･JPEGは確かに不可逆圧縮だがそこにこだわりすぎるとサイズがでかくなるだけ。
･ノーマル/最適化/プログレッシブの違いは主にサイズ。プログレッシブだと見れない人もいるらしいが普通は大丈夫。
･グレースケール画像をjpgを出力するときは白黒もしくはグレースケールオプションをオンに。
　サイズ的には変わりないがjpgのロードが早くなるグレスケjpgになる。
　写真屋以外でそのオプションがなければグレスケjpgは出力できない
　グレスケ画像は256色の白黒画像、グレスケjpgは256色までの白黒パレットの画像なので別物
･16色PNGならJPEG並のほどよいサイズに収まるが、256色→16色の情報劣化。
･256色のPNGは結構サイズでかい。
･スキャン後、リサイズ連番するときは、
カバー表→カバー折り返し表側→カバー裏→カバー折り返し裏側→表紙表→(表紙背中)→表紙裏→本編〜
の順番でノンブルにあわせて連番すればスキャン忘れ、ダブりが防げる。
･奥付、他の作家･作品の広告ページから読める情報もある。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
スキャン時間TIPS：スキャンボタンを押してから 棒グラフのウインドウが消えるまで
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

●モアレ防止オフ　　　　　　●モアレ防止オン

8300UF
24bit 300dpi A4 : 13s　　　24bit 300dpi A4 : 33s
24bit 600dpi A4 : 41s　　　24bit 600dpi A4 : 92s

GT8400U
24bit 300dpi A4 : 18s　　　24bit 300dpi A4 : 18s
24bit 600dpi A4 : 62s　　　24bit 600dpi A4 : 96s

GT7400U
24bit 300dpi A4 : 18s　　　24bit 300dpi A4 : 65s
24bit 600dpi A4 : 66s　　　24bit 600dpi A4 : 65s

GT-F500
24bit 300dpi A4 : 14.5s　　24bit 300dpi A4 : 30s
24bit 600dpi A4 : 30s　　　24bit 600dpi A4 : 30s

GT-F600
24bit 300dpi A4 : 18s　　　24bit 300dpi A4 : 33s
24bit 600dpi A4 : 36s　　　24bit 600dpi A4 : 36s

※UBS2.0使用時。速度(転送時間等)はPCの能力に影響されます。

　 ████　　　 ∫
＿████＿　∫
.ξ ´┏┓｀）─・

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>1
乙

>1
otu

細かいことを言うならやはり980まで待った方が良かったかと。

>1乙
見開き半分子ちゃんはそのうちログに移すのでファイル直リンでいいですよん
ほんとはログのほうにComicRCがあるんでそっちのほうを紹介してほしかったりしますが

>>7
独断でおかしなテンプレを追加しないで下さい

ageとかないと即死しそう

>1
ﾓﾂｶﾚ〜

(　 ﾟДﾟ)⊃旦

（　´∀｀）つt[]

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

前ｽﾚの無効領域対策の話だが、
どうせ傾き補整するんだからｽｷｬﾅの中央に紙を寄せることだけ注意して
傾きの発生は気にしないという自分は邪道でありますでしょうか？
原画集やVFBみたいなでかい本や大判のコミック2P同時取り込みしようとか
じゃなけりゃわずか数ミリの無効領域に神経質になる必要ないと思うんだが
紙の外形でトリミングするなら取り込みの精度に執着するのも理由あるけど、
みんな枠線基準で傾き補整+トリミングしてるんでしょ？

即死回避〜

>>17
そうだけど
置き位置を簡単に決めれるとプレビューの手間が省けるからだと思う
あと端にすればスキャンの時間も短くなるから冊数が増えると
その時間だけでもかなり時間が変わってくる

漏れ500F使ってるけど、直に板にサインペンで5mm枠線描いてるよ
どうせもうすぐ8400買おうと思ってるし（←邪道

>>19
プレビューしないとなると、蓋をアクリル板にした場合、結局端っこまでスキャンしちゃわないか？

>>21
8400だと一枚目でプレビューとって選択範囲決めとけば
あとはガイドに沿って置けばずれないからずっとその選択範囲でスキャンするよ
スキャンする時は蓋は外してアクリル板で重し＆裏写り防止

まぁ、蓋じゃガイドして無くても初めから紙浮くしね

今週、気合いれて炊いてみたが
どうやっても3日に1冊しか出来ん・・。
4ｺﾏや断ち切りが少ない漫画なら、
なんとか3日で2冊出来そうなんだが、
最近の漫画はそんなの少ないし見開きまで出てきたら週1冊くらいに。

単純に1週間に2冊として年間約100冊。
なかなか減らんね。

>>23
同意。
自炊のテクが上がってからかえって時間かかるようになった
細かい修正しなきゃ気が済まないから、なかなか終わらん
仕事もあるし、自炊のための時間が取れないからデジタル化が一向に進まない
炊きたいものは山のようにあるのに・・・

Scansnapも持ってるけど、やっつけ仕事で出来たものが不満だらけだったから小説
自炊専用になった
フラットベッドの高画質スキャンに慣れると低画質には戻れないなあ

>23
漏れなんか、"これ炊こう"と思ってﾌﾞｸｵﾌで買ってきた本が増えて
部屋圧迫してきてるぞw
炊ける本なんてせいぜい月2〜3冊なのに、
買ってくる本両手両足じゃきかなかったり・・・・・・

嗚呼、本末転倒･･･
もう持ってる本、自炊用とかいってもう一冊買っちゃったりしてるしな･･･
どうせみんな￥105だから金額的にはたいしたことないんだが、
逆にそれが状況を悪化させてるような･･･

ttp://www.forest.impress.co.jp/article/2005/01/24/sharaku.html
前スレで紹介してもらったコレ、結構使いやすいよ。
トーンカーブもちゃんとあるし、フリーだし。
これとECを併用すればフリーでもどうにかなるかも知れない。

素直に写真屋落として使えば良いじゃん
どうせやってる事は違法なんだし

個人で楽しもうが実本持ってようが違法だし

近所のコンビニ行くのにベンツなんかいらね。チャリでいい。

炊いたものをネットワーク上へ違法に流したりなどしない。

…という建前くらいは取り繕わないか？
実際に流してる奴でも、このスレではさ。
ここ見てるのは、多分この板の人間ばかりじゃないんだから。

ﾀﾞｳｿに来てるの時点で取り繕ってもね
ネットワークに流さなくても関係なく違法だし

トーンカーブ・レベル補正+バッチ処理が使えるフリーソフトってないんだよね
上のソフトもバッチ処理がないのが惜しい
D＆Dタイプの藤とかは処理後の画像の変化をたしかめるのがめんどくさいのと
グラフなどで直感的にいじれない

>>30
＞ネットワークに流さなくても関係なく違法だし

おまえ凶徒腐警のいうこと丸呑みするタイプだろ

違法だよ

「捕まらない」≠「違法じゃない」わけで

出版社に聞いてみろ
違法だけど「現時点」ではコストかけて対応しても効果的な手は無いから
って事だから

>32
なんで炊いただけで違法なんだ？
どういう理由で違法なのか説明してみろ

>31
マンガミーヤあるよ。
グラフほしけりゃ希望すればつくかもな。
何でも実装されるから。

マシンスペック等で写真屋以外の良いツールを実際に使ってる人が
TOOLの使用感等を書くのは大賛成だが。

>>26のはスタンプツールが無いんだよな・・・

>>32
著作権法は個人の範囲内に置いては複製をみとめてるのは当然知ってるだろうから
どの法律に違反するかあげてくれ

PictBear

>>32
もういいって。　ムキになるなよ。
これ以上醜態を晒すな･･･

>>32
昔の自分を見てるようで（´・ω・） ｶﾜｲｿｽ
ま、自分はやんわり書いてたんで
住人の方もやんわりと著作権法上での例外を教えてくれたけどね。　

まぁ、このへんを参考にしつつ、建前を守ってお話しませう。

ttp://www.geocities.jp/shun_disney7/hos3.html

ミーヤも一応グラフ出せるじゃん
フォトショほど使い良くは無いが、藤よりは余程やりやすい
リサイズも段違いに速いし、正直藤はもうｲﾗﾈ

スキャンするとき雑誌のふやけ？みたいなのが影になって入力されるんだけど
これ防止する方法ないかな？重し乗せても無理だったし

使っているのはCISスキャナ？
なら、CCDスキャナへの買い替えを推奨します。　かなり改善されるかと

もしCCDスキャナなら、トーンカーブ弄ったりして誤魔化すとか？

>>42
紙を水に浸してからガラスに貼り付けて放置。
乾かしてからスキャン。

せんせー　既出かも知れないのですが
よく、ほにゃほにゃ漫画.zip等を右クリするとコンテキストに
カバー画像が出るのですがアレってどうやって圧縮してるのでしょうか？

>>43
>>44
テンクス
でも>>44の方法でやったらさらにひどくなった
やっぱ買い替えが一番かな

マンアフターマンって流れてる？

>>47

>1

今からスキャナ買ってこようと思うんだがおすすめ教えて
予算は15000くらいまで
>>42みたいにならない感度がいいやつお願い

現行機ならEPSON　GT-F500。
場所によるが、税込み12000円台ならまずまずな値段。
F550はフイルムのオートローダ機能がｲﾗﾈｪし、
F600は高い、GT7400はモアレ低減モードが遅い。
Canonの薄型CIS機はコンパクトでいいが、原稿の浮き
に弱いのでコミック向きかといわれると･･･。

もしGT8400が新品で入手できれば、モアレ低減モード
でも速度低下がないのでいいかと。

>>49
CCDのスキャナ買っても解決しないと思うよ。
スキャンする時に原稿をまんべんなくガラス面に強く押し付けるか、
補正時に手作業で消すしかないんじゃないの？
B5サイズの雑誌だと、楽に紙全体を押さえることのできるB6やA5サイズに比べて
紙をしっかり押しつけてるつもりでも、押さえが甘くなりがちだし。(アクリル板使用の場合）

>>42>>51
軽い影くらいならカラーで取り込んでグレスケ化するとき消える。
3kgくらいまんべんなく重しを載せれば紙の歪みも折れ目も写らなくなるけど
その代わり軋み音が・・・

前ｽﾚでお世話になったものです。
Photoshop 5.0Jを導入して画像補整やってみました。
文字のぼけ気味はどうにもならないですけど
サイズ縮小と黒白は何とか出来ましたありがとうございます。
素人質問ですいませんがフォルダ一括補正って
どういう手順でするか教えて頂きたく・・・。

>>53

>>53
何故いまどき5.0Jなのか、そこから始めようか？

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

5.0は比較的軽いんじゃなかったか
どっかで見たような気がするが
まぁ写真屋の時点で重いけどw

たまたま落としたのが5.0だったってだけだろ

>>55-58
前PCにインストしてて今のにいれてなかったのがたまたま5.0Jでした。
前PCでえらい重かった記憶あったんでいれてなかったんですよね。
>>56の落として勉強してきます。
150dpiでも1冊スキャンするのに2時間かかる（´・ω・） ﾂﾗｲｽ
本体USB2.0対応じゃないのでどうしよーもないｽ

＞本体USB2.0対応じゃないのでどうしよーもないｽ
http://www.kuroutoshikou.com/products/usb/usb2+1394-pci3.html
こんなのお勧め、2000円くらいだよ

150dpiでやるぐらいなら300dpiのグレースケールでやったほうがいいよ
150dpiじゃゴミ残るかとばしすぎてモアレ発生させるかどっちかになる

>>61

150dpi True Color 1463*1058*24bit 875KB スキャン時間 17sec
http://www.uploda.org/file/uporg113548.jpg
いじったあと↓
http://www.uploda.org/file/uporg113549.jpg

300dpi グレースケール 2927*2117*8bit 2930KB スキャン時間 15sec
http://www.fileup.org/file/fup21499.jpg
いじったあと↓
http://www.uploda.org/file/uporg113547.jpg

Photoshop 5.0Jです。
4つ目はもっとサイズ小さくした方がいいでしょうか？

>>60
（´・ω・） 購入検討してみまｽ
>>61
300dpiでグレースケールの方がスキャン速度速い事実に驚きました

やっぱり150dpiだとスキャン時にモアレでてる
フルカラーでチャンネルミキサーかけられればそれに超したことはないけど
そのために解像度さげちゃ本末転倒
当然だけど最後にリサイズ必要だよ

補正とリサイズだけ
http://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050529211545601.jpg

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>64
素晴らしすぎます・・・orz

俺前スレで>>61と同じことを指摘してたのに無視されてたのかorz

雑誌を自炊したいのだけど
どれくらいのサイズでスキャンしたほうがいいの？

>>68
ちゃんと字が読める程度
字が少ないor無いならば自分の好みで決めれ

>>69
600dpiでスキャンしたら
加工するときに固まってしまたのだが
もう少し画質を落とせばいいの？

単行本スキャンで600dpiなら分かるが、雑誌なら200〜300dpi程度で十分字が読めるスキャンできない？
俺は200dpiだとトーンのモアレがチョイ気になるので300dpiで適当にやってるが

雑誌は原稿自体が黄色とか赤とかで
補正に限界があるから300だな
大して速度変わらないし

600dpiでスキャンしたのを300dpiにするソフトってありませんか？

>>73
意味がわからｎ
最初から300dpiで取り込むか>>2を参考に縮小すれば?

>62
>4つ目はもっとサイズ小さくした方がいいでしょうか？

・いざ読む時は全画面表示で読む人が多い
・大きい画像を縮小表示する場合に比べ、小さい画像を拡大表示すると汚くなる
・ディスプレイが大きくて1600ｘ1200を使っている人がボチボチいる
・大きいほど綺麗なのは分かっているが、出来ればデータサイズを小さくしたい

んなわけで、ｎｙなんかでは1600ｘ1200の人が全画面表示で見ても拡大処理されないように縦1200が主流。
将来的なことやルビの再現性を考えてか、縦1400〜縦1600ってのもたまにあるね。
完全自分用なら「綺麗に見たいので縮小無し」〜「読めればファイルサイズが小さいほど良い」まで好きにすれば良いかと。

>68
原理的に考えれば300dpiより600dpiの方が綺麗に決まっているが、
縦1200まで縮小した場合、少なくともオレの目では見分けが付かなかった。
んなわけでオレも手作業の処理が重いのが嫌で300dpiスキャンしている。
傾き補正中にモアレに気付いたページだけ600dpiでやり直しかな。
200dpiと300dpiを縦1200まで縮小して比べた場合、さすがにその気で見ると画質の差を感じるんで、
「発売時期を逃すと手に入らない雑誌こそ保存すべき」なら300dpi、
「雑誌は所詮単行本までの繋ぎに過ぎない」のなら200dpiでも十分ってとこかなぁ。
まぁオレは対象によっていちいちdpi変えると作業中に違和感有るんで、
なんでもかんでも300dpiだけどｗ
>73
dpiの意味分かって無いみたいだな。
そこまで説明してたらきりが無いから自分で調べておいた方が良いよ。

原稿の字が小さくて縦1200にすると潰れちゃうから、拡大しても読めるように大きいままにしてる。
当然ファイルサイズも大きくなるし、ビューアで見た時に(縮小処理が入るので)展開に時間がかかる。
でも字が読めなくなっては意味無いので、仕方なくそのサイズ(300dpiで取り込んだまま)で完成にする。

こればっかりは仕方ないよな……

このスレの住人的にはCanoScan 5200FとLiDE500Fとだったら
どっちがオススメ？

5200F
ttp://cweb.canon.jp/canoscan/lineup/5200f/index.html
LiDE500F
ttp://cweb.canon.jp/canoscan/lineup/lide500f/index.html

5200FはCCD
LiDE500FはCISだが。

みんなCISの画質の悪さ気にするけど
徹夜で大量に何冊も炊くような場合は
バスパワーで移動の簡単なCISは重宝だよ。
同じ姿勢で何時間も作業すると翌日のダメージがでかい（藁

>>78
藁って久しぶりに見た。
必死なの?

そりゃぁ必死だって。5冊も炊いたら肩がヒリヒリ

>>67
前ｽﾚ912さんかな、あの時は意味わからなかったｽ
>>75
わかりやすい説明ありがとうございます。
縦1200でリサイズしていく事にします。

補正でシャープにするとトーンの色合いが変になる・・・
シャープいれないと文字が薄くなる・・・
トーンカーブもいまいちよくわからなｽ・・・うーむ修行が足らぬ・・・（´・ω・）

5200Fのがいいと思う。やはりCCDとの差は大きいかと。
プレビューとか速くなってるらしいし。紙を横にすれば、大した速度の差は無いかと。

>>78
スキャナよりも炊く時の姿勢や位置を考えた方が良いんじゃ・・・？
うちは他のPC作業しながらのんびりとやってるけれど、そんな負担にならない。

>>82
77だけどｻﾝｷｭｰ
早速明日買ってくるわ。


頑張って立派なうｐ職人になるよ。

俺は明日ScanSnap(fi-5110EOX3)を買ってくる
まぁ色々と良い点悪い点が有るようだしちょい迷ったけど、
やっぱり自分で実際に使ってみないとホントのところはわからんしな

でも正直4万も出してダメスキャナだったらへこむ

そんならそもそも安い旧ScanSnapにしとけよって話でもあるが……
FAQの「fi-5110EOX2からの変更点」のとこにある
・検索可能なPDFの出力機能を追加しました。
・出力される画像の画質改善を行いました。
・原稿サイズにて「カスタム」指定時、長さ自動モードを追加しました。
・継続読み取り時、装置スキャンボタンでも読み取りをスタートできるようにしました。
あたりに期待

>>83
> 頑張って立派なうｐ職人になるよ。
自炊職人のタイポでつよね？

メール欄キモ、面白く無いし

縮小なら劣化は少ないといっても、グラーデーションやカケアミがが潰れたりするから、
原寸で見れるように縦1000でやってるなぁ。
保存は生スキャンデータでしてるし、一時的な閲覧用って感覚。

>>84
今ならScanSnapよりDR-2050Cを勧めたい。
ダブルフィードがないのは作業効率的にも精神的にもラク。
こっちとか参考に考えてみては。

ttp://pc8.2ch.net/test/read.cgi/printer/1114452094/

スキャナの無効領域にガイドレールを付ける時は両面テープで大丈夫でしょうか？
あとアクリル板の厚さは3ミリと5ミリのどちらがいいでしょう？

>86
単なる煽りはここではやめましょうよ。
建前上必要だし。

でも厨が増えてきたからそろそろ誰か捕まってもいいかもね。
腕コンとか言ってたヤシはちょっとびびり過ぎだったけど、
今みたいに堂々と宣言されたり貼られたりの流れはあまりいいとは思えない。

>>87
サンクス

……って、ここに来て迷わせるなよー
まぁちょっと比較してみたけど

SS
センサ/光源：白色冷陰極管/非球面レンズ縮小光学系(CCD採用)
ファイン/カラー200dpi(白黒400dpi相当)両面・片面：10枚/分

DR
センサ/光源：CMOS CIS/RGB LED
200dpi両面：12面／分

ということなんで性能的にはとりあえず問題なし。他にも色々あるんだろうけど。
ダブルフィードについては迷うところだが……
DRの方はローラのテンションが高いのでDF起こさないみたいね。
その代わり、SSよりも公称での消耗部品の交換時期が早い。(＆ちょっと高い)
DRのマニュアルが見つからなかったんであまり詳しい比較ができないけど
とりあえず購入前にちょっと見ては見る。
個人的には見た目的にSSを選びたいところだが……

>ダブルフィードがないのは
どうしてダブルフィードがないって分かるの？

比較的起こりにくいって意味だろうな
ダブルフィード0を公称する製品は無いだろうし、あっても買えまい

そんなのよりA4ノビやB4を読めるフラベかADFが安くほしい

>>91
絶対無いとは言わんが
http://pc8.2ch.net/test/read.cgi/printer/1114452094/145
こういう仕組みで
ttp://pc8.2ch.net/test/read.cgi/printer/1114452094/278
2000枚やって1枚ということだそうだ。

オレの場合はまだ400枚程度しかつかってないのでたいしたことは言えないが、
ダブルフィードはまだ一回もない。

>>91
DR-2080Cで3万枚ほど読み込んだが、
機械に責任のあるダブルフィードは1回も無かった。

ダブルフィードしたのは、
　・非分離（単票読み込み）モードで紙束をくべてしまった
　・糊でページがくっついたまま紙束をくべてしまった
という場合のみ。

書籍、コミック単行本、週刊誌、月刊誌など、
通常考え得る紙質のものは一通り試したが、
ダブルフィードは無かった。
たいしたもんだと思う。

「黒枠消し」「傾き補正」に関しては既報のとおり。
これが何とかなれば最強なのだが…

今日から俺はなんかのページ抜けはDR-2080Cでのダブルフィードっぽいんだけど違う？

結局ScanSnapにしますた
次があるなら、DR系を試してみるとします

で、色味の方はまぁ個性として許容できる範囲
確かに赤系の出方に癖があるような気はする
それより300dpiでもこの速さだって事の方が大きいわ
前のフラベは毎回調光してたから余計に……

ただ俺の場合わずかな傾きが回避できないのが今のところ唯一の欠点か
まぁこれは原稿に問題有るってだけだし簡単に補正できるからいいや

Photoshopを使った結合のしかた教えてください

http://tmp5.2ch.net/test/read.cgi/download/1111305313/360
ネット関係 [Download]　“【コミック】自炊技術総合スレッド15冊目【書籍】”

360 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2005/04/17(日) 02:18:18 ID:F/w1eimJ0
１．左右の絵を別々に傾き補正。横に横断するコマ線があればそれを０度に、なければ絵の端っこを９０度に。
２．レイヤーを二個作って、左右のページを別々に載せる。
３．上になっているレイヤーだけを表示して、輪投げツールや多角形ツール？で、余白だけを
　　ギリギリのところで囲んで、切り捨てる。矩形ツールで四角く切り捨てるのは
　　大雑把すぎるのでＮＧ。
４．位置をピッタリと合わせる。拡大して、１画素の単位まで追い込んで最適な位置を探す。
５．左右の絵の濃さが合っていなければ、レイヤーを選んで片方だけ濃度補正。空など、大きな
　　面のトーンが連続して見えるように
６．レイヤー結合して一枚の絵にする
７．あとはボカシ、塗り、コピペでスキマを埋める

おおまかな作業は、たぶん誰でもこんな感じでやってると思う。問題は７．だが、これは
とてもひと言では語りつくせん（ｗ
あと最初からずれている絵の場合でも、色々とゴマカシの技を使うと、きれいにつながることもある
（絵のパーツを個別に移動させたりとか）

すみません
あほなのでまったくわかりませんorz
もっと簡単に教えてください

とりあえずパソコンを窓から投げ捨てれば幸せになれます。

１番まではわかるのですが…

�@結合するページを開く
�A新規で結合分の大きさのキャンパスを大きめに作成
（どうせ後でトリミングするので50mmほど大き目でもよし)
�B結合元のページを傾き補正して結合辺のみ余白がないように範囲指定してコピー
�C作ったキャンパスに左ページは左側半分に、右側も同じようにペースト
(結合元に開いた2ページは失敗した時もOKなように保存無しで閉じておく）
�Dウインドウ→レイヤーでチェック
　レイヤーの窓に三つ表示されているはずなので
　それぞれのレイヤーを選んで移動して合わせてみる

最近のは綺麗に解体しても結合面が断ち切られておらず、
ピッタリと一致する物は1%も無いので
妥協するか書き足すかして結合終了
あとは普通の1ページと同じ扱い

結合終了したらレイヤー結合させる事
てかこれは書かなくても分かるかと思ったけど一応

合わせて繋いでも多分右ページと左ページで上下に5〜10ほど
ずれてるので端も切っちゃうか書き足すかになる

最近はホントに断ち切りばっか

断ち切られておらず、じゃなく
断ち切られていて、だた

トーンカーブやコントラスト
明るさ系はレイヤー結合前にそれぞれのレイヤーで
統一感が出るように変えといた方が楽かも

すいません、もう一度書き込みします。
うざかったらごめんなさい。
自炊始めようと思ってるのですが無効領域に付けるガイドレールは両面テープで張っても大丈夫でしょうか？
重石に使うアクリル板は3ミリと5ミリどちらがいいでしょうか？
教えてくださいm（_　_）m。

大丈夫じゃなさそうなら綺麗にはがせる両面テープとか
そのまんまの名前で売ってるでしょ
それぐらい調べなさい
重しに使うなら3mm5mmどっちが良いかも考えれば分かるでしょ

結合は左右それぞれの傾き補正が俺的に最初の重要ﾎﾟｲﾝﾂ。

半透明青のアクリルで裏写りしないってあったから買ってきたけど裏写りするなぁ
原稿のずれわからないけど不透明黒買い直すか・・・

>>109
半透明グレーを買いなさい。

>>110
自分は半透明ブラウンを買ったあげくに、やっぱり裏写りで買い直しのクチ。
紙質によって裏移りするﾔﾂとしないﾔﾂがあるみたい。
半透明グレーは裏移りしない？信じていい？ｗ

安いもんだし、今週末、念のため不透明黒と一緒に買って来よっと。

レイヤー結合できないのであきらめますorz

"レイヤーの統合"ですよ。

じゃないや、"画像の統合"ですた

古い本の黄ばみですがトーンカーブをきつくかけずに
上手く飛ばす方法はないでしょうか？

紙質は残さない派なので白く仕上げたいのですが
黄ばみを飛ばそうとすると薄いトーンが飛んでしまう…

>>111
ちょっと試しに透明な何かで原稿押さえるか、まったく蓋無しでスキャンしてみて。
それでも裏写りするならスキャナの特性かも知れない。
その場合は黒いものを原稿に乗せてスキャン。そんで黒いものがあるところと無いところで裏写りの具合を比較する。

チャンネルミキサーと色の置き換え後トーンカーブ＜黄ばみ

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

ttp://www.nomad-soul.org/

見習い職人の館　？？？

115です

チャンネルミキサーはやり方が違うのか
上手くいかないです　なにがいかんのだろう…

色相・彩度でイエロー系を指定、彩度をマイナス　明度をプラスに
指定するとちょっとマシになりました
ご意見ありがとうございました

グレースケールとレベル補正じゃダメなのか？

>>118
115が解決したようなので今更どうでもいいけど、
黄色は青と緑の混色ではなくて、赤と緑の混色です。念のため。

赤100％で他を0％っていうかデフォでそうなってるから白黒にチェックいれるだけ
わからなかったら藤の白黒化法を2で白黒化
トーンが消えやすい場合はdpiを大きめにするといいよ
400ぐらいがお勧め

白はRGBが飽和していて、黒は全ての色がない。
黄ばんでいる部分は青が足りないと考えていいのだろうか。
ttp://www.bekkoame.ne.jp/~kamikawa/colors/colors.htm
こんなので遊びながら考えちゃったよ。

黄ばんでいる部分を白くするには、青＋緑or赤を0%にして白黒化すればいいのかな？
要するに赤か緑で白黒化するのか？よくわからん。

もう既に結論は出てるわけで
わざわざ考えてしかもわからんって時間の無駄

>>119
転送量と、引用の表記の問題でweb上ってのは難しいので閉鎖
したんだがなぁ。

誰かがスペース取って勝手に転載したんだろうな
最近の奴は転載とか節操ないから

>>126
もう更新させる予定はないんですか？

>>128
モチベーション不足･･･　何か新しい手法や、ソフトが出てくれば
考えますけど。ヘタレ炊きが増えてきたので、手抜きでも綺麗に
炊ける方法も考えないとなぁ･･･

BlastPNGがグレスケにも対応してるけど、どの種類のグレスケが一般的なのかな？

>手抜きでも綺麗に炊ける方法
手抜きは認めないってのが多いからどんな方法でも
そんな手抜きしたのは認めないって文句言うのいそうだけどね。
そもそも手間隙かけて結合と貸して綺麗に炊いて完成させるのが目的のと
炊くのは漫画を読むためや交換する材料とするのが目的なのと二極化されてて
ゴミを量産してるってのと、たかが漫画炊くのに何時間もバカみたいって
両者の考えも全く違うんだからどうしようもない。
仮にも時間かけて炊いてる人に向かってヘタレ炊きとか見下してる時点で
両者を認めてるってわけでも無さそうだしさ。
コ○ラとかの連中はほっとけばいいじゃんか。

確かになぁ。
たとえば週刊物を炊いてる人（どっちかっつとスピード重視）と単行本炊く人（どちらかというと画質重視）じゃ、
考え方も違ってくるだろうし。

好きな作品ととりあえずで炊いてる作品でも考え方が変わるしね

以前フルオートで最低限の処理をするアプリがあったね。そう言うのならインスタントな人も使うんでない？

どなたか見習い職人の館流してください orz

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

落ちてきましたthx

>134
あれで傾き補正をするとOKサンド紙のナスみたいなノイズが
死ぬほどのったりして（ノイズが出ないページもあるけど）
結局使えなかった　あれは一体何が原因だったんだろう
ノイズがでるという不具合がでた人ってほかにいるんかな

手抜きはやっぱりダメなんだな、と思って今では
一枚一枚ECで傾き手動補正に戻した

>>138
くだらない質問で申し訳ないけど、その「OKサンド紙のナス」って、何？

>>139
「ひどい」って言葉の方言か何かだろ。
どこにお住まいかは存じませんが。

あ、これって方言なんですか？(^^;
いや、なにか具体的な現象を説明したものだと思ったものだから。
関東関西を人生の半分ずつ、方言は未だ理解できない若輩なもので。
なにかの抽象であったならもう少し詳しく知りたかっただけです。

ttp://www.shimeitehai.co.jp/cl2/03f/cl03f.htm
ググったらあた

>>142
ほほー

>>139
突貫で回転プログラムを書き起こしてみました。
ttp://syobon.com/upload/src/syobon29632.zip.html
落とし込んだ画像に対して回転処理を行います。(ただし回転する以外なんにもできません)
件の問題が、補完法の違いによる見た目の違いならばこれで試せるかと・・・(^^;
簡単なreadmeをつけておきました。

回転処理を行うってことは、つまるところ擬似点を生成させるわけで、
「ノイズ」が乗るという点で考えられることといえば、
1.補完法が甘く、線ががたがたになる。
2.補間そのものの制度が甘く、隙間ができる。
という2点だと(ぱっと思いつくかぎり)思っています。
1であれば、実質のところ「仕様かな？」と割り切れなくも無い範囲、
2であれば、プログラムの設計ミス。(想定外の角度入力がなされたとかいろいろ)
それらであれば「納得がいく」で済む話ですが、それ以外だとするとなかなか興味深いので聞いてみた次第です。
なにかためになる話が聞けるかと思いまして・・・

上記プログラムは、1の補完法側の質の違いを試すためのものです。まず隙間が開く(2)ことはないと思っていますけど・・・
もし隙間が開くようなら言ってください。良い機会なので。
ちなみに単なるサンプルプログラムなんで実用度はゼロです。試したら捨ててください。

>>142
とかやってたらすでに情報くださってましたね。
なんか道化になってしまいました。(すんません、軽く流してやってください)
なるほど、そういうことですか。
ありがとうございます、よくわかりました。

そういや、>>138で思い出したので、
>>7にある　gradg　というソフトの感想でも書いてみます。

自分は傾き補正にしか使ってませんでしたが、
枠線がきっちりしているもの（昔の漫画とか4コマ漫画みたいなやつ）はよく補正してくれました。
半分くらいは補正できてたんじゃないかと思います。
後、傾き補正した後は線がガタガタしてました。
しかし、割り切って使うならなかなか良いソフトだと思います。

｢ny・share職人より、

MX職人が炊いたほうが綺麗である、

というのはガセ｣

最近よく思う。
MX職人のほうが上手かったのは
自炊情報が少なく、それを内輪で共有してた遥か昔の話。
ny職人のほうが質・量(速度)で考えると上の時代になってきた。
間口が広く人口が多いから当たり前なのかもしれないが。

雑誌　スキャン　捨てたい

>147

ないないそれはないｗ
貴方がほんの一部しかしらないだけ。

ny職人なんてそんなにいるのか？
その「綺麗」のレベルを「裁断している」まで落としても
nyで綺麗に炊いてるのなんて僅かだと思うが。
さらにいうとその僅かの中には鯖にいる職人も多々混ざっているわけだし。
ただそれぞれ全体の割合でいうならmxは読むためや交換目的のがいるから
綺麗に炊く人＜炊かない人となり
nyはそれなりに綺麗に炊けるから流してる人が多いのか
綺麗に炊く人＞炊かない人となる感じなきがする。

138です

例を出してわかりやすくしよう、と思って逆に
わかりにくい書き方をしてしまって申し訳ないです
>142にある紙のような砂模様のノイズが全面にのってしまう不具合が
頻繁に起きていたので結局自分では使えなかったのですが
>146を見ると試したソースの殆どが少女漫画の雑誌だったので
枠線がまっすぐなものが少ない、紙質が悪い、色インク刷り　というのが
原因になっているのかもしれません
成年コミックなどで今度試してみます

>>151
少し聞きたいのですが、このソフトはカラーのファイルに使いましたか？
もし、カラーのファイルなら、白黒化したらうまくいくかもです。

字をクッキリさせるのは
やっぱアンシャープマスクなのかな？
どうも値が決まらない他にお勧めの処理有る？
ソフトは写真屋でもなんでも良いけど仕事で使ってるの有るし

Mxだろうが、nyだろうがうまい人はうまい。
前にも同じようなネタのループを見た気がするが、
同じようなことが他のところでも起きがちだな。

>>151
>>142さんが紹介してくれたページにあるようなノイズが乗っているというのは、プログラムの設計に問題があることがほとんどです。
回転後の画像に点を打たない場所がある可能性、もしくは補間の際にオーバーフローを起こして白が黒になってしまっている可能性があります。
詳しく説明すると長くなるのでそれは端折りますが、もし想像しているものと同じ現象が起きているなら、
これはどんなソースを使っても同じといえるでしょう。
労力の無駄になるといけないので簡単にチェックできる方法を提案してみます。

真っ白な画像(すべての画素が255)と灰色な画像(すべての画素が128)を用意してそれを放り込み、結果をチェックするという方法です。
(もし手入力で回転角度を指定できないタイプのアプリなら適当に違う色で斜めの線を一本引く必要があるでしょう。)
回転角度を指定する、もしくは線を引く場合でも、できる限り中途半端な角度がいいですね、例えば5.7777度とか72.3333度とか。

1.両方でそのノイズが見られる場合。残念ですがそのアプリは未完成と言わざるを得ません。
回転時に打たない点が存在するパターンなので、どんなソースを用意しても特定の角度に回転する場合そのノイズが発生する可能性があります。

2.真っ白な画像のみノイズが見られる場合。オーバーフローによるノイズが原因のパターンでしょう。
ソースの画像に(大まかに見積もって)0-5、250-255ぐらいのレンジの画素が無ければノイズは発生しないと考えられます。
とはいうものの、毎回ソースをそういう風に加工するのも面倒くさい話ですし、あまり実用的ではないかもしれません。

3.両方とも発生しない場合。これが一番厄介で、正直このパターンは現象を推測できません。
おっしゃるようにいろいろなソースで試してみるしかないかもしれません。

暇と興味があれば、一度試してみることをお勧めします。

>>155
srcからdst作ってんじゃないの？dstから逆座標変換せんと・・・
さすがにそれは無いか

いくらなんでも、90 x n度以外の回転で
srcからdestを作るプログラマは馬鹿野郎としか言えないと思う。
さすがにいないんじゃない、そんなの？

>138

俺も以前同じ症状出てたけど、>7にあるバージョンだと直ってたぞ。

ぽまいら炊く作業で一番好きな行程どこ？
自分は、webでも眺めながらまったりｽｷｬﾝしてく時が一番好きさ。

ところで、少年漫画って見開き多いｯｽね。
一冊に22ﾍﾟｰｼﾞ分の見開き…しかも描き込みぎっちり…　orz

見開き分だけnyで流したら、結合されて戻ってくるだろうかｗ

ふ。
俺が今スキャンしてるのは見開きが全く無くて
超楽だｗ
だがその分余計なトコに凝って結局時間的には同じってのはどうよ

クオリティ保存の法則

見開きは多用するやつとしない奴がいるからなー。
前気まぐれで代行したマンガが見開き祭りで氏ぬかと思った。

＞余計なトコに凝って
それは見開きがあるとやらないような事？
やる事は結局同じだから見開きがある場合、
単純に時間が＋されるだけのような希ガス。

この世界は二つに分けられる。
見開き結合をやる人間と、やらない人間と。

手動結合→デジカメでマクロ撮影

>>159
それを書いておけばやってくれるんじゃないか？
前に、補正前のやつを流した人がいて、その補正を誰かがやっていた。
しかし、名前みただけで嫌気がさす漫画家いるよね。
1/4が見開きとか、もう無理って感じます。

荒木とか藤田とかｾｲﾝﾄｾｲﾔの新しいのかいてる人とかか？

個人的には1冊5枚程度が楽しく結合できる限界
2桁になるとまだあんのかよ…と飽きてくる
なので一日5枚で数日にわけて作業

ｾｲﾝﾄｾｲﾔの新しいのなんて見開き以前に炊く気がしないがｗ
ｻﾑﾗｲﾄﾙｰﾊﾟｰのパクリかと思った
昔の第二次声優黄金期の頃にｱﾆｦﾀだった奴が書いてるんだろうな
俺もその時期ｱﾆｦﾀだったし

お前個人の作品に対する感想なんていらない。

出版社は見開きは断ち切らないように製本できんのか
結合じゃなく最近はほぼ書き足しになるが

藤、リサイズ、色薄くなって、変に分割、結合、失敗。
どうすればいい、っか教えてください。

死ねばいいと思うよ

このスレではふぉとしょっぷを割るのがデフォルトだと思うけど、ウイルスとかトロイとかAdobe製品につきもののユーザー情報送信とか怖くないの？

割る？意味が分かりません
持ってる人はみんな買ってるか仕事共用マシンなので
情報送信なんて全く怖くありませんよ(^-^;

なんか勘違いしてるみたいですね。
違法ソフトなんて使うわけないじゃないですか。
コツコツバイトして買ったフォトショを大切に使ってますよ。

gradg　使ってみた。　小説モードで白紙を食わせたらアドレス例外で落ちてしまった。
回転別プログラムにかかわらず落ちたので法線ベクトルの計算でも失敗したかな。

それにしても早い。
基本はハフ変換で直線求めて回転、で「がんばる」で周辺ヒストグラム試行
でしょうか？

いま炊いてる漫画見開きｶﾗｰがいっぱいあって萎え

だけど漫画自体を解体しちゃうとあとは捨てるしかないから
ﾃﾞｼﾞﾀﾙで綺麗に残さなきゃって思うし気合いが入る

BTScan 要望。
グレイスケール化を赤100%でやりたい。

BTScanの中の人に言えよ。

とりこむときにドロップカラーで赤を捨ててる漏れには、縁のない話なだ。

みんなは縦と横のサイズどの数値にしてるの？
教えてください

非公開用　1600（希望者用)1400(通常)
ny用　　　　1200
コアラ非鯖用　適当

こうしてみるとコアラのはトリミングとリサイズだけしかしてないなｗ

縦1200

縦1300、横830
縦1200、横800
俺はこんな感じ

>>181
当然わかってるだろうけどリサイズするときは指定するのは片方だけだよ
そういったら折り返しを開いたカバーと普通のページの元々のサイズがちがうものを
同じ横サイズ指定にした奴いたけど

先日某雑誌スキャンで目次ページも含まれてたが、字が潰れまくってた。
文脈と固有名詞の知識で何とか読めたけど。
一応縦1400で漫画は問題なかったから同梱しないほうが良かったのではと思ったよ。

横サイズは指定する必要ないよね
トリミングちゃんと一定にしてりゃいい話だし

公開用：縦960（ブラウザでも原寸で見れるサイズ）
保存用：縦3000くらい（つーか300dpiで取り込んでそのまま）

半年振りに炊いてるんだけど・・・orz
グレスケ化はどのタイミングでやればいいですか？

黄ばみ飛ばした後ならいつでも良いんジャマイカ

最後に忘れちゃ無意味だから最後にしなさい＞グレスケ

ありがと

一旦、電源落としたからID変わってるけど↑は>>189です。

鉄板を重しに使っている奴手を上げてﾉｼ

>>189
自分に合った(やり易い)タイミングで行ってもらうのが一番だと思いますが、
私の個人的な考えで言えば、GrayScale化は「考え得る最速のタイミング」で行うのがいいと思います。
特に「Rチャンネルのみ」を利用してGrayScaleへ持っていくのなら尚のことです。
最終的に捨てるG、B両チャンネルを持ったまま回転処理だの縮小処理だのを掛けると、
GrayScaleで処理するときの3倍の時間がかかることになりますし、
輝度補正など濃淡を変更するような処理でもカラーの画像を眺めていては、少々やりにくいだろうとも思います。
これらの処理において、G,B両チャンネルがRチャンネルに影響を与えることは皆無ですので。

ちなみに、RチャンネルのみでGrayに持っていくという処理には、黄ばみ除去の意味合いも含まれていますので、
「GrayScale化する場合」特に「Rのみ」という場合に限って言えば、黄ばみ除去という処理は意識する必要はないと考えます。
カラー画像で黄色く見える部分を白く見えるように変化させるというのは、
言い換えれば「Bの濃度を上げる(場合によって補助的にGの濃度も上げる)」ということなので、
結果的に切り捨てるチャンネルの輝度に色濃く影響する処理はあまり意味が無いと言えるでしょうから。
この処理は、粗く言えばカラー(もしくは多色刷り)のページを処理する時にだけ重要になるものだと思います。

・・・・・。

補正作業って麻薬だな・・・終わりが見えない

>>197
止めようと思えば一瞬で止められるよ？

オナニーが止められないのと一緒か・・・。

自炊もある意味自慰行為と同じだし

こんな天気のいい日に家に篭って何してるんだろう、
と考えるとすぐ止められるよ、俺は('A`)
夜だと気にならないんだけどね。

天気が良いくらいで外に出るなんて事も無いしな('A`)

書籍をデジタル化するのに実本をスキャンするのって
すごく無駄だよな〜といつも思う。

印刷する時に使ってるデジタルデータがあれば
すごく楽で綺麗に出来るわけだしね。

なんとかならんものかねぇ……

その変てこな思考こそ無駄だと思うが
なんとかなるかどうかくらい直ぐわかるだろ

オンライン販売でpdfを買う

なんとかならないこともない、というか、
いずれそうなると思ってる。

今後デジタル化進めば、
コピー対策とか権利調整とか海賊版潰しとか、社会全体からみればムダでしかないコストがますます大きくなる。
そうなるとデジタル著作物はフリーにして、
公共料金方式でまかなったほうが社会全体ではメリットが大きくなる。

被参照量やキャッシュ量に応じてプールされたカネを分配するとかすれば、
市場原理も損なわれない。

が、10年は先の話だな。
著作権関係は、とりあえずアメリカがその気にならないとﾐﾘ。

自炊の達人は
コミック１冊何時間で
仕上げるのでしょうか？

手炊いて一時間。
まあ画質は悪くないし満足してる。

時間を掛ければ掛けるだけ凄いと思ってる勘違い君の
自慢が始まるからそういう質問は止めようね

最近短時間で仕上げる方が凄いと思ってる馬鹿増えすぎ

一時間で満足っての、どんなファイルか容易に想像できるな．．．

インターフェース 2001年版流してちょ

ボケや歪みがディスプレイ上では目立たない程度なら一時間でも仕上がるけどな。
そのレベルだったら質の向上よりも全巻コンプを目指すのもありかと。

視野せまっ

1時間だったら、俺はまだ解体後の一休みをしてるよ。

つか他人と比べるのが目的だとか流すのが目的じゃないなら
どんなレベルだろうと他人がとやかくいう必要ねんじゃねーの？

時間かけたのがエライってんなら10年でも100年でもやってりゃいいんじゃね？

＞どんなレベルだろうと他人がとやかくいう必要ねんじゃねーの？
これいいだすと話終了。
時間かけた・かけないの流れは不毛だけど
このスレ的には「綺麗にするにはそれなりに時間がかかる」だと思ってる。

確かにね。
時間聞くならどのレベルまでとか具体的な目標の提示がなければ無意味だな。

見事なほどに予想通りの展開だなおい

解体した本のためにも綺麗に…とか言ってみたり

ナイフで4分割→裁断機：５分
200DPI横向きスキャン180ページ：45分
Irfanviewでコントラストを上げてローテイトJPEG化：10分
本が新品なら歪んでないし、インクもくっきりだからそう酷くならない。

紙の部分RGB:255（モニター上で真っ白）
インク部分RGB:0（モニター上で真っ黒）
これで仕上げるとコントラストきつすぎですよね？

白245（-10）・黒24(-24)ぐらいが良いのかなって試行錯誤してます。
（グレスケだとK:97%と5%ぐらいです。）
皆さんはどういうアンバイにしてます？

↑あ・ごめん

花とゆめアナザーストーリー連載版全ページ（82年〜97年・おまけ98年、ピンナップや付録も有り）、
綺麗な奴流そうか？
300dpiカラーで取り込んで補正して縦1400。
自炊きが好きなので以前にうｐされたのやnyに流れてるようなのよりちょっとは綺麗だよ。
そしたらこの厨な流れが止まって未完部分の感想ばかりになるかもしれんし良い案かなぁと思うんだけど。
あー、でもやめろ、って人がいたらやめるけど。

誤爆した。忘れてくれ。

スピードより静かなスキャナが欲しい今日この頃

>>222
白は別に255でもいいんじゃまいか。
今の環境でまぶしいのが別の環境になったら別段問題ない、
じゃあ今度はその環境用に調整して、、とかなると嫌なので
もと画像の背景には手を加えず、まぶしい時はソフト側で変えればいいと
個人的には思ってます。

黒を締めるのは若干好みの部分があるから適当かな。

俺も白は255
まぶしいっていってもワードやエクセルの背景と一緒だし。
その分自分のディスプレイの環境を色温度6500＆明るさ50％にしてる

黒はレベル補正でデータの開始時のあたりかな
昔は細かいゴミ残るのでそのデータ削ってたけど
全体的なバランスからみたら残してるほうがよくおもえてきたので今は残してる

300dpiで取り込んで
ECで縦横2100x1700ほどでトリミング、傾き補正
写真屋でゴミ取り等の処理をしました

その都度別フォルダにbmpのまま保存していってたのですが
保存前はRGBだったのですが加工して保存後はモード弄ってないのにインデックスカラーとなっていて
ファイルを右クリックでプロパティを見ると解像度300→72になってしまっているのですが

また、別のものでも写真屋でグレスケにしてサイズを1400〜1200でリサイズしたものも
やはり72になってしまいます

ny等の職人さんのをみると縦1400でも解像度は縦横ともに300で
グレースケールと表示されているのですが
何か設定しないといけないのでしょうか？

写真屋持ってないとロクに自炊できないな。
スキャン→BTScan
補正→こみこんぷ
傾き補正→E.C
トリミング→E.C
グレスケ化、リサイズ→藤

こんなんじゃどう頑張っても地雷＿|￣|○

あう
アンシャープマスクがインデックスだとかけられない(´Д`;)

bmpだと解像度72から300とか変更しても
劣化とかやっぱり無いのか不安(´Д`;)

http://tmp5.2ch.net/test/read.cgi/download/1111305313/555

フラットベッドに収まらない大きめのカラーページ炊いてるんですけど、
別々に取り込んだ後に結合すると色合いが微妙に違くて
結合部分から色がクッキリ分かれてしまうんですよ。
こういう時、職人のみなさんはどうされているのか教えてほしいんです。

>229
写真屋にデータを渡す前に解像度情報が失われているんだと思うよ。
写真屋のデフォルト解像度が72dpiになっていて、保存時にそれが付加されている。
Btscan→写真屋CSでは問題ないからECが捨てているのかな？

インデックスカラーは写真屋でグレースケールモードに変更すればよし。

>ny等の職人さんのをみると縦1400でも解像度は縦横ともに300
これは妥協(?)した結果だから参考にしなくていいと思う。
計算すればわかるけど、縦118.5mmでA7とB7の間のサイズになる。
解像度情報を重視するなら、写真屋で解像度指定縮小をする。
縦ピクセルサイズ指定で縮小をすれば、縮小前の解像度のまま。
この例ではスキャンが300dpiだと思う。

画像を一旦縦1600にリサイズしてから、さらに縦1200にリサイズするのと
直接1200にリサイズするのでは画質は変化しますか？

今度から自分用と配布用でサイズを分けることにしたんですが
自分はトリミングをリサイズ後にやってるので、
「1600でリサイズ→トリミング→1200にリサイズ」
という順序でやろうと思ってるんですがどうでしょう？

>233
レベル補正

>>236
ありがとうございます。慣れればなんとか同じ色に合わせそうです。

>>207
人それぞれというか平均的な時間が
知りたかったんです。
散髪のカットの時間みたいな。

>>231　なんかまだ勘違いしてるっぽいし、>>234の指摘だけでは理解できなそう。
1200とか1400はドット数。dpiはドットパーインチの頭文字です。
300dpiなら一インチ当たり300ドット詰め込む。72dpiなら72ドットが一インチの中に詰め込まれます。

さて、あなたはおそらくスキャン時に推奨される解像度である600dpiとか300dpが念頭にあって
72dpiというのは低すぎるではないかと思われているように見受けられます。
スキャン時の解像度とは、スキャン対象を一インチ当たり何分割して読み取るかの話です。
600dpiなら600分割、300dpiなら300分割です。解像度が高ければ高いほど詳細なデータが取れますね。

そして、取り込んでデータ化すると、縦1400とか1200と言う表現で画像の大きさがあらわされます。
冒頭で述べたようにこれらが表してるのはドット数です。縦に1400個ドットが並んでるわけです。
PC上で見てるだけならこれだけでいいのですが、これを印刷する場合一つのドットを
どんな大きさで印刷するか決めなければなりません。

これを指定するのがファイル情報に付加される解像度です。
つまり、一旦ファイルになった後は、解像度の数値は印刷用紙一インチ当たりどれだけのドットを詰め込むかであって、
情報量(ドット数)自体は一緒です。300dpiよりも72dpiのほうが大きく印刷されるということです。

ですから、PC上で閲覧するだけなら無意味な情報です。
また、解像度が変わってもドット数が変わるわけではないので、何度変更しても画質に変化はありません。
300dpiでないと気分が悪いとか、印刷もするということで解像度を指定したいなら>>234のやり方でなさってください。

>>235
写真屋などは2回に分けてリサイズしたほうが綺麗になる場合が多いですね。
>>238
ネイルケアしたりフットマッサージなんかもしてあげれば時間はいくらでもかかっちゃいます。
カットだけでは満足できない人も多いので。

★Winny週刊少年ジャンプ Part160
http://tmp5.2ch.net/test/read.cgi/download/1117776677/435
435 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：2005/06/05(日) 08:23:10 ID:4sd48GzT0
・ジャンプ買う、優しく手で千切る。
・BTScan使って150dpiのカラーでスキャンする。(手抜きポイント、だが必要なら300dpi)
取り込み領域を内側ギリギリに設定する。（手抜きポイント）
のどもとは余裕を持って、空白という情報を消さない程度かつ千切れた部分を取り込まないぐらいに設定する。
・写真屋にてチャンネルミキサで擬似グレスケ化。色置き換えを行い紙質を飛ばす。レベル補正にて画質を調整。
ここまでの処理をアクション登録しておき、自動処理→バッチにてバッチ処理を行う。
・ノドの汚れなどを消す。
・画像解像度にて縦1200に縮小。モード変換にてグレスケ化。jpg保存。(jpgの圧縮比は5、非プログレッシブ)
ここまでの処理をアクション登録しておき、自動処理→バッチにてバッチ処理を行う。
・Leeyesにて最終確認。
・JPEG Cleanerにて埋め込まれた余分な情報を削除してファイルサイズの削減、Carmineにてjpegファイルを劣化無しでサイズ削減。
・WinRARで無圧縮zipに固める。フォルダごとは固めない。

なお、見開き結合を行う場合は工程のいくつかを変更する。
・ECにて傾き補正を行う。見開き結合時、傾きがひどい(主観)などの理由がない場合は傾き補正はしない。(手抜きポイント)
見開き結合自体もいくつかの条件が整った場合にのみ行う。(手抜きポイント)


このスレ的には地雷ですか?
雑誌スキャンてこんなものですか?

>>229
写真屋はグレースケールのbmpを正確に読み込めない
グレスケ化は最後にやるだけでそれまではチャンネルミキサーをかけたRGBのBMPを使うか
もしくはグレースケール情報を持ってるpsd使うか。
サイズがでかいんでグレスケのbmpじゃないといやっていうのであれば毎回読み込み時にグレスケ化
ただ写真屋はRGB、インデックスとグレースケールで変換時に微妙に色が変わる

ちなみにインデックスカラーで回転とかやるとえらいことになるのでやらないようにね

>>205
それもほとんどが実本からのスキャンだ。

>242
>ちなみにインデックスカラーで回転とかやるとえらいことになるのでやらないようにね
まじ？
写真屋使えネ

基本だろ。
最近は質が落ちたな。

ﾌﾟ､昔からだろ

写真屋たけえよ。
同程度の機能備えた別のソフトって無いの？

>>227
>若干好みの部分があるから
なるほど、黒の方のみお好みでって感じですね。
いろいろ見てるとかなりグレーっぽい作品もあるし、ガリっと0のもある。
描かれてる内容にもよる、も有りなのか…。
>>228
>環境を色温度6500＆明るさ50％にしてる
色温度は一緒。明るさもほぼ同程度。
二人とも255ね。レスどうも有り難う。

>247
お前いい子だな。

>247
マジレスするとある
GIMP
フリーウェア
日本語も使える
Mac・Win両方ある

CMYK使わないならPaintShopProでいいだろ
バッチ処理もできるらしいぞ
ttp://paintshoppro.jp/tutorial/psp9/500/300.html

>>250
サンクスっす！おお、なんか凄げ。
ググったら解説サイトみたいのもたくさん出てきたから操作法わかんなくて困ることも少なかろうとおもふ。
とても期待。

>>251
GIMP試してみて満足できなくなったら、それ購入見当してみます。

JPEG Cleanerのバッチ処理で
サブディレクトリも読み込むにチェックを
入れているのですが
読み込まれません。
なぜでしょうか？

>>242
＞写真屋はグレースケールのbmpを正確に読み込めない
信じられないと思いつつ、試してみたら、確かにわずか輝度1の差があった。
カラーパレットからRGB→Y変換してるのかな。まあ、1,2程度の差なら気にならないレベルだが。
フォトショともあろうものが、、こんな基本的な不具合あるとは。(6.01で確認)

GIMPはバッチ処理が手軽にできたら使えるんだがなあ・・・
現状ではScheme言語をマスターしないとバッチ処理ができん。

PSの一番いいところは自動処理（バッチ）が出来ることだしな。
それ以外の機能はフリーソフトでも何とか代用できる。
事実PS使うまでフリーソフトだけで自炊してたし。今見返すとへぼい画質で鬱になるが・・・

>>253
俺だけか．．．
悲しい．．．

>>257
一日もたたないうちに回答を要求するわけ？間たった3レスだぞ？
環境もバージョンもディレクトリ名も書かずに？
そんな奴はお前だけ。

age

>258
働いている人とニートを比較した場合
8時間寝るとして16時間は起きているとしよう。

働いている人は、そのうち12時間は仕事などに時間を費やして
残りの4時間を２ｃｈに費やしているとします。
ニートは働かないので16時間は２ｃｈに費やしているのれす。
従ってニートは働いている人と比較して3倍時間がかかったと
感じるのではないのでしょうか。
ぜー金払ってないくせに。

寿命も3倍の速度で尽きればいいのに。

本って縦長だからどうしてもディスプレイでは読みにくいよなー。
小説とかも段組されてるやつはいいけど文庫とかだと１行読むたびスクロール。
読む気なくなるよ。
読書用に縦長のCRT開発してくれんかね。昔OASYSとかであったような

>>262
むかしはピボット機能の付いたパソコン用CRTもあったよ。
90度首振って画面を縦長にしても使えるやつ。

そこでUXGAですよ

液晶モニタなら　今もいろいろなメーカーからでてるよねPIVOT機能ついてるの。
メーカーによって呼び名はさまざまかもしれないけど。

NECのPC-100を思い出した。

ThinkPad X41 Tablet
IBMなら・・・買うかもだが・・・

>>265
いろいろなメーカー？

>>264
論点が違う

>>260
> 働いている人は、そのうち12時間は仕事などに時間を費やして
> 残りの4時間を２ｃｈに費やしているとします。

仕事と寝る以外は２ｃｈってのも何か嫌だな

実際似たようなもんだけどな('A`)
仕事以外は２ｃｈかネットか漫画か本読んでるか寝てるかだし。あと自炊か。

なんかかなしくなってきた

みんな似たような仲間さ

モアレ防止オフ　24bit 300dpi A4での最速スキャナは
>>5の8300UF : 13s
で宜しいのでしょうか？
どうしてもバラしたくない本用にFBスキャナ購入を考えている
のですが、GT-F500とどちらにするか悩んでます。

ちなみに色々調べているなかで、これのデカイのが出来たら欲しいと思いました。

http://imagescanner.fujitsu.com/jp/product/60f.html

8300はもう売ってない
8300→8400→F500

>>274
↓前スレにあったコレは？
http://www.e-zakka.net/guest/opticbook3600/ob3600.htm

>>276
あーこんなの欲しいですねえ。
日本に輸入されると倍の値段になってしまうのが悔しいですが、
こんなの日本のメーカーなら簡単に作れそうですけどね。
まー著作権のしっかりしてる日本だから敢えて作らないんでしょうけど。

ちなみに、見開きで取り込んだ場合真ん中の黒くなった部分を
消すにはどんな処理が一番手間がかからないでしょう？
以前、動作のとろいスキャナで一冊取り込んだときは、トーンカーブ
をいじって裏写りを目立たなくしてから、まぶしさ低減のため明るさを
低減して気にならない程度にはなったのですが。

・・・

ゴミはどういじってもゴミ

せめて「解体後二枚並べてスキャンして
そのまま分割せずに仕上げるケース」について
質問してるんだと思いたい。

……まぁ言葉通りの意味なんだろうけど。

地雷はこうして生まれるのか

地雷を地雷だと認識していないことが
地雷を生むんだな。

>>274=>>277
「どうしてもバラしたくない本」なら炊く必要無い。
実本のまま大切に持ってればそれでいいんじゃん。
ここの連中は綺麗なデジタル化を目的にしてるから解体は絶対条件。
見開きで綺麗な加工教えてくれってのは、ちょっと話が噛みあわないんだよ。

まぁ、どうしてもというなら、まともに閉じなくなるまで徹底的に押し付けてスキャン
ただし、それでも解体に比べて大幅に手間がかかる事必死だし、元の本の状態も
期待出来ない。
スキャン品質も、解体には及ばない

やはり解体するか、地雷作るかのトレードオフになるんでないかな

地雷地雷言うなよ。書籍のスキャンがどんだけ大変と思ってるんだ。
TV番組キャプチャしてDivXエンコすんのとは訳が違うぞ。
貴重な紙データが「デジタル化」されたことそのものに感謝しろよ。
劣化することなく、書棚も占有せずモニター上でいつまでも観賞出来るんだからな。

確かに地雷かどうか裁定するのは
個々の自由なんだけどな、
このスレ的には…ってこった。

生ゴミをどう料理しようがゴミはゴミ。
大変だろうが時間がかかろうが見開きは地雷。

写真屋の「画像解像度」「画像サイズ」の違いって何ですか？
このスレでいう縦サイズを1200に変更するのは「画像解像度」ですよね？

不毛なくそことば吐いてたのしい？

>>285
巣にお帰り
ここはお前の来る所じゃない

>>285
このスレで言っても釈迦に説法だよなあ。
ま、他の誰も炊かないコンテンツなら神は神だろうけど。

なんで見開きが地雷なんだ？
解体して見開きでも地雷なん？

＞ここの連中は綺麗なデジタル化を目的にしてるから解体は絶対条件。
む、そういうことだったか。
確かにそういう理由なら、解体等は絶対条件だな。ｽﾏｿ

見開きってのは通常、非解体見開きの略

略っていうかもともと見開きに対して解体してある見開きとして
解体見開きの注意書きができたんだから非解体なんて断りつけるまでもなく
見開きは解体されてない物を指す

だから略なんだろ

解体していれば、見開きでOKということ？

読む側の意見として言わせてもらえば、
グレスケ化やリサイズ等基本的な補正がされていた上で
目視ではっきり分かる明らかな傾きとか
恐ろしいまでのモアレとかがなければいいんでないか？
使っているビューアによっては
単頁のほうを望む人もいるかもしれないが。

自分で炊く場合は趣味の領域だから
単頁にしてトーンカーブだの見開き結合だの
0.1単位の傾き補正だのするけどな。楽しいし。

コミックじゃなければ見開きでも問題ないし、
どーしても解体できない本ってのは非コミックの
ことが多いけど、ここはコミックの炊き出しを念頭
に置いたスレなんですな。

>コミックじゃなければ見開きでも問題ないし
？？？？

日本語読めなくて文字を図形として認識してる奴は歪んで問題でまくりだろうな。

>>253
誰か答えてお願い！！！

以前「シャープとモアレを天秤にかける」
って人がいたがそういう人結構多いのかな。
有名どころでも意外と出てたりするけど、
800X1200が付いたの見てたりすると、綺麗だけどどうしてもモアレが気になってしまう。
逆にいうとモアレのせいで見開き結合や画質のよさがスポイルされて
全体的な完成度が下がっているような。

炊き予定にあるのは別に自分で炊くだろうけど
ちょっと「もったいないな」と思ったもので。ごめん。

ディスプレイの広さとか環境にもよるので
炊き主の環境では綺麗に見えてるのかも知れない。

原寸大で見てモアレが出ていないのが「モアレなし画像」。そういう画像を、細かく縮小倍率を
変えながらディスプレイで表示してみると、必ずどこかでモアレが出るはず。つまり千差万別な表示
環境のどこかで、必ずモアレが出てしまうってこと（モアレ＝原画像とディスプレイ画素の干渉縞）。

どんな表示倍率でもモアレフリーな画像ってのもあるけど、それは細かいトーンのパターンが潰れて
グレー一面になってしまっているからで、そういう画像はトーン以外の細かいディテールも潰れている
ことが多い。逆に言えば、モアレが出るほど高い解像度で仕上げてある、ともいえる。ディスプレイの
画素数が上がって原寸大以上で表示できるようになった時、そういう画像の方が高画質になる。

(　ﾟДﾟ)・・・

まぁ、CRTなら解像度を変えればいいんだけど。
21インチCRTでエロゲの800x600を全画面で見ても、キレイに見えるっしょ。

モアレ自体はあまり気にならないが、
モアレが出てるようだとたいていグラデーションやカケアミが潰れたり、
50％のトーンが60％や30％になってたりして、
元絵と雰囲気が変わってることが多い。

逆にグラデーションを潰さないように、
あるいは50％のトーンを50％で出せるようにってカンジで補正してくと、
自然とモアレの出ないレイな仕上がりに。

>>283
解体後可燃ゴミとして処分してもいいような
｢コミック｣
しかしらないから、
解体してしまっては取り返しのつかない
｢書籍｣を電子書籍として保存する
必要を
しらないんですね。

古事記の原本でもスキャンしてんの？

そんなもんこのスレに関係ないことぐらい誰でもわかる。
ついでにそんな重要なもん炊いたところで
共有するわけでもないから板違いでもある。
どっか別の板にデジタル化のスレがあったはずだからそっち行きな。

>>308
死ねばいいのに

みんなカラーの補正ってどんな感じでやってる？
非カラーページは見習い等を見ればわかるんだが
今は下手に弄らない方がいいかと思いサイズ変更とアンシャープだけ掛けて終了
一応いつでもやり直せるようにスキャンデータもそのまま保存してる

>312
私の場合は、スキャン時にカラー調整をしっかりと行うので
スキャン後にカラーの補正を行う事はしないです。
スキャン後にカラーの補正を行うと質が落ちてしまいますし。

>>313
くそ、釣られちまったじゃねーか。

>>310
そういうことはスレタイ変えてから言ってくれ。

スレタイとかそういうの関係ないから。
ここは16冊目にくるまでに住人の間でいろいろ模索した結果
原本をいかに綺麗に炊くかのみを追求する方向になってる。
ただ、早炊きとか非解体見開きとかそういう限られた条件の中で炊くというのも
このスレで要求されているだけの技術があれば
結果的にその技術から解決できるというのも含んではいるので
自分の条件だけを押し付けずにここで総合的な技術を学んで
そこから応用すればいいだけ。
だが、>283に>308みたいなレスしかできないようなのは要らないから
どこかの板にあったデジタル化スレに行って貰いたい。
他の板がいやなら↓があまってそうなので
そこを解体見開き自炊スレとして活用するとか。
comic161
http://tmp5.2ch.net/test/read.cgi/download/1118421327/

思い込み

おれっちのスタンスと違うから出て行けってのは頂けないな。
とりあえずプログレッシブjpgは無意味だから止めた方がいいと思う今日このごろ。

ここは書籍デジタル化について総合的に扱ってる訳じゃなくて
技術専門スレだからなあ。
綺麗に炊くのが目的＝解体前提となるのはいたしかたない。
でもって>>318に同意しつつつい最近までプログレで炊いてた俺。
しかしあやまらな（ｒｙ

>>318
プログレ化するとなぜかサイズが小さくなる。

>>320
お幸せに

>>320
ほんのチョッピリだけね
でもって巨大なdbファイル同封してたりして

非プログレJpegにCarmineかけるよりマシ。

ファイルサイズが大き過ぎると言われると今どき10M20Mの差なんて気にする必要ないと仰る。
プログレ止めろと言われると僅かでもファイルサイズが小さい方がいいと仰る。
もうね・・・

オレは".zip"のキャッシュが2300くらいある。
10Ｍも大きいとシャレにならん。

つーか、小さくなる利点を相殺するようなデメリットでもあるのか？

・・・

>>318
見開きで解体したくない大切な本を手間かけずに
綺麗に炊くにはどうしたらいいかって質問にはムリだって答えてるよ

見開きスキャンでぼろぼろになるのはOKでも解体はだめな書籍ってのが
なにかはよくわからないけどね

>>308みたいに逆ギレされても個人の都合なんか知るわけないから
2冊買えとしかいいようがない

炊くなら解体しろ
解体したくないなら炊くな

プログレ・非プログレの容量差は、
もちろん作品によって違うだろうが
B5版300Pで3〜4MB程度だと思う。
まあチリも積もれば山になるだろうから
どっちを選ぶかはこれも炊く人の好みだな。

というかjpgにしといて圧縮してないやついるよね。
単行本一冊で100M超えんなよ。

>>327
逆ギレには見えないが

>>308
これでも買えよ
ttp://konicaminolta.jp/products/business/micrographics/epicwin5000c/index.html

確かに手間はかけなくても金をかければ綺麗に炊けるな。

本当に貴重な書籍のデータ化なら業者に出したってやってくれそうな気がする。

>>332
ブック補正機能　←この機能すごいな、ホントにこんな綺麗に補正すんのかな
この部分のソフトを安く売り出したらバカ売れすると思うのに

>>327
レア本のなるべく綺麗な見開きﾃﾞｰﾀとってからヤフオクで売りたいだけだ。

大学や仕事で使うハードカバーの専門書とか高いからね。
備品だとばらすわけにもいかないし。

下記のスレはADF用だけど、ビジネス用途や学習用途で電子化してるひとが
多いからそっちのスレで話した方が適切だろうね。

【ADF】スキャナで連続取り込み006.jpg【OCR】
http://pc8.2ch.net/test/read.cgi/printer/1114452094/

こっちはフラットベッド派というりコミック派。

こっちのスレの方が趣旨に合ってるか。
過疎スレだけど。

【速い】本の取り込みに最適なスキャナ【手軽】
http://pc8.2ch.net/test/read.cgi/printer/1051171423/

誘導ありがとう。
非解体の話はこちらではしないようにするよ。

備品だったらとかろくでもない仮定に手助けする必要なんかないだろうに

>>339
いいから黙って追い出せよ。
スレ違いの話をされるより、向こうへ送りつけた方がいい。

本当に必要な研究や仕事なら金惜しむな

ｼﾞｴﾝﾃﾞｽﾀ

ｶﾞ━━(ﾟДﾟ;)━━━ﾝ!!!!!

今ひどい自演をｍ（ｒｙ

ちょっとプログレ化とCarmineで比較してみた。
ソースは中綴じコミック雑誌（256ファイル、グレースケール画像）を縦1200に藤で変換したもの。

　　　　　　　　　　　　　サイズ　　　増加処理時間
非プログレJpeg　　　68.5Ｍ　　　　　　0
　+Carmine　　　　　　67.1Ｍ　　　　　286秒
プログレJpeg　　　　　64.2M　　　　　318秒

とりあえずCarmineはイラナイと思う。
処理時間はny専のショボイPC(Athron600M、ATA33)の話なんで、
いまどきのPCなら1分程度になるのかな。

>>312
遅レスだけど、カラーはフォトショのLabモードで補正するか、
輝度を補正出来るツールで補正してる。
間違ってもフォトショのRGBモードでやってはならないね。

>>334
茶坊主優遇主義のコニカミノルタにこんな技術あるか！と思ったらOEMかも
ttp://www.ki21.jp/BUSINESS/GUIDE/seihin_04/product/bm0060_b.html

キャノンのDR-2050Cを購入しようか検討中なんですが
連続でスキャンしてもフラットヘッドと同等品質程度にスキャンできるんでしょうか？

連続にしたからといってスキャン品質が変わることはない。
もちろん、途中でスキャン面のガラスに糊がついたりすれば縦線が入ったりはする。

「扁平頭」じゃなくて「平らな台」な。
画質はそこそこだけど
フラットベッドスキャナとは明らかな違いがあるよ。

グレー300dpiとかだとちょっと区別がつかないが、
カラーはフラットベッドとの差がはっきり出るな。

過去ログ読んで勉強しようと思ったのですが
>>1にあるﾊｯｼｭ登録しても引っかからないので
お持ちの方は放流お願いします。

ごめんなさい。>>1のとは別のが引っ掛かりました。
スルーよろ。

フラットベットで人手でやってる「紙をスキャン面に置く」操作を機械でやっているために、
傾きやページごとのずれが生じる。画質よりこっちの方が問題。

2050Cにはソフト的な傾き補正機能もあるが範囲や傾きの誤認識が多く、
断ち切りベタのあるような漫画では使えない。４コマならともかく。

そんなわけで後からツールで回転などするとトータルの手間は意外に多くなる。

>>346
初歩的な質問で申し訳ないのですが、アンシャープマスクを使用しない場合でもカラーの場合は、Labカラー・16bit/チャンネルで補正した方が良いのでしょうか？

>>354
ページごとにバラバラに見える傾きだが、
実はスキャン時の傾きはほぼ一定してる。
表スキャン(奇数ページ）と裏スキャン(偶数ページ)にわけてバッチ処理すれば、
だいたい一定な結果が得られる。

が、オレ自身は1度未満の傾きは無視してる。
・・・つまり全然傾き補正はしてない、ｽﾏｿ

あと、斜行補正はいろいろとバグっぽい。
もともと文章の行の傾きを読んで補正してるらしいので、
マンガでは使わないほうがいい。

>>346
RGBカラーをRGBで処理しちゃいけない理由ってなに？

>>355
アンシャープマスクではなくてレベル補正をする場合です
RGBカラーでレベル補正をすると色質が変わってしまいますが
Labカラーでならこれを回避できます

色々情報ありがとうございます
連続スキャンするおt傾きがでますかぁ〜
確かにそれを補正するのが面倒ですね・・・

>>289
歳が知れるなw

誤爆？

>>345
プログレッシブJpegってインターレス機能の為にあるんだと思ってた。
サイズが大きくなるならともかくどうして小さくなるんだろう？

個人的にはファイルサイズと、それなりに綺麗で文字が潰れない程度の画質、のバランスを取るにはJPEG2000がいいような気がする。
今となってはマイノリティだが。

定期的に出てくるな、ロクに検証もしない知ったかJPEG2000厨は

使ったからそう言ってるに決まってるだろう。

それより｢J2k駄目論｣の論拠を教えてくれ。
試してみるから。

>>354
> 2050Cにはソフト的な傾き補正機能もあるが範囲や傾きの誤認識が多く、
> 断ち切りベタのあるような漫画では使えない。４コマならともかく。

豆知識だけど明るさを195にしとけば斜行補正オンでも
黒枠のバッサリ切り落としはなくなるよ。＞DR-2080Cの話だけど

>>364
あまりムキにならなくてもいいと思いますよ。
世論的にJPEG2000が未だ認められていないのは判りきっていることですから。
現時点でJPEG2000が「遅い」というのは紛れも無い事実ですし。

ただ、JPEG2000はPNGなんかよりもずっと小さいデータ量でlosslessを実現しているフォーマットであること、
lossyのジャンルでもJPEG並みのサイズで、JPEGがすっぽん以下に成り下がるほど高いクォリティを提供できること、
そういった点において既存のフォーマットの遥か上を行っていますから。
(2000と名乗る割りに登場がかなり遅くなりましたけどね。(^^;)
あ、言い忘れましたが、私もJPEG2000を高く評価しています。
近い将来、画像フォーマットのほとんどがJPEG2000に置き換わる日が必ず来ると確信していますから。
過去ログは一通り目を通しましたが、そういう部分は自分にとって価値が無いので飛ばして読んでしまったので、
過去にJPEG2000を推した人がどういう叩かれ方をしたかは知りませんけど。

問題(ボトルネック)の「圧縮展開のスピードが遅い」なんていう話も時代が解決します。
例えば今のご時勢、JPEGやらPNGの展開スピードを気にする人はほとんど居ないでしょう。
(最新機においては演算能力よりももっぱらストレージの遅さのほうがネックですからね)
そういう意味でフォーマット的に優れていることは非常に重要だと思っています。
まぁ、フォーマット的にJPEG2000が認められるのは、2007、2008、遅ければ2010年ぐらいの話かもしれませんね。
それまでは、一般的なフォーマットとして普及させるのは無理だろうな、と思っています。
個人用途的なレベルではもうJPEG2000は捨てられない存在ですケドね。

どちらかといえば、貴方のご発言にある、
>>今となってはマイノリティだが。
この発言のほうが気にかかりますよ。「今となっては」ではなく、「現時点では」でしょうに。(笑)
JPEG2000は言うなれば早すぎたフォーマット、これからのフォーマットですよ。
長くなってしまいましたが、今は何を言っても無意味だということはお判りください。
>>363さんのおっしゃるような返答が、世間的な一般論ですからね。
当面はIntelさんやAMDさんにがんばってもらいましょう。

>>366
フラクタル圧縮をなつかしんでる俺と、どこか似ているな、君。

>>367
フラクタル圧縮も考え的には素晴らしいものだと思いますよ。
ただ時代が若干、非可逆から可逆へと移行している所があって下火になってますが、
まだまだ消滅した圧縮法ではないと思います。懐かしむだなんてそんな、学術研究機関では世界的に未だに研究されてますよ。

サイズを抑えるとボケボケ、展開速度はJPEGの数倍、こんな糞フォーマットが
JPEGに取って代わるなどという事は未来永劫あり得ない。
まあ可逆としてなら使えなくもないが、それも数年は先だろうね。

>>366
>例えば今のご時勢、JPEGやらPNGの展開スピードを気にする人はほとんど居ないでしょう。
プログレjpgでさえ遅い重いと度々でているのに？
その上でrar圧縮でもしてあれば結構重いと思う人はいるだろうに。

個人的にはJPEGの展開速度は気になるな。特にマンガの場合は。
今は全てY1、ベースラインJPGに変換してるくらいだし。

JPEGとJPEG2kは圧縮方法が違うからJPEGの進化系と言うより別物だと認識してる。
全てのパターンでJPEG2kが優れるとは思わない。

10MHzの68000で開くjpegファイルは非常に遅かった。
縦500ピクセル程度だったのにな。

ビューワの実装に依存する部分も大きいしなぁ。
ミーヤだとページ先読みしてるせいか、
プログレだろうが縦1600だろうが一瞬で展開される。

ちなみに、手元にあった232ページのマンガ（プログレjpg）をミーヤで最初から最後まで一気にめくったら、
31秒かかった。
1ページ平均0.13秒。
環境はWin2k、Athlon2000、メモリ512Ｍ。

他のビューワ使ってる人、ちょっと試してもらえないかな？
めちゃくちゃ重いようなら少し考える。

あ、画像は縦1200で、原寸表示。
ウィンドウにあわせてスケーリングしたら37秒（0.16秒/p)かかった。

P2-300 256Mの身からしたら別次元だ・・・

>>373
ミーヤだと273枚で12秒くらい。
環境もそうだけど、jpgに依存する所が大きい。

ミーヤでは展開速度は
ベースライン << プログレ
Y1 << YCbCr 4:1:1: < 4:2:2 < 4:4
となっていて、SSEに対応させたjpg.dllを使っていると、
ベースライン/Y1のjpgなら一枚あたり12msくらいです。(ヘルプ - 画像情報でチェック)

環境WinXP/PenM 1.6Ghz/mem2GB

ミーヤのヘルプって詳細なんだなぁ。
確認したら、さっきの画像はYCbCr 4:1:1:だったorz

そういえば>>4にも
･グレースケール画像をjpgを出力するときは白黒もしくはグレースケールオプションをオンに。
　サイズ的には変わりないがjpgのロードが早くなるグレスケjpgになる。
って書いてあるし。

　写真屋以外でそのオプションがなければグレスケjpgは出力できない
ってことだが、藤で白黒化にチェック入れないとグレーでもYCbCr 4:1:1になってしまうのね。
カラーがまじってたので、チェックはずしたのが敗因か・・・

で、さっきの232枚、
非プログレY1で12秒(0.05秒/p)
プログレグレY1で19秒(0.08秒/p)
個人的には最初の31秒(0.13秒/p)でもストレスは感じてなかったので、
Y1にしておけばプログレでいいかな。

>>377
>写真屋以外でそのオプションがなければグレスケjpgは出力できない
そこで cjpeg -grayscale ですよ

ほぉー、こんなツールもあるのかぁ。
ぐぐってみたけど。ここでいいのかな？
ttp://hp.vector.co.jp/authors/VA010446/software2/

ずいぶん細かいオプションつけられるんですねぇ。
プログレjpgを最適化できるのはよさげ。
・・・ためしに使ってみたら、232ファイルで40kしかちぢまらなかったけど

sample 1x1だと、ブロックノイズが劇的に減ったり
・・・サイズも大きくなったけど

元々この分野は動画も見れないショボイPCユーザーが中心だったんだが随分変わったもんだな。

そりゃお前が始めるのが遅かっただけ
普通にこっちが先だったよ

こっちって何？？

三途の川の・・・

>>381
だれも早い遅いの話してないじゃんw

エプソン、高精細なゴミ・キズ除去が可能な「Digital ICE」搭載のスキャナー
ttp://arena.nikkeibp.co.jp/news/20050613/112476/
ttp://arena.nikkeibp.co.jp/news/20050613/112476/01v.jpg
ttp://arena.nikkeibp.co.jp/news/20050613/112476/02v.jpg
ttp://arena.nikkeibp.co.jp/news/20050613/112476/03v.jpg

エプソン、高速なゴミ除去機能“Digital ICE Lite”を搭載したフラットベッドスキャナー『GT-X750』など3製品を発表
ttp://ascii24.com/news/i/hard/article/2005/06/13/656373-000.html
ttp://ascii24.com/news/i/hard/article/2005/06/13/images/images776883.jpg
ttp://ascii24.com/news/i/hard/article/2005/06/13/images/images776882.jpg
ttp://ascii24.com/news/i/hard/article/2005/06/13/images/images776881.jpg

使い勝手も表現力も向上したグラフィックソフトの“王者” Adobe Photoshop CS2日本語版 アドビ システムズ
ttp://db.ascii24.com/db/review/soft/photoretouch/2005/06/13/656361-000.html

エプソン、フィルムスキャンに対応したフラットベッドスキャナ3機種
ttp://dc.watch.impress.co.jp/cda/accessories/2005/06/13/1724.html

Digital ICEを搭載した4,800dpiスキャナ「GT-X750」
ttp://dc.watch.impress.co.jp/cda/static/image/2005/06/13/epson1.jpg
ttp://www.i-love-epson.co.jp/products/scanner/gtx750/gtx7501.htm

オートフィルムローダを改良した「GT-F570」
ttp://dc.watch.impress.co.jp/cda/static/image/2005/06/13/epson2.jpg
ttp://www.i-love-epson.co.jp/products/scanner/f570_520/f570_5201.htm

フィルムスキャン対応のエントリー機「GT-F520」
ttp://dc.watch.impress.co.jp/cda/static/image/2005/06/13/epson3.jpg
ttp://www.i-love-epson.co.jp/products/scanner/f570_520/f570_5201.htm

>>386
読み込み速度はあまり変わってないようだね。
>>5の読み取り速度の表って誰かが実測したの？

駆動部がなくて全面にCCDでびっしりで板みたいなスキャナってないの？

>>388
http://hobby7.2ch.net/dcamera/
専用板がありますよ？

スキャナの設定を全く同じにしてるのに、取り込んだら明るさとかが全然違う時があるんだけど。
２Ｐ目はやたら白いのに３Ｐ目はやたら暗いとか。
これってなんで起こるかわかる？対処法とか誰か知らない？
ちなみにスキャナはＬｉＤＥ４０で、カラー200dpiで取り込んだ。

>390
「常に自動色調整を行う」にチェックが入ってるとか？

雑誌の場合物理的にインクの量が違うことあるよな。
ページごとに濃さが違うの。

>>390
俺もなるよ
原因わからないけど…

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>390
基本的にそういうものじゃないのか･･･?
逆にだから最終的に加工して調整する、みたいな
まあカラーページだったりするとそれも難しいが

ふた閉じずに黒板かなんかで押さえつけてスキャンしてると仮定して書くが、
黒板の押さえかたやスキャン原稿の置き位置かえれば光量の変化やら何やらで
同じ元原稿でもスキャンデータの明るさはいくらでも変わってくるよ
自動露出とか切るとまた変わってくるが、
それでも実際にセンサーに映る明るさが違うんだからまあ程度問題

個人的にBTScanへの要望として、タイマーでの連続取り込み時に毎回プレビュー
するようにできないだろうか?
エプソンのスキャナ実際にどうデータ処理してるかわからないが、
経験的な感覚からすると
最前のプレビューのデータからその後の取り込むデータの露出とか決めてる気がする
カラーページと白黒ページプレビューやり直さずに取り込むと
白黒ページの紙の色がえらい色になってたりするし･･･

補正切れ、とかちゃんと設定しろって罵倒はなしの方向で・・・
プレビューしながらスキャナに補正任せるのが結局一番きれいな気がするんよ
それが腕が悪い証拠？

カラーページプレビュー → スキャン×n → モノクロページプレビュー → スキャン×n
こんな感じですが・・・

いや、ちょっとならまだしも尋常じゃない差なんだよ。
カラーで取り込んだら２P時目はえっっらい勢いで地の紙の色が出てるけど
３P目は「このままグレスケ化するだけでよくね？」て感じの地色の飛びっぷりだったり。
元のデータ出せりゃよかったけど、捨てちゃった。すまん。

どうでもいい事をだらだら書いてるくせに必要な情報は一切書かない
典型的な初心者の質問だな

ttp://www.forest.impress.co.jp/article/2005/06/14/photofiltre.html
これも良さそうだな。

GT-F500買おうかと思ったけど520が出るまで待ってたほうがいいかな

500と比べてみてたいして性能かわらないなら500でいいんじゃね？

520が出たら500が安くなるってことではないか？

520 で 400dpi が速いんなら買い換えたいな。

カタログスペックだと　F500のほうが微妙に早いんだが
どうだろうね

しょぼいスキャナ使ってると、
・壊れるまで使う→ガイド付けたりアクリル板を切ったりして改造。
・買い換える→最新のスキャナを買う。改造はその後。
と言う選択肢がちらつく。

F500って400dpi遅いの？

F500が10k前後、F520が16k前後だな。
α-Hyper CCD IIとIじゃあ何が違うんだろね

>>395
そんな変更されたら困る
マジ勘弁

毎回勝手に色調整かけられるのが嫌でBT使ってるのに
大体カラーとモノクロを同じ行程に組み込むなんて正気のサタじゃないよ

>395
>最前のプレビューのデータからその後の取り込むデータの露出とか決めてる気がする

それが自動露出の機能だろ？なんか、なんか理解できてんのかできてないのか
よくわからん書き込みだなぁ。とりあえず自動露出は切れ。

週刊少年ジャンプ隔離避難所９
http://sakura03.bbspink.com/test/read.cgi/ascii2d/1118586280/

こちらのスレで
> ﾅﾙﾄのｺﾐｯｸｽを炊き直してて
> W6V氏みたいに表紙やｶﾗｰ絵も入れて放流したい思って
ジャンプの表紙捜してる人がいるらしいです。
> 2002年27号、39号
> 2003年5号、9号、20号、34号、42号
> 2004年10号、31号、37号
> 2005年27号
の表紙が希望らしいです。

持ってる人協力してあげてください。

わかった。




氏んでも炊くもんか。

一応手元には15巻相当分のカラーからならどっかに保存されてるはず。(表紙は無いけど)

が、、そんなに欲しいなら、オクか何かで探せばいいかと。ここで訊くことじゃない。

F500もだいぶ値段が下がってきたな。
そろそろ買い時だろうか

400dpi でのみ、なぜかモアレがでまくる本にぶつかった。
しかたがないので480dpiでとりなおし。F500の話だ。

520発売になったら、500が安くなるかと思いきや販売終了したりして。

少し上で色味が違うって話が出てるけど、それってキヤノン製ならではの、毎回調光するタイプ
なんじゃないかい？

散々酷使してる8400、全然壊れる気配なし。
意外と丈夫なんだなスキャナって。F500,520あたり少し欲しい気もするが
フラットベッド二台持ってても意味無いし。
フラットベッドの場合これ以上速度上がってもあんまり意味無いような・・・

スキャナのガラスの内側にゴミが入ってスキャンすると写ってしまうんだがスキャナって分解できたっけ？
ちなみに機種はGT8400

F500買っちゃった！
9800円

分解できない機械は無い

分解した後戻せるかが問題。

300dpiでスキャンしてるんだけど、藤で盾1200に縮小かける時に結構モアレが出る…
モアレ潰すのたるいんで、400dpiに変えればマシになるかな？

ちなみに藤の縮小方法はデフォルトです

藤以外のリサイザー試したらどうよ
Bitmap ResizerとかJTrimとか

>>421
スキャン時に透明のフィルムか薄いガラスを挟んでスキャンすればいいかも。
焦点距離が変わってモアレがなくなる。

と、今思いついたことを言ってみる。

>>421
輪郭強調するとモアレが出ることがある。

>>423
スキャンした時点ではモアレは出てないです
リサイズの時に出ます

>>422のを試してみます

スキャン時にモアレてたらそれはそれですごい

出るだろ

300dpiでスキャン⇒加工後、リサイズ手前で軽めにぼかしをかける。
リサイズ後にぼけが気にならないぐらいまで軽めでも、モアレ消えるはず

リサイズ後にモアレでるトーンはリサイズ前から色ムラが出てる
高めのdpiかモアレ防止で取り込めば防げるよ

それより実物さらしてくれたほうがわかりやすいけどね
補正が原因だったりシャープかけまくってモアレ出るとか騒いでるのもたまにいるし

正直、ﾀﾞｳｿ板で役に立つｽﾚは、ここと質問ｽﾚだけ

421だけど基本はここのテンプレ通り
補正は自動コントラストと藤で多少輝度とコントラストをいじる程度です
輝度（-10/260）、コントラスト（1.08）

シャープはかけるととんでもないことになるのでかけていません
モアレが出たトーンはガウスぼかしで対処してますが、最初からでなければスゲー楽なのに…

JTrim最強ということで

マンガの単行本だと元原稿の半分くらいに縮小されてるからねぇ。
単行本なら400dpiくらいあった方が安定する思うよ。

↓は文庫本の印刷によるトーン（175lpi?）を300dpiで取り込んだんだけど
ttp://www.imgup.org/file/iup45369.png.html

このくらい細かさだと取り込み段階でモアレの元凶が入ってしまう。
トーンを表現してるドットの大きさ自体は450dpi相当くらいか。
まぁマンガなら作者が60線くらいのスクリーントーンを使って、
飛んだり潰れたりしないようにしてくれてる。
雑誌サイズなら300dpiでモアレが出ることはないと思う。

ちなみにこれをミーヤで60％とか50％に縮小して、
スケールモード＞拡縮処理に〜を使う、でそれぞれの縮小フィルタの違いを見てみるとかなり差があることがわかる。
やっぱLanczosが一番安定してるみたい（藤のデフォルト）

そうはいっても藤でのリサイズはモアレでやすいのは事実。
写真屋が理想だよ、やっぱり。

いや事実とか詭弁の特徴ガイドラインみたいな言い切りされてもなあ
写真屋のバイリニアは2段リサイズしないとモアレ発生すること多いよ

Jtrimのリサイズは地味にいいと思うんだけどどうよ。

バイリニアなんかつかうなよ・・・

実際、藤でモアレがでて写真屋なら大丈夫って事が何度もあったから言ってんだけどな。
このスレでも何度か言われてることだよ。
別に信じないならそれでもいいけど。しょせん2chの情報だろうしね。

始めてJtrim使った
画像がマス目状になった・・・
これのスレってある？

boxじゃ

Lanczos3でも出ません？

>>436
BlastPNGの作者�dがJTrimのリサイズを目標に
チューニングしているくらいだしな

>>437
何度もあったって、どういう画像で何回あったってことを何も言ってないわけで。
それだけじゃあ
　詭弁のガイドライン：ごくまれな反例をとりあげる

って言われても仕方ない。
逆に写真屋でモアレの出る画像が藤でうまくいったケースが何回もあったぞ、と言われたらオシマイだし。
つまりサンプルplz

どーせ暇…ってわけでもないけど試してみた。
ソースを各種ソフトでリサイズだけしてみる。

ソース（BTでスキャンした後にホトショで適当に補正）
ttp://ranobe.com/up/updata/up42981.jpg
藤でリサイズ
ttp://ranobe.com/up/updata/up42982.jpg
Jtrimでリサイズ（Lanczos3)
ttp://ranobe.com/up/updata/up42983.jpg
ホトショでリサイズ（バイキュービック）
ttp://ranobe.com/up/updata/up42984.jpg

こうして見ると、あんまり違いは無くね？

>>437
間違い。バイキュービックでの話

>>443
比較したいならモアレ出やすい薄いトーンで結構差が出るよ
ただ藤も同じLanczos3のはずだけどJtrimだけ明らかに白い部分の階調つぶれてるね

俺は写真屋で2段階リサイズ。
色々やってみた末、これが一番安定している感があるから。
藤でリサイズ→升目
写真屋でリサイズ→モアレ
Irfan,ACDSee→昔すぎて覚えてない


>>442
＞何度もあったって、どういう画像で何回あったってことを何も言ってないわけで。
＝
＞詭弁のガイドライン：ごくまれな反例をとりあげる
＞って言われても仕方ない。

は少し強引。

写真屋、バイキュービックでも二段リサイズの方が良いの？
試してはみたがパッと見た目変わらんのだが。

>>447
モアレ発生するような時に2段リサイズが効果でる
藤の升目にしろ写真屋の一括リサイズでのモアレにしろ常にでるわけじゃなくて
たまに発生するものなんだけどそんなの全ページでチェックなんてやってられないからね

そっか、thx
リサイズはバッチ処理だから何の手間でもないし
これからは二段でやることにする。

初心者質問ですみませんが、２段リサイズっていうのは
例えば４０２０を１４００にしたいとき
４０２０→２７１０→１４００とするのでしょうか？

元サイズが4020で最終サイズが1400なら、中間サイズは2800じゃないかな。
基本的に中間サイズは最終サイズの整数倍にするのがこの2段階リサイズの特徴だと思う。

写真屋でぼかし(半径0.2)かけた後に足りないことに気づいて
更に半径0.1での処理を追加するという作業をよくやるんだけど、
これって最初から半径0.3でぼかしかけるのと同じ結果になるの？

一応比較してはみたけど見分けはつかなかったので
同じ結果に見えたけど……

一般に、フィルタや補間（拡大縮小）の類いの2度がけ・3度がけは、計算誤差や量子化誤差が
どんどん蓄積して画質劣化するから、やらないほうがいいかと。2段階の縮小でモアレが消える
というのも、ものすごく例外的な話だと思う。

縮小はデータの切捨て。半分にリサイズするとデータ量は1/4。
計算誤差、量子化誤差ってそれよりも大きいの？

まぁ、例外的なものであろうが結果的にまともになればいいので、2段階リサイズは重宝してるよ。
理論を大事にするより実践を大事にしたいしね。

>>451
そのソースある？
いままで中間サイズを整数割？にしてたんだけど
最終の整数倍のほうがいいかどうか比較したいんで

ttp://distantland.hp.infoseek.co.jp/comparison/resample/
Panorama Tools plug-in : Sinc256 (Lanczos-8)
が最強ということでよろしいか？
しかしバッチ処理ができないのは痛い

CZPだけで全てを語るというのはどうも。
あれは特殊事例すぎない？

2段階リサイズでモアレが消えるのは例外つーか、
モアレ以外の部分では劣化してそうな気がするんだが。
1発リサイズに比べて文字がボケっぽくなったりしてないか？

Lanczos-8とLanczos-16が藤で使えるようになる事を、祈ってます。

いや、ほんと…

>459
普通に考えれば、1発リサイズよりも2段階のほうが、参照する画素が多い分
きれいにリサイズできるはずだけど。

>>461
タップ数の多いフィルタで一回でリサイズする事とどう違うんだ?

雑誌スキャンは300dpiでもモアレ出るね
スキャナの除去フィルタ使うか最初から600で炊くか300で炊いた後加工するか。どれがベストだろうか。

>>461
嘘を言うな。
丸められた数値をまた丸めるんだぞ。

気になるなら自分で比較してみれば？
モアレ発生しなくても1回と2回は簡単に比べられるでしょ

>>463
俺も300だとリサイズ後にモアレが出る
400以上を試すかリサイズを縦1400にしようかな

Lanczos8・・・Lanczos3より7倍遅い。
Lanczos16・・・Lanczos3 より28倍遅い。
・・・使う人が余りにもいなさそうでコーディングをする気が起きません orz
そもそも参照点数を増やすとLanczos3の魅力であるエッジ保存性能を自分から捨てているようなものです。
本当に画質が良いと思うのか小一時間問い詰めたいです。

藤で升目になるならなるでいいですが、サンプルが出てこないと実装ミスなのか、Lanczos3の特性で発生しているのかわかりません。
サンプルをぷりーずです。
ちなみに、升目がでた時にINIファイルの FloatMode を1にしても発生したらLanczos3の特性だと思われます。
(速度度外視でバグりにくいコードになっているので。。。)

Lanczos3はバイキュービックよりもエッジの保存性能が高いのでそういったアーティファクトが出易いのは事実です。
でも、アーティファクトが出ない物を取るのか、アーティファクトの心配をしながらもエッジ保存性能を取るのかは人それぞれでいいとおもいます。

そもそも藤はLanczos3しか使えないわけではないので藤=升目じゃなくてLanczos3=升目といって欲しいです。
アルゴリズム切り替えのインタフェース用意してないからほとんどの人が変更しないってのは事実ですが。。。

近況です。
内部を各プレーン12bitのYCbCr(*1)にするための準備をちまちま進めていますが、土日両日休める日が最近ないのでいつコーディングし終わるかわかりません。
Wavleetを使ったノイズフィルタもその際に作る予定です。。。
(*1) 精度は12bitですが、16bitのメモリを消費します。3プレーンなので1ピクセル48bitで現在の倍の消費。4bitは計算途中の溢れ用。

以上です。

いつも乙です

>466
スキャンデータよく見るといい
ごく僅かにモアレ出てる場合がある

>>467
藤にはいつも御世話になってます。
個人的には藤でマス目が出た経験がないので、安心して使っています。
リサイズ前の補正の度合の影響が大きい気もしますね。

ちなみに>>433のサンプルをミーヤのフィルタで60％にすると、Lanczos以外だとマス目が発生します。

>>469
確かに元データをよく見るとうっすらとモアレの元になりそうな濃淡の差が出てます
300dpiモアレ除去で取り込んでたけど、解像度を上げるのが一番の解決策かな？

>>470
升目っていうのは白い部分に出る格子ノイズのことだぞ

─- ､::::;;;;;;;;;｀ﾞﾞ''‐ ､　 　 __,,,,......,,,,_／:::::::::/: !|　　　またまた　ご冗談を
　　. : : : : : : ｀ﾞ'ヽ､:::ﾞヾ´::::::::::::::::::::::｀ﾞﾞﾞ'''‐'､. l|
､､ . : : : : : : : : r'":::::::::::::::::::::::::,r':ぃ::::ヽ::::::::ヽ!　　　　　　　　　　　　　　　　　,､- ､
.ヽ:ﾞヽ; : : : : : :ノ:::::::::::::::::::::;;､-､､ﾞ::: 　 　 rｰ-:'､　　　　　　　　　　　　　 　 ／　　 }¬､
.　＼::ﾞ､: : : :./::::::::::::::;､-''"::::::::::　　　,...,:::,::.,　:::':､　　　　　　　　　　　　_,,/,,　 ,､.,/ 　 }
　　　ヽ:ヽ､ /:::::::::::::::::::::::::　 　 　_　　｀ﾞ''‐''"　 __,,',,,,___　　　　　　　／~　　 ヾ::::ﾂ,､-/
　　　　 ｀ヽ､:::::::::;;;､､--‐‐'''''',,iﾆ-　　　 _|　　､-l､,},,　 ￣""'''¬-, '　 ''‐-､ .,ﾉ'ﾞ,i';;;;ﾂ
　　　_,,,､-‐l'''"´:::::::'　　,､-'" ,.X,_,,､-v'"''ﾞ''yr-ヽ / ﾞﾞ'ヽ､,　　　 ,.'　　　 　 jﾞ,,, ´　7
,､-''"　　 　.l:::::::::::;､-''"　 ,.-'　　ﾞ､""ヾ'r-;;:l　　冫、 　 　 ヽ､ /　 　 __,,.ノ:::::ヽ. /
　　　　　　　l;､-'ﾞ:　　 ,／　　　 　 ゞ=‐'"~ﾞﾞ')　./.　＼　　　　/　　'''"/::::;:::;r-''‐ヽ
　　　　　,､‐ﾞ ヽ:::::..,.r'ﾞ　　　　　　　　 ,,. ,r／ ./　　　 ヽ.　　 ,'　　 　 '､ノ''"　　　ﾉ

　　　　　　　　 　 　 . ｨ
._ .......､._　　　 _　／:/l!
　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　_　　　　またまたご冗談を
ﾞ､'､::::::ﾉ:::::::_,.-=.　 _〜:、 　 　 　 　 ／_.}'':,
　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._　／_ﾞ''iﾞﾉ､ﾉ
　,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､　,:'　　ﾉﾞﾉﾌﾞ
"　　 .!-'",／　 `'-‐'') /＼　`/　てﾞノ-〈
　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.,'　　 ~　／
　　 ／/:::::　　　　 　 ',　 　 /　　　 ,:'ﾞ

　　　　 　 ,.ｨ
''==ｧ-‐‐,'ﾞ<l　　　　_,,　　　ご冗談を
`､:/::r'ﾞﾞ'_ｪ'ﾞﾞi､._ ／ﾗﾉ
,=キﾂﾞ `'ラ/ヾ/ (ｼﾌ
　 ,ｹ::　　　',. /　 ,:'ﾞ

ｰ;-‐<{
X,.^ｬ~ﾄ β　　　冗ﾆｬﾝを

*

ｰ;-‐<{
X,.^ｬ~ﾄ /3　　　冗ﾆｬﾝを

突っ込みどころ有ったら、おながいします。
・拾い物を結合
・エロ
ttp://www.angelfire.com/comics/kokuchi000/f48_060_0.jpg

>>477
manse?

>>477
リサイズ後だから大変だったとは思うけど一応

壁の色がそろってない
へんな数字が残ってる
ツールのタッチ跡が微妙に残ってる

ノンブルは残さね？

数字はページ数だと思うけど、見開きにページ表示があった場合、消す人いるの？

あえて言うなら、体のラインの繋ぎ目の補修が甘いかな、と…

どうでもいいけど、深田拓士のキャラを見ていると、巌窟王を思い出す。

いあー、拾い物でこれだけできれば立派なもんでしょ。

てか、自分で結合って言ってるし、
58の数字がページ数だから、そのちょい左が結合部分だろうな、って予想できるから繋ぎ目がなんとかわかる。
もし数字を消して、結合部分が真中にこないようにトリミングしたものを出されてたら、
どこが結合部分か探すのはけっこうタイヘンだったと思う。
職人名乗っても恥ずかしくない出来かと。

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

02.半余談
これらは、RGBモードでのレベル補正・トーンカーブ処理はRGB成分それぞれに対して等しく補正してるのに比べ、
人間の目に見える明るさ、ここで言う輝度は RGBを足して3で割った数値ではなく、

Y(輝度) = 0.2990×R + 0.5870×G + 0.1140×B

というグレースケールで観ているため、それぞれの成分に同処理をすると、
色相がずれてしまうようになっているからである。
(カラーをグレースケール化する時は、この計算式で算出している)

ちなみに、飛びすぎた明るい部分だけ下げたければ、PhotoshopのLabモードに切り替えて、
描画色を白(FFFFFF)に指定→色域指定(許容量150位)→レベル補正でガンマ値を0.8-0.6程度にさげると、
肌のグラデーションが自然な感じに戻った感じになる。
---------------------------------------------------------------------------
出来たらハッシュテンプレ入りしたら嬉しい。雑誌等カラーの補正がきつい人が結構いるから。
元々は自動斜め補正ツール予定なので、トーンカーブとか入れて欲しいとか要望あれば切り分けるかするかも。
susie入力、PNG出力対応した。

>>482
>>477はそんな感想を求めてるんじゃ無いと思う

壁の色修正と結合甘めな部分
ttp://r.skr.jp/10240/files/8650.jpg

ﾃｨｸﾋﾞだけは、(；´д｀)ﾊｧﾊｧしながら一生懸命つなげますタ。(w
今は、ﾓﾉｸﾛを違和感無く繋げるのが一番難しいと感じながら
技量の向上に邁進しております。

御指摘有難うございました。
これからも、修行に励むであります!!　（｀д´）ゞ　ﾋﾞｼｨｯ!!

あｄｇ

プログレッシブってビデオカードの性能で表示速度に差が出るのか？
うちの環境だとものすごもっさりなんだがな。
非プログレ＞ポぱっ
プログレ＞ポチッ・・・んぱっ

>>488
微妙にスレ違いっぽいが、ポチッ・・・んぱっの環境が知りたい

>>483
RGBでの補正の仕方おかしくないか？
いじってみたけどそんなコントラストきつい画像にならなかったぞ
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050626155836183.jpg

>>488
とりあえず使ったビューアと画像のサイズ・色数を書いてけれ。
ミーヤならヘルプ＞画像情報でロード時間なんかがわかるが、
縦1200・グレスケ・プログレッシブならAthron600M+GeoForce2MXなんて組み合わせでも、
0.15秒くらいだったぞ。

ただ、色数が256色でもグレースケールjpgになってないと、ムダに時間がかかるな。
イキナリ0.4秒くらいになる。
グレースケールのフリして色数9000色で縦1500とか、もうね・・・

>>490
分かりやすいように多少コントラスト強めにしたかもしれない。
雑誌のカラーとか、もっと強いのがある。完全に肌の色が飛んでるのとか。
まあ、どの程度のコントラストでやったのか分からないけど、同じ設定値で輝度補正しても違いは出るが。

なんの知識もなく交換ネタの量産だけが目的
藤の初期値がプログレだからそのままリサイズ
もちろん白黒化なんてチェックもしない
こんな地雷が結構多いってことなんじゃね？

>>493
多いね。
だから機会を見てはグレスケ止めろといってるんだけど、みんなアホだから聞かない。
ミーヤで処理して云々言ってるような奴らは特にヤバイ、そいつらの頭も。

>>494
グレスケ止めろ？

>>494の頭も特にヤバイ

>>483
ソース画像を拝見させて頂きましたが、残念ながらPhotoShopで排出された画像でありながら、ICCプロファイルを持っていない画像でしたので、
貴方が実際に見ていらっしゃる画像と同じ見え方をしているかどうかがわからず判断がつきませんでした。
コントラスト補正は、着眼点が違えば結果もかなり違ってくるので、貴方のお作りになったものも、>>491さんがお作りになったものも、
そういう意味においては、どちらも正しいのではと思っております。ことカラー画像は見え方に左右されやすいので。
その上での発言としてお受け取りください。

一般の方が貴方のお作りになった成果物(輝度補正を加えられた物です)を、マンガミーヤに代表されるフリーのViewerで閲覧した場合、

ttp://ranobe.sakuratan.com/up/updata/up43421.jpg

のように見えているはずですが、これで間違いはありませんか？

(PhotoShop上で閲覧しても間違いが無いように、敢えてICCプロファイルを追加させてもらいました。
それ以外は手を加えていないので、閲覧にPhotoShopを使用しない限り、up43299.jpgと同じものとして見えるはずです)

貴方のPhotoShopの環境がわからないので正確なことはいえませんが、デフォルトのPhotoShopは一般の閲覧環境であるsRGBではなくAdobeRGBという色空間で物を表現しますので、
ソースの時点で既に食い違いが出ていないかと思いまして。
もし、AdobeRGBが正しいプロファイルであれば、本来こう見えるはずです。

ttp://ranobe.sakuratan.com/up/updata/up43422.jpg

(ものがAdobeRGBであると仮定して、ソースとしてupしてくださった画像に無理やりICCプロファイルを履かせ、sRGBとして出力したものです。
マンガミーヤのようなツールを用いても、AdobeRGBとして取り込まれたものとしての結果と同等に見ることができます)
プロファイルの差し替え以外は何一つ変更は加えていません。

もしこれが正しければ、この時点でオリジナル(紙面)とかなり酷似しているはずであり、ソースが比較的きれいに見受けられましたので、これ以上の補正はあまり必要ではないかとも思いますが、
今回のお話は「コントラスト補正」ということなので、貴方の方針に合わせて更にYCbCr空間に叩き込んだ上で、Y軸に関して正規化補正を掛けた物を作ってみました。

ttp://ranobe.sakuratan.com/up/updata/up43423.jpg

いかがでしょうか。
最初のものが作者様の意図されたものと同じであるならば、この話題そのものが無意味ですが、
(そうならば、忘れてください。元の紙面を(原作がどういうタイトルであるかすら)全く知らずに発言させていただいてますので、正直あまり自信がありません。)
もし後者が本来意図されたものであるならば、補正云々以前の部分で問題が出ます。
その場合はどちらかといえば、早急にICCプロファイルハンドリングの実装が必要になるのではと思ったのが、今回の一連の書き込みです。

今はlittleCMSというプロファイルに関する非常に便利なライブラリが存在するのでそのあたりの導入も検討されてはいかがでしょうか?
ttp://www.littlecms.com

長々と失礼しました。

すみません、些細なことですが、>>491さんではなく>>490さんでしたね。

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

すいません、訂正。
最初のソースの輝度は27-226が最小値と最大値でした。
のだめ のソースが40-230でした。

それと、結局最初のものが自分の補正したものと一致してるので、
ちょっと自分も無意味な事を書いてるかもしれません。。ーー；；

トーンカーブ処理が出来れば、もうちょっと色んな違いが説明出来るのですが、
輝度に近い明度での補正の、Labモードでの補正との違いを検討してみるのもいいかもしれませんね。

取りあえず、カラーで色飛びしてるのとか良く見かけるので、こういった話題を提起してみました。
同時に、デフォのテンプレにあれば、もう少し全体的に改善されるんじゃないかと思ったもので・・・。

>>500

BMP読み込めないんだけど...

>>501
カラーの調整とか全然出来ないんでいつもﾌｫﾄｼｮ自動色調整。
なんかこの話題がうまいこと実を結んだら
初心者にも出来る簡単でオススメな色補正のﾃﾝﾌﾟﾚ期待しています。

>>500
書き方がまずかったかもしれません。申し訳ないです。
>結局最初のものが自分の補正したものと一致してる
いえ、一致していただかないと話が共有できないので、それで問題ありません。
そういうわけで今回の私の話は、「取り越し苦労」(要するに「余計なお世話」)で型がついたようでなによりだと思っています。
(ただ敢えて申し上げれば、使っていただく方(ユーザーの方)がsRGBの環境で作業をしていただけるかどうかが判らない、という懸念は若干残りますが。)

わざわざ新しいサンプルをupしていただいたようで、大変恐縮です。

なるほど、Y軸に対して上下同値の減算を掛ける手法を選択されているわけですね？
赤が良い感じに強調されていて、なかなか綺麗に仕上がっていると感じました。
こうして改めて実例を見ると、この方法は非常に良いですね。

私のほうでは、正規化で削られる量を前提として、それに対する掛け算という形で実装をしてみていたので、
(もしかしたら既にお試しになっているかもしれませんが)
手間もかからずすく出来るものですし、せっかくなので参考程度にアップしてみました。

http://ranobe.sakuratan.com/up/updata/up43462.jpg

ソースに当たる画像をY軸に関して見た場合に、レンジが24-241と出たので、
Y軸に対し下24,上14を削ることを基準に、その1.4倍、24*1.4=34,14*1.4=20として、34-235のレンジで補正を掛けさせてみました。
別に1.4という数値には特に理由はありません、この辺が綺麗かなと思っただけで・・・
ま、「こういう切り方も面白いかも」というただの余談です。
こうすることでチョット視覚感度を重要視したつもりではいたんですが、あまり良い結果にはならなかったようです。

P.S.
傾き補正がどういうアルゴリズムで実装をされてくるか、とても興味をもっております。
できあがった暁には、出来ればでかまいませんが、
実プログラムの方もどこかにアップしていただけるととてもうれしいです。
(個人的な話で恐縮ですが、当方、MXやNYというものには手を出していないもので、その手の流通手段しかないと試すに試せないので・・・)

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>504
なるほど、、そういう補正をかけることも出来るのですね。
参考にさせていただきます。まだまだ画像処理への知識は疎いもので。。
他にもフォトショのフィルタには無い(？)細線化など行く行くは追加していきたいなとも考えてます。

ttp://strawberry.web-sv.com/cgi/up/ia/up12892.zip.html
ここに、同じGradiatorという名前で以前作った自動斜め補正ツールをうｐしました。
入力にJPEG, RGB BMPと、出力に同様の対応しかしてないのと、非常に遅いという開発段階で
ソースが消えてしまったため、一から作り直しているところです。
バッチ処理なので、動画エンコと同様、放置しておけばいい(途中中断不可)なら使い物になる程度です。

アルゴリズム自体はいたって単純なので、それをあとは実装するだけです。
E.Cのように回転処理などに高速化出来るかはやってみないと分かりませんが。

なんかへんな流れになってるな
RGBだとカラーバランス崩れは不可避なのか補正値がおかしいだけなのかって問題じゃなかったの？

調べた限り写真屋のRGBが妙な動きをするけどそれ以外のソフトではそんなことは起きてない
写真屋は独自設定多いからそのあたり無視してRGBが悪いっての決めつけするのはどうかなあ
雑誌カラーが飛んでるとかってのはその職人の補正がまずいだけじゃね？

>>500さん
乙です。
あと苺は直リンできませんよ。

カラーで色飛ってどんな状態？
サンプルとまではいかなくても、わかりやすい例え下さい

古いのだと焼けあるからスキャンと実物みて比べなければ
正しい色というのがわからない気もするなあ。

おしえてください。
写真屋の7.0を使ってるんですが、バッチ処理の際に
｢ファイル名を変えずに別フォルダに保存｣なんてのはできるんでしょうか？
どうしてもやり方がわからないので・・・

アクションに保存先を組み込めばいいよ

>>511

ありがとうございます。
別フォルダに保存する方法はわかりました。

あとはファイル名を変えない方法なんですが、先ほどは私の言葉が足りませんでしたので、補足です。
たとえばひとつのフォルダにa001.jpg b03.jpg ccc.jpg とかいうファイルがある状態で
フォルダごとバッチ処理したいとき、新たに連番のファイル名を指定してやらないと自動処理ができなくて。
元のファイル名が連番になっていれば別に問題ないんですが・・・・
これが仕様なのかなぁ。

＞フォルダごとバッチ処理したいとき、新たに連番のファイル名を指定してやらないと自動処理ができなくて。
うーん、普通にそのままのファイル名で出力されるんだけどね。
ありそうなのは
「バッチ→"別名で保存"を省略」
にチェックとかかな。

>>509
ttp://ranobe.sakuratan.com/up/updata/up43496.jpg (プロファイル入れ忘れたかも)
あまり鳥付きの人のを挙げたくないんですが、こういうのとか。
赤チャンネルを観ればグレースケールで白く飛んでるのが分かるかと。
上の挙げた
ttp://ranobe.sakuratan.com/up/updata/up43449.jpg
これもその例の一つだったんですけどね。黄色と赤が強烈です。

>>507
上に書いた通りフォトショはＲＧＢ並行処理なので、
他のソフトは自分のツールのように輝度か明度で補正してるのかもです。
なので、職人の補正がフォトショのRGBモードで補正してる、というのが大きな原因ということで。
RGBが悪いのではなく、"フォトショのRGBモードで補正すること"が正確ですね。

要するに、写真屋でカラー画像を補正する場合はLabモードにしとけって事でいいんでしょ？

Labモードで補正する場合、16bitチャンネルにしたほうがいいのですか？

写真にアンシャープをかける補正の説明してたＨＰに書かれてたような・・・

なんかめんどくさいこと議論してるのでよくわからんが
>514のってトーンカーブで文字の色を黒くなるよう調整したから
他の色も濃くなっただけなんじゃないの？

ｽｷｬﾅ付属のPhotoStudio2000使ってセコセコやってるのって、
漏れだけなんだろうなぁ（´・ω・｀)ｵｶﾈ、ﾅｲｼ…

>>506のどっか別にうｐしてもらえませんか｡･ﾟ･つДT)･ﾟ･｡
苺きついっす・・・

ttp://para-site.net/up/data/2963.zip こっちにもうｐしておいた。

ちなみに、Labモードでもいいと思う。ただ、どうせやるなら輝度補正の方がいいかと思っただけで。
自分もこれを作るまではLabモードで補正してたし。
ただ、色空間をLabモードで、、って言われて分からない人も結構居そうな気もするから、
ツールに突っ込んで輝度補正に正規化して終わりの方が楽かなと。

>>514
ﾄﾝｸｽﾝ

黒レベルみたいに好みの範疇なのか、だめという明確な基準があるのか、
趣味でやってるレベルでは、見ても何が悪いかわからんです
とりあえず写真屋でRBGはやめたらいいのかな・・・？

ありがとうございます！感謝です

写真屋でのカラー補正はLabモードで、というのはテンプレ入れるべきだね。
ところで、正規化ってイマイチどういう処理なのか掴めないんだけど、何？

前の議論が難しくてよくわからなかったんだけど、
要するにプログレ化はしないほうがいいの？

>>523
>写真屋でのカラー補正はLabモードで、というのはテンプレ入れるべきだね。
小難しくてよく判らないのだけれど、おまじないみたいなものと考えていいの？
RGBだろうがなんだろうがトーンカーブいじれば
結局「飛び」という状態になるような気がするんだけど勘違いかいな。
原本に近づけつつの補正もあれば、鮮やかさを主としたい奴もいるのではないかな、と思ったり。

それともフォトショのRGBだと保存時に見えてる状態と、決定的に異なる画像で保存されるのかな？
無知でｽﾏｿﾝ

RGB 均等に輝度を動かすと色合いが変わってしまう。
Labモードなら色合いは変わらない、という理解でいいのかな？

Labモードの欠点は、白飛ばししても、薄い色とかが残る。
明度LはRGBそれぞれの最大値だから、仕方ないんだけど。
その点、輝度補正は白飛ばしした部分に色が残らないって相違点がありますね。

で、正規化ってのはソースのRangeが(例えば輝度が)最小値-最大値：27-235だとしたら、
それをを0-255に飽和するってこと。(多分。。)

>>525
>>484 みたいな感じだけど、イメージ掴みづらいかな。
JPEGで保存する場合はプロファイルってのを一緒に保存すれば同じように見えるはず。

>>524
プログレ化しても読み込み速度は問題ない（Athron600Mでも0.15秒）
サイズが一冊（60Ｍくらい）炊くと4〜5Ｍ小さくなる。

それよりグレスケ化しない方が問題(Athron600Mだと0.4秒〜）

ってカンジかと。

そういえばグレスケ化って一般的に、
モードをグレースケール化にすることを指してる？
それともやっぱチャンネルミキサーで擬似グレスケ化すること？

俺は後者の方と思ってるしそうしてるんだが、
たまーにホントにグレースケールモードになってるのがあって、
しかもそういうのに限って未補正で、読みやすいように補正しようとしたら
モード変更からしなきゃならなかったり。

前者では

ファイルフォーマットの話だろ。ﾎﾞｹｪ〜

>>494=529？

グレスケとグレチキは似てる

>>532
それはNO。

写真屋でチャンネルミキサーからモノクロ化、補正後
そのままRGB8bitのまま処理終わらせてるのって
実はマズかったりするのかな。
最後にRGB→グレースケールにモード変更したほうがいいの？

グレースケールかRGBで画質が変わると思ってることがまず間違い
つぎに画像がRGBかグレースケールかがグレスケ化(グレスケjpg)の方法だと思ってることが勘違い
写真屋がグレースケールの画像の時にグレスケjpgで出力してるだけ。
RGBだろうがグレースケールだろうが単なるjpgで出力したら24bitになる
逆もまた同じ

よく言ってる事が分からないのだけど、
取りあえず写真屋の「グレースケールモード」の時に出力したのがグレスケ(8bit)JPEGってことでしょう。
535と534は良く分からない。。

チャンネルミキサーだけじゃ8bit化されないからグレスケモードにして出力しようということじゃ。

写真屋が特別な処理をしてるのに写真屋基準で考えるから理解できなくなる。
jpgとグレースケールjpgは違うファイルフォーマットなんだよ
グレースケールの時に写真屋がgifで出力してくれたとしてもグレースケール＝gifとはいわんだろ

そういう勘違いしてると8bitのbmpを藤で白黒化にチェックせずにjpg出力して
グレスケ化してると勘違いする奴がでてくる

わからん人は、藤で白黒化にチェックつけてjpg化すればＯＫ。

確認はミーヤで開いて、ヘルプ＞画像情報で出るダイアログのその他の欄を見る。
Y1になってればＯＫ。
YCbCrはカラーのまま。

グレースケールjpgって要するにインデックスカラーの事だと思ってたが、違うのか

パレットデータの無い、色決めうちのインデックスカラーと言えないこともない。

藤で白黒化したものは、
写真屋で見ると8bitグレースケールモードなんだね。
つまり写真屋のチャンネルミキサーでモノクロ化したJPEGは擬似グレスケで、
それが「グレスケjpg」と呼ばれるものという認識で合ってるのかな。
だからどっちが良いとかでなくどっちでも良いが、
ただ、グレースケール化といったら基本的には
藤で白黒化したもののような画像を指す、と。
で、
グレスケjpg→RGB, パレット情報が残ってる, 写真屋特有の処理
グレースケール→グレースケール, 完全に白黒化, 大抵のツールではこれ


……あー何か親切に教えてもらってるのに間違ってたら馬鹿でごめん。
確かに>>537の言うとおり、写真屋だけ使ってると、
藤とか使ってみたくても感覚的に何か違ってて、
これまでよく分からなくて手が出せなかったんだ…

違う。

・グレスケ化＝グレースケールjpgでの出力

グレースケールjpgで出力できる条件

1．RGB画像をグレスケjpgで出力→○
2．グレースケール画像をグレスケjpgで出力→○
3．RGB画像をjpgで出力→×
4．グレースケール画像をjpgで出力→×

写真屋ではjpgで保存すると画像のモードにあわせて自動的に2か3が選ばれるから
グレースケールモードでのjpg保存＝グレスケjpg出力＝グレスケ化になる
藤は白黒化にチェックを入れるとjpgの出力オプションが1or2の状態になるから
どんな画像であってもグレスケ化される

写真屋のチャンネルミキサーでモノクロ化したというのはRGBだから
3を選んでいることになってグレスケ化にはならない。

つぎにjpgとグレスケjpgは画質的にはかわりない(本当は微妙に色合いは違う)けれども
画像のロード時間がグレスケjpgのほうが普通のjpgに比べて圧倒的に早い＆サイズも微妙に小さい
だから白黒画像はグレスケjpg出力＝グレスケ化することが推奨されてる

>>540
無茶を言うな。インデックスの意味知ってるのか？

>>538
やばっ自分で炊いたの確認したら巻ごとにバラバラだった....orz
ここでチャンネルミキサーでのやり方を覚えてからjpeg保存の前に、巻ごとにモード変更したり
しなかったりしてたんだなぁ...反省。

>>544
グレースケールPNGの規格書とかは日本語訳でているから見てみなよ。
パレットのないインデックスカラー。

>>543の
＞(本当は微妙に色合いは違う)

グレスケjpgがY(輝度情報)だけを非可逆圧縮して格納。
フルカラーjpgはYの他にCbCrも保存するが、使用している色がグレースケールだからCbCrは全部ゼロだろう。
結局Yについてだけ圧縮してるようなもんだから、同じソフト同じ品質なら同じ結果になりそうな気がしたんで、検証してみた。

で、検証しようと思って藤でグレスケpngをjpg化したら、
イキナリ800色のカラー画像になった件について。
bmp化したら27色になるとか、わけわかめ〜


ヘルプの隠れ設定の項の

＞PNGRead
＞内蔵のPNG読み込み機能を無効に出来ます。
＞グレイスケール PNG で一部問題が発生するようですが、無効にすることによって Susie Plug-in 経由で読み込むことが出来ます。

て、こういうイミだったのか。
藤でグレスケPNG使う人は必ずSusiePlugin使いましょう・・・

しょうがないので、まずPaintShopProでやってみたよ（写真屋ない）。

1.グレスケpng -> グレスケjpg・品質85プログレで保存（YCbCrをミーヤで確認）
　　　 -> 開きなおして24ビット化 -> BMPで保存
2.グレスケpng -> 24ビット化 -> 普通のjpg・品質85プログレで保存（Y1をミーヤで確認）
　　　 -> 開きなおしてBMPで保存

1、2でできたBMPファイルのCRCを比較。
完全一致でした。
PSPでは、グレスケと普通のjpg圧縮で画像に差はない模様。

藤はグレスケpngがダメポなのでグレスケbmpで。

1.グレスケ(8ビットパレット）bmp -> 品質85・プログレ・白黒化・ダウンサンプリングなしでグレスケjpg保存（Y1をミーヤで確認）
　　　　->PSPで開いて24ビット化 -> bmp保存
2.グレスケ(8ビットパレット）bmp -> 品質85・プログレ・ダウンサンプリングなしでjpg保存（YCbCrをミーヤで確認）
　　　 -> PSPで開いてbmp保存

1と2のCRCを比較。
一致しなかった。
念のため、jpgをPSPで開いてスポイトツールで色を比べてみたが、
グレスケjpgの方が1〜2程度暗かった。

まぁ、jpegの品質と圧縮率に関してはソフトごとにバラバラな状況をみると、
jpeg規格に品質・圧縮率に関しては規定はないっぽい。
グレスケとフルカラーのようにフォーマットが変わった場合、
同じ品質で同じ圧縮をするかしないかはソフト次第ってことかしらん。

バグっぽい気がしないでもない？

同じ画像をjpgとグレスケjpgにしたときに差が生じるのだから
bmpに変換してから比べてもだめだよ

>>548の
（〜をミーヤで確認）が逆ですたorz

>>550
藤では差が生じましたが、
PSPでは生じなかった、という結果です

なるほど。藤のjpg出力オプションの問題なのかもしれないね
写真屋もRGBからグレースケールに変換すると色が微妙に変化するけど同じ原因なのかな

>541
君は、PCの基本的な事を理解していないようだね。
上で何度もファイルフォーマットという言葉が出ていますが分かりますか？
最終出力形態が重要という事ですよ。
自分の使用しているアプリの動作がどうたらこうたらなんて考え方で物事を見る事自体が間違いです。
PCの基本動作を理解していれば、どんなアプリを使用しようがどういう処理を経て
最終的に出力するファイルのフォーマットで望みのものが得られるかどうかが分かる筈です。
もう少し精進を。MS-DOSとかコマンドライクなOSは使用したことが無いのかな？

何だか懐かしい流れだな。
まぁゆっくり考えて自分で作ってみたら分かると思うよ。

>>553
写真屋でも色が変わるなら、むしろPSPの方がヘンという可能性もアリですなー＿|￣|○

>556
そもそも、その実験の根拠が？なんですけど。
jpegって、非可逆圧縮ですよね？
jpegローダの種類によっても、展開の画質に明らかな差異を生じます。
昔は、画質の良いjpegローダが発表される度に狂喜乱舞したものですｗ

すげぇ分かりやすい説明マジthx
ファイルフォーマットについては理解してるが
画像ファイルについてのそれが、概念的なところで躓いてる感じだ。

とりあえずこれからは、過程の最後でちゃんとグレスケ化することにする。
試してみたら、確かに色合いは少し変わるけど
300k弱のファイルが270k台にまで容量減ったし、
全体的に読み込みも早くなるんなら
バッチの行程ひとつ増やすくらいやらなきゃだよな。

>>527
LabモードのLは、輝度だよ。ヘルプにも明記されてる。
ただ、算出の式は 0.2990×R + 0.5870×G + 0.1140×B　ではないみたい。
参照：　http://ofo.jp/osakana/cgtips/grayscale.phtml

だから、輝度補正とLabモードでの補正は、基準となる値が微妙に違うだけで
同じ事をしてるはず・・・

>516
Labモード使う場合、RGBとの変換で多少誤差がでるから、Labに切り替える前に
16bitに切り替えるのがいいっていう話だと思う。

>>544
パレットのないインデックスカラー、の意味をよく考えてみた？
インデックスってのは、画素ごとに0〜255の値が入っているわけだよね？
んで、その数字をパレットの参照として使うのではなく、そのまま輝度として扱うわけ。
だから、パレット自体は存在しない。そういう話。

cjpegで追試してきました。
オプション　-grayscaleのアリなしでできるjpgのサイズとフォーマットは違いますが（当然）、
bmp化してCRCを比較すると一致しました。

やはりソフト次第ってことなのかなぁ・・・ﾜｶﾗﾈ( ´Д`)

>>557
すいません、うまく説明できそうにないので、詳しい人に聞いてください。
てか、たいした検証でもないので忘れてください。

>>543の
＞(本当は微妙に色合いは違う)
あら、これってCRCレベルの話だったのか。
てっきりRGBからグレスケに変換する前と後の色数の表現(2^24と2^8)で
「微妙に違う」意味合いかと思ったよ。
また難しい話になってるなｗ

>>560
パレットを参照するために割り振られた番号がインデックスなのに
パレットを持たないインデックス？何それ？

>>562
あー、一応、検証の意義としましては、
今までフルカラーjpgで保存していた人も、
色が変わらないならグレスケjpgにすることになんの問題もないってことで、
スムーズに移行できるかなぁ、ということでした。

結果はメジャーな藤（と>>553さんによれば写真屋も）で色が変わり、
マイナーなPSPとcjpegで同じ色という微妙な結果に・・・( ´∀`)σ)∀`)

>>563
インデックスをパレットの参照として使うのではなく、そのまま輝度として扱うんだってば。
ちゃんと理解しようとして読んでくれてる？

>>565
だから、それをインデックスカラーとは言わないと言ってるんだよ
そもそもインデックスカラー＝パレットカラーだろうが

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>559
度々ｽﾏｿ。
フォトショでは(というか規格自体)YUVまたはYCrCbのY輝度とは違うのは了解の上でだったのね。
16bitでLabを扱う位なら、もうカラー補正で輝度云々話す必要性も無さそうだけど。。−−；

インデックスカラーについてだけど、定義については
「あらかじめ選んで通し番号をつけておき、色の指定に番号を用いる色表現方式」
とIT用語辞典で書いてたため、インデックスカラーと呼ぶのはおかしいね。とおもた。

>>566
頭固いなぁ・・・別にどうでもいいよそんなこと。もともと言えない事もないってだけの話なんだし。
そうだね、偶然使用する領域や値が同じなだけで、全然別のものだよね。うんうん、そうだよね。

>567
そのページの最後の分は、俺がさっき>559であげた参照で述べてる事を指してるのでは？

あ、リロードすればよかった・・・ｽﾏﾝです

言えない事も無いんじゃなくて、言えないんだよ
俺の頭が固いのではなくて、君の頭が悪いのよ

>>564
えーと写真屋で色が変わるのはRGB(インデックスカラー)とグレースケールの相互変換時ね
jpg出力時にはかわらないよ
藤は以前bmpの白黒化のときにも似たようなことあったから作者さんこのスレみてるみたいだし
もしかすると直してくれるかも

>>571
小さなことに粘着するねぇ。
なんかインデックスカラーに思い入れでもあるの？

グレスケ化っていつすりゃいいの？
チャンネルミキサーで色飛ばした直後？保存の直前？

チャンネルミキサで疑似化したなら、ラストでいいと思うよ

あんたいいやつだな。thx

>>573
いや、単に君みたいに自分の間違いを認められないクズが嫌いなだけだよ

どっちが正しいか誰か白黒つけてやってくれ。ﾁｬﾝﾁｬﾝ

>>572
Photoshopは内部ではカラーを16ビットで処理してるらしい。
ttp://blog.movie-db.jp/article_832.html

RGB（16ビット階調）＞グレイスケール（8ビット階調）変換で切り捨て誤差みたいなのが出るんかね。

＞jpg出力時にはかわらないよ
そうすると、グレスケjpgで色が変わるのは藤だけか。
仕様なのかバグなのか・・・
正直、輝度が1くらいズレてもわからないんだけど、他の処理でも悪さしてるかもしれないからなぁ。

8bitデータはパレットデータがなくてもインデックスカラーと呼んでいい？
呼ぶよ派 ─┬─ 輝度が暗黙のパレットだよ派
　 　 　 　 　 │
　 　 　 　 　 ├─ 0〜255だけの色定義なんて無いよ派
　 　 　 　 　 │
　 　 　 　 　 ├─ 呼んでもいいし呼ばなくてもいいよ派（中立派）
　 　 　 　 　 │
　 　 　 　 　 └─ パレットデータが無い場合はファイルフォーマット上で決められた数値がパレットだよ派
　 　 　 　 　 　 　　　　│
　 　 　 　 　　　　　　　└─ そもそも全てのデータが24bitパレットカラーだよ派（過激派）
呼ばないよ派── パレットデータが無いのにインデックスというのは無意味だよ派
　　　　　 　 　 　 　 │
　 　　　　　 　 　 　 └─ パレットカラー=インデックスカラーだよ派
その他派　 ┬─ 小さな事に粘着するねぇ派
　　　　　 　 │
　 　　　　　 └─ どっちが正しいか誰か白黒つけてやってくれ。ﾁｬﾝﾁｬﾝ派　 　 　　　

その他派に「よくわかんないからとりあえず放置だよ派」も入れてくれ。

そうするとテンプレのこの表現はどうなるんだ？

＞･グレースケール画像をjpgを出力するときは白黒もしくはグレースケールオプションをオンに。
　サイズ的には変わりないがjpgのロードが早くなるグレスケjpgになる。
　写真屋以外でそのオプションがなければグレスケjpgは出力できない
　グレスケ画像は256色の白黒画像、グレスケjpgは256色までの白黒パレットの画像なので別物

パレットと明言してないか…

そういえば、グレースケールJPEGって、ファイル内でパレット保持する部分あるの？

もしあったとしたら、逆にグレスケ以外で使えないのがまた不思議なんだけど。はて。

とりあえず、>577はささいな事でも青筋立てて間違いを正さないと気がすまない
粘着君ということはわかった。
まずは、自分の頭が固いのくらい認めなさいよ。楽になるよ。

>583
JPEGにパレット部分なんて無いよ。モノクロ256階調で表現してるから8ビットですむってだけ。
同じ画像の場合にグレースケールjpgとカラーのjpgでファイルサイズがあまり変わらないのは可逆圧縮でフォローしているから。

539 名前： [名無し]さん(bin+cue).rar [sage] 投稿日： 2005/06/28(火) 17:24:23 ID:Wzl/FdWm0
フルカラーjpgって要するにインデックスカラーの事だと思ってたが、違うのか

540 名前： [名無し]さん(bin+cue).rar [sage] 投稿日： 2005/06/28(火) 17:34:49 ID:A8NKLwrw0
パレットデータの無い、色決めうちのインデックスカラーと言えないこともない。

544 名前： [名無し]さん(bin+cue).rar [sage] 投稿日： 2005/06/28(火) 19:16:14 ID:25ERZYSB0
>>540
無茶を言うな。インデックスの意味知ってるのか？

560 名前： [名無し]さん(bin+cue).rar [sage] 投稿日： 2005/06/28(火) 21:33:04 ID:G2O/Rnkn0
>>544
パレットのないインデックスカラー、の意味をよく考えてみた？
インデックスってのは、画素ごとに0〜16777215の値が入っているわけだよね？
んで、その数字をパレットの参照として使うのではなく、そのままYCｂCrとして扱うわけ。
だから、パレット自体は存在しない。そういう話。

>>586
そもそも全てのデータが24bitパレットカラーだよ派（過激派）かよ！

>>560
パレットのないインデックスカラーというのは
黒-白が0-255に割り当てられていて
圧縮側と展開側はその約束を知っているので
ファイルの中にその情報を持っていなくても
展開側は取り出した0-255に対して黒-白を割り当て直せる
と言う話だろ

例えば、0-255が黒-白の順番ではなくゴチャ混ぜでも
それが圧縮側と展開側の共通の約束ならば許される

非可逆のJPGに使う言葉じゃない

もういいよ・・・

ああ、パレットとかインデックスとか言葉尻捕まえて罵り合うのは本当に無意味だな。

もういい…もういいんだ…

正直なんの話だかわからんヤツ挙手
ﾉｼ


まあ確かに普段からカラー原稿しか扱ってないけど……
なんの話かさっぱりだｼｮﾎﾞｰﾝ

ﾉｼ

自分初心者ですから！

とりあえずグレスケjpgにする方法と出来たブツがちゃんとグレスケjpgになってるか確認する方法を知っていれば問題ないはずだ

もう「コミック･雑誌･書籍等のスキャン方法や画像加工技術を語り合うスレ」じゃなくなってる(´･ω･｀)

厚さ5�oアクリル板が近所のドイトに売ってない…。3�oならあるけど
どこか練馬周辺で5�oアクリル板売ってるところって無い？

スキャンするのがB5程度なら、ダイソーの100円アクリル板がいいんじゃね？
厚さが足りないなら買い足して張り合わせるだけ

>>549
バグでした。 ⊂(｡Д｡⊂⌒｀つ
左シフトするところで右シフトしてた orz

ttp://hp.vector.co.jp/authors/VA015850/software/public_test/wisteria2441u.zip

TPNGImageのページに
29/06/2005 - ** NEW VERSION COMING SOON **
とあるので、近くpng系のバグが直るかもしれません。ちょっと期待。

>>596
3?汞｡のでいいじゃん。

グレースケールでこんなにあれるなんて
JPEGのグレスケ程度で理解できないならTIFFのグレスケなんか論外だね

整理
JPEGグレースケール
8bit(0-255)グレースケールのみ、明示的なパレットはないがWindowsの実装上（内部では基本BMP）
パレットの存在しない8bit画像は存在しない
RGB(0,0,0)→RGB(255,255,255)のパレットを読み込み時に割り当て
ファイル上にパレットはないがパレット画像と言えないこともない

グレースケール化
・フルカラー→グレースケール、輝度のみの情報に減じる
・輝度の表し方は色々な定義があるので一定ではない
・アプリ内部での取り扱い（8bit、16bit、色空間）によっては同じ画像を同じように処理しても結果は異なる

もうグレスケパレット論争やめん？
自炊とあんまり関係ないし。

別にグレースケールでは荒れてはいない
パレットかパレットじゃないかで言い争いしてる奴が2人いるだけ

おまえら、
>>598
に注目しているか？

当然
ﾁﾝ☆⌒ 凵＼(＼･∀･) まだぁ? とかやって焦らせるのもなんだしな

なんか全然分からんので、これが推奨とされる結論と
初心者でも地雷にならないであろうやり方のﾃﾝﾌﾟﾚが早く出来ないかなと待っている。

は？

写真屋で補正その他もろもろ処理する場合
チャンネルミキサーでモノクロにしてから処理、
一番最後にモードをグレースケールに変換。

これでいいんじゃない？グレスケ化に関しては

カラーの話はどこへ？

>>600
原稿の…なんていうだろ、ゴワゴワっていうか普通の蓋だとなんか微妙に浮き上がっちゃう部分ってあるじゃない。
あれをピシーッと平たく伸ばしてスキャンするためなんだけど3�oでいける？

>610
1ﾍﾟｰｼﾞずつなら、十分いけるよ
蓋の重みも加わるしね

>>611
ありがとん！

3mmあれば簡単には曲がらないのでそれ以上の厚さを求めるより
上から押さえる重石になるものを用意したほうが良いかと

俺は25枚組のCD-Rスピンドルを重し兼取っ手にしてる

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

それって、本当、個人的な意見だよね？

で、↑の人は原本忠実派って事でいいのかな？
そういう人はもしかしたらそれでいいのかも知れないけど、PCで見ることを前提として考慮している
俺としては、多少色味が変わっても、見易さと快適さを求めたいんだけど。
あんまし、意見を片側に傾けられても困るっぽ。
もっと多彩な方向の意見が欲しい。

ちなみに、俺はRGBモードでトーンカーブを使って曇りとコントラストを調整する程度。
(RGB設定はsRGB

>>616
別に、色味を変えたりしたければ、後から色相・彩度等で変えればいいんだよ。
だけど、最初からRGBモードで補正しちゃうと、それが出来ないってことが結構重要。

あと、
＞曇りとコントラストを調整する程度
なら別に構わないんじゃないかな。そうでない、色飛び・色ずれしてるのがあるから話題提起されたわけで。
グレスケモードと同じ感覚で強めにコントラストかけてる人とかが結構いるからテンプレに入れた方がいいというだけ。
まあ、厳密に原本忠実に・・・ってのもあるけど。
それでもRGBモードでやりたければ、それはそれで構わないでしょう。
実際、自分もテンプレに従ってない部分は結構あるし。

個人的かどうかは、、分からない。どのくらい同じように感じてる人が居るか、だね。
同意見は結構あったつもり。

テンプレに入れる話と自分の好みの補正値と自ツールの紹介を一緒くたにしないほうがいいよ
後者2つは押しつけがましく感じる人いるから荒れる元
今のテンプレに補正値のお勧め設定がないのも同じ理由

補正値というか補正の仕方ね。他にもLabモード推奨って人いたけどな。
(補正値は正規化の時の数値のことを指していると観ているけど、あってるかな？)
自ツールは、あくまで輝度補正するツールが無かったから作っただけ・・・。
確かに一緒にはしたくないんだが。

例えば 縮小は藤推奨とか、加工２の「白を飛ばして黒を強調」とか程度だと思ってる。
あくまで、地雷避け・より綺麗に(好みも入る)ということでの推奨。　草々

テンプレに入れるなら
「連載時カラーのモノクロ化ページは、
他のページと同じ補正をせず処理を変える（コミック限定）」
とかを入れてくれ。

全部自動補正かけてるのか真っ黒だったり、
もとが薄いのに他のページと同じ調子で飛ばすから薄々だったり。
「最後にビューワで確認とかしてたら何か思うだろ」、
というのが最近多い。

自分のやり方を自分で推奨してる時点で何だかな

本当に優れたやり方なら、自分でマンセーしなくても、
他者が自ずから追従するものだよ
自分マンセーは見苦しい

補正値ってのは

＞フリーならバッチ処理と正規化等を組み込まれたら輝度補正ツールで補正した方がいいかなと。
＞両方とも、補正後に色相・彩度で彩度を少しあげると丁度良いくらい。

このことじゃね？
レベル補正をRGB使わないのは賛成だけどその文章じゃ自分のツールを使えって書いてあるようにみえるし

>>620
その文章だと、カラーをモノクロ化したグレスケページについてと思われるんだけど・・・？？
じゃなくて、RGB24bitフルカラーのカラーページについて書いたつもりなんだが。。

特に自分ﾏﾝｾｰってわけじゃないし、>>622 のようにRGBでレベル補正不向きと言ってる人も居る(ここ以外でも)。
実際に検証した結果、Labモード・輝度補正を推奨化したいということで。
それと、別に自分のツールを使えとは言わんのだけど、現状として輝度を扱って処理するものが全然無い。
フォトショでやるならLabモードでいいと思ってる。フリーで藤みたいにバッチ処理をしたいなら使えばいいってだけで。
Labモードって？どうやって切り替えるの？とかそう言う人向けだし。

>>623
いやいや、俺は別件。
RGBとかの話は特に重要とは思ってないので(>>616と大体同じ意見)、
テンプレに入れるなら「これはどうよ？(620)」という感じで言っただけ。


結構気になっていた部分なんだけど、
Lab・輝度の話に埋もれて消えていりそうな気が・・・(；´Д`)

てすと

カラーバランスが崩れるのを防ぎたいだけで輝度補正をしたいわけじゃないよ
ためした限りではPSPも藤のlmapもカラーバランス崩れてなかった
写真屋が特殊なんじゃないの？

>>624
理解。誤解してた。
微妙だね。それならカラーは当然一緒に入れていいと思うし。
けど、元連載時カラーのページだって分からない人も居るから好み編に入るのかな。
地雷避けってほどじゃあないだろうし。

自分も、カラーに気を配るくらいだから、連載時カラーのモノクロページに関しては別処理をしてるよ。
カラーバランスについては他の使ってないけどフォトショが特殊なのかもね。
だとしたらLabモードを使おうってだけでいいかもな。

>元連載時カラーのページだって分からない人も居るから好み編に入るのかな。
>地雷避けってほどじゃあないだろうし。
いや、普通はわかるでしょ。
RGB・Labで処理した画像の判別はできない俺でもわかる。

簡単に言えば普通のページが
「黒いじりすぎて服の線や文字・表情と、トーン・ベタとが判別できない」
「とばしすぎてトーンなくなってる」
てのと同じ。内容的に数ページは今まで挙げられてきた「地雷」ではある。


>微妙だね。それならカラーは当然一緒に入れていいと思うし。
ここがどうもしっくりこないんだけど
>>483,500,514の画像はどこらへんが地雷よ？
自分がテンプレ化ｷﾎﾞﾝして
別の意見を「地雷避けってほどじゃあないだろうし」
ていうのなら当然RGBカラー補正は地雷なんだよね？
RGB・Lab補正かどうかはわからないけど、
表紙なんかでセル画のような人がいてあれは違和感を覚える。
でも別に地雷ではないんじゃないか、と思う。
自動補正で色が変な事になってたらまずいとは思うけど、それは補正の仕方の問題。
ソースと色合いが違うっていうならRGB・輝度正規化のやつも結構変わってる。
輝度のほうが落ち着いて見えるけど、それも好みなんだろよ。

意見としてはなんとなく似ている気もしなくもない気がしてきたけど
なんでこう自分の意見だけ・・・
なんか矛盾というか釈然としないものを感じたので多少語気を荒げた。
ｺﾞﾐﾝ

気になる部分や許容範囲、
またその程度の差ってのは人それぞれだしね。
テンプレ化して共通基準にしようとしたら、
総意を得るのは大変だし、内容を決めるのは中々難しいよね…

>>628
その「普通」が分からない。それはカラー補正に関してもそうなんだけど。
前述したとおり、連載時カラーのをグレスケ化したのを判別出来ない人も確かに居る。
その人が普通じゃないならそれはそれで、そう解釈するけど、
他のページと同様の処理をしても大して地雷にならないケースもある。やり方次第じゃないかと思うんですが。

ソース自体がトーン無くなってるのだから、普通に処理して、
白飛び等にさえ気を遣えば地雷にはならないと思ったんだけど、
今まで挙げられてきたものってのを知らないから、その辺は判断出来ないです。

カラーの地雷云々に関しては「RGB・Labで処理した画像の判別はできない」以上、
色飛びしてるだの、RGB各チャンネル成分のグレスケ言ってもあまり意味無さそうだけど、
好みの問題でもあるとの意見から、好み編でもいいかと思った。
けれど、本当は上に挙げた色飛び、色合い変化は地雷の元とでも言うか。。(地雷に近い地雷？)
加減を間違えれば >>514(これは地雷扱い) のようになってしまうと言いたかったのです・・・。

相変わらず自分マンセーなんだな
自分のやり方が絶対で他人が間違えてるっていう
自信に満ち溢れた態度は、ある意味で尊敬すら覚えるが、
それゆえにテンプレ化は無理だろう
己の態度を省みることから始めなさい

>>631
省みを試みるから、どの辺が自己ﾏﾝｾｰ？
他人のやり方は否定したつもりはないのだけど。

>514が地雷？地雷の定義を間違えてないかい？

>>632
(*･ω･)(*-ω-)(*･ω･)(*-ω-)ｳﾝｳﾝ♪
ずっとその調子でレスしてくれｗ
そして荒らして俺を楽しませてくれｗ

>>630
話がかみ合わんなあ。
連載時カラーかわかる人でやってない人はやって貰えたらいい。
>他のページと同様の処理をしても大して地雷にならないケースもある。やり方次第じゃないかと思うんですが。
そのとおり。でも上でも書いてるけど
(>>620 )
>全部自動補正かけてるのか真っ黒だったり、
>もとが薄いのに他のページと同じ調子で飛ばすから薄々だったり。
>最後にビューワで確認とかしてたら何か思うだろ
ぐらいのレベルの話。あまり人の話は聞かないほうか？
連載時カラーがわからなくても
ビューワで気にならない人はそういう人なんだからどうしようもないでしょ。

>>635
ｽﾏｿ、確かにあまり良く読んでなかったかもしれない。
＞連載時カラーかわかる人でやってない人はやって貰えたらいい。
>全部自動補正かけてるのか真っ黒だったり、
>もとが薄いのに他のページと同じ調子で飛ばすから薄々だったり。
うん、その通りだね。
ただ、全部自動設定だったら他のページまで地雷になりそうだけど、そこのところはどうなってるんだろう。
自動設定やってる時点で、カラーページだったかどうかを判別するか微妙な気もする。

>>633
カラーでどの位が地雷かサンプルか何かあったら観たい。

俺は元カラーページは、バッチを使わず
レベル補正もトーンカーブも一枚ごとに処理してるよ。
カラーだった頃の塗りの名残で
全体的に濃いページと薄いページとがあったりするから、
「元カラーページ用」とかでバッチを組むみたいな
ひとくくりにしての処理はいい仕上がりにはなりにくいと思うし。

>>635が言ってるのは、テンプレに入れることで
このへんに注意を喚起しるのはどうかというでないかと思うんだけど。

最後の行、
というでないか→ということでないか
だった

ということは、カラーをそのままグレスケ化したみたいに、
暗い部分はガンマ値挙げて露出上げたりとかしてるのかな・・・？
あまりそう言うのを観たことが無いから観てみたい。それとも気づかないぐらい自然に補正してるのばっか観てるのか。

テンプレに関しては了解。

>632
ぜんぜん自己マンセとは思わんが、知識や画像の出来に関する要求レベルを自分基準にしてるのが拙いのでは？
ココには「読めれば良い」ぐらいで炊くヤツから「保存用に1冊5〜10時間かける」ってヤツまで居るわけで…。
テンプレといえば「最低これぐらいはやっとけ」って意味合いが強いので、そこを>632のレベル基準で編集すれば、
「感性的に画質が余り気にならないヤツ」や「知識がなくて話がよくわからないヤツ」は
「テンプレすらクリアできないヤツ」と定義付けられてしまう訳で…。

オレは話し聞いてちょうど為になるぐらいの位置なんで話し自体はありがたいけど、
オレもテンプレに入れるのは無理でなかろうかと思う。
「RGB・Labうんぬん」言う前に、結構な割合のヤツがまずモニタのキャリブレーションでもするほうがずっと先という状態な気が…。。
せっかくの話が流れて消えてしまうのはもったいないけど、初歩的処理からよりやる気と暇のあるヤツ向けの処理まで
有用な話をまとめてHP運営でもしてくれる神の出現を願うしか…と人任せなオレ…。

むぅ…間抜けなレスになった…寝て忘れよう…オヤスミ…。

>>640
参考にします。
自他共に辛口とは言われるし、そう思う。
てことでテンプレ化は無理てことで。おやすみ。

>>632
自分の注意書きの最後に
＞適当にまとめてテンプレ化した方がいいね。

他人の提案に対して
＞けど、元連載時カラーのページだって分からない人も居るから好み編に入るのかな。

テンプレ希望どころかいれること指示しておいて他人の提案を自分の一存で却下
要求するレベルがとかそういうことじゃなくてもっと根本的なところで間違ってるよ

>>643
自分の一存で却下してるわけじゃなくて、テンプレ化は無理だと思った。それだけだよ。
テンプレ化するならそれはそれでいいと思うけど、今までの流れだと無理だという意見が多いからそう書いた。
別にテンプレ化しなくていいよという意味では無いです。

好み編については、必須編ほどじゃないだろうという事を意味して書きました。

ぶっちゃけた話カラーなんて版が違うどころか同じ版でさえ結構違う。
何度も間違えて同じ本を買い見比べた俺だからわかる。
そんなこだわるだけ時間の無駄だよ。

知識として、写真屋でカラー画像を補正するならLabモードにしとけ、というのが
テンプレにあるのは別にかまわないでしょ。

自分のツールをテンプレ入れてくれってのがちょっとねー。
それに、そのツール自体まだ全然未完成でしょ？宣伝する前に早く開発すすめなよ。
出来がよければ、黙ってても使う人も増えてそのうちテンプレ入るよ。

いや、別にPaintShopPro(？)とか藤で輝度補正出来るならそれで構わないけど。
藤だとヒストグラムで確認できないのが難点かもしれないが。
なので、ツールまでテンプレ化は最終的に出来上がって使いやすければ入るといいな程度です。
(最初は藤とかでも出来ないかと思ってたので、途中から少し変わってます)

Labモードのテンプレ化は正直、無理・反対(？)なのと、あってもいいとで
自分ではどう切り返せばいいのか分からん状態だけど、
上の方に貼った画像の違いでここにいる人で判断して貰うしか無いですね。
もう書くことは書いたと思うし。

一応開発は進めてます。自炊の方もあるから、そんな速く進められない。
これが終わったらメインの斜め補正の方を進める予定です。
テンプレに貼られる位のものに仕上げられたらと思います。

>>646
だいたい同意だが
便利なツール作ろうとしてる人がいるのはありがたい話だ。
書き込む前に感謝の心を忘れてはならん。

>>644
ｺﾞﾒﾝｺﾞﾒﾝ。
ちょっと勘違いしてた。
>(テンプレに入れるのは)微妙だね。
>けど、元連載時カラーのページだって分からない人も居るから
>(「スキャン技術･加工編1 - 必須」というより「スキャン技術･加工編2 - )好み(」)編に
>(分類するとしたら)入るのかな。
テンプレは無理だろうけど入れるとしたら、
みたいに先の話してたんだよね？


>けど、元連載時カラーのページだって分からない人も居るから
>(その人たちのことを考慮したら、 それは個人的な)好み編に入るのかな。
>地雷避けってほどじゃあないだろうし(テンプレは無理じゃない？)。
そっちは個人の好みじゃない？、ぐらいだと思ってた。
「好み編」という言葉がわかんなかったよ。
「必須編」が出てきて理解しました。

拙い文章でｽﾏｿ。。どうも板に書き込むと思うように文が書けないな。。

傾き補正ってバッチに組み込めないかな？
石便利だけどいちいち手直しﾏﾝﾄﾞｸｾ

まぁ、W6VjIfnC33氏もがんばってツール作ったんだし、そう責めてやるな

自業自得

他人を否定して自分ばかり持ち上げるからだ
まさに自業自得だな

ついでに言えばW6VjIfnC33氏はもう黙ってればいいと思う
W6VjIfnC33氏が黙ってても、氏の言うことが主流派になれば
勝手にテンプレ化もされるだろうしな

流れが読めんな…
なんでその鳥を連呼する必要がある？
なんかのネガティブキャンペーン？

職人があっちのスレで出てくるようになったのは
W6V氏に責任の一旦はある気がするな。
氏が頻繁に出てた後、
乞食が持ち上げまくってるのをみて勘違いした厨職人が
コメント付きでハッシュ貼ってるのみてﾜﾗﾀ
犯罪意識＜自己顕示欲なんだよな。

今まで出てきたツール作ったのはW6V氏

うｐされた画像が氏の自炊物ってことから想像してるわけか？

別に誰だろうが構いやしないとは思うが
氏のトリップで流れてるわけでもあるまいし
敢えて呼称するなら作者名の「じるち」と呼べばいいだろうに

名指しで個人の職人叩きとはこのスレも堕ちたものだな・・・

このスレに最初から期待することなんかないよ。
キモイっつーの

まあ表紙のソースを2つ上げてたら本人と思われちゃうな
もし「じるち」氏が別人で関係ない人(=W6V氏)のを出して
色々と自分のツールや色補正の講釈いってたら
そんな人の作ったツールはなんか嫌ですよ
友達って落ちかな

ってか、MXの子鯖のほうでW6V氏が自分の自炊物と一緒に自炊フォルダにそれらのツールも共有してるしな。

やぶへび

このスレはやたらと進むのが早いけど、有用な情報はほとんど出てこないな。

よくわからんがW6VjIfnC33ってのは何？

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

>>656
>>659
アホすぎ

> v2.46.0 #170 2005/07/02
> TPNGImage を 1.5 に更新。

LMap 利用者は一回起動した後に wisteria.ini をチェックして下さい。

写真集の神々がコミックの見開きつないだら、すごい上手いんだろうか？
写真集の見開きはつなぎ目がわからないのが多いんだが。

写真集って、見開きの補間の必要が無いものばかりだからなー

>>668
藤ばーじょんあぷキター！

＞v2.41.5 #161 〜 v2.46.0 #170 2005/07/02
＞TPNGImage を 1.5 に更新。
＞コマンドラインパラメータにディレクトリを渡すことが出来るようにした。
＞zlib を DLL 利用に変更し、1.2.2 にバージョンアップ。
＞「更新日時を写す」で更新日時だけではなく、作成日時をコピーするように変更。
＞GIF 画像の読み込みと書き出しに対応。
＞%c を追加。
＞貼り付けの Ctrl+V のショートカットを削除。

更新履歴を見ると、6/29から3つビルドしてたようで。
乙彼さまです。

個人的には
＞コマンドラインパラメータにディレクトリを渡すことが出来るようにした。
がちょっと嬉しかったり。

グレスケｊpgについては書いてないね

>>671
自ページの掲示板で依頼されたビルド以外はここで告知しているんですけどね（＾＾；
>>599 >>668 のことですが。

>>672
あれはグレスケJPEGのバグではなく白黒化のバグなのでした（＾＾；

あのー、ﾏｶｰで自炊してる方ってやっぱ補正は写真屋さんだけでやってます？

>>674
私はそうです。といっても、傾き補正もよほどでない限りしてないので
全体的にかなり手は抜いてる方ですが…
よく使うのはガウスぼかし、ダスト&スクラッチ、トーンカーブ、アンシャープマスク
あとNeat Imageのプラグインを入れて試行錯誤しながら使ってます。

あとはこのスレで以前に紹介されてた"rm JPEG extra"で
よけいなデータ削除するくらいですね。

lmap が隠し機能になったのかな？
知る人ぞ知る機能を使えるって、なんとなく優越感があったりして。

ヘルプの本体からの起動とlmapのGUIでの設定をぜひ・・・

突っ込みどころ有ったら、おながいします

※拾い物を結合
※元：縦1500　→　加工：縦1200　にしてます
※エロ

ttp://vladimir.ddo.jp:8888/cgi-bin/upload2/src/pic8719.jpg

かわいくない

>675
よろしければ、ダスト&スクラッチの使い方をご教示ください。

>>680
グレースケールで描かれた場合のムラをならす目的で使っています。
ガウスぼかし(半径0.5)の後、半径1しきい値10で。
(値は取込時の状態にもよるので参考程度に…)

ただ副作用として中間色が白黒に逃げるので、
後でトーンカーブで中間色に寄せる必要が有り、邪道かもしれません。

>681
なるほど、参考になりました。ありがとうございます。

>>678
左わき腹のトーンの繋ぎ目付近と、すぐ上の制服の繋ぎ目を徹底したら問題無いんじゃない？

>>678
左足についてる機械？の枠部分の線が糊がついてるのか色が薄くなってる

こんだけ結合で来てれば十分合格だと思う


てゆーかぱっと見じゃ>>683-684なしには結合部分を見つけられなかったorz

ScanSnapで取り込んだjpg画像（容量およそ2〜3M）をE.Cやこみこんぶでトリミングしようとすると
「このコマンドを実行するのに十分な記憶域がありません。」
と表示されて実行できません。

スキャンするのは初めてでよくわからないのですが、BMP画像以外は小さな画像しか処理できない
のでしょうか？

ソフト次第。

アプリのメモリを置いてるドライブの容量かPC自体のメモリ、
多分前者が足りないんじゃね？
2〜3Mのjpgなら300〜400dpiの取り込みだろうけど
写真屋の場合だと最低10G以上空いてないと
複数枚同時に開いての処理が辛いことあるし。

>683-685
位置合わせた後の、トーンの目違いを直すのが非常にムズくて(´･ω･｀)ｼｮﾎﾞｰﾝっす
結局、ｺﾋﾟｰｽﾀﾝﾌﾟでﾁﾏﾁﾏﾁﾏﾁﾏ……。orz

もうチョット腕磨くっす。
御意見、有難う御座いました。

うーん、ドライブの空き容量は50G以上あるしPCのメモリも１Gあるんですが…

こうなったらIrfanViewでトリミングするしかないのかな(´･ω･｀)
傾き補正ができないのは痛いけど…

なにが悪いか問題切り分けないとだめだよ
jpgがだめでbmpなら大丈夫なのか、仮想メモリは足りてるのかetc
bmp以外は〜ってことはbmpで大丈夫なら問題は別にある

とりあえず色々試してみましたが…

BMPに変更　→　出来そうに見えてやっぱり駄目
画像を縮小　→　これは正常に変更できる
スキャンしたもの以外の2メガ以上の画像　→　これも変更できる

どういう仕組みなのか(´Д｀； ）
ほかの場所で落とした画像は巨大なサイズでも処理できるんですけど…
スキャンした画像のみ処理してくれません。

>>692
PCの構成とOS、取り込みサイズ等を一通り晒してみるのが最初。
後出しジャンケンみたいなのは良くない。

2〜3Gだったりして(まさかねえ)

(´･ω･｀)ｽﾏｿ…

DELLのDimension8300でメモリは1G、HDは120GB。
OSはWinXP.Service2の最新版（常に最新のものをインストールしている）
取り込みサイズはScanSnap fi-5110EOX2のエクセレント（最高）モードで2.5〜4M


ネットで拾った画像ならいくらでも加工できたのに…

これ以上はスレ違いじゃないかな。

そういやXPのSP2入れてないこと思い出した。
入れたほうがいいのか？

あー俺も入れてないや。
別に入れなくてもよくね？

age

保守協力よろしく♪

MX一般コミックスレ 第23巻
http://tmp5.2ch.net/test/read.cgi/download/1120500304/

ECだと3200x4800の画像が保存できないのですが、
同じように特定のサイズによるものということはないでしょうか？

>>694
5110EOX3有るから後で試してみよう

>>675
同じﾏｶｰとしてお聞きしたいんですが
最終的に写真屋さんで保存する時は圧縮比どれくらいで保存してますか？
"rm JPEG extra"と言うのは知らなかったんで使ってみる事にします。

キヤノン、フラットベッドスキャナ2機種
〜ファイル管理ソフトを同梱
ttp://pc.watch.impress.co.jp/docs/2005/0705/canon.htm

CanoScan 5400F
ttp://pc.watch.impress.co.jp/docs/2005/0705/canon_1.gif
ttp://cweb.canon.jp/canoscan/lineup/5400f/

CanoScan LiDE 60
ttp://pc.watch.impress.co.jp/docs/2005/0705/canon_2.jpg
ttp://cweb.canon.jp/canoscan/lineup/lide60/

キヤノン、透過原稿の逆光補正が可能な『CanoScan 5400F』など、フラットベッドスキャナー2製品を発表
ttp://ascii24.com/news/i/hard/article/2005/07/05/656787-000.html
ttp://ascii24.com/news/i/hard/article/2005/07/05/images/images779309.jpg
ttp://ascii24.com/news/i/hard/article/2005/07/05/images/images779317.jpg
ttp://ascii24.com/news/i/hard/article/2005/07/05/images/images779310.jpg
ttp://ascii24.com/news/i/hard/article/2005/07/05/images/images779311.jpg
ttp://ascii24.com/news/i/hard/article/2005/07/05/images/images779313.jpg

キヤノン、高速2400dpiスキャン対応のフラットベッドスキャナなど2製品
ttp://www.itmedia.co.jp/pcupdate/articles/0507/05/news011.html

>>702
私は、気持ち余裕を持って 画質:8 のjpgにしています。
(一応取込時無加工の状態もpngで保存して、DVDに焼いています。)

閲覧する際に、モニタ解像度に合わせた縮小表示で見る分には
もう少し圧縮率を上げても気にならないかもしれませんが、
原寸で見た場合、これ以上圧縮率を上げると
特に台詞の文字周りのノイズが目立ち始める気がします。

静止画のW6、動画のaaL、ダウンロード板のNo1職人

aaLさんは職人達の共有鳥って聞いたが。

okidokezwg が共有トリップ
aaLPbRVQ8B　も構成員の一人です。

W6がNo1てあり得ないし

>>705-708
坊や荒れるからやめような

逮捕に最も近いNo1なら納得だ。

>>710
言えてる
目立ちすぎるのもどうかな、と
自分が自炊職人なら、殆ど話題に上らない地味な存在のほうがいいね

トリップ付けなければ目立たないよ

>>705-712
保守協力よろしく♪

MX一般コミックスレ 第23巻
http://tmp5.2ch.net/test/read.cgi/download/1120500304/

afoka

自炊始めてから買う雑誌の量が多くなったんだが…。
なんか矛盾してる（ﾉ∀｀）ｱﾁｬｰ

>>715
ん？なんで矛盾？
自炊の理由が金銭的な節約のみだったってこと？

ゴメ。おれの書き込み意味不明。
吊ってくる。

>715
漏れは同人の自炊してるんですが…
やっぱり、始める前に比べて同様に増加してるです。orz

炊いたら、その数だけ購入しても良い！　と、決めれば良いのだよ。

漏れは無理だけどナー

完成した後はZipとかに纏めるわけだけど、どうせならコミックに向いたコンテナって無いものかね。
どうせ無圧縮だしさ、綴じ方向とか作者情報とかをタグみたいに記録できたら便利じゃないかと思うんだが。

マンガミーヤにそんなのあった気がする。

傾き補正バッチ処理にできないかなぁ．

傾き検出用基準線を先に指定しておいて後は放置でパーっと．

>>720
そういうのいいね
アーカイブってのはさすがに難易度高そうだから情報ファイルみたいなのとか
んでマンガミーヤとLeeyesでみるときにそれを読み込んでくれたり

作者・掲載雑誌・初版発行年度・第○版・ジャンル・文庫版とかID3Tagみたいな感じで。
ページのラストには全部書いてあるんだろうけどさ

ttp://ranobe.sakuratan.com/up/updata/up44872.png

よくページ数に使われるこのフォントの名前分かりませんでしょうか。
補正やノンブルミスの修正のために欲しくて探し回ってるんですが・・・。

手持ちのフォントの中で一番似てると思ったのは
JTCウインM系の斜体。
下の画像はJTCウインM8P。
ttp://www.imgup.org/file/iup52126.png.html

>>725
サンクスです。丁度これっぽいですね。

>>722
非常に興味深い案です。
せっかくだから、その辺りもうチョット詳しく語ってもらえませんか？
「傾き検出用基準線」とはどういう状態を指すのかとか、
それをGUI的にどう指定させる形が使い勝手がよさそうかとか。

>傾き検出用基準線
俺はADFでスキャンした場合にナナメった紙と
紙以外の部分の境界線で補正できるのが欲しい。

枠自体が傾いてるからそれじゃ意味無いよ

アドビ、Photoshop CS2の発売日を8日に決定
http://dc.watch.impress.co.jp/cda/accessories/2005/07/07/1873.html

例えば、画像の中央指定域は除外して外周のみ、とか
指定域の直線だけを探して傾き検出する様にすれば
もう少し精度上がるんじゃなかろうか、
と、>>7にあるgradg.zip使って自動傾き補正試して思ってみたりもする。

外周が探せればトリミングも自動でできそうだし。

>>728
オレもそういうの欲しいと思ってた。
てか、ドライバに黒枠消し機能と斜行補正機能があるんだから、
ついでに黒枠基準斜行補正補正とか入れてくれればいいのにな、と思ってた。

>>731
外周って何か、中央領域って、
というのを暗黙のうちに規定してるから言えるんだよ。
それを計算式や条件判定で規定できればいいんだけどね。

具体的に作業始めると
断ち切りとか拭き出しはみ出てても判定するにはどうするの、とか
出てくるんだよな。

> それを計算式や条件判定で規定できればいいんだけどね。

左右端部の指定範囲内の縦線、上下端部の指定範囲内の横線、
とかだとまずいかなぁ。
んで、上下左右の判定した直線から重心割り出してそこを中心とした
指定エリアで自動トリミング、とか。

個人的には、枠一杯まで描かれたものまで全て自動処理、は求めないんで、
駄目なものは別フォルダに振り分けてあって
それらだけＥＣなりで手動、でも助かるんだけどなぁ。

Set GAMMAでガンマ値いじったら結構むらがみえる＿|￣|○
適正値がよく判んないけどどうしたらいいでしょう。
それ系のサイトで調べたら自分のモニタではは
2.0-2.4くらいだったんだけど眩しすぎる・・・・・

はじめに確認して枠一杯にかかれてるものだけ除外するような奴なら
全自動なんて求めないんじゃないの？
そんなもんできても90℃ぐらい回転したようなのを確認もせずに
一括トリミングしたのが流れるのが関の山だとおもう

WBSで出てた自動スキャナ欲しい

るん〜ばるんばｲｪｲ

>>735
おぉ、俺もだ・・・
他のﾓﾆﾀでも見とけばよかった orz

スキャン技術を語る場所でこの様な質問は場違いかと思いますが
宜しければお答えください。みなさんはスキャン時に原本に誤植が
あった場合修正はされますか？

�@多少原本と違ってしまっても修正派
�Aあまりに酷い時、気になる時だけ修正派
�B原本を尊重して修正しない派

ΣBookをカラーにして、zip展開しながらみれるようなデバイスが欲しいな。
出たら4万とかでも買う。

本をめくりながらスキャンしてくれるスキャナってこれでしょ？
ttp://pcweb.mycom.co.jp/articles/2005/07/08/bookfair/001.html
ttp://pcweb.mycom.co.jp/photo/articles/2005/07/08/bookfair/images/008l.jpg

なんかものすげえなあ。

>>737
くわしく。
WBSのWebサイトに行っても見つけられなかった。

>>740
修正しない。原本を尊重っていうか、雑誌掲載時と単行本収録時で内容が違うのはよくある事だし、
同じように、初版とそれ以降、版を重ねるごとに微妙に修正が入ったりするのは当たり前なんで、
その時その時を残しておいた方が後々見た時に価値を感じる。

>740
誤植は、修正しません。
見開きで繋げた時にヘンな場合（欠損、線ずれ等）に、結合部分の加描・修正はしてます。

>743

>742のだったと思う

初めて炊いてみました
気づいたところがあったら指摘お願いします
http://marmotfarm.com/cgi-bin/upload2/source/up68628.jpg

とりあえず、pngをjpgに書き換えた理由を聞かせ(ry

まぁ、黒を強く出しすぎなのと、モアレか。

シャープかけすぎなのでは？

スキャン画像も上げたほうが、アドバイスはもらいやすいと思うよ。
問題があったとして、スキャンが悪いのか補正が悪いのか、
使ったツールのせいなのかとか、問題を切り分けやすい。

で、画像が開けないと思ったら、拡張子だけjpgで中身はpngなのね。
線がジャギーっぽくなってるのが気になる。
一瞬、2値画像かと思った。

>>747
スキャン前の画像と補整でやったこと書いてみ
正直汚すぎる

初めてだからそんな叩いてやるなよ。
未補正のやつあげてみ。

400dpiの白黒でスキャンして藤でコントラスト・輪郭調整しました
Photoshopないのでこれくらいしか…

元スキャンアップしてくれたほうがわかりやすいんだけど、
白黒って本当に白黒2値でやってない？
ベストはフルカラー、そうじゃなくてもグレースケールでスキャンしないとだめだよ

でもレベル補正のバッチ処理できるフリーソフトってなかったっけ？
藤だと画像みながらできないからつらいだろうけど基本は灰色を飛ばして黒を引き締める
輪郭調整はそっちが満足できるような画質になってから試した方がいい

ミーヤで出来る

レベル補正の設定でlowとhighを上下させてみればよさそうだね
しかしミーヤって初めてさわったけどどこになんの設定があるのかがわかりづらい

ここﾀﾞｳｿなんだから写真屋無ければ落とせばいいじゃん

ハードカバーの場合上手に解体する方法ってなんかありますか？

なんかこうして見ていると、

出版社が元データを印刷して製本したものを販売して
我々消費者がそれを購入して解体してスキャンしてデータ化する
できあがりはもちろんオリジナルデータの劣化版

こんな作業に時間ばっかりかかっている。
無駄無駄無駄・・・

仮にやるとしても、皆で分担してできればいいのに、
今度は共有の問題があってできない。
（素人もいるだろうから満足できない人も出てくるだろうし）
無駄無駄無駄・・・

そもそも出版社がデジタル化して売ってくれれば（ただしうっとうしいコピーガードとかなし、単なる
jpgデータをzipでまとめたもの=今のnyで出回っているものと同じような感じで）
こんなことしないよな。　もしコミックのデジタルデータを一冊200円とかで買えるのだったら
爆発的に売れると思う。　（買ったデータをny流されないようにするためには、シリアル番号を
電子すかしなどを利用して埋め込んでおき、流れたら誰が流したのかをすぐにわかるようにしておく）

藤の新しいバージョンlmapの設定なくなってない？

>>761
このスレ内くらい読もうよ

iniをチェックしろって奴？
iniからしかいじれなくなったら使いづらくなっただけだし。
以前も一時的になぜかはずれることあったから同じような理由なんじゃなくて？

>>757
アプリの中でも写真屋は危険度が高いだろ？

分解した本が崩壊しそうだけど
終わったら捨ててるの？
片付け方法とかアイテム希望

>>764
つ[写真屋 6]

なぁ、CanonのADFスキャナ
DR-2050C と　DR-5010C
ってどっちが性能いいんだ？
何か炊こうと思ってるんだけど・・・
どっち買えばいいんだろ。。。
ttp://cweb.canon.jp/documentscanner/lineup/index.html

>765
縛って普通ゴミ
もしくはシュレッダーにかけて指定ゴミ袋へ

>767
性能の前に値段の選択肢で2050

資源回収だろ

>767 770
気になって再スキャンする時あるから
１００円ショップの袋に入れて置いてるけど
捨てれるのは達人だと思う　レス�d

>>771
再スキャンするならまた買えばいいのだ。

(GT-F500 のガラス面裏側清掃完了)。

>772
だよな。
漫画なんてどうせすぐbookoffで100円で売られるんだし。
プレミア付くぐらい希少とかもう二度と手に入らないぐらいなら
置いとくのもいいかも知れんけど、そうじゃないなら
捨てたほうが邪魔にならなくていい。

捨てるために炊いてる

炊く数より買う数の方が多い... orz

自動露出OFFにしてる人多いけど露出自体もアウトなのか？

ある程度コミックの紙質飛ばすのに露出便利だし、
毎回自動で設定変わる訳じゃないしいいと思うんだけど

777

>>767
fi-4120C2一択だろ

炊いて捨てたいんだけど、手持ちのはキープしてわざわざ同じのを古本屋で購入して
炊く時もあったり
ムダなのは分かってるんだけどさ…

本当に初歩的な質問ですみません
スキャナで取り込んだ画像を白くしたりするのにはフォトショのようなものが必要なんでしょうか

>>776
1冊を共通の設定でスキャンする分には問題ないでしょ
俺は、適当なページで自動露出して設定だして、それを全ページに使ってる

自動露出をOFFにするのは、ページの内容によって露出の設定が変わって
白や黒がページごとにバラバラになるのを防ぐってだけだよ

>780
テンプレ読みなよ

初めて　自炊しようとしているのですが

以下のタイプのスキャナではどちらがいいのでしょうか？

こちらのタイプは裏表同時にスキャンできるみたいなのですが


ttp://page3.auctions.yahoo.co.jp/jp/auction/c90644912　

こちらは一枚ずつスキャンするタイプみたいです

ttp://page10.auctions.yahoo.co.jp/jp/auction/m16508039

もうFAQに近い気がするけど、

ADFが有ってもフラットはあった方が良い。
いきなりADFを購入すると使いこなせない or 地雷量産の可能性がある。

以上の二点からフラットをまず購入する事を強くお奨めします。

ScanSnapって4万切ったのかー
http://www.kakaku.com/sku/ShopView.asp?s=1331&ItemCD=004015&MakerCD=30&Product=fi%2D5110EOX2

>784
ﾓﾃﾞﾙﾁｪﾝｼﾞでもあるのかね〜〜〜？
近所のPC屋でも40ｋ切ってた

しかし性能考えると微妙な値段だよな・・・
いっそ30ｋ切ってくれれば即購入なんだが・・・
ってのは流石に虫が良すぎるか

>784のはfi-5110EOX2で今はfi-5110EOX3がでてる。
色々細かい修正があるから買うならfi-5110EOX3のほうがいい。
多分値段もそんなに変わらないし。

お得意のドライバが違うだけなんじゃなくて？

電源ボタンが電子文書ボタンになったんじゃなかったっけ。

>>760
いいねそれ

>>789
反対。

デジタル化というか一度デジタル化してそれを印刷してる訳だが
そしてそれをスキャナーで・・という訳で

だが間の問屋とか卸とかが居るから無理だろう

そうは問屋がおろさない。

>>792
ウマい！（藁

カラーで取り込み藤でコントラストを１にし、白黒化を２にし、
輪郭強調を５５にしてトリミングしリサイズしてみました。
指摘お願いします
加工前
ttp://uper.on.pc1.jp/upload/so/up3423.jpg
加工後
ttp://uper.on.pc1.jp/upload/so/up3424.jpg

なんでリサイズ前に輪郭強調？リサイズでぼけたのをシャープ化する目的以外に
輪郭強調する意味ってあるの？トーンが変にざらついてて不自然に見えるんだが･･･

>794
私的には加工前で十分なので、シャープいらないかな。

まず、わりとどうでもいいツッコミから
・コントラスト1だと輝度は変化しないはずなのに変わっている件
・黒白化したはずなのに、加工後のjpgがフルカラーjpgになってる件
・リサイズしたはずなのに、加工前と加工後で同じサイズな件

加工は、加工前の画像がすでに割といい状態なので、
コントラスト処理で改善するのはなかなか難しいんじゃないでしょうか。

補正の方針は「紙は白く、インクは黒く、トーンの濃さはそのままに」てのが、まぁ無難なところだと思いますが、
この絵はバックの人物の右目の周りにも薄くトーンが入っています。
画面全体にコントラストなどを適用して紙を白くインクを黒くしようとすると、
この部分のトーンが飛んで絵の印象が変わってしまいます。
目の周りに隈のついた怪しい表情が、ただののっぺりとした仮面に・・・

藤でやるなら、この場合は正規化（-20,264）あたりか、
輝度補正(-30/264)あたりを使うとといいんじゃないでしょうか。
ex.正規化+白黒化
http://www.imgup.org/file/iup55603.jpg

好みの問題も強いのですが、白さ黒さにそれほどこだわりがなければ、
加工前の画像で完成にしてしまうのもアリかと思います。

加工前ってのはリサイズもなにもしてない状態をアップしてほしかったんだけどなあ
これ自動補正はいってたり裏写り防止してなかったりしてない？
加工後でなぜか横が1ピクセル減ってるし
あとトーンがリサイズ後に補正かけたような飛び方してる

↑でどうでもいいつっこみって書いてあるけどそれ全部書いてあることと
実際の画像が説明のとおりになってないってことだからね

>>797
コントラストは1.1に、黒白化はにチェックいれてませんでしたorz
加工前も比べやすいようにリサイズしました。
正規化試してみます。
>>798
加工前と後を別々にトリミングしたので、サイズが減ってしまいました。
トーンが飛んでいるのは上にも書いたコントラストが1.1になってたからです

トリミングどのタイミングでやったの？
そもそもなにもしない状態が加工前なんだからリサイズしてる時点で加工前じゃない
どこに問題があるかをみるために元スキャンアップしろって言われてるんだから
手をつけてないそのままをアップしないとだめだよ

>>800
すみませんorz
次回から気をつけます

　　_、　_　
（　,┏┓` )y━･~

【ADF】スキャナで連続取り込み006.jpg【OCR】
ttp://pc8.2ch.net/test/read.cgi/printer/1114452094/
から来ました。解体について伺いたいのですが、コミックの場合は
PK-513やDC-220のような裁断機を使うのはあまりよくないのでしょうか。

>>803
裁断機を使う事によるスキャン原稿の状態の変化と、
その結果スキャンされる画像をイメージせよ。
その画像が自分で受け入れられるなら問題は無いだろう。

初炊きしたんだが見返したら一部欠けが。
読み込みミスかと思って原本を見直してみたら印刷自体のミスでした。

このスレ的には、そういうのは自分で書いて補完

そんなのありかよｗｗｗ

ありあり。
傾き補正で欠けたとことか、地味に捕完してるよ俺。自己満だがなヽ（´ー｀）ﾉ

見開きとかで欠けてるとことか普通に書いてるもんなぁみんな・・・。
あと明らかなベタ塗り忘れとか、明らかなトーン貼り忘れとか
修正線とか（間違った線に×がしてあったのにホワイト忘れでそのままになってた）
普通に直してる。

見開き・傾き補正で発生した欠けは描いてるけど
＞あと明らかなベタ塗り忘れとか、明らかなトーン貼り忘れとか
＞修正線とか（間違った線に×がしてあったのにホワイト忘れでそのままになってた）
これはそのままにしてるな。
理由は特にないけど。

俺もそれは絶対にしないな
蛇足以外の何物でもない

自炊してみたのですが指摘お願いします
スキャナ：EPSON GT-F500
300dpiカラーでスキャン
↓
トリミング
↓
チャンネルミキサー
↓
トーンカーブ
↓
藤で輪郭強調を55にして縦1600pixにリサイズ(カバー以外白黒化済)

カバー加工前(5.8MBあります)
ttp://k-kura.net/upload/source/kura0522.jpg
原本加工前(3.6MBあります)
ttp://k-kura.net/upload/source/kura0521.jpg
加工後(パスはスレタイ)
ttp://k-kura.net/upload/source/kura0519.zip

>>812
エロいならエロいと(ry

まぁそれはともかく。特にこれといって問題は無い気もするけど、あえて言うなら
少し飛ばし気味な気もするので、俺としては取り込む時にもう少し紙質を整える調整をするかな。
そしてあまり強くトーンカーブを弄らないようにする感じで。

・個人的にはもう少し全体の色が濃い目のほうが見やすい
・カバーはもう少しくっきりした方が好き
・本文の文字がちょっとボケ気味

個人的な好みとしてはこんな感想
でもこれならこれでいいと思う

>812
イイヨ　ｲｲﾖｰ
813さんの言う通り、白飛びを抑えられたら完璧っす。
カラーに関しては、無問題。

白よりも黒が飛びすぎてると思うけどね
スカートの下の方なんて真っ黒になってるし

>>812
加工後のパスが解除できないんだがw

「スレタイ」って入れたけど解除できないぞ？

（´・ω・） ｶﾜｲｿｽ

黒とびを抑えてみた。
http://k-kura.net/upload/source/kura0525.jpg

そういや母乳って生臭いって話を聞くがどうなん？

母乳の前に牛乳のにおいをどう思いますか＞生臭い

雑談すんな阿呆

ちょｗｗｗｗｗｗｗ
この誤爆厨ひきとってくだしあｗｗｗｗｗｗｗ
Winny週刊少年ジャンプ Part1
http://por.uolog.net/test/read.cgi/uza/1121679994/

>>819
白がグレーすぎない？
俺はこれぐらいが好き
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050718222411499.jpg

>>819
白がグレーすぎない？
俺はこれぐらいが好き
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050718222411499.jpg

>>819
白がグレーすぎない？
俺はこれぐらいが好き
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050718222411499.jpg

>>819
白がグレーすぎない？
俺はこれぐらいが好き
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050718222411499.jpg

>>819
白がグレーすぎない？
俺はこれぐらいが好き
ttp://tool-ya.ddo.jp/2ch/trash-box/contents.jsp?file=20050718222411499.jpg

Σ(ﾟДﾟ)
すまん・・・

>>812
黒が潰れてる一因でもありますが、少しボケ気味かと。
05ページだと、1コマ目のバックのトーンが哀しいことに。
白トビで乳曇の大きさが微妙に小さくなったりもしてますので、
トーン濃度の保存にもう少し気を使ってみたらどうでしょうか。
ページの左側にスキャン時に入ったと思われる影があって、なかなか補正が難しいところですが。

自分なら↓なカンジかしらん。
藤　[正規化-10/290、コントラスト1.05、白黒化2、リサイズ] ＞Padie[4bit化]
ttp://www.uploda.org/file/uporg150476.png.html

最近、png化して文字周りのブロックノイズを出さないようにしつつ、
4bit化してサイズを抑えるのがマイブームです。

おまけ　自ツール　[輝度85以下、200以上にエッジ選別しながら強コントラスト] ＆藤[白黒化、リサイズ] &Padie[4bit化]
ttp://www.uploda.org/file/uporg150479.png.html

>>824-828
愛が伝わってきますなｗ
てか、鯖が不調っぽいので、これも連投になるかも・・・(((((( ；ﾟДﾟ)))))

文字周りにブロックノイズが出るなんて、余程高圧縮掛けてるんだね、ｳﾌﾟﾌﾟ

ttp://k-kura.net/upload/source/kura0530.jpg
ttp://k-kura.net/upload/source/kura0531.jpg　

なんとなくやってみたけど、なかなかうまくいかないもんだね

ボケるのはなぜだろうね。
↓おれの藤設定だけど、
http://k-kura.net/upload/source/kura0532.htm
まぶしいのがきらいなので白を247にしてる。
いやなら輝度補正をoffにしてくれ。
元の画像が横向いてるので、回転もかけてる。

エプロンに、うっすら横縞が出るのもなぁ

|д゜)　＜　ここはやっぱり取込段階から少し見直してもらった方がいいと思うぜ
　　　　　|　取り込んだ時のF500の設定を教えて頂きたいな
　　　　　|　明るさを上げて、シャドウを少し強く出す感じにすれば変わるかも？
　　　　　 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

>>831
量子化で出るノイズですから、画質100でも防げないっていう例のヤツです。

たとえば>>812さんの補正後のjpgと、わたしのpngで文字の周りをスポイトツールで探索すると、
jpgの方は一見真っ白に見えるところでも輝度が250〜254程度に変化してるのがわかると思います。
ところどころにある248くらいなら、ボケた点として認識できると思います。

気にしなければ気にしないでいい訳ですが、
一度pngでノイズレスな画質に慣れてしまうと妙に気になるように・・・


>>833
黒は0でいいとして、白を255にするかは悩みますね。
元の紙が255の明るさってことはまずないので、
多少抑えた方が自然な（作者が想定してる）画質に近いのではないか、とか。

まぁ、最後はオレ基準で補正しかないわけですが。

エッジに出るのはモスキートノイズ

>>837　Σ(ﾟдﾟ)
そうでしたorz
訂正してお詫びします。

>>835
スキャン時に補正かけるかソフトで補正かけるかはどっちでもかまわないと思うけど
初心者にやり直しのきかないスキャン時補正を勧めるのは反対
問題あったとき原因の切り分けできないだろうし

乳首で画像比較する俺
普段のやり方で加工したらモアレた

特に裏づけとなる理由はないが、最終サイズの2倍以上の解像度でスキャンしている。
縦1600dpiを作るんなら300dpiだと不足のような気がする。気のせいかもしれん。

結合すると高さ合わなくてかなり切らなきゃいけないよな

高さ1400にしちゃってしまったと思ってる俺ガイル('A`)

>841
大抵の印刷物は150lpi以内で印刷されてるので
リサイズ後の大きさに関わらず300dpiでスキャンすれば間に合う
本によってはそれ以上に細かい場合もあるので
その場合リサイズ後が縦800でも300dpiじゃ間に合わない

印刷とか詳しくないですが、
スキャン解像度を考えてたときに少し調べたことがあります。

ttp://blog.koss.jp/article_235.html
＞150lpi の網点を生成する出力機は 150×16 = 2400dpi 以上の出力解像度が必要になる

ということでらしいので、スキャン解像度を上げれば画質も改善するものと思われます。

また実際に印刷されたハーフトーンはトーンの形が円なので、
モニタの四角い画素ではどうやっても近似的にしか表せません。
スキャン解像度が大きいほど綺麗な円に近づくので、
より印刷された状態に近づいていくはずです。
（まぁ、元原稿が白黒2値なマンガ原稿にハーフトーンは出てこない気もしますが・・・）

ただ、むやみに解像度を上げて印刷された状態に近づけたろころで、
モニタに表示できる大きさに縮小したらそんな情報は吹っ飛ぶわけで。
ある段階から解像度を大きくしても無意味ってのはそういうことで、
経験的に300dpiで十分だということではないでしょうか。

しかし300dpiがセオリーになったころに縦1600で見る人はあまりいなかったでしょうから、
表示サイズを今までより大きくするからスキャン解像度も300dpi以上げるというのは、理にかなっているように思います。

・・・でも、縦1600を縮小しないで見れる人ってどれだけいるんでしょうね？

印刷とか詳しくないですが、

まで読んだ。

auto color indexing のコードのテストをしてて偶然バグ見つけた。
ファイル名(パスを含む)に%が入っている画像を食わせると、生成されたファイル名がバグります＞藤
アホらしいけど簡単に直らない orz

引数のやり方見る限り仕様じゃない？

>845
画像をスキャナで取り込む高い階調を持った入力の解像度と
数色(or黒一色)しかないインクの点で全ての色を再現する出力の解像度を一緒にしちゃいかん
150lpiと300dpiのように取り込みの数字が2倍なのはシャノンの標本化定理からくるもの。

雑誌のグラビアページで糊付けされてるページがあるけど、
あれもアイロンでうまく剥がせる？

やってみれ。

>>850
グラビアの雑誌ってホチキスで留めてる雑誌の方が多そうだけど。
取りあえず、カラーのページは直にアイロン当てると良くないので、それだけ気をつければいいんでないかな。

>>847
藤使わないからよく分からないけど、ヘルプ見る限り '%%' って二つ入力してみた？

というか、中綴じ漫画雑誌によくあるグラビアページの事でしょ？
アイロンで取れたり取れなかったりするんだけど、ノリの種類が違うのかも。

俺が外す時は、アイロンの熱を一番高温にしてる。それでなんとか少しずつはがせる感じ。
もちろんペーパー越しにだけど。ただ、カラーページの方は水分がもってかれてしなしなになっちゃうんで
問題があるかもしれない。

>851-853
ﾚｽ�d
一応アイロンで少しづつやれば、なんとか剥がせるのか
今度チャレンジしてみるよ

>>720
遅レスだが、いっそのことPDFにしてしまうのはどうだ？
マンガミーヤなら見れるし、確かタグ情報もつけられる…ような…気が。

847さんは藤の中の人と思われ。
減色処理を実装中なのかしらん。

ところで今、カラーページにラベル剥がしをスプレーしてみたら、
えらいあっさり剥げたんだけど。
ホットボンドじゃなくて普通の接着剤なのか？
紙にシミになったけど、再生紙だとシミが残るかも・・・

どなたか見習い職人の館流してください orz

上のほうにwebで置いてあるところが晒されてた気がするが

>857
nyで拾えない？
ロダで良ければうｐるけど

>>857
>>119
ローカルで見たいならGetHTMLWとか使えばおｋ

見つかりました。
ありがとうございます。

がんばります(｀・ω・´)ｼｬｷｰﾝ

shareの一般コミックの∩(・ω・)∩F258PRS1EA氏ってどういう圧縮してるんだろう。
ファイルサイズすごく小さいのに、文字周りのノイズが全く出てなくてきれいに仕上がってる。
参考にしたい、というか真似したい。

つ【ドット打ち】

ドット打ちだとアンチエイリアスが難しそうでつね

>>862
jpgに変換したら普通文字周りにブロックノイズでないか？
それとは別の話かな

安い液晶使ってるじゃね

>>865
>>837

日本国またはアメリカ合衆国、もしくはその両方の著作権法に触れる内容であると疑われることから表示できません。

�d(；´Д`)

∩(・ω・)∩氏のスキャンいくつか確認してみたけど

小日向海流はモアレがめだつ
涼風7巻や華麗なる食卓17巻は逆にトーンつぶれてコントラストが高くなってる
ページ上部の色が変色してるしスキャンスナップっぽい
あとなぜか表紙のカラーがおかしい。減色失敗したような感じ
藤でpngを変換させたときにこんな感じだったような。
それと華麗9ページも抜けてるぞ

あー文字周りノイズか。小日向海流はかなり文字周りめだつ
涼風7巻と華麗なる食卓17巻は小日向海流よりは目立たないけど等倍で確認出来るレベル

チェックする目でみちゃうとぼろくその糞スキャンみたいな表現になっちゃってるけど
出来はここに書いてる表現ほど悪くはないかな
にしても傾き補正しててページ抜け気づかないのかな

んでサイズだけど絵の書き込み量やゴミなどの画質×サイズ×jpg圧縮率で決まるから
こんなもんじゃないの？

BECKか
ノイズみえるよ。

jpg変換させるとノイズはどうしても出るんだよな。この画像形式の宿命みたいなもの。
できるだけノイズが出ないように、少しでも画質を上げるようにしてる。
そのせいか、50MB程度に圧縮したファイルでも文字周りのノイズはそれほど目立たなくなった。
拡大すれば目立つけど、等倍で読む分にはまず目立たないくらいのレベル。

初歩的なことだけど、白紙頁を飛ばして炊いてる人いない？
見開きだとずれ込んで勝手が悪い。
単頁で見る人がいようと見開きで自然と見れるように炊くのが基本

涼風 第7巻 みたんだけど、一年以上前の BECK の方ができがいいじゃん。
腕が落ちてるのは残念。

>>873
見返し？とかは放置するけど途中に挿入されてる白紙ページは普通に挿入する。

本文1枚目が見開きで見たときに左にくるように
白紙を入れるかどうか？という話なら自分は入れてる

入ってないものは自分で調節して
見開き合うようにして読むのでなくても構わないが
あるとその手間が不要になるから楽かな

まあ、真っ白とか真っ黒のページはスキャンはしない
作ったほうが速いから

>>876
そうそう。そういうこと。
左右白紙の場合は馬鹿正直にやる必要ないだろうけど。

ところで、カバーの炊き方って人それぞれだけど
テンプレ（●スキャン技術･保存編）のより
カバー（折り返しなど全て一枚）→カバー裏（一枚）→本編
こうした方が一番手軽で勝手のいい炊き順だと思ってるんだけどな。

すまん。余計なこといった。スルーして

職人批評は吊し上げてるみたいで胸くそ悪いからやめようぜ
勝手に色々言われたらたまったもんじゃない

アドバイス求めて自分がスキャンしたのを晒すやつには
色々言ってもいい（むしろ言うべき）だけどな。これはちょっとルール違反ていうか、気分が悪いな。

スキャナGT8400U使ってます。
スキャン時に自動露出はオフにしてるのですが、色補正もオフにした方がいいのでしょうか？

始め、自分は誉めて安穏として、
ここの住人にその炊き主を批評させる新手の叩きかと思った

ただ頁抜けの予防策の一つとしてに、
ノンブルとファイルの頁番号は合わせたほうがいいとも思った＞BECK

個人的に、頁抜けを作るなんて事は有り得ないんだけど・・・。
みんなはどうなの？

>>884
個人的な意見ですが…
雑誌、単行本一冊分丸々吸い出してみ
吸い出し自体単純作業だから重複とか頁抜けとか出てくるよ。
最も、頁数がずれるから途中で気付いて直すけどね

最終的に抜けている物を作る＝ページ抜けを作る、でしょ
抜けをやらかす人はチェックしてないんだよ
やらない人は一度もやらない。やる人は何度も繰り返す

ファイル名とノンブルをあわせる
ファイル個数とノンブルをチェックする
見開きビューアで一度全ページめくる

これだけで抜けなんてほぼすべてつぶせるのにやらないんだもん

何度も確認せんでもスキャン終わった時点で
スキャン枚数と紙の枚数確認すればまず無いでしょ。
数分でできる作業だからこれは必須だと思ってる。
数百冊炊いてるが確認後に二箇所訂正のところを
つい一箇所訂正しただけで終わらせた一冊だけページ抜けしたことがあるだけ。
それも最終確認で読むから抜けたままになる事はない。

自分の為に炊く香具師がページ抜け作るか？
炊き終わったら、すぐ読むべ？

>>888
何度も読んでるからなあ。
炊く理由は保存スペース開けたいだけだし。

お気に入りを保存したいんだからすでにコミックの段階で読んでるんだし
炊いてからすぐ読みたいかというと読みたくない

新しい漫画は1枚ずつスキャンしてるんですが
家に大量にある昔の漫画は連続取り込みのできる
スキャナでやりたいと思っています。

値段的にDR-2050C(\56000)かfi-5110EOX3(\43000)くらいしか
手がでないのですが、このスレ的には買うとしたらどちらが
お勧めですか？

fi-5110EOX3はjpgでしか出力できないっぽいですが、
jpg画質を最高画質にして取り込めばそれなりに綺麗なのかな？
妥協できそうな画質なら値段の安いfi-5110EOX3にしたいけれど…

上記スキャナ使用してる方おられましたら情報よろしくですm(_ _)m