worse compression in every single version after a21
subash said, on 11/09/2022
https://web.archive.org/web/20220620190414/https://css-ig.net/pingo
pingo -s9 -strip
a21 - https://web.archive.org/web/20220620190414/https://css-ig.net/pingo I can understand that You want it to be faster but shouldn't compression be priority for sa and sb? data set - https://css-ig.net/benchmark/files/ original size - 167041983 bytes pingo -s9 -strip pingo -sa -strip pingo -sb -strip bytes version time 109703258 0.99.5_s9 00:13:32.6781217 108707832 a18_s9 00:13:06.8720775 108707832 a19_s9 00:13:03.0430794 108707832 a20_s9 00:12:48.6439773 108707832 a21_s9 00:12:50.0815966 !!! 108740343 a22_s9 00:12:28.3737962 108740343 a23_s9 00:12:31.4602619 108740343 a25_s9 00:12:47.1652241 108740343 a27_s9 00:12:39.7123578 108740343 a29_s9 00:12:31.2109900 108738617 a30_s9 00:11:45.0842076 108731638 a31_s9 00:11:44.0233618 109634970 0.99.5_sa 00:16:54.2160274 108633290 a18_sa 00:14:53.6743895 108633290 a19_sa 00:14:49.5383801 108633290 a20_sa 00:14:32.8197403 108633290 a21_sa 00:14:32.1896602 !!! 108653565 a22_sa 00:14:18.0382624 108653565 a23_sa 00:14:17.7170599 108653565 a25_sa 00:14:21.3114353 108653565 a27_sa 00:14:25.7362671 108653565 a29_sa 00:14:18.4443228 108652313 a30_sa 00:13:19.3119139 108642288 a31_sa 00:13:20.9105740 109631794 0.99.5_sb 00:16:30.6632470 108635617 a18_sb 00:14:53.9410669 108635617 a19_sb 00:14:55.7861322 108635617 a20_sb 00:14:34.9165932 108635617 a21_sb 00:14:36.7956373 !!! 108655941 a22_sb 00:14:20.5082454 108655941 a23_sb 00:14:21.0950210 108655941 a25_sb 00:14:20.1442632 108655941 a27_sb 00:14:24.9967506 108655941 a29_sb 00:14:20.2458536 108654493 a30_sb 00:13:25.5716031 108652344 a31_sb 00:13:28.2532987
subash said, on 12/09/2022
a32 slower than a31 compression is better than a31 but still worse than a21 108707832 a21_s9 00:12:50.0815966 !!! 108731638 a31_s9 00:11:44.0233618 108723633 a32_s9 00:12:08.6239117 108633290 a21_sa 00:14:32.1896602 !!! 108642288 a31_sa 00:13:20.9105740 108635435 a32_sa 00:13:44.4733514 108635617 a21_sb 00:14:36.7956373 !!! 108652344 a31_sb 00:13:28.2532987 108646572 a32_sb 00:13:49.6411528
Adreitz said, on 13/09/2022
I am only a user of this project, but the dev seems most interested in compression per unit time. I don't know how he draws the line, but he obviously felt that pingo was using too much time for those extra few bytes per file. Pingo is never going to have the objective best compression. If you want closer to that with an automated tool, you can use ECT instead with --allfilters --pal_sort=120 options. It'll be pretty slow, but will almost always get you better pure compression than Pingo.
subash said, on 14/09/2022
a33 compression is better and faster than a31,a32 and for sa even a21 108707832 a21_s9 00:12:50.0815966 !!! 108731638 a31_s9 00:11:44.0233618 108723633 a32_s9 00:12:08.6239117 108715106 a33_s9 00:11:37.7650711 108633290 a21_sa 00:14:32.1896602 108642288 a31_sa 00:13:20.9105740 108635435 a32_sa 00:13:44.4733514 108626995 a33_sa 00:13:15.5952445 !!! 108635617 a21_sb 00:14:36.7956373 !!! 108652344 a31_sb 00:13:28.2532987 108646572 a32_sb 00:13:49.6411528 108641182 a33_sb 00:13:22.6124541 @Adreitz "he obviously felt that pingo was using too much time for those extra few bytes per file" there is nothing about that in his post: https://encode.su/threads/3879-Optimizing-palette-order-for-indexed-png-images?p=75050&viewfull=1#post75050