JavaScript(JS)、Adobeのエクスプレッションやスクリプトは、型の変換をうまいこと自動で処理してくれます。

 

型とは、

 

数値としての100

数字としての「100」

 

‥‥というように、一見同じに見えますが、カテゴリー・種別が違うことです。(なんか、雑な表現ですまんス)

 

数値として100+100なら200ですが、数字(文字)としての「100」+「100」は「100100」です。

 

初心の頃は、こうした「型の認識」が曖昧で、プログラム言語が提供する「暗黙の型変換」に甘えきっているので、自分の書いたプログラム文がうまくいかない時は理由が分からずパニックになります。

 

000+1が0001にならないよ! どうやっても1になっちゃうよ!

 

‥‥というのは、数値でプラスしているからです。

 

フレームナンバーは数値ですが、表示するときに文字にしたいのなら、丁寧に書けば、

 

"000"+String(1);

 

‥‥という書き方になります。String()を省いても暗黙のうちに型を変換してくれるので、

 

"000"+1

 

‥‥でも結果オーライです。文字列の"000"と連結した時点で、1は"1"にキャスト(型変換)されます。ありがとね、JS。

 

 

 

私が20年前に常用していたプログラム言語では、変数を使う時に必ず型を決めなければなりませんでした。たしか‥‥

 

Dim frameNumber as integer

 →意味:整数としての変数frameNumber

 

‥‥のような感じだったと思います。「今から取り扱おうとする値は、どんな型なのか」を宣言する必要がありました。つまり、御膳立てに時間がかかって、本題に入るまでが長かったのです。本格的なAppを作るのならともかく、ささっと自動処理したいニーズには向きませんでした。

 

それに比べれば、JSはヌルヌルのユルユルのズルズル。賢く使えば便利ですが、無自覚に使うとトラブルの元にもなります。

 

 

 

型の相違でありがちなのは、配列のインデックスによる取り出しです。

 

["A","B","C"]=配列「A,B,C」を、例えばスライスなどで1つだけ(例えば1番目だけ)を取り出した結果は、"A"=文字列ではなくて、["A"]=配列です。‥‥これ、JSを使っていると、結構忘れがちです。

 

多くの場合は言語環境側で、文字列に自動でキャストしてくれますが、なんらかの理由でキャストが機能しない場面では構文チェックにひっかかり、エラーで先に進めなくなるのです。型にギチギチの言語なら注意してプログラム文を書きますが、JSだとついつい甘えてユルくなりがちです。

 

 

 

型を自覚して扱うようになると、例えば350の桁数を、99より大きくて1000より小さいから3桁‥‥なんてしなくても、

 

String(350).length;

 

‥‥で、桁数が簡単に取得できます。

 

JSは、型とか特に意識しなくても、ネットで書き方を見て真似して覚えられる、非常に敷居の低い言語です。しかし、JS自体がユルくいいかげんに作られているわけではなく、できるだけプログラム言語にありがちな作法を意識しないで書けるように工夫されているのです。

 

なので、IF文やループ文などの基本的な書き方をなんとなく覚えたら、

 

型の扱い

オリジナルのファンクション(関数・ルーチン)

 

‥‥を覚えていけば、いきなりハードルが上がる感じもせずに、徐々にミラクルな処理ができるスクリプトを書けるようになってきます。正規表現とかは必要に応じてちょっとずつで良いと思います。

 

 

 

プログラムは頭の柔軟な20代から始めるのが良いです。10代ならなおさら良いですが、それは各人の自由で。

 

50代からは結構難しいようには思います。でも、もしかしたら、50代で通常業務の技術的余裕ができて、空いた時間に覚えれば、案外覚えられるかも知れません。

 

アニメーターって、実はプログラムの習得に向いているとも感じますしネ。

 

だって、人間の芝居や自然現象を、線画という言語を使って、カットという1つのプログラムに仕上げているわけでしょ。

 

まあ、中には理屈など全く意識せず感性だけで描く人もいましょうが、技量の確かな人なら、個人の中でなんらかの「絵を描く言語体系」が出来上がっていて、オーダーに合わせて構造的に組み立てているでしょう。実は凄いプログラム能力なんすヨ。

 

演出上の前後の流れを把握する能力、レイアウトの構成能力、動きの観察力、情報を線画として要約する能力、状況に応じて現実と空想を織り混ぜるバランス感覚。‥‥凄いプログラム能力ですよね、改めて列記すると。

 

今回の「型」の扱いに関しても、アニメーターなら、動きやフォルム、影の付け方など、描写しようとする対象の「型」を観察して把握し、分別して描きますよネ。

 

自然現象クラス>流動エフェクトクラス>水クラス

 属性:スケール(水溜りか津波かなどの大きさ)

 属性:不純物含有度(水に土砂などの不純物がどれだけ混入しているか)

 属性:ベロシティ(動きのエネルギーの強さ)

 属性:エクストラ(エネルギーの指向性のバラつきによる水の拡散ランダム度)

 属性:発泡度(空気を巻き込んだ量)

 属性:etc,etc...

 

