
Is WebP really better than JPEG? - kasabali
https://siipo.la/blog/is-webp-really-better-than-jpeg
======
gruturo
Every time I run an image comparison, the webp version looks worse and yet
Google insists it's the same quality. It's baffling.

Even if the above were just an individual... bafflement? and not an actual
issue, the size savings really don't seem worth the compatibility hassle, the
extra manpower/workflow complexity to support 2 formats, the additional
storage (and caching) caused by this duplication.

And the above is if it's done RIGHT. 80% of people outside this forum won't
understand that you're not supposed to convert from a lossy format to another,
and just convert jpegs to webp.

Webp seems so pointless. A progressive jpeg with an optimized Huffman table
can be understood by a 27 year old decoder without issues, achieves 90% of the
quality/size claims of webp and can be produced losslessly from your source
jpegs. This is without even touching Arithmetic Coding (also lossless, part of
the official standard, but poorly supported due to some software patents, even
though they all expired by now), or playing with customized DCT quantization
matrices to get more compressible outputs (incurs a generation loss, but
produces standard files).

~~~
gsich
I also don't get it why people insist on the same quality with lesser size.
How about more quality and the same filesize?

~~~
MaxBarraclough
> people insist on the same quality with lesser size.

Because a great proportion of people browsing the web have slow connections
and/or data caps.

> How about more quality and the same filesize?

We're already able to get acceptable quality.

~~~
gsich
>Because a great proportion of people browsing the web have slow connections
and/or data caps.

That doesn't matter one bit. See "webpages are doom".

>We're already able to get acceptable quality.

Apparently not when some examples are worse.

~~~
Narishma
Maybe it's just me but I couldn't tell the difference between the comparison
images in the article without zooming in a bunch.

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

