Arithmetic coded JPEG support

[vrubleg]

Arithmetic coding is a part of the JPEG standard. Initially, it wasn't implemented by encoders and decoders due patents. But now there is no such limitation, all patents are expired several years ago. libjpeg supports arithmetic coding since version 7.x (2009), libjpeg-turbo and mozjpeg also support arithmetic coding. It significantly improves compression ratio.

Currently, Chromium doesn't support it. There is a ticket about it, so it may be changed in the future. You can star the ticket to support it if you think that arithmetic coded JPEG support is a good idea.

[robryk]

We aim to produce images that will not surprisingly not display on some browsers, when a JPEG produced by more "conventional" tools would. This sadly rules out arithmetically coded JPEGs: many browsers handle them poorly or not at all and even if the situation improves, there'll be a lot of legacy browsers remaining for years to come.

[magicgoose]

there'll be a lot of legacy browsers remaining for years to come.

They too won't stay forever though. Also it's possible to test support in browser (through some headers like accept-encoding, or just trying to decompress a small test image) and use them conditionally. If nobody does anything to make it happen, it won't happen. I think it would be better if there's at least an option to make AC'd jpegs (marked as experimental, etc).

Also, do not forget that it's possible to losslessly transform from AC'd jpeg to plain jpeg and vice versa, so even if somebody accidentally converts their jpeg file to AC'd form and suddenly their buddy can't open it, that's no problem, they can always convert it back with no loss. In other words, unlike introducing some completely new lossy formats like WebP, this optimization is non-destructive.

Updating decoder software is not that hard too, because AFAIK it's mostly a matter of upgrading libjpeg in system and/or recompiling with updated libjpeg.

[robryk]

The effort required to support arithmetically encoded JPEGs in a browser seems to be of the same sort of magnitude as effort required to get something like Lepton supported. Lepton would give significantly larger gains than arithmetically encoded JPEGs (e.g. due to its exploitation of cross-block correlations). Additionally, there's no separate MIME type for different versions of JPEG, which makes any capability discovery very hard.

We think that, if we are to do something that requires all the effort on the compatibility and fallbacks front, we should rather invest it in something that would give us a bigger advantage than arithmetically coded JPEG.

Personally, I'd be curious to see how Guetzli would perform if it were to create AC JPEGs, use their size for feedback in its optimization loop, and have relevant parts of it tuned for them. Unfortunately, I don't have time to work on that. I encourage you to fork Guetzli and do that, if you are so inclined.

[andrius4669]

can always use jpegtran --arithmetic to losslessly recompress with arithmetic coding