13 ms·

Introducing the ‘mozjpeg’ Project

409 points by joshmoz 13y ago

kllrnohj 13y ago
So... version 1.0 is basically a shell script that calls libjpeg-turbo followed by jpgcrush?
- michaelmior 13y ago
  No, the jpegcrush functionality is implemented in C as an extension to libjpeg-turbo. But yes, I suppose a shell script would achieve roughly the same result.
  - kllrnohj 13y ago
    So why wasn't this upstreamed to libjpeg-turbo? Why fork at all? libjpeg-turbo is still an actively maintained project after all...
    - riquito 13y ago
      They want to do much more, and with a fork you don't have to justify and discuss every single commit with the original maintainer. If you want to modify heavily something, a fork is the right approach.
    - deleted 13y ago
      [deleted]
    - syntheticnature 13y ago
      Maintainer has different priorities, see https://news.ycombinator.com/item?id=7349117 https://news.ycombinator.com/item?id=7349117
- joshmoz 13y ago
  No shell script or second step involved. Functionality is built in and on by default. This is just a start, we wanted to have something people could use on day one. Further developments to come.
- briansmith 13y ago
  I believe this merge shows the C code that implements the crush functionality: https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d471650ec1f18bc727c9a36 https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d...
callesgg 13y ago
A bit to soon to start announcing the project. But I like the initiative hope the project manages to improve stuff.
- joshmoz 13y ago
  We would like to develop in the open, and hopefully with community participation.
  - brigade 13y ago
    BTW, please fix your lossy test methodology for when you do your tests on a future version of this. https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/ https://blog.mozilla.org/research/2013/10/17/studying-lossy-... was rather flawed and you never acknowledged this. (see https://news.ycombinator.com/item?id=6581827 https://news.ycombinator.com/item?id=6581827 - only one of the four sets of test results might have been valid)
- briansmith 13y ago
  Mozilla tends to announce projects when they begin so people can contribute to them right away. I think that's a good thing and that's one of the reasons I work for Mozilla. By the way, I think this is an awesome effort by Josh and the others working on this. I work mainly in security and networking, and I'm excited about anything we can do to make end-to-end communication more efficient because these kinds of improvements help enable more use of HTTPS and help reduce (hopefully eliminate) the need for content transforming proxies.
IvyMike 13y ago
JPEG has shown amazingly good staying power. I would have assumed "JPEG is woefully old and easy to beat" but Charles Bloom did a good series of blog posts looking at it, and my (non-expert and probably hopelessly naive) takeaway is that JPEG still holds its own for a 20+ year old format. http://cbloomrants.blogspot.com/2012/04/04-09-12-old-image-comparison-post.html http://cbloomrants.blogspot.com/2012/04/04-09-12-old-image-c...
- georgemcbay 13y ago
  (*)Charles Bloom.
  - IvyMike 13y ago
    Fixed.
- brigade 13y ago
  Do note that his "JPEG" is really JPEG with a PAQ entropy coder, which is actually a new format and not at all decodable by a JPEG decoder. He does no tests on baseline JPEG. But it's useful to point out that a lot of new overly complex formats can't beat something as simple as that.
- mistercow 13y ago
  In my opinion, the biggest drawback of JPEG is that its window is non-overlapping. Ring-artifacts are generally not a big deal for natural images at medium quality or higher, but blocking artifacts can be noticeable even at relatively high quality settings. There are a lot of post-processing techniques to try and mitigate this, but in my experience they tend to do about as much damage as they fix. The proper solution is to overlap the blocks using one of the myriad techniques DCT-based audio codecs use. It is bizarre to me that for all of the attempts to beat JPEG, nobody seems to have tried simply overlapping the blocks by 2 pixels. You'd have an implementation only marginally more complex than JPEG (in fact, you can even implement it on top of an existing JPEG encoder/decoder) with a slowdown of only 25%.
  - 13y ago
rwmj 13y ago
Why don't they just contribute the jpgcrush-like C code back to libjpeg-turbo? Edit: A good reason given in the reply by joshmoz below.
- jbondeson 13y ago
  If their only plans were to add that one feature I'm sure they would have done just that. Clearly they have grander plans than simply integrating existing functionality, and they felt they needed total control of the project to do so. The beauty of open source is that if the maintainers of libjpeg-turbo want to incorporate it, they can, and I'm sure the Mozilla devs would be more than happy to help.
- joshmoz 13y ago
  This was discussed with the author of libjpeg-turbo. His priorities are different, it was agreed that a fork is best.
  - nly 13y ago
    Listen, you're doing it all wrong. You're supposed to fork it, tell noone, do a years worth of work in secrecy, release it. palm it off to another FOSS community, then abandon it, then refork it, do another 2 years of work in secrecy and then release it again under a new name. Got it? You'll never get to play alongside big boys like Apple and Facebook with this 'talk to upstream' attitude of yours. That's just not how the game is played.
    - TheZenPsycho 13y ago
      It's telling you left off google.
