IntegerQ GeoLog

メモ、覚え書き、もろもろ...

← 2008/9 →

日月火水木金土
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
My Yahoo!に追加 RSS
Counter

2008/9/30 (火)

いよいよCS4

いよいよ、Adobe CS4の情報がちまたに流れ始めましたネ。残念ながら使用可能メモリの上限は相変わらずですし、64bitへの対応もOSX10.5絡みの問題でPhotoshopWindows版のみのようです。

ただ近頃は、マシンの処理性能に依存し過ぎる作業フロー自体を改善する取り組みをおこなっているので、After Effectsが十数GBのメモリを使いこなせない仕様のままでも、差し当たって「致命的な問題」とはなりません。‥‥まあ、もちろん、折角広大なメモリ空間をマシンが用意できるようになったのですから、After Effectsもその状況に対応して欲しい‥‥とは思いますが。

なので、After Effects CS4に対して、「巨大な寸法のBGにも気兼ねなく対応できる」とか、「メモリオーバーフローを気にせずに効果をバンバン適用できる」とか考えるのはNGです。依然として、「メモリの消費量を意識した」オペレーションがユーザに求められます。「細かな配慮」「急がば回れ」のオペレーションはCS4でも必須でしょうネ。

新しい機能・仕様については、以前はコンポジションレイヤーをダブルクリックすると、レイヤーウィンドウに表示されていましたが、CS4からはコンポジションそのもののタイムラインウィンドウが開く様になりました。これは実際の作業上においては「地味だけど便利」な仕様変更です。ミニワークフローも結構便利。スクリプトでは、ようやっと、テキストレイヤーのスタイル（フォントサイズとか）を制御できるようになりました。

なので、目玉機能は無くても、CS3よりはCS4‥‥でしょうかネ。幾分、動作が安定している様子‥‥ですし。バージョンアップ料金は、また25,000円じゃろか？。

そう言った状況から、アニメ業界でAfter Effects CS3はまさに「闇バージョン」確定‥‥と言う感じですネ。実写素材を扱う分には、CS3もキビキビと動作して使えるんですけど、アニメ制作のように大判サイズが頻発するような現場では、CS3を使いこなすにはかなりのコツが必要です。ちょっと大きなサイズの画像を扱うと簡単にコケるので‥‥。

ちなみに、CS4からはPowerPCのサポートは外れました。故に、OSX時代を生き抜いたG3,G4,G5でも、After Effectsの最終バージョンは、結果的に現バージョンのCS3となります。同時にRosettaを使うモードも消滅し、PowerPCのみ対応のプラグインも使用不可となります。つまり、

・After Effects CS4
・MacOSX10.4以降
・Intel Mac本体
・CS4＆Intel Mac対応のプラグイン

‥‥が、必要となります。一度に刷新するには、かなりの出費。

今までず〜っと昔の環境を使い続けてきて、今度のCS4でAfter Effectsを新しくする人は、他の部分も同時にバージョンアップしないと、動作しません。実際に、私の所有マシンの内の何台かは、動作対象から外れています。導入前に要注意‥‥ですネ。

作成者 ezura

2008/9/27 (土)

「STX」の開発

xtoolsバージョン1に、「STX」というツールを追加する事になりました。STXはどんな内容かと言うと、セル＆背景を組み合わせて基本的な構成を形成するツールで、既存の「CBX」と言う「コンポジション・ビルダー」とかぶる内容となっています。

ではなんで、そんな「内容のかぶる」ツールを作るかと言うと、「演出の撮出し作業」を考慮する事、演出家の用いるプラットフォームを不問とする事、演出家が理解し易いプロジェクト構成にする事‥‥等々を実現する為です。

「CBX」には演出家の介在するポイント・タイミングが考慮されておらず、現在すっかり主流となった「撮出し無し方式」に準じた内容になっています。つまり、「撮出し作業を組み込む余地がない」仕様と言えます。

「撮出し」という行程が、現在の「デジタル」時代にどのように成立するかは、まさに10人いれば、10通りの意見が出るかと思います。‥‥なのでSTXは、私が現在作業中の作品の事情に合わせて、暫定的な見極めの内に作られる「短命」なツールになる可能性があります。

短命なツールを作るくらいだったら、現在の自作ツール「CBX」を拡張すれば‥‥とも思うのです。しかし、自分で作っておいて何ですが、CBXバージョン1のコードは、「もう読み直したく無い」「直したいトコロ盛りだくさん」なのです。直すべき箇所、こんがらがった部分をそのままにして、さらに機能拡張した場合のグズグズな感じが、今からでも容易に想像できます。

なので、「次バージョンのテスト」的な役割も踏まえつつ、「撮出しニーズ対応型」のSTXを作り始めたのです。空セルの作り方の改善や、歯抜けセルの穴埋め方式の変更、美術さんが背動を作った事例への対応、コンポジットのツリー構造の見直しなど、xtools・CBXを使い続けて日々不都合に感じていた事をフィードバックして、コードをゼロから書き直すつもりです。

現在開発進行中のxtools II（バージョン2）は、まだまだアルファの段階で、どのような機能を装備すべきか？…すら変動している状態です。STXを作って、xtools IIの「足し」にできたらと考えています。

作成者 ezura

2008/9/25 (木)

「人手」の重要性

コンピュータによる「絵作り」を本格的に指向し始めると、逆に浮き彫りになってくるのが、「人手」の重要性・有用性です。

前回、例に挙げた「ケムリがもくもく」のカットも、要はコンピュータを活用できる部分に対してのみ、活用しただけであって、何もかもコンピュータで処理した訳ではありません。「カッコ良いフォルム」「グっとくるタイミング」をコンピュータが自発的に思考できる訳もなし。‥‥そんなこんなで、コンピュータを使い込んでいくうちに、逆にコンピュータの限界を知る様になり、「人の手作業」の重要性をまざまざと実感する事になるのです。

絵というものは、ある種、気まぐれなものです。イメージを具現化する為に、あえて描写の対象をねじ曲げる事すらあります。その「ねじ曲げ」は、時には「絵心」と呼ばれる事もある訳ですが、コンピュータに絵心を理解させた上で何か処理命令を実行させるのは‥‥‥、まだちょっと無理じゃないかなぁ‥‥と思います。コンピュータに絵心を実装するには、絵心をプログラムコードとして成立させなければならないので。

