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

91–97 of 97 posts

Re: Beware of Transparent Pixels

#91

Post by Dylan16807 »

foolrush wrote: post #89
Dylan16807 wrote: post #88

Earlier quoted context omitted.

I'm reading it. It doesn't quite seem to work. Objects that block a certain amount of light, and then emit a certain amount of light: You can only make that simplification if the entire world is evenly lit by white light. Blur the entire matchstick into one pixel. Under white light it has to emit brown plus yellow. In a dark room it has to emit just yellow. It's a clever technique but I can't figure out any way it's…

RGBA in associated is unique in that it represents distilled geometry. If you were to zoom in on a pixel that had a degree of geometry occluding it, the coverage is represented by the alpha ratio, while the RGB is purely emission. It is complimentary to lighting. The math works because of the differing forms of the alpha over formula. FG.RGB + ((1.0 - FG.Alpha) * BG.RGB), resulting in a pure add at the extreme case o…

They're plenty smart but they're talking about a different use case.

You don't know what color will be emitted unless you know what light is hitting the surface.

A dark glowing surface and a bright non-glowing surface have the same emissions under white light, but different emissions under other kinds of light. The method you're talking about requires the emissions be precalculated, which means you can't apply lighting at runtime.

Re: Beware of Transparent Pixels

#92

Post by mark-r »

Dylan16807 wrote: post #88
foolrush wrote: post #87

Earlier quoted context omitted.

Not sure what you think an RGB triplet is other than emission. Anyways, read the links I provided above.

I'm reading it. It doesn't quite seem to work. Objects that block a certain amount of light, and then emit a certain amount of light: You can only make that simplification if the entire world is evenly lit by white light. Blur the entire matchstick into one pixel. Under white light it has to emit brown plus yellow. In a dark room it has to emit just yellow. It's a clever technique but I can't figure out any way it's…

I agree with you, to do it properly you need two different RGBA objects, the emissive one will have A=0. But the same format suffices to represent both.

Re: Beware of Transparent Pixels

#93

Post by eukara »

Used to experience this all the time when making maps with custom textures for older games... Lots of people sure didn't though. Especially source ports that would apply filtering to games that didn't have any in the first place and you'd see blue or purple outlines because their original formats were obviously paletted

Re: Beware of Transparent Pixels

#94

Post by robohamburger »

munchbunny wrote: post #46
robohamburger wrote: post #35

Earlier quoted context omitted.

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…

In practice it's the other way around. Pre-multiplying alpha adversely affects image editing more than 3d rendering. 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 er…

Interesting! Thanks for clearing that up. I suppose if you have a strange shader that does some non-linear stuff it also might be more obvious to the programmer to use something higher precision or tweak how the math is done.

Re: Beware of Transparent Pixels

#95

Post by zeckalpha »

minikites wrote: post #45
zeckalpha wrote: post #43

Earlier quoted context omitted.

... which reminds me of similar notches from typography at small sizes. Interesting how physical bleeding ink and rendering issues result in similar workarounds.

For the curious: https://en.wikipedia.org/wiki/Ink_trap

Thanks! I couldn't remember the term.

Re: Beware of Transparent Pixels

#96

Post by the8472 »

dahart wrote: post #81
the8472 wrote: post #67

Earlier quoted context omitted.

> 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 th…

Yeah true, I suppose there is rounding error. Is this something that has actually happened to you, or are you saying it's a problem in theory? I'd be hard pressed to come up with a real-world use case for 10 of the same color being comped. For this to be a problem, the visible elements being comped would have to be exactly the same color, without any gradient or noise at all... Even if it did happen, the error is bou…

> Is this something that has actually happened to you

In a toy project where I tried to automatically generate SVG shapes and rendering them to a html canvas (which uses 8bit per channel premultiplied alpha). The assembled shapes occasionally overlapped and it did lead to visible color inconsistencies.

It's also a problem when working with PNGs. When you put your PNG pixels into a premultiplied space and pull them out again you actually lost information to rounding, which negates the benefits of a lossless format.

> You lost me on the edges part & aliasing. Rounding errors will not be visible as fringes, so if you're seeing fringes, you have some other problem... perhaps failure to pre-multiply! ;)

Well, if you got a solid shape then there's no alpha. But the aliasing at the edges introduces partially transparent pixels. If you then pull out the pixel data and apply it to a different canvas you get mismatched colors.

I only spent a few hours on it, so I don't recall all the details, but my conclusion was that it is inadequate for image manipulation since it is lossy and lacks precision.

Re: Beware of Transparent Pixels

#97

Post by twelvechairs »

munchbunny wrote: post #59
twelvechairs wrote: post #47

Earlier quoted context omitted.

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.…

Thanks for the answer - I did not know of this premultiplacation. This makes it effectively the same or very close? Assuming output transparency/alpha is (T1+T2/2), dividing by this gives the difference

I don't quite get your point on interpolation, but I'll look up when I have the chance

Post reply on HN