Apply gamma correction to fonts

[Clownacy]

The documentation of Dear ImGui's FreeType support mentions that FreeType outputs in linear space rather than gamma space. What I find strange is that the docs suggest that users should convert their entire app to render in linear space, when I'd argue that it's better to just convert the rendered glyphs from linear space to gamma space. This is exactly what I did in an old project of mine which used FreeType. It's also a fix that I provided to the GLideN64 project.

Another thing that I found strange was that the documentation seems to suggest that linear space rendering is exclusive to FreeType: when compared side-by-side, however, both FreeType and stb_truetype appear to produce identical-looking bitmaps when it comes to their gamma curve (or lack thereof). Unfortunately, I couldn't find anything in stb_truetype's documentation which specifies whether stb_truetype purposefully outputs in linear space or gamma space. I suppose I could ask a maintainer via a GitHub Issue or Discussion, or somehow try to comprehend the source code.

With all of this in mind, I've applied gamma correction to both font renderers by hijacking the ImFontAtlasBuildMultiplyCalcLookupTable function. This function conveniently applies a post-processing effect to the glyph bitmaps, which is exactly what I need to apply my gamma correction. Now, this function both applies brightening/darkening, and gamma correction. This does technically mean that glyph post-processing is now always applied, even when cfg.RasterizerMultiply is 1.0f, so I've removed the multiply_table == NULL checks in the FreeType renderer that were made redundant by this change.

The FreeType Group explains the needs for gamma correction here.

Here's a comparison of font renderers with and without gamma correction (the font is Karla Regular at 22px):

FreeType w/out:

stb_truetype w/out:

FreeType w/:

stb_truetype w/:

At native resolution, stb_truetype with gamma correction appears to produce a more pleasing result, suggesting that the default appearance without gamma correction is incorrect:

FreeType w/out:

stb_truetype w/out:

FreeType w/:

stb_truetype w/:

[Clownacy]

I think this vaguely relates to #2943, since it ties into Dear ImGui's general handling of colour spaces.

[Demonese]

Hello, thank you for finding this problem and it gave me a lot of inspiration.
But, why the linear space -> gamma space curve is pow(x, 1.0 / 1.8) instead of pow(x, 1.0 / 2.2)? I think the latter one is more general (sRGB). And I remmenber 1.8 is using for some MAC devices.

Update:
Ok, the API reference of FT_Render_Glyph tell me the answer.

[Clownacy]

I think this is ready for merging. I've updated the title and description to be a bit clearer and also reference a FreeType webpage that explains the need for gamma-correction.

[emoon]

Would it be possible to have this change behind a define that a user can change if they don't want the fonts converted to gamma space?

[ocornut]

I haven't looked at it yet but either way I see no reason that this can't be configured by a runtime flag if needed.

[emoon]

Great! Compile time or runtime flag would both work for me. I run my application in linear mode and convert to sRGB at the end and would have to "undo" this step above otherwise.

[adamkewley]

After converting my app to use linear colors, sRGB textures, sRGB framebuffers, etc. (incl. ImGui, where I linearize the drawlist, at the cost of some precision loss), I ran into this odd behavior. It manifested as "wow my fonts look better when using GL_FRAMEBUFFER_SRGB").

❤️ for noticing this! However, I'd echo @emoon 's request to put this behind some kind of runtime flag. The reason why is because I, probably like other devs in the wild, have gone through the effort of making a downstream project (this) use "correct" colors/lighting equations, but this PR would actually mean that I'd need to un-correct the fonts.