Resolve709処理の考察

DaVinci ResolveのBT.709規格のサポートには、インポートしたクリップや内部の処理、入出力プロファイルなどが含まれます。ITU-R BT.709は、時間の経過とともに更新されているものの、単一の規格です。とはいえ、DaVinci Resolve内のプロファイルを見ると、709という名前のものがいくつかあります。

ある意味で混沌とした709設定に立ち向かおうとして、ビューワやエクスポートされたメディアファイルなどを前にして、それがどのように機能するのか理解するのに苦労した方も多いと思います。私もその一人で、今回じっくりと確認する機会を得ました。

この考察の目的は、DaVinci ResolveでBT.709クリップがどのように処理されるかを理解することです。どのように動作するのか、どのように設定を行えばミスを防げるのか、ユーザーはどのように理解すればよいのか。この疑問をクリアにすることで、今後の映像制作に活かせるようにすることが目的です。私はDaVinci Resolveの開発者ではないので、ユーザーの視点から考察します。

この考察が前提としている環境は、下記のとおりです。macOSやソフトウエア、ドライバなど、いろいろな環境がこの先変化していくため、この記事の内容には「賞味期限」があることをご理解ください。最終更新日（ページ最下部に表示）から時間が経過してからの内容に関する正確性は、執筆時から変わっている可能性があります。

• macOS14.3.1（Windows環境は対象外です）
• DaVinci Resolve Studio 18.6.5
• UltraStudioシリーズのビデオI/OとDesktop Video 12.7
• SDIもしくはHDMI接続のリファレンスモニターと波形モニター
• MacBook Pro 2023｜Mac15,9

考察を進めていく中で、関係するDaVinci Resolveの設定箇所は下記の通りです。これらをどのように設定するかは、とても重要な前提条件になります。

カラーマネージメント（プロジェクト設定）

Color science・・・DaVinci YRGB／DaVinci YRGB Color Managed

ColorSync（環境設定）

General・・・Use Mac display color profiles for viewersのOn／Off

NCLC（Deliverページ）

Advanced Settings・・・Color Space Tag／Gamma Tag

今回の検証用に作成したDaVinci Resolveのプロジェクトを、DRAとDRP形式でダウンロードできるようにしました。すぐに確認したい方はこちらをご利用ください。zip圧縮したディスクイメージです。ダウンロードはこちらからどうぞ。

DaVinci Resolveが表示するコードバリューは、最も客観的で正確な情報であるため、非常に重要です。コードバリューは8ビット、10ビットなどの値で、3つのRGBコンポーネントのそれぞれのレベルを表します。各ページのビューアに表示されることもあれば、書き出されたファイル内に埋め込まれることもあります。また、ビデオI/Oを介して接続するSDIケーブルやHDMIケーブルの内部に流れることもあります。

Colorページのビューワにはpicker RGB valueの機能があり、8bitと10bitで表示できます。この値はDaVinci Resolveのレンダリング結果をビューワに表示した際の、RGBチャンネルのコードバリューを示し、スコープにも反映されます。また、RGB値を元にしてファイルに書き出されるため、とても重要な情報です。

この便利な機能には、動作の一部に課題がありました。ここで表示されるコードバリューは、ビューワの右上のオプションメニューから8bitと10bitの切り替えができます。8bit表示の際に、ファイルに書き出されたコードバリューと表示のものとの間にわずかな違いがありました。picker RGB valueでの表示は、レンダリングバリューをもとにしていると考えていますが、その際得られた値は一旦10bitに値を丸めているのではないか。その後10bitから8bitへの変換を行っていて、その結果、10bitの下位2ビットが切り取られる際に8bitでは数値に誤差が発生しているのではないか、と考えています。さらに、タイムラインを切り替えた直後には、正確なRGB値を表示しないこともしばしばありました。解決策としては、面倒ではありますが一旦picker RGB valueを無効にしてから、改めて有効にすると正常に表示できます。

これと似たような、コードバリュー表示の別の方法もあります。macOSにはDigital Color Meterというアプリが、ユーティリティフォルダに用意されています。これを起動すると小さなウインドウが現れて、スポイドで目的の部分をピックするとRGB値などが読み取れます。一見すると先に紹介したColorページのpicker RGB valueと同じに見えますが、Digital Color Meterでの値はColorSyncの処理の結果を見ているので、両者は一致しないことが多くなります。Digital Color Meterでの値は、ビューワの先にある、Macに接続されたモニターの表示と相関関係があるので、この値はモニター面の色味を示していると考えても大きな違いはないと私は考えています。本来ならば、測色機を用いてモニター面を測定するべきですが、それは簡単ではないのでこのような方法を使っています。

