Slashdot Mirror
New Mozilla Encoder Improves JPEG Compression
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."
It's not lossy. I try to always use PNG.
Wikipedia might care.
It is what it is.
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.
If 2-6% is nothing, why not donate that percentage of your monthly salary to a good cause?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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.
UNIX? They're not even circumcised! Savages!
Where in the article are you getting anything about patents? The innovation here is to try multiple orders of sending the DCT coefficients ("figuring out which progressive coding configuration uses the fewest bits").
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.
I make regular contributions to charitable organizations on a regular basis. It gets deducted from my pay cheque every two weeks :)
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Not only rural areas. Tablets nowadays have more pixels than HDTV, yet cellular plans still have a single digit GB per month cap.
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.
Would be interesting to calculate how much Wikipedia will save because of the delayed purchase of storage, and the slightly less bandwidth use.
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.
But it isn't 10%, its 2-6% :)
But I see the point, with large numbers of files served, it can add up.
is what I get from "compatible with the vast majority of decoders".
Sounds like it breaks something.
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.
Anyone with a metered internet connection. Which is a depressingly large set of people, and signs are that it's going to get larger.
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...
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 without changing the user experience at all.
I used to save my camera images as loss-less TIFF's or RAW's, but as my camera megapixels grew, the image sizes did too, and now I have so many megapixels that I don't even care that I'm throwing away some image quality by only saving JPG's... and I found that I rarely go back to edit older photos, I just look at them, or sometimes reprint them. No need to store files in a huge lossless format for that.
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.
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...
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.
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.
The resistance to support WebP in Mozilla seems to be more politically motivated than technical.
ayottesoftware.com
Seems like a negligible improvement..
Yes WebP would be a better choice
So, JPEG2000 is dead and WebP not alive yet.
JPEG is good enough that there is little motivation to build browser detection to serve up different formats to different browsers. So unless MS decides to support webp I don't see it taking off.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
These days people can use some wifi instead of paying for their own net connection. The resulting speed is highly situational but can be e.g. 70 to 90 KB/s downloads or less.
Or anyone who serves gigabytes of content per hour and possibly terabytes per day -- google, facebook, wikipedia, imgur, etc.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Serving static files is pretty cheap nowadays.
The main reason to keep image filesizes down on the web is to make life easier for those end users who are stuck on crappy dialup or cellular connections.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
jpegtran is a good util for shaving 5-10% off most jpegs out there.
Something to watch for with jpeg, "arithmetic coding" reduces your filesize compared to "huffman coding" but it also reduces compatibility. It caused me a fair bit of head scratching trying to work out why pdflatex wouldn't accept the jpegs that came out of jpegcrop (which started using arithmetic coding by default).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The resistance to support WebP in Mozilla seems to be more politically motivated than technical.
Why not add JPEG-XR as well?
https://en.wikipedia.org/wiki/JPEG_XR
A mess. Google refuses to have anything to do with APNG, preferring MNG instead. Firefox and Opera (up to v12) support APNG - but not MNG. Safari and IE supports neither.
General image software support is poor for both.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Thus reducing the cost of the content for the end user, especially for those who are stuck on metered bandwidth.
Such reading comprehension failure is inexcusable. Clearly you also do no have an understanding of end-to-end costs.
Just serve WebP to anything except IE and you're fine. There also appears to be something interesting at http://webpjs.appspot.com/ .
Ezekiel 23:20
Its also worth to remember than for congested systems, a single percentage reduction in traffic will yield a significantly higher percentage improvement in service speed. 90% congestion to 85% congestion gives a huge reduction to average waiting times.
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 worth spending $0.10 per website to reduce the bandwidth use (and increase speed of loading) by a few percent?
As others have pointed out, improvements to this JPEG compressor would not reduce the size of existing static images. But it would help with images which are under the control of some kind of content managment system which recompress the images. Nowadays almost all non-trivial websites fit that description.
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.
Maybe this would be good for use with MJPEG for video editing.
For most, bandwidth is cheap and change is expensive in many ways, but a 10% difference is decent. I think people forget how useful periodic increases in efficiency is quite useful in the long run. So much of what we obsess about is not being more efficient, but faster. A 10% increase in efficiently for CPUs is easy to appreciate for less power usage, but bandwidth is much harder.
I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase.
Decrease?
systemd is Roko's Basilisk.
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.
*facepalm* Yes, that would be the word I was looking for. They had me answering the Helpdesk phone today, so my brain is a little fried from too much user interaction.
I would rather see JPEG 2000 support.
Because he's not a normal person, he's a commenter on slashdot.
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 nearly 20 times longer to run.
I only tested with a few images (with the lossless .ppm file ranging from 2MB to 90MB), so this was by no means a comprehensive test.
If your bandwidth as a provider of content is costing you 400K and you can reduce it by 1% by just using a new image standards, that's a nice 4K saving per year just on service. Now you have to decide if saving 4K will cost you more than 4K. In some cases it's not about saving money but rather avoiding the need to upgrade hardware and infrastructures.
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 patented this idea... it increased compression by 20-30% with no loss.
3) JPEG 2000 used a more modern encoding process probably similar to VP8 as far as the quantization and color space handling. Nobody uses JPEG2000 even though the smarter encoding makes compression artifacts less noticeable. The file size was not much smaller for all that extra RAM and CPU it took over JPEG - plus incompatibility. probably patents involved with it's demise as well.
4) Yet another JPEG replacement by a big corp... When everybody has MORE bandwidth, faster computers, and unimaginably more storage space on their smart phones than their desktops had in the late 90s. Why limit yourself with an obscure format to gain 30% more space when the storage you buy on sale at the end of this year will easily be 30% bigger than last year.
How much more CPU / watts will WebP cost you over JPEG?
I don't care how good it is; it has to be patent free, widespread, and proven.
Democracy Now! - uncensored, anti-establishment news
Note that in paletted png files transparency is always handled by specifying alpha values for palette entries. Even if you are only doing simple binary transparencys so on a format level there is no real difference, it's just that some old browsers can't handle partially transparent palette values correctly.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I thought the world moved on from JPEG a long time ago.
Either you are trolling or you operate in some strange niche that is isolated from the rest of the world
Back in the real world jpeg is by far the dominant format for lossy compression of photographic images. The wide compatiblity of jpeg has outweighed the advantages of more modern formats.
Still patented?
There have been a number of patent claims against baseline jpeg over the years but afaict none of them have really stuck.
There was also previously a patent on the optional arithmetic coding feature but that has since expired.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
It can mean
8-bit indexed PNG with binary transparency, or it can mean 8-bit indexed PNG with
full transparency.
IIRC in the format itself there isn't really a distinction, PNG transparency for indexed images is always handled by specifying alpha values for palette entries. It's just old versions of IE fail to handle them correctly.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I didn't want to get into details, but over here semi-private hotspots are popular and pretty ubiquitous (a significant subset of ISP provided routers double as a secure hotspot that doesn't interfere with the main user's home network). You them need codes related to the ISP at hand (some login/password). The use cases are if your DSL/broadband is down, or if your are on the move, or for "unofficial" use.
So that works in urban areas actually. Wifi isn't necessarily great if you connect to some router in the neighborhood, it goes through walls and perhaps congested spectrum and your transfer rates are limited and QoS'ed anyway. Still it can be very decent (with outage sometimes, high latency sometimes, low latency other times)
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.
Chrome doesn't have native MNG or APNG right now. They only support APNG through a plugin. Which is a shame because I am sick of seeing 256 color animated GIFs everywhere.
..... a new format that doesn't seem like it will ever be feature-complete.
What features do you see WebP lacking. It uses the RIFF container format that allows XMP metadata, which itself can include EXIF data. It includes lossless and lossy modes, animation and alpha channel (transparency). What do you think is missing?
What features do you see WebP lacking
Ability to be displayed on most browsers?
Write boring code, not shiny code!
JPEG is the MP3 of images. Goo enough and so ubiquitous that nobody even tries to compete anymore.
Write boring code, not shiny code!
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.
Wolde you bothe eate your cake, and have your cake?
What features do you see WebP lacking
Ability to be displayed on most browsers?
Not really a limitation of WebP any more than "ability to be owned by most adults" would be a limitation of a Ferrari
So the price wouldn't be a limitation of the Ferrari? Well, it's up to you to ignore what most would consider the first limitation of the object... but still...
If WebP was available in all browsers like GIF, PNG and JPG, I would've had a deeper look into it. It's not. I couldn't care less about this file format. What use could I possibly find for it? What purpose does it serve for anyone? If you need lossy, go JPG. If you need lossless, go PNG. WebP doesn't fit any scenario...
Write boring code, not shiny code!