怪しい尺を知らせるスクリプト

アニメの制作現場では、作画が2コマ3コマでタイミングを作る事がほとんどで、ゆえに、カットごとムービーの尺(デュレーション)の傾向は偏ってきます。‥‥というのは、前にも書いたとおりです。

例えば、「4秒19コマ」とか、「5秒23コマ」なんていう尺は、かなり変わった尺です。なので、コンポジットを担当している作業者は、「うわ〜、妙な尺だなあ」と記憶に残ります。

しかし、記憶に無いのに、「5秒23コマ」なんていう尺が存在した場合、「何かの不具合により1コマレンダリングできてない」などの「障害の可能性」が高くなります。

今はQTでレンダリングする事が多くなったので、あまり「23コマ」などの「間違った尺」は見かけなくなりましたが、連番レンダリングではたまに発生する障害です。レンダリングが中途でエラーで止まり、再スタートした際に、1コマ欠落するのです。

まずいことに、尺の間違いはラッシュチェック(カットごとのムービーを上映してスタッフでチェックする)では見つけにくく、編集さんに渡った時点で初めて「発覚」する事がほとんどです。

間違った尺のムービーを度々、編集さんに渡していると、「いい加減な仕事しやがって」と信用を失います。なので、事前に尺間違いがないか、ちゃんと検査してから渡すのがベストです。

厳密な検査は、やはり、確固としたデータベースと照合するのが必定ですが、レンダリング時の障害から発生した類いの尺間違いは、コマ数を調べるだけでも結構「見分けられ」ます。文頭で書いた、現場の慣習による「尺の定番」が存在するからです。

今回は、尺のコマ数をチェックするスクリプトを書いてみます。現場では、実際のファイルから読み出して尺のチェックするのですが、まずは、架空の尺のリストを用意して、「検査エンジン」がうまく動くかを試してみます。

スクリプトは以下。今回はちょっと長めですが、構造自体は簡素です。

--ここから

--架空のカットの尺のリストです。実際には、QTから取得したり、連番ファイル数から取得します。
set cutList to {{cutName:"#10-c101", duration:"3+0"}, {cutName:"#10-c104", duration:"5+12"}, {cutName:"#10-c106", duration:"2+6"}, {cutName:"#10-c123", duration:"1+18"}, {cutName:"#10-c125", duration:"0+5"}, {cutName:"#10-c155", duration:"2+18"}, {cutName:"#10-c158", duration:"6+21"}, {cutName:"#10-c160", duration:"8+0"}, {cutName:"#10-c161", duration:"5+23"}, {cutName:"#10-c183", duration:"3+12"}, {cutName:"#10-c200a", duration:"2+2"}, {cutName:"#10-c200b", duration:"4+1"}, {cutName:"#10-c202", duration:"3+12"}}


--警告をおこなうための仕組みをつくります
--matchNumbersは、コマ数の番号
--dialogはそのコマ数に対するコメント
--levelは危険度レベル(level 1 を最安全レベルとして、最も危険なレベルを6としました)
set lev1 to {matchNumbers:{0, 12}, dialog:"正常と思われます.", level:1}
set lev5 to {matchNumbers:{1, 5, 7, 13, 17, 19}, dialog:"少々危険なコマ数です. 念のため尺の再確認をお勧めします.", level:5}
set lev4 to {matchNumbers:{2, 4, 8, 10, 14, 16, 20, 22}, dialog:"2コマベースならあり得るコマ数です.", level:4}
set lev3 to {matchNumbers:{3, 9, 15, 21}, dialog:"3コマベースならあり得るコマ数です.", level:3}
set lev2 to {matchNumbers:{6, 18}, dialog:"2コマ3コマ共通のよくあるコマ数です.", level:2}
set lev6 to {matchNumbers:{11, 23}, dialog:"危険なコマ数です. 尺の確認を強くお勧めします.", level:6}
set levList to {lev1, lev2, lev3, lev4, lev5, lev6}

set aColors to {{0, 0, 0}, {0, 0, 10000}, {0, 20000, 0}, {0, 20000, 0}, {50000, 20000, 0}, {50000, 0, 0}} --警告色の設定です

set numberDB to {} --0から23のコマ番号に対する、危険度レベルを設定するために、まず空のリスト「numberDB」を作ります

repeat with num from 1 to 24
    set numberDB to numberDB & {num} --「numberDB」にまず1から24で埋めます
end repeat
repeat with lev in levList
    repeat with num in matchNumbers of lev
        set item (num + 1) of numberDB to level of lev --「numberDB」に危険度レベルを当てはめます
    end repeat
end repeat
--以上で「numberDB」=各コマ番号に対する危険度レベルリストが完成しました

--いよいよ、尺をチェックして結果をテキストエディットに表示します
tell application "TextEdit" to set doc to make new document --新規書類をテキストエディットで作ります
my writeTextEdit(doc, "尺の端数をチェックしてみました!" & return & return, {0, 0, 0}) --1行目のコメントを書き込みます

repeat with dur in cutList --カットリストを順々に処理します
   
    set durationInfo to my calcFrames2(duration of dur, 24) --カットリストの尺情報を尺の分析ルーチンに投げて、結果を受け取ります
    set dispFr to (characters 2 thru -1 of ((10000 + (frames of durationInfo)) as Unicode text)) as Unicode text --フレーム総数を4ケタ表示にします(テキストエディット上できれいに表示させるため)
    set basicText to cutName of dur & tab & (displayText of durationInfo) & tab & dispFr & tab --書き込む基本情報を生成します
   
    if frames of durationInfo < 12 then --もし尺が12コマ未満だった場合
        my writeTextEdit(doc, basicText & "尺が短過ぎるかも知れません. 念のため尺の再確認をお勧めします." & return, item 6 of aColors) --‥‥のように書き込みます。警告色は「item 6 of aColors」〜つまり最危険度の色です
    else
        set myLevel to item ((framesCount of durationInfo) + 1) of numberDB --コマ番号を「numberDB」に照らし合わせて、当該の危険度レベルを得ます
        my writeTextEdit(doc, basicText & (dialog of item myLevel of levList) & return, item myLevel of aColors) --危険度別のコメントを書き込みます。テキスト色も危険度レベルに合わせた色にします。
    end if
   
end repeat

