Comment by jaffathecake
24 days ago
Because what you save in terms of storage, you pay for in decode time, which is an important consideration on the web.
24 days ago
Because what you save in terms of storage, you pay for in decode time, which is an important consideration on the web.
Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.
Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?
Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
3 replies →
I guess my surprise is mostly that it hasn't been adopted elsewhere. For instance, it still boggles my mind I can't store my JPEG XL images on Google Photos nor take photos as JPEG XL images directly on my Samsung smartphone, but can use HEIC for some fruity reason.
Google Photo teams wanted JXL too, but had to hold back due to Chromium not supporting them
The DoS thing would certainly make me worry about handling these images on my server.
You pay for decoding only when you view the image, whereas storage is a persistent cost.