27 ms·

Is WebP really better than JPEG?

424 points by kasabali 6y ago

NovemberWhiskey 6y ago
Does anyone know how these compare with the HEIC format that it seems my iPhone now uses by default? Is that non-mainstream, or otherwise not fit for comparison?
- izacus 6y ago
  It's a proprietary patent-encumbered format which isn't really widely supported in the web browsers.
  - zerocrates 6y ago
    I happened to look it up on caniuse.com yesterday and it's just a field of solid red: nobody supports it, not even Safari.
  - Y-bar 6y ago
    Patent-encumbered? Yes. > proprietary No. It is an open standard (ISO/IEC 23008)
    - chungus_khan 6y ago
      Being patent-encumbered kind of makes it moot on the web though, just like H.265 video.
    - NovemberWhiskey 6y ago
      Oh - so actually AVIF (as discussed in the original article) is an HEIF container with AV1 as the codec, and HEIC is the same but with H.265.
- chrisbrandow 6y ago
  I’d be curious about that as well. I made my own minor comparisons, and heif did well, but there are a ton of possible pitfalls my comparison may have been subject to so I’d love to see a comparison by someone with expertise
- irrational 6y ago
  I thought HEIC is apple only and not supported by any browser. Is it even supported by Safari?
  - deleted 6y ago
    [deleted]
  - reaperducer 6y ago
    HEIC/HEIF is not an Apple format. It's an MPEG format that's been around for half a decade. Apple started supporting it in 2017. Microsoft in 2018. You are correct, though — it's not supported by any browser.
- innocenat 6y ago
  I haven't follow the trend much nor seen a recent comparison, so take this with a grain of salt. WebP is based on VP8, which was considered to be competitor to H.264 (AVC). HEIC is based on H.265 (HEVC), which competes with VP9 and AV1. So I'd assume WebP is one generation behind HEIC. WebP was introduced 5 years before HEIC though.
  - pornel 6y ago
    Correct. WebP is 10 years old, based on the VP8 codec that is about 14 years old, which lost in the market to H.264 that is 17 years old. In video streaming VP8 has been completely replaced by VP9 years ago, and VP9 was going to be replaced by VP10 which became part of AV1. So WebP is hardly new, and a couple of generations behind. Now the next hotness is AVIF (or maybe JPEG XL), so ironically, WebP is becoming usable and obsolete at the same time.
- reaperducer 6y ago
  I like HEIC under the hood, but it's not suitable for web as it has exactly zero browser support. https://caniuse.com/#search=heif https://caniuse.com/#search=heif I'm surprised that Safari doesn't support it. I believe Apple released a bit of Javascript that lets you embed the animated HEIF images (I think they're called "live pictures") in your web site, but that's kind of a niche use.
kome 6y ago
tl;dr: it's not. And it's also a very annoying to deal with them, I might add, especially when you need to save them or to work with them, as they are not natively supported by macOS or win.
Santosh83 6y ago
As someone who hosts images on their site, what is the best software (preferably open source) one can use to compress JPEG images imported from a digital camera? I would be glad to serve only JPEGs and dispense with WebP versions and simplify my site html. A straightforward encoding of a JPEG into a WebP (using GIMP) does give me an almost 1/3rd reduction in file size, which is not insignificant.
- singlow 6y ago
  ImageMagick
- zimpenfish 6y ago
  imager.io was on here recently and seems to do a good job compressing into normal JPEG images. https://github.com/imager-io/imager https://github.com/imager-io/imager
- theandrewbailey 6y ago
  When you convert JPEG to WebP, you're converting data in a lossy format to another lossy format. Of course you're going to get good JPEG to WebP compression, because you're starting with a low-quality source. If you start with a lossless image (RAW/PNG/TIFF/etc.) instead of a JPEG, you might get different results.
- acdha 6y ago
  Re-encoding will produce smaller images because it’s discarding information - if you compare that WebP image you the original you’ll inevitably see fine detail is missing. That may or may not be reasonable but to be fair you’d want to compare it with different quality levels using MozJPEG. The easiest way to do a simple comparison might be to install ImageOptim and process a few images with various tools. Based on that you could put the same tools into your site’s workflow.
- tyingq 6y ago
  Others have mentioned you're using 2 lossy formats. You would probably get a similar end file size with jpegoptim. Compile it with mozjpeg for even smaller sizes.
HenryKissinger 6y ago
I make a lot of memes for Reddit with MS Paint. I tend to avoid WebP because of compatibility issues. Neither Reddit's native image host nor Imgur allows WebP files, and I save memes using images from multiple formats (e.g. a jpg, a png, and a WebP) in jpg or png to avoid that. When a WebP file is saved into jpg or png Paint gives an error message about how this will erase all transparency, but for my purposes that is not a problem.
- whywhywhywhy 6y ago
  I mean Photoshop doesn't even support it either so every encounter I have with this file format has been an exercise in frustration and honestly would have preferred it if it just went away and was replace with something companies are free to implement safely.
  - tracker1 6y ago
    IIRC WebP is open-source and unencumbered by patents so there's no reason it couldn't be implemented. That said, it's not a good source format.
mrob 6y ago
Is there something wrong with the AVIF decoder's chroma upscaling? E.g. look at "Kodim 3", where the colored hats overlap each other. There's severe blocking, where I'd expect blurring instead. All the other formats blur, which is much less distracting.
- theandrewbailey 6y ago
  I've noticed that too. I've been testing AVIF, and the reference encoder[0] defaults to 4:4:4 (no chroma downsampling) if you don't tell it otherwise. I tried 4:2:0 and it looked horrible, but the size hit for 4:4:4 wasn't bad and looked much better. [0] https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif
Jonnax 6y ago
So what's this AVIF format they mention that's actually better than both? WebP did not take off. But will AVIF be any better?
- theandrewbailey 6y ago
  It's based on the next-gen AV1 video codec. I've tried it out, and it's amazing. https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4?gi=e1406a7d46e6 https://netflixtechblog.com/avif-for-next-generation-image-c... https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif
- masklinn 6y ago
  > So what's this AVIF format they mention that's actually better than both? AVIF is an image format based on the intra-frame coding of AV1, as WebP is to VP8 and HEIF is to HEVC. AV1 and HEIF are super recent though, the AVIF 1.0 spec was only released in early 2019. By comparison, WebP was initially released in 2019. So AVIF currently has very little support (it's behind flags in Firefox and that's it). However all the big names are part of AOM, which oversees AV1 (and AVIF): http://aomedia.org/membership/members/ http://aomedia.org/membership/members/ So chances are pretty high it'll get widespread support, eventually. There’s one problem though: like WebP, AVIF just is not solving a big issue.
  - nerdkid93 6y ago
    - WebP was initially released in 2019 + WebP was initially released in 2010
- flowerbeater 6y ago
  I think it's just about to take off. Browser support across the board is coming by the end of the year. PNG also took a while to become fully supported, so we just need some patience.
lowmemcpu 6y ago
I'm using Firefox and just tried to save a webp image and it tried to save as a web page. [initially, I said no.. see edit below] Edit: Looks like it was that specific website and they are doing something odd, so I retract my initial judgement.
- discreditable 6y ago
  Is that server sending the image with the correct mimetype?
  - lowmemcpu 6y ago
    Good point! I just went back and checked that specific site, and they are definitely doing something odd. I retract my previous judgement
untog 6y ago
FWIW one of the reasons this has become relevant again is because the next version of Safari supports WebP. The article's discussion of AVIF is interesting but you're not going to be able to use it on the web any time soon. I'd be curious to see a WebP vs PNG comparison, since (IIRC) it has a lossless mode too.
- chungy 6y ago
  Lossless is pretty easy, there's no subjective qualities to compare, just file size. WebP Lossless almost always results in a smaller file than PNG. I have seen exceptions to this, but they're sufficiently rare that it's not worth worrying about.
pixelbath 6y ago
Subjectively, I'd say at those settings the WebP versions look slightly worse, though they don't suffer from the blocking artifacts native to JPEG. For the images I serve on my sites, a few KB here and there aren't going to make a huge difference, and I'd rather avoid the hassle of serving content that isn't universally supported.
- mrob 6y ago
  In most cases I prefer the WebP versions, but the JPEG formats handle chroma noticeably better. E.g. look at the purple band on the rightmost helmet in the 500 pixel version of Kodim 5. WebP reduces the saturation by excessive blurring. CJPEG handles this image best IMO.
- MaxBarraclough 6y ago
  Take a look at the Kodim 3 example image, either the '500px' version or the '1500px' (but not the '1500px' version). Zoom in (400%) on the cap of the yellow hat. The lines of the cap are muddied under all lossy compressed formats, but surprisingly, plain old cjpeg does so less than the others. Generally though I find the new formats look better than JPEG.
deleted 6y ago
[deleted]
snoo5780 6y ago
Does anyone have insight as to whether this same evaluation re:AVIF applies to WebM? Edit: saw somewhere that it is used in production for real-time video, but had trouble using rav1e as opposed to libvpx
- acdha 6y ago
  Yes: Google heavily promoted their format but unless you’re serving a high volume of traffic it’s not worth the cost of doubling your storage and maintaining a separate toolchain to lower your transfer by perhaps 10%. By now more devices have hardware support so its performance is more competitive but at this point I’d go straight to AV1.
  - snoo5780 6y ago
    Perhaps should clarify. Much of the reaction appears to be to Safari support for WebP. Those reacting believe that WebP will stick around even though used VP8 (Could have just hurdled straight to AV1). So curious to ask if those same people reacting think WebM will also stick around longer. It’s a bit different since WebM uses VP9, but, there perhaps there are still potential issues, and personally not know about browser landscape/hardware support.
