I think arithmetic coding is more problematic than you think, from a deployment and usage point of view.
Yes, it does save some bits, but alas minimum size is not what people optimize JPEG encoding for; they are much more interested in maximum compatibility. Much hardware support doesn’t include arithmetic coding, as far as I know, and even though libJPEG does, at least some users of that turn it off again. I think that’s partly because it’s quite a bit slower in libJPEG. So, one gains maybe 10-20% compression at the expense of compatibility and performance. Not a trade-off people want to take, I fear. sorry, practical realities bite again... > On Nov 30, 2016, at 6:34 , Evgeny Vrublevsky <evgeny.vrublev...@gmail.com> > wrote: > > Hello. > > I'm writing about arithmetic coded JPEG support. Historically, it wasn't > supported by browsers due patents. But all of these patents are expired > several years ago, and modern libjpeg, libjpeg-turbo and mozjpeg have > optional support of the arithmetic coding. > > Arithmetic coded JPEG support will allow us to recompress all existing > JPEGs losslessly, saving 10-20% of size. I've provided some examples here: > https://bugs.chromium.org/p/chromium/issues/detail?id=669501#c3 > > Similar ticket exists also in the Mozilla's Bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=680385#c17 . Now, I'm just > following this direction from the ticket: >> For now, the right place to go to move forward with this is on the > standards mailing lists, not in this bug. > > Unfortunately, browsers still don't support arithmetic JPEG officially. Is > this a right place to start a discussion if it is possible to change it? > > -- > Best regards, Evgeny Dave Singer sin...@mac.com David Singer Manager, Software Standards, Apple Inc.