インカメラ VFX カメラの色補正

特定のカメラでキャプチャするために、LED ウォール上のコンテンツ表示をキャリブレーションする方法を説明します。

Windows
MacOS
Linux

概要

このドキュメントでは、所定のカメラでキャプチャするために LED ウォール上のコンテンツ表示をキャリブレーションする手順について説明します。この後に詳しく説明する手順は、次の通りです。

  • シーンでライティングなしのエミッシブ テクスチャを使用して、UE で既知の RGB 値のチャートを表示する。

    • カメラに関連するすべてのパラメータをオフにし、OpenColorIO (OCIO) のみに PQ エンコーディングがあることを確認します。

    • Brompton を PQ エンコードした RGB 信号を受信するように設定し、それを PQ Achievable と解釈し、さらに、ウォールへの再現を Achievable に設定します。

  • カメラを使用してウォールの映像をキャプチャする。

    • キャリブレーションを行う際に、カメラのホワイト バランスを 6500 に設定し、露出をウォール上の明るいホワイトのパッチをキャプチャするのに適切な値に設定します。

  • 標準的な方法を使用してカメラ映像をリニアライズしてから、カメラのエンコーディング色空間から UE のカメラ検証用色空間に変換する (以下で使用)。

  • 既知の RGB からリニアライズされた検証用空間の RGB に変換するマトリクスを見つける。そのマトリックスを反転し、 カメラ キャリブレーション用マトリクス を生成します。

  • UE で再度チャートを表示する。なお、この時点では作業色空間にいることが前提となります。

    • OCIO ソースを作業色空間に設定し、目標の空間を次の 3 ステップで得られる空間に設定する。

      • 参照空間からカメラ検証用空間にマトリクス変換する。

      • 計算したカメラ キャリブレーション用マトリクスを適用する。

      • リニアから PQ エンコーディング。

  • 再度チャートをキャプチャし、映像を作業色空間にリニアライズします。チャートをリニアライズしたチャートと比較します。これは、リニア コンテンツを使用して分析的に実行することが望ましいものの、同じ Look LUT を両方に適用して目視で確認することでも可能です。

インカメラ VFX のカラー パイプライン

上記の概要は、カメラ/LED ウォールの組み合わせ向けのキャリブレーションを行うために使用する手順を説明しています。この概要は、UE から LED プロセッサへのカラー パイプラインを適切に設定する手順を説明する目的でこのドキュメントの冒頭に記載されています。

Unreal Engine では 作業色空間 は明示されません。この空間は、暗黙的に リニア Rec709 です (リニア sRGB とも言う)。これは、エンコーディングがリニアであることを意味し、色空間は Rec709 プライマリおよびホワイト ポイントとなります。他の色空間のテクスチャとマテリアルを提供することもできます。これは、エンジンにとって作業色空間が Rec709 以外の色空間であることを意味します。他の空間で一般的なのは ACEScg です。これは、多くの VFX スタジオで使用されています。

重要なのは、バーチャル シーンはリニアであり、そのリニア値を LED ウォールに表現することが目的であるということです。このためには、ポストプロセス チェーンの部分を無効化しなければならず (または 0 に設定する)、UE の通常の「カメラ エフェクト」をバーチャル コンテンツに適用しないことを確認する必要があります。

[Bloom Intensity (ブルーム強度)] および [Vignette Intensity (ビネット強度)]0.0 に設定する必要があります。これらのエフェクトは LED ウォールへの出力には通常望ましくないからです。さらに、 [Expand Gamut (色域拡張)] の量および [Tone Curve (トーン カーブ)] の量を 0.0 に設定します。なお、トーン カーブの量は OCIO が有効なときは自動的にゼロに設定されますが、色域拡張はユーザーが制御します。

OCIO 変換には OCIO Configuration アセットが必要です。このアセットでは、ローカルの OCIO コンフィグ ファイルを参照します。さらに、このアセットには、UE により使用可能になる OCIO コンフィグの色空間のホワイトリストが含まれています。nDisplay 出力ビューポートを使用した特定の変換元と変換先の色空間を関連付ける方法の詳細については、こちら を参照してください。

  • リニアから信号値への OCIO 変換。

    • 変換元の色空間:リニア作業色空間

      • これにより変換元空間から OCIO 参照空間に変換されます。

    • 変換先色空間:PQ エンコードされた信号色空間

      • これにより OCIO 参照空間から変換先空間に変換されます。

    • OCIO 参照からリニア カメラ キャリブレーション色空間に変換します。

      • カメラ キャリブレーション マトリクス

      • リニアから PQ 変換

