2007年 03月 01日
Lightroom TIPS 02 読み込めるファイルの長辺

Lightroomは、長辺10,000ピクセルを越えるファイルは、読み込めない ようです。

Photoshopで、11434 X 1806 ピクセルのパノラマ写真を合成し、Lightroomに読み込もうとしたら、次のアラートが出ました。
f0075955_2144790.jpg

そこで、ヘルプのTIFF format を見ると、その中に、

Lightroom supports large documents saved in TIFF format (up to 100 million pixels with pixel dimensions of no more than 10,000 on a side).

と出ていました。
PSDでセーブしたものでも読み込めなかったので、読み込めるファイルの長辺にリミットがあるようです。

となると、パノラマ写真は、Lightroomでは管理できないですね。
[PR]

# by yukinyaa03 | 2007-03-01 21:46 | Lightroom
2007年 02月 26日
Lightroom TIPS 01 Vibrance(自然な彩度)とSaturation(彩度)の違い
Adobe Photoshop Lightroom 1.0に関する記事を上げていきます。


Beta4までの記事と区別するために、Lightroom TIPS 0001としました。
ただし、カテゴリーは、従来通りLightroomのカテゴリーに入れておきます。

思いつくままにアップしますので、使い方マニュアルにはならないと思います。
使用感や検証記事としてお読みください。


●Vibrance(自然な彩度)とSaturation(彩度)の違い


現像モジュールの基本設定の中に、二つの彩度をコントロールするスライダがあります。
ひとつは、Vibrance(自然な彩度)、もうひとつはSaturation(彩度)です。

Saturation(彩度)のほうは、Camera Raw 3.xまで搭載されている、彩度スライダと同じもので、Photoshopで言えば、色相彩度ダイアログで、マスターのスライダを動かすのと同じ調整になります。
つまり、すべてのカラーの彩度が並行して上がっていきます。

それに対して、Vibrance(自然な彩度)は、LightroomBeta4から搭載された彩度調整機能です。
PhotoshopCS3のCamera Raw 4にも搭載されます。
Saturationと違う点は、人肌に近い色に対しては、ほかのカラーに比べて彩度の上がり具合を抑えた調整になるという点です。
また、Saturationに比べると、弱めの調整になっているようです。

Vibranceは「自然な彩度」という日本語訳になるようですが、確かにこちらのスライダの方が、彩度調整が自然な感じになります。
肌色系(と言っても、人種によって違うと思うけど)の彩度の上がり方を抑えてるので、赤系の色も、上がり方が控えめです。
それに対して、緑や青は、かなり上がります。

f0075955_200238.jpg
おねーちゃん画像じゃなくて、誠にすみませんです。m(__;)m
(クリックで幅1200pxになります。え?したくないって?そんな・・・・)
(ちなみに、この画像、グレーバランス取れていません。ていうより、チャートでバランス撮るとアンバーに寄りすぎるのでやめました。)

画像の並び順と異なりますが、最初Saturation(彩度)のスライダを50まで上げて書き出しました。(右の画像)

そしてLightroomの左右比較(Before/After)画面に切り替えて、Afterのほうを再びSaturation=0に戻し、Before(Saturation=50)の画面を見ながら、Vibrance(自然な彩度)のスライダを上げて、背景のグリーンの印象が同じくらいになるように調整しました。
(チャートのRGB値を見ながら調整したのではありません。)
Vibrance(自然な彩度)の数値が72という中途半端なのは、そのためです。

Vibrance(自然な彩度)を上げた方は、背景のグリーンは同じくらいの印象なのに対し、肌の彩度が抑えられているのが分かると思います。
逆に、青は、いっそう強調されています。
つまり、青空の風景などに使うと、よりいっそう青空が強調されます。


私は読んでいないので伝聞ですが、Vibranceのことを「肌の調子をきれいにする彩度調整」と解説してあるところがあるそうですが、それはちょっとニュアンスが違うと思います。
全体的な彩度調整の中で、肌色が派手になりすぎないような、抑えた調整が出来ると言うことだと思います。

Vibrance に関して、Helpに書かれていることを引用します。

Vibrance  Adjusts the saturation so that clipping is minimized as colors approach full saturation. Vibrance also prevents skintones from becoming over saturated.
[PR]

# by yukinyaa03 | 2007-02-26 20:31 | Lightroom
2007年 01月 22日
モニタで表示される色とは
新藤さんのところ1月20日の日記の流れで、学習帳にお越し頂いた方もいらっしゃると思うので、新藤さんの年賀状画像をお借りして、再びモニタの色の表示について調べてみたいと思います。


最初に説明しておきますと、掲載画像は、すべて私のモニタL997(5000K,ガンマ1.8でキャリブレーションしたプロファイルL997_061212_120cd_5K.iccを使用)で表示したものをキャプチャー(スクリーンショット)しました。
MacOS10.4.8では、キャプチャー画像に対しては、現在使用しているモニタプロファイルがあてがわれます。
それをPhotoshopで開いて、プロファイルをsRGBに変換し、web用に保存したものを投稿しました。


