IntegerQ GeoLog

過渡期の産物「.5」

Sat, 06 Feb 2010 18:08:41 +0900

新しいモノへと移行する過渡期には、「悩ましい」産物が出現したりします。私の作っているツール群などはまさにソレで、移行期の矛盾を多分に含んだ内容となっています。

コンポジット周りのツールの集合体である「xtools」やデータベース規約の「atDB」は、現在キメラ状態の真っ只中であり、バージョン番号さえフワフワしております。新しいモノが従来のモノに対して上位互換であれば、まだ収拾する事も可能ではあるのですが、互換をもたない新方式ですと、移行期のツジツマ合わせは大変です。例えば、MacOS9とXの時の騒動が、良い（悪い？）例です。UNIXにMacOSの「フリ」をさせるのは、さぞ大変だったと思います。

そんなこんな、どうしようかと悩む日々が続いていましたが、ふと「混沌を肯定」してしまえば良いのだと気付き、頭がクリアになりました。新旧双方を同時に満たす事ばかりを考えていましたが、もともとポリシー自体が大きく異なるモノを１つにまとめようとしていた事に無理が有った訳で、いっその事、「移行期はどっち付かずの状態」である事を基本構造として受け入れてしまえば良い‥‥と思った訳です。

例えば私の作っているxtoolsでは、

バージョン1.0　撮影台互換方式（現在開発終了）
バージョン2.0　撮影台互換方式に200x年代の新技術をプラス（現在メンテ状態）
バージョン2.5　撮影台互換方式と新方式をそこそこ共存
バージョン3.0　新方式（旧方式はサポートせず）

‥‥のように規定する事で、スッキリとまとめる事ができるかなと思った次第です。「0.5」バージョンの「どっちつかず」をあえて明確に設定する事で、移行期に対応しよう‥‥と言う訳ですネ。

ぶっちゃけ、新方式と旧方式を共存させるのは「無理な話」であり、後手にまわる対処も多いのですが、それはもう「仕方ない事」と割り切ってしまえば悩まずに済みます。「移行期間だけ耐えれば良い」と方針をハッキリさせる事で、どのように備えて対処すれば良いかを思考できます。

0.5‥‥。なるほど、たしかに半分、半分‥‥です。

QuickTimeの上限

Sat, 06 Feb 2010 13:42:57 +0900

After Effectsをいじっている最中、QuickTimeのドット数に上限がある事が解りました。‥‥まあ、無制限と言う事は無いだろうけど、どの辺りが上限かは調べてみた事が無かったので、実地で調べてみる事にしたのです。もしかしたら、どこかに文献があるのかも知れませんが、見つけられなかったので、手っ取り早く予測・実測で検証してみました。

結果はどうやら「2^24」、つまり2の24乗（＝24bit）、1677万ドットが上限のようです。横や縦の寸法制限ではなく、画面全体の画素数・ドット数による制限です。まあ、大体この手の制限値って、2の倍数（しかも8,16,24,32などの「キリの良い数値」）だよネ。

例えば、4500x3720=16740000ドットのQuickTimeを書き出すとAfter Effectsでも読み込み可能ですが、4500x3730=16785000ドットのQuickTimeは読み込みできません。画像の通り。

たった10pxの違いなのに、明暗が分かれる訳です。

スクリプトで判別する場合は、（compにCompItemを代入して）

(comp.width*comp.height)>Math.pow(2,24)

‥‥で検査して処理を振り分ければ対処できます。どのような対処をするかは、その時の状況で。

今はまだSD解像度がその字の通り「Standard Definition」、つまり標準と呼ばれているので表面化しない部分も多いですが、HDが「Standard」になった近い未来の状況では、色んな部分で問題が浮上するはずです。

まあ、次期After Effectsは（Mac版も）メモリを沢山使える仕様になるでしょうから、相殺される状況にはなるでしょうが、今までのような「16bitにしておけばバンディングがでない」みたいな大味な対処のままでは、そこかしこで「ヤギが鳴く」事になるでしょうネ。10年前のマシン性能が低かった頃の「工夫」を思い出して、近い未来こそ「手元にある機材を如何にして使いこなすか」を実践すべき‥‥なのでしょう。

After EffectsとESTKとWebサーバと