Eric_WVGG 6y ago
I just relaunched a website that makes extensive use of photographic collages that necessitate alpha backgrounds. They were previously shipping "retina-grade", multi-megabyte images all over, a typical page load could easily reach 25mb. I managed to refit it with `<picture>` tags using WEBP as well as JP2. The latter was a great deal of trouble, it appears that "the community" (notably Gatsby and Contentful) are very happy to talk about the benefits of WebP but conveniently ignore that Safari is the most important mobile browser, and Safari desktop is not insignificant. I bring this both to point out that there is a very valid reason to use WebP over JPEG — alpha blending — and that this entire field is still a gigantic mess.
- oauea 6y ago
  Safari Mobile is a broken mess not worth supporting.
  - ChrisMarshallNY 6y ago
    Since Safari (and WebKit) are the only available Web-rendering engine for iOS and iPadOS (and the default one for MacOS), it's kind of important to be able to at least render usefully on it.
  - donatj 6y ago
    I think by the nature of being the second most used browser, it's worth supporting. You don't have to like supporting it however. https://www.w3counter.com/globalstats.php https://www.w3counter.com/globalstats.php
    - kevin_thibedeau 6y ago
      Shades of IE6 Stockholm syndrome.
      - derefr 6y ago
        Very different problems. Many ISVs were stuck supporting IE6 for so long—long after it went into single-digit percentage usage—not out of some vague fear that someone, somewhere still used it; but because the particular moribund enterprise clients that they wanted to sell into still used it. (Otherwise, IE6 would have been just another irrelevant minority browser, like Opera.) Mobile Safari, meanwhile, is "still" used by 25% of people; but more importantly, iOS is used by 26% of people (52% in North America!), and those people can't actually get any other renderer than WKWebView, whether they use Safari or not.
dubcanada 6y ago
This is a weird comparison, while I get the comparison of non-transparent images jpeg or webp are probably fine. However the main benefit of webp is alpha backgrounds or transparency. It can destroy PNG when it comes to compression and size.
- RNiK 6y ago
  I would say it really depends on the PNG compression library you are using. Tools like RIOT or Compressor.io can give you optimal results on PNG compression.
buboard 6y ago
chrome keeps changing downloaded images to webP which is annoyin af. can't even find a way to disable it
- acdha 6y ago
  Are you sure that’s Chrome and not a website which selects the format based on the client’s advertised capabilities? I know Facebook did that and it confused a lot of people when a .jpg wasn’t a JPEG.
  - unnouinceput 6y ago
    For me was the same problem on Chrome. Switched to Firefox, same sites are happy to let me save their images as .jpeg instead of .webp
    - anonymoushn 6y ago
      I thought this might have been caused by a difference in whether image/webp is included in the Accept header on requests for web pages (not requests for images), since some people who run web sites prefer to serve different html to UAs that support and do not support webp rather than serving different image formats at the same URL. But when I looked at the Accept header Firefox sends for pages, it included image/webp. So I'm not sure what these sites are doing.
- crazygringo 6y ago
  It's not and you can't. The website is service up the images as webP. Chrome is just giving you what the website gives you, there's nothing to "disable".
  - bzb3 6y ago
    You could remove webp from the Accept header so the web server thinks your browser can't interpret webp. Not guaranteed to work, obviously.
  - 6y ago
jgrahamc 6y ago
Some data from when we deployed WebP generation: https://blog.cloudflare.com/a-very-webp-new-year-from-cloudflare/ https://blog.cloudflare.com/a-very-webp-new-year-from-cloudf...
ChrisMarshallNY 6y ago
I really want a better alpha-mask standard to emerge. PNG24 is attractive, but huge. PNG8/GIF works well, but is pretty limited. I don't think WebP is it, but we'll see what comes out of the scrum. I'll work with whatever that is, but I won't waste my time chasing will o' the wisp "standards."
- tombert 6y ago
  It's still relatively huge, and not widely supported without a polyfill, but FLIF [0] is a pretty neat format that tends to be smaller than the equivalent PNG, and can be converted to a lossy image "on the fly", and also supports alpha transparency. The polyfill is still kind of slow, at least compared to native PNG rendering on the browser, but it does work, and hopefully some day it can be integrated into the standard. [0] http://flif.info http://flif.info
  - andrius4669 6y ago
    >hopefully some day it can be integrated into the standard. see jpeg-xl
- thdrdt 6y ago
  Some time ago I experimented with a reduced color palette and dithering while keeping the fill alpha info. It reduced the file size a lot while keeping the alpha.
  - ChrisMarshallNY 6y ago
    Yeah, there's a number of ways to reduce GIF/PNG8 sizes. I started writing Web sites in the mid-'90s, where a page was supposed to be about 30K (quaint, huh?). The prevailing wisdom, then, was no dither, adaptive palette, and reduce the color palette until it hurts, then back up one.
karamanolev 6y ago
I'm surprised this doesn't include Google Guetzli (https://github.com/google/guetzli https://github.com/google/guetzli) in the comparison. In my experience trying to optimize product images for an eCommerce site, this provided the best compression. Yes, it's ridiculously slow, but for encode-once-transmit-often scenarios, it's perfectly usable.
- acqq 6y ago
  Did anybody really find any reason to use that? https://www.pixelz.com/blog/guetzli-mozjpeg-comparison/ https://www.pixelz.com/blog/guetzli-mozjpeg-comparison/ "MozJPEG files had fewer bytes 6 out of 8 times MozJPEG and Guetzli were visually indistinguishable MozJPEG encoded literally hundreds to a thousand times faster than Guetzli MozJPEG supports progressive loading"
  - karamanolev 6y ago
    I am compressing 200x200px and 800x800px images. For those sizes, while the encoding speed is slow for real-time use cases, for product images it's completely irrelevant - anything under 1 minute/image gets a pass and lower, generally, isn't better (or worse). I'm looking at absolute image quality/byte and it's even more niche than that - it's bytes to pass a threshold of acceptable quality (85 on Guetzli IIRC). I don't care about very low or very high qualities. In terms of absolute bytes to pass this threshold, Guetzli felt the best when I was doing the research (~ mid-2017). I don't have any hard data to back this though - I did the experiment with 5-6 different product images, drew the conclusion and started using Guetzli.
rakoo 6y ago
Extremely subjective, personal data point: I've been running with an extension (https://bandwidth-hero.com/ https://bandwidth-hero.com/) that compresses all images (including jpeg) and renders them in webp. I'm a typical social networks browser, so among the images I see a high majority of them don't need high quality. I'm running the extension with max compression but still keep colors: compression artifacts are clearly visible, but in my opinion they're not a problem. Looking at /r/all right now, there are 2 images that "deserve" to remain at the original resolution, the rest is typical pictures of text/memes that don't need all the bytes they currently have. The result: overall I saved 80% of data, just with images. In my case it's not so much a debate of JPEG vs WebP, but a debate of whether it's ok to keep images _on the web_ in their unoptimized form the way they are today, to which of course my answer is no. We don't need high quality images of a Facebook screenshot when compressing it to 20% of its original size can convey the same information with no subjective loss. I do agree on the unwieldy nature of WebP though, it's still mostly a read-only format right now and turns the web into a consumption platform
- andrewxdiamond 6y ago
  How does an extension resize an image without downloading it? Can it selectively read bytes from the stream?
  - cercatrova 6y ago
    It uses a proxy server as said on the landing page. That said, the service is shut down apparently so you have to self-host your own proxy server. That's not too useful for me so I uninstalled the extension.
    - rakoo 6y ago
      I self-host my own proxy server on my VPS, so I'm hoping said server is close enough to the origin to be useful in the overall reduction of transferred bytes
  - sp332 6y ago
    I suppose you could click on the provided link and find out?
alex_portabella 6y ago
I've recently converted some images to WebP on my side project Portabella [1]. I did it to appease Googles page speed test for SEO. But I agree with other comments in this thread that it's annoying so I might switch them all to JPEG and be done with it. [1] https://portabella.io https://portabella.io
unnouinceput 6y ago
Summary: - No. It's roughly the same. Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons.
- reaperducer 6y ago
  Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. Pithy comment, and reaction, aside, that's enough to give me pause about implementing it.
  - unnouinceput 6y ago
    *pity
- masklinn 6y ago
  > Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. WebP seems to have been the first "let's just use intra-frame coding" image format out there though, and it's hardly the first format to have tried to unseat JPEG. WebP is 4 years older than BPG (Bellard's HEVC-based format), 5 years older than HEIF (MPEG's same) and AVIF was only specified 9 years later.
- pornel 6y ago
  It's a sad story of broken promises. Back when video == Flash, Google bought and opened VP8 codec and got a bunch of companies to promise support for VP8 video. Back then it made a lot of sense to also have an image format based on exactly VP8 (despite it being a poor fit for still image format), since everyone promised to support it, including hardware acceleration. But Adobe never added VP8 to Flash, hardware support was too little too late. VP8 died, and WebP is burdened with compatibility with a world that never materialized.
yboris 6y ago
Obligatory mention of FLIF [0], FUIF [1], pik [2], and JPEG XL [3] as well as Jon Sneyers FLIF & FUIF were created by Jon Sneyers - http://sneyers.info/ http://sneyers.info/ and are lossless but progressive, generating better resulting images at every step of the image download and brilliant mobile support (your browser can just stop downloading the image once it reaches the quality sufficient for the viewport). A new update on the JPEG XL is worth reading: --> https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... [0] http://flif.info/ http://flif.info/ -- superseded by FUIF [1] https://cloudinary.com/blog/fuif_new_legacy_friendly_image_file_format https://cloudinary.com/blog/fuif_new_legacy_friendly_image_f... -- FLIF is lossless and amazing, in part absorbed by JPEG XL [2] https://github.com/google/pik https://github.com/google/pik - from Google, got absorbed by JPEG XL [3] https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
The_rationalist 6y ago
Jpeg XL is the real thing
zmix 6y ago
I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website: BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are: * High compression ratio. Files are much smaller than JPEG for similar quality. * Supported by most Web browsers with a small Javascript decoder (gzipped size: 56 KB). * Based on a subset of the HEVC open video compression standard. * Supports the same chroma formats as JPEG (grayscale, YCbCr 4:2:0, 4:2:2, 4:4:4) to reduce the losses during the conversion. An alpha channel is supported. The RGB, YCgCo and CMYK color spaces are also supported. * Native support of 8 to 14 bits per channel for a higher dynamic range. * Lossless compression is supported. * Various metadata (such as EXIF, ICC profile, XMP) can be included. * Animation support. [1] https://bellard.org/bpg/ https://bellard.org/bpg/
- notRobot 6y ago
  Relying on JavaScript just for images is a terrible idea. That said, I do think it's a neat project and can be used if there are proper fallbacks to formats that are natively supported.
- reaperducer 6y ago
  can be supported in any browser via a Javascript I think you answered your own question right there. I'm not going to use a dumptruck to bring a single sack of sand to my garden.
  - nine_k 6y ago
    For an image gallery, the balance could be the opposite: a small (56k) download of a decoder allowing to show many large (a few megs each) pictures. I wonder how good the performance of that decoder is, though; if the decoding delay is much longer that the network transfer delay, the approach becomes much less appealing.
    - acdha 6y ago
      It's also not common to need a ton of huge images all at once — in almost all applications you're either displaying thumbnails and JPEG is fine and will load faster thanks to the browser's preloader getting those requests in faster than the JavaScript can run or you're looking at something like pages where the latency is easily hidden by preloading. That means that in most cases the main driver is lower network transfer and you need to be serving a LOT of images to outweigh the cost of having to support something new and complicated versus something as widely tested and supported as JPEG.
deleted 6y ago
[deleted]
throw0101a 6y ago
I'm more interested in hearing about support for AV1. * https://en.wikipedia.org/wiki/AV1 https://en.wikipedia.org/wiki/AV1
- masklinn 6y ago
  AVIF is in the comparison, and the article notes it's in Firefox (behind a flag) and ought be coming to Chrome soon.
mindfulplay 6y ago
Two major advantages: transparency and optional lossless. JPEG blocky artifacts are very hard to remove for high resolution images unless you hand tune them.
zspitzer 6y ago
One of the biggest barriers against adoption of these newer formats is the lack of pure java implementations for use server side. The Java wrappers around a native binary are helpful, but for many projects not very useful and this hinders adoption. https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue+is%3Aopen+label%3A%22Sponsor+needed%22 https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue...
- adityapatadia 6y ago
  Is JAVA still a thing?
  - theduder99 6y ago
    for sure and it is probably doing the heavy lifting behind many of the companies+governments you interact with.
- grishka 6y ago
  Using Java code for things that are this performance critical doesn't feel like a good idea. It will work of course, but it will probably GC a lot, and while modern JVMs do JIT, the code they generate can't be as optimal as something that has manual SIMD optimizations.
  - lmm 6y ago
    Using C code is how you get the next cloudbleed. I'm happy to pay a performance cost for the sake of memory safety.
    - iomcr 6y ago
      Fix this easily by abstracting the manipulation of user uploaded files to chroot/serverless.
      - lmm 6y ago
        That doesn't fix the problem. The process can still fix any data that it has access to, which includes other users' confidential uploaded files.
gruturo 6y ago
Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. Even if the above were just an individual... bafflement? and not an actual issue, the size savings really don't seem worth the compatibility hassle, the extra manpower/workflow complexity to support 2 formats, the additional storage (and caching) caused by this duplication. And the above is if it's done RIGHT. 80% of people outside this forum won't understand that you're not supposed to convert from a lossy format to another, and just convert jpegs to webp. Webp seems so pointless. A progressive jpeg with an optimized Huffman table can be understood by a 27 year old decoder without issues, achieves 90% of the quality/size claims of webp and can be produced losslessly from your source jpegs. This is without even touching Arithmetic Coding (also lossless, part of the official standard, but poorly supported due to some software patents, even though they all expired by now), or playing with customized DCT quantization matrices to get more compressible outputs (incurs a generation loss, but produces standard files).
- ksec 6y ago
  And that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1]https://github.com/google/brunsli https://github.com/google/brunsli
  - gruturo 6y ago
    Absolutely. Simply unscrewing the Huffman stage from the bottom of JPEG and replacing it with a more effective, modern lossless stage kills webp's gains and does not incur in generation loss - the image is pixel accurate to the source jpeg. You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!
    - jerryX 6y ago
      JPEG XL uses this new ANS coding as e.g. zstd: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems https://en.wikipedia.org/wiki/Asymmetric_numeral_systems
