Quick review on pik fast mode

[khavish]

The latest version of pik seems to offer both better and faster compression.Note: This is nothing scientific but rather just a quick test.

Old pik

time cpik bench.png bench_1.0_old.pik
Compressing with maximum Butteraugli distance 1.000000
Compressed to 115793 bytes


real    1m0.421s
user    0m58.672s
sys     0m1.738s

time cpik bench.png bench_1.0_old.pik --fast
Compressing with fast mode
Compressed to 125221 bytes


real    0m0.158s
user    0m0.135s
sys     0m0.022s

Latest pik (with SIMD + updated butteraugli)

time cpik bench.png bench_1.0_new.pik --fast
Compressing with fast mode
Compressed to 126405 bytes


real    0m0.178s
user    0m0.139s
sys     0m0.023s

time cpik bench.png bench_1.0_new.pik
Compressing with maximum Butteraugli distance 1.000000
Compressed to 107785 bytes


real    0m37.641s
user    0m36.794s
sys     0m0.840s

Libjpeg compresion speed

time jpeg -q 90 -oz -h -qt 3 -qv bench.ppm bench_jpeg_90.jpg
jpeg Copyright (C) 2012-2014 Thomas Richter, University of Stuttgart
and Accusoft

This program comes with ABSOLUTELY NO WARRANTY; for details see 
README.license.gpl
This is free software, and you are welcome to redistribute it
under certain conditions, see again README.license.gpl for details.


0 bytes memory not yet released.

4038577 bytes maximal required.

542 allocations performed.

real    0m0.234s
user    0m0.227s
sys     0m0.007s

It seems that pik fast mode is faster than LibJPEG. Ofcourse we lose some compression here(~8%) with respect to pik default mode(--distance 1.0) .In my view the fast mode makes pik usable in a production setting , where the fast mode can be used first to serve the user the image asap and then the original image can be placed in a queue to be optimized by pik 1.0 later , thus gaining the 8% extra compression without compromising on user experience.