Forgot your password?
typodupeerror
Software Graphics Mozilla Open Source Upgrades Technology

New Mozilla Encoder Improves JPEG Compression 155

Posted by timothy
from the 6-percent's-a-lot dept.
jlp2097 writes "As reported by Heise, Mozilla has introduced a new JPEG encoder (German [Google-translated to English]) called mozjpeg. Mozjpeg promises to be a 'production-quality JPEG encoder that improves compression while maintaining compatibility with the vast majority of deployed decoders.' The Mozilla Research blog states that Mozjpeg is based on libjpeg-turbo with functionality added from jpgcrush. They claim an average of 2-6% of additional compression for files encoded with libjpeg and 10% additional compression for a sample of 1500 jpegs from Wikipedia — while maintaining the same image quality."
This discussion has been archived. No new comments can be posted.

New Mozilla Encoder Improves JPEG Compression

Comments Filter:
  • by Anonymous Coward
    It's not lossy. I try to always use PNG.
    • by Anonymous Coward on Thursday March 06, 2014 @11:27AM (#46419151)
      Because PNG is not lossy.
      • by omnichad (1198475)

        I wish I had mod points. Thank you.

    • by prefect42 (141309) on Thursday March 06, 2014 @11:30AM (#46419177)

      If you're talking about simple web graphics, then yes, PNG is often a good choice. Lossy compression simply makes more sense for photos, as the compression ratio is that much better. Always using PNG is idiotic, as is always using JPEG. JPEG2000 is not our saviour.

      • by bzipitidoo (647217) <bzipitidoo@yahoo.com> on Thursday March 06, 2014 @12:22PM (#46419795) Journal

        It's a shame JPEG2000 debuted dead on arrival thanks to patent encumbrances. Creation of a superior open lossy image compression standard seems to have been left behind in favor of video. We have PNG and Theora, but nothing free that improves on jpeg.

        • by Anonymous Coward

          I don't think patents are the problem. I would say it's more that jpeg2000 is slow as molasses, is trying to be lossless and lossy at the same time and failing at both - lossless is way larger than png, lossy throws away the advantage of downsampled YCbCr colorspace that jpeg has. It's not clearly superior to preexisting stuff, except for people with strange needs. Who in fact are using it. It just never went mainstream.

          • Yeah, lots of universities use it for a lot of things, like scientific and cultural heritage images... they serve the images up, if need be, through the proprietary lurawave image server... not a great solution from a systems perspective, but it's what they like.

            Personally, I think the lack of widespread adoption makes it a serious preservation concern.

    • PNG 8 to replace GIFs
      PNG 24 to replace JPEGs

      • Yeah, I also love those stitched panoramas with a few GiB file size, really a great idea ;)

        png is a great format of course and I use it a lot but such an generalization doesn't make any sense at all. Depending on the use case you have to decide which one you use.

      • 1) PNG8 can support full alpha transparency.
        2) PNG is better with fewer colours And blocks of one shade, as it compresses by merging close shades. JPEG is better to compress With lots of different colours like photos as it merges neighbouring pixels.

      • by Anonymous Coward

        Often the simplest solution doesn't cover the real world. Even with pngquant, a large photograph will be three times as large or more in PNG24 than JPEG. 300KB vs 100KB is nothing to sneeze at when you're on a mobile device and on the edge of cell coverage.

        Not to mention the server bandwidth usage when the bill comes due.

    • by jandrese (485) <kensama@vt.edu> on Thursday March 06, 2014 @12:10PM (#46419619) Homepage Journal
      Because truecolor PNG images are much larger (usually at least twice as large, often closer to 4 times larger) than a properly encoded JPG counterpart, and you can't see the difference with your naked eye.
      • Maybe if it is an 800x600 res photo printed with a bad printer, but JPEG shittyness comes into play when you want to DO something with that image, instead of just looking at it from afar
        • by jandrese (485)
          Seriously, try this yourself. Take a digital camera RAW and encode it with JPEG at reasonable settings (80 quality or so) and then compress it with truecolor PNG. Compare the file sizes. Now take a script that puts them up side by side and choose the better image. It should be the PNG right, because JPEG is lossy? I'd bet you would be hard pressed to beat random chance.

          Now that's not to say you should use JPEG absolutely everywhere. Stuff like computer generated images with 1 pixel lines or text loo
          • But you are still talking about LOOKING at that photographic image. If it needs manipulated, you are doing yourself a large disservice by starting out with a JPEG source. Even as something as simple as scaling/zooming will wreak havoc on the outcome. Need to lighten it? Sharpen or blur some lines? AND THEN resave it? No sir. Not good
            • by BronsCon (927697)
              And this is relevant to this discussion because... why, exactly? We're talking about Mozilla's JPEG encoder generating smaller files, and we're talking about it in terms of bandwidth and transfer times. To me, that spells "will be displayed on a webpage", rather than "will be edited and re-saved, possibly through multiple generations". Of course you won't use this for your originals; JPEG should be considered an output format, not an archival or intermediary format, just like any other lossy format for any
      • by Guspaz (556486) on Thursday March 06, 2014 @01:55PM (#46420813)

        Since I started looking at web pages with JPEG images, the speed of my internet connection has increased by roughly 345,000%, the size of my hard disk by 200,000%. Why is a 300% increase in image size a concern?

        • Re: (Score:3, Insightful)

          Because I remember watching graphics load line by line and that sucked.
        • by dryeo (100693)

          Since I started looking at web pages with JPEG images, my internet connection has almost doubled in speed and now there are pages that are basically unviewable.
          Many locations don't have any other option then dial up and many more have various caps on the amount you're allowed to download before charges increase.

          • by Guspaz (556486)

            There are services (Opera's work quite well, Google has one too) that will re-compress any images to lower quality lossy formats and into a single response to avoid round-trips. I don't think big image files are really the main problem for people still on dialup.

          • Many locations don't have any other option then dial up

            Are they all on a north face of a mountain? Because if there's a tall building in the way, the area is probably urban enough to get DSL or DOCSIS, and if there isn't a mountain in the way, it can more than likely get satellite.

        • by eulernet (1132389)

          Because you are not only one in this world, you are probably in the 0.01 percentile of fast connections.

          A lot of people like me have slow connections, so I *hate* big images, and particularly sites which put images everywhere.
          I'm in a rural region, so I don't expect a faster connection anytime soon. And moving is not an option either.

          There is a proverb that says that a picture is worth a thousand words, but it's not true with the Internet.

          • by Guspaz (556486)

            There are plenty of services like Opera Turbo that will recompress all images as smaller lossy images. Why should all users get a degraded experience when those on slow connections have options to automatically recompress images to be better suited for their connections?

            • by eulernet (1132389)

              Because the sites using lots of images tend to also use lots of Javascript.

              I don't see why I should upgrade my computer to be able to browser the web.
              The worst sites I browsed tend to put pictures everywhere, even (and especially) when unnecessary.

              And don't make me laugh with the "experience" of the web.
              Why do you think the simple Google search won over the "portal" search of Yahoo ?
              Has simplicity become so irrelevant ?

              • by Guspaz (556486)

                I don't see what javascript and computer upgrades have to do with PNG. Heck, the point of Opera's stuff was to run on lower-end devices. It was intended for use on mobile originally. And it still supports javascript.

      • by Waccoon (1186667)

        It would help if many paint programs had a default JPEG quality level higher than 70%. That's okay when dealing with 10 megapixel photos that are only shown on the screen or destined for 4x6 prints. Not so nice when dealing with large prints or artwork. I hate seeing Death by JPEG on sites like DeviantArt all the time.

    • by Millennium (2451) on Thursday March 06, 2014 @12:16PM (#46419705) Homepage

      PNG is great for everything but actual photos, and should be used for just that: everything but photos. But photos really do need the extra boost from lossy compression.

  • Now if Firefox could just scale images properly when viewing them.....

  • Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

    I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

    • by oji-sama (1151023) on Thursday March 06, 2014 @11:28AM (#46419163)
      Wikipedia might care.
      • by HetMes (1074585)
        Would be interesting to calculate how much Wikipedia will save because of the delayed purchase of storage, and the slightly less bandwidth use.
    • I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase. It's not a lot, but it is noticeable. However, I'm sticking to PNG for any non-photographic images.

    • by StripedCow (776465) on Thursday March 06, 2014 @11:42AM (#46419303)

      If 2-6% is nothing, why not donate that percentage of your monthly salary to a good cause?

      • by ironicsky (569792)

        I make regular contributions to charitable organizations on a regular basis. It gets deducted from my pay cheque every two weeks :)

      • If 2-6% is nothing, why not donate that percentage of your monthly salary to a good cause?

        Yes, please invest in my new bitcoin exchange. I'm calling it Mt. DevNull. Catchy!

        Incremental improvements in compression are all you are going to get these days. The field is pretty mature, so 2-6% is exciting. Well, to compression geeks.

    • by Zocalo (252965)
      It also reduces the time it takes to write the file out to disk or memory card. That could have a small knock on effect in a number of areas like the burst length on cameras and battery life on mobile devices (assuming that the new codec isn't much more CPU intensive). If the extra 10% compression improvement mentioned in the summary is from photographic images rather than illustrations then that could be quite a significant difference.
    • by Bert64 (520050)

      A few KB saved by an end user on a high speed connection isn't much, but...
      A few KB multiplied by millions of users accessing a single site soon adds up.
      And it's also of benefit to those on slow or metered connections.

    • by DdJ (10790) on Thursday March 06, 2014 @12:00PM (#46419519) Homepage Journal

      The file may be slightly bigger, but who cares.

      Anyone with a metered internet connection. Which is a depressingly large set of people, and signs are that it's going to get larger.

      • by sootman (158191)

        Or anyone who serves gigabytes of content per hour and possibly terabytes per day -- google, facebook, wikipedia, imgur, etc.

    • by hawguy (1600213)

      Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

      I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

      Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

      I'm with the AC in the first post, I use PNG for 90% of my images, since it supports transparency. The file may be slightly bigger, but who cares.

      Slightly better? For full color photographs, PNG is *much* bigger. Anyone that's serving up a lot of images to users cares because of bandwidth and storage costs.

      I picked a random Wikipedia image:

      https://upload.wikimedia.org/w... [wikimedia.org]

      The 1200x900 JPG is around 300KB. I converted to PNG with Gimp, and the resulting file was 1.7MB - almost 6 times larger. The Filesize after converting with Imagemagick was about the same.

      For busy websites, an improvement of 2-6% better jpeg compression can save significant money w

      • by hawguy (1600213) on Thursday March 06, 2014 @12:16PM (#46419695)

        Slightly better? For full color photographs, PNG is *much* bigger. Anyone that's serving up a lot of images to users cares because of bandwidth and storage costs.

        I picked a random Wikipedia image:

        https://upload.wikimedia.org/w... [wikimedia.org]

        The 1200x900 JPG is around 300KB. I converted to PNG with Gimp, and the resulting file was 1.7MB - almost 6 times larger. The Filesize after converting with Imagemagick was about the same.

        For completeness, I took a 94MB full color 6496x4872 TIFF and converted it to PNG (compressionlevel=9) and got a 64MB file. Then compressed the same TIFF to JPG (Quality=90), and got a 7MB file.

        • by AmiMoJo (196126) *

          Has anyone actually tried their code to see how effective it is? I don't have a system to compile it on at the moment.

          • by hawguy (1600213)

            Has anyone actually tried their code to see how effective it is? I don't have a system to compile it on at the moment.

            Seems to work as advertised, if you don't care how long it takes to convert an image.

            I compiled their source and ran their cjpeg against /usr/bin/cjpeg already installed on my system, and it did create jpegs that are 6 - 10% smaller in filesize with the same apparent image quality (I just zoomed in and eyeballed them side by side, I didn't do any extensive analysis).

            However, at a quality level of 75, the Mozilla code took 10 times longer to run, while at a quality level of 90, the Mozilla code took nea

        • Personally, for archive-stuff, I wouldn't go lower then quality=95 which would probably be around a 14MB file (at a guess). Quality of 85-90 is fine for most websites, but you should really archive at 95-98 level.

          Thumbnails can sometimes be pushed as low as 75-80 quality, but you start to notice the JPEG artifacts.
    • You start to care once you multiply those 2% across millions of users. Any savings at such basic level are multiplied by how often the resource is used. So no you don't care about this for your CRUD web application, but wikipedia saving 2% bandwidth translates in one less datacenter required which means thousands of dollars.

    • by Chrisq (894406) on Thursday March 06, 2014 @12:17PM (#46419713)

      Seems like a negligible improvement..

      Yes WebP would be a better choice

      • Webp is amazing (Score:5, Informative)

        by Stepnsteph (1326437) on Thursday March 06, 2014 @02:52PM (#46421419)

        Agreed, it's a much better choice. I actually converted my entire image library to .webp, and I use Irfanview to view the images. The filesize savings were huge, with no visible reduction in quality.

        Some examples:
        4.5 MB JPG -> 109 KB webp
        3.66 MB JPG -> 272 KB webp
        3.36 MB JPG -> 371 KB webp

        One folder of mixed JPGs and PNGs with a total of 169 MBs was converted to webp. the total size of all contents of the folder ("directory", whatever you want to call it) was 6.44 MBs. I was so impressed that I kept records of the results.

        Not only would this be HUGE for sites like Wikipedia, but it also significantly decreased the amount of space that I was using in my cloud storage account.

        Honestly for all of their PR about a better, more open web, all we really get is the same old politics and attempts at controlling what is and is not the standards. They still behave like children. Mozilla, Google, I'm not taking sides. They're both at fault.

        • by fgouget (925644)

          Agreed, it's a much better choice. I actually converted my entire image library to .webp, and I use Irfanview to view the images. The filesize savings were huge, with no visible reduction in quality.

          Some examples: 4.5 MB JPG -> 109 KB webp 3.66 MB JPG -> 272 KB webp 3.36 MB JPG -> 371 KB webp

          It would help to know mor about your experiment. I can get quite big size improvements here by recompressing my camera's (Canon EOS) Jpeg files to... Jpeg! And with no visible quality difference either. They go from 6.7MB for the Canon file, to 3.1MB for quality 90 in imagemagick, 1.7MB for 75 and 1.4MB for 65. And ni your experiment the WebP quality scale may not exactly match the Jpeg one which makes comparisons even harder.

          • by Pseudonym (62607)

            One of the problems with JPEG is that it works (caveat about luma/chroma subsampling) on 8x8 pixel blocks. This is great for medium-resolution images (e.g. 72-200dpi range), but not so great for high-resolution (e.g. 1200dpi).

            I grabbed a 3032x1986 image [wordpress.com] (warning: large image), and here's what I got.

            PNG, compression level 9: 6.1MB
            JPEG 4:4:4 100: 2.7MB
            JPEG 4:4:4 95: 1.2MB
            JPEG 4:0:0 95: 0.9MB
            WEBP 100: 1.5MB
            WEBP 95: 0.5MB

            Note that I have no experience with all of the WebP options. I just used -m 6 -q quality in

    • by gaspyy (514539)

      This is not for the benefit of the users but for webmasters.
      If you have a site with any decent amount of traffic, you pay for bandwidth and you have a content delivery network. 10% smaller images translates into 10% savings.
      Moreover, Google takes site speed into account when ranking sites.

    • Seems like a negligible improvement. I mean really. With hard drive space plentiful, and bandwidth faster than most users can use at any given moment, saving 20-60Kb on a 1Mb file is like a fart in the wind, even for mobile users.

      It would not be worth the effort for one website or even ten. But what is proposed is an improvement to the most commonly used JPEG implementation in the world. The cost will be amortized over millions of websites as software is upgraded over the next few years.

      To see how this works, let's make up some numbers. Lets say that the whole effort will consume $100,000 worth of labor. Let's guess that within five years it will be installed on one million websites. That means it will cost $0.10 per website. Is it

  • My digital camera has horrible compression. I can load and save the pictures with pretty much any application, and the size of the files is reduced significantly without any noticeable image quality reduction. (And yes, I am saving it in the original size.) Maybe it's just my old Sony camera, but it's likely a common issue--I expect embedded compression in consumer devices worries more about simple and fast than best quality for the file size.

    • Do you know that the quality isn't being reduced? An image manipulation program like the GIMP may not make it too clear that it's redoing the lossy part and further reducing quality even if asked to save at the same quality,

      jpegtran is a command line tool that can recompress a jpeg image without changing the quality. If the original compression was poorly done, jpegtran will shrink the file. If jpegtran can shrink your camera's photos, then you know your old camera does a hasty job on the compression.

    • by Splab (574204)

      Does the loading and saving keep EXIF? My camera puts in a lot of EXIF information, stripping it out can save quite a bit of space.

  • by Anonymous Coward

    is what I get from "compatible with the vast majority of decoders".

    Sounds like it breaks something.

  • by Flammon (4726) on Thursday March 06, 2014 @12:17PM (#46419711) Homepage Journal
    The resistance [mozilla.org] to support WebP [google.com] in Mozilla seems to be more politically motivated than technical.
    • by Anonymous Coward

      The resistance [mozilla.org] to support WebP [google.com] in Mozilla seems to be more politically motivated than technical.

      Why not add JPEG-XR as well?

      https://en.wikipedia.org/wiki/JPEG_XR

      • The resistance [mozilla.org] to support WebP [google.com] in Mozilla seems to be more politically motivated than technical.

        Why not add JPEG-XR as well?

        https://en.wikipedia.org/wiki/JPEG_XR

        "JPEG XR[3] (abbr. for JPEG extended range[4]) is a still-image compression standard and file format for continuous tone photographic images, based on technology originally developed and patented by Microsoft..."

        Keyword in bold. Still, a very nice format.

    • Re: (Score:3, Informative)

      The resistance [mozilla.org] to support WebP [google.com] in Mozilla seems to be more politically motivated than technical.

      AMEN!!!! WebP is modern. JPEG, GIF and PNG are all older than most pop stars. Why do we use the image compression equivalent of MPEG1 still?

      Seriously, this is so dumb. I continue using Firefox for two specific reasons (tagged bookmarks and Pentadactyl) but Vimperator and Pocket are making Chrome more tempting. I choose WebP (using the official encoder I build directly from Google's repository) for my online photo storage. Decades of photos and scans I would estimate occupy about 1/8th the space of JPE

    • 0) JPEG is past, present, and near future. Well supported everywhere.

      1) JPEG optimization could be better. Mozilla is doing more of that.

      2) Patents on enhancements to JPEG from minor obvious ones to significant compatibility breakers prohibit improvements. JPEG's final compression step was poor from the beginning and the better stuff was patented and unused. At least a decade ago StuffIt used modern binary compression to replace the final phase, which was exempt from existing patents; however, StuffIt pate

    • by roca (43122)

      Unfortunately WebP isn't all that good for a next-gen format.
      http://people.mozilla.org/~jos... [mozilla.org]

    • by Khashishi (775369)

      Can someone implement support as a plugin? Or is that non-trivial?

  • Maybe this would be good for use with MJPEG for video editing.
  • I would rather see JPEG 2000 support.

Help stamp out Mickey-Mouse computer interfaces -- Menus are for Restaurants!

Working...