JPEG arithmetic coding

Log-in or register.

JPEG arithmetic coding

Published by on December 2nd 2014.

The first specification of the JPEG image format was published more than 20 years ago and it obviously was a great success. Even after so many years, most digital cameras still produce .jpg images and a good portion of all images on the web are .jpg images. Now imagine if all .jpgs were about 10 percent smaller with exactly the same quality. Wouldn't that be nice?

There is thing called arithmetic coding, which can be used as a replacement for Huffman coding in the final step of JPEG compression. And it is more effective and the files using arithmetic coding are a bit smaller. Between 5% and 12% according to my tests.

So, 10% does not sound like much, but that means 10% more shots on your memory card, 10% more photos on that CD, 10% faster download speeds or 10% less paid for data transferred. The sad thing is that the JPEG standard had this option, but nobody dared to use it due to software patents and the previous disaster with GIFs.

This is a nice example of how software patents slow down the technological progress. This particular software patent cost us all a lot of money (sum those 10% up). And the issuers did not make money on it, because nobody chose to use it. Everyone went the safe, patent-less way. Loss-loss.

Arithmetic coding for RealWorld apps

Three years ago the patent expired and the standard JPEG library included the long abandoned option to use arithmetic coding to save that few percent of space. But it is too late now, as every piece of software would have to be updated to be compatible with the "new" JPEGs.

Let's have a look. Chrome does not support it, Firefox does not support it, Internet Explorer does not support it, Photoshop CS3 does not support it, Windows image viewer does not support it. Nobody uses it, nobody cares about extra 10% space saved.

Anyway, I care and RWPaint and RWPhotos were able to read JPEGs with arithmetic coding for about a year now. From the next version, you'll be able to save them as well. If you want to try it right now, grab this and replace the current codec in your installation folder. Then in the configuration, press the "Arithmetic coding" icon. If you want to make your own comparisons of how much space it can save you, be sure to save both with and without arithmetic coding at the same time to avoid possible re-saving loss.

Vlasta's blog RSS feed

Recent comments

user icon SYNTHCRѺ contributing user on December 5th 2014

That's interesting. I think it's great that you implement this into the rw software.

user icon Anonymous on December 6th 2014

http://filmicgames.com/archives/778
Dan Forever, on November 16th, 2011 at 5:46 am Said:
I find the Arithmetic jpeg works in Chrome, though perhaps it was updated between the time this blog post was written and my comment.
However, living in Europe I believe we don’t have software patents (though I’m not sure if that’s a per-country basis or EU specific)

https://bugzilla.mozilla.org/show_bug.cgi?id=680385

Akkana Peck 2014-11-01 12:07:12 PDT

Chromium here (on Debian sid) shows arithmetic coded images just fine. I think chrome/chromium uses the system library, so it probably varies by OS.

user icon Vlasta site administrator on December 6th 2014

Yes, it works on Linux via the system lib. On Windows, it does not work.

user icon The male boss registered user on January 14th 2015

thanks for some information
:-)

user icon cdl contributing user on March 5th 2015

Informative indeed.

icon-image/8311-16x16x32.png image icon-image/10305-32x32x32.png image

user icon j7n registered user on January 13th 2016

Arithmetic coding is SLOW! It is possible to read the time it took to load an image in IrfanView. Decompressing arithmetic takes about * 9 times * longer compared to Huffman using JPEG-Turbo, and 5 times longer using old JPEG. Other software can be expected to use either variant.

Computers are getting faster, but expectations for resolution and quality are also rising. It might not be possible to flick through hi-res scans without a noticeable delay with Arithmetic. The greatest compression ratio difference (13%) is found in large non-uniform images (where various parts would have different optimal huffman codes).

Small web-resolution images that you might download over paid traffic see only 6-7% improvement. And on the web, this difference is dwarfed by the typical bloat of css/javascript, and overhead from calling advertising/tracking bugs. We can also often encounter JPEG files with meaningless Exif/Xmp metadata automatically generated by Photoshop, which bloat their size. Compression isn't that important anymore.

During all those years when the patents were still in effect, it was definitely not a good idea to use arithmetic coding. ACDSee with its unique read-ahead and cache-behind features was even needed for normal files.

user icon Anonymous
Select background
Vista & Win 7 icons
What about ICL files?
I wish there were...