Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of Transparent Pixels

adriancourreges.com

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Beware of Transparent Pixels

#51

Post by mark-r »

jayshua wrote: post #49

While reading this article, it struck me that the amount of "useless" data increases as the alpha value approaches 0. For example: in a pixel with rgba values of (1.0, 0.4, 0.5, 0.0), the rgb values are redundant. Is there a color format that would prevent this redundancy? Perhaps by some clever equation that incorporates the alpha values into the rgb values? I don't think Premultiplied alpha would work, because you…

PNG uses compression to reduce the redundancy. The average number of bits per pixel is much less than 32. A=0 is a special case, and many PNG encoders will take advantage of that by setting RGB to some constant so it compresses better.

Re: Beware of Transparent Pixels

#52

Post by imron »

modeless wrote: post #21

I don't like this article because it blames the wrong people and buries the real solution, premultiplied alpha, at the bottom. Already there are many comments here that are confused because they didn't even see the premultiplied alpha part of the article. The issue with the Limbo logo was not that the source image was incorrect. The image was fine. The blending was incorrect because the PS3 XMB has a bug. Not using p…

Exactly. As I was reading the article I was thinking to myself 'this guy needs to learn about pre-multiplied alpha', and then he gets to the end and says, btw use pre-multiplied alpha to avoid this problem entirely.

Re: Beware of Transparent Pixels

#53

Post by theoh »

mark-r wrote: post #50
dahart wrote: post #42

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'm not sure I understand your concern. If the software converts all your assets into a premultiplied form, the bleeding you applied won't hurt anything even if it doesn't help. Yes, it's extra work that shouldn't be necessary - but we often find ourselves living in an imperfect world. I completely agree that premultiplied alpha should be used everywhere. I'd even go a step farther and say that you should use high bi…

Alvy Ray Smith may have the canonical paper on this, from 1995: http://alvyray.com/Memos/CG/Microsoft/4_comp.pdf

Re: Beware of Transparent Pixels

#54

Post by evincarofautumn »

Kiro wrote: post #2

> pay attention to what color you put inside the transparent pixels I don't understand this. When I make transparency I don't use any color? I use the Eraser tool or Ctrl-X, not a color with 0 opacity.

An eraser tool and a paintbrush tool do essentially the same thing—overwrite an area of the image with new pixel values, typically blended in some way with the old values. It’s just that the eraser is for painting in the alpha channel, while the paintbrush also affects colour channels.

An alpha mask (on a layer with no alpha channel) is essentially a different way of viewing & editing the same data, and there you probably have no logical trouble with using a paintbrush tool.

Re: Beware of Transparent Pixels

#55

Post by kllrnohj »

modeless wrote: post #21

I don't like this article because it blames the wrong people and buries the real solution, premultiplied alpha, at the bottom. Already there are many comments here that are confused because they didn't even see the premultiplied alpha part of the article. The issue with the Limbo logo was not that the source image was incorrect. The image was fine. The blending was incorrect because the PS3 XMB has a bug. Not using p…

I don't think that's a fair summary of the layout of the article. Once the article reaches the "How to Prevent This Issue" section there's far more space given to using premultiplied alpha than manually bled images, and it's not blaming anyone. It just tells an artist how they could fix it and tells programmers how they could fix it. Nobody is blamed and the "correct" solution isn't buried at all.

Re: Beware of Transparent Pixels

#56

Post by kllrnohj »

VikingCoder wrote: post #23

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 need to scale that up for some reason or are working with 10-bit displays then just use RGBA16F textures. No reason to stick to 32-bit here. GPUs are perfectly happy to work with half-float textures.

Although if you want to keep 32-bit textures you also shouldn't be doing linear premultiplication like the article suggests, you should be using sRGB instead.

Re: Beware of Transparent Pixels

#58

Post by ioquatix »

mark-r wrote: post #50
dahart wrote: post #42

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'm not sure I understand your concern. If the software converts all your assets into a premultiplied form, the bleeding you applied won't hurt anything even if it doesn't help. Yes, it's extra work that shouldn't be necessary - but we often find ourselves living in an imperfect world. I completely agree that premultiplied alpha should be used everywhere. I'd even go a step farther and say that you should use high bi…

A 16bpp linear pre-multiplied format would be awesome. sRGB is a pain to use in practice:

- Slow to convert to linear colour space (requires a pow).. except - GPUs use an 8-bit lookup table to convert input sRGB to output linear value. - This doesn't work for more than 8 bits as the table gets excessively large very quickly.

It's a pity PNG doesn't have flag to mark the image data as being pre-multiplied.

Re: Beware of Transparent Pixels

#59

Post by munchbunny »

twelvechairs wrote: post #47
munchbunny wrote: post #15

Earlier quoted context omitted.

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.

Which means that your output pixel cant be both white and low transparency. I guess its a typical graphics 'close enough and better performance' outcome (where mine is marginally more difficult to calculate and needs some more logic to avoid divide by 0)

> Which means that your output pixel cant be both white and low transparency.

Did you mean low opacity?

If so, that's not quite right. (0.1,0.1,0.1,0.1) premultiplied is the same color as (1,1,1,0.1) "normal." They're both white and low opacity, just in different representations. You don't actually lose much granularity because the graphics card has to multiply the color channels by the opacity value sooner or later.

Separately, your formula doesn't work for interpolation. It works for averaging, but in order to do texture sampling, you need interpolation, so your formula can't actually be used unless you can adjust it to deal with interpolation gracefully.

Re: Beware of Transparent Pixels

#60

Post by dahart »

mark-r wrote: post #50
dahart wrote: post #42

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'm not sure I understand your concern. If the software converts all your assets into a premultiplied form, the bleeding you applied won't hurt anything even if it doesn't help. Yes, it's extra work that shouldn't be necessary - but we often find ourselves living in an imperfect world. I completely agree that premultiplied alpha should be used everywhere. I'd even go a step farther and say that you should use high bi…

Just pointing out that attempting to solve the real problem should be tried first, before jumping to work-arounds.

If the software converts to pre-multiplied, then there'd be no halo problem and no bleeding necessary, right?

You're right that bleeding won't hurt assets if you're comping, but it will hurt assets if you're not converting to premult and then do texture filtering or mipmapping or blurring.

My concern is with using bleeding is the article's suggestion to use bleeding as a first resort, rather than a last resort (as an artist). It's a hack that totally works in a lot of cases, but it's still a hack. I've watched artists in film and games use random combinations of bleeding, (un)pre-multiply, gamma, and other stuff whenever something goes wrong with matting, and often it's not the right solution. A lot of people are scared of understanding premultiplied alpha - and the technical name isn't doing anyone any favors - and instead of figuring out the right solution they try every combination of hacks until it works. General misunderstanding and superstition about premultiplied alpha is the most common reason I've seen for people using un-premultiply nodes in production.

Post reply on HN