批評

「モノ」を実際に作りだす人間にとって、「批評」という行為は「何か釈然としない」、キモチがひっかかる行為です。それが一言だけのツイートであったとしても。

 

まあ、なぜ、ひっかかるか‥‥は、モノ作りの人間なら必ず覚悟すべき言葉〜「そう思うのなら、自分で作ればいい」という言葉〜が必ず返ってくるからだと、わかっているからです。「他者の成果物を批評する前に、自分自身を見つめろ」‥‥という暗黙の常識が、モノを生み出す人間には浸透しているのです。プロとして対価を得る人間は特に‥‥です。

 

ギタリストの場合

「アイツはギターが下手クソだ」

→「じゃあ、オマエはアイツより上手く弾けるのか?」

 

脚本家の場合

「この脚本はここがイマイチ」

→「じゃあ、オマエはその脚本より良いものが書けるのか?」

 

アニメーターの場合

「あいつは絵が下手だし動きも悪い」

→「じゃあ、オマエはアイツより絵が上手で動きも上手いのか?」

 

‥‥という流れになるのを、同じモノ作りの人間だったら、普通に避けます。モノを作り上げる難しさ、自分の仕事を全うする難しさを知っている人は、状況がよく判りもしない同業の他者を安易に批評する気にならないのです。「大変そうだな‥‥」と思うことはあっても‥‥です。

 

他者の「ウマいだ、ヘタだ」を批評するのなら、自分はかなり「上手い」と自己評価できて相当な覚悟ができている必要がある‥‥と、「同業者」なら思うのです。

 

 

でも、批評という行為に対して、それ以外にも「釈然」としないキモチが残ります。なんか、モヤモヤした気分といいますか。

 

それは、すなわち‥‥

 

 

‥‥のようなこと‥‥、なんでしょうね。

 

「批評されているものよりも、批評している者のほうが偉く見える」というのは、なんだか「モヤモヤ」を指してそのものズバリですネ。人は、往々にして、「分析することで、モノゴトを理解したと錯覚する」イキモノのようにも思いますし。

 

猫の行動を分析できても、猫を理解したことにはなるまい? 分析して「知った気になっても」、見落としや分析不足はやまほどあるわけです。

 

昔の歌で「包帯のような嘘を見破ることで 学者は世間を見たような気になる」‥‥みたいな節も思い出します。

 

その後に続く、「批評することはきわめて容易なので」〜「他のいかなる方法によっても人の興味を引くことができない凡庸な輩の避難所となる」‥‥という一節は、相当キツいことが書かれております。

 

 

でも、批評という行為をして、「凡庸な輩の避難所」と言い切ってしまうのも、極論過ぎるな‥‥と思っています。

 

私は20代前半の頃にニーチェ著作の文庫本を読んで、大いに共感したことがありますが、その内容は批評的・批判的な側面を多く含んでいました。以前の価値観・倫理観に対して、容赦のない批評を展開したことが、当時20代の私のココロに響いたのです。つまり、内容が批評的な性質を多く含んでいても、筆者の尋常ならぬ洞察力と分析力が伴って文体を為せば、それは著作=モノ作りと呼ぶに等しく、受け手の心を揺さぶる‥‥と実感します。

 

ただ、作品制作者がツイッターで気軽に、自分の能力も覚悟も棚上げして、同業者の作品表現をあれこれ言うのは、批評というよりは軽口であって、少々軽率かなとは思います。やはり、作品作りだけでなく、批評にもクオリティは存在するのでしょうネ。

 

 

 

 


ネット

昨日今日と休日に、昔のサイトコンテンツを整理していました。今や、自宅でインターネットサーバとか言ってる時代でもないですし、SSLはもはや個人・小規模サイトでも必須の時代にもなりましたし、激安レンタルサーバも競争や淘汰に耐えきれなくなって大幅値上げするサービスも多いし‥‥で、ざざっと整理しました。

 

まあ、今は、よほど腕に自信でもなければ、自宅のマシンを不特定外部に公開するのは避けたほうが良い時代です。10年前とは状況が違います。クラウドサービスやレンタルサーバの充実もあいまって、わざわざ自宅のマシンを危険に晒すことはなかろう。私はもう数年前から外部から自宅へアクセスを閉じていますから、私的には「ダイナミックDNS」のサービスも不要になっております。

 

昔は「ライトプラン」なら無料だったダイナミックDNSサービスも、年間15ドル、40ドル‥‥と値上げを重ねて、今年は50ドルとなり、「もう潮時かな」と判断しました。全く業界とは関係のない友人のWebを10年以上前に立ち上げて、その頃のドメインがダイナミックDNSのドメインゆえに、ずっと維持してきましたが、方針を変えて、統合管理によるレンタルサーバ&独自ドメイン&独自SSLに切り替えることにしました。

*独自SSLとは、レンタルサーバの特定ドメインに適用して証明書を共有するSSLではなく、ユーザ任意の独自ドメインに適用できるSSLを指す‥‥ようです。

 

ダイナミックDNSのドメインに、独自ドメイン&SSLのURLへとWebHop(転送ですね)を設定して、1年の猶予ののち、ダイナミックDNSは使用を終了しようと思います。

 

ただ眺めているだけのWebコンテンツでも、今や「非SSL接続」は敬遠される流れとなり、Chromeではアドレス欄に常時、httpかhttpsかの区別が表示されるようになりました。私のWebは、別にパスワードもクレカの入力も要求しない、平文の通信(データをそのまま送受する)で問題のない「見るだけ」のWebなので、ぶっちゃけ、「SSL必須」の流れは面倒なのです‥‥‥が、まあ、特に抗う理由もないので、対応しておきました。通信のほとんど全てを暗号化しよう!‥‥という流れなんでしょうネ。

 

 

*最近のChromeではこうしたキャプションと共に、URLが表示されるようになった‥‥とのことです。独自ドメインに対する独自SSLを無料で適用できるレンタルサーバも存在するので、今後の運用はその辺の付加サービスも含めて業者を選ぶ必要がありますネ。

 

 

‥‥ちなみに‥‥、このブログはサービス元のJUGEMの方針で、まだSSLに対応できていません。

 

https://support.jugem.jp/hc/ja/articles/115011932247--常時SSL-https-Googleより-保護されていません-という旨の警告が届きました-

 

書かれていることはごもっとも。‥‥SSLが必要がないのに、「安心をアピールするためだけ」にhttpsを使うのって、まあ、「道理が判る人なら拒否したい」ですもんネ。公的な証明書(サーバサイドで作る俺的証明書ではない、公的機関の発行する証明書)だって、タダじゃないですし。

 

SSL是非の話は、成り行きを見守るしかないスね。私はサーバを管理するプロではないので、その辺の「現場の雰囲気や論調」はよくわからないのです。

 

一方、レンタルサーバ業も最近は苦しい状況も増えてるんでしょうかね。私はレンタルサーバを2社と契約していたのですが、そのうちの1社が月額を6倍に値上げしたので(と言っても個人で支払える額ではありますが)、その1社との契約を終了することにしました。固定IPでダイナミックDNSと連携していたサーバですが、方針を変えたので、必要性も薄くなったのです。

 

ダイナミックDNSの終焉、SSL必須の風潮、安さを維持できなければ契約終了のレンタルサーバ‥‥と、私自身の事情が主ではありますが、じみじみ時代の流れを感じます。

 

 

 