billyhoffman 13y ago
This is very promising. Images by far dominate a web page, both in number of requests and total number of bytes sent [1]. Optimizing image size by even 5-10% can have a real effect on bandwidth consumption and page load times. JPEG optimization using open source tools is an area that really needs focus. There are a number of lossless JPEG optimization tools, but most are focused on stripping non-graphical data out of the file, or converting the image to a progressive JPEG (since progressive JPEG's have rearrange pixel data you can sometimes get better compression since there may be more redundancy in the rearranged data). Short of exceptional cases where you can remove massive amount of metadata (Adobe products regular stick embedded thumbnails and the entire "undo" history for an image) lossless optimization usually only reduces file size by 5-15%. Lossy JPEG optimization has much more potential. Unfortunately, beyond proprietary encoders, the most common lossy JPEG optimization exclusively is to reduce the JPEG quality. This always felt like killing flies with a tank, so advances in this area would be awesome. I've written extensively about Lossy optimization for JPEGs and PNG, and spoke about it at the Velocity conference. A post and my slides are available[2]. [1] - http://httparchive.org/trends.php http://httparchive.org/trends.php [2] - http://zoompf.com/blog/2013/05/achieving-better-image-optimization-with-lossy-techniques http://zoompf.com/blog/2013/05/achieving-better-image-optimi...
pavlov 13y ago
Bravo. I love JPEG. Amazing that it's been 23 years since its release and it remains as useful as ever. I remember what it was like to watch a 320*200 JPEG image slowly build up on a 386SX PC with a VGA card. Today, a HD frame compressed with JPEG can be decoded in milliseconds. This highlights the secret to JPEG's success: it was designed with enough foresight and a sufficiently well-bounded scope that it keeps hitting a sweet spot between computing power and bandwidth. Did you know that most browsers support JPEG video streaming using a plain old <img> tag? It works also on iOS and Android, but not IE unfortunately. It's triggered by the "multipart/x-mixed-replace" content type header [0]. The HTTP server leaves the connection open after sending the first image, and then simply writes new images as they come in like it were a multipart file download. A compliant browser will update the image element's contents in place. [0] http://en.wikipedia.org/wiki/MIME#Mixed-Replace http://en.wikipedia.org/wiki/MIME#Mixed-Replace
- dmm 13y ago
  Unfortunately chrome recently removed support for "multipart/x-mixed-replace". It's too bad too. It was a simple way to implement a webcam. https://code.google.com/p/chromium/issues/detail?id=249132 https://code.google.com/p/chromium/issues/detail?id=249132 http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-and-webrtc-in.html http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-an...
  - fzzzy 13y ago
    According to those links, they still support it for images, but removed support for other types of resources. It's too bad IE never supported multipart/x-mixed-replace or we might have seen more live updating websites earlier. Now that we have WebSockets and well understood long polling approaches it doesn't matter any more, since x-mixed-replace would keep the download spinner spinning forever and the newer approaches don't have that problem.
    - kybernetikos 13y ago
      I used multipart replace in firefox for streaming data for years with no download spinner. I couldn't use it in chrome because chrome always seemed to have some weird bug where 'frames' (of data in my case) were delayed. I was disappointed when they were unceremoniously ripped out, but yes, websockets are better.
ilaksh 13y ago
If my goal were to compress say 10,000 images and I could include a dictionary or some sort of common database that the compressed data for each image would reference, could I not use a large dictionary shared by the entire catalog and therefore get much smaller file sizes? Maybe images could be encoded with reference to a common database we share that has the most repetitive data. So perhaps 10mb, 50mb or 100mb of common bits that the compression algorithm could reference. You would build this dictionary by analyzing many many images. Same type of approach could work for video.
- pit 13y ago
  This is a Huffman table, right? I'm pretty sure this is how MP3s work.
  - _delirium 13y ago
    I read it as just being a suggestion (which is not that uncommon) to use inter-file common characteristics to optimize for the common case, at least within a certain context. JPEG is designed to compress any image. But imagine a new algorithm, gJPEG, which is only designed to compress photographs of grass. And furthermore, you get 100MB of raw buffer space in the executable to store some precomputed data that would be useful to gJPEG doing its work. It's quite possible you could significantly improve on the general performance by factoring out some data that's common to typical grass photographs, so that data could be stored once-and-for-all in the decoder and then omitted from each of your (presumably) billions of individual grass photographs. On the other hand, it's pretty tricky to make it work, so you might not be able to do such a thing effectively.
    - ilaksh 13y ago
      Why do you suggest that this would only work for photographs in one narrow domain?
      - _delirium 13y ago
        I read the proposal as intending to take advantage of similarities among photographs in a particular domain. Lacking such similarity, you're back to the general photo-compression problem.
tenfingers 13y ago
I noticed that optimizing JPEG images using jpegoptim (http://www.kokkonen.net/tjko/projects.html http://www.kokkonen.net/tjko/projects.html) reduces the size by a similar factor, but at the expense of decoding speed. In fact, on a JPEG-heavy site that I was testing with FF 26, there was such a degradation in terms of responsiveness that transitions would stutter whenever a new image was decoded in the background (while preloading). It made the effort to save 2-4% in size wasted with a worse user experience.
- gcp 13y ago
  Did you file a bug for this? This doesn't sound normal at all.
  - tenfingers 13y ago
    Honestly, no. libjpeg would show similar slowdown (interestingly, PNG decoding is slower than JPEG for the same size), and it make sense anyway. The problem is that even if the bug would be fixed in recent FF versions, libjpeg is basically used in all other browsers as well.
- pornel 13y ago
  I'm using jpegoptim extensively and haven't noticed such behavior. All jpegoptim does is rewrite JPEG with optimized Huffman tables, so it shouldn't have any impact on decoding performance. In the process it also changes progressive to baseline, which is even slightly faster to decode. If you can reproduce the problem with libjpeg-turbo (which is the library that browsers use) you should definitely file a bug.
sp332 13y ago
Any chance of incorporating other psy improvements, instead of just targeting SSIM?
drawkbox 13y ago
Data compression and image compression is a great way to improve the overall internet, bandwidth and speed. Maybe as important as new protocols like SPDY and js/css minification and cdn hosting of common libraries. As long as ISPs/telcos don't go back to the days of AOL network wide compression to reduce bandwidth beyond low quality I am for this at service level like facebook/dropbox uploads. I hope this inspires more in this area. Games also get better with better textures in less space. Still to this day, I am amazed at the small file sizes macromedia (adobe now) was able to obtain with flash/swf/asf even high quality PNGs would compress. So yes we all have lots of bandwidth now but crunching to the point of representing the same thing is a good thing. With cable company caps and other bandwidth false supply shortage that focus might resurge a bit.
- userbinator 13y ago
  SWF has a very cleverly designed binary vector graphics format, which naturally lends itself to small filesizes. Much better than SVG or (E)PS, I think.
  - est 13y ago
    Can you share more on the "clever" part?
    - userbinator 13y ago
      To quote from the format spec, "SWF uses techniques such as bit-packing and structures with optional fields to minimize file size." Many fields are variable-width numbers of bits, using only as many bits as necessary to encode the data. Coordinates are delta-encoded.
derefr 13y ago
Now if only they'd do a mozpng. (For context: libpng is a "purposefully-minimal reference implementation" that avoids features such as, e.g., Animated PNG decoding. And yet libpng is the library used by Firefox, Chrome, etc., because it's the one implementation with a big standards body behind it. Yet, if Mozilla just forked libpng, their version would instantly have way more developer-eyes on it than the source...)
- csense 13y ago
  See my comment about zopfli [1] for improved png compression algorithm. [1] https://news.ycombinator.com/item?id=7349635 https://news.ycombinator.com/item?id=7349635
- deleted 13y ago
  [deleted]
- pornel 13y ago
  There's already a "mozpng", it's called Zopfli. There's also AdvPNG which compresses PNGs with 7-zip's deflate implementation. And if you want much much smaller PNGs, then try http://pngquant.org http://pngquant.org or http://pngmini.com/lossypng.html http://pngmini.com/lossypng.html
  - sovok 13y ago
    Or try ImageOptim, which bundles these and other tools with a nice GUI: http://imageoptim.com/ http://imageoptim.com/
    - nness 13y ago
      ImageOptim also bundles PNGOUT, which I find to have exceptional compression when compared to the others (but it is a bit slower)
- maxst 13y ago
  Mozilla already uses patched libpng (with APNG support).
csense 13y ago
For improving general-purpose gzip / zlib compression, there is the Zopfli project [1] [2]. It also has (alpha quality) code for PNG file format; since this functionality wasn't originally included, there are also third-party projects [3]. You might be able to shave a percent or so off the download size of compressed assets. [1] https://news.ycombinator.com/item?id=5316595 https://news.ycombinator.com/item?id=5316595 [2] https://news.ycombinator.com/item?id=5301688 https://news.ycombinator.com/item?id=5301688 [3] https://github.com/subzey/zopfli-png https://github.com/subzey/zopfli-png
United857 13y ago
What about WebP? Isn't that intended to be a eventual replacement to JPEG?
- wmf 13y ago
  From the article: "...replacing JPEG with something better has been a frequent topic of discussion. The major downside to moving away from JPEG is that it would require going through a multi-year period of relatively poor compatibility with the world’s deployed software. We (at Mozilla) don’t doubt that algorithmic improvements will make this worthwhile at some point, possibly soon. Even after a transition begins in earnest though, JPEG will continue to be used widely." This is Mozilla's roundabout way of saying that they want to put off starting on WebP or JPEG 2000 as long as possible.
- cbhl 13y ago
  Only if other browser vendors adopt it, although IIRC WebP has hard-coded maximum file size limits that make it impractical for e.g. retina displays, let alone anything we might see twenty years from now.
  - magicalist 13y ago
    Ah, that's interesting. I hadn't heard that before. It is a maximum size of 16383x16383[1], so it's more than practical for retina displays, but I can see the point about files in 20 years (for reference, jpegs can be 4x that in each dimension, 65535×65535). I haven't heard that brought up as an objection to the format before, though. If it were really a fundamental stumbling block, there are likely ways to adapt the format around it. [1] https://developers.google.com/speed/webp/faq#what_is_the_maximum_size_a_webp_image_can_be https://developers.google.com/speed/webp/faq#what_is_the_max...
- d0ugie 13y ago
  .. WebP as a replacement to jpegs, pngs, apngs, gifs, and maybe one day svgs and psds, to the moon baby, with or without Mozilla. Though I'm sure they have their reasons to stay away from an across-the-board superior format. I just wish I knew what they were. Sigh.
cjensen 13y ago
JPEG-2000 exists, but decoding is still too slow to be useful. http://en.wikipedia.org/wiki/JPEG_2000 http://en.wikipedia.org/wiki/JPEG_2000
- wmf 13y ago
  What, it takes 2 ms instead of 1?
  - acdha 13y ago
    More like 500-2000ms - there are a few commercial codecs (Kakadu - as licensed in OS X, Aware) which are well-polished but the open-source situation was wretched for many years, relying on a few libraries which were indifferently maintained and seriously unoptimized. This meant that there were many valid files which could not be opened, key features like tiled decoding weren't supported and everything is so much slower that users will comment on how much longer it takes simply to open or convert a file. There is some good news in that OpenJPEG (http://www.openjpeg.org/ http://www.openjpeg.org/) has been making significant progress in recent years and is now on track to become an official reference implementation: https://groups.google.com/d/msg/openjpeg/OMc40gUsBIw/UM1ggXkii3EJ https://groups.google.com/d/msg/openjpeg/OMc40gUsBIw/UM1ggXk... Hopefully this will also translate into continued performance work and robustness testing, which would mean potential hope for a browser other than Safari to add native support: https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120 https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120
    - makomk 13y ago
      Funny story actually - OpenJPEG got a whole bunch of optimisation a few years back because Second Life relies on JPEG2000, after having been generally neglected for some time.
      - acdha 13y ago
        Yes - that was when I started looking at it more seriously. I'm hoping that work continues after the feature support is considered mature enough.
1ris 13y ago
I'm actually disapointed. I hoped they developed a still image format from Daala. Daala has sigificant improments such as overlapping blocks, differently sized blocks and a predictor that works not only for luma or chroma, but for both.
- nnethercote 13y ago
  Is Daala anywhere close enough to being finished for this to even be feasible?
- metajack 13y ago
  One of our listed intern projects is exactly that. It's not a high priority project for the Daala team because we already have good royalty-free image codecs, but not video codecs. We have finite time, so we choose to attack what we see as the more important problem. Developing a still image format from Daala is possible but not as trivial as it looks (the same can be said for the WebP work from WebM).
transfire 13y ago
If only JPEG supported transparency.
- chrisdew 13y ago
  You can do a JS hack with JPEG for RGB and PNG for alpha, but it's not ideal.
CookWithMe 13y ago
We've been using http://www.jpegmini.com/ http://www.jpegmini.com/ to compress JPGs for our apps. Worked OK, although we didn't get the enormous reductions they advertise. However 5% - 10% does still make a difference. We've been using the desktop version. Would love to use something similar on a server, but jpegmini is overpriced for our scenario (I'll not have a dedicated AWS instance running for compressing images every second day or so). Will definitely check out this project :)
- rast-a 13y ago
  Have u tried https://kraken.io https://kraken.io ?
