先日AppleでHTML 5はこんなんだぜ！みたいなページが公開されていましたが、今度はGoogleが「HTML5Rocks」というHTML 5のリソースサイトを公開されたようですね（って、これも今知った）。

中身についてはまだ見れてませんが、Twitterを眺めていたら目に入ったので簡単にお知らせまで。頑張りましょう（何を）。

こちらのサイトにURLを入れてチェックすると、YSlow!とPage Speedでのチェック結果が表示されます。それに加えてHTTPリクエストの数やロード時間、ウォーターフォールチャートも出るわで至れり尽くせりです。チェック項目の解説なんかも用意されています。

便利です。ありがとうございます（笑）。

今朝方「そう言えば…」と思い出して、外部からパフォーマンスチェックができるサービスの一覧へのリンクを入れておきました。で、改めてお礼といってはなんですが、そこにも追加した「Load Impact」さんをちょっと紹介しておこうかな、と。

こちらにも無償で利用できるパフォーマンスチェックツールがありますので、それとあわせてここのサイトのサービスを使えばどういうことが確認できて、どういう対処の仕方があるのかを簡単に書いてみましょう。

同時接続数を変えてロード時間を計測できるLoad Impact

Load Impactは、スウェーデンのとある会社が提供しているオンラインのロードテストサービスです。こちらの主なサービスは、同時に複数のクライアントで接続して負荷をかけてロード時間の平均や使用帯域を計測することができるのが特徴です（お試し版は同時接続数50クライアントまでで一日3サイトまでかな？）。

大規模なアクセスがあるサイトなんかはロードバランサーなんか入ってて負荷分散されてたりするんでしょうが、中小規模のサイトではそうはいきません。とはいえ、プレスリリースやテレビに紹介されたとかで一時的にアクセスが増えてしまうことも考えられます。ホスティングの共用サービスだとサーバのチューニングなんかはできないでしょうけど、ちょっとした負荷でも問題なくアクセスできるようなサイトにしておくことも時には必要になります。備えあれば嬉しいな、です（違）。

インフラが全然ダメなのにいきなり10MBのコンテンツとかダウンロードさせてたら、サーバとクライアントのコネクションがなかなか開放されず、すぐ一杯一杯になることは容易に想像できます（どことは言わんけど 笑）。かといって、新しい接続のためにリソースが確保できるかって言うとそこにも限界がありますから、自分とこで対応できる限界を知っておくこともまた大事なわけです。

いろんなUAをシミュレートできるPage Analyzer

この類のサービスを専門にされている会社さんは、大体無償で利用できるパフォーマンス計測ツールを公開されています。Load Impactさんでも「Page Analyzer」なる計測ツールがあります。

ここのツールの特徴は、他のとこよりも格段に豊富なUser Agentsをシミュレートすることができることでしょうか。

IEはもちろん、FirefoxやChrome、Safariなどのいろいろなバージョンが用意されています（ブラウザ毎にコネクション数とか違いますからね *1）。おそらくストックホルムからのアクセスになるはずですが、比較的レイテンシも少なくて良い感じです。

うちのヘボいトップで大体3秒前後。Chartbeatを使って国内からアクセスされている皆さんの様子を見てる感じでは、平均2秒いくかいかないかぐらいですのでまぁ良しと。秒数うんぬんより、UAのシミュレートができるということで便利です。

段階的に同時接続数をあげ、負荷をかけてロード時間を計測する

いよいよ本題に入りましょう。単なるサーバの設定などを確認する負荷テストであれば、専用のツールなどがあるのでそれを使えばいいわけですが、コンテンツの表示にかかる時間となるとどっかからやんないとなかなかわかりません。

が、しかし。このLoad Impactさんのサービスを使えば、段階的に同時接続数をあげて負荷を与えつつ、表示までにかかってる時間をチェックすることができるんですね。しかも同時接続数50までなら無償でチェック可能！、250まで接続数を上げてもたった$9！ってなわけです（どこの通販だと 笑）。

