Doesn't work on large PNG Files
GWD said, on 09/02/2022
I tried optimizing larger PNG files starting at around 35MB in size with pingo and pinga, unfortunately, the program doesn't even try to compress it but just instantly skips the files. Is there a reason this isn't supported? A little more documentation would be amazing. Other than that, very nice little utility, the lossless compression performance is great, thanks a lot!
cédric (dev) said, on 10/02/2022
is that fixed in a10?
GWD said, on 11/02/2022
Thank you for the quick reply! I just tested a10 and the issue seems at least partially fixed. Pingo now doesn't skip the files anymore but the processing doesn't always work consistently. For example on this 50MB file: https://drive.google.com/file/d/1-CVLNPkSGthq1JiuFmCjHNCTpk47f2BI/view?usp=sharing Lossless compression works fine with s0-s3 but the options s4-s9 terminate faster than s3 and fail to compress it. When the same file is cropped to not include the single-color bars at the top and bottom, like here: https://drive.google.com/file/d/1-E33-ydDjIm0Sh_--iGhHMnNwbUZdpBd/view?usp=sharing All options s0-s9 work fine and s9 achieves the best compression. Is the pixel count the problem here? I also tried some true color .png images with larger size (not as compressible, around ~200MB and 21600x10800 px) and everything worked fine. When I tried with an even larger png file (~500MB, 21600x21600 px) no option worked and it processed for a few minutes without managing to compress. (s0 taking the same time as s9) A quick note on the performance: The compression (when it works) is very fast and efficient compared to other tools I experimented with. Many tools fail on such large files or take ages to process. I monitored the RAM usage and for the files I linked, it maxed out around 2,5GB. With the large 200MB pictures for which everything worked, RAM usage went up to 4GB. For the very very large 500MB picture for which it failed, RAM usage went up to 6GB before it failed. Available RAM can't be the problem though, since there was more than 45GB free at all times. I realize that these files are much larger than what most people will realistically use your this tool for, but maybe these experiments lead to some issues that can be fixed without much effort.
cédric (dev) said, on 14/02/2022
what about a11? note that-s6(and more) have chance to offer better savings/time than-s5on this kind of files because they benefit from mt
GWD said, on 14/02/2022
Hello again and thanks for your hard work and quick replies! I tested it again on a13, now everything worked perfectly, even on the 21600x21600px, 500MB file, Pingo manages to save another 8% off the already oxipng optimized file! I have an even larger 86400x43200px, 2GB .png file. This Image is a truly enormous satellite mosaic of earth, most image viewers can't even open it, with IrfanView 64bit it works fine though, as long as you have enough RAM. The uncompressed size is around 10GB. For some reason, pingo doesn't recognize this image. I just get the message: error: ----------------------------------------------------------------- not found, not supported or already exists ----------------------------------------------------------------- Do you know why it isn't recognized? If you are interested, you can download it and similar images here: https://neo.gsfc.nasa.gov/archive/bluemarble/bmng/world_big/
cédric (dev) said, on 14/02/2022
the limit is 32768² (16383² for WebP). however, the message you get is more about file access issue (like read-only or something)
GWD said, on 15/02/2022
I tried it again with a14 and now the error is gone and it does recognize the file and determines that no savings can be achieved. The (2¹⁵)² limit seems reasonable enough, I understand that anything exceeding this is a niche use case. Personally, I'm only experimenting with it out of curiosity :) Thanks again for your help and the cool tool!