Hacker News Reader

Comment by gruturo | Hacker News Reader

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

View on HN

You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.

If transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.

clearly we need to dig in past work to find who tried that

Flash could do it

How? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably.

In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.

All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it?

And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.

You don't have 15 year old binaries linking against an 18 year old version of libwebp.

No; you just have no compatibility whatsoever.

It's not too unreasonable to assume that a given ancient program would have logic to differentiate between "This is a jpg and I know what to do with it" and "this is a something else and I don't know what to do with it" so it will technically handle webp images safely while it may not safely handle something that claims to be a jpg but apparently is not.

> In a theoretical world where transparency got added to JPEG

It's not theoretical. It's the JPEG XT spec. It adds alpha channel and HDR to standard JPEG in a backwards-compatible manner.

You offer two versions:

* A webp version with transparency, which won't be supported by most clients but the ones which do will support everything

* A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality.

That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.

Because JPEG 2000 was essentially a patent-covered mess that nobody wanted to touch

Shouldn't those patents be expiring soon?

Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.

It’s too compute intensive

That's kind of scary for something developed in the 90s. It was originally run on Pentiums, K6s, PPC 604s, and the like and it's still too expensive for a Ryzen 7?

Images got bigger... it’s not that it’s too expensive it’s just way more expensive that good enough alternatives. There are other reasons too but that’s a surprising one

Yep. There's a ton of data dependencies, where e.g. you can't begin decoding the next bit until you've finished decoding the current bit. It's all about progressive decoding so there's multiple passes over each group of wavelet coefficients, accessed in a data-dependent sequence. Each wavelet transform involves accessing and interleaving the same 2D arrays in both row- and column-oriented fashions.

These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.

> These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.

Arguably not a good choice for the year 2000, either, considering that all high performance CPUs at that time were out-of-order, superscalar and deeply pipelined.

No.

AFAIK it's pretty standard in DCP files for Digital Cinema.

webp was around since 2010 and has google's backing. Microsoft tried their own thing (Jpeg XR; 2009) and the actual JPEG committee announced their work Jpeg XL (with google backing) a while ago, while Apple switched to HEIC/HEIF as of 2017 (HEIC is like webp just based on HEVC aka H.265 instead of vp8 i-frames; and it's a patent mess of course).

There is simply no reason why people in 2016 or now would be interested in a format from 2000 that was a patent minefield until at least 2016.

Except for JPEG the alternatives are also patent minefields...

Are people just more cavalier about the patent risk these days? The problem with JPEG2000 wasn't the patents we knew about, it was the possibility of submarine patents. People were still wary after the GIF debacle. Nobody wanted to be charged $0.05/image after the fact when they've delivered literally billions of images. Plus the courts were seen as very favorable towards patent holders, even when they were acting in bad faith.

That was a little of it but the patents expired years ago. The big blockers I saw were basically that it was a very complex format with a specification behind a paywall and no good open-source implementation or test suite. Interoperability was bad until a couple of years ago and it took significant amounts of complex code to make it fast enough to use.

They've subsequently improved that — OpenJPEG is quite good now https://github.com/uclouvain/openjpeg — but probably missed the window for adoption barring a major upset, which is a shame because it's a very powerful codec and has some neat tricks like progressive decoding (imagine if you could have one file in storage and your responsive design simplify specified the HTTP range requests to get for successively large resolution images?). You could ship it in a browser using WASM but I think the browsers are — not without cause — being really reluctant to add new formats and the ensuing security risks without a good reason, and without browser support no format will be more than a niche.

On the web you can do it with SVG.

https://github.com/leni536/trans_jpg

That is really cool. I had never thought about (ab)using SVG in that way.

SVG is such an underappreciated technology that is in every browser. Why do icon fonts exist when you could just use SVGs just like you do PNGs and JPEGs? You can even inline them in your HTML so there isn't an additional HTTP request if you want.

Wouldn't it probably be one request per icon instead of just one request for a while font?

Not necessarily. You can have a single SVG file with multiple 'defs' that you can reference around the page, or just embed the SVG code in the HTML itself (via a templating language) if you're not using too many.

Great idea, I love 'thinking outside the box' solutions, but doesn't seem to work on Firefox mobile. (Perhaps it's just me.)

In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.

Every iOS and macOS device supports JPEG 2000… that should be pretty meaningful.

Chrome and Firefox don't.

That accounts for significantly less than half the whole market, and half the mobile and desktop markets if you split it out. If it's also supported by other OS's and headsets and browsers that bring it significantly closer to 100%, then maybe we have something meaningful.

Well, 2 billion devices is a meaningful number of devices, no matter how you slice it.