プログラム風に表現しましたが、水のエフェクト作画をするなら、普通に考える内容です。

 

アニメーターなら、コンピュータプログラムはできると思うんですよね。ただ、なかなかやろうと思う機会がないだけで。

 

まあ、興味が湧いたら、まずはPhotoshopのスクリプトを作って、地道なPhotoshop事務作業を自動化してみても良いですネ。

 

 

 


IFからステップアップ

エクスプレッションにせよ、スクリプトの自動処理にせよ、プログラム文を学んだ最初のうちは、IF文に頼りがちです。

 

例えば、数字の桁を4桁で揃える方法の場合、IF文を使うと以下のようになります。

 

もし、10未満だったら、

 000を数字の先頭に追加する

あるいはもし、100未満だったら、

 00を数字の先頭に追加する

あるいはもし、1000未満だったら、

 0を数字の先頭に追加する

でなければ

 そのまま

以上

 

After Effectsのテキストレイヤーのソーステキストにエクスプレッションで表現すると、

 

var frameNumber=timeToFrames(time, 1.0 / thisComp.frameDuration,true)+1;

if(frameNumber<10){

 "000"+frameNumber;

}else if(frameNumber<100){

 "00"+frameNumber;

}else if(frameNumber<1000){

 "0"+frameNumber;

}else{

 frameNumber;

}

 

 

一見、これで良いように思います。ちゃんと期待した通りに動作しますしネ。

 

しかし、長い。

 

文が長くて、変更しにくいです。

 

もし、5桁の「00001」にしたい場合、文の各所を直さなければなりません。面倒です。

 

IFを使うと、読解の時間が長くなり、メンテしにくくなる傾向があります。

 

以下の2行で、IFを使わなくても、桁数は簡単に揃えられます。

 

var frameNumber=timeToFrames(time, 1.0 / thisComp.frameDuration,true)+1;

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

 

 

 

2行であっさり終了。

 

「10000」の先頭1文字を削れば、「0000」になりますから、slice(1)、つまり1文字目の後から切り取れば、容易に4桁にできます。

 

桁数を5桁にしたければ、10000を100000に変更するだけです。IF文を数行に渡って書き換えるより、かなり楽です。

 

なんなら、自動で桁数まで設定できます。4桁にしたければ、10^4(結果は10の4乗=10000)と書けば良いので、総数を文字列化して文字数をカウントすれば、自動桁揃えが可能になります。

 

10^(String(総フレーム数).length); ‥‥という感じで。

 

IFをどうしても使わなければならない場面はあります。簡単に済ませる方法があるのなら、無闇にIFを使わず、他の方法で処理するのが良いです。

 

 

 

コンポ名からボールド表記を自動生成するのも、IFに頼らず可能です。

 

例えば、「ANIMEの01話、カット001、線撮テイク1」を、以下のような命名規則にしている作品があったと仮定します。

 

ANI01_001_S1

 

「_」アンダースコアのデリミタ(文字列を区切る文字)によって、カットの名前に含まれる各情報が区切られています。作品略号と話数の間にデリミタがないのが厄介ですが、そこはおいといて、何撮のテイクなのかを、IFありとなしの2種類の方法で取り出してみましょう。

 

Cはコンテ撮、Sは線撮、Kはタイミング撮、Tは本撮

 

IFを使うと、文が数行に渡って長くなり、メンテしにくくなります。

 

var cutName=thisComp.name;

var compType=cutName.split("_")[2].split("")[0].toLowerCase();

if(compType=="c"){

 "コンテ撮";

}else if(compType=="s"){

 "線撮";

}else if(compType=="k"){

 "タイミング撮";

}else if(compType=="t"){

 "本撮";

}else{

 "不明";

}

 

もし「XX撮」が増えた場合、どんどんIFを増やす必要があります。略字に変更があった場合もめんどくさいです。

 

IFを使わず、連想配列で処理すれば、メンテしやすく、読みやすくもなります。

 

var cutName=thisComp.name;

var compType=cutName.split("_")[2].split("")[0].toLowerCase();

var compTypeList={"c":"コンテ撮","s":"線撮","k":"タイミング撮","t":"本撮"};

compTypeList[compType];

 

しかし、このままだと、「存在しない略字」の場合、「不明」が表示されません。カット名の異常には気付きますが、せっかくなので「不明」と明記しましょう。

 

そんな時こそ、あえて、IFの出番です。

 

var cutName=thisComp.name;

var compType=cutName.split("_")[2].split("")[0].toLowerCase();

var compTypeList={"c":"コンテ撮","s":"線撮","k":"タイミング撮","t":"本撮"};

 

if(compType in compTypeList){

 compTypeList[compType];

}else{

 "不明";

}

 

 

略字がリスト(連想配列)に存在しない場合は「不明」を返すようにできます。

 

キーとバリュー、つまり、略字と関連づけた文字列を記述すれば、いくらでも「何撮」の種類を増やせて(あまり増やしたくないけどネ)、略字の変更にも1行で柔軟に対応できます。IFで数行に分けて連ねるよりも、1行で見渡せるので、内容把握や修正も楽になるわけです。

 

 

 

 

