Flickrに載せてある自分の写真ですが、ついに40,000枚を超えました(非公開設定の写真枚数を含む)。30,000枚を超えたのが昨年の7月[blogs.sun.com] なのでわずか半年で1万枚以上アップしたことになります。これもひとえにNikon D90の貢献が大きいと思います。D90は買った当初から連番モードにしてありますが、今日通算8000枚を超えました。また、ラストスパートの1,000枚では停滞しがちだったアップロードを手前味噌ながら自作ツールによって効率化できたことも一因だったと思います。
ツールのコア部分ができあがりました。いま手元の写真をアップロードしてテスト中ですがなかなか順調に動いています。まだUIが一切無いのでハードコードされた設定でしか動作しませんが、簡単にどのようなツールに仕上がっているか紹介しておきます。今回作っているアップローダ(j20000)は、ディレクトリ単位でアップロードの設定(Photosetの設定や、プライバシーの設定)をします。
設定したディレクトリを定期的(今は10秒ごと)に監視して、新しいファイルが見つかればアップロード候補に自動的に追加します。ファイルは変更時刻の新しい順にアップロードされ、随時Photosetの作成やPhotosetへのファイル追加処理が実行されます。まだ安定性の確認中で実装していませんが、アップロード済みのファイルを自動的に削除するオプションをつける予定です。j20000を使うと、ApertureやLightRoomなどで特定のディレクトリに書き出した写真を、書き出された順に随時アップロードすることができます。FlickrExport for Apertureのようなプラグインと違い、Apertureとは独立して動作するのでApertureの書き出し処理が終わったら(ややリソース喰いの)Apertureを終了してアップローダだけに働かせておくことができます。
一番うれしいのは、夜寝る前にApertureの書き出し処理とj20000のディレクトリに対するアップロード処理を開始しておけば、自然とアップロードが完了するところです。いちいち、Apertureの処理が終わるまで待ってから寝なくてもいいのです。例外処理はものすごくおおざっぱにしか実装していないのですが、それでも今まで使った中で一番の安定感を感じます。ソフトはUIができあがった段階あたりで公開したいと思います。
円高だということもあって思い切ってFlickrExport for Apertureを買ったのはいいものの、品質が低すぎて正直返品したい。良くても100枚一度にアップロードできない。ネットワークが途中で切断されたりすると必ずクラッシュする。ひどいときにはたった5枚すらアップロードする前にクラッシュ。しかも、単にpluginがクラッシュするだけではなくてApertureを巻き込んでクラッシュするのでたちが悪い。Nikon D90を買ってから急激に写真の枚数が増えてきたので、安定したアップローダがやっぱりほしい。jUploadrが一番安定しているから1000枚単位の大量アップロードをするときにはまだこれを使っているけど、いくつか不満な点が。
その1。サムネイルを作る時間が長すぎるし、CPUを使いすぎる。jUploadrに写真をDrag & Dropすると写真のサムネイルを作って、その後、Photosetに入れたりするための操作ができるんですが、まずこのサムネイルを作るのにとても時間がかかる。1000枚単位の追加をするとCPUは20分ぐらい100%フル稼働でほかのことができない。そもそも、Apertureで整理した後なので、サムネイルを確認して一枚ずつ設定を変えることもないからサムネイル作成処理は僕にとって不要。ディレクトリ単位でアップロードの設定ができれば十分。個別にいじりたいときでもファイル名だけわかればとりあえずApertureで確認できるし、そのときに個別にサムネイルを作ってほしい。
その2。Photosetsへの写真追加に失敗することがある。今まで試した、FlickrExport for Aperture、1001、jUploadr、Flickr Uploadr 2.x/3.xのいずれでも、あらかじめ設定しておいたとおりに写真がPhotosetsに追加されずに全部の処理が完了されましたと表示されてしまうことがあって、結局あとからもう一度手動でOrganizerを使って整理するのが必須でした。1000枚単位の写真をWeb画面で整理し出すと大変なので、このあたりの処理が確実に実行されるか、再試行について詳しく設定できるようにしてほしい。
その3。未現像のRAW画像について設定ができない。これは仕組み上しょうがないんだけど、Apertureなどのような現像ソフトを使っている場合、RAW画像はAperture上で管理されていて、JPEGに書き出したファイルについてようやくjUploadrがファイルとして認識して、アップロードのタスクとして追加される。RAW現像にかかる時間もなかなか侮れなくて1000枚単位だと20分ぐらいはかかるし、いちいちRAW現像処理が終わったことを目視確認してからjUploadrにかけるなんてやってると、面倒くさい。なので、できればApertureなどであらかじめ指定したディレクトリにRAW現像するようにして、現像が終わったJPEGファイルからディレクトリに対して設定されたメタデータを元に随時アップロードするようにしてほしい。またアップロードができたJPEGファイルが完了後に自動削除されるオプションがあるとよりうれしい。
そんなこんなで前々から作ろうと思っていたFlickrへのバッチアップローダを作り始めました。Flickr APIは認証周りの実装が面倒くさいので敬遠していました。どうせ作るなら安定して使えるJavaで実装したいのだけど、JavaのFlickr APIライブラリは古かったりアップロードAPIが実装されていなかったりするのも今まで着手していなかった理由の一つ。でも今回は、今実家にいてすることがないので、がっつりと時間を使って実装に集中することができ、とりあえず認証まわりとアップロードまでのライブラリが作りあがりました。次は、UIとアップロード順序の管理をするあたりを作ります。アプリケーションの名前はj20000という名前にしました。
デジタルと心霊写真で書きましたが、yuripopさんによれば、どうやら僕の推理のうち2〜4は間違っていたようです。
そういや昨日HEY!×3で心霊写真やっとった。写真専門の除霊師が食っていけてるということがヒントっぽい！
僕がテレビみなくなったからですね。なるほど！ところで、デジタル写真の場合、どういう風に除霊すべきでしょうか？フィルムの写真の場合、フィルムや紙焼きされた写真が物理的に存在しているのでそこに霊的な力が存在していることがイメージできます（僕は霊能者ではないのであくまで想像の範囲で）。一方、デジタルとなればその霊的な力はどこに行くのでしょうか？
フィルムの心霊写真が、心霊写真特集のテレビ番組で放送されていたことを考えると、霊的な力は放送波を通じては伝播しないように考えられます。もちろん、テレビ局が放送前に除霊師に除霊を依頼しているため、もともとその脅威へは対処済みかもしれません。
除霊について詳しいわけではありませんが、心霊写真と霊的な力について仮説を立ててみましょう。
仮説1の場合、デジタル化や媒体の変化によって、除霊作業に困難がつきまとうことが予想されます。たとえば、コンピュータウイルスなどによって心霊写真がインターネット中にばらまかれてしまったらそれぞれについて除霊しなければならないかもしれません。この場合、スパムフィルタは潜在的に強い霊的な力による脅威を受ける可能性があります。スパムフィルタ業者は年に一度ぐらい除霊をしてもらわないといけないかもしれません。
仮説2の場合、媒体がフィルムでも、デジタルでも関係ありません。解像度も日光写真程度のモノでも、2000万画素を超える超高解像度の写真でもトリガにさえなればよいのです。放送やインターネットを通じた流通が発生した場合でも、霊的な力は依然として人や土地などに宿っているので媒体の変化に依存しません。これならデジタル化しても心霊写真が存在していても想像上矛盾がないように感じられます。
仮説2で自分の中では納得しつつも、それなら、別に心霊写真がトリガじゃなくていいんじゃないの？っていう疑問も生まれます。たまたまリトマス試験紙をもって散歩していたら、降ってきた雨が酸性雨だって分かった。というようなイメージでしょうか。
どうでもいいことですが、デジタルカメラが普及してから心霊写真というのをあまり聞かなくなりました。いくつか理由を考えてみましたがどれが正しいでしょうねえ？
ちなみに、僕はデジカメを使い始めてから5万枚以上は写真を撮っていますが、それらしいものはありませんね。フィルムで5万枚もあれば、心霊写真の1つや2つありそうなものです。
写真の管理はほぼすべてオンライン・フォト・ストレージ flickrを使っています。無料アカウント版もありますが、年間25ドル程度でProアカウントをとればアップロード容量、写真容量は無制限になります。仮に、Proアカウントのための支払いを停止したとしても、既存の写真はそのまま保存しておいてもらえるようです。オンラインに置いておけば、ブログにもそのままはれるし、便利なことこの上ありません。実際に、いま自分のflickrアカウント上には31,000枚以上の写真をのせていて、容量はどれぐらいかきちんとはわかりませんが、100GB程度以上はあるんじゃないかと思います。
flickr以外にもフォト蔵など、代替サービスはたくさんありますが、最初にflickrを使い始めて、しかもすでに31,000枚以上も写真を置いてあるとなるとおいそれと別のところに写真を移動させるのもしんどい話です。完全にベンダーロックイン（＝特定の事業者に依存すること）状態ですね(笑)。でも、まじめな話、SaaSが本格的にインターネットサービスの基本になれば、ベンダーロックインとは、今までのような仕様がオープンなのかクローズなのかで議論されてきたところではなく、（オープンな仕様であることが前提の上で）データ量と帯域幅がベンダーロックインを決定する大きな要素となりそうです。
さて、写真共有サイトといえども、まずは写真をアップロードしなければ行けない訳ですが、デジカメ全盛の今では、手元に数百枚、数千枚単位の写真が存在することはさほど珍しいことではなくなりました。実際、最近自分で撮っている写真も毎月2,000枚程度はあります。これを安定的にflickrにアップロードするというのは思った以上に大変で、苦労を強いられてきました。
flickrに写真をアップロードする手段はたくさんあります。FlickrのWebページ上からアップロードする方法、携帯電話などからメールでアップロードする方法、専用ソフトウエアを利用する方法。数枚程度であれば、Webやメール経由のアップロードが便利ですが、数百枚、数千枚単位となればさすがに専用ソフトウエアを使わざるを得ないでしょう。この専用ソフトウエアですが、今までかなりの数のソフトウエアを試してきました。うちではMacを使っていますので、以下ほぼMac用(一部汎用)ソフトウエアです。
まず最初は、iPhoto + Flickr Export for iPhoto。現在最新のv2.x系ではシェアウエアとなっていますが、使っていたv1.xの頃はフリーソフトウエアでした。v1.xはソースが公開されており現在でも利用可能です。これを使っていた当時、iPhotoの安定性は最悪で、Flickr Exportを使うとさらに安定性が下がる感じでした。だいたい、200〜300枚アップロードしたあたりでクラッシュしていました。v2.x系は使ったことがありませんが、iPhoto自身もしばらく使っているとどうやらメモリリークしているような挙動に陥り、1000枚も写真を選んだり編集するとクラッシュすることもあり、一気にやる気をなくして使わなくなりました。
次に使っていたのは1001というソフトウエアです。こちらは、無償で使うことができますが毎回起動時に開発の寄付を募るメッセージが表示されます。これは比較的長いあいだ使っていました。Flickr Exportではアップロードするために選択した写真を一つのSetにしか格納できなかったのですが、1001では複数のSetを作りながらアップロードできるのが魅力的でした。とはいえ、こちらも残念ながら安定性にやや問題があり、ネットワーク回線が切断されていたりするとクラッシュしたり、フリーズするなど、1000枚単位のアップロードを安定的に実行することはできませんでした。
1001は結構長い間使っていましたが、その後、Flickr純正のFlickr Uploadr v3.0.xがリリースされました(これはWindowsプラットホーム向けにもリリースされています)。これは、UIの使いやすさ、複数Setへのアップロードなど魅力的な機能が満載で、一気に1001を捨てて乗り換えました。安定性もそこそこでしたが、しばらく使っていると画像アップロード失敗時の再試行に問題があることに気づきました。Flickr UploadrはFlickrへのアップロードを非同期的に行うようなアーキテクチャのようですが、失敗判定が甘いのか、同じ写真が何度もアップロードされたり、アップロード順序がむちゃくちゃだったりする場合があることに気づきました。また、再試行のあきらめが早く、アップロードが一向に終わらないことも不満でした。Flickr Uploadrはオープンソース化されているので、ソースをみてパラメータを修正したりしてある程度、まともになりましたが、それでも非同期アップロード(同期モードと書かれたパラメータを有効にしてもいまいち変わらない)がおかしいらしく、アップロード順序がくずれたり、アップロードされていない写真があるにもかかわらず、終わった風な顔をしているので、さすがに業を煮やして使わなくなりました。
次に使ったのがjUploadrです。ちなみに、今のところ、誰かにおすすめを聞かれたら間違いなくこれを一押しします。jUploadrはJavaで実装されたアップローダーで、UIが微妙にわかりづらいのですが、安定性はピカイチです。ネットワークの状況が悪い場合でもきちんとアップロードの責任を果たしてくれますし、クラッシュすることもまずありません。実際にこれを使って5000枚はアップロードしたと思いますが、クラッシュした記憶はありません。複数Setに対するアップロードも指定できますし、何より一番うれしいのが、アップロード中にも、新たにアップロード対象の写真を追加して、アップロード候補に加えることができることです。
ちなみに今使っているのは、せっかくここまでjUploadrを絶賛しているにもかかわらず、Aperture + Flickr Upload pluginです。Aperture + Flickr Upload pluginの安定度はそこそこですが、ネットワークの状態が悪くなるとクラッシュすることもあるようです。また、今まで使ったツールの中でFlickrへのサインインが最もトロトロしていて、20〜30秒は待たされます。それに、複数Setへのアップロードもできません。ここまでデメリットをあげているにもかかわらずあえてこれを使っているのは、写真管理のワークフローの中心にApertureがあるためです。iPhotoはクラッシュしすぎで使い物にならず、Adobe Bridge CS3は写真管理のためのツールとしては力不足で使い物にならず、ようやくApertureで満足のいく管理ができるようになりました。写真のカメラから取り込み、編集、アップロードという一連のワークフローを考えた場合、今のところAperture + Flickr Upload pluginが現実的だと思っています。
クマノミは動きが速いのでぶれしやすいのですが、今回はばっちり撮れました。たぶん、今まで撮った中でも１、２を争うできだと思います。失敗例として多いのが、白色の縞模様が白トビしまくるのと、あとは被写体ぶれするパターンだと思います。
素早い魚を撮るので、フレーミングはほとんど運の世界のような気がしますが、被写体ぶれはシャッタースピードを速くすればある程度改善できるし、白トビも何回か撮って調整する等いろいろ方法があるかと思います。でも、わかっていてもなかなかうまく行かないのが水中写真の奥深いところです。今回はたまたま露出、フレーミングとも満足な結果が得られました。
(こちらは失敗例、暗いしピントが合ってません)
使用機材はNikon D50, Sigma Macro 105mm F2.8, Sea&Sea YS-110です。TTLコンバーターを持っていないので、ストロボの強さとカメラ側の露出はカンで補っています。焦点距離が105mmとやや望遠のレンズを使っているので、撮影時にはシャッタースピード優先オートか、マニュアルモードで撮影し、シャッタースピードを1/200秒以下程度にしています。D50はマニュアルモードの場合、絞りの設定変更が露出ボタン＋ダイヤルなのですが、ハウジングに入れた状態だとこれらのボタンを操作するには両手を使う必要があり、絞りを意図的に変えるのはやや面倒です。このため、撮影前にはマニュアルモードの絞り設定をf/9程度にしています。シャッタースピード優先オートの場合、基本的に水中は暗いのでカメラ側の判断としては絞りをあけようとするので、f/2.8付近になります。
このサンゴガニの例はシャッタースピード優先 1/200秒で絞りはf/2.8になっています。つまり、ボケを重視したい構図ではシャッタースピード優先モードにし、被写界深度を深くしたい構図ではマニュアルに切り替えるというモードのダイアル操作と、それに伴いストロボの強さをかえる操作のみで済みます。ストロボの強さも3〜4段の範囲でしかいじりません。これならばだいたい片手で操作できますし、急にいい被写体が見つかったときにもそんなに焦らず撮影することができます。
ところで、被写体によってはもっと被写界深度を深く撮りたい場合があります。ほんの2〜3ミリのウミウシなど、ピントを厳密に合わせるのがしんどいような被写体です。時間的に余裕があれば、本来はしっかりフレーミングして撮りたいところですが、うかうかしていると、置いていかれてしまうのでそんなにじっくり撮ることもできません。たとえば、きちんとフレーミングできないが、被写界深度内にはおさめられるようf/11とかf/16あたりで撮りたいときには、もちろんマニュアルモードを使いますが、露出ボタン＋ダイアル操作はしんどいので、最近では絞り優先オートの設定を変えることでマニュアルモードの絞りを変えています。D50の仕様なのかどうかはわかりませんが、マニュアルモードのシャッタースピードはシャッタースピード優先オートの設定が引き継がれ、絞りはしぼり優先オートの設定が引き継がれるようです。陸上で使うときにはどちらかというとややこしい仕様のような気がしますが、露出ボタン＋ダイアル操作の敷居が高い水中ではとたんに便利な仕様に早変わりです。