OCIO が有効なときに、トーンマッピング後に ポストプロセス マテリアル (PPM) を使用することはできますが、PPM をエンコードされたデータに対して操作することになります。これは予期しない結果になる可能性があります。なぜなら、PPM が使用可能なすべての値は、出力信号色空間とカラー エンコーディングにあるからです。

PPM を使用してシーンを変更する必要がある場合は、トーンマッピングの前に使用することをお勧めします。そうすることで、マテリアルがリニア値に対して操作していることが保証されます。たとえば、独自のカラー補正コントロールを提供する必要がある場合、この方法がそういった操作に適しています。

OCIO 変換の詳細

OCIO 変換の目的は、UE の作業色空間から LED プロセッサ用の出力信号に変換することです。

以下のカメラのキャリブレーション手順では、キャリブレーションがターゲットに一致していることを判定するために、特定の色空間を想定しています。これを カメラ キャリブレーション色空間 と呼びます。作業色空間 と同じように呼ぶこともできますが、柔軟性を確保するため、ここでは呼び分けることにします。

「config.ocio」ファイルでは、PQ エンコード化信号色空間の目標空間に次の特定の 3 つのステップが必要です。

  1. 最初に、OCIO 参照空間からリニア カメラ キャリブレーション色空間への変換があります。

  2. 2 番目に、カメラ キャリブレーション マトリクスが適用されます。これによりリニア カメラ キャリブレーション色空間からリニア信号色空間に変換します。なお、信号色空間はプライマリを使用してではなく、キャリブレーション プロセスを通して定義されます。

  3. 3 番目のステップは、リニアから PQ へのエンコーディングです。

一連のたステップを開始するために、2、3 個の個別 OCIO 色空間の定義が必要です。1 つ目はリニア カメラ キャリブレーション色空間で、以下の例ではリニア sRGB (リニア Rec709 とも呼ばれる) であり、また簡単に「色域 sRGB」と呼ばれます。他に必要となる変換は、リニアから PQ への簡単で単純な変換です。この変換では、リニア値 1.0 は nit 値の 100 であり、次に 0~10,000 から 0-1 のエンコード値への標準的な変換が続くことが前提となります。

     - !<ColorSpace>
        name: Gamut - sRGB
        family: Gamut
        equalitygroup: ""
        bitdepth: 32f
        description: |
          "BT.709 / sRGB" colorspace primaries and "D65" whitepoint as per "IEC 61966-2-1:1999".
        isdata: false
        allocation: lg2
        allocationvars: [-8, 7, 0.00390625]

     - !<ColorSpace>
        name: CCTF - PQ
        family: CCTF
        equalitygroup: ""
        bitdepth: 32f
        description: |
          "PQ" color component transfer function as per "SMPTE ST 2084". Assumes scene value of 1.0 corresponds to 100 nits.
        isdata: false
        allocation: uniform
        allocationvars: [0, 1]
        to_reference: !<GroupTransform>
          children:
            - !<FileTransform> {src: Dolby_PQ_10000_to_linear.spi1d, interpolation: linear}
            - !<CDLTransform> {slope: [100, 100, 100], direction: inverse}

OCIO リニア参照空間は、この例ではリニア カメラ キャリブレーション空間と同じものです。そのためガマット sRGB 空間では色変換は必要ありません。

実際のターゲットとなる色空間は、ここに示される通り、エンコード化信号色空間への変換です。この変換は、カラー マトリクスを含み、リニアから PQ へのエンコーディングが続きます。この色マトリクスの導出については、後で説明します。下記のマトリクス変換における各値は例として示してあります。これらの値は、お使いの特定の LED およびカメラのキャリブレーション結果に置き換えてください。

     - !<ColorSpace>
        name:View - Camera on LED Walls - PQ
        family:View
        equalitygroup: ""
        bitdepth:32f
        description: |
          View for content on LED Walls (via camera calibration calcs) assuming input in OCIO Reference, then encoding to PQ "ST 2084" HDR color component \ transfer function.Assumes scene value 1.0 corresponds to 100 nits.
        isdata: false
        allocation: uniform
        allocationvars: [0, 1]
        from_reference: !<GroupTransform>
          children:
            - !<MatrixTransform> {matrix: [0.80252942, 0.12102891, 0.07644168, 0, 0.05176983, 0.89236679, 0.05488673, 0, 0.01495024, 0.07238952, 0.88267732, 0, 0, 0, 0, 1]}
            - !<ColorSpaceTransform> {src:Gamut - sRGB, dst:CCTF - PQ}

シーンの露出

