(I only skimmed the article so this may just be wrong but I imagine this is what they’ve done)
One step of JPEG compression requires you to losslessly compress some bits, and the spec lets you choose between Huffman coding and arithmetic coding. Huffman is fast but doesn’t compress very well, AC is slow but compresses very well. (for some rough datapoints: gzip/zlib uses Huffman, 7zip uses AC)
Sort of, based on my (not an expert at all in image coding) reading, they use a lossless arithmetic encoding that just uses less bits. And they can round trip between both a huffman version and the lepton version so effectively there is no difference outside of storage.
[Comment removed by author]
(I only skimmed the article so this may just be wrong but I imagine this is what they’ve done)
One step of JPEG compression requires you to losslessly compress some bits, and the spec lets you choose between Huffman coding and arithmetic coding. Huffman is fast but doesn’t compress very well, AC is slow but compresses very well. (for some rough datapoints: gzip/zlib uses Huffman, 7zip uses AC)
At the time IBM patented the shit out of arithmetic coding, so nobody bothered supporting it in their JPEG encoders. Today, no web browsers can display JPEG images that use AC because advertisers haven’t asked for it, so people still don’t bother implementing it.
It looks like the Dropbox devs have built tools to go from Huffman to AC and vice-versa, along with a few other tricks.
Sort of, based on my (not an expert at all in image coding) reading, they use a lossless arithmetic encoding that just uses less bits. And they can round trip between both a huffman version and the lepton version so effectively there is no difference outside of storage.
yet another case of patents holding back progress by decades?