Some PNGs using greyscale or tRNS are processed incorrectly
Minecraft does not process some PNGs correctly. Specifically, it does not seem to implement the tRNS specification fully, nor does it handle greyscale PNGs correctly. Attached are some vanilla textures from the most recent snapshot as of this writing (15w42a) that render incorrectly when compressed with ScriptPNG's most aggressive lossless setting. (If Mojang did this compression themselves, Minecraft's PNGs would be 34.45% [1299 KB] smaller, which is a not-insignificant amount of bandwidth.)
Environment
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_01, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
OpenGL: GeForce 9200/integrated/SSE2 GL version 3.3.0, NVIDIA Corporation
Is Modded: No.
Created Issue:
Some compressed PNGs render incorrectly in-game
If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to only apply to greyscale PNGs, wherein they will appear much lighter than they should, or will be solid black where they should be transparent. Attached is the default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.
Environment
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_01, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
OpenGL: GeForce 9200/integrated/SSE2 GL version 3.3.0, NVIDIA Corporation
Is Modded: No.
- Unresolved
- Open
- Unconfirmed
- Rendering TexturePack TexturePacks
- 1.5.1
If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to only apply to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached is the default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.
If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to only apply to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached
isthe default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to only apply to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.
If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to
only apply to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these PNGs correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft compressed with ScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.
13w21a's textures, compressed with pngslim 1.4. 595 KB [609442 Bytes] saved.
If a heavy-duty PNG compression tool such as ScriptPNG is used on a texture pack, Minecraft will not render some of these
PNGs correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft compressed withScriptPNG's highest setting (9, or Ultra), so you don't have to compress them yourself (the process takes several hours), as well as the stitched files and some screenshots.If a heavy-duty PNG compression tool such as ScriptPNG is used on the PNGs within a texture pack, Minecraft will not render some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (13w21a) compressed with pngslim 1.4 , so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to save these externally anymore), and some screenshots of the side-effects.
If a heavy-duty PNG compression tool such as ScriptPNG is used on the PNGs within a texture pack, Minecraft will not render some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (1
3w21a) compressed with pngslim 1.4 , so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to save these externally anymore), and some screenshots of the side-effects.If a heavy-duty PNG compression tool such as ScriptPNG is used on the PNGs within a texture pack, Minecraft will not render some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (1.6) compressed with pngslim 1.4 , so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to save these externally anymore), and some screenshots of the side-effects.
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
If a heavy-duty PNG compression tool such as ScriptPNG is used on
thePNGswithin atexture pack, Minecraft will not render some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (1.6) compressed with pngslim 1.4 , so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to save these externally anymore), and some screenshots of the side-effects.If a heavy-duty PNG compression tool such as ScriptPNG is used on PNGs in a resource pack, Minecraft will not render some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (1.6) compressed with pngslim 1.4 , so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to save these externally anymore), and some screenshots of the side-effects.
If a heavy-duty PNG compression tool such as ScriptPNG
is used on PNGs in a resource pack,Minecraftwillnotrender some of these textures correctly. This seems to apply mostly to greyscale PNGs, wherein they will appear much lighter than they should, and/or will be solid black where they should be transparent. Attached are the default textures of Minecraft (1.6)compressed withpngslim 1.4, so you don't have to compress them yourself (the process takes several hours), as well as stitched files (generated by 1.5.1; the snapshots do not seem to savetheseexternally anymore), and some screenshots of the side-effects.Minecraft does not process some PNGs correctly. Specifically, it does not seem to implement the tRNS specification fully, nor does it handle greyscale PNGs correctly. Attached are some vanilla textures from the most recent snapshot as of this writing (15w42a) that render incorrectly when compressed with ScriptPNG 's most aggressive lossless setting. (If Mojang did this compression themselves, Minecraft's PNGs would be 34.45% [1299 KB] smaller, which is a not-insignificant amount of bandwidth.)
Somecompressed PNGs renderincorrectlyin-gameSome PNGs using greyscale or tRNS are processed incorrectly
Relates to MC-12699.
The bug
If an animated png file is used as a texture, the game will only render the first frame of the file, and all following frames will be ignored.
How to reproduce
A resource pack is attached that replaces the glass texture with this public domain animated PNG file: https://commons.wikimedia.org/wiki/File:Animated_PNG_example_bouncing_beach_ball.png
- Download and apply the attached resource pack
- Look at glass
Expected results
The texture would be animated.
Actual results
It is not.
How to fix
Much like MC-12699, this issue most likely arises from a broken or incomplete implementation of the png specification.
Whether these files should be converted over to Minecraft's native animation format is another question entirely.



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.