Mon, 25 Jan 2010 15:30:49 +0900

私の作業環境は、公私どちらとも「サーバによるサポートで快適な環境を作る」事をポリシーとしております。「人間が直に関与してのみ、造り出す事のできる」ものに、最大限の時間を使いたいので、その逆に相当する事はできるだけ人間の手間を省きたい訳です。

そんな事なので、随分前から「単純作業の自動化」を押し進めており、「誰がやっても同じ結果」になる作業は、サーバで自動処理するように環境を整えてきました。

After Effectsを用いた「映像処理サーバ」もそうした取り組みの中の１つです。

「映像処理サーバ」と言っても、単にAfter Effectsが自動で動くコンピュータです。特注のAfter Effectsである訳も無く、ごく普通に、MacにAfter Effectsをインストールしただけの状態です。マシンはMac miniだったりMac Bookだったりしますが、サーバはその名の通り「Server」なので、特に高価で大仰なマシンを導入しなくても、「サービス」の内容に合わせてマシンの規模を考えれば良い訳です。

After Effectsを自動で動かすには、ESTK（アドビ独自拡張のJavaScript）にてスクリプトを書きます。サーバと言うからには、ユーザのリクエストに呼応する「サーバ的な」動作を望む訳ですが、scheduleTask()あたりを使えば手軽に自動巡回するプログラムが作れるので、自動応答する挙動は実現できます。自動で命令書を検索して、新たな命令書を見つけた場合は処理を開始する‥‥みたいに作れば、特に難しい事はありません。もちろんその命令書（テキストファイル）は、自由に定義すれば良いです。
＊After Effectsのポートを使う方法もアリかも知れませんが、プログラムはちょっと複雑になりますネ。それに、After Effects自体がマルチタスクで動作する訳では無いので、自動巡回くらいのレベルが負担的にもちょうど良いように思えます。

ちなみにAfter Effectsをサーバとして捉えた時、これほど高機能なアプリケーションはありません。After Effectsがサーバアプリ？‥‥いやいや、あれだけ豊富なスクリプト機能があれば、充分なサービスをユーザに提供できますヨ。

ではAfter Effectsの処理命令書をどのように作成するか‥‥ですが、運用面で一番手軽なのはPHPのようなWebベースのプログラムです。フォームで必要事項を構成して送信し、送信内容に基付いたテキストファイル（＝命令書）を作る‥‥という仕組みです。命令書の内容チェックとか優先順位とか訂正・破棄などを組み込み始めるとちょっとメンドくなりますけど、関係スタッフ以外は使わないサーバなので、エラー対策もほどほどで済みます。

実際にどんな事ができるかと言うと、「TIFFやDPX連番から編集用オフライン素材を作る」「音響用のタイムコード入りレタボ映像ファイルを作る」「ガンマやLUTを修正したムービーを作る」「白箱DVD用に最適化したムービーを作る」etc,etc...、「単純作業ではあるが、アプリケーションのメニュー項目としては存在しない」類いの作業が、自動かつ連続、休日無用で処理できます。

実は去年からFinal Cutによる本番編集作業も経験して、より明確に「どの部分が手作業必須で、どの部分を自動化できるか」を認識できるようになりました。いわゆる「撮影と編集」間のやり取りをインハウスでおこなったところ、無駄な段取り・形骸化した仕様が浮き彫りとなり、「標準化」を再定義できたのです。結果、「単純化」（＝サーバ処理）と「専門化」（＝人間の手作業）を実践できた‥‥と言う訳です。

まあ、「作業は作業以外の何ものでもない、内容も効率も二の次だ、とにかくこなせ」と言う向きにはサーバはおろか、「単純化」も「専門化」も不必要なのかも知れません。なぜ品質が向上しないのか、なぜこんなにも作業が苦しいのか‥‥を少しでも考えるのであれば、まずは作業内容の分析をおこない、然るべき作業体制の構築を（ちょっとずつでも）進めるべきでしょうネ。‥‥なんか知った風にエラそうに書いてますが、実は私もブチ当たった（今でもブチ当たり続けている？）壁でしたから‥‥。

今年は今まで以上にアニメが減るとか。今までのやり方では通用しない状況が、すぐ足もとまで迫ってきている‥‥のかも知れませんネ。

