W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2016

Re: [whatwg] Arithmetic coded JPEGs

From: David Singer <singer@apple.com>
Date: Tue, 06 Dec 2016 11:26:15 -0800
To: whatwg@whatwg.org
Message-id: <3F6D67E8-8982-4DB0-BFAF-7D41FD58EC08@apple.com>
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


David Singer
Manager, Software Standards, Apple Inc.
Received on Tuesday, 6 December 2016 19:26:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:40 UTC