Matrixik 13y ago
When I optimize JPG or PNG I usually use ScriptJPG and ScriptPNG from http://css-ig.net/tools/ http://css-ig.net/tools/ They are shell scripts running many different optimizers
TheZenPsycho 13y ago
I have heard similar things about GIF (that there are optimisations that most encoding software does not properly take advantage of). But I haven't seen any efforts, or cutting edge software that actually follows through on that promise. The closest I've seen is gifscicle, which is a bit disappointing. What would be great if there was some way for an animated gif's frame delays to opt-in to being interpreted correctly by browser- That is, a 0-delay really would display with no delay, and so optimisation strategies involving the splitting of image data across multiple frames could be done- and when read in by a browser, all frames would be overlaid instantly, module loading time. What other things can be done to further optimise animated gif encoding?
- Grue3 13y ago
  GIF should be killed. Animated PNG is where it's at.
  - iopq 13y ago
    Animated PNGs should be killed. Just embed a video with an alpha channel. It compresses way better. http://simpl.info/videoalpha/ http://simpl.info/videoalpha/
    - Grue3 13y ago
      Wrong use-case. Animated GIFs and animated PNGs were never intended for video. The analogy to still image formats is video:JPEG = web-animation:PNG. You don't save screenshots as JPGs and you don't save photos as PNGs. Same with video and web-animation, two different use-cases require two different formats.
      - iopq 13y ago
        except that's a false dichotomy one format can support both lossy and lossless images and use better compression between frames to achieve 10x better results for animations than animated pngs without visible loss of quality
