近年では撮影データを印刷以外のメディアへ展開することが一般的になった。適切な容量、カラーマネジメントなど、多メディア展開を前提にした画像入稿とワークフローが求められている。
画像データのトラブルと望ましい画像処理ワークフローについて、エコーインテックの庄司正幸氏に伺った。
画像データのトラブルと望ましい画像処理ワークフロー
エコ―インテックは、DTP制作の会社で、いろいろな仕事がお客様から入って来る。その中で、画像を中心にした入稿に関してのさまざまな問題とか、エコ―インテックでやっている画像ワークフローについて話をしたい。
入稿形態という意味では、エコ―インテックの制作現場は日本ではなく中国である。東京は営業部署しかなくて、実際の現場は中国でやっている。そういう環境もあって、画像に関してはCMYK支給が非常に多い。RGBを支給されるときもあるが、主なるものはCMYKで支給されてそれを貼り込むということがメインになっている。
また、画像の補正は、難易度の低いものに関してはよく受けるが、本当にうるさいものに関しては、プルーフ環境が、中国から送るわけにはいかないので、現場ではなかなかその辺の部分ができていない。
カタログの製版などでいろいろ合成処理をするときは、全部CMYKのレタッチでやっている。私は現場の人間にRGBレタッチを教える立場にいて、現場の人間はできるが、実際お客様のほうがCMYK原稿なので、CMYKでのレタッチという話になる。
最近、入稿に関して感じるのは、InDesignなりIllustratorにリンクされている画像の画素数が大きすぎるということが1つある。また、色の定義に関して、カラースペースに関してのいろいろなトラブルも起きている。
アナログ時代、私も昔は製版会社にいたので、倍率測定器でものを測ってからスキャニングするとか、実際に貼る原稿をそのサイズにして原寸にするというのが鉄則という世界で長くいたが、現在は撮影したものがそのまま来ている。
実際、Photoshopでいろいろな画像を開いてみると、ほとんど生のものをそのまま持ってきている。CMYKにはなっているが、ちょっとした補正はしているにしても、画素数とか、倍率を合わせてうまくコントロールするということはないまま支給される。
それをやるのに、最終的にはアウトプットというか、PDFを制作する時点で解像度をコントロールするというのがAdobeのテクノロジーの中にあるが、そういうところをやるにしても、お客様の要望によっては非常に高画質なまま、オーバークオリティなままPDFを作らざるを得ないといったことがある。
まず、定期折込における画像フォーマットと配置倍率と書いたが、折込といっても新聞のチラシ等ではなく、例えば日本橋にはコレド室町というのがあって、そういうところの入り口にはいろいろなイベントの冊子というか、8ページくらいのものがある。そのデータを見せていただいた中での話である。
おもしろいのは、クリエイティブをやっている制作会社からデータを受け取って、それをもう少し仕上げていくという仕事に入るが、基本的に最初の制作会社の使い勝手の良さでフォーマットとかそういうものが全部変わってしまう。
例えばIllustratorしか使えないオペレータがいるデザイン会社と、InDesignを使っているデザイン会社というのは、本当に極端に違う。そういう会社が同じような仕事の中にある。その統計的なもので、倍率を見てもらうとわかるが、ほとんどリンクされているものに関しては50％以下、半分以下で、画像がオーバーな状態である。
こちらもほとんどPhotoshopフォーマットで、InDesignだと画像フォーマットとしてPhotoshopフォーマットを使う人が多いが、それでも配置している部分を見ると約8割が縮小している。
InDesignの中にはそういうインフォメーションを見るところがあり、これはカメラの情報だが、それを見ると、Photoshopで開いたときは400dpiベースにして280×187mmの画像になっている。これは撮影時の画像だが、InDesignに貼ったときは34×23しか使っていない。
つまり、dpi相当でいくと、400dpiが原寸だとすれば3,333dpiの画像が貼ってあるという話になってしまう。これは完全にオーバークオリティである。こういう画像が1紙面に50点とか貼ってある。
当然、例えばネットを通してデータのやり取りとか、実際にそれを開いて処理して戻すといった作業だけでも、実はパソコンが、Mac等が高性能になったとはいえ、相当負荷の高い仕事をしているというのが現状だろう。
もう1つ、書き出しプリセットの違いということがある。左側はAdobe推奨の設定で、先ほどの3,333dpiの写真が貼ってあったとしても、左側でやった場合にはリサイズがかかって300dpi相当の画像に縮小した状態でPDFができる。
ところが、右側のほうはリサンプルをしない。ということは、でき上がったPDFは3,333dpiのままPDFの中に貼り込まれた状態になる。これも、お客様の印刷会社から「これでやれ」という指示でこういうジョブオプションをもらうので、変更するわけにいかないのでこのままやるしかない。
昔は確かに画素数が足りなかったので、「変にサンプリングして画質を悪くするのなら、しないほうがいい」という設定モードはあったかもしれない。ところが、今の現状でいくと、先ほど見てもらったとおり、もう半分以上が50％以下で貼ってあるような、相当圧縮率のかかった画素数の部分で、これをやって本当にいいのか、作業しながら疑問にちょっと感じているところではある。
これでやったからといって、それほどそれが後工程の印刷で品質のいいものに取って代わるとは決して思えない。その辺が、なかなか我々のほうで決められない値なので、お客様とのやり取りでなかなか辛い仕事のフェーズである。
実際にそれをベースにしてやってみると、ネイティブデータのパッケージの中で画像の容量を見ると580MBと、非常に高いが、それをダウンサンプリングして、要するに300dpiに落とした形でPDFを作った場合、PDFのデータ量が4.1MBになる。それでも300dpiの画像なのでクオリティ的には保持している。ZIPでも6.9MBである。ところが、それをネイティブのサンプリングしない場合だと43MBと、極端にデータ容量が違う。
データ容量が違うということは、作業自体で考えれば基本的には作業の長さに依存することになるので、本来はこういうふうな形にするか、それとも最初の段階で適切な画像サイズで作業するということを本当はお勧めしたい。
それから印刷物の種類によって画素数が違う。月刊誌の場合は、縮小ではあるが、それほど極端な縮小率というのはない。ほとんど貼って出すというような感じで、エコ―インテックに入って来る仕事の中でも実はRGBで、それもJPEG入稿されて、印刷会社のほうからバッチ処理のような形でPhotoshopのアクションツールのようなものを支給されていて、もうルーティンでやる仕事になる。それの支給されているものは、調べた結果でいくと64％、半分以上がsRGBである。商品撮影など、私の知り合いのカメラマンはほとんどAdobeRGBがデフォルトだが、取材などで使われているものだとほとんどsRGBで撮っている。
カメラも見ていただくと、これは少し古いデータなのでiPhone4が載っているが、この辺だとCOOLPIXといったコンシューマカメラで取材したりするので、どうしてもこれはsRGBの世界での画質として入稿されることが多い。
それを支給されているので、印刷仕上がりの条件であればOKということでPhotoshopのアクションでバッチ処理してレイアウトしていく。赤字に関しては、初校段階で赤が入ればまた画像をレタッチする。それ以外はどんどんルーティンのままやってしまう。雑誌だと、こういう画像の扱い方が多いと思う。
次に製品カタログの場合だが、この製品カタログが非常に重い。例えば2,000ページといったカタログなどを仕事でやるが、その中でも大体半分くらいはもう50％以下にされていて、なおかつPhotoshopが多い。
紙面の片面見開きの画像となるとお客様もうるさいので、そういうところだとPhotoshopでレタッチしたままのレイヤー付きの画像が支給されたりする。後で校正を出して赤が入ったらすぐ直せるという感じだが、それをそのまま貼らなくてはいけなので、それだけで膨大になって、この画像だけで200MBだとか、そんなものが飛んでくる。
カタログの場合、半面見開きで扱うような写真などで、それも補正のパラメータ付きで入稿されたりすることが非常に多い。ここでも40％の人はほとんどがそういう大きいサイズで、なおかついろいろレイヤーを使ってレイヤー調整して合成しているようなものの、そのレイヤー付きのまま作業として使わざるを得ないといったような入り方をしているものが多い。
製品カタログとか、そういうものの中では、最近とみにUSMの部分の問題が大きいと感じている部分がある。これは実際に画像を輪切りにした状態である。100％でUSMをかけた画像を25％に配置してやった場合、その画像を縦切りに切ってみると、シャープネス効果、エッジ効果というのを見ることができる。これを25％にすると、差は出るにしてもほとんどエッジ効果が消えている。要するに、シャープネスがかかっていないという状況になっている。
最初の段階で、原寸で、例えば先ほどお見せしたもので言えば最初の400dpiの画像の状態でシャープネスをかければ、300とかいう形でUSMをかけたとしても、実際にそれがInDesign上で25％に下げるということはUSMを消しているということになる。そういう形のものが最近多いと思う。
下の画像はPhotoshopでシャープネスをかけていて、上の画像はかけていないが、見てもらうと、やはりエッジの効果があることがわかると思う。下のほうがやはりくっきり見える。シャープさがあるが、上のほうはぼけたような形になっている。
これは実際の商品撮影のCMYK画像だが、40～50点全部調べてみたところ、全部USMがかかっていなかった。これは校了までのデータだったので、完全にUSMかからずに印刷されている。
データは私のほうで加工していなくて受け取ったデータだが、ほとんど最近は商品データはまず画素が大きくて縮小して貼ってあって、CMYKだけれどもシャープネスもない。こういう画像を非常に多く見かける。エッジ効果をかければそれなりに見えるのに、ちょっとシャープな感じのしない印刷物ができ上がってしまう状態のまま進行されているのではないかと思うことがよくある。
もう1つはカラースペースの話である。ものによって、カラースペースを切り替えなくてはいけない部分がある。基本的なものとしては「Japan ColorでCMYKにしなさい」という指示が飛んで来る場合と、お客様から支給された「オリジナルプロファイルで変換しなさい」という2種類ある。
よくトラブルになるのは、現場の技術のほうからは「これでやりなさい」という指令が来るが、何かの問い合わせで印刷会社の営業の人などにメールなどで質問すると、「Japan Colorでやっておいて」と言われたりする。「本当はこれなのだろう、でもこっちでやっていいのか」というような曖昧さが最近多いと思う。
本来は最初のカラースペースの設定というのが大事だが、なかなか意思統一されていなくて、エコ―インテックの現場のほうが戸惑ってしまうというのが最近多いと思う。後から「これにしてなかったから」という形でクレームとして言われることもあるが、現場自体考えると「こっちでもいいよ」という指示がいろいろな部署から回ってきたりしてトラブルになることがある。
実際に見てもらうと、ここで比較しているのはJapan Color2001というAdobeのプロファイルのガモット域とJapan Color2011という認証制度で使われているホームページからダウンロードできるプロファイルだが、この2つを比較すると、ほとんどガモット領域は同じで、ちょっとの違いはあるにしてもさほど変わらない。
ところが、今ある印刷会社からいただいているデータだと、赤とか黄色方面、緑方面に相当ガモット域が違ってくる。そうすると当然、印刷したときの結果も、例えばJapan Colorでプロファイル変換したもので考えるとガモットが小さくなっているので、余計印刷に行くとちょっとくすんだような上がりになってしまう。そういったことの違いみたいなことに最近無頓着になってきているのではないか。
これはエコ―インテックと一緒に協力してやっている画像レタッチ専門の会社の例である。真ん中を中心にして、左と右でちょっと色が違って見えると思う。これはPhotoshopで色相をいじって動かしているが、ΔEで2だけである。Labのa方向のaチャンネルをΔE2動かした。
デバイスによって再現性が違うが、本当はこちらのほうが少し赤く見えて、こちらのほうが少し青く見えるはずである。なかなかデバイスの違いで出ないこともあるが、実際ちょっと違うふうに見えると思う。
私が昔関わった仕事で言うと、こういうふうなメーカーもそういうことをやっていた。それを事例にすると、これも、こちらとこちらでΔE2くらいしか動かしていないが、ちょっと違って見える。
これは、あるメーカーがカメラマンと一緒に画像をやって、画像コンテンツを、自分たちの画像自体をライブラリ化している。そこで画質の安定というか、印刷の品質を安定させたいということで、Japan Color2011を採用して、その基準でやろうという話になって、いろいろ印刷会社とテストしたらしい。
上がってきたのを見ると、例えばAさんとBさんで色が違っている。印刷会社に聞くと、プルーフ認証だとΔE6くらいの範囲内に入っていれば認証合格のはずなので、「その範囲に入っている」と言われてしまう。しかし本当は色を統一したいので、クライアントが困った挙句、友人の会社のところに相談に来た。
今やっていることは、その会社の中で、色を安定させるための指針としてプルーフ見本を付けて、「この色に近づけてもらいたい」というワークフローに変えたいということでやっている。
言い方からすると、この流れはJapan Colorと言われるような認証制度の話になるが、こちらはどちらかというとプルーフで合わせてその色に近づけてもらうということである。昔で言うとJMPA、雑誌広告基準の考え方というのは、まさにプルーフで校正を出して、その色にみんなで合わせようという動きである。そういう形のものに近いワークフローを、今組もうとしている。
これがどうなったか、最近メンバーと会っていないのでわからないが、色というのは、実際印刷物を使っていろいろなことを展開しているような企業にとっては、この辺の基準化というのは非常に考えなくてはいけない世界のようだ。その部分を、画像だけの内校のような形で一生懸命構築しているという話もある。
これは通販系のカタログで、実際に我々が中国で普通にやっている仕事の内容である。ここはもう少し画像などのワークフローをうまくコントロールしてやっている仕事になる。エコ―インテックのオペレーションは、ディレクションとオペレーションとあって、画像をここからもらってきて、会社の中でストックして、向こうのほうからデータをもらってきて、ここで作ったものをパッケージ化してアップする。
エコ―インテックは中国でやっているので、中国を経由してオンラインでやっているので、なかなかトラフィックはあると思うが、実際にそういうふうなことがやれるのでやらせてもらっている事例である。
ここの部分で言うと、画像を常にこちらで、ディレクションをやっている印刷会社のほうで画像処理したものを、エコ―インテックのほうに、ある一定の期間でサーバ同士で通信してストックしてきている。
こちらのほうは文字とかInDesignのネイティブをコントロールするサーバの仕組みがあって、ここからInDesignをダウンロードしてきて、こちらの画像と、中に文字を組んだり、いろいろなことのレイアウトしたものをパッケージ化して、ここにアップすると、それがサーバ上でまたコンテンツ管理されるといった仕組みをやってみた形のものである。これは海外の外資系の通販カタログの仕事で、こういうワークフローを組んでやってみたことがある。
RGBワークフローの基本の話をしたい。基本的にはRGBの最適化、画像変換してRGBやCMYKに変える。これは昔からいろいろな形でやろうといって提唱してきたことである。実際にこういうものは、エコ―インテックのワークフローの中で言うと皆無に等しい。やはりCMYKベースで動いているものが多い。
私の仕事自体、自社の開発の人間とプログラムをしていきながらやることも多いが、例えばカタログ系だと、印刷の状態が終わって校了になってからWeb用のデータ構築みたいなものがあったりする。
CMYKのカタログのInDesignのデータから、必要なスペック情報をプログラム的に抜きだし、なおかつここに貼ってある例えばEPSなりPSDのデータをベースにしてWebで使うJPEGファイルに変換するというような流れがある。
カタログだと、いまだにCMYKからRGB変換とか、どちらかというとJapan ColorからsRGB変換してそれをWebで使うという流れの方がまだまだ多い感じがある。というより、ほとんど「こういう形で作業をやってくれ」という形態がまだ今も多い。
実際には違う方法もあるのではないかと考えて、これは出版社と私と著者と3人で相談してやったワークフローである。撮影された画像をRGBで補正しながら自分でデザインして本を作っていくという流れである。この流れの中はすべてRGBで進行するという流れのやり方をした。
その中で私がサポートしたのは、実はここの部分である。たまたま紙質がマット系の紙だったため、Japan Colorのプロファイルをそのまま使うことはできなかったので、この本を印刷してくれる印刷会社にお願いしてICCプロファイルを作成した。
それをベースにして、印刷会社に初校を出してもらうとき、デザインをやった人間がPhotoshopのCMYKのシャープネスを何段階か自分でかけてみて、どういう効果が出るのか、初校の段階でテスト刷りをやらせてもらった。
そのときには実際に変換してシャープネスもかけてということだが、そのとき私のほうで用意したのは、変換をバッチ処理するツールである。デザイナーはカメラのデータを縮小して貼っているが、印刷会社に入れる前の段階で全部InDesign上に原寸で貼って、なおかつPhotoshopで決めたシャープネス効果が得られるようなバッチ処理のツールを間にかませて初校を出した。それでOKになった段階でそのまま最終まで行ってしまう。
ここで作業している著者は、もうRGBだけで処理するという話である。それに対して、ここに行くときだけこういう仕組みをうまくかませて、CMYKでPDFにして印刷会社に入稿するという流れを作った。
ここで作ったものは、逆にリサイズをうまくかけてやればそのままEPUBのような電子書籍に変換できるし、印刷の条件、紙質を変えるのであれば、ここの部分をコントロールすることによってすんなりといくようなワークフローが組めるという形になる。
少しお見せすると、InDesignを自動的にバッチで呼んできて、中にどんなスタイルがどうリンクされているかを全部データベースに登録するためのボタンが付いている。2番目は、データベースに入っている情報をもとにして、例えばそれにUSMまでかけてCMYKにして戻すといった処理を行う。最後はInDesignに再リンクしてPDF/X-1aで保存する。こういったところをルーティンとしてやらせるような、ボタン1つ押せば何とかそこまで行くようなものを提供した。
これ1つ作っておくと、実は他の仕事にも全部応用できる。これは3年くらい前のもので、今のOSで動かないのでデモは難しいが、こういう形でちょっとしたことを補助することによってワークフロー自体はそのままRDBのマシンなりワークフローとしてはまとまって、必要なデバイスのところにそういうサポートができればものが作れるといったようなこともありえるのではないか。
そう考えると、CMYKから、例えばRGBのWebのオペレーションをするということではなく、適切な、CMYKはCMYK、RGBはRGBという流れがあってもいいのではないかというふうに思うこともある。
これは画像とは直接関係ないが、今エコ―インテックのある部隊でやっているのは、HTMLとCSSをベースにしてDTPの組版をしてしまう。それの基礎的な仕組みを作るというようなことをやっている仕事がある。
これはある大手出版社と絡んでやっているものだが、今までのようにCMYKありきで何かのデータを作って、それをRGBに展開するという話ではなく、逆にRGBでやったものから展開するということもありうるのではないか。そういう流れが少しずつできてきているように思っている。
これはアメリカのPrinceという、HTMLとCSSからPDFを生成するためのモジュールである。これはHTMLである。何ページか分をHTMLとCSSで組まれたホームページの状態のものである。実際にPrinceのホームページに載っていて、ソースコードもあるので、興味がある人はダウンロードしてみてもらいたい。中は、当然だがいろいろリンクされているJPEG画像がある。
ここにCSSと呼ばれるものがある。CSSというのはスタイルシートと呼ばれるが、中身は完全にテキストで、フォントは何を使うとか、ページサイズはいくつといったようなことが書かれているだけである。
これがPrinceのデモ版のライブラリだが、味もそっけもない、コマンドラインで打ちこむためのモジュールである。それをプログラムに仕込んだものがあるので、ここにドラッグする。そうすると、今PDFが1つ増えた。フォント環境が違うので化けるが、実は先ほどのホームページと同じ内容のものがPDF化されている。
こういう形で、ホームページのHTMLと同レベルのものが印刷用のPDFとしても使えるというふうな、逆の発想である。今までのDTPでやってHTML書き出しとかEPUB書き出しとかいうInDesignにする流れとは逆だが、HTMLの一般的なオープンソースで作った内容からCSSを変えて逆にPDFを作成させるようなことも、動きとして最近出てきている。この辺に関しても、基本的にはWeb系なので、最初のデフォルトになるデータとしては当然RGBのデータがベースになっていく。
そういう意味では、最初のRGB自体、撮影されたものとか、いろいろなコンテンツ自体、体系化したものがあって、それがいろいろな用途によって枝分かれしていって、必要なところで必要なサイズの用途として、解像度の問題とかシャープネスの問題等がコントロールされたものが行って印刷になったりWeb系になったりという形の流れが理想的なのではないか。
2014年6月3日TG研究会「デジタル入稿の新常識とワークフロー」より（文責編集）