
Firefox to support Google's WebP image format for a faster web - shdon
https://www.cnet.com/news/firefox-to-support-googles-webp-image-format-for-a-faster-web/
======
vladdanilov
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_...](https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification)

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

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

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

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

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

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

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

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

~~~
akmittal
Chrome on iOS is just wrapper around safari WebKit.

------
TheAceOfHearts
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](https://en.wikipedia.org/wiki/WebP)

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

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

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

From:
[https://developers.google.com/speed/webp/faq](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.

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

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

~~~
colejohnson66
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)

~~~
flohofwoe
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](https://developers.google.com/speed/webp/docs/riff_container)

~~~
dllu
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](https://commons.wikimedia.org/wiki/User:Dllu)

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

Anyways, webp is for websites not cameras..

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

~~~
freeone3000
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)

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

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

~~~
gardaani
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...](https://9to5google.com/2018/09/14/youtube-av1-video-beta-chrome/)

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

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

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

~~~
cornstalks
> _Unless I 'm mistaken AV1 is very far from finalized_

AV1 is finalized: [https://aomedia.org/av1-features/get-
started/](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.

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

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

~~~
tannhaeuser
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?

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

------
gojomo
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/](https://bellard.org/bpg/)

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

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

~~~
okket
Open Source does mean it is free of patents.

~~~
yjftsjthsd-h
Does _not_ mean it is free of patents.

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

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

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

------
wooptoo
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/](https://wooptoo.com/blog/serving-webp-today/)

------
tootie
Have browsers started deprecating any image formats to decrease bloat?

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

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

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

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

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

------
glenrivard
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?

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

~~~
matthewmacleod
_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.

~~~
writepub
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...](https://webrtc.github.io/samples/src/content/datachannel/basic/)

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

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

~~~
matthewmacleod
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](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.

~~~
writepub
Thanks for the clarification. Your time is much appreciated!

Cheers