ま、そんなわけでですね、とりあえず同時に50クライアントまで増やしながらテストしてみるには無償でも可能です。Webサイトのトップにある入力欄にURL入れて、上の図の左のFreeテストに進めばチェックできます。

ただし、チェック結果の保存にはアカウントの登録が必要だったかな？ アカウント登録しても最初はFree版なので大丈夫ですけどね。

有償版は同時接続数をもっと増やしたり、細かな設定をした上でテストが可能になっています。画面見ただけだとちょっとわかりにくいのですが、$9/per dayってなってるのは「24時間内にテストする」ワンタイムフィーみたいなもんです（他にもオプションがあります）。

有償でもそんなビックリする値段じゃないですし、ある程度の規模での同時アクセスが見込まれるコンテンツなどを制作されている方にはいいかもしれません。自分の作ってるコンテンツの限界点を知るためにも、とりあえず試してみるのが一番（笑）。

とりあえず試してみたらこうなった

いや、実はちょっと前からWordPressの設定やサーバの設定をいじってはチェックしていたんですけど、今回同時に100クライアントまで増やしてロード時間を計測してみました。一番安いプランではスウェーデンのストックホルムからしか計れなかったので、とりあえずそれで。

テストにはそれなりに時間がかかりますので、コーヒー飲んでたりしてればそのうち終わります（テスト数による）。この図は、10クライアントから段階的に10ずつ増やし、最終的に100クライアントの同時アクセスまでの結果です。

グラフの線は、できるだけ横方向に同じような状態が良いのは言うまでもないですかね。グラフの縦は表示までの秒数になっています。80クライアントのとこでちょっとだけあがってますけど、広い目で見ればストックホルムからでほぼ3秒前後なので良しとしましょう。

例えばグラフがこういうことになったら、サーバ側の設定をちょっと変更したりする必要があるかな？と。40クライアントが同時アクセスしてきたらガクッと時間がかかり始めたとか、そういうことがわかるわけです。このグラフの形によって意味があるので、それはフォーラムで解説されています（英語だけど 笑）。

最後に。ちゃんとアクセスされてます（笑）

「ホントにアクセスされてんの？」とか疑う方もいらっしゃるかもしれないので（笑）、うちのサーバを監視してる「MUNIN」の画面を出しておきます。

上の図はApacheのプロセスの数を表示したグラフです。左側の縦2つのグラフの右端がガクッとあがってますが、この時がLoad Impactで負荷テストをしている時間です（50と100と2回やってるので2箇所だけ急激にあがってますね）。

WebサーバのApacheはアクセスが増えれば自動的にプロセスを増やす仕組みになってるので良いとはいえ、テストしたらある数値から急激に時間がかかってる場合などは、サーバ側の設定やらコンテンツの作り方などもろもろを見直したりした方がいいかもしれませんね。

サーバの設定をいじるなんてみんながみんなできるわけではありませんし、システムのチューニングは餅は餅屋で任せた方が良いとは思います。でもまぁ、一応こういう負荷テストを使って、コンテンツの弱点を探すってのもありじゃないかな？と思ったので簡単にご紹介まで。

うちもとりあえず「100人乗っても大丈夫」のようです。

*1: ブラウザのバージョン毎の仕様はこちらが詳しいです

標準ウェブ制作完全ガイド 〜 プランニングからデザイン、そしてシステム構築まで。Webの「仕事」がトータルに理解できるプロフェッショナル養成講座。

松岡清一 監修／MdN編集部 編

で、肝心の内容はといいますと…、

「Web業界で一流を目指す、すべての方に」といった感じで

Web制作に関わるすべての方に向けて、プロとして必要な最先端の知識を1冊にまとめました。プランニングからデザイン、そしてシステム構築まで、 Web制作の「現場」の仕事で必要とされる常識や仕事の流れを解説しています。PLAN［設計・プランニング］→DO［制作・実装・デザイン］→SEE［効果・検証・解析］の3段階の構成でWeb業界の「現在」がトータルにわかる、プロフェッショナルのための教科書。