IFは、まさに「IF分岐」するので、読みにくくなります。分岐してるものを追うのって、面倒ですよネ。

 

IFを使わないことで、分岐が減り、読みやすくメンテしやすいプログラム文になります。

 

ある程度、スクリプトに慣れてきたら、IFを使わない方法にチャレンジすると、コンピュータをもっと理解できて、新たな運用のアイデアにも繋がります。

 

After Effectsの雛形を共通にして、作品ごとの命名規則や運用をデータベースサーバから取得して適用する‥‥なんていうことも可能になります。

 

 

 

記事文中のスクリプト文を補足しますと‥‥

 

文字列をデリミタで分割するsplit()は、引数に""を指定すると、"ABC" を ["A", "B", "C"]に1文字ずつ分割できます。substrとかを使わなくても、何番目の文字かを指定して取り出せます。

 

また、ケアレスミスで多いのが、大文字小文字の混在です。略字をちゃんと処理できるように、大文字か小文字かに変換すると「T1」も「t1」も正常に処理できます。

 

 


ESTKの代わりに

アドビのエディタ「ExtendScript Tool Kit」=ESTKは、After EffectsやPhotoshopの自動処理を書く時に重宝してました。

 

‥‥が、最近、CCのラインアップから外れました。配布中止するなら、次のエディタを出してくださいよ、アドビさん‥‥。ユーザは、サブスクリプション代金を一生懸命払ってるんだからさ‥‥。

 

‥‥と恨み節を吐いても事態は進展しないので、「mi」でもスクリプトを書いて実行できるように、ちょっとひと工夫。

 

mi

https://www.mimikaki.net

 

 

miから、直接After Effectsにスクリプトを実行したい場合は、毎度のAppleScriptで。

 

tell application "mi" to set txt to content of front document

 

tell application "Adobe After Effects 2020"

    activate

    DoScript txt

end tell

 

5行のスクリプトですが、これで、miで書いた内容を、After Effectsに送って実行できます。miのツールバーから呼び出して実行できるようにしておきます。

*自分のアカウントのLibrary/Application Support/mi/mode/NormalまたはJavaScript/toolbarの中に、適当な名前のフォルダを作ってスクリプトを入れておきます)

 

 

 

*ちなみに「構文チェッカー」とは、JavaScriptの構文ではなくて、私が独自に規定したTS(タイムシート)記述式の構文チェッカーです。‥‥ほんとに、いろいろなことを30代にはチャレンジしましたわ。

 

 

 

 

とりあえず、これでしのいで、Adobeスクリプトを書きます。

 

 

 

ちなみに、私がJavaScript上でシングルクォートばかり使うのは、AppleScriptに移植する際にダブルクォートとバッティングさせないための習慣です。

 

DoScript "alert("Hello, World.");"

 

‥‥なんて、エラーが出るのがわかりきってますよネ。

 

いちいち、エスケープしないで済むので、昔から「スクリプト on スクリプト」の場合は、使い分けてます。

 

 

 


復活の日。

4KHDRだカットアウトだと言っても、まだまだ旧来枠の仕事の依頼はそれなりにあります。

 

一方、2000年代に夢中になって作ったxtools=コンポジットの作業をアシストする自動化ツール群は、2010年代にアニメの撮影をあまりしなくなったこともあり、メンテがおろそかでmacOS "Catalina"になった現在に正常に動くのか、非常に危うい状態です。

 

一番昔の更新日を見ると2006年だもん。‥‥まあ、中身は差し代わっていますが、それでも一番新しいツールの更新日ですら2016年で終わっています。新しいOSで動作しなくなったのを、コンパイルしなおして書き出しただけの更新です。El CapitanとかSierraの時代で止まっています。

 

今後の動向を鑑みるに、今から一生懸命になってアニメ撮影の自動化ツールを再構築するよりも、必要最小限の自動化ツールを延命措置して、2020年代の主力は4KHDRでハイブリッド(従来作画と新方式の)の運用技術の確立に据えたほうが良いのは明白です。

 

昔ながらのアニメのコンポジットの段取り。‥‥すなわち、タイムシートを打ち込んでタイムリマップに変換して、背景とセルを読み込んで適用して、etc‥‥という作業スタイルに対して、「最後のご奉公」というか、開発における「最後の戦い」を2020年春の期限ですべきかな‥‥と考えております。

 

私が30代の頃に、苦労に苦労を重ねて作ったxtoolsが、時代に取り残され動作しないまま、朽ち果てて終わるよりは、レストアして復活させて、これから作業する作品に役立ててフィナーレを飾ったほうが、私の中でも大きな区切りができます。

 

 

 

とはいうものの。

 

当時、Adobeのスクリプトを覚えながら作ったので、大盛りパスタのごとくのコードなのよネ‥‥。自分ながら、うんざりするほどのスパゲティ。

 

習得しながらのプログラミングは、最初からスッキリハッキリ明快なコードなんて書けんもん。

 

 

 

