29 replies to this topic

[JarkkoL]

Sure, if you never do any lighting calculations with your textures ;) Even then if you do any bi-/trilinear texture filtering the results are off. sRGB isn't a texture format but a gamma standard, which tells how to linearize the color values assuming the widely used sRGB gamma.

[macnihilist]

@.oisyn: We did this in a dx9-engine and ran into _huge_ problems with blending. Because (apparently) all dx9-cards blend in 'gamma-space' (wrong) and all dx10 cards blend in linear space. And (at least at this time) there were no CAPS to check this behavior. (I think it's possible with an D3D9Ex device.)
With dx10 it should work correctly, although I'm not 100% sure about texture filtering and multisampling.

[.oisyn]

JarkkoL said:

Sure, if you never do any lighting calculations with your textures Even then if you do any bi-/trilinear texture filtering the results are off. sRGB isn't a texture format but a gamma standard, which tells how to linearize the color values assuming the widely used sRGB gamma.

Both opengl and directx support srgb texture formats (well, ok, in dx9 for example they are sampler and render states - documentation). The idea is that the values are converted to a linear space and back when reading / writing to such formats. According to the specs at least, I haven't ever experimented with it

[JarkkoL]

Heh, it's just the way those gfx apis limit gamma correction to specific formats, not that it's really a different format (: In DX9 you had sRGB defined as a sampler state. Anyway, in your earlier post you said "rather than sRGB data interpreted linearly" which kind of indiceted you didn't understand what was going on, i.e. that reading from sRGB texture does exactly that - linearizes the color data, so just thought of correcting that (:

[.oisyn]

JarkkoL said:

Anyway, in your earlier post you said "rather than sRGB data interpreted linearly" which kind of indiceted you didn't understand what was going on

Or that you were misinterpreting me. What DX9 does without the sampler states is interpreting the srgb textures as linear data. In that case you'll need to convert the samples yourself using an inverse gamma curve. But if the hardware understands that the data from the texture is actually srgb data (using the sampler state), it no longer interprets it as being linear and converts the samples using the inverted gamma ramp. That was the point I was trying to get across.

[JarkkoL]

People don't talk about linear interperation of the color data when you read the sRGB data straight without any gamma correction, so please don't use the term wrong and cause confusion ;)

[.oisyn]

Maybe you should buy an English dictionary then . Perhaps you're confusing interpretation with interpolation? Given that you write "interperation", whatever that might mean.

[JarkkoL]

Oh please ;)

[Reedbeta]

JarkkoL said:

No you wouldn't. You want the textures to be in linear space and just do the gamma correction as a post process for the output monitor in the very end.

Actually, given that we have only 8 bits per channel (even fewer with DXT), it's a good idea to store textures in gamma space. If you store textures or your framebuffer in linear space with only 8 bits you lose a good deal of precision in the darks, leading to banding once you convert the final image back to gamma space. But if you have a higher precision (11-12 bits per channel at least) then storing things in linear space is a great way to go.

Anyway, to clarify what I meant by the comment you quoted: I meant that you should store textures in gamma space, but decode them upon read (using the artist's monitor gamma or sRGB, whatever you decided to store it in), then do all the lighting computations (in linear space), then re-encode them into the user's monitor/TV gamma space at the end of the shader. Sorry for the unclear phrasing.

.oisyn said:

Wouldn't simply using actual sRGB textures (rather than sRGB data interpreted linearly) and an sRGB framebuffer do all the necessary conversions automatically? That's where the sRGB texture formats are for.

Yep, and it's great that the hardware supports these conversions built-in, and so much faster than doing the math yourself in the pixel shader. (Some NVIDIA GPUs also have fast PS instructions available for gamma, for even more flexibility - I don't know whether ATI GPUs do as well.)

[JarkkoL]

Yeah, you are right that it's better to have uneven precision of sRGB than using linear space for input textures.