http://www.mdn.co.jp/di/book/6102/

こんな感じで、Webサイトの企画立案的なことから制作や開発、公開後の話にいたるまで。いまどきのWeb制作において「これぐらいは知っておきたい」といったことを総合的にまとめたようなものです。

これからWeb業界に飛び込みたい方、今もう働いているけど次へのステップアップを考えてる方などに最適かと。分業化が進んでいる時代ですので、自分の担当する職域以外がどのようなことをしているのかなどもわかるんじゃないかと思います。

→ 標準ウェブ制作完全ガイド（MdN Design Interactive: 目次あり）
→ 標準ウェブ制作完全ガイド（impress Direct: 見本・目次あり）
→ 標準ウェブ制作完全ガイド（Amazon.co.jp）

実は半年間の…（笑）

実はこちら著者名にこそ出ておりませんが、わたくしも企画段階から参加させていただいておりまして、本書には半年超の思い入れがあるのです…。巻末に執筆者のリストとともに担当パートが記載されていますが、まぁ340Pもある分厚い書籍で執筆いただいてる方も多いので、軽く自身の担当分を明記しておきます。

執筆は、主にPart 2の制作・実装・デザイン的なパートを担当しております。私ひとりでやってる項目と各Partで本文の執筆協力をしている項目がいくつかあるので結構な量になっております（笑）。※担当箇所は項目番号です

Part 1

025（すべて）／050-055（本文執筆協力）

Part 2

089-115（すべて）／116-123（本文執筆協力）

Part 3

140-142（本文執筆協力）

というわけで、本屋さんでお見かけの際にはお手にとってそのままレジへ、パラパラと内容等をチェックしていただければ幸いです。340P、読み応えあります。

11月の半ばぐらいに「Googleの検索結果表示のアルゴリズムの一指標としてページの表示速度も加味するかもね」的な発言（元ソースはこれかな）があったり、Webをさらに速くするための技術にあたる「SPDY（スピーディって読むらしい）」についてアナウンスしたり、やたらと表示スピード（パフォーマンス）に関するものが増えてきました。

気になる気になる、あー気になる（笑）

さらに追い打ちをかけるように12月に入って早々、今度はGoogle Analyticsのコードを非同期モードで動作させる改良版のコードが公開されたり（まだβ版です。元ソースはこちら）、Google Webmaster Toolsの中にWebサイトの表示速度の統計が出るようになってます（下図）。

こんな感じでGoogleからアクセスした場合の数ヶ月間の平均ロード時間が表示されます。ちなみにこのサイトは、今日現在1.7秒と出てます（*1）。

前述のGoogle Analyticsのコードは、実際Webサイト表示のボトルネックになってる場合があって、最近特にそれで引っかかってたのも事実です。うちは試しに変更してみましたけど、喉のつっかえが取れた感じで速くなりました。

さらにさらに昨日今日の話ですが、DNSのルックアップ時間の短縮という名目で「Google Public DNS」の登場です（現在はアメリカ国内向けっぽいけど）。とまぁ、11月の半ばの発言を後押しするかのような動きなんですよね…。

検索のもう一つの巨頭、Yahoo!さんも以前からWebサイトの表示速度の改善には力を入れてるわけで、Firefoxのアドオンである「YSlow!」やドキュメントがかなり前から公開されてます。この辺はGoogleさんも同じように「PageSpeed」というアドオンとドキュメントをリリースしてます。

ちなみにAmazonさんの関連企業であるAlexaでは、TOP100のサイトの情報ページにサイトの平均ロード時間が表示されてまして、「1秒以下だと超速い。2秒以下だと速い。3秒以下で平均、それ以降は話にならない（嘘、遅いとか超遅いです 笑）」的な表示が出るようになっています。

