尺、桁揃え

After Effectsで尺〜デュレーションを自動表記する際、私が昔から好んで使うのは、以下のようなエクスプレッションです。

var offset=8;
//ボールドなどの尺を引く場合は、適宜
var t=thisComp.duration-framesToTime(offset);
String(100+Math.floor(t)).slice(1)+ "+" + String(100+Math.round(t%1/thisComp.frameDuration)).slice(1);
//2桁で表記を統一する場合です


*ブログのデザイン上、改行されている箇所がありますが、行末はあくまで「 ; 」です。

私は、昔からの習慣で、小数点の端数で痛い目にあっているので、thisComp.durationをframeDurationで割る‥‥というような事はせずに、1秒で割った余りだけをframeDurationで割るようにしています。誤差を極力出さないルーチンにしておけば、どんな環境でも表記上の誤差は発生しない‥‥という事です。
*誤差の累積を、故意に発生させる場合は別ですヨ。

また、floorとroundは上手く使いわけてこそ‥‥です。floorばかり使っていると、思わぬ結果が出る事がありますネ。


また、数字の表記を2桁で揃えたい、4桁で揃えたい‥‥という時には、

var ketaNumber=Math.pow(10,桁数);

で、必要な桁数の位が繰り上がった数を用意しておき、

String(ketaNumber+任意の数).slice(1));

‥‥にすれば簡単にゼロで埋めた文字列を生成できます。つまり、0025が欲しい場合は、

String(10000+25).slice(1);

‥‥で済みます。わざわざIF文を使わずとも、1行でおさまります。

if num<10 {"0"+num} みたいなのは、2桁だとさほど苦ではないですが、例えば4桁の場合は、IF分岐がめんどくさい事になりますネ。for構文でゼロを追加するのも、なんだか大袈裟過ぎます。

私は今まで散々、桁数を揃えた番号と付き合ってきたのですが、何だかんだ言って、上記のプリミティブなやり方(10のべき算を一時的に足す)が一番シンプルで使い易く感じています。項目の数に応じて、動的に桁数を変える事だって、簡単にできますしネ。


*「var」も「;」も、エクスプレッションでは無くても見逃してくれるんですが、何かね、不安で。 ‥‥妙な省略癖がつくのもイヤだし。

スクリプト、凡ミスです

前に書いたスクリプトの例文で、8フレームのオフセットで、

thisComp.duration-8;

とか書いてましたけど、これじゃあ、8秒引いてしまいますがな。。。すみません。

正しくは、

thisComp.duration-(framesToTime(8));

ですネ。

仕事してたら、ふと気付きました。

当該の記事は訂正して、順番を上げときました。

オリジナルのFunction集

スクリプトやプログラムを覚えたての頃(1996年頃)は、漠然とコードを書いていたのですが、それではあまりにも効率が悪い事に気がつき、定型の処理をモジュール化して共用するようになりました。誰に教えられたのでもなく、自然と。

オブジェクト指向のプログラムを覚えたのは、自己流のモジュールを作り始めて、さらに効率的な方法を求めていた頃でした。2000年前後の頃に、REALbasicというのがMacソフトウェアで出て、それで自作のクラスの作り方・使い方やプロトタイプ的な考え方を習得しました。オブジェクト指向って、何たるかが理解できるまでは悶々としますが、理屈がふと解る境界があって、それを超えると、反ってエスカレートしてオブジェクト的な考えで指向するようになります。‥‥まあ、それは私の場合、ですが。

でも、オブジェクト指向を持ち出さなくても、効率的に自作ソフトは作れます。時と場所で使い分ければ良いんですネ。

効率的に作る方法は、何よりも「使い回しの効くFunction」を作る貯める事です。例えば、連番の番号抜けをチェックするルーチンを、その度に書いていたら、まず時間を浪費してしまいますし、改良を加えようとすると、複数の自作ソフトウェアに埋め込まれたそのルーチンを全部直して回るハメになります。

MacOSXの場合は「Application Support」と言う共有ライブラリを置いておく場所も用意されてますから、そこに自作のFunction集を置いて、ソフトウェア上ではそのFunctionを呼び出すようにします。もしFunctionに不具合があった場合は修正すれば、すべてのソフトウェアに反映されます。

まあ、スタンドアロンのソフトウェアを作りたいのなら別なのですが、アニメーション制作で用いる様々なツールで共有するFunctionライブラリは、作り貯めて、活用できるよう整備しておくと、開発の面でとても楽になります。