jmspring 13y ago
It's not clear from the article, in their "comparison of 1500 JPEG images from Wikipedia" did they just run through the entropy coding portion again or did they requantize? (I suspect they did jus the entropy coding portion, but hard to tell). Getting better encoding by changing the quantization method can't be purely a function of file size, traditionally PSNR measurements as well as visual quality come into play. Good to see some work in the area, I will need to check out what is new and novel. That said, a company I worked for many moons ago came up with a method where by reorganization of coefficients post-quantization, you could easily get about 20% improvement in encoding efficiency, but the result was not JPEG compatible. There is a lot that can be played with.
jimbones 13y ago
This is so dumb, there are a million JPEG crushers in existence but instead of advocating the use of one of these Mozilla writes their own? Why not support webp rather than dismiss it due to compatibility and waste time doing what has been done before.
SimHacker 13y ago
Has somebody translated the jpeg library to JavaScript? Besides encoding and decoding jpeg, it has some useful modules that would be nice to have in the web browser.
davidgerard 13y ago
What license are they doing this under? Hopefully they're aiming to upstream this to libjpeg.
kraken-io 13y ago
Hey everyone, after some testing we have just deployed mozjpeg to our web interface at: https://kraken.io/web-interface https://kraken.io/web-interface You can test it out by selecting the "lossless" option and uploading a jpeg. Enjoy!
Taek 13y ago
I like that Mozilla is improving the existing accepted standard, but using modern (mostly patented) codec techniques we could get lossy images to under 1/2 of the current size at the same quality and decode speed. Or at a much higher quality for the same size. The speed modern web concerns me. The standards are not moving forward. We still use HTML, CSS, Javascript, Jpeg, Gif, and PNG. Gif especially is a format where we could see similar sized/quality moving images at 1/8th the file size if we supported algorithms similar to those found in modern video. In all of these cases, they aren't "tried and true" so much as "we've had so many problems with each that we've got a huge suite of half-hacked solutions to pretty much everything you could want to do". We haven't moved forward because we can't. WebP is a good example of a superior format that never stood a chance because front-end web technology is not flexible.
- pcwalton 13y ago
  I think the surprising thing is that JPEG is as good as it is. WebP certainly isn't "1/2 of the current size at the same quality and decode speed". It's a modest improvement if anything. GIF, sure. But, IMO, nobody should really be using GIFs anymore. We've had <video> and APNG for a while if you want animation.
morganw 13y ago
"support for progressive JPEGs is not universal" https://en.wikipedia.org/wiki/JPEG#JPEG_compression https://en.wikipedia.org/wiki/JPEG#JPEG_compression e.g. the hardware decoder in the Raspberry Pi http://forum.stmlabs.com/showthread.php?tid=12102 http://forum.stmlabs.com/showthread.php?tid=12102
Momentum 13y ago
At first glance this seems wasteful. I do not think anyone would have problem in using Jpeg. However, in many cases, before the the invention of a thing who has had no problem using old tools!

