shakeがApple ProRes422入力に対応したようだ。

先日のプロアプリケーションアップデートで、shakeがApple ProRes422入力に対応したようだ。
よかったよかった。
これでcolorがnVidiaのグラボにも対応してくれると、うちのMacPROとしてはありがたいのだが。

HD素材のアイドルDVDでカラリングを施してみた

★全HD素材のアイドルDVDの仕事来ました。

まだまだSD映像の仕事ばかりとは言え、HDへの対応も現実的・実際的に考え始めないといけないなと思う昨今。たまに短い尺でHD素材を試したりもしてきたが、ついに来ました全素材がHDの編集仕事。とはいっても納品はやはりSDですが。
それは久々のタレントDVDのまるごと編集仕事。今回の素材はほとんどがHDV、それに僕が撮影したDVCPRO HDが少し混ざっているという全素材がHD。今までHD素材を使用しても尺が短かったので力技で何とかしてきたが、今回は完成尺45-50分ぐらいのもの、力技では対応しきれない。そこで編集を始める前に（実際は始めながら）自分なりに今回のワークフローを考えてみることにした。


★HDVを粗編してSD サイズに。コーデックApple ProRes 422を試す。

１）FinalCutでHDVのまま粗編する。
２）そのままHDVコーデックで粗編をQuickTimeに書き出す。
３）それをshakeに入れてFileInのTimingタブのパラメータ（そして、その中のconvertのパラメータ）をいじって720*480(スクイーズの16:9)に変換を設定。ここでの目的は、インターレースを除去しつつ効果的に縮小化し、綺麗なSD素材に変換すること。
４）そして、FileOutで書き出し。なのであるが、ここで何のコーデックで書き出すかが問題。

さて、どうするか。

今回のDVDは写真集の付録なのだが、当の写真が非常に個性的なルックを持っている。写真集を刊行する編集部からも「同じような効果を映像では可能？」とやんわりオーダーされている。大幅なカラリングをするのであれば、素材は極力綺麗なコーデックのほうがいい。ここで「DVCAM納品」だからとDV圧縮を選んでしまえば、カラリングでの表現の可能性は狭くなってしまうだろう。
そこで、「非圧縮4:2:2」を試してみた。悪くない。縮小することで得られた画質向上は維持されていると思う。問題は重い。FinalCutに取り込んで編集を試みたが、なんとも足回りが悪く、編集をつめていくには大きなストレスとなる。今回は致命的。
DV（4:1:1）ぐらい足回りが軽くて、DVより画質の良いコーデックはないのか？と調べるとすぐに「Apple ProRes 422」が目を引いた。さっそく「非圧縮4:2:2」と比較してみる。同じ絵をそれぞれのコーデック変換したものを比べても目視レベルでは全く同じ。互いの差をとり、さらにレベル補正で強引に持ち上げて、やっと微妙な違いが判別できる程度。そして編集の足回り、これも良かった。DV編集と変わらぬぐらいの軽やかさだ。というわけで、今回はApple ProResコーデックで中間素材を扱っていくことにする。
というわけで、先の手順の続きを、少しダブらせて続ける。

４）そして、FileOutでApple ProRes 422コーデックのSDで書き出し。

この「HDV→DVサイズのAppleProRes」のリサイズは時間がかかった。shakeでの変換のパラメータはデフォルトの処理時間かからない設定で行ったのだが、現在最新のMacProにおいても1分の変換に約36分。20分の変換をしたら、さらにだんだんスピードが落ちていき、１日半かかってしまった。長すぎ。

話を作業進行に戻す。

５）SD(Apple ProRes 422)に変換したQuickTimeを再びFinalCutProに戻す。Apple ProRes設定のシーケンスにそれを敷く。ただそのままだと、一本化されていてカットの区切りが分からないので、元のHDV粗編を別トラックにコピペして、それを下敷きにAppleProRes素材に切れ目を入れる。
６）（Apple ProRes素材で）編集を仕上げる。

