cédric (dev) said on 03/15/2018

i added -pngcolor in 0.96h as an experimental feature. what it does is a well known method: basically, it reduces the number of colors in the image data, which should make the PNG smaller in some cases (atm, this could need some optimizations)

compare vs -pngfilter

it is speed oriented, so it is probably introduced with some limitations regarding low quality or the default compression. if you consider my very basic test on it, it seems to offer a bit better compromise at high quality settings (according to butteraugli or dssim)

pingo -pngfilter vs -pngcolor
chrome-original.png (54275 colors) — FX-4100 @ 3.6 Ghz - 8 Go RAM - Windows 7 64-bit
-pngfilter=100 (0.19s) -pngcolor=100 (0.22s)
65226 colors 35780 colors
0.00003022 0.00002244
1.075092 0.808836
-s0: 173 185 bytes -s0: 178 095 bytes
-s8: 169 559 bytes -s8: 168 829 bytes
pingo -pngfilter vs -pngcolor
original.png (6481 colors) — FX-4100 @ 3.6 Ghz - 8 Go RAM - Windows 7 64-bit
-pngfilter=80 (0.16s) -pngcolor=80 (0.19s)
22710 colors 2533 colors
0.00013061 0.00011965
1.499836 1.318377
-s0: 93 950 bytes -s0: 90 563 bytes
-s8: 90 373 bytes -s8: 77 585 bytes

about the compression, this is not really surprising: even the default does well on lossy filter since data is transformed for the filter. however, it should be possible to have more difference if you use -pngcolor. the default (-s0) have speed limitations whereas brute trials in (-s8) could do significant savings

comment this