Firefox to support Google's WebP image format for a faster web | Hacker News Reader

Firefox to support Google's WebP image format for a faster web

cnet.com

161 pointsshdon84 comments

WebP lossy and WebP lossless often get mixed up. They are substantially different. While the former is mostly just outdated VP8 4:2:0, it is fast and more pleasing to the eye than JPEG at low quality and more practical there, given it has transparency. The latter is a pretty good option for ARGB images offering 25% improvement over PNG [1], and 20-40% on top of that with near-lossless compression.

[1] https://developers.google.com/speed/webp/docs/webp_lossless_...

Not only that, but it's also MUCH faster than PNG in both decoding and encoding. I use it for all images I store as lossless.

People point out that WebP isn't ideal, that there are better alternatives etc.

All that may be true, but the most relevant factor here is Google and Microsoft backing WebP. Google has the power to push through its own inventions due to Chrome's market share. If you want less of that, use Firefox.

Meanwhile, Mozilla hasn't given up on better formats, as the article points out.

While I like a lot of the new capabilities of the web, I sometimes feel like it's Google strong-arming them into existence, and the rest has to follow.

Which makes Google Chrome a modern day IE. They push basically proprietary nonsense into the web that eventually gets scrapped or forced into being an open spec at which point its harder to redefine since it became a "works on my browser" implementation.

Except that the problem with IE was stagnation in era of IE6, not new standards backed by patent free and open source libraries.

The original problem with IE was its implementation of early CSS drafts - an open standard with specs. They just picked the “wrong” version of such specs and pushed it with their commercial strength. Everyone else was then caught between the choice of implementing the real (better) spec, or lose compatibility with IE.

Similarly, Google now picks the standards it likes, and everyone else is caught between the choice of investing in those or lose compatibility with Chrome. Not much of a difference.

I feel that Safari (mobile one) is way closer to the IE6 status with its ban of competition on platform, lack of standardised features and heavy handed management.

You can easily replace Chrome, it's not even a platform default. You're forbidden from replacing Safari.

I'm not sure why you're voted down. Mobile Safari has thrown some really bizarre and awful bugs at a few projects I've worked on, and given how critical mobile experiences are these days, it's genuinely a pain in the ass. It's a very nice mobile browser for the most part, but what it gets wrong is enough to make me kind of loathe having to deal with it.

I had thought that Chrome's Blink engine was the platform default on Android. But I am not sure.

How does a web developer test for Android compatibility? I have been testing against Chrome only.

Chrome on iOS is just wrapper around safari WebKit.

Firefox is also going to support webp

https://appleinsider.com/articles/18/10/05/firefox-gets-supp...

... as mentioned in the title of this submission.

Haha, sorry got confused and misunderstood the comment / article

That's surprising. I was under the impression that it was already supported since they support WebM.

The Wikipedia article [0] says they started evaluating adding support in 2016. Following the source links to this bug report [1]. From a quick glance at the discussion there, it's not obvious to me that they've settled on adding in WebP support.

What we need is buy-in from Apple. Although I'd be much more excited about them adding WebM support so we can finally drive the last nail in the GIF coffin. Does anyone know why they pulled it out? If I had to take a shot in the dark, maybe it doesn't perform well on mobile or it consumes too much power?

Maybe this is a dumb question, but why will we be supporting both WebM and animated WebP? According to the Wikipedia article, WebP also has animation support.... But isn't that kinda redundant? Do they solve different problems? You can just create WebM containers without an audio stream.

While we're on the subject of adding new image formats to the web, does anyone know if there's any interest in adding FLIF support [2]? When it came out it seemed much more interesting to me, but it looks like it never picked up steam.

As an aside, can I just say fuck CNET? Here they used a shitty linking practice which I always find incredibly annoying. Instead of linking to primary sources, they add some useless tag links along with references to old CNET articles. How about linking to the relevant bug reports, asshole?

[0] https://en.wikipedia.org/wiki/WebP

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

[2] https://en.wikipedia.org/wiki/Free_Lossless_Image_Format

> why will we be supporting both WebM and animated WebP?

From: https://developers.google.com/speed/webp/faq (Why not simply support WebM in <img>?)

