Skip to main content
Inspiring
July 22, 2022
Answered

Lumetriスコープのルーマ信号の表示に関して

  • July 22, 2022
  • 1 reply
  • 925 views

davinchi resolveでルーマ信号64~940の範囲のグラデーション素材を書き出し、

その素材をPremiere Pro CC 2022(22.5)に読み込み、Lumetriスコープで表示したところ

Lumetriスコープ右側の64~940の値に合わず、100~860辺りの値を示しています。

これはLumetriスコープのルーマ値の表示が誤っているものと考えて良いでしょうか?

それとも何か勘違いをしているのでしょうか?

 

DaVinciのスコープおよびPremiereのLumetriスコープのスクリーンショット画像を添付しました。

宜しくお願い致します。

This topic has been closed for replies.
Correct answer Ckun

>1つ目の疑問は、同じファイルを読み込んだ際にPremiereのLumetriスコープとResolveのスコープの値が異なるのはなぜかという事です。

 

Premiere Proは素材に合わせて良くも悪くも読み込みのレンジが決まりますが、基本的にはそのファイルの仕様に合わせた読み込み方になります。

(この仕様のため、Log収録された素材が収録方法により正しく扱えないという問題があるのですが、今回のケースとは異なる問題なので割愛します。)

 

>Premiereでは素材を読み込む際にビデオレンジの範囲内に圧縮?して読み込んでいるようです。

 

Premiere Proは、ビデオレンジの輝度色差(いわゆるYUV)で扱いますので、RGBフルレンジの素材はビデオレンジに変換されて扱われます。

 

単純な例として、デジカメで撮影した写真やPhotoshopやIllustratorで作成したイラストや図表をPremiere Proに読み込んだ際、黒がスーパーブラックになって白がスーパーホワイトになってしまっては使い物にならないですよね。

実写の素材でも、RGBのコーデックではフルレンジで扱われることが一般的なので、このレンジ変換は「必要なもの」ということになるかと思います。

(ただし、状況によっては不必要なこともあり、その設定ができれば良いと個人的には思っています。)

 

基本的には32bit浮動小数点で扱われますので、この部分のレンジ変換に限って申しますとよるビット落ちによる劣化の心配はありません(使用するエフェクト・設定によります)。

 

なお、Premiere ProがビデオレンジのYUVで扱うのに対し、Resolveは(設定次第ですが)フルレンジのRGBで扱いますから、ProRes422などビデオレンジのYUV素材を正しい設定でResolveに読み込めば、フルレンジに「伸張」されるわけで、基準が違うだけでどちらも同じようなものです。

 

 

>自動、ビデオ、フルの3つから選択できるのですが、今回ビデオレンジのファイルとして出力したかったのでビデオを選択しましたが、信号を変換したくない場合はフルを選ぶべきだったのかもしれません。

 

最初の返信でも書きましたが、Resolveにてビデオレベルで書き出すとビデオレンジへの変換が行われますから、レベルが変わるのは通常の動作です。Premiere Proの問題ではありません。

 

Resolveからフルで書き出せばレベルはデータレベル表示のスコープの表記と同じレベルになるのですが、書き出したファイルに「フルレンジ」の属性が付いているにもかかわらずビデオレンジ(ランプ信号を64-940で作成しているので)の中身ですから、正しくないファイルになる可能性はあります(私は正しくない組み合わせの検証をしたことが無いので断言はできません……)。

 

まずはResolve上でどのようにレベルを扱うかという部分が肝になると思います。お書きいただいた内容からは、おそらくResolve上でビデオレンジ(10bitコード値64を黒、940を白)で扱われようとなさっているのではないかと思います。

 

もちろんその方法も誤りではないものの、Resolveはフルレンジで扱うことが基本になるかと思います。

 

32bit浮動小数点にて扱われますので、レンジが異なることによるbit落ちなどは気にしなくて良いのですが、使用するコーデックによって基本となるレンジは異なりますので、そのあたりを把握したうえでお使いいただきますと、スムーズにファイルのやり取りができるのではないかと思います。

 

※この返信の内容は、説明を簡単にするために重要な部分を省いていたり、技術的な正確性を二の次にしていますため、あまり良い内容とは言えないものであると自分でも感じております。

「フルレンジ」と「ビデオレンジ」の説明に付随する補足的なものだと割り切っていただければと思います。


別の方向からアプローチしていただいた方が問題の本質が見えやすいかもしれないと思いましたので、Resolveのジェネレーターで出したカラーバーの波形の画像をのせてみます。

 

 

スコープの目盛りの設定は「データレベルスコープ」にしています。この目盛りを変えられることからもお分かりいただけると思うのですが、誤解を恐れず極論を申しますと、スコープの目盛りの数値は、書き出されるファイルのコード値との対応という面では、あまり意味がないということでもあります。

 

通常のビデオ信号を10bitコード値で表現すると、黒は64、100%白は940ですが、添付した画像のようにResolveでは黒が0、100%白が1023になっています。

 

これをビデオレンジでProRes422に書き出してPremiere Proに読み込むと、Premiere Proのスコープでは黒が64、100%白が940になります。

 

手元の環境がWindowsなので、ProRes422ではなくCineForm 10bit YUV のビデオレンジで書き出したのですが、このMOVをPremiere Proで読み込むと、こちらのように通常のビデオレベルの範囲で表示されます。

誤解の無いよう念のため付け加えますと、このレンジ変換はPremiere Proで行われたのではなく、Resolveでの書き出し時に行われているものです。

 

このレンジ変換が、大元のご質問で

>Lumetriスコープ右側の64~940の値に合わず、100~860辺りの値を示しています。

とお書きいただいている状況になった理由かと思います。

 