tell application "TextEdit"
    set bounds of window 1 to {20, 20, 720, 520} --最前面のウィンドウ(つまり結果を書き込んだ書類)のウィンドウ位置と大きさを見やすいように調整します
    activate --テキストエディットを最前面に表示します
end tell
--テキストエディットの表示を確認してください
--以上でメイン部分は終了です。


on calcFrames2(_durText, _fps) --前回使ったルーチンを使い回しています
    set delim to AppleScript's text item delimiters
    set AppleScript's text item delimiters to "+" as Unicode text
    set textitems to text items of (_durText as Unicode text)
    set AppleScript's text item delimiters to delim
   
    if length of textitems > 5 then return false
   
    set timescale to {1, _fps, _fps * 60, _fps * 60 * 60, _fps * 60 * 60 * _fps}
   
    set fc to 0
    repeat with i from 1 to length of textitems
        set textitem to item -i of textitems
        try
            set fc to fc + (textitem as integer) * (item i of timescale)
        on error
            return false
        end try
    end repeat
   
    set arr to {}
    set modfc to fc
    repeat with i from 1 to ((length of timescale) - 1)
        set arr to arr & modfc div (item -i of timescale)
        set modfc to modfc mod (item -i of timescale)
    end repeat
   
    set sec to (fc div (item 2 of timescale)) as Unicode text
    set frDisp to (characters 2 thru -1 of ((100 + modfc) as text)) as Unicode text
   
    return {frames:fc, durationText:(sec & "+" & (modfc as text)) as Unicode text, displayText:("(" & sec & "+" & frDisp & ")") as Unicode text, daysCount:item 1 of arr, hoursCount:item 2 of arr, minutesCount:item 3 of arr, secondsCount:item 4 of arr, framesCount:modfc, secondsText:sec, framesText:frDisp, fps:_fps}
end calcFrames2


--テキストエディットに文字を書き込むルーチンです
on writeTextEdit(_doc, _text, _color)
    tell application "TextEdit" to make new paragraph at the end of _doc with data _text with properties {font:"HiraKakuProN-W3", color:_color, size:14}
end writeTextEdit

--ここまで


AppleScript初心の場合は、読み切れないかも知れませんが、詳細な解説はいずれ。


上記スクリプトを実行すると、以下のような検査結果がテキストエディットを用いて表示されます。危険度が増すほどに、テキスト色が赤に近づいていきます。




架空ではなく、本番の作業では、上記のようには色とりどりにはならないでしょう。大体、黒か緑の文字で埋まるはずです。その中にあって、たまに赤い文字が1行あると、その行だけが異様に目立って、ユーザ(例えば撮影監督)に知らせてくれます。

コンピュータはあくまで「判断をユーザに求めてくる」だけです。意図された「5+23」なのか、意図しない「5+23」なのかは、人間が判断します。タイムシートが「5+23」だったら、「うん、そうなんだよ。中途半端な尺なんだよなぁ」と自分の中で念押しできます。

スクリプトのプログラム文を読むと、コマ番号に対する危険度レベルとコメントを設定しているのが解ります。その「からくり」通りに、スクリプトは尺を判断し、テキストエディットでユーザに告知します。

これは、「作業の内容」や「作業の慣習」をもとに、当該の様々な「値」を、プログラムで処理して判断する、初歩的なスクリプトです。こうした事をどんどん積み重ねていけば、コンピュータは、まるで介護犬のように、ユーザに色々と「尽くして」くれる存在になります。

少なくとも、私はこのようなプログラムを作業に取り入れたおかげで、格段にミスを減らし、格段に「映像表現に専心」できるようになりました。

映像作りは1枚絵を描くのに比べて、煩雑で事務的な作業が多過ぎます。‥‥で、それは減らせません。必要な雑務なのです。だったら、その雑務を「どう処理するか」を考えれば良いのです。

映像を作りたいのなら、思いのままに映像を作れるよう、環境を整えるのが「当たり前の事」です。雑務に自分の時間を搾取されっぱなしに放置しておくと、いつまでたっても本腰を入れて取り組めないのですヨ。

テキストエディットを操作してみる

少人数で映像制作をしていると、手弁当で各自が適宜制作管理して‥‥なんて考えがちですが、全くのナンセンス、「やるべき事」と真逆の行動です。少人数グループは、制作進行と呼ばれる制作を管理するスタッフが立てられない事が多いので、実は一番、その「制作」部分が甘くなり脆弱になるのです。そして、その甘さはまんま、映像のクオリティに影響します。

少人数制作ほど「誰も制作を管理していない」状況に陥り、土壇場になって「あれがない」「これが抜けてた」などの醜態をさらす事になります。プロ集団が「制作スタッフ」と呼ばれる人員を配置するのは、ちゃんと大きな意味があるのです。

私は2〜3人で作業する事がありますが、「人数が少なくて小回りが利く」のは確かにそうですが、代償として「誰も面倒を見てくれない」状況が待っています。なので、私が編み出したのが「コンピュータに面倒を見てもらう」制作手法です。まだ不完全なシステムではありますが、コンピュータに管理を委任するようになって、何よりもまず随分楽になりましたし、ミスも大幅に減りましたし、精神的にも余裕が出るようになりました。

コンピュータによる創作サポート体勢が必要なのは、まずは個人、少数人数の制作規模なのです。世間では全く逆に考えられていますが、ネ。

制作システムって、大所帯の会社が導入するものだとタカを括っていませんか。大所帯の会社は、いざとなればマンパワーでこなせますが、少人数・個人のマンパワーは悲劇的とすら表現できます。制作システムの「守護」が必要なのは、むしろ、個人や少人数なんですヨ。

ちなみに‥‥コンピュータを制作上の強い後ろ盾にする‥‥わけですから、その制作システムが「日々、何でもかんでも、いちいち手で入力しないとうまく動かない」ようでは「本末転倒」も甚だしいです。作業の中にとけ込むようなシステムでなければなりません。

現在のコンビニ・スーパーのレジをイメージすると、どういう事か、想像できるんじゃないでしょうか。面倒な作業を肩代わりしてくれるツールが、実はデータベースなどと連携して強いシステムをどんどん作っていく‥‥というのが、好ましいのです。制作システムにこき使われるようじゃアウトです。

