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

81–90 of 97 posts

Re: Beware of Transparent Pixels

#81

Post by dahart »

the8472 wrote: post #67
dahart wrote: post #39

Earlier quoted context omitted.

> 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 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 bounded - with 10 layers of the same color, the maximum error in any channel is 5, and the average error is 2.5. It's pretty hard to say it would be wildly and noticeably different to most people even with 8 bit color channels, but I certainly have met some film directors and CG supervisors who were very color sensitive. It would be literally invisible in anything higher than 8 bits.

I'm curious -- why do you say the rounded colors would tend toward gray? Rounding error can happen in both directions, so I would expect rounding errors to cause a uniformly distributed error -- some colors would get slightly more saturated, some less, some of them would shift hue, and some would be unaffected.

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! ;) Tell me more about stacking shapes and getting fringes. Is this stacking 10 of the same shape in the same place, or at the edge crossings of different shapes? What kind of fringes are you seeing?

Anyway, I've never witnessed a case in 20 years of film & game production where rounding errors caused a visible, detectable problem, but I'd love to know if there real cases where it's an issue!

Re: Beware of Transparent Pixels

#82

Post by Dylan16807 »

foolrush wrote: post #73
Dylan16807 wrote: post #66

Earlier quoted context omitted.

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

It ends up being a pure add emission. It can't be done with unassociated alpha due to the multiplication.

Sure, you can do a pure add.

But that means you need to dedicate specific objects to being purely emissive, to avoid blurring at the boundaries.

And once you've separated the objects, you don't really need to have purely-emissive textures and non-emissive textures in the same file, with the same exact format. You might as well store emissive textures as RGB and save on memory.

Using a different format can even benefit you. You're less likely to accidentally blend emissive and non-emissive pixels, and you're less likely to accidentally apply lighting calculations to emissions.

Re: Beware of Transparent Pixels

#83

Post by dahart »

foolrush wrote: post #62
ioquatix wrote: post #58

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…

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

The main reason why CG studios can't use PNG is because both renderers and compositors always output pre-mult images. Yes you can choose to un-pre-mult them after rendering, but the native result of a blending operation is always a pre-mult color, regardless of the input sources. Unpremultiplied blending still results in premultiplied colors.

Since everyone knows that un-premultiplying (dividing) is to be avoided at all costs, it means you can't render or comp something and then save the file in PNG.

> Associated (aka premultiplied) alpha is the _sole_ means to embody both occlusion and emission.

I would suggest avoiding thinking of image colors as emissive. That's a material property, and using RGBA to encode material properties is only something you'd do if you were stuck in a weird fixed-function pipeline with no choice, or if you were really really low on disk space. Otherwise, emission colors go in their own separate emission channel that doesn't have an alpha value.

Re: Beware of Transparent Pixels

#84

Post by foolrush »

dahart wrote: post #83
foolrush wrote: post #62

Earlier quoted context omitted.

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…

> That little ditty is also very likely why PNG has zero uptake in visual effects and CGI. The main reason why CG studios can't use PNG is because both renderers and compositors always output pre-mult images. Yes you can choose to un-pre-mult them after rendering, but the native result of a blending operation is always a pre-mult color, regardless of the input sources. Unpremultiplied blending still results in premul…

It is emissive.

Feel free to reference the original Porter Duff paper regarding "luminescent pixels" or Alvy Smith's opinion on the matter as relayed by Zap Andersson in the legendary Adobe thread.

https://forums.adobe.com/thread/369637

Here is a sample of the candle referenced by Zap:

https://i.imgur.com/bnXyAl1_d.jpg?maxwidth=640&shape=thumb&f...

Remember that a ray tracing engine uses associated alpha as that is the sole format it can generate. Only associated alpha models emission and occlusion.

Further reading:

http://lists.openimageio.org/pipermail/oiio-dev-openimageio....

https://groups.google.com/forum/m/#!topic/ocio-dev/ZehKhUFqh...

Re: Beware of Transparent Pixels

#85

Post by foolrush »

Dylan16807 wrote: post #82
foolrush wrote: post #73

Earlier quoted context omitted.

It ends up being a pure add emission. It can't be done with unassociated alpha due to the multiplication.

Sure, you can do a pure add. But that means you need to dedicate specific objects to being purely emissive, to avoid blurring at the boundaries. And once you've separated the objects, you don't really need to have purely-emissive textures and non-emissive textures in the same file, with the same exact format. You might as well store emissive textures as RGB and save on memory. Using a different format can even benefi…

Except associated alpha models emission and occlusion via the operation. You don't need zero alpha either, as any ratio can occlude partially and emit partially as well.

No hacking needed.

Re: Beware of Transparent Pixels

#86

Post by Dylan16807 »

foolrush wrote: post #85
Dylan16807 wrote: post #82

Earlier quoted context omitted.

Sure, you can do a pure add. But that means you need to dedicate specific objects to being purely emissive, to avoid blurring at the boundaries. And once you've separated the objects, you don't really need to have purely-emissive textures and non-emissive textures in the same file, with the same exact format. You might as well store emissive textures as RGB and save on memory. Using a different format can even benefi…

Except associated alpha models emission and occlusion via the operation. You don't need zero alpha either, as any ratio can occlude partially and emit partially as well. No hacking needed.

You can't do both in a single pixel, unless you turn off lighting entirely and make everything fullbright.

Let's have blue-tinted pane of glass, (0, 0, .5, .5). And a red tinted pane, (.5, 0, 0, .5).

Then a blue glow, (0, 0, .5, 0). And a red glow, (.5, 0, 0, 0).

If you have your blue glass glow red, and your red glass glow blue, both combinations come out as (.5, 0, .5, .5).

Under 99% of lighting conditions, it will look wrong. If you put it in darkness, it will look overwhelmingly wrong.

Even if occlusion and emission are the same color it doesn't work. A dark blue object that glows brightly, and a bright blue object that glows dimly, both will have the same RGBA.

Re: Beware of Transparent Pixels

#87

Post by foolrush »

foolrush wrote: post #85
Dylan16807 wrote: post #82

Earlier quoted context omitted.

Sure, you can do a pure add. But that means you need to dedicate specific objects to being purely emissive, to avoid blurring at the boundaries. And once you've separated the objects, you don't really need to have purely-emissive textures and non-emissive textures in the same file, with the same exact format. You might as well store emissive textures as RGB and save on memory. Using a different format can even benefi…

Except associated alpha models emission and occlusion via the operation. You don't need zero alpha either, as any ratio can occlude partially and emit partially as well. No hacking needed.

Not sure what you think an RGB triplet is other than emission.

Anyways, read the links I provided above.

Re: Beware of Transparent Pixels

#88

Post by Dylan16807 »

foolrush wrote: post #87
foolrush wrote: post #85

Earlier quoted context omitted.

Except associated alpha models emission and occlusion via the operation. You don't need zero alpha either, as any ratio can occlude partially and emit partially as well. No hacking needed.

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 not fundamentally incompatible with having lighting. If one pixel has to both be lit and emit extra light, you need two RGB values.

Re: Beware of Transparent Pixels

#89

Post by foolrush »

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…

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 of alpha being zero, or ratios of addition when non-zero.

Within the limitations of the RGB model, it works extremely well.

The folks cited are extremely adept imaging people, covering years of experience and several Academy Achievement Awards.

Re: Beware of Transparent Pixels

#90

Post by dahart »

foolrush wrote: post #84
dahart wrote: post #83

Earlier quoted context omitted.

> That little ditty is also very likely why PNG has zero uptake in visual effects and CGI. The main reason why CG studios can't use PNG is because both renderers and compositors always output pre-mult images. Yes you can choose to un-pre-mult them after rendering, but the native result of a blending operation is always a pre-mult color, regardless of the input sources. Unpremultiplied blending still results in premul…

It is emissive. Feel free to reference the original Porter Duff paper regarding "luminescent pixels" or Alvy Smith's opinion on the matter as relayed by Zap Andersson in the legendary Adobe thread. https://forums.adobe.com/thread/369637 Here is a sample of the candle referenced by Zap: https://i.imgur.com/bnXyAl1_d.jpg?maxwidth=640&shape=thumb&f... Remember that a ray tracing engine uses associated alpha as that is t…

> It is emissive.

Yes you're right; I wasn't arguing with you about that. I always feel like calling it additive rather than emissive. But just because you can represent additive colors in premult images doesn't mean you should, and I'd speculate wildly that it occurs less often in production than halo problems. Someone who writes lens flare and rainbow shaders is going to scold me for saying that though...

In the context of the OP's article, and of artists who paint images with transparency in them, worrying about emissive colors isn't really an issue. Artists very rarely paint pre-mult images, they can't work with premult images, generally speaking. No doubt a few people who know what they're doing do it, but I can't personally say I've ever seen an artist painted premult image with emissive colors, nor do I recall ever seeing a software rendered layer with emissive colors either. Is this common now? I've been out of film & games for a few years now.

I'm already familiar with everything you referenced; and I can vouch that it's all very good stuff so thanks for sharing, especially the Adobe thread. I hope others here benefit. It's amusing that an entire industry knows who Chris Cox is because of this thread, right? :P

Post reply on HN