ksec 6y ago
In my opinion, the true contender to JPEG is JPEG XL. [1], where is has better quality than even AVIF at >0.5 bpp ( Bits per Pixel ) [2]. But the truly amazing next generation VVC manage to compress image with even better ratio than JPEG XL. Both JPEG XL and VVC is expected to be finalised in July/Augest. JPEG XL will be royalty free. VVC as usual is lots of unknown. [1]https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... [2] https://medium.com/@scopeburst/mozjpeg-comparison-44035c42abe8 https://medium.com/@scopeburst/mozjpeg-comparison-44035c42ab...
- Scaevolus 6y ago
  VVC is definitely not going to be royalty free, and it's unlikely its intra coding will compete with JPEG XL for the same target (relatively high bitrate high quality images).
cptskippy 6y ago
> Note that Mozilla somewhat walked back from this and implemented WebP support for Firefox in 2019 I wouldn't call the decision to support a format 6 years after first evaluating it a walk back, it's a concession that the format has been adopted by the industry. If the most popular browser supports WebP and sites are using it, it makes sense that you should support it.
- jonny_eh 6y ago
  WebP also supports animation, and is clearly more efficient than GIF.
  - cptskippy 6y ago
    What's the benefit of WebP over something like h264? Most sites today just convert uploaded GIFs to MP4 or GIFV.
    - imtringued 6y ago
      Or just use .webm without audio.
      - dundarious 6y ago
        Webm is a container, not a codec.
mikece 6y ago
An implicit assumption is that "smaller file size is better" and if this discussion were about audio would probably be mp3 vs ogg vorbis... but flac is the BEST to em because I want all of the audio data in the best lossless compression scheme. As a photographer, I would like to have ALL of my image data in a losslessly compressed format as well. What is the FLAC equivalent in the photo/image space?
- NikolaNovak 6y ago
  TIFF, I believe? https://en.wikipedia.org/wiki/TIFF https://en.wikipedia.org/wiki/TIFF
  - sigio 6y ago
    There are lossless versions of PNG, BPF and there is also a lossless JPEG enhancement.
    - mceachen 6y ago
      PNG is always a lossless format. You can only control the level of compression. There are tools that let you re-encode a PNG after applying a lossy filter, but the PNG still encodes it losslessly.
  - mceachen 6y ago
    TIFF is just a image container. I'd make sure when you save as TIFF, you specify a bit depth equal to your source image, and a format that isn't lossy (like standard JPEG). If you've got a standard sRGB 8-bit-per-channel image, though, the loss from JPEG at q95 or q100 is negligible, and means your image still enjoys wide app compatibility. If it's something else (like a raw format from a DSLR), the best you can do is retain the original file. Also: don't forget file metadata! I inadvertantly deleted all EXIF headers from a number of my original images many years ago because I used jpegtran (without the -copy option!) to losslessly rotate images. I ended up adding a bunch of heuristics in PhotoStructure to automatically infer missing metadata to repair this mistake.
- 6y ago
adityapatadia 6y ago
ASK HN: Since this discussion has come up, I would like to ask HN if you are interested for an in-depth comparison on a production workload. I run this https://www.gumlet.com https://www.gumlet.com which serves more than 50M images per day. We can put entire study on different image formats if HN finds it helpful. Please let us know.
- mbStavola 6y ago
  Definitely interested-- a site with an image heavy workload such as yours is the perfect testbed for this sort of exploration.
- Reubend 6y ago
  Yes, I'm personally quite interested. Although more for my own curiosity than any business use case.