さてカラリングをどうするか問題。


★カラリングを何で行うべきか。そしてグレイン除去も欲しい。

カラリングを何のアプリで行うべきか。ホワイトバランスずれの色調整ぐらいなら、FinalCut内臓のエフェクトのみで対応可能なのだが、完全に創作としてのカラリングとなるとFinalCutでは無理である。
今回の編集に先立つ事一年ほど前に、実は同じ素材を用いて同様の効果を作成したことがある。使用したのはCombustion。同様のCGアプリとして、むしろもっとメジャーなAfterEffectsがあるが、カラリングに関してはCombustionのが向いている。その時はFinalCutからカラリングするカットだけTiff連番で書き出して、WindowsのCombustionに入れて処理し、またTiff連番で書き出してMacのFinalCutに戻していた。連番のやりとりはMacとWinをまたいでも画質はほぼキープされるものの、進行の足回りがひどく悪くなる。短期間＆低予算（苦笑）で50分近い尺を扱う今回では非現実的だ。
今回の現実的方向は、可能な限りMac内で全ての処理を完結させること。まずshakeでCombustionで行った処理と同じ事が可能か試してみる。かなり可能そうだが、決定的にshakeのデフォルトに欠けているものがある。 グレイン（フィルムのノイズ粒子）追加のエフェクトはデフォルト搭載されているが、グレイン除去のエフェクトがデフォルトでは搭載していないのである。さて、「ビデオ素材なのに何故フィルムグレイン除去が必要なのか」というと、使用目的はグレイン除去ではなく、肌の質感を良くする為である。女性タレント映像なのでこれはできるだけ押さえておきたい。デフォルト搭載はなくともサードパーティーでは出ているようだが、自分の現状を考えるにそこに高額の投資をするのは的確か疑問。自分でエフェクト開発も一瞬試したが、そう簡単ではなく、今回の限られた時間内では非現実的とすぐに諦める。


★colorを試してみる。

そこでふと思い出したのがFinalCutStudio搭載のcolor。以前、一度軽くいじってみたのだが、パネルが英語のままな事もあり直感操作できないのでさっさと諦めたのだが、グレイン除去のエフェクトもデフォルト搭載されているようだし、何よりFinalCut Studioファミリーのひとつ、ワークフローの足回りを良くするには、うってつけだろう。ここは覚悟して向き合ってみるしかなさそうだ。
マニュアルは日本語版があるので読み始めてみるが、当然かたくて理解するには時間がかかってしまいそう。ざっと全体の概要を掴んでから、かたい詳細を読みたいところである。すると目にとまったのが付属のチュートリアルDVD。普段は素人っぽい気がして見たりしないのだが、ここは謙虚に（？）拝見することにする。そのまま再生したら英語なので一瞬たじろぐが、すぐに日本語に切り替えられることに気づく。非常に短く全体をまとめられていてすごく良い。すでにCombustionでカラリングの基礎知識はあったせいもあって、かなり全体を理解できた。そして、それからじっくりマニュアルに目を通す。結局、目を通すのに２日かかってしまったが、やれる自信がついた。「とにかくいじってみる」から入って仕事として使うようになったCGだが、最近は「じっくり基礎を理解する」から入るのも良いなと思う。
さて、実際にcolorを使ってみてだが、Combustionのカラコレの主要部とshakeの簡易版が組み合わさったような印象を受けた。shakeはすでに開発終了なので、appleはその機能をmotionとcolorに配分するつもりなのかもしれない。Combustionとshakeを使用した経験のある僕としては、作業手順を把握してしまえば、細かい実作業自体は既視感を感じるくらいサクサク進められた。戸惑ったのは、その作業手順である。目的別の作業室がいくつかあり、そのラインを通じて映像を加工する考え方なのだが、これを感覚的に掴むのに少し手間取った。この作業手順は、僕は他では見たことがない。おそらくマニュアルを読まなければ理解できなかったと思うが、分かってしまえば非常に理に適った手順である。気に入った。もっと使ってみたいと思った。ひとつ残念なのが、僕のマシンだと内部演算を8bitでした行えないこと。floatまではいかずとも、16bitでは行えるようにもしておきたい。僕のグラボは購入時にカスタムで選択したもので、デフォルトのものではない。どうやらデフォルトのグラボでないと内部演算の選択肢に制限があるようなのだ。この事はあまり注意事項として大きく表記されていないので、少し問題ではないかと思う。それとも、まだ開発間もないソフトなので、近々にも対応予定なのだろうか。