ではまず、ヂョンさんが投稿された、「画像とプロファイルの統合」ページの見え方から。
ヂョンさんがアップされた画像は、左が新藤さんのオリジナルでsRGBタグあり、右がヂョンさんが加工してタグなしにしたものです。
ヂョンさんが行った作業については、先に挙げた新藤さんの1月20日の日記をご覧ください。

Safari(2.0.4)
f0075955_150313.jpg
IE(5.2.3) ColorSync使用
f0075955_154525.jpg
Firefox(2.0.0.1)
f0075955_1571477.jpg
Opera(9.10)
f0075955_15113915.jpg

上2つはカラマネ対応、下2つはカラマネ非対応ブラウザです。

次に、これは新藤さんの1月4日の日記にアップされた年賀状画像。
Safariで表示し、画像を直接Photoshopにドラッグ&ドロップして開きました。
sRGBのタグが埋め込まれているのが分かります。
それをキャプチャーし、L997のモニタプロファイルで開かれたものを、再びsRGBに変換してweb用保存しました。
私の環境ではサイトに掲載されているものと、色はほとんど同じですが、私のモニタプロファイルに変換しているので、ご覧の方の環境では、サイトのものと色が違うかも知れません。

Photoshop
f0075955_15363441.jpg

この画像は、ヂョンさんのページの左側にリンクされているものと同じです。
そこからブラウザ上で、別ウインドウに開いたものが次です。

Safari
f0075955_15465626.jpg
IE(ColorSync)
f0075955_15513848.jpg
Firefox
f0075955_15563777.jpg
Opera
f0075955_1612246.jpg

上の3枚は、ほぼ同じに見えています。
下2枚は、上とは異なっています。
ですが、データにはタグが埋め込まれているので、FirefoxやOperaで表示した画像も、Photoshopで開くと上3枚と同じ色調になります。

Photoshopで開いた画像の色調の方が、作者のイメージ通りのはずですが、タグを読まないブラウザで見ている人には、作者のイメージが伝わりません。
しかし、実はこの見え方の違いは、Mac、しかもモニタを5000K相当にしてキャリブレーションしている環境において差が大きくなります。

Macは、カラマネ非対応アプリの場合、OSが色管理をします。
その場合、画像データの色空間には、モニタプロファイルが当てはめられます。
タグを読んでカラマネするアプリであれば、まずはタグに記載されたカラースペースで画像を開き、そしてモニタプロファイルの色域に変換されて表示します。
つまり、もとのタグがsRGBであれば、白色点6500K、ガンマ2.2のデータを、モニタプロファイルの色域(私のL997であれば、白色点5000K、ガンマ1.8)に置き換えることを行っていることになります。

5000Kにモニタの白色点を合わせるのは、特殊な使い方だと言えるかも知れません。
カメラマンの環境で、5000Kが推奨されるのは、商業印刷の評価光源が一般的には5000Kとされているため、印刷物の仕上がりとモニタの見た目を合わせるために、モニタの方を調整する必要があるからです。
商業印刷に関係しない人たちは、モニタの白色点は、ネイティブで使っていても問題はないと思います。

ただ、インクジェットプリンタで出力する場合の見た目も、ネイティブよりは色温度を落とした方が良いように思います。
このあたりは、環境光、観察光源の色温度によっても変わるとは思いますが。
(余談ですが、すごくオタク的な調整としては、観察光源を当てて用紙の白を測り、それをモニタの白色点にするのが究極かな?と思います。ただしその場合は、用紙ごとのモニタプロファイルが必要になるかも知れませんが。(^_^;) ガンマについては、インクジェット用光沢写真用紙を使う場合は、ガンマは1.8よりも高い方がマッチングするような気がしてます。ちゃんとした検証はしていません。)

話を戻しますと、現在のMacは、タグがない画像の場合は、最初からモニタプロファイルの色域で規定して表示してしまいます。
つまり、私のL997であれば、L997_061212_120cd_5K.iccを、その画像の色空間とみなして表示するわけです。

このことは、けっこう問題なのでは?と思われるかも知れませんが、通常は、モニタの色空間は、ネイティブのままなら、sRGBに準拠しているはずです。
Macの場合は、AppleRGBを基準にしていると思いますが、その場合も白色点は6500Kで、カラースペースも大体同じような形をしています。
違うのは採用しているガンマ値ですが、そのためタグなし画像はそれぞれのOSでは明るさが違って見えますが、カラースペースは似ているので、色の違いはさほどないと思います。
従って、モニタをネイティブで使っているなら、タグなし画像にモニタプロファイルを当てて表示しても、色のイメージはさほど損なわれないことになります。

しかし、モニタプロファイルをカスタマイズしていると、話が変わります。
5000K、ガンマ1.8にキャリブレートされたモニタプロファイルは、sRGBとかなり色空間の形が違います。
従って、そのモニタプロファイルを、データの色空間としてしまうと、閲覧する側は、発信側の意図する色彩を正しく受け取っていないことになります。

ですが、世の中の大半のOS、Windowsの方は、カラースペースがsRGBがお約束なので、画像がsRGBであるのが当たり前、モニタもsRGBに準拠してるのが当たり前、ということで、タグがなくても色の見え方の違いはさほど大きくないのです。