anaisbetts 6y ago
If you're writing an Electron app, using WebP/WebM is a Free space optimization, especially in lossless mode for GIFs or sprite maps. You can also make really beautiful, 60FPS animations with WebM that are as easy to use as GIF
aliceryhl 6y ago
You can make a lossless webp from a png. I use this on my site, and it consistently results in smaller images than what I get from png.
ocdtrekkie 6y ago
WebP would never have been adopted and nobody would care about it if it wasn't developed by the owner of the world's largest browser and the world's largest website (which ranks everyone else based in part on what formats and conventions they use), who has the ability to implement it on both sides, and force everyone to care. WebP is a blatant example of how monopoly power is used to push bad things upon everyone else, and as seen here, for literally no good technical reason.
santoshalper 6y ago
Improving image compression should really free up some space on my website so I can fit in a few more javascript frameworks.
Lammy 6y ago
My results with libvips have been way more encouraging than this post suggests with MozJPEG and the WebP reference encoder! Here's a MEGA folder with my example files so you can compare for yourself. Sorry I know this host might be blocked in many places, but every image host I tried (imgur, postimg) recompressed my uploaded files negating the fairness of the test. If anyone has a suggestion for a better host I'm happy to re-upload. https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-BeENEA https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-BeENEA e: another host: http://www.filedropper.com/libvipswebpvsjpeg http://www.filedropper.com/libvipswebpvsjpeg My random sample is a black-and-white JPEG photograph vs its WebP equivalent. The results are in line with my results for many other images of different types, like other black-and-white photos, color photos, clean computer graphics, screenshots of UIs and media/games, etc etc. The original image for this test can be found here: https://en.wikipedia.org/wiki/Sand_Hill_Road https://en.wikipedia.org/wiki/Sand_Hill_Road Both test images were output by libvips after loading the original JPEG. The libvips-generated JPEG is 1.22mb, smaller than the 1.26MB original, but the libvips-generated WebP is 944KB! I included two sceenshots of each libvips-generated version opened in a same-size window too, both much smaller than the full res. Tabbing between the two on my PC does not visibly change on screen at all. I don't entirely enjoy WebP just because the software support is still spotty, but I haven't been able to argue with the compression benefits!
xvilka 6y ago
Of course. JPEG doesn't support transparency and animation.
kn8 6y ago
In my experience, when building websites, webp has always been smaller thus far. For anyone interested and building sites with Next.js, I've released a plugin for optimizing images and converting to webp with fallback to jpg/png: https://github.com/humaans/next-img/ https://github.com/humaans/next-img/
MayeulC 6y ago
> Only concern I have is the excessive blurring of low detail areas? Couldn't the person who picks the compression ratio tell the encoder which part of the image is important? And even have it done automatically to some extent. If you are going to send a 5MB picture from a person at their birthday party, if feels worth it to spend a few more bits on that person than its surroundings. Extrapolating to smartphone pictures where you generally select a focus area (and sometimes selectively blur the rest), they could use that information to keep more bits of information in this area.
jchw 6y ago
> I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG Well, MozJPEG didn’t exist until four years after WebP, so I suspect that might explain why.
devwastaken 6y ago
Av1 images are way better, and you can already do them in Firefox with a video with 1 frame in it. It's a shame it hasn't been adopted as a singular format yet
- andrius4669 6y ago
  >It's a shame it hasn't been adopted as a singular format yet it has been. look up avif, you can already sorta try it out on firefox nighty.
twotwotwo 6y ago
JPEG XL is worth mentioning here. It includes a JPEG1 repacker (Brunsli) that saves about 20% and allows recovering the original file exactly. All that existing JPEG1 content isn't going anywhere, so that seems good. It has some other neat features like the ability to mix a DCT-based codec with lossless (modular) mode in an image. Its lossless/modular mode (successor to FLIF/FUIF) is interesting on its own. It can be illuminating to stretch codecs a bit past the visually-indistinguishable threshold, both to better nail down where that threshold is and to see how annoying the artifacts you end up with are. Lots of comparisons you can do; this is a fun one: https://encode.su/threads/3108-Google-s-compression-proje%D1%81ts?p=64512 https://encode.su/threads/3108-Google-s-compression-proje%D1... At very few bits-per-pixel like the first (bridge) image, everything has some artifacts. On that image AVIF tends to just blur lower contrast areas, whereas HEIC produces some visible ringing (faint lines that weren't there before) around the bridge. Unlike JXL, AVIF and HEIC both have spatial prediction (extend pixels above/to the left of this block in whatever direction), which is particularly helpful with straight sharp lines like the bridge image happens to have. I wouldn't put too much stock in results on that one image, but I do like being able to judge results subjectively. (FWIW, a presentation on JPEG XL suggested they were targeting the equivalent of ~2bpp JPEG quality[0], so perhaps performance in this super-low range wasn't as much of a priority.) Anyway, I hope both these formats get wide support, because they each have clear benefits in some application: JXL's include the upgrade path for JPEG1 content and the multiple modes, and AVIF may be able to salvage a bit more quality at super low bitrates. AV1 (on which AVIF is based) has wide industry backing, and the JPEG XL effort is also going for a royalty-free codec and has support from Google, so hopeful they actually will be usable relatively soon. (Although HEIC's images are OK and it has Apple's support already, it's patent-encumbered, limiting what you or I can do with it.) [0]: https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...
phillipseamore 6y ago
The software versions are never mentioned and since the article says "cwebp only supports TGA input" I suspect that's a very old build of cwebp.
whatsmyusername 6y ago
We have too many different formats! Let's make a new standard! 2 years later We have too many different formats! Let's make a new standard! shrug
trekrich 6y ago
bad enough that google are pushing AMP, let alone trying to take over the webs image formats as well. No more Google!
maxk42 6y ago
Another reason to prefer MozJPEG to webp is that Safari and Edge don't support webp yet. [1] Although it looks like that's changing very soon for Safari. 1: https://caniuse.com/#feat=webp https://caniuse.com/#feat=webp
smallstepforman 6y ago
We use WebP for a number of reasons: - supports lossless - supports alpha - excellent decode speed - open business friendly license In essence, it eliminates PNG.
slx26 6y ago
Question for people more knowledgeable on the topic: is it reasonable to expect a future where audio, image and video are easy to work with and compression / decompression / encoding / decoding is done transparently by the hardware? Like, an OS read call giving you a standard plain format directly? I know PS5 is doing something like that for 3d assets, but I wonder how difficult it would be to do this and just spare the rest of humanity from having to suffer with formats for the rest of our lives. Or would there be too many cons?
- rasz 6y ago
  It has been said PS5 uses Kraken. If its this http://www.radgametools.com/oodlekraken.htm http://www.radgametools.com/oodlekraken.htm then nothing really changes. PS4 games use RAD Kraken today. Texture assets themselves have standardized long time ago, currently on the desktop we are at http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/ http://www.reedbeta.com/blog/understanding-bcn-texture-compr... with history going all the way back to 1990 patents for Apple Video 'road pizza' codec, later ripped off by S3 and re-patented as S3TC texture compression in 1997.
robbrown451 6y ago
Regardless of whether it is better, I sure wish Macs would support them natively, such as in Preview and Finder. Really annoying that if you save an image from the web they aren't as usable as pngs and jpegs. Now, I typically save it locally, see it's a webP, then go back and screenshot it so it is a PNG. (and then find it on my desktop, rename it, move it where I want it to be, etc)
jpambrun 6y ago
These numbers need decompression computational complexity for completeness. I am not better off if I save 1ms downloading, but it takes 5-10 more ms decoding. Bandwidths in the 100s Mbps are common now..
- flowerbeater 6y ago
  Not for me. I'm in the United States in an urban area and mobile data is 1 cent per megabyte (my provider is Google Fi). Decoding is nearly pretty fast for me, but the time for page elements to download is in the seconds (not even milliseconds). And if there's any low signal (wifi or mobile data), then over 10 seconds is not uncommon.
xmichael0 6y ago
Does anyone know of a comparison that looks at the encoding and decoding times / cpu requirements?
cosmojg 6y ago
I can't wait for AV1 and AVIF to take over the world. We've needed better formats for awhile now.
bscphil 6y ago
Unfortunately, targeting same SSIM makes this test basically bullshit. It would be far better to make images that are the same size, and then we can use both our eyes and various objective metrics to compare the images. The reason for this is basically that most codecs do not target SSIM internally. They're using their own algorithms to determine how to allocate bits, so two images with the same SSIM may look better or worse depending on what codec is used. Many modern codecs (e.g. from x264 onwards) deliberately take approaches that lower the score of the result on objective metrics but usually look better to the human eye. This exact issue was originally highlighted on the x264dev blog: "How to cheat on video encoder comparisons" #3: "Making invalid comparisons using objective metrics". [1] If you really want to compare image codecs, I'd look at one of the many comparisons from this family on Github. [2] In my judgment WebP is clearly better than Mozjpeg for most images. [1] https://web.archive.org/web/20141103202912/https://x264dev.multimedia.cx/archives/472 https://web.archive.org/web/20141103202912/https://x264dev.m... [2] https://wyohknott.github.io/image-formats-comparison/#abandonned-factory&webp=s&jpg=s https://wyohknott.github.io/image-formats-comparison/#abando...
- viluon 6y ago
  This should be higher up. siipo.la's benchmark is anecdotal evidence, the image formats comparison shows crisper edges and smoother gradients for WebP even at large filesizes. For small files, mozjpeg can't compare.
- krick 6y ago
  This. JPEG has way too many artefacts on naturally smooth areas (like sky) to be ever considered a pinnacle of lossy image compression. WebP or not, but some adaptive technique must be the future, if there is any space for lossy compression in the future at all.
Animats 6y ago
It's all about Google wanting control. Their own file formats, their own protocols, AMP, not showing URLs in Chrome. The goal is to turn the web into a closed Google ecosystem.
- jonsneyers 6y ago
  How does a royalty-free codec with an open source implementation turn the web into a closed ecosystem? Not that I trust Google, but in this case I don't see the harm.
  - Animats 6y ago
    How does a royalty-free codec with an open source implementation turn the web into a closed ecosystem? Google did it with Android. It's "open source", but try to do something without Google Play Services.
