You need to go gamma -> linear before doing any linear algebra on your color values.

There is some debate over whether the alpha should be stored linearly or not in low precision (8 bit) formats. I think the standard practice is linear, but there’s good arguments it should be gamma encoded.

And, from there it’s important to point out that while pre-mul alpha is great for the math, having a color recorded in an 8-bit per channel image pre-multiplied doesn’t leave many possible values in the low range. So, you can get a lot of banding. Dithering becomes important. You should probably store the image non-premultiplied and do the premul as part of the math at runtime. Unfortunately, almost all image editors and encoders make it impossible to control the rgb values of low or zero alpha pixels. They all assume those colors conceptually “don’t exist” and don’t matter. But, they matter here because the filtered transition between solid and transparent pixels is the whole issue we are struggling with here.

Do you have any recommended resources for self-learning a ground-up education in these concepts? Book, etc? I've struggled to find any good ones.

Not a book, but I had a similar question yesterday and ended up finding this article https://tomforsyth1000.github.io/blog.wiki.html#%5B%5BThe%20.... Goes into more detail than I thought I needed!

Gamma should not have any effect on the alpha channel, which is linear by definition. The alpha channel represents the average coverage of (infinite) subpixels within the pixel. The color encoding of an object should not have any impact on the coverage within that pixel.

I recommend reading the technical memo "Alpha and the History of Digital Compositing" by Alvy Ray Smith [1] to get a better intuition on the matter.

[1] http://alvyray.com/Memos/CG/Microsoft/7_alpha.pdf

Gamma does however have an effect on blurring. And I suspect that because of gamma correction, applying a blur filter to a premultiplied image is (very subtly) incorrect.

Yes, I think the possibilities, in practice, for bad interactions between gamma-related and alpha-related operations are real.

"PS3 does sRGB conversion before alpha-blending, so the blending is done in gamma space, which is not quite right."

https://tomforsyth1000.github.io/blog.wiki.html

Applying a blur filter to a premultiplied image is (very subtly) _correct_, at least if the goal is to emulate what happens if you used a physical lens to blur the same image. Not only does postmultiplied alpha mess up the correct pixel values (as the original post shows), but even without alpha, you get a “halo” that is weird and unphysical.

I think corysama had the right of it, you need to do all the operations in linear colors, i.e.

original image -> convert to linear color space -> multiply alpha -> blur -> composite -> possibly convert back to sRGB if needed

The wrong way I meant was

original image -> multiply alpha -> gamma-correct-blur -> composite

where gamma-correct-blur = convert to linear color space -> blur filter -> convert to sRGB

If you create a sRGB texture on a modern GPU, the R/G/B channels are stored in sRGB (functionally a lot like gamma correction in this case) while the alpha channel is always linear 0-255. So while the GPU's texture samplers will convert the R/G/B channels to linear before filtering or sending the result to a shader, nothing gets done to the alpha channel.