renderer/metal: blend rendered text in linear RGB space (aka. Gamma Correction) #4686
Conversation
DO NOT MERGE, right now this is a draft for demonstration. Before, we were blending rendered text onto the background in sRGB space, which is linear in perceived color/brightness but _not_ linear in physical terms. Correct alpha blending requires decoding from sRGB space into linear RGB space, performing the blending, and then encoding back to sRGB space for presenting. See here for a very good article on the whole topic of gamma and how it relates to sRGB and text rendering: https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/#antialiasing In this demonstation, I do the decoding "by hand" in the shader, and rely on Metal do re-encode as sRGB, by setting the right pixelFormat on the colorAttachment. One thing to note is that correct alpha blending in linear space makes the rendered fonts look even thinner than they already are. When Kitty introduced alpha blending in linear space, they introduced a configuration that allows adjusting the gamma/contrast, which will thicken up the fonts again. Fonts being thinner when doing correct blending is also something that the article linked above explains, and you can confirm this behavior for youself by running through an example alpha blending calculation by hand, on pen and paper, say. TODO/Notes before merging: - Add config that allows thickening fonts - Check performance, maybe introduce a LUT for doing the conversions/decode - Follow up: I've only looked at Metal, but the Linux/OpenGL renderer probably has the same issues. I could work on that one next.
aljoscha
changed the title
|
There's nothing wrong with this implementation, however it isn't "correct" for macOS apps. After thorough investigation and a very helpful hint from @lunacookies, I've determined that these days what Apple seemingly does for their native apps (e.g. Terminal.app, TextEdit), is that they simply ignore gamma correction, but they avoid having particularly glaring fringing thanks to the fact that they render in the display's color space, which is typically a wide gamut color space more or less equal to Display P3. By rendering in a wide gamut color space, fully saturated sRGB colors are no longer at the very edges of the space, so blending issues are reduced quite a bit with no special extra handling required. In experimenting with trying to exactly replicate Terminal.app's rendering (which I have successfully achieved now), I've already got a branch locally which has most of the code required for doing things that way, so I'll probably clean it up a bit and PR it some time tomorrow. I intend to have things implemented in a way that can be generalized to the OpenGL renderer and Linux, and which will allow the user to configure their desired alpha blending, whether they want "native" style rendering or proper gamma correction (or possibly a special third option I cooked up, which might give the best of both worlds). Sorry to take this from you 😅 -- this PR is definitely on the right track if just doing proper gamma corrected blending was what was needed, but it's not exactly, and I already have most of the details of what is necessary worked out on my local branch. |
No problem at all! Closing now... |
Touches #2125
Before, we were blending rendered text onto the background in sRGB
space, which is linear in perceived color/brightness but not linear in
physical terms.
Correct alpha blending requires decoding from sRGB space into linear RGB
space, performing the blending, and then encoding back to sRGB space for
presenting. See here for a very good article on the whole topic of gamma
and how it relates to sRGB and text rendering:
https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/#antialiasing
In this demonstation, I do the decoding "by hand" in the shader, and
rely on Metal do re-encode as sRGB, by setting the right pixelFormat on
the colorAttachment.
One thing to note is that correct alpha blending in linear space makes
the rendered fonts look even thinner than they already are. When Kitty
introduced alpha blending in linear space, they introduced a
configuration that allows adjusting the gamma/contrast, which will
thicken up the fonts again. Fonts being thinner when doing correct
blending is also something that the article linked above explains, and
you can confirm this behavior for youself by running through an example
alpha blending calculation by hand, on pen and paper, say.
Just letting you know, I'm not at all wedded to this PR. 🕊️ I got interested in the topic because font rendering on Ghostty looked somewhat "flimsy" to me, so I dug down into the rabbit hole of sRGB, gamma correction, etc. If you have other plans or someone is already working on this I can close the PR. If you're keen to help me shepherd this in, though, I'd be very happy to respond to any comments/suggestions!
TODO/Notes before merging:
conversions/decode. Which benchmarks should I be running?
might have the same issues. I could work on that one next.
Screenshots
You might have to zoom in/pixel peep on these.
This shows how fonts look even thinner now, as the above article also describes:
We can see there's no more dark color artifacts around the edged:
And here I demonstrate how we could thicken the fonts again by adding adjustable "gain" (name totally TBD) to the rendered font's alpha:
Here's a yet more thorough comparison. We have browsers up top (Firefox, Safari, Chrome), of which I'd say Firefox does not blend in linear space but Safari and Chrome do. And I'd say Safari looks best to my eyes. In the bottom row we have Ghostty main and Terminal, which blend in sRGB space (without gamma correction), and then Kitty and this branch on the bottom right which do blend in linear space (with gamma correction). Here it also really helps to click through to the screenshot and zoom in. But the changes are most obvious when going in there with Digital Colour Meter.
