Channel data read incorrectly from uncompressed .dds about pillow

[Yay295]

Pillow 6.2.2 was released more than four years ago. Would you be able to find a newer version of Pillow that works as expected?

I looked through the history of the TGA image plugin since 6.2.2 and didn't notice anything, so it may a change to some other file that caused this.

[radarhere]

The demo code that the user provided doesn't use the TGA format, so I think this is just about DDS. I think Pillow 8.2.0 would be the last version that gives the result you want, and that the change came from #5383.

If I manually eyedrop the top left corner in Gimp, I get (192, 192, 192).
If I convert your image to a PNG using ImageMagick and get the top left pixel using Pillow, I get (192, 192, 192, 0)

I suspect PVRTextool only works on Windows. Is that the case?

Could you attach a copy of what you think the image should look like, in a common format like PNG?

This is what Pillow thinks the image should look like, ImageMagick agrees, and so does https://imagetostl.com/view-dds-online.

I'm not convinced that Pillow is behaving incorrectly.

[7ippo]

Thanks for the reply. Yes It is more likely related to the DDS plugin. And here is the png I got from PVRTextool's File - Save Image function and this what I expect.

The PNG format file

This is also what I see from PVRTextool. I'm not sure if PVRTexTool only works on Windows, but I usually use it to view texture data.

What I see from PVRTextool, including channel's information and raw texel data.

[radarhere]

Thanks for the image.

My conclusion from my previous comment is that Pillow is not incorrect, and nothing needs to be changed here.

Here's some more evidence to consider

• someone saying that PVRTexTool doesn't read A8R8G8B8 correctly - https://www.gamedev.net/forums/topic/692707-directx-texture-tool/5359502#post_5359503
• in the issue that prompted this new behaviour, here's a user saying that Windows Texture Viewer disagreed with the old behaviour that you are after - #4264 (comment)

If you would like Pillow to create your version of the image from A8R8G8B8 images, you could move the channels around only for those images like so

from PIL import Image
with Image.open("water6_1x4.dds") as img:
    if img.tile[-1][-1] == (32, (16711680, 65280, 255, 4278190080)):
        r, g, b, a = img.split()
        img = Image.merge("RGBA", (g, b, a, r))
    img.save("out.png")

[7ippo]

Thank you for your patient explanation. After a careful troubleshooting process lasting for almost two days, we have basically confirmed that the issue is caused by a bug or bizarre behavior in PVRTextool related to uncompressed DDS textures.

We discovered that, interestingly, the rendering error in our game was not caused by Pillow's DDS reading. Instead, it was precisely due to a brief usage of a newer version of the PVRTextool(v5.5.0) during the update of our cacheserver project, for compressing from DDS to ASTC, which led to the issue. This will turn the texture into yellow(different channel data), just like the png file I uploaded above. But the previous version of PVRTextool(v4.20) will not encounter this issue. Pillow won't either. And we confirmed that if the uncompressed DDS textures are preprocessed by using Pillow they will render correctly in the game.

Viewing the uncompressed DDS textures using tools like Nvidia Texture Tool shows different results compared to PVRTextool.

So it seems that there might be an issue with how PVRTextool handles uncompressed DDS textures, causing problems when viewing or compressing using command-line tools.

[radarhere]

Thanks for figuring that out. It may be helpful to anyone else encountering this in the future.