Re: [whatwg] Arithmetic coded JPEGs

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.vrublevsky@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

singer@mac.com



David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 6 December 2016 19:26:47 UTC