Now I'd only wish browsers could come up with more convenient ways to get around when some websites and upload fields don't support jxl or some other image format, and would either do something about it automatically or offer some option to get around it (convert to jpeg or png and upload, or 'paste as an image' which would pretty much be the same as png conversion, or something)
Firefox 157 will include JPEG XL by default on all platforms
31–40 of 139 posts
Re: Firefox 157 will include JPEG XL by default on all platforms
#32Earlier quoted context omitted.
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still d…
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferre…
> JpegXL will be the best of all worlds choice in a few years when software support is good.
Where is the software support lacking other than the browsers at this point?
Re: Firefox 157 will include JPEG XL by default on all platforms
#33Earlier quoted context omitted.
avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size…
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021):
https://github.com/dlemstra/Magick.NET/discussions/872
cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked:
$ cjxl src.jpg out.jxl
(some output)
$ djxl out.jxl rev.jpg
(more output)
$ cmp src.jpg rev.jpg
(no output: files identical)Re: Firefox 157 will include JPEG XL by default on all platforms
#34Re: Firefox 157 will include JPEG XL by default on all platforms
#35Earlier quoted context omitted.
avif also supports lossless, but it's so inefficient it might as well not exist. Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size…
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to. Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG. What am I misunderstanding here?
Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool.
(The IR used to be PixelPacket. Not sure how modern versions handle it.)
Re: Firefox 157 will include JPEG XL by default on all platforms
#36Re: Firefox 157 will include JPEG XL by default on all platforms
#37Earlier quoted context omitted.
What a funny tangent to go off on. JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices. I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking. [1] Worth noting…
[flagged]
I don't see what this has to do with the topic, sorry.
Re: Firefox 157 will include JPEG XL by default on all platforms
#38With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/ jxl-rs started to outperform the C++ library 2 months ago.
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
Re: Firefox 157 will include JPEG XL by default on all platforms
#39Earlier quoted context omitted.
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/ jxl-rs started to outperform the C++ library 2 months ago.
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
Because developers of security critical code don't flippantly merge LLM changes for marginal performance gain, and their time is incredibly valuable.