12 ms·

Google offers JPEG alternative for faster Web

204 points by ukdm 16y ago

bediger 16y ago
Won't the on-line Porn Industry have to adopt this for large scale adoption to take place? I'd think that the size decrease alone would sell the Porn Industry.
- mhd 16y ago
  Are galleries that important? I thought right now it's all about videos.
  - nlogn 16y ago
    What about all the "video preview" images? Surely porn sites would benefit from serving less bytes there.
    - mhd 16y ago
      I don't think those are important enough to risk browser compatibility issues, I don't see a reason why the porn industry would throw its weight in the ring because of this. And that's if this new format would actually have advantages at these sizes. The factor doesn't need to remain constant in different resolutions. (And even if, we're talking about small pictures anyway, so if you save 1kb per preview pic, would this matter compared to the video stream bandwidth?)
      - pjscott 16y ago
        There are no browser compatibility issues if you use conservative HTTP content negotiation. Browsers which support WebP can say so in their HTTP Accept headers, and the server can serve WebP to those browsers, falling back on ordinary JPEG for older browsers. This was also used back when PNG support was spotty, by sites which wanted to combine the goodness of PNG with the ubiquity of GIF. It's actually pretty simple: http://en.wikipedia.org/wiki/Content_negotiation http://en.wikipedia.org/wiki/Content_negotiation Now that I think about it, there's probably a business opportunity for someone who handles such hosting issues for image-heavy web sites. The porn industry may seem sketchy, but they have a lot of money and a pressing need to keep overhead down.
        mhd 16y ago
        Yes, but it has to have some significant effect. For this to happen, the gain from the format conversion has to matter for the porn sites use case, this has to be a certain percentage of bandwidth (wonder how that's for video sites), and then the amount of browser who support it (not just advertise it, cf. IE and its PNG "support") has to be high enough. Anybody got some statistics on browser distribution on a major *tube site? I guess we'll see a lot of Internet Explorer there, although it Chrome's "incognito" mode may have found some fans.
        pjscott 16y ago
        The cost of format conversion can be made very low by having it done automatically by the web server. It'll just take some time for the software to do that.
  - barrkel 16y ago
    Soft / "art" sites focus much more on stills, and headline pixel counts, e.g. met-art etc. I would expect them to prefer large file sizes, to aggravate people who like to scrape content.
    - RexRollman 16y ago
      As a past member of Met-Art and current member of Digital Desire, I would think that this has the potential to save lots of bandwidth for those types of services. And even the services that do specialize in videos usually offer photos sets of shoots, so it would still benefit them as well. The trick will be to build enough mass to make it common enough for all the browsers to support WebP. I can see Firefox and Webkit adding it fairly quickly, so the real question is, if and when will Microsoft support it?
    - wtracy 16y ago
      I would expect the large file sizes to hurt the host at least as much as the scrapers. Better to insert random delays in responses to HTTP requests from suspected scrapers (or outright reject them).
    - pjscott 16y ago
      I would expect them to prefer smaller file sizes, especially in public preview galleries, to lower their bandwidth costs. Someone scraping high-quality images incurs a small one-time bandwidth cost, and they can re-encode the images at a lower quality if they want to save bandwidth.
- deleted 16y ago
  [deleted]
bartl 16y ago
Why is the performance of PNG so disappointing? The WebP sample image from the article (top image) is shown here as a PNG of 234kB...
- mhd 16y ago
  There are limits to non-lossy compression…
  - wmf 16y ago
    Also, PNG isn't very good for photos and other "natural" images; JPEG-LS (which nothing supports) is much better.
- samdk 16y ago
  Partly because PNG is lossless, but also largely because that's not the kind of image that PNG compresses well. JPEG is a better format (than PNG) to use for photos and similar types of images, because it does an okay job of compressing them and because the compression artifacts are a lot less noticeable. However, JPEG is a really bad format for things like graphics with lots of flat colors or text, because there the compression artifacts are very easy to see. This image from Wikipedia comparing the two shows the difference: http://en.wikipedia.org/wiki/File:Comparison_of_JPEG_and_PNG.png http://en.wikipedia.org/wiki/File:Comparison_of_JPEG_and_PNG... PNG has the advantage of being lossless, and so it performs very well in some situations, but very poorly in others. Photos and images like them are an example of where PNG compresses poorly, because the . PNG actually does outperform JPEG (compression-wise) on some kinds of images though: those with lots of flat colors/text/gradients/etc., and those conveniently end up being the kinds of images where compression artifacts are really visible. tl;dr: Use the right format for the job. PNG is not good at compressing photo-like images, but does really well at things like diagrams and vector graphics. JPEG is best-used for things like photos where compression artifacts aren't a huge deal. If you're looking to learn more about how JPEG and PNG compress images, I recommend checking out Smashing Magazine's guides to JPEG and PNG optimization techniques. (I don't usually recommend Smashing Mag articles, but these are both good.) Both will give you some insight into how these things work. http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/ http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optim... http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/ http://www.smashingmagazine.com/2009/07/15/clever-png-optimi...
lmkg 16y ago
Wait, so Google took a bunch of JPGs, re-compressed them with a lossy format, and claims to have gotten them 40% smaller with no loss in quality. Either the lossyness in the format is entirely in aspects of the image that the JPG compression already removed and they're just better at compressing the residue (possible, but I am skeptical), or else the image is altered, but in a way that Google claims is subjectively a sidegrade in quality. I'm not putting much faith in their quality claims until I see side-by-side comparisons of a JPG and WebP compression of the same TIFF (or other uncompressed) image at the same compression ratio. A double-blind study is probably too much to ask, but it would be nice.
- wccrawford 16y ago
  That's that the article says, but they're probably restating something and got it horribly wrong. What probably happened was that they took images and compressed them to WebP and JPEG and compared the sizes.
  - dgreensp 16y ago
    No, I would believe Google recompressed a whole ton of JPEGs as a test. Not the most scientific test of a codec, but as a Web company they are interested in improving image serving more than image authoring. As for the recompression, you can losslessly squeeze a JPEG by at least 15% (e.g. StuffIt came out with this a few years back, claiming higher numbers but mainly at low bitrates I think). In the lossy camp, H264's intra-frame encoding significantly outdoes both JPEG and JPEG2000. WebP is probably similar to H264 intra. As for recompression vs. straight compression, this probably has little effect to the extent JPEG and WebP are "compatible", e.g. both being block-based transforms. It would be unfair, on the other hand, to run a very different codec after JPEG and compare it to WebP after JPEG, because the other codec might be working hard to encode the JPEG artifacts.
    - jacobolus 16y ago
      > It would be unfair, on the other hand, to run a very different codec after JPEG Exactly. I found Google’s “study” pretty sketchy, given the lack of concrete detail about this. http://code.google.com/speed/webp/docs/c_study.html http://code.google.com/speed/webp/docs/c_study.html Here’s some of what I wrote in an email to a friend: Since they’re dealing with an arbitrary collection of already encoded images, there are likely e.g. artifacts along JPEG block boundaries that take up extra space in JPEG 2000. While they have a big sample size, they don’t compare the metric used (PSNR) with noticeable quality degradation. There's a graph of size distribution (which would be a lot more readable if they binned some of the sizes and showed a histogram instead of a sea of overlapping red plus signs), but then compression percentages aren't in any way related to those various sizes: were big images easier to compress better than JPG/JP2? Small images? Looking at the size distribution, a large percentage of these images are absolutely tiny, the kinds of images that as far as I know JPEG 2000 was never intended to be used for. The overhead of the data storage container ends up dominating the size of the image for very tiny images – I don’t know anything about the relative overhead of JPG/JP2/etc. images, but it would be good to include that in any discussion. It seems to me like the WebP images have their color profiles stripped. Is that an inherent part of WebP? If so, I hope Google doesn’t encourage people dealing with photographs to adopt it in large numbers. Browsers are just finally getting to the point where proper color management of images is expected; no need to regress there.
Terretta 16y ago
At 8 times longer to compress, this reminds of Iterated Systems FIF, but article claiming based on WebM suggests it's still DCT compression. Adoption by just Flickr and Facebook could push a new image format fast. Google has much to gain since they archive a copy of indexed images. Hence their interest in "recompression".
shawndumas 16y ago
Not sure about this one google. Firstly, Worst. Name. Ever! Secondly, what kind of browser support do they think they'll get? I know ie is covered via google chrome frame but will Apple and Mozilla jump on this? Both issues have alloyed this one on me.
- aw3c2 16y ago
  Well, the name hints at a close relationship to WebM so I guess they target the same progressive browsers.
  - shawndumas 16y ago
    My boss walked passed and I called him over to tell him about WebP and he literally laughed out loud at the name. I said it without a hint of sarcasm and it was the first thing he noticed. Anecdotal I know; but still...
    - sandipc 16y ago
      this reminds me of the internet's reaction to the name "iPad" - although I haven't heard anything along those lines since the first week it was announced.
- njharman 16y ago
  Chrome is a given, Firefox (and isn't webkit) is open source. Google has the devs to write the needed code/extension and give it to those projects.
  - shawndumas 16y ago
    Okay, I'll buy that Chrome and ie are a shoe-in, and that FF is probably easy. So that leaves Apple and Opera. Not bad, not bad...
    - redrobot5050 16y ago
      Chrome and Safari both use WebKit. If Google releases an implementation, it shouldn't be hard for Apple to adopt it. That just leaves Opera.
goalieca 16y ago
I was hoping Jpeg2000 would take over because it is so flexible. It encodes really well at the low end and really well at the high end. You can target a specific file size and have it produce it. Instead of the blocking artifacts caused by the 8x8 DCT grid, you get smooth blurring.
- InclinedPlane 16y ago
  Sadly, jpeg2000 may never catch on until the patents encumbering it expire.
  - wmf 16y ago
    Given that the JPEG 2000 patents are licensed royalty-free, I think this says something about open source patent nitpicking. "All patents that WG1 believes to be essential to practice JPEG 2000 Part 1 are available on ITU-T’s patent policy 2.1, which is fee-free (see the ITU-T web site for their interpretation of this)." http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q3f042a68b1081 http://www.jpeg.org/faq.phtml?action=show_answer&questio...
    - pbhjpbhj 16y ago
      Two things after a quick scan of the page: 1) "Again, at every JPEG meeting the following resolution is also passed unanimously" appears to be saying each year they vote whether to continue or wether to reel in the bait. Tasty free morsels given by fisherman often turn out to have hooks attached. 2) It appears that one has to give up any patents that read on to a baseline spec for JPEG. This sounds like it could be bad for large multimedia companies who want to retain rights to an image format - what's the baseline. If the baseline is something like "uses huffman codes to compress image data" then this is going to be a potential huge cost in IPR given up. These are possibly unfounded, just first thoughts at 2am.
  - nwmcsween 16y ago
    This hasn't stopped nearly every codec popular today.
sudonim 16y ago
Please, if anyone can figure out a format so my mom doesn't attach 10 mb files that should be 750k, I'm all for it.
- dkarl 16y ago
  An actually helpful suggestion (I hope): help her change the settings on her camera. Explain that she'll be able to take more pictures without filling up the memory.
MikeCapone 16y ago
Our CPUs are so much faster than even a few years ago, but bandwidth hasn't increased that much (at least not here in Canada). I'd gladly trade some CPU cycles for bandwidth (or same bandwidth, but better quality).
jessriedel 16y ago
As a regular person, I really can't see a 40% decrease in size (of which I'm skeptical) for just jpeg images (not nearly the full "65% of the bytes on the web") being worth the huge switch-over costs. The ubiquity of jpeg is just too valuable.
- wmf 16y ago
  If you understand how to use content negotiation (which basically no one outside Google does) then there's virtually no switching cost.
  - jessriedel 16y ago
    I mean cost beyond just web development. As mentioned in the article, there is a massive range of consumer and non-consumer products which have adopted jpeg as a universal format.
    - wmf 16y ago
      So those devices just keep on using JPEG and thus bear no additional cost. Even if WebP is only used between Google and Chrome, it will be worth it for Google.
acdha 16y ago
I'd be very curious in seeing a comparison with JPEG-XR, which has a number of nice advantages for photography.
- confuzatron 16y ago
  I've been googling for examples of that format to no avail. I just wanted to see if Google's browser supports it.
gshayban 16y ago
With OLED/IPS etc. taking over in the next few years, will this really support >8bpp or HDR? Interesting move, Google
- jbarham 16y ago
  WebP uses the same color model as WebM which "works exclusively with an 8-bit YUV 4:2:0 image format" so seems like WebP will not be HDR capable, which is a pity.
  - Maskawanian 16y ago
    Considering it basically is 1 frame of WebM it isn't exactly a surprise either.
drv 16y ago
There's no way this will catch on; the slight image quality per bit improvement is not nearly enough to counteract the huge momentum of existing JPEG use. Certainly JPEG isn't the best possible image codec or even all that good, but it's good enough, and it works everywhere.
nphase 16y ago
But there is a loss in quality! The dithering is noticeably worse. Notice the light outline on that red-ish thing in the top middle of the image. I bet I could've gotten the 10kb decrease by just lowering the JPG quality.
- mayank 16y ago
  Umm...how can you claim a loss in quality without looking at the original? The linked page shows two lossily compressed versions of an unknown original image. You're commenting on which image subjectively LOOKS better to you, not on compression quality.
  - deleted 16y ago
    [deleted]
  - Tomek_ 16y ago
    Take a look at those red and orange "things" in the center of the image in the PNG/WebP version. My bet is on a loss in quality.
  - nphase 16y ago
    My point was just that they're showing a lower quality image that is is lower in size. Great, ice is cold.
igrekel 16y ago
The article is quite light so far. I am sure it brings other improvements than just a reduced file size. I would hope that at least some features of JPEG2000 would make it in this format. Maybe also a convenient way to pack several images in a single file without resorting to css clipping tricks.
jmspring 16y ago
JPEG (and many image/video coding algorithms) are really made up of a couple pieces -- transform, modeling and entropy coding. In the case of JPEG, the transform is handled through breaking the image up into eight by eight blocks that are then run through the DCT and quantized. This is where the loss comes from. Modeling and entropy coding are handled on the coefficients generated above. However, this is done on each 8x8 block (note, I am making a slight simplification ignoring the use of differential compression on the DC coefficients between blocks. Since the algorithm is relegated to encoding at most 64 coefficients at a time, there isn't much "modeling" that can be done. If one reorders the coefficients of the 8x8 blocks to resemble a non-block based transform -- you can perform better modeling to get much better compression with the exact same image quality as the original JPEG image. However, in this case, you lose compatibility with a JPEG encoder since the format of the coefficients is not JPEG.
- eru 16y ago
  One simple way to be able to throw more CPU at image compression/decompression, and thus save space, could be to use bigger blocks than 8x8.
jdavid 16y ago
This has other implications. * a save in bandwidth is huge on mobile speed, google believes that speed effects web use, web use effects revenue * a save in bandwidth is cheaper for google * att, verizon, sprint, and tmobile are limiting mobile data plans, smaller images means more web page loads * net neutrality might fail, you might have to pay for data * google runs a lot of content via app-engine, gmail + chrome, google should be able to make the switch for the stacks they own to develop an advantage. * others will follow in adoption like facebook if it saves them on one of their largest costs cdns. * openness an open format can go on more devices. * open devices might appear faster on the web.
jbarham 16y ago
Given that most JPEG images are generated by digital cameras, I don't think WebP will get any traction until Canon, Nikon et al support WebP natively. And hopefully attaching metadata to WebP images will be saner than it is for JPEGs.
- pjscott 16y ago
  It shouldn't be too long before Android phones start supporting WebP natively, and image-hosting sites like Picasa and Flickr already do re-encoding to lower the image size; adding WebP to that shouldn't be a serious problem. I can see this getting traction even without support from most digital cameras. As for metadata, the container format is based on RIFF, which consists of tagged binary chunks. Metadata chunks follow the image data, and consist of null-terminated strings. No word yet on whether or not you can use Unicode. http://code.google.com/speed/webp/docs/riff_container.html http://code.google.com/speed/webp/docs/riff_container.html
  - jbarham 16y ago
    > No word yet on whether or not you can use Unicode. You should be able to use UTF-8 since it doesn't include embedded nulls.
    - pjscott 16y ago
      Sure, but I'm worried about the guy who decides that his decoder will use ISO-8859-1 by default, or UTF-16 if that's specified in some meta-metadata chunk somewhere. If this were written down in a spec, we wouldn't have to fret about it.
pmjordan 16y ago
Looks like they didn't bother to seize the opportunity to add an alpha channel. Being stuck with PNG for transparent/translucent images sucks.
- thesz 16y ago
  Lossy compression for alpha channel isn't that good idea, I think. Brightness and color compression artefacts will be multiplied by alpha compression artefacts.
  - kevingadd 16y ago
    Then provide baseline support for an uncompressed alpha channel. Not being able to store one at all in an image limits the usefulness of the format. Artifacts for lossy alpha compression are already, to some extent, well understood and dealt with, since compressing video game textures that contain an alpha channel is already done lossily using the DXTC compression formats.
  - pmjordan 16y ago
    You could choose alpha compression quality separately from luma/chroma. Alternatively, either compress the premultiplied colour values directly, or compress raw colour but optimise the premultiplied error.
metamemetics 16y ago
Just a note to anyone using Adobe software to produce their web PNGs: Make sure to run PNGCrush to remove all extraneous information in them! http://pmt.sourceforge.net/pngcrush/index.html http://pmt.sourceforge.net/pngcrush/index.html
- Osmose 16y ago
  Does this apply when using the Export options in Fireworks, is it just for saving as a Fireworks PNG?
- dagw 16y ago
  Just be sure to test your crushed pngs under all the situations in which they'll be used. I've had a few situations where PNGCrushed files couldn't be opened by certain programs, but the uncrushed files could. In particular the Python image library tends to choke on files that have been run through PNGCrush.
sbarre 16y ago
I love this site! Reading the comments here has taught me more about image compression in 45 minutes than I've learned from reading random articles on the web for the last few years...
sswam 16y ago
The Jpeg shown is of a higher fidelity than the WebP image; look around the top edge of the red quadrilateral. In the Jpeg image, the edge is sharp, in the WebP image it looks a bit like the coloured sprinkles you might put on ice-cream. It would be better to show two versions of an image, having the same file size, so that we can look for any difference in quality. Read more: http://news.cnet.com/8618-30685_3-20018146.html?communityId=2140&targetCommunityId=2140&blogId=264&messageId=9908776&tag=mncol;tback#ixzz113sUDAa0 http://news.cnet.com/8618-30685_3-20018146.html?communityId=...
- sswam 16y ago
  I suspect that the improvement is not good enough that this image format would be adopted, when jpeg is already established.
jomohke 16y ago
Have they explained their reasons for not backing JPEG-XR instead? This seems to be a step back from JPEG-XR: - No alpha support - Not lossless support (Useful for the alpha channel, and could encourage more cameras to support lossless images) - No HDR support JPEG-XR also allows different regions of the image to be encoded independently. See wikipedia for more features: http://en.wikipedia.org/wiki/JPEG_XR http://en.wikipedia.org/wiki/JPEG_XR I have no idea what the patent landscape for JPEG-XR is, but I'd be disappointed if we replaced JPEG and didn't get some of these features. The lack of alpha support in JPEG is especially a pain for web developers. PNG does not do photos well.
- Groxx 16y ago
  Gah! No alpha? Count me out. The web NEEDS alpha channels. I can't count the number of hacks I've seen to get around the lack of an alpha channel in preferred-format-X.
- roel_v 16y ago
  I've seen the 'no alpha' repeated a few times, but can you give your use cases for alpha in jpeg? I understand the need for alpha channels in gif/png, and have fought the lack of alpha support for years, but for jpg's I don't remember ever needing it, nor can I easily imagine a situation where it would be needed. So I'm interested to learn about where you'd use transparency in jpgs.
  - ithkuil 16y ago
    why not? I mean, why should I be forced to use a lossyless image format just because I want it to blend with the background (if the image compresses better with jpeg and the image quality is fine) Are there technical reasons to not implement an alpha in jpeg-like compressions?
    - roel_v 16y ago
      Features shouldn't be there 'just because it's possible', at least not if they may impact other features(1). If greater compression can be reached by leaving out the alpha, and if there's no compelling reason to put it in, it should be left out. 'why not' is not a reason, there needs to be a business case for each feature, in everything. In my experience, and this seems to be a widely held position, the main use case for jpgs is in pictures, as in photographs. The main use case for png (gif) is for graphical elements: borders, menus, etc. Those last ones you want to compress with a lossless format anyway - you need to be sure that a flat menu background is not dithered or doesn't have other artifacts. I understand the question mostly as 'do you need transparency in photographs' and 'do you need non-rectangular photographs where the non-rectangular nature is encoded in the photograph itself, and not part of another rendering in stage in the presentation layer'. Thinking about it more, maybe things like drop shadows or other fancy borders could be case where you need transparency in photos. Otherwise you have to work around it by having the picture as jpg and the border as a separate (or several separate) png's. More requests, harder layouting, etc. I'm not convinced yet that this use case alone is a compelling argument. As for technical reasons to not implement it, I don't know - I'm assuming there are because I'm quite sure that someone at Google must've thought about it and decided against it, they must have had their reasons. (1) I'm reasoning from the assumption that including transparency has adverse effects on file size and/or decompression complexity. Maybe there aren't in which case balancing features becomes a different matter and most of my argument is moot.
lazugod 16y ago
There's a conversion tool available for WebP now: http://code.google.com/speed/webp/download.html http://code.google.com/speed/webp/download.html
- pornel 16y ago
  They have only Linux binary. I've compiled one for Mac OS X: http://pornel.net/webp http://pornel.net/webp

204 points by ukdm 16y ago

Won't the on-line Porn Industry have to adopt this for large scale adoption to take place? I'd think that the size decrease alone would sell the Porn Industry.

mhd 16y ago
Are galleries that important? I thought right now it's all about videos.
- nlogn 16y ago
  What about all the "video preview" images? Surely porn sites would benefit from serving less bytes there.
  - mhd 16y ago
    I don't think those are important enough to risk browser compatibility issues, I don't see a reason why the porn industry would throw its weight in the ring because of this. And that's if this new format would actually have advantages at these sizes. The factor doesn't need to remain constant in different resolutions. (And even if, we're talking about small pictures anyway, so if you save 1kb per preview pic, would this matter compared to the video stream bandwidth?)
    - pjscott 16y ago
      There are no browser compatibility issues if you use conservative HTTP content negotiation. Browsers which support WebP can say so in their HTTP Accept headers, and the server can serve WebP to those browsers, falling back on ordinary JPEG for older browsers. This was also used back when PNG support was spotty, by sites which wanted to combine the goodness of PNG with the ubiquity of GIF. It's actually pretty simple: http://en.wikipedia.org/wiki/Content_negotiation http://en.wikipedia.org/wiki/Content_negotiation Now that I think about it, there's probably a business opportunity for someone who handles such hosting issues for image-heavy web sites. The porn industry may seem sketchy, but they have a lot of money and a pressing need to keep overhead down.
      - mhd 16y ago
        Yes, but it has to have some significant effect. For this to happen, the gain from the format conversion has to matter for the porn sites use case, this has to be a certain percentage of bandwidth (wonder how that's for video sites), and then the amount of browser who support it (not just advertise it, cf. IE and its PNG "support") has to be high enough. Anybody got some statistics on browser distribution on a major *tube site? I guess we'll see a lot of Internet Explorer there, although it Chrome's "incognito" mode may have found some fans.
        pjscott 16y ago
        The cost of format conversion can be made very low by having it done automatically by the web server. It'll just take some time for the software to do that.
- barrkel 16y ago
  Soft / "art" sites focus much more on stills, and headline pixel counts, e.g. met-art etc. I would expect them to prefer large file sizes, to aggravate people who like to scrape content.
  - RexRollman 16y ago
    As a past member of Met-Art and current member of Digital Desire, I would think that this has the potential to save lots of bandwidth for those types of services. And even the services that do specialize in videos usually offer photos sets of shoots, so it would still benefit them as well. The trick will be to build enough mass to make it common enough for all the browsers to support WebP. I can see Firefox and Webkit adding it fairly quickly, so the real question is, if and when will Microsoft support it?
  - wtracy 16y ago
    I would expect the large file sizes to hurt the host at least as much as the scrapers. Better to insert random delays in responses to HTTP requests from suspected scrapers (or outright reject them).
  - pjscott 16y ago
    I would expect them to prefer smaller file sizes, especially in public preview galleries, to lower their bandwidth costs. Someone scraping high-quality images incurs a small one-time bandwidth cost, and they can re-encode the images at a lower quality if they want to save bandwidth.
deleted 16y ago
[deleted]

bartl 16y ago

Why is the performance of PNG so disappointing? The WebP sample image from the article (top image) is shown here as a PNG of 234kB...

mhd 16y ago
There are limits to non-lossy compression…
- wmf 16y ago
  Also, PNG isn't very good for photos and other "natural" images; JPEG-LS (which nothing supports) is much better.
samdk 16y ago
Partly because PNG is lossless, but also largely because that's not the kind of image that PNG compresses well. JPEG is a better format (than PNG) to use for photos and similar types of images, because it does an okay job of compressing them and because the compression artifacts are a lot less noticeable. However, JPEG is a really bad format for things like graphics with lots of flat colors or text, because there the compression artifacts are very easy to see. This image from Wikipedia comparing the two shows the difference: http://en.wikipedia.org/wiki/File:Comparison_of_JPEG_and_PNG.png http://en.wikipedia.org/wiki/File:Comparison_of_JPEG_and_PNG... PNG has the advantage of being lossless, and so it performs very well in some situations, but very poorly in others. Photos and images like them are an example of where PNG compresses poorly, because the . PNG actually does outperform JPEG (compression-wise) on some kinds of images though: those with lots of flat colors/text/gradients/etc., and those conveniently end up being the kinds of images where compression artifacts are really visible. tl;dr: Use the right format for the job. PNG is not good at compressing photo-like images, but does really well at things like diagrams and vector graphics. JPEG is best-used for things like photos where compression artifacts aren't a huge deal. If you're looking to learn more about how JPEG and PNG compress images, I recommend checking out Smashing Magazine's guides to JPEG and PNG optimization techniques. (I don't usually recommend Smashing Mag articles, but these are both good.) Both will give you some insight into how these things work. http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optimization-techniques/ http://www.smashingmagazine.com/2009/07/01/clever-jpeg-optim... http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/ http://www.smashingmagazine.com/2009/07/15/clever-png-optimi...

lmkg 16y ago

Wait, so Google took a bunch of JPGs, re-compressed them with a lossy format, and claims to have gotten them 40% smaller with no loss in quality. Either the lossyness in the format is entirely in aspects of the image that the JPG compression already removed and they're just better at compressing the residue (possible, but I am skeptical), or else the image is altered, but in a way that Google claims is subjectively a sidegrade in quality. I'm not putting much faith in their quality claims until I see side-by-side comparisons of a JPG and WebP compression of the same TIFF (or other uncompressed) image at the same compression ratio. A double-blind study is probably too much to ask, but it would be nice.

wccrawford 16y ago
That's that the article says, but they're probably restating something and got it horribly wrong. What probably happened was that they took images and compressed them to WebP and JPEG and compared the sizes.
- dgreensp 16y ago
  No, I would believe Google recompressed a whole ton of JPEGs as a test. Not the most scientific test of a codec, but as a Web company they are interested in improving image serving more than image authoring. As for the recompression, you can losslessly squeeze a JPEG by at least 15% (e.g. StuffIt came out with this a few years back, claiming higher numbers but mainly at low bitrates I think). In the lossy camp, H264's intra-frame encoding significantly outdoes both JPEG and JPEG2000. WebP is probably similar to H264 intra. As for recompression vs. straight compression, this probably has little effect to the extent JPEG and WebP are "compatible", e.g. both being block-based transforms. It would be unfair, on the other hand, to run a very different codec after JPEG and compare it to WebP after JPEG, because the other codec might be working hard to encode the JPEG artifacts.
  - jacobolus 16y ago
    > It would be unfair, on the other hand, to run a very different codec after JPEG Exactly. I found Google’s “study” pretty sketchy, given the lack of concrete detail about this. http://code.google.com/speed/webp/docs/c_study.html http://code.google.com/speed/webp/docs/c_study.html Here’s some of what I wrote in an email to a friend: Since they’re dealing with an arbitrary collection of already encoded images, there are likely e.g. artifacts along JPEG block boundaries that take up extra space in JPEG 2000. While they have a big sample size, they don’t compare the metric used (PSNR) with noticeable quality degradation. There's a graph of size distribution (which would be a lot more readable if they binned some of the sizes and showed a histogram instead of a sea of overlapping red plus signs), but then compression percentages aren't in any way related to those various sizes: were big images easier to compress better than JPG/JP2? Small images? Looking at the size distribution, a large percentage of these images are absolutely tiny, the kinds of images that as far as I know JPEG 2000 was never intended to be used for. The overhead of the data storage container ends up dominating the size of the image for very tiny images – I don’t know anything about the relative overhead of JPG/JP2/etc. images, but it would be good to include that in any discussion. It seems to me like the WebP images have their color profiles stripped. Is that an inherent part of WebP? If so, I hope Google doesn’t encourage people dealing with photographs to adopt it in large numbers. Browsers are just finally getting to the point where proper color management of images is expected; no need to regress there.

Terretta 16y ago

At 8 times longer to compress, this reminds of Iterated Systems FIF, but article claiming based on WebM suggests it's still DCT compression. Adoption by just Flickr and Facebook could push a new image format fast. Google has much to gain since they archive a copy of indexed images. Hence their interest in "recompression".

shawndumas 16y ago

Not sure about this one google. Firstly, Worst. Name. Ever! Secondly, what kind of browser support do they think they'll get? I know ie is covered via google chrome frame but will Apple and Mozilla jump on this? Both issues have alloyed this one on me.

aw3c2 16y ago
Well, the name hints at a close relationship to WebM so I guess they target the same progressive browsers.
- shawndumas 16y ago
  My boss walked passed and I called him over to tell him about WebP and he literally laughed out loud at the name. I said it without a hint of sarcasm and it was the first thing he noticed. Anecdotal I know; but still...
  - sandipc 16y ago
    this reminds me of the internet's reaction to the name "iPad" - although I haven't heard anything along those lines since the first week it was announced.
njharman 16y ago
Chrome is a given, Firefox (and isn't webkit) is open source. Google has the devs to write the needed code/extension and give it to those projects.
- shawndumas 16y ago
  Okay, I'll buy that Chrome and ie are a shoe-in, and that FF is probably easy. So that leaves Apple and Opera. Not bad, not bad...
  - redrobot5050 16y ago
    Chrome and Safari both use WebKit. If Google releases an implementation, it shouldn't be hard for Apple to adopt it. That just leaves Opera.

goalieca 16y ago

I was hoping Jpeg2000 would take over because it is so flexible. It encodes really well at the low end and really well at the high end. You can target a specific file size and have it produce it. Instead of the blocking artifacts caused by the 8x8 DCT grid, you get smooth blurring.

InclinedPlane 16y ago
Sadly, jpeg2000 may never catch on until the patents encumbering it expire.
- wmf 16y ago
  Given that the JPEG 2000 patents are licensed royalty-free, I think this says something about open source patent nitpicking. "All patents that WG1 believes to be essential to practice JPEG 2000 Part 1 are available on ITU-T’s patent policy 2.1, which is fee-free (see the ITU-T web site for their interpretation of this)." http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q3f042a68b1081 http://www.jpeg.org/faq.phtml?action=show_answer&questio...
  - pbhjpbhj 16y ago
    Two things after a quick scan of the page: 1) "Again, at every JPEG meeting the following resolution is also passed unanimously" appears to be saying each year they vote whether to continue or wether to reel in the bait. Tasty free morsels given by fisherman often turn out to have hooks attached. 2) It appears that one has to give up any patents that read on to a baseline spec for JPEG. This sounds like it could be bad for large multimedia companies who want to retain rights to an image format - what's the baseline. If the baseline is something like "uses huffman codes to compress image data" then this is going to be a potential huge cost in IPR given up. These are possibly unfounded, just first thoughts at 2am.
- nwmcsween 16y ago
  This hasn't stopped nearly every codec popular today.

sudonim 16y ago

Please, if anyone can figure out a format so my mom doesn't attach 10 mb files that should be 750k, I'm all for it.

dkarl 16y ago
An actually helpful suggestion (I hope): help her change the settings on her camera. Explain that she'll be able to take more pictures without filling up the memory.

MikeCapone 16y ago

Our CPUs are so much faster than even a few years ago, but bandwidth hasn't increased that much (at least not here in Canada). I'd gladly trade some CPU cycles for bandwidth (or same bandwidth, but better quality).

jessriedel 16y ago

As a regular person, I really can't see a 40% decrease in size (of which I'm skeptical) for just jpeg images (not nearly the full "65% of the bytes on the web") being worth the huge switch-over costs. The ubiquity of jpeg is just too valuable.

wmf 16y ago
If you understand how to use content negotiation (which basically no one outside Google does) then there's virtually no switching cost.
- jessriedel 16y ago
  I mean cost beyond just web development. As mentioned in the article, there is a massive range of consumer and non-consumer products which have adopted jpeg as a universal format.
  - wmf 16y ago
    So those devices just keep on using JPEG and thus bear no additional cost. Even if WebP is only used between Google and Chrome, it will be worth it for Google.

acdha 16y ago

I'd be very curious in seeing a comparison with JPEG-XR, which has a number of nice advantages for photography.

confuzatron 16y ago
I've been googling for examples of that format to no avail. I just wanted to see if Google's browser supports it.

gshayban 16y ago

With OLED/IPS etc. taking over in the next few years, will this really support >8bpp or HDR? Interesting move, Google

jbarham 16y ago
WebP uses the same color model as WebM which "works exclusively with an 8-bit YUV 4:2:0 image format" so seems like WebP will not be HDR capable, which is a pity.
- Maskawanian 16y ago
  Considering it basically is 1 frame of WebM it isn't exactly a surprise either.

drv 16y ago

There's no way this will catch on; the slight image quality per bit improvement is not nearly enough to counteract the huge momentum of existing JPEG use. Certainly JPEG isn't the best possible image codec or even all that good, but it's good enough, and it works everywhere.

nphase 16y ago

But there is a loss in quality! The dithering is noticeably worse. Notice the light outline on that red-ish thing in the top middle of the image. I bet I could've gotten the 10kb decrease by just lowering the JPG quality.

mayank 16y ago
Umm...how can you claim a loss in quality without looking at the original? The linked page shows two lossily compressed versions of an unknown original image. You're commenting on which image subjectively LOOKS better to you, not on compression quality.
- deleted 16y ago
  [deleted]
- Tomek_ 16y ago
  Take a look at those red and orange "things" in the center of the image in the PNG/WebP version. My bet is on a loss in quality.
- nphase 16y ago
  My point was just that they're showing a lower quality image that is is lower in size. Great, ice is cold.

igrekel 16y ago

The article is quite light so far. I am sure it brings other improvements than just a reduced file size. I would hope that at least some features of JPEG2000 would make it in this format. Maybe also a convenient way to pack several images in a single file without resorting to css clipping tricks.

jmspring 16y ago

JPEG (and many image/video coding algorithms) are really made up of a couple pieces -- transform, modeling and entropy coding. In the case of JPEG, the transform is handled through breaking the image up into eight by eight blocks that are then run through the DCT and quantized. This is where the loss comes from. Modeling and entropy coding are handled on the coefficients generated above. However, this is done on each 8x8 block (note, I am making a slight simplification ignoring the use of differential compression on the DC coefficients between blocks. Since the algorithm is relegated to encoding at most 64 coefficients at a time, there isn't much "modeling" that can be done. If one reorders the coefficients of the 8x8 blocks to resemble a non-block based transform -- you can perform better modeling to get much better compression with the exact same image quality as the original JPEG image. However, in this case, you lose compatibility with a JPEG encoder since the format of the coefficients is not JPEG.

eru 16y ago
One simple way to be able to throw more CPU at image compression/decompression, and thus save space, could be to use bigger blocks than 8x8.

jdavid 16y ago

This has other implications. * a save in bandwidth is huge on mobile speed, google believes that speed effects web use, web use effects revenue * a save in bandwidth is cheaper for google * att, verizon, sprint, and tmobile are limiting mobile data plans, smaller images means more web page loads * net neutrality might fail, you might have to pay for data * google runs a lot of content via app-engine, gmail + chrome, google should be able to make the switch for the stacks they own to develop an advantage. * others will follow in adoption like facebook if it saves them on one of their largest costs cdns. * openness an open format can go on more devices. * open devices might appear faster on the web.

jbarham 16y ago

Given that most JPEG images are generated by digital cameras, I don't think WebP will get any traction until Canon, Nikon et al support WebP natively. And hopefully attaching metadata to WebP images will be saner than it is for JPEGs.

pjscott 16y ago
It shouldn't be too long before Android phones start supporting WebP natively, and image-hosting sites like Picasa and Flickr already do re-encoding to lower the image size; adding WebP to that shouldn't be a serious problem. I can see this getting traction even without support from most digital cameras. As for metadata, the container format is based on RIFF, which consists of tagged binary chunks. Metadata chunks follow the image data, and consist of null-terminated strings. No word yet on whether or not you can use Unicode. http://code.google.com/speed/webp/docs/riff_container.html http://code.google.com/speed/webp/docs/riff_container.html
- jbarham 16y ago
  > No word yet on whether or not you can use Unicode. You should be able to use UTF-8 since it doesn't include embedded nulls.
  - pjscott 16y ago
    Sure, but I'm worried about the guy who decides that his decoder will use ISO-8859-1 by default, or UTF-16 if that's specified in some meta-metadata chunk somewhere. If this were written down in a spec, we wouldn't have to fret about it.

pmjordan 16y ago

Looks like they didn't bother to seize the opportunity to add an alpha channel. Being stuck with PNG for transparent/translucent images sucks.

thesz 16y ago
Lossy compression for alpha channel isn't that good idea, I think. Brightness and color compression artefacts will be multiplied by alpha compression artefacts.
- kevingadd 16y ago
  Then provide baseline support for an uncompressed alpha channel. Not being able to store one at all in an image limits the usefulness of the format. Artifacts for lossy alpha compression are already, to some extent, well understood and dealt with, since compressing video game textures that contain an alpha channel is already done lossily using the DXTC compression formats.
- pmjordan 16y ago
  You could choose alpha compression quality separately from luma/chroma. Alternatively, either compress the premultiplied colour values directly, or compress raw colour but optimise the premultiplied error.

metamemetics 16y ago

Just a note to anyone using Adobe software to produce their web PNGs: Make sure to run PNGCrush to remove all extraneous information in them! http://pmt.sourceforge.net/pngcrush/index.html http://pmt.sourceforge.net/pngcrush/index.html

Osmose 16y ago
Does this apply when using the Export options in Fireworks, is it just for saving as a Fireworks PNG?
dagw 16y ago
Just be sure to test your crushed pngs under all the situations in which they'll be used. I've had a few situations where PNGCrushed files couldn't be opened by certain programs, but the uncrushed files could. In particular the Python image library tends to choke on files that have been run through PNGCrush.

sbarre 16y ago

I love this site! Reading the comments here has taught me more about image compression in 45 minutes than I've learned from reading random articles on the web for the last few years...

sswam 16y ago

The Jpeg shown is of a higher fidelity than the WebP image; look around the top edge of the red quadrilateral. In the Jpeg image, the edge is sharp, in the WebP image it looks a bit like the coloured sprinkles you might put on ice-cream. It would be better to show two versions of an image, having the same file size, so that we can look for any difference in quality. Read more: http://news.cnet.com/8618-30685_3-20018146.html?communityId=2140&targetCommunityId=2140&blogId=264&messageId=9908776&tag=mncol;tback#ixzz113sUDAa0 http://news.cnet.com/8618-30685_3-20018146.html?communityId=...

sswam 16y ago
I suspect that the improvement is not good enough that this image format would be adopted, when jpeg is already established.

jomohke 16y ago

Have they explained their reasons for not backing JPEG-XR instead? This seems to be a step back from JPEG-XR: - No alpha support - Not lossless support (Useful for the alpha channel, and could encourage more cameras to support lossless images) - No HDR support JPEG-XR also allows different regions of the image to be encoded independently. See wikipedia for more features: http://en.wikipedia.org/wiki/JPEG_XR http://en.wikipedia.org/wiki/JPEG_XR I have no idea what the patent landscape for JPEG-XR is, but I'd be disappointed if we replaced JPEG and didn't get some of these features. The lack of alpha support in JPEG is especially a pain for web developers. PNG does not do photos well.

Groxx 16y ago
Gah! No alpha? Count me out. The web NEEDS alpha channels. I can't count the number of hacks I've seen to get around the lack of an alpha channel in preferred-format-X.
roel_v 16y ago
I've seen the 'no alpha' repeated a few times, but can you give your use cases for alpha in jpeg? I understand the need for alpha channels in gif/png, and have fought the lack of alpha support for years, but for jpg's I don't remember ever needing it, nor can I easily imagine a situation where it would be needed. So I'm interested to learn about where you'd use transparency in jpgs.
- ithkuil 16y ago
  why not? I mean, why should I be forced to use a lossyless image format just because I want it to blend with the background (if the image compresses better with jpeg and the image quality is fine) Are there technical reasons to not implement an alpha in jpeg-like compressions?
  - roel_v 16y ago
    Features shouldn't be there 'just because it's possible', at least not if they may impact other features(1). If greater compression can be reached by leaving out the alpha, and if there's no compelling reason to put it in, it should be left out. 'why not' is not a reason, there needs to be a business case for each feature, in everything. In my experience, and this seems to be a widely held position, the main use case for jpgs is in pictures, as in photographs. The main use case for png (gif) is for graphical elements: borders, menus, etc. Those last ones you want to compress with a lossless format anyway - you need to be sure that a flat menu background is not dithered or doesn't have other artifacts. I understand the question mostly as 'do you need transparency in photographs' and 'do you need non-rectangular photographs where the non-rectangular nature is encoded in the photograph itself, and not part of another rendering in stage in the presentation layer'. Thinking about it more, maybe things like drop shadows or other fancy borders could be case where you need transparency in photos. Otherwise you have to work around it by having the picture as jpg and the border as a separate (or several separate) png's. More requests, harder layouting, etc. I'm not convinced yet that this use case alone is a compelling argument. As for technical reasons to not implement it, I don't know - I'm assuming there are because I'm quite sure that someone at Google must've thought about it and decided against it, they must have had their reasons. (1) I'm reasoning from the assumption that including transparency has adverse effects on file size and/or decompression complexity. Maybe there aren't in which case balancing features becomes a different matter and most of my argument is moot.

lazugod 16y ago

There's a conversion tool available for WebP now: http://code.google.com/speed/webp/download.html http://code.google.com/speed/webp/download.html

pornel 16y ago
They have only Linux binary. I've compiled one for Mac OS X: http://pornel.net/webp http://pornel.net/webp