1 件の正解
改めて検証しましたら、前回の返信内容に誤りがあることがわかりました。
今回の問題にAtomos製レコーダー使用の有無は関係なく、ProResコーデックのうち「422」のものにて発生することがわかりました。先日の検証では、たまたま手元にあった他社製NLEソフトで書き出したファイルがProRes444だったので、誤認しておりました。不正確な情報を返信してしまい、申し訳ございません。
ひとつまえのバージョン（CC2019 13.0.3）に戻すと症状が出ませんので、直近のアップデートで出てきたバグだと思います。
なお、非圧縮4:2:2 10bitや、GoProCineForm YUV10bitでは症状が出ないようですので、10bit素材に関する問題ではなくProRes 422ファミリーに限定された問題ではないかと思います。
ちなみに、私は未だCC2018をメインで使用しておりますが、ProRes書き出し用に入れているCC2019は、今回の一件で13.1から13.0.3に戻しました。
たぶん、仕事中にこの症状に遭遇していたら冷や汗ダラダラで対応する羽目になっていたと思うので、事前に知ることができて助かりま
...
21
返信
Ckunさん
お返事ありがとうございます。
映像は権利上お見せいただくことができないとのことですので、もう少し具体的な作業の手順とどの段階で「本来よりコントラストが低くなった」のか、お教えいただけますでしょうか。
文面からは、Premiere Pro上で明るさ調整など行ったところまでは正常で、H.264やQuickTime(CineFormでしょうか)への書き出し結果のみがコントラストが下がっているように読み取れますが 、念のため確認できればと思います。
＞編集に時間がかかり、今回の編集に関しては今日までしっかりとした書き出しを行ってきていませんでした。。
（よくないですね。。）
Premiereの編集画面上で見る限りは、Lumetriで調整した内容はしっかり反映されていて、
Lumetriスコープの反応も、未調整・調整後と、正常に反応しているようです。
- 収録時のコーデック選択（ProResか、DNxHRか）と、カメラの色関連の設定（通常のRec.709か、Logか）
＞PCM ittsuiさんにも送った情報を画像で添付します（先ほど画像が送れなかったので改めて同じ情報になります）
添付画像の情報だと、コーデック選択はProResになると思います。
- Premiere Proで読み込んだ直後（何も調整しない状態）の表示は正常か否か（カメラのカラーバーが収録されていれば、Lumetriスコープで正しいレベルで読み込まれているか確認できます。）
＞カラーバーは収録していないので、詳細なことまでは分かりませんが。。明らかに以上が認められるようなことはなかったです。
私自身が撮影したわけではないのですが、一部撮影現場に立ち会って確認していて、その時「コントラストを低めに撮影してほしい」と撮影者の方には伝えていました。
その後持ち帰ったデータを確認したときは、現場で確認した内容と相違なかったと記憶しています。
- 書き出したファイルの「コントラストが低い」とご判断なさっている再生環境（Premiere Proに読み込んでの確認か、ほかの再生ソフトによる確認か）
＞コントラストが低いと感じたのは、書き出した映像をウィンドウズの「映画＆テレビ」で確認したときに気が付きました。
Premiere上では編集結果がしっかりと反映されているので、書き出しかシーケンスの設定に問題があるのかと考えました。
- Premiere上で調整した色や明るさなどが「全く反映されず素材のままの色・明るさで出力される」のか、「調整内容が反映されているけれども意図した色調よりコントラストが下がる」のか、 また後者の場合、未調整で出力した場合に元素材と色調が変わるか否か。
＞今回は後者のような状態です。少し、しかしカットによっては明らかにコントラストが低く、
色も調整したものより少しずれているように見える状態です。
未調整で出力したものも、Premiereの画面と比べるとやはりコントラストが落ちていました。
- 色調整に使用したエフェクトの種類と、レンダラーの設定。
＞色、明るさ調整にはLumetriカラー、レンダラーはAdobeMediaEncoderを使用しました。
また、かのうでしたら「HDカラーバー」をシーケンス冒頭や末尾などにつけて書き出してみていただき、カラーバーのコントラストも変になってしまっているか確認していただくと、原因がつかみや すいと思います。
＞添付のような結果になりました。特に変化はないように見えますがどうでしょうか。。
なお、10bit収録の素材の諧調を生かすためには、32bit対応のエフェクトを使う、ソフトウェアレンダリングの際は「最大ビット数」でレンダリングされるよう設定する必要があったと記憶 しています。
＞32bit対応Effect…盲点でした。。しかしLumetriカラーは対応しているようなので、問題はそこではないということでしょうか。。
書き出し時のソフトウェアのレンダリング設定は「最大ビット震度に合わせてレンダリング」にチェックは入れているので大丈夫かとは思いますが。。
以上、長くなりましたが現状です。
細かなご指示本当に助かります。
これで何が原因が分かればよいのですが。。
何卒ご助言のほどよろしくお願い致します！
▼MOVデータ詳細です
▼左：Premiere画面、未調整／右：書き出し後「映画＆テレビ」再生、未調整
▼左：Premiere画面、Lumetri調整／右：書き出し後「映画＆テレビ」再生、Lumetri調整
▼左：Premiere画面、カラーバー／右：書き出し後「映画＆テレビ」再生、カラーバー
LUTがらみの問題は検証しておりませんが、ProRes 422の問題を再検証しました。前回はWindows版のPremiere Pro 13.1.0で症状が出出ていましたが、今回13.1.2で検証しても症状が出ました（最大ビット数で処理する場合）。
諸々の都合上、非圧縮とProResの二つのファイルは、Apple Final Cut Pro 7.0.3で書き出したものを使っております。Premiere Pro 13.1.2でProRes 422 HQ書き出しした素材を読み込んでも症状が出ることは確認しましたので、ProResファイルの作成元に関わらず症状が出ると思います。
この画像の通り、ProRes素材は誤ってフルレンジ→リミテッドレンジの変換がかかってしまっています。
ちなみに、Premiere Pro 13.0.3ではこの問題は発生しません。
Premiere Pro 13.1.2でも「最大深度に合わせてレンダリング」のチェックを外すとこの問題は起きないと思いますが（今回時間の都合で書き出しはチェックしておりません）、以前の返信にも書きました通り、各色10bitのProRes素材も8bitの処理となってしまいます。
ノーマルのルックで撮影された素材でしたら8bitで処理してもさほどアラは出てこないと思いますが、Log収録した素材の場合は注意が必要かと思います。
現状では、WindowsでProRes素材を読み込んで使用する場合、Premiere Pro 13.1.xで編集を開始することは適切ではないと思っております。
AdChoices