409 points by joshmoz 13y ago

kllrnohj 13y ago

So... version 1.0 is basically a shell script that calls libjpeg-turbo followed by jpgcrush?

michaelmior 13y ago
No, the jpegcrush functionality is implemented in C as an extension to libjpeg-turbo. But yes, I suppose a shell script would achieve roughly the same result.
- kllrnohj 13y ago
  So why wasn't this upstreamed to libjpeg-turbo? Why fork at all? libjpeg-turbo is still an actively maintained project after all...
  - riquito 13y ago
    They want to do much more, and with a fork you don't have to justify and discuss every single commit with the original maintainer. If you want to modify heavily something, a fork is the right approach.
  - deleted 13y ago
    [deleted]
  - syntheticnature 13y ago
    Maintainer has different priorities, see https://news.ycombinator.com/item?id=7349117 https://news.ycombinator.com/item?id=7349117
joshmoz 13y ago
No shell script or second step involved. Functionality is built in and on by default. This is just a start, we wanted to have something people could use on day one. Further developments to come.
briansmith 13y ago
I believe this merge shows the C code that implements the crush functionality: https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d471650ec1f18bc727c9a36 https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d...

callesgg 13y ago

A bit to soon to start announcing the project. But I like the initiative hope the project manages to improve stuff.

joshmoz 13y ago
We would like to develop in the open, and hopefully with community participation.
- brigade 13y ago
  BTW, please fix your lossy test methodology for when you do your tests on a future version of this. https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/ https://blog.mozilla.org/research/2013/10/17/studying-lossy-... was rather flawed and you never acknowledged this. (see https://news.ycombinator.com/item?id=6581827 https://news.ycombinator.com/item?id=6581827 - only one of the four sets of test results might have been valid)
briansmith 13y ago
Mozilla tends to announce projects when they begin so people can contribute to them right away. I think that's a good thing and that's one of the reasons I work for Mozilla. By the way, I think this is an awesome effort by Josh and the others working on this. I work mainly in security and networking, and I'm excited about anything we can do to make end-to-end communication more efficient because these kinds of improvements help enable more use of HTTPS and help reduce (hopefully eliminate) the need for content transforming proxies.

IvyMike 13y ago

JPEG has shown amazingly good staying power. I would have assumed "JPEG is woefully old and easy to beat" but Charles Bloom did a good series of blog posts looking at it, and my (non-expert and probably hopelessly naive) takeaway is that JPEG still holds its own for a 20+ year old format. http://cbloomrants.blogspot.com/2012/04/04-09-12-old-image-comparison-post.html http://cbloomrants.blogspot.com/2012/04/04-09-12-old-image-c...

georgemcbay 13y ago
(*)Charles Bloom.
- IvyMike 13y ago
  Fixed.
brigade 13y ago
Do note that his "JPEG" is really JPEG with a PAQ entropy coder, which is actually a new format and not at all decodable by a JPEG decoder. He does no tests on baseline JPEG. But it's useful to point out that a lot of new overly complex formats can't beat something as simple as that.
mistercow 13y ago
In my opinion, the biggest drawback of JPEG is that its window is non-overlapping. Ring-artifacts are generally not a big deal for natural images at medium quality or higher, but blocking artifacts can be noticeable even at relatively high quality settings. There are a lot of post-processing techniques to try and mitigate this, but in my experience they tend to do about as much damage as they fix. The proper solution is to overlap the blocks using one of the myriad techniques DCT-based audio codecs use. It is bizarre to me that for all of the attempts to beat JPEG, nobody seems to have tried simply overlapping the blocks by 2 pixels. You'd have an implementation only marginally more complex than JPEG (in fact, you can even implement it on top of an existing JPEG encoder/decoder) with a slowdown of only 25%.
- 13y ago

rwmj 13y ago

Why don't they just contribute the jpgcrush-like C code back to libjpeg-turbo? Edit: A good reason given in the reply by joshmoz below.

jbondeson 13y ago
If their only plans were to add that one feature I'm sure they would have done just that. Clearly they have grander plans than simply integrating existing functionality, and they felt they needed total control of the project to do so. The beauty of open source is that if the maintainers of libjpeg-turbo want to incorporate it, they can, and I'm sure the Mozilla devs would be more than happy to help.
joshmoz 13y ago
This was discussed with the author of libjpeg-turbo. His priorities are different, it was agreed that a fork is best.
- nly 13y ago
  Listen, you're doing it all wrong. You're supposed to fork it, tell noone, do a years worth of work in secrecy, release it. palm it off to another FOSS community, then abandon it, then refork it, do another 2 years of work in secrecy and then release it again under a new name. Got it? You'll never get to play alongside big boys like Apple and Facebook with this 'talk to upstream' attitude of yours. That's just not how the game is played.
  - TheZenPsycho 13y ago
    It's telling you left off google.

billyhoffman 13y ago

