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.
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.
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.
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.
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.
Not sure about his images, but WebP supports lossless compression. If they are coming from a camera, it seems reasonable that they might be lossless, depending on the camera settings.
[Update] Just noticed he's going JPEG->WebP so my comment makes no sense.
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.
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.
> 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
From a business point of view, it makes sense to waste a few days once in a while to support it.
But sometimes you can't support it without huge hacks like implementing everything on CPU with WebAssemply. For example MediaSource is disabled on Safari for iPhones (but enabled since a few months for iPads). I think the only reason is to force developers to publish apps in the AppStore. Which is a pain.
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.
But it is the only browser on iOS (even if you install another browser, under the hood it MUST use the safari rendering engine, so all browser use on iOS is really Safari). Not supporting means you are not supporting any iPhone or iPad user. You might be anti-apple in your personal technology choices, but can you be anti-apple for whoever you work for?
Pretty sure you can just use Firefox and then check in Safari and Chrome. It's pretty hard to make a website for firefox that will be broken in any modern browser...
WEBP support has been added to the next version of Safari (14).
Good to hear. But that still means it'll still be 1½ years before enough users in the wild are on iOS 14 to make the change without breaking the sites for a large number of people. At least, from what I read, iOS upgrade adoption is very quick compared with other platforms.
WebP is something to look forward to on my company's internal projects, but externally we still have to support IE11, as it's still very widespread in the medical field, and I haven't seen the user numbers budge on that.
IE11 supports the figure element, so it is possible to use webp and have a fallback to the png or jpeg, but since I already use figure for multiple image sizes I will support webp with fallbacks for a while...
Safari users seem to update very quickly (based on stats about iOS and MacOS update timelines). I've already got some desktop-oriented websites that are WebP only, and once Safari supports WebP on iOS, I'll finish transitioning them all.
The space savings is quite nice for my bandwidth bills (my websites don't have video, so I estimate saving about 20% in bandwidth costs, or approximately $120/month across all of them).
I wouldn’t be able to view any of your sites as I’ve disabled webp in my browser. It always looks blurry to me and if I save an image I can only view it again in a browser.
Most of the images are converted losslessly. So are pixel-for-pixel identical. Some are lossy but only with conversion settings that make them essentially identical. So far no one has ever been able to tell.
> 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.
Yeah, you can do manual alpha masking in webkit, but it's freaky and stupid.
Looks like mask is standard now. In Webkit it is behind the -webkit-* prefix, and it only implements mask-image (which is what you want anyway).
-webkit-mask-image does exactly what you're looking for (poorly) :+ )
The other way to do it is SVG, but if you want that to be data efficient, you generally end up with three HTTP requests at two levels for a single image, or you have base64 and it has to be gzipped or it's larger.
On iOS, any screenshot taken while iOS background blur is active will balloon from 0.15MB to 15.0MB, because iOS uses PNG for screenshots and blurred backgrounds are apparently irreducible by PNG.
Does the WebP format permit bounded areas of an image to be represented at lower fidelity with a smooth blur, so that the blurred-background effect can be stored and retrieved using fewer pixels and a blur algorithm rather than more pixels and no blur algorithm? Do PNG or HEIF (h265) support this? Does any image format support bounded areas of lower fidelity?
The tricky part is that this implies that some areas of the image should intentionally be reproduced as ‘lossy’ and ‘lower fidelity’ and so forth, which is precisely correct - but goes against the grain of image encoding in the past.
I did some reading of the PNG specification and it may be possible to take advantage of Adam7 interlacing (8 passes total) and scanline filtering (several methods) to write out an image where the scanlines of 'known to be blurry' areas contain only 1 pass of image data and 7 passes of highly-compressible scanlines with filters that generate blur at decode-time.
Doing this formally at scale would require the compositor and the encoder to cooperate, as the encoder would benefit greatly from having access to both the 'blurred' and 'unblurred' areas without the blur filter having been applied to the former, as it could then construct low-fidelity, low-bandwidth, visually pleasing blur for the 'blurred' segments.
This exceeds my ability to write PNGs by hand and it certainly exceeds the bounds of what most people think 'an encoder' should be capable of doing, but at least it presents a path forward. I'll post to HN someday if I ever somehow manage to do this.
At that point you might as well use something like PDF, where you can choose exactly what image format you need for each region. Put a JPG as the blurred background, then put a transparent PNG as the foreground for text and buttons in your screenshot.
macOS screenshots appeared to be PDF natively for the first few years, which made sense since their window compositor was operating what appeared to be a PDF canvas in-memory. They're still clearly using a PDF-like canvas, since there are certain windows that aren't included in screenshots — but what's underneath them is — which is not possible without a layered canvas somewhere. I think after the first decade they stopped offering .PDF screenshots and switched to .PNG now, and based on other replies alongside yours, it's likely they'll be replaced by HEIF soon, but it bodes well for improvements here that their screenshot engine has access to the original layers.
(This isn't just relevant to Apple users — imagine if Photoshop's PNG/HEIF encoder could export blurred segments with lower byte density than unblurred segments, for example. Folks generally are not used to thinking about fidelity-sensitive image encoding, and that's why this is so interesting to me.)
HEIC (HEVC-based image) and AVIF (AV1-based image) both support a lossless mode that does efficient compression of blurs and gradients, without losing any visual fidelity. They're good candidates for screenshots in the future. Lossless HEIC is often 50% of the size of the equivalent PNG.
HEIF, AVIF and JPEG XL all support multi-layer images, so you could e.g. encode the background in a lossy layer (which works well on blurry stuff) and foreground in a lossless layer (which works well on screenshots).
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.
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.
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".
In theory, you could probably do some combination of altering the user agent, and/or blocking .onload for webp images (which is often used to detect webp support).
If you changed both, most sites would probably serve you a jpg/png version.
Perhaps a site is giving you a different version of a file based on your user-agent? Try changing your user-agent and see if that changes. Or contact the website and ask them.
Chrome sends "Accept: image/webp" by default when requesting images. Some CDNs send webps to clients who send this header and original-format images to clients who do not.
Use the developer tools, right click on the image's request and from there copy as curl... paste in an editor and remove all the headers, etc and you should get a more compatible version.
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?
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
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.
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.
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.
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.
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.
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.
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."
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.
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.
I'm surprised this doesn't include 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.
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.
Extremely subjective, personal data point: I've been running with an extension (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
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.
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
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.
> 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.
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.
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/ 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).
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.
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.
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.
can is not the same as must ... there is absolutely the possibility of adding support as a binary implementation, especially with the relatively short turn around of green browsers. IE11 and Safari are the last of the old guard on this and mobile devices have a 2-3 year burnout in terms of support.
Not to mention it could be feature detected via browser, js and other means as an interim solution. Also, I'm pretty sure the implementation is wasm with a very thin JS shim, at least that would be my presumption as I'm not familiar with this format/project.
It's extremely ironic then that IE11 and Safari are the only browsers to support HEVC, the rest didn't bother because of the licensing issues (which BPG inherits) severely limiting any chance it has of ever being natively supported.
Thats a great and accurate metaphor. Maybe its not a good metaphor since those compare dissimilar things with common attributes. So, this is just accurate.
This is kind of neat, but when I think of "HEVC-based image codec" I think of Apple's .heic format. Unfortunately I didn't see a high-level comparison to HEIC on Bellard's site, so I'm not sure what the advantages of BPG are. Wouldn't I want to use the more common format?
BPG came before HEIF. It was a great proof of concept, but there’s little reason for it to exist now. BPG was an impressive one-man spec; HEIF is based on input from OS developers, camera makers, IC designers, display manufacturers, etc.
HEIF is just a generic image container format. It’s almost identical in structure to a .mp4/.mov/.av1 file (follows ISO BMFF) and can be parsed in an identical way using a simple tree structure. That’s a perfect fit for wrapping a single video I-frame as an image, the basis of all of these new image codecs.
Note that video I-frames can often only be properly rendered using metadata from outside the bitstream, such as HDR characteristics, color profile, or orientation. Sharing that metadata structure with the codec’s canonical video format is the only way to be forward-compatible.
A HEIF that wraps AV1 frame(s) is an .avif
A HEIF that wraps HEVC frame(s) is a .heic
Codecs will change, but the HEIF container is probably the last bitmap file format that we’re going to need for decades.
Of course any format can be decoded in js or wasm, that’s not an advantage and doesn’t tell us anything. The most important thing for a format is probably vendor buy-in. Why would anyone choose this over HEIF, which also uses HEVC (optional), is backed by MPEG (like it or not, MPEG represents the industry), and has vendor buy-in from Apple and Google? (I know it’s not supported in the browsers, at least not yet, but you can also use a library.)
Also, the latest news entry:
> (Apr 21 2018) Release 0.9.8 is available
Edit: Spoke too soon. “Official” HEIF JavaScript port measures ~500-600k gzipped, so 56k gzipped is an advantage.
> MPEG (like it or not, MPEG represents the industry)
Not so much anymore. The licensing fiasco with HEVC has reduced MPEG's relevance, particularly for web video. Here's what Leonardo Chiariglione, founder and chairman of MPEG, says about it:
Why would anyone waste their time on a format with complex and uncertain licensing when they can just implement AV1 with its simple, royalty-free licensing?
Key questions: (1) Is it encumbered by any patents? (2) Does a formal description of the algorithm exists, to allow for independent implementations? (3) Does a MIT/BSD or at least LGPL implementation exist? (4) Has it been submitted for standardization?
Technical merits are of limited value if you can't deploy them.
It's great in terms of compression (close to half size of WebP for comparable quality), but:
• In countries with software patents it's illegal to use BPG without a patent license for the H.265 codec, and that patent pool is a mess. Someone needs to do BPG with AV1 payload, or just wait for browsers to finish implementing AVIF.
• JavaScript adds significant latency. Browsers request native images before running any JS, so even an infinitely fast JS polyfill already starts from a losing position. On top of that, low-end devices are likely to spend more time and energy on running the JS decoder than on downloading a larger JPEG.
I just have to re-affirm I do appreciate the lower quality render path of hevc (blurry) more than the default for jpeg and others (blocky mess). I really don't visually notice the lower quality reductions at much lower quality levels/file sizes than comparable blocky formats.
That's not to say it isn't lower quality, when looking in detail you see it... but for a lot of use cases (and in video) much better experience in general.
318 comments
[ 3.1 ms ] story [ 103 ms ] threadAnd 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.
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.
https://github.com/imager-io/imager
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.
[Update] Just noticed he's going JPEG->WebP so my comment makes no sense.
WebP did not take off.
But will AVIF be any better?
https://netflixtechblog.com/avif-for-next-generation-image-c...
https://github.com/AOMediaCodec/libavif
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/
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.
+ WebP was initially released in 2010
Edit: Looks like it was that specific website and they are doing something odd, so I retract my initial judgement.
I'd be curious to see a WebP vs PNG comparison, since (IIRC) it has a lossless mode too.
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.
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.
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.
Edit: saw somewhere that it is used in production for real-time video, but had trouble using rav1e as opposed to libvpx
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.
https://www.w3counter.com/globalstats.php
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.
Is a Raspberry Pi "expensive hardware"?
But sometimes you can't support it without huge hacks like implementing everything on CPU with WebAssemply. For example MediaSource is disabled on Safari for iPhones (but enabled since a few months for iPads). I think the only reason is to force developers to publish apps in the AppStore. Which is a pain.
Realistically people should be using either Safari or Firefox during their development. Then check for chrome compatibility after.
https://news.ycombinator.com/item?id=23614193
Good to hear. But that still means it'll still be 1½ years before enough users in the wild are on iOS 14 to make the change without breaking the sites for a large number of people. At least, from what I read, iOS upgrade adoption is very quick compared with other platforms.
WebP is something to look forward to on my company's internal projects, but externally we still have to support IE11, as it's still very widespread in the medical field, and I haven't seen the user numbers budge on that.
The space savings is quite nice for my bandwidth bills (my websites don't have video, so I estimate saving about 20% in bandwidth costs, or approximately $120/month across all of them).
Yeah, you can do manual alpha masking in webkit, but it's freaky and stupid.
-webkit-mask-image does exactly what you're looking for (poorly) :+ )
The other way to do it is SVG, but if you want that to be data efficient, you generally end up with three HTTP requests at two levels for a single image, or you have base64 and it has to be gzipped or it's larger.
Does the WebP format permit bounded areas of an image to be represented at lower fidelity with a smooth blur, so that the blurred-background effect can be stored and retrieved using fewer pixels and a blur algorithm rather than more pixels and no blur algorithm? Do PNG or HEIF (h265) support this? Does any image format support bounded areas of lower fidelity?
The tricky part is that this implies that some areas of the image should intentionally be reproduced as ‘lossy’ and ‘lower fidelity’ and so forth, which is precisely correct - but goes against the grain of image encoding in the past.
Doing this formally at scale would require the compositor and the encoder to cooperate, as the encoder would benefit greatly from having access to both the 'blurred' and 'unblurred' areas without the blur filter having been applied to the former, as it could then construct low-fidelity, low-bandwidth, visually pleasing blur for the 'blurred' segments.
This exceeds my ability to write PNGs by hand and it certainly exceeds the bounds of what most people think 'an encoder' should be capable of doing, but at least it presents a path forward. I'll post to HN someday if I ever somehow manage to do this.
(This isn't just relevant to Apple users — imagine if Photoshop's PNG/HEIF encoder could export blurred segments with lower byte density than unblurred segments, for example. Folks generally are not used to thinking about fidelity-sensitive image encoding, and that's why this is so interesting to me.)
Still something like 5x what I would recommend to most folks, but there’s just no getting around a site like this being very photographic.
(Edit) I can’t attribute all of this to next-gen images, also doing lazy load and other tricks.
Feel free to shoot me an email if you don’t want to respond here. rouven _at_ contentful _dot_ com
https://chrome.google.com/webstore/detail/save-image-as-type...
In theory, you could probably do some combination of altering the user agent, and/or blocking .onload for webp images (which is often used to detect webp support).
If you changed both, most sites would probably serve you a jpg/png version.
> proprietary
No. It is an open standard (ISO/IEC 23008)
Apple started supporting it in 2017. Microsoft in 2018.
You are correct, though — it's not supported by any browser.
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.
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.
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.
[0] https://github.com/AOMediaCodec/libavif
However the main benefit of webp is alpha backgrounds or transparency. It can destroy PNG when it comes to compression and size.
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."
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
see jpeg-xl
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.
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"
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.
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
[1] https://portabella.io
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.
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.
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.
FLIF & FUIF were created by Jon Sneyers - 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_im...
[0] http://flif.info/ -- superseded by FUIF
[1] 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 - from Google, got absorbed by JPEG XL
[3] https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
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.
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.
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.
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.
Not to mention it could be feature detected via browser, js and other means as an interim solution. Also, I'm pretty sure the implementation is wasm with a very thin JS shim, at least that would be my presumption as I'm not familiar with this format/project.
AVIF however may have a chance.
HEIF is just a generic image container format. It’s almost identical in structure to a .mp4/.mov/.av1 file (follows ISO BMFF) and can be parsed in an identical way using a simple tree structure. That’s a perfect fit for wrapping a single video I-frame as an image, the basis of all of these new image codecs.
Note that video I-frames can often only be properly rendered using metadata from outside the bitstream, such as HDR characteristics, color profile, or orientation. Sharing that metadata structure with the codec’s canonical video format is the only way to be forward-compatible.
A HEIF that wraps AV1 frame(s) is an .avif
A HEIF that wraps HEVC frame(s) is a .heic
Codecs will change, but the HEIF container is probably the last bitmap file format that we’re going to need for decades.
Also, the latest news entry:
> (Apr 21 2018) Release 0.9.8 is available
Edit: Spoke too soon. “Official” HEIF JavaScript port measures ~500-600k gzipped, so 56k gzipped is an advantage.
https://github.com/nokiatech/heif/tree/gh-pages/js
Not so much anymore. The licensing fiasco with HEVC has reduced MPEG's relevance, particularly for web video. Here's what Leonardo Chiariglione, founder and chairman of MPEG, says about it:
https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu...
https://blog.chiariglione.org/stop-here-if-you-to-know-about...
And they're shaping up to make VVC (https://en.wikipedia.org/wiki/Versatile_Video_Coding) licensing just as bad.
Leonardo says there is no longer a united MPEG:
https://blog.chiariglione.org/a-future-without-mpeg/
Why would anyone waste their time on a format with complex and uncertain licensing when they can just implement AV1 with its simple, royalty-free licensing?
Key questions: (1) Is it encumbered by any patents? (2) Does a formal description of the algorithm exists, to allow for independent implementations? (3) Does a MIT/BSD or at least LGPL implementation exist? (4) Has it been submitted for standardization?
Technical merits are of limited value if you can't deploy them.
https://github.com/mirrorer/libbpg
• In countries with software patents it's illegal to use BPG without a patent license for the H.265 codec, and that patent pool is a mess. Someone needs to do BPG with AV1 payload, or just wait for browsers to finish implementing AVIF.
• JavaScript adds significant latency. Browsers request native images before running any JS, so even an infinitely fast JS polyfill already starts from a losing position. On top of that, low-end devices are likely to spend more time and energy on running the JS decoder than on downloading a larger JPEG.
Isn't it Fabrice Bellard?
@als0: Thanks for pointing that out.
https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...
Windows, OSX, iOS and Android have support baked in already
That's not to say it isn't lower quality, when looking in detail you see it... but for a lot of use cases (and in video) much better experience in general.
https://github.com/victorvde/jpeg2png
* https://en.wikipedia.org/wiki/AV1