Live data from Hacker News

It's the future – you can stop using JPEGs

daniel.do

41–50 of 61 posts

Re: It's the future – you can stop using JPEGs

#41
post #37

> In fairness, it wasn’t practical to use even with a fallback until around 2015 and only became usable without a fallback in the last 2-3 (ish?) years. And because of that school of thought, about 20% of all sites I visit are currently broken for me. I'm still on macOS Catalina, which is the last somewhat bearable version of macOS, but which has no webp support in Safari. Even pages which pretend to specify JPG fall…

Also most image processing sites (like google translate) don't support webp upload.

Just sayin...

Re: It's the future – you can stop using JPEGs

#42
post #35
post #14

The non-browser support of WebP is just bad. I hate website using WebP, because, when I save them, I have a hard time editing them.

Seconding this. It feels like every other day I download an image, realize it's WebP and start bashing my head against the desk because it means opening it in GIMP to convert it to JPEG once again . I've got several hundreds of GB of unused SSD storage, and I'm downloading it over a 1Gbps connection. Honestly, I really could not care less about those 150KB I'm saving.

> I've got several hundreds of GB of unused SSD storage, and I'm downloading it over a 1Gbps connection.

It's helpful to remember that many people have far worse setups.

Re: It's the future – you can stop using JPEGs

#43

Earlier quoted context omitted.

https://caniuse.com/avif - 87% penetration. JpegXL have about zero (actually 5% - safari). So, in practice, you can't use it

But it has a great advantage: it is not made by Google (which also is probably the reason why it is not adopted too widely). I am trying to minimize using things originating from Google.

A bad news for you; it was made by Google, partly (Google Zurich and Cloudinary). It wasn't adopted probably because it didn't originate from the Google Chrome team.

Re: It's the future – you can stop using JPEGs

#44

I encourage everyone to click the images and zoom in on them. The test itself is pretty flawed since the images probably all came from the jpeg in the first place (and if they didn't, then that's pretty damning to the non-jpeg options, in my opinion). The place I found the most interesting is the dark, top of the screen. Zoomed to 240% and looking at the top area, especially where the power lines are going across, th…

Well, there are many things at play here... JPEG leaves it to the codec author to interpret the compressed information. You can get different JPEG implementations that will result in visually different images (on screen) when displaying the same file. Some JPEG viewers will even allow you to control some of the parameters of the render (typically, the amount of blur and the size of the "swatch" with which the blur is applied).

This is less noticeable with stills, but it's a special form of art / a matter of professional pride for teams working on video codecs: how to make pictures produced from the same file look "better".

Similarly for compression. It's far from given that two different JPEG implementations will create byte-for-byte identical files given raw image input and all the same compression settings. There's special art in figuring out what parts of the picture will compress better, what parts can use wider "swatches" etc.

It's also true that different codecs can perform better on different kinds of pictures either in the sense of producing smaller files or in the sense of producing more visually appealing picture. So, anyone trying to establish the behavior of compression of competing codecs needs to try this on a carefully selected set of images which need to include images with high and low brightness, sharp and blurred images, pastel colors and neon glow as well as pictures of things we are often interested in seeing s.a. portraits or medical images etc.

There won't be usually an all-winning codec.

Also, as for the images compared in OP: does OP know if there's any metadata written into those images? I mean, the answer can be as simple as discovering that JPEG images included a thumbnail in the image, and then all that measuring would be worthless...

Re: It's the future – you can stop using JPEGs

#46
post #37

> In fairness, it wasn’t practical to use even with a fallback until around 2015 and only became usable without a fallback in the last 2-3 (ish?) years. And because of that school of thought, about 20% of all sites I visit are currently broken for me. I'm still on macOS Catalina, which is the last somewhat bearable version of macOS, but which has no webp support in Safari. Even pages which pretend to specify JPG fall…

That sounds self-imposed. Why are you using safari when it's version is locked to your outdated OS? Current Firefox works on catalina.

Re: It's the future – you can stop using JPEGs

#47
webp is perfect for serving images but not perfect as a source. jpeg at 100% quality is less lossy than webp lossy version. webp lossless is fine, but then not very small. taking photos at 100% jpeg can be a good middle ground for that reason, unless you really dont care about the quality.

Re: It's the future – you can stop using JPEGs

#48
post #37

> In fairness, it wasn’t practical to use even with a fallback until around 2015 and only became usable without a fallback in the last 2-3 (ish?) years. And because of that school of thought, about 20% of all sites I visit are currently broken for me. I'm still on macOS Catalina, which is the last somewhat bearable version of macOS, but which has no webp support in Safari. Even pages which pretend to specify JPG fall…

And sometimes some image CDNs seem to have been configured such as to ignore an explicit request for JPEG via their image format parameter (you can change it to all sorts of different formats that then actually get delivered, only jpeg stubbornly continues to return a webp image (!)) unless you also spoof the user agent to some older browser.

Re: It's the future – you can stop using JPEGs

#49
> An overview of some compelling alternatives.

The story lost me at the subtitle--I'll wait until there's one. Seriously though if a very large part of your company's cost or user experience depends on efficiently rendering quality images, then this should be on your reading list.

For the vast majority, choosing the nearly-right image dimensions and compression level is probably going to do a lot more than choosing any format over jpeg.

Re: It's the future – you can stop using JPEGs

#50
post #14

The non-browser support of WebP is just bad. I hate website using WebP, because, when I save them, I have a hard time editing them.

I tried to use it for a screenshot in a README on GitHub, and raw.gitusercontent.com couldn't serve the right MIME type. I was surprised. PNG it is, then.

So not only browser support, but server support. (Which is really easy to support.)

Post reply on HN