このDigital Color Meterでの表示は、ColorSyncが加わった値ですが、DaVinci Resolveの環境設定でColorSyncを無効にした場合には、この表示はDaVinci Resolveのレンダリングバリューと同じになります。つまり、Digital Color Meterの表示は、picker RGB valueと同じになります。前述の通り、picker RGB valueの8bit表示には誤差が含まれることから、より正確にビューワ値を8bitでピックしたい場合には、Digital Color Meterを使うことで誤差を回避できる場合があります。ただし10bit表示には対応していないので、これは8bit専用の使い方になります。DaVinci Resolveの環境設定でColorSyncの有効か無効に関わらず、picker RGB valueの値は常にレンダリングバリューを示し、スコープもその値を示します。

ファイルに書き出したメディアファイルの中を見るには、ファイル内をHEX（16進数）表示できるアプリがあると便利です。私はAppStoreから入手できる、Hex Fiendを使っています。例えばRGB8bit形式で書き出したメディアファイルを見てみると、先頭に40byteのヘッダがあり、それに続いてRGBデータが並んでいます。この16進数のコードバリューを見れば、どのようにファイルに出力されているのかが確認できるわけです。上のスクリーンショットでは、GreyとRedの境界あたりを表示しています。コードバリューは、画像の左端から右端に向かってピクセルの値が並んでいます。

DaVinci Resolveが示すコードバリューを得るためには、自分で把握できているテストチャートを使うことで、間違いなく変化を検出できるようになります。今回はとてもシンプルな二つのカラーパッチを含むテストチャートを使います。これは、CutまたはEditページで内蔵のSolid Colorを使って、事前に決めていたコードバリューのチャートを作りました。それを元にしてファイルをエクスポートして、そのファイルをDaVinci Resolveにインポートして再利用します。現実的な制作では使うことのないシンプルなチャートをここで使う理由は、DaVinci Resolveの動作の傾向を見つけるためです。検証の最後段階では、普段と同じような実データで検証することが欠かせません。

上記のチャートで、グレーのコードバリュー128は50%だとわかりますが、赤いカラーパッチはなぜこの値なのでしょうか。Rは75%、GとBは25%なので、パレード表示の目盛りに合わせてあるのです。検証中には値の変化を確認することがよくあり、こうしたわかりやすい値は、一目で変化に気付きやすい利点があります。当初はマクベスチャートから赤のパッチの色を使っていましたが、現在はこの赤に変更しています。

出力されるメディアファイルの内部には、一般にNCLCと呼ばれる三つの数字の組み合わせで表す、映像の状態を示す情報が含まれることがあります。このメタデータは当初QuickTimeで採用されたものでしたが、現在ではITU-T H.273で規格化されて、各種ファイル形式にも広がり始めています。BT.709準拠のファイルでは、表のように1-1-1が使用されます。先頭から順に、カラースペース、ガンマ、カラーマトリクス係数を示します。この三つの数値の組み合わせは、Finderの「情報を見る」から確認できる場合があります。DaVinci Resolveからのエクスポートでは、Output color spaceによってこの情報は確定しますが、オプションでDeliverページから上書きできます。

ビデオI/Oによる外部モニターとの接続についても、確認する必要があります。この写真のように、ビューワのpicker RGB valueで確認した値と同じコードバリューが信号に流れていることが確認できました。写真のコードバリューは16進数表記で10ビットなので、ビューワ値と比較するために、16進数から10進数に変換後、4で割って8ビットのコード値としました。ファイル出力とSDI信号のコードバリューは、DaVinci Resolveのビューワに現れるpicker RGB valueと同じであることが確認できました。

