ここ数年の仕事のひとつであるグラビアメイキング撮影に手術後初めて復帰してきた。
スタジオ撮りなので比較的楽な現場のはずなのだが、後半背中に疲れが溜まってきた。
帰宅後は、まずは横になってしばし休んだ。
休息後は、新たなプラモを少し進めた。その新たなプラモのことは、また後日。
2008年7月1日火曜日
2008年6月29日日曜日
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の教室内のカット）
両者とも、コンストラストの強い箇所に誤差が出やすく。誤差のみを画像に出し強調表示させると輪郭検出のエフェクトをかけたような画面になった。数値にみるように該当ポイントのピクセルの誤差はかなり大きいが、画像上の形に合った非常に目立たない形に発生し、平均値に見るように全体的には誤差を感じないので、先述のように何度も繰り返すのではなく、出力時に一度発生する程度ならば問題ないと思う。
（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の項目もあるので、自由度ありそうです。今度のコンバートはこれでやってみます。
知ったのは、英語版のアップルプロトーニングブックのShake4のp284-288です。そのまままさしくHDからDへのコンバートが解説されてました。そこで取り上げられた適切な手段とは、素材を取り込んだFileInノード内で、Timing＞reTiming＞Convert parameterを使用するものでした。UserManualの対応箇所はVol.1のp120 Remastering Mediaからp124までです。
以前のReSizeでの検証では、縮小におけるディティールの維持機能の上で、ノイズまで維持どころか目だってしまう点を気にしましたが、上記のparameterにはAntiAliasとDetailsの項目もあるので、自由度ありそうです。今度のコンバートはこれでやってみます。
登録:
投稿 (Atom)