[1] [https://bellard.org/bpg/](https://bellard.org/bpg/)

~~~
reaperducer
_can be supported in any browser via a Javascript_

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.

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

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

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

~~~
oauea
Safari Mobile is a broken mess not worth supporting.

~~~
donatj
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](https://www.w3counter.com/globalstats.php)

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

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

Is a Raspberry Pi "expensive hardware"?

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

~~~
00deadbeef
If the browser is the same what difference would it make?

------
bscphil
Unfortunately, targeting same SSIM makes this test basically bullshit. It
would be far better to make images that are the same size, and then we can use
both our eyes and various objective metrics to compare the images.

The reason for this is basically that most codecs do _not_ target SSIM
internally. They're using their own algorithms to determine how to allocate
bits, so two images with the same SSIM may look better or worse depending on
what codec is used. Many modern codecs (e.g. from x264 onwards) _deliberately_
take approaches that lower the score of the result on objective metrics but
usually look better to the human eye.

This exact issue was originally highlighted on the x264dev blog: "How to cheat
on video encoder comparisons" #3: "Making invalid comparisons using objective
metrics". [1]

If you really want to compare image codecs, I'd look at one of the many
comparisons from this family on Github. [2]

In my judgment WebP is _clearly_ better than Mozjpeg for most images.

[1]
[https://web.archive.org/web/20141103202912/https://x264dev.m...](https://web.archive.org/web/20141103202912/https://x264dev.multimedia.cx/archives/472)

[2] [https://wyohknott.github.io/image-formats-
comparison/#abando...](https://wyohknott.github.io/image-formats-
comparison/#abandonned-factory&webp=s&jpg=s)

~~~
krick
This. JPEG has way too many artefacts on naturally smooth areas (like sky) to
be ever considered a pinnacle of lossy image compression. WebP or not, but
some adaptive technique must be the future, if there is any space for lossy
compression in the future at all.

------
ksec
In my opinion, the true contender to JPEG is JPEG XL. [1], where is has better
quality than even AVIF at >0.5 bpp ( Bits per Pixel ) [2].

But the truly amazing next generation VVC manage to compress image with even
better ratio than JPEG XL.

Both JPEG XL and VVC is expected to be finalised in July/Augest. JPEG XL will
be royalty free. VVC as usual is lots of unknown.

[1][https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...](https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs)

[2] [https://medium.com/@scopeburst/mozjpeg-
comparison-44035c42ab...](https://medium.com/@scopeburst/mozjpeg-
comparison-44035c42abe8)

~~~
Scaevolus
VVC is definitely not going to be royalty free, and it's unlikely its intra
coding will compete with JPEG XL for the same target (relatively high bitrate
high quality images).

------
jgrahamc
Some data from when we deployed WebP generation:
[https://blog.cloudflare.com/a-very-webp-new-year-from-
cloudf...](https://blog.cloudflare.com/a-very-webp-new-year-from-cloudflare/)

------
twotwotwo
JPEG XL is worth mentioning here. It includes a JPEG1 repacker (Brunsli) that
saves about 20% and allows recovering the original file exactly. All that
existing JPEG1 content isn't going anywhere, so that seems good. It has some
other neat features like the ability to mix a DCT-based codec with lossless
(modular) mode in an image. Its lossless/modular mode (successor to FLIF/FUIF)
is interesting on its own.

It can be illuminating to stretch codecs a bit _past_ the visually-
indistinguishable threshold, both to better nail down where that threshold is
and to see how annoying the artifacts you end up with are. Lots of comparisons
you can do; this is a fun one: [https://encode.su/threads/3108-Google-s-
compression-proje%D1...](https://encode.su/threads/3108-Google-s-compression-
proje%D1%81ts?p=64512)

At _very_ few bits-per-pixel like the first (bridge) image, everything has
some artifacts. On that image AVIF tends to just blur lower contrast areas,
whereas HEIC produces some visible ringing (faint lines that weren't there
before) around the bridge. Unlike JXL, AVIF and HEIC both have spatial
prediction (extend pixels above/to the left of this block in whatever
direction), which is particularly helpful with straight sharp lines like the
bridge image happens to have. I wouldn't put too much stock in results on that
one image, but I do like being able to judge results subjectively.

(FWIW, a presentation on JPEG XL suggested they were targeting the equivalent
of ~2bpp JPEG quality[0], so perhaps performance in this super-low range
wasn't as much of a priority.)

Anyway, I hope both these formats get wide support, because they each have
clear benefits in some application: JXL's include the upgrade path for JPEG1
content and the multiple modes, and AVIF may be able to salvage a bit more
quality at super low bitrates. AV1 (on which AVIF is based) has wide industry
backing, and the JPEG XL effort is also going for a royalty-free codec and has
support from Google, so hopeful they actually will be usable relatively soon.

(Although HEIC's images are OK and it has Apple's support already, it's
patent-encumbered, limiting what you or I can do with it.)

[0]: [https://www.spiedigitallibrary.org/conference-proceedings-
of...](https://www.spiedigitallibrary.org/conference-proceedings-of-
spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-
coding-tools/10.1117/12.2529237.full?SSO=1)

------
cptskippy
> Note that Mozilla somewhat walked back from this and implemented WebP
> support for Firefox in 2019

I wouldn't call the decision to support a format 6 years after first
evaluating it a walk back, it's a concession that the format has been adopted
by the industry. If the most popular browser supports WebP and sites are using
it, it makes sense that you should support it.

~~~
jonny_eh
WebP also supports animation, and is clearly more efficient than GIF.

~~~
cptskippy
What's the benefit of WebP over something like h264? Most sites today just
convert uploaded GIFs to MP4 or GIFV.

~~~
imtringued
Or just use .webm without audio.

~~~
dundarious
Webm is a container, not a codec.

------
Lammy
My results with libvips have been way more encouraging than this post suggests
with MozJPEG and the WebP reference encoder!

Here's a MEGA folder with my example files so you can compare for yourself.
Sorry I know this host might be blocked in many places, but every image host I
tried (imgur, postimg) recompressed my uploaded files negating the fairness of
the test. If anyone has a suggestion for a better host I'm happy to re-upload.

[https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-
BeENEA](https://mega.nz/folder/JsUXWIqI#xYIohBdiVKrGYTi-BeENEA)

e: another host:
[http://www.filedropper.com/libvipswebpvsjpeg](http://www.filedropper.com/libvipswebpvsjpeg)

My random sample is a black-and-white JPEG photograph vs its WebP equivalent.
The results are in line with my results for many other images of different
types, like other black-and-white photos, color photos, clean computer
graphics, screenshots of UIs and media/games, etc etc. The original image for
this test can be found here:
[https://en.wikipedia.org/wiki/Sand_Hill_Road](https://en.wikipedia.org/wiki/Sand_Hill_Road)

Both test images were output by libvips after loading the original JPEG. The
libvips-generated JPEG is 1.22mb, smaller than the 1.26MB original, but the
libvips-generated WebP is 944KB! I included two sceenshots of each libvips-
generated version opened in a same-size window too, both much smaller than the
full res. Tabbing between the two on my PC does not visibly change on screen
at all.

I don't entirely enjoy WebP just because the software support is still spotty,
but I haven't been able to argue with the compression benefits!

------
rakoo
Extremely subjective, personal data point: I've been running with an extension
([https://bandwidth-hero.com/](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

~~~
andrewxdiamond
How does an extension resize an image without downloading it? Can it
selectively read bytes from the stream?

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

~~~
rakoo
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

------
karamanolev
I'm surprised this doesn't include Google Guetzli
([https://github.com/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.

~~~
acqq
Did anybody really find any reason to use that?

[https://www.pixelz.com/blog/guetzli-mozjpeg-
comparison/](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"

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

------
jchw
> I think Google’s result of 25-34% smaller files is mostly caused by the fact
> that they compared their WebP encoder to the JPEG reference implementation,
> Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG

Well, MozJPEG didn’t exist until four years after WebP, so I suspect that
might explain why.

------
zspitzer
One of the biggest barriers against adoption of these newer formats is the
lack of pure java implementations for use server side.

The Java wrappers around a native binary are helpful, but for many projects
not very useful and this hinders adoption.

[https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue...](https://github.com/haraldk/TwelveMonkeys/issues?q=is%3Aissue+is%3Aopen+label%3A%22Sponsor+needed%22)

~~~
grishka
Using Java code for things that are this performance critical doesn't feel
like a good idea. It will work of course, but it will probably GC a lot, and
while modern JVMs do JIT, the code they generate can't be as optimal as
something that has manual SIMD optimizations.

~~~
lmm
Using C code is how you get the next cloudbleed. I'm happy to pay a
performance cost for the sake of memory safety.

~~~
iomcr
Fix this easily by abstracting the manipulation of user uploaded files to
chroot/serverless.

~~~
lmm
That doesn't fix the problem. The process can still fix any data that it has
access to, which includes other users' confidential uploaded files.

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

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

[0]
[https://github.com/AOMediaCodec/libavif](https://github.com/AOMediaCodec/libavif)

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

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

------
Jonnax
So what's this AVIF format they mention that's actually better than both?

WebP did not take off.

But will AVIF be any better?

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

 _However_ all the big names are part of AOM, which oversees AV1 (and AVIF):
[http://aomedia.org/membership/members/](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.

~~~
nerdkid93
\- WebP was initially released in 2019

\+ WebP was initially released in 2010

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

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

[0] [http://flif.info](http://flif.info)

~~~
andrius4669
>hopefully some day it can be integrated into the standard.

see jpeg-xl

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

~~~
izacus
It's a proprietary patent-encumbered format which isn't really widely
supported in the web browsers.

~~~
Y-bar
Patent-encumbered? Yes.

> proprietary

No. It is an open standard (ISO/IEC 23008)

~~~
chungus_khan
Being patent-encumbered kind of makes it moot on the web though, just like
H.265 video.

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

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

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

------
santoshalper
Improving image compression should really free up some space on my website so
I can fit in a few more javascript frameworks.

------
yboris
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/](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...](https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs)

[0] [http://flif.info/](http://flif.info/) \-- superseded by FUIF

[1]
[https://cloudinary.com/blog/fuif_new_legacy_friendly_image_f...](https://cloudinary.com/blog/fuif_new_legacy_friendly_image_file_format)
\-- FLIF is lossless and amazing, in part absorbed by JPEG XL

[2] [https://github.com/google/pik](https://github.com/google/pik) \- from
Google, got absorbed by JPEG XL

[3]
[https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...](https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs)

------
slx26
Question for people more knowledgeable on the topic: is it reasonable to
expect a future where audio, image and video are easy to work with and
compression / decompression / encoding / decoding is done transparently by the
hardware? Like, an OS read call giving you a standard plain format directly? I
know PS5 is doing something like that for 3d assets, but I wonder how
difficult it would be to do this and just spare the rest of humanity from
having to suffer with formats for the rest of our lives. Or would there be too
many cons?

~~~
rasz
It has been said PS5 uses Kraken. If its this
[http://www.radgametools.com/oodlekraken.htm](http://www.radgametools.com/oodlekraken.htm)
then nothing really changes. PS4 games use RAD Kraken today. Texture assets
themselves have standardized long time ago, currently on the desktop we are at
[http://www.reedbeta.com/blog/understanding-bcn-texture-
compr...](http://www.reedbeta.com/blog/understanding-bcn-texture-compression-
formats/) with history going all the way back to 1990 patents for Apple Video
'road pizza' codec, later ripped off by S3 and re-patented as S3TC texture
compression in 1997.

------
devwastaken
Av1 images are way better, and you can already do them in Firefox with a video
with 1 frame in it. It's a shame it hasn't been adopted as a singular format
yet

~~~
andrius4669
>It's a shame it hasn't been adopted as a singular format yet

it has been. look up avif, you can already sorta try it out on firefox nighty.

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

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

~~~
tracker1
IIRC WebP is open-source and unencumbered by patents so there's no reason it
couldn't be implemented. That said, it's not a good source format.

------
kn8
In my experience, when building websites, webp has always been smaller thus
far.

For anyone interested and building sites with Next.js, I've released a plugin
for optimizing images and converting to webp with fallback to jpg/png:
[https://github.com/humaans/next-img/](https://github.com/humaans/next-img/)

------
adityapatadia
ASK HN: Since this discussion has come up, I would like to ask HN if you are
interested for an in-depth comparison on a production workload.

I run this [https://www.gumlet.com](https://www.gumlet.com) which serves more
than 50M images per day. We can put entire study on different image formats if
HN finds it helpful. Please let us know.

~~~
Reubend
Yes, I'm personally quite interested. Although more for my own curiosity than
any business use case.

------
nisten
What really sucks about all this is that they're actually ruining the
credibility of lighthouse audits this way; what has been for years the best
all-in-one automated performance+accessibility analysis tool for any web
app/site and is now being used to promote some random new image format no one
wants to care about.

You spend all this time improving your stack, reducing your app bundle size,
convincing your company on the benefits of server side rendering, improving
your devops, getting your manager to see these measurable benefits by running
lighthouse audits themselves etc...

Then all of a sudden it turns out that the main tool you used for this has
been turned into a.. a f __king ad platform.

I apoligise for this emotionally charged rant, but seriously though, is that
how you plan on getting developers adopt your dubious new standard, by p*ssing
them off?

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

[1] [https://portabella.io](https://portabella.io)

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

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

------
anaisbetts
If you're writing an Electron app, using WebP/WebM is a Free space
optimization, especially in lossless mode for GIFs or sprite maps. You can
also make really beautiful, 60FPS animations with WebM that are as easy to use
as GIF

------
dubcanada
This is a weird comparison, while I get the comparison of non-transparent
images jpeg or webp are probably fine.

However the main benefit of webp is alpha backgrounds or transparency. It can
destroy PNG when it comes to compression and size.

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

------
ache7
JPEG quality can probably be better (but slower) when using sophisticated
decoder libraries. This way, a JPEG image with a WebP size may look with the
same quality. But I didn't test.

[https://news.ycombinator.com/item?id=22245788](https://news.ycombinator.com/item?id=22245788)

Also, Google has a "brunsli" library, that can recompress JPEG to JPEG XL
format without loss.

[https://google.github.io/brunsli/](https://google.github.io/brunsli/)

------
MayeulC
> Only concern I have is the excessive blurring of low detail areas?

Couldn't the person who picks the compression ratio tell the encoder which
part of the image is important? And even have it done automatically to some
extent. If you are going to send a 5MB picture from a person at their birthday
party, if feels worth it to spend a few more bits on that person than its
surroundings.

Extrapolating to smartphone pictures where you generally select a focus area
(and sometimes selectively blur the rest), they could use that information to
keep more bits of information in this area.

------
phillipseamore
The software versions are never mentioned and since the article says "cwebp
only supports TGA input" I suspect that's a very old build of cwebp.

------
mindfulplay
Two major advantages: transparency and optional lossless. JPEG blocky
artifacts are very hard to remove for high resolution images unless you hand
tune them.

------
mikece
An implicit assumption is that "smaller file size is better" and if this
discussion were about audio would probably be mp3 vs ogg vorbis... but flac is
the BEST to em because I want all of the audio data in the best lossless
compression scheme. As a photographer, I would like to have ALL of my image
data in a losslessly compressed format as well. What is the FLAC equivalent in
the photo/image space?

~~~
NikolaNovak
TIFF, I believe?
[https://en.wikipedia.org/wiki/TIFF](https://en.wikipedia.org/wiki/TIFF)

~~~
sigio
There are lossless versions of PNG, BPF and there is also a lossless JPEG
enhancement.

~~~
mceachen
PNG is always a lossless format. You can only control the level of
compression.

There are tools that let you re-encode a PNG after applying a lossy filter,
but the PNG still encodes it losslessly.

------
robbrown451
Regardless of whether it is better, I sure wish Macs would support them
natively, such as in Preview and Finder. Really annoying that if you save an
image from the web they aren't as usable as pngs and jpegs. Now, I typically
save it locally, see it's a webP, then go back and screenshot it so it is a
PNG. (and then find it on my desktop, rename it, move it where I want it to
be, etc)

------
aliceryhl
You can make a lossless webp from a png. I use this on my site, and it
consistently results in smaller images than what I get from png.

------
nyanpasu64
As an observer of video codec development, I heard Daala (PVQ) used activity
masking to make quantization steps finer (don't discard all detail) in low-
contrast areas. I don't know if that's practical in AV1 (a DCT block-based
codec).

------
maxk42
Another reason to prefer MozJPEG to webp is that Safari and Edge don't support
webp yet. [1] Although it looks like that's changing very soon for Safari.

1: [https://caniuse.com/#feat=webp](https://caniuse.com/#feat=webp)

------
jpambrun
These numbers need decompression computational complexity for completeness. I
am not better off if I save 1ms downloading, but it takes 5-10 more ms
decoding. Bandwidths in the 100s Mbps are common now..

~~~
flowerbeater
Not for me. I'm in the United States in an urban area and mobile data is 1
cent per megabyte (my provider is Google Fi). Decoding is nearly pretty fast
for me, but the time for page elements to download is in the _seconds_ (not
even milliseconds). And if there's any low signal (wifi or mobile data), then
over 10 seconds is not uncommon.

------
Animats
It's all about Google wanting control. Their own file formats, their own
protocols, AMP, not showing URLs in Chrome. The goal is to turn the web into a
closed Google ecosystem.

~~~
jonsneyers
How does a royalty-free codec with an open source implementation turn the web
into a closed ecosystem?

Not that I trust Google, but in this case I don't see the harm.

~~~
Animats
_How does a royalty-free codec with an open source implementation turn the web
into a closed ecosystem?_

Google did it with Android. It's "open source", but try to do something
without Google Play Services.

------
snoo5780
Does anyone have insight as to whether this same evaluation re:AVIF applies to
WebM?

Edit: saw somewhere that it is used in production for real-time video, but had
trouble using rav1e as opposed to libvpx

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

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

------
throw0101a
I'm more interested in hearing about support for AV1.

* [https://en.wikipedia.org/wiki/AV1](https://en.wikipedia.org/wiki/AV1)

~~~
masklinn
AVIF is in the comparison, and the article notes it's in Firefox (behind a
flag) and ought be coming to Chrome soon.

------
xvilka
Of course. JPEG doesn't support transparency and animation.

------
unnouinceput
Summary: - No. It's roughly the same.

Mandatory Google bash comment: - It's mainly another wheel reinvention from
Google, because reasons.

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

~~~
unnouinceput
*pity

------
whatsmyusername
We have too many different formats! Let's make a new standard!

 _2 years later_

We have too many different formats! Let's make a new standard!

 _shrug_

------
cosmojg
I can't wait for AV1 and AVIF to take over the world. We've needed better
formats for awhile now.

------
xmichael0
Does anyone know of a comparison that looks at the encoding and decoding times
/ cpu requirements?

------
smallstepforman
We use WebP for a number of reasons:

\- supports lossless

\- supports alpha

\- excellent decode speed

\- open business friendly license

In essence, it eliminates PNG.

------
lowmemcpu
I'm using Firefox and just tried to save a webp image and it tried to save as
a web page. [initially, I said no.. see edit below]

Edit: Looks like it was that specific website and they are doing something
odd, so I retract my initial judgement.

~~~
discreditable
Is that server sending the image with the correct mimetype?

~~~
lowmemcpu
Good point! I just went back and checked that specific site, and they are
definitely doing something odd. I retract my previous judgement

------
trekrich
bad enough that google are pushing AMP, let alone trying to take over the webs
image formats as well. No more Google!

------
kome
tl;dr: it's not.

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.

------
buboard
chrome keeps changing downloaded images to webP which is annoyin af. can't
even find a way to disable it

~~~
crazygringo
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".

~~~
slipheen
There's an extension you can use to save it as a different format, but it's
transcoding.

[https://chrome.google.com/webstore/detail/save-image-as-
type...](https://chrome.google.com/webstore/detail/save-image-as-
type/gabfmnliflodkdafenbcpjdlppllnemd)

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.

------
ocdtrekkie
WebP would never have been adopted and nobody would care about it if it wasn't
developed by the owner of the world's largest browser and the world's largest
website (which ranks everyone else based in part on what formats and
conventions they use), who has the ability to implement it on both sides, and
force everyone to care.

WebP is a blatant example of how monopoly power is used to push bad things
upon everyone else, and as seen here, for literally no good technical reason.