DaVinci Resolveは1984年生まれの映像ツールです。誕生からしばらくの間は、ハードウエアとしての巨大なシステム製品でした。そして、その中で扱うフォーマットは、主にNTSCとBT.709 HDでした。外部接続のマスターモニターは、常に必須でした。当時のDaVinci Resolveシステムから出力する映像信号にも、ガンマは付加されていなかったはずです。この頃のDaVinci Resolveの信号処理方式は、BT.709モニター用に設計されていたため、Display Referredでした。厳密には、BT.709のOutput Referredです。この名残が今でも残っていて、プロジェクト設定のカラーサイエンスにある「DaVinci YRGB」設定です。DaVinci Resolveのバージョン12以降では、ここに加えて柔軟にカラーワークフローへ対応できるように、カラーサイエンス設定が大きく変更されました。この時に登場したのが、「DaVinci YRGB Color Managed」です。これにより、Input、Timeline、そしてOutputの三つのcolor space設定が必要になりました。

DaVinci Resolveはハードウエアからソフトウエアへと変化し、現在では多くの映像制作者が利用できるように無償版が提供されています。ユーザー層が広がったことで、カラーグレーディングをはじめとして映像編集を行う環境を限定することが難しくなりました。外付けのマスターモニターを接続するようなポストプロダクションもあれば、MacBook Proだけで完結するようなYouTuberなど、さまざまなケースが想定できます。むしろ、Macだけで制作するようなユーザーの方が主流になってきたと、個人的には感じています。誰でも簡単に快適に、DaVinci Resolveを使う時代がやってきました。

前述したように、BT.709フォーマットを使ってMac内だけで映像制作を完結させる場合、ガンマをどう扱うかが課題になります。そこで、Input、Timeline、Outputのcolor space設定に用意されているプロファイルが活躍します。現在の最新版では、5つのRec.709と名のつくプロファイルが用意されています。このプロファイルには、色域を表現するカラーガマットと、明るさを調整するためのガンマが含まれます。そのプロファイルがどのようなカラーガマットとガンマ設定を含んでいるのかを確認するためには、プロジェクト設定のカラーマネージメントに進み、Use separate color space and gammaのチェックを有効にします。

• Rec.709 (Scene)
• Rec.709 Gamma 2.2
• Rec.709 Gamma 2.4
• Rec.709 HLG ARIB STD-B67
• Rec.709-A

このリストにあるHLGは、明らかにSDR完パケでは除外できても、残る4つをどのように選択して運用するのかは、頭の痛い問題ではないでしょうか。

検証はコードバリューのチェックに基づいて行われるため、使用するソースを正確に把握する必要があります。一般的に使われている画像生成アプリを使用することもできましたが、DaVinci Resolve内からTIFFファイルを出力することにしました。QuickTimeファイルの代わりに、NCLCを持たないTIFFファイルを使用することにしました。

DaVinci Resolveを起動してCutページに進みます。Editページでも構いません。Effectパレットの中からGeneratorsセクションに進み、Solid Colorでグレーとレッドの2色をトラックに分けて上下に配置します。トラック2に配置したレッドのCrop Leftを960ピクセルにして右半分だけの表示にします。仕上げにこの二つのトラックを複合クリップにします。これにより、先に示したチャートが出来上がります。それぞれのRGB値は上記を参照してください。値に関しては自分で把握できるのであればどのような値でも構いませんが、0%や100%から離れている値をお勧めします。これは、ガンマの影響が顕著に現れるためです。

このタイムラインの設定は、タイムライン設定のColorから下のスクリーンショットのように設定しました。これにより、作成したカラーチャートは値を保持したまま出力されます。その後、DeliverページからTIFFファイルを1フレームだけ書き出しておきます。

先ほどのチャートを作成したDaVinci Resolveプロジェクトとは別に、プロジェクトを作成しておきます。カラーサイエンスは、Scene ReferredのDaVinci YRGB Color Managedを使用します。DaVinci Resolve18.5以降では、タイムラインごとにカラーサイエンス設定を個別に指定できるようになりました。先のテストチャートを作成した時のように、プロジェクト設定とは別にタイムラインのカラー設定が必要になる点に注意してください。

Mediaページから、作成したテストチャートのTIFFファイルを読み込みます。この際のInput color spaceは、Rec.709 (Scene)にします。これにより、ファイルに記録された色が維持され、入力時に色が変化するのを防ぐことができます。