ゆくゆくは、アニメ制作に関する新しい技術ムーブメントを、何かの形で「然るべき人々」とWebで共有することも考えています。今更‥‥ですが、SSLによるWordPressを、ちゃんと計画した上で運用すれば有用かも‥‥と考え始めています。野放図に公開すると確実に「新技術を安売り用途に貶める」人々も現れるので、その辺の「セキュリティ」は考えなければなりませんが。

 

2020年代を前にして、現場用途の技術解説書をざわざわ紙に印刷する必要もないでしょうし、制作に必要な全ての情報はパソコンやタブレットPCに集約することを考えれば、アニメ技術の「デベロッパーズサイト」なるものを業界の垣根を超えて形成することも、すぐ先の未来には必要になるでしょう。

 

そのためには、昔の「ホームページ」と呼ばれていたインターネットの常識から知識を更新し、日々の運用でちょっとずつでも試してみるのが良いと思っています。

 

個人でも、独自SSLによるhttpsで始まるWebアドレス、独自ドメイン、HTML5以降のWebコンテンツ作り、CSSやPHPやPythonなどの積極的な活用‥‥など、できることは結構あります。

 

まあ、映像作りで毎日忙しいのは皆同じですが、その忙しい中でさらに何ができて、未来への橋頭堡として何を確立できるか‥‥も、大切なことですネ。

 

私はとりあえず、PythonとCSSを裏で進めようと思ってます。CSSありきの脳に、未だに移行できていない感があるので。

 

‥‥<center>タグは使えなくなったのか?‥‥とか言ってる時期は、もう、とうに過ぎていますもんネ‥‥。

 

 

 

 


橘花

今年も終戦の日が近づいてきましたが、そんなシーズンに思い出すのが、日本人の飛行機好きなら誰もが知っている、終戦間際のジェット機、「橘花」。

 

 

Wikipediaには、こうあります。

 

1944年(昭和19年)8月、日本は高高度を飛行するための過給機付き高性能レシプロエンジンの開発にも行き詰まり、原油生産地のマレー半島と日本本土間の制海権の喪失から燃料事情も悪化していた。海軍は低質燃料、低質潤滑油でも稼動し、レシプロエンジンに比較し構成部品が少なく簡易で高性能なジェットエンジン(噴進機関、タービンロケット)を装備した陸上攻撃機を「皇国二号兵器」と仮称して企図し、同25日、中島飛行機に開発指示を出した。

 

 

44年の8月か。遅い。終戦の1年前にアクションして間に合うわけがないヨ。

 

橘花のお手本となった「Me262」は、41年には機体が完成しており、44年に実戦配備。

 

 

 

Me262の顛末は、戦後の主力となるジェット機の先駆け的存在であったものの、運用上の問題もあって、戦局に対する絶大な効果は発揮しないままドイツ敗戦となりました。

 

ドイツの場合は、先見的な技術を推し進めながらも、総合的な戦略で敗れ、日本の場合は後手に回った技術に甘んじたまま、戦略においても敗れ‥‥と、同じ敗戦国でも状況は大きく異なります。

 

 

技術はさ‥‥、「もうダメだ。あとがない。何か特効薬を!」みたいな段階で開発スタートしたんじゃ、遅すぎるんですよネ。

 

何度も書くけど、起死回生の戦局挽回兵器、決戦兵器なんて、負ける寸前の人間が考えることであって、「決戦」=「戦いを決める」という思想自体が、追い詰められた人間たちの産物であることに当事者こそ気がつかないのです。‥‥いや、気がついていても、「決戦を仕掛ければ、勝てる」と思い込んで自己洗脳するしか、道がないのかも知れません。

 

「戦い」なんて、「決戦」1つで簡単にカタがつく話じゃないのは、わかってるじゃん?

 

いくつもの作戦を地道に仕掛けて実行し、大攻勢の前段階を形成するのが、戦いというもの‥‥だと、私は多くの歴史から学びました。勝利条件の状況をいくつも積み重ねて、満を持して大攻勢を仕掛ける時点で、勝利への道筋はほぼ確定していることを、歴史は証明しています。一方で、寄せ集めの戦力でその場限りの大攻勢を仕掛けても、一時的な勝利は得られてもその後が続かないのも、歴史は証明しています。

 

 

 

戦史を読むたびに、いつも考え込むのが‥‥

 

新兵器の開発は、いつからスタートすべきだったのか

 

‥‥です。

 

日本が終戦を迎えた夏の日に思うことは、「敗戦間際では遅い」ということだけ‥‥は、わかっています。

 

 

 

とはいえ、アニメ業界は70数年前の状況を、奇妙にも全く似た構造をトレースしていますよネ。上掲の一節の‥‥

 

過給機付き高性能レシプロエンジンの開発にも行き詰まり、

 

‥‥は、レシプロエンジンの限界を心のどこかで薄々気づいていながら、終戦の1年前まで「新しいエンジン」の航空機開発に着手せず、固まった思考で重い腰を上げようとしなかった「日本人気質」そのものです。その気質は、全くそのまま、孫の代、ひ孫の代まで、脈々と受け継がれているのを、ひしひしと感じます。

 

上層部だけの問題ではなく、日本のパイロットたちが、そもそも「格闘戦至上」の考えを変えられず、新人パイロットの育成にも旧来思考が伝達され、日本国民も「堪えて忍べば、いつか勝てる」と思い込み、日本人一丸となって、最後は「one-way suicide mission」へ突き進んだわけです。

 

アニメ業界の「レシプロ」エンジンたる手描きで動かす技術。何千何万枚も描く技術。その技術を「高高度化」するために「デジタル」によって「過給器」を付加しても、果たして戦局を挽回するに至ると思いますか?

 

過給器によって強制的に空気を送り込んでレシプロエンジンの燃焼力をアップしたところで、プロペラブレードの限界に達していれば、それ以上の性能向上は望めません。‥‥同じように、どんなに「デジタル」を導入しても、何千何万と描き続ける技術そのままでは、限界は見えているでしょう。

 

 

なぜ、同じことを繰り返すのかな。

 

多くの人は、平和な日々がデフォルトで、日頃から「戦史」なんて読まないし研究もしないがゆえに、無意識に知らず知らずに、同じ道をトレースしてしまうのかな。

 

最近「ダス・ライヒ」のドキュメンタリーを見て、特に「オラドゥール」村の事件には血が凍る思いがしました。でも、そうした過去の事実の歴史を知らずして、平和を所与とするばかりでは、違う場面で同じことを繰り返すばかりです。

 

「橘花」や「火龍」がダメダメなまでに間に合わなかった歴史上の事実を思えば、アニメ制作現場での制作を維持しつつ、一方で何をバックグラウンドで進めるべきかは、もはや明白でしょう。

 

 


不都合な現実

未来に向けて新しく機材をリプレースして、制作中の映像から過去作品の映像まで、日々色々と見るようになると、映像だけでなく、アニメの旧来技術の「不都合な現実」も見えてきます。

 

別にね‥‥、毎回毎回、旧来技術のネガティブキャンペーンを張ろうというのではないのです。四方八方から、旧来アニメ技術の弱点を突くような状況に実際に触れ、耳にする話もアニメ業界標準技術にとって不都合な内容が多いのを、ここで書き綴っているに過ぎません。

 

私は小さい頃からオバQのQちゃんが大好きですし、ヤマトも999も好き、カリ城うる星のBDも好き過ぎて、セリフを暗記しているほどです。アニメをこき下ろしたいなんて、根本的に思ってはいません。

 

