niutech/jxl.js

JPEG XL decoder in JavaScript using WebAssembly (WASM)

jxl.js's Issues

Why config.imageType = 'jpeg'?

Hello,
I guess this option is there to save space if the cache is enabled, but it's a bit strange, since it's a lossy option.
Maybe it shouldn't be the default, or maybe it should be forced to PNG if config.useCache = false?
Is there any technical reason why JPEG should be used if the cache is disabled?

Support for loading miniatures

I have something like this in my Go website:

<img intrinsicsize="124x70" width="124" height="70" src="/api/uploads/2023/08/1692059893-20230725140644.jxl"/>

I am using the wasm/multi-threaded version of jxl.min.js and I am trying to force it to load a miniature version of the image, but seems like instrinsicsize and width and height are not doing anything. It could be cause of my CSS but I would assume that this would load regardless because insrinsicsize is set.

This would be a killer feature for my site and would save me a ton of extra work in making miniatures etc because the time to decode is a bit long. Takes longer than AVIF to load, I tested with 12 HD size images with JXL it took like 12 secs with caching disabled whereas AVIF was 6 seconds with no caching. If there is any SIMD/optimization work that needs to be done I'm ready to help out on it because to me JXL is a better format all around, it supports miniatures, animations, transparency, I want to use this exclusively but the speed has to be there as well.

I'm testing on Chrome/Firefox I got a Ryzen 7 3700X and 32GB 3000MT/s DDR4 memory. On mobile it's much slower than on my PC.

Mismatched quotes

jxl.js/jxl.js

Line 46 in e92e951

el => (el instanceof HTMLImageElement && el.src.endsWith('.jxl')) || (el instanceof Element && getComputedStyle(el).backgroundImage.endsWith('.jxl")')))

workers never freed?

I haven't actually tried using this, was just browsing the source code and notice it looks like the workers never get terminated. It may be that it isn't an actual issue for some reason I've missed, but I thought I'd comment having noticed. Seems like it could start to be an issue if this was used in a more dynamic context.

firefox?

hello,

the sample page doesn't work in my firefox (version 106 and 107) on Linux mint. On an other computer it's the same. It doesn't work either in brave browser. WASM is activated since this sample page is working for me: https://d2jta7o2zej4pf.cloudfront.net/

The only browser which worked for me was google chrome.

Multi-threaded version doesn't work in Electron

Error Info:

node:internal/worker:187 Uncaught (in promise) Error: The V8 platform used by this instance of Node does not support creating Workers
    at new Worker (node:internal/worker:187:21)
    at Object.allocateUnusedWorker (jxl_decoder_simd.min.js:1:15239)
    at Object.initMainThreadBlock (jxl_decoder_simd.min.js:1:10603)
    at jxl_decoder_simd.min.js:1:25077
    at process (jxl.js:155:20)
    at jxl.js:72:33

electron-v23.2.0-win32-x64

Is there any solution?

Images that read in one chunk show up blurry

My current workaround is calling processChunk(0) inside if (chunk.done) { or in onFinish.

My first guess is maybe it's returning on dec_frame even if dec_full_image is available.

Support for embedded image decoding

Decoding support for base64 embedded jpeg xl images would be nice. Any plans for that?

Browser extension?

Just wondering out loud here, could this be implemented in a browser extension? It may not be practical to make users install an extension, but maybe it could perform better for those that do.

[edit] As another thought, could there be a ‘lite’ version for transcoded jpegs only? It could be smaller and decode back to jpeg for better performance.

Suggestion: replace image with canvas to avoid data URL conversion

Hey,

So first of all thanks for making this! It looks surprisingly simple (I guess the hard part is the wasm?)

Having said that, if I understand correctly the current approach is to load an image as a data URL. That has incredibly large memory overhead:

1. first we need to create the raw data
2. we create a canvas to put the raw data
3. then perform the string conversion by extracting the image from the canvas as a data URL (note: 6 bits of data are encoded per character, and officially JS is UTF16 so unless the browser uses an optimized internal 8-bit representation that's a 133% size increase due to wasting 10 bits)
4. then we need to set that string as a source in the DOM too.

As someone mentioned in a reddit thread discussing this polyfill, the result is that large images can crash browsers on less powerful machines.

Another thing is that setting the source to a data URL means that downloading the image will result in a PNG anyway. So there's no real benefit to an image over a canvas, since we're losing the JXL format anyway.

So my suggestion is to instead switch to "replacing" the image with the canvas you're already using now to get the data URL. Then the string conversion steps can be skipped. I think it could be as simple as:

    img.insertAdjacentElement("beforebegin", canvas);
    img.parentNode.removeChild(img);

Alternatively we might get away with inserting the <canvas> as a child to the <img> without removing the latter (in case other parts of the website expect the <img> element to exist), but I haven't thought that one through (maybe that actually lets people download the original jxl file?)

srcset causes infinite loop

Having jxl files in srcset attribute causes infinite loop.

Repo for repro:
https://github.com/joppuyo/jxl-js-responsive

PNG example (this works like it should)
https://joppuyo.github.io/jxl-js-responsive/srcset-png.html

JXL example (infinite loop, image doesn't display)
https://joppuyo.github.io/jxl-js-responsive/srcset-jxl.html

I think if srcset attribute exists, the blob uri should be replaced in the srcset attribute rather than src attribute.

Multithread version doesn't seem to work on WebKit-powered browsers (like on iOS)

Impressive work! I tried it on various browsers, even the multithread version worked on anything modern BUT webkit-powered browsers (such as, unfortunately, ALL browsers on iOS). Is there a way to do multithread on webkit? (The non-multithread does seem to work fine.)