
Mozilla Advances JPEG Encoding with Mozjpeg 2.0 - dochtman
https://blog.mozilla.org/research/2014/07/15/mozilla-advances-jpeg-encoding-with-mozjpeg-2-0/
======
joedrew
(Note: I used to be employed by Mozilla, and in that capacity I was the owner
of Mozilla's image decoders. I've been disconnected from all decisions for
almost a year, though.)

The main take-home here is that while Google's numbers all show WebP as being
objectively better, the metrics they chose for comparison were relatively bad
(i.e., some of them didn't take into account colour or didn't model colour
correctly), and once you accounted for that the numbers were not nearly as
good a story for WebP; in some cases, JPEG outperformed it.

The facts that (1) WebP was not terribly compelling technically, (2) JPEG is
already supported by everything on the web, not to mention devices and mobile
phones etc, and (3) there's still headroom to improve JPEG in a backwards-
compatible way, meant that WebP was (and, it seems, remains) a non-starter.

~~~
cromwellian
But is there headroom for JPEG to replace animated gifs? If I look at mobile
social apps these days, animated GIFs eat up enormous amounts of data. JPEG
doesn't seem to have an answer for this, and no one has yet, it appears, made
the <video> element work for this use case.

~~~
mbell
> no one has yet, it appears, made the <video> element work for this use case.

Gfycat seems to be getting more and more popular or at least I'm personally
starting to see a lot more of their links in place of imgur gif links.