WebM uses more memory, it is less widely supported, uses more resources when playing, and is currently less efficient compression-wise than WebP.

About FLIF, I was recently checking it and it's indeed a very interesting format. Notably because it can be used on any type of image. I assume it hasn't pickep up steam because it doesn't have the backing of any big sponsor. Google is pushing WebP, and introducing another format at this time is probably not worth it.

FLIF is interesting, yes, but after doing some more research into it I came to the conclusion it doesn't hold any promise as an image format for the web.

The progressive streaming is a cool trick, but if you actually use the progressive stream to embed lossy images in your web page, you end up with lower quality than if you had just used JPEG in the first place, never mind something newer. The difference was pretty stark.

CNET is an all around terrible experience.

WebP is reasonably fast, this can't be said about the other image formats. I tested WebP, FLIF and BPG when I was looking for a PNG alternative and WebP seemed to be the best choice all-around. The only downside of WebP is that it doesn't work with images larger than 16383 pixels in width or height.

2^14 pixels in both directions with 4 bytes per pixel (ARGB) puts the pixel data at a maximum size of 2^30 bytes. Just barely enough to be indexed using a 32-bit integer (even a signed one if you want)

Looks like WebP uses RIFF data chunks [1] (which look a lot like the old Amiga IFF file format), and the size of such a chunk is a 32-bit integer. Besides, 16k width/height ought to be enough for anyone ;)

[1] https://developers.google.com/speed/webp/docs/riff_container

I take photos of trains [1] and regularly run into file format limitations as the photos can easily reach hundreds of thousands of pixels wide.

Besides, modern cameras such as the Sony a7R II are already producing photos 8000 px wide, and the upcoming 100 megapixel cameras such as the Fujifilm will do 12000 px wide images. It's very easy to hit the limit if you're planning to shoot any panoramas.

[1] https://commons.wikimedia.org/wiki/User:Dllu

If the raw size is approaching 4GB maybe it's fair to split the image..

Anyways, webp is for websites not cameras..

I don't get your point. You wouldn't typically encode such a large image in one chunk.

Sorry for the ignorant question, but what does it mean for a format to be "fast"? Does it takes less time to compress the image? and why would that matter in 99% of cases?

That's too bad. WebP was a bad idea released several years too early, now it's stuck with VP8 and the only color format is 8-bit 4:2:0 which is just not good enough. Please don't use it.

It's better than JPEG and PNG for most uses, with smaller image sizes. Even 4:2:0 is better than the sRGB usually used in PNG. I'd rather have this now than wait another few years for a few niche usecases (where TIFF can still be used)

You can use AV1 or HEIF right now, and they're actually modern formats.

> Even 4:2:0 is better than the sRGB usually used in PNG.

Better for what? Not for wide-color photographs or any kind of colored text, that's for sure.

Afaik there is no av1 or heif browser implementations. Theres far less efficient polyfills for heif that are poor on large images.

HEIF works in Safari, and I believe Android will have it soon if it doesn't already. As for AV1, browsers can add it anytime they want…

Looking at CanIUse [1][2], it seems like the HEIF support is in macOS itself, and not the Safari browser. I wouldn't be surprised if the Windows version of Safari didn't support it.

[1] https://caniuse.com/#feat=heif

[2] https://github.com/Fyrd/caniuse/issues/3767

Safari for Windows has been discontinued a few years back.

Chrome 70 Canary and Firefox Nightly support AV1. YouTube has a test channel with AV1 encoded videos.

https://9to5google.com/2018/09/14/youtube-av1-video-beta-chr...

That is very, very new, and afaik it uses the poorly performing reference Implimentation.

JPEG can do 4:4:4. And so can PNG.

Every format looks like a bad idea released too early when you're looking 8 years back at it. At least lossless WebP is better than PNG. Is there something better by now? Yeah, but 8 years from now when everything actually supports and uses it you'll have the same thoughts.

There is something better by now, so why add it now?

I actually don't think this about other formats - for instance MP3 is 25 years old and I think it's just fine to support it. It's patent free and its quality limit is all you need for many applications.

This isn't true for VP8, our eyes are just harder to please. (And On2 was never the best codec developer…)

Strange to cave so late in the game with AVIF right around the corner. This article really doesn't explain why.