実は、この「今さらAppleScript」は、各個人が自分なりの作業システムを作るためのきっかけになればと想い、書き綴っているのです。‥‥まあ、ちょっと遠い気もしますが、ちまたには、あまりにも文献が少ないからネ。

今回は手短に、MacOSX付属の「テキストエディット」のスクリプトをちょい、紹介します。

コンピュータが処理している様子は、人間からはまったく伺い知る事はできません。空冷ファンの音が大きくなると、「あ、大変なんだ」とか解る程度です。なので、スクリプトプログラムの文中に「見ている人間がわかるように、文字を表示する」仕掛けを作るのが一般的です。

AppleScriptで文字を表示する手段は、いくつもありますが、今回はテキストエディットを使って、遊んでみます。

以下がスクリプト文です。

--ここから

set cont to "=>
==>
-==>
- - ==>
   - - ==>
       - - ==>
      .       - - ==>
   .              .   - - ==>
             .           .    - - ==>
          .           .         .   .   - - ==>
  .            .       .           .            .   - - ==>
                  .         .                                      - - ==>
         .                          .        .       .                             - - ==>
                                 .                          .        .       .                             - - ==>
  .        .               .   .      .             .            .
.     .           .      .        .        .     .
    .           .      .     .     .
.         .    . 
.    .
"

set AppleScript's text item delimiters to "
"
set cont to text items of cont
set AppleScript's text item delimiters to ""

tell application "TextEdit"
    --activate
    set doc to make new document at the end
    set bounds of window 1 to {60, 60, 1060, 260}
    tell doc
        make new paragraph at the end of it with data item 1 of cont with properties {font:"Courier-Bold", color:{40000, 0, 0}, size:14}
        delay 2
        repeat with txt in cont
            delay 0.1
            set paragraph 1 of it to txt
        end repeat 
    end tell
end tell

--ここまで


上記スクリプトを動かすと、以下のYouTubeムービーのようになります。




‥‥まあ、これ自体に有用性はありません。しかし、文字を書き換えて動かす段取りはわかるかと思います。

次に紹介する予定の、尺のコマ数をチェックして「怪しいかどうかを告知する」スクリプトでも、テキストエディットを使います。

ではまた。

尺とフレーム数、全部入り

前回書いた「尺からフレーム数への変換」は、実際に使ってみると実用性に乏しい事がわかります。制作作業では、フレーム数から尺への変換が必要な場合もありますし、After Effectsのテキストレイヤーに流し込む際に、秒とコマの情報を別々に欲しい場合もあります。

そんな時は、自作のルーチンを強化して、機能アップを図れば良いのです。

ユーザが「00+00」「00+00+00」の書式で入力した場合と、「0000」のフレーム数を入力した場合の、2つの場面に対応できるルーチンに改良します。

「どうやってみわけんの?桁数?」「IFで分岐?」‥‥とか考えがちですが、実は何も見分けなくても、前回書いたルーチンは「フレーム数の入力に対応」しています。

前回のルーチンは、

  • 6+0
  • 0+144
  • 144
  • 3+72

‥‥のどれでも、正しく処理します。これはAfter Effectsもそうで、人間が繰り上がりを計算しなくても、自動で繰り上げを計算するようプログラムされているのです。「1+18」のカット尺にボールド8コマを足した「1+26」と入れても、ちゃんと「2+2」に変換してくれます。

要は、ベタなフレーム数を計算した後、改めて「00+00」の書式を生成するルーチンに仕立てておけば、「行儀の悪い」入力でも「清書」した値を返してくれます。

また、ルーチンが返す値も単に「フレーム数」だけでなく、様々な情報を返すように強化します。AppleScriptでは「ラベル付きリスト」とか呼ばれるデータで、今回作ったルーチンは以下の値をまとめて返してくれます。

  • フレーム数
  • 尺の汎用的な書式
  • 尺のコマ数(フレーム数)を2ケタ表示にして括弧で囲んだ表示書式
  • 日(普通はいらないよね、こんな単位)
  • 時間
  • フレーム
  • 秒の表示(端数を除いた総秒数)
  • フレームの表示(2ケタ)
  • 計算に用いたFPS

ルーチンを利用する際、上記の中から、ニーズに適合するものを取り出して使います。

で、せっかくなので、単にルーチンを走らせるだけでなく、対話式のプチ「尺とフレームの変換計算」アプリケーションに仕立て上げます。

以下がAppleScriptのスクリプト文です。

--ここから

set res to text returned of (display dialog "尺またはフレーム数を入力してください" default answer "")

if length of res = 0 then
    beep
    display dialog "入力欄が空です." with icon stop buttons {"中止"} default button 1
    return
end if

set res2 to my calcFrames2(res, 24)

if res2 is false then
    beep
    display dialog "入力した文字に問題があります." with icon stop buttons {"中止"} default answer res
    return
end if

display dialog "計算結果は以下の通りです" with icon note buttons {"OK"} default answer "尺:" & durationText of res2 & "
表示書式:" & displayText of res2 & "
フレーム数:" & frames of res2


on calcFrames2(_durText, _fps)
    set delim to AppleScript's text item delimiters
    set AppleScript's text item delimiters to "+" as Unicode text
    set textitems to text items of (_durText as Unicode text)
    set AppleScript's text item delimiters to delim
   
    if length of textitems > 5 then return false
   
    set timescale to {1, _fps, _fps * 60, _fps * 60 * 60, _fps * 60 * 60 * _fps}
   
    set fc to 0
    repeat with i from 1 to length of textitems
        set textitem to item -i of textitems
        try
            set fc to fc + (textitem as integer) * (item i of timescale)
        on error
            return false
        end try
    end repeat
   
    set arr to {}
    set modfc to fc
    repeat with i from 1 to ((length of timescale) - 1)
        set arr to arr & modfc div (item -i of timescale)
        set modfc to modfc mod (item -i of timescale)
    end repeat
   
    set sec to (fc div (item 2 of timescale)) as Unicode text
    set frDisp to (characters 2 thru -1 of ((100 + modfc) as text)) as Unicode text
   
    return {frames:fc, durationText:(sec & "+" & (modfc as text)) as Unicode text, displayText:("(" & sec & "+" & frDisp & ")") as Unicode text, daysCount:item 1 of arr, hoursCount:item 2 of arr, minutesCount:item 3 of arr, secondsCount:item 4 of arr, framesCount:modfc, secondsText:sec, framesText:frDisp, fps:_fps}