リニア値は PQ としてエンコードされ、その値は基本的な 0~10,000 nit の範囲に解釈されるので、シーンの露出は OCIO 変換の前に調整する必要があります。この調整は、CineCamera または PostProcess Volume の露出制御で行うことができます。ここでの重要なのは、バーチャル シーンの輝度と LED ウォールの実際の輝度を一致させることです。

一般的には、リニア シーンには HDR 値が含まれます。シーンの値の大多数は輝度が約 100 nit のであるのに対し、部分的にははるかに明るく、一部のピクセルは 2,000 または 3,000 nit になる場合もあります。多くの LED ウォールで、この輝度は LED パネルの性能を上回ります。その結果ウォールでは、シーンでは異なる可能性のあるピクセルが同じ輝度値になります。LED で表示可能な最大値は、多くの場合、1,500~1,800 nit であるためです。たとえば、LED の輝度の最大値が1,600 nit である場合、それは露出補正後のシーンのリニア値では 16.0 に相当します。

カメラ キャリブレーション マトリクス

カメラ キャリブレーション マトリクスの目的は、バーチャル シーンのリニア カラーとカメラ映像のリニアライズから生成された色が確実に一致することを保証することです。

その背景として、カメラは独自の一連のスペクトル応答を備えており、スペクトル応答はカメラのブランドごとに異なり、さらには人の目ごとにも異なります。LED は比較的狭いスペクトラムの分布であるため、カメラの応答の微妙な違いにより、別のカメラで撮影された LED の映像が違って見える可能性があります。この問題を軽減するためには、特定のカメラのリニアライズした映像がシーンで表現された値と一致するように、LED ウォールのピクセルを変更することをお勧めします。

そのマトリクスを作成するため、4 色の最小値を UE が表示する必要があります。これらの 4 つの値は、赤、緑、青、および白のパッチです。これらは、カメラがキャプチャし、ウォールに表示されるピクセルです。これが適切に処理されるには、ウォールでネイティブの色を生成するように LED プロセッサが設定されている必要があります。Brompton プロセッサの場合、これを Achievable と呼びます。他のベンダーではこれを Native と呼びます。この色空間を使用する目的は、キャリブレーションでカラー値をクリッピングすることなくウォールの性能をフルに活用することです。さらに、カラー エンコーディングは実際の撮影で使用されるのと同じカラー エンコーディングに設定する必要があります。Brompton 設定では、PQ エンコーディングを使用しました。

実際には、全体的な動作が想定通りであることを確認するためにより多くのパッチを使用しました。ただし、キャリブレーションの計算に必要なのは、わずか 4 つのパッチです。

以下はカメラ キャリブレーション マトリクスを作成する基本的な方法です。懸念事項と、問題になる可能性の点がありますが、これらについては後程説明します。

シーンのリニア チャートの表示

幾何学平面オブジェクトおよびライティングなしモードでパッチ値を表示するシェーダを使用して、UE でシーンのリニア チャートを表示します。各値は、既知のテクスチャ ファイルから、または平面のシェーダ マテリアル内の演算から得られます。

チャートは、既知のシーンの輝度値を含む赤、緑、青、および白のパッチを含んでいます。最も単純な例は、赤については (1.0, 0.0, 0.0) で、他の色のパッチの値も同様です。UE の露出を調整することにより、LED ウォール上に特定の目標とする輝度が含まれるようにチャートを表示する必要があります。輝度は、ウォールの最大値まで近づきますが、クリッピングにより発生する色の変位を避けるために最大値よりわずかに低い値になります。

チャートは、結果の映像で各パッチのサンプリングが問題なくできるほどに十分な大きさである必要がありますが、レンズのビネットにより発生するフォールオフの領域を避けられるように小さく、中心に配置する必要もあります。

OCIO 変換は、チャートが表示されたときに有効化されなければなりません。使用される変換は、最終的な目標となる変換と同様である必要がありますが、リニアから PQ への変換のみとなります (このステップでキャリブレーション マトリクスを作成しているため、キャリブレーション マトリクスは含まれない)。

ベンダー向けに映像をリニアライズする

映像は特定のベンダー向けに標準的な方法でリニアライズする必要があります。たとえば、Sony の Venice 向けには、映像は Sony XOCN F55 ST コーデックを使用してリニア化する必要があります。データは SGamut3-Cine 色空間でエンコードされた Slog3 です。このシンプルな例では、Nuke12 の Read ノードを使用して Rec709 色域にリニアライズしています。

映像のリニアライズに使用した方法と、結果が本当にリニアであるかを検証するために使用した方法を確認してください。このガイドの例では、Rec709 にリニアライズしました。しかしこの言葉は誤解を生むものです。なぜなら多くのユーザーは、コンテンツに適用された色対応表を通常持つ Rec709 カメラ出力について話すからです。このキャリブレーションの目的上、目標は、Look を適用しないカメラのネイティブ形式でキャプチャすること、およびキャプチャした映像を標準的な方法でリニアに変換することです。