別に脅すつもりはないですが、皆さんのWebサイト大丈夫ですか？ いや、正直なところ。8秒ルールとかあれもう古すぎますから。今3秒以下ですよ…。

ま、そんなわけでうちのブログで4月のエイプリルフールに冗談交じりで上げたクソみたいなエントリーがあるのですが（笑）、これをもう少し真面目に解説するエントリーを近々あげようかと思ってます、という予告のためのエントリーです。

*1: うちはWordPressを使ったブログですから、PHPがページを作ってブラウザに送るまでの時間がマシンパワーなんかに左右される部分もあったり、自宅サーバで回線が細いうえにいくつかのWebサイトが動いてるため、できるかぎりパフォーマンスをあげるためのアレコレをやってます（試行錯誤の様子が上のグラフにも出てますね 笑）。

スライドの方は別途公開ということで、フォローしておいた方が良さそうなカラーマネジメント系の話とモニタの調整の手順（Windows / OS X）、あとおまけで講演時に使ったトマトの写真の元写真からCamera RAWを使った補正の手順をざっくりと書き記しておきます（元ファイルはダウンロード可）。

（追記: 2009.09.25）スライドと音声をCSS Niteさんの方で公開していただいたようです。なお、スライドのみSlideShareでも公開しておりますので、オンラインで確認したい方はこちらからどうぞ。

非常に長いエントリーになるので気合いを入れてください（笑）。

ブラウザのカラーマネジメント的なこと

まず、ブラウザを介して見る自身の環境の状態からいってみましょう。ICCのWebサイトのこちらのページでカラーマネジメントの状態を確認することができます。

ブラウザでそのページをみると一番上に写真がありますが、ICCのColor ProfileのVer. 4に対応していれば普通に表示されるはずです（Safari）。Ver. 2までの対応であれば下半分が正常な状態（Firefox 3.5）になり、全然カラーマネジメントと縁がなければ4箇所がバラバラの色になるはずです（IEとか）。

Firefoxも3.0まではカラーマネジメントを有効にすると全部同じになってたような気がしますが、3.5だとおそらく下半分だけ有効になるんじゃないかと。まぁ、それでも十分です。

ICCのWebサイト以外にも、miyahan.comさんの方でカラーマネジメントに関する非常に詳細な記事とテストルームなどが公開されています（まとめるのが面倒な話を丁寧にまとめられていますので、一度は目を通しておくと良いのではないでしょうか）。

→ miyahan.com | 液晶ディスプレイとカラーマネジメント
→ miyahan.com | 液晶ディスプレイとカラーマネジメント テストルーム

こちらはカラーマネジメントが有効なFirefox3.5

こちらはカラーマネジメントのないInternet Explorer 8

いずれもmiyahan.comさんのテストルームでの表示です。
こちらのテストルームは、下の方までバーッといろいろテストできるので、キャリブレーションの前と後でチェックしてみると、いかに何もしてない状態が「…」なのかよくわかるのではないかと。

Firefoxでのカラーマネジメントオプション

Firefoxのカラーマネジメントの設定についてですが、3.5からはデフォルト有効で3.0.xまでは手動で有効にするとお話ししました。設定の確認は、ブラウザのURLバーのところに「about:config」と入力し隠されている設定情報を表示します。

ページの上部にある「Filter（日本語版だとフィルタとかですかね）」に「gfx」と入力して、カラーマネジメントに関する項目だけに絞り込みます。

ここに出てきた「gfx_colormanagement.mode」がカラーマネジメントのオンオフの設定です。Firefox 3.0.xまでは「0」か「1」でオンオフを切り替えたはずですが、Ver. 3.5からは「0」でオフ、「2」が初期設定（写真だけカラーマネジメントを有効）です。「1」はページ全体にカラーマネジメントを効かせるみたいな感じだったかと。

