How do I disable Gamma Correction?

I’m currently trying to make the material for my character,
and while I’ve discovered you can turn off gamma correction in the texture preview, it frustratingly seems to still effect the characters material (including the texture preview in the Materials ‘Texture Sample’ Node…
Here’s a comparison of part of the texture:
Original on the left, gamma corrected in the ‘Texture Sample’ node of the material editor.

While I’ve found references to it in code commands in the documentation I haven’t been able to find anywhere how to disable this so that my material can be rendered as I want it to be.

I’d greatly appreciate a solution to this.

Turn off sRGB in the texture properties to disable gamma correction on a texture.

Thank you for the response, though that’s not quite the solution.
When I disable the sRGB value (which I was referring to in the first post as gamma correction in the texture preview), it changes the texture preview in the material editor from looking like the left, to the right.

However frustratingly though it looks closer to the original in the actual texture preview, it changes from the left (original) to the right (slightly lighter.duller).

Which means though the material is closer with sRGB turned on, there’s still a difference and I haven’t been able to work out how to solve that.

Try to use pow function, f.e.:

return pow(yourColor, 2.0);

It worked in UE3 with nice precision.

The minor differences in color in this image are likely to be due to the texture compression rather than any sRGB issues.

If you absolutely need the exact colors from the original file, you could try changing the compression mode to vector displacement, which seems to leave the texture uncompressed - complete with the performance implications that entails.

That’s a pretty ugly workaround though. I could barely see any difference until I took it into Photoshop for a close look, and even then I wouldn’t know which was the original if you hadn’t said. :slight_smile:

Thank you for your response.
That was with vector displacement compression though. And I tried changing through different compression settings too, but it didn’t solve the issue. The only thing I changed in that image between the left and the right is ticking/unticking sRGB, so the difference has nothing to do with the compression.
I realize it’s not much of a difference at that point, but I’m given a specific palette by our concept artist and I wish to hold true to those colors as they fit it best. and the difference becomes more visible when on the character and comparing it to the original, it just doesn’t look quite right.

I wouldn’t rely on the texture viewer preview too much, as it seems to display things in sRGB space regardless of the settings - that’s where the color differences came from too, not from compression. My mistake.

The material editor shows things as they should appear in game since it’s using the same shaders, and if the texture had sRGB disabled in the image in your original question then that actually appears to be working as intended.

Did you try comparing the original file to how it looks in the material editor with sRGB enabled? If it still doesn’t look right then I’d suggest setting a vector to the correct color value and seeing if that’s displayed similarly.

Sorry I thought I responded, musn’t have gone through correctly.
Thanks for your response. While it does bring it close to the original color, it would require more calculations and reduce the performance for every material I have, and it doesn’t get it any closer than the option of turning on sRGB (which while close still doesn’t result in the correct color), so regrettably that doesn’t solve the issue.

You should realize that there are two conversion steps going on:

  • You have a texture in gamma space that is converted to linear space before it’s used by a shader.
  • You have your final render target in linear space that is converted back to gamma space before it is send to your display.

Two conversion steps can obviously introduce minor differences, although the added benefit of correctly calculating your lighting in linear space is usually worth it.

By disabling the sRGB option on the texture you effectively turn off the first conversion. However, the second conversion still happens. To completely get rid of gamma correction you would also have to disable this correction. This used to be an option in UE3, but it seems like you have to dig a little deeper to do so in UE4.

However, know that there is a reason for this workflow, only disable it if you are making a game where you don’t care about correct lighting at all.

Thanks a lot for the deeper explanation of what’s going on.
Yeah, with the art direction I’m working towards there won’t be any lighting calculations like that necessary so completely removing gamma would be most preferable, but as mentioned I also couldn’t find it anywhere.

Here’s an extended comparison.
sRGB enabled on left,disabled on right.
Material on object preview/Material node editor preview/Texture preview.

Again I realize the difference is minor, I just don’t understand why there should even be a difference and I’d prefer the colors to appear as intended.
For additional comparison I’ve used Unity previously and never had any issue with something like this.

As you can see the sRGB disabled in the preview has the correct colors, but then ruins them completely in the Material previewer and on the model in the scene.

I looked into this a little more over lunch and got correct results (as in the output colors are numerically identical to the input texture as seen in Photoshop) by disabling sRGB and then doing a pow(x,2.2) immediately after the texture is sampled in the material.

This works because the gamma correction performed as the very last step before the image is sent to the display is pow(x,1/2.2) rather than the exact inverse of the sRGB conversion performed by the hardware during the texture lookup. The differences are minor, as seen here - the red line is sRGB, and the black dashed line behind it is gamma 2.2 - but if you need absolute precision then it’s not quite right.

It’s also worth noting that the final gamma correction on mobile platforms is sqrt(x) instead of pow(x,1/2.2) for performance reasons, so if that’s what you’re targeting you’ll need to multiply the texture by itself instead of using pow(x,2.2).

It’s generally not a good idea to convert textures to linear space manually like this, as it costs a couple of shader operations versus letting the hardware take care of it for free with the added bonus of correct filtering.

Alternatively, you could get the same results by disabling sRGB on all your textures and removing the final gamma correction from GammaCorrection.usf and TonemapCommon.usf. I haven’t actually tried this, and it’s likely there are other places it would need changing too. I’d also advise against doing this as it will cause incorrect results with lighting and many other mathematical operations. In gamma space, 2 + 2 = 9.

There’s a good article on gamma vs. linear space here for anyone interested.

1 Like

Thank you so very much for discovering and sharing all of that information.
It’s extremely frustrating that there isn’t an option available for people not trying to develop realistically rendered projects to turn gamma correction off, instead of having to add calculations to the material like that. Regardless though, 2.2 is indeed the magic number that allows the colors to render as intended, and thank you very much for the additional information regarding the fact it will need to be multiplied by it’s own material for the mobile build-which I’m intending to make. Certainly saved another future headache with that bit of extra information.

While I don’t understand all of that article I appreciate the link as it definitely shows the advantages it has, however when developing a specific art direction like our project it’s annoying to have to spend resources on working around something like that.

Thanks a lot for your help. While it’s disappointing that there is a performance cost even if in the grand scheme of things its likely minor, it seems to be the only option available at the moment so I’ll consider this solved.
(In the case of anyone else having difficulties with this and for extended clarification-make sure to set the metallic value to 1 to have the colors completely correct-which can be done by dragging the alpha channel of the texture to metallic.).

In my case I changed the image to 8bit channel in photoshop and it solved all the issues.

I opened the image in photoshop and in Image->Mode->8bits/Channel then saved and reimported