end calcFrames2


--ここまで

上記スクリプトを「アプリケーション形式」で書き出すと、いつでも尺の変換計算を確認できるプチAppができます。実行してみると、



ここに何か、尺を入力します。例えば6秒ジャストの尺を色々な書式で入力してみましょう。



結果は、



‥‥とちゃんと正確に計算しております。さらに違う書式で‥‥



‥‥とか、



‥‥などでも、やはり以下の通り、正確に計算して返します。



別の尺でも、



ちゃんと変換します。



さらには、こんな表記もイケちゃいます。



1時間0分0秒0コマ。もちろん結果は、



‥‥ですネ。3600秒は1時間ですから、バッチリ、処理できてます。


仮に、尺以外の入力をした時は、



以下のようにエラー警告をおこないます。




‥‥とまあ、こんな感じで、尺の変換ルーチンに「display dialog」のGUIをくっつけて、1つの小さなアプリケーションにする事もできます。

尺の変換ルーチンは、それそのものは何らUIを持ちませんから(というか、そのように作ったので)、対話式のアプリにしたい場合は、AppleScriptの他の機能と組み合わせてアプリを作ります。After Effectsのレンダーオートメーションと連携して、コンポジションの尺や、テキストレイヤーの内容を書き換える事も可能ですネ。

次回は、尺の変換の体勢も整ったので、「尺が怪しくないか、判断してユーザに知らせる」スクリプトを作ってみます。以下のような「素敵なお知らせ」をMacがテキストエディットを使って知らせてくれます。



AppleScriptはdisplay dialogだけでなく、テキストエディットを用いて告知板にしたり、HTMLファイルを書き出してFireFoxやSafariで表示する事もできますから、ユーザへの「お知らせ方法」の手段はそれなりに豊富です。

ではまた。

尺からフレーム数への計算

アニメ制作現場では、2コマ3コマで動きのタイミングをとる事が多いので、都合、タイムシートでの尺は「傾向が偏って」きます。

例えば、「3+12」(つまり3秒半)なんていう尺は、それこそ耳にタコができるくらいお馴染みの数値です。

そんな中、QTファイルのPDF伝票で「3+11」とか「5+23」とか言う尺を見ると、「なんかやらかしたか?」と直感します。つまり、「何かの障害で、尺が足りてない」的な「危険予測」です。‥‥まあ、危険予測と言っても、既にレンダリング済みのムービーファイルの尺なので、実際は「現物を確認する前の、状況予測」なんですけども。

シートを確認してみると、「うわー、変な尺。ほんとに5+23だよ。1コマ伸ばして6+0にしときゃいいじゃん‥‥」という珍しい状況もあったりします。しかし、そんな変な尺の大体は、レンダリングの何らかの不具合による途中終了、もしくはオペレーション上のミスの場合が大半です。

なので、カットを管理するデータベースと連携しなくても、尺を見るだけで尺の不具合を発見する事ができます。もちろん、全て発見できるわけではないですが、ソフトウェア上で発生したような障害は、大体検出できます。

つまり、レンダリングしたムービーの尺を取得して、「変なコマ数」か否かをチェックするスクリプトを作れば、作業者がいちいちファイルをチェックしなくても、コンピュータが「やばそうな尺を教えて」くれる‥‥というわけです。そうやって、コンピュータを自作ツールで「育てて」いくと、次第に「作業上のパートナー」「ヘルパー」的な役割へとコンピュータが変わってきます。

今回はまず、その土台となる、尺とフレーム数の変換スクリプトを、AppleScriptにて書いてみます。やる事自体は、そんなに難しくないのは、考えればお分かりかと思います。24コマで1秒‥‥というのを、計算すれば良いのですからネ。

アニメ現場の場合、尺は通常、1秒24コマ換算で、「秒+コマ」の書式で書きます。3秒なら「3+0」、5.5秒なら「5+12」です。

尺をフレーム数に換算するのは、例えば「5+12」の場合、

5+12

‥‥を「+」で文字列分解して、

5 12

‥‥の要素に分けます。そして、

(5x24) + 12 = 132

‥‥という計算をしてやれば良い訳です。

ちなみに、After Effectsではコンポジション設定のデュレーションの欄に、「5+12」と入れると、「5秒12フレーム(コマ)」としてちゃんと認識します。さらには、「1+30+0」と入力すると、「1分30秒0フレーム」と認識します。どこまでプラス(+)の連結を受け入れるのか、怖くてやってませんが、AppleScriptでも似た構造で処理してみます。

ちょっと図にのって、「日+時+分+秒+フレーム」という5段階まで受け入れるように作ってみました。‥‥まあ、「日」単位の需要があるとは思えませんが。

my calcFrames("5+12", 24)

on calcFrames(_durText, _fps)
    set delim to AppleScript's text item delimiters
    set AppleScript's text item delimiters to "+" as Unicode text
    set textitems to text items of (_durText as Unicode text)
    set AppleScript's text item delimiters to delim
   
    if length of textitems > 5 then return false
   
    set timescale to {1, _fps, _fps * 60, _fps * 60 * 60, _fps * 60 * 60 * _fps
}
    set fc to 0
    repeat with i from 1 to length of textitems
        set textitem to item -i of textitems
        set fc to fc + (textitem as integer) * (item i of timescale)
    end repeat
   
    return fc
end calcFrames



「on calcFrames...」以下が尺をフレーム数に変換する「自作ルーチン」です。1行目の「my ...」でルーチンを呼び出して処理させます。

1行名の「my...」のかっこ内の「"5+12"」を、「"7+0+0+0+0"」(7日0時間0分0秒0フレーム)に書き換えると、7日=1週間のフレーム数が計算できます。

ちなみに7日間のフレーム数は、1451万5200フレームみたいです。

きりがないので、「1+0+0+0+0+0」(=1年)などの6つ以上の連結の場合は、「false」(偽の値〜「もうダメよ」的な)を返すようにしてあります。

こんな感じで、「処理ルーチン」を自作して、そのルーチンに値を投げ込むと、処理された値が戻ってきます。このやり方は、スクリプトが複雑化する際に、必須となります。

