Jump to content

  • Log In with Google      Sign In   
  • Create Account


[DX11] Why we need sRGB back buffer

  • You cannot reply to this topic
15 replies to this topic

#1 user88   Members   -  Reputation: 268

Like
3Likes
Like

Posted 13 June 2014 - 03:32 AM

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:

ng.jpg

 

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

g1.jpg

 

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

g1div2.2.jpg

 

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

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:

pixcmp.jpg


Edited by user88, 13 June 2014 - 03:33 AM.


Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 6685

Like
7Likes
Like

Posted 13 June 2014 - 04:03 AM


The result is almost the same

Yes, almost is the little, but important, feature. Standard images and displays still work with 8bit only, and 8 bits are really low nowadays. Most game engines will work internally with 10,12,16,32 bit per channel and the final rendered images needed to be converted (pressed) into 8 bits to be displayable by your devise (monitor). The trick with the sRGB color space is, that it distribute the visible distinguishable colors better on just 8 bits (the human eye can't distinguish dark color as good as bright colors) and therefor displaying the image reproduce less artifacts. That's it, just an improvement of display quality while keeping the memory impact the same.

 

PS: the devise should support the sRGB color space, else you would encounter artifacts or it would be converted back to a devise compatible mapping.


Edited by Ashaman73, 13 June 2014 - 04:07 AM.


#3 joeblack   Members   -  Reputation: 253

Like
1Likes
Like

Posted 13 June 2014 - 04:23 AM

Hi, in this simple case it can look like same, but whole point of linear vs gamma is when it came to calculations, e.g. when values are multiplied/added together. Normally you would think that 1 + 1 = 2 and 1*1 = 1, e.g when you double light intensity or blend two lights together, result will have doubled brightness, but gamma is not linear so 1 +1 can be 3.

#4 user88   Members   -  Reputation: 268

Like
0Likes
Like

Posted 13 June 2014 - 06:00 AM

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?



#5 phantom   Moderators   -  Reputation: 6786

Like
9Likes
Like

Posted 13 June 2014 - 06:45 AM

Erm, if the backbuffer is sRGB then you shouldn't be providing ANY changes to the values you are writing out; you should be writing linear values and allowing the hardware to do the conversion to sRGB space when it writes the data.

The correct versions are either;
linear maths in shader => sRGB buffer
or
linear maths in shader => pow(1/2.2) => non-sRGB buffer 8bit/channel image

Anything else is wrong.
(Also, keep in mind sRGB isn't just a pow(2.2) curve, it has a toe at the low end to 'boost' the dark colours).

Edited by phantom, 16 June 2014 - 04:53 AM.


#6 mark ds   Members   -  Reputation: 1071

Like
6Likes
Like

Posted 13 June 2014 - 07:09 AM

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.


Edited by mark ds, 13 June 2014 - 07:13 AM.


#7 Jason Z   Crossbones+   -  Reputation: 4683

Like
5Likes
Like

Posted 14 June 2014 - 06:08 AM

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.



#8 user88   Members   -  Reputation: 268

Like
0Likes
Like

Posted 16 June 2014 - 01:33 AM

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?


Edited by user88, 16 June 2014 - 01:48 AM.


#9 Hodgman   Moderators   -  Reputation: 27590

Like
0Likes
Like

Posted 16 June 2014 - 01:37 AM


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 biggrin.png



#10 user88   Members   -  Reputation: 268

Like
0Likes
Like

Posted 16 June 2014 - 01:49 AM

 


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 biggrin.png

 

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



#11 Hodgman   Moderators   -  Reputation: 27590

Like
7Likes
Like

Posted 16 June 2014 - 02:23 AM

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

That's correct... but no correction is required to be performed when the buffer is outputted, because it's already been applied when the values were stored.
 
The display expect to receive data that has been encoded into sRGB format (approx pow(1/2.2)).
No matter what kind of back-buffer you use, the bytes in that buffer are sent to the display as-is.
JPEGs are stored with sRGB correction already applied, so JPEG data is sent to the display without any further modifications applied to the data.
 
If you're using an sRGB back-buffer, then when you draw into this back-buffer, the GPU automatically does the linear->sRGB conversion (pow(1/2.2)).
If you're not using an sRGB buffer, then you have to manually perform the pow(1/2.2) yourself in the shader code.
 
So:

  • pixel shader outputs linear data to sRGB buffer -> data is converted using the linear-to-srgb curve -> sRGB(data) sent to the display -> user sees correct/linear result
  • pixel shader outputs linear data to linear buffer -> data is not converted -> linear data sent to the display -> user sees incorrect result (~gamma 2.2 curve)
  • pixel shader outputs gamma-corrected data to linear buffer -> data is not converted -> gamma-corrected data sent to the display -> user sees correct/linear result
  • pixel shader outputs gamma-corrected data to sRGB buffer -> data is converted using the linear-to-srgb curve -> sRGB(sRGB(data)) sent to the display -> user sees incorrect result (~gamma 0.45 curve).

Either you output linear data to an sRGB buffer, which automatically applies sRGB gamma correction, and sends an sRGB signal to the display.
Or, you output manually perform sRGB correction yourself and send data to a regular buffer, which still results in an sRGB signal being sent to the display.
 

So, my question is why we need sRGB backbuffers plus modifying final output pixel shader if we can simply use non-sRGB texture?

You shouldn't do either of those things.
You should either use sRGB with no modification during output, or you should use non-sRGB with modification on output.
Your first, third and fourth images are all incorrect. The second image is correct.
 
The reason you think the first image is 'correct' is because "mathematically linear" is not the same as "perceptually linear". In order to perform correct lighting and shading calculations, or to be able to reproduce the same photograph that we captured earlier, we need all the data to be mathematically linear.
 
If you're painting pretty gradients, you don't care about maths and you just want it to look good, you care about perceptions, not mathematical correctness tongue.png So your test, of painting a black/white gradient, is not a very good test for this purpose. It turns out that "gamma 2.2" is also a pretty good approximation of the human perception of brightness! So the non-linear "gamma 2.2" gradient is perceived as being fairly even, even though it's mathematically curved.

 

In modern games, this perceptual part is taken care of by the tone-mapping algorithm. All of the lighting algorithms still require mathematical linearity though.
 
I don't know if it's because of JPEG artifacts, or problems with your program, but none of your images are quite correct. When measured at equal points along the horizontal though, I got these intensity measurements. As you can see, the 2nd image is the closest match to a linear gradient cool.png

 0%, 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90%, 100% -- Ideal linear gradient
 0%,  2%,  6%, 12%, 20%, 30%, 40%, 53%, 67%, 83%,  99% -- image #1
 0%, 16%, 28%, 39%, 48%, 58%, 67%, 76%, 84%, 93%,  99% -- image #2
11%, 44%, 56%, 65%, 72%, 78%, 83%, 88%, 92%, 96%, 100% -- image #3
 0%,  1%,  5%, 11%, 20%, 30%, 42%, 55%, 69%, 84%,  99% -- image #4

Edited by Hodgman, 16 June 2014 - 02:49 AM.


#12 Chris_F   Members   -  Reputation: 1938

Like
1Likes
Like

Posted 16 June 2014 - 04:40 AM

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:

attachicon.gifng.jpg

 

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

attachicon.gifg1.jpg

 

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

attachicon.gifg1div2.2.jpg

 

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

attachicon.gifg2.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:

attachicon.gifpixcmp.jpg

 

I'd like to point out that that only your second image is "correct", that is because your performed the "manual" conversion incorrectly. Maybe an older post of mine can clear up any lingering confusion. It's not complicated, but it trips people up often. To answer the question, the advantage of a sRGB renderbuffer is that it performs the actual linear to sRGB conversion, not a gamma approximation, and by using it instead of a pow() instruction you are less likely to make a mistake as you did. wink.png

 

Erm, if the backbuffer is sRGB then you shouldn't be providing ANY changes to the values you are writing out; you should be writing linear values and allowing the hardware to do the conversion to sRGB space when it writes the data.

The correct versions are either;
linear maths in shader => sRGB buffer
or
linear maths in shader => pow(2.2) => non-sRGB buffer 8bit/channel image

Anything else is wrong.
(Also, keep in mind sRGB isn't just a pow(2.2) curve, it has a toe at the low end to 'boost' the dark colours).

 

That should be:

 

linear maths in shader => pow(1 / 2.2) => non-sRGB buffer 8bit/channel image

 

And that is only correct insofar that it is a close-ish approximation to sRGB.


Edited by Chris_F, 16 June 2014 - 04:44 AM.


#13 phantom   Moderators   -  Reputation: 6786

Like
0Likes
Like

Posted 16 June 2014 - 04:55 AM

linear maths in shader => pow(1 / 2.2) => non-sRGB buffer 8bit/channel image


Yeah, my bad, if I was doing it by hand in shader code I'd have double checked that, but as I'd normally leave things linear (16f or 10rgb2a) or have sRGB source/dest I tend not to hold the number in my brain ;)

Anyway, post corrected now so anyone finding it isn't confused smile.png

#14 user88   Members   -  Reputation: 268

Like
0Likes
Like

Posted 16 June 2014 - 09:47 AM

Okay, with implementation of Gamma Correction as well as backbuffer sRGB format all is clear for me now.

 

Great post, Chris:

 

http://www.gamedev.net/topic/652795-clarifications-gamma-correction-srgb/#entry5127278

 

Hodgman, your post also was very helpful, thanks. One point is not clear for me. It is about "mathematically linear" and "perceptually linear" things:

The reason you think the first image is 'correct' is because "mathematically linear" is not the same as "perceptually linear". In order to perform correct lighting and shading calculations, or to be able to reproduce the same photograph that we captured earlier, we need all the data to be mathematically linear.

 

  - Why the linear gradient that i can see on screen looks like non-linear with gamma correction (second case in my first post)? I compared it visually with linear gradient that i have made in PhotoShop. Same width in pixels. On screen looks different. Is there some PhotoShop trick?



#15 Zaoshi Kaba   Crossbones+   -  Reputation: 3608

Like
0Likes
Like

Posted 18 June 2014 - 04:33 AM

I've never used gamma correction thing and I'd like to make sure I understand correctly.

I have to use SRGB diffuse/color textures, non-SRGB normal textures, SRGB backbuffer to make it gamma correct?

 

I've tried to compare results and here's what I've got.

SRGB backbuffer:

Screenshot 2014-06-18 13.01.56.png

Non-SRGB backbuffer:

Screenshot 2014-06-18 13.02.04.png

 

With texture:

SRGB backbuffer and texture:

Screenshot 2014-06-18 13.27.31.png

Non-SRGB backbuffer and non-SRGB texture:

Screenshot 2014-06-18 13.27.56.png

Texture source: http://minecraftworld.files.wordpress.com/2011/05/earth_flat_map.jpg

 

So SRGB variants are correct ones?


Edited by Zaoshi Kaba, 18 June 2014 - 04:34 AM.


#16 Hodgman   Moderators   -  Reputation: 27590

Like
2Likes
Like

Posted 18 June 2014 - 05:58 AM

Assuming that the textures were painted on an sRGB monitor, and you're viewing the results on an sRGB monitor, then yep.

 

n.b. the sharper termination line in the first sphere matches real life physics much more than the soft gradient in the second image too biggrin.png

Why the linear gradient that i can see on screen looks like non-linear with gamma correction (second case in my first post)?

The way that us humans perceive light is not linear.

 

e.g. If you're in a room lit by one light bulb, and you turn on a second bulb, physically/objectively/mathematically speaking the room is now twice as bright, but subjectively a person won't say that it looks twice as bright (their perceptions don't match the objective truth). You might have to turn on 10 light bulbs before the person says that the room is twice as bright as it was initially.

Likewise, if you get a gradient that looks linear/smooth and then measure it using a light-meter, you'll find that it's probably logarithmically curved!

 

I'm not sure how photoshop creates gradients - but there are several "smoothing" options from what I remember, to produce results that are perceived as looking nice.

 

The point of "being gamma correct" is mostly so that we can match how physics/maths works. When we add two lights on top of each other, we need them to behave the way they work in the real world.


Edited by Hodgman, 18 June 2014 - 06:06 AM.






PARTNERS