ache7 6y ago
JPEG quality can probably be better (but slower) when using sophisticated decoder libraries. This way, a JPEG image with a WebP size may look with the same quality. But I didn't test. https://news.ycombinator.com/item?id=22245788 https://news.ycombinator.com/item?id=22245788 Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL format without loss. https://google.github.io/brunsli/ https://google.github.io/brunsli/
nisten 6y ago
What really sucks about all this is that they're actually ruining the credibility of lighthouse audits this way; what has been for years the best all-in-one automated performance+accessibility analysis tool for any web app/site and is now being used to promote some random new image format no one wants to care about. You spend all this time improving your stack, reducing your app bundle size, convincing your company on the benefits of server side rendering, improving your devops, getting your manager to see these measurable benefits by running lighthouse audits themselves etc... Then all of a sudden it turns out that the main tool you used for this has been turned into a.. a fking ad platform. I apoligise for this emotionally charged rant, but seriously though, is that how you plan on getting developers adopt your dubious new standard, by p*ssing them off?
nyanpasu64 6y ago
As an observer of video codec development, I heard Daala (PVQ) used activity masking to make quantization steps finer (don't discard all detail) in low-contrast areas. I don't know if that's practical in AV1 (a DCT block-based codec).

424 points by kasabali 6y ago

Does anyone know how these compare with the HEIC format that it seems my iPhone now uses by default? Is that non-mainstream, or otherwise not fit for comparison?

izacus 6y ago
It's a proprietary patent-encumbered format which isn't really widely supported in the web browsers.
- zerocrates 6y ago
  I happened to look it up on caniuse.com yesterday and it's just a field of solid red: nobody supports it, not even Safari.
- Y-bar 6y ago
  Patent-encumbered? Yes. > proprietary No. It is an open standard (ISO/IEC 23008)
  - chungus_khan 6y ago
    Being patent-encumbered kind of makes it moot on the web though, just like H.265 video.
  - NovemberWhiskey 6y ago
    Oh - so actually AVIF (as discussed in the original article) is an HEIF container with AV1 as the codec, and HEIC is the same but with H.265.
chrisbrandow 6y ago
I’d be curious about that as well. I made my own minor comparisons, and heif did well, but there are a ton of possible pitfalls my comparison may have been subject to so I’d love to see a comparison by someone with expertise
irrational 6y ago
I thought HEIC is apple only and not supported by any browser. Is it even supported by Safari?
- deleted 6y ago
  [deleted]
- reaperducer 6y ago
  HEIC/HEIF is not an Apple format. It's an MPEG format that's been around for half a decade. Apple started supporting it in 2017. Microsoft in 2018. You are correct, though — it's not supported by any browser.
innocenat 6y ago
I haven't follow the trend much nor seen a recent comparison, so take this with a grain of salt. WebP is based on VP8, which was considered to be competitor to H.264 (AVC). HEIC is based on H.265 (HEVC), which competes with VP9 and AV1. So I'd assume WebP is one generation behind HEIC. WebP was introduced 5 years before HEIC though.
- pornel 6y ago
  Correct. WebP is 10 years old, based on the VP8 codec that is about 14 years old, which lost in the market to H.264 that is 17 years old. In video streaming VP8 has been completely replaced by VP9 years ago, and VP9 was going to be replaced by VP10 which became part of AV1. So WebP is hardly new, and a couple of generations behind. Now the next hotness is AVIF (or maybe JPEG XL), so ironically, WebP is becoming usable and obsolete at the same time.
reaperducer 6y ago
I like HEIC under the hood, but it's not suitable for web as it has exactly zero browser support. https://caniuse.com/#search=heif https://caniuse.com/#search=heif I'm surprised that Safari doesn't support it. I believe Apple released a bit of Javascript that lets you embed the animated HEIF images (I think they're called "live pictures") in your web site, but that's kind of a niche use.

kome 6y ago

tl;dr: it's not. And it's also a very annoying to deal with them, I might add, especially when you need to save them or to work with them, as they are not natively supported by macOS or win.

Santosh83 6y ago

As someone who hosts images on their site, what is the best software (preferably open source) one can use to compress JPEG images imported from a digital camera? I would be glad to serve only JPEGs and dispense with WebP versions and simplify my site html. A straightforward encoding of a JPEG into a WebP (using GIMP) does give me an almost 1/3rd reduction in file size, which is not insignificant.

singlow 6y ago
ImageMagick
zimpenfish 6y ago
imager.io was on here recently and seems to do a good job compressing into normal JPEG images. https://github.com/imager-io/imager https://github.com/imager-io/imager
theandrewbailey 6y ago
When you convert JPEG to WebP, you're converting data in a lossy format to another lossy format. Of course you're going to get good JPEG to WebP compression, because you're starting with a low-quality source. If you start with a lossless image (RAW/PNG/TIFF/etc.) instead of a JPEG, you might get different results.
acdha 6y ago
Re-encoding will produce smaller images because it’s discarding information - if you compare that WebP image you the original you’ll inevitably see fine detail is missing. That may or may not be reasonable but to be fair you’d want to compare it with different quality levels using MozJPEG. The easiest way to do a simple comparison might be to install ImageOptim and process a few images with various tools. Based on that you could put the same tools into your site’s workflow.
tyingq 6y ago
Others have mentioned you're using 2 lossy formats. You would probably get a similar end file size with jpegoptim. Compile it with mozjpeg for even smaller sizes.

HenryKissinger 6y ago

I make a lot of memes for Reddit with MS Paint. I tend to avoid WebP because of compatibility issues. Neither Reddit's native image host nor Imgur allows WebP files, and I save memes using images from multiple formats (e.g. a jpg, a png, and a WebP) in jpg or png to avoid that. When a WebP file is saved into jpg or png Paint gives an error message about how this will erase all transparency, but for my purposes that is not a problem.

whywhywhywhy 6y ago
I mean Photoshop doesn't even support it either so every encounter I have with this file format has been an exercise in frustration and honestly would have preferred it if it just went away and was replace with something companies are free to implement safely.
- tracker1 6y ago
  IIRC WebP is open-source and unencumbered by patents so there's no reason it couldn't be implemented. That said, it's not a good source format.

mrob 6y ago

Is there something wrong with the AVIF decoder's chroma upscaling? E.g. look at "Kodim 3", where the colored hats overlap each other. There's severe blocking, where I'd expect blurring instead. All the other formats blur, which is much less distracting.

theandrewbailey 6y ago
I've noticed that too. I've been testing AVIF, and the reference encoder[0] defaults to 4:4:4 (no chroma downsampling) if you don't tell it otherwise. I tried 4:2:0 and it looked horrible, but the size hit for 4:4:4 wasn't bad and looked much better. [0] https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif

Jonnax 6y ago

So what's this AVIF format they mention that's actually better than both? WebP did not take off. But will AVIF be any better?

theandrewbailey 6y ago
It's based on the next-gen AV1 video codec. I've tried it out, and it's amazing. https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4?gi=e1406a7d46e6 https://netflixtechblog.com/avif-for-next-generation-image-c... https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif
masklinn 6y ago
> So what's this AVIF format they mention that's actually better than both? AVIF is an image format based on the intra-frame coding of AV1, as WebP is to VP8 and HEIF is to HEVC. AV1 and HEIF are super recent though, the AVIF 1.0 spec was only released in early 2019. By comparison, WebP was initially released in 2019. So AVIF currently has very little support (it's behind flags in Firefox and that's it). However all the big names are part of AOM, which oversees AV1 (and AVIF): http://aomedia.org/membership/members/ http://aomedia.org/membership/members/ So chances are pretty high it'll get widespread support, eventually. There’s one problem though: like WebP, AVIF just is not solving a big issue.
- nerdkid93 6y ago
  - WebP was initially released in 2019 + WebP was initially released in 2010
flowerbeater 6y ago
I think it's just about to take off. Browser support across the board is coming by the end of the year. PNG also took a while to become fully supported, so we just need some patience.

lowmemcpu 6y ago

I'm using Firefox and just tried to save a webp image and it tried to save as a web page. [initially, I said no.. see edit below] Edit: Looks like it was that specific website and they are doing something odd, so I retract my initial judgement.

discreditable 6y ago
Is that server sending the image with the correct mimetype?
- lowmemcpu 6y ago
  Good point! I just went back and checked that specific site, and they are definitely doing something odd. I retract my previous judgement

untog 6y ago

FWIW one of the reasons this has become relevant again is because the next version of Safari supports WebP. The article's discussion of AVIF is interesting but you're not going to be able to use it on the web any time soon. I'd be curious to see a WebP vs PNG comparison, since (IIRC) it has a lossless mode too.

chungy 6y ago
Lossless is pretty easy, there's no subjective qualities to compare, just file size. WebP Lossless almost always results in a smaller file than PNG. I have seen exceptions to this, but they're sufficiently rare that it's not worth worrying about.

pixelbath 6y ago

Subjectively, I'd say at those settings the WebP versions look slightly worse, though they don't suffer from the blocking artifacts native to JPEG. For the images I serve on my sites, a few KB here and there aren't going to make a huge difference, and I'd rather avoid the hassle of serving content that isn't universally supported.

mrob 6y ago
In most cases I prefer the WebP versions, but the JPEG formats handle chroma noticeably better. E.g. look at the purple band on the rightmost helmet in the 500 pixel version of Kodim 5. WebP reduces the saturation by excessive blurring. CJPEG handles this image best IMO.
MaxBarraclough 6y ago
Take a look at the Kodim 3 example image, either the '500px' version or the '1500px' (but not the '1500px' version). Zoom in (400%) on the cap of the yellow hat. The lines of the cap are muddied under all lossy compressed formats, but surprisingly, plain old cjpeg does so less than the others. Generally though I find the new formats look better than JPEG.

deleted 6y ago

[deleted]

snoo5780 6y ago

Does anyone have insight as to whether this same evaluation re:AVIF applies to WebM? Edit: saw somewhere that it is used in production for real-time video, but had trouble using rav1e as opposed to libvpx

acdha 6y ago
Yes: Google heavily promoted their format but unless you’re serving a high volume of traffic it’s not worth the cost of doubling your storage and maintaining a separate toolchain to lower your transfer by perhaps 10%. By now more devices have hardware support so its performance is more competitive but at this point I’d go straight to AV1.
- snoo5780 6y ago
  Perhaps should clarify. Much of the reaction appears to be to Safari support for WebP. Those reacting believe that WebP will stick around even though used VP8 (Could have just hurdled straight to AV1). So curious to ask if those same people reacting think WebM will also stick around longer. It’s a bit different since WebM uses VP9, but, there perhaps there are still potential issues, and personally not know about browser landscape/hardware support.

Eric_WVGG 6y ago

