前のセクションでは、古いSDR Color Pipelineと、最も一般的な2つのSDRディスプレイとそれらの色空間標準（sRGBおよびRec. 709）について説明しました。しかし、色彩管理とディスプレイには、SDRディスプレイは欠点があリます。色彩表示とストレージの需要が高まるにつれ、HDRディスプレイの時代が到来しました。これらの複雑なディスプレイと色の標準により、Pipeline全体に重大な管理上の課題が追加されました。ACESは、すべての段階で一貫した表示結果を達成するために生まれました。
4.1SDRの欠点
SDRの最も明らかな欠点は、非常に狭い色域をカバーし、CIE 1931色空間の約35.9％しか占めていないことです。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
彩度が非常に高い一部の色は、このような低い色域では表現できないため、色表現の豊かさに影響します。同時に、低色域で照明とレンダリングを計算すると、色の値がclipされ、色の精度に影響します。
また、SDRのOETF関数と最終的なディスプレイの輝度の間には不確実なギャップがあります。これは、SRD OETFの出力範囲が0〜1であり、ディスプレイの最大輝度が不確であるためです。これは、特定のディスプレイモデルに関連しています。たとえば、HDTVディスプレイのピーク輝度は、通常、PCディスプレイのピーク輝度よりも大きいです。使用したSDR Tonemapping曲線は、低輝度のPCディスプレイでうまく機能する可能性がありますが、高輝度のピークを持つHDTVでは細部の表示がダメになるかもしれません。もちろん、高輝度のディスプレイに別のTonemapper曲線を使用して、強調表示の部分の詳細を増やすことができますが、色彩管理が複雑になってしまう危険性があります。
これらの問題に対処するために、HDR色空間標準を導入しました。
4.2 HDR色空間標準
最も一般的なHDR色空間標準はITU-R Recommendation BT.2020（REC. 2020またはBT.2020と略称する）。 REC. 2020は、HDR色空間の三原色（R（0.708,0.797）、G（0.170,0.046）、B（0.170,0.046））および白点（D65）を定義しています。色域範囲について、CIE 1931の色空間の75.8％をカバーできます。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
Rec. 709と同様に、Rec. 2020標準も正確なOETF伝達関数を指定しています。
ここで、αとβの値は、32ビットの完全精度で1.09929682680944と0.018053968510807、12ビットの精度で1.0993と0.0181、10ビットの精度で1.099と0.018です。
Rec. 2020標準では、SDR表示で使用するEOTF関数を定義しています。このEOTF関数は、BT.1886で定義されているEOFT関数であるRec. 709と同じです。 Rec. 2020で使用されるより一般的な伝達関数は、HDRディスプレイで使用されるEOTF関数です。これは、ITU-RBT.2100で定義されているST2084またはHLG伝達関数です。
4.2.1 2084/PQ伝達関数
ST 2084はSMPTE ST 2084（Society of Motion Picture and Television Engineers、2014）と呼ばれ、Rec. 2020の3原色で使用されるEOTF関数（つまり、output-referred encoding function）です。もともとはドルビー（Dolby）によって定義されたPQ（Perceptual Quantizer）と呼ばれるエンコード関数であり、最大10000cd /m²（ニット）の高い動的輝度値をエンコードできます。PQ伝達関数の本質は、コーディングスペースを最大限に活用して、人間の視覚系が明るさへの感知に応じてデジタル信号を定量化することです。簡単に言えば、人間の目が知覚できる輝度色階（banding）が避けられる場合に、データを量子化させ、エンコードを行います。
以下は、人間の視覚システムから派生したBarten Rampモデルです。これは、現在の輝度値（横座標）の下で、2つの輝度値の違いが人間の目でどの程度認識できるかを示しています。輝度の差が点線より上にある場合、人間の目は明るさのコントラストを認識でき、いわゆるbanding現象が発生します。輝度の差が点線より下にある場合、人間の目はそれを区別がつかず、滑らかで且つ漸進的です。
Source: HDR in Call of Duty
Barten Rampモデルに依存して、輝度エンコーディング曲線のデータ使用率を評価できます。 たとえば、下の緑色の線は、16ビット精度（OpenEXR形式など）で輝度値を直接保存することによって生じる輝度精度の違いを表しています。その違いはすべて曲線の下にあるため、視覚的なbandingはありません。
Source: HDR in Call of Duty
以下のオレンジ線と青線は、それぞれ15ビットと10ビットの精度でガンマエンコーディングを使用した曲線を表しています。10ビットの精度のガンマエンコーディングが0〜1の輝度範囲での輝度差は、曲線の上にあります。これは、人間の目に見える色階の問題があることを意味します。 15ビットの精度のガンマエンコーディングは曲線の下にありますが、強調表示された領域でのエンコーディングはデータの無駄です。つまり、これらの領域に格納されている多数の異なる輝度値は、人間の目から見れば大きな差がありません。紫色の線は、13ビット精度のLogエンコーディングを表します。15ビットのガンマエンコーディングと比較すると、強調表示された領域のデータエンコーディングをより十分に活用しますが、低輝度領域のデータが無駄になります。
Source: HDR in Call of Duty
ドルビーが提案した12ビット精度のPQ伝達関数を用いて得られた輝度差曲線を以下に示します。PQ伝達関数のエンコーディング方法は、各輝度区間の範囲にエンコーディングデータをより有効に活用できることがわかります。
Source: HDR in Call of Duty
ITU-R BT.2100は、PQ用の特定のEOTF伝達関数を定義します。 ST 2084 EOTF伝達関数は次のとおりです。
定数値は次のとおりです：
その曲線は次のように表されます。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
PQ OETF関数は、前に見たsRGBまたはRec. 709のEOTF関数とは大きく異なることがわかります。まず、PQ伝達関数は0から10000cd /m²の範囲の絶対輝度値を出力しますが、SDRは0から1の範囲の相対輝度値を出力します。SDRディスプレイによって表示される真の輝度値不明です。この確実性は、debug時にも役立ちます。たとえば、PQ値が0.5である時、古いLCDディスプレイのピーク輝度値である約100 nitに対応します。PQ値が0.75である時、一部のHDRTVディスプレイのピーク輝度値である約1000nitに対応します。
PQ伝達関数の視覚的な一貫性により、output-referred imageのワークスペースとして適しています。これにより、エンコードされたデータを最大限に活用して視覚的なエラーを減らすことができます。実際、多くのゲームエンジンは、最初にPQ伝達関数を使用して、HDRを表示するときにシーンの線形輝度値を0から1のエンコード値に変換し、これを使用してColor GradingおよびTonemapping操作用の3DLUTをサンプリングします。たとえば、HDR表示用の3D LUTを計算するときに、UE4はST 2084 ToLinearを使用してデコードして線形輝度値を取得し、この輝度値で後続のカラー操作を実行します。
// Since ST2084 returns linear values in nits, divide by a scale factor to convert
// the reference nit result to be 1.0 in linear.
// (for efficiency multiply by precomputed inverse)
LinearColor = ST2084ToLinear(LUTEncodedColor) * LinearToNitsScaleInverse;
この3DLUTをサンプリングする場合、上記の計算の逆関数を実行して、線形輝度値を0から1のテクスチャサンプル座標に変換します。
// ST2084 expects to receive linear values 0-10000 in nits.
// So the linear value must be multiplied by a scale factor to convert to nits.
float3 LUTEncodedColor = LinearToST2084(LinearColor * LinearToNitsScale);
float3 UVW = LUTEncodedColor * ((LUTSize - 1) / LUTSize) + (0.5f / LUTSize);
float3 OutDeviceColor = Texture3DSample( ColorGradingLUT, ColorGradingLUTSampler, UVW ).rgb;
上記のPQ伝達関数には、2つのpow計算と1つのrcp計算が必要です。計算するときに、コマンドの消費に注意してください。
//
// Dolby PQ transforms
//
float3 ST2084ToLinear(float3 pq)
{
const float m1 = 0.1593017578125; // = 2610. / 4096. * .25;
const float m2 = 78.84375; // = 2523. / 4096. * 128;
const float c1 = 0.8359375; // = 2392. / 4096. * 32 - 2413./4096.*32 + 1;
const float c2 = 18.8515625; // = 2413. / 4096. * 32;
const float c3 = 18.6875; // = 2392. / 4096. * 32;
const float C = 10000.;
float3 Np = pow( pq, 1./m2 );
float3 L = Np - c1;
L = max(0., L);
L = L / (c2 - c3 * Np);
L = pow( L, 1./m1 );
float3 P = L * C;
return P;
}
PQ伝達関数は最大10,000nitの絶対輝度値をサポートできますが、ほとんどのディスプレイの輝度ピック値は2,000 nitを超えることはなく、多くのHDRディスプレイの輝度ピック値は約1,000nitであることに注意してください。もちろん、最も簡単な方法は、シーンの輝度値を線形にスケーリングして特定のディスプレイの輝度値に対応させ、ST 2084 OETF関数を使用してエンコードしてディスプレイに送信することです。しかし、SDRディスプレイで見たように、この線形から線形への対応は視覚的な線形性を満たさないため、明るい領域と暗い領域の両方でも細部が不足します。したがって、シーン内の高い動的輝度値をディスプレイデバイスがサポートできる輝度範囲に再マッピングするには、何らかのトーンマッピング操作が必要です。このトーンマッピング操作は、強調表示部と陰影部のコントラストを目立たせることができ、より良い視覚効果が得ルことができます。 ACESは、最も一般的なHDR曲線のマッピング（View Transform）のいくつかを提供します。これらは、それぞれ1000 cd /m²、2000 cd /m²、4000cd/m²の標準HDRディスプレイに使用されます。これらのマッピング機能の本来の目的は、HDRディスプレイをSDRディスプレイと可能な限り視覚的に一致させることです。これらのマッピング関数については、後でACESについて説明するときに詳しく説明します。
4.2.2HLG伝達関数
HLG伝達関数は、ゲームエンジンのHDR表示パイプラインでは一般的に使用されていません。ここでは、完全を期すために簡単に説明します。 HLGの正式名称はHybridLogGammaで、BBCとNHKは共同で設計したコーディング機能です。HLG伝達関数の設計の本来の目的は、主にHDR表示ができないSDRディスプレイと互換性を持たせることです。つまり、従来BT 1886 EOTFを使用していたSDRディスプレイにHLG信号を送信すると、表示効果を得ることができます。
HLGコーディング関数もITU-RBT.2100で定義されており、ここではHLGEOTFの関数曲線のみを示します。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
4.3 The Domination：ACES
撮影デバイスの型番や特定のエンコーディングおよび表示標準や制作プロセスの段階（合成、CG、VFXなど）でのデータ入出力の複雑さにより、映画やテレビの制作では色彩管理が非常に難しい作業です。問題が発生しやすいリンクとして、推測や当てずっぽうの場合がよくあります。ACESは、この問題を解決するために存在する管理システムです。
ACESの定義は以下の通りです。
The Academy Color Encoding System (ACES) is a set of components that facilitates a wide range of motion picture and television workflows while eliminating the ambiguity of legacy file formats. The system is designed to support both all-digital and hybrid film-digital motion picture workflows.
—— From github
このシステムは主に次のような部分からなっています。
（１）いくつかの仕様
色エンコディングとメトリックの仕様
ファイル形式の仕様
色変換、およびオープンソースバージョン（CTL言語を使用）のコード実装を提供する
（２）ACESで色変換を使用して参照画像を処理した結果に対応する一連の参照画像と校正ターゲット画像。これはユーザーがACESシステムの実装の精度を検証するのに役立ちます。
（３）システムとソフトウェアツールのドキュメント
ACESのドキュメントは広範囲にわたり、その命名と有用性について非常に厳密に説明されています。これらのドキュメントは、ACESの個々の標準と実装の詳細について詳しく知りたい場合に最適なリファレンスです。たとえば、TB-2014-001は、他の各ドキュメントの一般的な使用方法を提供する概要ドキュメントです。TB-2014-002は、ACESインターフェースと概念をユーザーによりよく紹介するため、ACESをソフトウェアに統合する必要がある開発者向けのユーザー製品エクスペリエンスガイドを提供します。TB-2014-012は、ACESのさまざまなコンポーネントの詳細な名前（色空間、色変換、ファイル形式を含む）を提供します。
9
リアルタイムレンダリングの場合、私たちに最も関係のあるのは、色のコーディングと色変換に関するACESシステム仕様の一部です。
4.3.1カラーコーディング
ACESシステムは、映画やテレビの制作プロセスのさまざまな段階で使用するためのいくつかの色空間を定義します。これらの色空間の三原色と変換関数の定義は、それらのアプリケーションシナリオ用に特別に指定されており、次のものが含まれます。
（１）ACES2065-1：線形変換関数でエンコードされたscene-referred色空間です。主なACESプロセスでの画像交換作業に使用されます。
三原色：AP0（ACES Primaries 0）という名前の三原色値を使用します。これらの値は、1931 CIE xy色度図でR（0.7347、0.2653）、G（0.0、1.0）、B（0.0001、-0.077）です。
白色点：D60値と類似しているが同じではない白色点値（0.32168、0.33767）。一部の記事では直接D60と呼ばれることもありますが、これは実際には不正確です。
（２）ACEScg：線形変換機能でエンコードされたシーン参照色空間でもあり、主にCG、VFX、合成ステージの作業スペースに使用されます。
三原色：AP1（ACES Primaries 1）という名前の三原色値を使用します。これらの値は、1931 CIE xy色度図でR（0.713、0.293）、G（0.165、0.830）、B（0.128）です。 、0.044）。
白色点：白色点の値はACES2065-1の値と同じで、つまり（0.32168、0.33767）です。
（３）ACESproxy、ACEScc、ACEScct：これら3つのスペースの三原色と白色点の値はACEScgと同じですが、異なるコーディング深度と伝達関数が使用されます。たとえば、ACESproxyは、伝達関数の色空間としてlogを使用して、10ビットまたは12ビットの整数データエンコーディングを使用します。これらの色空間は、主に映画やテレビの制作プロセスで使用され、ゲームのリアルタイムレンダリングではほとんど触れられません。
AP0とAP1の原色の値は、アプリケーションシナリオのために、多数の専門家によって厳密に設計および定義されています。 AP0の3つの頂点で囲まれた領域には、スペクトルトレース全体が含まれています。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
AP0は、AP0線形色空間で正の値を使用して、人間の目に見える色値をエンコードできるように定義されています。 AP0に対応する三原色の値は物理的に不可能ですが、つまり、現実の世界ではそのような3色を作成することはできません（1931 CIE XYZの三原色と類似している）が、これはアプリケーションシナリオ。と関わり、その広い色域は、制作プロセスでの画像転送の中間色空間として理想的であり、情報の損失を最小限に抑えます。
AP0と比較すると、AP1の色域範囲は非常に「保守的」であり、AP1が囲む色域範囲は、スペクトル軌跡とわずかに交差していますが、Rec. 2020に非常に近いです。
Source: https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
色情報を最大限に保持およびエンコードすることを目的とするAP0とは異なり、AP1はCGおよびVFXでのレンダリングおよび照明計算に適しています。レンダリングに使用される色空間の選択は非常に重要です。これは、照明の計算方法に影響を与え、したがって最終的なレンダリング結果、特に間接照明の計算に影響を与えます。どちらも平等であるにもかかわらず、いくつかの色空間は他の色空間よりも優れていて正確であると言えます。
これは、色空間の比較に言及する必要があります。コンピュータレンダリングの分野では、私たちの計算はすべて、色空間の三原色、つまり3次元空間におけるこの色空間の3つの基本ベクトルに基づいています。次の状況を考えてみましょう。sRGB空間で特定の色を使用して特定の照明計算を実行した後、結果をCIE XYZ空間に変換して結果Aを取得します。これらのsRGB空間の色をACEScg空間に変換して同じ照明計算を行なった後、その結果もCIEXYZ空間に変換して、結果Bを取得します。結果Aと結果Bが同等でないことが多いのは憂慮すべきことです。
数学的には、この現象をより簡単に理解できます。さまざまな色空間の3つの基底ベクトルは、XYZ空間では正規直交基底ではありません。これらの非直交基底には、加算や減算などの操作を除いて、乗算と除算と指数などの一般的な照明計算さえも同価ではありません。では、これらの結果のどれがより正しいかをどのように比較しますか？
一般に、スペクトルレンダラー（波長で色の計算を行う。Mitsubaなど。）を使用して得られた結果はground truthであり、Ward and Eydelberg-Vileshin (2002)、Langlands and Mansencal (2014)、Mansencal (2014)などは色空間比較の実験を行い、AndersLanglandsとThomasMansencalは、『Computer Graphics』という記事で、これらの実験の結果について簡単に説明しました。比較結果は次のとおりです。
Source:https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/
上記の最初の3行は、Rec. 709、Mitsuba、およびRec. 2020が同じターゲットに対するレンダリング結果です。最後の2行は、MitsubaからRec. 709とRec. 2020を差し引いた差です。色が濃いほど、差が小さいほど、結果がground truthに近く、より正確であることを意味します。Rec. 2020の全体的なパフォーマンスは、スペクトルレンダリングの結果に近いことがわかりますが、場合によっては、Rec. 709のパフォーマンスが実際に優れていることもわかります。実際、まだ胸を叩いて、コンピューターのレンダリングに最適な色空間があるとは言えませんが、ThomasMansencalは次のように述べています。
Some RGB colourspaces have gamuts that are better suited for CG rendering and will get results that overall will be closer to a ground truth full spectral rendering. ACEScg / BT.2020 have been shown to produce more faithful results in that regard.
—— From this article
以前の研究では、三原色がスペクトル軌跡に近い色域空間のレンダリング結果は、スペクトルレンダリングの正しい結果に近いことが多いことが示されています。ACEScgはそのような色空間であり、その三原色AP1はスペクトル軌跡の近くにあり、且つRec. 2020およびその他の一般的な広色域空間が含まれているため、CGやVFXなどのコンピューターレンダリングのワークスペースとして理想的です。
10年以上前は、sRGBとRec. 709が業界で最も一般的な規格でしたが、技術の進歩に伴い、Rec. 2020などのHDR広色域色規格が普及しており、古いSDR色域空間は、いつか歴史の舞台から撤退するのも早晩のことといえます。AP0とAP1のこれらの特性により、将来、広い色域を持つ新しい色空間がさらに提案されたとしても、それらは非常に強力な互換性を持ち、短期間で歴史によって排除されることはありません。これは、ACESの強度システムも反映しています。
##色変換
ACESはまた、映画やテレビの制作のすべての段階で、完全で強力な色変換のセットを定義しています。これらの変換には次のものが含まれます。
（１） Input Transform：Input Device Transform（IDT）とも呼ばれていました。 ACES 1.0の正式名称は、ACES Input Transform、または略してInputTransformです。入力データをscene-referred色空間に変換する役割を果たします。たとえば、別の撮影デバイスで撮影された写真は、独自のIDTを使用して変換する必要があります。
（２）Look Transform：Look Modification Transform（LMT）とも呼ばれていました。 ACES 1.0の正式名称は、ACES Look Transform、または略してLookTransformです。 LMTは、正式なカラーグレーディングステップの前に全体的な画像の外観の変換を提供します。その入力スペースと出力スペースは同じです。このような変換が別々に抽出される理由は、フィルムとテレビのプロセスを使用するためです。
（３）Output Transform：RRT（Reference Rendering Transform） + ODT（Output Device Transform）とも呼ばれ、ACES Viewing Transformです。ACES 1.0の正式名称は、ACES Output Transform、または略してOutputTransformです。その中で、RRTは画像をscene-referred空間からoutput-referred空間に変換する責任があり、ODTはRRTの結果を特定の出力デバイスの色空間に変換し続ける責任があります。 RRT + ODTは、scene-referred画像を特定のディスプレイデバイスに完全にレンダリングする変換操作であるため、Viewing Transform/Output Transformと呼ばれます。
映画やテレビの制作の分野では、IDTはさまざまなカメラ機器メーカーから提供されているという点で特別です。RED、Alexa、Canon、Panasonic、Sony、およびその他の主要メーカーには、独自の色空間とコーディング標準があります。ACESワークフローでは、これらのメーカーは自分の「レシピ」を公開する必要はなく、SMPTEのACES標準に従って独自のIDTを作成して、その画像データをACES色空間に均一に変換することだけで十分です。これにより、映画やテレビの制作プロセスにおける入力データの不確実性が排除され、これはACESの魅力なところといえます。もちろん、ゲームレンダリングでは、通常、IDT はsRGB画像をガンマ空間から線形空間に変換するところに使用されます。
LMTは、ユーザー定義のLUT変換ステージであり、その入力コントロールはscene-referredの線形シーン空間です。その機能は調色と混同されやすいです。画像の領域ごとに異なる種類のカラー操作を必要とする調色とは異なり、LMTは画像全体を変更し、「調子を設定する」役割を果たす変換操作です。それが特定の変換に分離される理由は、全体的な画像操作の一部がより複雑であり、LMTは映画やテレビのさまざまな制作パイプライン間で共有されるそのようなLUTアプローチを提供するためです。ゲームのレンダリングでは、LMTの存在は比較的薄いといえます。
RRTはACES委員会によって開発されたものであり、その出典は「調色されていない画像をどのように見せたいか」という質問として理解できます。ACESはこの質問に答えるために多数の業界専門家を集め、最終的にこのRRT変換を取得しました。その特定の実装は、githubでACESによって提供されたCTL実装バージョンを参照できます。ODTの特定の定義も同様です。ODTとRRTの定義には特定の主観的な要素があり、これらの業界の専門家が各ディスプレイで画像を最良の結果として表示する方法を考える方法の変化であることがわかります。ゲームレンダリングの分野では、ほとんどの場合、sRGBおよびRec. 709のODTを扱います。これらのODTには、画像を視覚的に「より良く」するためのトーンマッピングのような操作が含まれています。業界で最も目の肥えた多くの目によって検証されており、簡単に変更するべきではありません。 RRT + ODTを直接変更するのではなく、事前に調色して画像の外観を実現する必要があります。
ACES 1.0では、RRTとODTは2つの独立したステージであり、それぞれにTone Scale操作があります（特定の実装については、githubにあるRRTソースコードとODTソースコードのセクションを参照してください）。
このTwo Stage Tone Scaleモードは非常に紛らわしく、実装はあまり直感的ではありません。これは、HDR Output Device Transformに関連する標準を策定するのに役立ちません。 したがって、ACES委員会はACES ODT改善計画を提案し、代替として統一されたSingle Stage Tone Scale（SSTS）アルゴリズムを使用することを選択しました。 統合プロセスパイプラインは次のとおりです。
新しいOutput Transformソースコードの実装から、元のRRTステージで色の計算を保持し、SSTS曲線を使用してTonemapping操作を完了することがわかります。 ネーミングでは、新しいOutput TransformはRRTODTをプレフィックスとして使用して、以前の個別のOutput Transform（ODT）ステージと区別します。
以下は、映画やテレビの分野でACESを使用する比較的完全なプロセスです。
Source: https://z-fx.nl/ColorspACES.pdf
映画やテレビの制作プロセスのCGおよびVFXステージでのACESの適用は、ゲームのレンダリングと非常に似ています。
Source: https://z-fx.nl/ColorspACES.pdf
ACESは、誰もが認める色彩管理の達者です。
4.3.3DCCのACES
現在、さまざまなソフトウェアでACESワークフローを使用する最も便利な方法は、OpenColorIOを使用することです。OpenColorIOは、SonyPicturesImageworksによって開発されたオープンソースの色彩管理システムです。Nuke、Fusion、MayaなどのソフトウェアはすでにOpenColorIOをサポートしています。色彩管理にOCIO構成ファイルを使用できます。最新のACES OCIOファイルはgithubにダウンロードできます。これらの構成ファイルは、画像のさまざまなACES色変換を行うのに役立ちます。
残念ながら、Substance Painterなどの一部のソフトウェアはまだOpenColorIOをサポートしていません（Substance Designerは2019年後半にサポートすることを発表しました）。ただし、これらのソフトウェアでは通常、色変換にカスタムLUTを使用でき、これらのソフトウェアに必要なLUT形式の特定のLUTファイルを生成できます。たとえば、Substance Painterでは、単一のLUTイメージを使用して、sRGB linearからACESsRGBディスプレイに変換できます。このLUTは、Nukeによって作成することも、コードによって直接生成することもできます。
Christophe Brejonは、彼の本の中で、さまざまなソフトウェアでACESを使用するプロセスとリファレンスを示しています。OpenColorIOとカスタムLUTを使用すると、基本的に、さまざまなDCCソフトウェアでの色の校正作業を満足させることができます。
映画やテレビの制作プロセスのACESとゲームのゲームにはまだいくつかの違いがあります。ゲームでHDR表示を実現するには、ACESプロセスにいくつかの変更を加え、ゲームの特定の開発作業を行う必要があります。次のセクションでは、他のゲームとエンジンについて見ていきます。
参考文献
１、Digital Dragons 2018: HDR in Call of Duty
２、https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html
３、https://nick-shaw.github.io/cinematiccolor/academy-color-encoding-system-aces.html
４、https://nick-shaw.github.io/cinematiccolor/visual-effects-animation-and-games.html
５、https://www.oscars.org/science-technology/aces/aces-documentation
https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/
６、https://github.com/ampas/aces-dev/
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
今なら、UWA GOTローカルツールが15日間に無償試用できます！！
よければ、ぜひ！
UWA公式サイト：https://jp.uwa4d.com
UWA GOT OnlineレポートDemo：https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ：https://blog.jp.uwa4d.com