This is very promising. Images by far dominate a web page, both in number of requests and total number of bytes sent [1]. Optimizing image size by even 5-10% can have a real effect on bandwidth consumption and page load times. JPEG optimization using open source tools is an area that really needs focus. There are a number of lossless JPEG optimization tools, but most are focused on stripping non-graphical data out of the file, or converting the image to a progressive JPEG (since progressive JPEG's have rearrange pixel data you can sometimes get better compression since there may be more redundancy in the rearranged data). Short of exceptional cases where you can remove massive amount of metadata (Adobe products regular stick embedded thumbnails and the entire "undo" history for an image) lossless optimization usually only reduces file size by 5-15%. Lossy JPEG optimization has much more potential. Unfortunately, beyond proprietary encoders, the most common lossy JPEG optimization exclusively is to reduce the JPEG quality. This always felt like killing flies with a tank, so advances in this area would be awesome. I've written extensively about Lossy optimization for JPEGs and PNG, and spoke about it at the Velocity conference. A post and my slides are available[2]. [1] - http://httparchive.org/trends.php http://httparchive.org/trends.php [2] - http://zoompf.com/blog/2013/05/achieving-better-image-optimization-with-lossy-techniques http://zoompf.com/blog/2013/05/achieving-better-image-optimi...

pavlov 13y ago

Bravo. I love JPEG. Amazing that it's been 23 years since its release and it remains as useful as ever. I remember what it was like to watch a 320*200 JPEG image slowly build up on a 386SX PC with a VGA card. Today, a HD frame compressed with JPEG can be decoded in milliseconds. This highlights the secret to JPEG's success: it was designed with enough foresight and a sufficiently well-bounded scope that it keeps hitting a sweet spot between computing power and bandwidth. Did you know that most browsers support JPEG video streaming using a plain old <img> tag? It works also on iOS and Android, but not IE unfortunately. It's triggered by the "multipart/x-mixed-replace" content type header [0]. The HTTP server leaves the connection open after sending the first image, and then simply writes new images as they come in like it were a multipart file download. A compliant browser will update the image element's contents in place. [0] http://en.wikipedia.org/wiki/MIME#Mixed-Replace http://en.wikipedia.org/wiki/MIME#Mixed-Replace

dmm 13y ago
Unfortunately chrome recently removed support for "multipart/x-mixed-replace". It's too bad too. It was a simple way to implement a webcam. https://code.google.com/p/chromium/issues/detail?id=249132 https://code.google.com/p/chromium/issues/detail?id=249132 http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-and-webrtc-in.html http://blog.chromium.org/2013/07/chrome-29-beta-web-audio-an...
- fzzzy 13y ago
  According to those links, they still support it for images, but removed support for other types of resources. It's too bad IE never supported multipart/x-mixed-replace or we might have seen more live updating websites earlier. Now that we have WebSockets and well understood long polling approaches it doesn't matter any more, since x-mixed-replace would keep the download spinner spinning forever and the newer approaches don't have that problem.
  - kybernetikos 13y ago
    I used multipart replace in firefox for streaming data for years with no download spinner. I couldn't use it in chrome because chrome always seemed to have some weird bug where 'frames' (of data in my case) were delayed. I was disappointed when they were unceremoniously ripped out, but yes, websockets are better.

ilaksh 13y ago

If my goal were to compress say 10,000 images and I could include a dictionary or some sort of common database that the compressed data for each image would reference, could I not use a large dictionary shared by the entire catalog and therefore get much smaller file sizes? Maybe images could be encoded with reference to a common database we share that has the most repetitive data. So perhaps 10mb, 50mb or 100mb of common bits that the compression algorithm could reference. You would build this dictionary by analyzing many many images. Same type of approach could work for video.

pit 13y ago
This is a Huffman table, right? I'm pretty sure this is how MP3s work.
- _delirium 13y ago
  I read it as just being a suggestion (which is not that uncommon) to use inter-file common characteristics to optimize for the common case, at least within a certain context. JPEG is designed to compress any image. But imagine a new algorithm, gJPEG, which is only designed to compress photographs of grass. And furthermore, you get 100MB of raw buffer space in the executable to store some precomputed data that would be useful to gJPEG doing its work. It's quite possible you could significantly improve on the general performance by factoring out some data that's common to typical grass photographs, so that data could be stored once-and-for-all in the decoder and then omitted from each of your (presumably) billions of individual grass photographs. On the other hand, it's pretty tricky to make it work, so you might not be able to do such a thing effectively.
  - ilaksh 13y ago
    Why do you suggest that this would only work for photographs in one narrow domain?
    - _delirium 13y ago
      I read the proposal as intending to take advantage of similarities among photographs in a particular domain. Lacking such similarity, you're back to the general photo-compression problem.

tenfingers 13y ago

I noticed that optimizing JPEG images using jpegoptim (http://www.kokkonen.net/tjko/projects.html http://www.kokkonen.net/tjko/projects.html) reduces the size by a similar factor, but at the expense of decoding speed. In fact, on a JPEG-heavy site that I was testing with FF 26, there was such a degradation in terms of responsiveness that transitions would stutter whenever a new image was decoded in the background (while preloading). It made the effort to save 2-4% in size wasted with a worse user experience.

gcp 13y ago
Did you file a bug for this? This doesn't sound normal at all.
- tenfingers 13y ago
  Honestly, no. libjpeg would show similar slowdown (interestingly, PNG decoding is slower than JPEG for the same size), and it make sense anyway. The problem is that even if the bug would be fixed in recent FF versions, libjpeg is basically used in all other browsers as well.
pornel 13y ago
I'm using jpegoptim extensively and haven't noticed such behavior. All jpegoptim does is rewrite JPEG with optimized Huffman tables, so it shouldn't have any impact on decoding performance. In the process it also changes progressive to baseline, which is even slightly faster to decode. If you can reproduce the problem with libjpeg-turbo (which is the library that browsers use) you should definitely file a bug.

sp332 13y ago

Any chance of incorporating other psy improvements, instead of just targeting SSIM?

drawkbox 13y ago

Data compression and image compression is a great way to improve the overall internet, bandwidth and speed. Maybe as important as new protocols like SPDY and js/css minification and cdn hosting of common libraries. As long as ISPs/telcos don't go back to the days of AOL network wide compression to reduce bandwidth beyond low quality I am for this at service level like facebook/dropbox uploads. I hope this inspires more in this area. Games also get better with better textures in less space. Still to this day, I am amazed at the small file sizes macromedia (adobe now) was able to obtain with flash/swf/asf even high quality PNGs would compress. So yes we all have lots of bandwidth now but crunching to the point of representing the same thing is a good thing. With cable company caps and other bandwidth false supply shortage that focus might resurge a bit.

userbinator 13y ago
SWF has a very cleverly designed binary vector graphics format, which naturally lends itself to small filesizes. Much better than SVG or (E)PS, I think.
- est 13y ago
  Can you share more on the "clever" part?
  - userbinator 13y ago
    To quote from the format spec, "SWF uses techniques such as bit-packing and structures with optional fields to minimize file size." Many fields are variable-width numbers of bits, using only as many bits as necessary to encode the data. Coordinates are delta-encoded.

derefr 13y ago

Now if only they'd do a mozpng. (For context: libpng is a "purposefully-minimal reference implementation" that avoids features such as, e.g., Animated PNG decoding. And yet libpng is the library used by Firefox, Chrome, etc., because it's the one implementation with a big standards body behind it. Yet, if Mozilla just forked libpng, their version would instantly have way more developer-eyes on it than the source...)

csense 13y ago
See my comment about zopfli [1] for improved png compression algorithm. [1] https://news.ycombinator.com/item?id=7349635 https://news.ycombinator.com/item?id=7349635
deleted 13y ago
[deleted]
pornel 13y ago
There's already a "mozpng", it's called Zopfli. There's also AdvPNG which compresses PNGs with 7-zip's deflate implementation. And if you want much much smaller PNGs, then try http://pngquant.org http://pngquant.org or http://pngmini.com/lossypng.html http://pngmini.com/lossypng.html
- sovok 13y ago
  Or try ImageOptim, which bundles these and other tools with a nice GUI: http://imageoptim.com/ http://imageoptim.com/
  - nness 13y ago
    ImageOptim also bundles PNGOUT, which I find to have exceptional compression when compared to the others (but it is a bit slower)
maxst 13y ago
Mozilla already uses patched libpng (with APNG support).

csense 13y ago

For improving general-purpose gzip / zlib compression, there is the Zopfli project [1] [2]. It also has (alpha quality) code for PNG file format; since this functionality wasn't originally included, there are also third-party projects [3]. You might be able to shave a percent or so off the download size of compressed assets. [1] https://news.ycombinator.com/item?id=5316595 https://news.ycombinator.com/item?id=5316595 [2] https://news.ycombinator.com/item?id=5301688 https://news.ycombinator.com/item?id=5301688 [3] https://github.com/subzey/zopfli-png https://github.com/subzey/zopfli-png

United857 13y ago

What about WebP? Isn't that intended to be a eventual replacement to JPEG?

wmf 13y ago
From the article: "...replacing JPEG with something better has been a frequent topic of discussion. The major downside to moving away from JPEG is that it would require going through a multi-year period of relatively poor compatibility with the world’s deployed software. We (at Mozilla) don’t doubt that algorithmic improvements will make this worthwhile at some point, possibly soon. Even after a transition begins in earnest though, JPEG will continue to be used widely." This is Mozilla's roundabout way of saying that they want to put off starting on WebP or JPEG 2000 as long as possible.
cbhl 13y ago
Only if other browser vendors adopt it, although IIRC WebP has hard-coded maximum file size limits that make it impractical for e.g. retina displays, let alone anything we might see twenty years from now.
- magicalist 13y ago
  Ah, that's interesting. I hadn't heard that before. It is a maximum size of 16383x16383[1], so it's more than practical for retina displays, but I can see the point about files in 20 years (for reference, jpegs can be 4x that in each dimension, 65535×65535). I haven't heard that brought up as an objection to the format before, though. If it were really a fundamental stumbling block, there are likely ways to adapt the format around it. [1] https://developers.google.com/speed/webp/faq#what_is_the_maximum_size_a_webp_image_can_be https://developers.google.com/speed/webp/faq#what_is_the_max...
d0ugie 13y ago
.. WebP as a replacement to jpegs, pngs, apngs, gifs, and maybe one day svgs and psds, to the moon baby, with or without Mozilla. Though I'm sure they have their reasons to stay away from an across-the-board superior format. I just wish I knew what they were. Sigh.

cjensen 13y ago

JPEG-2000 exists, but decoding is still too slow to be useful. http://en.wikipedia.org/wiki/JPEG_2000 http://en.wikipedia.org/wiki/JPEG_2000

wmf 13y ago
What, it takes 2 ms instead of 1?
- acdha 13y ago
  More like 500-2000ms - there are a few commercial codecs (Kakadu - as licensed in OS X, Aware) which are well-polished but the open-source situation was wretched for many years, relying on a few libraries which were indifferently maintained and seriously unoptimized. This meant that there were many valid files which could not be opened, key features like tiled decoding weren't supported and everything is so much slower that users will comment on how much longer it takes simply to open or convert a file. There is some good news in that OpenJPEG (http://www.openjpeg.org/ http://www.openjpeg.org/) has been making significant progress in recent years and is now on track to become an official reference implementation: https://groups.google.com/d/msg/openjpeg/OMc40gUsBIw/UM1ggXkii3EJ https://groups.google.com/d/msg/openjpeg/OMc40gUsBIw/UM1ggXk... Hopefully this will also translate into continued performance work and robustness testing, which would mean potential hope for a browser other than Safari to add native support: https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120 https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120
  - makomk 13y ago
    Funny story actually - OpenJPEG got a whole bunch of optimisation a few years back because Second Life relies on JPEG2000, after having been generally neglected for some time.
    - acdha 13y ago
      Yes - that was when I started looking at it more seriously. I'm hoping that work continues after the feature support is considered mature enough.

1ris 13y ago

I'm actually disapointed. I hoped they developed a still image format from Daala. Daala has sigificant improments such as overlapping blocks, differently sized blocks and a predictor that works not only for luma or chroma, but for both.

nnethercote 13y ago
Is Daala anywhere close enough to being finished for this to even be feasible?
metajack 13y ago
One of our listed intern projects is exactly that. It's not a high priority project for the Daala team because we already have good royalty-free image codecs, but not video codecs. We have finite time, so we choose to attack what we see as the more important problem. Developing a still image format from Daala is possible but not as trivial as it looks (the same can be said for the WebP work from WebM).

transfire 13y ago

If only JPEG supported transparency.

chrisdew 13y ago
You can do a JS hack with JPEG for RGB and PNG for alpha, but it's not ideal.

CookWithMe 13y ago

We've been using http://www.jpegmini.com/ http://www.jpegmini.com/ to compress JPGs for our apps. Worked OK, although we didn't get the enormous reductions they advertise. However 5% - 10% does still make a difference. We've been using the desktop version. Would love to use something similar on a server, but jpegmini is overpriced for our scenario (I'll not have a dedicated AWS instance running for compressing images every second day or so). Will definitely check out this project :)