なお、今回の検証でのResolveの設定は、デフォルトのカラーサイエンス「DaVinci YRGB」、タイムラインカラースペース「Rec.709 Gamma 2.4」にしております。

1 reply

Ckun
Community Expert
Community Expert
July 22, 2022

>これはLumetriスコープのルーマ値の表示が誤っているものと考えて良いでしょうか?

Lumetriスコープのルーマ値の表示は誤りではありませんので、そのお考えは正しいとは言えないと思います。

 

>それとも何か勘違いをしているのでしょうか?

Resolveのから書き出す際のデータレベル設定が、ビデオレベル(もしくは「自動」になっていてコーデックに合わせてビデオレベルになっている)なのではないでしょうか。

 

【追記】

Resolveのスコープが「データレベルスコープ」(少々ややこしいですが、Resolveがそのように表記しているので……)と仮定して、一番シンプルなパターンでのフルレンジ→ビデオレンジ変換が行われている可能性をふまえて返信しましたが、Resolveの各種設定の状況次第で状況が変わってきますので、ResolveとPremiere Proと素材交換で使うコーデックなど、全体の流れを通してレベルが適切に扱われているかの確認が必要だと思います。

茶田郎Author
Inspiring
July 26, 2022

回答頂きましてありがとうございます。

1つ目の疑問は、同じファイルを読み込んだ際にPremiereのLumetriスコープとResolveのスコープの値が異なるのはなぜかという事です。

Photoshopで作成したカラーチャートを読み込ませておぼろげながら理由が判明しました。

Premiereでは素材を読み込む際にビデオレンジの範囲内に圧縮?して読み込んでいるようです。

また、DaVinci Resolveの機能を勘違いしていたのかもしれません。

自動、ビデオ、フルの3つから選択できるのですが、今回ビデオレンジのファイルとして出力したかったのでビデオを選択しましたが、信号を変換したくない場合はフルを選ぶべきだったのかもしれません。

ここで2つ目の疑問が生じてフルを選択して書き出した場合でも、

ProRes422HQ(MOV)形式で書き出せばビデオレンジのファイルが出来上がるという理解で良いのでしょうか?

Premiere以外のResolveの質問が混ざってしまい恐縮ですが、ご存じでしたらご教示頂けますと幸いです。

 

Ckun
Community Expert
Community Expert
July 26, 2022

>1つ目の疑問は、同じファイルを読み込んだ際にPremiereのLumetriスコープとResolveのスコープの値が異なるのはなぜかという事です。

 

Premiere Proは素材に合わせて良くも悪くも読み込みのレンジが決まりますが、基本的にはそのファイルの仕様に合わせた読み込み方になります。

(この仕様のため、Log収録された素材が収録方法により正しく扱えないという問題があるのですが、今回のケースとは異なる問題なので割愛します。)

 

>Premiereでは素材を読み込む際にビデオレンジの範囲内に圧縮?して読み込んでいるようです。

 

Premiere Proは、ビデオレンジの輝度色差(いわゆるYUV)で扱いますので、RGBフルレンジの素材はビデオレンジに変換されて扱われます。

 

単純な例として、デジカメで撮影した写真やPhotoshopやIllustratorで作成したイラストや図表をPremiere Proに読み込んだ際、黒がスーパーブラックになって白がスーパーホワイトになってしまっては使い物にならないですよね。

実写の素材でも、RGBのコーデックではフルレンジで扱われることが一般的なので、このレンジ変換は「必要なもの」ということになるかと思います。

(ただし、状況によっては不必要なこともあり、その設定ができれば良いと個人的には思っています。)

 

基本的には32bit浮動小数点で扱われますので、この部分のレンジ変換に限って申しますとよるビット落ちによる劣化の心配はありません(使用するエフェクト・設定によります)。

 

なお、Premiere ProがビデオレンジのYUVで扱うのに対し、Resolveは(設定次第ですが)フルレンジのRGBで扱いますから、ProRes422などビデオレンジのYUV素材を正しい設定でResolveに読み込めば、フルレンジに「伸張」されるわけで、基準が違うだけでどちらも同じようなものです。

 

 

>自動、ビデオ、フルの3つから選択できるのですが、今回ビデオレンジのファイルとして出力したかったのでビデオを選択しましたが、信号を変換したくない場合はフルを選ぶべきだったのかもしれません。

 

最初の返信でも書きましたが、Resolveにてビデオレベルで書き出すとビデオレンジへの変換が行われますから、レベルが変わるのは通常の動作です。Premiere Proの問題ではありません。

 

Resolveからフルで書き出せばレベルはデータレベル表示のスコープの表記と同じレベルになるのですが、書き出したファイルに「フルレンジ」の属性が付いているにもかかわらずビデオレンジ(ランプ信号を64-940で作成しているので)の中身ですから、正しくないファイルになる可能性はあります(私は正しくない組み合わせの検証をしたことが無いので断言はできません……)。

 

まずはResolve上でどのようにレベルを扱うかという部分が肝になると思います。お書きいただいた内容からは、おそらくResolve上でビデオレンジ(10bitコード値64を黒、940を白)で扱われようとなさっているのではないかと思います。

 

もちろんその方法も誤りではないものの、Resolveはフルレンジで扱うことが基本になるかと思います。

 

32bit浮動小数点にて扱われますので、レンジが異なることによるbit落ちなどは気にしなくて良いのですが、使用するコーデックによって基本となるレンジは異なりますので、そのあたりを把握したうえでお使いいただきますと、スムーズにファイルのやり取りができるのではないかと思います。

 

※この返信の内容は、説明を簡単にするために重要な部分を省いていたり、技術的な正確性を二の次にしていますため、あまり良い内容とは言えないものであると自分でも感じております。

「フルレンジ」と「ビデオレンジ」の説明に付随する補足的なものだと割り切っていただければと思います。