カメラが 6500K のホワイト バランスに設定されていることを前提として、ホワイト パッチが、ほとんどニュートラルである必要があります。パッチにかなり色が付いている場合は、処理を進める前に問題を解決する必要がありますのある問題があります。

マトリクス作成演算

次のセグメントは、R、G、B、W のサンプル データからマトリクスを作成する方法のための演算です。

最初に、赤 緑 青の断片から 3x3 のマトリクスを作成します。

RR

GR

BR

F

=

RG

GG

BG

RB

GB

BB

I = F-1

そのマトリクスの逆マトリクスに、最大値が 1.0 に正規化されている白のサンプルを乗算します。

S = I × W/max(WRGB)

計算したスケール ファクターを F マトリクスに乗算し、その逆マトリクスを計算します。

SR

0

0

F

=

0

SG

0

x

F

0

0

SB

CalibrationMX = F-1

OCIO 変換にキャリブレーション マトリクスを配置する

結果のキャリブレーション マトリクスは、先程示したように、ウォール/カメラの組み合わせのための OCIO 変換に配置する必要があります。マトリクスでは、9 個の数字が、最初に 1 番目の行があり、次に 2 番目の行、次に 3 番目の行という順番で表現されることに注意してください。

上記の例では、OCIO 参照色空間は Rec709 でした。これは、キャリブレーション中のリニアライズに使用された色空間と一致します。他の OCIO 参照色空間を選択したら、キャリブレーション マトリクスは参照色空間からカメラの映像でリニアライズするのに使用した Rec709 空間への変換を含む必要があります。これは上記のアウトラインに「参照からカメラ検証用空間へのマトリックス変換」で説明しています。

キャリブレーションの検証

カメラ キャリブレーション マトリクスが有効で適切に機能していることを確認することは有益です。これを行うには、最初のキャプチャで使用されたのと同じ方法を使用して既知のパッチを表示します。ただし、色空間の目標が新たに作成したキャリブレーション マトリクスを含むことは除きます。

目標は、シーンのリニア空間の既知のパッチの値が、同じ作業空間に戻すリニアライズの後の映像にある値と一致することです。

以前は、必要なパッチは単純に R、G、B、および W でした。検証のためには、0 から 1 の既知の位置にある値を含めると役立ちます。このイメージは、0.25 ずつ離してある 5x5x5 の断片の集合を示しています。結果としてリニア空間におけるサンプルの等間隔配置になっています。

Calibration patches for full verification

単なる RGBW 以外のサンプルを含める理由は、このイメージのリニアライズした映像が輝度によるクリッピング (または他の同様の懸念点) があるかどうかを確認するのに役立つためです。

リニアライズの例

次の例は、3 つの異なるカメラ フォーマット用の Nuke12 スクリプトのノードです。いずれの場合も、変換は Rec709 線形色空間に変換されます。これは、前述した評価に使用されたものです。

AlexaV3LogC

AlexaV3LogC settings, part 1

AlexaV3LogC settings, part 2

ARRI .arx ファイル形式 (または ARRI .mxf) の Nuke ノードには クリップ設定Colorspace オプションがあります。クリップ設定はデフォルトのまま、そして Colorspace オプションは AlexaV3LogC に設定する必要があります。

この設定により、ARRI Wide Gamut 色空間に線形データを得ることができます。ターゲット空間 (この例では sRGB) へ変換するためには、追加の Colorspace ノードが必要です。線形エンコーディングを維持し、AlexaV3LogC から sRGB へ変換します。

Sony Venice

Sony Venice settings

Sony XOCN ファイルの Nuke ノードは、コーデック専用オプション野中に Gamut オプションがあります。このオプションを Rec709 に設定すると、変換は SLog3 S-Gamut3-Cine から Rec709 リニアになります。

RED

RED settings, part 1

RED settings, part 2

RED R3D ファイルのインポート ノードには、ターゲットの色空間がありません。通常の RED カラー パイプライン (IPP2) では、結果の線形データの色空間は REDWideGamutRGB になります。この事実は、グレー表示された色空間オプションのツールチップで強調表示されます。この例では、REDWideGamutRGB から Rec709 への変換の値を事前に計算した Read ノードの後に ColorMatrix ノードが追加されています。

Unreal Engine のドキュメントを改善するために協力をお願いします!どのような改善を望んでいるかご意見をお聞かせください。
調査に参加する
閉じる