日々適当

Lion以降、Javaがインストールされなくなり、そして、そのインストーラの配布は、Javaの配布元であるオラクルから直接なされるようになりました（例えばターミナルから java -version と打ち込んでJavaを呼び出しても存在しない時、この時はAppleからインストーラが提供されるみたいですね。この場合、Java SE 6が入るようです。）。ってことで、Javaの緊急の脆弱性が発表されたら、オラクルからダウンロードしましょう。ただし、Java SE 7になります。

Verify Java Version [java.com]

ここで、インストールされているJavaのバージョンを調べられ、もし最新でなかったらインストーラへのリンクが示されます。



そして、8/31に

Oracle、Javaの深刻な脆弱性を公表―攻撃者はリモートであらゆる操作が可能〔今朝パッチ緊急リリース〕

というリリースがオラクルからなされています。Javaを利用している人も利用している意識のない人もチェックをした方が良さそうです。
問題は Snow Leopard 以前の環境で使用している人および、Java SE 6が必要な人ですよね。10.7未満のバージョン向けに、オラクルは提供していないようなので、Appleからサポートされるのを待つしかありません。
それがリリースされるかも不明ですが、とりあえずJavaのプラグインはオフにしておいた方が良さそうです。

<追記>
9/6にAppleから対応バージョンがリリースされています。該当する方はソフトウェアアップデートをかけておきましょう。
</追記>

そもそもJPEGってのは Wikipedia によると、色成分をRGB, YCbCr, YMCKのどれも用いることが出来るのだそうです。RGBだけじゃないのですね。しかも、デジタルカメラで用いられている規格EXIFにおいては一番標準的なフォーマットであるJFIFを拡張したフォーマットをらしいのですけど、JFIFってのはYCbCrを用いることが規定されているのだそうです。4:4:4とか4:2:2とかは自由に選択可能だそうらけど、いわゆるYUVが標準なようです、JPEGって。

さて、ここで疑問が起こります。
JPEGの色空間ってsRGBとかAdobe RGBとか。つまりRGBなんじゃないの？って。
これ、たぶんごっちゃにしちゃっている。
色を座標で指示できる色空間の範囲の大きさの規定としてのsRGBとかAdobeRGBってのと、色を実際にデータとして記録するためにRGBの情報をYCbCrに変換の上記録するというのは矛盾しないでしょう。

故に、iMediaHUDってソフトにJPEGファイルをドラッグアンドドロップすると、おそらくファイルに保存されている色がどんなフォーマットであるかを示しているために、カラースペースにYUVって表示されるのだけど、プレビュー.appで開くと、そのファイルの画像に定義されている色空間がsRGBであるという意味で色空間情報って部分にsRGBと表示されるんじゃないかと愚考いたします。



ちなみに、デジカメでRAWで撮影したものを現像してJPEGに保存する時、RAWファイルの画質をいい感じで出力するために、YCbCrの4:4:4で保存する物もあるようです。EXIF規格においては4:2:2なのだそうで、そんな意味でもRAWからJPEGにした方が画質面で有利ってのがあるのかもしれませんね。

シグマが追求する画質観 [SIGMA DP2 : スペシャルコンテンツ]

Mac版Photoshopは、ファイル保存時、その作業に時間がかかる場合にはプログレスバーが出ます。CS6になり、保存時にも他の作業が出来るようになっているものの、プログレスバーは健在です。で、そのプログレスバーには処理をキャンセルするためのボタンがあります。



ボタンがあれば押してみたくなります。保存中に処理をキャンセルしてみましょう。

すると、

そのファイルがsmbやnfsのネットワーク越しに保存されていたものの場合、ファイルが消えてしまいます。

ファイル保存中に、Finderでそのファイルのある階層をリスト表示にして、そのファイルのファイルサイズが見える状態で確認してみると、いったんファイルのサイズがガッと減り、保存が進むにつれてファイルサイズが徐々に増えていく様子が見えるはずです。つまり、どうもオリジナルのファイルを直接上書きしていっているようなのです。

一方ファイルがローカルに存在する場合、ファイル保存中は一旦一時的なファイルを作成し、そこにすべてのデータが保存された時点で、オリジナルと一時ファイルを入れ替える、という事をしているようです。ですから、保存中に処理をキャンセルした場合、保存途中のファイルは削除されるものの、それは一時的に作られたファイルなので、オリジナルはちゃんと残っているという事になるのだと思います。

