Hi,

after reading a couple of resources in web about Gamma Correction I still feel confused.

In my experiment pixel shader simply outputs linear gradient to backbuffer.

- First case: backbuffer format is not sRGB, value of linear gradient is outputted without any modifications:

[attachment=22107:ng.jpg]

- Second case: backbuffer format is sRGB, value of linear gradient is outputted without any modifications:

[attachment=22104:g1.jpg]

- Third case: backbuffer format is sRGB, value of linear gradient is outputted with correction of pow(u, 1/2.2):

[attachment=22105:g1div2.2.jpg]

- Fourth case: backbuffer format is sRGB, value of linear gradient is outputted with correction of pow(u, 2.2):

[attachment=22106:g2.2.jpg]

As you see, first and last results are almost the same. So, my question is why we need sRGB backbuffers plus modifying final output pixel shader if we can simply use non-sRGB texture? The result is almost the same:

[attachment=22108:pixcmp.jpg]

Hello Ashaman73, as I understood you are talking about sRGB color space and HDR, but my question is about advantage sRGB backbuffer + pow(u, 2.2) over non-sRGB format + direct output.

What I can guess from comparison image (last one in my first post) the advantage is in precision of Gamma curve applied to final image. With sRGB backbuffer + pow(u, 2.2) it is more precise. Right? Are there any other advantages?

The correct workflow is:

Source sRGB textures (explicitly tell d3d they are sRGB) -> normal non sRGB (linear) offscreen buffer (with a higher precision like fp16) -> sRGB backbuffer.

This way the hardware will remove the gamma component from the source textures when it reads each texel, and apply linear math (for things like blending) to the normal (non-rRGB) offscreen buffer, it will then reapply the correct gamma when copying the offscreen buffer to the backbuffer. This will 'just work' as expected. However, you MUST submit your textures as sRGB.

Have you read the article "The Importance of Being Linear"? It does a pretty good job of explaining why you need gamma correction, including the situations when you should use it and when you shouldn't. I applaud the OP's willingness to experiment, but in this case it seems like you don't get the high level concept just yet - so please try to read through that article and come to a mathematic reasoning for doing this and then the correct operation will be quite clear.

Hi Jason,

I have read this article (anyway thank you for a link) and understand the mathematic reasoning of Gamma Correction process. All is clear for me with sRGB images sampling and correction for further linear calculations. All intermediate calculations should be outputted to buffers with any correction. That is also clear for me.

The misunderstanding actually is with sRGB backbuffer. I thought that sRGB backbuffer is like JPEG in sRGB color space, meaning that all values in sRGB backbuffer are already Gamma Corrected (pow(value, 1/2.2)). If so, then final color values should outputted with pow(value, 1/2.2) correction. But no, it seems the sRGB backbuffer is the opposite of what I thought. Furthermore, final color value should be outputted with pow(value, 1/2.2) correction for non-sRGB backbuffers, right?

I thought that sRGB backbuffer is like JPEG in sRGB color space, meaning that all values in sRGB buffer are already Gamma Corrected (pow(value, 2.2)). If so, then final color values should outputted with pow(value, 2.2) correction. But no, it seems the sRGB backbuffer is the opposite of what I thought.

No, the display/monitor itself does the pow(value,2.2) itself, in the display hardware.

If you do the pow(value,2.2) yourself, then you end with seeing pow(pow(value,2.2),2.2) after the display emits the picture

I mean 1/2.2 not 2.2. Already corrected my previous post. Sorry for that..