なので、ずっと放置していた‥‥というのもありますが、レストアすれば確実にコンポジット作業は快適になります。

 

5〜6カットの特殊カットのヘルプなら、ゼロからAfter Effectsで手作業で組んでも良いですが、今後累計で、何十、何百を作業するともなれば、やはり自動処理アシストツールのパワーは絶大です。もうアニメの撮影をメインにすることはないですが、作画からコンポジットまで一式で依頼されることは度々あるので、ツールを復活させて準備しておくのは決して無駄にはならんでしょう。

 

それに、人災もないしネ。コンピュータは、1168と指定すれば必ず1168に設定して動作しますからネ。私はケアレスミスをよくやらかすので(「1186」とか)、コンピュータのアシストはどんなに経験を積もうが頼もしい存在です。数値的なつじつま合わせは、ほとんどコンピュータに任せて、人間は映像表現を追求すれば良いので、作品作りに集中できます。

 

 

 

コードを全部精査して、若気ゆえにわけのわからんことをしている箇所は直して、すっきりと見通しの良いコードにブラッシュアップして、xtoolsのファイナルバージョンを作ろうと思ってます。

 

 


クイックアクションをもっと。

クイックアクションから直にPhotoshopやAfter Effectsは操作できなくても、AppleScript経由で全てのスクリプト制御を使用可能です。

 

Adobeのスクリプト機能をAppleScriptでラップして、Automatorのクイックアクションで実行できるのです。

 

ややこしいですが、PhotoshopやAfter Effectsの豊富なスクリプト機能がまずあって……

 

 

それをAppleScriptの「DoScript」で実行可能にして‥‥

 

 

ユーザにはAutomatorのクイックアクションとして供給する‥‥

 

 

という流れです。

 

Automatorの「AppleScriptを実行」は、外部ファイルも呼び出せるので、jsxのスクリプトファイルも読み込み可能です。もちろん、直にJavaScriptの文をAppleScriptの中に書いて実行することも可能です。

 

では、お約束の。

 

 

 

AppleScriptのdisplay dialogではなく、JavaScriptのalert()にてダイアログを表示しました。つまり、AdobeのJavaScript自動処理で動作しているということです。

 

ハローワールドではちっともAfter Effectsぽくないので、After Effectsに「PSDはコンポで、そのほかの画像ファイルはフッテージで」というちょっとしたスマートインポートを実行してみます。

 

 

After Effectsのドラッグ&ドロップでは、一緒にファイルをドロップすると、全部同じ読み込み形式になったりします。スクリプトを使えば、PSDはレイヤーを保持したコンポジションで読み込んで、TIFFやTGAはフッテージ(アルファがある場合はアルファ付き)で読み込んで‥‥と、単純な動作ではありますが、ちゃんとファイルを切り分けて読み込みします。

 

内容はこんな感じ。とても単純なIF分岐。

 

 

マウス右クリックで実行してみます。

 

 

はい、完了。

 

種別を見ての通り、PSD(=コンポで読み込み可能なファイル)はコンポジションで、TIFFやTGAはレイヤー構造をもたないフッテージで読み込みました。

 

*背景は空と山BOOKと地面BOOKのPSD、雲はTIFF、星はTGAです。

 

これを発展させれば、以前私が作っていたコンポ自動ビルドツールと同じ自動処理も可能です。背景とセルを読み込んでコンポに配置してタイムシートも適用する‥‥という流れを自動化できます。

 

今ごろ、Automatorに注目しているあたり、ちょっと間抜けなんですが、まあ、いいです。便利なものに時と場所は関係なし。

 

アニメ業界でも、映像業界でも、Macを使っている人は結構多いですよネ。仕事では業務用Windowsでも、プライベートではMacBookやiPadを使っている人を数多く見ます。

 

クイックアクションは右クリックで呼び出せて、いちいちマウスを大きく移動させる手間がないので、地味に快適になりますヨ。

 

 


コンポーネント

たとえ小さなスクリプトを作成する際にも、同じサブルーチンを何度も繰り返し書くのは非効率である上に、メンテナンスも煩雑になります。

 

例えば再帰処理を毎回書くのはいかにも面倒ですよネ。なので、共通したルーチンは、コンポーネント化して集約します。

 

AppleScriptは他の言語同様、外部のスクリプトを読み込んで活用できます。以下みたいに。

 

set myCOMP to load script file "Macintosh:components.scpt"

display dialog myCOMP's getFileList(folder "Macintosh:Folder:")

 

とは言うものの、最近のmacOSは、昔のようにユーザが自由にイジれる仕様ではなくなっています。以前は可視だったシステム関連のフォルダは不可視になって久しいです。

 

たとえば、クイックアクションで使うルーチンのコンポーネントをどこに置いておけば良いか。

 

簡単な方法としては、クイックアクションのファイルと同階層に置くのがいかにもわかりやすいです。

 

しかし、果たしてクイックアクションのファイルから見て「同階層」とはどこになるのか。クイックアクションに内包されるAppleScriptから呼び出すので、「ユーザ/Library/Services/」を示す結果となるのか。

 

 