[http://www.gfycat.com/](http://www.gfycat.com/)

~~~
dublinben
There's also a similar site[0] which is open source, so you could deploy it
yourself if you wanted to.

[0][https://mediacru.sh/](https://mediacru.sh/)

~~~
mbell
I looked over mediacru.sh and unless I'm missing something it doesn't serve
the same purpose as gfycat. The point of gfycat is to upload a gif, it
converts it to webm then it gives you a bit of embed code that will try to use
the webm variant but will fall back to the gif when unsupported. I didn't see
anything in mediacru.sh's code that would allow gif <-> video conversion, I
tried uploading a few gifs on their site as well and didn't get any video
options back from the API.

~~~
dbcooper
Mediacru.sh should give you a "view as html 5" option. It did for me when I
uploaded a gif a few minutes ago.

------
Daemon404
It should be noted, since it is nowhere to be seen in this post, it breaks API
and ABI while still presenting itself as libjpeg version 6 to the system,
which is _very_ evil.

Open Issues:

[https://github.com/mozilla/mozjpeg/issues/67](https://github.com/mozilla/mozjpeg/issues/67)
[https://github.com/mozilla/mozjpeg/issues/21](https://github.com/mozilla/mozjpeg/issues/21)

------
xvilka
It is sad that Mozilla wont implement WebP format in addition to GIF/APNG due
to political reasons (I see no valid technical reasons to not include this
code, especially after the news about including code for DRM). They've even
disabled comments in the WebP bug [1]. And this bug was already second,
they've closed first one [2]. You still can write your comments in this bug
(about APNG removal) - it is not closed yet [3]

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=856375](https://bugzilla.mozilla.org/show_bug.cgi?id=856375)

[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=600919](https://bugzilla.mozilla.org/show_bug.cgi?id=600919)

[3]
[https://bugzilla.mozilla.org/show_bug.cgi?id=935466](https://bugzilla.mozilla.org/show_bug.cgi?id=935466)

~~~
thristian
Did you not read the section in the linked article about how WebP is not
measurably better than JPEG?

~~~
xvilka
I've read it. Yep, looks like they can be compared for the static images. But
what about animation? And there are plenty of websites using webp already. It
is not like JPEG or WebP - why not just support them both!? (or APNG and
WebP).

~~~
kevingadd
I imagine there's some amount of frustration on the part of people being told
they should spend time implementing WebP, when APNG was a real working
alternative circa ~2004 and nobody else was willing to implement it.
(Admittedly, WebP does things APNG isn't capable of.)

Reminds me of MNG, where we had an animation format with support for alpha and
either PNG or JPEG style compression of frames, but it never got a pervasive
browser implementation so it died. (I get the impression there were strong
technical reasons for that, of course.)

Coincidentally, MNG also indirectly solved this problem. JNG was a subset-
format of MNG that provided JPEG-compressed static images with optional
support for alpha, so implementing MNG implied implementing JNG. But we never
got it on the web.

At the very least, instead of just saying 'WebP is bad', they're putting their
money where their mouth is and advancing the state-of-the-art in JPEG encoding
so that people won't need WebP (other than the alpha channel use case, that
is.)

------
notlisted
How does this MozJPEG 2.0 encoding compare to JPEGMini? I've been using
JPEGMini for all client projects, it results in optimized JPEGs that work on
all platforms with minute differences, rarely visible to the naked eye, only
when I subtract pre/post in Photoshop. Very rarely does it save less than 5%
and for larger images (saved with PhotoShop, save for web) often 15-30% or
even more.

Is the test set of images available?

~~~
muizelaar
jpegmini works by compressing an image as much as possible while keeping the
distortion calculated by there particular metric below a threshold. To compare
against mozjpeg you'd need to compress a bunch of images with JPEGMini and
then compress those images with mozjpeg so that they were the same size. You
could then compare the quality of the resulting images.

The test set of images is here:
[https://github.com/bdaehlie/web_image_formats/tree/master/im...](https://github.com/bdaehlie/web_image_formats/tree/master/images)

If you're interested,
[https://github.com/dwbuiten/smallfry](https://github.com/dwbuiten/smallfry)
is program similar to JPEGMini that uses mozjpeg as its backend.

~~~
ZeroGravitas
How much extra saving does JPEGMini or smallfry offer over a sanely but
conservatively encoded JPEG?

------
RDeckard
This is all fine and dandy, but whatever happened to JPEG-2000 and wavelet-
based compression? Still licensing/patent issues blocking wide adoption?

~~~
acdha
It's still competitive performanc-wise but adoption has been lacking. Patents
were an issue but there were other problems, too: uncertainty about rights and
the high complexity of the spec (which for awhile was, IIRC, $1500 simply to
get a copy) meant that there wasn't much traction in the open-source world,
which in turn meant that many image processing apps either didn't support it
at all or used a slow library with limited compatibility and incomplete spec
support. There are several commercial libraries available but they also had
compatibility issues (largely resolved by now) and required negotiating
licenses.

Mike Shaver had a good comment in the Mozilla feature-request ticket which is
no doubt representative of many other projects' concerns:

[https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120](https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120)

None of this is insurmountable, of course, but it made a lot of people
hesitant to invest heavily in it. I wrote about the long-term risks awhile
ago:

[http://blogs.loc.gov/digitalpreservation/2013/01/is-
jpeg-200...](http://blogs.loc.gov/digitalpreservation/2013/01/is-
jpeg-2000-a-preservation-risk/)

The situation is getting better – OpenJPEG is now actively developed (see
[http://www.openjpeg.org](http://www.openjpeg.org)), supports many of the more
valuable features (e.g. tiled decoding so you can avoid decoding an entire
large image to extract a fragment), and is becoming an official reference
implementation:

[http://comments.gmane.org/gmane.comp.graphics.openjpeg/773](http://comments.gmane.org/gmane.comp.graphics.openjpeg/773)

Recently ImageMagick and Pillow (the maintained fork of the Python Imaging
Library) added support for JPEG-2000 using OpenJPEG and the same trend seems
to be happening in other places. The big remaining challenge is browser
support for non-Apple browsers but that's now possible, if somewhat grotesque,
using Emscripten on OpenJPEG to render into a canvas tag.

------
1ris
It's very sad Mozilla does not even mention their own codec, Daala, and only
compares to HEVC etc. I suspect it's severely lacks funding.

~~~
joshmoz
Daala development is proceeding at a rapid pace. We're just not ready to bring
Daala into this conversation quite yet.

------
paulsmith
Not sure how fair a comparison it is but FWIW I built it and ran it (./cjpeg)
over a few photos and got ~18% savings in file size vs. imagemagick convert at
quality=50%

------
panzi
5%? I don't know but I hoped for significantly more.

------
pdknsk
IMO the linked study is pretty much useless, because of enforced 4:2:0 chroma
subsampling. I guess this is because some of the newer codecs were originally
video codecs where 4:2:0 is standard, but for still images I expect much
better. Photoshop, which is obviously widely used on the desktop to make
JPEGs, only uses 4:2:0 for quality <= 50 by default.

This also makes me question the use of metrics to measure image quality.

~~~
kevingadd
I don't think it would make sense to compare some codecs at 4:2:0 and some at
4:4:4. Unless they can all do 4:4:4, you have to pick a subsampling that they
can all do and compare them at that so it's like-for-like.

If your goal is to demonstrate 'JPEG can deliver better quality than this
format by using 4:4:4, because that format can't do 4:4:4', then that's great,
but it's a different observation than the one they're trying to make. (Also, I
would be pretty curious about whether the different subsampling produces
superior file sizes.)

------
vlucas
Facebook's $60,000 donation is interesting. The article says that the average
file size reduction was 5%. Given that Facebook has built datacenters capable
of storing exabytes of photo data in "cold storage", I wonder how much money
Mozilla just saved Facebook in storage space costs in relation to how much
they donated.

~~~
spacefight
It would be interesting to learn what the cost of CPU overhead vs. additonal
cost of 5% cold storage is - but I bet the FB folks did that calculation.

------
skrowl
Seems to be source only. Has anyone built win64 binaries for this that they'd
like to share.

~~~
jibsen
On that subject; say what you want about how clunky CMake is, but it's really
nice to be able to build projects like this with VC++ or plain MinGW-w64.

------
NVI
Is there a command line tool available? I’d like to include it into my website
build process.

~~~
joshmoz
Yes, building the source will produce (among other things) a command line
application called "cjpeg", which can encode or re-encode.

------
bastawhiz
\- Alpha channel \- Animation \- Proper metadata \- File size

The list of things that WebP offers that JPEG, PNG, or GIF alone will never
address.

------
pekk
If Google had done this, people would be in here complaining it wasn't open
even though it was released under an open source license.