That's entirely dependent on context. In the context of "can I use this and expect it to work most the time" it's nowhere close enough. All that matters in that respect is percentage of the whole, and at less than half, it's not really much.

As an example, we could talk about the number of connected IoT devices that are supported and up to date, and it's probably in the billions. But compared to the number of connected out of date and unsupported devices, it's likely inconsequential in comparison by metrics of total numbers, percentage of a whole, and importance (alternatively, total number of unsupported and possible exploitable devices does matter, because of what it implies about how they can be used destructively).

Is there still some licensing issues with jpeg 2000?

I did some proof-of-concepts ages ago (October 2010) exploring different ways of embedding a PNG alpha channel in JPEG application specific fields to have 100% JPEG compliant files which web browsers could display with transparency. It worked just fine.

If you want transparent JPEGs on your web page that works.

Back then the number of GETs was really important, so stuffing the mask into the JPEG made sense. Now with our HTTP/3 and QUIC world that isn't such a big deal.You might be better off just using a CSS mask image.

I think the idea is "if you're going to break compatibility, might as well make all the improvements at once".

WebP also supports animation, which is important because GIFs are notoriously large.

Also, gif only supports one-bit transparency; Whereas webp and png allow partial/gradated transparency.

Animations should just be videos. No reason for an animated image format, an animated image is just a video with no audio track.

My understanding is that webp is video. That is, it's a still frame using the vp8 codec.

As far as I can tell though, it has to be VP8 and can't be VP9. Maybe I'm mistaken about that, but all the webp literature I've read or skimmed talks about VP8 specifically. So what's the advantage of an animated webp using VP8 over a webm using VP9?

It only has VP8's intraframe compression, not VP8's interframe compression, so animated WebP is not a proper video codec and is a different beast to WebM video.

An animated WebP is basically a WebM video.

Or let me rephrase, why is WebP as a animated picture / video format insufficient?

video format usually take up too much memory: what you gain in efficiency costs in resources. Conversely, animated WebP are dirt cheap: one buffer only, written over and over.

Then, there's optim being made in WebP to allow fast jump to keyframe, even when there's transparency. Video codec don't allow that, and you can have an arbitrary long torture sequence of transparent frame that needs to be decoded back when the video comes in the view again.

Last, animation are usually low-fps (~10fps): there, video codec don't perform very well and are basically keyframes. So the difference isn't as great as one would think.

Oh, and hardware need a 'reset' between decoding tasks, to reconfigure memory, and decoding can't be parallelized.

Eh. An animated image (an image that contains some sort of video media, whether gif or h264 or whatever) is a hint to the browser to play it automatically and without sound. If everything were true video (say, mp4) you couldn’t make that distinction. As long as the video in the animated video is encoded properly — as real video and not a sequence of frames as gif does — then animated images definitely have their places.

> An animated image (an image that contains some sort of video media, whether gif or h264 or whatever) is a hint to the browser to play it automatically and without sound. If everything were true video (say, mp4) you couldn’t make that distinction.

<video autoplay muted> says the same thing.

The only advantage I can see it where videos are not allowed to autoplay you would want a gif to play somethig small.

Videos can autoplay on browsers if they are muted

For me is all about sharing. The website itself usually displays the "video" as if it was a gif, but as soon as you go to share anywhere, you're sharing a video on platforms that handle it like a video. No looping, seek controls, complicated UI, etc. I just want to post a photo that auto plays and loops anywhere. I don't are about the internals, but I want all applications to recognize that file as an animated photo, not a video.

No need for image formats either as an image is just a very short single frame video.

I think this a very poor comparison to make because it denies the time dimension of video completely, which fundamentally affects how we perceive and use video, and also ignores the fact that still images linger and have different requirements.

As a point of data, Animated PNG is finally (as of ~2019) supported natively among all major browsers.

https://caniuse.com/#search=animated%20png

Edit- I was unaware the recently-announced Safari 14 Technical Preview adds support for WebP too! Making both formats viable for all browsers, finally.

Ooh, does that mean that slack supports WebP now?