そうした事から、人手の作業というものは、コンピュータで処理できる作業とは差別化され、「特別の価値を設定された作業」へと推移していくようになる‥‥というか、なるべきだと考えています。実際、顔の描写ひとつとっても、人間じゃないと制御できない事例はたくさんあります。線一本、いろ一色だけを考えても、「良い塩梅」をコンピュータに期待するのは、まあ、無理ですネ。大事なキャラクターの表情を、例え清書だけだったとしても、コンピュータの「自動認識機能」「自動補完機能」なんかに委ねたくないですもの‥‥。繊細な表情や演技は、優れた技能の動画・仕上げスタッフを経て、完成させたいですネ。

とは言え、「コンピュータでどこまでできるのか」を知らなければ、「人間が介在しないとできない事」を知る事も不可能です。コンピュータを扱う職種ならば、「人は何をすべきか、コンピュータはどこまでできるか」を作品作業ごとに思考して、次回にどれだけ向上策を盛り込むかを考えていかないと、同じ事を繰り返すばかりです。

人手とコンピュータ双方の特性を理解し有効に活用する現場を構築するのが先か、はたまた、疲弊して衰退し空洞化していくのが先か、ここ数年の取り組みがその後の未来を大きく変えてしまうような気がしています。

作成者 ezura

2008/9/24 (水)

作画と「デジタル」と

私は最近、作画の方にも重点を置く様にしています。過去10年間くらい「作画能力仮死状態」で過ごしてきましたが、ぼちぼち、作画とコンピュータの要素を融合する取り組みを本格化させようかなと考えております。

何故、過去10年間、アニメーターの能力を事実上「封印」してきたかと言うと、ズバリ、コンピュータを「作画の片手間」で使いこなすのは無理だったからです。コンピュータをアニメに活用すると言う事を、「PhotoshopやAfter Effectsを使う」と言う事に狭めてしまえば、「自分で作画したカットを、『デジタル』でちょこっとイジる」‥‥のようなスタンスも可能だったと思います。しかしコンピュータや映像関連の様々な要素を自在に操る術を体得するには、「アニメーターを廃業する」くらいの決心・取り組みが必須だったのです。

しかし、映像の出力近辺の仕事ばかりをするようになると、映像の「発生源」に関わる事がどんどん少なくなってきます。「デジタル」専門の現在よりも、10年前の「作画と『デジタル』の掛け持ち」だった頃の方が、今よりも先鋭的・野心的な取り組みが可能だったと感じます。それは、作品の内容、シーンの内容に合わせて、「にわとりが先」「卵が先」を自在に使い分けられたからです。もちろん、そうする事の弊害もあった訳ですが、「コンピュータを使って、『何が可能か？』を追求しよう」とする観点では、非常に有利なフローだったのです。

現在は「模索・追求」という能動的なスタンスというよりは、「撮影さんで何をやってもらえるか」という受動的なスタンスのほうが多いように感じます。「作画内容は今までのままで、撮影さんのほうで‥‥」のようなオーダーが頻発するのは、その証しだと思います。

また、相変わらず基本は「フィルム撮影台」の感覚のままです。作画の時点で「仮想フィルム撮影台」を意識していれば、当然の事ながらコンピュータの映像生成の技術も「仮想フィルム撮影台」に準じたものになります。作風が「フィルム時代の刷り直し」となったとしても、それはごくごく当然の結果と言えます。

私はその状況を「手がまわらないんだから、やむなし」として許容してきましたが、‥‥まあ、そろそろ「次」にいかないとヤバいかなあ‥‥と感じています。どう考えても、今の技術・状況のまま「この先、10年、20年」持ち堪えるとは思えません。

‥‥なので、私が主導的立場にある作品においては、どんどん「次」の取り組みにシフトしていきたいと考えています。

実は「次」の取り組みのほんの一部は、今までの作品で色々と実用しています。例えば昨日放映されたRDという作品の中で、私が原画〜コンポジットをおこなった「ケムリがもくもく」のカットでは、「次世代の手法」（うさんくさい呼び名‥‥だけどネ）を導入しています。‥‥ディテールの細かいケムリなんて、原画も動画も仕上げも「通常単価なんかでやってられるか！」とブチ切れる複雑な絵で、しかも枚数が多く、まさに「泣きっ面に蜂」のカット内容ですが、コンピュータを活用する事を前提とした技術＆作業フローならば、作業状況と品質は激変します。

そのカットで描いたケムリは、「After Effectsの煙系プラグインで簡単に作ったケムリ」ではなく、作画能力を最大限活用した「描き手が思い通りに動かして描いたケムリ」でした。ですから、いくらコンピュータを使っても、アニメーターとして動かす能力が低い場合は、そのまんまケムリの動きに表れます。‥‥近年よくある「何か知らないけど、コンピュータが上手くやってくれる」ような事は一切ありません。良い面でも悪い面でも、コンピュータがその人間の能力・特質を増大するように働きます。

ちなみに、例に挙げた「ケムリ」の１カットですが、動画枚数200枚の内容でしたので、作業費もそれに呼応したものになりました。１カットの作業費としてひとりの人間が受け取る金額で考えれば、高価に感じられるかも知れませんが、内容的には相応の金額です。もし、「デジタル＝ローコスト＝簡単」という図式で考える人が「デジタルなんだから、もっと安くしてよ」みたいに言ってきた場合は、「『デジタル』だからと言って安くはなりません。もし高いと言うのであれば、従来通りの作業工程でやってください」‥‥とサックリと対応しましょう。同じ様に、「作り方さえ教えてくれれば、次からはウチで安く作るよ」というような向きにも、毅然と対応しなければなりません。

安価に高速に作りたいのならば、既に業界はその方法論を確立しているのだから、これから先もその方法論でやっていけば良い‥‥のでしょう。だからと言って、新しい未来を切り開く次世代のアニメーション作品にまで、その方法論を適用する必要は‥‥ありませんよネ。

作成者 ezura

