Some PNGs using greyscale or tRNS are processed incorrectly

Interestingly, Irfanview and XnView also render these compressed PNGs in exactly the same way Minecraft does. Other applications, including Windows Photo Viewer, Google Chrome, or GIMP, will render them correctly. Does Minecraft share a library with XnView and Irfanview for rendering PNGs?

Wow.... didn't think somebody would report this, let alone yesterday! Saves me the trouble, though.

I am a texture pack creator, and just got the idea to use an image compression tool, I found one for Ubuntu called "trimage" (Trim-age, like mixing trim and image. It uses optipng, advpng, and pngcrush), it cuts the size of my texture pack in half!

However, much like you, I noticed that images that were grayscaled displayed in Minecraft too bright and with transparency displayed as black. However, in GIMP, Chrome, EOG (Eye Of GNOME, the GNOME image viewer), and Nautilus thumbnails all display these images properly.

It would be nice to see this bug fixed, as it's an annoyance to actually find out which images are grayscaled (for some reason trimage seems to keep some of them indexed....) and then you gain a slightly larger file size (for me it added 1 KiB) which probably in larger texture packs (both in data and resolution) would add up much more than my texture pack.

Mojang should also fix this to encourage .PNG optimization a little more (or really, just not accidentally discourage it....)

Yes, this is still an issue in 13w19a.

Added a new .zip with 13w21a's textures compressed with pngslim 1.4.

This is still an issue with the new resource pack format. Added a new .zip with 1.6's textures compressed with pngslim 1.4.

Arg, can't believe this small issue still isn't fixed.

I think the issue is not with the libraries that render textures, but the libraries that process textures in order to stitch them! I think that this library is reading grayscale .PNGs wrong, and then writing them to the atlas wrong as a result. If the that library cannot be changed, possibly there could be a check for grayscale textures before that library, and if so, convert the mode to RGB before attempting to read it?

I know this getting fixed would solve me a great deal of needed precautions and potential issues.... such as not needing to refrain from using an image optimizer on images that are all gray, or needing to re-edit them to switch from grayscale to indexed.

I also have this issue. It's a pain to run a batch optimizer on a texture pack and load it up to find out that some textures are rendered incorrectly and having to manually go back and change them to RGB.

I came across the same problem, and I have fixed it in my client today. The bug is in Java's ImageIO thingy. I replaced the calls to ImageIO.read with javapng (http://code.google.com/p/javapng/), and grayscale images render properly now. This is a very simple change and it shouldn't take much time for Mojang to implement.

Is this still a concern in the current Minecraft version 14w21b / Launcher version 1.4.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Yes, this is still bugged.

Still an issue in 1.8.3.

Since you attached textures_compressed_15w42a.zip, does this also affect 15w42a?

Yep, added.

Java itself handles our png files. Seems I might end up writing our own loader code for this. Definitely not happening before 1.10.

Not noticing any issues when trying that resource pack in 18w03b. This was probably fixed even earlier.

As for the "should" of this report (the game's image files should be compressed further), I'll not comment.