それでは、手順の続き

7)FinalCutから編集したシーケンスごとcolorに送信。

8)colorにてカラリング。レンダリング。

9)colorからFinalCutに送信。FinalCut内にカラリング済みの新たなシーケンスが作られる。

10)再生チェック。

11)もし、colorで再修正したい場合は、colorの該当プロジェクト上で修正し、修正箇所をレンダリング。すると、FinalCut側は最新レンダリングを反映してくれる。

12)もし、編集を少し変えたいときは、そのままカラリング済のシーケンスを編集。さらにcolorでの再調整も反映される。ただ大きな編集直しは、colorとの連動を壊しかねないので避けたい。編集を固めてからカラリングすべき。

13）あとはシーケンスを出力形式に合わせた形に変換。今回はDV形式で書き出した。DV形式のシーケンスに配置しなおすのもありだと思う。ただここで、プログレッシブ素材がインターレース素材と誤認された上で、プログレッシブのシーケンスに配置されないように注意。FinalCutの自動判別に任せていると、意外と発生しやすい。これは解像度が落ちたような画質劣化につながる。


★ShakeとApple ProRes 422の不和？

新たにApple ProResコーデックとcolorをワークフローに取り入れて、想像以上に可能性が広がったのだが、同時に疑問点もでてきた。
今回の素材はHDV以外に、1シーンのみDVCPRO HD 24pで撮られている。これをcolorでカラリングし、他と同じくApple ProRes422コーデックでFinalCutのシーケンスに渡した。最終書き出しは60iのDVCAMなので、このカラリングされたシーケンスをプルダウンする必要がある。そこで、FinalCutからApple ProRess 422でシーケンス全体を書き出し、それをshakeにてプルダウン処理し、Apple ProRess 422でFinalCutに戻そうとした。これがうまくいかない。画像がカラーノイズになってしまうのである。色々試してみたところ、どうやらshakeはApple ProRess 422の出力には対応しているが、入力には対応していないようだ。(＊追記下部にあり)ネットで調べてみると、海外でも同様の疑問を持った人がいたようで、その人はファイルをブートディスクに置いたらうまくいったような事を書いていた（英語なので理解不完全）が、僕の場合、それでもうまくいかなかった。しかたないので、ここは重くても非圧縮4:2:2コーデックを使用し、再実行。今度はうまくいく。


★Apple ProRess 422で分からない点

先のshakeとの相性もそうだが、Apple ProRess 422で分からない点がいくつかある。
ムービーの書き出しとしてApple ProRess 422設定を選ぶ場合、設定のウィンドウにおいてCompressorという項目があり、Interlaceの選択肢と、ChromaFilterのチェックボックスがあり、これらの効果に関する記載が、少なくとも日本語では見当たらない。軽く、それらの選択肢オンオフを切り替えた画像を比較してみたが、非常に微妙な違である。単に、ファイルサイズを小さくするための圧縮手段の選択肢なのだろうか。前述のshakeとの不和を調べていた時に見た海外掲示板では、これらをオンにすると、書き出しの時間が倍増するような事が書いてあったが、これは未検証。
あと、今回使用したApple ProRess 422はApple ProRess 422（HQ）というほうなのだが、shakeで書き出したものと、FinalCutで書き出したものが、FinalCutのファイル分析にかけると、前者は（最高品質）と表示され、後者は（中品質）と表記されるのである。書き出しの時に品質選択はないようなので、いったいどこでこの差が生まれるのか分からないし、実際の画質を見る限り差があるように思えない。それどころか、中品質とされるほうのがビットレートが高い場合するある。いったい、この（最高品質）（中品質）は何を意味しているのだろうか。


