http://nekora.main.jp/film/tmp/C082.mov*1
→2006/9に出来るようになった。
http://nekora.main.jp/film/tmp/C082.mov
かくして、私の活躍により、↑の様に背景にだけぐにゃぐにゃフィルター＆セピア色フィルターを掛けつつ、前面は微妙にズーム＆下降するだけ、というこれまでの私の装備では出来なかった*2新たな表現が可能になったのであった。
だがしかし！同時に入力補助機能*3を付けないと大変面倒であることが同時に判ったのであった。昔、色見本ファイル*4目当てに買った RETAS!PRO Infinityテクニックバイブル を見て良さそうな機能を真似るか。
それにしてもMedia Studio Proは案外今ひとつ録なフィルターが無いというか、フィルターの設定の自由度が低いなー。ぐにゃぐにゃの「つまむ」フィルターも焦点は固定だしなー。フィルターの類は余り使わなかったからこの辺に気づかなかった。意外と貧弱。Expression3みたいなメッシュワープがあると良いのに。あとグレイスケールファイル参照の置換マップ。

は、基本が追加モードだからタイムシートエディタとしては甚だ使い難い*1のでどっちにしろ派生クラスは作らなければならなかった運命だった模様。
行編集も出来たし後はtms形式でのロードとセーブだがどうもサムネイルテーブルのクリアが上手く行かないような*2。でもまぁもはや技術的困難は無いよなー。lnコマンドを見つけた時点で勝敗は決していたと言える。
あ。そうだ。サムネイルの生成速度とOut of memoryかー。速度の方は最初に覚悟を決めて全部サムネイル生成してしまえば*3速度はOKだろうけどOut of Memoryがなー。やっぱGCの様子を見ながらJavaの-Mmx, -Mmsでよろしくチューニングしか無いのか。でもあんな小さいサムネイルでOut of memoryは納得がいかんのでどうもなー。タスクマネージャで荒っぽく見ただけだけどそんなにメモリー使用量が増えてる訳でも無いのに…。

と思ったら、これは…！！うーむ、やはりレンダクラスとエディタクラスをカラム毎に作らないとダメかねー。要するに桝目に数字入れるだけのショボいものだから手抜きしたかったんだが…。
未知の画像ファイル対応は完了。空セル用画像ファイルさえ１枚用意して指定ディレクトリに放り込めばありとあらゆる形式が扱える(筈)。
→あれ？そう言えばUISって、画像毎にサイズが変わっても大丈夫だっけ？調べておかないと。まぁ結局私はMedia Studio Proに渡す段階では720*540の32bitPNGしか使わないけど。
ところでImageIOの拡張(JAI)使ってるのにTIFFが読めるようになっていない気がする。何故だろう…WBMPとかどうでも良い（というか見たこと無い）のは挙がってるのに。実行時のクラスパス周りとは思うが…。

javax.imageio.ImageIO.setUseCache(false)で。でも余り変わらん。
昨日のは実行するバッチファイルのフルパス名も""で囲んだらズバット解決。後はタイムシートファイルの読み書きか。それとサムネイルの高速化。それにしてもサムネイル作成は本当に遅い。何故ここまで時間が掛かるのか。
そいえばJavaのImageIOってTargaやPSD読めないんだっけ。結局、桝目に番号書いてlnコマンド発行するだけのアプリだから画像として読めないからって排除するのもやりすぎだよなー。サムネイルには「×」でも表示しつつ扱うのはどうか。空セルは透明画像ファイルを別途事前準備してコピーだ。

まー大体基本動作は出来て後は便利機能とかイリーガルな操作対策とか入れれば形になる訳だが、一つ問題が。
結局lnコマンドを羅列したバッチファイルを吐いてこれをexecする事でハードリンクを作るんだけど、ディレクトリ名にスペースがあるとパラメータ区切りと誤認して非常にまずい事に。どうしよう。ショートネームに変更なんてJavaには出来ない。
一番簡単なのは例のlnコマンドを改造することだけれど面倒なのでとりあえずスペースのあるディレクトリ指定を禁止に。そもそもファイル名にスペースを入れるなんて暴挙は例えマイクロソフト社が許してもこのポワトリンが(略)。
でもC:\Documents and Settings\usr1\My Documents\My Picturesとかスペース使いまくりだろうなー。私はD:直下に別ディレクトリ掘ってマイドキュメントにはそこを指定してるけど。
→下のコメントでねこまたやさんに教わってファイル名を""で囲んだらスペースでも大丈夫だった。
→うわ。今度は日本語ファイル名がダメな事を発見してしまった。もー。空白は使わないけど日本語は割と使ったりするんだよなー。まーいいか。
　→明日は吐いたバッチファイルの文字コード方面をちょっと調べるか。例えばUnicodeで書いたらOK,みたいな事が有るかも知れない。→気になったので今見たらSJISだけど改行コードがLFのみ。CRが無い。何かこの辺が怪しいな。でも改造は明日。もう寝る。
→むむ。今度はOut of Memoryが。heapが足りないのか。まぁこの辺は(メモリリークしてなければ)起動オプションでどうにでもなるから開発中は放置。でもおかしいな。読んだ画像は32*32の小さいサムネイル作ったら即廃棄してるのに。何か忘れてるかも。

絵コンテエディタの時は画像のサムネイルを最初の表示の時に画像を読み込んでキャッシュしてたけど、これの場合は１度に表示する数が多いんで結構時間掛かって操作し難い。寧ろ各セルディレクトリ最初の読み込み時にプログレスバーダイアログ出して全部読んだ方が良いな。でもそれは後で。

って実は隠し機能であったのか。
http://homepage1.nifty.com/emk/symlink.html
Media Studio Proだとどちらにせよ個別クリップ扱いだから状況は変わらないけど。一応メモ。
→いや待て待て。ハードリンクなら先日失敗したUIS*1扱いが出来るかも知れないな。帰宅したら試そう。
→んむ。出来る。Media Studio Proからは通常ファイルにしか見えてない。普通にUISにも変換出来る。本当なら自前でリンク機能作るべきだろうけれど面倒なので上記のlnコマンド羅列なバッチを吐いて実行させよう。つか寧ろその方が動作確実しかもUnixでも使えるし。使わないけど。

だーめーだー。
タイムライン上に配置は意図通り成功するけれど、個々の駒はあくまで別クリップという扱いなので、フィルターや透明度等々は１駒毎に指定することになる。非現実的。いいアイデアだと思ったんだが…。
せっかくエディタも作ったのに…*1。

後はショートカットの作成部分をJNIにしてJavaから行うか、あるいは別exeにして指示ファイル渡すかだけだったのに…。
やはりAVIにしなければ駄目なのか*2。ロスレスかつα保持するCODECは無いものか。LCLは良い線行ってるんだがαが無いのよね。
ちなみにVFAPI Codecのヘッダ見たけどVF_StreamInfo_Videoの構造体定義が

DWORD dwBitCount;// 映像のビット数(24 のみ)

とあるなー。わざわざコメントで24 のみ。と有るからαは持てないっぽい気がする。