I have a texture SRV with a BC7_SRGB format. I write the content of this texture to a RTV with a R16G16B16A16_FLOAT format, which will be written to a RTV (my back buffer) with a R10G10V10A2_UNORM format, after applying a custom gamma correction. The result only looks correct if I use a custom gamma exponent of 1 (=no-op) for gamma correction?

MSDN says:

1. If a texture has sRGB content, ensure the ShaderResourceView has the _SRGB format modifier so when you read from the ShaderResourceView into the shader, you convert the texture content from gamma 2.2-corrected color space to linear color space.

So if they just use an approximate sRGB to linear conversion by raising to the power of 2.2. A simple raising to the power of 1.0/2.2 should be a no-op instead of raising to the power of 1.0?

are you reading the texture via samplers or image load ?

8 hours ago, Krypt0n said:

are you reading the texture via samplers or image load ?

Via sampling and filtering: 

g_sprite.Sample(g_linear_wrap_sampler, input.tex);

10 hours ago, cgrant said:

I'm confused. What does look correct means? The linear conversion happens when the SRV is read. If you write the sampled result to a RTV ( if I'm interpreting this correctly ) then the linearized value is whats actually written. Unless you are doing the exact gamma encoding step as the original input, I would not expect the result to look the same.

HLSL's conversion from sRGB to linear is just C^2.2.

In my final pass, I do C'^(1/2.2) = C, so the final output should be just the content of the texture as-is?

Currently, if I open the .dds file in Visual Studio, the appearance of the images does not match (mine looks over saturated when raising to the power of 1/2.2. In fact it only looks the same if I do not raise to a power at all.

23 minutes ago, matt77hias said:

HLSL's conversion from sRGB to linear is just C^2.2.

Approximately

23 minutes ago, matt77hias said:

Currently, if I open the .dds file in Visual Studio, the appearance of the images does not match (mine looks over saturated when raising to the power of 1/2.2. In fact it only looks the same if I do not raise to a power at all.

Do you have the original (non-BC7) image to compare against? Maybe VS is doing something off when visualising the image? 

Can you sample your data from plain BC7 and BC7_SRGB and compare the results? 

42 minutes ago, Hodgman said:

Do you have the original (non-BC7) image to compare against? Maybe VS is doing something off when visualising the image? 

Can you sample your data from plain BC7 and BC7_SRGB and compare the results? 

I needed to reconstruct the image, since I didn't had the originals anymore

I tried the following:

texconv -f BC7_UNORM_SRGB // original setup

texconv -srgb -f BC7_UNORM_SRGB // this looks more logical, doesn't look ok in VS (too dark), but turns out ok in my renderer

I assume that -srgbo is always implicitly included since my output format is an sRGB format.

9 minutes ago, pcmaster said:

Try another viewer, like AMD Compressonator. I wouldn't count on all viewers showing 16F textures fine. What about writing to a R8G8B8A8_UNORM render target instead, for a test, so you can inspect if the srgb/non-srgb sampler works fine and the bug isn't elsewhere?

When you use the correct SRV with BC7_UNORM_SRGB format, shader should return the "original" linear values. But you should be fine already, that's obvious.

I think it was just related to the Visual Studio viewer itself.

I now always use -srgb in texconv.

Eventually, I go to something like R8G8B8A8_UNORM. The 16F is just an intermediate (I view these in RenderDoc).