★その効果のほどは。宣伝と余談。

来月11月11日に学研から発売される写真集『雫－しずる－』（写真家・長野博文氏）の付録DVDにて効果のほど確認できます。７人の若手新進女優を長野さん独特の透明感あふれる質感で捉えた写真集です。今回のカラリングは、長野さんの写真の魅力的な質感という、リファレンスというには眩しい目標を参照させていただきながらの作業だからこそ可能だったのだと思います。ありがとうございます。
ちなみに今回僕が撮影したのは、とある一人のパートのみ。あとは『好夏』のプロデューサーでもある一木氏が自らSonyのHDVカメラで撮影しています。撮影好きの一木氏ですが、氏の素材がこれだけ占めるDVDも少ないのでは。と思ったら他にもありました。『好夏』のメイキングDVDです。

＜後日の追記です＞
上記の「どうやらshakeはApple ProRess 422の出力には対応しているが、入力には対応していないようだ」の件について追記。
先日、Appleのプロアプリケーションアップデートの項目に珍しくshakeが入っていたので、もしやと思いアップデートしてみたところ、上記の件、どうやら対応されたようだ。精査こそまだしていないが、一見したところ問題なさそうである。
合わせてcolorもアップデートあったのだが、例のグラボとの相性はそのままらしく、うちのMacでは8bit演算のみの状態。。。。

shake出直し再起動3 「DVCPRO HD素材をFileIn、FileOut」

僕の場合の、撮影がDVCPRO HDで編集ソフトがFinalCutPro(以下FCP)とした時のshakeの入出力は以下で良いかと思う。あくまで自分用です。他の方は環境も映像の使用用途も違うと思うので参考程度に。
（DVCPRO HDは720Pで検証。1080もそのまま応用で良いと思う）

＜基本＞
HVX200 → FCPv6 →（書き出し＞Quicktimeムービー）→ shake → （FileOutでQuicktimeのDVCPRO HD設定で★） →　FCPv6

＜他のソフトも使用＞
HVX200 → FCPv6 →（書き出し＞Quicktimeムービー）→ shake → （FileOutで連番出力☆）→ 他のCGソフト →（連番出力☆）→ **shake → （FileOutでQuicktimeのDVCPRO HD設定で★） →　FCPv6

上記で★としたのは圧縮における映像変化が認められた箇所。shakeでQuickTimeのDVCPRO HD圧縮入れ、同じくDVCPRO HD圧縮出しは、その過程において圧縮劣化によるオリジナルとの誤差のようなものを生ずるようだ。とは言っても目視は困難なものなので、何度も繰り返すのでなければ上記で問題ないと思う。一応、試した数値は下段に示す。
他に非圧縮QT等でのFCP渡しも考えられるが、その後の編集作業の能率も落ちるので、前述手段で問題を感じたときに最終的に非圧縮出力検討すれば良いと思う。

上記で☆は検証ではTIFF連番を使用。

上記**shakeについて、ここでshakeを介さずに直接、あるいはQuickTimePlayerでムービーに変換してFCPに戻す手段も考えられるが、連番を介したshakeとFCPの間にはガンマ問題が発生しやすいらしく、appleのページでもshake上でQT化を薦めていた（http://docs.info.apple.com/article.html?artnum=93794-ja）ので無難にそれを踏襲。