rast-a 13y ago
Have u tried https://kraken.io https://kraken.io ?

Matrixik 13y ago

When I optimize JPG or PNG I usually use ScriptJPG and ScriptPNG from http://css-ig.net/tools/ http://css-ig.net/tools/ They are shell scripts running many different optimizers

TheZenPsycho 13y ago

I have heard similar things about GIF (that there are optimisations that most encoding software does not properly take advantage of). But I haven't seen any efforts, or cutting edge software that actually follows through on that promise. The closest I've seen is gifscicle, which is a bit disappointing. What would be great if there was some way for an animated gif's frame delays to opt-in to being interpreted correctly by browser- That is, a 0-delay really would display with no delay, and so optimisation strategies involving the splitting of image data across multiple frames could be done- and when read in by a browser, all frames would be overlaid instantly, module loading time. What other things can be done to further optimise animated gif encoding?

Grue3 13y ago
GIF should be killed. Animated PNG is where it's at.
- iopq 13y ago
  Animated PNGs should be killed. Just embed a video with an alpha channel. It compresses way better. http://simpl.info/videoalpha/ http://simpl.info/videoalpha/
  - Grue3 13y ago
    Wrong use-case. Animated GIFs and animated PNGs were never intended for video. The analogy to still image formats is video:JPEG = web-animation:PNG. You don't save screenshots as JPGs and you don't save photos as PNGs. Same with video and web-animation, two different use-cases require two different formats.
    - iopq 13y ago
      except that's a false dichotomy one format can support both lossy and lossless images and use better compression between frames to achieve 10x better results for animations than animated pngs without visible loss of quality

