Hacker News Reader

Comment by Eric_WVGG | Hacker News Reader

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.

View on HN

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.

The only image format I can think of where you can encode a blur applied to some part of the image is SVG

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

WEBP support has been added to the next version of Safari (14).

!!!!

Yes, and I submitted it on HN.

https://news.ycombinator.com/item?id=23614193

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.

Full blending, or just masking? i.e. can alpha values take on the full range from 0-1, or are they limited to full on or full off?

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.

What was the result of the switch, how heavy is a full page load now?

2.44mb, down from 22.2mb (just checked). And the new site has more, even larger images. https://www.prior.club

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.

Contentful person here - what could we do to make your experience better?

Feel free to shoot me an email if you don’t want to respond here. rouven _at_ contentful _dot_ com

Safari Mobile is a broken mess not worth supporting.

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

Shades of IE6 Stockholm syndrome.

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.

The IE6 problem is the same reason I'm currently stuck supporting IE11. The vague fear that we don't want to cut off like 3% of our users.

It's impossible to test for without buying expensive hardware, so I'll pass.

A used iPod Touch is $35, the same price as a Raspberry Pi.

Is a Raspberry Pi "expensive hardware"?

Right, I'll put "Designed for used iPod Touch" in the footer then.

If the browser is the same what difference would it make?

Use a service like browserstack

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?

If you're outside of the US then the answer can easily be "yes". I don't recommend it though.

Said that about IE5 in 1999. Didn't work out for me.

What problem exactly you have?

If Safari was your main browser during your web development you wouldn't have any issues would you?

Realistically people should be using either Safari or Firefox during their development. Then check for chrome compatibility after.

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

Reply on news.ycombinator.com