1.28
a significant one, which have improvements for all transforms — i rewrote some pingo's features to see if i can make it better and eventually, i made another tool with less limitations
auto
auto would be more efficient — it would be able to choose the auto lossless/lossy more precisely — better & faster detection of sensible area and usage of new filters
auto (neighbor)
| version |
infile |
outfile |
time |
| 1.27 |
431.34 KB |
64.57 KB |
0.05s |
| 1.28 |
431.34 KB |
33.10 KB |
0.02s |
| 1.27 |
57.51 KB |
43.21 KB |
0.03s |
| 1.28 |
57.51 KB |
20.19 KB |
0.02s |
| 1.27 |
155.56 KB |
144.21 KB |
0.03s |
| 1.28 |
155.56 KB |
58.53 KB |
0.02s |
auto (gradient)
| version |
infile |
outfile |
time |
| 1.27 |
171.02 KB |
41.20 KB |
0.05s |
| 1.28 |
171.02 KB |
21.43 KB |
0.08s |
| 1.27 |
777.57 KB |
84.44 KB |
0.16s |
| 1.28 |
777.57 KB |
59.58 KB |
0.14s |
auto (palette cleaner)
| version |
infile |
outfile |
time |
| 1.27 |
471.77 KB |
421.88 KB |
0.09s |
| 1.28 |
471.77 KB |
126.81 KB |
0.16s |
| 1.27 |
314.14 KB |
281.74 KB |
0.08s |
| 1.28 |
314.14 KB |
97.09 KB |
0.05s |
lossy filter
the lossy filter has been improved significantly regarding the visual perception, even at low quality
— so it would have new range: each 5 means new settings; -quality=100 down to -quality=45 (or less)
palettizer
the palettizer has been improved by quite margin regarding the visual perception, while it would not any dithering atm. it usually impact filesize a bit — could be more than this demo
near-lossless
significant changes also for near-lossless PNG/WebP: pingo would do several transform and adaptive compression that would lead to faster and results than precedent version. new range: each 5 means new settings, from -near=100 to -near=80 (or less)
1.45 MB
| tool |
lvl |
out |
dssim |
time |
| cwebp |
80 |
817.60 KB |
0.00004711 |
0.74s |
| pingo |
100 |
745.64 KB |
0.00004065 |
0.26s |
| cwebp |
60 |
756.57 KB |
0.00008397 |
0.78s |
| pingo |
95 |
685.03 KB |
0.00008702 |
0.23s |
| cwebp |
40 |
716.70 KB |
0.00019907 |
0.81s |
| pingo |
90 |
637.91 KB |
0.00009669 |
0.24s |
| cwebp |
20 |
697.91 KB |
0.00051994 |
0.82s |
| pingo |
85 |
614.61 KB |
0.00012418 |
0.24s |
| cwebp |
1 |
683.46 KB |
0.00126561 |
0.84s |
| pingo |
80 |
573.90 KB |
0.00017888 |
0.26s |
lossless
new profiles in this version: they would compress more densily, especially -s0 — see this benchmark — palette sorting has been improved again: -s3 and -s4 would save more bytes, should run as fast and would require a bit less memory than previous version
PNG
PNG lossless - palette-dr (128 files) — color with tRNS, encoded as palette
| version |
lvl |
saved |
time |
mem |
| 1.00 |
-s4 |
1187.12 KB |
5.15s |
76 MB |
| 1.25 |
-s4 |
1475.43 KB |
5.32s |
90 MB |
| 1.27.3 |
-s4 |
1705.48 KB |
3.93s |
171 MB |
| 1.28 |
-s3 |
1703.96 KB |
3.63s |
143 MB |
| 1.28 |
-s4 |
1713.68 KB |
3.83s |
143 MB |
PNG lossless - palette-sx (200 files) — gray/color with (1) tRNS, *not* encoded as palette
| version |
lvl |
saved |
time |
mem |
| 1.00 |
-s4 |
6442.18 KB |
7.41s |
71 MB |
| 1.25 |
-s4 |
6663.16 KB |
7.94s |
100 MB |
| 1.27.3 |
-s4 |
6808.90 KB |
5.85s |
205 MB |
| 1.28 |
-s3 |
6815.38 KB |
5.64s |
188 MB |
| 1.28 |
-s4 |
6828.50 KB |
5.85s |
183 MB |
PNG lossless - palette-xn (280 files) — gray/color with(out) tRNS, encoded as palette
| version |
lvl |
saved |
time |
mem |
| 1.00 |
-s4 |
2776.39 KB |
10.19s |
76 MB |
| 1.25 |
-s4 |
3106.36 KB |
10.75s |
84 MB |
| 1.27.3 |
-s4 |
3438.64 KB |
8.01s |
227 MB |
| 1.28 |
-s3 |
3489.04 KB |
7.59s |
197 MB |
| 1.28 |
-s4 |
3510.21 KB |
8.01s |
196 MB |
note that those sets, or most of sets you could find here, would not only be related to palette sorting — other colortype, like grayscale, could occasionally produce smaller files
WebP
for WebP, lower profiles (-s0 and -s1) should be faster while savings more. profiles in WebP would be precedent version n-1 from -s2; new -s4 should do more savings but that would cost some time
PNG to WebP lossless - palette-dr (128 files) — color with tRNS, encoded as palette
| version |
lvl |
saved |
time |
| 1.27 |
-s0 |
1946.46 KB |
1.87s |
| 1.28 |
-s0 |
1965.76 KB |
1.39s |
| 1.27 |
-s1 |
2024.09 KB |
2.15s |
| 1.28 |
-s0 |
2043.23 KB |
1.65s |
| 1.27 |
-s4 |
2155.37 KB |
4.28s |
| 1.28 |
-s3 |
2155.37 KB |
4.28s |
| 1.28 |
-s4 |
2173.67 KB |
4.73s |
PNG to WebP lossless - palette-xn (280 files) — gray/color with(out) tRNS, encoded as palette
| version |
lvl |
saved |
time |
| 1.27 |
-s0 |
4036.16 KB |
3.68s |
| 1.28 |
-s0 |
4105.85 KB |
2.83s |
| 1.27 |
-s1 |
4339.08 KB |
4.66s |
| 1.28 |
-s1 |
4473.81 KB |
3.93s |
| 1.27 |
-s4 |
4776.87 KB |
8.86s |
| 1.28 |
-s3 |
4776.87 KB |
8.86s |
| 1.28 |
-s4 |
4803.05 KB |
9.45s |
PNG to WebP lossless - palette-sx (200 files) — gray/color with (1) tRNS, *not* encoded as palette
| version |
lvl |
saved |
time |
| 1.27.3 |
-s0 |
7464.41 KB |
2.75s |
| 1.28 |
-s0 |
7526.49 KB |
2.12s |
| 1.27.3 |
-s1 |
7565.54 KB |
3.51s |
| 1.28 |
-s1 |
7628.71 KB |
3.09s |
| 1.27.3 |
-s4 |
7781.25 KB |
6.53s |
| 1.28 |
-s3 |
7781.25 KB |
6.53s |
| 1.28 |
-s4 |
7795.51 KB |
6.99s |
behavior
during a conversion (PNG to WebP/JPEG), precedent version would stop if they could find the output — which means target file already exists. 1.28(+) would always process, and if the output already exists:
- savings would be calculated from the existing output before the process — not from the source
- it would overwrite only if it could do savings, regardless of settings (quality)
that way, the user could do multiple runs with differents settings (which could be done in lossless or lossy modes) and compare the gains over the precedent run. finally, if you want to go further or differently than pingo, you could see beeim — by using the right flags, it could probably compress more densely