しかし、前述したように、smbやnfs越しのファイルではオリジナルを直接上書きしていくようです。ですから、処理をキャンセルして、処理していたファイルを削除するという事は、オリジナルを削除する事に等しく、結果、ファイルが消えちゃうということのようです。まぁ、オリジナルを上書きしている時点で、キャンセルしても壊れたファイルしか残らないってことですから、動作としては問題ないといえばそうなんだけど(^^;

ちなみに、Windows版ではこのようなことは起こりません。ネットワーク越しのWindowsサーバー（もしくはsmbサーバー）上のファイルを上書き保存するとき、不可視ファイルを表示する設定にしているなら、一旦一時ファイルが作られている様子が確認できるはずです。つまり、ローカルに保存するのとかわらない処理をしているわけですね。
別にWindows版が優秀という話ではなく、何でMac版のsmbやnfs越しのファイルに対する挙動を、Adobeはそのようにしているのだろう、と単純に疑問に思ったのです（念のため、Macのネイティブのネットワークではafpを使いますが、この場合、ローカルファイルを保存するのと同様の挙動を示します。保存中にキャンセルしてもファイルは消えません）。

この辺の事情、どっかで説明されてませんかねぇ。

modo 601 sp3 にてAppleScriptをサポートしたことが書かれていました。
スクリプトのドキュメントには、上図のように run command しか書かれていませんが、modoに対して、modoのコマンドを投げることが出来るわけで、うーん、どんな使い方が考えられるでしょうか。

例えば

tell application "modo"
--activate
run command "script.run \"macro.scriptservice:19601440010:macro\""
run command "scene.saveAs /saveDirectory/a.lxo $LXOB false"
quit
end tell

と書いておけば、modoを起動していなくても、modoが起動し球を作成しsaveDirectoryにa.lxoというファイル名で保存した上で終了する、という事が出来るわけで、適当なバッチ処理に使えそうです。
たぶん真価を発揮するのは、他のアプリケーションと連携させるような場合でしょうね。具体的にどんな場合かは有用なのがぱっとは思いつきませんが(^^;

ま、その前にスクリプトをおぼえないとというのはありますな。

iCalに、この時間はこの仕事をしていました、って記録を付けています。



この図の「新規イベント」となっている部分に仕事名を入れて、カレンダー（「ホーム」になっているところ）を仕事記録専用のカレンダーにして、開始・終了時刻を入れる（終日にはしない）。こんなルールで記録しておけば、まぁ、大ざっぱにでもそのお仕事に何時間費やしたか分かるというものです。
ところが、いざ何時間掛かったという数字を出そうとする時、数日程度の仕事なら自分で数えてもいいんですけど、長めのスパンのだとやってられません。

ってか、今、久しぶりにそんな長めのスパンの仕事しててですね、で、面倒だな、と。

というわけで、AppleScript書きました。その仕事の合計時間が分かればいいので、もう非常に大ざっぱなスクリプトです。

set dStartS to "2012/7/19 0:00:00" --集計の開始時間
set dEndS to "2012/8/25 0:00:00" --集計の終了時間
set calName to "仕事" --カレンダー名
set summaryName to "仕事名" --仕事名

set dStart to date dStartS
set dEnd to date dEndS

tell application "Calendar"
set evnList to every event of calendar calName whose (start date ≥ dStart) and (end date ≤ dEnd)
set workTime to 0
repeat with evn in evnList
if (summary of evn) = summaryName then
set eDuration to (end date of evn) - (start date of evn)
set workTime to workTime + eDuration
end if
end repeat
end tell

display dialog calName & "/" & summaryName & ":" & ((workTime / 60 / 60) as string) & "時間"

こんな感じ。単純に該当する期間内のイベントを総ざらいして、イベント名が該当している物の開始時間と終了時間から作業時間を割り出して、どんどん足していく、という内容です。雑。

ともあれ、これで目視で数えるよりかはなんぼか信頼できる値が取得できるというものです。

余談ながら、このスクリプトを書きだす時、

tell application "iCal"
end tell

って書いたんですよね。で、スクリプトエディタのコンパイルボタンを押したら、iCal って部分が Calendar に自動的に書き換えられちゃいました。そいえば、iCal って名前はきえちゃったのね、Mountain Lion から。

来ているけど、アップデートはまた今度。



About the OS X Mountain Lion v10.8.1 Update

10.8.0 で個人的に困っていたバグらしき動作って何かあったかなぁ…?

<追記>


ずいぶんとサイズが小さいのね@MacBook Pro Early 2011
</追記>

少しおぼえたのでメモ。



上図、「位置」に設定してあるエクスプレッションは、他のレイヤーの位置に一致させるという内容です。
他のレイヤーの位置を参照するとき、position ではなく、anchorPoint を取得するのがみそみたいですね。AEのレイヤーは、アンカーポイントを起点としてトランスフォームを行うってことを全く意識しておりませんでした。
toWorld() は、グローバルな座標系の値に変換しているもので、参照しているレイヤーが、別のレイヤーの子供になっているときなんかに必要になってきます。

「スケール」に設定してあるエクスプレッションは、カメラからの距離に関係なく、大きさが一定になるという内容です。
下図において、Wはコンポジションの幅。pはそのコンポジション上で目標をどんな大きさにするかという値。θは水平画角で、zはカメラからコンポジション平面までの距離。これはAE上ではズーム値として表現されます。そしてdはカメラから処理を行うレイヤーまでの距離となります。

で、上図のエクスプレションにおいて、

変数 targetSize で指定した大きさになるようにスケールを調整します。下図におけるpです。
変数 angle は、カメラの水平画角をラジアンで出しています。下図におけるθを求めてます。
変数 distance はカメラからこのレイヤーまでの距離。下図におけるdです。

その上で、下図におけるsの値を求めて、これをスケール値に入れちゃっている、ってことをやってます。

計算結果をスケール値にしちゃってますけど、ここは厳密には違うんだろうなぁと思いつつ、大きさを一定にはクリアしているはずです。



この、大きさを一定にってのは、今やっている仕事にてSIのICE Treeの方で重宝した考え方でございます。
その場合、Wはレンダリング時の画像の幅になり、pについては、画像内で何ピクセルの大きさで表現するかの指定となります。

<追記>
今回のように、位置を一致させて大きさも固定にするという場合、固定される方を2Dレイヤーのまま扱えれば良さそうだよなぁと思っていたら、そんなエクスプレッションもありました。
上図のテキストレイヤー text_meso は3Dレイヤーですが、これを2Dレイヤーにして、位置に対して以下のエクスプレッションを書いてやれば良いようです。

thisComp.layer("Meso").toComp([0,0,0])

これでこのレイヤーにレイヤー Meso が投影され、このレイヤー上の2Dの位置が帰ってくるみたいです。
もしオフセットをつけたいなら

pos = thisComp.layer("Meso").toComp([0,0,0]);
[pos[0] + 10, pos[1] + 10];

とでもしてやれば良いでしょう（10ピクセルずつ動かすという意味になってます）。
</追記>

Fury [Exocortex]

いつの間にやら Exocortex サイトにFuryのページが出来てた。8月いっぱいまでページに記載されているディスカウントコードを入力することで $100 オフですよ。ページにはタイタニックとかアベンジャーズで使われているぜって書かれておりまする。Mayaプラットホームでも動作するようになった恩恵でしょうか。
個人的にParticle replicationが目玉の一つだと思うんですけど、重いです。現実的なパラメータの範囲がどの程度なのか見極めないとです。
実用上の最大の目玉は各種パスを出力できるようになっていることすかね。



ってことで、for Mac も出てくれないかなぁ。そしたら職場で提案しやすいんだけどなぁ（で、for mayaのライセンスはfor Softimageも動作するフローティングなので、SI使いにも恩恵あるんですよ）。

<追記>
何となく参考までにレンダリングしてみたけど、パラメータをまったく詰めていないので何の参考にもならないかもという。ただ、emRPCはAOやGIをサポートしているのに対し、Furyはそこまでは無いので、場合によってはemRPCの方が有利かもと思いつつ、Furyが出すパスの情報によってはコンポジット時の表現の幅が広がるはずなので、実用上ではどちらがいいか迷うところ。
レンダリングのしやすさという意味では、Render Manager からレンダリング管理できる Fury の圧勝だとは思う。


</追記>

Windows のエクスプローラでアドレス欄に cmd って打ち込むと、エクスプローラで開いているディレクトリをカレントディレクトリしてコマンドプロンプトが開く、というTipsを twitter のTL で知りました。
ならばMacでも、と思ったんですけど、Macにはアドレス欄が無いんですよね。 テキスト入力で指定したフォルダに移動するってのは 移動→フォルダへ移動…コマンドから行けるんですけど、そこからターミナルが起動できるわけじゃない。

ってことで

Go2Shell [Mac App Store]

こちらのツールを入れるとよいのだそうです。幸い、Mac App Store で無料で配布されている。
アプリケーションフォルダにDLされたそれを、Finderウインドウのツールバーに登録してやれば、後はそれをクリックすれば、それを実行したFinderウインドウをカレントディレクトリとしてターミナルが開かれます。



ちょっと便利かもです。

EX-F1の充電器が行方不明だったのですよ。なもので、このカメラを今でも持っている唯一の理由、ハイスピード撮影ができずにおりました。それが今日発掘されたんで、夕方、ちょっと空を撮影してみたのですよ。
今どきのカメラと違って暗部に強くないため、日が沈みかけている時刻で地上部分の撮影はあんまりよろしくありません。いいモチーフもありませんしね。

ってことで、取り込んで iPhoto で補正一発かましてみたんですけどね。やっぱり、絵が粗いですぁ。


Camera Casio EX-F1
Exposure 0.004 sec (1/250)
Aperture f/8.3
Focal Length 87.6 mm
ISO Speed 100
Exposure Bias 0 EV

このズーム能力はなかなかの物だと思います（35mm換算で450mmオーバー）。


Camera Casio EX-F1
Exposure 0.004 sec (1/250)
Aperture f/7.4
Focal Length 87.6 mm
ISO Speed 100
Exposure Bias -1 EV


Camera Casio EX-F1
Exposure 0.002 sec (1/500)
Aperture f/7.8
Focal Length 9.4 mm
ISO Speed 100
Exposure Bias -1 EV

しかし、ISO 100 なのにずいぶんとノイジーっすなぁ。
つーわけで、やはりこのカメラの真価はハイスピードにあります。
ってか、普通のカメラとして使う時、画質もそうだけど、操作のレスポンスが悪すぎて使いづらいんですよねー。

後継機、でないかなぁ…


Camera Casio EX-F1
Exposure 0.002 sec (1/500)
Aperture f/5.6
Focal Length 11.5 mm
ISO Speed 100
Exposure Bias -1 EV