画像容量は、小さめに
デザインしていくと、いろいろ細かい部分に手が入り、どうしてもデータの容量が重くなってきます。
しかし、データ作成者にとって、データ容量をコントロールしてデータを作成することは、重要な作業になります。
とりわけ、チラシのように膨大な写真がレイアウトされる印刷物のデータにとって、データ容量と眺めっこしながらデザインするのが、データ作成者の使命です。
個人の作品を描いていると、特にデータ容量が大きくなります。
フィルタ機能や透明機能など、仕事では使わない効果を多様してしまいます。
さて、わたしがこれまで印刷所に入稿してきたデータは、以下のようなものでした。
◆これまで私が保存してきた画像形式
（A）EPS／CMYK／350dtp／プレビュー：８bit／エンコード：バイナリ
（B）EPS／CMYK／350dtp／プレビュー：８bit／エンコード：JEPG圧縮（最高画質〈低圧縮率〉）
ほとんどは、（A）または（B）どちらでもかまわないというのが、印刷所の指定でした。
しかし、ある出力先から指摘されたものは違いました。
◆ある出力先で指定された画像形式
（C）EPS／CMYK／350dtp／プレビュー：８bit／エンコード：JEPG圧縮（低画質〈高圧縮率〉）
理由は、データの容量が非常に軽くなるというものでした。
（A）や（B）に較べると、かなり軽くなります。
しかし、私は、「画質の問題」を指摘しました。
ある出力先からは、「最高画質であろうと、低画質であろうと、納品される印刷物にそんなに違いはありませんよ。それ以上に、データをいかに軽くするかが、データ作成者の使命です。」と指摘されました。
私は、印刷所に勤務したことがなかったので、いい指摘を頂きました。
実際、印刷所に入稿する場合は、これまでのように（A）と（B）を基本にしながら、（C）の入稿も確認するような流れです。
指摘されたのは、昨年の夏でした。
ありがたいかぎりです。
GAGA 2007/07/11 18:13:33
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
001
あらためて書く必要などないと思いましたが、上記の書き込みは、MacOS9の環境となります。
では、失礼します。
GAGA 2007/07/11 18:28:23
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
002
エンコードをJEPG圧縮にすればデータは軽くなるが
エンコードをバイナリにした方が処理が速く安定するって機械もあるなぁ。
古いのだとJEPGエンコーディングのEPSデータは処理出来ないのとか。
まあ画像や用途によっての使い分けだろ。
JEPG低画質での品質でも問題のない物件（こんなのはやった事ないが）ならそうすればいいし
JEPG最高画質でも画質の劣化が顕著に現れるものもあるから
そういう場合はバイナリやASCIIのエンコーディングを使えばいいし。
まあ最近はEPS自体使う事が少なくなってきたけどな。
というか何でこんなチラシの裏に書くような事を突然？
2007/07/11 19:01:21
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.2.1 (KHTML, like Gecko) Safari/419.3
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
003
まず
350dtp→350dpi
JEPG圧縮→JPEG圧縮
ですな。
んー、まぁ仕上がりは各個人の判断なので良いかと思いますが、JPEG圧縮の「（低画質〈高圧縮率〉）」って白いバックに赤いスイトピーがおいてある画像なんかだと、ブロックノイズが出て結構崩れそうな気がします。
笹川％DTPオペ 2007/07/11 19:01:47
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
004
>350dtp→350dpi
>JEPG圧縮→JPEG圧縮
すみかせんでした。
クライアントと印刷所と相談しながらの判断でしょうか。
GAGA 2007/07/11 19:23:52
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
005
×すみかせんでした。
○すみませんでした。
GAGA 2007/07/11 19:24:43
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
006
よほど小さい画像でない限り、JPEG圧縮の「（低画質〈高圧縮率〉）」は使用しません。
ブロックノイズがそれなりに目立つのと、万が一画質が問題になったときに非可逆だからもう一度（最高画質〈低圧縮率〉）にしたところでブロックノイズは元には戻らない。
校正出して「画質が悪いので直してください」とか赤字入れられちゃったらどうにもならなくなりそうな気がしますっていうか過去にそういうことがありました。
データ入稿だったので「Jpeg保存する前のデータを...」っていったらデザイナーさんが真っ青になってしまいました。
大きさにもよるけどあまりおすすめできません。
今まではバイナリ保存していたけど、ＯＳＸになってから（最高画質〈低圧縮率〉）にしています。
ちょっとアスキーはでかすぎて運用が悪すぎます。
製版屋 2007/07/11 19:54:34
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
007
>最高画質であろうと、低画質であろうと、納品される印刷物にそんなに違いはありませんよ。
ものによっては、使い物になりませんけどねぇ。
あなたが出した先で、再保存する状況がないなら、最終画像（一旦保存し、再度開いてみる）を確認しておくことをお勧めします。怠って事故を起こしませんように。
匿名 2007/07/11 21:11:31
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
008
003
>350dtp→350dpi
こういう指摘をするのなら、dtp→dpiじゃなくてppiだろ。
008の匿名 2007/7/11 22:26
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/418.9 (KHTML, like Gecko) Safari/419.3
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
9
みなさま、ありがとうございます。
どの画像形式でデータを作成するかは、印刷品質を印刷所とクライアントと話し合って納得できる方法を採用するのが一番という結論でしょうか。
実は、出力先と書きましたように、正確言うとその回のこの納品物とは、印刷ではなく、看板系の機種の大型インクジェットでの出力でした。
私は、「（（B）EPS／CMYK／350ppi／プレビュー：８bit／エンコード：JPEG圧縮（最高画質〈低圧縮率〉）」で入稿したのですが、担当オペレーターの方が、2から3年前まで印刷所でオペレーター・製版を担当方で、製版に詳しくない私に、親切に教えてくださったのです。
その方からの印刷データ同様に、「（C）EPS／CMYK／350ppi／プレビュー：８bit／エンコード：JPEG圧縮（低画質〈高圧縮率〉）」での入稿という指示でした。
ともかく、さまざまな方とお話すると、新しい事を教えてくださるので、感謝しております。
ご指摘くださるのは、皆様も同様です。
ありがとうございました。
GAGA 2007/7/11 23:57
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
10
それじゃあ通常の印刷物と用途も方式も全然違うじゃん。
それこそ通常の印刷物に適用できないよ。
何でも同じに考えては駄目です。
匿名 2007/7/12 0:16
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.2.1 (KHTML, like Gecko) Safari/419.3
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
11
看板と小型印刷では見る寸法とキョリが違うので画像の取り扱いのセオリーは異なる。
それよりもなによりも後出しで媒体の正体を告げるのは感心しない。
agag 2007/7/12 2:34
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
12
おはようございます。
私にとって、上記は、２つの意義がありました。
看板業界にいる印刷所の元・製版の方からの「印刷データの入稿について」からのありがたい指摘でした。
・データはなるべく小さく。
・場合によっては、印刷データでも、EPS／エンコード：JPEG低画質もあり。
ふたつめに、印刷より、クオリティが要求されない看板の世界の常識について知る機会ともなりました。
・画像形式は、EPS／エンコード：JPEG低画質。
・解像度は、２００MBあるいは、１００MBでもいい
でした。
ちなみに、今フォトショップで写真の保存形式の違いでのデータの大きさをくらべてみました。
バイナリで２３，３MBのデータは、JPEG最高画質では４、１３MB、JPEG低画質では、１，２４MBでした。
ありがとうございました。
GAGA 2007/7/12 8:01
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
13
データ容量を気になさるなら
仕様サイズでの３５０dpi（３００dpi以上）にするべきかな。
JPEG低画質、最高画質は仕事によりけりだけど
低画質は自分はしません。
リサイズちとめんどいけど。
〜〜〜 2007/7/12 8:46
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
14
>・解像度は、２００MBあるいは、１００MBでもいい
用語とかの間違い、誤記が多すぎる。
「匿名」の重箱の隅でした。
匿名 2007/7/12 8:57
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
15
>どの画像形式でデータを作成するかは、印刷品質を印刷所とクライアントと話し合って納得できる方法を採用するのが一番という結論でしょうか。
というよりも質問ではなく「書き込まれた感想文」のような物に対してついたレスを適当にまとめられても何だかなぁというのが正直なところです。
情報的にも誤記が多かったり、後付で看板用だったりするところは良い書き込みとはいえません。
中途半端に読んで「JPEGセーブはどんなクォリティでもいいんだ」みたいな間違った認識をしてしまう人がいるかもしれませんし、適切なレスがもらえないのでそういったことは一番はじめに書いておくべきでしょう。
製版屋 2007/7/12 10:17
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
16
>「匿名」の重箱の隅でした。
ここまでやると、隅じゃないと思うけどねぇ。
・知識がない
・ミスが多い
・人のいうことを理解できない
など、非常に重要なことが垣間見える。
＃＃きちんと打ち合わせをして、確認には念を入れること。
匿名007 2007/7/12 10:18
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
17
JPEG圧縮は、代表的なところで、画像を小さな正方形単位でサンプリングし、変換圧縮するので、空のあわ〜いグラデとかがガタガタになったり、髪の毛の先や建物のエッジ部分があま〜くなったりしますよね。
低圧縮になればなるほどサンプリング時の「間引き」と変換圧縮計算の「端数切り」が強まっちゃって、ブロック構成っぽさがでちゃう。
で、失ったデータは二度と再び蘇らない。
JPEG低画質（高圧縮率）で保存して見た目は大丈夫だなあ、と安心しちゃダメ。ファイルを閉じて、再度開くと大変なことになってるかもしれない。元データはキチンと別に取っておこう。
それはそうと、AMスクリーニングとFMスクリーニングで、ブロックノイズの出方は違ってくるのかな。
ぷり 2007/7/12 11:11
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
18
いかん、高低がこんがらがってる。訂正の書き込み常習犯、かな。
＞低圧縮になればなるほど
高圧縮ですよね〜（恥っ）
蛇足の書き込みなのにスミマセン。
ぷり 2007/7/12 11:46
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
19
看板系ということですが、屋外の大型看板と店頭の看板ではもちろん違います。解像度も100でも200でも変わらないわけではなく、内容や見る人と広告物の距離によります。データも軽い方がいいですが、必要に応じて、と言ったところでしょう。保存形式もそうだと思います。
たまたま今扱っていらっしゃる制作物には書いていらっしゃる保存形式等が適切だっただけで、全ての印刷、すべての看板もそうとは限りません。
その都度、広告物の設置箇所や内容にあわせて確認すべきでしょう。
目から鱗な感じだったのでしょうし、その気持ちは良くわかるのですが、気をつけないとトラブルのもとになりますよ。
って、代理店の私が言うまでもないけど一応。
tami 2007/7/12 15:24
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[3099] 旧掲示板 (2007/07/11 Wed 18:13)
- [3099] 画像容量は、小さめに 旧掲示板 2007/07/11 18:13
