What does HackerNews think of jxl.js?

Chrome: Heap buffer overflow in WebP | Sep 2023

Expand Context ↕

You can use WASM for image codecs, like my JPEG XL decoder: https://github.com/niutech/jxl.js

There is also WebCodecs API: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

Chrome: Heap buffer overflow in WebP | Sep 2023

Expand Context ↕

My JPEG XL decoder uses WASM: https://github.com/niutech/jxl.js

Apple Safari 17 beta release notes: JPEG XL support added | Jun 2023

Expand Context ↕

> If you care about JXL, and only want to support JXL, and you put a JXL in your picture tag, then the browser still won't render it, even if you use a picture tag.

Is this true if you provide a polyfill? Have you tried it and it failed? (Serious question.)

https://github.com/niutech/jxl.js

Apple Safari 17 beta release notes: JPEG XL support added | Jun 2023

Expand Context ↕

In the meantime you can use a polyfill: https://github.com/niutech/jxl.js

Chrome still hasn't changed its opinion about dropping JPEG XL support | Jun 2023

Expand Context ↕

and here's one: https://github.com/niutech/jxl.js

FSF Slams Google over Dropping JPEG-XL in Chrome | Apr 2023

All of the people here who are so passionate about JPEG-XL will be happy to learn that there's nothing preventing them from using it on their sites right now:

https://github.com/niutech/jxl.js

If you want Chrome to ship with JPEG-XL support, use it. At some point, browser makers will decide it's worth the incremental cost (to them and all users) to add it.

Nvenc vs. QSV: Who Has the Best Hardware AV1 Encoder? | Apr 2023

> Please be aware that some images may not load on this page unless your browser supports JPEG-XL

The site could provide a WebAssembly decoder to make the JPEG-XL images work for everyone.

For example, here's a WebAssembly decoder: https://github.com/niutech/jxl.js

Demo: https://niutech.github.io/jxl.js/

JPEG XL vs. AVIF: A Comparison | Mar 2023

Expand Context ↕

By implementing the decoder in WebAssembly. It'd be lower performance than native decoding but probably not that bad.

Here's one: https://github.com/niutech/jxl.js

Demo: https://niutech.github.io/jxl.js/

Libjxl's own WASM build: https://github.com/libjxl/libjxl/tree/main/tools/wasm_demo

JPEG XL support has officially been removed from Chromium | Dec 2022

Expand Context ↕

Have a look at WASM decoder JXL.js: https://github.com/niutech/jxl.js

JPEG XL support has officially been removed from Chromium | Dec 2022

Expand Context ↕

My comment was apparently too concise to give you a sense of complications. I can think of those concrete problems:

- Rendering images from a different origin without CORS. This is a fundamental limitation of any JS or WebAssembly solution and can't be fixed. Thankfully this use case is relatively rare.

- Not all approaches can provide a seamless upgrade. For example if you replace all `` with a canvas DOM will be changed and anything expecting the element to be HTMLImageElement will break. Likewise, CSS Painting API [1] (a relevant part of CSS Houdini) requires you to explicitly write `paint(foo)` everywhere. The only seamless solution will be therefore a service worker, but it can't introduce any new image format; it can only convert to natively supported formats. And browsers currently don't have a "raw" image format for this purpose. JXL.js [2] for example had to use JPEG as a delivery format because other formats were too slow, as I've been told.

- It is very hard to check if a certain image is visible or not, and react accordingly. This is what I intended to imply by saying that canvas has to unconditionally retain all pixels, because if implementations can't decide if it's safe to unload images, they can't do so and memory will contain invisible images in the form of canvases. Browsers do have a ground truth and so can safely unload currently invisible images from memory when the memory pressure is high.

[1] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...

[2] https://github.com/niutech/jxl.js