From the MC guestbook...

Quote Originally Posted by Matt Mahoney
I have fixed the bug in the JPEG model in paq8fthis, but instead of putting it back in paq8f, I put it in the latest version, paq8l, and called the new version paq8m. It is here:

http://cs.fit.edu/~mmahoney/compression/

paq8m is identical to paq8l in compression for non JPEG data. paq8fthis crashed because of a division by zero when fed malformed JPEG data, such as the image fragments in Thumbs.db. Some benchmarks are below. Unfortunately the JPEG compression is not always as good in paq8l as it was in paq8f even though it is the same model. Im not sure why. Compression times are on a 2.2 GHz Athlon-64 with 2 GB, 32 bit WinXP. I used option -6 for all tests.

842,468 a10.jpg
698,214 a10.jpg.paq8f 19 sec
667,190 a10.jpg.paq8fthis 47
667,722 a10.jpg.paq8l 22
674,995 a10.jpg.paq8m 36

4,168,192 ohs.doc
553,493 ohs.doc.paq8f 105 sec
524,926 ohs.doc.paq8fthis 217
547,082 ohs.doc.paq8l 171
518,694 ohs.doc.paq8m 228

The JPEG model by Jan Ondrus uses DCT/IDCT to compute pixel values in adjacent blocks to provide extra context, but this is CPU intensive. I did some simple optimization on this code (moving stuff out of inner loops). I could do more because not all of the computed values are needed, but it is late and I wanted to get the fix released.

paq8m will report warnings if the JPEG is malformed, but these are harmless. It will drop back to a non-JPEG model so the compression will still be correct.
Mirror: Download