2008/9/14 (日)

ESTKと他の言語のundefined

ESTKを常用していると、たまに他の言語の作法が面倒になる事があります。例として比べやすいのが、「undefined」等の使い方です。

例えば、AppleScriptで以下のスクリプトを実行すると、エラーとなります。

set x to 0
if x > 1 then set w to 1
if w then display dialog w



何故かと言うと、変数「w」が定義（宣言）されないと、その次に続く行で支障がでる為です。加えて、if分岐の条件に適合し変数「w」が設定されたとしても、変数「w」は「真偽値／boolean」では無いため、「if w then」なんて言う書き方では支障がでます。期待する動作を実現するには、（例えば）以下の様に書きます。

set x to 0
set w to 0
if x > 1 then set w to 1
try
display dialog w
end


しかし、ESTK（=JavaScriptの拡張言語）だと「undefined、null、false、0 以外はtrue」と言う構造のため、変数の宣言や真偽値を導く演算をしなくても、エラーにはなりません。

var x=0;
if(x>1){var w=1;}
if(w){alert(w);}


これは非常にらくちんな仕様です。構造を把握していれば、文を簡潔にまとめられます。

‥‥しかし、困った事も発生します。特に困るが「変数の寿命」です。例えば、AppleScriptなどの他言語では実行ごとに変数は宣言も含めて初期化される仕様が多いのですが、ESTKですと変数はそのまま生き続けて、以下のような状態が成立してしまいます。

下図のスクリプトを実行します。



その次に、全ての文面を消去します。



下図のスクリプトを書き込みます



スクリプトを実行すると、あれまあ、文面には存在しない変数「x」が表示されちゃいました



実際に私はこの仕様に気付くまで、何度も混乱しました。一度実行した変数は、その後にスクリプトを書き直して文面から消滅しても、「裏」では生きている訳です。

ですから、if分岐で条件に適合した時だけ宣言がおこなわれる変数は、非常に危うい構造と言えます。今回のESTK例文も「NG」。変数そのもののundefinedを期待しても、前回実行時に変数が宣言されてしまった場合は、undefinedにはならないからです。

でもまあ、こうした特性をふまえて活用すれば、ESTKはフットワークの軽い快適な開発環境です。

あとは、インターフェイスビルダー的なものが付属してくれると、すごく助かるんですがネ‥‥。実際、ESTKのスクリプト文だけでGUIを組むのは、時間の浪費が激しく、「XcodeのAppleScriptをブリッジにして、Interface Builderで組めばいいか」と早々に投げ出したくなります。‥‥かといって、AppleScriptをブリッジにするのも面倒なんだよなぁ‥‥。

作成者 ezura

2008/9/13 (土)

RAネタ、その14「BGとセルを読み込む・序の口編」

今回のRAネタは、レンダーオートメーションのアニメ業界での「本命」とも言える「コンポジションの自動構築」の話題です。

自動構築‥‥と聞いて、「それは便利で良いね」と簡単に頷く人は、恐らくAfter Effectsでの作業経験の浅い人、もしくは実際のコンポジット作業をあまり経験していない人‥‥だと思います。逆に、「本当に上手くいくんだろうか？」と半信半疑に感じる人は、実際の作業でのAfter Effectsオペレーションの煩雑さを体験済みで、「そうそう簡単に、自動で構築なんて出来るはずが無い」と作業上の経験から考える人‥‥だと思います。

後者の人は、まさに賢明。その「実（じつ）」を知っている人からすれば、多種多様な条件分岐の生じるコンポジット作業を、コンピュータの自動処理に適合するように「整理整頓」するのが如何に困難な事か‥‥を、肌身で感じているはずです。

ただ同時に、作業を積み重ねてきた経験から「作業範囲のうち、いくつかの部分は、決まったパターンが存在する」事も実感しているはずです。コンポジションの自動構築の第一歩は、その「決まったパターン」を分析する事から始まります。

分析を進める傍ら、「レンダーオートメーションでどのような事ができるのか」を知る必要もあります。今回の「序の口」編は、「BGとセルを読み込んで配置する」と言う基本的な機能を紹介しようと思います。

例によって、スクリプト文が長いので、スクリプト本文は外部テキスト（jsxファイル）にリンクしておきます。文字化けするようなら「UTF-8」の文字エンコードに切り替えてください。

http://integer9.ezqnet.com/glog/bg_and_cell_import.jsx

「背景とセルを読み込んでコンポジションに配置する」と言う基礎動作のみのシンプルなスクリプトですが、故に、今後の「発展形」のひな形となるものです。

では、ザッとスクリプトの段取りを説明しましょう。

背景ファイルは「BG」と言うフォルダに、セル（ペイント）のファイルは「CELL」と言うフォルダにそれぞれ格納し、全てまとめて「カット名」のフォルダに格納しておきます。