Unless I'm mistaken, while AVIF may be "right around the corner", it's still quite a way off relative to the speed of technological advances. Unless I'm mistaken AV1 is very far from finalized or being a realistic option for the web, and as AVIF will effectively just be a still-image subset of AV1 it's going to take some time as well. (I'm still very excited about it, however.)

I suspect they might be motivated by the rapid way in which HEIF seems to be taking over. My understanding is that comparatively, the patent situation of WebP is much better. If you're a company concerned about software patents on the web, it might suddenly seem that throwing your weight behind WebP as a way of avoiding the proliferation of HEIF is worthwhile.

> Unless I'm mistaken AV1 is very far from finalized

AV1 is finalized: https://aomedia.org/av1-features/get-started/

I think there are a couple bugs and contradictions between the spec and reference implementation that are being ironed out, but the bitstream is now frozen.

The copy of Firefox that I'm using to type this has the AV1 library linked to it (via ffmpeg).

AV1 is enabled for video in the next release of Chrome, and the current release of Firefox has it behind a flag IIRC. The spec has been finalized since early this year, and the results are stunning: You can produce recognizable, sometimes perfectly passable, images at around one tenth of a bit per pixel.

Try the "clovisfest" test image here[0], with the most recent AV1 snapshot on the right, and MOZJPEG (the most advanced JPEG encoder on the market, AFAIK) on the left, with both set to the "Tiny" target bitrate (0.1bpp). Smooth, continuous grades look hideous on JPEG up to pretty high bitrates, and JPEG never quite reproduces hard edges or sharp specks properly; AV1 excels at both of these.

[0]: Image formats comparison <https://wyohknott.github.io/image-formats-comparison/#clovis...

Indeed, strange that Microsoft decided to support WebP and not wait for AVIF [1]. Mozilla had said that if at least one browser in addition to Chrome supports WebP, then they will consider supporting it, so looks like they are just fulfilling that promise [2].

WebP has its drawbacks, like no support for HDR content. AVIF supports it and Netflix would like to use it for video thumbnails.

[1] https://www.cnet.com/news/googles-webp-image-format-finally-...

[2] https://www.cnet.com/news/apple-ios-macos-tests-googles-webp...

We'll probably end up with both like we've had jpg and PNG, at least if more people/organizations call for it.

AVIF is primarily a lossy format, the place were WebP shines is in it's lossless mode. Being able to replace PNG as the de facto standard lossless format would yield better compression while still decoding and encoding faster.

Great, but we really need Safari to support WebP since that is the only option for iOS mobile devices.

My business is 80% mobile traffic, of which 80% is iOS. It feels a lot like the old IE6 days, only (fortunately) less painful.

Yeah I confirm, I spend so much time fixing bugs for IE11 and Safari mobile.

similar market forces at play - apple users use safari coz it is the default browser so you have to develop for safari first not web first just like ms wanted you to develop for IE first not web first.

It's actually the only browser engine on iOS, all the third party ones are just skins on it with convenience features like syncing with their desktop counterparts.

... For some reason. Because Apple. This is one of the things keeping me from taking them seriously.

I recall how much joy I felt when my company's IT retired IE 7 and force-upgraded everyone to IE 8. So much polyfills and crutches that we could get rid of... (It was about the same, to a lesser extent, when moving the minimum requirement up to IE 9. That's the point where I stopped thinking about browser support.)

Doesn't Safari support JPEG 2000 in exchange? And Safari was the one that introduced the newer picture element for enumerating responsive image choices (though to the dismay of HTML semanticists as HTML rather than CSS) wasn't it?

Not really, Firefox and Chrome supported the picture element well before Safari did. It was part of the nascent HTML5 standard.

