Slashdot Mirror


Mozilla Doubles Down on JPEG Encoding with mozjpeg 2.0

An anonymous reader writes: Mozilla today announced the release of mozjpeg version 2.0. The JPEG encoder is now capable of reducing the size of both baseline and progressive JPEGs by 5 percent on average (compared to those produced by the standard JPEG library libjpeg-turbo upon which mozjpeg is based). Mozilla today also revealed that Facebook is testing mozjpeg 2.0 to see whether it can be used to improve the compression of images on Facebook.com. The company has even donated $60,000 to contribute to the ongoing development of the technology.

129 comments

  1. Hard to get excited. by tysonedwards · · Score: 1, Interesting

    Sorry, it is hard to get excited about marginal improvements in still raster image compression. Yes, rasters are really important and everything, but at the same point images themselves are so absurdly small already compared to the likes of video technologies, and video is the vast majority of the internet. Seems like a better use of their time to focus on making HEVC or VP9 more capable.

    --
    Thirty four characters live here.
    1. Re:Hard to get excited. by Anonymous Coward · · Score: 5, Insightful

      5% of image bandwidth saved for someone like Facebook is millions of dollars in operating expense. Get a clue.

    2. Re:Hard to get excited. by gstoddart · · Score: 2

      and video is the vast majority of the internet

      And yet, you're posting that on a web site which is mostly text.

      I suspect a 5% decrease in size yields a very large percentage in bandwidth savings over time.

      And there will always be people with slower links who will benefit from this.

      --
      Lost at C:>. Found at C.
    3. Re:Hard to get excited. by tysonedwards · · Score: 5, Insightful

      And when Facebook is saying that only 1.48% of their bandwidth is going towards images. That puts said reduction 5% reduction at a new percent of 1.41% at the expense of increased CPU time to transcode all existing images, which is itself not free. It is a marginal savings, even for an organization the size of Facebook. It certainly adds up over time, which is great, but when there is really great low hanging fruit like cutting the 37% of their bandwidth used on videos by 20-30% by getting HEVC or VP9 really working well (would then be 26% total), then that is a way to save significant money not just in Bandwidth but in Disk Space for retention as well.

      --
      Thirty four characters live here.
    4. Re:Hard to get excited. by Sigma+7 · · Score: 1

      video is the vast majority of the internet. Seems like a better use of their time to focus on making HEVC or VP9 more capable.

      Most videos (at least those linked to from meme-based image sites) are stored in GIF format, despite them taking twenty times the bandwidth/file size of the Youtube video they're based on.

      Thus the best way to save space/bandwidth is to find a way to optimize compression of .GIF files.

    5. Re:Hard to get excited. by gstoddart · · Score: 1

      But what fraction of videos on Facebook are actually served by Facebook?

      Most of what I see on Facebook is just links to external sites, and Facebook doesn't host it at all.

      --
      Lost at C:>. Found at C.
    6. Re:Hard to get excited. by mythosaz · · Score: 3, Funny

      I should use a smaller font then, I think.

    7. Re:Hard to get excited. by gstoddart · · Score: 3, Funny

      Totally, going from 12pt to 10pt is a 20% savings. Got for a 6pt font and you can save 50%.

      Add that to the 5% savings in the jpegs, and that's a lot of extra porn you can download before you fill the tubes.

      --
      Lost at C:>. Found at C.
    8. Re:Hard to get excited. by Anonymous Coward · · Score: 0

      Better would be to ditch GIFs for webm. GIFs are lossless and the format doesn't lend itself well to recorded video, no matter how optimized the compression. Any significant improvement would require the format itself to change.

    9. Re:Hard to get excited. by omnichad · · Score: 3, Insightful

      ...low hanging fruit like cutting the 37% of their bandwidth used on videos by 20-30% by getting HEVC or VP9 really working well

      If they wanted to tackle the low-hanging fruit, why not stop auto-playing video at all?

    10. Re:Hard to get excited. by Daniel+Hoffmann · · Score: 1

      Don't some video codecs use JPEG algorithms to encode the i-frames? This could translate in better video compression too.

    11. Re:Hard to get excited. by gstoddart · · Score: 1

      If they wanted to tackle the low-hanging fruit, why not stop auto-playing video at all?

      Ad revenue.

      --
      Lost at C:>. Found at C.
    12. Re:Hard to get excited. by Charliemopps · · Score: 3, Interesting

      And when Facebook is saying that only 1.48% of their bandwidth is going towards images. That puts said reduction 5% reduction at a new percent of 1.41% at the expense of increased CPU time to transcode all existing images, which is itself not free. It is a marginal savings, even for an organization the size of Facebook. It certainly adds up over time, which is great, but when there is really great low hanging fruit like cutting the 37% of their bandwidth used on videos by 20-30% by getting HEVC or VP9 really working well (would then be 26% total), then that is a way to save significant money not just in Bandwidth but in Disk Space for retention as well.

      I deal with this sort of thing all day at work... you're not appreciating the scale of small adjustments.
      For example: I recently got asked to approve an upgrade to internet explorer on an enterprise network.
      I tested, and replied back that In one application, there was a 3 second delay in opening records. I declined approval and said this issue would have to get fixed before I could sign off on it.

      Lots of managers had your attitude... it's only a 3 second delay!

      So I had to present my reasoning in a meeting to explain:
      We have approximately 1000 users that will be affected.
      They each open, on average, 100 records per day.
      They get paid an average of $15/hr
      1000 users times 100 records = 100,000 records per day
      Times 3 seconds = 300,000 seconds
      Divided by 60 = 5000 minutes
      Divided by 60 again = 83.33hrs
      Times $15/hr = $1250

      Not fixing that issue would cost the company roughly $1250 per day!
      It's nearly a half a million dollar per year problem!
      The fix is an increase in memory that would cost the company a 1 time charge of less than $20k.

      Scale matters.

    13. Re:Hard to get excited. by Russ1642 · · Score: 2

      Any company that can save millions from something this small is so big that millions don't mean anything.

    14. Re:Hard to get excited. by nickittynickname · · Score: 1

      You know facebook owns instagram right?

    15. Re:Hard to get excited. by omnichad · · Score: 1

      There is no ad revenue to be made from a video recorded by a friend starting to play automatically in my feed. It plays the video, not an ad.

    16. Re: Hard to get excited. by Kumiorava · · Score: 1

      Even the biggest companies care about million(s). Reduction in operating expenses are always a good thing and if facebook can shave off million dollars a year without significant downsides they will take it gladly. Big companies didnt get big by being inefficient.

    17. Re:Hard to get excited. by makq · · Score: 1

      And this is a great demonstration of why people hate IT departments.

    18. Re:Hard to get excited. by Gerald · · Score: 1

      Most of the pages on my web sites have a combination of PNG and JPEG content and almost no video. Smaller images means faster page load times for my users.

    19. Re:Hard to get excited. by gstoddart · · Score: 1

      I am aware of that fact, yes.

      However, never having seen or given a damn about Instagram ... I have no idea of it supports videos or not.

      I would have to take extra steps to watch videos on the internet.

      Like installing Flash or caring. Thus far, I've done a remarkable job of doing neither.

      --
      Lost at C:>. Found at C.
    20. Re:Hard to get excited. by Anonymous Coward · · Score: 0

      I doubt your bandwidth analysis is the most important issue. The storage of images is a large footprint overhead issue, and consumes a great deal of electrical power, for disks, cpus, network switches, airconditioning, and lighting (of the floorspace). Depending on availability and purchasing, that might translate to fossil consumption and greenhouse emissions, or uranium consumption and nuclear waste - at the very least it reduces the amount of electricity available to the general market. All that is improved by better compression.

      And who says the increase in CPU time isn't worth it? Usually compression efficiency increases are divided into online image analysis, taking CPU cycles, and algorithm decision thresholds tuning, taking no CPU cycles. The cost on the threshold tuning is the up front engineering, amortized over usage. So not all the improvement comes at cost of CPU cycles.

    21. Re:Hard to get excited. by wonkey_monkey · · Score: 1

      Luckily we don't care, because we're right.

      --
      systemd is Roko's Basilisk.
    22. Re:Hard to get excited. by radish · · Score: 1

      Don't forget storage. Bandwidth is one thing, but image storage is a big deal for sites like FB. They often store multiple copies of each one (e.g. at different sizes) and then you also have copies cached on CDNs etc, which also costs money. 5% isn't going to make or break the company, but it's worth investigating.

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    23. Re:Hard to get excited. by SuricouRaven · · Score: 1

      Yes. I've written a program that achieves a similar saving for PNGs and other lossless formats by making them very slightly lossy (It actually works by slightly adjusting the boundary between quantization bands, so no pixel ever changes value by more than a tiny, definable amount). What happens to it? No-one wants something like that, so it joins all my other dabbling in obscurity.

    24. Re:Hard to get excited. by aardvarkjoe · · Score: 1

      Most videos (at least those linked to from meme-based image sites) are stored in GIF format...

      While I don't disagree that the storing videos in GIF format is incredibly inefficient (and annoying), I somehow don't think that "meme-based image sites" are actually a significant fraction of internet bandwidth use compared to websites that use more standard video formats.

      --

      How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    25. Re:Hard to get excited. by BronsCon · · Score: 1

      You know the Instagram app could do the image compression client-side, right? This would help there, as well, without costing Facebook a single extra CPU cycle.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
    26. Re:Hard to get excited. by TechyImmigrant · · Score: 2

      Luckily we don't care, because we're right.

      No, you are wrong. This kind of analysis was debunked before I got to college 30 years ago.

      Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.

      If your analysis is so great why aren't you advocating moving to technologies that take less time to bring up a record? Or pre-loading the next record, or anything to save your oh-so precious 300 seconds per worker. I'm glad I don't work in your sweatshop.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    27. Re:Hard to get excited. by Selur · · Score: 1

      so donating 60k isn't really much,..

    28. Re:Hard to get excited. by Anonymous Coward · · Score: 0

      Unless you're doing analytic work, you shouldn't have to wait 3 seconds to retrieve data.

    29. Re:Hard to get excited. by retchdog · · Score: 1

      this kind of thing probably does help, but, yeah, not because of the magical linear time bank.

      rather, something that keeps the user's attention often means less coffee breaks and chit-chat. waiting sucks.

      --
      "They were pure niggers." – Noam Chomsky
    30. Re:Hard to get excited. by stewsters · · Score: 1

      Who's to say they don't have a few coders working on better video codecs? They seem at least to be hiring for video chat: https://www.facebook.com/caree... Every bit counts with a site their size. Google doesn't even close its tags.

    31. Re:Hard to get excited. by Thud457 · · Score: 3, Insightful

      They just ripped this off from Pied Piper. Probably can't even handle 3D video properly.

      aw crap, I have shamed myself.

      --

      the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

    32. Re:Hard to get excited. by tlhIngan · · Score: 1

      Just because something on the computer takes more or less time doesn't mean the user isn't adapting and overlapping other behaviors during those 3 seconds. Do a controlled experiment and come back when you have real data.

      3 seconds is long enough to be annoying, and short enough that an annoyed user will take longer than 3 seconds.

      After the update, they'll waste 3 seconds each time. Then after a week, they'll use those 3 seconds to respond to a text on their cellphone, or an IM, or browse Facebook. So now that 3 second time takes 20 seconds to a minute because the user got bored waiting, switched to something else, then switched back much later.

      So now that 3 seconds cost up to 60 seconds.

      And if that happens often enough (100 minutes is over an hour), that 100 records may turn into 90 records.

      Of course, it makes the assumption that the record opening time is instant - you click it, and it responds instantly. Now you click it and wait. Which makes a huge difference - it actually gives the appearance of slowness if you clicked and it instantly displayed versus you clicked and now have a wait. Most users would find a way to occupy themselves in that wait that takes far longer than 3 seconds.

    33. Re:Hard to get excited. by tepples · · Score: 1

      Good luck getting Apple to add WebM support to iPod touch, iPhone, or iPad.

    34. Re:Hard to get excited. by Belial6 · · Score: 1

      Your math is a lie.

    35. Re:Hard to get excited. by Anonymous Coward · · Score: 0

      Well maybe you(r) right, those three seconds can occur at a frequency of say once a minute where at the end of the day no significant human time was lost. If the same amount of work is done but with some unecessary task switching pain to the human then no. If they're worked balls to the wall like rented mules, then yes.

    36. Re:Hard to get excited. by narcc · · Score: 1

      Perhaps it's because no one (importnat) has seen it? Put together a paper for the relevant ACM SIG conferences.

    37. Re: Hard to get excited. by bill_mcgonigle · · Score: 1

      so, apparently it's only worth $60k to them.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    38. Re:Hard to get excited. by TechyImmigrant · · Score: 1

      If the user opens a record and waits 3 seconds then spends 30 seconds staring at the record or typing in it or talking to a customer, then the UI is messed up.
      The computer is pretty idle in the subsequent 30 seconds and can be loading the next form in the background.

      The people who use my PoS like it not because of it's neato use of python and ncurses. They like it because it responds instantly, is very non modal and never required more than two or three keystrokes to complete a transaction. If you are paying 1000 people to use your badly designed UI, you need to fix the UI first.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    39. Re:Hard to get excited. by ArcadeMan · · Score: 1

      But can your program beat the compression done by ImageOptim and ImageAlpha?

    40. Re:Hard to get excited. by Bite+The+Pillow · · Score: 1

      Why would they transcode all existing images? They could re-scale the thumbnails, but they wouldn't dare touch the originals unless they were so massive it made sense to give it a go.

      Thumbnails for new images, ignoring existing ones, would more than pay off in just one more world cup, simply by replacing the existing implementation with this one.

      So let me re-phrase. Mozilla open source people who can work on stuff because they want to, or can attribute some generic benefit, have teamed up with one of the largest image hosts in terms of active usage, to see if their benefits also help the image host. If this had not been a news item, no one would have noticed. Is FaceBook using subscription fees to make investment in minor advancements instead of something useful? No, it looks like they are just trying stuff out, kinda like they always do.

      So what's the down side here that we need to shit on this news about?

    41. Re:Hard to get excited. by Mal-2 · · Score: 1

      Most videos (at least those linked to from meme-based image sites) are stored in GIF format...

      While I don't disagree that the storing videos in GIF format is incredibly inefficient (and annoying), I somehow don't think that "meme-based image sites" are actually a significant fraction of internet bandwidth use compared to websites that use more standard video formats.

      Not to mention that our poster child for "meme-based image sites" now supports webm, and the format has become incredibly popular there.

      --
      How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
    42. Re:Hard to get excited. by spacefight · · Score: 1

      It keeps you longer on Facebook, so FB can show you more ads. More impressions, more clicks.

    43. Re:Hard to get excited. by SuricouRaven · · Score: 1

      No, but it works through different means: My thing + imageoptim > either alone.

    44. Re:Hard to get excited. by SuricouRaven · · Score: 1

      I'm just a hobbyist tinkerer, I have no qualifications between a not-very-good engineering diploma and no idea how to go about something like that.

    45. Re:Hard to get excited. by ArcadeMan · · Score: 1

      But you can also do three types of colour reducing with ImageAlpha and then compress further with ImageOptim.

    46. Re:Hard to get excited. by omnichad · · Score: 1

      No, it doesn't. I don't keep a Facebook tab open, mostly for that reason.

    47. Re:Hard to get excited. by Shirley+Marquez · · Score: 1

      One fundamental difference. Improving the JPEG encoding used by Facebook would reduce their bandwidth use without requiring users or browser developers to do anything. Moving to H.265 or VP9 video encoding requires two things: that browsers add support for those video formats (some have already done that), and users upgrade to browser versions that include the support.

      Most likely, Facebook would not transcode existing images; unless they saved the originally uploaded files (rather than the transcoded ones they made when they were uploaded) that would involve generation loss and thus a degradation of image quality. They would use the new encoder when they transcode new uploads. YouTube DOES retain the original uploads (though they did not in the early days which is why many older videos are only available in 240p or 144p) so they have been able to re-encode videos as new formats become available.

  2. Really? by Anonymous Coward · · Score: 0

    The comments thus far have been compacted...

  3. Tiny bumps in JPEG performance by chrylis · · Score: 5, Insightful

    and still no merge of the working WebP patch that was proposed four years ago because NIH.

    1. Re:Tiny bumps in JPEG performance by Anonymous Coward · · Score: 0

      Maybe Mozilla devs can tell that WebP produces shitty looking images and would handcuff the world to just one format (from Wikipedia):

      "Like VP8 on which it is based, lossy WebP only supports 8-bit YUV 4:2:0 format"

      I suppose they may as well put it in, but not everything is a step forward.

    2. Re:Tiny bumps in JPEG performance by Anonymous Coward · · Score: 0

      What's wrong with them not wanting to support Google's NIH format? I don't see the problem.

    3. Re:Tiny bumps in JPEG performance by roca · · Score: 3, Interesting

      The reason we're not merging WebP in a hurry is because it's not very good. The study results linked to in the article show that WebP isn't much better than mozjpeg. (This is especially clear in the second part of the study where mozjpeg is tuned for SSIM.) On the other hand the study shows HEVC *is* much better than WebP/mozjpeg, so we know a much better format than WebP is technically available *now*. We can't simply adopt HEVC as is due to patent licensing issues, but we should be able to create an unencumbered format with similar or better performance (e.g. using VP9 or Daala as a base). It doesn't seem like a good idea to try to move to WebP when we know a better format is coming fairly soon (probably within a couple of years).

    4. Re:Tiny bumps in JPEG performance by rrp · · Score: 3, Insightful

      One problem with your logic is that WebP isn't just a replacement for jpeg. Sure it can be used that way, but WebP also supports alpha channels and animations. And yes, you can argue that we can just use a HTML5 video for that (except I've only heard of Chrome supporting transparent videos at the moment...), but it's much more complicated than creating a WebP with those features, and it can be shown on a website with a simple img tag, IMHO. And being able to take for example a 10 MB animated gif and shrink it down to around a 1 MB animated WebP seems like a worthy enough cause to me.

    5. Re:Tiny bumps in JPEG performance by Anonymous Coward · · Score: 0

      4chan already has WebMs taking over from animated GIFs on the porn boards

    6. Re:Tiny bumps in JPEG performance by rrp · · Score: 1

      WebM is great for what it does. I definitely support tools that use WebM to replace gifs, like gfycat. But it still can't do transparency (except in Chrome) and as I said it's more complicated than creating a WebP with those features. There are some things that only WebP can do at the moment, which is why it shouldn't just be dismissed like Mozilla has done.

    7. Re:Tiny bumps in JPEG performance by roca · · Score: 1

      We agree that alpha channel and animations are required features for any next-gen image format, but that doesn't change the analysis. It doesn't make sense to try to get WebP support everywhere for those features or for small compression gains, when in a couple of years or less we could introduce a new format with those features and big compression gains.

    8. Re:Tiny bumps in JPEG performance by Njovich · · Score: 1

      so we know a much better format than WebP is technically available *now*. [...] It doesn't seem like a good idea to try to move to WebP when we know a better format is coming fairly soon (probably within a couple of years).

      So what you are saying is that for the next few years (plus the past 4 years), WebP was available for you to use, better than mozjpeg is even now (and having a bunch of extra features like lossless compression, animations, alpha channel), but you will not use it because you are waiting for some hypothetical file format that may exist in a few year and will provide better compression?

      Can we please have the old Mozilla back that was more interested in building a great browser than having petty conflicts over formats?

    9. Re:Tiny bumps in JPEG performance by AmiMoJo · · Score: 1

      So what if WebP is only slightly better than mozjpeg? That isn't a reason not to include the patch. Even a slight improvement is worthwhile for site owners and people on limited speed connections. What reason is there NOT to include it?

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    10. Re:Tiny bumps in JPEG performance by olau · · Score: 1

      I think the reason is that once it becomes widespread, all browsers will have to carry the support forever, not just distributing the code but also maintaining it (fixing security bugs etc.).

    11. Re:Tiny bumps in JPEG performance by rrp · · Score: 1

      WebP already has big compression gains. Just not in comparison to a static jpg. But compared to an animated gif it's a huge savings. I know I'm not going to convince you or Mozilla to change your positions, but to outsiders, who aren't involved in the browser wars, it seems rather silly that you guys won't add support for this just because something better might come alone a few years down the road, when there's nothing else available to do it now.

  4. Worthless by Anonymous Coward · · Score: 0

    1982 called, it want's its bandwidth back.

    1. Re:Worthless by Anonymous Coward · · Score: 0

      You were using JPEG 10 years before it was created? Where you keeping that time machine?

    2. Re: Worthless by fatgraham · · Score: 1

      Next week

  5. taking facebook money is like by Anonymous Coward · · Score: 0

    having your boyscout troop sponsored by a meth dealer.

  6. The future turned out to not be so cool by CRCulver · · Score: 1

    A decade ago, nerds sometimes posited that in the future, connectivity will be so fast, RAM/storage space so large, and processors so powerful that the world might just switch to lossless formats. Here we are in 2014 still trying to trim a couple of percentage points off JPEG file sizes, and web designers still advise keeping images under 100k each or so.

    1. Re:The future turned out to not be so cool by mwehle · · Score: 1

      Yes, but this is still 2014, not the future, silly!

      --
      Wir sind geboren, um frei zu sein - Rio Reiser
    2. Re:The future turned out to not be so cool by gstoddart · · Score: 5, Funny

      Yes, but this is still 2014, not the future, silly!

      Correct, now is now.

      But back then, now was then, and now was in the future. Of course, now 'then' was back then, and was the past. In the future, now will also be in the past, as will then. But by then, then will be now and then will be the present. The future present, not the current present.

      So, soon, when now is later, the then now will be then, and now will still be in the past. But by then we won't have to worry, because it will be now, and I've already told you what happened.

      Every now and then you need to remember which now, which then, how long until then is now, or how long ago then then was now.

      Then you can say that you did know now what you knew then. Of course, when you say now then, it will be a different now than now, because it will be then.

      It's all very complicated now, but by then it will make perfect sense.

      --
      Lost at C:>. Found at C.
    3. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      We did better than lossless formats, we switched to 50x the original data. If you told a nerd in 1994 (20 years, minimum to technically qualify as 'decades') that a mobile phone would be able to take photos in 4096 * 4096 resolution, apply a 'lossy' compression (that has been refined enough that you will not see the artifacts unless the image is altered and recompressed multiple times and then examined at full zoom) and trivially send the image to a remote server over the course of seconds, I'm fairly certain they'd all drop the obsession with lossless formats that they had when a large image was 640 x 480.

    4. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      Web pages are like gases: they expand to fill the space (bandwidth) available. And they will have always have just-tolerable load times.
      Many web pages from 2004 would probably load fairly quickly with today's machines and connections.

    5. Re:The future turned out to not be so cool by mythosaz · · Score: 5, Funny

      It's all very complicated now, but by then it will make perfect sense.

      Colonel Sandurz: Try here. Stop.
      Dark Helmet: What the hell am I looking at? When does this happen in the movie?
      Colonel Sandurz: Now. You're looking at now, sir. Everything that happens now, is happening now.
      Dark Helmet: What happened to then?
      Colonel Sandurz: We passed then.
      Dark Helmet: When?
      Colonel Sandurz: Just now. We're at now now.
      Dark Helmet: Go back to then.
      Colonel Sandurz: When?
      Dark Helmet: Now.
      Colonel Sandurz: Now?
      Dark Helmet: Now.
      Colonel Sandurz: I can't.
      Dark Helmet: Why?
      Colonel Sandurz: We missed it.
      Dark Helmet: When?
      Colonel Sandurz: Just now.
      Dark Helmet: When will then be now?
      Colonel Sandurz: Soon.
      Dark Helmet: How soon?

    6. Re:The future turned out to not be so cool by gstoddart · · Score: 1

      I'm fairly certain they'd all drop the obsession with lossless formats that they had when a large image was 640 x 480.

      In 1994, more than a few of us were using dialup modems, and we wouldn't have believed you.

      Or, more accurately, we wouldn't have been willing to wait 20 years for porn at that resolution.

      Like so many things, people who say "in 20 years we'll be doing this" tend to get laughed at. Because the track record of people predicting what we'll be doing in 20 years is pretty sketchy.

      --
      Lost at C:>. Found at C.
    7. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      A decade ago, nerds sometimes posited that in the future, connectivity will be so fast, RAM/storage space so large, and processors so powerful that the world might just switch to lossless formats.

      Yet even with a 24 megabit VDSL2 downstream, I still cringe when someone uploads a screen shot from a video to 4chan as .PNG, because it takes multiple seconds to download.

      (Note that I said from a video, which means it was already compressed, and you won't lose anything by setting JPEG to even a medium quality level. But they're too lazy to change the default in their video player program's screen shot function from .PNG.)

    8. Re:The future turned out to not be so cool by Desler · · Score: 1

      That's because those nerds were idiots.

    9. Re: The future turned out to not be so cool by loufoque · · Score: 1

      Not if they use pngcrush first.

    10. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      I think the largest PNG file that I've been aware of was under 500KB. You should be able to download that in less than 1/6th of a second with 24mb. I just took a screenshot of my dual-monitor desktop and it was about 125KB. And that's just saving it with MS-Paint.

    11. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      In 20 years we will uses solar, wind, batteries, and other forms of renewable energy and I expect to get laughed at.

    12. Re:The future turned out to not be so cool by Guspaz · · Score: 1

      Corporal: Sir.
      Dark Helmet: What?
      Corporal: We've identified their location.
      Dark Helmet: Where?
      Corporal: It's the Moon of Vega.
      Col. Sandurz: Good work. Set a course, and prepare for our arrival.
      Dark Helmet: When?
      Corporal: Nineteen-hundred hours, sir.
      Col. Sandurz: By high-noon, tomorrow, they will be our prisoners.
      Dark Helmet: WHOOOOOOO?!?!?

    13. Re:The future turned out to not be so cool by toejam13 · · Score: 1

      A decade ago, nerds sometimes posited that in the future, connectivity will be so fast, RAM/storage space so large, and processors so powerful that the world might just switch to lossless formats. Here we are in 2014 still trying to trim a couple of percentage points off JPEG file sizes, and web designers still advise keeping images under 100k each or so.

      Some of that is due to the rise of mobile computing. The computing power and data connectivity of mobile handsets are running about a decade behind desktop computers, so the least common denominator problem has remained somewhat static. And even as that market matures, rural areas and users will continue to lag for some time.

      In addition, for any increase in computing power and data storage, we've often seen an equal increase in resolution and bit depth. A decade ago, 480p videos were the norm. Now we're now up to 1080p videos. Within a decade, it'll be 2160p videos. Same deal with digital cameras that have jumped from 5MP or less to 20MP or more today.

      I'd argue that lossless formats like FLAC and ALAC were adopted early in the audio world because music files have generally remained fixed at 44.1kHz × 16bit × 2 channels. Movies have somewhat settled at 48.8kHz × 24bit × 6 channels (with 192kHz being the ceiling). They're also relatively small from the start. Lossless formats in the video world outside of the editing room or archival repository don't make sense. Same with raw image formats for cameras.

      We've also seen an increase in the number of users, which in turn results in an increase in the amount of data. How many MySpace visitors were there in 2006? How about Facebook today? About ten times as many. And Facebook encourages more uploading than MySpace did. If people are satisfied with good enough, it just doesn't make economic sense to go lossless.

    14. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      For graphics we mostly do. PNG is pretty much the standard for graphics that aren't vectorable, and SVG is good for those. I don't see us ever going to lossless for photographs though. Most of what is captured by modern image sensors contains a lot of noise anyway, and JPEG kind of actually filters that unwanted crap out.

    15. Re:The future turned out to not be so cool by Lehk228 · · Score: 1

      I remember back when images over 15k needed to have a damned good reason for being over 15k

      --
      Snowden and Manning are heroes.
    16. Re:The future turned out to not be so cool by petermgreen · · Score: 1

      I think the largest PNG file that I've been aware of was under 500KB.

      I'm sure i've seen bigger.

      A 1080p frame in uncompressed RGB is about 6MB. Afaict PNG gets of the order of a 3x ratio on photographic data so we are probablly talking a couple of megs of png if someone lifts a frame from a 1080p video.

      You should be able to download that in less than 1/6th of a second with 24mb.

      Unfortunately the intenet architecture doesn't handle short connections well. The TCP/IP stack doesn't know what the available bandwidth is so it has to be conservative initially. On high bandwidth but also high latency connections (e.g. user in europe, server in the USA or vice-versa) it often doesn't reach the full speed available before the transfer is over.

      I just took a screenshot of my dual-monitor desktop and it was about 125KB. And that's just saving it with MS-Paint

      This is pretty meaningless without knowing what was on the desktop at the time.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    17. Re:The future turned out to not be so cool by ChunderDownunder · · Score: 1

      Migrate to Australia, then. :(

      The ghost of Uncle Rupert and Big Coal will still be dominating. Our current treasurer, Joe Quixockey, tilts at Canberran windmills.

    18. Re: The future turned out to not be so cool by Anonymous Coward · · Score: 0

      +5

      We could be curing cancer or preventing global warming but instead we are shaving 5% off of jpegs so that super large companies can make even more money whereas to the rest of the world it doesn't matter a lick.

      Renaming the HOST field in HTTP headers to just "HO" would save trillions of bytes daily or even hourly but there are bigger fish to fry and I don't think cutting images down by 5% is one of them.

      Based on comments here everyone hates Facebook and calls them the devil yet when something comes along that may be useful for them everyone celebrates like we're all part of the FB family, what the hell is going on? My FB family birthday card must have got lost in the mail because I don't see any reasons to jump for joy and squeeze my tits together over this.

    19. Re:The future turned out to not be so cool by Anonymous Coward · · Score: 0

      I agree with everything you said, but I want to point out one thing about "tcp". Newer TCP stacks are starting to get more aggresive because of fixed high latency but much higher bandwidth. Newer OSes, like FreeBSD, will actually save TCP window information across connections to the same IP address. If a new TCP connection is made, it will start it off at the last known window.

      My connection to YouTube regularly ramps up to 100mb in about 1/4 of a second once the connection is established, and it's not a CDN. I've done 200ms+ speed tests to Europe from the Midwest and it takes about 1/2 a second to get to 50mb/s. The 3 way handshake is probably more of an issue than the TCP window growth. Even that will eventually be fixed with TCP cookies and HTTP1.1 and connection pools already mostly solve this issue.

  7. but being Mozilla by Anonymous Coward · · Score: 0

    The jpg's are now encoded 180degrees rotated.

    "The only regret we have is that we could not also rotate the controls of all the image viewing software out there, that would have made this improvement even more awesome. But please be assured that it is on our to-do list for version 34 (release expected in September or October)" said Josh Aas.

  8. The future turned out to not be so cool by Anonymous Coward · · Score: 0

    Lossless formats still have a pixel density. For the same size of file, a compressed image will have a higher apparent resolution than an uncompressed one. So even with near-unlimited bandwidth, there are STILL arguments you can make in favor of compression being part of the standard.

    e.g. 1MB of space used to encode a JPEG vs the same space used to encode a .png. The JPEG would have a higher effective resolution.

  9. And I just want Firefox not to shit itself by drinkypoo · · Score: 1

    G+ is making FF crash its ass off these days. It would be a fun paranoid speculation to imagine that Google knows of bugs in FF which can be triggered with mundane code to make my browser asplode, but even if it were true it would be irrelevant because mundane code shouldn't blow up Firefox.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:And I just want Firefox not to shit itself by The+MAZZTer · · Score: 1

      Start Firefox up in safe mode and see if it still happens. Chrome did right doing extensions the way they did... the way Firefox did it, it's near impossible to tell the difference between a problem caused by the browser or one of its addons.

    2. Re:And I just want Firefox not to shit itself by Ash-Fox · · Score: 3, Insightful

      That's only an issue for adblock+ users.

      --
      Change is certain; progress is not obligatory.
    3. Re:And I just want Firefox not to shit itself by gstoddart · · Score: 1

      That's only an issue for adblock+ users.

      Not a problem if you don't use G+. Certainly not my problem.

      --
      Lost at C:>. Found at C.
    4. Re:And I just want Firefox not to shit itself by Megane · · Score: 2

      I instead have a non-paranoid speculation that the FireFox people keep adding new buggy features faster than Google can swerve to avoid the bugs. So I use SeaMonkey instead.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    5. Re:And I just want Firefox not to shit itself by gstoddart · · Score: 1

      Or, alternately, Google introduces the suck faster than anybody else can counterbalance it.

      Just sayin'.

      --
      Lost at C:>. Found at C.
    6. Re:And I just want Firefox not to shit itself by H0p313ss · · Score: 1

      G+ is making FF crash its ass off these days.

      If only there was a simple workaround for this, but it's just not coming to me.

      --
      XML is a known as a key material required to create SMD: Software of Mass Destruction
    7. Re:And I just want Firefox not to shit itself by drinkypoo · · Score: 1

      I find the web unusable without Adblock+, especially on my kiddie-grade 5Mbps max WISP connection. And Chrome's Adblock+ is still inferior to Firefox's, or I'd run chromium.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:And I just want Firefox not to shit itself by Anonymous Coward · · Score: 0

      The current extended support release of Firefox eats memory until the browser croaks or the offending tab is closed, particularly on GIF image heavy sites like Tumblr. One bug that was fixed between this release and the one before was a use-after-free bug in relation to image handling. I guess the memory is not freed at all now.

    9. Re:And I just want Firefox not to shit itself by drinkypoo · · Score: 1

      The current extended support release of Firefox eats memory until the browser croaks or the offending tab is closed

      Yeah, I wasn't going to go into that, but I actually tried that release hoping that an ESR release would be a good thing. But I guess I should have known better. I followed ESR on G+ for a while. That was a mistake. ;)

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:And I just want Firefox not to shit itself by Anonymous Coward · · Score: 0

      There is only one page my browser in any combination (Firefox, Chrome or (IE) on Linux or Windows) will crash regularly: www.bahn.de and searching for a train to use.

    11. Re:And I just want Firefox not to shit itself by Anonymous Coward · · Score: 0

      I agree. When Firefox manages to crash twice a day, Mozilla shouldn't be sinking its development time in trivial JPEG encoder improvements.

    12. Re:And I just want Firefox not to shit itself by Ash-Fox · · Score: 1

      I find the web unusable without Adblock+, especially on my kiddie-grade 5Mbps max WISP connection.

      I don't. I have a simple proxy.pac file that sends a few annoying advertiser domains to use a proxy connection on 255.255.255.255 (and for US-access only sites, hits my local ssh proxy to one of my US servers).

      I should also note that I travel frequently (Monday through Friday) and I am often on mobile Internet.

      --
      Change is certain; progress is not obligatory.
    13. Re:And I just want Firefox not to shit itself by Ash-Fox · · Score: 1

      Not a problem if you don't use G+

      And that's how the day was saved by Captain Obvious.

      --
      Change is certain; progress is not obligatory.
  10. Save even more bandwidth for facebook users! by BenJeremy · · Score: 1

    Take all landscape photos and crop 33% of the space on the left side and 33% on the right side. I see they already do this to widescreen videos taken on smart phones.

    I just saved 66% of their bandwidth, and made the images more appealing to hipsters and guidos!

    1. Re:Save even more bandwidth for facebook users! by Anonymous Coward · · Score: 0

      Don't know if your comment is serious or joking, so ignore if it's the latter. 66% reduction in size (as in, image dimensions) does not necessarily mean 66% reduction in file/transfer size. P.S: If you take 66% from the image width, you are probably taking out most of the interesting stuff in the image, or at least a great deal of context.

    2. Re:Save even more bandwidth for facebook users! by gstoddart · · Score: 1

      Bah, you could replace 33% of all Facebook pictures with cute cat photos, and nobody would even know the difference.

      --
      Lost at C:>. Found at C.
  11. NIH, or once-bitten twice-shy? by Millennium · · Score: 1

    Google has deliberately killed more technologies than Microsoft ever just let wither and die, and Mozilla has been burned by this more than once. At this point, I'd say it's quite reasonable to demand that Google provide some assurances that it's not going to flake out this time.

    1. Re:NIH, or once-bitten twice-shy? by Anonymous Coward · · Score: 0

      > Mozilla has been burned by this more than once

      It would be useful if you named these cases.

    2. Re:NIH, or once-bitten twice-shy? by STratoHAKster · · Score: 1

      Google has deliberately killed more technologies than Microsoft ever just let wither and die, and Mozilla has been burned by this more than once.

      Really? You just throw this assertion out there without spending the extra few seconds to name a few of these technologies? I'm really curious.

    3. Re:NIH, or once-bitten twice-shy? by amRadioHed · · Score: 1

      Google has killed services before that cost them money to continue operating, that's not the same thing as an open source codec at all.

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    4. Re:NIH, or once-bitten twice-shy? by Anonymous Coward · · Score: 0

      Mozilla asked Google to support APNG, and Google basically said "nope, we wanna use MNG because reasons." Google has also snubbed them by saying "h264 is no longer needed since we invented WebM. support that. we'll be dropped h264 from chrome" and Mozilla did. Then Google said "nope, fuck that, still using h264, so now you have to support both."

      Just those two reasons are enough to make me think twice about supporting a huge, complex, constantly moving "one size fits all" image spec from Google. Google has a tendency to kitchen-sink their tech, hence no one wants to support it unless they're Opera.

      There's also the case that other good replacement image formats have been around forever, but they were NIH as far as Google was concerned, so they made WebP. So your argument is plain idiotic to begin with. Focusing on Mozilla just because they want to improve what's there already instead of slapping in more and more image formats is the callsign of someone who just goes along with their favored brand because why not? It's an improvement and it's by my favored brand, so screw all the other possibilities.

    5. Re:NIH, or once-bitten twice-shy? by rrp · · Score: 1

      The problem with APNG is that it was not adopted and is not supported by the PNG group. That means the official libpng source has no support for it and will never have support for it. Thus making it a non-standard. Instead the PNG group chose to support MNG. So Google chose to go with the standards; they're not just doing it "because reasons."

    6. Re:NIH, or once-bitten twice-shy? by Elbart · · Score: 1

      WebM?

  12. And??? by Anonymous Coward · · Score: 0

    What ELSE does it do? is it encrypting your metadata into it so you can never detatch yourself from it?

  13. HSA decoder by ponos · · Score: 1

    AMD recently presented HSA-enabled jpeg decoding. That would also be an interesting addition. Make these shaders work a little...

    http://developer.amd.com/resou...

  14. Secret new facebook image compression method! by linebackn · · Score: 1

    Here is how their new compression method works. It reduces all images down to a single one or zero. If the bit read in is one, it display a picture of a cat. If it is zero, it displays a picture of Peter Griffin farting. And as a bonus, if no bit can be read, it displays the goatsex guy.

  15. Formal verification by Burz · · Score: 1

    Why indeed would Mozilla waste their resources on this when stability and security on web clients ought to be their greater concern?

    If it were up to me, I would start with self-contained date formats like JPEG that browsers handle frequently, and put that code through a formal verification process. Eventually, maybe even HTML rendering and the browser could be subject to formal verification. This could strengthen computer security dramatically.

  16. Facebook could do more by stewsters · · Score: 1

    If Facebook really wanted to help reduce global bandwidth and was willing to play hardball, they would just switch their images to webP suddenly, and display a message to update your browser if you cant see them. Microsoft would have to fold if suddenly their browser didn't show images. Not sure if FB is large enough to survive the backlash, but if they are we could see new codecs in IE within the month.

  17. No WebP in any web browser for iPad by tepples · · Score: 2

    Microsoft would have to fold if suddenly their browser didn't show images.

    With Apple holding a monopoly on web browser engines on 36 percent of tablets, it arguably has room to play hardball with Facebook.

  18. Balderdash. by jensend · · Score: 1

    Any "nerd" who posited that bandwidth and storage concerns would be so totally irrelevant that we'd happily waste 10-20x as much of them for practically zero benefit was not so much a "nerd" as a total idiot. Having more bandwidth means you want to do more with it, not waste it for no reason.

    Real "nerds" worth the cred understand that not only does lossy compression provide great results at small fractions of the sizes of the best lossless representations, but research into lossy compression also helps us understand the structure of real-world information, intelligence, and human perception in new ways.

    A future where we have lossy formats which achieve results equal to today's formats in a quarter the bandwidth because we've come to better understand the structure present in real-world signals and the ways humans perceive and interpret information is a cooler and more exciting future than one in which we [url=http://scholarlykitchen.sspnet.org/2012/01/19/the-hidden-expense-of-energy-costs-print-is-costly-online-isnt-free/]waste exajoules of energy and help destroy the planet[/url] by sending each other millions of terabyte-sized high resolution lossless cat videos.

  19. oops by jensend · · Score: 1

    that'd be this link

    that'll teach me to use preview esp. when I've been spending too much time on sites where the article discussions use bbcode

  20. What we really need by ArcadeMan · · Score: 1

    What we really need is a new container format that combines the image data of a JPEG with the 8-bit transparency layer of a PNG image.

    1. Re:What we really need by petermgreen · · Score: 1

      It exists, it's called JNG but support for it is poor :(

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. Re:What we really need by ArcadeMan · · Score: 1

      And even if support for it was added tomorrow, we probably couldn't use it for another decade or so because of Internet Explorer (insert version numbers still in use today).

  21. Not JPEG2000? by Anonymous Coward · · Score: 1

    As long as the renderers support it, and it doesn't come saddled with unFRANDly baggage, it will probably do fine.

    However, Mozilla has a questionable track record, when it comes to support for standard media.

    As a Web developer, it rankles me to have to store double the size of the video on my server, just so that stubborn developers can have their way.

  22. False equivalence by Bite+The+Pillow · · Score: 1

    False equivalence. Facebook could use that $60k to fund/bribe inclusion of WebP, or maintain their own build of AssWeasel or whatever fork they want to call it.

    Or they could entice users with "if you want to see pictures, click here". That works really well, and the facebook using billions might convert to something other than firefox.

    Or, they could be supportive of this new tech and not use their massive market share to clobber open source into submission.

    On the other side of the argument, NIH is a terrible summary of this link, found on the page you linked to.

    http://muizelaar.blogspot.com/...

    WebP seems like it has grown a lot - which means keeping up with another imaging library and testing something that is continually changing. Given the limitations mentioned, it hardly seemed worth the effort. And problems with the new patch abound - no tests, breaking Windows build, and devolution into a discussion forum.

    Take the opinion that you don't care either way, and read through that bug with an open mind. It's hoseshit, top to bottom, and I don't blame anyone one bit for keeping WebP out.

  23. Weissman Score?? by Anonymous Coward · · Score: 0

    So what is its Weissman Score? if it's less than 5, forget about it, Pied Piper has done it before.

  24. How does it compare to JPEGmini? by XNormal · · Score: 1

    JPEGmini is a proprietary implementation of the same concept : fully compatible implementation of a JPEG compressor that does better than libjpeg at the cost of much higher CPU use.

    --
    Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
  25. I'm not convinced webP is better by AC-x · · Score: 1

    I'm not convinced webP is better, I've done a quick comparison and to my eyes JPEG beats it on like for like file sizes:

    40k jpeg vs 40k webP (images converted to png for your viewing convenience)

    Compared to the lossless original (one of Google's own webP comparison images) the webP version has lost more chroma resolution, leading to desaturation in parts and blurring of strong colour details like the red arm band.

    It would be nice as a replacement for PNGs with alpha channels though.

  26. useless by Anonymous Coward · · Score: 0

    As long as JPEG is 8-bit and not 14-bit like RAW is, it will be useless. Anthony David Photography Greece