さて、下の図は、赤線がL997を5000Kにキャリブレーションしたカスタムプロファイル、青線がsRGB、青い点が新藤さんがsRGBで投稿したデータのプロット、赤い点がそのデータをL997のプロファイルに変換したものです。
f0075955_17351244.jpg

私もちょっと前まで勘違いしていましたが、モニタを5000Kにキャリブレーションしているということは、今見ているモニタは、sRGB対応モニタでも、表示できる色空間はsRGBではないということです。
昨今AdobeRGB対応モニタが取りざたされていますが、ネイティブのまま使うなら、AdobeRGBに近似したモニタのカラースペースでデータが表示されると思いますが、5000Kにキャリブレーションしたら、AdobeRGBとはカラースペースが異なってくると思います。
このことは、実際の運用上には問題にならないですが、厳密な意味としては、AdobeRGBの色を見ていることにはなりません。

デジタルデータを目に見えるようにするには、デバイスが必要です。
つまり、デバイスによって色が作られているわけです。
もし、本当の意味でのAdobeRGBにこだわるなら、6500K、ガンマ2.2でキャリブレーションすべきです。
モニタがAdobeRGB域まで表示できるものであるなら、その時はじめてAdobeRGBで規定された色が見られることになります。

ということで、私が日常L997で見ている色も、sRGBでもAdobeRGBでもありません。
sRGBやAdobeRGBを、L997_061212_120cd_5K.iccに置き換えた色を見ているのです。
それはつまり、AdobeRGBやsRGBを印刷した時の色調をシミュレーションしていることになります。
(実際には、印刷のシミュレーションには、プリンタプロファイルで変換する必要がありますが。)

このガマット上のプロットは、そのことを表しています。
青点は、実際のsRGBの位置を示していますが、私が目にしているのは、赤点で示されるカラーです。
この図の青点と赤点は、今示しているL値の中で、1:1対応しているわけではありませんが、どの明るさにおいても、おおよその相関関係を保っているのが分かると思います。


さて、話が少し逸れましたが、タグなし画像にモニタプロファイルを当てはめて開いた場合と、sRGB画像をモニタプロファイルで変換した場合は、色が違います。
下の図で、赤線は先ほどと同じL997_061212_120cd_5Kのカラースペース、赤点はsRGBをL997_061212_120cd_5Kに変換したデータ、黄点は元データはsRGBで作成されたけれど、タグなしになってカラースペースが不明のRGB画像を、L997_061212_120cd_5Kに当てはめて開いた状態です。
f0075955_2227152.jpg

赤点と、黄点の位置が違うことが分かります。
つまり、モニタに表示される色が違うと言うことです。


Photoshopには、「プロファイルの指定…」と「プロファイルの変換…」という設定があります。

「プロファイルの指定…」のほうは、そのデータの作成からスペースが分からない時、つまりタグなしの時に、データが作成されたカラースペースを指定するものです。
sRGBで作成された画像がタグなしだった場合は、sRGBを指定すれば、作成時に意図されたカラーで表示されますが、ほかのカラースペースを指定してしまうと、表示される色が変わってしまいます。

これと同じ事が、カラマネ機能のないブラウザでは行われています。
つまり、タグがあろうがなかろうが、RGB画像には、モニタのカラースペースを指定して表示してしまうわけです。
カラマネできるブラウザでも、タグがない場合は、モニタのカラースペースを使います。

試しに、新藤さんが日記に載せた画像(sRGBタグあり)を、Photoshopで開き、タグなしにしてから、モニタプロファイルを指定すると、タグを読まないブラウザで表示する色調と同じになりました。
f0075955_23171417.jpg




書きながら、紆余曲折してしまい、途中文章がおかしいところがありますが、ご容赦ください。
書いていて、少し自身のないところもあります。
間違いがありましたら、忌憚なくご指摘頂ければ幸甚です。
[PR]

# by yukinyaa03 | 2007-01-22 12:21 | カラーマネジメント
2006年 12月 05日
Lightroom 007 (@Beta)
Beta4になってからの、はじめてのLightroom記事です。(^_^;)

キャプチャ画像入りで、詳しく書いてる時間がないので、文字だけです。
時間が出来たら、内容を書き加えます。


・・・・・・・・・・・・・・・・・・・

Lightroomフォルダの置き場所

Lightroomの読み込みは、実データを、ユーザ>ピクチャ>Lightroom>Managed Photos(Macの場合)の中に取り込むのがデフォルトになっているようです。

読み込みのダイアログで、「ファイルをLightroomライブラリにコピー」になっていると、元データが同じパソコン内にあっても、LightroomはコピーをLightroomフォルダの中に作ります。
つまり、そのパソコンの中で、データが倍になってしまいます。
iPhotoも同じようなことしますよね。
これでは、いくら高容量のHDを積んでいても、すぐにいっぱいになってしまいます。

ですが、LightroomはiPhotoと違って、「既存の位置にあるファイルを参照」して読み込むことが出来ます。
この場合は、参照して、Lightroomの中で表示するためのキャッシュを作るだけで、実データはコピーされません。
私、現在、Lightroomに22,000枚近く読み込みましたが、Lightroomフォルダは、6.79GB程度です。

