Gamma-correct bilinear filtering as an option

[axredneck]

That's how GZDoom and old games do bilinear filtering:

W65B_2-old.png

That's how FTEQW, GIMP, Blender and modern game engines do it:

W65B_2-correct.png

It's especially noticeable on motley (e.g. heavily dithered) textures.

[Rachael]

In order to do this correctly the entire scene would have to be rendered in a (2.2) gamma and then render it back with a (1.0/2.2) gamma in post. I don't think there is any other way to do this to get the desired result.

Then dynamic lights would have to be adjusted to fade with the new gamma ramp. Not even sure how fog will work.

[Chris]

Having a gamma-correct rendering pipeline would be nice, especially for PBR stuff for more accurate lighting. But yeah, all currently available content is expecting sRGB rendering/blending so there'd have to be some method to opt-in to it when the content can expect it, probably at a game level.

[Nash]

The color difference demonstrated in the OP is even more obvious on this IPS monitor I'm using. I didn't even realize this was a thing before this. :O

The bottom one looks much more pleasing to the eyes, too.

[Rachael]

Yes - it makes linear filtering a lot more tolerable.

[Graf Zahl]

That's a bad texture for demonstration.

In any case, you'll need someone with better technical knowledge of how to implement it. It seems to involve a major rework of the entire renderer. I'm not going to do this myself.

[axredneck]

That's a bad texture for demonstration.

Yes, most textures look OK-ish. I showed this texture on purpose as extreme case among actual Doom textures.

[axredneck]

In order to do this correctly the entire scene would have to be rendered in a (2.2) gamma and then render it back with a (1.0/2.2) gamma in post. I don't think there is any other way to do this to get the desired result.

Doesn't Vulkan have some better way of doing it?

[Rachael]

The last thing we need to do is increase the complexity of the renderer when an option is available that provides more of a correct render for all elements rather than just the textures themselves. Putting in a change for just the textures would introduce an unnecessary complexity that would interfere with a better and more comprehensive solution which if implemented would solve this issue anyhow.

[dpJudas]

There is no real difference here between OpenGL and Vulkan. In both cases it involves setting the texture format to sRGB so that the linear sampling filter will interpolate correctly. Unfortunately that then creates a linear output. The easiest way to deal with that would be to then reapply the sRGB gamma right after the texture(tex, pos) call in the GLSL code.

If Doom was a modern game with complex modern lights this might be worth it. For Doom? It would make it run worse on lower end hardware for a very minor visual improvement for higher end. I'd say it isn't worth it. In any case, I won't try do it because I'm in the nearest filtering camp anyway.

[Graf Zahl]

That settles it. I fail to see the appeal if you need the ugliest texture in all of Doom to demonstrate the difference. Personally I never perceived the filtering as-is as incorrect.

[Darkcrafter]

Am I the only who prefers the way GZDoom does it better? Look at those huge awful red squares scattered over blue mess, the old way they're much thinner fireflies. I also obtained an LOC IPS monitor which I got rid off after a week of having and replaced it over old TS matrix one just because it seemed to me that I actually don't like the detalisation and color saturation it provides, especially in Doom that starts looking so brownish.