41–50 of 97 posts
Using premultiplied alpha avoids this. Jim Blinn's books from the 90s give a very thoughtful treatment of the topic.
The Porter and Duff compositing paper is good, too. One clarification, though: With premultiplied colors, something like (1,1,1,0) is either illegal or a light source. It's not a valid normal color.
> As an Artist: Make it Bleed!
> If you’re in charge of producing the asset, be defensive and don’t trust the programmers or the engine down the line.
If you are an artist working with programmers that can fix the engine, your absolute first choice should be to ask them to fix the blending so they convert your non-premultiplied images into premultiplied images before rendering them!
Do not start bleeding your mattes manually if you have any say in the matter at all, that doesn't solve the whole problem, and it sets you up for future pain. The only right answer is for the programmers to use premultiplied images. What if someone decides to blur your bled transparent image? It will break. (And there are multiple valid reasons this might happen without your input.)
Even if you have no control over the engine, file a bug report. But in that case, go ahead and bleed your transparent images manually & do whatever you have to, to get your work done.
Eric Haines wrote a more technical piece on this problem that elaborates on the other issues besides halo-ing:
http://www.realtimerendering.com/blog/gpus-prefer-premultipl...
Reminds me of "Is there a reason Hillary Clinton's logo has hidden notches?" https://graphicdesign.stackexchange.com/questions/73601/is-t...
Earlier quoted context omitted.
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.
If you follow the recommendation at the end to use premultiplied alpha for all computations, this becomes a moot point.
Reminds me of "Is there a reason Hillary Clinton's logo has hidden notches?" https://graphicdesign.stackexchange.com/questions/73601/is-t...
... which reminds me of similar notches from typography at small sizes. Interesting how physical bleeding ink and rendering issues result in similar workarounds.
Premultiplied alpha results in less color depth, though. If my alpha is 10%, then my possible RGB values become 0-25. Even if I multiply by 10, I still lose the maximum possible values 251-255, and only values 0, 10, 20, 30... 250, are possible. The correct solution is to pay close attention to all of the factors... and to be ESPECIALLY aware of pixel scaling. Provide your RGBA textures at the 1:1 pixel scale they wi…
If you were just doing image compositing would this be an issue? I can easily imagine how that would adversely effect a 3d game where the images are used as texture maps and the values of the diffuse texture map may change from other lighting contributions and shaders. It seems like in that case doing some kind of HDR/higher precision texturing would be good right? Disclaimer: not a graphics programmer just a hobbyis…
For image editing, the problem is that you might send the same pixel through many different operations, and if you flatten something and further manipulate, then the rounding error will continue to accumulate. So losing granularity early in the process due to alpha can result in accumulated rounding error.
In 3d graphics, the texture typically goes through a very predictable and short number of transformations, and they will rarely need to "stretch" the color range of the transparent pixel. When you alpha blend with pre-multiplied alpha, you're literally just adding the whole color value. And then you're slapping a whole lot of other colors onto it in the lighting/shadow/other passes, so the subtle nuances of that mostly transparent window get lost in the bustle.
Earlier quoted context omitted.
Surely the answer if you want this is to weight the final RGB by the transparency. E.g. the final red channel would be (R1xT1 + R2xT2)/(T1+T2)
You're mostly right. The industry-wide accepted answer is to multiply the opacity into the colors before interpolating, so the formula would be (R1xT1 + R2xT2)/2 for the average, and then to do later transparency blending as if the opacity term was already multiplied in.
This is extremely useful to take advantage of (that you can store RGB values in 0-alpha pixels). I've written some pretty simple but powerful shaders for a game I'm working on by utilizing transparent pixels' "extra storage" which allowed for either neat visuals or greatly reduced the number of images required to achieve a certain affect. For instance, I wrote a shader for a characters hair that had source images col…
Really nice article! Succinctly demonstrates the problem with not using premultiplied alpha. > As an Artist: Make it Bleed! > If you’re in charge of producing the asset, be defensive and don’t trust the programmers or the engine down the line. If you are an artist working with programmers that can fix the engine, your absolute first choice should be to ask them to fix the blending so they convert your non-premultipli…
I completely agree that premultiplied alpha should be used everywhere. I'd even go a step farther and say that you should use high bit depth linear values too, but that's a topic for another day.