次に、インポートしたテストチャートを使った、タイムラインを四つ作成します。タイムラインの名称はわかりやすいものにしました。タイムラインを作成したら、Mediaページからタイムライン設定で、タイムライン毎にOutput color spaceをRec.709 (Scene)、Rec.709 Gamma 2.4、Rec.709 Gamma 2.2、そしてRec.709-Aに設定します。Colorページに切り替えて、ビューワをpicker RGB valueとDigital Color Meterで確認してみました。その結果を下記の表にまとめました。

picker RGB valueはレンダリングの値を示しているので、ここでの表示はファイル出力した際の書き込まれる値と等しいことが事前の確認で明らかになっています。Sceneと2.4では、使用したソースクリップの値をそのまま維持していることがわかります。2.2とAは値が下がっていることから、映像としては暗くなっています。これに対して、ビューワの見た目の色を示すDigital Color Meterの示す値は、すべて同じでした。

四つの709設定を使用する場合、どれを選択してもビューワの見え方は変わらない反面、2.2とAではファイル出力と信号出力は暗くなる。これが示していることは、EOTF2.4の前提の環境で2.2とAのファイルをプレビューすると、明るくなるはずです。そのためここでは、2.4/2.2、2.4/1.96の逆ガンマ値が加わっていると考えられます。この計算式が正しいことを確認するために、ピックした値の下に理論値を並べてみました。理論値のコードバリューを計算するためには、一旦0%から100%の値に正規化して、結果を整数で表す8bitiに変換します。そのため、計算結果は小数点以下を四捨五入しています。

次に行う入力側の検証のために、先ほどのOutput color spaceのプロジェクトから、4本のQuickTime非圧縮RGB8bit形式のファイルを出力しておきました。それを新規プロジェクトにインポートします。

インポートしたクリップへのInput color spaceプロファイルは、自動で適用されるものもありますが、Rec.709-AのクリップはSceneが当たっていたので、修正しておきました。この四つのファイルの中で、Sceneと2.4は出力時にはガンマ補正をかけていませんが、2.2とAは先の説明のように暗くなるガンマ補正を加えていました。これを考慮して、このクリップを単一のタイムラインに並べてみました。タイムラインのOutput color spaceは、ガンマ補正がないRec.709 (Scene)にしました。

picker RGB valueの値がほぼ揃っています。Sceneと2.4は値が変わっておらず、2.2とAに関しては出力時の逆のガンマ補正が加わっているように見えます。そこで、ここでも計算結果を下に並べてみました。

この計算では、先の検証-1のOutputガンマの逆数になっている点が異なります。ピックと計算値がピタリと一致していることがわかります。

OutputとInput color spaceをコードバリューを観察しながら数式に照らし合わせて見てみると、下記のような特徴であることがわかりました。

この条件で注意するべき点があります。今回は自分だけでの検証だったので、読み込んだ素材で同じ1-1-1クリップでも、Rec.709 (Scene)なのかRec.709-Aなのかの判別がつきました。しかし、これが他からやって来たクリップの場合には、この違いは判別できるでしょうか？さらに、やって来たファイルの作成された環境は、DaVinci Resolveだとは限りません。受け取るクリップの素性に対する厳格な申し送りが欠かせません。NCLCだけではなく、出力時に逆ガンマ補正を加えてレンダリングしているかも、ともて重要な点です。

QuickTimeプレーヤーは、Macを使っているユーザーが動画ファイルを視聴する際に、一番利用されているアプリケーションだと思われます。以前は、動画ファイルの表示に関しては、色の再現性に掴みどころがなかったため、「使ってはいけないアプリ」だと私は位置付けていました。しかし、最近のバージョンではColorSyncに対応しているようで、Macのデフォルト動画ビューワとしての確固たるポジションに落ち着いていると言えます。一般ユーザーを含め、Macを使う際に多用されるため、色の見え方を確認してみました。

ここで知りたかったのは、DaVinci Resolveのビューワでの見え方が、QuickTimeプレーヤーでどのように変わるかということです。両者はColorSyncを有効にした状態で見ることが基本です。これまで見てきたように、DaVinci ResolveのビューワでColorSyncを有効にすれば、709のプロファイルを使ったOutput color spaceでは、どれも同じ色で見えます。これに対してQuickTimeプレーヤでほぼ同じ色で表示できるのは、2.4とAの二つだけでした。不思議だったのは、Sceneと2.2はNCLCも異なり、ファイルに書き込まれたコードバリューも異なるのに、表示はほぼ同じになるところです。この動作が何を意味するのか、今のところわかっていません。

