Sign in to follow this  
Shrinker

Transparency problem

Recommended Posts

Hi.

I created a PNG picture with shapes and 100% transparent areas. When loading this in a 3d environment where colors are interpolated I notice black borders around everything. With the color picker I found out that every 100% transparent pixel's color is set to pitch black (and alpha = 0, of course). Is there a way to prevent Paint.NET from using a default color there? This behavior has been criticized in Photoshop already by the official PNG website: Photoshop sets transparent pixels to be white, causing white outlines in 3d environments. This default color also applies to areas I filled with another color whose alpha is zero.

*edit:

I was just happy to find out that this is possible to do with Gimp. :)

S

Share this post


Link to post
Share on other sites

Whatever software you are using for "3d environments" is flawed. A color value with alpha=0 is equivalent to all other color values with alpha=0. They are all fully transparent and must contribute nothing to any blending operations which sample from them. If the software is using correct alpha blending, it won't matter what the RGB portion of the color value is set to.

Share this post


Link to post
Share on other sites

Well that software is OpenGL and properly blends every color component...

That is bilinear texture filtering and it's the way how transparent things are interpolated in every 3D API.

It is wrong to assume that a color with alpha = 0 is equivalent to all other colors with alpha = 0, even though that doesn't matter the least bit most of the time. To properly support this, Paint.Net would need the ability to edit all four color layers individually like in Gimp... I think that'd be a nice feature.

I like your program nevertheless, but this is a situation where you could reduce the need to use more than one program to solve a certain task :)

Share this post


Link to post
Share on other sites

Maybe you're telling it to use pre-multiplied alpha, which Paint.NET does not use. Paint.NET's alpha handling here is indeed correct, and all colors with an alpha=0 should be rendered exactly the same. They are all completely transparent, and the color channel values should not matter. With the way you are expecting things, the "transparent" color would always have to match whatever background it was laid upon, and so you'd need one image per background. Not the best way to do things really.

If your renderer is expecting pre-multiplied alpha, then for every pixel you load in from a PNG you should do pixel.Red = (pixel.Red * pixel.Alpha) / 255 (and then repeat for green and blue channels).

Recommended reading:

http://en.wikipedia.org/wiki/Alpha_compositing

http://www.getpaint.net/doc/latest/en/L ... Modes.html

http://en.wikipedia.org/wiki/RGBA_color_space

Share this post


Link to post
Share on other sites
Maybe you're telling it to use pre-multiplied alpha, which Paint.NET does not use. Paint.NET's alpha handling here is indeed correct, and all colors with an alpha=0 should be rendered exactly the same.

Please open your eyes and see the reality, which is that textures are filtered and all channels are interpolated along the pixels. That's the way it is done in every modern graphics engine. Your assumption is wrong because it does make a difference, but it seems like you'll never agree. As I said I'll have to use both Paint.Net and Gimp to accomplish this then. I remember reading on the official png page how they described Photoshop's handling of the matter some time ago as plainly wrong. (It's like in Paint.Net, only that they used to set the color to white). Note that fixing this would require very little effort from your side, since it would merely be a removal of a "feature" which defaults the colors. BTW, why are you using black and not white or pink? I remember pink being a designated color for transparency in many old DOS games. I personally like green too.

Let me state this very important fact once again: While filtering textures (e.g. bilinear, trilinear), it does make a difference what the color channels' values are when the image is 100% transparent in places. Your method causes uncontrollable black outlines. Also please note that some shader systems give you the option to just ignore the alpha layer. An example would be a green texture with jungle bushes which could optionally have transparent holes between the leaves and also be set to be 100% opaque but still look nice.

Why limit the user in this way? If you don't automatically set 100% transparent pixels to black, this can still be done, while the current implementation imposes an unnecessary limitation. You could add a little dialog for setting 100% transparent pixels' color values to something, but as a real feature and not a silent limitation. I'd always yield to a solution which allows for more things, and that would clearly be not defaulting those pixels.

See my font in action:

http://www.intercomm.com/shrinker/images/08/font.tech.test.png

Using only Paint.Net, it'd have ugly black outlines. Zooming out, mipmaps would make it look gray.

Also note that during mipmap calculation, your black color makes subsequent mipmaps darker and darker because of interpolation effects too.

Such a generic gaming scene has a lot of transparency going on too, and as you see, texture filtering is a must:

http://www.happypenguin.org/images/doom3.jpg

Recommended reading:

http://en.wikipedia.org/wiki/Texture_filtering

http://en.wikipedia.org/wiki/Magic_Pink

http://en.wikipedia.org/wiki/Mipmap

Share this post


Link to post
Share on other sites

I've personally implemented filtering that correctly takes the alpha channel into account. Just try resizing an image that has transparency using Image->Resize. There's no fundamental difference between that bilinear or bicubic resampling and whatever you are using (which is probably the graphics card and its interaction with OpenGL/Direct3D). Transparent pixels do not contribute color to any area in the output that has sampled from them. Partially transparent pixels contribute color that is proportional to their alpha value (i.o.w. they are weighted with respect to the alpha channel). Filtering/resampling must not be implemented as just interpolation of color values -- it must use a weighted mechanism based off the alpha channel.

My assumptions are not wrong, and my math is provably correct. Whatever renderer you are using, whether it's your own or otherwise, is simply not handling the alpha channel correctly or is configured wrong. There are definitely renderers out there that expect pixel data to be in a certain format, such as using green or pink as a color key. That is, however, a very arbitrary way of doing things that still introduces ugly edge cases (why not use blue? or yellow? or lavender? there's no mathematical reason to choose one over the other). Quite often these choices are made in the interests of performance, not correctness (which, I might add, is often a very legitimate engineering tradeoff, but less so nowadays with modern graphics cards).

