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
> 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:
> 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
Manager, Software Standards, Apple Inc.