Little something I've been working on. To my knowledge this is the only(?) compression codec using Hopf-fibration quotient coding in any way.
It's lossy, guarantees fixed rate compression on any input, zero codebook (same as other vector quantizers), provable exact O(1) random access, and ships a fully deterministic compile-time provable format. Beats int-N quantization cleanly in all metrics, haven't directly compared it to data-adaptive methods yet, but since they lie on a completely different functionality axis felt like there was no need.
Had this idea for quite a while now, but never had the time to implement it fully. The math was described in part by Constructive Spherical Codes by Hopf Foliations (https://arxiv.org/abs/2008.10728, so if you're interested in a deeper overview I implore you to read that paper. One nitpick is that the paper as written is technically unimplementable (tables explode to multi GB entries rapidly + their encoder/decoder pairs are asymmetric, eq (34) is provably wrong etc).
Performance is relatively decent; obviously you can determine the compression ratio by tweaking dims and the granularity level, so it's a one size fits all kinda codec. The biggest advantage is that you can avoid using a learned codebook entirely, so for offline/embedded environment's this works great.
rfgplk•21m ago
It's lossy, guarantees fixed rate compression on any input, zero codebook (same as other vector quantizers), provable exact O(1) random access, and ships a fully deterministic compile-time provable format. Beats int-N quantization cleanly in all metrics, haven't directly compared it to data-adaptive methods yet, but since they lie on a completely different functionality axis felt like there was no need.
Had this idea for quite a while now, but never had the time to implement it fully. The math was described in part by Constructive Spherical Codes by Hopf Foliations (https://arxiv.org/abs/2008.10728, so if you're interested in a deeper overview I implore you to read that paper. One nitpick is that the paper as written is technically unimplementable (tables explode to multi GB entries rapidly + their encoder/decoder pairs are asymmetric, eq (34) is provably wrong etc).
Performance is relatively decent; obviously you can determine the compression ratio by tweaking dims and the granularity level, so it's a one size fits all kinda codec. The biggest advantage is that you can avoid using a learned codebook entirely, so for offline/embedded environment's this works great.