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