Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

I'm a fan of JpegXL and happy to see support finally begin to coalesce around it on the browser scene, but I was wondering if anyone knew what goes into the decision of whether or not to consider adding encode support, e.g. via offscreenCanvas.convertToBlob() or whatever. How did browsers (minus Safari, of course) end up deciding to add support for WebP encode in addition to JPEG and PNG?

View on HN

It often comes down to compat, and developer requests. Personally I find in-browser encoding for images inadequate, because it doesn't expose enough options. When we built https://squoosh.app/, we exposed the browser encoders for completeness, but they're pretty bad compared to the wasm codecs.

I love your editor/comparison tool. Would you be open to adding browser WebP?

Is the JpegXL lossless options the "transparent JPEG recompression" or the actual lossless profile? I'm presuming the latter because it more than doubled the image size.

Yeah it's the latter. I'm going to look into adding transcoding, but Squoosh is currently set up to pass a bitmap to the encoder rather than the original image, because the original image can be processed first.

I can totally see how this feature would upend most architectures. Great work, I am adding a todo list action item up see if the performance can’t work out in favor of using this in place of the browser APIs we currently run to maybe adopt it. Love what you’ve done with the package and the site (this isn’t the first time it’s come on my radar, but you’ve spurred me to actually do something about it this time).

I love squoosh.app! Thanks so much for making that.

Reply on news.ycombinator.com