また、以前も書いたが、取り込んだままの素材QTはスクイーズ情報がない。しかし、FCPでQuickTimeムービー出力するとそれにスクイーズ情報が付加される。両者をshakeに取り込むと、素材QTは横が圧縮された縦長の映像になるが、FCPスルーのQTは正常な16:9のワイドスクリーンで取り込まれる。
前者は素のオリジナル素材であるがshakeで作業するにはGlobalタブで設定を長方形ピクセルに合わせるか、Fileinにおいて解像度を変更するかする必要がある。
後者はQuickTimeのスクイーズ情報処理（？正確にはわからないが）から横960ピクセルを1280ピクセルに変換して取り込まれている。言ってみれば、勝手に変換されているわけだが、画質は前者とほとんど同じである。
shakeなどのエフェクトの素材としては、本来前者オリジナルのほうが良いわけだが、ほとんど差はなく、オリジナルを使用するために発生する複雑さに対して収穫が少ない。なのでここは分りやすく、FCPをスルーしてスクイーズ情報を付加し、shake中では正方形ピクセルで作業するほうが無駄がないように思う。
ひょっとしたら、Trackerノード適用などにおいてはオリジナルが良い場合もあるかもしれない、それはそのような行き詰まりにぶつかってから検証でも遅くはないだろう。とりあえず、smoothCamノードの処理を比較してみたが目視的にはほとんど同じであった。

FileOutにおいて気になるのが、横1280の正方形ピクセル換算で作業して、そのまま横960のDVCPRO HD 720PのQT出力ができるのだろうかと言うこと。FileOut前に960に変換する必要があるのか？
検証したが、変換しなくて問題ないようだ。横1280正方形ピクセル作業を、DVCPRO HD 720PのQuickTime出力に設定したところ、入力と同じくスクイーズ情報がある960*720のムービーとなった。ちなみにスクイーズ情報のない素材の960*720ムービーをそのまま上記と同じ設定で出力したら、スクイーズ情報のないDVCPRO HD 720PのQTムービーとして出力された。

ここまでのようなshake経由（ただしエフェクトは無し）のムービーをFCPに戻して、タイムライン上のオリジナルと比較した。目視的には同じ。ビデオスコープを見ても数値的には無視可能な微細な誤差範囲内だと思う。もちろん例のごとく100%以上のハイライトにおいてフォールダウンはあるが、この部分はデジタルビデオデータ作業においては宿命的誤差の発生地域であり、FCP（あるいは他の映像編集ソフト）内のみで閉じて作業する場合の方言のようなものだと思うので、気にする必要はないと思う。

前述のshakeでのDVCPRO HD圧縮の出し入れで発生した誤差について。FileInした素材と、それをそのままFileOutした素材とを比較した。
スクイーズ無しの場合は、画面全体平均のチャンネルごと誤差は0.09%-0.15%。チャンネルごとの最大誤差値は27.84%。
スクイーズ有の場合は、画面全体平均のチャンネルごと誤差は0.12%-0.20%。チャンネルごとの最大誤差値は23.13%。
（以上、使用した素材は好夏zerφ4の教室内のカット）
両者とも、コンストラストの強い箇所に誤差が出やすく。誤差のみを画像に出し強調表示させると輪郭検出のエフェクトをかけたような画面になった。数値にみるように該当ポイントのピクセルの誤差はかなり大きいが、画像上の形に合った非常に目立たない形に発生し、平均値に見るように全体的には誤差を感じないので、先述のように何度も繰り返すのではなく、出力時に一度発生する程度ならば問題ないと思う。

shake出直し再起動2 「HDからSDへのコンバート」

以前、ReSizeノードを使用してFCP上でのリサイズと比較しましたが、もっと適切とされる方法がありました。
知ったのは、英語版のアップルプロトーニングブックのShake4のp284-288です。そのまままさしくHDからDへのコンバートが解説されてました。そこで取り上げられた適切な手段とは、素材を取り込んだFileInノード内で、Timing＞reTiming＞Convert parameterを使用するものでした。UserManualの対応箇所はVol.1のp120 Remastering Mediaからp124までです。
以前のReSizeでの検証では、縮小におけるディティールの維持機能の上で、ノイズまで維持どころか目だってしまう点を気にしましたが、上記のparameterにはAntiAliasとDetailsの項目もあるので、自由度ありそうです。今度のコンバートはこれでやってみます。