Rec.709-AでDaVinci Resolveから出力したファイルなら、QuickTimeプレーヤーでも同じに見えるので、これからはこのプロファイルを使ってみよう。と考えるのは少し危険な面があります。なぜなら、このファイルをもしビデオI/Oを経由して表示すると、期待していた色よりも暗く表示されるためです。NCLCが1-1-1になっている点も要注意で、受け取った者が一般的な1-1-1ファイルで、ガンマの焼き込みが行われていないと誤解すると、再利用する際に逆ガンマ（1.96/2.4）をかけずに使ってしまうでしょう。そう考えると、Rec.709-Aの使い所はYouTube完パケのように限定的になるのではないかと思います。

ここまでの検証で、DaVinci Resolveの709プロファイルを使用すると、Input color spaceは上側に膨らんだupper gamma、Output color spaceは下側のlower gammaを加える処理が確認できました。次に確認したのは、DaVinci Resolveの内部で作成したSolid Colorが、ビューワと出力にどのような変化をもたらすのかです。この動作を見ることで、Input color spaceプロファイルを持たないクリップが、どのように処理されるかが判明すると考えました。

この表を見ると、これまで集めたコードバリューの傾向とは相反するようです。この結果だけを見ると、709プロファイルはどれを使用しても出力されるコードバリューに変化がありません。その代わりに、ビューワの見えはOutput color spaceによって明るさに違いが出ています。Input color spaceプロファイルを持たないクリップでは、外部から読み込んだクリップとは異なる処理をしているのでしょか？

実は私は当初そのように考えていました。しかし、繰り返し考えている中で、果たしてDaVinci Resolveはそのような面倒な処理を加えているのだろうか、との疑問が湧きました。そして、次のような推測に至りました。このような、Input color spaceを持たないクリップでは、自動的にOutput color spaceと同一のプロファイルを適用しているのではないか。これを裏付けるように、ColorページのCustomカーブパレットのヒストグラムをInputモードで見ると、Sceneのレベルは、2.2やAに比べて低くなっていました。

この推測で考えると、2.2やAのクリップでもスコープのレベルが変化しなかった理由が説明できます。入力側で2.2/2.4や1.96/2.4ガンマが加わり、出力側ではその逆数になる2.4/2.2や2.4/1.96ガンマが加わります。両者は打ち消し合うので、総合的なシステムガンマは1.0になり、レベルに変化が出なかったと考えられます。一方ColorSyncが有効なビューワでは、Output color spaceだけに依存した調整が加わるので、プロファイルにより明るさに違いが出たと考えられます。

個人的には、DaVinci YRGBカラーサイエンスは検証の時くらいしか使うことはありません。しかし、一般にはこちらの設定を、そのまま使われるユーザーの方が多いことも理解しています。主な理由は、DaVinci Resolveのデフォルト設定だからです。そこで、次はDaVinci YRGBではどのような特徴があるかを見ていきましょう。

このスクリーンショットは、プロジェクト設定のデフォルトを示しています。とてもシンプルで、TimelineとOutputの二つの設定だけです。Output color spaceをSame as Timelineにしておけば、Timeline color spaceだけの設定で済みます。ここまでのDaVinci YRGB Color Managed設定では、TimelineにDaVinci WG/Intermediateを選択していました。ここでも同じ設定と考えたのですが、デフォルト設定を使用されているユーザーが多いことから、スクリーンショットのようにTimeline color spaceだけの変更にすることとしました。

DaVinci YRGBカラーサイエンスでは、Input color space設定は必要ありません。基本的にはTimeline color spaceと同じプロファイルを持つクリップを、DaVinci Resolveの中で使用することを前提としています。ここではTimeline color spaceはRec.709 (Scene)を使用しているので、インポートしたクリップの持っているファイル内のコードバリューが、そのまま反映されていることがわかります。ビューワの見えであるDigital Color Meterの値は、レンダリングバリューに合わせて変化しているように見えます。ソースクリップがRec.709 (Scene)の時のビューワの色味はDaVinci YRGB Color Managedの設定と同じ値を示しているので、基本的な動作は同じであると考えて良さそうです。

当初感じたDaVinci Resolveの709処理は、とても複雑で理解に苦しむ印象でした。しかし、順を追って部分的にコードバリューを取ることで、だんだんと理解が進んでいきました。