ただ、22,000枚のサムネールキャッシュはまだ全て出来上がってはおらず、今後ファイルを閲覧するたびに徐々に作られていくキャッシュによって増えていくと思われるので、22,000枚に対するデータベースの容量がどれくらいになるかは分かりません。

Beta3までは、フルサイズに近いくらいの大きさの表示用キャッシュも作る構造になっていました。
でも、今は、必要な時だけキャッシュを作り、一番大きいキャッシュについては、30日で削除されるようです。(環境設定で、それがデフォルトになっています。)


さて、Lightroomフォルダは、デフォルトの場所から移動させても大丈夫です。

つまり、一度デフォルトの場所でLightroomフォルダを作成したら、もっと高容量のボリュームに移動させて、そこで管理することが出来ます。

その場合は、Lightroomを起動する際に、オプションキーを押しながら起動すると、ライブラリの場所を聞いてきますので、移動した先のLightroomフォルダを指定してやります。

このダイアログでは、あらたなライブラリを別の場所に新規に作ることも出来るようです。
場所と名前を指定すると、読み込み数が0になった、あらたなライブラリ画面が開きます。
その際出来るライブラリフォルダは、任意に付けた名前のフォルダが作られます。
つまり、例えば「Snap Library」などとライブラリ名を付けておくと、フォルダ名はLightroomではなくなります。
ということは、最初にLightroomという名前で作られたフォルダも、あとから名前を変えられるのかも知れません。
これについては、試していません。

それらの方法を使えば、ジャンルごとにライブラリを作って、複数のライブラリを管理することも出来ます。
私の場合は、仕事写真とプライベート写真は、分けることが出来るので、この方法でライブラリを分けた方がいいと思いました。
ただし、違うライブラリ同士では、今のところデータの交換や同期は出来ません。

複数マシンでライブラリを同期するにはどうしたら良いか?と思っていたのですが、現状では別ボリュームにライブラリを置いて、使う時はそれぞれのマシンにつなぎかえてライブラリを読み込むしかないのではないかと思います。

ちなみに、今のところ、Lightroomフォルダをネットワークボリュームに置いて、複数マシンで同時アクセスというのは出来ないようです。
でも、製品になるまでに、複数マシンで簡単に同期するようになって欲しいですね。
現状では、Lightroomのパラメータをサイドカーファイルに書き出しても、Bridge&Camera Rawとの互換性もありませんし。

(Beta4から、「写真バインダとして書き出し」という機能が加わったのですが、ちょっと実用上疑問に思う部分もあるので、もう少し検証してから突っ込みを入れようと思っています。)


自宅のマシンのストレージを参照して作成したライブラリを、ノートパソコンに入れて持ち歩くことも出来ます。
その際は、起動させると、オリジナルに対するリンクがないので、グリッド表示のファイルの角に、?マークが付きます。
ですが、サムネールキャッシュの作成が終わっていれば、拡大表示も出来ます。
さすがに1:1表示は、多少ジャギーが残ったままですが、ルーペ表示くらいの大きさだったら、閲覧に問題ないと思います。
ただし、元ファイルがないので、色調補正などは出来ません。

キャッシュが出来ていれば、スライドショーも出来ます。
つまり、自宅の膨大なストレージを持って行かなくとも、その影武者だけで、プレゼンなどが出来ると思います。

余談ですが、?マークが出るのは、「参照して読み込み」した場合で、読み込んだ時の場所とのリンクが切れているということです。
その際?マークをプレスすると、元のファイルが見つからないので検索するか、というダイアログが出るので、オリジナルの場所を指定してやると、?マークが消えます。
この作業は、ひとつのファイルに対して行えば、他のファイルも同じ場所にある場合、すべてリンクが復帰します。
[PR]

# by yukinyaa03 | 2006-12-05 08:51 | Lightroom
2006年 10月 25日
アプリケーションによるRAW現像結果の違い
先日、仕事の掲載紙を見て、驚きました。
9月20日に撮ったのに、桜が咲いている!
f0075955_19564590.jpg

(^_^;)
桜じゃありません。

掲載紙を見た時、これは製版の時のリサイズに問題があるのだろうと思いました。

ですが、今日、曇り空に枝のディテールが飛んでいる別の画像で、同じような現象が出ているのを発見!
そして調べてみたら、納品したデータが、そういう状態だったことに初めて気がつきました。
大量にフリンジが発生しているのです。

カメラは、EOS5D、レンズは16-35/2.8L(絞りf5.6)です。
そして、Camera Rawで現像しました。

空がハイライト警告で真っ赤になるくらい飛んでいたので、露光量を下げ、明るさを上げて調整しました。
トーンカーブでもハイライトを抑えています。
その分、全体のコントラストは上げました。
現像時にはリサイズしていません。

その結果がこれです。
100%表示してトリミングしました。
f0075955_2092730.jpg
どっひゃ〜、ですね。(^_^;)(^_^;)(^_^;)