Update: nope. Maybe another year :(

Recently we've been going through the browser stats on our websites, and while globally apparently IE is dying, it's certainly not dead yet. In the specific industry I work in (Heavy Automotive Retailing, eg Truck Sales and Servicing), we see upwards of 30% of our users on browsers <= IE11. All of our sites are getting poor lighthouse scores on performance with the main suggestion to be changing to webp, but that would exclude 30% of our customers.

There is a way to offer both jpg and webp, letting the browser to choose.

WebM (despite being closely related to WebP) can be 5-10x more efficient than WebP.

That's because WebP focused so strongly on being a GIF equivalent that it also dropped all things that made WebM efficient and instead adopted GIF's awfully inefficient architecture (just dumb frames overlaid on top of each other, without motion vectors or predicted frames).

Safari shows how it can be done: it supports silent MP4/H.264 straight in <img>. You get all the ease of use GIF, order of magnitude smaller file, and hardware acceleration.

It's unintuitive, but well-compressed videos are cheaper to decode than dumb "animation" formats, because file size differences are so massive that it's cheaper to decompress a small amount of complex data than to chew through vast amounts of poorly compressed data.

There's also the practical matter of network speed. In many common scenarios a 300kb webm can be fully downloaded and playing while a roughly equivalent 5mb gif is paused a few frames in, buffering.

Also video decoding is cheaper because most GPU/SoCs supports hardware decoding.

This isn't a good assumption to make, many people own cheap phones that lack hardware codecs that can decode videos with modern encodings.

I can't imagine any cheap SoC for smartphones without H.264 HW decoder because playing video is essential and it can record video. Possibly exists for low-feature phones without camera but it's not for web browsing.

The licenses for codecs sometimes cut into the thin margins on budget phones. A large amount of people outside of the US and EU are stuck on low-end phones, and I'm pretty sure many of the government subsidized phones in the US are in the same boat.

Do people really use Safari?

Lots of folks using Mobile Safari.

Yes, lots of them... on iOS.

Also worth noting that all the alternative browsers on iOS are just reskinned versions of Safari as well.

Somewhere between 25 and 50% globally based on your audience.

>JPEG can't do transparency

JPEG "can't" do depth maps either, and yet it manages to do them just fine.

"Portrait mode" on Android is simply JPEG + greyscale JPEG embedded in metadata.

If anyone really wanted transparency, it is very easy to add it to JPEG.

That said, in practice, transparency is not needed in non-vector / non-generated graphics formats. The nature doesn't really have an alpha channel, photographs certainly do not.

Transparency is extra information, and can be passed along as such.

The problem is always standards. I want transparency to work correctly everywhere, not just in one application and broken everywhere else.

Even if transparency was add to JPEG right now, it would take sometime to become available everywhere, and you would have tons of legacy devices showing broken transparency.

The advantage of a new format that supports transparency from is interception is that every device that is compatible with it will display it correctly. So there is no issue with some devices supporting the format partially.

The larger picture is that you can use PNG or SVG anywhere you need transparency, which are also better suited for the content that has transparency.

JPEG is optimized for photos, which don't have transparent parts.

SVG and PNG are optimized for graphics.

So, if you need transparency, WEBP is probably not the format you'd choose anyway.

> The larger picture is that you can use PNG or SVG anywhere you need transparency, which are also better suited for the content that has transparency.

It is pretty common to have anime characters where you remove the background to use as reactions, and while you can use PNG in those cases it makes the images huge. WebP makes it ideal for those cases, this is even the case that I saw this being used in some image boards (specially also including animation, another thing that is popular).

Just because you can't think in a use case there isn't mean that there isn't a use case.

Do you though? The transparent png use case is largely being replaced by svg.

There are some situations where transparency is legitimately needed but im not sold it can justify webp and all that comes with it.

vector graphics and raster graphics aren't really comparable.

Why not?

They display an image. Bit if a weak argument to say they dont matter when theyre being used to create the same final outcome.

How would you show a photographed image as a svg? Either you would have to "vectorize" the image which would look totally different or you'd create a grid of vectors with different hue values, ultimately representing pixels in an extremely inefficient format.

Raster graphics and vector graphics can't be compared because sure, you could create 2 million vector squares with individual positions, sizes and colors and align it into a 16:9 grid or you could just use a jpg. The latter being a fraction of the size and processing power needed to display it.

Why would you show a photograph as an svg? You wouldnt. Thats what jpegs are for.

We're discussing transparency and the use case for it. I dont think ive ever heard of someone wanting transparency in a photo. The only times i see the need is if theyre doing something that is better off in a vector format. I.e. png, which is being supplanted by svg, which alleviates the size problems raised about pngs.

I.e. webp is a format solution in search of a problem.

Downvoted, wow, petty.

>I dont think ive ever heard of someone wanting transparency in a photo.

OK, but they do. It's pretty common for someone to cut out an object in a photo and have a transparent background.

And that is the reason why I dont like Open Media Alliance in General.

Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead.

[1]https://github.com/google/brunsli

Absolutely. Simply unscrewing the Huffman stage from the bottom of JPEG and replacing it with a more effective, modern lossless stage kills webp's gains and does not incur in generation loss - the image is pixel accurate to the source jpeg.

You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!

JPEG XL uses this new ANS coding as e.g. zstd: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems

What has AOMedia to do with this? That alliance is what has made AV1 (and thus AVIF), which is clearly superior to JPEG. AOMedia had nothing to do with WebP (though Google is a member, and WebP is based on VP8, and AV1 is based in part on VP9 which was the successor to VP8).

Is it better? The AVIF examples in the article look even worse than the WebP ones

At 30% reduced size. The true comparison would be at the same file size, which format is able to squeeze more perceivable information into the same bucket?

Indeed. The article's comparisons seem a bit useless - neither the quality or the filesize is kept constant.

Do you mean the Alliance for Open Media? WebP was created solely by Google years about AOM was founded.

I thought the JPEG people were supposed to have JPEG XL [1] out by now, and it was supposed to be the open standard for JPEG's next generation. Anyone know what's happening there?

[1] https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Gro...

Yes, here's an update: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...

TL;DR: We're now at "Draft International Standard" stage; soon we'll enter "Final Draft International Standard" stage and at that point the bitstream is effectively frozen and adoption can start. The officially ISO-published International Standard will take until first half of 2021, but the codec should be ready to use before that.

It's the same situation with VP9. It's supposed to be a competitor to HEVC, but in reality lack of serious psychovisual optimizations in any of the publicly available encoders make it at best on par with x264 compression-wise, while being significantly more computationally expensive.

Its only appeal is that it's royalty-free, but since all devices that support VP9 decoding also support h.264, is it really worth it?

Using VP9 recently has really made me appreciate how great x264 is both in terms of quality and speed.

The quality of encoders have a much bigger effect on whether or not a codec is 'good' or not. LAME, mozjpeg, and x264 are great examples.

MP3 is competitive with AAC and far more compatible, if you use LAME. Same with JPEG and WebP, or x264 and VP9. All 3 of those encoders deliver higher quality AND better encoding speed than their competitors.

Switch encoders before you switch formats.

You are comparing an encoder (x264) with a format (VP9). While there is a reference encoder for VP9 (libvpx). x264 has been one of the most heavily optimized encoders whose development was sponsored by many different organizations, whereas libvpx did not see the same kind of love and most of the work came from Google's employees (with some from outside, I'm sure).