「gfx_colormanagement.display_profile」は、モニタのプロファイルを指定する箇所なのでブランクでも構わない気もします。一応ダブルクリックすれば.iccもしくは.icmのファイルまでのパス（場所）を指定できます。

Windowsならキャリブレートしたモニタの.icmファイルかsRGBの.icmファイルを指定すれば良いのではないでしょうか。

WindowsのsRGBの.icmは「C:\\WINDOWS\\system32\\spool\\drivers\\color\\sRGB Color Space Profile.icm」あたりにありますかね…。この後解説するCalibrizeを実行したあとに生成される.icmファイルは「C:\Users\ユーザ名\Documents\My ICC Profiles\ほげほげ.icm」という感じで、ドキュメントフォルダに保存されます。

OS Xの場合はColor Profileが保存される場所が何カ所かあるので、ライブラリの中や自分のホームディレクトリのライブラリにある「ColorSync」などを探してみましょう。「/Library/ColorSync/Profiles/Displays/ほげほげ.icc」みたいな感じで指定します（空欄でいいかと）。

あとは再起動すればオッケーです。

モニタのキャリブレーション – Windows

Windowsの場合、昔からAdobeさんのソフトを使ってらっしゃる方は「Adobeガンマ」というのがコントロールパネルにあるのでそれを使っても構いません。ここ数年でリプレイスした方なんかは入ってないので、「Calibrize」というソフトをありがたく使わせていただきます。

→ Calibrize

公式サイトからダウンロードし起動するとこのような画面が出てきます。とりあえず中央右の「Next」 をクリックして次の画面へ。

モニタの明るさとコントラストを調整して、黒と白のそれぞれの中に●がみえるような感じにしましょう。下にあるのは明るすぎとか暗すぎのサンプルです。

RGBそれぞれのスライダが出てきたら、先日お話ししたように2mぐらい離れて目のピントをあわせないようにしてボーッとしながら各色背景と中央の●が区別できないように調整してください。

で、最後に保存してお終いです。前述したようにこのファイルは、ご自身のディレクトリの「ドキュメント」の中にあります。

WCSが導入されたVistaの場合は、コントロールパネルを開くと「色の管理」ってのがありますので、そちらを開いて自分のディスプレイのプロファイルとします。おそらく読めない謎の文字が出てるんじゃないかと（笑）。XPの場合は、カラーマネジメントなんてものはないに等しいはずなのですが、「画面」とかその辺でひょっとしたら追加できるのかもしれません。

モニタの状態が良くなったかどうかは、先ほど紹介したmiyahanさんのテストルームで確認してみましょう。IE 8でみるとカラーマネジメント効かないので、FirefoxとかSafariで見た方がいいですかね。

モニタのキャリブレーション – OS X

OS Xの場合は、システム環境設定の「ディスプレイ」にあるカラーを開いて「補正…」をクリックして「ディスプレイキャリブレータ・アシスタント」を開きます。

調整の仕方はほぼ一緒で、中央に表示されたリンゴとその背景が区別できないように左右のスライダを使って調整します。これを6回ぐらい繰り返します（笑）。

さらにモニタのガンマ値を設定し（Snow Leopardから2.2という話ですね）、モニタの色温度を設定します。モニタの色温度は、環境によって異なるものなのですが、一般的には6500℃にされていることが多いです（印刷が対象の場合は5000℃とか）。ようは白いものが白いように見える状態にすると。

で、最後に保存してお終いです。
Windows同様、miyahanさんのテストルームで確認しましょう。

おまけ。RAWファイルを使った現像処理

先日「時間が余ったらRAWからもやろうかな」と一応準備だけしていたのですが、大方の予想通り駆け足でも時間オーバーになったのでこちらにおまけとして一連の処理を書き記しておきます（元ファイルは一番下からダウンロードしてください）。

中川さんの講演やAdobeさんのフォローでもお話がありましたが、RAWは非破壊データになります。なので、元ファイルを維持しながら変更点だけが別に保存されて、いつでも撮影時の状態に戻せるという優れものです。失敗したと思った写真も、別にあとから露出を変更したりすることができますので（限界はありますが）非常に便利です。