箱絵のコレクション

私は、プラモデルの箱絵が小さい頃から好きで、よく模写したものでした。今も箱絵に対する愛着は変わらず‥‥というか、昔よりも増しているやも知れません。

資料用で買うプラモの他に、ノスタルジーで買うプラモもあって、その場合は、箱が今以上に痛む前に、スキャンした後に保管します。

何せ、30〜40年の月日が経っていますから、印刷の状態は様々な原因で悪化の一途を辿っております。ヤニによる汚れはまだ良いほう(拭けばずいぶん奇麗に取れるから)で、カビ、インクの退色、紙焼け、やぶれ、はがれ、etc...と、出来るだけ早急に今の状態以下にならないように対応します。

私は絵を眺めたいので、もちろん、スキャンしてデータとしても保存します。しかし、スキャンしたそのままの状態では、なかなか鑑賞に堪える画像にはなりません。とにかく、黄ばみが凄くて、絵をまともに眺められないのです。

なので、今までの本業の経験を活かして、補正作業を施して保存します。スキャンの生状態もそのまま残しますし、当然ですが、原版もファイリングして残します。

例えば、つい最近買ったF-4Eは、




‥‥のような状態を、




‥‥のようなクリアな状態に補正してコレクションしました。色温度の危うい箇所とかがありますが、「まずはこのくらいでいいか」というレベルに留めております。Photoshop形式600dpiで保存してあるので、後で気になるところは再調整できます。

スキャン直後のものを見てもらえば解りますが、特に右側の帯のところが、退色と黄ばみが激しく、これを補正するのは、中々のチャレンジではあります。




上図のような状態です。おそらく、日のあたる窓方向にこの面を向けていたのでしょう。幸い、積み重なって保存していたのか、メインのトップ絵は、あまり色あせしていませんでした。

かなり強引な力技で補正して、



‥‥のような感じに仕上げました。実は、「タン」(明るい黄土色)の色調が明るく黄色過ぎるのですが、このくらい直ってればいいや‥‥という事で、フィニッシュとしました。あくまでも自分のコレクションなんで、自分で見てて気にならなきゃ良いという品質基準ですネ。

しかし、なんだかマニアっぽい話ですが、箱の状態を見ると、前のオーナーの性格とか生活習慣が、思い浮かびます。このファントムのキットは、おそらく奇麗に積み上げられておらず、ややルーズに積まれていたのでしょう。部屋は、やや強めの光が差し込む時間帯があり、徐々に退色が進行したものと思われます。収集癖はあるものの、あまり几帳面な人ではなかったのかも知れません。黄ばみが回り込んでないですから、ヘビースモーカーではなかった雰囲気です。

一生出会うことのない見知らぬオーナーから、ショップを通じて、私に引き継がれたキット。

私は、作品にて昇華しようと思っているのです。

宇宙船ペペペペラン

私が小さい頃、家に「ドレミファブック」という音楽絵本がありまして、毎日のようにレコードをかけ、絵を眺めていました。

その中で私が好きだったのは、「ちびくろサンボ」「ないたあかおに」「はくちょうのみずうみ」「ほらふきヤーノシュ」そして「宇宙船ペペペペラン」です。

宇宙船ペペペペランは、抽象絵画のような挿絵でしたが、私は今でも明確に、その時感じたイメージを思い出す事ができます。こずるくて小器用な処世術を身につける前の、無防備かつ、ある種残酷な子供時代のほうが、抽象絵画を感じとる能力は高いのかも知れません。

筋立ては、おじいさんが街にやってきて、子供たちに「昔話のような、未来の話」を聞かせるというものです。話は、地球上が1つの国になった未来に、子供たちだけを乗せた宇宙船ペペペペランが新天地アンドロメダを目指して、宇宙を航行する‥‥と言う内容です。

宇宙船には男女同数の子供が乗っているはずだったが、実は(何かのミスで)男の子が1人多くのっており、男女が思春期を経て結婚するようになると、「弱虫ロン」が1人取り残された。ある時宇宙船に彗星が衝突し、独身で妻帯者ではないロンが船外での危険な修理を引き受ける事になった。修理が済むとすぐにロケットは発進し、ロンは宇宙に取り残され、気が狂れた‥‥という、子供の私には(今思うと)強過ぎるほどの刺激の絵本でした。


‥‥で、最近、エスペラント語の事を人から聞いて、ふと、この「ペペペペラン」の事を思い出したのです。全くエスペラント語の事を知らなかった私(古文書か何かだと思ってた)が、その成り立ちを聞いた後、ふと「ペペペペラン」はエス「ペラン」トのもじりだと言う事に気がつきました。そして、子供の頃に呼んだ「創作絵本」が何を言わんとしてたかが、瞬時にクリアになったのです。

世界に国の境がなくなり、言葉も共通になっても、全ての人間が解り合えて愛し合い幸せになるわけではない‥‥という理不尽などではなく淡々とした現実を、そっと語りかけているのでしょう。これはもっと遡って思いを巡らせれば、自己の「こっち側とむこう側の垣根」は、あらゆる個性に取り憑かれたカラダからは、取り払う事はできない‥‥と言う事ですネ。

ロンがなぜ大勢の女の子の誰ひとりからも愛されなかったのか。作中では、「弱虫」「しし鼻」という理由を上げています。おじいさんの話を聞いてた女の子が「私だったらロンと結婚するのに」とか言うと、他の子が「そしたら、また誰か他の子が余っちゃう」と言います。

恐るべし。ドレミファブック。

子供に何を語ろうとしたのか。何をインプリントしようとしたのか。

今になってしみじみ思うのは、6000万人とも言われる死者を出した未曾有の惨劇とも言えるWWIIを経た人類、その若い世代が自由や友愛に理想を掲げ(例えばヒッピームーブメントのような)、内輪でもめ混乱し、やがて挫折していく様を、この絵本の筋立てに見るのでした。

「子供たちだけで未来の新天地を目指す」というのも、確信的、示唆的です。理想を託された子供たちが、大人になって、どうなったか?‥‥という事ですネ。

この創作絵本の作者は、何か世相から、挫折感を感じとっていたのでしょうかネ。ドレミファブックは、1970年前後の出版なはずですから、例の全共闘絡みの「終盤」です。

