3 ms·
I agree that we should expect side by side examples to support the claims, but my first thought is that they're making an analysis of the JPEG compression and u
by ebiester 16y ago
I agree that we should expect side by side examples to support the claims, but my first thought is that they're making an analysis of the JPEG compression and using improvements on computing power to encode the information more efficiently. Consider that JPEG is using a (or more) Huffman table and a (or more) quantization table. (I'm getting this from wikipedia, IANA compression expert)
What if you analyzed all those images and came up with a composite huffman compression that was more efficient than the best guess in the 70s? Then, you did some magic on the quantization table to make the most common vales correspond to the lowest numbers, relying on processing power to decode the compressed quantization table before you started?
- jodrellblank 16y agoI note that WinZip 14 does decode JPGs and reencode them smaller, but without further loss of quality: "The main trick those three programs use is (partially) decode the image back to the DCT coefficients and recompress them with a much better algorithm then default Huffman coding." - http://www.maximumcompression.com/data/jpg.php http://www.maximumcompression.com/data/jpg.php
- Lerc 16y agoMost lossy image compression systems use a transform that does not reduce the data size but makes transformed data that is more compressible. This means the final layer of compression is a traditional compressor. These, like the transforms themselves get improved upon over time. JPEG is old. When I did some experiments with various compression techniques, I found that DCT with a LZMA base compared quite well to newer compression systems.
- astrange 16y agoWhy bother wasting time analyzing Huffman tables when you own a video codec? JPEG is mostly an MPEG-1 keyframe. WebP is exactly a VP8 keyframe. VP8 is better than MPEG1, so there's no need to change anything when you can just use that decoder. Although there are many inefficiencies left in VP8, and to a lesser extent H.264, when dealing with very large images. One is that the same texture can be repeated in different areas of the same image, but prediction only happens from neighboring pixels, so it can't reuse the same texture in compression. Some solutions are in the JVTVC/H.265 proposals and are usually called "extended texture prediction".