shake出直し再起動1

またである。基本を知らぬまま、知っている事だけ使って無理矢理応用していたことが判明。デジタルはそれでも結果が問題なく出せたりするのであるが、分ってみると自分の無知さに赤面。
ゆっくり社会復帰進行中の現在、プラモも作ったのであるが他に進めていたのがshakeの勉強。このshake、非常に優れもので、開発こそ終了したもののまだまだ愛好者は多く、ハリウッドでも現役で活躍中なのだが、日本語ではトレーニングブックが一冊と簡単な小冊子が一冊出ているだけ。付属のマニュアルもチュートリアルも英語版のみ。そんな事もあって、僕は日本語のトレーニングブックの最初の方だけ読んで、後は画面表示から類推して無理矢理使ってきていた。
そして今回すっかり時間ができたので、最近のVFXの本などに目を通し出していたところ、「shakeをもっと使いこなすべきなんじゃないか」と気が猛烈にしてきた。今なら時間はある（笑）。まずは日本語のトレーニングブックをほぼ読破（コマンドラインはまだ）。その勢いで思い切って電子辞書片手に英語のチュートリアルを読破し、同じく英語のマニュアルは気になる箇所のみだがこれもチェック。英語には苦手意識がこれまであったので、チュートリアル読破には我ながら勇気付けられた。勢いで日本語版が出ていないshakeのトレーニングブック（日本語版がshake3用で英語版はshake4用）をamazon.comでアメリカから取り寄せる。今日までで約8割目を通した。
そうして思ったこと。「もっと使いこなすべき」どころではない、まったく基礎が分からぬまま乱暴な使い方をしてきたのだと。shakeの学習を通して、shakeばかりかプレマルチプライ等の映像合成処理知識を演算上の観点から正しく捉えなおすことができ、こんな基礎を今までおろそかにしてきたのかと内心、非常に赤面。せっかく気づいた基礎も忘れっぽい昨今なので、たまにブログにメモしてこうかなと思う。
ところで、今回英語を読むにあたって使用した電子辞書は、実は本来中国語用。例の旅行で使うつもりだったけどほとんど使わぬまま。予備的な英語の辞書機能ばかりを使用されて、辞書君さぞかし複雑な気持ちだろうなあ（笑）

DVCPRO HD 1080Pから720Pにダウンサイズ（追記有）

FinalCutでDVCPRO HD 1080Pの映像を720Pにダウンサイズする上での検証。
以下を比較してみる。

A) 1080の素材を並べた1080のシーケンスからQuicktime出力時に720に指定し出力。

B) 1080の素材を720のシーケンスに配置してから720に出力。

C) 1080で出力したものをshakeのResize（フィルターはsinc）で720にして出力。

結果は

A) この中では最も輪郭がボケた感じ。
B) この中では輪郭のシャープ感は真ん中
C) この中では最もデャープだが、暗部のノイズも一緒に強調されているようにも見える。

というわけで
BかCが適当そう。とりあえず、Cで様子見てみようかな。
Cのオプション手段として、C処理の前に、なんらかのノイズリデュースのエフェクトをかける手も考えられ葉するが、制作進行の足取りが遅くなり過ぎそうな気もするし、効果も未知なので、これはとりあえず保留。

後日の追記）
shakeのダウンコンバートのみなら、Resizaノードではなく素材を入れたFileInノード上ですべきだと後日判明。

sonyHDVをネット配信サイズに（追記有）