RAWはカメラによって違いますが、大体12bitや14bitのデータになっていて、白く飛んでしまったようなハイライトや暗く潰れてしまったシャドウ部分にも撮影した生のデータが記録されています（どこまで記録されているかは、メーカーやカメラのお値段にも… 笑）。なので、後からハイライトを抑えたりシャドウを持ち上げたりできると。だから、モニタのキャリブレーションも必須ってわけですね。

ということで、先日の写真を使ってRAW現像してみましょう。

※今回使うRAWファイルは、NEFというNikonの独自形式です。一応AdobeさんのCameraRAWやLightroomでも開いて処理することが可能ですが、RAWに記録された公表されていないメーカー独自の設定などが飛んでしまいます。それじゃ困るって方は、メーカーが出してる現像ソフトの方が良いでしょう。Adobeさんの提唱するDNGというRAWの形式をサポートしているカメラも多いので、気にしたくない方はそちらを買っておくといいですね（ちなみにボクはRICOHのGRDとPENTAXのK-mはDNGで撮って、Lightroomで処理しています）。

まずは、CameraRAW（Lightroom）で開く

まず最初にお断りしておくと、今回はCameraRAWにしましたが、CaramaRAWでもLightroomでも基本的な画面構成というか処理系等は一緒ですので、どちらでやっても同じように作業できます。CameraRAWにはバージョンがあるので、古いバージョンでは最新のカメラのRAWが開けない（というか対応していない）とかあるかもしれません。

右側にパネルがいろいろ並んでいます。上に並んだボタンをおして適宜処理を選ぶという感じです。Lightroomはこれが単純に縦にバーッと並んでいます。

今回は作業の前にカメラのキャリブレーション（カメラプロファイル）を「Adobe Standard」に変更しました。メーカーさんによっていくつか出てくるものが異なると思います。

で、Adobeさんの初期設定だと「明るさ」と「コントラスト」がそれぞれ「+50」「+25」になっているので、これを一旦「0」に戻してみます。別に戻さなくても構わないんですが、まぁどうせやるならゼロからということで。

ホワイトバランスを調整する

撮影時にホワイトバランスのことを何も考えずに撮った場合には、状況によって白が白くなかったりしますが、それは後から「色温度」で調整可能です。今回はちょっと黄色いので、まず色温度を「2250℃」まで下げてみました。

露出を後から調整する

続いて思い切り暗く撮れているので、これを「露光量」で調整します。露出を適正に近くなるぐらいまであげてみます。ここで活躍するのが上にあるヒストグラムです。明るくすればヒストグラムの山がずれていくのが確認できるでしょう。

露出の調整はこのように後から調整できますが、カメラによってはやり過ぎるとノイズが出たりしますので「-2.0〜+2.0」の範囲で収めておきましょう。ちなみに露光量の下にある「白とび軽減」は飛んでしまったハイライト部分を抑えてくれます。

全体の明るさを調整

写真全体の明るさを調整するなら「明るさ」を使うと便利です。

露光量はあくまでも露出の調整です。前述したようにやり過ぎるとノイズやらが出てきます。露出補正は一定レベルで抑えておいて、全体の明るさを調整する時はこちらがいいんじゃないかと。

黒レベルと補助光効果

「黒レベル」はシャドウ（0）の位置を調整できます。「0」に近づけばシャドウの位置が左にずれ明るくなり、増やせば右にずれてより暗くなります。

写真はどうしてもそのままでは人間の目に見えてるようには保存してくれません。「補助光効果」は、今時でいうとこの「ダイナミックレンジ補正」に近いというか、シャドウ部分を持ち上げて暗く潰れ気味になるシャドウの部分を明るくすることができます。

皿の下の部分とかが明るくなり、ちょっとだけ見た目に近づいたのがわかると思います。人間の目は優秀なんですね。

