Revisit Linear vs sRGB blending

[hoshinolina]

PRs such as #2071 #7311 have progressively switched egui from doing color math in linear space to sRGB/"gamma" space. I believe this is fundamentally wrong and those PRs were essentially solving the problem they set out to solve in the wrong way.

Blending in gamma space produces perceptually incorrect (and often ugly) colors, see for example this famous video. Sampling in gamma space additionally produces moire/aliasing effects.

An easy place to see the regression that I found is the very test image in #2011: if you look at the curves at the bottom, the "before" image has smooth lines of constant width, while the "after" image has blotchy inconsistent antialiasing.

A classic test for image sampling behavior would be to use a checkerboard image, which when viewed from a distance should be the same color as 0.5 grey in linear or 0.735 grey in sRGB. That image will become a solid 0.5 color when downsampled to 50% scale, which is only correct in linear space.

sRGB blending is simply... not great, and never really "correct" for anything. As far as I'm concerned the only reason to do it is for compatibility with sRGB authoring pipelines (i.e. people using Photoshop, which by default does gamma-incorrect blending, and who expect semi-transparent areas to render the same in egui). Even GIMP does gamma-correct (linear) blending by default these days, as do most game engines etc.

I suspect a lot of the confusion and problems have come with subtle mistakes in alpha premultiplication. Premultiplied alpha must be done in the same space as blending. If you premultiply in sRGB and blend in linear, you get broken results, and vice versa. I suspect this is the root cause of a lot if not all of the issues attributed to linear blending. For example, dark halos around white-on-white antialiased items are what happens when you premultiply in the sRGB world, then sRGB decode and blend in linear: Your 50% transparent white pixels become (0.5, 0.5, 0.5, 0.5) when premultiplied in sRGB, and that decodes to (0.214, 0.214, 0.214, 0.5) in linear which most decidedly isn't transparent white any more. This also causes significantly different "weight" for white-on-black and black-on-white content, for similar reasons.

Other than that, if there are issues with text rendering, they should be addressed by adjusting the text rendering pipeline. "Pleasant" text rendering is notoriously tricky indeed (and much has been written about it), but the solution isn't to change how the entire framework does blending!

[hoshinolina]

Looks like this was already identified in #1765. It's unfortunate that, despite the real problem being identified, it wasn't fixed and instead blending was changed to sRGB in #2011...

The problem remains in the shader code: this function is quite simply incorrect when used with premultiplied alpha (which my understanding is it is). To convert premultiplied linear RGBA to premultiplied sRGB RGBA, you need to unpremultiply, then convert the color portion to sRGB, then re-premultiply. I bet fixing this would have fixed the issue #7311 was trying to fix, without further degrading texture sampling quality.

[hoshinolina]

To demonstrate, I'm working on a library I'm trying to embed into egui. The library works with premultiplied textures with sRGB sampling (premultiplied and sampled in linear space) and renders correctly in raw wgpu/winit, with an sRGB-aware framebuffer (using linear color in all shader code). The library is rendering a character "part by part" (this is not a single texture, it is many dozens of individual textured meshes blended together directly in egui's RenderPass).

This is how it looks originally, with wgpu/winit using an sRGB-aware framebuffer (linear blending):

When embedded into egui naively, the colors are too dark, as linear colors are being interpreted as sRGB:

By adding egui's gamma_from_linear_rgba() function to my shader after texture sampling, the result is still incorrect (notice the cheeks):

Fixing the function yields nearly "correct" rendering (as correct as sRGB blending gets):

// 0-1 sRGBA gamma  from  0-1 linear
fn gamma_from_linear_rgba(linear_rgba: vec4<f32>) -> vec4<f32> {
    var a = saturate(linear_rgba.a);
    if linear_rgba.a <= 0 {
        return vec4<f32>(0.);
    }
    return vec4<f32>(
        linear_rgba.a * gamma_from_linear_rgb(linear_rgba.rgb / linear_rgba.a),
        linear_rgba.a
    );
}

If you flip between this image and the first one, you'll notice that the result still isn't quite correct: the cheek color is still ever so slightly off, and the line art is rendered differently (e.g. the black outline of the face is noticeably thicker, and many of the other lines have stronger aliasing and are slightly thicker too). These are the result of doing blending in sRGB/gamma-compressed space. In this case it's not very noticeable, but with content that has large semi-transparent areas or alpha gradients it can make a striking difference.