それでも、Bridgeのサムネールや、Camera Rawウインドウでの100%未満の倍率表示では、こんなにくっきりフリンジが出てこないんです。
100%にすると、いきなりこのような状態に。
通常は、ウインドウに合わせたサイズで見ているので、こんなになっているとは気がつきませんでした。
現像したJPEGのほうでは、サムネールにすでにフリンジが見られます。
でも、サムネールだから、中途半端な倍率のため起きたのだろうと、100%で確認してませんでした。

原因は、シャープネス設定のようです。
Camera Rawは、デフォルトで25%のシャープがかかるようになっています。
私は、ずっとそのままにしていました。
シャープネスを落とすと、フリンジが和らぎます。
ということは、Camera Rawは、現像時にけっこう輪郭強調してるんですね。
今回はそれに加えて、初期設定とはパラメータを変えていることも、強調された原因のようです。
ちなみにここまでフリンジがひどいと、Camera Rawのフリンジ除去では追いつきません。
フリンジ除去するにも、シャープネスを0%にしたほうが良さそうです。

Camera Raw初期設定(出荷時の初期設定よりカスタマイズしてますが)だと、こんな感じです。
f0075955_2025435.jpg
これもシャープネスは25%かかっていますが、ほかのパラメーターは、彩度+10、トーンカーブコントラスト(中)以外は動かしていません。
それでも、色のにじみが出ていますね。


そこで、キヤノン純正ソフトだったらどうかと思い、試してみることにしました。

まずは、DPP。
ピクチャースタイルは、スタンダード、シャープネス設定は3、その他無調整のデフォルトの状態です。
f0075955_2028289.jpg
シャープネスの掛かり方にだいぶ差があるのが分かります。
やはりフリンジは出ていますが、輪郭強調が少ないので、Camera Rawほど強調されていません。
DPPの環境設定のノイズ緩和設定は、「強」になっています。
(このノイズ緩和設定は、フリンジには効かないという話です。)


さて、たぶん、ほとんどの人は使わないとは思いますが、Raw Image Taskでも現像してみました。
Raw Image Taskは、ImageBrowserから起動させて使います。
以前のEOS Viewer Utilityの流れを汲む現像ソフトだと思います。
ここでも、ピクチャースタイルスタンダード、シャープネス3、その他無調整で現像しました。
f0075955_20361761.jpg
おおお!
意外や意外。
これが一番フリンジが少ないです。

う〜む・・・・。

Camera Rawが汎用ソフトのために、現像結果がベストではないのは仕方ないですが、DPPよりRaw Image Taskのほうが良かったとは・・・・。
Raw Image Task、私の環境のせいかも知れませんが、パフォーマンスが悪いんです。
展開に時間がかかります。
IntelMacだったら、速いだろうか?
対応してるだろうか?


Camera Rawのシャープネス、もう少し下げた状態を初期設定にし直そうかと思います。
今、Camera Raw初期設定では、「すべての画像」にシャープが適用されるようになっていますが、「プレビュー画像のみ」にしたほうがいいのかも知れません。
ちなみに、展開画像にシャープネスが掛からない設定で、一番上の画像をJPEGに書き出したら、こうなりました。
f0075955_20534548.jpg
偽色は見えますが、少なくともシャープがかかったものよりはまともです。

納品データにはシャープネスをかけず、印刷工程で使用サイズに合わせたシャープネスを掛けるのが、基本とされてますが、今回はそのことを実感しました。
やはり、納品データには、シャープネスかけないほうが良さそうですね。
[PR]

# by yukinyaa03 | 2006-10-25 21:06 | デジタル・フォト
2006年 10月 25日
SafariとPhotoshopでの色の見え方
wan-wanさんの承諾を得て、wan-wanさんがいろんなアプリでweb用に縮小した画像が、Mac OS 10.4のwebブラウザSafari上で、どのような色に表示されるかを、Photoshopで開いた場合と比較しました。

画像は、左がSafari、右がPhotoshopです。

画像は、ナナオのモニタL997上で、両者のウインドウを並べてキャプチャーしたものです。
キャプチャー時のモニタプロファイルは、ナナオデフォルトのモニタプロファイルです。

Macでキャプチャーする(スクリーンショットを撮る)と、その画像には、モニタプロファイルが当てはめられます。
それをPhotoshopで開く時に、作業用色空間sRGBに変換しました。

ここにアップした画像は、そののち「web用に保存」で画質80で圧縮、ICCプロファイルを埋め込んで保存しました。

wan-wanさんの画像は、長辺350ピクセルだったので、2つ並べてちょうど700ピクセルになるように、キャプチャーしました。
従って、リサイズはしてませんので、劣化は少ないと思います。
ここのブログでは、横幅700ピクセルまで、オリジナルサイズのまま投稿できます。


では、まず、コンデジ画像をPhotoshopの「web用に保存」を使って縮小したもの。
wan-wanさんの画像には、sRGBが埋め込まれていました。
f0075955_17575927.jpg

次に、縮小専科のデモ版を使った画像。sRGB埋め込みなし。
左のSafariのウインドウでは、L997のモニタプロファイルがあてがわれて表示しています。
右のPhotoshopのほうは、作業用色空間sRGBを当てはめて開きました。
f0075955_1815622.jpg