創作絵本の中に、自由や友愛の「阿鼻叫喚」が磁気転写されたとしても、何ら不思議ではありませんし、むしろ「大いにありそう」です。

およげたいやきくんも、そんな歌でしたネ。「やっぱり、ぼくはたいやきさ。すこし、焦げある、たいやきさ。オジサン、つばをのみこんで、ぼくをうまそうに食べたのさ。」

レシピにそって、日々、大量に製造される、たいやき。ある日、たいやきは自由を求めて海に逃げ込む。しかし、海は海で、いじわるなサメはいるし、お腹も空く。ふと美味しそうな餌が漂っているのを見て、おもわずパクつく。そしたら、釣り上げられ、もとの世界へと戻されてしまう。結局は、他のたいやきの運命と同様に、オジサンに食べられて一生を終えた。チャンチャン。

なんだろう。この頃の創作家は、大人の社会での無念を、子供に訴えかけようとしてたんでしょうかネ? ‥‥で、私はその子供のなかの1人です。うーむ。

70年代は、そんな風味が数多い時代‥‥ですネ。

ファイルの分別(後)

AppleScriptでファイルの分別をする後半です。ポイントは、

  • 大量処理の場面ではFinderを使わず、高速化する
  • カット名らしき文字列を含むファイルだけを対象とする
  • 特定のファイル形式(今回はDPX)だけを対象とする

‥‥です。つまり、PSDやQT、JPEGは対象から自動的に外し、さらにはDPXファイルと言えどもカット名を含まないものも自動的に対象外とします。

そこそこ長いスクリプト文なので、まずは下記に記します。

(*

まず、手始めに‥‥

本番のファイルを使うのはマズいし、テスト用にAfter Effectsで連番ファイルをレンダリングするのもバカらしいので、「ニセの画像ファイルの連番」を作ってしまいます.

*)

set folderName to do shell script "date +%y%m%d-%H%M%S" --日付&時間の文字列を生成
tell application "Finder" --Finderに命令を開始
    activate --Finderを最前面にする
    set theFolder to make new folder at desktop with properties {name:folderName} --先ほど生成した文字列を名前にしてフォルダ(=テストの作業場所)をデスクトップに作る
    open theFolder --作ったテスト用フォルダのウィンドウを開く
end tell --Finderへの命令終了

set folderPath to theFolder as Unicode text --フォルダをパス文字列に変換する
set countOfFiles to 720 --カット毎の連番ファイル数を指定
set dummyCutNames to {"dummy_02_165_t1", "dummy_01_014_t2", "anime_12_254a_t1", "dummy_02_098_t3", "test_a_211_t3", "test_a_211_t4"} --架空のカット名を生成

repeat with dummyCut in dummyCutNames --ダミーのカットで繰り返し処理
    repeat with i from 10001 to (10000 + countOfFiles) --10001から数え始めて指定ファイル数へ繰り返し処理
        set ofa to open for access file ((folderPath & dummyCut & "_" & ((characters 2 thru -1 of (i as text))) as Unicode text) & ".dpx") with write permission --テスト用フォルダ内にカット番号+4桁連番+拡張子の名前のダミーファイルを作ってアクセス開始
        write "dummyだよん" to ofa --dummyという文字列を書き込む(テキトーな文字)
        close access ofa --ファイルへのアクセスを終了する
    end repeat --繰り返し処理終了
end repeat --繰り返し処理終了

--テストフォルダの中には、5秒前後で数千個のファイル(自動処理のテスト用の偽ファイル)が生成された、はずです.

--故意に他の拡張子のファイルも数種類混ぜてみましょう
--名前でソートした際にごちゃごちゃになるよう、わざとイジワルな名前をつけて、スクリプトの耐久性を見ましょう
repeat with dummyFile in {"A-関係ないPhotoshopファイル.psd", "B-関係ないQuickTimeファイル.mov", "s_全く関係ないJPEGファイル.jpg", "Y_消し忘れたPNGファイル.png", "0-素材のイラレファイル.ai", "testで書き出したDPX.dpx"}
    set ofa to open for access file (folderPath & dummyFile) with write permission --偽ファイル
    write "dummyだよん" to ofa --dummyという文字列を書き込む(テキトーな文字)
    close access ofa --ファイルへのアクセスを終了する
end repeat



activate --このスクリプトを最前面にして
set theResult to display dialog ((length of dummyCutNames) as text) & "カットの合計" & ((countOfFiles * (length of dummyCutNames)) as text) & "ファイルを生成しました" with icon note buttons {"ここで止めとく", "分別を処理してみる"} default button 1 giving up after 20 --処理の続行を尋ねる
tell application "Finder" to activate --Finderを最前面にする(処理の様子を見せる)
if button returned of theResult is "ここで止めとく" then return --ユーザが中止を選択した場合は処理を中止


(*


これより以下がフォルダごとの分別処理です.
回りくどいトリッキーな事をしているように見えますが、「できるだけFinderを大量のファイルに関与させない」工夫ゆえです.

*)

set cutNameSliceStart to 1 --カット名を抜き出す開始番号(アンダースコアで区切った配列のスタート)
set cutNameSliceEnd to 4 --カット名を抜き出す終了番号(アンダースコアで区切った配列のエンド)
set nameExtension to ".dpx" as Unicode text --収拾するファイルの拡張子を設定
set AppleScript's text item delimiters to "_" as Unicode text --ファイル名のリスト分解に備える

set tryCount to 0 --検索ファイルのカウント
repeat --無限の繰り返し
    set tryCount to tryCount + 1 --検索ファイルのカウントを1つ増やす
    try --エラー発生を見越して(故意にエラーを発生させる)
        tell application "Finder" --Finderに命令
            set theFile to file tryCount of theFolder --分別のきっかけとなるファイルを指定
            set theFileName to (name of theFile) as Unicode text --ファイルの名前を取得
        end tell --Finderへの命令終了
    on error --ファイルを検索し終えた場合にエラーが出る
        activate --このスクリプトを最前面に呼び出して
        display dialog "処理が終了したようです.
       
ちゃんと分別されたか、Finderのウィンドウで確認してみてください.