塵も積もれば‥‥でしょうが、結構な数のFunction、サブルーチンを書き貯めました。ファイル名を分析する、撮影種別を撮影用語に変換する、番号欠番をリストする、EDLをAfter Effectsのtimeに変換する、数列からタイムリマップキーを生成する、TGAの空セルを生成する、他社の命名規則へ変換するマクロ、虫食いのイメージシーケンスを虫食い連番から生成する‥‥などなど。

Function集が充実してくると、骨組みを作ってFunctionで肉付けするだけで、そこそこの処理ソフトが作れるようになります。その時に足りないものは、ここぞとばかりに書き足せば、Function集はどんどん強力に育ってきます。

やっぱり、コンピュータはプログラムを作れてナンボ、だと思います。うわべで快適を謳うソフトが増えても、底力としてプログラムの知識は「特にコンピュータで四六時中仕事をする人」は必須だと思います。今も昔も変わらずに。

思うに、近年のコンピュータって、使う人間と使われる人間の「貧富の差」がどんどん大きくなっているように思います。iOSなんぞに満足してたら、あかんのです。

コードを書き直し

プロジェクトとコンポジションを自動でビルドする「CBX」というオリジナルソフトウェアがあるのですが、作った当時、After Effectsのスクリプトを探りながら書いたので、今読むと「ありえない」ような書き方が頻発しております。覚えながら作る弊害みたいなもので。

そろそろ、その「CBX」も、書き正すところは正して、開発を一旦終了すべきかと考えております。大量に作画して大量にペイントして‥‥というスタイルのアニメの作り方が、もう私にとってはリアルでは無くなってきた事もあり、「CBX」を使う頻度はどんどん減少するでしょう。しかし、まだ従来撮影様式の要請があるのも事実なので、少ない頻度であっても「レタス素材のコンポジット」を効率良く作業するために、内容をかすかでも記憶している今のうちにコードを読みやすく、刷新しようかと考えています。

‥‥自分で書いたプログラムでも、時が経てばすっかり忘れるものなのです。というか、私の場合は、少なくとも。

「CBX」は通常のアニメ撮影内容〜セルと背景、全セル、BGオンリーなど、旧来からのアニメ撮影のスタンダードを網羅するため、非常に面倒で煩雑なルーチンが内蔵されております。さらに、必要に応じて「増築」したゆえに、ラビリンスと化しており、作った本人でも早々に迷子になります。困ったもんで。

もしこのまま放置すると、数年後には書いた本人ですら読解に時間のかかるシロモノになってしまいます。

あと、もうちょっとは活躍しそうなツールですし、近々に必要になるので、4月あたりで何とか書き直そうかと思っています。あまり、奇麗にしようと欲張らずに。

目下の標準仕様

色々と映像技法を試すにつれ、2013年現在のコンシューマ向け機材で、作業運用上の限界かなと思うのは、大体4K/60fpsくらいかな‥‥と実感できるようになりました。これは2Dアニメーション作品の場合、ですが。

2Dアニメーション作品とは、現在業界標準のレタス仕上げ素材を撮影する方法とは全く異質なもので、アニメーターやコンポジット作業者が、あらゆるツールを駆使して絵を動かして映像を作るスタイルの作品です。‥‥ゆえに、現在のコンピュータ処理能力だと、4k/60fpsくらいが打ち止めでしょうか。レタス仕上げ方式のアニメ作品とは、段違いに処理能力が要求されます。

解る人には解る感じ‥‥で例えると、今のMac ProやCore i7 Macが、PowerMac8600かG3/233MHzくらいに感じる速度‥‥ですかネ。

しかし、4K/60fpsとなると、国立の技術研究所とか家電メーカーの開発部とかと連携しないと、足場がおぼつかないでしょうネ。テレビは存在しても、再生機器やメディアの問題とか、色々ありますし。

ただまあ、私としては、目下の標準仕様は、4K/60fpsとターゲットを定めて研究しています。これは最近出た4Kテレビ(2160P)に呼応しているのではなくて、単に次のステップへの中間地点です。次のステップ、これはすなわち、8K/120fpsなんですが、それはいくらなんでも、運用が追いつきません。

なぜ、4K/60fpsを目下の標準とするか‥‥ですが、「絵が動いて映像作品となる」というアニメーションの本質を再定義するには、このくらいのスペックが必要だと考えるからです。みんな、アニメとは、「塗りやすい略画が、1秒間8枚、もしくは1秒間12枚で動くもの」と思っているでしょうが、どうやら、その「概念」とは全く違うタイプのモノが作れる事が解ってきました。