‥‥‥‥。どこ?

 

おそらく、Automatorのパッケージファイルの中の深いところでしょう。

 

そりゃそうか。クイックアクションのファイルはそれ自体は実行ファイルじゃないもんな。「path to me」すれば、実行ファイル自身のパスを取得するのは当然か。

 

runner.xpcという実行ファイルに頼っているようですネ。でもまさか、Automatorのフレームワークの中に私独自のファイルを置くわけにはいくまい。アップデートのたびに消される可能性大。

 

う〜ん、どうしようか。

 

 

 

コンポーネントをどこかにおいて呼び出すことは簡単ですが、どうせなら、Application Supportとかに置いて、クイックアクションだけでなくスクリプトメニューやレンダー庭園(仮名)とも共用したいです。

 

しかし、従来のApplication Supportだと、マシンローカルに限定されます。Catalina以降は色々と実行許可もキビしいし。

 

むしろ、Apple IDを活用して、iCloudの特定場所にしたほうが良いかな。

 

そうすれば、同一のApple IDを使う限り、どのマシンでもコンポーネントが呼び出せます。

 

 

 

では、iCloudって、どんなパスになるんでしょう。

 

/Users/ローカルのアカウント/Library/Mobile Documents/com~apple~CloudDocs/

 

「com~apple~CloudDocs」というのが、見慣れないですが、Finderが認識できるiCloudのパスはソコみたいですネ。

 

なので、「home」(AppleScriptでのユーザホームフォルダのエイリアス)でユーザのローカルパスを取得して、「Library/Mobile Documents/com~apple~CloudDocs/」を連結し、あとはコンポーネントファイルの以下のパスを連結すれば、毎回変わらず特定できそうです。

 

/Users/ローカルのアカウント/Library/Mobile Documents/com~apple~CloudDocs/コンポーネントのパス

 

これでiMacからもMacBookからもMac miniからも、コンポーネントが呼び出せて、コンポーネントを編集して機能アップすれば、全台のMac端末に反映されます。

 

試しにTIFFの変換スクリプトを移植がてら、正常に動作するか試してみました。

 

 

 

無事、TIFFファイルが書き出されました。

 

 

 

随分と自由なファイル名ですが、クォーティング(quated form)してShellに投げるので、正常に処理されます。もちろん、仕事の時は、こんな名前は一切出しませんし、仕事用のリネームスクリプトも色々用意しています。それこそ、CODE39の文字に丸めるスクリプトとかネ。

 

*「安全な文字列に変更」というスクリプトも随分前に作りました。

 

 

クイックアクションはいっそのこと、Library/Servicesもクラウドで共有できると楽なんですが、まずはそこまでしなくても良いか。

 

今頃になって、Automatorを使い始めるのも何ですが、右クリックで素早くJPEGやTIFF、連番リネーム、項目のリストなどが取得できると、作業が地道に捗ってストレスが軽減されます。

 

「こんな感じの絵です」みたいな途中経過の画像をメールで送る時に、まさかPhotoshopを立ち上げてJPEGに変換するなんて大げさな手間はしたくないですよネ。右クリックでJPEG変換できれば楽です。

 

クイックアクセス用途だけでも、まずはAutomator重宝。

 

 

 


クイックアクション

‥‥といっても、QARのことではなく、macOSのFinderの右クリックメニューの「クイックアクション」です。

 

前々から、ここに自分で作った数々のプチスクリプトを呼び出せるようにすれば便利だなと思っていました。ファイル名を大量に置換したり、ファイル名を番号でリネームしたり、JPEGやTIFFに変換したり‥‥と、昔から自分で作りためた単機能のスクリプトは、クイックアクションで現代のmacOSでも活きると感じてました。

 

でも、どうやれば、自分でクイックアクションを作れるのか。何となく、調べもしないまま、月日が経ちました。

 

たぶん、Automator。

 

Automatorを使えば、macOS時代のサービスに対応した自作のスクリプトが作れるのではないかと、重い腰を上げてみることにしました。

 

普段は全く使ってなかったAutomatorを起動して、新規書類の一覧を見たら、あっけなく、その機能がありました。

 

 

欲しかったそのまんまの書類=「クイックアクション」対応のファイルが作成可能みたいです。

 

 

 

では、実際にどうするのか。

 

私のプチスクリプトはAppleScriptで実行可能になっていますので、そのスクリプトの中身を移植すれば良いのですが、単純にコピペすれば良いって話でもなさそうです。

 

いろいろ試した結果、「こうすれば良い」というのがわかりましたので、ここでご紹介。

 

自分で作ったクイックアクションは、自分のライブラリの「Services」に保存されます。

 

 

Finderは自動でServicesの中のクイックアクションを認識するはずです。しかし、クイックアクションの内容に合わせて提供する仕組みなのか、単純に保存しただけではクイックアクションのメニューに表れません。

 

右クリックしてクイックアクションを呼び出しても、「てすと」が表示されません。

 

 