A transparent pixel is a transparent pixel is a transparent pixel. If your filtering code treats it as anything else, then it is simply implemented incorrectly, or it is configured wrong.

Please open your eyes and see the reality...

But if you're going to have this attitude about it then I simply can't help you any more.

Share this post


Link to post
Share on other sites

Um...you can change the color of the fully transparent areas.

Steps:

Open image with transparent area.

Use the Magic Wand (Tolerance 0) to select transparent area.

Fill with desired color.

With the selection still active, use BoltBait's Transparency Adjustment Effect to lower the transparency to 0.

I tested this and it works. Your desired color info is retained.

Share this post


Link to post
Share on other sites

Shrinker, no, you are wrong. Your program is wrong. The only time a transparent color's colors should have any effect on output is if you're creating a gradient between a non-transparent color and a transparent one.

You ask why Paint.NET uses black instead of pink? Simple. It's not black, it's transparent.

Why don't you go get some real 3D modeling software (assuming that's what that is - I'm not entirely sure)? Like Maya, 3DSMax, or Blender!

(Your turn, Rick ;) )

Share this post


Link to post
Share on other sites
The only time a transparent color's colors should have any effect on output is if you're creating a gradient between a non-transparent color and a transparent one.

Even then, it should not. If you are computing a gradient between A and B, and B is transparent, then the gradient should be a smooth transition from A to transparency ... regardless of B's color values.

If you look at the way pre-multiplied alpha is set up, you'll quickly see why my statement of "all color values where A=0 are equivalent" is try. It's because they literally are the same value. Paint.NET does not use pre-multiplied alpha for storage, but the mathematics are still relevant.

Share this post


Link to post
Share on other sites

* I've just checked out a trim texture in Doom 3 and the problem does indeed not occur because the filtering is set to draw really sharp edges. What if I don't want them?

* So how about the mipmaps still? You darken the image by defaulting that color.

* And what if I wanted to have a shiny glow around my letters, e.g. in red?

* And still, what about textures which are supposed to look nice with the alpha layer ignored/disabled?

* What if pre-multiplied alpha is not available or has been decided against for some reason (performance, anyone?) You're not even using it in your program!

pyrochild, please note that it doesn't matter whether it is my 3D engine, that of id software or Valve, or just a test project someone made in DirectX or OpenGL. I don't need advice which modeler to use since my sole intention is to convince Rick that it is better to lift that limitation because it is unnecessary. Absolutely unnecessary.

Rick, please tell me: What are the benefits of defaulting that color over not doing so? I clearly see an advantage for gimp there for allowing me that freedom.

How to compare this limitation...

What if your text editor only allowed you to place at max 2 empty lines? What if Windows wouldn't start up if you didn't set a desktop background? What if your compiler did not allow float literals which have more than 2 digits after the decimal separator? What if Microsoft Visual Studio set a fixed indent size of 10 without any way to change it? Unnecessary limitations.

We are mostly treating pictures to be made of the red, the green, the blue and the alpha channel, aren't we? Why to make that very exception, only when the alpha is zero, and alter the channel content automatically? You're all right that 99% of the time it does not matter at all whether or not that is defaulted, but apparently I found a case where it matters, and this program could easily cope with it with a slight modification.

(Your turn, Rick ;) )

Newbie biting?

Share this post


Link to post
Share on other sites

No, it wasn't newbie biting. I'm going to lock this for 12 hours to let tempers cool before it goes any further. Rick might add more in the way of comments later, but I don't want any more bickering. I'll unlock it again in the morning (EST). :-)

Thread Locked

Share this post


Link to post
Share on other sites
* I've just checked out a trim texture in Doom 3 and the problem does indeed not occur because the filtering is set to draw really sharp edges. What if I don't want them?

I don't know, ask the DOOM 3 guys. I don't see how this question is Paint.NET related at all. Paint.NET is not the DOOM 3 code, nor vice-versa.

* So how about the mipmaps still? You darken the image by defaulting that color.

It's not darkening any images. I don't know what you're talking about -- Paint.NET doesn't generate mip-maps. Or are you talking about the DDS stuff? If not, this is still just an artifact of your renderer.

* And what if I wanted to have a shiny glow around my letters, e.g. in red?