願わくば、早々に、家電の映像再生機器関連が、もう1世代先へ技術更新されれば‥‥と思います。作っても、見せる場所がないのは悲しいですからネ。

ないものねだり

日々、黒鉛と紙と付き合ってて、ステッドラーペンテルの筆記具を愛用しているのですが、全ての用途に対して満足しているわけではありません。

特に、均一な線を描く場面などは、もっと良いものはないかと、考えてしまいます。

ペンのようなトレスブラックを軽い筆圧で描けて、細い線(0.1mmくらい)が筆圧で調整できて、芯は折れにくい‥‥という感じの筆記具。ないものねだりなのは、解ってはいます。今のところ、ステッドラーの0.3mmに2Bの芯というのが、一番ニーズに近いのですが、ちょっと気を緩めるとスキャン後の処理で悪影響の出る線になってしまうので、都合、筆圧が高くなりがちで、正直疲れます。そして、2Bは基本的に折れやすいのが泣き所です。

黒鉛特有の書き味が必要な場合は、全然気にならないのですが、黒白のハッキリした線が必要な場合は、悲観的になるくらい、鉛筆・シャーペンって「適してない」のかも知れない‥‥と考える事があります。

前々から、白黒クッキリ線の場合は、全面的にCOPICのマルチライナーに切り替えても良いかと考えてはいるのですが、無論、消しゴムは使えないですから、厳密な用途の場合(版権イラストなど)は下書き段階でほぼ完璧に仕上げておく必要があります。以前からマルチライナーは使っていますが、鉛筆画をマルチライナーに切り替えるとなると、「運用レベル」での変更が必要となります。

デジタルデータ視点ならば、ソフトウェアのシェイプ(ベクターとかパスとか呼び方は色々)で全部描いてしまうか。やっぱり、ステッドラーの0.3mmを基軸として、シャーペンの芯を総ざらいでテストしてみるか。

悩みどころです。

鉛筆に馴れ親しんで生きてきた慣習が、躊躇を誘います。

ちなみに、用紙も重要な要素です。どんなに黒鉛が真っ黒く紙に定着しても、紙の白色度が低いと、スキャン時にコントラストが稼げません。黄ばんだ紙はNGです。また、パルプの目が粗いと、線がブチブチになるので、平滑度も重要です。私は、坪量の低くて白色度の高い、薄いケント紙を常用しています。

紙のほうは、大体「これが落としどころかな」と思える紙は見つかっています。紙についてはまたいずれ‥‥。


一生のうちに完成できる絵を、できるだけ多くしたい‥‥という欲望ゆえに、どうしても効率的なツールを追い求めてしまいます。線で語る‥‥のは、鉛筆やシャーペンで充分に達成できます。しかし、「クッキリトレス線のデータ入力」というニーズでは、逆に黒鉛の表情が裏目にでます。

ドンシャリカーブのカーボン筆記具がほちい。

NHKスペシャル

ロボット革命もNHKスペシャルでしたが、NHKスペシャルは昔から今まで、楽しみにしている番組です。

戦後50年に合わせて放映された「映像の世紀 第5集 世界は地獄を見た」は何度も見返しましたし、同じ年に放映された「時は流れず〜794通が語る太平洋戦争〜」もよく見返した番組です。「映像の世紀」はDVDが出ていますから入手は比較的楽ですが、「時は流れず」は運悪く8mmビデオに録ってしまったので、もう見れません。

「時は流れず」はNHKが終戦50年を機に、戦時中にやりとりされた手紙を募集して、実際に残された人々に取材する‥‥という内容でした。手紙では槇村大尉の素子ちゃんへの手紙が有名ですが、誰にも公開しないまま、全国に同じような内容の手紙が膨大にあるのだと思います。この番組はその片鱗を紹介した番組でした。

私はNHKスペシャルを結構録りためていましたが、8mmはそうそうにダメになり、VHSも市場から急速に姿を消し、まるで役に立たないライブラリになってしまいました。‥‥なので、数年前にドカンと大量処分してしまいました。自分の頭の中の、記憶にあるから良い‥‥と。

今また、急速に、BDAVの録画ライブラリが増えており、NHKスペシャルやプレミアムアーカイブスのライブラリが増えるばかりです。

しかし、BD。

8mmビデオよりは長持ちして欲しいですが、どうなるかなあ‥‥。

ASIMO

昨日日曜のNHKスペシャルで、ASIMO君がいっぱい登場したのですが、特に走るASIMO君がとてもキュートで、途中からでも録画しておけばよかった‥‥と後悔してたら、

