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."
Because PNG is not lossy.
Wikipedia might care.
It is what it is.
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.
jh
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.
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").
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!
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.
is what I get from "compatible with the vast majority of decoders".
Sounds like it breaks something.
Anyone with a metered internet connection. Which is a depressingly large set of people, and signs are that it's going to get larger.
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.
I read the internet for the articles.
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.
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.
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
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.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
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
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.
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?
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
"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.
I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase.
Decrease?
systemd is Roko's Basilisk.
Because I remember watching graphics load line by line and that sucked.
Time to offend someone
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.
Yes, and he's pointing out that the exact thing the parent said as an advantage for PNG is also its disadvantage.
A lossless compression format cannot compete with a good lossy compression format in terms of file sizes for arbitrary content, even though it wins by definition in terms of fidelity. The web, even today, is very bandwidth constrained and thus file sizes are one of the most important things to optimize against, for both the client and the server. Fidelity is often not a very important consideration.
But why have the many successors to jpg that provide better lossy compression not caught on?
Without getting into a full-blown Doctoral Thesis, it's usually because either they suffer performance issues, or don't do nearly as good a job of preserving the visual integrity of the source image. JPG is a good balance of speed, quality preservation, and size of the compressed file.
Nah, I think it's mostly because JPEG is good enough. JPEG2000, for example, also provides perfectly acceptable performance and quality, with significantly-reduced file sizes. But unlike JPEG, JPEG2000 decoders aren't already available everywhere. The slightly-reduced file size isn't sufficient justification for the risk that some users might not be able to see the photo. An improved JPEG encoder helps (a little) with file size without incurring the need for a new decoder, so it's immediately useful.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I think it's mostly because JPEG is good enough. JPEG2000, for example, also provides perfectly acceptable performance and quality, with significantly-reduced file sizes. But unlike JPEG, JPEG2000 decoders aren't already available everywhere.
It's the fax-machine effect, JPEG will be around forever because everything, and I mean everything, that creates, processes, manipulates, and displays images, speaks JPEG. If Jobs was still alive and decided that from now on iWhatever's were only going to do JPEG2000 (and it's not just for file size reasons, image quality is also vastly improved), you can bet that we'd have a surge in JPEG2000 adoption as soon as the first JPEG2000-only iWhatever was released.
(Personally I'd opt for JPEG-XR, which is more flexible than JPEG2000, addressing the 20-odd-years' worth of issues that have emerged since the original JPEG first saw widespread adoption, but since it was developed by Microsoft I'm nervous even mentioning it here. You never saw these lines, move along, move along...).
JPEG XR is actually quite good and is now an open standard. I recently did an extensive evaluation of JPEG 2000 vs. JPEG XR. While JPEG 2000 has slightly better compression quality (less visible artifacts) at the same file sizes it’s decode performance is substantially slower than JPEG XR (the same is true for encode performance, but decode is much more important). In my testing, one of the fastest JPEG 2000 libraries, Kakadu, is anywhere from 1.8 to 2x slower than JPEG XR at decoding files. Kakadu is a commercial framework, the open source OpenJPEG library is supposed to be substantially slower.
Compared to standard JPEG, JPEG XR has on average the same or very similar decode performance. The bottom line is that with JPEG XR you get compression quality and file sizes that are similar to JPEG 2000 with performance that is similar to standard JPEG. In my eyes, it’s the best successor available to replace JPEG. But it has a long uphill battle ahead of it.
infested with jello like fishes no melotron wishes