DaVinci YRGB Color ManagedとDaVinci YRGBどちらでも、Output color spaceで四つの709プロファイルを使うと、ColorSyncが有効なビューワの表示色は同じです。異なるのは、ここからファイルに書き出した結果です。このため、ビューワのネイティブと言えるpicker RGB valueも異なります。ファイル書き出しでコードバリューが異なる理由は、2.4/2.2や2.4/1.96という1.0以上の値になるガンマを加えることで、暗くなるプロファイルがあるためです。一方で、709クリップを読み込んだ際の挙動は、Input color spaceのプロファイルによって変化します。Sceneと2.4では何も処理を加えないリニアなものですが、2.2とAでは2.2/2.4と1.96/2.4のガンマを加えます。これらは1.0よりも小さな値なので、明るく色が変わります。これが、DaVinci Resolveの709処理の概要です。

Rec.709 (Scene)

DaVinci YRGBカラーサイエンスでは、デフォルトのTimeline color spaceになっているように、開発者もこのSceneの利用を基本と考えているようです。Sceneを使うことで、入出力時にガンマ変更の処理を加えないので、一般的なシステムの動作と互換性があります。出力時にガンマを加えないため、モニター側でのEOTF2.4を加えることが前提となり、BT.709とBT.1886の規格に沿った運用ができます。ただし、このファイルを受け取った者が、Macの中でQuickTimeプレーヤなどで表示すると、期待していたよりも明るく見えます。これはアプリがEOTF2.4を適用せず、1.96を加えるからです。Rec.709 (Scene)ファイルは、ビデオI/Oを経由した業務用の用途でも安心して利用できます。

Rec.709 Gamma 2.4

基本的な入出力の動作は、Rec.709 (Scene)と似ている面が多いプロファイルです。最も大きな特徴は、エクスポートしたファイルのNCLCが、1-2-1になるところです。NCLCで2.4ガンマを想定してはいるものの、ファイル出力ではガンマ2.4を焼き込んでいない点は理解しておく必要があります。Rec.709 Gamma 2.4ファイルは、Macの中でQuickTimeプレーヤなどで正確に色の表示をしたい場合に利用できるでしょう。そのままビデオI/Oを経由して出力しても正常に表示できます。

Rec.709 Gamma 2.2

ガンマ2.4/2.2をファイル出力時に加える点が特徴的です。709の色域でガンマ2.2ということは、PC向けのディスプレイsRGB規格と同じことを意味します。sRGB環境で表示する前提の場合には、このプロファイルは使用できる可能性があります。また、Windows環境ではsRGB規格を採用しているモニターがまだ多い印象があるので、そのような環境をターゲットにする制作でも利用できるかもしれません。

Rec.709-A

NCLCが1-1-1で書き出せて、QuickTimeプレーヤーでの表示もDaVinci Resolveと同じなので、安易に利用してしまうかもしれません。しかし、ファイルに2.4/1.96ガンマで焼き込まれるため、映像が暗くなる特徴があります。最も用途が多いのがYouTube向けのようなWebコンテンツだと考えられます。しかし、この素材をWindows環境で見るとMacとは色の見え方が異なる点も悩ましいところです。

709クリップの読み込み

709フォーマットだとされるクリップをDaVinci Resolveに読み込む際には、NCLCの確認とそのクリップのコードバリューには、ガンマが「baked」されているかの確認は欠かせません。bakedというのは、このクリップが作成された際に2.4/2.2や2.4/1.96ガンマにより、暗めに記録する処理が加わっているという意味です。1-1-1クリップだとしても、DaVinci Resolveからの出力では、bakedのあるなしが選択できます。他のシステムがどうなっているかまでは私は調べきれませんが、基本的な709処理ならばbakedになっていないと思われます。

DaVinci YRGB Color Managedカラーサイエンスで、1-1-1クリップを読み込む際のオプションとして、環境設定の中に「Automatically tag Rec.709 Scene clips as Rec.709-A」があります。これにチェックを入れることで、読み込んだ1-1-1クリップに1.96/2.4ガンマ補正を加えてくれます。デフォルトではSceneクリップとして読み込む動作なので、それを大量に変更したい時には、この設定変更が役に立つでしょう。

