Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Mozilla Encoder Improves JPEG Compression

timothy posted about 5 months ago | from the 6-percent's-a-lot dept.

Software 155

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."

cancel ×

155 comments

Sorry! There are no comments related to the filter you selected.

Why aren't we using PNG? (1)

Anonymous Coward | about 5 months ago | (#46419089)

It's not lossy. I try to always use PNG.

Re:Why aren't we using PNG? (5, Informative)

Anonymous Coward | about 5 months ago | (#46419151)

Because PNG is not lossy.

Re:Why aren't we using PNG? (1)

omnichad (1198475) | about 5 months ago | (#46419697)

I wish I had mod points. Thank you.

Re:Why aren't we using PNG? (0)

Anonymous Coward | about 5 months ago | (#46421525)

Because JPEG is good enough and far smaller in many applications than PNGs.

Re:Why aren't we using PNG? (0)

Anonymous Coward | about 5 months ago | (#46421599)

But that's exactly what the parent said.

Re:Why aren't we using PNG? (0)

Anonymous Coward | about 5 months ago | (#46421819)

Yes it is. RTFM.

Re:Why aren't we using PNG? (4, Interesting)

prefect42 (141309) | about 5 months ago | (#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.

JPEG2000 is dead (0)

Anonymous Coward | about 5 months ago | (#46419649)

No other browser maker except Microsoft supports it, and no others even plan to. It doesn't compress better than WebP. Unlike WebP it doesn't have a lossless or paletted/indexed variant. So what is JPEG2000 even for? An alpha channel? With masking and other filter effects arriving in CSS, you can effectively add a selective alpha channel after the fact. Or just use WebP.

Firefox will be supporting WebP as soon as they consider it stable enough. Opera already supports it by moving to Blink. Chrome for Android supports it and consequently so does Android 4.4. If Safari gets it, kiss JPEG2000 goodbye forever. Microsoft simply doesn't control the space enough anymore to dictate features.

Re:JPEG2000 is dead (1)

Blaskowicz (634489) | about 5 months ago | (#46419775)

So, JPEG2000 is dead and WebP not alive yet.

Re:JPEG2000 is dead (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46420159)

Just serve WebP to anything except IE and you're fine. There also appears to be something interesting at http://webpjs.appspot.com/ [appspot.com] .

Re:JPEG2000 is dead (0)

Anonymous Coward | about 5 months ago | (#46420547)

How about you don't do that, and instead consult the browser's accept header like a normal person.

Re:JPEG2000 is dead (1)

Anonymous Coward | about 5 months ago | (#46421679)

Because he's not a normal person, he's a commenter on slashdot.

Re:JPEG2000 is dead (1)

petermgreen (876956) | about 5 months ago | (#46419861)

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.

Re:Why aren't we using PNG? (4, Insightful)

bzipitidoo (647217) | about 5 months ago | (#46419795)

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.

Re:Why aren't we using PNG? (1)

Anonymous Coward | about 5 months ago | (#46420447)

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.

JP2 is used, just not on the web. (1)

RandomUsername99 (574692) | about 5 months ago | (#46420759)

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.

Because it is bigger? (0)

Anonymous Coward | about 5 months ago | (#46419179)

Because it is bigger?

Exactly (0)

davebarnes (158106) | about 5 months ago | (#46419193)

PNG 8 to replace GIFs
PNG 24 to replace JPEGs

Re:Exactly (0)

Anonymous Coward | about 5 months ago | (#46419357)

What is the situation with APNG?

Re:Exactly (5, Informative)

DarkXale (1771414) | about 5 months ago | (#46420081)

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.

Re:Exactly (0)

Anonymous Coward | about 5 months ago | (#46421731)

DEATH TO MNG!

Re:Exactly (0)

Anonymous Coward | about 5 months ago | (#46422479)

It's extra funny now that Mozilla is refusing to implement WebP. What goes around...

Re:Exactly (2)

LordNelsonthe2nd (2817893) | about 5 months ago | (#46419409)

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.

Re: Exactly (1)

ewanm89 (1052822) | about 5 months ago | (#46419513)

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.

Re: Exactly (0)

Anonymous Coward | about 5 months ago | (#46420021)

The type of transparency supported depends on who is defining PNG8. It can mean
8-bit indexed PNG with binary transparency, or it can mean 8-bit indexed PNG with
full transparency.

Usually it means the former because that's all the most common browser supported
back then. The question ocassionally comes up among the ImageMagick/GraphicsMagick
developers. It might be better to refer to the latter as PNG88, but for now we just
call them PNG.

Re:Exactly (1)

Anonymous Coward | about 5 months ago | (#46419707)

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.

Because bandwidth is money (0)

Anonymous Coward | about 5 months ago | (#46419531)

Your source images should always be lossless and very high resolution. For geometric images, you should be using font glyphs for monochrome and SVG for multi-color or filtered content. For animated geometric images, you use SVG+SMIL. For a fallback (stupid Microsoft), you use animated GIF or JavaScript with SVG or canvas. For continuous tone images and some limited cases, you use WebP. For a fallback, you use JPEG for continuous-tone images, i.e,, photographs, and PNG for geometric images. Except for extremely simple and tiny images—less than 500 bytes—in which case GIF wins for size.

Seems like a lot of work, right? Why go through the trouble? Because SVG and font glyphs are commonly 90% smaller than PNG for geometric images. WebP is 10-20% smaller than JPEG. Images (and videos) take up most bandwidth on a site. The bigger the site, the bigger the difference in your bandwidth bill proportionally.

Oh yeah, and optimize those PNGs! pngquant to reduce your color palette when possible. PNGOUT for indexed images. Pngcrush for PNG24 and PNG32. And advpng to re-DEFLATE the output. Or use a program that bundle these tools.

Re:Because bandwidth is money (0)

Anonymous Coward | about 5 months ago | (#46421241)

For animated geometric images, you use SVG+SMIL. For a fallback (stupid Microsoft), you use animated GIF or JavaScript with SVG or canvas.

No need for JavaScript, just convert the SMIL into CSS animation within the SVG [github.io] which works fine in IE10+

Re:Why aren't we using PNG? (5, Informative)

jandrese (485) | about 5 months ago | (#46419619)

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.

Re:Why aren't we using PNG? (1)

TheRealMindChild (743925) | about 5 months ago | (#46420279)

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

Re:Why aren't we using PNG? (1)

jandrese (485) | about 5 months ago | (#46422155)

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 look awful with JPEG and compress awesomely with PNG--lots of big flat color spaces are very nice to a PNG encoder. For photographic images however, JPEG is the way to go. You get effectively the same quality and save a lot of bits. It's all about choosing the right tool for the job.

Re:Why aren't we using PNG? (3, Interesting)

Guspaz (556486) | about 5 months ago | (#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:Why aren't we using PNG? (3, Insightful)

Bob the Super Hamste (1152367) | about 5 months ago | (#46421387)

Because I remember watching graphics load line by line and that sucked.

Re:Why aren't we using PNG? (1)

dryeo (100693) | about 5 months ago | (#46422373)

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.

Re:Why aren't we using PNG? (1)

Waccoon (1186667) | about 5 months ago | (#46422215)

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.

Re:Why aren't we using PNG? (3, Insightful)

Millennium (2451) | about 5 months ago | (#46419705)

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.

Re:Why aren't we using PNG? (0)

Anonymous Coward | about 5 months ago | (#46421119)

I agree.
I use PNG for everything except photos.
For photos I the camera raw format.

Images in Firefox (0)

Larry_Dillon (20347) | about 5 months ago | (#46419097)

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

Seem Negligible (0)

ironicsky (569792) | about 5 months ago | (#46419131)

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.

Re:Seem Negligible (4, Insightful)

oji-sama (1151023) | about 5 months ago | (#46419163)

Wikipedia might care.

Re:Seem Negligible (2)

HetMes (1074585) | about 5 months ago | (#46419405)

Would be interesting to calculate how much Wikipedia will save because of the delayed purchase of storage, and the slightly less bandwidth use.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46420929)

Wikipedia might care.

No. The Wikimedia Foundation only cares about donations and only pays lip service to the Free Content movement. In fact most foundation employees are kinda clueless about the English Wikipedia community and can barely use the software. I wont be surprised if the anti-net neutrality Wikipedia Zero comes to AT&T sponsored data.

Off the top of my head, examples of MediaWiki file bloat: If the color profile exists it is included with all thumbnails, so a 4 KB 40x40 thumbnail has a 200 KB color profile included. Scaled down pixel art or two tone images may be larger than their source image since "we're traded spatial resolution for spatial detail". Of course ImageMagik (as most photo software) doesn't gamma correct images [4p8.com] (all of his examples are Wikimedia Commons images). And while I haven't looked too closely at the file output recently, PNGs included a full 8-bit alpha channel.

There's also a CPU concern as thumbnails are rendered and cached on the fly. I know when I did the absurd overhead report (We found a few .RAR as JPEGs) that pngout was a significant bottleneck in generating the report.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419205)

Says the person who has no idea what the cost is to serve up content.

Re:Seem Negligible (1)

petermgreen (876956) | about 5 months ago | (#46419935)

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.

Re:Seem Negligible (1)

Anonymous Coward | about 5 months ago | (#46420115)

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.

Re:Seem Negligible (1)

Bengie (1121981) | about 5 months ago | (#46420897)

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.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419265)

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.

Anyone who has to serve thousands or tens of thousands of images will absolutely care. Their disk space requirements, bandwidth and the client's load time are all reduced. 10% is a noticeable is the threshold where change becomes noticeable.

Re:Seem Negligible (1)

ironicsky (569792) | about 5 months ago | (#46419441)

But it isn't 10%, its 2-6% :)

But I see the point, with large numbers of files served, it can add up.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419273)

1. People on Sat-links
2. People on mobile devices
3. People on dial-up
4. People running image heavy sites
5. People coding for contstrained environments (read: embedded devices)
6. Anyone who's answer to resource management isn't "throw more money at it"

*draws breath*

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419455)

To the narrow segment of people who have a kick ass computer, kick ass network (oc numbers you didnt know existed), and lots of free time. Then yes this is negligible.

If you have thousands of pictures that come in around 40 gig 10% is 4 gig. 4 gig of space you can do something *else* with. 4 gig of network space you can do something else with. 4 gig of data that did not need to be shoveled thru your server cpu. 4 gig of data that does not need to be read off the hard drive. Your end customer sees the data 10% faster.

Yeah this is a terrible idea who would want to get their data faster?! /sarcasm

Even the built in encoders for most PNG encoders are semi awful using zlib. I run them thru a few utils that give back the same image but compressed better.

jpegtran is a good util for shaving 5-10% off most jpegs out there.
pngout is pretty good for shaving 5-10% off most pngs out there.

Same picture no loss of quality just compressed differently.

Re:Seem Negligible (2)

petermgreen (876956) | about 5 months ago | (#46420007)

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).

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46420663)

jpegcrop (which started using arithmetic coding by default).
Yeah one of the reasons I ended up with jpegtran. I use the 'change no settings' bit. So you end up with the same type of jpeg you started with. You can have it change types though to get more out of it.

Keep in mind many cameras use extremely low compression settings (but tend to use high settings in data loss with acceptable image loss). Because the cpu is rather weak in them. So they try to bash it out as fast as they can the flash.

jpegcrop actually changes the image. Which was one of my reasons for not using it.

Re:Seem Negligible (1)

DarkXale (1771414) | about 5 months ago | (#46420317)

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.

Re:Seem Negligible (1)

SJHillman (1966756) | about 5 months ago | (#46419289)

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.

Re:Seem Negligible (3)

wonkey_monkey (2592601) | about 5 months ago | (#46421317)

I found switching large photographs on my site from png to jpeg led to a noticeable loadtime increase.

Decrease?

Re:Seem Negligible (2)

SJHillman (1966756) | about 5 months ago | (#46421537)

*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.

Re:Seem Negligible (4, Insightful)

StripedCow (776465) | about 5 months ago | (#46419303)

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

Re:Seem Negligible (1)

ironicsky (569792) | about 5 months ago | (#46419353)

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

Re: Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46421415)

Your government and insurance company are not charitable organisations.

Re:Seem Negligible (-1)

Anonymous Coward | about 5 months ago | (#46419385)

Why don't I donate my foot into your ass...

Re:Seem Negligible (1)

ThatsDrDangerToYou (3480047) | about 5 months ago | (#46419393)

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.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419749)

Cause the goverment already sucks 60%

Re:Seem Negligible (1)

Zocalo (252965) | about 5 months ago | (#46419319)

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.

Re:Seem Negligible (2)

Bert64 (520050) | about 5 months ago | (#46419359)

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.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419413)

Sounds like you've never been downwind of Cowboy Neal two hours after gorging at Taco Bell. The stench is unbearable.

Re:Seem Negligible (4, Insightful)

DdJ (10790) | about 5 months ago | (#46419519)

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.

Re:Seem Negligible (1)

sootman (158191) | about 5 months ago | (#46419893)

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

Re:Seem Negligible (1)

hawguy (1600213) | about 5 months ago | (#46419607)

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 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.

Re:Seem Negligible (5, Informative)

hawguy (1600213) | about 5 months ago | (#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.

Re:Seem Negligible (1)

AmiMoJo (196126) | about 5 months ago | (#46420113)

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.

Re:Seem Negligible (1)

Daniel Hoffmann (2902427) | about 5 months ago | (#46419693)

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.

Re:Seem Negligible (4, Insightful)

Chrisq (894406) | about 5 months ago | (#46419713)

Seems like a negligible improvement..

Yes WebP would be a better choice

Webp is amazing (5, Informative)

Stepnsteph (1326437) | about 5 months ago | (#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.

Re:Seem Negligible (0)

Anonymous Coward | about 5 months ago | (#46419741)

Sure, for YOU. But what about people with limited bandwidth, cpus, and so forth? They care, and even a 10% savings on an image-intensive site (say, a lame mobile phone's gallery app) can make a huge difference over time. A few k quickly becomes a few megs. So if the price to get there is "just use a drop-in replacement for your jpeg encoder" then I say to hell with your doubts - I'll take even a seemingly-negligible improvement, not for me, but for my users.

Re:Seem Negligible (1)

gaspyy (514539) | about 5 months ago | (#46419959)

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.

Re:Seem Negligible (1)

Давид Чапел (3032005) | about 5 months ago | (#46420425)

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.

Can't wait (-1)

Anonymous Coward | about 5 months ago | (#46419155)

Until they add tab groups and web sync to it.

I wish they'd fix the memory leaks some day

Re:Can't wait (0)

Anonymous Coward | about 5 months ago | (#46419683)

Yesterday [mozilla.com]

Still patented? (-1)

Anonymous Coward | about 5 months ago | (#46419165)

I thought the world moved on from JPEG a long time ago.

Re:Still patented? (2)

tepples (727027) | about 5 months ago | (#46419337)

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").

Reminds me of dialup (0)

Anonymous Coward | about 5 months ago | (#46419249)

In the dialup days you could use your ISPs web proxy that would super compress images using some proprietary version of JPEG (M-JPEG?) so that you'd get adequate quality and maybe 20x the compression.

These days people have 25mbit, 50mbit, 150mbit Internet connections so I wondered if it really matters? Then I realized yes it does because many websites stopped caring about how many MEGABYTES of stuff you have to download just to look at one page. Our local TV news had a store on it last year. There is an effort to help a large rural area to get high speed Internet, and they were showing how slow it is to load a single page on modern websites using dialup. Some pages could take 4 - 5 minutes to display. I remember how slow dialup used to be, and it wasn't that bad before. People put large images without caring about compression on their pages these days.

Cellular (1)

tepples (727027) | about 5 months ago | (#46419367)

Not only rural areas. Tablets nowadays have more pixels than HDTV, yet cellular plans still have a single digit GB per month cap.

Re:Cellular (0)

Anonymous Coward | about 5 months ago | (#46419449)

I've seen how web designers do it. They make a really fancy PICTURE of what a web page should look like, and then use Adobe tools to automatically slice and output HTML, images, CSS, etc. Often when I work with web designers they just give me a picture of what it should look like and I have to manually craft the HTML, CSS, crop images, etc.

Re:Reminds me of dialup (1)

Blaskowicz (634489) | about 5 months ago | (#46419863)

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.

Re:Reminds me of dialup (0)

Anonymous Coward | about 5 months ago | (#46420881)

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.

In a rural area? Where your nearest neighbor is hundreds of feet away, well outside wifi range? Where if you don't have broadband, your neighbor certainly doesn't either? Or did you mean make the 30-45 minute drive out to the nearest McDonalds to use their wifi to check the news?

Compression/decompression speed/CPU cycles? (0)

Anonymous Coward | about 5 months ago | (#46419323)

What's the cost in time and/or CPU cycles for the 2-6% gain in compression?

Needed for Digital Cameras (1)

crow (16139) | about 5 months ago | (#46419343)

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.

Re:Needed for Digital Cameras (0)

Anonymous Coward | about 5 months ago | (#46419403)

I reckon it is your old Sony camera that is the problem

Re:Needed for Digital Cameras (1)

bzipitidoo (647217) | about 5 months ago | (#46419595)

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. Yes, it is a common issue. Lot of these compression improvers work by more deeply exploring more choices in the compression algorithm, which takes more computing. That's how 7zip improves on zip and gz files.

Re:Needed for Digital Cameras (1)

Splab (574204) | about 5 months ago | (#46420365)

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.

GO ASCII ART !! (-1)

Anonymous Coward | about 5 months ago | (#46419443)

And never look at pr0n then same way again !!

http://goat.cx/asc/ [goat.cx]

Compatible with all except what you want to use, (2, Interesting)

Anonymous Coward | about 5 months ago | (#46419473)

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

Sounds like it breaks something.

I wish they would focus on WebP instead (4, Interesting)

Flammon (4726) | about 5 months ago | (#46419711)

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

JPEG XR (1)

Anonymous Coward | about 5 months ago | (#46420009)

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

Re:JPEG XR (2)

Negroponte J. Rabit (2820825) | about 5 months ago | (#46421081)

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:JPEG XR (0)

Anonymous Coward | about 5 months ago | (#46421689)

Excellent that you know how to read! Now, if your attention span was not limited to five paragraphs, maybe you could scroll down to the "License" section where it says how those patents affect you?

Re:I wish they would focus on WebP instead (3, Informative)

Negroponte J. Rabit (2820825) | about 5 months ago | (#46420349)

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 JPEG with little perceptual difference. WebP really shines on very clean, noise-free images and occasionally I'll have 5 megapixel images compress down to under 200kb (variable block compression, it's the 21st century.

Few points about WebP. It might be nice for Google to fix encoder crashes with extremely large images, and maybe improve that GIF2WEB converter.

It is nice that Google provides an installer that makes Windows transparently handle WebP. Would love to see better support for it in KDE apps.

Re:I wish they would focus on WebP instead (0)

Anonymous Coward | about 5 months ago | (#46421269)

It seems only Google hasn't realised how awful VP8 is yet.

MJPEG (1)

LarryRiedel (141315) | about 5 months ago | (#46420847)

Maybe this would be good for use with MJPEG for video editing.

Use JPEG2000 instead (1)

MobyDisk (75490) | about 5 months ago | (#46421673)

I would rather see JPEG 2000 support.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>