画像容量は、小さめに
デザインしていくと、いろいろ細かい部分に手が入り、どうしてもデータの容量が重くなってきます。
しかし、データ作成者にとって、データ容量をコントロールしてデータを作成することは、重要な作業になります。
とりわけ、チラシのように膨大な写真がレイアウトされる印刷物のデータにとって、データ容量と眺めっこしながらデザインするのが、データ作成者の使命です。
個人の作品を描いていると、特にデータ容量が大きくなります。
フィルタ機能や透明機能など、仕事では使わない効果を多様してしまいます。
さて、わたしがこれまで印刷所に入稿してきたデータは、以下のようなものでした。
◆これまで私が保存してきた画像形式
(A)EPS/CMYK/350dtp/プレビュー:8bit/エンコード:バイナリ
(B)EPS/CMYK/350dtp/プレビュー:8bit/エンコード:JEPG圧縮(最高画質〈低圧縮率〉)
ほとんどは、(A)または(B)どちらでもかまわないというのが、印刷所の指定でした。
しかし、ある出力先から指摘されたものは違いました。
◆ある出力先で指定された画像形式
(C)EPS/CMYK/350dtp/プレビュー:8bit/エンコード:JEPG圧縮(低画質〈高圧縮率〉)
理由は、データの容量が非常に軽くなるというものでした。
(A)や(B)に較べると、かなり軽くなります。
しかし、私は、「画質の問題」を指摘しました。
ある出力先からは、「最高画質であろうと、低画質であろうと、納品される印刷物にそんなに違いはありませんよ。それ以上に、データをいかに軽くするかが、データ作成者の使命です。」と指摘されました。
私は、印刷所に勤務したことがなかったので、いい指摘を頂きました。
実際、印刷所に入稿する場合は、これまでのように(A)と(B)を基本にしながら、(C)の入稿も確認するような流れです。
指摘されたのは、昨年の夏でした。
ありがたいかぎりです。
しかし、データ作成者にとって、データ容量をコントロールしてデータを作成することは、重要な作業になります。
とりわけ、チラシのように膨大な写真がレイアウトされる印刷物のデータにとって、データ容量と眺めっこしながらデザインするのが、データ作成者の使命です。
個人の作品を描いていると、特にデータ容量が大きくなります。
フィルタ機能や透明機能など、仕事では使わない効果を多様してしまいます。
さて、わたしがこれまで印刷所に入稿してきたデータは、以下のようなものでした。
◆これまで私が保存してきた画像形式
(A)EPS/CMYK/350dtp/プレビュー:8bit/エンコード:バイナリ
(B)EPS/CMYK/350dtp/プレビュー:8bit/エンコード:JEPG圧縮(最高画質〈低圧縮率〉)
ほとんどは、(A)または(B)どちらでもかまわないというのが、印刷所の指定でした。
しかし、ある出力先から指摘されたものは違いました。
◆ある出力先で指定された画像形式
(C)EPS/CMYK/350dtp/プレビュー:8bit/エンコード: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)]
[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)]
[ ]-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]
[笹川%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]
[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)]
[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保存する前のデータを...」っていったらデザイナーさんが真っ青になってしまいました。
大きさにもよるけどあまりおすすめできません。
今まではバイナリ保存していたけど、OSXになってから(最高画質〈低圧縮率〉)にしています。
ちょっとアスキーはでかすぎて運用が悪すぎます。
よほど小さい画像でない限り、JPEG圧縮の「(低画質〈高圧縮率〉)」は使用しません。
ブロックノイズがそれなりに目立つのと、万が一画質が問題になったときに非可逆だからもう一度(最高画質〈低圧縮率〉)にしたところでブロックノイズは元には戻らない。
校正出して「画質が悪いので直してください」とか赤字入れられちゃったらどうにもならなくなりそうな気がしますっていうか過去にそういうことがありました。
データ入稿だったので「Jpeg保存する前のデータを...」っていったらデザイナーさんが真っ青になってしまいました。
大きさにもよるけどあまりおすすめできません。
今まではバイナリ保存していたけど、OSXになってから(最高画質〈低圧縮率〉)にしています。
ちょっとアスキーはでかすぎて運用が悪すぎます。
[製版屋]-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)]
[匿名]-2007/07/11 21:11:31 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)]
[008の匿名]-2007/07/11 22:26:49 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/418.9 (KHTML, like Gecko) Safari/419.3]
» 009
みなさま、ありがとうございます。
どの画像形式でデータを作成するかは、印刷品質を印刷所とクライアントと話し合って納得できる方法を採用するのが一番という結論でしょうか。
実は、出力先と書きましたように、正確言うとその回のこの納品物とは、印刷ではなく、看板系の機種の大型インクジェットでの出力でした。
私は、「((B)EPS/CMYK/350ppi/プレビュー:8bit/エンコード:JPEG圧縮(最高画質〈低圧縮率〉)」で入稿したのですが、担当オペレーターの方が、2から3年前まで印刷所でオペレーター・製版を担当方で、製版に詳しくない私に、親切に教えてくださったのです。
その方からの印刷データ同様に、「(C)EPS/CMYK/350ppi/プレビュー:8bit/エンコード:JPEG圧縮(低画質〈高圧縮率〉)」での入稿という指示でした。
ともかく、さまざまな方とお話すると、新しい事を教えてくださるので、感謝しております。
ご指摘くださるのは、皆様も同様です。
ありがとうございました。
みなさま、ありがとうございます。
どの画像形式でデータを作成するかは、印刷品質を印刷所とクライアントと話し合って納得できる方法を採用するのが一番という結論でしょうか。
実は、出力先と書きましたように、正確言うとその回のこの納品物とは、印刷ではなく、看板系の機種の大型インクジェットでの出力でした。
私は、「((B)EPS/CMYK/350ppi/プレビュー:8bit/エンコード:JPEG圧縮(最高画質〈低圧縮率〉)」で入稿したのですが、担当オペレーターの方が、2から3年前まで印刷所でオペレーター・製版を担当方で、製版に詳しくない私に、親切に教えてくださったのです。
その方からの印刷データ同様に、「(C)EPS/CMYK/350ppi/プレビュー:8bit/エンコード:JPEG圧縮(低画質〈高圧縮率〉)」での入稿という指示でした。
ともかく、さまざまな方とお話すると、新しい事を教えてくださるので、感謝しております。
ご指摘くださるのは、皆様も同様です。
ありがとうございました。
[GAGA]-2007/07/11 23:57:23 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)]
[匿名]-2007/07/12 00:16:07 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419.2.1 (KHTML, like Gecko) Safari/419.3]
[agag]-2007/07/12 02:34:20 [Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4]
» 012
おはようございます。
私にとって、上記は、2つの意義がありました。
看板業界にいる印刷所の元・製版の方からの「印刷データの入稿について」からのありがたい指摘でした。
・データはなるべく小さく。
・場合によっては、印刷データでも、EPS/エンコード:JPEG低画質もあり。
ふたつめに、印刷より、クオリティが要求されない看板の世界の常識について知る機会ともなりました。
・画像形式は、EPS/エンコード:JPEG低画質。
・解像度は、200MBあるいは、100MBでもいい
でした。
ちなみに、今フォトショップで写真の保存形式の違いでのデータの大きさをくらべてみました。
バイナリで23,3MBのデータは、JPEG最高画質では4、13MB、JPEG低画質では、1,24MBでした。
ありがとうございました。
おはようございます。
私にとって、上記は、2つの意義がありました。
看板業界にいる印刷所の元・製版の方からの「印刷データの入稿について」からのありがたい指摘でした。
・データはなるべく小さく。
・場合によっては、印刷データでも、EPS/エンコード:JPEG低画質もあり。
ふたつめに、印刷より、クオリティが要求されない看板の世界の常識について知る機会ともなりました。
・画像形式は、EPS/エンコード:JPEG低画質。
・解像度は、200MBあるいは、100MBでもいい
でした。
ちなみに、今フォトショップで写真の保存形式の違いでのデータの大きさをくらべてみました。
バイナリで23,3MBのデータは、JPEG最高画質では4、13MB、JPEG低画質では、1,24MBでした。
ありがとうございました。
[GAGA]-2007/07/12 08:01:41 [Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; IEMB3; IEMB3)]
[~~~]-2007/07/12 08:46:26 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)]
[匿名]-2007/07/12 08:57:14 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6]
[製版屋]-2007/07/12 10:17:11 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)]
» 016
>「匿名」の重箱の隅でした。
ここまでやると、隅じゃないと思うけどねぇ。
・知識がない
・ミスが多い
・人のいうことを理解できない
など、非常に重要なことが垣間見える。
##きちんと打ち合わせをして、確認には念を入れること。
>「匿名」の重箱の隅でした。
ここまでやると、隅じゃないと思うけどねぇ。
・知識がない
・ミスが多い
・人のいうことを理解できない
など、非常に重要なことが垣間見える。
##きちんと打ち合わせをして、確認には念を入れること。
[匿名007]-2007/07/12 10:18:39 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)]
» 017
JPEG圧縮は、代表的なところで、画像を小さな正方形単位でサンプリングし、変換圧縮するので、空のあわ~いグラデとかがガタガタになったり、髪の毛の先や建物のエッジ部分があま~くなったりしますよね。
低圧縮になればなるほどサンプリング時の「間引き」と変換圧縮計算の「端数切り」が強まっちゃって、ブロック構成っぽさがでちゃう。
で、失ったデータは二度と再び蘇らない。
JPEG低画質(高圧縮率)で保存して見た目は大丈夫だなあ、と安心しちゃダメ。ファイルを閉じて、再度開くと大変なことになってるかもしれない。元データはキチンと別に取っておこう。
それはそうと、AMスクリーニングとFMスクリーニングで、ブロックノイズの出方は違ってくるのかな。
JPEG圧縮は、代表的なところで、画像を小さな正方形単位でサンプリングし、変換圧縮するので、空のあわ~いグラデとかがガタガタになったり、髪の毛の先や建物のエッジ部分があま~くなったりしますよね。
低圧縮になればなるほどサンプリング時の「間引き」と変換圧縮計算の「端数切り」が強まっちゃって、ブロック構成っぽさがでちゃう。
で、失ったデータは二度と再び蘇らない。
JPEG低画質(高圧縮率)で保存して見た目は大丈夫だなあ、と安心しちゃダメ。ファイルを閉じて、再度開くと大変なことになってるかもしれない。元データはキチンと別に取っておこう。
それはそうと、AMスクリーニングとFMスクリーニングで、ブロックノイズの出方は違ってくるのかな。
[ぷり]-2007/07/12 11:11:20 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6]
[ぷり]-2007/07/12 11:46:04 [Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/312.8.1 (KHTML, like Gecko) Safari/312.6]
» 019
看板系ということですが、屋外の大型看板と店頭の看板ではもちろん違います。解像度も100でも200でも変わらないわけではなく、内容や見る人と広告物の距離によります。データも軽い方がいいですが、必要に応じて、と言ったところでしょう。保存形式もそうだと思います。
たまたま今扱っていらっしゃる制作物には書いていらっしゃる保存形式等が適切だっただけで、全ての印刷、すべての看板もそうとは限りません。
その都度、広告物の設置箇所や内容にあわせて確認すべきでしょう。
目から鱗な感じだったのでしょうし、その気持ちは良くわかるのですが、気をつけないとトラブルのもとになりますよ。
って、代理店の私が言うまでもないけど一応。
看板系ということですが、屋外の大型看板と店頭の看板ではもちろん違います。解像度も100でも200でも変わらないわけではなく、内容や見る人と広告物の距離によります。データも軽い方がいいですが、必要に応じて、と言ったところでしょう。保存形式もそうだと思います。
たまたま今扱っていらっしゃる制作物には書いていらっしゃる保存形式等が適切だっただけで、全ての印刷、すべての看板もそうとは限りません。
その都度、広告物の設置箇所や内容にあわせて確認すべきでしょう。
目から鱗な感じだったのでしょうし、その気持ちは良くわかるのですが、気をつけないとトラブルのもとになりますよ。
って、代理店の私が言うまでもないけど一応。
[tami]-2007/07/12 15:24:20 [Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)]