TGAvsQT - 某巨大掲示板にこんな話題がでていた。
目次
某巨大掲示板にこんな話題がでていた。
http://anime.2ch.net/test/read.cgi/iga/1106209857/889-
ああ、そういえば コレってたしかむかし考えたな…と
あの時はどうだったかな?…もう、一度考えてみる。
某所に発言すると匿名無責任発言になりそうなのでこちらでやるべい
納入フォーマットに連番画像(TGA?)とQTムービー(Animation圧縮)どっちが良いの?
まず前提ですが
納入フォーマットと行ってもワークフローのどの部分にあたるのか考慮しておくこと。
ま、上の話題は主に撮影関連なので、コンポジット作業者から発注元に対する納入フォーマットを考えてみるわけです。
また、フォーマットの性質上個々のコンポジット作業者が決定するのではなく発注側でのフォーマット選択の要件として考えます。
画像は単一のカットに対して
- 背景付き
- 1シーケンスあたり尺相当のフレーム数
- 音なし
- 8bit深度(まだ16ビットの要求は無い)
- 可逆圧縮
- フレームレートは発注元次第(24 or 30(プルダウン付き))
という単位での取扱になるわけだ。
…ってことで
一般的には、ふたつのフォーマットの差はこんな感じか?
--- | 連番 | ムービー |
1.容量 | 大きい | 小さい |
2.ファイル数 | フレーム数 | 1 |
3.レコーダーの対応 | 機材による | 機材による |
4.そのほか | コピー時に壊れる | そんなことない? |
一個づつ見てみる
1番 サイズ
そんなに違ったかな?やってみよう。 手元の同一カットを処理
720x486(DVサイズ)/24FPS(24p)/96フレーム
QT(Animation圧縮) 55.1MB TGA連番(RLE圧縮) 67.7MB
あれ? あまり違わない…よ
ワタシノ記憶に間違いがなければQT(Animation圧縮)は、各フレームをRLE圧縮しているだけだったと思うです。背景が普通にくっついてエフェクトがかかると大体50%あたりが最高に圧縮できるサイズなので、ま、こんな感じ。
TGAは、RLE圧縮で大体6〜7割くらいだったのでやっぱりこんな感じ。うまい圧縮テーブルを作るソフトだと圧縮率は上げられたような気もする。
全体的な傾向としては、たしかにQTムービーの方がやや圧縮率が高いが…特に「目を見張るほど違う!」ってわけでもないかしらん。
「すごく違う」と思っているのヒトは、TGAを「非圧縮」前提で使っているのではないかな?
そういえば、機種は忘れたが圧縮したTGAを受け付けないレコーダーがあったような気もする。
TGAは、すごく初期のフォーマットの一つで(手元の資料によると最初のバージョンは1984年ダ) バージョンの違いとかあると(当然だけど)「古い設計の機械」では互換性に問題がでてきます。
受注側にしてみれば、他所に手渡すデータで機械の指定も圧縮の指定もなく「TGAで」とだけ注文されたら… それとなく機種を聞くか、あきらめて「非圧縮TGA」で納品するしか無いワナ。
2番 ファイル数
キャリーの点では、ファイル数が少ない方が良さそうだが…連番も、どのみち「シーケンス単位でディレクトリで扱う」のであまり操作上の差はないかもしれない。
メディアに入りきれない大きなシーケンスなどの場合は連番ファイルの方が分割は楽ちんかもね。
考えられる「こわい」コトは、カット(シーケンス)が長くなって総容量が増えるコトかな? 2GBオーバーのファイルは環境によっては かなり危険なので。認識できなかったり、できても読めなかったり。
テレビシリーズのコンポジットで1カット2GBオーバーすることはあまりなさそうだから、それほど問題にはならないか。
AEに限定すると、でかいムービーをメモリ(仮想記憶)に全部展開しようとして檄重フッテージになることがあったような記憶が…あ、納品フォーマットの話だっタネ。ごめんです。
無駄話ですが、 相当以前に、某ANIM●のセルをMOにコピーしていて途中でディスクフルで エラー終了が続いたことがあったげな。 容量は空きがあるのにそれ以上コピーできないとヌカすのだわシステムが。 実は、一見少なそうにみえたファイル数だったが、アプリケーションバンドルの データファイルを開いてみるとセル1枚あたり4つのファイルがバラバラと… デスクトップで1つにみえていたアイコンに1000ファイルくらい入っていて、 iノード不足でエラーになっていたので…ぎゃー 閑話休題ファイル数は、一般的には少ない方がよろしいが、それでファイルサイズが肥大化するのはまずいかもしれない。
双方メリットもデメリットもあるのでひきわけ
3番 レコーディング機材の対応
ま、こりはしょうが無いような気がする。各社ごとに環境は違うので…
4番 コピー時にファイルが壊れる。
むかしも時々見かけたような気が…アレって、原因なんなんでしょ?
むかしFTP転送ではよく見かけたかな。 FTPの場合は、たぶんデータ転送エラーがでていて、でもチェックサムは合っちゃって正常転送扱いになるパケットが原因のような気が、でもそれだとTGAだろうがムービーだろうがお構いなしに出るはずだわな。 すると、データがへボった時に再転送量の少ない連番のほうが有利になりそうだわな。ムービーだと1カット丸ごとオシャカだし。
でも、このたぐいのエラーは回線状態の悪い時にだけ発生していたので今は昔よりも少ないかな?。
単純な複製で、あのたぐいの画像が壊れる現象って出るの? わしゃ、あたったことないんですが。
わたし、もう長いこと作画野郎なので、ファイルの扱い数は 撮影さんよりもかなり少ないです。
今の所、私のもっている情報では、どっちが特に有利ってことはなさそう。 納品フォーマットとしてはどっちでも(その現場で)都合の良いほうにきめなさいってことだね。
で、先の掲示板の話題の冒頭発言を読み返してみると
思ってたんだが、こないだの作品、サンプルカットを 覗いたら中間ファイルまでtga連番だったりするんだけど・・・ なんでQuickTime使わないの?わー、ごめんね。読み違えてたワ。
流れのせいで納品フォーマットだと思っちゃったよ。 2-3、とか 番号づけの話題に目をとられたせいだな。
改めて…
中間フォーマットに連番画像(TGA?)とQTムービー(Animation圧縮)どっちが良いの?
って …
これ、まず前提として「中間素材だったら、作業者の好きにして良いよ」ってことはお断りしておきます。強制するつもりとか毛頭無いし、しても意味無いですから。
で、考えてみる
あれ? みなさん、アニメーションのコンポジットで上流工程から流れてくる素材以外の中間素材ってどの程度レンダリングするですか?わたしが作業していた時はあまり作らなかったかな。…ほとんど
結構ケース少なそうだが…どんなケースがあるかな?
考えられるのは、
- 特効素材
- これは(コンポジット担当が)自分で処理するわけじゃないから関係ないか? AEのベクトルペイントで書いた場合は…中間素材のレンダリングはしないか。
- 複雑な合成のプリレンダリング
- …もAEはプリコンポが普通にできるのであまりやらなさそうだし…
- 兼用のエフェクト素材
- これはありそうだ。うん
…ケース少ないよ。それでも考える
上の流れにしたがって
1 サイズ
上でもふれたが、非圧縮を使わない限りあまり差はない。したがってどちらかを積極的に支持する理由は無い。中間ファイルで(TGA/QTほか限らず)非圧縮を使うヒトは…ま、「ディスクがもったいないのでおすすめできない」とだけ…。
2 ファイル数
これも上の考察の通り。連番シーケンスはハンドリング上1シーケンス1フォルダで扱うことでムービーとのハンドリングの差はほぼ無くなるのであまり気にしない。
3 レコーディング機材
中間素材なので考慮の必要なし。評価要因にならない。 プレビューなどでレコーディング機材を使うヒトは…その機材に合わせると吉かも。
4 コピーで…
中間素材なので考慮の必要なし。評価要因にならない。 基本的にはヒトにわたすものでは無い。納品物では無いので、作業上必要なフォーマットで好きに扱えばよろしいわけだ。 納品物の一部として(「プロジェクトで納品」等になっている場合など)扱う場合は、別途指定があるわけだが、それはまた別の話。
単一の現場内部では、(同じ現場だと物理条件が似るので…)みんなで話し合ってファイル形式とか合わせておくと融通がきいて便利だと思う。…が、よその現場に勧める理由にはならんわね。
一応考察終り。
余談ですけど
中間ファイルまでtga連番これ、セルのことかな?
もしセルだったら、彩色ソフトの標準フォーマットが(独自拡張の)TGAなので、TGA連番でないとリテイク時のハンドリングが悪くなるためだと思われるです。って…知ってるか
余談その二
納品フォーマットを告知された場合、口頭で伝えられた仕様は要注意。
伝えてきた当人が「人間レコーダー(いわれたことを理解せずに繰り返しているだけ)」なのはよくある話なので、納品フォーマット等の重要な情報はちゃんとした文書でもらって言質をとっておくか、責任者に確認をとっておくのが吉。
発注側も、「前はこうだったから」とか「(何となく)普通TGAだから」とかでなく、なぜそうなるかの理由を添えた「納品仕様書」を発行して関係者の共通認識にするが吉
一番困るのは「お前がそんなこと知る必要はない」的な態度をとる(つまり自分が理解してない)人物が間に立ってしまった場合だが…うまくその人をスルーして必要な人物と連絡をとろう!
余談か?
気が向いた方は突っ込みをどうぞ。(<というコーナーでしたが一言コメント機能は休止中)
SPAMロボとコンフリクトしてしまった…
Powered by YukiWiki 2.1.2a / Modified by Nekomataya.