I just relaunched a website that makes extensive use of photographic collages that necessitate alpha backgrounds. They were previously shipping "retina-grade", multi-megabyte images all over, a typical page load could easily reach 25mb. I managed to refit it with `<picture>` tags using WEBP as well as JP2. The latter was a great deal of trouble, it appears that "the community" (notably Gatsby and Contentful) are very happy to talk about the benefits of WebP but conveniently ignore that Safari is the most important mobile browser, and Safari desktop is not insignificant. I bring this both to point out that there is a very valid reason to use WebP over JPEG — alpha blending — and that this entire field is still a gigantic mess.

oauea 6y ago
Safari Mobile is a broken mess not worth supporting.
- ChrisMarshallNY 6y ago
  Since Safari (and WebKit) are the only available Web-rendering engine for iOS and iPadOS (and the default one for MacOS), it's kind of important to be able to at least render usefully on it.
- donatj 6y ago
  I think by the nature of being the second most used browser, it's worth supporting. You don't have to like supporting it however. https://www.w3counter.com/globalstats.php https://www.w3counter.com/globalstats.php
  - kevin_thibedeau 6y ago
    Shades of IE6 Stockholm syndrome.
    - derefr 6y ago
      Very different problems. Many ISVs were stuck supporting IE6 for so long—long after it went into single-digit percentage usage—not out of some vague fear that someone, somewhere still used it; but because the particular moribund enterprise clients that they wanted to sell into still used it. (Otherwise, IE6 would have been just another irrelevant minority browser, like Opera.) Mobile Safari, meanwhile, is "still" used by 25% of people; but more importantly, iOS is used by 26% of people (52% in North America!), and those people can't actually get any other renderer than WKWebView, whether they use Safari or not.

dubcanada 6y ago

This is a weird comparison, while I get the comparison of non-transparent images jpeg or webp are probably fine. However the main benefit of webp is alpha backgrounds or transparency. It can destroy PNG when it comes to compression and size.

RNiK 6y ago
I would say it really depends on the PNG compression library you are using. Tools like RIOT or Compressor.io can give you optimal results on PNG compression.

buboard 6y ago

chrome keeps changing downloaded images to webP which is annoyin af. can't even find a way to disable it

acdha 6y ago
Are you sure that’s Chrome and not a website which selects the format based on the client’s advertised capabilities? I know Facebook did that and it confused a lot of people when a .jpg wasn’t a JPEG.
- unnouinceput 6y ago
  For me was the same problem on Chrome. Switched to Firefox, same sites are happy to let me save their images as .jpeg instead of .webp
  - anonymoushn 6y ago
    I thought this might have been caused by a difference in whether image/webp is included in the Accept header on requests for web pages (not requests for images), since some people who run web sites prefer to serve different html to UAs that support and do not support webp rather than serving different image formats at the same URL. But when I looked at the Accept header Firefox sends for pages, it included image/webp. So I'm not sure what these sites are doing.
crazygringo 6y ago
It's not and you can't. The website is service up the images as webP. Chrome is just giving you what the website gives you, there's nothing to "disable".
- bzb3 6y ago
  You could remove webp from the Accept header so the web server thinks your browser can't interpret webp. Not guaranteed to work, obviously.
- 6y ago

jgrahamc 6y ago

Some data from when we deployed WebP generation: https://blog.cloudflare.com/a-very-webp-new-year-from-cloudflare/ https://blog.cloudflare.com/a-very-webp-new-year-from-cloudf...

ChrisMarshallNY 6y ago

I really want a better alpha-mask standard to emerge. PNG24 is attractive, but huge. PNG8/GIF works well, but is pretty limited. I don't think WebP is it, but we'll see what comes out of the scrum. I'll work with whatever that is, but I won't waste my time chasing will o' the wisp "standards."

tombert 6y ago
It's still relatively huge, and not widely supported without a polyfill, but FLIF [0] is a pretty neat format that tends to be smaller than the equivalent PNG, and can be converted to a lossy image "on the fly", and also supports alpha transparency. The polyfill is still kind of slow, at least compared to native PNG rendering on the browser, but it does work, and hopefully some day it can be integrated into the standard. [0] http://flif.info http://flif.info
- andrius4669 6y ago
  >hopefully some day it can be integrated into the standard. see jpeg-xl
thdrdt 6y ago
Some time ago I experimented with a reduced color palette and dithering while keeping the fill alpha info. It reduced the file size a lot while keeping the alpha.
- ChrisMarshallNY 6y ago
  Yeah, there's a number of ways to reduce GIF/PNG8 sizes. I started writing Web sites in the mid-'90s, where a page was supposed to be about 30K (quaint, huh?). The prevailing wisdom, then, was no dither, adaptive palette, and reduce the color palette until it hurts, then back up one.

karamanolev 6y ago

I'm surprised this doesn't include Google Guetzli (https://github.com/google/guetzli https://github.com/google/guetzli) in the comparison. In my experience trying to optimize product images for an eCommerce site, this provided the best compression. Yes, it's ridiculously slow, but for encode-once-transmit-often scenarios, it's perfectly usable.

acqq 6y ago
Did anybody really find any reason to use that? https://www.pixelz.com/blog/guetzli-mozjpeg-comparison/ https://www.pixelz.com/blog/guetzli-mozjpeg-comparison/ "MozJPEG files had fewer bytes 6 out of 8 times MozJPEG and Guetzli were visually indistinguishable MozJPEG encoded literally hundreds to a thousand times faster than Guetzli MozJPEG supports progressive loading"
- karamanolev 6y ago
  I am compressing 200x200px and 800x800px images. For those sizes, while the encoding speed is slow for real-time use cases, for product images it's completely irrelevant - anything under 1 minute/image gets a pass and lower, generally, isn't better (or worse). I'm looking at absolute image quality/byte and it's even more niche than that - it's bytes to pass a threshold of acceptable quality (85 on Guetzli IIRC). I don't care about very low or very high qualities. In terms of absolute bytes to pass this threshold, Guetzli felt the best when I was doing the research (~ mid-2017). I don't have any hard data to back this though - I did the experiment with 5-6 different product images, drew the conclusion and started using Guetzli.

rakoo 6y ago

Extremely subjective, personal data point: I've been running with an extension (https://bandwidth-hero.com/ https://bandwidth-hero.com/) that compresses all images (including jpeg) and renders them in webp. I'm a typical social networks browser, so among the images I see a high majority of them don't need high quality. I'm running the extension with max compression but still keep colors: compression artifacts are clearly visible, but in my opinion they're not a problem. Looking at /r/all right now, there are 2 images that "deserve" to remain at the original resolution, the rest is typical pictures of text/memes that don't need all the bytes they currently have. The result: overall I saved 80% of data, just with images. In my case it's not so much a debate of JPEG vs WebP, but a debate of whether it's ok to keep images _on the web_ in their unoptimized form the way they are today, to which of course my answer is no. We don't need high quality images of a Facebook screenshot when compressing it to 20% of its original size can convey the same information with no subjective loss. I do agree on the unwieldy nature of WebP though, it's still mostly a read-only format right now and turns the web into a consumption platform

andrewxdiamond 6y ago
How does an extension resize an image without downloading it? Can it selectively read bytes from the stream?
- cercatrova 6y ago
  It uses a proxy server as said on the landing page. That said, the service is shut down apparently so you have to self-host your own proxy server. That's not too useful for me so I uninstalled the extension.
  - rakoo 6y ago
    I self-host my own proxy server on my VPS, so I'm hoping said server is close enough to the origin to be useful in the overall reduction of transferred bytes
- sp332 6y ago
  I suppose you could click on the provided link and find out?

alex_portabella 6y ago

I've recently converted some images to WebP on my side project Portabella [1]. I did it to appease Googles page speed test for SEO. But I agree with other comments in this thread that it's annoying so I might switch them all to JPEG and be done with it. [1] https://portabella.io https://portabella.io

unnouinceput 6y ago

Summary: - No. It's roughly the same. Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons.

reaperducer 6y ago
Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. Pithy comment, and reaction, aside, that's enough to give me pause about implementing it.
- unnouinceput 6y ago
  *pity
masklinn 6y ago
> Mandatory Google bash comment: - It's mainly another wheel reinvention from Google, because reasons. WebP seems to have been the first "let's just use intra-frame coding" image format out there though, and it's hardly the first format to have tried to unseat JPEG. WebP is 4 years older than BPG (Bellard's HEVC-based format), 5 years older than HEIF (MPEG's same) and AVIF was only specified 9 years later.
pornel 6y ago
It's a sad story of broken promises. Back when video == Flash, Google bought and opened VP8 codec and got a bunch of companies to promise support for VP8 video. Back then it made a lot of sense to also have an image format based on exactly VP8 (despite it being a poor fit for still image format), since everyone promised to support it, including hardware acceleration. But Adobe never added VP8 to Flash, hardware support was too little too late. VP8 died, and WebP is burdened with compatibility with a world that never materialized.

yboris 6y ago

Obligatory mention of FLIF [0], FUIF [1], pik [2], and JPEG XL [3] as well as Jon Sneyers FLIF & FUIF were created by Jon Sneyers - http://sneyers.info/ http://sneyers.info/ and are lossless but progressive, generating better resulting images at every step of the image download and brilliant mobile support (your browser can just stop downloading the image once it reaches the quality sufficient for the viewport). A new update on the JPEG XL is worth reading: --> https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... [0] http://flif.info/ http://flif.info/ -- superseded by FUIF [1] https://cloudinary.com/blog/fuif_new_legacy_friendly_image_file_format https://cloudinary.com/blog/fuif_new_legacy_friendly_image_f... -- FLIF is lossless and amazing, in part absorbed by JPEG XL [2] https://github.com/google/pik https://github.com/google/pik - from Google, got absorbed by JPEG XL [3] https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...

The_rationalist 6y ago

Jpeg XL is the real thing

zmix 6y ago

I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website: BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are: * High compression ratio. Files are much smaller than JPEG for similar quality. * Supported by most Web browsers with a small Javascript decoder (gzipped size: 56 KB). * Based on a subset of the HEVC open video compression standard. * Supports the same chroma formats as JPEG (grayscale, YCbCr 4:2:0, 4:2:2, 4:4:4) to reduce the losses during the conversion. An alpha channel is supported. The RGB, YCgCo and CMYK color spaces are also supported. * Native support of 8 to 14 bits per channel for a higher dynamic range. * Lossless compression is supported. * Various metadata (such as EXIF, ICC profile, XMP) can be included. * Animation support. [1] https://bellard.org/bpg/ https://bellard.org/bpg/

notRobot 6y ago
Relying on JavaScript just for images is a terrible idea. That said, I do think it's a neat project and can be used if there are proper fallbacks to formats that are natively supported.
reaperducer 6y ago
can be supported in any browser via a Javascript I think you answered your own question right there. I'm not going to use a dumptruck to bring a single sack of sand to my garden.
- nine_k 6y ago
  For an image gallery, the balance could be the opposite: a small (56k) download of a decoder allowing to show many large (a few megs each) pictures. I wonder how good the performance of that decoder is, though; if the decoding delay is much longer that the network transfer delay, the approach becomes much less appealing.
  - acdha 6y ago
    It's also not common to need a ton of huge images all at once — in almost all applications you're either displaying thumbnails and JPEG is fine and will load faster thanks to the browser's preloader getting those requests in faster than the JavaScript can run or you're looking at something like pages where the latency is easily hidden by preloading. That means that in most cases the main driver is lower network transfer and you need to be serving a LOT of images to outweigh the cost of having to support something new and complicated versus something as widely tested and supported as JPEG.

deleted 6y ago

[deleted]

throw0101a 6y ago

I'm more interested in hearing about support for AV1. * https://en.wikipedia.org/wiki/AV1 https://en.wikipedia.org/wiki/AV1

masklinn 6y ago
AVIF is in the comparison, and the article notes it's in Firefox (behind a flag) and ought be coming to Chrome soon.

mindfulplay 6y ago

Two major advantages: transparency and optional lossless. JPEG blocky artifacts are very hard to remove for high resolution images unless you hand tune them.

zspitzer 6y ago

One of the biggest barriers against adoption of these newer formats is the lack of pure java implementations for use server side. The Java wrappers around a native binary are helpful, but for many projects not very useful and this hinders adoption. https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue+is%3Aopen+label%3A%22Sponsor+needed%22 https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue...

adityapatadia 6y ago
Is JAVA still a thing?
- theduder99 6y ago
  for sure and it is probably doing the heavy lifting behind many of the companies+governments you interact with.
grishka 6y ago
Using Java code for things that are this performance critical doesn't feel like a good idea. It will work of course, but it will probably GC a lot, and while modern JVMs do JIT, the code they generate can't be as optimal as something that has manual SIMD optimizations.
- lmm 6y ago
  Using C code is how you get the next cloudbleed. I'm happy to pay a performance cost for the sake of memory safety.
  - iomcr 6y ago
    Fix this easily by abstracting the manipulation of user uploaded files to chroot/serverless.
    - lmm 6y ago
      That doesn't fix the problem. The process can still fix any data that it has access to, which includes other users' confidential uploaded files.

gruturo 6y ago

Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. Even if the above were just an individual... bafflement? and not an actual issue, the size savings really don't seem worth the compatibility hassle, the extra manpower/workflow complexity to support 2 formats, the additional storage (and caching) caused by this duplication. And the above is if it's done RIGHT. 80% of people outside this forum won't understand that you're not supposed to convert from a lossy format to another, and just convert jpegs to webp. Webp seems so pointless. A progressive jpeg with an optimized Huffman table can be understood by a 27 year old decoder without issues, achieves 90% of the quality/size claims of webp and can be produced losslessly from your source jpegs. This is without even touching Arithmetic Coding (also lossless, part of the official standard, but poorly supported due to some software patents, even though they all expired by now), or playing with customized DCT quantization matrices to get more compressible outputs (incurs a generation loss, but produces standard files).

ksec 6y ago
And that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1]https://github.com/google/brunsli https://github.com/google/brunsli
- gruturo 6y ago
  Absolutely. Simply unscrewing the Huffman stage from the bottom of JPEG and replacing it with a more effective, modern lossless stage kills webp's gains and does not incur in generation loss - the image is pixel accurate to the source jpeg. You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!
  - jerryX 6y ago
    JPEG XL uses this new ANS coding as e.g. zstd: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems https://en.wikipedia.org/wiki/Asymmetric_numeral_systems