分別対象以外のファイルはそのまま残っています." with icon note buttons {"OK"} default button 1 giving up after 15 --処理終了を報告する
        exit repeat --無限ループから脱出
    end try --故意エラーへの対応終了
   
    if theFileName ends with nameExtension then --もしファイルが対象ファイル形式だったら
        set nameArray to text items of theFileName --ファイル名をリスト(配列)分解
        set fileNameCheckIsOK to length of nameArray > cutNameSliceEnd --ファイル名が規定を満たすかをチェック
        if fileNameCheckIsOK then --もしファイル名が規定を満たす場合
            set tryCount to tryCount - 1 --検索ファイルのカウントを1つ戻す(カウントの空滑りを防止)
            set cutName to (items cutNameSliceStart thru cutNameSliceEnd of nameArray) as Unicode text --カット名をファイル名から抽出する
            do shell script "mkdir " & quoted form of POSIX path of (folderPath & cutName) --フォルダをシェルで作る
            do shell script "mv " & (quoted form of POSIX path of (folderPath & cutName)) & "_*" & nameExtension & " " & quoted form of POSIX path of (folderPath & cutName) --対象ファイルをカット名フォルダに移動する
        end if --ファイル名チェックの「もし」の範囲、ここまで
    end if --対象ファイル形式の「もし」の範囲、ここまで
end repeat --無限ループの範囲、ここまで

set AppleScript's text item delimiters to "" --リスト分解の設定を初期値に戻す

tell application "Finder" to activate --Finderを最前面にする

return tryCount --検索ファイルの最終カウントを結果として戻す


コメントを入れたおかげで、余計、長く感じられますが、まだシンプルなほうだとは思います。やっている事が、単にファイルの分別ですからネ。テスト用の偽物ファイルを作るところからやっているので、長くなっているのですネ。

動作中のスクリーンショットは、こんな感じ。

スクリプトを実行すると、デスクトップに日付のフォルダが自動生成され、その中に数秒後、テスト用のダミーファイルが大量生成されます。

5040個の連番ファイルと、故意に混ぜた関係のないファイル6個。変更日でソート表示されてるので、並びはバラバラですが、ウィンドウ下部の項目数に注目してください。





…実際に作ったのは、上記の通り、5040+6で5046ファイル。

「分別を処理してみる」ボタンをクリックすると、数秒後‥‥

‥‥のような感じで、思惑通り、カット名を持つ連番ファイルだけが、分別されました。イジワルな名前の混在にもメゲず、ちゃんとカット名連番だけを見分けて、新規フォルダを作って格納しています。

種類でソートすると、こんな感じ。

めでたく、終了。5046項目のごちゃまぜファイルが、数秒で、スッキリ、13項目に整理されました。


たとえ、以前にレンダリングしたQTファイルや、とりあえず置いといたJPEGファイルがあっても、「カット名を含む、DPX」以外は処理対象から外すので大丈夫なのです。

また、作品や話数がごっちゃになっていても、「カット名の命名規則に準じて」ファイルを選別するので、問題無いのです。

スクリプトの文中に目を通すと、AppleScript独特の表現もちらほら見えます。「AppleScript's text item delimiters」なんてのは、その最たるもので、私はこれが面倒でイヤなんですが、要は「テキストの要素を分解する文字」の事です。これを操作すると、文字列を任意の文字で分解できるようになります。

ファイルを分別するくだりは、目の前にあるものを処理して、もし対象外のものだったら、一歩進む‥‥という、何とも可愛い動作にしてあります。一歩進む‥‥とは、「自分のいる位置のカウントを1つ足す」という事ですが、AppleScriptには「++」なんてシャレたものはないので、set その変数 to その変数+1 みたいにして、地道に書きます。

Finderは言わば窓口。そこに大量の物品を持ち込んでもパニックになるだけです。窓口で簡単な手続きを済ませたら、後は頼りになるバックヤードでドカンと大量処理するのです。

しかし、AppleScriptに馴れていない人が、上記スクリプト文を読んでも、理解できないかも知れません。コメントだけ読んで、流れを汲んでもらえればと思います。文中の細かい説明はまたいずれ。

今回はダミーファイルまでも作るデモ的なスクリプトですが、文中後半の「ファイル分別ルーチン」を抜き出してちょっと手直しすれば、汎用性があって何度でも使い回しのできる、連番分別アプリケーションに育てる事ができます。

次回は、似たようなスクリプトを使って、「作業者にツッコミをいれる」スクリプトを作ってみます。データベースを使わなくても、スクリプト自身が判断して、「ほんとに、その尺で合ってる?」とユーザに確認してくるのです。

ではまた。

ずっと欲しかったプラモ

子供の頃、「畏怖の念」を持って眺めた箱絵のハセガワのプラモデルを、ようやく入手できました。F-4Eの「シャークティース」のパッケージのプラモデルで、たしか当時の価格は400円だったと思います。私が小学校3〜4年の頃、ですネ。

そのプラモデルは3つ離れた兄が買ってきたもので、逆ガルで鋸翼の主翼、機首のバルカン砲、ベトナム迷彩、爆弾をしこたま翼下に搭載し、トドメは機首の恐ろしげな顔。戦闘爆撃機の凶暴で粗野なイメージを体現する箱絵、そしてキットでした。

当時の特撮やアニメヒーローの「かっこいい」とは、全く別次元の強烈な印象を、ハセガワのいち商品から受けたのです。

実機のプラモデルは、「子供に人気がでるように」デザインはされていません。プラモデルが売れるように、マクドネルダグラス社がF-4を作ったわけじゃないですもんネ。

しかし、なんでまた、子供に「飛行機や戦車が人気があるのか」。「ロボットやヒーローが敵を討ち果たすストーリーを見て、歓喜するのか」。

カッコいいと思わせる要素って、何なの?

大げさに言えば、そんなような部分を、子供ながらに感づいて意識するようになったキッカケが、このプラモの箱絵かも知れません。だって、このF-4ファントムの攻撃して殺傷する相手は、絵に描いたような悪人顔の秘密結社の戦闘員じゃないですからネ。

私の母系の家系は昔から浅草にあって、祖父母が結婚した時に高円寺に居を構えたのですが、母は子供ながらに東京大空襲で空が真赤になっているのを見たと言っております。私は「その頃はもう群馬に疎開して、高崎の大空襲と記憶違いなんじゃないの?」と聞いたのですが、「よくわからない」らしいです。高円寺の住所もわかっているので、今度、「その地域が無事に焼け残ったのか」を調べるつもりですが、何とも壮絶な話です。