Finderが処理すべき内容であることを、クイックアクションのオプションで指定する必要がありそうです。

 

以下のように設定してみました。

 

 

そしたら、出ました。

 

クイックアクションの仕組みにおいて、どのアプリのどんな項目が対象かを、上図のオプションで指定すれば、Finderでファイルやフォルダを選択した状態のクイックアクションのリストの中に表示されます。

 

 

 

クイックアクションは、どのアプリケーションでどのオブジェクトが対象かを、それなりにちゃんと判断するので、ファイルやフォルダを対象とするのなら、「認識させるためにも」上述のオプション指定は必須になる‥‥みたいですネ。

 

たとえ選択項目を処理する場合(=ファイル選択のプロンプトを経なくても)は、「自動(ファイルまたはフォルダ)」を選んでおくと良いみたいです。

 

Finder上でファイルやフォルダを選択した時点で、入力ソースの指定は終わっていますので、「このアクションの入力を無視」にしてもちゃんと正常に処理が進行します。

 

 

ちなみに、サブルーチンも使えます。いつも通りに。

 

 

残念ながらpropertyは設定できるものの、前回の値を記憶せず、毎回初期化されるみたいです。その点は注意点ですかね。

 

 

 

このブログに掲載する画像は、必ずJPEGに変換してアップロードするのですが(WikipediaやAmazonは直接リンク)、項目を選択して右クリックで簡単にJPEG変換スクリプトが呼び出せれば手軽で良いなと思っていました。

 

クイックアクションで呼び出す方法を調べぬまま今まで来て、ようやくそれが今日可能になりました。‥‥もっとはやくやっとけば良かった。

 

こんな感じに簡単に変換できるようになりました。自作のJPEG変換スクリプトを実行してみます。

 

 

 

変換後にオリジナルとペアになるように、単純に変換前のファイル名に拡張子をつけてますが、もちろん、行儀の良い名前で変換もできますヨ。

 

 

新規項目の命名規則は自分で好きなようにプログラムできます。

 

アイコンがスクエアになるのはご愛敬。最近(=Catalina)、なぜかこうなっちゃたんだよネ。原因は調べてないので知りません。アイコンを作り直す自動処理まで作らなくても、いつか改善されるんじゃないかと思ってます。

>解決しました。sips上でアイコンを追加する(-iオプション)のをやめて、Finderに任せることにしました。-iオプションで生成されるアイコンがスクエアに変形される理由は未だ不明。

 

ちなみに、JPEG変換はsipsコマンドでdo shell scriptで実行してます。つまり、Automator>AppleScript>Shellという流れです。画質とリサイズが簡単なUIで指定できるようにプログラムしてあります。TIFFやPNG、TARGAへの変換も可能です。私は昔からsipsを愛用してます。

 

 

 

Automatorは使わずにきましたが、クイックアクションへの移植だけでも、Automatorは有用だと言うことがわかりました。

 

特に、AppleScriptなりシェルなりで自動処理を自作してきた人は、右クリックでも呼び出せる便利な自動処理へと、Automatorで変換できますヨ。

 

AEPファイルを選択して、ライセンスをもたない(というか、正規版の親ライセンスを継承した)レンダリングエンジン版に、aerenderでレンダリングさせるクイックアクションも簡単に作れそうです。Automatorを経由してシェルに命令を投げれば良いだけですからネ。

 

監視レンダーはAdobeの流儀にキッチリ合わせないと動作しないですが、aerenderなら「UIと編集機能のない実行専用のAfter Effects」として動作するので、コマンドさえ使いこなせば1つのライセンスで自分なりのレンダーファームを組めます。監視レンダーに束縛されずに。

 

 

 

話はズレますが(毎度のことか)、aerenderを使って、レンダーガーデン的なものを作ろうと考えています。必要は発明の母。

 

2000年前後の再来はレンダリング事情にも及んで、もはやMacだのWinだのプラットフォームなど超えて、あらゆるマシンのリソースをレンダリングに活用しないと、4KHDR時代の新アニメ技術には間に合いません。2Kテレビ作品のレンダリング時間など比較にならないくらい、時間がかかるようになります。CS6を使っていられるのもリミットが来ましょう。

 

2020年代にAppleScriptを積極的に使おうとは思いませんが、自力開発の必要性は高まるでしょう。

 

去年見たTシャツの画像で、

 

原価で欲しけりゃ自分で作れ

 

‥‥というのがありました。その通りですネ。

 

まあ、原価とまでは言わなくても、開発能力のない集団は、どんな些細な処理でも金を支払って出来合いのアプリケーションをいくつも買い揃えて、使い分けて組み合わせる手間を負いましょう。

 

でなければ、自力開発できる能力を備えるしかないです。PhotoshopやAfter Effectsはともかく、レンダーガーデンのようなソリューションは、自分たちで作っても良いと思いますヨ。自分たちが一番使いやすいように作ることができるんだから。

 

 

 

開発の旅路に終わりなし。

 

 

 


IFS()がない

NumbersにはIFS()もないのか。う〜ん、面倒。

 

4分岐の場合、

 