次に、縮小専科、Exifつき。
Exifを見ると、確かにsRGBと書かれているのですが、何故かSafariはタグなしと見なし、上の画像と同じ色調、つまりモニタプロファイルを当てはめてしまいました。
Photoshopで開くと、タグが読まれ、sRGBの色調で開きます。
f0075955_1851590.jpg

最後に、NC4で縮小した画像。
Nikon sRGB が埋め込まれています。
Photoshopはこれに対して、プロファイルの不一致のアラートは出さず、そのままsRGB画像として開きます。
この画像は、「web用に保存」同様、SafariとPhotoshopでの色の見え方は、同じです。
f0075955_18171161.jpg


結論として、Safariは、sRGBのタグがあっても読まないことがあるということになります。
それが何故かは分かりません。
お分かりになる方がいらっしゃいましたら、教えて下さい。


下は、sRGBと、私が持っているモニタプロファイルを比較したものです。
白がsRGB、赤がL997、緑がイーヤマのH540Sです。
f0075955_18363625.jpg

L997は、さすがにsRGB対応を謳っているだけあって、メーカーデフォルトのモニタプロファイルは、ほぼsRGBのスペースに近似しています。
H540Sも近似と言えるかも知れませんが、L997と比べると、差があります。

sRGBに近似しているとは言うものの、微妙な空間の違いはあります。
この色空間の違いが、見え方の差を生んでいます。
モニタの色空間が、sRGBに近似していない、あるいは相似形でない場合は、もっと色の見え方が変わると思います。

汎用性のある共通のカラースペースを使わず、デバイスに依存してカラーを表示していたのでは、デバイス間のカラーの一致は望めません。
そのために、カラーマネジメントが必要になります。
[PR]

# by yukinyaa03 | 2006-10-25 18:52 | カラーマネジメント
2006年 10月 20日
タグなし画像のSafari(Tiger)での見え方について
タグなしweb画像が、Macでは色が違って見えるということに、Windowsユーザーの方々は関心を持って頂けないようなので、シミュレーションしてみます。

まずは、sRGBが埋め込まれている場合。
f0075955_1847689.jpg

次に、タグがない画像(元画像はsRGB)を、私のPBのSafariで表示した場合。
f0075955_18491788.jpg

次に、同じくタグがない画像を、L997で表示した場合。
f0075955_18503012.jpg


これだけ違いがあることが、お分かりいただけたでしょうか?

解説しておきますと、
Photoshopで、sRGB画像に対してそれぞれのモニタプロファイルを「指定」し、それからsRGBに変換して、sRGBのタグを残したまま、web用に保存しました。

Safari上でタグなしファイルに対して、モニタプロファイルをあてがうことことは、この「指定」というのと同じ意味です。
つまり、作成されたカラースペースと、違うカラースペース内で、同じカラー値が使われるので色が変わるのです。
RGBはカラー値(RGB値)が同じでも、カラースペースによって、色は違うことを理解して下さい。
つまり、カラースペースの大きさによって、カラー値がプロットされる位置が違うのです。

紺碧の空も、タグなしになると、Safariでは色がくすんで見えてしまいます。
MacとWindowsのガンマ値の違いもひとつの原因ですが、モニタプロファイルの色域に左右されるので、モニタがプアだと、もっと色が濁ることになります。
タグが付いていれば、その色空間のカラーを表示しますので、Photoshopで開くのと同じカラーで見ることが出来ます。

ですので、タグは重要だと思うのですが・・・・・。


関連過去ログ、Trackbackしました。
[PR]

# by yukinyaa03 | 2006-10-20 19:07 | カラーマネジメント
2006年 08月 18日
染料インクジェットプリントの色が落ち着く時間
依頼を受けて、EPSON PM-G820(染料プリンタ)のプロファイルを作成しました。

昨日ターゲットのプリントを受け取り、プロファイルを作成したのですが、ガマットが、シャドウ域でいびつな形をしていました。
そこで、1日おいて、今日また作り直してみました。

白が昨日、最初に作ったもの。
赤は、その20分後に作ったもの。
緑は、今日作ったものです。
f0075955_1239446.jpg
D=50では、大きな違いはありません。
ほぼ同じと言えると思います。
これより明度の高い方でも、同様に差はありません。
f0075955_12405723.jpg
ですが、明度を下げていくと、差が出てくる部分があることが分かります。
f0075955_1241106.jpg
f0075955_12412585.jpg
f0075955_12413528.jpg
f0075955_12414642.jpg
おおむね、今日作ったプロファイルの方が、形も整い広くなっています。

これは推測ですが、染料プリンタの場合、インクが乾くのに時間がかかるので、そのために昨日測色したのと、今日測色したのでは、ガマットの形が変化したのではないだろうかと思います。
ガマットの大きさを見ても、今日作成したもののほうが全体的に大きいですし、平均dE値も、確か昨日は1.3だったのが、今日は1.2になっていました。
今日の方が、精度が高いことになります。