しかし、現実は不都合なことばかり。民生の4Kテレビは、24p3コマ打ちのアニメにとって「余計、技術の古さが強調される」モーション補完技術がデフォルトでONですし、詳細化・高品質化する世間の基準と裏腹に、映像技術内容も作業労働内容も前近代的なものへと陥る一方です。

 

ぶっちゃけ、昔から今に続くアニメ作品の映像を、現在最新の4Kテレビで「自然」で「あるべき内容」で見るためには、色々な高度な機能を軒並みOFFにする必要があります。ソニーブラビアの「コマ数補完技術」などテレビの「倍速補完技術」はその筆頭ですが、そうした「売りの機能」を、旧来アニメではOFFにしなければ正常な再生ができません。

 

何がマズいって、アニメの2コマうち・3コマうちシートの動きはそのままで、24コマフルモーション部分だけフレーム補完技術が適用されるので、そりゃあもう、違和感たっぷりで「制作者側の意図しない」結果となります。PANのカメラワークだけ120fpsでセル部分は8fps‥‥なんていう恐ろしいほどの落差を、テレビに自動で生成され映し出されてしまいます。皮肉な話ですが、最新のテレビの補完技術によって、アニメ技術の古い部分が「さらしもの」になってしまうわけです。

 

で、たたみかけるように、旧来アニメにとって不都合なのは、その「アニメにとって違和感たっぷり」な機能設定が「工場出荷時のデフォルト」だということです。一般的な消費者が、果たして、テレビ設定メニューの深い階層に潜って「機能をわざわざOFF」にするのか、よく考えてみましょう。

 

 

 

さて‥‥。

 

こうした不都合な現実がどんどん迫ってくる、すぐ先の未来において、アニメ業界関係者は‥‥

 

新しい技術などけしからん。全くもって不要の長物だ。

 

世間がアニメ業界に合わせろ。世界の技術がアニメ業界の事情に合わせろ。

 

‥‥とでも言うのでしょうか。

 

まあ、そんな人はいまい。

 

明らかにアニメ業界の技術がどんどん旧式化していくのを、なすがままに放置している業界当事者側が「分が悪い」でしょう。進化する世界的規模の映像技術に対して、どんどん「アウェー」になっていきます。

 

 

 

今、制作本数が多いのは、未来への何の担保にもなり得ません。いつか減少に転じ、あれよあれよと言う間に新興勢力に制作が移り変わり、「昔は作りきれないほどのアニメの本数が溢れていたんだよ」と懐かしい想い出話になることだってありましょう。どんなに多くの業界関係者の生活がかかっていようと、必要とされなくなった時点で無残にバッサリ切られます。

 

昔ね‥‥。「合作アニメ」というのがあったんですが、あれもバッサリ無くなりましたもんネ。今思うと「特需」だったんだな‥‥と思います。「合作アニメ」を主軸にしていた会社が、「合作アニメの特需終了」とともに国内テレビアニメに転身を図るも、数年で倒れる‥‥というのを見たことがあります。

 

あくまで私の考えや実感‥‥ではありますが、未来への担保とは、「未来の技術とともに歩むこと」ただそれだけです。

 

どんな昔話も武勇伝も、未来への担保にはならず、昔のやりかたに固執することは、未来に見捨てられ置き去りにされる運命を好んで選択するようなもの‥‥と、私は思います。

 

明確な意志と戦略があって昔の方法を選択しているのなら勝機もありましょう。しかし、「それしか方法がない」という理由だけだと、未来は相当危ないと感じます。

 

 

 

現在私らが進める技術は、フルモーションが基本で、そこにストップモーションを表現として意図的に加える手法です。ゆえに、どんなにテレビがフレーム補完をしてくれても、全然OKオーライ。むしろ、補完した映像を楽しみたいとすら思います。エコノミーな理由で8〜12fpsに動きを抑える必要など全くないのが、新しい手描きとコンピュータ共存のアニメの技術です。

 

4Kも、HDRも、そして24〜60pが120pに補完されるのも、全く問題なし。だって、手描きならではのキャラを、未来とともに歩ませようと、本気で取り組んでいるのですから。

 

 

 

私がかつて少年時代に熱中したアニメの輝きは、まるで失せることはありません。むしろ、新しい時代の中で、輝きをいちだんと増すほどです。

 

でも、その昔つくられたアニメの技術にすがりついて未来も生きるのは、限界アリアリです。不都合な現実だけが突きつけられましょう。

 

アニメ現場が培ってきた技術をこき下ろしたいのではなく、現在の現実を純粋にシンプルに見定めるべき‥‥と思うだけなのです。タイムシートで2コマ3コマのシートを打ち続ける限り、不都合な現実からは脱出できないです。

 

でもまあ‥‥何を言っても、何を考えても、多かれ少なかれ、何らかの「淘汰」は生じるだろうなあ‥‥。本人たちが行動を開始しない限りは‥‥。

 

 

 


ESTKのスクリプトをAppleScriptに埋め込む

前々回のブログで、せっかく、それなりに高速処理のリネームスクリプトができたので、ESTKエディタからの実行だけでなく、AppleScriptでGUIをくっつけて、気軽にドラッグ&ドロップでも処理できるようにしました。

 

アプレットでもドロップレットでも動作するように、「on open」と「on run」を併用しています。

 

macOSのアプリケーションフォルダにある「スクリプトエディタ」を起動して、おもむろにAppleScriptとESTKの合体コードを作ります。

 

 

property defaultItem : false

 

on open theItems

    my main(theItems)

end open

 

on run

    tell application "Finder" to if defaultItem is false or not (defaultItem exists) then set defaultItem to home as alias

    set res to choose folder with prompt "処理するフォルダを選択してください." default location defaultItem with multiple selections allowed

    tell application "Finder" to set defaultItem to (parent of (item 1 of res)) as alias

    my main(res)

end run

 

to main(_folders)

    set errorText to {"フォルダ指定が不正です", "フォルダが空です"}

    set errorLog to ""

    repeat with _folder in _folders

        set res to my runAdobeScript(_folder as Unicode text)

        activate

        if res as integer > 0 then

            tell application "Finder" to set folderName to name of _folder

            set errorLog to errorLog & folderName & tab & res & tab & (item (res as integer) of errorText) & return

        end if

    end repeat

    activate

    if errorLog is "" then

        display dialog "処理が正常に終了しました" with icon 1

    else

        display dialog "エラーが発生しました

下記のエラーログを確認してください" with icon caution default answer errorLog

    end if

end main

 

to runAdobeScript(folder_path)

    tell application "Adobe After Effects CC 2018"

        DoScript "app.exitCode=0;

_1801_RENAME_RE=new RegExp('[_-]*[0-9]+¥¥.[A-Za-z0-9]{2,}');

app.exitCode=main();

 

function main(){

    var theFolder=new Folder('" & folder_path & "');

    if(!theFolder){return 1;}

    var theFiles=theFolder.getFiles();

    if(theFiles.length<1){return 2;}

    for(var i=0;i<theFiles.length;i++){

        var reMatch=theFiles[i].name.match(_1801_RENAME_RE);

        if(reMatch&&theFiles[i].name.match(/^[A-Za-z0-9]/)){

            theFiles[i].rename(theFolder.name+String(reMatch));

        }

    }

    return 0;

}"

    end tell

end runAdobeScript

*前回のバックスラッシュの文字化けを防止するために、ARIELフォントにしてみました。‥‥けど、やっぱり、¥になっちゃった。