基本的には、709クリップの読み込みでは、Rec.709 (Scene)として読み込むことをデフォルトにすれば大多数のクリップでは問題が出ないと思われます。予想以上に暗めに見えるような場合には、Input color spaceでRec.709-Aに変更すると明るく変更できます。もちろんColorページでの手動調整でも構いません。Input color spaceでRec.709 Gamma2.4プロファイルは、使う必要はないと思われます。これはRec.709 (Scene)と同じ入力処理になるので、Rec.709 (Scene)に統一した運用が良いかと思います。

709クリップの書き出し

YouTube向けコンテンツで、視聴環境がMac及び他のAppleデバイスであれば、Rec.709-AのOutput color spaceで良いでしょう。これにより、出力するファイルはbakedガンマになって暗めに記録されることも意識しておきましょう。

最も難しい問題の一つは、一般的な709クリップの書き出しです。選択肢としては、Rec.709 (Scene)とRec.709 Gamma 2.4があります。これらの違いはNCLCが1-1-1なのか、1-2-1の違いだけです。しかし、その違いが及ぼす影響は小さくありません。1-2-1で書き出す利点は、そのファイルをMacの中でQuickTimeプレーヤーなどを使って見るときに、DaVinci Resolveのビューワで見た色と同じにできる点です。聞くところによれば、放送局向けのメディアファイルは、1-1-1で作成するガイドラインがあるそうです。しかし、このファイルをMacで見ると明るく見えてしまいます。正確にプレビューするためには、1-2-1での運用が望ましいと思われます。しかし、他のアプリケーションで1-2-1書き出しに対応していないものもあると聞くので、このあたりの運用にはまだ改善の余地があります。

ビューワの動作

EditもしくはCutページでジェネレートしたSolid Colorを使った検証により、ColorSyncが有効なビューワの動作が理解できました。DaVinci YRGB Color Managedカラーサイエンスでは、Input、Timeline、そしてOutput三種類のcolor space設定があります。ColorSyncが有効なビューワは、Output color spaceのみに影響を受けているようです。このように、Outputプロファイルで指定する環境でモニタリングした際の、色の見えをシミュレーションしているような動作だと私は理解しています。

MacBook ProやiMacのようなモニター内蔵モデルでは、そのキャリブレーション精度には限界があると、私は経験から感じています。これらのMacでは、ColorSyncが有効なビューワの色は厳格ではありませんが、ある程度の「目安」にはなりそうです。一部のXDRタイプのモニターを搭載しているMacであれば、その精度も一定のレベルには届きそうです。

ここまでかなりの長文になってしまい、読み疲れた方も多かったと思います。恐縮です。冒頭でも書いたように、映像技術の中には意味が不明なものが多くあります。どのように設定するかの表面的なところさえ間違わなければ、結果オーライでツールを使っていることも多いでしょう。私もそんな使い方をしてしまうことはあります。一旦トラブルに見舞われた時に、どのように解決するかのヒントは、正確な知識が役に立つと私は考えます。DaVinci Resolveの709設定は日常でもよく利用するところだと思うので、是非理解を深めていただけると嬉しいです。

この記事を書く前までは、冒頭で述べたようにOutput color spaceはRe.709 Gamma 2.4を使っていました。しかし、今後はRec.709 (Scene)を使っていこうと考え方を改めました。誤解のないようにお願いしたいのですが、「Scene以外の設定は間違い」ではないのです。プロファイルとしてDaVinci Resolveに搭載されているので、何らかの使用用途はあるのです。何事も目的に応じて道具は使うべきです。

この考察の中では触れませんでしたが、現実的な撮影素材や完パケしたファイルなどを使って、ご自身で動作確認されることをお勧めします。「生きた」素材を使うことで、これまで見えなかったことが見えるかもしれません。

過去に私は、SNSやblogなど各所で自分で検証した結果をもとにして技術的な解説を試みてきました。時には誤ったことを発信したこともありました。DaVinci Resolveのガンマの取り扱いに関しては、この記事の内容に現在私が把握している情報の全てを出し切ったと思っています。過去の記事をご覧になった方も、改めてこれを参考にしていただくと、正確な知識の取得につながると思います。この記事を書いたことによって、フォローできなかった過去の私の記事の訂正につながることを願っております。

2024-02-14 10:54:05｜山本久之