Fix semi-transparent colors appearing too bright

[emilk]

The bug was in Color32::from_rgba_unmultiplied and by extension affects:

• Color32::from_rgba_unmultiplied
• hex_color!
• HexColor
• ColorImage::from_rgba_unmultiplied
• All images with transparency (png, webp, …)
• Color32::from_white_alpha

The bug caused translucent colors to appear too bright.

More

Color is hard.

When I started out egui I thought "linear space is objectively better, for everything!" and then I've been slowly walking that back for various reasons:

• sRGB textures not available everywhere
• gamma-space is more perceptually even, so it makes sense to use for anti-aliasing
• other applications do everything in gamma space, so that's what people expect (this PR)

Similarly, pre-multiplied alpha makes sense for blending colors. It also enables additive colors, which is nice. But it does complicate things. Especially when mixed with sRGB/gamma (As @karhu points out).

Related

• Closes Semi-transparent pixels of image appear too bright? #5751
• Closes Rgba::From<Color32> does not consider alpha #5771 ? (probably; hard to tell without a repro)
• But not Ringing around pre-rasterized circles. #5810

TODO

• I broke the RGBA u8 color picker. Fix it

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/5824-emilkfix-transparency-blending
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[Wumpf]

this blending in gamma space business drives me nuts, but apparently this produces the results everyone expects so great catch! 👍

[karhu]

As mentioned in one of the line comment threads I think we need to properly specify and document what Color32 stores in respect to a linear, unmultiplied rgba value:

a) to_gamma(to_premultiplied(some_linear_rgba_unmultiplied_value))
or
b) to_premultiplied(to_gamma(some_linear_rgba_unmultiplied_value))

Or expressed differently: Do we gamma encode in linear space or in premultiplied space?

If I understand your changes to from_rgba_unmultiplied correctly, this flips the order of the two operations, so we now do b) instead of previously a).

For what it is worth, I think b) is the right way to go about this, as a) behaves weirdly when blending between non-opaque colors. However: From going through the egui codebase, my impression is that code pretty consistently assumes that we are doing a).

This includes conversions between Color32 and Rgba. For example this quick test fails now:

    let rgba_unmult: [u8; 4] = [200, 150, 100, 150];

    let as_color32 = egui::Color32::from_rgba_unmultiplied(
        rgba_unmult[0],
        rgba_unmult[1],
        rgba_unmult[2],
        rgba_unmult[3],
    );

    let as_rgba = egui::Rgba::from(as_color32);

    let rgba_unmult_after = as_rgba.to_srgba_unmultiplied();
    assert!(
        rgba_unmult == rgba_unmult_after,
        "Values differ: {rgba_unmult:?} != {rgba_unmult_after:?}"
    );

with Values differ: [200, 150, 100, 150] != [151, 113, 77, 150] (to be fair, it also fails on master but only due to rounding errors).

Sidenote: Should from_rgba_unmultiplied be renamed from_srgba_unmultiplied to be in line with to_srgba_unmultiplied ?

Another place is the shader code, which currently directly transforms between gamma and linear encoding, but would have to be changed to transform between premult / unmult before doing any gamma transforms. Also in the shader code, the texture read (which currently happens from an sRGBA aware texture) might be affected. From a first glance the automatic conversion on the driver level works with a), but not b).

Phew, sorry for the wall of text. My brain is smoking, and I concur with @Wumpf that this is driving me nuts, so please take all of it with a big pile of salt.

[emilk]

@karhu you are right to point that out… I'll try to make things a bit more consistent.

EDIT: now the Color32 <-> Rgba conversions does the alpha unmultiply… it's not pretty, but it works.

[Wumpf]

nice, feels a looot more rigorous now!