I believe what WebKit introduced was the analogous CSS image-set property, which likely influenced the picture's element's development (but image-set still hasn't managed to escape draft-spec territory).

Yeah, if you want to serve the most optimal image for Safari (iOS or desktop) JPEG 2000 is the way to go.

The ideal format would be HEIF but there's not a lot of conversion support out there, Imgix doesn't support it for instance.

You can use a polyfill: libwebpjs.

To my eyes, Fabrice Bellard's HEVC-based 'BPG' looks even better at the same sizes, so I'd love to see it more widely supported, too. See:

https://bellard.org/bpg/

... except you need to pay loads of money for the (edit: HEVC) license

Why? The "licensing" information at the bottom of the page makes it seem like it's open source?

Because it's based on HEVC. HEVC patents have a very complex (and expensive) licensing situation right now.

Open Source does mean it is free of patents.

Does not mean it is free of patents.

Oops, right. I really thought I wrote this. Sorry.

Yeah, I assumed it was just a typo, but I figured we wanted to be absolutely clear here.

I promise I will never become a lawyer or write math books.

The author can only give up his own rights. Identifying and acquiring any patent rights owned by other people is up to you.

Patent complications do seem to be a factor, but it's unclear if in practice it'd be "loads of money", as the project page suggests many existing systems already have licensed decoding capabilities.

Also, one of the patent pools covering HEVC announced in 2016 that software-only implementations would be royalty-free:

https://www.prnewswire.com/news-releases/hevc-advance-announ...

Whether still-other licenses from other patent-holders might be necessary for software-only, in-browser decoding is unfortunately murky.

Which is basically the same as HEIF, except bpg has a sane container.

Good to see Firefox join the party, even tough it's 4 years late. Serving multiple content types based on the http accept header sent by the browser is easy to setup. [1] So Chrome and Firefox users can benefit from the better webp compression while Safari and IE can stick to jpeg. [1] https://wooptoo.com/blog/serving-webp-today/

Have browsers started deprecating any image formats to decrease bloat?

Would that meaningfully reduce bloat?

I'd like to see the opposite; Browsers having support for more image formats, especially the legacy ones from 20+ years ago (PCX, ART, ILBM, MAC etc.). That way interesting and useful imagery from days gone by aren't lost forever when the few remaining decoders never get ported to newer operating systems.

People compare it to JPG or PNG. I think the main point is for deprecating GIFs, with their poor quality and very slow processing.

Congratulations! It took them only 8 years to implement WebP. Here is the original bug: https://bugzilla.mozilla.org/show_bug.cgi?id=600919

Are there any technical details on that? For example would Firefox send Accept headers with image/webp?

It would essentially have to, in order to support WebP as the web uses it.

This is fantastic to see. I hope Firefox will also isolate sites for better Spectre protection like Google did with Chrome. Takes more RAM but the added protection, IMO, is well worth it.

Had heard they are working on it. But had not heard a date?

Mobile web consumption is now the majority of web engagement. Given that, iOS Safari's reluctance speaks volumes. I bet this has anything to do with technology, and more with Apple's business rivalry with the open web.

Given how iOS Safari is the least standards compliant browser of our time (other than the now defunct IE), I'm surprised they even implemented webassembly & webRtc (they didn't implement the data channel)

webRtc (they didn't implement the data channel)

That is not correct. I've used WebRTC data channels myself on iOS and it works fine.

Can you link to a WebRTC Data Channel URL that works on iOS Safari?

Here's a simple WebRTC DataChannel demo that doesn't work on iOS 12.0 Safari

https://webrtc.github.io/samples/src/content/datachannel/bas...

I'm afraid not – none of the available demos seem to work, but I don't know why that would be the case. All I can say is that I worked with the technology pretty extensively, and was absolutely able to use a data channel between Chrome and Safari 11 on both desktop and mobile without any issues.

It doesn't work because iOS Safari hasn't implemented WebRTC Data Channels.

I'm sorry, this is not correct. Like I said, I used data channels in Safari on iOS only a few weeks ago, and I'm not making that up!

Since you're not convinced, I looked into it a bit more, and the reason most of the available demos don't work is down to a difference in behaviour between Safari and other browsers, probably to do with address selection for the connection. WebRTC can leak private network configuration in some cases, so Safari seems to be pretty strict in that it requires `getUserMedia` to be called before allowing a data-channel-only to be established.

I made this into a small demo (https://codepen.io/anon/pen/GYrqGL) and you can see after a couple of clicks of 'connect' that a data channel connection is established and works as expected. This is a bit of a privacy/usability tradeoff. But data channels are very much implemented in Safari.

Thanks for the clarification. Your time is much appreciated!

Cheers

Reply on news.ycombinator.com