*このスクリプトのコードはサンプルです。実際に使用する際は、自己責任でお願いします。

*あ‥‥そういえば、パスに日本語(2バイト文字)が混ざっている場合の処理は盛り込まれていないです。忘れてました。なので、その辺はよしなに。

 

書いたら、アプリケーション形式で保存すれば、ドラッグ&ドロップで動作する、小さなアプリケーションみたいなのが出来上がります。

 

 

 

実際に動作している映像はこちら。毎度のGIFアニメですまんす。

 

 

 

フォルダの名前で、内包するファイルの名前をリネームしている様子が、小さくて見にくいですが、なんとか伝わると思います。

 

合計500ファイル以上あるリネームを瞬時に処理します。フォルダを複数処理すると、ウィンドウの更新に時間がかかるようですが、それでも数秒の処理です。

 

 

‥‥で。

 

ここまで作ってなんですが、「この方法はないな‥‥」と思いました。

 

ESTKのエディタからであれば、実行ボタンで処理を実行できます。しかし、ESTKエディタではなく、AppleScriptからですと、なんらかの「ホストアプリケーション」〜つまり、実行する環境が必要になります。

 

なので、上述のAppleScriptのコード文では「After Effects」を呼び出していますが‥‥

 

そりゃないでしょ。

 

After Effectsの機能は全く使わず、リネームの実行環境としてのみ使うためにAfter Effectsを起動するなんて、スーパーへ買い物に行くのにヘリコプターを飛ばすようなもんです。段取りが大袈裟すぎます。

 

 

まあ、なので、結論としては、

 

ESTKのスクリプトはjsxで保存して、After EffectsやPhotoshopを起動している時に、メニューから呼び出す

 

‥‥のが、使い方の基本ですかね。やっぱり。

 

リネームのため「だけ」に、PhotoshopやAfter Effectsを起動するのは‥‥さすがに、ないわ。

 

 

 

まあでも、せっかく作ったので、なんかあった時に使ってみるかも、です。

 

どうせ、After EffectsやPhotoshopは起動しっぱなしだし。

 

 

 


ネットの物書き

前回、軽く、プログラムとファイル名の関係性(=関係における性質)を、実例を踏まえて書こうと思ったら、どんどん長くなってしまいました。一方で、「文章はできるだけ手短に」という美徳もあり、その代表的存在がツイッターでもあります。

 

でも、ツイッターって、往々にして「帯に短し」で、状況解釈の齟齬を生み出しますよネ。物事の構造を分析しつつ語ろうとする時、ツイッターはあまりにも不向きです。細切れにツイートしたあげくに、あとでわざわざWebで「まとめ」なければ1つの文章になり得ないものすら多いです。

 

ツイッターで文章を細切れにして連続ツイートするのは、そもそも、ツイッターの開発の本意と真逆な行為のようにも思えます。

 

ですから、ツイッターは大きな拡散力が強みであるものの、日々のひとことや見出し程度にしか使えず、状況説明や解説や分析は、ブログなどの長文向きのソリューションが適しています。

 

しかし。

 

ブログも、「日記」「日々の記録=ログ」の性質が強く、ひとまとまりのコラムや論文には向きません。話題が日時で分断され、たとえカテゴリーで分類分けできても、1冊の解説書や技術書の体裁にはなり得ません。

 

となると、昔ながらの「ホームページ」、いわゆるWebサイトで閲覧できる「Webページ」の形態も、まだまだ捨てたものではなく、むしろツイッターのような細切れテキストより俄然有用に活用できることもありましょう。しかし、「何が新着の文献」だか、わざわざ「新着情報」をトップページに設置しないと伝わりにくい最大の欠点があります。

 

告知はツイッター、日々の散文はブログ、テーマに基づく読み物はWebページ‥‥という住み分けが良いと思ってはいます‥‥が、それを全部こなすのは相当面倒です。本業がソレなら頑張るべきですが、本業は別にあって、累積戦略的な目論見でネットの手段を活用する「片手間」の場合は、すべてを快活に運用するのは難しいと思います。

 

個人がどんどんツイッターに流れたのって、「手軽だから」でしょ。

 

手軽じゃないと、片手間にできないから‥‥だと思います。

 

でも、片手間で手軽だと、ある程度は話題になっても、その次の実質的な有効手段まで到達しないことが多いです。「このままじゃいけない」なんて危機感を何千何万ツイートしたところで、アニメ業界は悪化の一途‥‥ですもんネ。

 

ツイートは瞬発的な拡散力はあっても寿命が短い。Webページは寿命が長くても人の目に触れる拡散力が小さい。そして、ツイッター・ブログ・Webページの全てを本業の片手間に維持するのは難しい。

 

う〜ん。

 

どうしたもんかな。

 

 

 

 


プログラムとファイル名

数行のスクリプトであっても、コンピュータプログラムを実際に作って、ファイルやフォルダのリネームを処理するようになると、明確に「それ以前と以後」で当人に変化があらわれます。それは‥‥

 

人間もプログラムも、両方で扱いやすい、ファイル&フォルダの命名規則

 

‥‥を考えるようになるのです。

 

なぜかというと、人間だけでなく、プログラム的に見ても、扱いやすいファイル名のほうが、運用が円滑で効率的になるからです。

 

例えば、

 

a0001.tga

 

‥‥というファイル名があったとします。そしてこの名前の「a」を「b」へと自動処理で変えたいとします。

 

その時、どのようにプログラム上で名前を変更するでしょうか。

 

「a」は1文字だから、2文字目から最後までを抜き出して、先頭に「b」を足せば良い。つまり‥‥

 

"b"+"a0001.tga".substr(1);

 

‥‥とスクリプト文を書けば、結果は‥‥

 

「b0001.tga」

 

‥‥で、めでたし、めでたし。

 

‥‥と考えるのは、よくあることでしょう。

 

しかし、それはハッキリ申しまして「浅知恵」と言わずばなりません。

 

もし、「A上セル」の場合にファイル名が‥‥

 

a-ue0001.tga

 

‥‥だった場合は‥‥

 

"b"+"a-un0001.tga".substr(1);

 

‥‥とスクリプト文が以前と同じままだと、結果は‥‥

 

「b-un0001.tga」

 

‥‥で、全然ダメ。

 

なので、スクリプト文を部分的に書き直して、

 

"b"+"a-un0001.tga".substr(4);

 

‥‥と書けば、「a-ue0001.tga」を「b0001.tga」に変更できる。‥‥めでたし、めでたし‥‥?

 

‥‥のようになりましょう。本当に「めでたし」でしょうか?

 

問題は明らかです。ファイル名の状況によって、毎度毎度、スクリプトのコード文を修正しなければ使えないのです。

 

「大した手間じゃないし」と考える人もいましょうが、スクリプト・プログラムを導入するのは「自動処理で効率化」する目的なのですから、「毎回毎回スクリプトを手動で書き換えていたら、それはもはや自動処理と言えない」わけです。

 

「じゃあ、後ろから数えて、連番と拡張子を抜き出せば良い」と思いますよネ。つまり‥‥

 

"b"+"a-un0001.tga".slice(-8);

 

‥‥と書けば、後ろから8文字以降を抜き出せるので、"b"と合体して‥‥

 

b0001.tga

 

‥‥となり、思った通りの結果を得られる。

 

 

「ならば、ソレでいいじゃん」と思いがちです。でも、よく考えて見れば、連番は必ず4ケタと言い切れるでしょうか? セル素材の場合は2ケタだったり、コンポジット後の連番は5ケタだってあり得ます。連番のケタ数が変われば、その時点でスクリプトは台無しです。

 

