Live data from Hacker News

Beware of Transparent Pixels

adriancourreges.com

61–70 of 97 posts

Re: Beware of Transparent Pixels

#61
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…

Would you count compression schemes as valid answers to your question, or are you asking about the raw data not having any redundancy?

There're no channel formats or clever equations I'm aware of that avoids the redundancy part. But your question totally reminds me of Greg Ward's RGBE format, which is a high-dynamic range format stored in 8 bits per channel, with an extra 8 bit exponent channel. http://www.graphics.cornell.edu/~bjw/rgbe.html

RGBE isn't doing exactly what you're asking about, but it's similar in a way. Instead of storing 16 bits per channel separately for each channel, what you really get instead is 16 bits (sort-of) for the brightest channel, and the other 2 channels in 8 bits each - discarding the extra bits. You can't see them because the bright channel will prevent you from seeing anything super dark in another channel, so you can discard the extra color resolution in the darker channels.

If you count compression, then pre-multiplying would help the situation. Anytime the alpha value gets low or goes to 0, the color channels do too, so run length encoding or DCT or whatever else will collapse large transparent areas into all zeroes.

Re: Beware of Transparent Pixels

#62
post #50

Earlier quoted context omitted.

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.

That little ditty is also very likely why PNG has zero uptake in visual effects and CGI.

Associated (aka premultiplied) alpha is the _sole_ means to embody both occlusion and emission. Unassociated (aka straight or key) alpha cannot represent these facets.

Consider a candle flame that exists as mostly emission and low to no occlusion. With associated alpha, you can use zero alpha triplets with non-zero emission RGB to represent this real-world scenario. With unassociated alpha? Impossible.

Re: Beware of Transparent Pixels

#63
post #22

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…

This is not quite accurate.

In an associated alpha image (aka premultiplied), zero alpha with non-zero RGB represents emission with no occlusion.

Re: Beware of Transparent Pixels

#64

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.

Entirely false in that it is indeed a completely valid combination. See luminescent pixels in the Porter Duff paper. It represents a pixel that has no occlusion and is emitting.

Re: Beware of Transparent Pixels

#65
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…

In premultiplied alpha, you can think of all the legal (non-emissive) colors as a triangle. At an alpha of 1, all colors are legal, tapering off as alpha decreases until you reach an alpha of 0, where no colors are legal. To turn the triangle into a square, you could scale it up by two, cut off the top, and rotate the top over into the empty space (like this: https://i.imgur.com/6hjNe7X.png). That would give you twice the colors you had before.

Re: Beware of Transparent Pixels

#66

Earlier quoted context omitted.

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.

That little ditty is also very likely why PNG has zero uptake in visual effects and CGI. Associated (aka premultiplied) alpha is the _sole_ means to embody both occlusion and emission. Unassociated (aka straight or key) alpha cannot represent these facets. Consider a candle flame that exists as mostly emission and low to no occlusion. With associated alpha, you can use zero alpha triplets with non-zero emission RGB t…

> Consider a candle flame that exists as mostly emission and low to no occlusion.

I don't think associated alpha helps much here. You can special case pixels that are doing pure emission, but when a pixel is doing both you need the lighting to affect the color of the occlusion but not affect the color of the emission.

Re: Beware of Transparent Pixels

#67
post #39

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…

> Premultiplied alpha results in less color depth, though. That doesn't matter unless you color-scale the image (like multiply by 2 to make it brighter) before displaying it. Otherwise, the depth is at the correct resolution for display. And premultiplied alpha should be used for final display, not just for the halo-ing reasons demonstrated here, but for lots of reasons. Artists should generally be working in un-prem…

> that doesn't matter unless you color-scale the image (like multiply by 2 to make it brighter) before displaying it.

It does if you stack several image layers. Let's say I have a particular color tone. Then I use that as background color. And I also stack 10 layers of the same color with alpha 0.05 on top of that. If you use premultiplied colors then this will actually result in a different color.

Due to rounding those colors often tend to be more greyish too. So if draw some vector graphics and have multiple basic shapes with semi-transparent edges (aliasing!) stacked on top of each other you can get some ugly fringes.

Re: Beware of Transparent Pixels

#69
Note that SVG 1.1 doesn't have an option for color interpolation to work in premultiplied/associated alpha. SVG 2 is not finalized though, I added an issue some time ago.

https://github.com/w3c/svgwg/issues/303

It affects gradients, animations and imported+scaled raster images. Maybe other stuff too, I don't know.

Post reply on HN