Just came across this bug “Some PNGs fail to load with ImageIO”.
I am amazed to find that over a year has passed since this bug was reported - yet it still exists in the latest 1.5.0_04 release!
Can the proper people please get notified about this, and get it fixed.
(The fix appears to even be highlighted in the bug comments!)
It seems from the comments that only invalid PNGs cause the problem (PNGs with an illegal pallet size).
It is perfectly legal to have a 256 color palettized png with a palette of less than 32 elements.
Suns decoder is just borked due to an optimisation some bright spark put in, that breaks under these circumstances.
Surely that bug has inflicted pain on every mobile games studio. Yet Sun still hasn’t fixed it.
Whenever we try to develop a new tool which uses optimised low-colour PNGs from our midlets you’ll hear someone cursing about it.
Our solution has been to maintain 2 copies of the graphics. Optimised PNGs for the midlet and non-optimised copies for the editor software. This of course leads to a maintenance nightmare. Admittedly it is not a very good solution.
Indeed. Besides the compressing scheme works best with 8bit values. So even if you have <=16 colors, the image will be usually smaller in 8bit.
Toolkit.createImage works though - so atleast there is a workaround (without having to write your own decoder ^_^)
Though im reliably informed Toolkit.createImage fails with certain png’s too - so you end up having to use both… arg the pain!
Folks, if you think a bug is important, please vote for it, or add comments explaining
why. Or preferably both.
This is the info engineers use when prioritizing the bugs to be fixed in a particular release.
Bugs with many votes get priority.
Dmitri
Java2D Team
Ahh… That might explain why some of my Paint-Shop-Pro optimised pngs won’t load in Java. If I load & save them again with windows paint, the problem goes away.