2009/04/25

TAMRON 18-270 VC MACRO試用記

TAMRON キタ━(゚∀゚)━!!!!!

先週末某大型量販店で、
  • TAMRON AF18-270mm F/3.5-6.3 Di II VC LD Aspherical IF MACRO Model B003
  • SIGMA 18-250mm F3.5-6.3 DC OS HSM
  • NIKON AF-S DX VR Zoom-Nikkor ED 18-200mm F3.5-5.6G(IF)
の実機を触ってTAMRONに決めました。
購入は価格.com経由です。(量販店産ごめんなさい)

決め手はなんと言っても手ブレ補正の精度(強度、凶度?)。
手ブレ補正を含めメリット、デメリットについて少々自分なりに分析をしました。

■手ブレ補正精度(SIGMA 18-250、NIKON 18-200比較:TAMRON圧倒的優勢)
手ブレ補正が効き始める瞬間に、派手にファインダー像が揺れます。
それだけ強力に補正をかけるのか、その後はファインダー像が不自然に感じるほど強力に止まります。
ファインダーに画像が粘着している感覚です。
270mmテレ端で1/10秒とかもかなりの確立でいけます。

シャッタースピード1/30秒のテレ端で3者を比較すると、10M pixelクラスの本体でピクセル単位に手ブレが押さえられる確立は圧倒的勝利。
TAMRONが十中八九といった感触なのに対して、NIKON、SIGMAは一、二割といった感触です。
テレ端が高倍率なTAMRONが不利な条件にもかかわらず、です。

3者とも公証4段分の補正ですが、感覚的には1段分以上の差が有るようです。

これを期に手ブレ精度競争が始まることは間違いありませんが、純正は更にお高くなる可能性も大なので、この買い物は正解だったと思っています。

■フォーカス成功率(NIKON 18-8570比較:TAMRON劣勢)
買う前に調べたWeb上の噂では、TAMRON 18-270のフォーカスは最悪と言うものでした。
とはいえ、測距離センサー、フォーカス制御のアルゴリズムは本体側なので共通なので、噂を割り引いていました。

結果は、予想以上に悪いものでした。

比較対照がNIKON純正の18-8570の超音波モーターなので、高倍率TAMRONのテレ端は不利なことを割り引いて考えると、辛うじて合格点と言ったところでしょうか。
それでも、次項目のフォーカススピードもあいまってか、8570mmで比較してもTAMRONがはっきりと劣勢です。

■フォーカススピード(NIKON 18-8570比較:TAMRON劣勢)
比較対照が悪すぎます。
フォーカスリングが一往復する時間はNIKON 18-8570の2倍から3倍あります。
それでも、本体内蔵モーター頼りであった18-200の時代に比べれば操作音、スピードともにかなり改善されていて、合格点を与えても良いかと思います。

■画質(??比較:同等??)
分からないし、関心なし。
もちろん程度問題ですが、私のレベルでは誤差の範囲。
等倍以上に拡大するとわかるレベルかも知れませんが、それは写真鑑賞というよりPCのベンチマークに近い自己満足というのが持論。
写真はアングルと露出とぼかしでしょ! (って頭で理解しているだけ)

参考になれば幸いです。

2009/04/19

アクセスカウンタが破壊:OpenSocialじゃ作れないの?

アクセスカウンタとして無料のアクセスカウンター![動くアクセスカウンター]を利用していましたが、なぜかリセットされてしまいました。
カウンタの再生成をすれば事足りるのですが、またリセットされるのも何なので忍者カウンターにしました。
ついでに、Analytics導入時からのセッション数でカウンタをセットしたのでアクセス数がジャンプアップしています、あしからず。


ここからが本題。
OpenSocialの習作としてアクセスカウンタでも作ってみようとも思ったのですが、OpenSocial APIだけでは無理そうなのでちとハードルが高い。

OpenSocialには永続化の手段としてnewUpdatePersonAppDataRequest()がありますが、どうもこれはViewer別かつアプリ別かつOwner別の記憶領域のようです。
そして、更新権があるのはViewerのみ(コンテナによって違うらしいが、仕様上は)。

これでは、アクセスカウンタのようなViewer跨りのデータを管理するものや、GFCのコメント欄、5スター評価のようにアプリ跨りのデータを管理するものには利用できません。

このサイトでも導入しているEiji KitamuraさんのFriendConnect向けあしあとガジェットでは、VIEWERごとに自分のAppData領域にデータを保存する、という技。OWNERの友達のAppDataをまとめて取得という「テクニック」で何とか「みんなのあしあと」という「共有」データを演出しているようです。

しかし、この方法にも限界があり、メンバが増えるとサーバおよびクライアントの負荷が耐えられないような気がします。
また、単なるViewer毎のデータの集約ではない、本当の意味で更新可能な共有データを扱うことができません。

現状、Viewer間やアプリ間で共有・更新するデータを持つアプリを作成しようとすると、外部サーバを立ててgadgets.io.makeRequest() でやり取りを行うのが一般的かつ唯一の方法のようです。

Google Bloggerユーザのように自前サーバを持たない人もGoogle App Engine等を使えば良いようですが、こういった外部サーバを用意するのも一手間ですし、FriendConnectは残念ながらmakeRequest未対応 だったりします(2008.4.20追記:今は出来るそうです。出来るという記述を見つけていませんし、実験も出来ていません、念のため)ので、やはりOpenSocial APIだけで実現できることが望まれます。

newUpdatePersonAppDataRequest()の関数名の意味や、"Person"を特定するものと思われる第一引数に指定できるのが現在VIEWER IDのみという不自然な状況からして、OpenSocalも元々はより柔軟なデータ永続化を目論んでいるように思います。

who can read/write the data を仕様として決定すべきとの意見も出ているようですので、将来的にはより柔軟(でセキュア)なアクセスが可能になるかもしれません。