飛行機が大挙して飛来して、こともあろうに、爆弾(というか焼夷弾)を落としていく‥‥んですから、よく考えてみれば、凄い事です。「公然と人間を殺しにやってくる」のですから。

なのに、なぜ、カッコいい? そう感じる?

子供時代の無垢な部分と残忍な部分。大人も、子供に対して友愛や平和を説く一方で、小さな事から大きな事まで争い事を止める事はない。

子供心に、「自分は、人間の呪いの中に、居る」という事を、うすうす、感じさせた「思い出深い」キットなのです。

F-4Eのパッケージ。シャークティースの口の中が真赤で、陰惨な印象すら受けます。思い出すのは、ゴヤのこの絵。

子供の頃、怖過ぎてイヤだったなぁ。。。いや、今見ても、充分、怖いですワ。



ルーズリーフ、万年筆

久々にルーズリーフや大学ノートを買いました。何年ぶりだろうか。おそらく、10年以上は買ってなかったはず。

文字を書かなければならないので、必要に迫られて買ったのです。文というよりは、文字、です。

さらに、万年筆も買いました。ペリカンとラミーの2本。ペリカンのは、前から気にいっている廉価モデルを買い足し。ラミーのは実は初めて注文したので、楽しみです。

今の私は、何だか両極端な性質があります。かたや、紙と黒鉛を吟味し、万年筆で字を書き、一方でコンピュータで絵を動かしキーフレームの山をかきわけ、現行のマシンが遅くてじれったい衝動にかられる‥‥という。

多分、今の私は「中途半端な踏み込みで、『デジタル』をやりたくない」のでしょうネ。ごまかすような使い方をしたくないんだと思います。「アナログ」も「デジタル」も。



ファイルの分別(中)

ドロップレットAfter Effectsで出力した連番やQTを整理するスクリプト。実は、運用やワークフローがどれだけ考え抜かれているかを示す「試金石」のようなものです。

スクリプトでうまく処理できない運用ルールやワークフローは、未発達で穴が多い、もしくは、理路整然としてなくて複雑である証拠です。複雑怪奇な運用ルールは、コンピュータだけでなく、人間も往々にしてミスを連発します。「IF分岐が多過ぎる」と言いますか。

誰もが短時間でルールを理解できる運用方針は、その運用の過程で働く人間に優しいのはもちろんの事、コンピュータでも処理しやすいのです。

複雑で大風呂敷を広げたフローは、素人さんは「すげー」とか関心しがちですが、多様な現場に接してきたプロの目からすると、「メンテが大変そう。もっとシンプルにできなかったんだろうか‥‥」と気の毒になるフローです。複雑なフローはそれだけで、時間やお金、体力とメンタルに、負荷を及ぼすからです。
*納得ずくで背負い込む覚悟の作品もあるでしょう。その場合は金と人と時間に対して覚悟する‥‥という事ですネ。

シンプルで澱みがなく、INOUTが明確であるのが理想ですが、「一生懸命取り組むほどに、フローや運用を複雑にしてしまう」事も少なくありません。運用上の笑い話で「チェックが甘いからこのようなミスが出るのだ。ならば、ちゃんとチェックしたか、さらにチェックするようにしよう。」なんてのがあります。「なぜミスが出たか」を解消しようとはせず、チェックだけを何重にも上乗せしていく‥‥のは、誰もが「馬鹿っぽいやり方」だと感じるはずなんですが、結構、ありますよネ、そういうの。

さて‥‥。「地獄絵図のようなごちゃ混ぜのフォルダ」内から、連番ファイルを抜き出し、カットごとのフォルダにまとめるスクリプトですが、まずはファイル名から「カット名」(今回の場合「クリップ名」と呼んでも)を抜き出す方法から。

anime_01_123_t1_0001.dpx

上記のファイル名は、「anime」という作品略号の、「01」話、カット「123」、テイク「1」の、連番1フレーム目のDPXファイルです。

まず、ドットで分解すると、

anime_01_123_t1_0001 dpx

‥‥の2要素になり、さらに分解した1番目の要素を、アンダーバーで分解すると、

anime 01 123 t1

‥‥のように、カットの情報をカテゴリで分解できます。

今回の分別処理は、「作品、話数、カット番号、テイク」をひとかたまりとして扱い、分別しようと思います。つまり、

anime_01_123_t1_0001.dpx から anime_01_123_t1 を抽出したい

‥‥わけです。

何が入っているか特定できない状況において、ファイル名から「作品_話数_カット番号_テイク」を抽出し、その文字列をキッカケにしてファイルを収集する‥‥わけですネ。


さらに次。

何千項目入っているか数がわからないフォルダを相手に、Finderでファイル数を数えようとして「count of files」なんてやったら、またレインボーカーソルかも知れません。ここはひとつ、「ファイルの総数なんて数えないで、先頭のファイルからどんどん喰っていく」やりかたで処理します。「わんこそば」のように、「目の前にある項目を処理していく」やりかたです。

何度も書いてきた通り、大量の項目を処理しようとすると、Finderは破綻するわけですから、Finderには項目を1つだけ渡して順次処理するようにすれば、破綻せずに済みます。あくまで「使いよう」を考えます。

処理ルーチン上で、ファイルをひとつずつ処理し、条件に合った場合は、ファイルを収集して新規フォルダに移動します。これを、ファイルに全部目を通しきるまで、繰り返して処理します。

処理に適合する条件は、

  1. DPXファイルであること
  2. カット名を含んでいると予測できるもの

‥‥の2種です。もっと条件を増やしても良いでしょうが、カット名(らしき)を含んでいて、DPXファイルであれば、かなり特定できますから、今回はシンプルなこの2つの条件だけで処理します。

  • DPXファイル→ファイル名が「.dpx」で終わる
  • カット名を含んでいる→アンダーバーで文字列分解して要素数が5以上のもの

‥‥まあ、条件が甘いような気もしますが、運用とワークフローの前提が「そこそこ、要素を絞り込んでくれてる」ので、これでも充分上手くいきます。



‥‥と思ったら、またこんなに文がかさんでおる。なので、締めは次回に。




calendar

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
<< October 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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