Load-Save TGA wiping alpha channel
AN3Orik opened this issue · comments
Prerequisites
- I have written a descriptive issue title
- I have verified that I am running the latest version of ImageSharp
- I have verified if the problem exist in both
DEBUGandRELEASEmode - I have searched open and closed issues to ensure it has not already been reported
ImageSharp version
3.0.0
Other ImageSharp packages and versions
3.0.0
Environment (Operating system, version and so on)
Windows 10
.NET Framework version
.NET 8
Description
Loading 32bit RGBA TGA and saving after wiping Alpha channel to white (255) color.
Steps to Reproduce
using (Image<Rgba32> image = Image.Load<Rgba32>("test.tga"))
{
image.Save("test_output.tga");
}
Before:
After:
Images
Sorry, library version is 3.1.1
The image descriptor byte in the file header of the provided image is 0. Usually bits 0-3 indicate designated as alpha channel bits.
Since the descriptor is 0, the decoder assumes there is no alpha channel.
That is the reason it is lost when decoding and encoding again.
I still believe the provided image does not follow the spec with omitting the image descriptor, when there is alpha data.
Other decoders have problems with it too, like irfanview:
edit: not sure why this image renders so weird in github, looks different when you click on it.
I think one solution in handling this is to assume true color images with 32 bits per pixel to always have a alpha channel with 8 bit. @JimBobSquarePants What do you think about this? Would anyone write a 32 bits per pixel image without a alpha channel?
Yeah @brianpopow good idea! I think that’s a safe assumption and it’s non-destructive. We should add it to the v3.1.x branch and then main.
@AN3Orik can I use the image you have provided in a unit test?
@AN3Orik can I use the image you have provided in a unit test?
It's a texture from very old game, so i think it's not a problem at all if you care about license or something.
We should add it to the v3.1.x branch
@JimBobSquarePants I have opened a PR for this Issue. I am not sure how the procedure is to add it to the v3.1.x, I think, it would be better if you do that, so I dont break stuff. Also I am not totally sure this should go into a hotfix, since the image is not following the spec correctly and this PR only adds a workaround to deal with those kind of images.
I’m happy to skip adding to 3.1.x I’ve only been doing so because v4 is so far away.
closing this now with #2643 merged