PostProcess HDR10 support for additional source colorspaces

[walbourn]

The shader that performs HDR10 signal preparation assumes the HDR source is using the Rec.709 color primaries when it does the rotation to Rec.2020:

static const float3x3 from709to2020 =
{
    { 0.6274040f, 0.3292820f, 0.0433136f },
    { 0.0690970f, 0.9195400f, 0.0113612f },
    { 0.0163916f, 0.0880132f, 0.8955950f }
};

float3 rgb = mul(from709to2020, color);

The result is 'correct', but can result in less saturated colors. A common hack is to assume DCI-P3 color primaries instead:

static const float3x3 fromP3to2020 =
{
    { 0.753845f, 0.198593f, 0.047562f },
    { 0.0457456f, 0.941777f, 0.0124772f },
    { -0.00121055f, 0.0176041f, 0.983607f }
};

float3 rgb = mul(fromP3to2020, color);

Another option is a slightly expanded custom color space version of Rec.709:

static const float3x3 fromExpanded709to2020 =
{
    { 0.6274040f, 0.3292820f, 0.0433136f },
    { 0.0457456, 0.941777, 0.0124772 },
    { -0.00121055, 0.0176041, 0.983607 }
};

float3 rgb = mul(fromExpanded709to2020, color);

The ToneMapPostProcess class should be updated to support these new options for the final output.

[walbourn]

There's also a Display P3 matrix one could use as well:

    const XMMATRIX c_from709toDisplayP3 =
    {
        0.822461969f, 0.033194199f, 0.017082631f, 0.f,
        0.1775380f,   0.9668058f,   0.0723974f,   0.f,
        0.0000000f,   0.0000000f,   0.9105199f,   0.f,
        0.f,          0.f,          0.f,          1.f
    };

All of these options defintely pushes to the idea of having the shader fetch the HDR10 colorspace matrix from a CB instead of having it baked into the shader...

See also this issue