"b"+"a-un_01.tga".slice(-8);

結果:「bn_01.tga」〜余計な文字が入り込み、「b_01.tga」に変換できない

 

毎回異なる状況に合わせて、「-8」を「-7」「-9」などその都度スクリプトを書き換えなければ、正常に機能しません。つまり、「何度も使いまわせる自動処理」とはなりません。

 

前から数えようが、後ろから数えようが、文字数に合わせて「1」とか「-8」などの決まった数字を使っている限り、臨機応変に対応する自動処理にはならない‥‥ということです。

 

 

‥‥と書いてて何ですが、正規表現を使えば、かなりの柔軟度でファイル名を修正できます。以下の正規表現でアニメ制作の実質的な連番関連の文字列を抜き出せるからです。

 

new RegExp("[_-]*[0-9]+¥¥.[A-Za-z0-9]{2,}");

 

*「¥」は、実際はバックスラッシュです。このブログのフォントが日本語フォントの影響だか、「¥」に見えてしまうようです。ブログのコード直書き機能でフォントを英語フォントにすれば良いのかな‥‥。

 

上記正規表現ならば、「アンダーバーかハイフンの区切り文字(=無くても可)のあとに、連番と拡張子をもつ、ファイル名」を全て共通のコード内容で処理できます。

 

"a0001.tga"を"b0001.tga"に変えたい

"b"+"a0001.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);

結果:"b0001.tga"

 

 

"a-un_001.tga"を"b_001.tga"に変えたい

"b"+"a-un_001.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);

結果:"b_001.tga"

 

"a-01.tga"を"b-01.tga"に変えたい

"b"+"a-01.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);

結果:"b-01.tga"

 

*注)match()を実行すると、実際は「配列」が返ります。例では「暗黙の型変換」で処理していますが、After Effectsなどで実行する際はString()で囲んで明示的に型変換=キャストしないと、エラー(ゼロによる除算)で構文チェックにひっかかる可能性もあります。

 

ファイル名がセル名と連番が直結していようが、アンダーバー(アンダースコア)やハイフンで区切られていようが、何桁だろうが、全て連番と拡張子以外を名前変更します。実際は「a0001.tga」や「b」は動的に自動入力されますから(ファイルの繰り返し処理や親フォルダ名から取得するなどして)、スクリプトを変更せずに処理できます。

 

 

でも、こうした、まるで呪文のような複雑な正規表現を、アニメ制作上で頻繁に用いるフォルダ名・ファイル名に適用しなければ、名前の変更1つすら自動化できない‥‥なんて、いかにも「運用上の命名規則の甘さ」のリカバーそのものです。

 

運用開始時点で、プログラムにも人間にも判りやすい、汎用性の高い命名規則を制定すれば良いのです。

 

最初っから、先を見越して、決めておけば良いのです。その場その場で場当たり的に対応するのではなく。

 

プログラムが、現場のルーズな運用規則をリカバーするばかりに徹するのではなく、現場のファイル運用もプログラムによる運用効率化に歩み寄るべきです。自動処理、スクリプト処理云々以前に、作業者ごとでまるでバラバラな命名規則で運用し、その都度対応して無用な手間を増やし続けて、口にするのは「手間が多くて大変だ」なんて、窮状の自作自演と言われても何も言い返せません。

 

 

ファイル名・フォルダ名は「その場の雰囲気でつける」ものではありません。たとえ、簡素な命名規則でも、実は根っこに色々な工夫が張り巡らされているものです。

 

そして、その命名規則は、人間だけでなく、プログラム・スクリプトにとっても活用性の豊富な規則であれば、効率化はどんどん加速します。制作進捗状況を記録するデータベースにおいても、円滑に処理できる基盤となるでしょう。

 

例えば、アンダーバーは「カット固有や素材ファイルの要素を区切る文字」と決め、ハイフンは「注釈や派生を付記する文字」と決めれば、人間でもコンピュータでも、ファイル名から解釈は容易です。

 

anim_05_234_mo_t1.mov

意味:作品「anim」の「05」話のカット「234」の出力種別「mo」の「テイク1」のQuickTimeファイル

 

a-ue_0004.psd

意味:「a-ue」素材の「4」つめのPhotoshopファイル

 

b_01.tga

意味:「b」素材の「1」つめのTargaファイル

 

 

こうした、シンプルだけども汎用性や拡張性の高い命名規則を規定しておけば、ファイル名を変更するスクリプトを何度もそのままで流用可能になりますし、データベースなどへの情報記録もフォルダやファイル名から一貫できます。

 

ファイル名やフォルダ名は、制作運用上のメタデータと心得るべきです。

 

そのためには何よりも、ファイル命名規則を規定する人間が、人間主観だけでなく、プログラムの観点からも鑑みることが、必要になります。

 

例えば、After Effectsでテキストレイヤーのエクスプレッションなどで形成する「カットボールド」は、作品・話数・カットの各文字列がアンダーバーでセパレートできれば、何度でも無修正で使いまわせる雛形コンポが作れます。substrで「何文字目」なんて毎回変更せずとも、配列のインデックスでどんな作品でも要素を確定できます。

 

「thisComp.name.split("_")[0];」は作品キーワード(作品略号)

「thisComp.name.split("_")[1];」は話数またはシーン

「thisComp.name.split("_")[2];」はカット番号

 

同じ「数字指定」をしても、セパレートの文字=デリミタをあらかじめ規定しておき、そのデリミタで文字列を「split()」で分解して処理すれば、作品ごとに「数字指定を変更せずとも通用する」のです。

 

 

プログラムを知れば、ファイル命名規則の考え方も変わってくる。

 

ファイル命名規則の考え方が変われば、ファイルやフォルダの運用も変わってくる。

 

ファイルやフォルダの運用が規則的になれば、制作現場のデータ運用も変わってくる。

 

データ運用の無駄を抑制できれば、金銭や時間や人的資源の運用コストも変わってくる。

 

運用コストを改善できれば、現場全体を改善へと導くきっかけとなる。

 

 

‥‥と、以前、「地道に状況をレゴブロックのように積み重ねる」と書いたことは、まさにこうした流れのことを指します。秘密兵器、必勝兵器なんて存在せず、地道で先見性のある「積み重ね」だけが現場を変えていけると、少なくとも私は考えます。

 

改善の積み重ねも無しに、業界外部の門外漢の人々に、いくら「私たちアニメ業界はお金に困っています。増額してください。」なんて訴えたところで、「まず、自分らの基礎的で地道な改善をしてから、訴えてくださいよ」とひと蹴りされておしまいです。効率改善、現場の改善なんて、どんな業種だって重要なテーマです。アニメ業界だけが野放図に状況にひきづられてダダ漏れコスト消費のなすがままで良い‥‥なんて「あるわけがない」のです。

 

構造の改善は全く着手せず、現場作業者の目先の報酬を徐々にカットしていく‥‥なんて、アホ丸出しです。ゴツ石だらけ、ゴミだらけの畑に、いくらタネと水を撒いても、まともな作物なんて育ちません。上の人間も下の人間も、制作構造の「土壌」から改善することを、2020年代の目標にすべきと思います。

 

「コンピュータを毎日使っていながら、コンピュータの基本的かつ絶大な能力を使っていない」なんてことが起こらないよう、プログラムの「ちから」を制作現場にもっと導入すべき‥‥と考えます。

 

 

 

