JyrkiAlakuijala

29 ms·

361.
by JyrkiAlakuijala 10y ago
In my benchmarks brotli compresses more densely, compresses typically faster to a given density, but decompresses slower. I benchmark with internet-like loads, not with 50-1000 MB compression research corpora.
362.
by JyrkiAlakuijala 10y ago
> https://news.ycombinator.com/item?id=12003131 This is some sort of misunderstanding. If one replaces the static dictionary with zeros, one can easily benchmark brotli without the static dictionary. If one actually benc
363.
by JyrkiAlakuijala 10y ago
There is no Thai or Korean in the dict. The total size of the dict (including all languages) is 120 kB.
364.
by JyrkiAlakuijala 10y ago
It is interesting that Japanese, Russian and Thai benenefit more (30 %) from brotli, than latin languages (25 %). This is because of the utf-8 context modeling in brotli.
365.
by JyrkiAlakuijala 10y ago
Guetzli runs the whole image to the same specified quality -- when artefacts start to emerge, they are everywhere, not just in one sensitive area. Guetzli can be more likely worth its cpu cost at a higher quality, around 92-96.
366.
by JyrkiAlakuijala 10y ago
Quality-wise, Guetzli is applicable to about 50% of the JPEG images in the internet. The other half is stored with lower than 85 quality, and Guetzli declines to attempt to compress to that quality. Another limitation is that Guetzli runs v
367.
by JyrkiAlakuijala 10y ago
There was a large variety of regularization and optimization techniques used. An embarrassingly large amount of manual work went into both. In this use the gamma is the inverse of something close to 2.6. Butteraugli needs both gamma correct
368.
by JyrkiAlakuijala 10y ago
It is old school: 100000+ cpu hours of Nelder-Mead method (+common tricks) to match butteraugli to a set of 4000 human rated image pairs created with an earlier version of Guetzli and specially-built image distortion algorithms.
369.
by JyrkiAlakuijala 10y ago
Thank you for giving such a present for all of us! JPEG was in my opinion really ahead of its time, is still impressive, and many of the engineering compromises between simplicity and efficiency are just brilliant.
370.
by JyrkiAlakuijala 10y ago
When we pack guetzlified JPEGs we see slightly smaller wins than with stock JPEGs. Think -14% for guetzlified JPEGs vs. -20% libjpeg JPEGs.
371.
by JyrkiAlakuijala 10y ago
This comes through the internal use of butteraugli -- and depending the quantization decisions on butteraugli. Butteraugli uses a 8x8 FFT, but computes this every 3x3 pixel creating coverage at block boundaries. In later stages of butteraug
372.
by JyrkiAlakuijala 10y ago
I'm afraid Guetzli is quite a lot more complex. It does a global search on this, i.e., quantization decisions in neighboring blocks may impact the quantization decisions on this block. Also, quantization decisions have cross-channel im
373.
by JyrkiAlakuijala 10y ago
Guetzli sacrifices some chromaticity information, but tries to keep that in balance with the intensity loss. Guetzli sacrifices colors much less than the commonly used YUV420 mode -- the common default mode in JPEG encoding.
374.
by JyrkiAlakuijala 10y ago
Three main methods: 1) YUV420 vs YUV444. Guetzli practically always goes for YUV444. 2) Choosing quantization matrices. 3) After normal quantization, choose even more zeros. JPEG encodes zeros very efficiently. When doing the above, increas
375.
by JyrkiAlakuijala 10y ago
Results with geo.protodata (118588 bytes uncompressed) from snappy test data: 11728 bytes - brotli 11 11941 bytes - brotli 10 12056 bytes - lzma 12219 bytes - zstd 22 12314 bytes - brotli 9 12512 bytes - brotli 5 12526 bytes - zstd 15 12809
376.
by JyrkiAlakuijala 10y ago
For every gzip setting, it should be possible to find a brotli setting that is both faster and more dense than your chosen gzip setting, i.e., better in every major aspect: computational resource cost, latency in computation and user observ
377.
by JyrkiAlakuijala 10y ago
> Why you don't disclose the compression time of brotli ? I left it out because zstd didn't produce comparable output size. I showed the compression and decompression speed at brotli at quality 7 that already compressed more de
378.
by JyrkiAlakuijala 10y ago
If you read your own results with care you will notice that your results also show that fastest brotli is faster than fastest zstd. Your results also show that brotli compresses more than zstd at higher settings, even if you turn off the st
379.
by JyrkiAlakuijala 10y ago
TurboBench didn't compile straigth after git clone. lzbench did: I get a test file by: wget https://web.archive.org/web/20151222062543/http://www.micros... The test file is 267253 bytes. $ ./lz
380.
by JyrkiAlakuijala 10y ago
Brotli's fastest compression is slightly faster than zstd's. Zstd decompresses faster, but neither is slow. Zstd can use sliding window size longer than 16 MB, in brotli this is limited to 16 MB to have guarantees of the maximum r
381.
by JyrkiAlakuijala 10y ago
About 25 % of compression improvements for short files (such as web pages) come from the static dictionary. The rest are format improvements. The relatively small static dictionary does not improve the compression of long files.
382.
by JyrkiAlakuijala 10y ago
https://groups.google.com/a/webmproject.org/forum/#!topic/we... WebP lossless is a more efficient solution, processing pixels instead of bytes.