Re:OxiPNG: PNG optimizer written in Rust
by userbinator on Thursday September 07, 2017 @11:31PM
(#15197714)
It would be more useful if you didn't round the sizes to "12M", because I have a hard time believing they were all exactly the same. Bytes are a discrete and exact quantity, and ideally would be displayed to full precision to allow useful comparison.
Re:OxiPNG: PNG optimizer written in Rust
by dikaiosune on Friday September 08, 2017 @12:49PM
(#15201809)
It would probably be more useful, yes. But that would require remembering what my ls alias without `-h` is, and also would maybe give more confidence in the results of the quick 'n' dirty analysis than is justified.
Re:OxiPNG: PNG optimizer written in Rust
by 62747478182 on Friday September 08, 2017 @10:08PM
(#15205201)
You can type `/bin/ls -l` to skip your shell aliases.
Re:OxiPNG: PNG optimizer written in Rust
by vladdanilov on Friday September 08, 2017 @04:38AM
(#15198742)
Comparing supposedly the best results.
oxipng optipng optimage
size 12 231 612B 12 231 612B 11 027 901B
time 23.82s 90.57s 50.8s
I keep on improving my single-threaded image compressor (http://getoptimage.com).Is that optimage result for lossless or lossy mode?
Re:OxiPNG: PNG optimizer written in Rust
by vladdanilov on Friday September 08, 2017 @08:04AM
(#15199563)
Lossless in this case.
With that file size, I'm guessing you're using a big picture without transparency and with many colors, which is the opposite of the usual use case of optimizing PNGs.
Re:OxiPNG: PNG optimizer written in Rust
by dikaiosune on Friday September 08, 2017 @12:51PM
(#15201820)
With significantly smaller file sizes, it could be more challenging to see timing differences. Also, this image is one that someone used the last time OxiPNG was discussed, which seemed relevant to me.
Note in that thread that the author implies that the optimization levels between the two tools are not necessarily equivalent or stable.
Ran on a 2016 MBP, i7.Time:
Size of resulting image: TBH I don't really know how to interpret these results. But with the strange exception of `oxipng -o 2`, it does seem like the naive parallelism offers some real performance wins. Disclaimer: this is an incredibly amateur attempt to benchmark, I really don't have enough knowledge to produce something authoritative.