* * * * * * * * *

 

おまけ:正規表現によるフォルダ内リネーム

 

今回のブログ記事用にせっかく「アンダーバーかハイフンで区切られた(区切られていなくても良い)、1桁以上の連番と、ドットと、拡張子」にマッチする正規表現を書いたので、以前ブログで書いた「ESTKからフォルダ内をリネームするスクリプト」を改造して、汎用度を高くしました。

 

以下。

 

_1801_RENAME_RE=new RegExp("[_-]*[0-9]+¥¥.[A-Za-z0-9]{2,}");
alert(main());

 

function main(){
    var theFolder=Folder.selectDialog("フォルダを選択してください");
    if(!theFolder){return "処理をキャンセルしました";}
    var theFiles=theFolder.getFiles();
    if(theFiles.length<1){return "フォルダが空です";}
    for(var i=0;i<theFiles.length;i++){
        var reMatch=theFiles[i].name.match(_1801_RENAME_RE);
        if(reMatch&&theFiles[i].name.match(/^[A-Za-z0-9]/)){
            theFiles[i].rename(theFolder.name+String(reMatch));
        }
    }
    return "処理が正常に終了しました";
}

 

これなら、「a-01.tga」でも、「a_1.tif」でも「a_001.tiff」でも、「a0001.psd」でも、全て「ファイル名に含まれる素材名部分を親フォルダ名に書き換えてリネーム」できます。

 

ドットで始まる「隠しファイル」がわんさか存在するOSXでの運用を鑑みて、「match(/^[A-Za-z0-9]/)」の条件は念のため入れときました。先頭に記号を付与して、事前に処理対象から意図的に外すことも可能です。

 

まあ、まだ穴はある(エラーで止まる条件は残っています。例えば、「a0001.tga」と「b0001.tga」が同じフォルダに入っていた場合、2つとも「親フォルダ名0001.tga」にしようとして失敗する‥‥など)のですが、かなり現場の作業傾向を吸収できそうです。

 

私は正規表現の使い手ではなく、必要に応じてチョコっと‥‥という程度なので、「.」を「¥.」にするまでは良かったものの、「""」で囲む時に「¥自身のエスケープ」を忘れて、期待通りの動作をせずにウンウン唸ってました。「""」で囲む=クォーティングする場合は、「¥¥.」ですよネ。正規表現に限らす、「" "」や「' '」のクォーティングの際にエスケープ文字自身をエスケープするのは、基本ですよね。

 

そんな程度の私でも、日々の制作作業において、自作スクリプトは大活躍です。‥‥というか、自作のスクリプトやヘルパーソフトウェア、エクスプレッションがなければ、「できることもできなくなる」のが未来の制作技術だと痛感しています。数百にも及ぶキーフレームを意のままに操作するなんて、手作業でいちいち操作してたら無理ですもんネ。

 

 


速度感覚

昨日、新しいディスクを設置しました。これ。

 

 

 

SonnetのFusionです。1TBのThunderbolt 3 の外付けディスクです。内部は高速なM.2のSSDが内蔵されています。

 

制作期間だけお借りする機材なので、返却時に判りやすいようにタグが付いています。

 

 

 

容量こそ1TBですが、その辺の1TBポータブルHDDとは「色々」と格が違います。

 

まず、速度。‥‥毎度のGIF映像ですまんす。個人的に、YouTubeにいちいちアップするのが面倒で。

 

 

 

BlackmagicのDisk Speed Testでの計測の模様を、QuickTime Xで動画収録して、AME(Adobe Media Encorder)でGIFに変換しました。肝心の計測結果は、見ての通りの4K時代を体現する、充分過ぎるほどの高速性能です。書き込みで1300MB/s、読み込みで2200MB/s。次世代映像制作のスタンダードと言える速度です。

*BlackmagicのDisk Speed Testは古いバージョンですと、メーターの速度範囲が狭い=速度範囲が低速仕様なので、忘れずにアップデートが必要です。

 

昔の認識ですと、「SSDなら速い」と無意識に思いがちですが、SATA IIIでUSB3.0接続では、速度は「理論値がそのまま出ても」PCIe(M.2)のThunderbolt3接続の速度には到底及びませんし、そもそも4Kの映像制作には外付けUSB3.0/SATA/SSDでは不適格です。

 

SSDであることは速度を保証する証にはならず、SATAかM.2か、USB3.0かThunderbolt3か‥‥の、接続形態の転送速度が問われる時代にもはや突入しています。

 

ここまでディスクの速度が高速になると、今度はCPUの処理速度が問われるようになるのです。

 

やはり、昔の認識ですと、CPUは充分高速で、SATAやUSB3.0、HDDやSSDの速度が低速ゆえに「お荷物」「足枷」状態でした。しかし、M.2の高速SSDになると、ディスクの転送速度は充分間に合って余裕すらあるのに、CPUのデコード速度が追いつかず、再生が落ちる‥‥なんていう「立場逆転」が起こります。

 

なので最近、システムスタッフの同僚と、「CPUの速度が問われる時代へと、時代がひとまわりしましたね‥‥」としみじみ感じ入った次第です。

 

‥‥で、4K制作において、Sonnet Fusionの使い道は、何よりも「イメージキャッシュ」「リアルタイム再生ファイルの置き場」でしょう。4Kになると、一番「性能が必要になる」部分です。

 

「対性能効果の高い」運用をしないと、もったいなさ過ぎますもんネ。Sonnet Fusionの速度性能が活きる運用が不可欠です。2K24pSDRの制作にはオーバースペック〜対費用効果は低く、4K24〜60pHDRでこそ必要な機材と言えましょう。

 

 

 

 

次に値段。

 

2018年現在ですと、1TBのポータブルHDDは6千円台で買えます。以前、私が買ったのはコレ。

 

 

 

そして、そのUSB3.0 HDDの速度はこんな感じ。

 

 

M.2 SSDの速度を見た後では、随分遅く感じますが、いやいや、全然優秀です。バスパワーで2.5インチ省電力(5400回転?)のHDDで100MB/s(=800Mbps)出ているのですから、充分、廉価なポータブルHDDとしては高速でしょう。映像制作のキャッシュディスクには無理ですが、持ち歩きやノートPCの補助ディスクには有効です。

 

一方、SonnetのFusionは$999です。大雑把に12万円‥‥くらいでしょうか。まあ、つまり、USB3.0のポータブルHDDの20倍のお値段です。

 

「うわッ!高っっ!」と思うでしょうが、値段だけ20倍ではなく、読み込み速度も20倍なので、なんだか妙に説得力がありますネ。「速度こそ値段」を体現しています。

 

 

 

ちなみに、中身は東芝のRD400との表記がありました。

 

 

 

OCZのブランドで売られているコレ‥‥ですかね。

 

 

 

まあ、1TBに10〜12万円なんて、個人がプライベートでホイホイ買える機材ではないですが、現場の、しかも4Kの制作環境には、必須のアイテムになると思います。

 

After Effectsは特に、「ディスクの容量があればあっただけ、どんどんキャッシュにして喰う」ので、Mac/PCの高速なM.2起動シスクを消費することなく、安心してアドビ製品に容量を喰わせるディスク領域は、環境管理面でも有効です。

 

 

‥‥で、最後のスペシャル。

 

Sonnet Fusionを、2台、Thunderbolt3に挿して、ソフトウェアRAID0で組むと、どんな速度が叩き出せるか。

 

こんな時でもなければ、検証できないチャンスなので、実際に試してみました。

 

 

 

