Hacker News Reader

Comment by carra | Hacker News Reader

We keep hearing different variants of "webp should take over because now it has good browser support". But that is not nearly enough for an image format to reach widespread adoption.

People want to be able to open the images anywhere (what about watching photos in a smartTV? or an old tablet? what about digital picture frames?). They want to edit the images in any program (what about this FOSS editor? what about the many people stuck in pre-subscription Photoshop versions?).

They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone. I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

View on HN

i don't like working with webp. especially since chrome pushes it on everyting, but googles other tools like slides do not support it. Super annoying, especially since google developed it.

It also doesn't help that most people's experience with webp is force-recompressed versions of images that were originally jpeg. With relatively low quality settings.

I'm not sure people consciously make that association, but you know which association they absolutely do make? The one where google images started using webp at the same time as they were locking it down. At the time, ecosystem support was practically nonexistent, so it functioned as "soft DRM" and among people who know the term "webp" at all that's by far the #1 association.

TIL webp is more than just potato shots that I have to delete off my hard drive once in a while

JPEG XL is better than webp

Anywhere? I would be super happy if I could open them all in all contexts on my desktop computer.

This reminds me of rust: even if rust will be widespread in 10 or 20 years, it will not really displace C++.

Although I need a engineering explanation as to why COBOL is still alive after all those years, because any tech cannot live forever.

> COBOL

Was popular in the 60s in fintech, so banks, ATM:s and related systems went digital using it.

Those systems are still running.

Although you can do a bit of Ship-of-Theseus philosophy on those COBOL systems. After every software component has been rewritten multiple times and every hardware has died and subsequently got replaced, all that's left is the decision to stick with COBOL, not the fact that it's a legacy system built in the 60s.

Can’t live forever?

Latin is still going strong as well as water pipes (oldest being several millenia old).

Hard to predict which innovations remain resilient. The longer they stick around the more ”Lindy-proof” they are.

The explanation for COBOL is not an engineering one, but an economics one: “It’s cheaper to train a programmer to use COBOL than it is to rewrite the codebase in <language>.” (Perhaps LLMs might change the economics here.)

"If it ain't broke, don't fix it" also applies here.

There is also no guarantee that whatever new language you port the COBOL code to won't also be seen as obsolete in a few years. Software developers are a fickle bunch.

Last I checked you couldn't even upload .webp images to GitHub or Telegram. Well, for GitHub you can cheat by renaming it to .png and GitHub's content detection will make it work regardless, but meh.

> But that is not nearly enough for an image format to reach widespread adoption

I use WEBP extensively but WEBP has a major flaw: it can do both lossy and lossless.

That's the most fucktarded thing to ever do for an image compression format. I don't understand the level of confusion and cluelessness that had to happen for such a dumb choice to have been made.

I've got an entire process around determining and classifying WEBP depending on whether they're lossless or lossy. In the past we had JPG our PNG: life was good. Simple. Easy.

Then dumbfucks decided that it made sense to cram both lossy and lossless under the same umbrella.

> They also want to ensure far future access to their precious photos, when formats like JPEG2000 or even WebP might be long gone.

That however shall never be an issue. You can still open, today, old obscure formats from the DOS days. Even custom ones only use by a very select few software back then.

It's not as if we didn't have emulators, converters, etc. and it's all open source.

Opening old WEBP files in the future shall never ever be a problem.

Determining if it's a lossy or lossless WEBP for non-technical users, however... ; )

That however shall never be an issue. You can still open, today, old obscure formats from the DOS days. Even custom ones only use by a very select few software back then.

Certainly not true.

One example: I have many thousands of photos from my Sony digital camera that cannot be opened by any current operating system without installing third-party software.

I'm lucky that the camera also output JPEG versions as it saved, so I'm able to view the JEPG thumbnails, then drag the Sony version into my photo editor of choice.

> In the past we had JPG our PNG: life was good. Simple. Easy.

Except for if you wanted a compressed image with transparency for the web, in which case you had to sacrifice one of those two things or use a different format besides those two.

> Then dumbfucks decided that it made sense to cram both lossy and lossless under the same umbrella.

> I don't understand the level of confusion and cluelessness that had to happen for such a dumb choice to have been made.

Besides many end users not caring which one it is as long as they recognize the file type and can open it, I found a few interesting reasons for having both in the same format from a simple web search. One was the possibility of having a lossy background layer with a lossless foreground layer (particularly in an animation).

JPEG XL also decided to support either lossless or lossy compression, so it wasn't just WebP that decided it made sense.

I am pretty sure webp is supported everywhere nowadays. I think it is just inertia.

It isn't universal, my phone gallery doesn't support webp at all by default and the windows gallery only supports non-animating webp from what I can tell?

My smartphone camera does not output webp and so does my professional Nikon.

As long as these two major sources of pictures stay on JPEG, I will too. Simply because that's all for subjective and completely debatable reasons.

To me what cameras support as an output is irrelevant. On a pro camera you generally use the raw files as a default format. What is important is the formats you can export to / manipulate afterwards for publication/exchange.

To me

Not everyone is you.

When I download a photo to send to my family webp always causes some kind of problem so I end up screenshotting it

Always always always -- and it's often multiple problems, where the filesystem preview generators don't support it or don't support it over a network or the social media used by the other person doesn't support it (often egregiously so, where an unrecognized drop bubbles up to browser scope and blasts the page you were on) or there's a weird problem with a site/app that is supposed to support it, such as it turns into a black box.

Support for webp is still so rough that I have to wonder what one's ecosystem must look like for it to be seamless. Maybe if you are a googler and your phone/computer/browser use entirely google software and ditto for your friends and your friends friends and your spouses? Maybe?

To my knowledge, not even every Google product supports it, but I have not verified support myself.

I blame Google for pushing it, but I also blame every third-party product for not supporting it, when it is mostly free to do so (I'm sure all of them internally use libraries to decode images instead of rolling their own code).

I think it works better in a totally open source ecosystem. I can share webp pics to my daughters via xmpp for example regardless if I am on my smartphone (conversations) or desktop (gajim)

> I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

I don't understand this argument. WebP is an algorithm, not a service. You cannot kill it once it's published.

Fair enough. What I meant by this is that, in the end, most software that decides to add webp support is doing it because of the huge push by Google to do so. But if they suddenly change that push to something else then webp might find itself growing more irrelevant.

I didn't know webp was pushed by Google. They should publicize that fact more so people know to avoid the format entirely.

What Google pushes is in their self interest and has nothing to do with the good of the unwashed masses.

WebP is basically a single i-frame from the WebM video codec, which literally was developed by Google to avoid paying license cost for H.264. For which they had great incentive.

WebP is to WebM what HEIC is to HEVC.

You can argue that using free codecs is a collateral benefit here, even though Google did it for selfish reasons. It is not detrimental to the public or the internet.

JPEG XL is similarly an algorithm that's been published, but Google removed it from their browser and Mozilla followed suit, which effectively killed its usefulness as a web-friendly (and, more generally, usable-anywhere) format.

Some nuance there — it's not dead yet: https://github.com/mozilla/standards-positions/pull/1064

Thanks, do you know the status of said safe decoder?

I do not, sorry.

> the reference decoder, which weighs in at more than 100,000 lines of multithreaded C++.

Wow! I have never written a compression codec implementation, but that's kind of staggering.

Reply on news.ycombinator.com