NHK総合(地デジ)
3月21日(木)
午前0:25〜午前1:16
[水曜深夜]

‥‥に再放送するようで、良かったです。

画像認識、音声認識、触感の認識などが、性能向上しており、指の内側のセンサーで固いものと柔らかいものを判別して力加減をする‥‥なんて、凄いですネ。

100年後の世界はどうなっているのか、私は死んでいるので見れなくて悔しいですが、もしかしたら、江戸時代の人間が旅客機なんてとても想像できなかったように、私らの想像の及ばない世界が展開されているかも知れませんね。



ロボット

日曜のNHKスペシャルで、ロボット開発のドキュメンタリーをやってました。おなじみホンダのASIMOや例の米軍の軍事ロボットを紹介しつつ、事故現場で自立的に行動できる「ヒューマノイド」(人型のロボット)の開発の様子を伝えていました。震災以降、米国で加速した「ヒューマノイド」開発は、国防総省が絡んでいるだけに、興味深い内容でした。

日本の生産現場でも汎用性の高いロボットが徐々に導入されているようで、番組中で「未来、人間の役割はどうなるのか」と言った話題にも触れていました。ある程度のルーチンワークなら、汎用ロボットが学習する事でどんどんこなせるようになる‥‥と。19世紀は産業革命、20世紀はコンピュータ革命、21世紀はロボット革命だ‥‥とも。

ロボット‥‥というほど高度ではありませんが、過去、私もアニメの撮影行程を作業するようになって、自動処理の有効活用を考えるようになりました。明らかに同じ事の繰り返しが撮影行程には存在し、全自動は無理でも、節目でいくらでも自動処理の導入は可能だと感じました。

‥‥で、自身で開発して実際に導入したのが、atDBとxtoolsです。作業の進行状況を「わざわざ人間が記録する」のではなくて、コンピュータを作業で用いる行為が作業記録を兼ねる‥‥というのがatDB、撮影・コンポジット作業の毎度決まりきった煩わしい作業を自動化するのがxtools‥‥で、導入の効果は絶大でした。「人間は人間でしかできない事をすべき」という、極めて基本的なスタンスを実現するための、土台となりました。

セルやBGのファイルをシート通りにAfter Effectsプロジェクトを構成する‥‥なんていう誰がやっても同じレベルの作業を、大切な人生の時間を割いてすべき事ではない‥‥と強く感じたからこそ、そのようなツールを作ったのです。

タイムシート書式がちゃんと規定され、データ化されオンラインにのれば、コンポジットのかなりの部分は自動化できるでしょう。実は過去、その段階まで進もうかと考えた事がありました。しかし、フィルムの因習が根強く残るアニメ業界フローでは基盤整備に時間がかかると思いましたし、何よりも楽な方にどんどん流れていくルーズな体質では、構築した後ですぐに形崩れが始まると、容易に予感できたので、業界フローに関する計画は放棄しました。

既存の業界フローが、時代の進化・新しい技術に取り残されていく事は、随分昔から肌身で実感できていました。実際に業界フローのほとんどは、HDの解像度すらアップコンでしのいでいるような状態です。そして何よりも、今の業界フローをHDや4Kに対応させたところで、トレス線がきれいになった‥‥程度の効果しか表れません。つまり、もう基盤の設計思想自体が、新しい映像技術に不適応なほど、旧いのです。業界フローはフィルム時代の品質には最適でしたが、近い未来の映像フォーマットにおいては、フォーマットの持つ高いスペックを活かしきれません。

なので、発想をゼロ地点まで戻して、因習そのものが存在しないところから、アニメーション作品の作り方を思考し始めたのです。原画とか動画とか、フィルムとか、ノスタルジーとか、過去の一切、何もかもを白紙に戻して、「絵が演技してストーリーを語る作品」とはどういう事かを、新しく定義するところから始めたのです。過去の段取りを全てまっさらにしても、「話を作る」「絵を作る」「動かす」能力が必要なのは何も変わりません。

実はそうやって、旧時代の慣習や段取りを全て放棄して、物事に取り組むと、「ロボットに人間の仕事が奪われてしまう」なんていう考え自体が消え失せます。むしろ、真逆で「人間でしかできない仕事、一生の限られた時間」を実感できて、「じゃあ、ロボットにはどれだけ一杯働いてもらおうか」という意識が芽生えます。代用という考えではなく、活力の1要素として、ロボット・コンピューターを、当初から意識するからでしょうネ。‥‥まあ、私の言うロボットは、世に言うロボットなんてレベルではなくて、単にコンピュータベースの作業支援システムですけども。

