> Even with an alpha of 0, a pixel still has some RGB color value associated with it.
Wish the article was more clear as to why this happens. Let me elucidate: this happens because, per the PNG standard[0], 0-alpha pixels have their color technically undefined. This means that image editors can use these values (e.g. XX XX XX 00) for whatever -- generally some way of optimizing, or, more often than not, just garbage. There are ways to get around this by using an actual alpha channel in Photoshop[1], or by using certain flags in imagemagick[2].
While what you wrote is correct, it's not actually the problem being described in the posted link. The problem in the posted link is just as relevant if the alpha value was "01" for "you pretty much can't see it but it's meaningfully there", and has to do with image filtering artifacts as opposed to purely data representation.
But it's specifically a problem with PNG because the spec explicitly allows encoders to substitute their own RGB values for any transparent pixel. Most other formats are expected to store the values you give them without modification.
No, the problem discussed in the article can occur with any image format (that supports alpha) and occurs later in the pipeline so it really doesn't matter how the texture was stored on disc. Or even whether it was stored - this could happen with procedurally generated textures.
The article discussed one possible workaround, which was to specify RGB values for the fully transparent pixels in the artwork. If the PNG tool you're using substitutes its own RGB values in those transparent pixels, as allowed by the spec, the workaround doesn't work. That's why PNG in particular is a problem.
If you follow the recommendation at the end to use premultiplied alpha for all computations, this becomes a moot point.
I remember this giving me headaches years ago when I tried to save color data in a PNG with 0-alpha values that contain color. I needed the color and the alpha and thought it would make sense to save both in one image, basically, but nope. This was with GIMP and I remember looking it up and the GIMP devs insisting it was correct behavior by the PNG standard even when it made oh-so-much sense to at least give an option to bypass this shit for niche cases.
fought with this recently while creating pdf having image overlays, ended up having to draw the underlining image on top image's pixel having full alpha to avoid aliasing on the edges
Wish the article was more clear as to why this happens. Let me elucidate: this happens because, per the PNG standard[0], 0-alpha pixels have their color technically undefined. This means that image editors can use these values (e.g. XX XX XX 00) for whatever -- generally some way of optimizing, or, more often than not, just garbage. There are ways to get around this by using an actual alpha channel in Photoshop[1], or by using certain flags in imagemagick[2].
[0] https://www.w3.org/TR/PNG/
[1] https://feedback.photoshop.com/photoshop_family/topics/png-t...
[2] http://www.imagemagick.org/discourse-server/viewtopic.php?t=...