書き込みの速度はかなり向上しました。一方、読み込みの速度はあまり向上していません。ソフトウェアRAIDによるRAID0なので‥‥ということもあるのかも知れません。

 

Thunderbolt3を2本挿しなので、そもそもハードウェアRAIDは組めません。それに、アニメ制作の場合、読み込み性能のほうが重視されることもあり、単品接続で充分速度は出ていますし、作業環境としてはわざわざ複数買ってRAIDを組むのは、速度というよりはバックアップ・耐障害性目的になるかと思われます。

 

こうして色々テストしてみると、改めて、iMac Proの内蔵SSDの速度性能が飛び抜けていることがわかります。以下はiMac Proの内部SSDのスピードテストで、書き込みが恐ろしく高速なのがわかります。‥‥まあ、非リアルタイム記録のアニメ制作だと、あまり関係ないんですけどネ。

 

 

 

今までも、あらゆるジャンルにおいて、速度の感覚がどんどん上がる一方でした。乗り物などの移動手段だけでなく、買い物の速度〜ネット通販での決済と宅配サービス〜まで。

 

2020年代、コンピュータの色々な速度も、さらにまた1世代、高速化して進化することになる‥‥のでしょうネ。

 

 


最初は覚えることいっぱい

前回、スクリプトの補足を書いてて、どんどん解説文が長くなるのを我ながら見て、たった3行のスクリプトでも覚えることはそれなりに多いな‥‥と実感しました。あれだけ長く書いた割に、「var」とか、「 = 」とか、for構文の「{ }」とか、行末の「 ; 」は、しれっと何も説明しないまま、スルーしてますもんネ。

 

例えば、「var theNumber = 120;」の「var」はvariable〜バリアブル〜「変数」の英単語の頭文字3文字です。しかし、変数といっても、ローカル変数=その場だけで有効な変数もあれば、グローバル変数=After Effectsが起動している間はずっと有効な変数もあります。また、値やオブジェクトを格納するのは、変数だけでなく、定数でも可能です。

 

varは、ローカル変数を明示的に生成する時に用います。そうしないと、特にAfter Effectsの場合、昼は作業、夜はレンダリング‥‥みたいにAfter Effectsが起動しっぱなしだと、偶然、複数のスクリプトで同じ変数名を使っていた際に、思わぬ事故が起こることがあります。空だと思っていた変数が、実は全く違うスクリプトで数日前に代入済みで、思わぬ動作をする‥‥みたいに。

 

ですから、After Effectsのスクリプトの場合、

 

theNumber = 120;

 

のような、グローバル変数の代入ではなく、

 

var theNumber = 120;

 

‥‥のようなローカル変数の代入が基本になります。After Effectsのグローバル変数は、After Effectsが起動している限り、たとえスクリプトが終了しても生き続けるので、注意が必要です。

 

「え? エクスプレッションだとvarなんて使わなくてもトラブルはないけどな」

 

‥‥というのは、その通りで、After Effectsのスクリプトとエクスプレッションは、グローバル変数の「スコープ=範囲」が違うのです。

 

エクスプレッションは逆に、変数の寿命‥‥というか有効範囲が「そのフレームだけ」と極端に狭いです。毎フレームごとにエクスプレッションが実行されますが、そのたびに、グローバルもローカルも関係なく変数の寿命は終了して空になります。

 

なので、エクスプレッションは、

 

theNumber = 120;

 

‥‥でも、全く問題がないのです。

 

反面、エクスプレッションは、タイムライン〜フレームにまたがって変数を持てません。ですので、裏技‥‥というか、他の方法でフレーム共通のグローバル変数もしくは定数を実現することになります。マーカーを作ってコメントを書いて参照して定数にしたり(直にエクスプレッション文をイジらなくても定数の変更が可能)、他のテキストレイヤーのテキスト内容の読み取り(連動して動作させるには、結構、構造は複雑になります〜正確には変数ではなくクリップボードのような扱い)など、「本来、変数・定数の格納場所として想定されていないものを無理矢理活用」すれば実現できます。

 

 

‥‥とまあ、変数1つで、ちょっと説明しただけで、これくらいは必要になります。

 

最初は覚えることが多くて、それが初心段階の大きな障壁ともなります。

 

なので、いっきに覚えて習得するのは、そもそも無理だと諦めて、今、自分の差し迫って必要な雑事を軽減するためのスクリプトを書くことだけに集中して覚えて、それを繰り返していけば、いつのまにか、「あれ? 自分、プログラムのことをある程度、理解できてるよな?」と我ながら驚くわけです。

 

日本語だってそうだったはず。

 

喋りたいこと、伝えたいことのために、まず言葉を覚えていったのを思い出せばよいです。

 

‥‥で、プログラム、スクリプトは、20〜30代の若い頃に覚えちゃうのが、絶対にお得です。だって、何よりもまず、覚えるための脳の柔軟性がありますもんネ。アラウンド40以降になると、何度も反復しないと覚えられないことが、アラウント30だとあっさり覚えられたりします。ん〜、自身で実感。

 

普通に現代社会の状況の成り行きを考えて、10〜20〜30代の人間は、コンピュータを絡めて仕事をする未来がほぼ確定しています。よほど特殊な職種でない限り、コンピュータと無縁ではいられないはずです。だったら、プログラムの基礎を覚えておいて、損はないはず。

 

代々の農業を兼業するのだって、田畠の管理にコンピュータを使っても良いわけですから、デジタルデータで運用する映像産業に従事するのなら、なおさら‥‥ですよネ。

 

 

 


スクリプト補足

前回に載せた「フォルダ名で、中身のファイルをリネームする」スクリプトですが、あまりにもちゃちゃっとブログ文中で済ませたので、補足しておきます。

 

ちなみに、私はアニメーター100%だった頃、コンピュータやプログラムとは真逆の人間だと周囲から思われていましたし、自分もプログラムなんてとてもじゃないが‥‥と思っていました。学校でコンピュータやプログラムを教わったことなど皆無でしたし。

 

でも、今はこんな‥‥です。

 

なので、本人の気概次第でプログラムの基礎くらいは習得できると思っています。プログラム言語よりも遥かに難解な日本語を話せるのですから。

 

で、前回のスクリプトは‥‥

 

var theFolder=Folder.selectDialog("フォルダを選択してください");
var theFiles=theFolder.getFiles("*_?????.tga");
for(var i=0;i<theFiles.length;i++){theFiles[i].rename(theFolder.name+"_"+theFiles[i].name.split("_")[theFiles[i].name.split("_").length-1]);}

 

‥‥の3行スクリプトでした。

*ブログの表示幅の都合で、自動回り込み改行で4行に見えることもありますが、実際は3行となります。

 

これに注釈を添えると‥‥

 

var theFolder=Folder.selectDialog("フォルダを選択してください");

 

ユーザにフォルダを選択してもらうよう催促するのが、Folder.selectDialog() です。選択したフォルダを記憶しておくために、変数「theFolder」に代入します。変数の名前はtheFolderでなくても構いませんが、予約された単語とは被らないようにします。「folderA」「target_folder」などでも大丈夫です。

 


var theFiles=theFolder.getFiles("*_?????.tga");

 

getFiles() は、文字通り、フォルダの中にあるファイルをゲットする命令です。ただし、ファイル全てをゲットしてしまうと、不要なファイルまでゲットしてしまう可能性も否めません。そこで、「連番ファイルだけを選び出す」ために、条件をつけます。

 

