日々適当

村枝賢一のまんが『RED』は西部劇の傑作だと思うとかなんとかそのREDのことではなく、REDで撮影されたデータのことでございます。いや、昨日、ミューズテクスのアップルストアで行われたイベント？に行ってきて、ちょっと感心したのでございます。

REDというその素敵カメラから出力される映像は4Kと呼ばれる解像度を持っているため、非常にハンドリングが悪くなることが想像されます。単純に重い、と。
そこで、REDで撮影された生のデータ（R3Dフォーマット）を参照する形でQuickTimeムービーの解像度違いが数種類生成されます。一つのクリップにつき、それらファイルが一つのフォルダにまとめられ、それをワンセットで運用する事になるようですね（生成されるQuickTimeファイルは参照ムービー形式なので非常に小さいために、ディスク消費量が無駄に増えるということは無い）。FCPにはそのフォルダごと放り込んでやれば、読み込めるフォーマットが自動で取り込まれますけど、素材数が多くなりすぎるから、イベントではClipFinderというツールを使って素材を整理しながら取り込むワークフローが紹介されました。

REDの生データはデジカメに置けるRAWフォーマットと近くセンサーごとに12bitのダイナミックレンジで記録されているそうです。通常、ムービー編集向けのフォーマットは各色10bitで、かつ4:2:2だったりすることも多いので、それよりもはるかに高精細な内容を保持していることのなります。その情報量を失うこと無く編集を行えるわけですね。

ところでそのイベントではFCPからColorにデータを渡してカラーグレーディングを行うワークフローをしめすというのも一つの主題でした。FCPからColorに渡す時には、単にファイル→送信で良いわけですけど、カット編集を行い、クリップの尺調整を行った状態のシーケンスを渡したとき、それがREDの素材であった場合、現状では尺調整が反映されていない状態でColorに渡されてしまうという問題があるみたいです。
つまり、ClipAが00:00:00:00から00:00:10:00という長さを持っていて、それをタイムラインに並べる時に、00:00:01:00から00:00:08:00の間でインアウトを設定した上で行ったとしても、Colorに送ると、00:00:00:00から00:00:10:00のクリップとして渡されてしまうわけです。
将来は解消される問題であろうけど、現状では、尺を調整した状態の新しいクリップを作った上でColorに渡してやる、ということを考えるみたいですね。
つまり、00:00:01:00から00:00:08:00の長さを持ったクリップをFCPから出力してやり、それをFCP上でタイムラインに並べたシーケンスを新たに作って、Colorに送ってやる、と。XMLを介することで、変換時間はかかるにせよ、それほど難しくない作業で行えることを示してくれました。変換時間は「ファイルをコピーするぐらい」と言っておりました。
ちなみに、尺調整されたクリップを出力するとき、ProRes 4444（「ぷろれずふぉーばいふぉー」と呼んでいました）というようなフォーマットで書き出してもいいのだけど、REDCODE QTというフォーマットを選べば、R3Dの内容を全部引き継いだ状態の独立形式のQuickTimeファイルが出力されてくるために、それをColorに渡せば、Color上で「現像」作業を行えるるそうです。それによりさらに詳細な調整が可能になるわけですね。でもって、それを4Kの解像度で行えるようになったのがColor 1.5の大きな売りみたいです（FCS2のColorでは、2Kまでしか取り扱えなかった）。

そんなワークフロー。redportal.jpにて簡単に紹介されていますね。そこに書かれていることのColorに渡される所までがイベントではデモされました。

カメラ自体も魅力的なREDですけど、その後のワークフローのこともよく考えられたものなんだなぁということを今更ながら感じましたですよ。
まぁ、自分がRED関係を取り扱うことはたぶんありえないのでしょうがねー。