Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

Is there a real distinction? It can be a great format, but if actually using it sucks then in practice it's a pain to use/encounter. (I don't actually have this problem personally - all my apps seem to handle it fine - but the argument seems reasonable.)

View on HN

Yes, it's important to distinguish annoyances of the codec from annoyances of the ecosystem.

Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.

Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF

Perhaps it's a matter of who hits the pain point? Ugly specs make annoyed devs, licensing problems make distributors unhappy, and ecosystem issues leave users unimpressed. (With some spillover between categories, of course.)

> Like HEIC being a license minefield and also slow as shit.

How much slower? I'm finding very conflicting numbers.

But on the timescale of "wow this still doesn't support webp" those patents will solve themselves soon.

hardware-decoded HEIC is around 10x slower than JPEG.

software-decoded HEIC is around 100x slower than JPEG.

WebP is something like 20-50% slower than JPEG, so still solidly an order of magnitude faster than best case hardware-accelerated HEIC decoding.

How slow are we talking though? 10x slower than instant and not noticeable for the average use case? Dog slow and everyone will always notice?

well that depends on the size of the image. But a modern cell phone is shooting 50mp+, and at that size you're talking 50-200ms for a jpeg vs. a couple seconds for HEIC. Which is borderline instant-feeling vs. extremely not instant.

HEVC intra is definitely not 10-20x slower than decoding VP8 intra, so something is way off with your numbers. That's on the order of comparing HM at -O0 against an actual VP8 decoder.

It seems much harder to get an audience as someone complaining about technical details of codecs and their implementations, than as someone complaining about the formats (which in practical terms is always going to mean the ecosystem, or really, how broad the support base is or what the user has to do in order to deal with it).

RIFF is so trivial and has such useful properties that I've done several application-specific binary formats that are RIFF with a different start atom.

RIFF itself is fine, but in the context of webp it's pointless. WebP doesn't make any use of being in a riff container. Like it still internally has its own chunk system anyway. So you end up with a single RIFF chunk for the webp file that itself then can contain multiple, non-RIFF chunks

The current WebP Spec RFC9649 defines the format as effectively:

A 'RIFF' chunk containing formtype 'WEBP' and a mandatory 'VP8 ' or 'VP8L' chunk, and optional 'VP8X', 'ICCP','ANIM', 'ANMF', 'EXIF', 'XMP ' chunks and possibly some unknown chunks, where if any of these optional chunks appear 'VP8X' must be first, and with certain ordering restrictions on the chunks.

It is true that earlier spec versions only allowed the core 'VP8 ' or 'VP8L' chunk, and the spec does warn that some older software might not support files with the newer chunks, so they should only be used if really needed for best compatibility.

Absolutely there is. If it works seamlessly for potentially endless end users and the burden is only on the singular you… yeah, it’s worth the extra effort on your part.

nah, life is a trade off between developer effort and the result. There is a reason we don't hand code everything in assembly anymore - it just isn't worth it.

cough FFMPEG, cryptography…

So no actually we very much do, because sometimes it is worth it.

sure, but we don't hand-code everything.

No one is suggesting hand coding a bespoke WebP encoder. FFMPEG is an apt comparison. Using FFMPEG can be annoying, the end user benefits are enormous.

well yes, my point was its a trade off...

It matters. The ecosystem by itself could be fixable. But a bad ecosystem could also be a symptom of a bad standard, for example IPv6.

>I don't actually have this problem personally - all my apps seem to handle it fine

I heard this argument against WebP about 3 times, each time I asked people what software exactly do they use that doesn't support WebP, they told me, I checked the support (downloaded the software and opened/edited WebP file), and it did support WebP.

I deemed this "I hate WebP" just a comment bait argument in social networks.

There was a multiple year timespan where webp was being used on websites, but local software (especially image viewers/phone gallery apps) wouldn't render webp. The format's poor reputation is sadly earned.

> I deemed this "I hate WebP" just a comment bait argument in social networks.

Go try adding a webp image to a Google doc and then reconsider your position.

>Go try adding a webp image to a Google doc and then reconsider your position.

Lacking support for WebP or for other common media is a flaw of a specific service.

Many websites accept videos only in mp4 + h264 + aac audio for some reason, while there are many other video formats and codecs which could be used on the web and in general. That doesn't mean the other formats or codecs are worse or annoying.

Ok? You originally said you'd never seen evidence of poor webp compability so you dismissed complaints out of hand. Now you've seen evidence, so you've immediately moved on to a different argument so you can dismiss complaints out of hand.

You have now seen evidence of poor webp compatibility. It exists. The people you said were making it up to bait you into commenting were probably being sincere. That's the entire point of the comment. The end.

I haven't seen missing support of WebP in software I'm using, and also asked people of the software they're using to test it and check for WebP support some months ago.

I was curious because I use WebP pretty extensively for many years, and haven't seen any issues with it.

I don't consider web services to be a software. It's no news that many services don't support wide variety of formats, it's their decision. Missing WebP support is a minor inconvenience compared to other missing features of web services.

The article is about self-hosted website as far as I understand, so it doesn't matter what the external services support or not.

That seems needlessly uncharitable. Isn't the more obvious explanation that they tried using it in a program, hit a failure, cached that result and never retried?

Reply on news.ycombinator.com