Reading through author's float compression series, I can't unnotice that in this post plot axis got switched - and it is a lot... easier? more elegant? to have speed on the vertical somehow
That you can chain one compressor with a second reminds me of the QOI (a png-competitor) whose output is often competitive with png (which uses gzip) _before_ it's output gets compressed with something as mundane as zstd or gzip.
My understanding is that chaining compressors is a classic technique for image compression. IIRC PNG and Basis are both implemented as initial transformation/pre-filtering/conditioning pass(es) designed to make the image data more compressible before feeding it to a codec like gzip or zstd.
This definitely works for things that aren't images too. I previously proved that you could improve the compression ratio for WebAssembly significantly by performing lossless transforms on the module before feeding it to gzip or brotli (though the gains are much smaller for brotli since it's so good to begin with): https://github.com/WebAssembly/design/issues/1180
Mesh optimizer's performance here is a nice reminder: the state of the art in general purpose compression is hard to beat, but special purpose still has room for improvement.
Reading through author's float compression series, I can't unnotice that in this post plot axis got switched - and it is a lot... easier? more elegant? to have speed on the vertical somehow
at least for me
That you can chain one compressor with a second reminds me of the QOI (a png-competitor) whose output is often competitive with png (which uses gzip) _before_ it's output gets compressed with something as mundane as zstd or gzip.
My understanding is that chaining compressors is a classic technique for image compression. IIRC PNG and Basis are both implemented as initial transformation/pre-filtering/conditioning pass(es) designed to make the image data more compressible before feeding it to a codec like gzip or zstd.
This definitely works for things that aren't images too. I previously proved that you could improve the compression ratio for WebAssembly significantly by performing lossless transforms on the module before feeding it to gzip or brotli (though the gains are much smaller for brotli since it's so good to begin with): https://github.com/WebAssembly/design/issues/1180
Vidvox HAP and Resolume DXV codecs also have a fast lossless compression stage
Mesh optimizer's performance here is a nice reminder: the state of the art in general purpose compression is hard to beat, but special purpose still has room for improvement.