コントラストや彩度を調整する

あとは適宜コントラストや彩度などを調整すればまぁ大体のトコが終わりです。

トーンカーブも用意されているので、ちょっと明るい部分と暗い部分のカーブを使ってコントラストを付けたい場合はそちらを使いましょう。

とまぁ、RAW現像が面倒とか思われてる方が非常に多いのですが、実際のところこないだPhotoshopだけでやった補正の作業というか手順と何ら変わりません（笑）。

色範囲を個別に調整する

さらにCameraRAWやLightroomでは、色の成分というか色相毎に色の強さをコントロールしたり彩度を調整することも可能です。

あとはPhotoshopで開いてリサイズとか色空間の変更を

こんな感じでRAWの現像が終わったら、Photoshopで開きます。

写真では画面ショットの撮影の関係で「オブジェクトとして開く」となっていますが、標準は「開く」になっています。その左にある「Adobe RGB〜」ってとこをクリックすると開く際のファイルサイズなどが設定可能です。ここでは16bitのAdobe RGBの画像として開いてみます。

埋め込まれたプロファイルで開きましょう（笑）。

Photoshopでの修正後8bitに変更します。写真の色補正だけならもう何にもすることはないんですが…（笑）。

で、使用用途にあわせてプロファイルを変更します。
ここではネット用ということでsRGBにしましょう。

最終的にできたファイルがこれです。

と、このような感じです。
他にもアンシャープマスクみたいな処理や色収差を補正したりノイズを除去したりといろんなことができます。非破壊データで壊れることもなく、後からいくらでも変更可能でさらにこれらの調整をコピーして他の同じような写真に適用できるなんて便利以外の何ものでもありません。使わないのはあまりにももったいない。

JPGで保存しておくと数年後あの写真使いたいと思っても、小さいサイズかつ加工されて保存されてもうどうしようもないとかありますからね。思い出はいつまでも綺麗なままで残しておいた方が良いかと（笑）。

ということで、おまけの方が長くなりましたが、こちらでCSS Niteのフォローアップとさせていただきます。

→ RAWデータのダウンロードはこちらから（著作権なんて放棄しますのでご自由に）

# Lightroomはハイブリッド版でお安いので、「写真の補正だけで終わりだよ」って方はこちらの方が最新版のカメラへの対応もCameraRAWのバージョンに影響しないのでいいんじゃないですかね。ボクは普段こっちです。

# あ、あとNik Softwareから出ている「ColorEfex Pro」ってのがあると、写真の現像処理に関するあんなことやこんなことをフィルタ的に適用できます。最近Photoshopだけでなく、Lightroomにも対応したようです（ボクはNikonのソフトの方で使ってます）。

→ Adobe Photoshop Lightroom 2.0（Amazon.co.jp）
→ Nik Color Efex Pro 3.0J Complete Edition（Amazon.co.jp）

ローカルにWeb制作環境を構築するとなると、サーバのことがわからない場合は一般的に「MAMP」とか「XAMPP」を使うと思うんですが、制作環境の自由度を高めるために私は「MacPorts」を使っています（簡単に言うと、OSとは別にUnix環境を一個作っちゃう）。

Wikiに書いてあることを順おって確実にやっていけば環境構築はできると思うのですが、ちょっとしたミスが原因でエラーになったりして、どうしていいか途方に暮れることになりかねません（エラー対応するにも基礎がないと大変です 笑）。

自由自在にコントロールできる制作環境を作りたいとか、MacPortsを使ってみたいけどどうすればいいかわからない人は、UnixのコマンドリファレンスとかApacheの解説書なんかを片手にチャレンジしてみてはいかがでしょうか。

※一応、自分のメモ代わり兼、知りたい人に面と向かって説明するために用意したものなので、隅から隅まで丁寧には解説してません。しかもUnixコマンドの解説などを除いた抜粋版ですので、あしからず。