ksec 6y ago

In my opinion, the true contender to JPEG is JPEG XL. [1], where is has better quality than even AVIF at >0.5 bpp ( Bits per Pixel ) [2]. But the truly amazing next generation VVC manage to compress image with even better ratio than JPEG XL. Both JPEG XL and VVC is expected to be finalised in July/Augest. JPEG XL will be royalty free. VVC as usual is lots of unknown. [1]https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... [2] https://medium.com/@scopeburst/mozjpeg-comparison-44035c42abe8 https://medium.com/@scopeburst/mozjpeg-comparison-44035c42ab...

Scaevolus 6y ago
VVC is definitely not going to be royalty free, and it's unlikely its intra coding will compete with JPEG XL for the same target (relatively high bitrate high quality images).

cptskippy 6y ago

> Note that Mozilla somewhat walked back from this and implemented WebP support for Firefox in 2019 I wouldn't call the decision to support a format 6 years after first evaluating it a walk back, it's a concession that the format has been adopted by the industry. If the most popular browser supports WebP and sites are using it, it makes sense that you should support it.

jonny_eh 6y ago
WebP also supports animation, and is clearly more efficient than GIF.
- cptskippy 6y ago
  What's the benefit of WebP over something like h264? Most sites today just convert uploaded GIFs to MP4 or GIFV.
  - imtringued 6y ago
    Or just use .webm without audio.
    - dundarious 6y ago
      Webm is a container, not a codec.

mikece 6y ago

An implicit assumption is that "smaller file size is better" and if this discussion were about audio would probably be mp3 vs ogg vorbis... but flac is the BEST to em because I want all of the audio data in the best lossless compression scheme. As a photographer, I would like to have ALL of my image data in a losslessly compressed format as well. What is the FLAC equivalent in the photo/image space?

NikolaNovak 6y ago
TIFF, I believe? https://en.wikipedia.org/wiki/TIFF https://en.wikipedia.org/wiki/TIFF
- sigio 6y ago
  There are lossless versions of PNG, BPF and there is also a lossless JPEG enhancement.
  - mceachen 6y ago
    PNG is always a lossless format. You can only control the level of compression. There are tools that let you re-encode a PNG after applying a lossy filter, but the PNG still encodes it losslessly.
- mceachen 6y ago
  TIFF is just a image container. I'd make sure when you save as TIFF, you specify a bit depth equal to your source image, and a format that isn't lossy (like standard JPEG). If you've got a standard sRGB 8-bit-per-channel image, though, the loss from JPEG at q95 or q100 is negligible, and means your image still enjoys wide app compatibility. If it's something else (like a raw format from a DSLR), the best you can do is retain the original file. Also: don't forget file metadata! I inadvertantly deleted all EXIF headers from a number of my original images many years ago because I used jpegtran (without the -copy option!) to losslessly rotate images. I ended up adding a bunch of heuristics in PhotoStructure to automatically infer missing metadata to repair this mistake.
6y ago

adityapatadia 6y ago

ASK HN: Since this discussion has come up, I would like to ask HN if you are interested for an in-depth comparison on a production workload. I run this https://www.gumlet.com https://www.gumlet.com which serves more than 50M images per day. We can put entire study on different image formats if HN finds it helpful. Please let us know.

mbStavola 6y ago
Definitely interested-- a site with an image heavy workload such as yours is the perfect testbed for this sort of exploration.
Reubend 6y ago
Yes, I'm personally quite interested. Although more for my own curiosity than any business use case.

anaisbetts 6y ago

If you're writing an Electron app, using WebP/WebM is a Free space optimization, especially in lossless mode for GIFs or sprite maps. You can also make really beautiful, 60FPS animations with WebM that are as easy to use as GIF

aliceryhl 6y ago

You can make a lossless webp from a png. I use this on my site, and it consistently results in smaller images than what I get from png.

ocdtrekkie 6y ago

WebP would never have been adopted and nobody would care about it if it wasn't developed by the owner of the world's largest browser and the world's largest website (which ranks everyone else based in part on what formats and conventions they use), who has the ability to implement it on both sides, and force everyone to care. WebP is a blatant example of how monopoly power is used to push bad things upon everyone else, and as seen here, for literally no good technical reason.

santoshalper 6y ago

Improving image compression should really free up some space on my website so I can fit in a few more javascript frameworks.

Lammy 6y ago

My results with libvips have been way more encouraging than this post suggests with MozJPEG and the WebP reference encoder! Here's a MEGA folder with my example files so you can compare for yourself. Sorry I know this host might be blocked in many places, but every image host I tried (imgur, postimg) recompressed my uploaded files negating the fairness of the test. If anyone has a suggestion for a better host I'm happy to re-upload. https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-BeENEA https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-BeENEA e: another host: http://www.filedropper.com/libvipswebpvsjpeg http://www.filedropper.com/libvipswebpvsjpeg My random sample is a black-and-white JPEG photograph vs its WebP equivalent. The results are in line with my results for many other images of different types, like other black-and-white photos, color photos, clean computer graphics, screenshots of UIs and media/games, etc etc. The original image for this test can be found here: https://en.wikipedia.org/wiki/Sand_Hill_Road https://en.wikipedia.org/wiki/Sand_Hill_Road Both test images were output by libvips after loading the original JPEG. The libvips-generated JPEG is 1.22mb, smaller than the 1.26MB original, but the libvips-generated WebP is 944KB! I included two sceenshots of each libvips-generated version opened in a same-size window too, both much smaller than the full res. Tabbing between the two on my PC does not visibly change on screen at all. I don't entirely enjoy WebP just because the software support is still spotty, but I haven't been able to argue with the compression benefits!