私は、今は染料プリンタを使っていないので、最近では気になりませんが、染料機をお使いの方は、色が落ち着くまで、乾燥には1日程度は見たほうが良さそうです。
その際も、すぐに重ねたりせず、銀塩プリントを自家処理した時のように、広げてしばらく自然乾燥するのが良いでしょう。

今回送ってきた方も、相紙を挟むなどしてありましたが、正確に計測するには、1日以上置いてから送って頂いた方が良さそうです。
[PR]

# by yukinyaa03 | 2006-08-18 12:50 | カラーマネジメント
2006年 08月 18日
色はデバイスによって表現されている
ちょっと、大上段に振りかぶったタイトルですが、モニタによる色の見え方の違いを考察してみたいと思います。


これは、昨日写真帳にアップした画像ですが、PowerBookのSafariで見たら、雲のハイライト部分が、だいぶ飽和して見えることに気がつきました。
f0075955_004627.jpg

そこで、Monaco GamutWorksを立ち上げ、PowerBookのモニタプロファイルと、画像データを表示させてみました。
f0075955_051847.jpg
赤線がPowerBookのモニタプロファイルで、白点がデータのハイライト部分です。
L=83が、データ上のハイライトの上限でした。
しかし、この図を見ると、データはモニタプロファイル域内にあり、飽和していないように思えます。

そこで、勘違いをしていることに気がつきました。
いま表示している白点は、sRGB上のデータの位置を示しているものです。
それに対して、実際私が見ているのは、sRGB上のデータ値ではなく、モニタプロファイルの色域に変換されたものを見ているのではないだろうかと思いました。

そこで、Photoshopで、データのプロファイルを、sRGBからモニタプロファイルに変換(マッチング方法は、相対的)してみました。
ピンクの点が、モニタプロファイルに変換したデータです。
f0075955_0241736.jpg
データが、モニタの色域のはじっこにへばりついているのが分かります。

これよりももっとL値が低い部分でも飽和しており、飽和が始まるのは、L=70前後からのようです。
f0075955_0264750.jpg
なので、PowerBookでは、ハイライト側が飽和して見えたわけですね。

一方、PowerMacに接続している、ナナオのL997では、色域がsRGBに近似していることもあって、変換しても、あまり色の動きはありません。
青線が、L997のプロファイル、緑点が、L997のプロファイルに変換した値です。
f0075955_0381549.jpg

L=80あたりでは、やはり飽和が見られるようになりますが、それ以前では飽和していないので、PowerBookに比較すると、ハイライト側の微妙なグラデーションが見て取れます。


以前も書きましたが、モニタの色域が、データの色域と近似していれば問題は少ないですが、かなり異なっている場合は、その色域にデータが大幅に変換されて表示されていることになります。
モニタでの見え方がおかしいからといって、データそのものの色域が変わってしまったわけではないですが、モニタを頼りに補正作業をする場合は、注意が必要です。
[PR]

# by yukinyaa03 | 2006-08-18 00:52 | カラーマネジメント
2006年 08月 16日
Dr.Brown's 1-2-3 JPEG !
1-2-3 JPEGは、これもRussell Brownさんが作ったスクリプトです。
一度の作業で、3種類のJPEGを作ることが出来、非常に便利です。

私は、RAWからJPEGに変換して納品しています。
その際は、サイズはオリジナルサイズ、画質は12を選んでいます。

そしてそれから、そのJPEG画像を使い、Photoshopの「コンタクトシートII」でコンタクトを作り始めるのですが、元画像がオリジナルサイズのままなので、コンタクトシート作成には、結構時間がかかります。

そこで、納品用のオリジナルサイズと、コンタクトシート用に縮小したJPEGを、同時に生成しておけば、処理時間が短縮されるだろうと思いました。


さて、1-2-3 JPEGは、Dr. Brown's Services 1.4という、スクリプトセットの中に入っています。
ダウンロードは、昨日書いたRussell Brown tips & techniquesからできます。

Mac用とWindows用のEasy Installerがありますので、それをダウンロードします。

今回紹介するのは、PhotoshopCS2用ですが、サイトの下の方には、CS用の1-2-3 JPEGも用意されています。
CSお使いの方は、そちらをご利用下さい。
ただし、CS2用と、ダイアログが同じかどうかは、試していないので分かりません。

スクリプトセットの中には、他のスクリプトも入っていますが、詳細はサイトを見て下さい。

また、それぞれのスクリプトの使い方も、チュートリアル・ムービーが用意されていますので、大変分かりやすいです。
QuickTime Tutorials と書かれた下に並んでいるのが、チュートリアル・ムービーです。
1-2-3 JPEGのチュートリアルもあるので、私が解説するまでもなく、そちらを見て頂ければ分かると思います。


ですが、簡単に説明します。

f0075955_1333753.jpg

Dr. Brown's Services 1.4をインストールすると、Bridgeのツールメニューに追加されるので、ツールメニュー>Dr. Brown's Services 1.4>Dr. Brown's 1-2-3 JPEGで、ダイアログを開くことが出来ます。

f0075955_19571752.jpg

このダイアログは、すでに設定済みの状態です。
一番始めに開いた時は、何も設定がされていません。