There exist other VP9 encoders, but all for specialized purposes.

> x264 has been one of the most heavily optimized encoders whose development was sponsored by many different organizations

No, it did not.

> whereas libvpx did not see the same kind of love and most of the work came from Google's employees.

You're getting your facts wrong: x264 was developed by a very small open source community, with at most 5 developers on it, on their free time, while libvpx got quite a few people from Chrome Media Team paid to work for years on it.

What’s interesting is that Google’s Lighthouse tool for measuring site speed pushes for “Next Gen” image formats like WebP. But I often find that WebP files are larger than jpg, too. Yet Lighthouse recommends it. And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm.

> And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm.

AFAIK they don't? They use some of the metrics which are provided in Lighthouse (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) all play a role in ranking, but the score itself is meaningless.

You're both wrong, but you're only slightly wrong. It's been announced that those metrics will contribute to ranking in the bear future. Search for Core Web Vitals.

You are, of course, technically correct, which is the best type of correct.

There's been some level of performance weighting for a while (but only very slight and mobile-only), but I don't actually know what metric they were using for that (this was from ~2018, before any of those metrics landed in Blink).

The irony is that the Lighthouse site itself scores really badly! Can you accept its advice?

Idk. I optimized the end-user facing part of my website heavily, while the backend part (which is used only by a few people), I don't really care. I didn't even minify the JS.

And then there's times I want to save an image, and can't convince the web site to give me a jpeg, so I have to convert it again.

> Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling.

Could you share your comparisons? From the ones I've seen, it looks like WebP significantly outperforms JPEG encoders[0].

[0]: https://wyohknott.github.io/image-formats-comparison/#endeav...

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

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

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

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

PNG already exists.

The answer is simple: money

If you can get one then you can get the other, for any compression format that allows varying compression ratios.

Because the files already looked fine for the most part. Assuming the JPEG is sensibly encoded the human eye probably won't be able to detect the quality improvements in a different algorithm.

So the only place they can target is where JPEG starts to break down: When you've cranked the quality knob down to 20 and you're seeing macroblocks and other artifacts in the image. But this is a niche use case as network speeds continue to improve every year.

The worst part is that they have to compete with free, and that's never easy, especially if you're talking about "well, it's still distorted, but the distortion is less displeasing to the eye", also you need to configure some pain in the ass licensing system and work out how to do the payments.

Part of it is about quality. These new formats now support 10+ bit color depth (which is critical for modern displays and for HDR) and full 4:4:4 chroma subsampling (to preserve pixel-level as needed). Many apps/services are currently evaluating or already migrating to AVIF or HEIC because these formats unlock those improvements in image quality, even without a major reduction in file size.

Reply on news.ycombinator.com