ユーザにフォルダ選択を求めて対象となるカットフォルダ（本例では「kuma_01_003」）を確定し、「BG」「CELL」内の素材ファイルの検索処理をおこないます。BGオンリー、全セルのカットへの対処を忘れずに。
--> if(Folder(matfolder.absoluteURI+"/BG").exists){

また作業者のうっかりミスで「カット名フォルダだけ作って、何も置かなかった」のような事態にも対処しておきます。そうしないと、いとも簡単にスクリプトからエラーが発生します。
--> if(!bgitems && !cellitems){

現在のプロジェクトを閉じて、新しいプロジェクトを作ります。その際、未保存のプロジェクトが開いていた場合はユーザに問い合わせます。
--> if(!app.project.close(CloseOptions.PROMPT_TO_SAVE_CHANGES)){

いよいよ、ファイルをAfter Effectsのフッテージとして読み込みます。
--> if(bgitems){
--> if(cellitems){

背景ファイルは、クロップしたコンポジションとして読み込むよう設定してあります。またセルのファイルは、「止めセル」か否かを判断して読み込んでいます。いずれの場合も一旦「インポートアイテム」と言う型を踏襲してからプロジェクトに読み込みます。‥‥これはAfter Effectsの流儀なので、それに準じます。

背景とセルをフッテージとして読み込むと同時に、コンポジションに配置します。
--> comp.layers.add(item);

コンポジションへの配置も完了し、これにて終了‥‥と言う事で、以下の様なコンポジションが自動で作成されました。




「ウチは、違うフォルダ構造で作業している」「背景はPSDの時もあれば、TIFFの場合もある」「レイアウトやスライド指示のファイルは、セルとは別扱いにしたい」とか、「ウチの場合は、プロジェクトはゼロから作るんじゃなくて、ひな形プロジェクトからカーボンコピーするんだけど」とか、「シートの処理は？」「スムージングのエフェクトは？」などの、色々な都合・疑問点はおありでしょうが、基礎のスクリプトさえ読み解ければ、そうした作業上の分岐に合わせて改良していく事ができます。

恐らく「自分で作らなければ、誰も作ってくれない」ツールが、今回の様な「自動コンポジション構築」ツールです。「スクリプトを習得する」と言うタネを自身の土壌に撒いて、日々コツコツと育てていかないと、収穫となる「自分の為のツール」なんて手にできない‥‥のでしょうネ。

作成者 ezura

2008/9/11 (木)

大学の講義、今週から開始

‥‥です。最近「RAネタ」をババっと書き続けたのは、恐らく、講義への思考準備だったのかも知れません。‥‥実際、RAネタのほとんどは大学の講義でもやりますから、ブログで書く事により、頭の中を整理したのでしょう。自分的に。

私の科目の講義内容は年々変化して行きますが、それは「現場からのフィードバック」が作用しているからです。フィードバック‥‥と言うか、危機感‥‥と言うか。

結局のところ、映像が完成すれば目的は達成できる訳ですから、ツールをどのように使おうがその人の自由なのです。しかし「映像が完成する」とはどのような事なのかをよくよく考えてみれば、「自分の完成像に対して、自分は有効かつ適切にツールを使えているか？」‥‥とか、「そもそも、自分の表現したい映像とはどのようなものか？」‥‥などの疑問・自己疑念がフツフツと湧いてきます。

例えば、ある作業者が「晴れた空に、炎をかざして」のようなイメージを持っていたとして、その人に「では、空と炎ではどちらが明るいのですか？」と尋ねると、しどろもどろで答えられなかった‥‥とします。結局その人は、「文字としてのイメージはある」のですが、「画像としてのイメージは無い」訳です。映像が頭の中に見えてなければ、何が「完成像」かも解りません。絵作りに実際に加担する人間がそのような状態では、映像表現は二転三転・迷走するばかりです。

また他の例えでは、「自分は完成像通りの映像を作った！」と自信満々に上映会場に自身の完成映像を持ち込んだものの、実際に上映が始まると「暗くてよく見えない」「明る過ぎて目が疲れる」「残像がキツい」‥‥のような状態になっており、観客からは良い反応を得られなかった‥‥とします。その時になって、「自分の家の『PCモニタ』では、ちゃんと映ってたんだー！！」と絶叫しても、他人からは「ふーん、そうでしたか」でおしまいです。映像は上映環境によりいくらでも変動するものだ‥‥という基本的な知識を欠いていたため、自分の「PCモニタ」を妄信して、ある種「心中」してしまった訳です。これは一生懸命に作っていた本人にしてみれば、最大の悲劇としか言いようがありません。

私が講義時間内でレクチャーしたい事は、「自己のイメージを、実際の映像メディア（上映も含む）へと決像する方法・手段」であって、私の映像スタイルを学生全員に押し付けたい訳でもなければ、ましてや「アニメ業界の通例」を職業訓練よろしく習得させたい訳でもありません。初心者の頃は、イメージや意気込みだけが先行して空滑りしやすい傾向にありますから、私の講義では、表面上のプラグインの使い方なんかよりも、どうすれば「空滑りせずに、目標通りに、映像を完成できるのか」という根本的な部分をレクチャーする為に時間を割くべきだ‥‥と思う訳です。

私の授業は午前中‥‥なのですが、本業をこなしつつ、授業開始に時間を合わせるのは相当にキツいッす。でもまあ、未来の心強い仕事仲間や強力なライバル（手強い競合は業界を活性化させるのでネ）が、数人でも出てきてくれれば（と言うか、生き残ってくれれば）‥‥と思いながら、中年な身体にムチ打ってでも、朝の満員電車に乗る事にしますヨ。

作成者 ezura

COMPと言えば、

‥‥私はどうにも「Compressor」＝コンプレッサー（しかもギターのエフェクターのほう）を思い出してしまいます。‥‥ゆえに、映像制作における「コンポジット＝Composite」のキーワードが、「COMP」＝４文字だと、どうにもキモチ悪い‥‥のです。先のブログでは「COMPTYPE」とか書きましたけども、「COMPOTYPE」の方が良かったかなとも思っています。

ちなみに、私の管理する「atDB」では、コンポジションの略語は「COMPO」で統一しています。「COMPO_DIMENSION」「COMPO_NAME」等の様に。

作成者 ezura

2008/9/10 (水)

RAネタ、その13「カット名をもっと活用してみる」（後編）

では、「りんご、みかん」のサンプルではなく、カット名と独自データベースとの連携を、レンダーオートメーションで実践してみましょう。

今回のスクリプト文の文字数は、ブログ文字制限内では過多なので、外部のテキストファイルでリンクしておきます。もし文字化けするようでしたら、Shift-JIS/LF改行で読んでみてください。また文字サイズの大小はご自由に。

カット名の情報を表示するスクリプト

上記スクリプトで、データベースを担っている箇所は、以下の部分です。

//作品基本仕様のデータベース
TITLE_DB="@anm=とあるアニメ=第@話=劇画太郎=撮影次郎,@sca=そんなこんなのアニメ=@パート=アニメ花子=撮影桃子,@a5=アニメーションPart5=Episode@=J.アニメスキー=A.コンポジットスキー,@ga=元祖アニメ漫画=シーン@=まんがイチロー=アフター太郎";

//撮影種別のデータベース
COMPTYPE_DB="@hon=本撮=本撮,@sen=線撮=線撮,@tmg=T撮=カラータイミング撮,@con=コンテ撮=コンテ撮,@rlo=ラフLO撮=ラフレイアウト撮,@lo=LO撮=レイアウト撮,@rgen=ラフ原撮=ラフ原撮,@gen=原撮=原撮,@rdou=ラフ動撮=ラフ動撮,@dou=動撮=動撮,@3D=3D撮=3Dタイミング撮,@bo=ボード撮=イメージボード撮,@lei=Leica=ライカリール,@ct=CT=カッティング,@ar=AR=アフレコ,db=DB=ダビング";


「TITLE_DB」は、作品の基本情報を一定の書式で記述した内容となっています。以前のブログの命名規約の内容通り、カット名から抜き出した作品キーワードで作品基本情報を引き出せる様になっています。

「COMPTYPE_DB」は、撮影種別の用語辞書となっています。「キーワード『tmg』は、省略用語『T撮』、用語『カラータイミング撮』」‥‥という様なあんばいです。なぜ「用語」だけでなく、「省略用語」を定義しているかと言うと、伝票記入欄など、文字数スペースが狭い状況に対処する為です。また、「こんなに細かい分類が必要か？」と思われるかも知れませんが、あくまで「ころばぬ先の杖」です。

では、スクリプトを実行してみましょう。

「anm_03_142_t1」を入力




「sca_a_021_dou_t1」を入力




「a5_27_304_lo_t1」を入力




「ga_3_055_rgen_t1」を入力




このように、「たかだかカット名」のはず‥‥なのに、ほんの数行の小さなデータベースと連携する事によって、作品のタイトルや監督などの名前も同時に取得できるようになりました。もし、カット毎の情報を記録するデータベースと連携すれば、「誰が担当者か」「いつ作業INしたか」「尺は」「トランジションの有無は」‥‥などの情報も記録・取得できるようになります。

データベースへの取り組みが大規模になってくると、さすがにJavaScriptの「変数扱い」では役不足になってきます。何らかの「データベース記録に適した媒体」が必要になります。その際は、一念発起して色々なデータベースソリューションを吟味して、自分のニーズに合ったものを選択すれば良いと思います。もちろんその時には、小規模ながらも自身でデータベースを構築していた経験が役に立ちます。同時に「データベース専用のソリューションは、こんな事もできるのか」と頼もしく感じる事もあるでしょうネ。

ちなみにAfter Effects／ESTKは、FTP、HTTP、任意ポート・ソケットによるデータの送受が可能です。つまり、After Effects＆ESTK、各種サーバ、ネットワーキング等々の知識が蓄積してくれば、それらの知識を活用して高機能なワークグループを構築する事が可能となります。つまり、既にお膳立ては揃っている‥‥という事です。

データベースを定義・規約する時、既存の概念やワークフローに縛られて思考してしまい、作品の映像表現の限界まで早々に定義してしまう事がよくあります。「状況を把握したい＝既知」「新しい映像作品を作りたい＝未知」と言う相反する要素を、どのように捌いていくかが重要なポイント‥‥と言えるでしょうネ。

作成者 ezura

RAネタ、その13「カット名をもっと活用してみる」（前編）

何回か続いたカット名ネタも今回が最後です。まとめとして、カット名をもとに「データベースとのやり取り」をおこなうレンダーオートメーション（と言うか、ESTK）を作ってみます。

データベース‥‥なんて聞くと、初心の頃は「自分には無理っぽい」と考えてしまいがちですが、それはよくありがちな、コンピュータの「高度げな言葉に怖じ気付く」状態‥‥です。実は自分の身の丈に合ったデータベースを使えば、特に難しくは無いのです。いきなり初心者が「データベースサーバ用にコンピュータを購入・設定し、SQLにてプログラムを組む」なんて事をする必要はありません。

まず何よりも「データベースとは何ぞや」と言うところから理解して、先ほども書いた様に「身の丈に合ったデータベースを作る」事が大切です。そうした手順・ステップアップなしに、誰かから聞きかじった一般論だけで「よく解らないけど、サーバを購入しちゃった」なんて、使いこなせる訳がありません。

データベースの一番身近なものは「メモ」です。いわゆる「走り書き」ですネ。「りんごが３個、みかんが２個」のような。

「そのメモの、どこが『データベース』なんじゃい」と思う人は、既にコンピュータの呪いの中に居る‥‥と言っても過言ではありません。何でも「コンピュータの中で考えないと修まらない」と言う人種で、「データベース＝コンピュータの要素」と狭い考え方をしている状態です。

では、「データベースの定義」についてWikipedia等で検索するとどうか？‥‥と言うと、「特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの再利用をできるようにしたもの。」とあります。先ほどのメモを引き合いに出すと、「青果店での買い物」と言うテーマに沿って「品目・個数のデータ」をメモ用紙に集めて管理し、実際に買い物をする時に検索・抽出などができるようにしたもの‥‥ですネ。走り書きの状態とは言え、データベースの体裁は有している訳です。

先ほどのメモ書きがデータベースと言えるのならば、もしかしたらコンピュータ上でも処理できるかも知れません。‥‥もちろん可能です。以下がスクリプトです。

var memo="りんごが３個、みかんが２個";
var memofact=memo.split("、");
var db=new Array();
for(var i=0;memofact.length>i;i++){
db[memofact[i].split("が")[0]]=memofact[i].split("が")[1];
}

var res=prompt("品名を入力","","お買い物メモ");
if(res){
if(db[res]){
alert(res+"は"+db[res]+"買います");
}else{
alert(res+"は買いません");
}
}

ではまず、「みかん」を問い合わせると‥‥




次に、買う予定の無い「ぶどう」を問い合わせると‥‥




‥‥このように、「りんごが３個、みかんが２個」と言うデータを用いて、「品目を入力して、個数を得る」データベースを実現できました。

こうした基礎無しに、初心者がスペックだけ丸暗記して「データベースサーバがどうのこうの」と言っても、有効に活用できるとは到底思えません。まずは自分の身の丈に適合した取り組みから始めて、感触を得て、段階的に発展させて行けば良いのです。例えば、アニメ制作現場の人間が、いきなり「データベースサーバを購入・設定しましたから使ってください」と言われても、制作現場の人間自身が「データベースをどのように作業に活用するか」の実感が無ければ、どうにも上手く使えないでしょう。

データベースは「りんごが３個、みかんが２個」の例が示す様に、まずは「文字列」だけで組んでみて、自身に使用感・実感を得るのが有効かと思います。例えば、以下の様に。

COMPTYPE_DB="@hon=本撮=本撮,@sen=線撮=線撮,@tmg=T撮=カラータイミング撮";


‥‥たった、これだけの事ですが、「撮影種別キーワードを用語に関連付けるデータベース」が出来ました。「@キーワード＝省略用語＝用語」の書式は、自分自身で定義したものなので、後で再利用する際は、自身の定義に準じてデータを取り出す事になります。

では後編に続く。

＊ちなみにスクリプトサンプルでは、品目が「がんもどき」「らくがん」の場合は、‥‥期待する動作になりません。理由はスクリプト本文にアリ。

作成者 ezura

2008/9/9 (火)

RAネタ、その12「カット名の情報をWebにて表示してみる」

今回はESTKから少々脱線して、RAネタ・その11の内容を、Webサーバ上で実現してみます。

前回の内容は、「カット名を簡易分析する」ものでしたが、ともすれば、「レンダーオートメーションの中だけの話題」と受け取られる事もあるかと思います。‥‥それは単なるはやとちりで、データを扱って処理できる環境があれば、別にレンダーオートメーションだけに使用を限定する必要などありません。AppleScriptでもVisualBasicでも、PerlでもPHPでも、「データを処理する何か」であれば一向に構わない訳です。

今回はその例として、After Effectsからちょっと離れて、Webサーバ上で動作するPHPにて、カット名の簡易分析をおこなってみます。

PHPについては、Web上で検索してみてください。PHPとは要するに、Webサーバ上で動作するプログラム言語で、Webサーバだけでは実現できない多様な処理を提供するモジュールです。MacOSXにはApacheと共に標準インストールされていますので、（Admin権限さえあれば）Apacheのコンフィグファイルを一部書き換える（モジュール読み込みのコメントアウトを除去する程度）だけですぐに動作可能となります。

私の常用するレンタルサーバ上でもPHPがアクティヴとなっているので、そのサーバ上で「カット名簡易分析PHPファイル」を動作してみます。

このアドレスで。
このアドレスは？
こっちのアドレスでも。

表示されたWebページを見てもらえればお解りの通り、前回ESTKでおこなった事と同等の内容が、Webブラウザ上で閲覧できます。Webのアドレスを注意深く読んでもらえば、その仕組みが何となく解ると思います。

http://integer9.ezqnet.com/glog/cutname_info.php?sn=anm_03_142_t2

アドレス文字列の「？」の後の「sn=anm_03_142_t2」が、Webサーバに文字列データを送信している箇所です。この「sn=anm_03_142_t2」と言う文字列をWebサーバが受け取り、PHPに渡して処理をおこないWebページの内容を生成し、閲覧ユーザのコンピュータに返している訳です。この送受方法はごくごく一般的な方法で、「Google」などでもこうしたURL内の「クエリ文字列」を活用していますネ。

サーバに配置した「cutname_info.php」と言うファイルには、サーバが受け取った文字列を処理する内容が書いてあるので、カット名を（簡易ですが）分析する事が可能なのです。もちろん、カット名をちゃんと分析できるのは、カット名を事前に規約しておいたからです。



ファイル名・カット名の命名規則の効能が実感できる様になるのは、今回の例のような「自分の規定した情報が、After Effects以外の色々なアプリケーションで活用できる」事を実感してからかも知れません。今回の例は、単にカット名を分解して簡単な分析をしただけですが、想像豊かな人ならば、今回の例を発展させてさらにどのような事が可能になるか‥‥を、何となくでも思い浮かべる事ができるんじゃないでしょうか。

作成者 ezura

RAネタ、その11「カット名を活用する」

先のブログで「プログラムをたしなむ様になると、コンピュータの活用法が変化してくる」のような内容を書いたのですが、その「活用法の変化」はファイル名・カット名にも及んできます。ファイル名・カット名・フォルダパスなどを、「単に目で読む為のもの」「成り行きでそうなったもの」として「場当たり的に運用」するレベルから、「基本情報をひとまとめに記述したもの」として「確固とした指針を持って運用」するレベルへと発展してきます。

「たかだかファイル名・カット名」ですが、「たかだか」だからこそ、それを扱う人間の状態が浮き彫りになる訳です。単にファイル名ひとつで、それを扱う作業現場の意識・運用レベルまで見えてしまうのです。

コンポジットをおこなう際のカット名を例にとると、カット名の文字列を「情報記録媒体」として活用した場合、５つくらいの情報を載せる事ができます。例えば、

anm_03_142_t2

‥‥と言うカット名・ファイル名には、「作品anm、第３話、カット番号142、本撮、テイク２」と言う情報が含まれています。

このような情報を記載できるファイル名・カット名を、単に「目で読んだら、それで役目は終わり」だなんて、とても勿体無い話‥‥なのです。そのファイル名・カット名を用いてデータベースサーバと連携すれば、「現在の進行状況」「尺」「作業者」「難易度」「いつ作業開始して、いつ作業終了したか」「自分はあと何カット残っているのか」「１日でどのくらいの作業量が可能なのか」「現在のマシンでどのくらいレンダリング時間が必要なのか」などの情報を、照合したり計算したりする事が可能となります。‥‥たかだかカット名‥‥なのに、コンピュータを用いたシステムと統合して運用する事により、今まで以上の高度・高速な作業分析が可能となる訳です。

カット名を活用するには、まず何よりも、「カット名の命名規則」を確立する事が重要です。命名規則無しに、各作業者が好きな様にカット名を定義したら、その後のカット名の分析等出来るはずもない（‥‥できるけども、非常に煩雑で非効率な分析ルーチンが必要になる）ので、「名前のお約束」はどうしても避けて通れない段取りなのです。

私が常用している命名規則を例にしますと、

作品Key _シーンKey _カット番号 [_自由定義] _撮影種別(本撮のみ省略可能) _tテイク番号


‥‥のようになります。名前に内包される各情報は前回のRAネタでも出てきた「デリミタ」で区切って記述しており、容易に情報を切り分ける事が可能となっています。

名前をアンダースコア「_」で区切った第１要素が作品キーワード、第２要素がシーン・話数キーワード、第３要素がカット番号、第４からマイナス第３要素（後ろから数える時はマイナスを使います）までが自由に拡張できる領域、マイナス第２要素が撮影種別、マイナス第１フィールド＝最終要素がテイク番号‥‥のようになっています。1,2,3,-2,-1の要素は使用目的を予約していますが、4〜-3は使用目的を任意に定義して未知の状況に対して柔軟に対応できるように配慮しています。

この命名規則を元に、任意文字列を簡単に分析してみます。ソースは以下。

var cutname=prompt("カット名を入力してください","","カット名簡易分析");

if(cutname){
var array=cutname.split("_");
if(array.length>3){

if(array.length==4){array=array.slice(0,3).concat("hon",array[3]);}
if(array.length>4){array=array.slice(0,3).concat( array[array.length-2], array[array.length-1]);}

var typeconf="@hon=本撮,@sen=線撮,@tmg=T撮";
var type=typeconf.match("@"+array[3]+"=.+","i");
if(!type){
type="その他";
}else{
type=String(type).split(",")[0].split("=")[1];
}

alert("「" + cutname + "」の分析結果\r作品キー：" + array[0] + "\rシーン・話数：" + array[1] + "\rカット番号：" + array[2] + "\r撮影種別：" + type + "\rテイク番号：" + array[4].slice(1));

}
}


上記スクリプトを実行すると、以下の様になります。





‥‥たったこれだけの事‥‥ですが、この「名前の解析」の可否が、作業現場の様相を左右すると言っても過言ではありません。コンピュータ導入後の状況を有効に活用できる制作現場を確立できるか否かが、この「たかだか名前」に表れてしまうのです。言わば、コンピュータ活用の試金石が「カット名の扱い」‥‥と言う訳ですネ。

次のRAネタでは、もう少し突っ込んだ「名前の活用法」を紹介したいと思います。

作成者 ezura

2008/9/5 (金)

RAでスクリプトを常用する意義‥‥

RAネタ‥‥で、せっせと「レンダーオートメーション」の紹介を細々とやっている訳ですが、たまに「プログラムはプログラマーに任せておけば良い」と言う文言を耳にする事があります。

「プログラムはプログラマーに任せておけば良い」‥‥と言うフレーズは、状況・環境が揃った時に初めて言える言葉です。プログラマーは映像分野・コンポジット作業の専門家ではありませんから、何らかのオーダーが無ければ映像制作用のプログラムを自発的に作ることはありません。いくら首を長くして待っていても、コンポジット作業に都合の良いツールなど「自然発生」する訳がありません。

そこでオーダーを出してプログラムを作ってもらおう‥‥と言う発想に移行する訳ですが、プログラムのプの字も知らない人間が、どれだけ有用かつ発展性（先見の明）のあるオーダーを出せるのか、甚だ疑問です。おそらく「場当たり的な」オーダーに終始してしまうか、従来の機能だけを羅列しただけのものになってしまう事は、容易に想像できます。‥‥その割に、使い始めると「機能が足りない」とか「融通が利かない」などと宣う訳ですが、実際、オーダーを出す時点でその「機能」「融通」に対してどれだけ「読めていたのか」‥‥オーダーを出す側にもかなりの責任があると常々思います。オーダーが甘ければ、製品も甘くなるのは当たり前の話です。住戸の建築に疎い人間は、住みにくい家を買う危険性を常に孕んでいる訳で、買った後で「なんか、住みにくいなあ」と思っても「後の祭り」です。

洗練されたコーディングなど、プログラムの手練手管は専門家に任せれば良いですが、それはオーダーを出す側・実際に使う側がプログラムに対して無知のままで良いと言う事とイコールにはなりません。

私が作っているスクリプトなどかわいいレベルのものですが、「コンピュータで何が出来るのか」「どのように活用できるのか」への考察は、スクリプト等のプログラムを覚える以前・以後では雲泥のレベル差があると実感します。もし自身でスクリプトを作っていなかったら、いつまでも受動的にコンピュータを使うばかりになっていたと思います。

コンピュータをメインに据えて仕事を続けていくのならば、ぼちぼちでも構わないから、スクリプト「くらい」は習得しておくべきだ‥‥と思う訳です。特にコンポジットは、「映像のプログラム」とも言える行為ですから、制作現場が「デジタル」に移行して10年が経過しようとする現在、「スクリプトはたしなみ」くらいに考えておいてもバチはあたらないと思います。

「プログラムはプログラマーに任せておけば良い」と言うのは、オーダーを出す側の知識・素養が揃った上での話であって、プログラマーとコンポジット作業者の意図が空しく平行線をたどるばかりでは、現場の底上げをするソフトウェアなど作れようはずも無い‥‥と、しみじみ実感します。

作成者 ezura

RAネタ、その10「HTMLに変換してみる」

今回は、その9で生成した情報テキストをHTMLのテーブル＝表に置き換えるスクリプトです。

データは、その情報量が増えると「読み辛く」なってきます。そこで、可読性の高い「表の体裁」で閲覧できるファイルを作ってみます。表を作成できるアプリケーションは山ほどありますが、データ構造が非公開だったり、そもそもテキストファイルではなく、バイナリファイルだったりする事も多いので、今や誰でも閲覧可能な「HTML」ファイル形式を用いる事にします。

HTML‥‥つまり「ホームページ」を表示する際に多く用いられるファイルは、作表機能を有しています。データの生成もさほど難しくありません。HTMLの記述方法は（レンダーオートメーションと違って）Web上で色々と検索できますから（‥‥これも有志の方々の苦労の賜物）、そちらを参照してみてください。

まず、前回のスクリプトに一部加筆して、「見出し行」を書き込む命令を追加します。表に見出しが有った方が、「何の情報か？」が解り易いですよネ。

var delim=String.fromCharCode(9);
var textfile=File.saveDialog();
if(textfile){
textfile.open("w");
textfile.writeln("カット名"+delim+"テイク"+delim+"尺");
for(var i=1;i<=app.project.numItems;i++){
var item=app.project.item(i);
if(item instanceof CompItem){//コンポジションだけを対象に
textfile.writeln((item.name.split("_")[0]) + delim + (item.name.split("_t")[1]) + delim + String(Math.floor(item.duration)) + "+"+String(Math.round(item.duration*item.frameRate) % item.frameRate));
}
}
textfile.close();
}


上記スクリプトを実行すると、以下の様になります。

[After Effectsプロジェクト]


[書き出したテキストファイルの内容]


書き出したテキストファイルを用いて、以下のスクリプトを実行してみます。

var delim=String.fromCharCode(9);
var doc=File.openDialog ("タブ切りテキストを選択してください");

var newdoc=File(doc.parent.absoluteURI+"/"+doc.name+".html");
newdoc.open("w");
newdoc.writeln('<;!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">;');
newdoc.writeln('<;html lang="ja">;');
newdoc.writeln('<;head>;');
newdoc.writeln('<;meta http-equiv="content-type" content="text/html;charset=shift_jis">;');
newdoc.writeln('<;title>;'+doc.name+'のHTMLテーブル化'+'<;/title>;');
newdoc.writeln('<;/head>;');
newdoc.writeln('<;body>;');
newdoc.writeln('<;table width="100%" border="1" cellspacing="0" cellpadding="6">;');

doc.open("r");
while(!doc.eof){
var cont=doc.readln().split(delim);
if(cont.length>;0){
newdoc.writeln('<;tr>;');
for(var i=0;i<;cont.length;i++){
newdoc.writeln('<;td>;'+cont[i]+'<;/td>;')
}
newdoc.writeln('<;/tr>;');
}
}
doc.close();
newdoc.writeln('<;/table>;');
newdoc.writeln('<;/body>;');
newdoc.writeln('<;/html>;');
newdoc.close();

＊ブログ表示上の改行が介在しておりますが、コードをESTKエディタにペーストすれば、正常な行表示となります

上記スクリプトを実行すると、以下の様なHTMLファイルが生成されます。



なんとも簡素な表だこと。‥‥でもまあ、この内容を発展させれば、もっと情報豊富な伝票を作成する事も可能でしょう。

HTMLの「お約束」部分が少々煩雑ですが、こういった訳で、レンダーオートメーション（と言うか、ESTK）でもHTMLを生成する事が可能なのです。

作成者 ezura

RAネタ、その9「テキストファイルの扱い」

RAネタその8が未完ですが、箸休めとして小ネタを挟んでみようかと思います。

After Effectsのレンダーオートメーションは、AdobeのES（ExtendScript）の機能を使えますから、テキストファイルの読み書きも可能です。After Effectsの使用中にテキストファイルの読み書きなんて関係あるのか？‥‥と言う人もいるかも知れませんが、多様なセクションが存在するアニメ制作では、「伝票」を作成して情報を伝達する事が多く、After Effectsを使うコンポジットセクションも等しく伝票を作成します。

この「伝票」‥‥手書きやキーボード入力で記述するとそれなりに大変です。さらに、人手が介在する事により、ケアレスミスの発生頻度が増大する事も問題となります。例えば、ムービーの諸元を羅列する伝票作成においても、人手よりコンピュータのほうが正確かつ高速です。手作業で苦労して作成した伝票上で「誤字脱字」「情報の書き間違い」がある事が発覚し、そのリカバーにさらに「作業時間を浪費した」‥‥なんて悲しすぎます。

After Effectsがそこにある‥‥のだったら、After Effectsを活用して伝票を作成してしまいましょう。

ファイルの読み書きには一定の「段取り」があります。ファイルにアクセスする明確な段取りが必要となります。

File.open(アクセスモード);
File.close()

読むだけならreadモード、書き込みをおこなうならばwriteモードにて、ファイルをオープン状態（ファイル内のデータとやり取りできる状態）にして、用が済んだ後はちゃんとクローズします。クローズしないと、「このファイルは開いているので、変更できませんでした」のような警告が出る事があります。

また、何らかの情報をテキストファイルに箇条書きにする際、情報を区切る「デリミタ」で情報を区切った方が、後で処理し易いテキストファイルとなります。例えば‥‥

姓,名,性別
江面,久,男

‥‥のように特定の文字列（上例はカンマ）で区切って記述すれば、後で情報を切り分け易くなります。実は、私のグループで扱うファイル名はこの「デリミタ」を使ったファイル命名規則にしてあります。意識的に運用すれば、ファイル名は情報の格納場所になる訳です。

では、試しに、After Effects上の３つのコンポジションの情報をテキストファイルに書き出してみます。作例の区切り文字はタブ、‥‥つまり「タブ切りテキスト」を書き出すスクリプトとなっています。



[スクリプト文]

var delim=String.fromCharCode(9);
var textfile=File.saveDialog();
if(textfile){
textfile.open("w");
for(var i=1;i<=app.project.numItems;i++){
var item=app.project.item(i);
if(item instanceof CompItem){//コンポジションだけを対象に
textfile.writeln((item.name.split("_")[0]) + delim + (item.name.split("_t")[1]) + delim + String(Math.floor(item.duration)) + "+" + String(Math.round(item.duration*item.frameRate) % item.frameRate));
}
}
textfile.close();
}

＊「writeln()」は一行ずつ書き込む命令です。
＊一部、表示上の改行が入っていますが、ソースをESTKエディタにコピペすれば、正常な行表示になります。

結果は、以下の通り。



内容は「カット名、テイク番号、尺」の一覧となっています。今回はたった3つの情報だけにしてありますが、もちろんもっと沢山の情報を書き出す事も可能ですし、情報取得対象をコンポジション（CompItem）以外にする事も可能です。

簡素な書式のテキストファイルですが、これが後々大きく役立って、作業者の負担軽減をしてくれる事になります。この「小さな一歩」を見落とすと、その後の「大きな収穫」も得られない‥‥訳ですネ。

次回は、今回書き出したテキストファイルから、HTMLによる簡易一覧表を作ってみます。

作成者 ezura
前の記事  |  次の 1 記事

新着記事一覧