jmspring 13y ago

It's not clear from the article, in their "comparison of 1500 JPEG images from Wikipedia" did they just run through the entropy coding portion again or did they requantize? (I suspect they did jus the entropy coding portion, but hard to tell). Getting better encoding by changing the quantization method can't be purely a function of file size, traditionally PSNR measurements as well as visual quality come into play. Good to see some work in the area, I will need to check out what is new and novel. That said, a company I worked for many moons ago came up with a method where by reorganization of coefficients post-quantization, you could easily get about 20% improvement in encoding efficiency, but the result was not JPEG compatible. There is a lot that can be played with.

jimbones 13y ago

This is so dumb, there are a million JPEG crushers in existence but instead of advocating the use of one of these Mozilla writes their own? Why not support webp rather than dismiss it due to compatibility and waste time doing what has been done before.

SimHacker 13y ago

Has somebody translated the jpeg library to JavaScript? Besides encoding and decoding jpeg, it has some useful modules that would be nice to have in the web browser.

davidgerard 13y ago

What license are they doing this under? Hopefully they're aiming to upstream this to libjpeg.

kraken-io 13y ago

Hey everyone, after some testing we have just deployed mozjpeg to our web interface at: https://kraken.io/web-interface https://kraken.io/web-interface You can test it out by selecting the "lossless" option and uploading a jpeg. Enjoy!

Taek 13y ago

I like that Mozilla is improving the existing accepted standard, but using modern (mostly patented) codec techniques we could get lossy images to under 1/2 of the current size at the same quality and decode speed. Or at a much higher quality for the same size. The speed modern web concerns me. The standards are not moving forward. We still use HTML, CSS, Javascript, Jpeg, Gif, and PNG. Gif especially is a format where we could see similar sized/quality moving images at 1/8th the file size if we supported algorithms similar to those found in modern video. In all of these cases, they aren't "tried and true" so much as "we've had so many problems with each that we've got a huge suite of half-hacked solutions to pretty much everything you could want to do". We haven't moved forward because we can't. WebP is a good example of a superior format that never stood a chance because front-end web technology is not flexible.

pcwalton 13y ago
I think the surprising thing is that JPEG is as good as it is. WebP certainly isn't "1/2 of the current size at the same quality and decode speed". It's a modest improvement if anything. GIF, sure. But, IMO, nobody should really be using GIFs anymore. We've had <video> and APNG for a while if you want animation.

morganw 13y ago

"support for progressive JPEGs is not universal" https://en.wikipedia.org/wiki/JPEG#JPEG_compression https://en.wikipedia.org/wiki/JPEG#JPEG_compression e.g. the hardware decoder in the Raspberry Pi http://forum.stmlabs.com/showthread.php?tid=12102 http://forum.stmlabs.com/showthread.php?tid=12102

Momentum 13y ago

At first glance this seems wasteful. I do not think anyone would have problem in using Jpeg. However, in many cases, before the the invention of a thing who has had no problem using old tools!