Then you should probably add a shiny red glow. I don't know where this question is coming from.

* And still, what about textures which are supposed to look nice with the alpha layer ignored/disabled?

Then that's a function of your renderer. Don't use any alpha in that case. Put your layer against a solid background (use 2 layers, then flatten). Or, it sounds like what you really want is TWO textures. One is alpha only (probably saved as grayscale), the other is color only. The fact that your renderer wants a 32-bit texture and then mistreats the alpha channel is a convenience or performance optimization (but, in this case, it's actually inconvenient).

* What if pre-multiplied alpha is not available or has been decided against for some reason (performance, anyone?) You're not even using it in your program!

Pre-multipled and regular alpha are mostly equivalent, it just requires simple math to convert between. Depending on what you are doing, or what stage of your rendering pipeline you're in, either one may be most convenient to work with at the time. Paint.NET does not store anything -- in memory or on disk -- in pre-multiplied alpha, except for certain short durations while it's performing certain blending operations.

pyrochild, please note that it doesn't matter whether it is my 3D engine, that of id software or Valve, or just a test project someone made in DirectX or OpenGL. I don't need advice which modeler to use since my sole intention is to convince Rick that it is better to lift that limitation because it is unnecessary. Absolutely unnecessary.

There is no limitation. That's what we're telling you. To be quite honest you sound like you don't really know what you're talking about. You're taking some artifacts of how certain renders treat (or mistreat!) the alpha channel, and projecting it as canon.

Rick, please tell me: What are the benefits of defaulting that color over not doing so? I clearly see an advantage for gimp there for allowing me that freedom.

I'm not defaulting to any color. When the image is rendered, any pixel with an alpha value of 0 has lost its color values. That's just how layer compositing w/ alpha works (aka alpha compositing). There are no color values to keep around -- they literally fall to zero once they pass through 1 or 2 parts of the blending stuff. When you take N pixels all of which have 0 alpha and thus 0 weight, and then blend them all together, the math results in a tuple of all zeros. The alternative is to have division by zero errors (i.o.w. crashes).

It sounds like you're asking me to simply replace all RGBA={0,0,0,0} values with {r,g,b,0} values where "r,g,b" are "Shrinker's favorite color."

How to compare this limitation...

What if your text editor only allowed you to place at max 2 empty lines? What if Windows wouldn't start up if you didn't set a desktop background? What if your compiler did not allow float literals which have more than 2 digits after the decimal separator? What if Microsoft Visual Studio set a fixed indent size of 10 without any way to change it? Unnecessary limitations.

Like I said, this isn't a limitation in Paint.NET. Those are all very flawed analogies, and don't really make sense. It seems like there's an impedance mismatch in your understanding of how textures should work with respect to the alpha, how the alpha channel has been taken into account in various rendering engines, and how the alpha channel is supposed to work from a mathematical standpoint. Paint.NET takes the latter implementation.

We are mostly treating pictures to be made of the red, the green, the blue and the alpha channel, aren't we? Why to make that very exception, only when the alpha is zero, and alter the channel content automatically? You're all right that 99% of the time it does not matter at all whether or not that is defaulted, but apparently I found a case where it matters, and this program could easily cope with it with a slight modification.

You should figure out a way to make your renderer work correctly, or structure your input data more appropriately (sometimes it sounds like what you really want is TWO textures). Like I said, it's not difficult to convert to the exact type of alpha that you want. You know that transparent pixels are output as RGBA={0,0,0,0} from Paint.NET. What's stopping you from modifying those after you load them?

I really don't see where you are going with any of this. It sounds like you just want Paint.NET to be randomly psychic about how you are going to be misusing the alpha channel in other programs or in your own code.

Share this post


Link to post
Share on other sites

Ultimately, Shrinker, I think you're confusing the RGBA and RGBX pixel formats.

RGBA defines a very specific way for treating the alpha channel: it defines how transparent the pixel is.

RGBX just has an extra channel that the application can interpret however it wants.

Paint.NET uses RGBA, not RGBX. Quite often other software will use these interchangeably for any number of reasons.

Share this post


Link to post
Share on other sites

Shrinker has a valid argument, he is just not expressing it very clearly.

My assumptions are not wrong, and my math is provably correct. Whatever renderer you are using, whether it's your own or otherwise, is simply not handling the alpha channel correctly or is configured wrong.

This is true. OpenGL/DirectX hardware does not handle it correctly. Texture filtering interpolates all channels linearly, and special cases like zero alpha are not taken into account.

That's why fully transparent pixels should have color data as well.

It is of course possible to handle it correctly by using multiple texture samples, but it's not worth the cost when (nearly) every paint application can 'preprocess' it for you.

There is no limitation. That's what we're telling you.

Well there is a limitation, but it is only for those who wish to make textures for DirectX or OpenGL.

The only change needed would be to allow fully transparent pixels to store a color value. I would imagine that it would not take much effort to do this, but I may be wrong as well.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this