Alpha channel and resizing issue

[Chaky]

Whenever the picture is resized by using other than "Nearest Neighbour" method, and if alpha channel is present, the all-transparent parts actually become black.

It affects image resizing and mipmap generating.

I guess the culprit is in the resizing code. Apparently when alpha channel is 255, Red Green and Blue channels are set to 0. Only the "Nearest neighbour" method doesn't produce the black spots.

I'm using Paint.NET to work with textures (including normal maps with embedded mipmaps), and changing colors to black is very unwanted effect.

Edited August 4, 2010 by Chaky

[APShredder]

This doesn't repro for me.

[Rick Brewster]

It's showing up as black in Paint.NET, or in another application?

Please provide a screenshot, and a sample image that reproduces the problem.

[Chaky]

Here's the example.

There are 6 files within the archive. 3 dds files are examples I just made, and 3 jpg files are screenshots of those files without an alpha channel, viewed from another tool.

wall01.dds is the original

wall02.dds is that same original with a stroke of eraser across the picture. As you can see, the picture is still preserved. Only alpha channel is added.

wall03.dds is wall02.dds, but resized (to 1024x1024, then back to 512x512). You can see that the transparent part is now black.

Edit:

It is done with Paint.NET.

Only the 100% transparent pixels are turned black, so it is impossible to see from within the Paint.NET.

This doesn't happen when "Nearest Neighbour" method is used when resizing (or generating mipmaps).

Examples.7z

Edited August 4, 2010 by Chaky

[Rick Brewster]

Oh I see what you mean -- originally you said,

Apparently when alpha channel is 255...

But now you're saying that this happens when the alpha channel is 0.

Well, the truth is, this is how the math works out when doing correct alpha composition. When alpha is zero, it doesn't matter at all -- mathematically speaking -- what the values of the R, G, or B channels are. Fully transparent is fully transparent. Also, the math doesn't work out to even allow a meaningful R,G,B value to be computed -- it's undefined, but the computer can't actually represent "undefined", so instead Paint.NET uses 0. I could've picked lime green or purple, which are popular colors for apps that use a "transparency key" type system, but in the end it's still a completely arbitrary choice that not everyone would agree with. To make it customizable would greatly reduce performance, as the customized color "key" would have to be referenced for every pixel operation (even a 1024 x 1024 image has over 1 million pixels).

Thus, the problem is actually with the other tool you are using and how it is interpreting an Alpha=0 pixel value. It does not appear to be doing correct alpha blending, which would treat all Alpha=0 color values as equivalent (completely transparent, in other words).

[Chaky]

But now you're saying that this happens when the alpha channel is 0.

Whether the alpha is 0 or 255 when the pixel is completely transparent, I don't know.

Well, the truth is, this is how the math works out when doing correct alpha composition. When alpha is zero, it doesn't matter at all -- mathematically speaking -- what the values of the R, G, or B channels are. Fully transparent is fully transparent.

Yes, it matters if the dds file is normal map. It is actually ruining the texture.

Also, the math doesn't work out to even allow a meaningful R,G,B value to be computed -- it's undefined, but the computer can't actually represent "undefined", so instead Paint.NET uses 0.

When displaying the picture, it can not represent the transparent pixels. But that does not mean that R, G and B channels should be all set to 0. Alpha channel is separate from RGB channels, and they must not get altered with alpha.

Thus, the problem is actually with the other tool you are using and how it is interpreting an Alpha=0 pixel value. It does not appear to be doing correct alpha blending, which would treat all Alpha=0 color values as equivalent (completely transparent, in other words).

The "other tool" is bug-infested allright, but that's beside the point.

It does not matter how the other tool represents the alpha channel. Actually, it completely ignores the alpha when previewing the picture and display RGB part only. That is why there is virtually no difference between wall01 and wall02, and that's how one can see that Paint.NET is actually destroying the RGB channels when resizing, and not during the actual editing.

I remind you that wall02.dds contains RGB channels intact WITH the srike of alpha across the picture. Wall03.dds is the outcome of resizing of wall02.dds. Not the eraser.

[Rick Brewster]

Paint.NET isn't actually destroying anything: when you resize the image it must blend together neighboring pixels. When those pixels have an alpha value of zero, everything multiplies together to zero and also gets divided by zero. Zero is zero is zero is zero is zero. This is just math. The information simply isn't there and cannot be psychically extracted, nor can an accurate guess be made.

The problem you're seeing stems from the fact that normal maps and color bitmaps are overloaded onto the same storage format. The "RGB" in the image is coerced to be XYZ by other tools and renderers, because historically it was very convenient to simply use the same tools and file formats for both.

There is no bug in Paint.NET. It is performing correct calculations on RGB+A pixels exactly the way it was designed to do. The fact that normal maps are actually XYZ instead of RGB is an artifact of other tools that want to leverage RGB-based tools (which in general has been a smart thing). There is no XYZ alpha composition calculus out there. Maybe you simply shouldn't be using the alpha channel for images which will then be used as normal maps.

[Chaky]

Thing is, the alpha channel is used as specular highlight map. Only the blue channel (to my understanding) is unused.

I guess the normalmaps must not be resized using any other method than "Nearest neighbour".

I wish I knew that before edited tonnes of normal maps that were missing mipmaps...

Edited August 4, 2010 by Chaky