=IF(条件式,TRUEの結果1,IF(条件式,TRUEの結果2,IF(条件式,TRUEの結果3,FALSEの結果4)))

 

となって、何とも読み辛いなあ‥‥。

 

しかも、0から9はA、10〜19はB、20〜29はC、30以上はD‥‥みたいな場合は、$A2を参照する場合、

 

IF($A2>30,"D",IF(AND($A2<30,$A2≥20),"C",IF(AND($A2<20,$A2≥10),"B","A")))

 

‥‥って、めちゃくちゃ読みにくいです。

*正確には、「どれにも当てはまらない場合は"A"」ですネ。-10で空白でもAになります。Numbersの場合、エラーが返ると、"D"になるようです。

 

どれがどのかっこ閉じか、書いてて解らなくなります。

 

Numbersは関数の追加更新が弱いですネ。こんな時は、Googleスプレッドシートに移行したくなりますが、ユーザの保守ではどうにも手出しできないのが、ネットのサービスです。最近、ジオシティーズもYahooブログも終了して、データが閲覧不能となったのは記憶に新しいところです。確実なのは自分のローカルに保存しておくこと‥‥です。

 

時代についていけなくなっても、最悪、マシン環境一式をアップデートせずに隔離して保全すれば、データの吸い出しができますもんネ。

 

Googleが「や〜めた。終了!」と言っても、ローカルのソフトウェアなら、即崩壊にならずに済みます。ネットサービスは本体ではなく、エイリアスくらいの気持ちで使うのが適当だと感じます。

 

あてにならないネットに頼るよりも、ローカルのNumbersでも入れ子でIFS的な処理は可能なので、今は我慢して使います。

 

 


TEXT()

しばらく経つとすぐに忘れる、NumbersにTEXT関数が存在しない件。

 

TEXT関数とは、1や15や209などの数値を、0001, 0015, 0209 ‥‥に書式を揃える表計算の関数です。

 

何か、代わりになるものはないかと、検索をしてはみるものの‥‥。

 

ないもんはない。

 

ならば、他の言語の時のように、自分で工夫して「桁揃え」を作れば良いです。

 

‥‥って、似たようなことを以前、このブログでも書いた記憶があるなあ‥‥。

 

 

 

例えば、行番号を2020年の末尾「20」と組み合わせて、「20-001」にしたければ、

 

"20-"&RIGHT(1000+ROW(),3)

 

もしヘッダ行で既に1行使っていて、カウントを1つ差し引きたければ、

 

"20-"&RIGHT(1000+ROW()-1,3)

 

ですネ。

 

暗黙の型変換で、1001は"1001"となり、右から3文字抜き出せば、"001"ですわ。原始的な方法。

 

もう20年前以上から、各言語でこのやりかたで桁数を合わせています。どんな言語でも使えます。

 

ちなみに、1000を作り出す場合は、10^3、つまり表計算だとPOWER関数を使って、

 

POWER(10,3)

 

で、桁数から1000や10000を作りだすことができます。3桁の000を作る時は、10を3乗して先頭の1を削れば000が生成できます。

 

なので、表の2行目から、20-001=3桁の001, 002, 003...を作り出す場合は、

 

"20-"&RIGHT(POWER(10,3)+ROW()-1,3)

 

ですネ。

 

まあ、明らかに、TEXT関数のほうが文字が短くてスッキリしてますが、Numbersにはないんだからしょうがない。

 

 

 

年末に、次の年の表計算へと更新する際に、BD-Rの一覧などで001, 002, 003...という書式が必要になるのです。ゆえに、年末にいつも、TEXT()でひっかかっている気がします。

 

私は数年来、Numbersをデータベース代わりにして、ディスクなどの整理をしています。個人レベルの整理整頓や記録には、データベースのサーバを立てるよりも、表計算で記録したほうが手軽です。簡単に内容を検索できますし、ソートも簡単、変換が必要になった際はTSVか何かで書き出せば済みますしネ。

 

 

 

 

私は1年でだいたいBD-Rを100枚くらい焼いているようなので(Numbersで記録して自覚しました)、データベース的には大した件数ではないです。

 

ただまあ、整理整頓の記録云々より、こうして焼いて保存して管理しているBD-RやDVD-Rのビデオって、見たいと思った時に果たして再生装置が健在か、ディスクの状態は良好か、もしかしたら、未来的に見れないディスクを焼いて保存するという、ものすごく無意味なことをしている予感もします。

 

しかし、テレビを年がら年中見ているような生活ではないので、見たいと思っている番組は、後で見る「可能性」のために、とりあえず保存するしかないです。

 

ちなみに、私のソニー製のBDレコーダーは、なぜかソニーブランドのBD-Rがほぼ全滅(=「フォーマットできない」と拒否される)、相性が良いのは、ビクターと三菱(バーベイタム)です。アマゾンの商品レビューを読むと「ビクターはダメ」「三菱ダメ」とみんな状況が激しく異なるんだなあ‥‥と、相変わらずの「相性」問題に少し気が重くなります。

 