いつものアイドル映像仕事で、sonyHDVをネット配信用に縮小する必要性が出た。そのまんまエンコードソフトに入れてしまい、そこで縮小する手もあるのだが、素材のsonyのHDVはインターレース、対して今回使用するエンコードソフトFlash Video Enchoderはインターレース除去の機能はどうやらないらしい（あったらゴメンなさい）ので、エンコード前にネット配信用に640*360（正方形ピクセル）に縮小しておくことにする。
素材自体の編集はMac上のFinalCutなので、Shakeで縮小することにする。
まずは、インターレース除去。するとまあ、MPG圧縮という事もあってか、拡大して見ると、すごいブロック化状態である。斜めの線や、曲線が、ガタガタになっている。（でも、どうしてSONYはインターレースにこだわるんだろう。世間の最終出力はプログレッシブになってきていると思うのだけど）
ガタガタを消すために、縮小前にブラーをかける。アルゴリズムは無難にガウスにした。値的には、5あたりからガタガタ感が薄くなり、6でほぼ消えた。今回はちょっと遠慮して、5.5に設定。
で、それからReSizeで640*360に、ここでのアルゴリズムはsincにしました。sincは縮小においてディテイルが維持されるとの事ですが、シャープネス作用も強いので、先のぼかしで弱まった輪郭をここで戻そうという意図もある。
そうしてQuickTimeのTGA圧縮で出力。でも、FCPに戻すと、素材よりちょっとだけ明るめになっていた。以前にも書いたが、shakeとQTの組み合わせにおいては入れと出しのフォーマットが異なる場合、ガンマが変ったかのように明るめになったり、暗めになったりする事があるようだ。今回は入れがQT(HDV)で出しがQT(TGA)だったからからかもしれない。直そうかなとも思ったが、アイドル映像の調整としては、むしろちょうどいい明るさ具合だったので、そのままにする。


(修正しました)
HDTV表記をHDV表記にしました。この場合はHDVですよね（苦笑）

（後日追記）
shakeでのダウンコン処理のみならReSizeノードよりファイルを入れたFileInノード上で行うほうが良いらしいです。

3dsMAXレンダリング

自分はまったくまだ手探り状態の3dsMAX。今回zerφ2を制作する中で、そのレンダリングについて体験したメモ。

そのほとんどはmental rayを使用してレンダリングしましたが、動画においてはどれぐらいの設定が現実的なんでしょう？ちなみに今回の画像サイズは1280*720。
最初は、「そりゃ、できるだけ高画質にすべきでしょう！」と、サンプルは最小4、最大16、ファイナルギャザーはプリセットの最高にしてレンダリングしてみましたが、いやはや遅いのなんの。よほど時間もあって完全に決定状態でもない限り、避けたほうが良いスピード。ひとつのカットに8時間から数十時間（数日）かかってしまいます。
今回、現実的に選んだのは、サンプル最小1、最大4、ファイナルギャザーは高。レンダリング時間はひとつのカットあたり、数十分から8時間程度になりました。クオリティ的には、その後、合成先の実写に合わせてぼかしやモーションブラーを足すことを考えると問題がないくらいになっていると思います。
あと、この作業において、フィルターはmitchellにしました。最近出たＭＡＸ本でMitchellが推奨されていたからです。後で知ったのですが、Shakeにおいてデフォルトのフィルターは拡大ではmitchell、縮小ではsinc（縮小時にディテイルが維持されるらしい）だそうです。ただ、MAXのフィルターにsincはありません。そういえば、AEやCombustionではどうなんだろう？

で、ざっと映像ができて、音声担当の高橋さんにお渡しした今、差し替えように設定のクオリティをあげたものを合間にレンダリングさせています。いやはや、遅いです。果たして違いはでるのかなあ。。。

そうそう、あと、被写界深度とモーションブラーはMAXでは処理してません。その後のAEでやっています（あるいは、やっているようにみせている）。

960×720を1280×720にするにあたって（後日追記あり）

先のshakeのSmoothCamの時もそうだが、960×720（長方形ピクセル）を、1280×720（正方形ピクセル）にする場合、そのままスケーリングしただけだと、オリジナルよりやや寝ぼけた絵になってしまう。なので、少しアンシャープをかけるべきだろう。その時、最も適切なパラメータはどれぐらいだろうか。とりあえず、今回はAfterEffectsにてアンシャープマスクを、量50%、半径0.9、しきい値0でかけてみた。本来のパキパキ感は戻った感じだが、全体にかかりすぎの感もなきにしもあらず。しきい値2ぐらいが良いかもしれない。絵によっても違うだろうし、他の値も検証の余地はあるが、あまりここに時間をかけすぎるのもバランス悪いので、今回はこの辺で。

