Prevent creation of tRNS chunk
rossy opened this issue · 4 comments
Hi. I've been trying to use ZopfliPNG to compress PNG images inside Windows .ico and macOS .icns files. These PNG images have pretty strict format requirements: They must be RGBA32 with a full alpha channel (colour type: 6) otherwise certain parts of the user interface will mis-render them. Unfortunately, if ZopfliPNG detects that the image only has binary transparency, it will save the file as RGBA24 with a tRNS chunk, which will cause sporadic image corruption in the Windows and macOS user interface.
It would be great if there was an option to prevent the generation of a tRNS chunk. I'm not sure how it should work, but maybe it could just expose the internal keep_colortype flag on the command-line.
@rossy, In practice this requirement seems to be excessive. I'm developing Optimage which supports ICO & ICNS. No problems with Mac app icons or favicons so far. Sparkle project has also switched to an ICNS containing indexed PNGs. Do you have any examples to reproduce the issue?
@vmdanilov Actually, you might be right. I just tried to reproduce this bug with some test images and I think my image corruption on macOS was being caused by a different issue. By coincidence, the images that were affected happened to be the ones with the tRNS chunk.
I also had some image corruption on Windows, but I can't reproduce that now either. Explorer displays the .ico files with a tRNS chunk fine. I'll close this issue for now, since I can't think of a use case for it anymore.
@rossy Some icon libs can't extract indexed images properly, e.g. libicns fills them with adjacent memory.
@vmdanilov Actually, the problem I was having seems to be this one: http://vallisoftware.com/ICNSCreator/Home/pgs/lpage4.html
Apparently there is a bug in macOS which causes icp4 and icp5 type ICNS entries to be interpreted as compressed ICNS data instead of PNG when they are used in an app bundle. I was using different source images for my 16x16@1x and 32x32@1x icons and they had a tRNS chunk, which is why I thought this was the cause. After more testing, I realised the icp4/icp5 bug affects all kinds of PNGs, and PNGs with a tRNS chunk work fine when used for other sizes (like ic11 and ic08.)
I'm pretty sure I saw corruption in my Windows icon as well, but I can't repro it at the moment, though it might actually be because the source image is indexed (it definitely has less than 256 colours.)