xvilka 6y ago

Of course. JPEG doesn't support transparency and animation.

kn8 6y ago

In my experience, when building websites, webp has always been smaller thus far. For anyone interested and building sites with Next.js, I've released a plugin for optimizing images and converting to webp with fallback to jpg/png: https://github.com/humaans/next-img/ https://github.com/humaans/next-img/

MayeulC 6y ago

> Only concern I have is the excessive blurring of low detail areas? Couldn't the person who picks the compression ratio tell the encoder which part of the image is important? And even have it done automatically to some extent. If you are going to send a 5MB picture from a person at their birthday party, if feels worth it to spend a few more bits on that person than its surroundings. Extrapolating to smartphone pictures where you generally select a focus area (and sometimes selectively blur the rest), they could use that information to keep more bits of information in this area.

jchw 6y ago

> I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG Well, MozJPEG didn’t exist until four years after WebP, so I suspect that might explain why.

devwastaken 6y ago

Av1 images are way better, and you can already do them in Firefox with a video with 1 frame in it. It's a shame it hasn't been adopted as a singular format yet

andrius4669 6y ago
>It's a shame it hasn't been adopted as a singular format yet it has been. look up avif, you can already sorta try it out on firefox nighty.

twotwotwo 6y ago

JPEG XL is worth mentioning here. It includes a JPEG1 repacker (Brunsli) that saves about 20% and allows recovering the original file exactly. All that existing JPEG1 content isn't going anywhere, so that seems good. It has some other neat features like the ability to mix a DCT-based codec with lossless (modular) mode in an image. Its lossless/modular mode (successor to FLIF/FUIF) is interesting on its own. It can be illuminating to stretch codecs a bit past the visually-indistinguishable threshold, both to better nail down where that threshold is and to see how annoying the artifacts you end up with are. Lots of comparisons you can do; this is a fun one: https://encode.su/threads/3108-Google-s-compression-proje%D1%81ts?p=64512 https://encode.su/threads/3108-Google-s-compression-proje%D1... At very few bits-per-pixel like the first (bridge) image, everything has some artifacts. On that image AVIF tends to just blur lower contrast areas, whereas HEIC produces some visible ringing (faint lines that weren't there before) around the bridge. Unlike JXL, AVIF and HEIC both have spatial prediction (extend pixels above/to the left of this block in whatever direction), which is particularly helpful with straight sharp lines like the bridge image happens to have. I wouldn't put too much stock in results on that one image, but I do like being able to judge results subjectively. (FWIW, a presentation on JPEG XL suggested they were targeting the equivalent of ~2bpp JPEG quality[0], so perhaps performance in this super-low range wasn't as much of a priority.) Anyway, I hope both these formats get wide support, because they each have clear benefits in some application: JXL's include the upgrade path for JPEG1 content and the multiple modes, and AVIF may be able to salvage a bit more quality at super low bitrates. AV1 (on which AVIF is based) has wide industry backing, and the JPEG XL effort is also going for a royalty-free codec and has support from Google, so hopeful they actually will be usable relatively soon. (Although HEIC's images are OK and it has Apple's support already, it's patent-encumbered, limiting what you or I can do with it.) [0]: https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...

phillipseamore 6y ago

The software versions are never mentioned and since the article says "cwebp only supports TGA input" I suspect that's a very old build of cwebp.

whatsmyusername 6y ago

We have too many different formats! Let's make a new standard! 2 years later We have too many different formats! Let's make a new standard! shrug

trekrich 6y ago

bad enough that google are pushing AMP, let alone trying to take over the webs image formats as well. No more Google!

maxk42 6y ago

Another reason to prefer MozJPEG to webp is that Safari and Edge don't support webp yet. [1] Although it looks like that's changing very soon for Safari. 1: https://caniuse.com/#feat=webp https://caniuse.com/#feat=webp

smallstepforman 6y ago

We use WebP for a number of reasons: - supports lossless - supports alpha - excellent decode speed - open business friendly license In essence, it eliminates PNG.

slx26 6y ago

Question for people more knowledgeable on the topic: is it reasonable to expect a future where audio, image and video are easy to work with and compression / decompression / encoding / decoding is done transparently by the hardware? Like, an OS read call giving you a standard plain format directly? I know PS5 is doing something like that for 3d assets, but I wonder how difficult it would be to do this and just spare the rest of humanity from having to suffer with formats for the rest of our lives. Or would there be too many cons?

rasz 6y ago
It has been said PS5 uses Kraken. If its this http://www.radgametools.com/oodlekraken.htm http://www.radgametools.com/oodlekraken.htm then nothing really changes. PS4 games use RAD Kraken today. Texture assets themselves have standardized long time ago, currently on the desktop we are at http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/ http://www.reedbeta.com/blog/understanding-bcn-texture-compr... with history going all the way back to 1990 patents for Apple Video 'road pizza' codec, later ripped off by S3 and re-patented as S3TC texture compression in 1997.

robbrown451 6y ago

Regardless of whether it is better, I sure wish Macs would support them natively, such as in Preview and Finder. Really annoying that if you save an image from the web they aren't as usable as pngs and jpegs. Now, I typically save it locally, see it's a webP, then go back and screenshot it so it is a PNG. (and then find it on my desktop, rename it, move it where I want it to be, etc)

jpambrun 6y ago

These numbers need decompression computational complexity for completeness. I am not better off if I save 1ms downloading, but it takes 5-10 more ms decoding. Bandwidths in the 100s Mbps are common now..

flowerbeater 6y ago
Not for me. I'm in the United States in an urban area and mobile data is 1 cent per megabyte (my provider is Google Fi). Decoding is nearly pretty fast for me, but the time for page elements to download is in the seconds (not even milliseconds). And if there's any low signal (wifi or mobile data), then over 10 seconds is not uncommon.

xmichael0 6y ago

Does anyone know of a comparison that looks at the encoding and decoding times / cpu requirements?

cosmojg 6y ago

I can't wait for AV1 and AVIF to take over the world. We've needed better formats for awhile now.

bscphil 6y ago

Unfortunately, targeting same SSIM makes this test basically bullshit. It would be far better to make images that are the same size, and then we can use both our eyes and various objective metrics to compare the images. The reason for this is basically that most codecs do not target SSIM internally. They're using their own algorithms to determine how to allocate bits, so two images with the same SSIM may look better or worse depending on what codec is used. Many modern codecs (e.g. from x264 onwards) deliberately take approaches that lower the score of the result on objective metrics but usually look better to the human eye. This exact issue was originally highlighted on the x264dev blog: "How to cheat on video encoder comparisons" #3: "Making invalid comparisons using objective metrics". [1] If you really want to compare image codecs, I'd look at one of the many comparisons from this family on Github. [2] In my judgment WebP is clearly better than Mozjpeg for most images. [1] https://web.archive.org/web/20141103202912/https://x264dev.multimedia.cx/archives/472 https://web.archive.org/web/20141103202912/https://x264dev.m... [2] https://wyohknott.github.io/image-formats-comparison/#abandonned-factory&webp=s&jpg=s https://wyohknott.github.io/image-formats-comparison/#abando...

viluon 6y ago
This should be higher up. siipo.la's benchmark is anecdotal evidence, the image formats comparison shows crisper edges and smoother gradients for WebP even at large filesizes. For small files, mozjpeg can't compare.
krick 6y ago
This. JPEG has way too many artefacts on naturally smooth areas (like sky) to be ever considered a pinnacle of lossy image compression. WebP or not, but some adaptive technique must be the future, if there is any space for lossy compression in the future at all.

Animats 6y ago

It's all about Google wanting control. Their own file formats, their own protocols, AMP, not showing URLs in Chrome. The goal is to turn the web into a closed Google ecosystem.

jonsneyers 6y ago
How does a royalty-free codec with an open source implementation turn the web into a closed ecosystem? Not that I trust Google, but in this case I don't see the harm.
- Animats 6y ago
  How does a royalty-free codec with an open source implementation turn the web into a closed ecosystem? Google did it with Android. It's "open source", but try to do something without Google Play Services.

ache7 6y ago

JPEG quality can probably be better (but slower) when using sophisticated decoder libraries. This way, a JPEG image with a WebP size may look with the same quality. But I didn't test. https://news.ycombinator.com/item?id=22245788 https://news.ycombinator.com/item?id=22245788 Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL format without loss. https://google.github.io/brunsli/ https://google.github.io/brunsli/

nisten 6y ago

What really sucks about all this is that they're actually ruining the credibility of lighthouse audits this way; what has been for years the best all-in-one automated performance+accessibility analysis tool for any web app/site and is now being used to promote some random new image format no one wants to care about. You spend all this time improving your stack, reducing your app bundle size, convincing your company on the benefits of server side rendering, improving your devops, getting your manager to see these measurable benefits by running lighthouse audits themselves etc... Then all of a sudden it turns out that the main tool you used for this has been turned into a.. a fking ad platform. I apoligise for this emotionally charged rant, but seriously though, is that how you plan on getting developers adopt your dubious new standard, by p*ssing them off?

nyanpasu64 6y ago

As an observer of video codec development, I heard Daala (PVQ) used activity masking to make quantization steps finer (don't discard all detail) in low-contrast areas. I don't know if that's practical in AV1 (a DCT block-based codec).