*「相性」‥‥とか、2020年になっても、そんなこと言ってのるのは、ちょっと情けない。ディスクのブランドは、まさに「賭け」そのものです。

 

 

バーベイタムのBD-Rは安くていいですが、2020年代はいわゆる4層だか5層だかの128GBのBD-Rも普及するのかな??

 

円盤がそもそも存続するのか、未来は予測できない部分も多いですが、大容量化の波はこれから先もどんどん進行していくんでしょうネ。

 

 


スクリプトの刑に処す

作業が活気付いてくると、日々の雑事はたとえ些細なレベルでも面倒で厄介です。ちょいちょい作業の腰を折るので。

 

現在、新しいタイプの作画技術ではタイムシートをクラウドの表計算で記しています。一方、原画上がりに相当する作画上がりはPSDファイルのレイヤー構造で、規則(階層や名称など)を定めてファイルを出力しています。

 

つまり、PSDファイルのレイヤー構造は、セル重ねの構造であり、彩色作業枚数でもあります。

 

新しい技術ではもはや「ABCDE」というセルの名称は廃止し、実際のキャラの略語で表し、各パーツと内容を、レイヤー名で記しています。

 

例えばタローの顔と髪の毛の線画なら、

 

taroというレイヤーセットの

face.line

hair.line

 

‥‥といった具合です。

 

これらは、アクションシート上では、

 

taro as contents

face as Obj ID

hair as Obj ID

 

‥‥のように表記されます。‥‥‥というか、そのように記述しなければ、次の工程の作業者が理解できません。ちゃんと階層構造も名前も正確に記さなければ、「これは誰の髪の毛?」ということになります。

 

‥‥まあ、絵の内容を見れば、彩色作業者さんは良きに計らってくれるのですが、だからといってレイヤー名やレイヤー構造や伝票の表記を滅茶苦茶なまま渡してしまうのは、甘え過ぎを通り越して未来の作業体制の不安にもなりましょう。

 

ちゃんと規定して整然と取り回すフローを確立するのは、コンピュータを導入した後だからこそ、改めて、重要な取り組みとなります。

 

 

とはいえ。

 

こうした事務的な「レイヤー名 to 表計算の記述」を手作業でやると、地味に面倒。

 

大した所要時間ではないですが、文字を打ち間違えないように神経を使いますし、もしかしたら、レイヤー名を書き写し忘れる人災も起こりましょう。

 

そんな雑事は、

 

スクリプトの刑に処す

 

‥‥です。コンピュータの一番得意な、1文字も間違えずにコピペする能力を使わない手はないです。

 

Photoshopのレイヤー名を順々に取得して、promptのテキスト欄に書き出せば、後はコピーして、表計算に「内容だけペースト」すれば、一番面倒な「レイヤー名を書き写す」作業を自動化できます。

 

まあ、一番良いのは、そもそもアクションシートと連動してAfter EffectsやPhotoshopが動作することなのですが、今はそんなに欲張らずに、地道に面倒な手間を軽減することで確実にミスと時間消費を抑えます。

 

 

エレガントな統合作業環境を目指すのは、見果てぬ夢として抱き続けて、今は、とにかく人の時間を奪う雑事を、「思いついたらスクリプト」でプチ自動化して、どんどん新しい取り組みによる映像制作を進めましょう。

 

単に第1階層のレイヤー名だけを取得するなら、

 

var adys=app.activeDocument.layers;
var text="";
for (var i=0;i<adys.length;i++){
    text=text+adys[i].name+"¥r";
}
prompt("レイヤー名の一覧です",text);

 

‥‥と、改行(バックスラッシュとアール)で区切ったテキストを生成できます。

 

まあ、このままだと、フレームのレイヤーや使わないレイヤーや背景レイヤーまで取得しちゃいますので、visibleを使うなり、レイヤーセットで仕分けるなり、名前で判別するなり、適宜工夫して「使えるスクリプト」に変えます。

 

動作の様子は、以下のスクリーンショットのごとく。

 

 

*プロンプトの見た目は1行ですが、改行して下に連なっています。

 

*サンプルのスプレッドシートです。実際は、作業用アクションシートとしてのスプレッドシートの見た目になっています。

*実際はドット以下の「.line」をsplitで削除して、項目名だけ書き込んでいます。「hair」「face」というように。

 

 

 

こんな簡単なスクリプトでも、もしレイヤーが20個あって、そのレイヤー名をスプレッドシートなどの伝票に書き写さなければならない時は、手作業と自動処理で格段の差が出ます。自動処理なら、楽な上にミスも皆無です。

 

HTMLのテーブルや、TSVやCSVでよければ、直にファイル出力することまで、Adobeのスクリプトで可能です。

 

スクリプトは覚えて損はないので、思い立った時に、自分の力で覚えましょう。

 

 

 

毎日毎日、線画ばかり描いて、雑事に振る時間があったら、休息に充てたいです。

 

本業をちょいちょい阻害する雑事は、スクリプトの刑に処すのが一番です。

 

 

 



calendar

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< August 2020 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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