Hacker News Reader

Comment by kllrnohj | Hacker News Reader

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

View on HN

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

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

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.

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

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.

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.

Reply on news.ycombinator.com