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?

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. 

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.

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.

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).