5 ms·

Somebody, make "image format powered by brotli", please.

• sanxiyn 10y ago
  I think zstd will be better: https://github.com/Cyan4973/zstd https://github.com/Cyan4973/zstd.
• niftich 10y ago
  Since most of Brotli's improvements over its ancestor LZ77 are due to its large, hardcoded, text-corpus dictionary [1], most of the algorithm's strengths would be wasted on binary data like images. Zopfli, from the same people, is a DEFLATE encoder, so it can be used in PNG [2] and this has already been added to some optimizers, e.g. AdvanceCOMP [3] [1] https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e [2] https://github.com/google/zopfli/commit/337d27f25ef15a6cf34fef2acd0613fddc411cb1 https://github.com/google/zopfli/commit/337d27f25ef15a6cf34f... [3] http://www.advancemame.it/doc-advpng.html http://www.advancemame.it/doc-advpng.html
  • 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.
  • est 10y ago
    First time saw the Brotli dictionary. It has duplicates. Line 3131 and 8704 both are "操作"
    • niftich 10y ago
      Interestingly, there are also 121 different transformations [1] you can apply to each dictionary word, from adding various prefixes and suffixes, trimming letters, and some more complex ones [2]. If the plain-text dictionary linked earlier [3] is accurate, it'd appear that the dictionary contains a lot of redundant forms. [1] https://tools.ietf.org/html/draft-alakuijala-brotli-11#page-27 https://tools.ietf.org/html/draft-alakuijala-brotli-11#page-... [2] https://tools.ietf.org/html/draft-alakuijala-brotli-11#appendix-B https://tools.ietf.org/html/draft-alakuijala-brotli-11#appen... [3] https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e
• JyrkiAlakuijala 10y ago
  https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/ic00NLoJH24 https://groups.google.com/a/webmproject.org/forum/#!topic/we... WebP lossless is a more efficient solution, processing pixels instead of bytes.
• lifthrasiir 10y ago
  Brotli is not as good as an image compression algorithm because it is strongly tuned to the "typical" workload for Web (have you looked at the preset dictionary? :-), not images. I would instead suggest FLIF [1], which roughly consists of an image-specific context model, adaptive entropy coding and general interlacing (that makes any sufficiently long prefix of the file a valid approximation to the original image). Still in development, but seems very promising. [1] http://flif.info/ http://flif.info/
  • Dzugaru 10y ago
    Interesting, would like to see comparison with FFV1. Arithmetic coding beats Huffman all day every day, and pixel-aware predictors are a thing.
    • eln1 10y ago
      Arithmetic coding is very expensive - zstd uses new entropy coding with compression ratio like arithmetic coding, but with Huffman-like speed: https://github.com/Cyan4973/zstd https://github.com/Cyan4973/zstd https://github.com/Cyan4973/FiniteStateEntropy https://github.com/Cyan4973/FiniteStateEntropy http://encode.ru/threads/2078-List-of-Asymmetric-Numeral-Systems-implementations http://encode.ru/threads/2078-List-of-Asymmetric-Numeral-Sys...
• sp332 10y ago
  It seems you could just use PNG, but swap out the deflate step with Brotli.