undefined | Better HN

0 pointsgardaani6y ago0 comments

I hope that JPEG XL will be simpler than the competitors. If it's compression ratio is similar to AVIF and it can do HDR, then I'll all for it!

AVIF (and its image sequences) seems to be fairly complicated. Here's few comments [1] about it:

"Given all that I'm also beginning to understand why some folks want something simpler like webp2 :)"

"Despite authoring libavif (library, not the standard) and being a big fan of the AV1 codec, I do occasionally find HEIF/AVIF as a format to be a bit "it can do anything!", which is likely to lead to huge or fragmented/incomplete implementations."

Anyway, instead of adding FLIF, AVIF, BPG, and lots of similar image formats to web browsers, I think only one good format is enough and JPEG XR might be it. After something has been added to web browsers, it can't be removed.

Safari hasn't added support for WebP (which is good, there's no need for WebP after AVIF/JPEG XR is out) and it hasn't added support for HEIF (which is weird, considering Apple is using it on iOS), but maybe they know that there's no need to rush.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=960620...

0 comments

sk655356y ago

WebP version 2 is in the work at AOM: https://www.youtube.com/watch?v=zogxpP2lm-o

It is complementary to AVIF (which targets photo capture more than delivery over the web).

WebP2 is like WebP: keep it simple, with only useful and efficient features, no fancy stuff. And aim at very low bitrate, it's the current trend, favoring image size over pristine quality.

Progressive rendering uses ~3x more resources on client side. So, instead, better have efficient 300-bytes thumbnails in the header.

ksec6y ago

>I think only one good format is enough and JPEG XR might be it.

I think you meant JPEG XL here? JPEG XR [1] is a completely different thing.

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

jhabdas6y ago

Browsers don't need the codecs anyway. They just need Wasm and a decoder. Clients can do the work[1] until the hardware supports the goods.

[1] https://git.habd.as/comfusion/fractal-forest/src/branch/mast...

bscphil6y ago

The example you linked to is pretty telling, because not only do the BPG images decode more slowly than natively supported images, the javascript decoding approach apparently breaks the browser's (Firefox's) color management. I think native support is needed for newer codecs to be viable for more than simple demos.

spider-mario6y ago

Chrome appears to interpret the canvas as sRGB and to convert from that, but that means that images decoded that way are effectively limited to sRGB until the canvas API allows specifying other colorspaces.

1 more reply

j / k navigate · click thread line to collapse