人の仕事、人間の存在意義って、すご〜く解りやすく言えば、自動処理ではできない事をする‥‥のが、基本ですネ。

最近、Windows環境のAfter Effectsで、STSというタイムシート関連のソフトウェアをちょっとイジって垣間みる機会があったのですが、生成したキーフームのコピーペーストを手作業で1レイヤーずつ処理しているのを見て、愕然としました。

これ以上は申しますまい。‥‥とにかく、ロボットや自動処理で自分の仕事がなくなる‥‥と感じるのは、結構ヤバい兆候だとは思います。逆に、ロボットが自分と同じ記憶と身体能力を持つのならまだしも、そうでないのなら、自分の創作行為にとって変わるのは不可能だ‥‥と感じるのならOK。

NHKスペシャルの話に戻ると、ASIMOは5つのマイクで3人同時に発する言葉を判別するようです。画像認識の技術も向上し、入力された情報を処理する人工知能などの技術もどんどん発達しているようです。‥‥ですから、ロボットは定型のプリミティブな動作・反応しかできない‥‥という昔の認識は旧くなっているようです。

例えば、「美しい」とはどのような状態を指すのか‥‥とかも、超高速データベースと処理プログラムにより「一般論」程度の人工知能で判断できるようになるかも知れませんネ。

しかし‥‥、番組中、ルームランナーみたいなので一生懸命走るASIMOは、めっちゃ可愛かったなあ。



分数コード

坂本龍一さん(私はアホアホブラザーの印象が強くて、どうにも笑けてしまうのですが‥‥)の「エナジーフロー」という奇麗な曲があるのですが、その楽譜を眺めていてコード表記をふと見たら、分数コードが多用されており、不思議に思いました。この楽曲は、分数コードというよりは、オンベースの展開の楽曲だと聴いてて感じていたからです。

「この分数コードの表記は、オンベースと同義で扱っているのかも。‥‥それで可なのか?」と思い、ちょっと気になって調べてみたら、結構、分数コードそれ自体に解釈の違いがあるようで、余計混乱してしまいました。

私は、「オンベース」と「分数」を「分別して扱う派」で、ずっとやってきました。「F on G」と「F/G」は似てるけど根本的には違う‥‥という考え方です。

でもネットでは結構「2つは同じ」と解説しているところがあって、「え?そうなの?」と不安になりました。

オンベースはその名の通り、ベース音を指定音で演奏し、その上に和音を乗せる‥‥というものです。

分数コードは、分母の示す調性のフレーズ(多くの場合)に、分子の示す和音(分散和音的なフレーズも含む)を乗せる‥‥というものです。

Wikipediaを読むと、分数コードはいくつも異なった使い方が存在するらしく、‥‥なるほど、アニメ業界と似たようなもんで、用語に関しては「ほぼ似た感じなら、結果オーライ」なのネ。

ちなみに、私の解釈している分数コードは、Wikipediaによると、

2・真の分数コード
  • 分母と分子を調性から切り離してサウンド作りをするための手法を表現するための分数コード(分母はベース音、分子はメイジャー・トライアドまたはマイナー・トライアド)

「調性から切り離して」という言い方に何か釈然としないものを感じますが(調性から切り離すまでにエグいのはあまり無いもんネ)、まあ、ほぼその感じです。

でも、やっぱり自分が解釈しているのとは微妙に異なる気がします。分母はベース‥‥というのがひっかかります。例えば、Amのフレーズを、ベースおよびギターカッティングで演奏し続け、その上にエレピで、Am, G, Fのようなコードを被せたアレンジの場合、表記はAm, G/A, F/A なのだろうか。実質的には「G/Am」「F/Am」なんですけども。

つーか、あれだ‥‥。コード表記に高望みし過ぎてるんだろうな、私。

コード表記は楽曲の片鱗を伝える、あくまで簡易表記で、実際は五線譜、またはセッション本番で形成するべきなんでしょうネ。実際、コード表記では、厳密なコードのフォーム(例えば88鍵での和音の構成)まで伝えきれないですもんネ。


‥‥そういえば、前のブログを書いた時、コードを拾う際に久々にミニキーボードをいじりましたが、指がナマっててもどかしかったです。楽器みたいに、指を動かすものは、定期的にやらないとダメですネ。



坂本龍一さんのエナジーフローです。私はメジューエワさんの演奏しか知らなかったので、このYouTubeの音源(本人演奏?)は新鮮な感じでした。


calendar

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM