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

31–40 of 97 posts

Re: Beware of Transparent Pixels

#31

Post by mark-r »

tgb wrote: post #16
munchbunny wrote: post #13

Earlier quoted context omitted.

While what you wrote is correct, it's not actually the problem being described in the posted link. The problem in the posted link is just as relevant if the alpha value was "01" for "you pretty much can't see it but it's meaningfully there", and has to do with image filtering artifacts as opposed to purely data representation.

Also the problem can occur with any image format; what matters is how it's stored in the texture not on disc.

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.

Re: Beware of Transparent Pixels

#32

Post by microcolonel »

tantalor wrote: post #8

Reminds me of "Is there a reason Hillary Clinton's logo has hidden notches?" https://graphicdesign.stackexchange.com/questions/73601/is-t...

I had to do a similar thing with the Gitlab logo[0] (and it's still messed up on their marketing sites). There are limitations to the SVG renderers in browsers (and elsewhere), it is kinda sad that we don't have AGG-quality rendering as a standard feature of browsers these days. :- (

[0]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2741

Re: Beware of Transparent Pixels

#33

Post by wink »

mark-r wrote: post #29
fnayr wrote: 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…

Paint Shop Pro had some picture frames that were fully transparent in the middle. As an Easter egg, a couple of those frames had pictures of the staff in those transparent areas and you could use the unerase tool to see them.

Aww, just checked my Paint Shop Pro 4.12 (Build Date: Dec 21 1996) and it doesn't yet have these picture frames :/

Re: Beware of Transparent Pixels

#34

Post by mark-r »

Kenji wrote: post #27

You also have a similar problem when you render opaque, rectangular images without the clamp edge mode, and the renderer is in tiling mode, so the borders wrap around when your picture is halfway between pixels and become a mix between the top/bottom or left/right colour, corrupting the edges. Easy to fix, but annoying until you get what it is that corrupts your edges. Also: "The original color can still be retrieved…

It would be more accurate to say that the original color can be approximated. The approximation quality goes down as the transparency goes up, until at zero it gets lost entirely.

Re: Beware of Transparent Pixels

#35

Post by robohamburger »

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 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 hobbyist seeking clarification. :)

Re: Beware of Transparent Pixels

#36

Post by mark-r »

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…

The article suggests why 1:1 won't be adequate, there will still be interpolation when the position isn't on a pixel boundary.

In practical applications the reduced color gamut isn't a problem, your ability to discriminate the colors goes down as the transparency goes up. It would only be a problem if you were trying to convert the pixels to something less transparent than they started.

Re: Beware of Transparent Pixels

#37

Post by mark-r »

wink wrote: post #33
mark-r wrote: post #29

Earlier quoted context omitted.

Paint Shop Pro had some picture frames that were fully transparent in the middle. As an Easter egg, a couple of those frames had pictures of the staff in those transparent areas and you could use the unerase tool to see them.

Aww, just checked my Paint Shop Pro 4.12 (Build Date: Dec 21 1996) and it doesn't yet have these picture frames :/

That's because 4.12 didn't have partial transparency.

Re: Beware of Transparent Pixels

#38

Post by Kenji »

mark-r wrote: post #34
Kenji wrote: post #27

You also have a similar problem when you render opaque, rectangular images without the clamp edge mode, and the renderer is in tiling mode, so the borders wrap around when your picture is halfway between pixels and become a mix between the top/bottom or left/right colour, corrupting the edges. Easy to fix, but annoying until you get what it is that corrupts your edges. Also: "The original color can still be retrieved…

It would be more accurate to say that the original color can be approximated. The approximation quality goes down as the transparency goes up, until at zero it gets lost entirely.

You're right. I didn't want to mention precision because it's a whole other can of worms, but one worth knowing how to deal with. I was looking at it from a mathematician's point of view, using rational numbers.

Re: Beware of Transparent Pixels

#39

Post by dahart »

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…

> 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-premultiplied alpha though, and the premultiplication is something that should happen right before an artist image is used. Artists shouldn't work in premultiplied images (and they generally don't) because of the color depth issue, and because it's crazy to paint premultiplied transparency manually.

Re: Beware of Transparent Pixels

#40

Post by tgb »

mark-r wrote: post #31
tgb wrote: post #16

Earlier quoted context omitted.

Also the problem can occur with any image format; what matters is how it's stored in the texture not on disc.

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.
Post reply on HN