今回の連番のファイル名は、「親フォルダの名前」+「アンダーバー」と「数字5桁」と「ドット」と「TGA拡張子」で構成されていますので、その連番ファイルだけを選び出してゲットします。「選び出し」を可能にするのが、getFiles() の括弧内の指定です。

 

「*」は0文字以上の何らかの文字列、「?」は何らかの1文字を表し、その他はそのままの文字として認識されて、選び出しの条件となります。ゆえに、「*_?????.tga」で「a_00001.tga」などの連番ファイルだけを抜き出すことが可能になります。同じ条件で「zz_xx_cdefg.tga」も条件に引っかかることになりますが、映像制作の素材フォルダにはそのようなファイル名が含まれていないことがわかっていますので、甘い条件でも十分機能します。

 

もし「b_0001.tif」や「b_0122.tif」などの4桁&TIFF連番を抜き出したい場合は「*_????.tif」にすれば良いです。

 

もっと条件をユルくして、「*.???」なら、「b_0001.tif」も「a-ue_001.tga」「anim_06_231_t2_0048.dpx」でも、全部対象になります。「ドット&3文字拡張子」なら何でも抜き出せる‥‥というわけです。中身に何が入っているか、自分自身で確信があるのならそのくらいユルくてもOKですが、スクリプトプログラムを作った本人以外の他人が使う時は注意が必要です。

 


for(var i=0;i<theFiles.length;i++){theFiles[i].rename(theFolder.name+"_"+theFiles[i].name.split("_")[theFiles[i].name.split("_").length-1]);}

*ブログの表示幅の都合で、自動回り込み改行で2行に見えることもありますが、実際は1行となります。

 

for」は繰り返しを処理する構文で、プログラム初心者の「最初のハードル」と言えるかも知れません。「for(var i=0;i<theFiles.length;i++)」は、「まず最初に変数iにゼロを代入し、変数iが変数theFilesの中身の総数より小さい間は処理を繰り返し、繰り返しごとの最後に変数iに1をプラスしてループ先頭に戻る」という意味になります。

 

一方、変数theFilesの中身は、先ほどの「getFiles("*_?????.tga")」によって、TGAの連番ファイルが格納されているので、この、for構文で順番に中身を取り出して処理していきます。theFilesの中にあるTGA連番ファイルは、一番目のファイルを「theFiles[0]」、七番目のファイルは「theFiles[6]」というように「ゼロスタートに読み替えて」指定して取り出すことができます。

 

for構文において、変数iは、繰り返しごとに、0, 1, 2, 3, 4, ....と増えていくので、変数iを呼び出し番号として活用し、theFiles[i]のように用いれば、theFIlesの中身を順番に取り出すことが可能になります。

 

次に、theFiles[i]で呼び出した個々のTGA連番ファイルを、いよいよ、「rename()」命令でファイル名変更しますが、そのためには、新しいファイル名を、親フォルダの名前と古いファイル名を部分的に合体させて生成する必要があります。

 

変更後の名前は、「親フォルダの名前」+「アンダーバー」+「元の連番と拡張子」にしたいので‥‥

 

親フォルダの名前を得る>>theFolder.name

 

‥‥は簡単だとしても、面倒なのは‥‥

 

元のファイル名から連番と拡張子だけを得る>>「a_00001.tga」の「00001.tga」の部分

 

‥‥です。でも、映像制作では連番の前を「アンダーバーなどで区切る」のが一般的なので、それを有効活用します。つまり、ファイル名をアンダーバーで区切れば、「a」と「00001.tga」を分割=split() できます。

 

例えば、"a_b_c_d" という文字列があった場合、"a_b_c_d".split("_") を実行すると、["a","b","c","d"] という配列に分解されます。この配列から3番目の要素である "c" を抜き出したい場合、ゼロから数え直して、[2]という呼び出しかたで抜き出します。つまり、"a_b_c_d".split("_")[2] で "c" を抜き出せます。

 

なので、"a_00001.tga" から "00001.tga" を抜き出すには‥‥

 

"a_00001.tga".split("_")[1]

 

‥‥でうまくいきます。

 

しかし、今回は「a_00001.tga」でしたが、もし「a_un_00001.tga」みたいなファイル名だったら‥‥

 

"a_un_00001.tga".split("_")[1]

 

‥‥では「un」が抜き出されてしまいます。前方から数えて抜き出すのではなく、最後の要素を抜き出せば、必ず、「00001.tga」が抜き出せます。しかし、残念ながら、最後から数えるのに [-1] のような指定方法は通用しません。

 

なので、split() で分割した要素数を数えて、1スタートではなく0スタートで指定するために要素数からマイナス1すれば、最後の要素を指定して抜き出すことが可能になります。要素数を数えるには「length」を使います。

 

"a_00001.tga".split("_")["a_00001.tga".split("_").length-1]

 

"a_un_00001.tga".split("_")["a_un_00001.tga".split("_").length-1]

 

この方法なら、ちょっと文が長くて解りにくくなりますが、どの場合も確実に「00001.tga」を取り出すことができます。スクリプト文中ですと‥‥

 

theFiles[i].name.split("_")[theFiles[i].name.split("_").length-1]

 

‥‥という具合になります。

 

連番と拡張子が取り出せたのなら、あとは親フォルダの名前と合体させるだけです。アンダーバーも忘れずに。

 

theFolder.name+"_"+theFiles[i].name.split("_")[theFiles[i].name.split("_").length-1]

 

新しい名前を生成できたら、rename()」命令で実際にファイル名を変更して終了です。

*ブログの表示幅の都合で、自動回り込み改行で2行に見えることもありますが、実際は1行となります。

 

theFiles[i].rename(theFolder.name+"_"+theFiles[i].name.split("_")[theFiles[i].name.split("_").length-1])

 

 

実際に処理をすると、72ファイル程度のリネームなど「瞬殺」で処理終了です。

 

 

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓

 

 

 

 

たった3行のプログラムですが、最後の行に「for」「rename()」「split()」などが一気に盛り込まれたので、ちょっと難しいようにも思えますが、落ち着いて、行頭から1つ1つ意味を理解して進めば、混乱することはありません。

 

リネームはこのやり方の他にもたくさん方法があります。今回は「親フォルダ名と元の連番&拡張子を合体させる」方針なので、上記の方法になりましたが、文字列の「置換」を使ったり、ソートしてリナンバーする方法も考えられます。

 

何か1つの段取りを守らないとリネームができないわけではなく、工夫次第で色々なアプローチを考えて実践できるのが、プログラムの「実は楽しいところ」です。

 

でも‥‥

 

工夫次第で色々なアプローチを考えて実践

 

‥‥って、絵を描いたり、話を考えたり、視覚効果を追加したり、音楽を作ったりすることと、何だか似てます。料理や運転、経営・経済などにも共通すること‥‥かも知れませんネ。

 

 

 

 

*追記:

今回の3行のサンプルスクリプトは、できるだけ簡潔にするために、例えば「ユーザがキャンセルボタンをクリックした」「フォルダの中身が空だった」などの「false」「null」「[ ]」「undfined」に対応する処理が全く書かれていません。その点に関しては、ESTKの元になっているJava Scriptの指南Webなどで独学してください。

 

例えば‥‥

 

main();

 

function main(){

var theFolder=Folder.selectDialog("フォルダを選択してください");

if (!theFolder) {return false;}

}

 

‥‥などのようにキャンセルに対する処理を施します。

 

 

 



calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< August 2018 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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