ご覧になって分かると思うのですが、イメージプロセッサとほとんど同じです。
イメージプロセッサでは、JPEG,PSD,TIFF に展開していたのが、JPEG3種類に展開に変わったと思えばいいでしょう。

1. Select the images to process
f0075955_23231892.jpg
「処理する画像を選択」です。
この作例では、Bridge上の102枚の画像を選択していること意味しています。

2. Select iocation to save processed images
f0075955_23241767.jpg
「処理後の画像を保存する場所を選択」ですね。

イメージプロセッサの場合は、指定したフォルダの中に、JPEG,PSD,TIFFのサブフォルダが自動生成されましたが、1-2-3 JPEG の場合は、サブフォルダを作るか否かの選択と、それぞれのサブフォルダに名前を付けることが出来ます。
初期状態では、1.Small,2.Medium,3.Large というフォルダ名がプリセットされていますが、変更可能です。
f0075955_23394466.jpg
私は、1.Original(オリジナルサイズ)、2.Contact(コンタクトシート用)、3.Web(web用)という風に分けてみました。

フォルダ名は、日本語で付けても大丈夫だと思います。

通常の私の仕事では、1.と2.だけあれば良いのですが、今回は説明用に3.まで設定しています。

3. JPEG File Types
「JPEGファイル形式」です。

ここで、3種類のJPEGの設定ができます。
設定は、使う人の勝手で良いわけですが、私は作例として、次のようにしてみました。

Save as JPEG1(JPEG1として保存)
f0075955_2325875.jpg
ここではリサイズせず、画質も最高画質の12に設定しました。
カラースペースや解像度は、Camera Rawの設定が適用されます。

Save as JPEG2(JPEG2として保存)
f0075955_23255034.jpg
ここでは、あとでコンタクトシートを作るための縮小画像を設定しています。
画質を8、Resize to Fit にチェックを入れ、コンタクトシート上でプリントされる大きさと解像度を設定しています。

f0075955_23271787.jpgリサイズする際の単位は、pixels以外にも、cmやmmでも設定できます。
コンタクトシートを作る際には、再サンプリングされるので、あまりシビアに大きさを決めておく必要はないとは思いますが、コンタクトシートに印刷される大きさがきちんと決まっているなら、それに合わせた大きさにしておいたほうが、より高速に処理されるのではないかと思います。

Save as JPEG3(JPEG3として保存)
f0075955_23353242.jpg
ここでは、webに載せることを想定して、カラースペースをsRGBに変換し、ファイルサイズを小さくする設定をしています。

4.Peferences
f0075955_23361113.jpg
「環境設定」です。

イメージプロセッサと違うのは、アクションの設定項目がグレーアウトしていません。
アクションを施す場合は、上の設定で、各JPEGの設定欄に Run Action というチェックボックスがあるので、そこにチェックを入れます。

アクションの種類は、1つしか設定できないので、それぞれのJPEGに違うアクションを行うということは出来ないようです。

あとは、著作権情報と、プロファイルの埋め込みの設定です。

これでRun(実行)ボタンを押すと、処理が始まります。


さすがに3種類の画像を作るので、通常の処理より時間がかかるようです。
もし、単純に時間が3倍かかるようだと、同時処理してる意味があまりないですけどね。(笑
正確な時間計測はしていません。
ま、実行ボタンを押したら、ちょっと休憩、というところでしょうか。


さて、当初の目的、コンタクトシートの作成時間の短縮は、果たされたでしょうか。

まず、オリジナルサイズ(約760万画素。トリミングしてあるので、小さくなってます。)の画像、102枚から、A4用紙に横3枚X縦5枚のコンタクトシートを作ってみました。
枚数は7枚、作成時間は、9分47秒かかりました。

次に、コンタクト用に縮小(約64万画素)した画像から、同じ条件で作成。
作成時間は、7分59秒でした。

むむむむ・・・・・・
た、大して短縮されてませんね・・・・(-.-;)
コンタクト程度に、360dpiは高解像度すぎるかも知れませんが、私は、コンタクトだからこそ、高解像度にしておいたほうが良いのでは?と思っています。

ですが、現実には、インクジェットの300dpiと360dpiに違いがある!と叫ぶのは、私のような変態だけでして、実用上は300dpiで十分だと思います。
そうすれば、もう若干、時間が短縮されるかも・・・・(^_^;)

でも、その差が現れるのも、コンタクトシートの枚数が多い時でして、枚数の少ない時は、オリジナルサイズから作成しても、大して違いが出ないことになります。
今回は、1分48秒短縮されましたが、1-2-3JPEGで、サイズ違いのJPEGを作成することによる処理時間の延長を考えると、ほとんど相殺されてしまいそうです。

また次回テストしてみようと思いますが、コンタクトシート作成時間短縮のための、サイズ違いのJPEG作成、という目論見は、少しはずれてしまいました。
しかしながら、オリジナルサイズのPSDやTIFFからコンタクトシートを作るよりかは、時間の短縮になっていると思います。
[PR]

# by yukinyaa03 | 2006-08-16 13:47 | Photoshop