テレビ、壊れる、直る

Wed, 20 Jan 2010 16:00:55 +0900

自宅で使用しているSONY製のブラウン管テレビが数日前に壊れました。

液晶にリプレースするのはもう少し先の予定なので直そうかなとも思いましたが、一方で、現時点でアナログ波＆SDのテレビを直すのに何万円もかけるのは無駄金になると思い、無料引き取りに送る事に「一旦は」決めました。

クロネコヤマトのWeb集荷サービスを入力し、「確定」ボタンをクリックするその間際になって、「故障について、ろくに調べてもいなかった」事を自覚し、クリックを思いとどまりました。で、即座に「ソニー　DX550 故障」の語句で調べてみたところ‥‥、なんとまあ、全国各地のオーナーさんが「同じ症例」を経験している事が解りました。

検索結果を読み進めているうちに、どうも「無償修理の対象」となっている事が判明し、無料引き取りに送るのはやめて、まずはサービスセンターに修理を依頼する事にしました。

表向きは「修理料2万円くらい」のようでしたが、「チップの不良で発生する症状に酷似している」事を伝え、さらには「もし高額修理になるようなら修理はしない」事も伝えたところ、「直す直さないに関わらず、サービス出張料は発生するかも知れません（＝ユーザに負担してもらう）」との返答が得られました。‥‥まあ、３千円の出張料＋無償修理代金で直るなら良いか‥‥と思い、実際に修理をしてもらう段取りにしました。

で、訪問修理をしてもらったところ、やはり皆と同じパーツ（MCZ3001）の不具合が原因だと言う事が明らかとなりました。サービスマンの方も手慣れたもので、サックリとチップの交換を済ませて（ハンダごてでチュチュっと直していたのは懐かしかった‥‥）修理は終了し、出張料も無しとなりました。つまり、全額無償修理です。

修理の終わり際、サービスマンさんの名刺だけ渡され、修理に関する明細・伝票を渡されなかったのは、‥‥伝票が出ない（出せない？）何かビミョーなジジョーでもあるのかな‥‥と深読みしてみたり。‥‥まあ、いいか、ソレは。

もしネットで調べていなかったら、まだ使えるテレビを、無料引き取りに送ってしまっていた事でしょう。SD解像度とは言え、絵自体は奇麗で、HDや地デジの事さえ考慮しなければ十分現役で通用するテレビです。

ぶっちゃけ、数ヶ月後にはリプレースする予定のテレビではあるのですが、今すぐ無くなるのは非常に困る訳です。予定通りの任期を全うさせたいと考えております。

遅ればせながら、ギガビット

Sat, 12 Dec 2009 22:49:32 +0900

今日ようやく自宅のネットワークを100Baseから1000Baseへと転換しました。ケーブルをカテゴリ6に敷設し直すのが面倒で、長らく放置していたのですが、もろもろ不便になってきたので、重い腰を上げた訳です。

何故腰が重くなっていたか‥‥と言うと、ネットワークの積年の小変更により、取り回しがグダグダになっていて、クリアするのがとても面倒だったからです。家具の下に潜ってみると、PhoneTalkの配線まで残存していたり‥‥と、経た年月をしみじみ振り返る事もしばしばでしたが、何とか家中のケーブルを張り直し、めでたくギガビットへとアップグレードしました。

で、ギガビットになってどれだけ快適になったか‥‥というと、日頃仕事でギガビットの速度に馴れきっているので、喜びはさほど大きくはありません。ぎゃふん。ここ数年我慢し続けた自宅の「遅さ」が解消された‥‥と言う程度です。

でもまあ、ちょっとしたファイルでもギガバイト単位でデータをやり取りする昨今、100Baseは低速の部類に属する様になってきたようにも思えますから、そろそろ「張り替えの潮時」だったのかも知れません。いっその事、数年先を見越して、カテゴリ6eにでもしてしまおうかとも思いましたが、とりあえずは1000Base/T合わせで更新してみた次第です。

自宅の環境もギガビットへと移行し、いよいよ来年2010年は「新しいフェイズ」へと移行しようと考えています。‥‥足踏みするのは、もうそろそろタイムリミット‥‥のような気がしています。