（追記）
Shakeのためのピクセル比変更によるサイズ変更なら、Shake内のResizeやZoomを使用のほうが良いようだ。オプション操作すればサブピクセルも考慮に入れてくれる。
ただ、上記のようなスケールアップ時は問題ないのだが、スケールダウン時が問題。デフォルトのダウンサイズアルゴリズムはsincという、ディテイルを維持してくれるアルゴリズムで、非常に優秀なのだが、ノイジーな素材だとノイズのデイテイルまで維持どころか浮き出てしまう。この場合は、アルゴリズムをデフォルトではなく他のものに指定する必要がある。

（後日さらに追記）
マニュアルと英語版のshake4本によると、素材のダウンコン、アップコンのみなら、素材を入れたFileInノード上で行うほうが良いとの事。FileInにそんな機能まであったのですね……

shakeで階調が変ってしまう

shakeでは、連番で入れたら連番出し、QuickTimeで入れたらQuickTimeで出したほうが、良いようである。
QuickTime DVCPRO HD 720P24入れで、QuickTime DVCPRO HD 720P24出しにおいて、目に見える階調の変化はなかったし、また、TARGA連番入れで、TARGA連番出しにおいても、目に見える階調変化はなかった。しかし、QuickTime DVCPRO HD 720P24入れで、TARGA連番出しや、逆にTARGA連番入れでQuickTime DVCPRO HD 720P24出しでは、暗めの階調になってしまった。
上記の他の場合の検証は行っていないので、全て当てはまるとは言えないまでも、shake段階での映像形式の変換は避けたほうが無難そうである。

shakeのSmoothCamの歪み(後日追記有)

1年半前にshakeを買ったのは、このSmoothCam機能のためと言って過言ではない。
このSmoothCamとは、手持ち映像のブレを抑えてくれる、柔軟なスタビライズのような機能で、手持ち映像をステディカム撮影のような動きに変えてくれる。ちなみに好夏zerφ1の冒頭の自然なパンダウンは実は手持ち撮影で、このSmoothCamによって、滑らかな動きに修正している。
shake自体は、もはやバージョンアップしないらしく、すでに消えゆくソフトなのではあるが、このSmoothCamの機能はその優秀さゆえかFinalCutの最新版に吸収されているらしい（最新版にしてないので未確認ですが…。誤報ならゴメンなさい）。

そんな素敵なSmoothCamだが、クセがあるようだ。ピクセルが正方形ピクセルでないと、動きの中で歪みが出るようなのだ。HVX200のDVCPRO HD 720P24素材（長方形ピクセルの940*720）を使用時に、微妙ではあるが歪みが発生した。GlobalsのFormatのパラメータは、素材に合わせたDVCPRO HD 720P24にしてあるので、何故か良く分からない。さらにAspect関連の値をいじって調整を試みるものの、どうも効果なし。
そこで素材を先にAfterEffectsで正方形ピクセル1280＊720の連番ファイルに変換してから、適用してみると、見事きれいに機能してくれた。

（追記11/3）
その後、検証してみたところ、歪みはFCPでキャプチャしたDVCPRO HDの素材をそのまま使用した場合に発生するものの、タイムライン上からDVCPRO HDフォーマットで出力したQT（勿論デフォルトの長方形ピクセル）では発生しないことがわかった。原因はピクセルのアスペクトではなく、ShakeがFCPでキャプチャしたままの状態のDVCPRO HDのQTに対して、対応できていないだけのようである。

（さらに追記）
当時と同じ素材がないので同一状態で再検証できないのだが、長方形ピクセルにおいてはGlobalTab上のdefaultAspectにおいて適切な設定を行ったほうが良いとのこと。（UserManual Vol.1 P.209-210）