WebP support

Bibs said on 02/13/2018

Hello cédric,

I would like to know if you plan to include WebP in pingo?

cédric (dev) said on 02/14/2018

no, this is out of the scope

Bibs said on 02/15/2018

Why? Both WebP's lossless and lossy are much better than PNG and JPEG. It could be nice to include pingo :

Lossless : https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study
Lossy : https://developers.google.com/speed/webp/docs/webp_study

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

Lossless : https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study
Lossy : https://developers.google.com/speed/webp/docs/webp_study

i think a careful selection of tools/samples/settings could show something more fair. anyway if you still want WebP, i suggest you use their tools

Bibs said on 02/15/2018

I don't see what's unfair. I run my own tests and WebP is always better than PNG. It's time to leave PNG and JPEG for a new format. Please re-consider WebP.

cédric (dev) said on 02/19/2018

WebP is always better than PNG

PNG is 20 years, WebP is expected to be *better*. it would be naive of me to believe that PNG could beat it. however, here is some counterexamples on default/max WebP compression (machine: G1820 @ 2.7 Ghz — 2 Go RAM — Windows 7 32-bit — 0.6.1 binary)

the lossless default

:: cwebp (0.6.1)
cwebp -lossless in.png -o out.webp
cwebp -lossless -q 100 in.png -o out.webp
original file: tweetnf.png (41 949 bytes)
cwebp 0.6.1 (default) cwebp 0.6.1 -q 100 pingo 0.95 -s0
31 466 31 334 21 271
0.127s 0.823s 0.121s
original file: flower.png (517 448 bytes)
cwebp 0.6.1 (default) cwebp 0.6.1 -q 100 pingo 0.95 -s0
478 106 476 710 397 147
1.358s 2.406s 0.914s
original file: box.png (31 094 bytes)
cwebp 0.6.1 (default) cwebp 0.6.1 -q 100 pingo 0.95 -s0
19 410 19 414 17 510
0.031s 0.052s 0.084s
original file: server.png (60 186 bytes)
cwebp 0.6.1 (default) cwebp 0.6.1 -q 100 pingo 0.95 -s0
43 706 43 606 38 552
0.080s 0.140s 0.182s
original file: books.png (90 796 bytes)
cwebp 0.6.1 (default) cwebp 0.6.1 -q 100 pingo 0.95 -s0
75 892 75 826 74 837
0.132s 0.198s 0.145s

if you use default lossless on those files, it seems that cwebp 0.6.1 is offering worse compression than fast PNG optimization — perhaps i missed something obvious here?

higher compression

:: cwebp (0.6.1)
cwebp -lossless -q 100 -m 6 in.png -o out.webp

:: zopflipng default (64c6f36)
zopflipng --lossy_transparent in.png out.png

:: zopflipng brute (64c6f36)
zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent in.png out.png

:: pingo (0.95)
pingo -s8 file.png
original file: tweet.png (71 850 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
53 706 53 464 52 032 40 186
2.897s 610.643s ! 0.562s 5.201s
original file: apple.png (258 636 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
212 374 209 449 205 995 148 714
10.795s 2343.451s ! 1.850s 7.232s
original file: tweetnf.png (41 949 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
21 135 21 111 20 541 15 568
2.102s 667.256s ! 0.386s 3.633s
original file: flower.png (517 448 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
394 580 394 179 393 759 290 282
21.496s 7460.730s ! 1.938s 7.671s
original file: box.png (31 094 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
20 658 20 641 17 055 18 820
0.920s 54.412s ! 0.132s 2.148s
original file: server.png (60 186 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
50 007 48 945 34 782 43 278
3.233s 588.195s ! 0.701s 4.978s
original file: books.png (90 796 bytes)
zopflipng (default) zopflipng (brute) pingo 0.95 -s8 cwebp 0.6.1 -q 100 -m 6
78 129 77 588 70 176 74 072
2.511s 630.053s ! 0.544s 3.448s

if you use highest compression settings, cwebp 0.6.1 should beat those PNG optimizers most of the time but definitely not *always*

lossy

original file: tweet.png (71 850 bytes) — palettization
cwebp 0.6.1 -q 100 cwebp 0.6.1 -q 100 -pre 4 pingo 0.95 -pngpalette
0.047s 0.064s 0.171s
0.00146015 0.00044603 0.00049206
8.066730 2.612889 2.320599
21 318 bytes 22 474 bytes 16 500 bytes

about the lossy, i see no mention to lossy PNG optimization. it could be competitive, especially if you use palettization

original file: apple.png (258 636 bytes) — lossy filtering
cwebp 0.6.1 -q 100 -m 6 pingo 0.95 -pngfilter=1 -s8
3.093s 1.510s
0.00032260 0.00167222
3.140802 3.012185
48 690 bytes 49 030 bytes

on this sample, the lossy filter creates dissimilarity with the original file but should look better than palettization while providing more compressible data

imo

WebP could be probably *much better* than PNG by speed, size and quality on most of samples (also, you could combine palettization and WebP lossless). the great thing about it is that it can be used on (almost) any kind of images including animations (even if FLIF claims to do this better), so it is good for lazy users

but 7 years after the first release, who use WebP? perhaps the reason is that PNG is much better supported since years, and is just good enought even if WebP beats it technically. for JPG, try MozJPEG and according to your settings (4:4:4, q.table) — or use Guetzli — some samples above quality 80 could be close/better in JPG

why out of pingo's scope

  • barely used on Web
  • it should require changes for pingo since it does not use libpng
  • i should not add something more than the current WebP encoder *

* to be honest, i did not check this seriously, but perhaps it should benefit from multiprocessing. i would change default in both lossless/lossy modes, but nothing that can be done with a simple script/tool/GUI

comment this